Anwendungsfälle¶
Dokumentation im Aufbau
Die vorliegende technische Dokumentation befindet sich derzeit im Aufbau. Demzufolge können sich die Inhalte zum Thema eEKP-FHIR-Anbindung noch ändern, respektive weitere Inhalte hinzukommen.
Für die Realisierung der Anforderungen seitens eEKP-FHIR sind sowohl lesende als auch schreibende Zugriffe auf das eEKP-Zentralsystem erforderlich. Im folgenden werden die Anwendungsfälle aus technischer Sicht näher beschrieben.
Information
Die im Folgenden abgebildeten Darstellungen zeigen eine vereinfachte Client-Sicht. Sie beschränken sich auf jene Komponenten die als direkte Kommunikationspartner mit dem jeweiligen GDA-System agieren. Zusätzlich beschränken sich die in den Abbildungen dargestellten Sequenzflüsse auf die fachlichen Interaktionen mit den Upstream-Systemen, i.e. dem eEKP-Zentralsystem. Die notwendigen Voraussetzungen, um eine fachliche Transaktion durchzuführen, werden unter Erste Schritte zusammengefasst.
Lesender Zugriff auf das eEKP-Zentralsystem¶
Für den lesenden Zugriff auf das eEKP-Zentralsystem, werden in eEKP-FHIR Schnittstellen in Anlehnung an das IHE MHD Profil (vgl. Mobile access to Health Documents (MHD)) bereitgestellt. Konkret gestaltet sich der lesende Zugriff für ein GDA-System über die am AGW etablierten eEKP-FHIR Schnittstellen als zweistufige Abfrage auf Grundlage der IHE Transaktionen ITI-67 und ITI-68. Mittels ITI-67 kann ein GDA-Client eine Liste von Metadaten verfügbarer eEKPs vom eEKP-Zentralsystem abrufen. Diese vom eEKP-Zentralsystem bereitgestellten Metadaten erlaubt es einem GDA-Client eine Übersicht der vorhandenen eEKPs zu erhalten. Der lesende Zugriff auf das eEKP-Zentralsystem orientiert sich an den Festlegungen des IHE Mobile Access to Health Documents Profils (IHE MHD). Ein eEKP wird dabei als ein Dokument und damit als das Resultat einer Anfrage verstanden. Dabei gestaltet sich der lesende Zugriff wie folgt:
-
Mittels der IHE-Transaktion ITI-67
FindDocumentListswerden vorhandene eEKP-S bzw. eEKP-K angefragt. Das eEKP-Zentralsystem liefert die Metadaten aller im System verspeicherten eEKP-S und eEKP-K. Diese werden über die definierten Schnittstellen in Form von FHIRDocumentReferencesan das jeweilige Client-System ausgeliefert. -
In Folge muss am zugreifenden Client-System der zu ladende eEKP aus der Menge an verfügbaren Eltern-Kindpässen ausgewählt und mittels IHE ITI-68 abgerufen werden. Seitens des eEKP-Zentralsystems wird hierbei auf die Möglichkeit zurückgegriffen, den gesamten eEKP einer Person in ein PDF-Dokument, das in ein CDA-Dokument (CDA Level-1) eingebettet wird, zu serialisieren. Dieser serialisierte PDF wird in Folge als FHIR
Binary-Ressource an den Consumer übertragen und kann im jeweiligen Client-System zur Anzeige gebracht werden.

Lesender Zugriff auf ein Untersuchtungskapitel¶
Nebst der Möglichkeit über eEKP-FHIR einen eEKP in Form eines PDFs auszulesen, wir über eine weitere Schnittstelle die Möglichkeit angeboten, einzelne Untersuchungskapitel durch den Client als strukturierte FHIR QuestionnaireResponse Ressourcen abzurufen. Da es zu einem definierten Zeitpunkt grundsätzlich mehrere eEKPs zu einer Person geben kann, muss für das Lesen eines Untersuchungskapitels in Form einer QuestionnaireResponse der zugehörige EKP eindeutig identifiziert werden. Die dafür erforderliche Abfrage mittels ITI-67 Transaktion gestaltet sich analog zur Beschreibung des lesenden Zugriffs (siehe Lesender Zugriff auf das eEKP-Zentralsystem). Dabei sei darauf hingewiesen, dass aus den retournierten DocumentReference-Ressourcen nach Auswahl des zutreffenden eEKP nicht wie eine ITI-68 Transaktion durchgeführt wird, sondern der eEKP-Fachidentifikator extrahiert und für die Folgetransaktion, eine FHIR-Search-Interaktion auf der Ressource QuestionnaireResponse, verwendet wird. Mit dem ermittelten eEKP-Fachidentifikator besteht für den Client unter zusätzlicher Bekanntgabe eines Identifikators die Möglichkeit das betreffende Untersuchungskapitel als FHIR-Ressource über eEKP-FHIR zu lesen. Grundsätzlich sind nach Ermittlung des eEKP-Fachidentifikators zwei Szenarien denkbar:
- Der GDA-Client verfügt im lokalen System über einen zuvor im Zuge der Erstellung eines Untersuchungskapitels gespeicherten Identifikator.
- Der GDA-Client initiiert eine FHIR-Search-Interaktion unter Bekanntgabe des ermittelten eEKP-Fachidentifikators sowie eines Codes, der einem Untersuchungskapitel eindeutigt zugeordnet werden kann.

Unabhängig vom jeweiligen Szenario wird ein im eEKP-Zentralsystem vorhandenes Untersuchungskapitel als FHIR QuestionnaireResponse Ressource über die eEKP-FHIR-Schnittstelle an einen aufrufenden Client retourniert. Den Festlegungen der FHIR-Spezifikation folgend, wird das Ergebnis der Search-Interaktion in eine FHIR Bundle-Ressource eingebettet.
Schreibender Zugriff auf den eEKP¶
Für die Krankenanstalten stellt die eEKP-FHIR Anbindung eine zusätzliche Schnittstelle zur Verfügung, die es erlaubt einzelne Kapitel des eEKP im eEKP-Zentralsystem zu speichern. Die Festlegungen hinsichtlich Untersuchung, Kapitel sowie Struktur und Inhalt sind dem Datenerfassungskonzept zu entnehmen. Auf Ebene von eEKP-FHIR wird das Anlegen eines Kapitels mittels einer FHIR Create-Interaktion in Form einer QuestionnaireResponse Resource (https://hl7.org/fhir/questionnaireresponse.html) durchgeführt. Voraussetzung für das erfolgreiche Anlegen eines Untersuchungskapitels ist die Zuordnung zum jeweils gültigen eEKP. Da es zu einem definierten Zeitpunkt grundsätzlich mehrere eEKP-S zu einer Person geben kann, muss beim Erstellen einer QuestionnaireResponse der zugehörige EKP eindeutig identifiziert werden. Im eEKP-Zentralsystem erfolgt dies über einen Fachidentifikator, der als Teil der Metaddaten eines eEKP abgerufen werden kann. Dementsprechend, muss einer Anlage eines Kapitels eine Abfrage mittels lesendem Zugriff (ITI-67) und eine Auswahl des zugehörigen eEKP am jeweiligen GDA-Client erfolgen.

Richtigstellung eines Untersuchungskapitels¶
Für die Wahrnehmung des Rechts auf Richtigstellung wird in eEKP-FHIR eine weitere Schnittstelle angeboten. Die damit verbundene FHIR-Interaktion ermöglicht es einem berechtigten GDA-Client einzelne, von ihm erfasste Untersuchungskapitel richtigzustellen. Der grundsätzliche Ablauf, bzw. die einer Richtigstellung vorausgehenden Interaktionen gestalten sich analog zu Schreibender Zugriff auf den eEKP D.h. ein GDA-Client benötigt für die Richtigstellung eines Untersuchungskapitels einen eEKP-Fachidentifikator in Kombination mit einem Identifikator eines Untersuchungskapitels. Nachdem ein GDA nur berechtigt ist die von ihm erstellten Untersuchungskapitel richtigzustellen, ist das unter Lesender Zugriff auf ein Untersuchungskapitel beschriebene Szenario 2.) hinfällig, da der GDA als initialer Ersteller des Untersuchungskapitels den zugehörigen vom eEKP-Zentralsystem erzeugten Identifikator in seinem lokalen System (bspw. Geburtenmeldesystem) verspeichert hat. Die Sicherstellung, dass ein GDA nur jeweils die von ihm erstellten Untersuchungskapitel ändern kann, erfolgt durch das eEKP-Zentralsystem. Abweichend von der unter Punkt Lesender Zugriff auf das eEKP-Zentralsystem festgelegten Search-Interaktion, wird bei der Richtigstellung eine Update-Interaktion durchgeführt, die das betroffene Untersuchungskapitel unter Verwendung des eEKP-Fachidentifikator und sowie des Kapitel-Identifikators richtigstellt. Die von der Richtigstellung betroffenen Daten werden vom jeweiligen GDA-Client aus dem lokalen System übernommen und als FHIR-QuestionnaireResponse über eEKP-FHIR an das eEKP-Zentralsystem übermittelt.
