Schnittstellen zur Fachlogik eines AC¶
Da eine Vielzahl von IHE Transaktionen für die Anbindung einer AC Fachlogik zur Verfügung stehen, wird derzeit vom e-Impfpass und VO als Standard ausgegangen. Alternativ zu der PHARM-1 Transkation ist es natürlich auch möglich, die normale ITI-18 Abfrage zu verwenden. Ebenfalls kann eine ITI-47 PDQ Anfrage für eine Patientensuche verwendet werden.
Generell werden alle nach BeS Regeln validen ITI und PHARM-1 Transaktionen an die Fachlogik der AC Anwendung weitergeleitet. Die Fachlogik muss daher alle notwendigen ITI und PHARM-1 Transaktionen, die ein Fachkonzept vorsieht, IHE konform unterstützen. Daher ist es aus Sicht des ELGA BeS nicht relevant, ob die Fachlogik hinter den IHE Schnittstellen ein ebXML Datenmodel implementiert.
Für alle Transaktionen wird eine AC Community-Assertion auf der antwortenden ZGF erstellt und an die Fachlogik weitergeleitet.
Es dürfen ausschließlich TLS Transaktionen nach ELGA Vorgaben von der AC Fachlogik akzeptiert werden.
Wenn bei einer XCF – Cross Community Fetch [ITI-63] Transaktion die DocEvent@rspUsedQueryID dem Wert "urn:uuid:f2072993-9478-41df-a603-8f016706efe8" entspricht, dann wird die XCF Transaktion von der Responding ZGF an die Fachlogik weitergeleitet. Andernfalls, wird die XCF ITI-63 Cross Gateway Fetch Anfrage nicht direkt an die Fachlogik weitergeleitet, sondern auf eine IHE Query Transaktion (einstellbar in: acImport.xml /DocEvent/rspQueryAction & rspUsedQueryID) und ITI-43 Retrieve Document Set übersetzt. Im Kontext AC kann in BeS als Stored Query ID "jeder Wert" verwendet werden – auch wenn dieser nicht als IHE Stored Query existiert. Der gewählte Wert muss jedoch von der Fachlogik unterstützt werden.
Um etablierte Prüfungen bei XDS Transaktionen wie z.B. die Author Prüfung beim Ersetzen von Dokumenten zu ermöglichen, muss die ZGF aktiv eine getDocuments Abfrage an die Fachlogik absetzen, welche IHE konform die Metadaten mit Stored Query ID ‚urn:uuid:5c4f972b-d56b-40ac-a5fc-c8ca9b40b9d4’ zurückliefert.
Für neue Anwendungen müssen die spezifischen Ausprägungen der Schnittstellen im jeweiligen Fachkonzept beschrieben werden. In diesem Pflichtenheft wird lediglich das Superset der möglichen Schnittstellen zur Fachlogik beschrieben.
In folgender Abbildung werden beispielhaft alle Schnittstellen zur e-Impfpass Fachlogik dargestellt.
Zu unterstützende IHE Transaktionen der Fachlogik einer AC Anwendung¶
Die Fachlogik der AC Anwendung muss die folgenden IHE Transaktionen vollumfänglich unterstützen – ein AC kann abhängig von der Ausprägung des AC auch nur eine Submenge unterstützen:
- XDS ITI-41 Provide and Register Document Set
- Um Dokumente zu erstellen, muss die ITI-41 Provide and Register Document Set Transaktion unterstützt werden
- Um Dokumente zu ersetzten, muss auch die RPLC Association unterstützt werden
- XDS ITI-57 Update Document Set
- Um Dokumente als ungültig zu kennzeichnen, muss der Trigger Event Update DocumentEntry availabilityStatusUpdate (Storno) unterstützt werden
- XDS ITI-43 Retrieve Document Set
- Um Dokumente abzurufen, muss die ITI-43 Retrieve Document Set Transaktion unterstützt werden
- ITI-18 Stored Query
- Um Dokumente mittels UUID abzurufen, muss die ITI-18 Stored Query getDocuments Abfrage mit Stored Query ID ‚urn:uuid:5c4f972b-d56b-40ac-a5fc-c8ca9b40b9d4’ unterstützt werden.
- PHARM-1 Query Pharmacy Documents
- die zu unterstützenden Ausprägungen sind abhängig vom jeweiligen AC.
- PDQ ITI-47 Patient Demographic Query
- Um eine Patientenuche zu machen kann eine PDQ ITI-47 verwendet werden. Die PDQ wird von antwortenden ZGF mittels Community Assertion an die Fachlogik weitergeleitet.
- Hierbei handelt es sich um einen PDQ-Endpunkt, der je nach Anwendung, von der Fachlogik unterstützt werden muss und nicht um den Bereits vorhandenen PDQ-Endpunkt der AGW Richtung Z-PI.
- L-ARR ITI-20 Record Audit Event
- Zur Protokollierung muss die ITI-20 Record Audit Event (over TLS RFC 5425) laut ELGA Vorgaben unterstützt werden
Fehlermeldungen der Fachlogik der AC Anwendung¶
Die Fachlogik der AC Anwendung muss IHE konforme XDS Registry Errors zurückliefern. Es ist jedoch zulässig eigene Fehlermeldungen zu definieren. Die initiierende und antwortende ZGF leitet alle XDS Registry Error Meldungen, die von der Fachlogik zurückgeliefert wurden, an den Anfragenden weiter. Alle AC spezifischen Fehlermeldungen werden via XDS Registry Error bis zum Aufrufer weitergeleitet. Im Falle einer PDQ werden die Fehlermeldungen der Fachlogik ebenfalls unverändert an den Anfragenden zurückgeliefert.
AC Community-Assertion¶
Analog zu den ELGA und VO Transaktionen wird im Kontext AC eine spezifische AC Community-Assertion vom Berechtigungssystems an die AC Fachlogik weitergegeben. Die Transaktion wird um die ELGA e-Health Anwendung-ID im OID Codesystem 1.2.40.0.34.5.159 erweitert und in das Attribut "Purpose" eingefügt und präfixiert mit "E-HEALTH-CONTEXT^".
Die AC Community-Assertion muss von der Fachlogik laut ELGA Vorgaben validiert werden (z.B. Korrektheit der Signatur). Die Verfahren, eine AC Community-Assertion anzufordern, sind analog denen der ELGA Community-Assertion bis auf die Vorbedingung einer AC Kontext-Assertion. Darüber hinaus unterscheidet sich der Inhalt der einzelnen WS-Trust Transaktionen bzw. der SAML-Assertions in dem SAML Attribut "Purpose". In diesem SAML Attribut wird das "Purpose of Use" der AC Kontext-Assertion via FriendlyName="Purpose" mitgeführt.