Open c-schelian opened 9 months ago
patrick-werner
commented
9 months ago Dies wird aktuell in der AG patient-merge bereits als use-case diskutiert. Aktueller Stand der AG: merge ist eine Sache des Primärsystems, eine Vorgabe wie ein merge getriggert wird ist aktuell out-of-Scope, es soll aber der Topic based Subscription Ansatz aus R5 (subscription-backport) mit einem patient-merge Topic spezifiziert werden.
c-schelian
commented
9 months ago In der AG wird der Patientenmerge besprochen und nicht der Fallmerge. Ich muss als Subsystem mitbekommen ob a) ein Patientenmerge passiert ist (das wird gerade in AG patient-merge diskutiert) und b) ob ein Fallmerge passiert ist (nicht um einen durchzuführen). Grund ist: Das Subsysteme auch Daten auf Fallnummerebene speichern und somit das Subsystem mitbekommen bzw. abfragen können muss welche Fallnummer hatte den Patient.
f-peverali
commented
7 months ago @c-schelian danke nochmal für den Input. Wir tracken das intern (PTDATA-980) und würden das in den AGs für Stufe 5 nochmal ansprechen.
Target Date
No response
Implementation PR
No response
Reference Issues
No response
Summary
Fallmerge implementieren um HL7 Schnittstellen komplett ersetzen zu können, um den Datenaustausch für Fremdsystem nur über ISiK stattfinden zu lassen. Fallmerge sind für die Praxis relevant und passieren regelhaft.
Common Examples
Use Case siehe HL7 A42 https://wiki.hl7.de/index.php/Korrekturen_von_Identifikatoren#Zusammenf.C3.BChrung_zweierF.C3.A4lle.28Event_A42.29
Als Lösungsidee: Analog der Lösungsidee Patientmerge ein Link-Property, mit Link-Typen (u.a.) replaces und replaced-by. Diese Lösungsidee könnte man auch bei Encounter und Account nutzen.
Drawbacks
Keine
Unadressed questions
No response