Priorisierung der Bedarfe für Patient merge

[f-peverali]

Für die Identifikation und Priorisierung von Bedarfen rund um das Thema 'Patient merge' wollen wir gerne die Meinungen möglichst vieler Stakeholder aus der Community einholen. Daher hier eine Abstimmung zur Erhebung eines Meinungsbilds.

Die unten gelisteten Optionen spiegeln die Bedarfe im Konzept Draft wieder.

Falls weitere Bedarfe bestehen, bitte entsprechend direkt hier als Kommentar einbringen.

[patrick-werner]

Wie gehen wir damit um wenn der inform nicht alle relevanten Systeme erreicht (bspw. Netzwerk down)?
Vorschlag:
Zusätzlich zum inform werden patient.link beider Patientobjekte gesetzt, und der nicht mehr gültige Patient auf active = false gesetzt

[KaiMindermann]

@markus020 : würdest Du es denn für vertretbar halten, bei einem Request zu einer Patientenressource, die gemerged wurde und bei Euch nicht mehr in der aktuellen DB vorhanden ist, vor dem Liefern der 404-Response in die Provenance reinzuschauen und dann eine synthetisierte Patientenressource mit dem patient.link auf den neuen Patienten zu liefern? Wäre sicherlich keine perfekte Lösung, aber vielleicht ein inhaltlich und wirtschaftlich vertretbarer Kompromiss.

[patrick-werner]

Vielen Dank für ihren Input @KaiMindermann
Ich verstehe den Wunsch nach guaranteed delivery Optionen, aber selbst in R5 wird sich so darauf bezogen:

Unless otherwise specified by a server implementation and channel, the Subscriptions Framework does not involve guaranteed icon delivery of notifications; channels are assumed to be simple best-effort icon unless otherwise specified. While the Subscriptions Framework is able to support such mechanisms, defining channels using them is beyond the scope of the standard at this time.
https://hl7.org/fhir/subscriptions.html#overview-notification

Custom Channel definitionen könnte man nutzen um guaranteed delivery channels erzeugen zu können. Nur sind wir hier dann außerhalb der Definition des backport IGs oder des R5 Standards, also weniger interoperabel. Und außerhalb heutiger erhältlicher Softwarelösungen.
Ein sehr spannendes Thema, ich freue mich auf den Austausch im nächsten AK Meeting und weitere Meinungen hier im Issue.

[markus020]

@KaiMindermann: Aus KIS-Sicht wäre das eher suboptimal aus insbesondere folgenden Gründen:

1. i.d.R. gibt es für den Zugriff auf archivierte Daten gesonderte und stark eingeschränkte Regelungen. Diese würden damit faktisch außer Kraft gesetzt, indem quasi eine Hintertüre geschaffen wurde.
2. das KIS müsste hier prüfen, weshalb die Ressource nicht mehr vorhanden ist (Möglichkeit wäre u.a. Umsetzung von DSGVO-Forderungen) und dann anhand einer nur hierfür umzusetzenden Berechtigungslogik die Ressource freigeben
3. das (ohnehin schon sehr komplexe) Berechtigungsmanagement müsste erweitert werden. Hier ist die Frage, ob das Subsystem anhand der Berechtigungen vor dem Löschen ein Zugriff gewährt werden kann oder, ob hier anderweitige Rechte eingeführt werden müssen.

Insgesamt würde ich das nicht als praktikable Lösung sehen.

[KaiMindermann]

@markus020 : vielen dank für die detailreiche Information. Dass das aus Entwicklungssicht nicht optimal ist, ist auf jeden Fall klar. Die Kernfrage aus meiner Sicht ist, wie hoch man den Grad der Interoperabilität - also der nahtlosen Zusammenarbeit der Systeme - ansetzt und fehlende Interoperabilität (also Nahtstellen, die vom Anwender kompensiert werden müssen) auf Akzeptanz stößt und damit zu welchen Kompromissen alle Parteien bereit sind.

[KaiMindermann]

@patrick-werner : ich habe die Frage nach guaranteed delivery channel gestern Abend in einer Q&A an Gino Canessi richten können. Aus seiner Sicht sind guaranteed delivery channels Bestandteil des backport IGs und eben eine der beiden Tode, die man sterben kann... Entweder best-effort mit serialisierter Eventid und der Client muss fehlende Events detektieren und nachholen oder guaranteed notification und dann eben mit etwas mehr Aufwand in der Pub/Sub Verwaltung beim Server.