first version of Patient-merge (#359)

* feat: added patient-merge subscription relevant ressources * auto-generated FHIR files by GitHub Actions (CI FSH to FHIR Validation) * feat: added patient-merge subscription md page * Update ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Patient-merge.md * add ig requirements + comments + examples * auto-generated FHIR files by GitHub Actions (CI FSH to FHIR Validation) * update requirement * Apply suggestions from code review * add Konzept Patient merge (#360) * add filge + update README * add file + update README * add: concept draft * fiy typos * Update Patient_merge.md * update with feedback from and after working group(#306) * Update Patient_merge.md * Add files via upload * Update Patient_merge.md * Update Patient_merge.md * Update Patient_merge.md * Update Patient_merge.md * editorial changes * Update Patient_merge.md * Update Patient_merge.md * add IHE info * minor corrections * TOC and numbering update * fix link * update: add summary + insert feedback --------- Co-authored-by: Max Theilig <[email protected]> * Update Patient_merge.md * Update Patient_merge.md * Update Patient_merge.md * Update Patient_merge.md * Update nach 2. AG --------- Co-authored-by: Max Theilig <[email protected]> * update concept * auto-generated FHIR files by GitHub Actions (CI FSH to FHIR Validation) * fix: modified patient merge to reflect the R5 backport * auto-generated FHIR files by GitHub Actions (CI FSH to FHIR Validation) * feat: added missing new markdown files to IG-resource * feat: added datensicherheit & websocket details * fix: added hl7.fhir.uv.subscriptions-backport: 1.1.0 dependency to package.json * fix: applied changes from PR review * update Festlegungen * add diagram * remove duplicate page * fix branch nacke for diagram * fix branch name * fix link * fix minor wording * fix minor typo * fix: changes Subscriptopn support to MAY * added pagelink * Update ImplementationGuide/markdown/Subscription/Subscription_Interaktionen.md Co-authored-by: f-peverali <[email protected]> * Update ImplementationGuide/markdown/Subscription/Subscription_AnmerkungenZuDenMustSupportFeldern.md Co-authored-by: f-peverali <[email protected]> * Update ImplementationGuide/markdown/Subscription/Subscription_AnmerkungenZuDenMustSupportFeldern.md Co-authored-by: f-peverali <[email protected]> * add info * applied all PR comments * fix: Formulierung * update information * feat: Aussage zu referenzen beim Patient-merge * auto-generated diagrams by GitHub Action after source code change * fix: Typo & Entfernung der Beschränkung auf den letzten Merge identifier entfernt * feat: merged with add-MS-Patient.link-PTDATA-676 * auto-generated diagrams by GitHub Action after source code change * fixed ReleaseNotes.md * Update Resources/input/fsh/ISiKCapabilityStatementBasisServer.fsh Co-authored-by: f-peverali <[email protected]> * Update ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Patient-merge.md Co-authored-by: f-peverali <[email protected]> * Update ImplementationGuide/markdown/Subscription/Subscription_Motivation.md Co-authored-by: f-peverali <[email protected]> * updated sushi version in devcontainer * PR Kommentare eingepflegt * PR Kommentare eingepflegt * auto-generated FHIR files by GitHub Actions (CI FSH to FHIR Validation) * Update Resources/input/fsh/ISiKPatient.fsh * auto-generated FHIR files by GitHub Actions (CI FSH to FHIR Validation) * Update Resources/input/fsh/ISiKPatient.fsh --------- Co-authored-by: patrick-werner <[email protected]> Co-authored-by: f-peverali <[email protected]> Co-authored-by: f-peverali <[email protected]> Co-authored-by: Max Theilig <[email protected]>
gematik · Mar 20, 2024 · c7edf75 · c7edf75
1 parent d5c1f32
commit c7edf75
Show file tree

Hide file tree

Showing 37 changed files with 1,167 additions and 642 deletions.
diff --git a/.devcontainer/Dockerfile b/.devcontainer/Dockerfile
@@ -3,8 +3,7 @@ FROM mcr.microsoft.com/devcontainers/base:alpine-3.18
 # Setzen der Umgebungsvariablen
 ENV FIRELY_TERMINAL_VERSION=3.1.0
 ENV JAVA_VALIDATOR_VERSION=6.0.11
-ENV SUSHI_VERSION=3.5.0
-
+ENV SUSHI_VERSION=3.8.0
 # Installieren der notwendige Tools
 # Add Microsoft's .NET SDK repository and install .NET SDK
 RUN wget https://dot.net/v1/dotnet-install.sh \

diff --git a/ImplementationGuide/Implementierungsleitfaden_ISiKBasismodul.json b/ImplementationGuide/Implementierungsleitfaden_ISiKBasismodul.json
@@ -111,6 +111,11 @@
               "nameUrl": "ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Rest.md",
               "title": "REST-API",
               "generation": "markdown"
+            },
+            {
+              "nameUrl": "ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Patient-merge.md",
+              "title": "Patient-Merge",
+              "generation": "markdown"
             }
           ]
         },
@@ -671,6 +676,43 @@
                   "generation": "markdown"
                 }
               ]
+            },
+            {
+              "nameUrl": "ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Subscription.md",
+              "title": "Subscription patient-merge (R5 Backport Subscription)",
+              "generation": "markdown",
+              "page": [
+                {
+                  "nameUrl": "ImplementationGuide/markdown/Subscription/Subscription_Motivation.md",
+                  "title": "Motivation",
+                  "generation": "markdown"
+                },
+                {
+                  "nameUrl": "ImplementationGuide/markdown/Subscription/Subscription_Kompatibilitaet.md",
+                  "title": "Kompatibilität",
+                  "generation": "markdown"
+                },
+                {
+                  "nameUrl": "ImplementationGuide/markdown/Subscription/Subscription_Profil.md",
+                  "title": "Profil",
+                  "generation": "markdown"
+                },
+                {
+                  "nameUrl": "ImplementationGuide/markdown/Subscription/Subscription_AnmerkungenZuDenMustSupportFeldern.md",
+                  "title": "Anmerkungen",
+                  "generation": "markdown"
+                },
+                {
+                  "nameUrl": "ImplementationGuide/markdown/Subscription/Subscription_Interaktionen.md",
+                  "title": "Interaktionen",
+                  "generation": "markdown"
+                },
+                {
+                  "nameUrl": "ImplementationGuide/markdown/Subscription/Subscription_Beispiele.md",
+                  "title": "Beispiele",
+                  "generation": "markdown"
+                }
+              ]
             }
           ]
         }

diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Subscription.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Subscription.md
@@ -0,0 +1,3 @@
+## Subscription patient-merge  [(R5 Backport Subscription)](https://hl7.org/fhir/uv/subscriptions-backport/components.html)
+
+---
diff --git a/ImplementationGuide/markdown/ReleaseNotes.md b/ImplementationGuide/markdown/ReleaseNotes.md
@@ -11,6 +11,7 @@ Version: 4.0.0-rc
 Datum: 11.03.2024 (WIP)
 
 * Ersetzen des ISiK-spezifischen Profils für IdentifierAbrechnungsnummer mit Profil aus Basisprofil-DE https://github.com/gematik/spec-ISiK-Basismodul/pull/381
+* Hinzufügen MustSupport für Patient.link & patient-merge Subscription(Topic) https://github.com/gematik/spec-ISiK-Basismodul/pull/395
 * Abkündigen der Slices zu VersichertenId-GKV und ersetzen mit generischer Versicherten-ID : https://github.com/gematik/spec-ISiK-Basismodul/pull/382/files
 
 ----

diff --git a/...nGuide/markdown/Subscription/Subscription_AnmerkungenZuDenMustSupportFeldern.md b/...nGuide/markdown/Subscription/Subscription_AnmerkungenZuDenMustSupportFeldern.md
@@ -0,0 +1,49 @@
+### Anmerkungen zu den Must-Support-Feldern
+
+### `Subscription.status`
+
+**Bedeutung:** Der Status der Subscription, der den Serverstatus der Subscription angibt. Neue Subscriptions werden immer mit dem Status `requested` an den Server übergeben. Der Server ändert im Anschluss den Status auf `active` oder im Fehlerfall auf `error`.
+
+**Hinweise:** Siehe [R4 Subscriptions](https://hl7.org/fhir/R4/subscription.html)
+
+### `Subscription.reason`
+
+**Bedeutung:** Beschreibung wieso diese Subscription erstellt wurde.
+
+**Hinweise:** Siehe [R4 Subscriptions](https://hl7.org/fhir/R4/subscription.html)
+
+### `Subscription.category`
+
+**Bedeutung:** Canonical URL des Subscription-Topics, aktuell wird nur folgendes SubscriptionTopic unterstützt: https://gematik.de/fhir/isik/SubscriptionTopic/patient-merge
+
+**Hinweise:** Siehe [Subscriptions R5 Backport](https://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition-backport-subscription.html)
+
+### `Subscription.type`
+
+**Bedeutung:** Der Typ des Kommunikationskanals, über den Subscription-Benachrichtigungen gesendet werden sollen.
+
+**Hinweise:** Siehe [R4 Subscriptions](https://hl7.org/fhir/R4/subscription.html)
+
+### `Subscription.endpoint`
+
+**Bedeutung:** Adresse des Kommunikationskanals/ Endpunkts an den Subscription-Benachrichtigungen gesendet werden sollen. Dies ist nur für rest-hook Subscriptions relevant.
+
+**Hinweise:** Siehe [R4 Subscriptions](https://hl7.org/fhir/R4/subscription.html)
+
+### `Subscription.payload`
+
+**Bedeutung:** Format in dem Subscription Notifications versendet werden sollen (JSON oder XML)
+
+**Hinweise:** Siehe [R4 Subscriptions](https://hl7.org/fhir/R4/subscription.html)
+
+### `Subscription.payload.extension[content]`
+
+**Bedeutung:** Welcher Ressourceninhalt in der Nutzlast der Benachrichtigung geliefert werden soll. Zur Auswahl stehen eine leere Nutzlast (`empty`), nur die Ressourcenid (`id-only`) oder der gesamte Inhalt der Ressource (`full-resource`).
+
+**Hinweise:** Siehe [Extension: Backport R5 Subscription Payload Content Information](https://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition-backport-payload-content.html)
+
+### `Subscription.header`
+
+**Bedeutung:** http-Header welcher dazu genutzt werden kann einen Authorization-header zu setzen. Dies ist nur für rest-hook Subscriptions relevant.  
+
+**Hinweise:** ACHTUNG: dieses Datenfeld muss bei READ-Interaktionen maskiert werden! Siehe [R4 Subscriptions](https://hl7.org/fhir/R4/subscription.html)
diff --git a/ImplementationGuide/markdown/Subscription/Subscription_Beispiele.md b/ImplementationGuide/markdown/Subscription/Subscription_Beispiele.md
@@ -0,0 +1,25 @@
+### Beispiele
+
+#### Subscription
+
+{{json:PatientMergeSubscriptionExample}}
+
+#### SubscriptionNotification-Bundle
+
+{{json:SubscriptionNotificationBundleExample}}
+
+#### Patientenobjekte
+"Quell" Patienten-Ressource:  
+{{json:DorisQuelle}}
+
+und
+
+"Ziel" Patienten-Ressource:  
+{{json:DorisZiel}}
+
+Mittels eines Patient-merge-Vorgangs wird die "Ziel" Patienten-Ressource ausgewählt und beide Ressourcen entsprechend modifiziert:
+
+Resultierende Patientin:
+{{json:DorisResultat}}
+
+---
diff --git a/ImplementationGuide/markdown/Subscription/Subscription_Interaktionen.md b/ImplementationGuide/markdown/Subscription/Subscription_Interaktionen.md
@@ -0,0 +1,11 @@
+### Interaktionen
+
+Für die Ressource Subscription SOLL die REST-Interaktion "READ", "CREATE", "UPDATE", "DELETE" implementiert werden, insofern der festgelegte Lösungsansatz zu 'Patient merge Notification' implementiert wird.
+
+## Operations
+
+Bei der Umsetzung des Subscription Channel Type `websocket` SOLL die Operation [`$get-ws-binding-token`](https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/OperationDefinition-backport-subscription-get-ws-binding-token.html) supported werden.
+
+Siehe auch: {{pagelink:ImplementationGuide/markdown/CapabilityStatement.md, text:CapabilityStatement}} & {{pagelink:ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Patient-merge.md, text:Patient merge und Notification}}
+
+---
diff --git a/ImplementationGuide/markdown/Subscription/Subscription_Kompatibilitaet.md b/ImplementationGuide/markdown/Subscription/Subscription_Kompatibilitaet.md
@@ -0,0 +1,8 @@
+### Kompatibilität
+
+Das Profil PatientMergeSubscription basiert auf dem [Backport-Subscription Profil](https://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition-backport-subscription.html).  
+Der [SubscriptionStatus](https://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition-backport-subscription-status-r4.html), sowie das [Subscription Notification Bundle](https://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition-backport-subscription-notification-r4.html) werden unverändert direkt aus dem [Subscriptions R5 Backport IG](https://hl7.org/fhir/uv/subscriptions-backport/index.html) genutzt.  
+
+---
+
+
diff --git a/ImplementationGuide/markdown/Subscription/Subscription_Motivation.md b/ImplementationGuide/markdown/Subscription/Subscription_Motivation.md
@@ -0,0 +1,9 @@
+## Motivation
+
+Subscription ist eine FHIR Ressource um als Client-System Benachrichtigungen über Events auf dem FHIR Server anzufragen. Der Subscription Mechanismus in FHIR R4 ist nicht geeignet, um alle relevanten Events (hier im Speziellen das Mergen von Patienten) zu unterstützen. Daher basiert das ISiK Subscription-Profil auf dem [Subscriptions R5 Backport Profil von HL7](https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/StructureDefinition-backport-subscription.html).
+
+Siehe auch: {{pagelink:ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Patient-merge.md, text:Übergreifende Festlegungen Patient-merge}}
+
+Um als Subsystem über ein Patienten-Merge-Event informiert zu werden, KANN der FHIR Subscription Mechanismus gemäß des [Subscriptions R5 Backport IGs von HL7](https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/index.html) genutzt werden.
+
+---
diff --git a/ImplementationGuide/markdown/Subscription/Subscription_Profil.md b/ImplementationGuide/markdown/Subscription/Subscription_Profil.md
@@ -0,0 +1,11 @@
+## Profil
+
+@```
+from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/patient-merge-subscription' select Name: name, Canonical: url
+```
+
+{{tree:https://gematik.de/fhir/isik/StructureDefinition/patient-merge-subscription, hybrid}}
+
+@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/patient-merge-subscription' for differential.element.constraint select key, severity, human, expression```
+
+---
diff --git a/...markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Patient-merge.md b/...markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Patient-merge.md
@@ -0,0 +1,111 @@
+# Patient merge und Notification
+
+## Motivation
+Im Rahmen von Krankenhausbesuchen umfassen u.a. die Aufnahme-Workflows regelmäßig die manuelle Bearbeitung von Patientenstammdaten. Daher ist hier das Risiko redundant persistierter Patientendaten stets vorhanden. Dies hat auch zur Folge, dass Zusammenführungen von Patientendaten in Krankenhäusern an der Tagesordnung stehen. 
+
+Die Patientendatenzusammenführung (Patient merge) bezeichnet den Workflow der Bereinigung redundanter Patienten-Instanzen innerhalb eines KIS oder einer KH-IT-Umgebung. Die Bereinigung geschieht erfahrungsgemäß als halb-automatisierter Prozess, für den dedizierte Komponenten eingesetzt werden können (d.h. Master-Patient-Index).
+
+Im Kontext verteilter Systeme ist es entscheidend, dass ein patientenführendes System/Server (KIS) einen Client über einen Patient merge benachrichtigt (Patient merge Notification), damit der Client weiterhin auf eine korrekte Patienteninstanz zugreifen kann. Daher trifft dieser Abschnitt eine Festlegung zur Umsetzung einer Patient merge Notification auf Basis von FHIR.
+
+## Normativer Status 
+Alle hier getroffenen Festlegungen haben den normativen Status einer KANN-Anforderung. Werden allerdings die hier festgelegten Lösungen genutzt, so SOLLEN die hier angeführten Vorgaben (inklusive Profil-Ebene) eingehalten werden.
+
+Eine Prüfung im Rahmen des Bestätigungsverfahrens zur Patient merge Notification ist in der jetzigen Entwicklungsstufe nicht vorgesehen.
+
+## Zweck und Definition 'Patient merge Notification'
+Zweck dieses Abschnitts ist eine Festlegung darüber zu treffen, wie externe Clients Patient-merge-Vorgänge nachvollziehen und entsprechend verarbeiten können.
+Entsprechend wird hier eine Festlegung zur Kommunikation eines stattgefundenen Patient merges (Patient merge Notification) gegenüber einem Subsystem oder einem externen Service - u.a. mittels FHIR Subscriptions - festgelegt.
+
+**Definition**: Der Workflow 'Patient merge Notification' entspricht der Benachrichtigung angeschlossener Systeme  über den erfolgreichen Patient merge. Die Benachrichtigung unterstützt das Kernziel einer reibungslosen Kommunikation zwischen zwei Systemen, nachdem ein Patient merge stattgefunden hat. Durch die Benachrichtigung wird ein fehlerhafter Abruf oder falsche Referenzierung einer alten Patientenressource von Seiten des Clients verhindert oder zumindest vorgebeugt und damit eine Verbesserung der Qualität hinsichtlich Robustheit und damit auch eine Stärkung der Praxistauglichkeit von ISiK als Schnittstellen-Lösung erreicht.
+
+## Festlegungen zu 'Patient merge Notification'
+Falls eine Patient merge Notification im Rahmen von ISIK bereitgestellt wird, gelten folgende Festlegungen:
+
+Das patientenführende System SOLL einen Client mittels FHIR Subscription über einen erfolgten Patienten merge informieren können. Dieser Mechanismus basiert auf dem [Subscriptions R5 Backport IG](https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/channels.html) und nutzt das Konzept der "Topic-Based Subscription" aus FHIR R5.  
+
+Hierfür wurde das Subscription Topic: *https://gematik.de/fhir/isik/SubscriptionTopic/patient-merge* definiert.
+
+Das patientenführende System SOLL den Support dieser Subscription innerhalb des CapabilityStatements bekannt geben.
+
+Weitere Informationen zum Subscription Workflow finden sich hier:
+
+[Subscription Workflow - Subscriptions R5 Backport](https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/workflow.html)
+
+### Prove of Concept Implementierung
+Zur Illustration der technischen Umsetzung für die Patient merge Notification dient ein [Prove of Concept (POC) mit Anleitung](https://github.com/gematik/poc-isik-patient-merge). 
+
+### Notification Channel Types
+Notifications über einen Patient-merge-Vorgang können per *rest-hook* oder *websocket* an das subscribende System versandt werden. Im *rest-hook* Fall postet das patientenführende System ein NotificationBundle an den in `Subscriptipn.channel.endpoint` definierten REST Endpunkt. Bei einer *websocket* Notification geschieht das über einen Websocket-Channel. Die Websocketurl, sowie ein Access Token können mittels [`$get-ws-binding-token` Operation](https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/OperationDefinition-backport-subscription-get-ws-binding-token.html)  vom Server abgerufen werden.
+
+## Abgrenzung zu 'Patient merge'
+Das Mergen von Patientendaten ist Aufgabe des bestätigungsrelevanten Systems (d.h. hier des patientenführenden Systems / KIS). 
+Ein externes Starten eines Patient merge - bspw. durch die [$patient-merge Operation aus R5](https://hl7.org/fhir/R5/patient-operation-merge.html) - MUSS von einem bestätigungsrelevanten System NICHT unterstützt werden.
+
+**Hinweis**: Die Patienten-Ressource, die nicht weiter verwendet werden soll, nennen wir im Folgenden die "obsolete Ressource". Die Ressource, die erhalten bleiben soll, nennen wir "resultierende Ressource".
+
+### Obsolete Patienten-Ressource
+Es gelten keine gesonderten Anforderungen an eine obsolete Patienten-Ressource über die ISiKPatient Profilanforderungen hinaus.
+
+Es gilt allerdings folgende Annahme: Das patientenführende System SOLL sicherstellen, dass alle auf die obsolete Ressource referenzierenden FHIR-Ressourcen nach dem Patient merge auf die resultierende Ressource referenzieren. 
+
+Allerdings KANN das patientenführende System die obsolete Patienten-Ressource weiter vorhalten. Ein Entfernen der obsoleten Ressource ist ebenfalls erlaubt.
+
+Falls die obsolete Ressource nach einem merge weiter vorgehalten wird, SOLLEN die Elemente der obsoleten Ressource folgendermaßen befüllt werden, um sicherzustellen, dass die obsolete Ressource auf die resultieren Ressource verweist und dass die obsolete Ressource als inaktiv gekennzeichnet ist:
+- .active = false
+- .link.other = Reference(auf “resultierenden” Patient)
+- .link.type = “replaced-by”
+
+### Resultierende Patienten-Ressource
+Es gelten keine gesonderten Anforderungen an eine obsolete Patienten-Ressource über die ISIKPatient Profilanforderungen hinaus.
+
+Allerdings SOLL das patientenführende System nach einem merge die Elemente der resultierenden Ressource folgendermaßen befüllen, um sicherzustellen, dass die resultierende Ressource auf die obsolete Ressource verweist:
+- .link.other = Reference.identifier (logische Referenz mittels Patientennummer Identifier auf “obsoleten” Patient)
+- .link.type = “replaces”
+
+Siehe auch: {{pagelink:ImplementationGuide/markdown/Patient/Patient_Profil.md, text:Patienten Profil }}
+
+### Referenzen auf das Patientenobjekt
+Das patientenführende System muss im Rahmen des Patient merges alle auf den Patienten referenzierenden Ressourcen auf die resultierende Ressource referenzieren lassen.
+
+## Hinweise zum Client-System
+
+### Recovery Mechanismus
+Ein Recovery Mechanismus wird benötigt, damit im Falle einer ausgebliebenen Patient merge Notification ein Client die aktuelle Patienteninstanz auffinden und erneut referenzieren kann.
+
+Folgender Hinweis dient der Einhaltung eines Recovery Mechanismus:
+
+Client-Systeme SOLLEN den Status einer gecachten Patienteninstanz vor der Interaktion mit einem patientenführenden System per READ auf das Patientenobjekt überprüfen.
+Sollte die Patienten-Ressource nicht mehr bereitstehen, oder die Ressource den status `active=false` haben, kann das Patientenobjekt mittels Suche auf einen bekannten und stabilen Identifier, bspw. die gesetzliche Krankenversichertennummer, neu geladen werden.
+
+
+### Datensicherheit Client
+
+**Hinweis**: Die "patient-merge Subscription-Notification" kann personenbezogene Daten versenden, falls man "full-resource" als Content-Code gewählt hat. Für den REST-Hook sollte daher stets ein HTTPS-Endpunkt genutzt werden. Zusätzlich kann Subscription.channel.header genutzt werden, um einen Autorisierungs-Header an den Endpunkt zu übertragen.   
+Siehe auch: [Safety and Security, Subscription Backport IG](https://hl7.org/fhir/uv/subscriptions-backport/safety_security.html)
+
+In jedem Fall sind auch Client-seitig die notwendigen Maßnahmen zu ergreifen, um eine sichere Kommunikation personenbezogener Daten zu gewährleisten.
+
+### Websocket
+
+Hier muss sich der Client per [`$get-ws-binding-token` Operation](https://hl7.org/fhir/uv/subscriptions-backport/OperationDefinition-backport-subscription-get-ws-binding-token.html) einen Token zum Zugriff auf den Websocket-Endpunkt des patientenführenden Systems holen. In der Operation-Response sind zusätzlich die Expiration-Dauer, sowie der Websocket-Endpunkt enthalten.  
+Siehe auch: [Subscriptions R5 Backport IG, Websocket](https://hl7.org/fhir/uv/subscriptions-backport/channels.html#websockets)
+
+## Beispiele
+Die Patient merge Notification kann folgendermaßen illustriert werden: 
+
+Es existieren fälschlicherweise zwei Instanzen im patientenführenden System, die sich lediglich hinsichtlich der organisationsspezifischen Patienten-ID unterscheiden.
+Diese sind:
+
+"Quell" Patienten-Ressource:  
+{{json:DorisQuelle}}
+
+und
+
+"Ziel" Patienten-Ressource:  
+{{json:DorisZiel}}
+
+Mittels eines Patient merge wird die "Ziel" Patienten-Ressource ausgewählt und beide Ressourcen entsprechend modifiziert. Daraus entsteht die resultierende Patienten-Instanz:
+{{json:DorisResultat}}
+
+Da sich ein Client am patientenführenden System für das dedizierte SubscriptionTopic (http://hl7.org/SubscriptionTopic/patient-merge) registriert hat, erhält der Client eine Benachrichtigung in Form eines Bundles mit Verweis auf die resultierende Ressource.
+
Original file line number	Diff line number	Diff line change
		@@ -0,0 +1,3 @@
		## Subscription patient-merge [(R5 Backport Subscription)](https://hl7.org/fhir/uv/subscriptions-backport/components.html)

		---