-Elementen zusammengefügt werden.
+
+### Extraktion der Patient-/ und Encounter-Ressource im Document-Bundle
+
+Folgende Fälle sind zu beachten, um eine Patient-/ und Encounter-Ressource aus dem Document-Bundle zu extrahieren:
+
+* Die aufzulösende Referenz ist eine URN (immer absolut, z. B. "urn:uuid:9d1714da-b7e6-455b-bfd2-69ce0ff5fb12"):
+ * Suche nach einem Bundle-Entry mit einer fullUrl, die mit dem reference.value übereinstimmt
+ * Wenn einer gefunden wird, ist die Auflösung erfolgreich (und endet hier)
+ * Andernfalls schlägt die Auflösung fehl (und endet hier). Die Referenz hat in dieser Spezifikation keine definierte Bedeutung.
+
+* Wenn die Referenz eine absolute URL ist (z. B. "https://fhir.example.org/base/Patient/123", "https://fhir.example.org/base/Patient/123/_history/a"):
+ * Suche nach einem Bundle-Entry mit einer fullUrl, die mit dem reference.value übereinstimmt
+ * Wenn einer gefunden wird, ist die Auflösung hier erfolgreich (und endet)
+ * Wird mehr als ein Eintrag gefunden, KANN der Server nach der neuesten Version suchen (basierend auf meta.lastUpdated). Wenn jener auf diese Weise genau eine aktuelle Version findet, ist die Auflösung erfolgreich (und endet hier)
+
+* Wenn die Referenz die Form "[Typ]/[id]" hat (z. B. "Patient/123")
+ * Wenn der Bundle-Entry, der den Verweis enthält, eine FullUrl hat, die dem [RESTful-URL-Regex](https://hl7.org/fhir/R4/references.html#regex) entspricht (z. B. "https://fhir.example.org/Observation/456"):
+ * Extrahiert wird die [root] aus der fullUrl des Bundle-Entries und mit der relative Referenz zusammengefügt (z. B. "https://fhir.example.org/" + "Patient/123" --> "https://fhir.example.org/Patient/123")
+ * Gefolgt wird den Schritten für die Auflösung absoluter Referenzen. Siehe oben.
+
+### Persistierung der menschenlesbaren Repräsentation
+
+Das Narrative der Ressource KANN innerhalb einer DocumentReference-Ressource persistiert werden. Zum derzeitigen Zeitpunkt obliegt es der jeweiligen Implementierung wie diese DocumentReference Ressource ausgestaltet ist.
+Ein Mapping der Composition-Metadaten auf DocumentReference-Metadaten KANN der FHIR Kernspezifikation entnommen werden. Siehe [Abschnitt "2.42.8.7 FHIR Composition"](https://www.hl7.org/fhir/R4/documentreference-mappings.html#fhircomposition).
+
+Das Narrative MUSS als Binary-Ressource unter DocumentReference.content.attachment.url angegeben werden.
+
+**Hinweis:** Es ist zu beachten, dass in einem Attachment-Datentyp im Element "url" eine absolute URL anzugeben ist. Somit muss zunächst das Binary auf dem externen System per POST angelegt werden. Der hieraus resultierende Link kann anschließend im Attachment verwendet werden.
+
+Falls ein Bundle erneut mit dem gleichen Bundle.identifier übermittelt wird, MUSS eine neue DocumentReference erstellt werden, welche unter DocumentReference.relatesTo.target angegeben wird.
+
+### Hinweise zum Umgang mit strukturierten Daten
+
+Auch wenn in der aktuellen Stufe nur die Übernahme der menschenlesbaren Repräsentation erforderlich ist, empfiehlt es sich dennoch, das vollständige Bundle samt der strukturierten Anteile zu einem Dokument zu persistieren, sodass zu einem späteren Zeitpunkt, wenn eine Übernahme einzelner Daten möglich ist, diese auch rückwirkend erfolgen kann.
+
diff --git a/guides/Implementierungsleitfaden-ISiK-Basismodul-401/Einfuehrung/UseCasesAnwendung/Index.page.md b/guides/Implementierungsleitfaden-ISiK-Basismodul-401/Einfuehrung/UseCasesAnwendung/Index.page.md
new file mode 100644
index 00000000..0d09eda8
--- /dev/null
+++ b/guides/Implementierungsleitfaden-ISiK-Basismodul-401/Einfuehrung/UseCasesAnwendung/Index.page.md
@@ -0,0 +1,6 @@
+---
+topic: ImplementationGuide-markdown-UseCasesAnwendung
+---
+# Use Cases und Anwendungszusammenhänge
+
+{{index:current}}
\ No newline at end of file
diff --git "a/guides/Implementierungsleitfaden-ISiK-Basismodul-401/Einfuehrung/UseCasesAnwendung/Patientenzusammenf\303\274hrung.page.md" "b/guides/Implementierungsleitfaden-ISiK-Basismodul-401/Einfuehrung/UseCasesAnwendung/Patientenzusammenf\303\274hrung.page.md"
new file mode 100644
index 00000000..009c1909
--- /dev/null
+++ "b/guides/Implementierungsleitfaden-ISiK-Basismodul-401/Einfuehrung/UseCasesAnwendung/Patientenzusammenf\303\274hrung.page.md"
@@ -0,0 +1,112 @@
+---
+topic: Patient-merge
+---
+# 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 `Subscription.channel.endpoint` definierten REST Endpunkt. Bei einer *websocket* Notification geschieht das über einen Websocket-Channel. Die Websocket URL, 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.
+
+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
+Es gilt 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.
+
+## 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:Resources/static/Patient-DorisResultat.json}}
+
+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.
+
diff --git a/guides/Implementierungsleitfaden-ISiK-Basismodul-401/Einfuehrung/UseCasesAnwendung/UseCases.page.md b/guides/Implementierungsleitfaden-ISiK-Basismodul-401/Einfuehrung/UseCasesAnwendung/UseCases.page.md
new file mode 100644
index 00000000..9e3112ef
--- /dev/null
+++ b/guides/Implementierungsleitfaden-ISiK-Basismodul-401/Einfuehrung/UseCasesAnwendung/UseCases.page.md
@@ -0,0 +1,18 @@
+---
+topic: ImplementationGuide-markdown-UseCasesAnwendung-UseCases
+---
+# Use Cases - Übersicht
+Im Folgenden wird ein grafischer Überblick über für dieses Modul relevante Anwendungsfälle gegeben.
+Da es sich um eine Zusammenfassung handelt, werden nur folgende Use Case und dafür hinreichende Funktionen dargestellt:
+* Allgemeine und intuitive verständliche Use Cases.
+ * Kombinationen und weitere Details sind möglich.
+ * Übergreifende Use Cases und ihre Sub-Use-Cases können ggf. in einem separaten Diagramm auf den entsprechenden Seiten gefunden werden.
+* Allgemeine und intuitive Adverse Use Cases. Diese gilt es zu vermeiden.
+
+
+**Use Case Digramm**
+
+
+
+
+
diff --git a/guides/Implementierungsleitfaden-ISiK-Basismodul-401/Einfuehrung/UseCasesAnwendung/toc.yaml b/guides/Implementierungsleitfaden-ISiK-Basismodul-401/Einfuehrung/UseCasesAnwendung/toc.yaml
new file mode 100644
index 00000000..de3c602e
--- /dev/null
+++ b/guides/Implementierungsleitfaden-ISiK-Basismodul-401/Einfuehrung/UseCasesAnwendung/toc.yaml
@@ -0,0 +1,12 @@
+- name: Index
+ filename: Index.page.md
+- name: Anwendungsfälle (Use Cases)
+ filename: UseCases.page.md
+- name: Abbildung des Konstrukts "Fall"
+ filename: Abbildung-des-Konstrukts-Fall.page.md
+- name: Datenübermittlung aus Subsystemen
+ filename: Datenübermittlung-aus-Subsystemen.page.md
+- name: Patientenzusammenführung
+ filename: Patientenzusammenführung.page.md
+- name: Beispielszenarien
+ filename: Beispielszenarien
diff --git a/guides/Implementierungsleitfaden-ISiK-Basismodul-401/Einfuehrung/toc.yaml b/guides/Implementierungsleitfaden-ISiK-Basismodul-401/Einfuehrung/toc.yaml
new file mode 100644
index 00000000..3d8a5416
--- /dev/null
+++ b/guides/Implementierungsleitfaden-ISiK-Basismodul-401/Einfuehrung/toc.yaml
@@ -0,0 +1,12 @@
+- name: Index
+ filename: Index.page.md
+- name: Motivation
+ filename: Motivation.page.md
+- name: ReleaseNotes
+ filename: ReleaseNotes.page.md
+- name: Use Cases
+ filename: UseCasesAnwendung
+- name: Übergreifende Festlegungen
+ filename: UebergreifendeFestlegungen
+- name: Datenobjekte
+ filename: Datenobjekte
diff --git a/guides/Implementierungsleitfaden-ISiK-Basismodul-401/guide.yaml b/guides/Implementierungsleitfaden-ISiK-Basismodul-401/guide.yaml
new file mode 100644
index 00000000..3d414f98
--- /dev/null
+++ b/guides/Implementierungsleitfaden-ISiK-Basismodul-401/guide.yaml
@@ -0,0 +1,6 @@
+title: Implementierungsleitfaden ISiK-Basismodul (Refactored)
+description:
+version: 4.0.1
+style-root: styles
+style-name: twolevelmenu
+numbered-headings: false
diff --git a/guides/Implementierungsleitfaden-ISiK-Basismodul-401/toc.yaml b/guides/Implementierungsleitfaden-ISiK-Basismodul-401/toc.yaml
new file mode 100644
index 00000000..07923a09
--- /dev/null
+++ b/guides/Implementierungsleitfaden-ISiK-Basismodul-401/toc.yaml
@@ -0,0 +1,2 @@
+- name: Einführung
+ filename: Einfuehrung
diff --git a/guides/Implementierungsleitfaden-ISiK-Basismodul-401/variables.yaml b/guides/Implementierungsleitfaden-ISiK-Basismodul-401/variables.yaml
new file mode 100644
index 00000000..d1bca92f
--- /dev/null
+++ b/guides/Implementierungsleitfaden-ISiK-Basismodul-401/variables.yaml
@@ -0,0 +1,2 @@
+greeting: Hello World!
+capability: https://gematik.de/fhir/isik/CapabilityStatement/ISiKCapabilityStatementBasisServer
\ No newline at end of file
diff --git a/package.json b/package.json
index c2d0b296..990681e8 100644
--- a/package.json
+++ b/package.json
@@ -1,6 +1,6 @@
{
"name": "de.gematik.isik-basismodul",
- "version": "4.0.0",
+ "version": "4.0.1",
"fhirVersions": [
"4.0.1"
],
diff --git a/scripts/update-compile-and-validation-tools.py b/scripts/update-compile-and-validation-tools.py
new file mode 100644
index 00000000..e2ce5b6e
--- /dev/null
+++ b/scripts/update-compile-and-validation-tools.py
@@ -0,0 +1,30 @@
+### This script updates the main.yml file with the latest versions of firely-terminal and sushi and can be used locally
+import requests
+import os
+
+def get_latest_version(repo):
+ url = f"https://api.github.com/repos/{repo}/releases/latest"
+ response = requests.get(url)
+ response.raise_for_status()
+ return response.json()["tag_name"]
+
+if __name__ == "__main__":
+ firely_terminal_version = get_latest_version("FirelyTeam/firely-terminal-pipeline")
+ sushi_version = get_latest_version("FHIR/sushi")
+
+ script_dir = os.path.dirname(__file__)
+ main_yml_path = os.path.abspath(os.path.join(script_dir, "../.github/workflows/main.yml"))
+
+ with open(main_yml_path, "r") as file:
+ lines = file.readlines()
+
+ with open(main_yml_path, "w") as file:
+ for line in lines:
+ if line.strip().startswith("uses: FirelyTeam/firely-terminal-pipeline@"):
+ file.write(f" uses: FirelyTeam/firely-terminal-pipeline@{firely_terminal_version}\n")
+ elif line.strip().startswith("SUSHI_VERSION:"):
+ file.write(f" SUSHI_VERSION: {sushi_version}\n")
+ else:
+ file.write(line)
+
+ print(f"Updated main.yml with firely-terminal=={firely_terminal_version} and sushi=={sushi_version}")
\ No newline at end of file