update concept

ImplementationGuide/markdown/UebergreifendeFestlegungen/Patient_merge.md → Material/Patient_merge.md

@@ -47,15 +47,15 @@ Dieses Dokument soll der Harmonisierung der Problemdefinition zum Patient merge
 ## 2. Ziele (Update 29.01.2024)
 Ziel der Arbeiten im Rahmen der Ausbaustufe 4 ist:
 Die Schaffung eines modulübergreifenden Implementierungsleitfadens zum Vorgehen bei der Patientenzusammenführung.
-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.
+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.
 
 Für die Implementierung wurde gemeinsam mit den beteiligten Stakeholdern in der ersten Projektphase entschieden, zu welchem Vorgang die Spezifikation eine mögliche Festlegung treffen soll:
-1. Eine Festlegung zur Kommunikation eines stattgefundenen Patient merges gegenüber einem Subsystem oder einem externen Service wird festgelgt und dafür wir eine Lösung mit FHIR-subscriptions angestrebt.
-  - Eine Lösung mittels FHIR-Susbscriptions MUSS auf den in R5 definierten Lösungen aufbauen; eine Nutzung des R4 Subscription Profils genügt nicht.
-  - Die technische Lösung DARF NICHT auf einer Persisitierung obsoleter Ressourcen beruhen. Auch DARF (aus Gründen der Performance) in der resultierenden Ressource keine (vollständige) History obsoleter Ressourcen (z.B. über das .link-Element) geführt werden.
+1. Eine Festlegung zur Kommunikation eines stattgefundenen Patient merges gegenüber einem Subsystem oder einem externen Service wird festgelegt und dafür wir eine Lösung mit FHIR-subscriptions angestrebt.
+    - Eine Lösung mittels FHIR-Subscriptions MUSS auf den in R5 definierten Lösungen aufbauen; eine Nutzung des R4 Subscription Profils genügt nicht.
+    - Die technische Lösung DARF NICHT auf einer Persistierung obsoleter Ressourcen beruhen. Auch DARF (aus Gründen der Performance) in der resultierenden Ressource keine (vollständige) History obsoleter Ressourcen (z.B. über das .link-Element) geführt werden.
 1. Im Zuge des POC SOLLEN auch Sicherheitsaspekte umgesetzt werden (ggf. Autorisierung und Authentifizierung über SMART on FHIR / ISiK Connect).
-  - Subscriptions sollen nur von System gelesen werden können, das sie geschrieben hat.
-1. Es SOLL ein Recovery-Mechanimus eingeführt werden (dieser SOLL über den Business-Identifier umgesetzt werden), um den Fall einer fehlgeschlagenen Notification abzufangen.
+    - Subscriptions sollen nur von System gelesen werden können, das sie geschrieben hat.
+1. Es SOLL ein Recovery-Mechanismus eingeführt werden (dieser SOLL über den Business-Identifier umgesetzt werden), um den Fall einer fehlgeschlagenen Notification abzufangen.
 1. Vorgaben zum eigentlichen Patient-merge-Workflow werden im Rahmen der Ausbaustufe 4 nicht oder nur bedingt festgelegt.