From 42f77dab6441c8f2e67c04c197aed04f3bbd8ef4 Mon Sep 17 00:00:00 2001 From: patrick-werner Date: Wed, 28 Feb 2024 08:52:36 +0100 Subject: [PATCH] fix: applied changes from PR review --- .../markdown/Subscription/Subscription_Motivation.md | 5 +++-- .../UebergreifendeFestlegungen_Patient-merge.md | 4 ++-- .../resources/StructureDefinition-ISiKPatient.json | 3 ++- Resources/input/fsh/ISiKPatient.fsh | 3 ++- 4 files changed, 9 insertions(+), 6 deletions(-) diff --git a/ImplementationGuide/markdown/Subscription/Subscription_Motivation.md b/ImplementationGuide/markdown/Subscription/Subscription_Motivation.md index f23be482..dd36a213 100644 --- a/ImplementationGuide/markdown/Subscription/Subscription_Motivation.md +++ b/ImplementationGuide/markdown/Subscription/Subscription_Motivation.md @@ -1,7 +1,8 @@ ## Motivation -Duplizierte Patientendatensätze innerhalb eines patientenführenden Systems treten im betrieblichen Alltag immer wieder auf. Diese Duplikate werden nach dem Bekanntwerden auf ein Patientenobjekt zusammengeführt (gemerged). +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. -Um als Subsystem über ein Patienten-Merge-Event informiert zu werden, wird der FHIR Subscription Mechanismus gemäß der FHIR R5 Spezifikation genutzt. +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. --- diff --git a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Patient-merge.md b/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Patient-merge.md index 061b18fc..ac8296e8 100644 --- a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Patient-merge.md +++ b/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Patient-merge.md @@ -58,11 +58,11 @@ Das patientenführende System MUSS den Support dieser Subscription inneralb des ## Client-System **REQ_BAS_PAT-MER-021**: Client-Systeme MÜSSEN den Status einer gecachten Patienteninstanz vor der Interaktion mit einem patientenführenden System per READ auf das Patientenobjekt überprüfen. -Sollte das Patientenobjekt nicht mehr bereitstehen, oder hat den status `active=false` muss das Patientenobjekt mittels Suche auf einen bekannten & stabilen Identifier neu geladen werden. +Sollte das Patientenobjekt nicht mehr bereitstehen, oder hat den status `active=false` kann das Patientenobjekt mittels Suche auf einen bekannten & stabilen Identifier neu geladen werden. ## Datensicherheit -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 Authorization-Header an den Enpunkt zu übertragen. +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) ### Websocket diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKPatient.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKPatient.json index 83b97c56..bbbe22bf 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKPatient.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKPatient.json @@ -622,7 +622,7 @@ { "id": "Patient.link", "path": "Patient.link", - "comment": "Dieses und untergoerdnete Elemente MÜSSEN bei einem erfolgten Patient merge entsprechend der Festlegungen im Implementation Guide befüllt werden.", + "comment": "Dieses und untergeordnete Elemente MÜSSEN bei einem erfolgten Patient merge entsprechend der Festlegungen im Implementation Guide befüllt werden.", "mustSupport": true }, { @@ -633,6 +633,7 @@ { "id": "Patient.link.other.identifier", "path": "Patient.link.other.identifier", + "comment": "Logischer Verweis auf Identifier[Patientennummer]", "mustSupport": true }, { diff --git a/Resources/input/fsh/ISiKPatient.fsh b/Resources/input/fsh/ISiKPatient.fsh index 8e2c2655..0976b14a 100644 --- a/Resources/input/fsh/ISiKPatient.fsh +++ b/Resources/input/fsh/ISiKPatient.fsh @@ -105,9 +105,10 @@ Description: "Dieses Profil beschreibt die Nutzung von administrativen Patienten * postalCode 1.. MS * country 1.. MS * link MS - * ^comment = "Dieses und untergoerdnete Elemente MÜSSEN bei einem erfolgten Patient merge entsprechend der Festlegungen im Implementation Guide befüllt werden." + * ^comment = "Dieses und untergeordnete Elemente MÜSSEN bei einem erfolgten Patient merge entsprechend der Festlegungen im Implementation Guide befüllt werden." * other MS * identifier MS + * ^comment = "Logischer Verweis auf Identifier[Patientennummer]" * type MS Instance: PatientinMusterfrau