Stream: german (d-a-ch)
Topic: Medikationsplan Plus $document
Alexander Zautke (Sep 09 2018 at 16:14):
Hallo zusammen, ich bin gerade dabei $document als ein Plug-In für Vonk zu implementieren.
Als Beispiel hatte wollte ich einfachheitshalber einen Medikationsplan Plus erzeugen. Hierbei stellt sich mir jedoch gerade die Frage, was passiert, sollte eine Resource, die inkludiert werden soll, nicht verfügbar sein. Soll nur ein Hinweis als OperationOutcome zum Bundle hinzugefügt werden? Wird die gesamte Operation abgebrochen? Leider geht dies nicht für mich aus der Definition von $document hervor. Gibt's diesbezüglich Meinungen?
Patrick Werner (Sep 09 2018 at 18:03):
Sehr guter Gedanke. Ich habe bei HAPI damals einfach nur alles inkludiert was verfügbar ist. Dies nochmals gegen Composition abzugleichen ist aber eine sehr gute Idee.
Sollte eine Resource nicht verfügbar sein würde ich die komplette Operation mit 500 abrechen da das Dokument nicht (komplett) erstellt werden kann, und die Ursache ins OperationOutcome packen.
Stefan Lang (Sep 09 2018 at 18:38):
Fehlende direkt referenzierte Ressourcen sind auf jeden Fall ein Error:
"Any resource referenced directly in the Composition SHALL be included in the bundle when the document is assembled."
http://build.fhir.org/documents.html
Stefan Lang (Sep 09 2018 at 18:39):
Das steht zwar nicht direkt bei der Spec der $document-Operation, ist aber ziemlich eindeutig.
Stefan Lang (Sep 09 2018 at 18:45):
Auf einem produktiven Server macht man sich natürlich schon Gedanken, wie man referentielle Integrität wahren kann. Auf einem Testserver wird das aber eher hinderlich.
Simone Heckmann (Sep 10 2018 at 06:34):
Hallo,
da wir ja beim Medikationsplan immer noch davon ausgehen, dass die Dokumente immer „als ganzes“ auf einen Server gepostet oder von einem Server abgerufen werden, und keine Möglichkeit zur Löschung einzelner Ressourcen vorgesehen ist, muss es schon mit seltsamen Dingen zugehen, wenn eine einzelne Ressource einfach verschwindet. In so fern sehe ich das ebenfalls als harten Fehler, der zu einem Abbruch der Transaktion führen sollte.
Genau so würde ich auch das Posten eines Bundles auf einen Medikationsplan-Server als Ganz-oder-Gar-nicht-Transaktion sehen.
Alexander Zautke (Sep 10 2018 at 08:51):
Super, vielen Dank für die Hinweise. HAPI hat die tolle Eigenschaft, dass es möglich ist zu bestimmen, dass eine Ressource nicht gelöscht werden kann, sollte eine Composition noch darauf verweisen. Bei Vonk kann ich dies nicht so direkt einstellen. Daher kamen meine Überlegungen, was passiert sollte jetzt doch mal eine Resource nicht mehr vorhanden sein.
Da, wie oben zitiert, nur direkt referenzierte Ressourcen mit einem SHALL versehen sind, gehe ich dann richtig davon aus, dass für alle weiteren indirekt referenzierten aber nicht vorhandenen Ressourcen nur eine Warning mit ins Bundle gepackt werden soll? Also z.B. im Falle eines MedicationStatements welches durch eine List referenziert wird.
Stefan Lang (Sep 10 2018 at 16:34):
@Simone Heckmann Transaktionen sind per definitionem immer "ganz oder gar nicht", sonst wären sie in FHIR-speak ein batch.
Hier haben wir aber ein document, das sowieso (als Bundle an [base]/Bundle gesendet) "ganz oder gar nicht" ist ;-)
@Alexander Zautke Die Spec sagt dazu, dass das der Server entscheidet ...
Im konkreten Fall des Medikationsplans wäre es wohl ziemlich sinnbefreit, die List ohne MedicationStatement zu schicken ;-)
In anderen Fällen kann das natürlich durchaus sinnvoll sein
Alexander Zautke (Sep 10 2018 at 18:05):
Schreit das nicht förmlich danach eine Option für die Operation einzuführen? Entweder als Element in der OperationDefinition oder als Parameter in der URL. Und sei es nur für die es nur für diese spezielle Medikationsplan-Operation?
Alexander Zautke (Sep 10 2018 at 18:06):
Sodass der Client sagen kann, dass in einem bestimmten Use Case es keinen Sinn macht, wenn der Server selbst bestimmen kann?
Alexander Zautke (Sep 10 2018 at 18:11):
Klar sehe ich auch, dass es überhaupt keinen Sinn macht, nur dass es theoretisch valide ist die Operation nicht abzubrechen sollten die Medication Statements nicht vorhanden sein. Ich würde es nur irgendwie "schöner" finden, wenn man das Verhalten vorgeben würde. Und sei es beispielsweise als Extension auf OperationDefinition.
Stefan Lang (Sep 10 2018 at 20:16):
Es ist valide im Sinn der FHIR Core-Spezifikation. In den MPPlus würde genau diese Ergänzung ganz sicher mit reingehören; so wie insgesamt eine Beschreibung der API. Sprich: eigentlich muss da genau Deine OperationDefiniton "$documentWithAllChildren" oder vielleicht "$document?fullRecursion=true" hin.
Sollte man das in den implementers-Stream werfen? Ich denke schon, dass so ein IN-Parameter für die 80% sinnvoll wäre.
Patrick Werner (Sep 11 2018 at 09:52):
+1 $document sollte beide Modi beherrschen, per Parameter gesteuert. @Alexander Zautke wirfst du das Thema nach nebenan in den Implementers?
Simone Heckmann (Sep 12 2018 at 07:49):
FYI: es gibt einen fhir/documents-Stream: https://chat.fhir.org/#narrow/stream/97-fhir.2Fdocuments
Simone Heckmann (Sep 12 2018 at 07:53):
@Simone Heckmann Transaktionen sind per definitionem immer "ganz oder gar nicht", sonst wären sie in FHIR-speak ein batch.
Hier haben wir aber ein document, das sowieso (als Bundle an [base]/Bundle gesendet) "ganz oder gar nicht" ist ;-)
Post an [base]/Bundle würde bedeuten, dass das Bundle als solches persistiert und nicht aufgesplittet wird. In diesem Fall brauchen wir uns über $document gar keine Gedanken machen, da es auf dem Server keine Compositions gibt, nur Bundles...
Simone Heckmann (Sep 12 2018 at 07:56):
Es ist valide im Sinn der FHIR Core-Spezifikation. In den MPPlus würde genau diese Ergänzung ganz sicher mit reingehören; so wie insgesamt eine Beschreibung der API. Sprich: eigentlich muss da genau Deine OperationDefiniton "$documentWithAllChildren" oder vielleicht "$document?fullRecursion=true" hin.
Das wird ja eigentlich über den Parameter "graph" geregelt, der genau definiert, an welcher Stelle wie tief rekursiert werden soll...
http://build.fhir.org/composition-operation-document.html
Simone Heckmann (Sep 12 2018 at 08:00):
Nach meiner Auffassung gibt es bei $document nur "ganz oder gar nicht":
"The server takes the composition resource, locates all the referenced resources and other additional resources as configured or requested and either returns a full document bundle, or returns an error."
Was genau "ganz" bedeutet muss entweder im Server als default hinterlegt sein, oder der Client kann seine Vorstellung von "ganz" kundtun, indem er eine GraphDefinition übergibt. Entweder das klappt dann, oder halt nicht.
Aber "halbe" Dokumente gibt's nicht.
Stefan Lang (Sep 12 2018 at 10:21):
Die Spezifikation von FHIR Documents erklärt indirekt referenzierte Ressourcen aber ausdrücklich als optional bzw. implementierungsabhängig:
"Other resources that these referenced resources refer to may also be included in the bundle if the document construction system chooses to do so. Including these additional resources will make the document bigger but will save applications from needing to retrieve the linked resources if they need them while processing the document. Thus, whether these linked resources should be included or not depends on the implementation environment. "
D.h. die Definition von "alles" ist hierdurch relativiert.
graph hatte ich tatsächlich nicht auf dem Schirm. Wie würde eine Wildcard in einer GraphDefinition aussehen? Und wäre ein simpler Parameter hier nicht trotzdem deutlich einfacher?
Alexander Zautke (Sep 12 2018 at 12:07):
Mhm, d.h. man müsste jede Reference als ein "link" element in die GraphDefinition packen. Hätte den Vorteil, dass der Client genau sagen könnte was an indirekten References jetzt unbedingt notwendig ist. Für Wildcard Use Cases wäre es aber irgendwie schon schön sagen zu können, dass die GraphDefinition alle Links einer Resource enthalten soll.
Simone Heckmann (Sep 12 2018 at 12:40):
Ich lese die Spezifikation so: Jedes System kann selbst entscheiden, welche Resourcen es bei $document mitbundelt und welche nicht.
Wenn ein System aber so konfiguriert ist, dass bestimmte Referenzen Teil eines Document-Bundles sind, dann wäre eine 404 beim Versuch die Instanz einer Composition zu bundlen immer noch ein harter Fehler. "Optional" beziehe ich hier auf die Konfiguration, nicht jedoch auf die Laufzeit.
Simone Heckmann (Sep 12 2018 at 12:42):
Bzgl GraphDefinition mit Wildcard kuckstu hier: http://build.fhir.org/graphdefinition.html#examples
Simone Heckmann (Sep 12 2018 at 12:47):
Und wäre ein simpler Parameter hier nicht trotzdem deutlich einfacher?
Ich wäre der Auffassung, dass das im Normalfall nicht der Client zu entscheiden hat. Der Server muss einen Plan haben (als GraphDefinition oder sonst wie), wie ein Document zu bauen ist und sich strikt daran halten. Wenn der Versuch, für eine Composition-Instanz nach Plan ein Dokument zu bauen fehlschlägt, dann ist das ein Fehler. Das muss sich der Client dann mit einem OperationOutcome zufrieden geben.
Stefan Lang (Sep 12 2018 at 14:24):
Wenn ein System aber so konfiguriert ist, dass bestimmte Referenzen Teil eines Document-Bundles sind, dann wäre eine 404 beim Versuch die Instanz einer Composition zu bundlen immer noch ein harter Fehler. "Optional" beziehe ich hier auf die Konfiguration, nicht jedoch auf die Laufzeit.
Absolut d'accord bezüglich 404, und auch bezüglich des Verständnisses von "optional". Das ist Sache der konkreten, möglicherweise Use Case-spezifischen, Implementierung.
Für einen generischen FHIR-Server aber trotzdem wünschenswert, wenn der Client das steuern kann.
Patrick Werner (Sep 12 2018 at 14:31):
und diese Steuerung wäre als parameter für die document operation deutlich leichter als das Erstellen von GraphDefinitions
Alexander Zautke (Jan 19 2019 at 16:11):
BTW, $document hat durch den Text in https://hl7.org/fhir/STU3/graphdefinition.html#document einen in der OperationDefinition nicht spezifizierten Parameter für GraphDefinition auch schon in STU3 :D Man findet immer irgendwo noch Leichen im Keller^^
Last updated: Apr 12 2022 at 19:14 UTC
