Neben den im ELGA-Gesetz definierten Dokumentenklassen können zukünftige Dokumentenklassen mit ihrer Struktur und ihrem Format für ELGA per Verordnung festgelegt werden. Auch für diese Dokumentenklassen gilt zumindest die unterste Interoperabilitätsstufe „EIS Basic“. Wenn ein CDA Implementierungsleitfaden für die jeweilige Dokumentenklasse harmonisiert wurde, ist es möglich, Dokumente in den höheren Interoperabilitätsstufen „EIS Structured“, „EIS Enhanced“ und „EIS Full Support“ auszutauschen.
=Anwendungsfälle=
Folgende Kapitel stellen eine Zusammenfassung der Inhalte der ELGA Gesamtarchitektur<ref name="ELGA-Gesamtarchitektur" />, des Leitfadends XDS Metadaten und Usability Styleguides zum Thema e-Befunde dar. Detailinformationen sind in den entsprechenden Dokumenten nachzulesen (verfügbar auf der Homepage der [https://www.elga.gv.at/ ELGA GmbH]). Die wesentlichen Anwendungsfälle sind
*[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Schreiben_und_Einbringen_von_Dokumenten|Schreiben und Einbringen von Dokumenten]]
*[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Versionierung_von_Dokumenten|Versionierung von Dokumenten]]
*[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Stornierung_von_Dokumenten|Stornierung von Dokumenten]]
*[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Filtern_und_Suchen_von_Dokumenten|Filtern und Suchen von Dokumenten]]
*[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Lesen_von_Dokumenten|Lesen von Dokumenten]]
==Voraussetzungen für den Zugriff auf e-Befunde in ELGA==
Der ELGA GDA ist in ELGA angemeldet, berechtigt und besitzt eine gültige Kontaktbestätigung für den Patienten.
Der Patient ist ELGA-Teilnehmer und hat keinen generellen, partiellen oder situativen Widerspruch hinsichtlich ELGA eingelegt.
==Schreiben und Einbringen von Dokumenten==
Im Zuge der Veröffentlichung eines CDA-Dokuments in ELGA übermittelt das lokale System des ELGA-GDA als XDS Document Source ein Dokument an das, seitens des ELGA-GDA bereitzustellende, XDS Document Repository. Anschließend übernimmt das XDS Repository die Aufgabe der Übermittlung entsprechender Dokument-Metadaten an eine (ELGA) XDS Registry.
Das Dokumentdatum (clinicalDocument.effectiveTime) wird abhängig von der Dokumentenklasse gesetzt.
Die Registrierung von Dokumenten in ELGA muss je nach Trigger (u.a. abhängig von Dokumententyp, Informationssystem, Versandzeitpunkt) automatisch vom jeweiligen Informationssystem erfolgen.
===Mehrsprachigkeit und grenzüberschreitender Austausch===
Ein ELGA Dokument wird grundsätzlich in deutscher Sprache erstellt. Es ist möglich, den Inhalt zusätzlich in weiteren Sprachen im Dokument anzugeben. Dokumente mit durchgängig maschinenlesbaren Inhalten können prinzipiell auch automatisiert übersetzt werden. Bestimmte Dokumente (wie z.B. Patient Summary) sollen auch für den grenzüberschreitenden Austausch von Gesundheitsdaten eingesetzt werden können.
===Vorgaben zu Dokument-Metadaten (XDS-Metadaten)===
Die Metadaten für die Registrierung eines Dokuments in ELGA sind teilweise im Dokument vorhanden und teilweise explizit durch die Document Source anzugeben (siehe Leitfaden [http://www.elga.gv.at/cda XDS Metadaten]).
Informationen, welche CDA Elemente in die welche XDS-Metadaten übernommen werden müssen ("XDS-Mapping"), wurden an den entsprechenden Stellen der Templates eingefügt.
{| class="wikitable"
! XDS-Mapping
! Optio-
nalität
! CDA-Element
clinicalDocument.
! Beispiel
! Erklärung
|-
| uniqueId
| M
| .id
|
| Dokumenten-Id des CDA-Dokuments
Es MUSS eine gültige und innerhalb des ID-Pools eindeutige Dokumenten-ID angegeben werden.
|-
| classCode
| R
| .code
|
*@code="18842-5"
*@displayName="Discharge summary"
*@codeSystem="2.16.840.1.113883.6.1"
*@codeSystemName="LOINC"
| Dokumententyp oder Dokumentenklasse
|-
| typeCode
| R
| .code.translation
|
*@code="11490-0"
*@displayName="Physician Discharge summary"
*@codeSystem="2.16.840.1.113883.6.1"
| Dokumententyp in feiner Granularität
|-
| practiceSettingCode
| C
| .hl7at:practiceSettingCode
|
*@code="F019"
*@displayName="Innere Medizin"
*@codeSystem="1.2.40.0.34.5.12"
*@codeSystemName="ELGA_PracticeSetting"
| Die fachliche Zuordnung des Dokumentes
|-
| confidentialityCode
| F
| .confidentialityCode
|
*@code="N"
*@displayName="normal"
*@codeSystem="2.16.840.1.113883.5.25"
*@codeSystemName="HL7:Confidentiality"
| Vertraulichkeitscode des Dokuments aus ValueSet „ELGA_Confidentiality“
TODO: Fixen Wert in XDS setzen?
|-
| languageCode
| F
| .languageCode
|
*@code="de-AT"
| Sprachcode des Dokuments
|-
| referenceIdList
| R
| .setId
|
*@id root="1.2.40.0.34.99.111.1.1"
*@extension="BBBBBBBBBBBBBBB"
*@assigningAuthorityName="KH Eisenstadt"
| Eindeutige Id des Dokumentensets. Diese bleibt über alle Versionen der Dokumente gleich (initialer Wert bleibt erhalten).
Die setId SOLL unterschiedlich zur clinicalDocument.id sein.
Dieses Element wird ins XDS-Attribut referenceIdList ("urn:elga:iti:xds:2014:ownDocument_setId") gemappt.
|-
| rowspan="4"| sourcePatientId
| rowspan="4"| R [1..1]
| rowspan="4"| .recordTarget.patientRole.id
|
'''id[1] Identifikation des Patienten im lokalen System.''' Grundsätzlich sind die Vorgaben gemäß „Identifikations-Elemente“ zu befolgen. (1..1 M)
Das Element id[1] wird ins XDS-Attribut sourcePatientId gemappt.
| Hinweis: Die Reihenfolge der id-Elemente MUSS unbedingt eingehalten werden!
|-
|
'''id[2] Sozialversicherungsnummer des Patienten (1..1 R):'''
*@root: OID der Liste aller österreichischen Sozialversicherungen, fester Wert: 1.2.40.0.10.1.4.3.1 (1..1 M)
*@extension: Vollständige Sozialversicherungsnummer des Patienten (10 Stellen) (1..1 M)
*@assigningAuthorityName: Fester Wert: Österreichische Sozialversicherung (0..1 O)
Zugelassene nullFlavor:
*NI … Patient hat keine Sozialversicherungsnummer (z.B. Ausländer)
*UNK … Patient hat eine Sozialversicherungsnummer, diese ist jedoch unbekannt
|
|-
|
'''id[3] Bereichsspezifisches Personenkennzeichen, Bereichskennzeichen GH (Gesundheit) (0..1 O)'''
*@root: OID der österreichischen bPK, fester Wert: 1.2.40.0.10.2.1.1.149 (1..1 M)
*@extension: bPK-GH des Patienten: concat(Bereichskürzel, ":", bPK) (Base64,28 Zeichen)
*Anmerkung: Das bPK dient ausschließlich der Zuordnung der elektronischen Identität und darf daher nicht am Ausdruck erscheinen (1..1 M)
*@assigningAuthorityName: Fester Wert: Österreichische Stammzahlenregisterbehörde (0..1 O)
|
|-
|
'''id[4] Europäische Krankenversicherungskarte (0..1 O)'''
*@root: OID der EKVK, fester Wert: 1.2.40.0.34.4.21 (1..1 M)
*@extension: Datenfelder der EKVK nach folgender Bildungsvorschrift: concat(Feld 6,"^",Feld 7,"^",Feld 8,"^",Feld 9) wobei Feld 6 "Persönliche Kennummer" angegeben sein MUSS (1..1 M) . Die übrigen Datenfelder sind optional (0..1 O)
*In Feld 9 MUSS die Datumsangabe im Format YYYMMDD erfolgen.
|
|-
| Author
| M [1..*]
| .author
|
*AuthorInstitution (=representedOrganization)
*AuthorPerson (=assignedAuthor)
*AuthorRole (=functionCode)
*AuthorSpeciality (=assignedAuthor.code)
| Nur Author-Elemente mit einer Person sind für das XDS-Mapping zu übernehmen.
|-
| intendedRecipient
| M
| .intendedRecipient
|
Elemente in der Auswahl:
*hl7:id[not(@nullFlavor)]
*hl7:id[@nullFlavor='NI']
*hl7:id[@nullFlavor='UNK']
| Identifikation des beabsichtigten Empfängers (Person)
Empfohlene Information für einen Empfänger ist die ID aus dem GDA-Index.
Dieses Element kann ins XDS-Attribut intendedRecipient gemappt werden (derzeit von ELGA '''nicht''' unterstützt).
|-
| legalAuthenticator
| F
| .legalAuthenticator
|
*AuthorInstitution (=representedOrganization)
*AuthorPerson (=assignedAuthor)
*AuthorRole (=functionCode)
*AuthorSpeciality (=assignedAuthor.code)
| Hauptunterzeichner, Rechtlicher Unterzeichner
'''ACHTUNG:''' Nach DocumentEntry.legalAuthenticator kann jeweils nur das erste ELement (ClinicalDocument/LegalAuthenticator[1]) übernommen werden.
|-
| eventCodeList
| M [1..*]
| .serviceEvent/@classCode
|
*@code="300"
*@displayName="Hämatologie"
*@codeSystem="1.2.40.0.34.5.11"
*@codeSystemName="ELGA_LaborparameterErgaenzung"
| Hauptunterzeichner, Rechtlicher Unterzeichner
Code der Gesundheitsdienstleistung
|-
| serviceStartTime
| R [1..1]
| .documentationOf.serviceEvent
.effectiveTime.low
|
Zeitpunkt des '''ältesten''' effectiveTime aus:
*"Immunization Entry":
**templateId 1.2.40.0.34.6.0.11.3.1
**substanceAdministration.effectiveTime und
*"Impfrelevante Erkrankungen Problem Entry":
**templateId 1.2.40.0.34.6.0.11.3.9
**act.effectiveTime.low
| Beginn des ersten documentationOf/serviceEvent-Elements
|-
| serviceStopTime
| R [1..1]
| documentationOf.serviceEvent
.effectiveTime.high
|
Zeitpunkt des '''jüngsten''' effectiveTime aus:
*"Immunization Entry":
**templateId 1.2.40.0.34.6.0.11.3.1
**substanceAdministration.effectiveTime und
*"Impfrelevante Erkrankungen Problem Entry":
**templateId 1.2.40.0.34.6.0.11.3.9
**act.effectiveTime.high
| Ende des ersten documentationOf/serviceEvent-Elements
|-
| healthcareFacilityTypeCode
| M
| componentOf.encompassingEncounter.location.healthCareFacility.code
|
*@code="300"
*@displayName="Allgemeine Krankenanstalt"
*@codeSystem="1.2.40.0.34.5.2"
| Code zur Klassifizierung des GDA
|}
==Versionierung von Dokumenten==
Änderungen an einem Dokument, das bereits in ELGA registriert wurde, sollen über die Registrierung einer neuen Dokumentenversion in ELGA Eingang finden. Mittels ITI-41/42 Provide and Register DocumentSet wird eine neue Version des Dokumentes geschrieben und die Metadaten der Vorversion auf den Status „deprecated“ gesetzt. In den XDS-Metadaten und in den CDA-Metadaten der neuen Version werden Verweise auf das ersetzte Dokument eingetragen (Beziehungstyp „replace“ (RPLC)).
Es dürfen ausschließlich Dokumente derselben Dokumentenklasse ersetzt werden. Dementsprechend muss das Metadaten-Attribut XDSDocumentEntry.classCode von ersetztem und ersetzenden Dokument ident sein (der typeCode darf sich unterscheiden). Ein Dokument darf auch durch ein älteres Dokument ersetzt werden.
Folgeversionen zu Originaldokumenten dürfen aus Gründen der rechtlichen Autorenschaft ausschließlich von jenem GDA (Organisation) registriert werden, der auch das entsprechende Originaldokument in ELGA veröffentlicht hat.
Ein bestehendes Dokument, das auf Basis eines bestimmten Leitfadens erstellt wurde, KANN auch später mit einer höheren Leitfadenversion ersetzt werden. Die Metadaten müssen entsprechend angegeben werden (formatCode).
Eventuell der Dokumentenvorversion zugeordnete individuelle Zugriffsberechtigungen werden durch das ELGA Berechtigungssystem auch auf die Nachfolgeversionen angewendet.
Neue Versionen eines Dokuments im jeweiligen Informationssystem sollen automatisch für ELGA registriert werden. In der neuen Dokumentversion sollen die Änderungen im Text erkennbar gemacht werden. Zur Kennzeichnung der Änderungen stehen spezielle Funktionen für CDA zur Verfügung die vom Referenzstylesheet entsprechend angezeigt werden können (siehe Kapitel [[ILF:Allgemeiner Implementierungsleitfaden 2020#Verwendung von Revisionsmarken|Verwendung von Revisionsmarken]]).
==Stornierung von Dokumenten==
Falls eine Korrektur des Dokumentes nicht möglich ist, kann ein Dokument auch komplett storniert werden. Dazu wird der Status des Dokumentes via ITI-57 (Metadata Update availability Status) in der Registry auf “deprecated” gesetzt, aber keine neue Dokumentenversion registriert. Ein storniertes Dokument wird daher nicht in der Dokumentliste enthalten sein, sofern nicht spezifische Anfragen gestellt werden, um deprecated-Versionen zu bekommen.
Diese Aktion ist nur in bestimmten Ausnahmefällen zulässig, z.B. wenn ein Dokument für einen falschen Patienten angelegt wurde.
{{BeginYellowBox}}
Das '''Löschen von Dokumenten''' in ELGA erfolgt ausschließlich in folgenden Fällen:
*Löschen durch ELGA-Teilnehmer
*Opt-Out des ELGA-Teilnehmers
*Ablauf der gesetzlichen Aufbewahrungsfrist (GTelG2012).
{{EndYellowBox}}
==Filtern und Suchen von Dokumenten==
ELGA ermöglicht den Zugriff auf die vollständige Liste von registrierten e-Befunden eines Patienten (entsprechend der jeweiligen Berechtigungen). Um die relevanten e-Befunde selektieren zu können, kann die Dokumentenliste nach verschiedenen Kriterien ("XDS-Metadaten") gefiltert werden. Zu den Filterkriterien zählen in XDS Metadaten wie
*classCode (Dokumentenklasse)
*typeCode (Dokumententyp)
*title (Titel des Dokuments)
*creationTime (Datum des Dokuments)
*authorPerson (Autor des Dokuments)
*availabilityStatus (Gültigkeit des Dokuments)
*serviceStartTime und serviceStopTime (Beginn und Ende der Gesundheitsleistung)
*serviceEventList ("Stichwortliste")
*…
Ein Mapping der Metadaten im CDA Header zu den entsprechenden XDS-Metadaten ist in diesem Leitfaden bei den jeweiligen Elementen beschrieben. Eine vollständige Dokumentation findet sich im [[ILF:XDS_Metadaten|Leitfaden XDS-Metadaten]].<ref>http://www.elga.gv.at/cda</ref>
==Lesen von ELGA Dokumenten==
Die ELGA-Anwendung "e-Befunde" stellt für jeden ELGA-Teilnehmer über Dokumentenverweise den Zugriff auf dezentral gespeicherte Dokumente bereit. Der ELGA-Teilnehmer kann über das ELGA-Portal Dokumente ansehen, lokal abspeichern oder ausdrucken (als PDF z.B. mittels CDA2PDF, mit eingefügter persönlicher Kennung).
Der ELGA-GDA kann auf ELGA Dokumente direkt aus seiner Software-Umgebung, entsprechend seiner Rolle und Berechtigung, über standardisierte Schnittstellen zugreifen. Grundsätzlich lassen sich die gesamte Dokumentenliste, bestehend aus deren Dokumentmetadaten (Registry Stored Query [ITI-18]) oder einzelne Dokumente eines Patienten abrufen (Retrieve Document Set [ITI-43]) und in das lokale System übernehmen.
Das ELGA-Berechtigungssystem liefert in erster Linie immer nur jene CDA-Dokumente, die im Status „approved“ sind. Um Dokumente, die in den Status „deprecated“ gesetzt worden sind zu lesen, müssen spezifische Anfragen (z.B. zeige alle Versionen eines bestimmten Dokumentes) gestellt werden.
===Vorherige Version eines bestimmten ELGA Dokuments abrufen===
Gemäß dem XDS Document-Lifecycle sind neu veröffentlichte Dokument-Metadaten mit dem Status „approved“ zu versehen. Diese ersetzen die entsprechenden Vorversionen. Technisch wird dabei ein neues Dokument, das in Beziehung vom Typ „replace“ (RPLC) zur Vorversion steht, erstellt. Auch Ergänzungen zu einem bestehenden Dokument müssen direkt im betroffenen Dokument durchgeführt und anschließend als Folgeversion über die Dokumentenbeziehung „replace“ (RPLC) abgebildet werden.
Das Updatedatum eines Dokuments ist in submissionTime in den XDS submissionSet Metadaten zu finden.
===Darstellung von CDA Dokumenten mittels ELGA Referenzstylesheet und CDA2PDF===
Das "ELGA Referenz-Stylesheet" ermöglicht eine allgemeine, einheitliche und benutzerfreundliche Darstellung von medizinischen CDA-Dokumenten (HL7 CDA Release 2.0), die gemäß der Vorgaben der ELGA CDA Implementierungsleitfäden erstellt wurden. Dabei werden die XML-Dateien mit einer XSLT-Transformation in HTML umgewandelt. Informationen zur Hinterlegung eines Stylesheets im CDA-Dokument siehe Kapitel [[#Hinterlegung_eines_Stylesheets|Hinterlegung eines Stylesheets]].
Zur Darstellung der ELGA-Befunde steht das CDA-Visualization-Paket auf der ELGA-Website zur Verfügung. Dieses Paket enthält zwei unterschiedliche Tools zur Darstellung von CDA-Dokumenten: Ein Stylesheet zur Erzeugung einer HTML-Bildschirmansicht (Referenzstylesheet) und einen Generator zur Erzeugung eines druckfähigen PDF-Dokuments (CDA2PDF). Diese Tools sind speziell für die Anzeige von CDA-Dokumenten optimiert, die den Regeln des Allgemeinen CDA Implementierungsleitfadens entsprechen.
Bei den Referenzstylesheets sowie dem CDA2PDF Tool wird großer Wert auf die Benutzerfreundlichkeit gelegt. Zuletzt wurde unter Beteiligung von ELGA-Benutzern und einem Usability-Experten eine kompakte, platzsparende Darstellung geschaffen.
====Referenzstylesheet====
Das ELGA-Referenzstylesheet erzeugt aus CDA-XML Dokumenten eine HTML Datei, die in einem Webbrowser angezeigt werden kann.
Für bestimmte CDA Dokumente, die vollständig maschinenlesbar vorliegen (z.B. e-Medikation, e-Impfpass), können alternativ speziell auf diese Dokumentenklasse optimierte Stylesheets zur Anwendung kommen, die ebenfalls im Paket enthalten sind. Diese greifen dann auch auf die maschinenlesbaren Daten zu.
Für Details zur Anwendung des Referenzstylesheets, etwa zu den umfangreichen einstellbaren Optionen oder der Darstellung von lokal gespeicherten CDA-Dateien beachten Sie bitte die im CDA-Visualization-Paket mitgelieferte readme-Datei.
=====Versionierung=====
Sowohl das Referenzstylesheet für e-Befunde als auch das CDA2PDF Tool zieht ausschließlich den menschenlesbaren (Level 2) Teil des CDA-Dokuments für die Anzeige heran und ist damit in der Lage beliebige CDA Dokumente anzuzeigen.
Das Referenzstylesheet wird aus Gründen der Abwärtskompatibilität bis dato immer in der Version 1.0 zur Verfügung gestellt. Damit ist sichergestellt, dass alle e-Befunde weiterhin dargestellt werden können (die Stylesheet-Version ist im CDA-Dokument enthalten). Sollte es wider Erwarten größere Änderungen geben, die einen Versionswechsel nötig machen (breaking changes) wird die Stylesheet-Version geändert.
=====Verbindlichkeit und eigene Änderungen=====
Die Referenzstylesheets für e-Befunde und die e-Medikation werden von der ELGA GmbH bis auf Widerruf unentgeltlich und nicht-exklusiv sowie zeitlich und örtlich unbegrenzt, jedoch beschränkt auf Verwendungen für die Zwecke der "Clinical Document Architecture" (CDA) zur Verfügung gestellt. Veränderungen für die lokale Verwendung sind zulässig. Derartige Veränderungen (sogenannte bearbeitete Fassungen) dürfen Ihrerseits publiziert und Dritten zur Weiterverwendung und Bearbeitung zur Verfügung gestellt werden. Bei der Veröffentlichung von bearbeiteten Fassungen ist darauf hinzuweisen, dass diese auf Grundlage des von der ELGA GmbH publizierten "ELGA Referenzstylesheet" erstellt wurden. Die Anwendung sowie die allfällige Bearbeitung des "ELGA Referenzstylesheet" erfolgt in ausschließlicher Verantwortung der Anwender. Aus der Veröffentlichung, Verwendung und/oder Bearbeitung können keinerlei Rechtsansprüche gegen die ELGA GmbH erhoben oder abgeleitet werden.
====CDA2PDF====
Mit der CDA2PDF-Suite können ELGA-konforme CDA-Dokumente zu PDF-Dokumenten transformiert werden. Das WAR-File kann auf einem Web Application Server eingespielt und verwendet werden. Das CDA2PDFOffline Paket steht auch zur offline-Nutzung zur Verfügung. Im CDA-Visualization Paket finden Sie eine umfangreiche Dokumentation zur Nutzung der CDA2PDF-Suite.
Die ELGA GmbH stellt den ELGA CDA2PDF Konverter unentgeltlich zur Verfügung. Die ELGA GmbH übernimmt keine Haftung für die korrekte Funktion, etwaige Mängel, Schäden oder Folgefehler. Aus der Verwendung des vorliegenden Programmes kann keinerlei Rechtsanspruch gegen die ELGA GmbH erhoben und/oder abgeleitet werden.
{{BeginYellowBox}}
Informationen zur Anpassung des Stylesheets mittels Parametern sind unter [[ELGA_Referenz-Stylesheet|ELGA Referenz-Stylesheet]] zu finden.
Ein Downloadpaket zum Thema CDA-Darstellung (inkl. Referenzstylesheets, Changelog und CDA2PDF) ist unter [https://www.elga.gv.at/cda Technische ELGA-Leitfäden] abrufbar.
{{EndYellowBox}}
===Drucken von CDA Dokumenten===
Mit der CDA2PDF-Suite können ELGA-konforme CDA-Dokumente zu PDF-Dokumenten transformiert werden.
Diese inkl. Benutzer- und Entwickler-Dokumentation ist ebenfalls im Downloadpaket zum Thema CDA-Darstellung unter [https://www.elga.gv.at/cda|Technische ELGA-Leitfäden] abrufbar.
=Konformitätsprüfung=
