Stream: german (d-a-ch)
Topic: Status Medikationsplan PLUS auf Simplifer
Morten Ernebjerg (Jun 22 2018 at 08:54):
Hi,
ich habe gesehen, dass Mitte Mai sehr viel im SIMPLIFIER repo von Medikationsplan PLUS geändert wurde. So ist zum Biespiel auch nur ein Resource-Beispiel übrig geblieben. Weisst jemand, ob da gerade eine größere Umstrukturierung/Update im Gange ist, und wenn ja, mit welchem Zeithorizont? Ich konnte leider in Köln nich dabei sein, und habe so vielleicht einiges verpasst...
Simone Heckmann (Jun 22 2018 at 13:27):
Hallo Morten,
ja, wir haben mitte Mai am Aufbau des Testservers für den Medikationsplanplus gearbeitet und dabei noch einige kleinere Fehler an den Profilen festgestellt und behoben. Beispiele findest du reichlich auf http://fhir.hl7.de:8080/
Simone Heckmann (Jun 22 2018 at 13:29):
Es gibt noch ein paar offene Punkte, die kannst du in unserem Issue-Tracker nachlesen: https://github.com/hl7germany/medikationsplanplusplus/issues
(oder neue dazutun, wenn du welche findest ;-) )
Morten Ernebjerg (Jun 25 2018 at 08:58):
Hi Simone
super, danke! Ich bin schon am reinschauen :)
Morten Ernebjerg (Jun 25 2018 at 11:51):
@Simone Heckmann Bonus-Frage - sag Bescheid, wenn ich sie lieber in einem neue Topic unterbringen sollte :) Gibt es auch vorgeschriebene Workflows, die Erstellung und Aktualisierungen für einen Medikationsplan Plus (via HTTP) beschreiben? Inbesonders interessiert mich, wie man am besten einen MedPlan qua FHIR Document aktualisiert, zumal es ja keinen einfachen PUT für Documents gibt. Ich vermute , für Klient-Systeme wäre es am einfachsten, den neuen Plan als Document Bundle zu POSTen, dann hätte man aber mehrere parallele Pläne pro Patient im System (oder man müsste extra die alten Pläne entfernen/invalidieren). Anderseits, wenn man nur die Composition aktualisieren würde und ggf. neue Resources einzeln hinzufügen, müssten Klient-Systeme immer einen "Diff" machen , die Richtige referenzen für ggf. schon bestehende Medication/MedicationStatement raussuchen usw., und man hätte nicht die "einfache Integrität" eines Document-Bundles. Oder übersehe ich da schönere Alternativen?
Patrick Werner (Jun 27 2018 at 12:09):
spannende Frage welche wir auch in Köln während des Connectathons diskutiert hatten.
Patrick Werner (Jun 27 2018 at 12:14):
qua document aktualisieren ist noch der einfache Fall, hier würde ich das Dokument immer per PUT ersetzen. Der Endpunkt für DocumentBundles ist {base}/Bundle
Patrick Werner (Jun 27 2018 at 12:20):
Was wir für Köln in HAPI ergänzt hatten war die $document operation. Hier hat man alle resourcen einzeln auf dem Server (was den Vorteil der deutlich besseren durchsuchbarkeit hat). Sobald man dann ein document Bundle benötigt word dieses anhand der COMPOSITION resource erstellt
Patrick Werner (Jun 27 2018 at 12:20):
Hier ist ein Update dann ein Update der "beteiligten" resourcen
Patrick Werner (Jun 27 2018 at 12:21):
Angenommen man hat aber resourcen einzeln auf einem Server, und möchte diese mit einem document bundle aktualisieren wird es kompliziert.
Patrick Werner (Jun 27 2018 at 12:22):
Man könnte aus dem Document Bundle eine Transaction Bundle machen und hier jeweils einzelUpdates generieren.
Morten Ernebjerg (Jun 28 2018 at 13:37):
Hi Patrick,
danke, dann ist es vielleicht einfacher, als ich dachte! Ich hatte von der Doku zu FHIR Documents den Eindruck gekriegt, dass ein ganzes Document Bundle nicht einfach aktualisiert werden darf, da steht ja z.B. (v3.0.1.):
Once assembled into a bundle, the document is immutable - its content can never be changed, and the document id can never be reused. (...) Any additional documents derived from the same composition SHALL have a different document id.
Heisst dass denn nur, dass ein Document Bundle durch einen PUT auf [base]/Bundle aktualisieren darf, solange man den Bundle Identifier auch ändert (ich nehme an, dass das die "document id" vom Zitat oben ist)?
Stefan Lang (Jun 28 2018 at 16:03):
Ich denke, das entscheidende ist der wegglassene Satz im Zitat: "However, the directly referenced content within the document and the presentation of the document cannot change substantially (such that it changes the clinical meaning of the content)"
Das ist vor allem eine fachlich-inhaltliche Aussage. Erlaubt im Umkehrschluss durchaus ein update (mit nicht-substanziellen Changes), und das wird wie überall anders auch als PUT [base]/Bundle/[id] ausgeführt.
Infos dazu hat Abschnitt 2.23.4 in https://www.hl7.org/fhir/documents.html#bundle : "This works like a normal end-point for managing a type of resource, but it works with whole document bundles - i.e. a read operation returns a bundle, an update gets a bundle and a search returns a bundle of bundles. Note that if documents are POSTed using a create interaction the Bundle.id will change, but the Bundle.identifier will not"
Die genannte "document id" hat nichts mit Bundle.identifier zu tun - "id" ist immer der systeminterne Identifikator. "identifier" ist ein Business Identifier. Der würde beim PUT natürlich den Wert erhalten (oder behalten), der im gePUTteten Bundle steht.
Würde man das geänderte Bundle POSTen, ohne den identifier zu ändern, hat man hinterher zwei Bundle-Ressourcen mit unterschiedlicher id, aber identischem identifier. Und zwar unabhängig davon, ob im gePOSTeteten Bundle ein id-Element enthalten ist, die wird beim POST verworfen.
Stefan Lang (Jun 28 2018 at 16:08):
Inwiefern das "SHALL have a different document id" technisch erzwingbar ist, sei mal dahin gestellt.
Zumindest müsste der Server dann bei einem PUT wissen, welche Änderungen substanziell sind und welche nicht. Das ist zumindest anspruchsvoll.
Morten Ernebjerg (Jun 29 2018 at 11:14):
Hi Stefan,
danke, dass klärt einiges auf! Für einen Medikationsplan würde ich eigentlich davon ausgehen, dass die meisten Änderungen substanziell sein werden (oder mindestens, dass man sicherheitshalber diese Annahme machen muss) - er kann ja vom Arzt komplett umgekrempelt werden. Das hiese dann, wenn ich das richtig verstehe, dass man eigenlicht immer Bundle POST machen muss (ggf. mit den gleichen Identifier), obwohl es - konzeptuell gesehen - immer noch der gleiche Medikationsplan ist. Ich glaube, es ist eben dieser Kontrast, was mich etwas verwirrt hat: Ein MedPLan kann beliebig geändert werden und doch "sich selbst" bleiben, ein Document eher nicht.
Stefan Lang (Jun 29 2018 at 12:43):
Ob es nach einer substanziellen Änderung noch "der selbe" ist, kann man glaube ich ausgiebig diskutieren ;-)
Auf jeden Fall bildet der Unterschied zwischen id und identifier das ganz gut ab.
Morten Ernebjerg (Jun 29 2018 at 12:53):
War so mein Bauchgefühl (und aus meinem Kontext gesehen), die existentielle Fragen sind nie einfach :) Aber mit der Interpretation, dass die Identität vom MedPlan am Identifier hängt, kann ich auch gut leben.
Patrick Werner (Jun 29 2018 at 15:36):
Beim persönlichen papier-gebundenen Medikationsplan wird ja pro Änderung neu ausgedruckt und der alte verworfen.
Ich denke auch man muss hier grundlegend Unterscheiden zwischen Dokument und Informationen. Wenn ich einen FHIR Server habe der immer den aktuellen Zustand meiner Patienten wiederspiegelt würde ich den Identifier nicht ändern, und immer Updaten (Identifier hier ggfs. = PatID).
Da ein Dokument ein Zustand zu einem Zeitpunkt beschreibt würde ich hier immer neue Pläne POSTen. (Wobei man auch argumentieren könnte PUT zu nehmen, da per history alle Zeitpunkte verfügbar wären). Wie Stefan schon schrub, darüber kann man prima länglich diskutieren.
Simone Heckmann (Jul 01 2018 at 15:03):
(deleted)
dr Kai U. Heitmann (Jul 01 2018 at 21:25):
Zur Migration "Medikationsplan PLUS" hin zu tatsächlich FHIR-gerechter Medikations-Dokumention und -Versorgung wird es in Kürze ein Whitepaper geben, welches in Vorbereitung ist und die verschiedenen Aspekte beleuchtet..
Morten Ernebjerg (Jul 02 2018 at 12:32):
@Patrick Werner Guter Punkt (Dokument vs Info), damit kann man das etwas klarer beschreiben. Ich tenderiere jetzt auch zu POSTen.
@dr Kai U. Heitmann Spannend, da freue ich mich drauf! Wo wird es erscheinen?
Last updated: Apr 12 2022 at 19:14 UTC
