3.920
Bearbeitungen
Änderungen
→Anwendungsfälle
=Anwendungsfälle=
Folgende Kapitel stellen Auszüge bzw. eine Zusammenfassung der Inhalte der ELGA Gesamtarchitektur , des Leitfadends XDS Metadaten und Usability Styleguides zum Thema e-Befunde dar. Detailinformationen sind im in den entsprechenden Dokument Dokumenten nachzulesen (verfügbar unter auf der Homepage der [[httpsHttps://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/|Gesamtarchitektur der elektronischen Gesundheitsakte ELGAGmbH]]) nachzulesen.
==Voraussetzungen für den Zugriff auf ELGA Dokumente==
Der ELGA GDA ist in ELGA angemeldet , berechtigt und berechtigt (besitzt eine gültige Kontaktbestätigung), Patient ist ELGA-Teilnehmer und hat keinen generellen, partiellen oder situativen Widerspruch hinsichtlich ELGA eingelegtfür den Patienten.
==Einbringen von CDA-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 die, seitens des ELGA-GDA bereitzustellende, XDS Document Repository Komponente. Anschließend übernimmt die XDS Repository Komponente 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 nach der medizinischen Freigabe bzw. Vidierung vollautomatisch erfolgen.
===Vorgaben zu Dokument-Metadaten (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.
===Mehrsprachigkeit und grenzüberschreitender Austausch===
==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, auf die Dokumentenliste und auf Einzeldokumente über standardisierte Schnittstellen zugreifen (suchen, filtern, sortieren ist möglich).Grunsätzlich 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 findet man ist in submissionTime in den XDS submissionSet Metadatenzu finden.
===Darstellung von CDA Inhalten mittels Referenzstylesheet===
cda2pdf
==Suche / Filtern von ELGA-Dokumenten==
Die Selektion von ELGA-Dokumenten erfolgt über eine Filterfunktion. Zu den Filterkriterien zählen Metadaten wie *classCode bzw. typeCode (Dokumentenklasse/-typ)
*authorPerson (Autor des Dokuments als freie Zeichenkette, hier ist keine GDA-OID angeführt)
*formatCode (Format des Dokumenteninhalts)
*availabilityStatus (Gültigkeit des Dokuments)
*serviceStartTime und serviceStopTime (Beginn und Ende der Gesundheitsleistung)
*creationTime (Zeitpunkt der Dokumentenerstellung)
*objectType
TODO: Liste prüfen/ergänzen
==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 Dokumentklasse ersetzt werden. Dementsprechend muss das Metadaten-Attribut XDSDocumentEntry.classCode von ersetztem und ersetzenden Dokument ident sein (der typeCode darf sich unterscheiden). Ein Dokument darf durch 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 in KIS 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, wie z.B. wenn ein Dokument für einen falschen Patienten angelegt wurde.
=Dataset des Allgemeinen Implementierungsleitfadens=
