Stream: german (d-a-ch)
Topic: CapabilityStatement.document .profile
Alexander Zautke (Jan 17 2019 at 21:02):
Hallo zusammen,
Zwei Anliegen meinerseits:
1) Der HL7 DE FHIR Server sagt in seinem CapabilityStatement (löblicherweise), dass er $document unterstützt. Jedoch zeigt die URL der OperationDefinition zu "OperationDefinition/Composition-i-document" anstelle von "http://hl7.org/fhir/OperationDefinition/Composition-document". Nur ein kleiner Hinweis ;)
2) Da nun Support für $document vorhanden ist, könnte man auch dementsprechend CapabilityStatement.document setzten. Hier stellt sich mir nur die Frage, ob wir einen Change Request einbringen wollen um CapabilityStatement.document.profile von 1..1 auf 1..* setzen zu lassen? Mir scheint es jedenfalls nur bedingt sinnvoll, dass eine Instanz stets nur ein Dokument-Typ erstellen darf, also z.B. nur den Medikationsplan-Plus. Oder lese ich hier die Spec falsch?
Stefan Lang (Jan 17 2019 at 21:11):
CS.document ist ja bereits 0..*
Und da darunter auch .mode und .documentation liegen, die tendenziell spezifisch für das document-Profil sind, macht es IMHO Sinn, wie es ist.
Stefan Lang (Jan 17 2019 at 21:12):
Kurz: Einfach für jedes document-Profil ein eigenes document-Element ins CapStmt
Alexander Zautke (Jan 17 2019 at 21:16):
Ups, danke! Irgendwas macht gerade keinen Sinn :sweat_smile:
Alexander Zautke (Jan 17 2019 at 22:16):
Müsste es dann aber nicht bedeuten, dass $document noch einen weiteren Parameter bräuchte durch welchen ich angeben kann, welches Profil mein erzeugtes Bundle haben soll?
Stefan Lang (Jan 18 2019 at 00:30):
Interessante Frage. Folgt zwar m.E. nicht aus dem obigen gelösten Problem, aber es gibt m.W. hier auch keine Möglichkeit, ein meta.profile zu setzen.
Die Frage ist: will man das im Standard?
Edit: Unfug entfernt
Stefan Lang (Jan 18 2019 at 00:44):
Bei $document kann man als Parameter die Referenz zu einer GraphDefinition übergeben, die die genauen Inhalte des document definiert.
Im Profil der Composition geht das m.W. aber nicht.
Man kann also z.B. auch die Rekursionstiefe nur zur Laufzeit maschinenverarbeitbar definieren (zumindest im Kontext der FHIR-Spec).
Dass der Client diese GraphDefinition im Kontext von Composition-Profil XY übergeben muss, kann m.W. nur textuell spezifiziert werden. Ist somit Sache der Business Logic. Das gilt auch, wenn der Server so intelligent (bzw. von IG dazu verpflichtet wird) ist, diese GraphDefinition automatisch anzuwenden, wenn $document auf Compositions vom Profil XY angewendet wird.
Kurz: Business Logic muss ich in jedem Fall dahinter stehen haben, wenn ich $document auf profilierte Compositions/Bundles anwende.
Es wäre aber IMHO durchaus interessant, ob es genügend Interesse gibt, profilierte documents per $document rein mittels FHIR-Standard durchzudefinieren.
Ohne jetzt weiter darüber nachzudenken, könnte da aber noch die eine oder andere Falle lauern.
Alexander Zautke (Jan 19 2019 at 10:26):
Vollkommen richtig, egal wie man es dreht und wendet, man braucht immer eine Composition und GraphDefinition, wenn man möchte, dass es die Regeln maschinen-lesbar ausgedrückt werden und in FHIR spezifiziert sind. Meiner Meinung macht die Angabe von verfügbaren Document Profilen im CapabilityStatement jedoch nur Sinn, wenn ich sie irgendwo auch übergeben kann. Ansonsten müsste der Server nachdem das Dokument fertiggestellt wurde anhand der Struktur "erkennen" was das nächstbeste Profil ist, welches passen könnte.
Hat jemand eigentlich schonmal ausprobiert, wie gut oder schlecht, dass mit der GraphDefinition funktioniert?
Stefan Lang (Jan 19 2019 at 15:33):
Gute Frage. Vielleicht besser mal im implementers-Stream stellen?
Last updated: Apr 12 2022 at 19:14 UTC
