320
Bearbeitungen
Änderungen
→XDS Metadaten für CDA Dokumente
=XDS Metadaten für CDA Dokumente=
Die folgenden Kapitel spezifizieren die XDS-Metadaten von HL7 CDA-Dokumenten für deren Verwendung in ELGA. Nicht weiter eingeschränkte Metadaten sind nicht angeführt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, vol3, rev. 17, "Table 4.2.3.2-1 “DocumentEntry Metadata Attribute Definition”" angeführt.
==XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet==
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
#Laut Festlegung in den ELGA Gesundheitsdaten wird die Organisation, der der Autor des Dokuments angehört grundsätzlich in folgendem Element abgelegt:##ClinicalDocument/author/assignedAuthor/representedOrganization#Ein Organisationselement in CDA beinhaltet unter anderem die folgenden Unterelemente:##'''id'''[1] … ID der Organisation mit den folgenden Attributen:###@root … Root OID des ID Pools, oder direkte die OID der Organisation (ohne @extension-Attribut)###@extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Organisation identifiziert)##'''name''' … Name der Organisation als String<br /> Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, soll das name Element SOLL einer möglichst eindeutigen Kurzbezeichnung der Organisation entsprechen (im GDA-I im Tag description enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird.<br /> Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz" # GDAs, in dessen Gültigkeitsbereich Dokumente erstellt werden können sind seitens der Basiskomponente „GDA Index“ mit einer eindeutigen OID ausgestattet. # Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird.
<span >$inst</span> … ClinicalDocument/author/assignedAuthor/representedOrganization
*Fall 1:<br />
concat(<br/><span>$inst</span>/name,"^^^^^^^^^",<br/><span>$inst</span>/id[1]/@root<br/>)<br/>
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
*Fall 2:<br/> Element $inst/id[1] ist vorhanden<br/>Attribut $inst/id[1]/@root ist vorhanden<br/>Attribut $inst/id[1]/@extension ist vorhanden<br/>
concat(<br/><span >$inst</span>/name,"^^^^^&",<br/><span >$inst</span>/id[1]/@root,"&ISO^^^^"<br/><span >$inst</span>/id[1]/@extension<br/>)<br/>
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit CDA Header Elementen:
# Laut Festlegung wird der Autor im Header-Element „author“ abgelegt:## ClinicalDocument/author/assignedAuthor# Der Autor (Person)## Ein Personenelement enthält unter anderem die folgenden Unterelemente:### id … ID der Person mit den folgenden Attributen:#### @root … Root OID des ID Pools, oder direkte die OID der Person (ohne @extension-Attribut)#### @extension … Eigentliche ID aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)### assignedPerson#### Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält##### name# Gerät oder Software als Autor ## Alternativ zu einer Person kann auch ein Gerät oder eine Software als Autor aufscheinen, dann sind die folgenden Unterelemente verfügbar:### assignedAuthoringDevice#### Enthält ein Element mit dem Namen des Herstellers des Geräts oder der Software ##### manufacturerModelName#### Enthält ein Element mit dem Namen des Geräts oder der Software ##### softwareName
=====Spezifikation für Personen=====
'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
<span > $person</span> = ClinicalDocument/author/assignedAuthor
concat(<br/><span > $person</span>/id/@extension,"^",<br/><span > $person</span>/assignedPerson/name/family,"^",<br/><span > $person</span>/assignedPerson/name/given[1],"^",<br/><span > $person</span>/assignedPerson/name/given[2],"^",<br/><span > $person</span>/assignedPerson/name/suffix,"^",<br/><span > $person</span>/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;",<br/><span > $person</span>/id/@root,"&amp;ISO"<br/>)<br/>
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
<span > $person</span> = ClinicalDocument/author/assignedAuthor
concat(<br/>"^",<br/><span > $person</span>/assignedAuthoringDevice/manufacturerModelName,"^",<br/><span > $person</span>/assignedAuthoringDevice/softwareName<br/>)<br/>
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
Beispiel:
* „Diensthabender Oberarzt“* „Verantwortlicher diensthabender Arzt für die Dokumenterstellung“
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
# Laut Festlegung wird die „Rolle“ der Person, welche das Dokument inhaltlich erstellt hat im Element functionCode des Autors abgelegt:## ''ClinicalDocument/author/functionCode''# Die Angabe einer Rolle des Autors ist in ELGA ein verpflichtendes Element, wenn vorhanden '''''[R2]'''''.# Wenn das Element angegeben ist, wird die Rolle als Text im Attribut @displayName erwartet.
=====Spezifikation=====
'''authorRole''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
ClinicalDocument/author/functionCode/@displayName<br/>
<pre class="ilfbox_code"><Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
Beispiel:
* „Facharzt für Gynäkologie“* „Facharzt für interne Medizin“
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
# Laut Festlegung wird die „Fachrichtung“ der Person, welche das Dokument inhaltlich erstellt hat im Element code des Autors abgelegt:## ''ClinicalDocument/author/assignedAuthor/code''# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer Fachrichtung des Autors ein verpflichtendes Element, wenn vorhanden '''''[R2]'''''.# Wenn das Element angegeben ist, wird die Fachrichtung als Text im Attribut @displayName erwartet.
======Spezifikation======
'''authorSpeciality''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
ClinicalDocument/author/assignedAuthor/code/@displayName<br/>
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
====Spezifikation====
confidentialityCode wird als ebRIM Slot gemäß folgendem Beispiel abgebildet:<br/>
<pre class="ilfbox_code">
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
# Im CDA wird der Zeitpunkt der Dokumentenerstellung wie folgt abgelegt:## ClinicalDocument/effectiveTime# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentendatums ein verpflichtendes Element.
#Im CDA wird jeweils das medizinisch zutreffendste Datum angeführt. Die Bedeutung des Datums ist für jede einzelne Dokumentenklasse im zugehörigen speziellen Leitfaden separat definiert werden.
# Ein einfaches Zeitelement (HL7 TS) in CDA beinhaltet unter anderem die folgenden Attribute:# @value … enthält das Datum in folgenden möglichen Formen## YYYYMMDD## YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)### Bsp: 20081224082015+0100### Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
{{BeginYellowBox}}
CreationTime entfällt bei On-Demand Documents.
====Spezifikation====
'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br/>
ClinicalDocument/effectiveTime/@value = "20200511193000+0200"
<pre class="ilfbox_code">
Im allgemeinen Fall eines beliebigen CDA R2 Dokuments gilt grundsätzlich folgende Verknüpfung mit den CDA Header Elementen:
# Im CDA wird die Liste der Service-Events wie folgt abgelegt:## ClinicalDocument/documentationOf/serviceEvent# Mehrere dieser Service-Events können durch beliebig viele „documentationOf“ Elemente ausgedrückt werden.# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe mindestens eines Service-Events verpflichtend, wenn bekannt [R2].# Ein serviceEvent Element in CDA beinhaltet unter anderem die folgenden Elemente:## code … ein Code-Element, welches die Art des ServiceEvents angibt
Die Vorschriften zur Befüllung der CDA R2 ServiceEvents leiten sich vom Allgemeinen und vom jeweiligen speziellen CDA Implementierungsleitfäden ab. In den speziellen Implementierungsleitfäden wird definiert, ob im Service Event eine Gesundheitsdienstleistung angegeben werden muss, und welche Bedeutung dieses Element hat.
====Spezifikation====
'''eventCodeList (und eventCodeListDisplayName)''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br/>
Für jedes documentationOf Element 1..n:<br/>
<span >$code </span>= ClinicalDocument/documentationOf[n]/serviceEvent/code/@code<br/><span >$displayName</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName<br/><span >$codeSystem</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystem<br/>
<pre class="ilfbox_code">
<Classification
Für CDA R2 Dokumente gilt folgende Verknüpfung mit den CDA Header Elementen:
# Laut Festlegung wird die Person, welche das Dokument vidiert hat, im Element „legalAuthenticator“ abgelegt:## ClinicalDocument/legalAuthenticator/assignedEntity
{{BeginYellowBox}}
'''ACHTUNG:''' Nach DocumentEntry.legalAuthenticator kann jeweils nur das erste Element (ClinicalDocument/LegalAuthenticator[1]) übernommen werden.
{{EndYellowBox}}
# Die vidierende Person## Ein Personenelement in CDA beinhaltet unter anderem die folgenden Unterelemente:### id … ID der Person mit den folgenden Attributen:#### @root … Root OID des ID Pools, oder direkte die OID der Person (ohne @extension-Attribut)#### @extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)### assignedEntity#### Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält##### Name
====Spezifikation====
'''legalAuthenticator''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br/>
<span > $person </span>= ClinicalDocument/legalAuthenticator/assignedEntity
concat(<br/><span > $person</span>/id/@extension,"^",<br/><span > $person</span>/assignedPerson/name/family,"^",<br/><span > $person</span>/assignedPerson/name/given[1],"^",<br/><span > $person</span>/assignedPerson/name/given[2],"^",<br/><span > $person</span>/assignedPerson/name/suffix,"^",<br/><span > $person</span>/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;",<br/><span > $person</span>/id/@root,"&amp;ISO"<br/>)<br/>
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe von mindestens einem Service-Event verpflichtend:## ClinicalDocument/documentationOf/serviceEvent# Das Element serviceEvent beinhaltet unter anderem die folgenden Unterelemente:## effectiveTime gibt das Zeitintervall an, in dem die Gesundheitsdienstleistung durchgeführt wurde## Laut Vorgabe der ELGA Gesundheitsdaten SOLL ein Zeitintervall (HL7 IVL_TS) in wie folgt angeordnet werden:### low … enthält das Startdatum### high … enthält das Endedatum### Andere im CDA möglichen Angaben (low/width, width/high, ...) sind nicht gestattet
TODO: '''Welches serviceEvent''' für das Mapping verwendet wird, muss im Speziellen Leitfaden angegeben sein.
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
# Im CDA wird die ID des Patienten in folgendem Element abgelegt:## ClinicalDocument/recordTarget/patientRole/id# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe von mindestens den folgenden zwei IDs des Patienten im CDA verpflichtend bzw. verpflichtend, wenn bekannt:## id[1] … Lokale ID des Patienten vom einbringenden System## d[2] … Österreichische Sozialversicherungsnummer (nur wenn bekannt)<br/><span style="color:red;">Achtung: Diese ID gelangt nicht in die Metadaten!</span>
====Spezifikation====
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumententitels verpflichtend:## ClinicalDocument/title
====Spezifikation====
{| class="wikitable"
|- style="background:white"
| '''typeCode'''| '''Dokumentenklasse in feiner Granularität (Spezialisierung).'''
|- style="background:white"
| classCode| Dokumentenklasse in grober Granularität.<br/> Siehe Kapitel [[ILF:XDS Metadaten 2020#classCode_.28und_classCodeDisplayName.29|classCode]]
|}
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
# Im CDA wird die Klassifizierung des Dokuments wie folgt abgelegt:## ClinicalDocument/code# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentencodes ein verpflichtendes Element.# Ein Code-Element in CDA beinhaltet unter anderem die folgenden Attribute:## @code … Codierter Wert der Dokumentenklasse### Bsp: Code „11490-0“## @displayName … Lesbarer Wert der Dokumentenklasse### Bsp: „Discharge summarization note (physician)”## @codeSystem … Codierter Wert des zugrundliegenden Codesystems### Bsp: „2.16.840.1.113883.6.1“# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe dieser 3 Attribute des Elements code verpflichtend.
====Spezifikation====
'''typeCode (und typeCodeDisplayName)''' wird wird als ebRIM Classification zum DocumentEntry umgesetzt und gemäß folgender Vorschrift zusammengesetzt:
<span > $code</span> = ClinicalDocument/code/@code<br/><span > $displayName</span> = ClinicalDocument/code/@displayName<br/><span > $codeSystem</span> = ClinicalDocument/code/@codeSystem<br/>
<pre class="ilfbox_code">
<Classification
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer ID für das Dokument verpflichtend:## ClinicalDocument/id
====Spezifikation====
uniqueId wird als ebRIM ExternalIdentifier zum DocumentEntry gemäß folgender Vorschrift zusammengesetzt:<br/>
Fall 1<br/>
Attribut ClinicalDocument/id/@extension ist nicht vorhanden
$value = concat(ClinicalDocument/id/@root)
Fall 2<br/>
Attribut ClinicalDocument/id/@extension ist vorhanden
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
# Laut Vorgabe der ELGA Dokumenten Leitfäden ist die Angabe einer setId für das Dokument verpflichtend: ## ClinicalDocument/setId
====Spezifikation====
Mögliche Werte laut IHE sind:
* Approved* Deprecated
Dieses Attribut wird im Zuge des Einbringens von neuen Dokumenten („Submission“) durch die empfangende XDS Registry immer auf “'''Approved'''” gesetzt.
Im CDA-Schema wurde für die HL7-Austria Domäne ein genau entsprechendes Element geschaffen, "hl7at:formatCode".
====Bildungsregel für den formatCodeDisplayName ====
TODO: Prüfen, ob diese Bildungsregel noch gültig ist. Weiters ist FormatCodeDisplayName ist nicht Teil des CDA, allerdings 1..1 M nach IHE XDS.
'''Beispiele:'''
* '''ELGA Entlassungsbrief Ärztlich, EIS Basic v2.06:PDF'''* '''ELGA Entlassungsbrief Pflege, EIS Enhanced v2.06+'''* '''ELGA Laborbefund, EIS Full Support v2.06+'''
====Spezifikation====
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:<br/><span >$code</span> = ClinicalDocument/hl7at:formatCode/@code <br/><span >$displayName</span> = gemäß Liste der in ELGA gültigen FormatCodes<br/><span >$codeSystem</span> = OID der Liste der in ELGA gültigen FormatCodes, fixiert mit OID 1.2.40.0.34.5.37 von [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS]
<pre class="ilfbox_code">
<Classification
'''healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:
<span >$code </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@code
<span >$displayName </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@displayName
<span >$codeSystem </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@codeSystem
<pre class="ilfbox_code">
'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.
Folgende Mime-Types sind für Dokumente zugelassen:<br/>CDA R2: '''text/xml'''<br/>DICOM/KOS: '''application/dicom'''<br/>
<pre class="ilfbox_code">
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
# Im CDA werden die Informationen über Dokumente, die mit dem eingebrachten Dokumenten in einer bestimmten Relation stehen, in folgendem Element abgelegt:## ClinicalDocument/relatedDocument# Der Typ der Relation MUSS verpflichtend in folgendem Attribut angegeben werden:## ClinicalDocument/relatedDocument/@typeCode## Folgende Relationen sind in ELGA erlaubt (siehe „[[ILF:Allgemeiner Implementierungsleitfaden 2020|Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente]]“ [1]):### Versionierung (RPLC)# Das zugrundeliegende Dokument (auf welches die Art der Relation wirkt), wird in folgendem Element angegeben:## ClinicalDocument/relatedDocument/parentDocument
====Spezifikation====
ClinicalDocument/relatedDocument/@typeCode
'''practiceSettingCode (und practiceSettingCodeDisplayName)''' wird als ebRIM Classificationgemäß folgender Vorschrift zusammengesetzt:
<span >$code</span> = ClinicalDocument/hl7at:practiceSettingCode/@code<br/><span >$displayName</span> = ClinicalDocument/hl7at:practiceSettingCode/@displayName<br/><span >$codeSystem</span> = ClinicalDocument/hl7at:practiceSettingCode/@codeSystem<br/>
<pre class="ilfbox_code">
<Classification
</pre>
===objectType ===
Das objectType Element gibt den Typ des XDS DocumentEntry wieder. Entsprechend den IHE XDS Vorgaben wird zwischen den Typen „stabiles Dokument“ (stable document, SD) und „On-demand Dokument“ (on-demand document, ODD) unterschieden. Der objectType ist als ebRIM ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziert.
===elgaFlag===
Das elgaFlag dient zur Kennzeichnung eines Dokuments als „ELGA-Dokument“<sup>18</sup>. Ein XDS Source des ELGA-Bereiches sendet eine „XDS.b Provide and Register Transaktion [ITI-41]“, eine „XDS.b Register Document Transaktion [ITI-42]“ oder eine „XDS Update Document [ITI-57]“ an die ELGA-Zugriffssteuerungsfassade (ZGF). Hierbei wird das Attribut „elgaFlag“ entsprechend dem Ergebnis der Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Zugriffssteuerungsfassade (ZGF) explizit gesetzt. „elgaFlag“ kann folgende Werte annehmen:
* "true" oder* "false"
====Spezifikation====
<!--Anhänge-->
<references />
=Anhänge=
