Stream: german (d-a-ch)
Topic: Medikationsplan PLUS: Links zwischen "Nachfolger-Documents"?
Morten Ernebjerg (Nov 26 2018 at 14:52):
Bei der Bundereinheitliche Medikationsplan in Papierformat sind (wenn ich das richtig verstehe) aufeinanderfolgende Pläne unabhängig; ein neuer Papierplan ersetzt alle ältere Pläne. Wie in diesem Thread diskutiert, könnte man das mit Medikationsplan PLUS in FHIR nachbilden, in dem man jeden neuen Plan (qua Bundle) POSTet. Dass ist auch im Einklang mit der generellen Regel für FHIR Documents, dass der Inhalt eines bestimmten Dokuments nie substantitiell geändert werden darf (was ja bei Medikationspläne meistens passiert).
Wenn man aber immer POST macht (im Gegensatz zu PUT), hat man keine Verbindung mehr zwischen aufeinenanderfolgenden Pläne (Historie), genau wir bei ausgedruckten BMP-Plänen. In der elektronischen Welt möchte man aber vielleicht z.B. gerne von einem Med-Plan zum Vorgängerplan navigieren. Oder nach Plänen, die in einem bestimmten Zeitraum erstellt wurden, suchen, und dann wissen, welcher Plan am Anfang vom Zeitraum gültig war (also der Vorgänger vom ersten Plan, der von der Suche zurückkam).
Daher meine Frage (endlich :smile:): Gibt es schon Extensions für Composition, womit man FHIR Documents miteinander verlinken kann, und so z.B. auf einen "Vorgänger" zeigen kann? Was ich damit gerne kommunizieren würde wäre: "Als dieser MPP-Plan erstellt wurde, war der folgende Plan gültig (wurde aber durch mich ungültig gemacht)". Oder gibt es vielleicht ganz andere Ansätze?
Stefan Lang (Nov 26 2018 at 17:47):
Interessante Frage.
Eigentlich wäre dafür Composition.relatesTo gedacht, mit relatesTo.code=replaces (oder transforms) und targetReference auf die "veraltete" Composition.
Ich bin aber gerade nicht sicher, ob eine Referenz auf eine Composition, die ausschließlich in einem Bundle existiert, zulässig ist.
Stefan Lang (Nov 26 2018 at 17:49):
Wobei beim MPP ja durchaus auch gedacht war, die Ressourcen aufzulösen, dann wäre das kein Thema.
Morten Ernebjerg (Nov 27 2018 at 14:38):
Guter Punkt, das hatte ich irgendwie übersehen! Aber könnte man nicht die Composition, auf der man verweist, mit in das Bundle aufnehmen? Oder, als alternative, könnte man nicht relatesTo.targeIdentifierbenutzen und damit auf eine Compositionverweisen, auch wenn sie in einem Bundle"eingeschlossen" ist? Ich hätte eigentlich gedacht (gehofft), dass die Persistenzmethode für Bundles nicht darüber entscheidet, ob man auf andere Bundles verweisen kann oder nicht.
Eigentlich frage ich mich, ob man nicht immer eine zweiteComposition, auf der man so verweist, in das Bundle aufnehmen müsste, denn die Doku für FHIR Documents (STU3) sagt ja:
Any resource referenced directly in the Composition SHALL be included in the bundle when the document is assembled.
und das würde ja eigentlich auf ein Referenz in relatesTozutreffen. Allerdings gibt es gleich danach einen Liste von allen relevanten Feldern und da ist relatesTonicht drauf:
Specifically, this means the following resource references:
- Composition.subject
- Composition.encounter
- Composition.author
- Composition.attester.party
- Composition.custodian
- Composition.event.detail
- Composition.section.entry
Other resources that these referenced resources refer to may also be included in the bundle if the document construction system chooses to do so.
Stehe ich auf dem Schlauch oder wiederspricht die Doku sich selbst hier?
Stefan Lang (Nov 27 2018 at 18:07):
Ich denke, das Ziel von relatesTo (also die "alte" Composition) aufzunehmen, widerspricht ein wenig der Idee, mit Document-Bundles die Strukturen von (CDA-)Dokumenten zu repräsentieren.
Ist aber sicher eine kurze Frage im Implementers-Chat wert, und wahrscheinlich auch einen Tracker zur Clarification.
Simone Heckmann (Nov 28 2018 at 06:58):
Hallo, hier meine 5ct zu diesem Thema:
Würde man ein FHIR-Repository dazu verwenden, Dokumente nur als unveränderliches Ganzes, also als Bundles zu persistieren, hätte man keinerlei Such-Funktionen über die API. Die Dokumente sind damit ungefähr genau so nützlich wie PDFs. Um die Bundles sinnvoll (im Sinne von FHIR) verwalten zu können, müsste man zu jedem eine DocumentReference-Ressource erstellen, die die Metadaten zu dem Dokument enthält (ählich wie man das in XDS mit dem ebXML zu einem CDA macht). Über die DocumentReference könnte man dann nach bestimmten Dokumenten suchen und auf sie zugreifen. Die DocumentReference hat auch die Möglichkeit, über einen relatesTo-Link auf ein vorhergehendes Dokument zu verweisen. Das Bundle mit dem Inhalt würde man über content.attachment referenzieren.
Zweite Möglichkeit: Man packt die Ressourcen aus (so wie wir das momentan au dem Testserver tun) und hat damit volle Such- und Zugriffsmöglichkeiten. Sinnvoll wäre indiesem Zusammenhang, das Original-Bundle ebenfalls zu speichern und über eine Provenance mit den daraus extrahierten Einzel-Ressourcen zu verknüpfen. Dann hat man beides: flexibel nutzbare Daten und unveränderliche Dokumente. Aber auch 100% Redundanz.
Ich schätze, jeder Medikatinsplan-Annahme-Server muss für sich selbst - und abhängig vom UseCase - entscheiden, ob er ein Dokumenten- oder ein Daten-Repository sein will...
Dass das Ziel eines relatesTo-Links einer Composition nicht in einem Document-Bundle enthalten sein muss ist m.E. richtig. Denn das Ziel hätte ja auch wiederum direkt verlinkte Ressourcen, die dann auch mitverpackt werden müssten und dann hätte man jedes mal die komplette Historie bis Adam und Eva in jedem Bundle.
Stefan Lang (Nov 28 2018 at 11:34):
Die zweite Möglichkeit ist ja eigentlich beim MPP die Intention (s.o. "... auch Ressourcen aufzulösen ...").
Via DocumentReference ist natürlich machbar, aber IMHO irgendwie von hinten durch die Brust ins Auge.
Morten Ernebjerg (Nov 29 2018 at 08:53):
Danke für Euren Input!
@Stefan Lang Jou, da werde ich mal nachfragen.
@Simone Heckmann Ja, einen "dumb Bundle" ist sicherlich nicht viel Wert. Anderseits ist das komplette Auseinandernehmen & Weiderzusammenbauen natürlich auch komplitziert (und ggf. redundant), und in unserem Fall brauchen wir z.B. keinen Zugriff oder Suche auf Einzelresources aus dem Plan. Wie Du ja sagst muss man sich das gut überlegen, ich habe da auch viel Zeit versenkt (und bin noch nicht ganz am Ziel...).
Eine dritte Möglichkeit - die auch in der Doku zu FHIR Documents erwähnt wird - ist ja auch, dass man (teilweise) die Dokumente über eigene FHIR Operations (oder vielleicht Custom-Search) sucht/bearbeitet. Da geht man zwar über die vordefinierte FHIR-Elemente hinaus, was natürlich die "offene Interoperabilität" einschränkt. Anderseits kann man aber sehr gezielt die Workflows für einen bestimmten Usecase unterstützen, was ja auch für die Clients eine erhebliche Erleichterung sein kann, besonders wo sehr genaue und komplizierte Business-Logik involviert ist.
Und stimmt, noch einen Composition im Bundle würde ja szs. zu einem Babuschka-Bundle führen - lieber nicht machen :smile:
Morten Ernebjerg (Nov 29 2018 at 09:05):
BTW, habe gerade gesehen, dass in der R4 Doku der verwirrende Satzt zu "directly referenced Resources" weg ist.
Stefan Lang (Nov 29 2018 at 09:10):
Was man mit Dokumenten und eigenen Operations treibt ist natürlich jedem selbst überlassen (dafür gibt's ja frei definierbare Operations).
Man sollte nur darauf achten, die Funktionalitäten der RESTful API nicht via dieser Operations noch einmal komplett abzubilden ;-)
"Babuschka-Bundle" trifft es sehr gut :joy:
Stefan Lang (Nov 29 2018 at 09:13):
Der "directly referenced"-Satz steht doch auch noch in R4?
Morten Ernebjerg (Nov 29 2018 at 09:14):
Nee, der ist Weg, jetzt gibt es nur eine Liste von Felder, für die man referenzierte Resources inkludieren muss (und relatesToist nicht auf dieser Liste)
Stefan Lang (Nov 29 2018 at 09:16):
Copy & Paste von http://build.fhir.org/documents.html
"Any resource referenced directly in the Composition SHALL be included in the bundle when the document is assembled. Specifically, this means the following resource references: "
Oder was meinst Du?
Morten Ernebjerg (Nov 29 2018 at 09:17):
ahh... ich war bei der Doku für Composition und da steht jetzt nur eine Liste.
Stefan Lang (Nov 29 2018 at 09:17):
Hehe, Konsistenz is an issue :D
Morten Ernebjerg (Nov 29 2018 at 09:17):
Gut das Du das bemerkt hast, ich schreibe gerade die Frage für implementers
Morten Ernebjerg (Nov 29 2018 at 09:36):
Frage in Implementer-Stream is hier.
Patrick Werner (Nov 29 2018 at 10:37):
[bundle]#[id] where bundle is the url of the bundle, and id is the id of the composition resource
Ich hatte den fragment identifier gar nicht auf dem Schirm, gut zu wissen und danke fürs nachfragen.
Stefan Lang (Nov 29 2018 at 11:03):
Dito. Wieder was gelernt!
Patrick Werner (Nov 29 2018 at 11:16):
ist sogar in DSTU3 enthalten, aber nur in der beschreibung von URI :-)
Morten Ernebjerg (Nov 29 2018 at 12:09):
Da musste ich auch erst mal schnell nachlesen... Aber ist das eindeutig? - teoretisch könnten ja zwei unterschiedliche Resources unterschiedlichen Typs im Bundle die gleiche ID haben.
Patrick Werner (Nov 29 2018 at 13:23):
IDs sollten immer unterschiedlich sein, explizit finde ich das aber nicht. Man könnte es ableiten aus:
bdl-7: FullUrl must be unique in a bundle, or else entries with the same fullUrl must have different meta.versionId (except in history bundles)
und bei details der FullURl: The Absolute URL for the resource. The fullUrl SHALL NOT disagree with the id in the resource
Patrick Werner (Nov 29 2018 at 13:25):
eine ID kann zudem den Type enthalten, also Patient/123
Stefan Lang (Nov 29 2018 at 13:51):
Für die Referenz ins Bundle rein ist es damit eindeutig.
Ob IDs global unique sein sollten, darüber kann man heftig diskutieren - darf aber nicht davon ausgehen, dass es so ist.
Patrick Werner (Nov 29 2018 at 13:55):
was wenn man keine FullUrls hat, aber IDs?
Stefan Lang (Nov 29 2018 at 13:57):
Hm, dann autsch ... hast Recht.
Morten Ernebjerg (Dec 13 2018 at 11:25):
Kleiner Nachtrag: Mir ist gerade aufgefallen, dass Composition.relatesTo in MPP gar nicht erlaubt ist, darüber kann man also nicht verlinken. Wisst Ihr, warum es rausgenommen wurde (im Profil selber steht leider kein Kommentar dazu)?
Simone Heckmann (Dec 13 2018 at 17:16):
Hallo Morten,
im MPP wurde leider die etwas unglückliche Entscheidung getroffen, alles was im Datenmodell nicht vorgesehen ist zu verbieten, was es im Prinzip unmöglich macht, neue Features hinzuzufügen.
Aber mach doch bitte ein Issue ins GitHub des MPPs, damit der Ansatz überdacht werden kann...
Morten Ernebjerg (Dec 14 2018 at 09:18):
Hi Simone, wir haben genau damit zu kämpfen für unseren Usecase, habe gerade Gestern lange drüber nachgedacht. Ich hoffe, dass unsere Erfahrungen vielleicht auch für die Weiterentwicklung interessant sein könnten, da können wir gerne was mitbringen & einbringen. Ich mache erstmal einen Issue auf.
Morten Ernebjerg (Dec 14 2018 at 12:18):
GitHub issue #62
Simone Heckmann (Dec 14 2018 at 15:48):
@dr Kai U. Heitmann
Simone Heckmann (Dec 14 2018 at 15:48):
@Julian Sass
Last updated: Apr 12 2022 at 19:14 UTC
