elga-cdaxds-2.06.2:XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet: Unterschied zwischen den Versionen
[unmarkierte Version] | [unmarkierte Version] |
Zeile 211: | Zeile 211: | ||
<sup>14</sup> Die deutsche Sprachvariante wird im SVS Format als Attribut „deutsch“ geführt, im CSV-Export als Spalte „meaning“. | <sup>14</sup> Die deutsche Sprachvariante wird im SVS Format als Attribut „deutsch“ geführt, im CSV-Export als Spalte „meaning“. | ||
+ | |||
+ | ====Spezifikation==== | ||
+ | {{BeginYellowBox}} | ||
+ | '''classCode (und classCodeDisplayName)''' wird gemäß folgender Vorschrift zusammengesetzt:<br/> | ||
+ | |||
+ | <span style="color:red;">$typeCode </span>= ClinicalDocument/code/@code<br/> | ||
+ | |||
+ | Mapping der Dokumentenklasse (feine Granularität) auf Sammelbegriff:<br/> | ||
+ | <span style="color:red;">$code = Mapping-Tabelle($typeCode)<br/> | ||
+ | $displayName = displayName($code)<br/> | ||
+ | $codeSystem = fixe OID aus der Mapping-Tabelle<br/></span> | ||
+ | <pre class="orange"> | ||
+ | <rim:Classification | ||
+ | classificationScheme= | ||
+ | "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" | ||
+ | classifiedObject="theDocument" | ||
+ | nodeRepresentation="$code"> | ||
+ | |||
+ | <rim:Name> | ||
+ | <rim:LocalizedString value="$displayName"/> | ||
+ | </rim:Name> | ||
+ | <rim:Slot name="codingScheme"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>urn:oid:$codeSystem</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | </rim:Classification> | ||
+ | </pre> | ||
+ | {{EndYellowBox}} | ||
+ | |||
+ | In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste “hl7-austria-Dokumentenklassen” OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at). | ||
+ | |||
+ | ===confidentialityCode=== | ||
+ | Das ''confidentialityCode'' Element beschreibt die Vertraulichkeitsstufe des Dokuments. | ||
+ | |||
+ | Die Konzeption des ELGA Berechtigungssystems sieht vor, den Zugriff auf Dokumente ausschließlich in der ELGA Infrastruktur zu verwalten, dementsprechend wird dieses Element vorerst nicht genutzt. | ||
+ | |||
+ | Die Angabe dieses verpflichtenden XDS Metadaten Elements ist dennoch erforderlich. Es wird der Vertraulichkeitscode aus dem CDA Header Element gemäß folgender Spezifikation übernommen: | ||
+ | {{BeginValueSetBox}} | ||
+ | Zulässige Werte gemäß Value Set „'''ELGA_Confidentiality'''“. | ||
+ | {{EndValueSetBox}} | ||
+ | |||
+ | ====Spezifikation==== | ||
+ | {{BeginYellowBox}} | ||
+ | confidentialityCode wird gemäß folgender Vorschrift zusammengesetzt:<br/> | ||
+ | |||
+ | <span style="color:red;">$code </span>= ClinicalDocument/confidentialityCode/@code<br/> | ||
+ | <span style="color:red;">$displayName </span>= ClinicalDocument/confidentialityCode/@displayName<br/> | ||
+ | <span style="color:red;">$codeSystem</span> = ClinicalDocument/confidentialityCode/@codeSystem<br/> | ||
+ | |||
+ | <spre class="orange"> | ||
+ | <rim:Classification | ||
+ | classificationScheme= | ||
+ | "urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" | ||
+ | classifiedObject="theDocument" | ||
+ | nodeRepresentation="$code"> | ||
+ | |||
+ | <rim:Name> | ||
+ | <rim:LocalizedString value="$displayName"/> | ||
+ | </rim:Name> | ||
+ | <rim:Slot name="codingScheme"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>urn:oid:$codeSystem</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | </rim:Classification> | ||
+ | </pre> | ||
+ | {{EndYellowBox}} | ||
+ | |||
+ | ===creationTime=== | ||
+ | Das creationTime Element beschreibt den Zeitpunkt der Dokumentenerstellung. Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN. | ||
+ | |||
+ | 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/effectiveTime | ||
+ | # Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentendatums ein verpflichtendes Element. | ||
+ | # 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 | ||
+ | CreationTime entfällt bei On-Demand Documents. | ||
+ | |||
+ | ====Spezifikation==== | ||
+ | {{BeginYellowBox}} | ||
+ | '''creationTime''' wird gemäß folgender Vorschrift zusammengesetzt:<br/> | ||
+ | <pre class="orange"> | ||
+ | ClinicalDocument/effectiveTime/@value | ||
+ | Bsp: 20100511134500 | ||
+ | </pre> | ||
+ | |||
+ | '''Hinweis: '''<br/> | ||
+ | creationTime MUSS – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein „Kürzen“ auf andere Formate ist nicht zulässig. | ||
+ | |||
+ | Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20100511193000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, '''MUSS '''diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20100511173000). | ||
+ | |||
+ | Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß [IHE ITI-TF3]. | ||
+ | {{EndYellowBox}} | ||
+ | |||
+ | ===eventCodeList (und eventCodeListDisplayName)=== | ||
+ | Im Fall eines Entlassungsbriefs beschreibt dieses Element die Liste der vollbrachten Gesundheitsdienstleistungen für den im Dokument dokumentierten Patientenkontakt. | ||
+ | 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 Gesundheits¬dienst¬leistung angegeben werden muss, und welche Bedeutung dieses Element hat. | ||
+ | |||
+ | ====Spezifikation==== | ||
+ | {{BeginYellowBox}} | ||
+ | '''eventCodeList (und eventCodeListDisplayName)''' wird gemäß folgender Vorschrift zusammengesetzt:<br/> | ||
+ | |||
+ | Für jedes documentationOf Element 1..n:<br/> | ||
+ | |||
+ | <span style="color:red;">$code </span>= ClinicalDocument/documentationOf[n]/serviceEvent/code/@code | ||
+ | <span style="color:red;">$displayName</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName | ||
+ | <span style="color:red;">$codeSystem</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystem | ||
+ | <pre class="orange"> | ||
+ | <rim:Classification | ||
+ | classificationScheme= | ||
+ | "urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4" | ||
+ | classifiedObject="theDocument" | ||
+ | nodeRepresentation="$code"> | ||
+ | |||
+ | <rim:Name> | ||
+ | <rim:LocalizedString value="$displayName"/> | ||
+ | </rim:Name> | ||
+ | <rim:Slot name="codingScheme"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>urn:oid:$codeSystem</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | </rim:Classification> | ||
+ | </pre> | ||
+ | {{EndYellowBox}} | ||
+ | |||
+ | ====Spezielle Vorschriften laut IHE PCC==== | ||
+ | Das PCC Profil definiert in Kapitel „Medical Document Bindings“ Spezialbehandlungen für gewissen Dokumenttypen (z.B.: XD-Lab, XDS-SD, BPPC). | ||
+ | |||
+ | Diese speziellen Vorschriften werden in ELGA '''nicht''' angewandt. | ||
+ | |||
+ | ===languageCode=== | ||
+ | Das languageCode Element beschreibt den Sprachcode in dem das Dokument verfasst ist. Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen: | ||
+ | ====Spezifikation==== | ||
+ | {{BeginYellowBox}} | ||
+ | '''languageCode''' wird gemäß folgender Vorschrift zusammengesetzt: | ||
+ | <pre class="orange"> | ||
+ | ClinicalDocument/languageCode/@code | ||
+ | Bsp: de-AT | ||
+ | </pre> | ||
+ | {{EndYellowBox}} | ||
+ | |||
+ | ===legalAuthenticator=== | ||
+ | Das ''legalAuthenticator'' Element beschreibt die Identifikation und demographische Informationen der Person, welche das Dokument rechtlich verbindlich unterzeichnet hat. Entfällt bei automatisch erstellten und nicht durch natürliche Personen freigegebenen Dokumenten (z.B. On-Demand Documents wie der „Medikationsliste“). | ||
+ | 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 | ||
+ | # 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==== | ||
+ | {{BeginYellowBox}} | ||
+ | '''legalAuthenticator''' wird gemäß folgender Vorschrift zusammengesetzt:<br/> | ||
+ | <pre class="orange"> | ||
+ | $person = ClinicalDocument/legalAuthenticator/assignedEntity | ||
+ | </pre> | ||
+ | <pre class="orange"> | ||
+ | concat( | ||
+ | $person/id/@extension,"^", | ||
+ | $person/assignedPerson/name/family,"^", | ||
+ | $person/assignedPerson/name/given[1],"^", | ||
+ | $person/assignedPerson/name/given[2],"^", | ||
+ | $person/assignedPerson/name/suffix,"^", | ||
+ | $person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&", | ||
+ | $person/id/@root,"&ISO" | ||
+ | ) | ||
+ | Bsp: 1234^Musterdoktor^Herbert^^^Dr.^^^&1.2.3.4.5.6.7.8.9&ISO | ||
+ | </pre> | ||
+ | Dies entspricht einer Transformation auf HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3]. | ||
+ | {{EndYellowBox}} | ||
+ | |||
+ | ===serviceStartTime / serviceStopTime=== | ||
+ | Die ''serviceStartTime/serviceStopTime'' Elemente beschreiben die Zeitpunkte des Beginns und Beendigung des Patientenkontakts/Behandlung. | ||
+ | |||
+ | Laut ELGA Implementierungsleitfäden ist in ELGA CDA Dokumenten die Angabe von mindestens einer Gesundheitsdienstleistung (“documentationOf/serviceEvent“) verpflichtend, wenn bekannt '''''[R2]'''''. | ||
+ | |||
+ | Wenn vorhanden, beinhaltet dieses Element die semantisch korrekten Informationen zu Start- und Enddatum gemäß der jeweiligen Fachdomäne (z.B.: das Aufnahme/Entlassungsdatum im Falle von Entlassungsbriefen aus stationärer Behandlung). Die relevanten Informationen dazu finden sich in den speziellen ELGA CDA Implementierungsleitfäden. | ||
+ | |||
+ | 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 | ||
+ | |||
+ | ====Spezifikation==== | ||
+ | {{BeginYellowBox}} | ||
+ | '''serviceStartTime''' wird gemäß folgender Vorschrift zusammengesetzt: | ||
+ | <pre class="orange"> | ||
+ | ClinicalDocument/documentationOf/serviceEvent/effectiveTime/low/@value | ||
+ | Bsp: 20110504120000 | ||
+ | </pre> | ||
+ | '''Hinweis: '''<br/> | ||
+ | Dieses Element MUSS – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein „Kürzen“ auf andere Formate ist nicht zulässig. | ||
+ | |||
+ | Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20100511193000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, '''MUSS''' diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20100511173000). | ||
+ | {{EndYellowBox}} | ||
+ | |||
+ | {{BeginYellowBox}} | ||
+ | '''serviceStopTime''' wird gemäß folgender Vorschrift zusammengesetzt: | ||
+ | <pre class="orange"> | ||
+ | ClinicalDocument/documentationOf/serviceEvent/effectiveTime/high/@value | ||
+ | Bsp: 20110510173000 | ||
+ | </pre> | ||
+ | '''Hinweis: '''<br/> | ||
+ | Dieses Element MUSS – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein „Kürzen“ auf andere Formate ist nicht zulässig. | ||
+ | |||
+ | Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20100511193000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, '''MUSS''' diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20100511173000). | ||
+ | {{EndYellowBox}} | ||
+ | |||
+ | ===sourcePatientId=== | ||
+ | Das ''sourcePatientId'' Element beschreibt die Patienten ID des Patienten im lokalen Informationssystem des GDA. | ||
+ | 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==== | ||
+ | {{BeginYellowBox}} | ||
+ | '''sourcePatientId''' wird gemäß folgender Vorschrift zusammengesetzt: | ||
+ | <pre class="orange"> | ||
+ | concat( | ||
+ | ClinicalDocument/recordTarget/patientRole/id[1]/@extension, "^^^&", | ||
+ | ClinicalDocument/recordTarget/patientRole/id[1]/@root, "&ISO" | ||
+ | ) | ||
+ | Bsp: 4711^^^&1.2.3.4.5.6.7.8.9&ISO | ||
+ | </pre> | ||
+ | Dies entspricht einer Transformation auf den HL7 v2 CX Datentyp gemäß [IHE ITI-TF3]. | ||
+ | {{EndYellowBox}} |
Version vom 10. August 2017, 11:31 Uhr
Inhaltsverzeichnis
- 1 XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet
- 1.1 authorInstitution
- 1.2 authorPerson
- 1.3 authorRole
- 1.4 authorSpeciality
- 1.5 classCode (und classCodeDisplayName)
- 1.6 confidentialityCode
- 1.7 creationTime
- 1.8 eventCodeList (und eventCodeListDisplayName)
- 1.9 languageCode
- 1.10 legalAuthenticator
- 1.11 serviceStartTime / serviceStopTime
- 1.12 sourcePatientId
1 XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet
1.1 authorInstitution
Das authorInstitution Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich das Dokument erstellt wurde.
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
- 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.
1.1.1 Spezifikation
authorInstitution wird gemäß folgender Vorschrift zusammengesetzt:
$inst … ClinicalDocument/author/assignedAuthor/representedOrganization
Fall 1
Element $inst/id[1] ist vorhanden
Attribut &inst/id[1]/@root ist vorhanden
Attribut &inst/id[1]/@extension ist nicht vorhanden
concat(
$inst/name,"^^^^^^^^^",
$inst/id[1]/@root
)
Bsp: Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45
Fall 2
Element $inst/id[1] ist vorhanden
Attribut &inst/id[1]/@root ist vorhanden
Attribut &inst/id[1]/@extension ist vorhanden
concat( $inst/name,"^^^^^&", $inst/id[1]/@root,"&ISO^^^^" $inst/id[1]/@extension ) Bsp: Unfallkrankenhaus Neusiedl^^^^^&1.2.3.4.5.6.7.8.9.1789&ISO^^^^45
Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß [IHE ITI-TF3].
1.2 authorPerson
Das Element authorPerson beschreibt die Identifikation und demographische Informationen der Person oder das Gerät/die Software, welche das Dokument inhaltlich erstellt hat (also nicht die Schreibkraft).
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
- Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält
- id … ID der Person mit den folgenden Attributen:
- 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
- Enthält ein Element mit dem Namen des Herstellers des Geräts oder der Software
- assignedAuthoringDevice
1.2.1 Spezifikation für Personen
authorPerson wird gemäß folgender Vorschrift zusammengesetzt:
$person = ClinicalDocument/author/assignedAuthor
concat(
$person/id/@extension,"^",
$person/assignedPerson/name/family,"^",
$person/assignedPerson/name/given[1],"^",
$person/assignedPerson/name/given[2],"^",
$person/assignedPerson/name/suffix,"^",
$person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&",
$person/id/@root,"&ISO"
)
Bsp: 1234^Musterdoktor^Herbert^^^Dr.^^^&1.2.3.4.5.6.7.8.9&ISO
Ist clinicalDocument/author/assignedAuthor/id mit einem NullFlavor angegeben, sind die entsprechenden Felder für @extension und @root leer zu lassen.
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].
1.2.2 Spezifikation für Software und Geräte
authorPerson wird gemäß folgender Vorschrift zusammengesetzt:
$person = ClinicalDocument/author/assignedAuthor
concat(
"^",
$person/assignedAuthoringDevice/manufacturerModelName,"^",
$person/assignedAuthoringDevice/softwareName
)
Bsp: ^Good Health System^Best Health Software Application
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].
1.3 authorRole
Das authorRole Element beschreibt die Rolle, die der inhaltliche Autor des Dokuments zum Zeitpunkt der Dokumentation innehatte.
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.
1.3.1 Spezifikation
authorRole wird gemäß folgender Vorschrift zusammengesetzt:
ClinicalDocument/author/functionCode/@displayName
Bsp: Diensthabender Oberarzt
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer
1.4 authorSpeciality
Das authorSpeciality Element beschreibt die Fachrichtung der Person, welche das Dokument verfasst hat.
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.
1.4.1 Spezifikation
authorSpeciality wird gemäß folgender Vorschrift zusammengesetzt:
ClinicalDocument/author/assignedAuthor/code/@displayName
Bsp: Anästhesiologie und Intensivmedizin
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer
1.5 classCode (und classCodeDisplayName)
Das classCode Element beschreibt die Dokumentenklasse (grobe Granularität) der das Dokument angehört und ist relevant für das Berechtigungssystem.
Unterscheidung classCode/typeCode:
classCode | Dokumentenklasse in grober Granularität |
---|---|
typeCode | Dokumentenklasse in feiner Granularität. Siehe Kapitel 2.2.15 |
Ausgangsbasis dieses Werts ist das Element ClinicalDocument/code, welches ELGA auf hierarchische Überbegriffe (die Dokumentenklasse) gemappt werden kann. Der Wert für classCode ergibt sich aus dieser Zusammenfassung.
Vorschrift für die Zusammenfassung ClassCode - TypeCode:
Als classCode MUSS dasjenige Element des Lvl-Typ „0“ des Value Sets „ELGA_Dokumentklassen“ angegeben werden, in dessen Unterelementen sich der Wert der Ausgangsbasis (ClinicalDocument/code) befindet. Weitere Informationen finden sich in den ELGA CDA Implementierungsleitfäden.
Beispiel:
Die Spezialisierungen des Entlassungsbriefes „Ärztlich“ und „Pflege“ werden unter dem Sammelbegriff „Entlassungsbrief“ zusammengefasst:
Lvl-Typ | Code (LOINC) | DisplayName | Deutsche Sprachvariante14 | Element in XDS |
---|---|---|---|---|
0-S | 18842-5 | Discharge summary | Entlassungsbrief | classCode |
1-L | 11490-0 | Physician Discharge summary | Entlassungsbrief Ärztlich | typeCode |
1-L | 34745-0 | Nurse Discharge summary | Entlassungsbrief Pflege | typeCode |
Als typeCode wird 11490-0 oder 34745-0 angegeben, als classCode entsprechend 18842-5.
14 Die deutsche Sprachvariante wird im SVS Format als Attribut „deutsch“ geführt, im CSV-Export als Spalte „meaning“.
1.5.1 Spezifikation
classCode (und classCodeDisplayName) wird gemäß folgender Vorschrift zusammengesetzt:
$typeCode = ClinicalDocument/code/@code
Mapping der Dokumentenklasse (feine Granularität) auf Sammelbegriff:
$code = Mapping-Tabelle($typeCode)
$displayName = displayName($code)
$codeSystem = fixe OID aus der Mapping-Tabelle
<rim:Classification classificationScheme= "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject="theDocument" nodeRepresentation="$code"> <rim:Name> <rim:LocalizedString value="$displayName"/> </rim:Name> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>urn:oid:$codeSystem</rim:Value> </rim:ValueList> </rim:Slot> </rim:Classification>
In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste “hl7-austria-Dokumentenklassen” OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
1.6 confidentialityCode
Das confidentialityCode Element beschreibt die Vertraulichkeitsstufe des Dokuments.
Die Konzeption des ELGA Berechtigungssystems sieht vor, den Zugriff auf Dokumente ausschließlich in der ELGA Infrastruktur zu verwalten, dementsprechend wird dieses Element vorerst nicht genutzt.
Die Angabe dieses verpflichtenden XDS Metadaten Elements ist dennoch erforderlich. Es wird der Vertraulichkeitscode aus dem CDA Header Element gemäß folgender Spezifikation übernommen:
Zulässige Werte gemäß Value Set „ELGA_Confidentiality“.
1.6.1 Spezifikation
confidentialityCode wird gemäß folgender Vorschrift zusammengesetzt:
$code = ClinicalDocument/confidentialityCode/@code
$displayName = ClinicalDocument/confidentialityCode/@displayName
$codeSystem = ClinicalDocument/confidentialityCode/@codeSystem
<spre class="orange"> <rim:Classification
classificationScheme= "urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="theDocument" nodeRepresentation="$code">
<rim:Name> <rim:LocalizedString value="$displayName"/> </rim:Name> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>urn:oid:$codeSystem</rim:Value> </rim:ValueList> </rim:Slot>
</rim:Classification> </pre>
1.7 creationTime
Das creationTime Element beschreibt den Zeitpunkt der Dokumentenerstellung. Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.
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/effectiveTime
- Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentendatums ein verpflichtendes Element.
- 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
CreationTime entfällt bei On-Demand Documents.
1.7.1 Spezifikation
creationTime wird gemäß folgender Vorschrift zusammengesetzt:
ClinicalDocument/effectiveTime/@value Bsp: 20100511134500
Hinweis:
creationTime MUSS – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein „Kürzen“ auf andere Formate ist nicht zulässig.
Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20100511193000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, MUSS diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20100511173000).
Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß [IHE ITI-TF3].
1.8 eventCodeList (und eventCodeListDisplayName)
Im Fall eines Entlassungsbriefs beschreibt dieses Element die Liste der vollbrachten Gesundheitsdienstleistungen für den im Dokument dokumentierten Patientenkontakt. 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 Gesundheits¬dienst¬leistung angegeben werden muss, und welche Bedeutung dieses Element hat.
1.8.1 Spezifikation
eventCodeList (und eventCodeListDisplayName) wird gemäß folgender Vorschrift zusammengesetzt:
Für jedes documentationOf Element 1..n:
$code = ClinicalDocument/documentationOf[n]/serviceEvent/code/@code $displayName = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName $codeSystem = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystem
<rim:Classification classificationScheme= "urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4" classifiedObject="theDocument" nodeRepresentation="$code"> <rim:Name> <rim:LocalizedString value="$displayName"/> </rim:Name> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>urn:oid:$codeSystem</rim:Value> </rim:ValueList> </rim:Slot> </rim:Classification>
1.8.2 Spezielle Vorschriften laut IHE PCC
Das PCC Profil definiert in Kapitel „Medical Document Bindings“ Spezialbehandlungen für gewissen Dokumenttypen (z.B.: XD-Lab, XDS-SD, BPPC).
Diese speziellen Vorschriften werden in ELGA nicht angewandt.
1.9 languageCode
Das languageCode Element beschreibt den Sprachcode in dem das Dokument verfasst ist. Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
1.9.1 Spezifikation
languageCode wird gemäß folgender Vorschrift zusammengesetzt:
ClinicalDocument/languageCode/@code Bsp: de-AT
1.10 legalAuthenticator
Das legalAuthenticator Element beschreibt die Identifikation und demographische Informationen der Person, welche das Dokument rechtlich verbindlich unterzeichnet hat. Entfällt bei automatisch erstellten und nicht durch natürliche Personen freigegebenen Dokumenten (z.B. On-Demand Documents wie der „Medikationsliste“). 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
- 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
- Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält
- id … ID der Person mit den folgenden Attributen:
1.10.1 Spezifikation
legalAuthenticator wird gemäß folgender Vorschrift zusammengesetzt:
$person = ClinicalDocument/legalAuthenticator/assignedEntity
concat( $person/id/@extension,"^", $person/assignedPerson/name/family,"^", $person/assignedPerson/name/given[1],"^", $person/assignedPerson/name/given[2],"^", $person/assignedPerson/name/suffix,"^", $person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&", $person/id/@root,"&ISO" ) Bsp: 1234^Musterdoktor^Herbert^^^Dr.^^^&1.2.3.4.5.6.7.8.9&ISO
Dies entspricht einer Transformation auf HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].
1.11 serviceStartTime / serviceStopTime
Die serviceStartTime/serviceStopTime Elemente beschreiben die Zeitpunkte des Beginns und Beendigung des Patientenkontakts/Behandlung.
Laut ELGA Implementierungsleitfäden ist in ELGA CDA Dokumenten die Angabe von mindestens einer Gesundheitsdienstleistung (“documentationOf/serviceEvent“) verpflichtend, wenn bekannt [R2].
Wenn vorhanden, beinhaltet dieses Element die semantisch korrekten Informationen zu Start- und Enddatum gemäß der jeweiligen Fachdomäne (z.B.: das Aufnahme/Entlassungsdatum im Falle von Entlassungsbriefen aus stationärer Behandlung). Die relevanten Informationen dazu finden sich in den speziellen ELGA CDA Implementierungsleitfäden.
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
1.11.1 Spezifikation
serviceStartTime wird gemäß folgender Vorschrift zusammengesetzt:
ClinicalDocument/documentationOf/serviceEvent/effectiveTime/low/@value Bsp: 20110504120000
Hinweis:
Dieses Element MUSS – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein „Kürzen“ auf andere Formate ist nicht zulässig.
Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20100511193000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, MUSS diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20100511173000).
serviceStopTime wird gemäß folgender Vorschrift zusammengesetzt:
ClinicalDocument/documentationOf/serviceEvent/effectiveTime/high/@value Bsp: 20110510173000
Hinweis:
Dieses Element MUSS – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein „Kürzen“ auf andere Formate ist nicht zulässig.
Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20100511193000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, MUSS diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20100511173000).
1.12 sourcePatientId
Das sourcePatientId Element beschreibt die Patienten ID des Patienten im lokalen Informationssystem des GDA. 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)
Achtung: Diese ID gelangt nicht in die Metadaten!
1.12.1 Spezifikation
sourcePatientId wird gemäß folgender Vorschrift zusammengesetzt:
concat( ClinicalDocument/recordTarget/patientRole/id[1]/@extension, "^^^&", ClinicalDocument/recordTarget/patientRole/id[1]/@root, "&ISO" ) Bsp: 4711^^^&1.2.3.4.5.6.7.8.9&ISO
Dies entspricht einer Transformation auf den HL7 v2 CX Datentyp gemäß [IHE ITI-TF3].