applied all PR comments

ImplementationGuide/Implementierungsleitfaden_ISiKBasismodul.json

@@ -595,7 +595,7 @@
                 },
                 {
                   "nameUrl": "ImplementationGuide/markdown/Subscription/Subscription_Interaktionen.md",
-                  "title": "Anmerkungen",
+                  "title": "Interaktionen",
                   "generation": "markdown"
                 },
                 {

ImplementationGuide/markdown/Subscription/Subscription_Interaktionen.md

@@ -2,4 +2,10 @@
 
 Für die Ressource Subscription MUSS 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` MUSS 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}}
+
 ---

ImplementationGuide/markdown/Subscription/Subscription_Motivation.md

@@ -1,8 +1,9 @@
 ## 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 halbautomatisierter Prozess, für den dedizierte Komponenten eingesetzt werden können.
+ Subscription ist eine FHIR Ressource um als Client-System Benachrichtigungen über Events auf dem FHIR Server zu erhalten. 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 Subscriptionprofil auf dem [Subscriptions R5 Backport Profil von HL7](https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/StructureDefinition-backport-subscription.html).
 
-Um als Subsystem über ein Patienten-Merge-Event informiert zu werden, KANN der FHIR Subscription Mechanismus gemäß der [FHIR R5 Spezifikation](https://hl7.org/fhir/R5/subscription.html) genutzt werden.
+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.
 
 ---

ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Patient-merge.md

@@ -27,16 +27,15 @@ Hierfür wurde das Subscription Topic: *https://gematik.de/fhir/isik/Subscriptio
 
 Das patientenführende System MUSS den Support dieser Subscription innerhalb des CapabilityStatements bekannt geben.
 
-Zur Illustration der Patient merge Notification dient folgendes Diagramm:
+Weitere Informationen zum Subscription Workflow finden sich hier:
 
-<img src="https://raw.githubusercontent.com/gematik/spec-ISiK-Basismodul/feat/pat-merge/Material/images/diagrams/Sequence-Diagram-Patient-Merge-Notification.svg" alt="Sequence Diagram 'Patient merge Notification'" width="90%"/>
-<!-- 
-TODO  
-<img src="https://raw.githubusercontent.com/gematik/spec-ISiK-Basismodul/rc/main-stufe-4/Material/images/diagrams/Sequence-Diagram-Patient-Merge-Notification.svg" alt="Sequence Diagram" width="90%"/ >
---> 
+[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). 
 
-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). 
@@ -75,7 +74,7 @@ Ein Recovery Mechanismus wird benötigt, damit im Falle einer ausgebliebenen Pat
 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 neu geladen werden.
+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

Resources/fsh-generated/resources/StructureDefinition-ISiKPatient.json

@@ -622,8 +622,7 @@
       {
         "id": "Patient.link",
         "path": "Patient.link",
-        "comment": "Dieses und untergeordnete Elemente MÜSSEN bei einem erfolgten Patient merge entsprechend der Festlegungen im Implementation Guide befüllt werden.",
-        "mustSupport": true
+        "comment": "Dieses und untergeordnete Elemente können bei einem erfolgten Patient merge entsprechend der Festlegungen im Implementation Guide befüllt werden."
       },
       {
         "id": "Patient.link.other",

Resources/input/fsh/ISiKPatient.fsh

@@ -104,8 +104,8 @@ Description: "Dieses Profil beschreibt die Nutzung von administrativen Patienten
   * city 1.. MS
   * postalCode 1.. MS
   * country 1.. MS
-* link MS
-  * ^comment = "Dieses und untergeordnete Elemente MÜSSEN bei einem erfolgten Patient merge entsprechend der Festlegungen im Implementation Guide befüllt werden."
+* link 
+  * ^comment = "Dieses und untergeordnete Elemente können bei einem erfolgten Patient merge entsprechend der Festlegungen im Implementation Guide befüllt werden."
   * other MS
     * identifier MS
       * ^comment = "Logischer Verweis auf Identifier[Patientennummer]"