Zum Inhalt

Dokumententransaktionen (XDS)

Alle dokumentenbasierten Transaktionen müssen im SOAP Security Header die e-Impfpass Kontext-Assertion mitführen. Die ZGF leitet alle Transaktionen an der Fachlogik der zentralen e-Impfpass Anwendung weiter. Sollte die e-Impfpass ZGF nicht erreichbar sein, wird die Fehlermeldung "XDSUnavailableCommunity" XDS Registry Error retourniert. In den nachfolgenden Kapiteln wird die Einschränkung auf den Dokumentenklassen sowie die Schnittstellen aus Client Sicht Richtung Berechtigungssystem beschrieben.

Es ist zu beachten, dass neben den darin beschriebenen Suchparametern (siehe im Detail Tabelle PHARM-1 FindMedicationAdministrations Suchparameter, Tabelle PHARM-1 FindMedicationList Suchparameter und Tabelle PHARM-1 XCF Suchparameter) weitere Parameter an die Fachlogik weitergegeben werden können. Diese werden vom Berechtigungssystem jedoch nicht überprüft, daher werden diese im Pflichtenheft nicht erwähnt.

CDA und Dokumentmetadaten

Die CDA Definitionen und Metadaten sind dem ELGA Leitfaden zu entnehmen:

https://www.elga.gv.at/technischer-hintergrund/technische-elga-leitfaeden/index.html

Bei der Kommunikation mit der Anwendung e-Impfpass ist nur folgende Dokumentenklasse (ClassCode) erlaubt:

  • 11369-6 Immunisierungsstatus

Alle anderen werden von der antwortenden dezentralen Zugriffsteuerungsfassade aussortiert.

Die Unterscheidung der Dokumente erfolgt analog zur e-Medikation über folgende Dokumententypen (TypeCode):

  • 82593-5 Kompletter Immunisierungsstatus
  • 87273-9 Update Immunisierungsstatus

Registrieren von Immunisierungseinträgen

Immunisierungseinträge werden von einem GDA mittels ITI-41 Transaktion entsprechend dem IHE ITI CMA Akteur und einem CDA Dokument "Update Immunisierungsstatus" von einem GDA an die initiierende ZGF gesendet. Ein ELGA Teilnehmer kann keine Immunisierungseinträge registrieren.

Registrieren von Immunisierungseinträgen
Abbildung: Registrieren von Immunisierungseinträgen

Transaktionsworkflow:

  1. Ein Benutzer führt eine ITI-41 Abfrage mit e-Impfpass Kontext-Assertion durch.
  2. Die initiierende ZGF beantragt vom ETS eine e-Impfpass Treatment-Assertion.
  3. Mit der e-Impfpass Treatment-Assertion wird nachfolgend eine ITI-80 (XCDR) Cross-Community Document Reliable Interchange Transaktion an die e-Impfpass ZGF gesendet.
  4. Die ITI-80 XCDR Transaktion wird von der e-Impfpass ZGF als ITI-41 an die Fachlogik der zentralen e-Impfpass Anwendung weitergeleitet.
  5. Die Fachlogik der zentralen e-Impfpass Anwendung retourniert dem GDA im positiv Fall eine Bestätigung der durchgeführten Transaktion.

Weiterführende Überprüfungen von Transaktionsdaten:

Vom BeS werden neben SAML Validierungen und Durchsetzen von XACML Policies zusätzlich folgende Überprüfungen durchgeführt:

  • Bei ITI-41 Transaktionen (Registrieren und Ersetzen) wird vom BeS der XDSDocumentEntry.classCode auf "11369-6" geprüft - bei nicht Übereinstimmung wird vom BeS ein "XDSRepositoryMetadataError" zurückgeliefert
  • Beim Registrieren von Immunisierungseinträgen muss die XSPA Organization ID der e-Impfpass Kontext-Assertion mit der AuthorInstitution der Übertragungsdaten (SubmissionSet) und mit der der Dokumentmetadaten übereinstimmen – bei nicht Übereinstimmung der XSPA Organization ID der e-Impfpass Kontext-Assertion mit der AuthorInstitution der Übertragungsdaten wird vom BeS eine "DocumentStatusUpdateDenied" (ITI-57) bzw. eine "DocumentSubmitDenied" SoapFault zurückgegeben. Bei Transaktionen, die von der Korrekturrolle ("717") initiiert werden, werden keine AuthorInstitution Prüfungen durchgeführt

Stornieren und Ersetzen von Immunisierungseinträgen

Immunisierungseinträge können von einem GDA mittels XDS ITI-41 RPLC oder ITI-57 Update Transaktion ersetzt bzw. storniert werden. Ein ELGA Teilnehmer kann keine Immunisierungseinträge aktualisieren.

Mit Ausnahme des Korrekturberechtigten, Rolle "717", wird von der ZGF überprüft, ob die Organisations-ID (AuthorInstitution) der Übertragungsdaten und des neu eingebrachten Dokuments und die, des bereits vorhandenen Dokuments, übereinstimmen. Zusätzlich muss die XSPA-Organisation-ID der SAML-Assertion mit der Organisations-ID der AuthorInstitution des neu eingebrachten Dokuments ident sein. Besteht keine Übereinstimmung, wird vom BeS eine "DocumentStatusUpdateDenied" (ITI-57) bzw. eine "DocumentSubmitDenied" SoapFault zurückgegeben.

Stornieren und Ersetzen von Immunisierungseinträgen
Abbildung: Stornieren und Ersetzen von Immunisierungseinträgen

Transaktionsworkflow:

  1. Ein Benutzer führt eine ITI-41/ITI-57 Abfrage mit e-Impfpass Kontext-Assertion durch.
  2. Die initiierende ZGF beantragt vom ETS eine e-Impfpass Treatment-Assertion.
  3. Mit der e-Impfpass Treatment-Assertion wird nachfolgend eine ITI-80 (XCDR) Cross-Community Document Reliable Interchange bzw. eine Cross-Community Metadata Update (XCMU) Transaktion an die e-Impfpass ZGF gesendet. Näheres zu der XCMU Transaktion kann aus der Ergänzung zur IHE IT Infrastructure Technical Framework entnommen werden.
  4. Es wird von der e-Impfpass ZGF, um die Metadaten des zu ersetzenden Dokumentes zu bekommen, eine ITI-18 getDocuments Abfrage an die Fachlogik der zentralen e-Impfpass Anwendung gestellt.
  5. Die Fachlogik der zentralen e-Impfpass Anwendung gibt die Metadaten an die e-Impfpass ZGF zurück.
  6. Die ITI-41/ITI-57 Transaktion wird von der e-Impfpass ZGF an die Fachlogik der zentralen e-Impfpass Anwendung weitergeleitet.
  7. Die Fachlogik retourniert dem GDA im positiv Fall eine Bestätigung der durchgeführten Transaktion.

Zu adressierende Herausforderungen:

Um eine Stornierung durchzuführen, wird eine UUID vorausgesetzt. Um eine UUID zu erhalten, muss eine zeitnahe Suchanfrage (innerhalb von 30 Minuten) vom Client (GDA) durchgeführt werden.

GDA-Abfrage aller selbst eingebrachten Immunisierungs-Metadaten zu einem Patienten

Mit der IHE PHARM-1 Transaktion und der FindMedicationAdministrations "Option" (specialized query) aus dem CMPD Profil können GDA selbst eingebrachte Metadaten der Immunisierungseinträge zu einem Patienten abgefragt werden. Der Korrekturberechtigte kann diese Abfrage auch durchführen, er bekommt jedoch alle eingebrachten Immunisierungseinträge zu einem Patienten. Bei der Abfrage werden nur Metadaten für CDA des DocumentTypes "87273-9" (Update Immunisierungsstatus) zurückgeliefert. Das CDA Dokument mit den Immunisierungsdaten kann nachfolgend (innerhalb von vorkonfigurierten 30 Minuten) mit einer ITI-43 Retrieve Document Set Transaktion abgerufen werden.

Die Suchanfrage an die initiierende AGW/ZGF muss im SOAP Security Header eine e-Impfpass Kontext-Assertion mitführen, in der PHARM-1 Anfrage (SOAP Body) muss ein dem Z-PI bekannter Identifikator (bPK-GH, SVNR oder eigene LPID) enthalten sein und die OID des anfragenden GDAs (e-Impfpass Kontext-Assertion - XSPA Subject organization-id) muss im AuthorInstitution Slot der Anfrage enthalten sein.

Bei einem Zugriff eines Korrekturberechtigten wird die Prüfung der $XDSDocumentEntryAuthorInstitution ausgesetzt.

Die Abfrage von selbst eingebrachten Immunisierungs-Metadaten steht dem ELGA Teilnehmer am EBP nicht zur Verfügung.

Abfrage aller selbst eingebrachten Immunisierungs-Metadaten zu einem Patienten
Abbildung: Abfrage aller selbst eingebrachten Immunisierungs-Metadaten zu einem Patienten

Transaktionsworkflow:

  1. Ein Benutzer führt eine PHARM-1 FindMedicationAdministrations Abfrage mit e-Impfpass Kontext-Assertion durch.
  2. Die initiierende ZGF fordert eine e-Impfpass Treatment Assertion an.
  3. Die PHARM-1 Anfrage wird von der initiierende ZGF als ITI-38 XCA Transaktion an die e-Impfpass ZGF weitergeleitet.
  4. Die e-Impfpass ZGF leitet die Anfrage als PHARM-1 FindMedicationAdministrations an die Fachlogik der zentralen e-Impfpass Anwendung weiter.
  5. Die Antwort der Fachlogik der zentralen e-Impfpass Anwendung wird die Transaktionskette zurückgeben.

PHARM-1 FindMedicationAdministrations Suchparameter:

Element Beschreibung
Stored Query ID für FindMedicationAdministrations Als Stored Query ID in der PHARM-1 Anfrage muss der Wert "urn:uuid:fdbe8fb8-7b5c-4470-9383- 8abc7135f462" verwendet werden
Query Parameter $XDSDocumentEntryPatientId Muss einen, dem Z-PI bekannten, Identifikator enthalten (bPK-GH, VSNR oder eigene LPID)
Query Parameter $XDSDocumentEntryAuthorInstitution Muss die exakte OID des aktuell Abfragenden aus der e-Impfpass Kontext-Assertion - XSPA Subject organization-id enthalten
Document Entry Type $XDSDocumentEntryType Darf nicht befüllt werden oder muss den Wert für Stable Document Entry Type enthalten "urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"

Tabelle: PHARM-1 FindMedicationAdministrations Suchparameter

Weiterführende Überprüfungen von Transaktionsdaten:

Vom BeS werden neben SAML Validierungen und Durchsetzen von XACML Policies zusätzlich folgende Überprüfungen durchgeführt:

  • Bei Angabe einer nicht gültigen Stored Query ID wird der BeS Fehler "spirit:xds.004.3.00020" zurückgeliefert
  • Wird keine "$XDSDocumentEntryPatientId" mitgeführt, wird der IHE Fehler "XDSStoredQueryMissingParam" zurückgeliefert
  • Wird ein falscher "$XDSDocumentEntryType" angegeben, wird der IHE Fehler "XDSStoredQueryMissingParam" zurückgeliefert
  • Wird kein "$XDSDocumentEntryAuthorInstitution" angegeben, wird der BeS Fehler "spirit:xds.004.3.00020"zurückgeliefert (Ausnahme: für Korrekturberechtigte , Rolle "717", ist diese Überprüfung ausgesetzt)
  • Wird ein Wert in "$XDSDocumentEntryAuthorInstitution" angegeben der nicht der nicht der XSPA Organisation ID entspricht, wird der IHE Fehler "DocumentQueryDenied" zurückgeliefert (Ausnahme: für Korrekturberechtigte, Rolle "717", ist diese Überprüfung ausgesetzt)

Abfrage der Metadaten "Kompletter Immunisierungsstatus" zu einem Patienten

Mit der IHE PHARM-1 Transaktion und der FindMedicationList "Option" (specialized query) aus dem CMPD Profil kann der Immunitätsstatus zu einem Patienten abgefragt werden. Dieser Immunitätsstatus wird von der Fachlogik der e-Impfpass Anwendung mittels IHE On-Demand Documents (ODD) realisiert. Dabei werden von der Fachlogik die gespeicherten Immunisierungseinträge und berechneten Impfempfehlungen verwendet, um daraus ein On-Demand CDA Dokument "Kompletter Immunisierungsstatus" vom TypeCode "82593-5" zu erstellen, welches in der PHARM-1 FindMedicationList zurückgeliefert wird.

Bei der Abfrage werden nur Metadaten zurückgeliefert, die Immunisierungsdaten selbst können nachfolgend (innerhalb von vorkonfigurierten 30 Minuten) mittels einer ITI-43 Retrieve Document Set Transaktion abgerufen werden.

Auch wenn die PHARM-1 Transaktion auf der ITI-18 Stored Query Transaktion aufbaut und sich auch die Definition des On-Demand Document Entry von einem Stable Document Entry nur geringfügig unterscheidet, bestehen im Detail sehr wohl Unterschiede die unter anderem in den IHE Dokumenten IHE_ITI_TF_Vol1.pdf, IHE_ITI_TF_Vol3.pdf und im IHE_ITI_TF_Vol2a.pdf bzw. dem ELGA e-Impfpass Implementierungsleitfaden nachzulesen sind. Diese Abfrage steht auch dem ELGA Teilnehmer mittels EBP zur Verfügung, um seinen Immunisierungsstatus abzurufen.

Abfrage der Immunitätsstatus-Metadaten zu einem Patienten
Abbildung: Abfrage der Immunitätsstatus-Metadaten zu einem Patienten

Transaktionsworkflow:

  1. Ein Benutzer führt eine PHARM-1 FindMedicationList Abfrage mit e-Impfpass Kontext-Assertion durch.
  2. Die initiierende ZGF fordert eine e-Impfpass Treatment Assertion an.
  3. Die PHARM-1 Anfrage wird von der initiierenden ZGF als ITI-38 XCA Transaktion an die e-Impfpass ZGF weitergeleitet.
  4. Die e-Impfpass ZGF leitet die Anfrage als PHARM-1 FindMedicationList an die Fachlogik der zentralen e-Impfpass Anwendung weiter.
  5. Die Antwort der Fachlogik der zentralen e-Impfpass Anwendung wird die Transaktionskette zurückgeben.

PHARM-1 FindMedicationList Suchparameter:

Element Beschreibung
Stored Query ID für FindMedicationList Als Stored Query ID in der PHARM-1 Anfrage muss der Wert "urn:uuid:80ebbd83-53c1-4453-9860- 349585962af6" verwendet werden
Query Parameter $XDSDocumentEntryPatientId Muss einen, dem Z-PI bekannten, Identifikator enthalten (bPK-GH, VSNR oder eigene LPID)
Document Entry Type $XDSDocumentEntryType Darf nicht befüllt werden oder muss den Wert für On-Demand Document Entry Type enthalten "urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248"

Tabelle: PHARM-1 FindMedicationList Suchparameter

Weiterführende Überprüfungen von Transaktionsdaten:

Vom BeS werden neben SAML Validierungen und Durchsetzen von XACML Policies zusätzlich folgende Überprüfungen durchgeführt:

  • Bei Angabe einer nicht gültigen Stored Query ID wird der BeS Fehler "spirit:xds.004.3.00020" zurückgeliefert
  • Wird keine "$XDSDocumentEntryPatientId" mitgeführt, wird der IHE Fehler "XDSStoredQueryMissingParam" zurückgeliefert
  • Wird ein falscher "$XDSDocumentEntryType" angegeben, wird der IHE Fehler "XDSStoredQueryMissingParam" zurückgeliefert

Als Antwort werden Metadaten für ein einzelnes CDA Dokument zurückgeliefert.

Beispiele und weiterführende Information sind im IHE_Pharmacy_Suppl_CMPD.pdf und in den ELGA-Leitfäden zu finden.

Abrufen der CDA Dokumente

Alle CDA Dokumente zu den zurückgelieferten Metadaten (FindMedicationAdministrations, FindMedicationList) können mittels einer ITI-43 Retrieve Document Set Transaktion nach ELGA Vorgaben abgerufen werden. Es muss eine e-Impfpass Kontext-Assertion, anstelle einer HCP-Assertion im SOAP Security Header mitgeführt werden.

Um ein CDA Dokument abzurufen, muss eine zeitnahe (innerhalb von 30 Minuten) Suchanfrage (PHARM-1) vom Client durchgeführt werden.

Abrufen von e-Impfpass CDA und/oder ODD CDA Dokumenten
Abbildung: Abrufen von e-Impfpass CDA und/oder ODD CDA Dokumenten

Transaktionsworkflow:

  1. Ein Benutzer führt eine ITI-43 Abfrage mit e-Impfpass Kontext-Assertion durch.
  2. Die initiierende ZGF fordert eine e-Impfpass Treatment Assertion an.
  3. Die ITI-43 Anfrage wird von der initiierende ZGF als ITI-39 XCA Transaktion an die e-Impfpass ZGF weitergeleitet.
  4. Die e-Impfpass ZGF leitet die Anfrage als ITI-43 an die Fachlogik der zentralen e-Impfpass Anwendung weiter.
  5. Die Antwort der Fachlogik wird der zentralen e-Impfpass Anwendung die Transaktionskette zurückgeben.

XCF - Query Metadaten und Retrieve Immunitätsstatus CDA (in einer Transaktion)

Das IHE Profil Cross Community Fetch dient dazu die XDS ITI-18 bzw. PHARM-1/ FindMedicationList Query Anfrage nach Metadaten und das ITI-43 Abrufen des Dokuments (e-Impfpass ODD CDA "Kompletter Immunisierungsstatus") in einer einzigen XCF ITI-63 Cross Gateway Fetch Transaktion durchzuführen.

IHE_ITI_Suppl_XCF: "The Cross-Community Fetch (XCF) Profile defines a single transaction for accessing medical data between gateways, that facilitate multiple dimensions of communication (trust, semantics, encoding, legislation, authority, etc.). The profile is highly inspired by the Cross Gateway Query/Cross Gateway Retrieve transactions and integrates these originally distinct transactions"

XCF - Query Metadaten und Retrieve Immunitätsstatus (in einer Transaktion)
Abbildung: XCF - Query Metadaten und Retrieve Immunitätsstatus (in einer Transaktion)

Transaktionsworkflow:

  1. Ein GDA, ELGA Teilnehmer bzw. dessen Vertreter startet eine ITI-63 Cross-Community Fetch (XCF) Abfrage an die initiierende ZGF seines ELGA Bereiches.
  2. Die initiierende ZGF fragt beim ETS um eine e-Impfpass Treatment-Assertion an.
  3. Diese Assertion wird nachfolgend in die ITI-63 Anfrage, an die e-Impfpass ZGF eingebettet. Die e-Impfpass ZGF konvertiert die empfangene ITI-63 Anfrage in zwei separate Transaktionen Richtung Fachlogik der zentralen e-Impfpass Anwendung.
  4. Es wird eine PHARM-1 FindMedicationList Query Anfrage an die Fachlogik der zentralen e-Impfpass Anwendung gesendet, um die Metadaten des kompletten Immunisierungsstatus zu erhalten.
  5. Nachfolgend wird mittels ITI-43 das OnDemand CDA Dokument abgefragt.
  6. Die e-Impfpass ZGF transformiert die Metadaten der PHARM-1 Antwort zusammen mit dem CDA Dokument der ITI-43 Antwort in eine XCF Antwort.
  7. Diese XCF Antwort wird über die Transaktionskette an den Client zurückgegeben.

Vorteile der XCF Transaktion (ITI-63) gegenüber der PHARM-1 und ITI-43 Kombination:

  • Die gesamte Berechtigungsprüfung wird nur einmal durchgeführt und nicht zweimal (XCF statt PHARM-1 und ITI-43)
  • Die gesamte Semantik der Query und Retrieve Transaktion wird in eine Transaktion gebündelt und nicht lose über mehrere Transaktionen verteilt
  • Am Client entsteht nur eine Transaktion für ein Dokument
  • Die ZGF muss keine Metadaten wie bei einer PHARM-1 Transaktion für spätere Berechtigungsprüfungen bei einer ITI-43 vorhalten

Um Kompatibilität mit der FindMedicationList Anfrage zu gewährleisten, haben alle QueryArgumente (alle Slot Elemente innerhalb des AdhocQuery Elements) auch in der XCF ITI-63 Cross Gateway Fetch Anfrage Gültigkeit.

Im Kontext e-Impfpass wird vom Client (GDA) direkt die ITI-63 Anfrage an die initiierende ZGF gesendet. Der Client bekommt somit auch die Metadaten und den e-Impfpass ODD CDA "Kompletter Immunisierungsstatus" in einer Antwort zurückgeliefert.

PHARM-1 XCF Suchparameter:

Element Beschreibung
Stored Query ID für XCF Als Stored Query ID in der XCF Anfrage muss der Wert "urn:uuid:f2072993-9478-41df-a603-8f016706efe8" verwendet werden
‘home’ attribute in der Suchanfrage
<AdhocQuery id="..." home="urn:oid:1.2.3">		 Muss die Home-Community der initiierenden ZGF beinhalten (kann der HCP- bzw. der e-Impfpass Kontext-Assertion entnommen werden)
‚returnType’ ResponseOption Attribute Muss den Wert "LeafClassWithRepositoryItem" enthalten
Query Parameter $XDSDocumentEntryPatientId Muss einen, dem Z-PI bekannten, Identifikator enthalten bPK-GH, VSNR oder eigene LPID
Document Entry Type $XDSDocumentEntryType Darf nicht befüllt werden oder muss den Wert für On-Demand Document Entry Type enthalten "urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248"
$XDSDocumentEntryClassCode Mit dem Wert: 11369-6
$XDSDocumentEntryTypeCode Mit dem Wert: 82593-5

Tabelle: PHARM-1 XCF Suchparameter

Weiterführende Überprüfungen von Transaktionsdaten:

Vom BeS werden neben SAML Validierungen und Durchsetzen von XACML Policies zusätzlich folgende Überprüfungen durchgeführt:

  • Bei Angabe einer nicht gültigen Stored Query ID wird der BeS Fehler "spirit:xds.004.3.00020" mit der Meldung "XDS request failed" zurückgeliefert
  • Wird keine "$XDSDocumentEntryPatientId" mitgeführt, wird der IHE Fehler "XDSStoredQueryMissingParam" zurückgeliefert
  • Wird ein falscher "$XDSDocumentEntryType" angegeben, wird der IHE Fehler "XDSStoredQueryMissingParam" zurückgeliefert
  • Wird ein falscher "$XDSDocumentEntryClassCode" angegeben, wird der IHE Fehler "XDSStoredQueryMissingParam" zurückgeliefert
  • Wird ein falscher "$XDSDocumentEntryTypeCode" angegeben, wird der IHE Fehler "XDSStoredQueryMissingParam" zurückgeliefert

Auszug eines Nachrichtenbeispieles einer XCF Suchanfrage:

Beispiel e-Impfpass XCF-Request.xml

Informatives Nachrichtenbeispiel einer XCF Antwort:
Das ‚Document’ Response Element mit dem Namespace ‚urn:ihe:iti:xds-b:2007’ der ITI-43 Transaktion wird in der XCF Transaktion wiederverwendet, die Metadaten sind wie in einer ITI-18 Antwort im ExtrinsicObject enthalten.

Beispiel e-Impfpass XCF-Response.xml

Weiterführende Details bezüglich XCF können dem IHE_ITI_Suppl_XCF.pdf entnommen werden.