DSUB - Benachrichtigungsservice

Es wird ein neues bereichsübergreifendes DSUB (Document Metadata Subscription) -Benachrichtigungsservice bereitgestellt. DSUB ist als anwendungsneutrale Funktion umgesetzt. DSUB kann durch Konfiguration je Anwendung aktiviert/deaktiviert werden (on/off-Schalter). Damit wird gesteuert, ob für diese Anwendung Subskriptionen eingebracht werden dürfen. DSUB ist keine anwendungsübergreifende Funktion. Es besteht auch die Möglichkeit DSUB generell zu deaktivieren. Eine via ITI-52 Transaktion (Document Metadata Subscribe) eingebrachte Subskription kann sowohl vom GDA als auch vom ELGA-Teilnehmer nur mit einer gültigen Assertion für diese Anwendung eingebracht werden. Auch Benachrichtigungen werden nachfolgend nur im Kontext dieser Anwendung ausgelöst.

Der Ansatz verfolgt einen zentralen E-Health-Broker, der die Rolle des Document Metadata Notification Broker übernimmt. Ein GDA kann mittels ITI-52 Document Metadata Subscribe ein Abonnement bezüglich bestimmter Metadaten, die in ELGA zentral temporär verfügbar sind, beantragen. Das ETS erhält aufgrund der derzeitigen Architektur bei jedem in ELGA eingebrachten Dokument eine Anfrage für die Treatment-Assertion. Diese WS Trust Nachricht wird - wo notwendig - mit Metadaten auf die in ELGA abonniert werden kann, erweitert (referenceIDList, AuthorInstitution, ClassCode, etc.). Die Anfrage einer Treatment-Assertion wird vom ETS an den e-Health-Broker weitergereicht, welcher prüft, ob für das neu eingebrachte Dokument ein Abonnement vorliegt und benachrichtigt, wenn notwendig, den Document Metadata Notification Recipient. Der Notification Recipient ist außerhalb vom BeS zu sehen. Derzeit ist nicht vorgesehen, die IHE ITI-53 direkt an GDA- oder Bereichskomponenten auszuliefern, sondern die Benachrichtigungen mittels ExchangeServer/SMTP zu versenden.

Beim Filtern auf Subscriptions werden grundsätzlich nur folgende Argumente mittels DB Query gefiltert (appId, BPK, Elapse>now). Der Rest der Werte wird im Memory aussortiert (Provider, RefIdList, TypeCode, ClassCode).

Subscribe und Unsubscribe Events werden im Z-L-ARR entsprechend DSUB-Profil Dokument

geführt. Im A-ARR werden diese Events nicht protokolliert.

Mit dem gewählten Ansatz kann auch auf XDW Dokumente subscribed werden. Benachrichtigungen sind mittels der vorhandenen Metadaten wie classCode und ReferenceIDList ebenso möglich. Mittels ReferenceIDList kann z.B. ein Abonnement auf einen bestimmten Workflow gemacht werden.

Für DSUB stehen Service-Permissions zur Verfügung, die der jeweiligen Rolle zugeordnet werden müssen und die die Steuerung über die Kontaktprüfung übernehmen:

• urn:elga:bes:2019:permission:{{AppId}}:dsub:noContact
  • es wird keine KBS Prüfung durchgeführt.
• urn:elga:bes:2019:permission:{{AppId}}:dsub:contact
  • es wird eine KBS Prüfung auf Existenz eines Kontaktes und Gültigkeitsdauer (DSUB_KBS_VALID_TIME) durchgeführt.
  • Es werden keine Berechtigungen der Patientenpolicy geprüft.
  • Die KBS Prüfung wird nur bei der Subscribe Nachricht durchgeführt.

Wenn ein GDA / Patient keine Berechtigung für DSUB hat, wird die Nachricht mit einer AccessDenied SOAP Fault abgelehnt.

Subskription

Die ITI-52 Document Metadata Subscribe Nachricht wird von einem GDA oder einem Bürger über die AGW an den zentralen e-Health-Broker von BeS gesendet. Ein GDA kann mehrere Subskriptionen je ELGA-Teilnehmer und Anwendung einbringen. Weder ELGA-Teilnehmer noch GDA dürfen die gleiche Subskription mehrfach einbringen. Für eine Subskription gilt das Prinzip der Idempotenz. Sollte die gleiche Subskription hintereinander mehr als einmal eingebracht werden, erkennt das System dies aktiv. Nach Annahme der ersten Subskription werden die nachfolgenden mit Success beantwortet, ohne dabei einen zusätzlichen Subscription-Record zu eröffnen. Jede korrekt und vollständig eingebrachte Subskription ist für eine per Konfiguration zu definierende Zeitdauer gültig (DSUB_ELAPSE :default 6 Monate, falls keine "InitialTerminationTime" angegeben wurde). Nach Zeitablauf werden die Subskriptionen unwiderruflich storniert (bzw. gelöscht). Individuelle Policies werden bei der Einbringung einer Subskription nicht geprüft. Der GDA (mit der Permission 'urn:elga:bes:2019:permission:{{AppId}}:dsub:contact') benötigt zum Einbringen der Subskription einen Kontakt (kbsStatus:active), welcher nicht älter als DSUB_KBS_VALID_TIME ist. Hat der Benutzer eine 'urn:elga:bes:2019:permission:{{AppId}}:dsub:contact' Permission wird bei fehlendem Kontakt ein AccessDenied Fehler zurückgegeben.

Hat der Benutzer eine 'urn:elga:bes:2019:permission:{{AppId}}:dsub:noContact' Permission, wird keine Prüfung auf die Kontakte durchgeführt.

Ein Patient bzw. sein Vertreter kann nicht für einen anderen Patienten eine Subskription einbringen.

Mögliche Filter einer Document Metadata Subscribe Nachricht:

• LPID oder bPK-GH
  • Ist verpflichtend anzugeben
  • Es wird immer auf eine bPK-GH gewandelt
• GDA OID - Author Institution
  • Filtert auf ein Dokument, das ein GDA einbringt oder aktualisiert
  • Es wird immer nur auf auf die tatsächliche OID gefiltert
• ReferenceIDList
  • Ermöglicht einen Filter auf ein bestimmtes Dokument oder einen Workflow (setID) bzw. auf andere Wertebereiche, die in der ReferenceIDList geführt werden.
• Class Code
  • Filtert auf eine Dokumentklasse
• TypeCode
  • Filtert auf einen Dokumententyp

Die E-Mail-Adresse, die für die SMTP Benachrichtigung verwendet werden muss, wird in der ITI-52 Nachricht als ConsumerReference/Address anstelle des Endpunkts des Notification Recipients übergeben.

Mit dem optionalen Element InitialTerminationTime kann eine Gültigkeitsdauer für die eingebrachte Subskription angegeben werden.

• Ist dieses Element nicht vorhanden wird die default Gültigkeitsdauer (DSUB_ELAPSE) verwendet.

• Als Format kann eine absolute DateTime oder aber auch eine Dauer mittels ISO-8601 Duration Format verwendet werden.

• Die angegebene InitialTerminationTime wird bei der Idempotence Prüfung nicht herangezogen. Es wird demnach auch bei unterschiedlichen InitialTerminationTime die gleiche Subscription zurückgegeben.

Die ID der Subskription, die für eine Abmeldung benötigt wird, kann folgendem Element der Antwort entnommen werden:

• SoapBody/SubscribeResponse/SubscriptionReference/Address (TextContent)

Die Gültigkeitsdauer der eingebrachten Subskription kann folgendem Element der Antwort entnommen werden:

• SoapBody/SubscribeResponse/TerminationTime

DSUB ITI-52 Beispiel

Abmeldung einer Subskription

Der Subscriber kann eine "Unsubscribe" Notifikation (entsprechend DSUB-Profil Kapitel 3.52.4.3 "Unsubscribe Request Message") einbringen, welche eine aktive Subskription storniert (bzw. löscht). Nach dem erfolgreichen Löschen der Subskription erfolgen dann keine weiteren Notifizierungen. Auch abgelaufene Subscriptions müssen abgemeldet werden.

Beim Unsubscribe wird der in der Subscrption Antwort erhaltene Wert aus SubscribeResponse/SubscriptionReference/Address in die Unsubscribe-Anfrage in das SOAP Header / To Element übernommen. Im Body wird ein leeres wsnt:Unsubscribe Element eingefügt (xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2").

Die Abmeldung einer Subskription wird laut DSUB an eine dynamische URL gesendet, die die ID der Subskription enthält, die beim Abonnieren zurückgegeben wurde. Der gleiche Wert ist im Addressing Header im ‚To‘ Element einzusetzen. In der BeS Implementierung würde es ausreichend sein, wenn das ‚To‘ Element korrekt befüllt ist – die tatsächliche URL könnte abweichen.

Hintergrund:

Der Client sendet seine Anfrage an vorgelagerte Komponenten wie die AGW oder andere Reverse-Proxy Komponenten, die den Addressing Header im Normalfall nicht anpassen. Die URL wird allerdings vom Apache der AGW verändert. Damit die Transaktionen nicht fehlschlagen, wird seitens BeS nur der Addressing Header geprüft, jedoch nicht ob die URL mit dem Addressing Header übereinstimmt.

Unsubscribe_REQ.xml

Unsubscribe_RSP.xml

Benachrichtigungen

Die ITI-53 Document Metadata Notify Nachricht wird nicht implementiert. Es wird eine E-Mail-Benachrichtigung über einen SMTP-Server ausgelöst. Die E-Mail-Adresse wird, wie bereits erwähnt, in der ITI-52 Nachricht im Element ConsumerReference/Address übergeben. Individuelle Policies werden bei der Notifizierung nicht geprüft.

Trigger Events für eine Benachrichtigung:

• Ausstellen einer Treatment-Assertion für schreibende Dokumenttransaktionen
  • Der E-Health-Broker wird aufgrund eines neuen Dokuments angestoßen

Für die Verarbeitung der Benachrichtigung muss vom Betreiber ein E-Mail-Server gestellt werden über den BeS die Benachrichtigungen versenden kann. Der SMTP-Server darf keine E-Mails außerhalb vom BeS empfangen.

Die Inhalte der Mails kann im Mail-Template frei angepasst werden. Es kann ein unterschiedliches Template für Bürger und GDA angegeben werden.

Es stehen folgende Variablen zur Verfügung, die verwendet werden können:

• {{SUB_ID}}
  • Die ID der Subskription, die auch für ein Unsubscribe verwendet werden muss
• {{SUB_OID}}
  • Die OID der Organisation die eine Subskription eingebracht hat
• {{SUB_SUB}}
  • Das XSPA-Subject aus der SAML des Benutzers der die Subskription eingebracht hat
• {{SUB_BPK-GH}}
  • Die BPK-GH auf die eine Subskription gemacht wurde
• {{SUB_ELAPSE}}
  • Das Datum/Zeit wann die Subskription abläuft
• {{SUB_DATE}}
  • Das Datum/Zeit wann die Subskription eingebracht wurde

Hinweis:
Der Inhalt der E-Mailbenachrichtigung muss final abgestimmt werden (auch sicherheitstechnisch). Grundsätzlich kann BeS nur Daten in die E-Mail übernehmen, die derzeit auch in BeS zur Verfügung stehen. Der Patientenname ist z.B. nicht bekannt.

Übersicht der Komponenten

Akteur	Transaktion	Komponente	Kommentar
Document Metadata Notification Broker	ITI-52 Document Metadata Subscribe und wsn:Unsubscribe	BeS zentral	Es wird vom E-Health-Broker eine Subscribe oder Unsubscribe-Nachricht empfangen. Die Subskription wird dementsprechend erstellt oder gelöscht. Es kann dabei vom Client ein Gültigkeitszeitraum mit dem InitialTerminationTime Element in der ITI-52 Anfrage angegeben werden (sonst gilt der Default-Wert aus DSUB_ELAPSE). Sie wird vom GDA über die AGW direkt an den zentralen BeS E-Health-Broker gesendet.
	ITI-54 Document Metadata Publish		Die Rolle wird vom E-Health-Broker bzw. ETS übernommen. Für jedes Dokument wird geprüft ob ein Abonnement vorliegt.
Document Metadata Subscriber	ITI-52 Document Metadata Subscribe	GDA, ELGA-Teilnehmer	Der Akteur, der benachrichtigt werden will, wenn ein "bestimmtes" Dokument in einem AC gespeichert wird macht eine Subskription beim E-Health-Broker.
Document Metadata Publisher	ITI-54 Document Metadata Publish	BeS zentral	Der Document Metadata Publish schickt jedes Dokument an den Document Metadata Notification Broker. Die Rolle wird vom E-Health-Broker bzw. ETS übernommen.

Tabelle: Übersicht DSUB Komponenten