320
Bearbeitungen
Änderungen
→Bildungsregel für den formatCodeDisplayName
{| class="wikitable"
|- style="background:white"
| '''''classCode'''''| '''''Dokumentenklasse in grober Granularität'''''|-style="background:white"| ''typeCode''| Dokumentenklasse in feiner Granularität.<br/> Siehe Kapitel [[ILF:XDS Metadaten 2020#typeCode_.28und_typeCodeDisplayName.29|4.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. {{BeginYellowBox}}Vorschrift für die Zusammenfassung ClassCode - TypeCode:<br/>Als classCode MUSS dasjenige Element des Lvl-Typ „0“ des Value Sets „'''ELGA_Dokumentenklassen'''“ angegeben werden, in dessen Unterelementen sich der Wert der Ausgangsbasis (ClinicalDocument/code) befindet. Weitere Informationen finden sich in den ELGA CDA Implementierungsleitfäden.{{EndYellowBox}} Beispiel: Die Spezialisierungen des Entlassungsbriefes „Ärztlich“ und „Pflege“ werden unter dem Sammelbegriff „Entlassungsbrief“ zusammengefasst:{| class="wikitable"! Lvl-Typ! Code (LOINC)! DisplayName! Deutsche Sprachvariante<sup>15</sup>! Element in XDS
|- style="background:white"
|''' 0-S'''|''' 18842-5'''| Discharge summary| Entlassungsbrief| '''classCode'typeCode''|-style="backgroundDokumentenklasse in feiner Granularität.<br /> Siehe Kapitel [[ILF:white"XDS Metadaten 2020#typeCode_.28und_typeCodeDisplayName.29| 1-L| 11490-0| Physician Discharge summary| Entlassungsbrief Ärztlich| typeCode|-style="background:white"| 1-L| 34745-0| Nurse Discharge summary| Entlassungsbrief Pflege| typeCode4.2.15]]
|}
====Spezifikation====
'''classCode (und classCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:<br/> TODO: <span >$typeCode </span>= ClinicalDocument/codetranslation/@codedisplayName<br/span>ist im CDA optional, in XDS jedoch 1..1 M
<pre class="ILFgreen">
<Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
# Im CDA wird die Klassifizierung des Dokuments 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
# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe dieser 3 Attribute des Elements code verpflichtend.
====Spezifikation====
Beispiel 1: setId/@root und setId/@extension sind im CDA strukturiert. In /@extension wird KEINE UUID angegeben.
<pre class="ILFgreen"><ClinicalDocument xmlns=„urn"urn:hl7-org:v3“v3">
…
<setId root="1.2.40.0.34.99.111.1.1" extension="ZZZZZZZZZZZZZZZZZZZ"/>
<versionNumber value="2"/>
…
</ClinicalDocument>
</pre>
Wie oben angeführt wird folgender CXi Wert erstellt:
Beispiel 2: in setId/@extension im CDA wird eine UUID geführt
<pre class="ILFgreen"><ClinicalDocument xmlns=„urn"urn:hl7-org:v3“v3">
…
<setId root="2.25" extension="urn:uuid:19FEE6C3-6B35-4C5B-B1CC-2B5B4001AB2"/>
<versionNumber value="2"/>
…
</ClinicalDocument>
</pre>
Wie oben angeführt wird folgender CXi Wert erstellt:
"<nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^</nowiki>&amp;2.25&amp;ISO^urn:elga:iti:xds:2014:ownDocument_setId^&amp;1.2.40.0.34.99.999&amp;ISO"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
</Slot>
</ExtrinsicObject>
</pre>
===intendedRecipient===
====Bildungsregel für den formatCodeDisplayName ====
TODO: Prüfen, ob diese Vorgabe Bildungsregel noch gültig ist. Weiters ist FormatCodeDisplayName ist nicht Teil des CDA, allerdings 1..1 M nach IHE XDS.
Der formatCodeDisplayName ist analog zum formatCode aus den displayNames des entsprechenden Value Sets [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS] zu bilden, auch bei der Bildung der Zusätze (Das Format MUSS mittels „:“ (Doppelpunkt) am Ende angefügt werden, das Plus-Zeichen am Ende des FormatcodeDisplayNames).
|y
|Kapitel 1.11.1 "Spezifikation": Verbot von CR und LF hinzugefügt.
|-
|
|
|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalität von "sourcePatientInfo" zu X angepasst.
|-
|
|
|Kapitel "4.2.10 sourcePatientInfo" angepasst. Name, Geschlecht, Geburtsdatum und Adressdaten sind für die Nutzung der XDS Metadaten nicht erforderlich
|-
|
|
|Kapitel "4.2.7 legalAuthenticator" angepasst. Es wird immer das erste Vorkommen von ClinicalDocument/legalAuthenticator[1] in die XDS-Metadaten übernommen.
|-
|
|
|Kapitel "4.2.4 creationTime": Bedeutung von ClinicalDocument.effectiveTime präzisiert
|-
|
|y
|Kapitel "4.3.3 "healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "healthCareFacility" hinzugefügt.
|-
|
|y
|Kapitel "4.3.2 formatCode (und formatCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "hl7at:formatCode" hinzugefügt.|-|||Kapitel "4.2.2.1 Spezifikation": Ableitungsvorschrift aus dem CDA-Header Element "ClinicalDocument/code/translation" für XDS DocumentEntry.classCode hinzugefügt.
|}
