622
Bearbeitungen
Änderungen
→IHE XDM
Für den Export der beschlossenen Normdaten wird als Basis das IHE XDM (Cross-Enterprise Document Media Interchange) Profile herangezogen. Dieses Profile ist in den IHE Technical Frameworks IT-Infrastructur definiert (IHE-ITI Vol1<ref name="ITI_Vol1">[https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf], IHE-ITI Vol1</ref> und IHE-ITI Vol2b<ref name="ITI_Vol2b"/>). Das XDM Profil definiert wie Daten abseits einer technischen Infrastruktur geteilt werden können, es definiert also den Austausch von Daten über Datenträger (z.B. USB-Speicherstick, CD/DVD). Hierzu wird in XDM eine Verzeichnisstruktur vorgegeben. Betreffend der verspeicherten Fileformate ist das Profil jedoch agnostisch. Das bedeutet, dass mithilfe von XDM nicht nur CDA (XML) Dokumente übertragen werden können, sondern auch die anderen geforderten Dokumentenklassen wie z.B.: iCalander, .json. Anzumerken ist, dass IHE XDM für die Datei- und Ordnerbezeichnungen den ISO9660 Standard vorschreibt. Dies bedeutet, dass für die Benennung die "8.3" Konvention zu verwenden ist. Im Zuge dieses Leitfadens und basierend auf der Anforderung, dass .json Dateien verwendet werden können, wird bewusst gegen die ISO9660 und somit IHE XDM verstoßen (es gibt keine Dateiextension für .json mit nur 3 Zeichen).
In der nachfolgenden Tabelle werden die einzelnen Inhaltselemente des METADATA.XML-Files aufgelistet. Hinsichtlich des Konformanzkriteriums wird zwischen stable Documents (SD) und on-demand documents (ODD) unterschieden. Erstere sind Dokumenten, welche im klassischen Sinnen von einem Autor erzeugt wurden und als Beispiele hierzu zählen im Kontext des Exportnormdatensatzes die ELGA eBefunde. On-demand Documents sind Dokumente, welche im Zuge der generieren des Exportnormdatensatzes automatisch erstellt werden. Beispiele hierzu ist das „Datenbankexport“-CDA selbst oder auch JSON-Files, welche Abrechnungsdaten beinhalten.
Die Konformanzkriterien basieren auf den Anforderungen der IHE und weichen bei manchen Elementen von den Anforderungen der ELGA-XDS Metadaten ab. Dies ist Aufgrund der Tatsache erklärbar, dass ELGA den Fokus auf den ungerichteten Dokumentenaustausch mittels IHE XDS legt und der gegenständliche Leitfaden den trägermediumgebunden (CDA, USB Speicherstick) Austausch auf Basis von IHE XDM legt. Zudem werden in ELGA nur CDA Dokumente mittels IHE XDS verfügbar gemacht und im Kontext des Exportnormdatensatzes können auch andere Dateiformate inkludiert sein. Hinsichtlich der Vorschriften des Mappings von CDA-Headerelement zu den XDS-Metadaten werden die Spezifikationen von ELGA angewendet.
{| class="wikitable"
|+
! rowspan="2" |Ebene
! rowspan="2" |Element
! colspan="2" |Konformanz
! colspan="2" |Kommentar
|-
!SD
!ODD
!CDA Dokumente
!NICHT CDA Dokumente
|-
|SubmissionSet
|author
| colspan="2" |R
| colspan="2" |
|-
|SubmissionSet
|availabilityStatus
| colspan="2" |O
| colspan="2" |
|-
|SubmissionSet
|comments
| colspan="2" |O
| colspan="2" |
|-
|SubmissionSet
|contentTypeCode
| colspan="2" |NP
| colspan="2" |contentTypeCode beschreibt die medizische Dienstleistung welche der Generierung des XDM Datensatzen zu Grunde liegt. Aufgrund der Tatsache, dass der Export NICHT auf einer medizischen Dienstleistung beruht, wird der contentTypeCode NICTH im Kontext von EXNDS verwendet.
|-
|SubmissionSet
|entryUUID
| colspan="2" |R
| colspan="2" |
|-
|SubmissionSet
|homeCommunityId
| colspan="2" |O
| colspan="2" |Laut ELGA wäre dieser Eintrag verpflichtend. Laut IHE für XDM optional. Weil nicht jeder (Fach)Arzt an einer Community teilnehmen muss, ist hier die Verpflichtung abgeändert.
|-
|SubmissionSet
|intendedRecipient
| colspan="2" |R2
| colspan="2" |Sollte der Patient auskunft darüber geben für wen der Export gemacht wird (Patient, anderer Arzt) soll dies in diesem Element vermerkt werden
|-
|SubmissionSet
|patientId
| colspan="2" |R2
| colspan="2" |
|-
|SubmissionSet
|sourceId
| colspan="2" |R
| colspan="2" |
|-
|SubmissionSet
|submissionTime
| colspan="2" |R
| colspan="2" |
|-
|SubmissionSet
|title
| colspan="2" |O
| colspan="2" |
|-
|SubmissionSet
|uniqueId
| colspan="2" |R
| colspan="2" |
|-
| colspan="6" |
|-
|DocumentEntry
|author
|R2
|R2
| rowspan="26" |siehe ELGA Metadaten
|
|-
|DocumentEntry
|classCode
|R2
|R2
|
|-
|DocumentEntry
|confidentialityCode
|R
|R2
|
|-
|DocumentEntry
|creationTime
|R
|R2
|
|-
|DocumentEntry
|entryUUID
|R
|R
|
|-
|DocumentEntry
|eventCodeList
|O
|O
|
|-
|DocumentEntry
|formatCdoe
|R2
|R2
|
|-
|DocumentEntry
|hash
|R
|R
|
|-
|DocumentEntry
|healthcareFacilityTypeCode
|R2
|R2
|
|-
|DocumentEntry
|homeCommunityId
|O
|O
|
|-
|DocumentEntry
|languageCode
|R2
|R2
|
|-
|DocumentEntry
|legalAutheniticator
|R2
|O
|
|-
|DocumentEntry
|mimeType
|R
|R
|DICOM "application/dicom", für JSON "application/json", für iCal "text/calendar" ...
|-
|DocumentEntry
|objectType
|R
|R
|Unterscheidung zwischen "Stable Documents" und "On Demand Documents". Das "Datenbankexport"-CDA wäre als ODD zu führen, andere CDA-Report (eBefunde) wären als SDD zu führen
|-
|DocumentEntry
|patientId
|R2
|R2
|
|-
|DocumentEntry
|practiceSettingCode
|R2
|R2
|
|-
|DocumentEntry
|referenceIdList
|O
|O
|
|-
|DocumentEntry
|serviceStartTime
|R2
|R2
|
|-
|DocumentEntry
|serviceStopTime
|R2
|R2
|
|-
|DocumentEntry
|size
|R
|R
|
|-
|DocumentEntry
|sourcePatientId
|R2
|R2
|
|-
|DocumentEntry
|sourcePatientInfo
|R2
|R2
|
|-
|DocumentEntry
|title
|O
|O
|
|-
|DocumentEntry
|typeCode
|R2
|R2
|
|-
|DocumentEntry
|uniqueId
|R
|R
|
|-
|DocumentEntry
|URI
|R
|R
|
|}
TODO - Formatcode bei ELGA beantragen
