Stream: german/mi-initiative
Topic: Technische Fragen
Birger (Aug 12 2019 at 07:53):
Hi an alle, ich wollte gerne hier mal die Power der Community nutzen, um einige technische Fragen zu sammeln. Konkret geht es darum, dass ich gerade versuche ein Bundle mit mehreren Resources zu definieren. Es soll ähnlich aussehen wie hier: https://simplifier.net/BidirectionalService/BSeRObesityRequestSupportBundle/~overview
Das mit dem Einbinden der Resourcen werde ich vermutlich hinbekommen (muss mich erst noch mit den Details von Forge vertraut machen), der eigentliche Punkt ist, dass ich gerne weitere Constraints auf die inkludierten Resources/Profile definieren möchte (z.B. möchte ich die Kardinalität von Elementen innerhalb eines component auf null setzen). Prinzipiell müsste StructureDefintion das erlauben, aber wird das auch von den Tools unterstützt? Vielen Dank für eure Hilfe!
Patrick Werner (Aug 12 2019 at 08:44):
Klaro, ist so alles von Forge unterstützt.
Birger (Aug 12 2019 at 09:30):
Das heißt, dass diese Aussage falsch ist, oder? "That example just defines the inclusions in the bundle it dos not apply any constraints to the included profiles/resources. So you first need to create individual per-resource profiles applicable to the bundle." Bei der Profiling Academy habe ich noch nicht die richtigen Infos entdeckt
Birger (Aug 12 2019 at 17:11):
@Patrick Werner Kannst Du die Aussage bestätigen?
Simone Heckmann (Aug 12 2019 at 17:16):
Woher kommt die Aussage und auf welches Example bezieht sie sich?
Simone Heckmann (Aug 12 2019 at 17:23):
Normalerweise würde man die Ressourcen in individuellen Profilen constrainen und nicht im Bundle, da das Bundle ja nur ein Transportcontainer ist und die Constraints unabhängig von diesem gelten. Ist idR auch leichter zu managen als alles in einem riesigen Bundleprofil zu machen.
Nebenbei: Elemente auf 0..0 zu setzten sollte gut überlegt sein. Nur weil man ein Element in einem bestimmten Kontext nicht benötigt, heißt das nicht, dass es nicht in einem anderen Kontext relevant sein könnte. Ist es in einem von beiden Profilen jedoch explizit verboten, schließt das jegliche Interoperabilität zumischen beiden Kontexten aus.
Also wenn das Element nicht begründet stört, bitte drin lassen!
Patrick Werner (Aug 12 2019 at 17:55):
Zu Allem von Simone: +1
Birger (Aug 12 2019 at 18:28):
@Simone Heckmann @Patrick Werner Vielen Dank für eure Hilfe! Das bezog sich auf das oben verlinkte Beispiel. Die Aussage kam von einem Kollegen aus UK, den ich aus der openEHR community kenne, der aber auch schon viel mit FHIR gearbeitet hat. Das Problem, das ich hier sehe ist das folgende: Patrick hatte mir vor einiger Zeit mal geschrieben, dass man gewisse Kontext-Informationen nicht direkt in der component modelliert haben möchte, sondern in einer eigenen Resource bzw. dem Profil auf einer Resource. Wenn ich Kontextinformationen über mehrere Resources/Profile verteile, muss ich sicherstellen, dass verschiedene Anwender sie trotzdem konsistent nutzen. Dieses würde ich nach meinem Verständnis in einem Bundle erledigen, das ich dann konsistent wiederverwenden könnte in verschiedenen FHIR Documents.
Eng damit verbunden ist der Anwendungsfall, dass man dann in einem FHIR Document (oder Bundle) nur bestimmte Elemente aus verschiedenen Resources/Profilen benötigt, um einen konkreten Use-Case zu modellieren. Hier ist es zum Beispiel sehr von Vorteil, wenn ich einem Entwickler nicht sämtliche Elemente zeige, sondern nur diejenigen, die für den Anwendungsfall relevant sind. Zudem könnte ich hier weitere Einschränkungen vornehmen. Beispielsweise könnte ich in einer Patientenakte in der Gynäkologie eine Condition mit einem passenden Display Namen versehen und ein spezifisches Value-Set anstatt der vollständigen SNOMED oder ICD Diagnosen als Valuesets definieren. Man könnte vielleicht auch festlegen, dass eine Observation in einem bestimmten Fall nur für den Fötus gelten kann und nicht für die Mutter. Solche Sachen halt, um möglichst spezifisch den Anwendungsfall abzudecken. Dadurch, dass ich nur weitere Constraints definieren kann bzw. bestehende erweitere, bleiben die Modelle ja konsistent. Wenn ich jedes Mal neue Profile erstellen muss, um die Sachen in einem Bundle oder Dokument spezifische einzubinden, wird das vom Management her irgendwann doch ziemlich unübersichtlich. Hoffe das erklärt ein wenig, worauf ich hinaus möchte. Wäre für mich erstmal wichtig zu wissen, ob das denn prinzipiell technische geht und ob die Tools das können und man kann natürlich gerne diskutieren, ob das schlechter Stil bei FHIR ist.
Birger (Aug 12 2019 at 18:40):
Anderes Beispiel zur Erläuterung: wenn ich die Auswahl habe eine Quantität mit verschiedenen Einheiten zu kodieren, dann wäre es gut, wenn ich dem Entwickler nur diejenige "zeige", die ich gerne haben möchte in meinem Use-Case. D.h. ich würde bei der Körpertemperatur die Definition für Fahrenheit spezifisch für meinen Anwendungsfall entfernen (vielleicht nicht das beste Beispiel, da man Fahrenheit beim deutschen Profil entfernen würde, aber ich denke, das illustriert soweit die Idee), so dass niemand erst auf die Idee kommt, hier die "falsche" Definition zu verwenden.
Mareike Przysucha (Aug 12 2019 at 20:36):
Für mich klingt aber genau das nach Profiling: Anpasssung vorhandener Ressourcen auf den konkreten UseCase incl. use-case-spezifischer ValueSets.
Beispiel von oben: Profiling der Patientenressource für Föten (sofern es da modellierungstechnische Unterschiede gibt), Profilierung von Conditions udn Observations etc. mit den entsprechenden values und Codes und ggf. ValueSets und/oder units unter Berücksichtigung des Fötus-Profis.
Und ja, je nach Use Case können das viele Profile sein, die da erstellt werden. Aber wenn diese bei simplifier zur Verfügung gestellt werden, können andere in einem anderen UseCase zu einem ähnlichen Thema entscheiden, ob einzelne Profile für sie nutzbar sind oder nicht, und wenn ja, die Interoperabilität vorantreiben.
Auch für die Anpassungsfähigkeit später wird es einfacher: Bei kleineren Änderungen, zum Beispiel aufgrund einer Absprache mit anderen FHIR-Profilieren oder Entwicklern, man nur das Profil ändern, die anderen Profile, auch von den anderen Profilierern und Entwicklern, bleiben im Großen und Ganzen unverändert.
So, und damit eine gute Nacht.
Patrick Werner (Aug 12 2019 at 20:43):
(deleted)
Patrick Werner (Aug 12 2019 at 20:56):
@Birger
das obige Beispiel ist wie vorgeschlagen ein constrain auf Bundle, in den entry slices gibt es constrains welche profilierte Resource erwartet wird
Patrick Werner (Aug 12 2019 at 20:57):
Also je Slice ein weiteres Profil welches die Resource im entry definiert.
Patrick Werner (Aug 12 2019 at 20:57):
bezüglich vital-signs gibt es profile die man nutzen muss:
Patrick Werner (Aug 12 2019 at 20:57):
https://www.hl7.org/fhir/observation.html#core
Patrick Werner (Aug 12 2019 at 20:57):
https://www.hl7.org/fhir/observation-vitalsigns.html
Patrick Werner (Aug 12 2019 at 20:58):
man kann aber von diesen ableiten, also weitere constrains hinzufügen
Patrick Werner (Aug 12 2019 at 21:11):
Schöner als ein reines Bundle fände ich eine Composition, anstatt auf profile der Resource zu slicen (was je nach Tooling ein auch schwer zu beweisen ist, bin ich das erwartet Slice wenn ich das in meta behaupte, oder werde ich durch validierung konform).
Expressiver wäre eine Composition zu verwenden, dann können die Resourcen auch außerhalb des Bundles exisitieren. In den Sections kann man diese Resourcen verlinken und auf den code slicen.
Birger (Aug 12 2019 at 21:13):
@Mareike Przysucha Ich halte das für etwas schwierig, wenn man neben den Kontext-Informationen (worst case: ich modelliere für jede Apgar-Score Messung ein eigenes Profil und baue dafür ein Bundle) für X Use-Cases ca. X + n profile erstellen muss. Ich würde es bevorzugen, wenn man weitere Einschränkungen während des Erstellung des Bundles bzw. des Dokumentes machen könnte und nicht einzeln für jede Resource vorher (ist vermutlich eher eine Sache des Tools).
@Patrick Werner Das hatte ich soweit verstanden. Für mich war die Frage, ob ich die Use-Case spezifischen Profile immer vorher definieren muss, oder ob ich einfach, wie in der Antwort an Mareike erwähnt, man das während der Document oder Bundle Definition einschränken kann. Wenn ich ein Document mit >200 Datenelementen definiere und vorher jedes verwendete Profil nochmal anpassen und ggf. ein neues erzeugen muss, ist das schon etwas schwierig im Handling.
Patrick Werner (Aug 12 2019 at 21:16):
Naja, du musst um conformance garantieren und testen zu können vorher profilieren, ja. Die Profile können UseCase spezifisch sein, aber auch abstrakter. Das ist die Entscheidung des Modelers.
Birger (Aug 12 2019 at 21:17):
@Patrick Werner Danke für die Ergänzung, dann schaue ich mir das auch nochmal genauer an (auch wenn ich das noch nicht 100% verstehe)
Patrick Werner (Aug 12 2019 at 21:19):
Bei einem Document mit 200 Einträgen ist es deutlich einfacherer handlebar 201 profile zu erstellen (falls sich nichts wiederholt sonst ggfs. deutlich weniger), als ein Monstrum mit 201 Einträgen.
Birger (Aug 12 2019 at 21:19):
@Patrick Werner Aber bin ich nicht automatisch konform, wenn ich nur engere Constraints definieren darf? Oder ist das durch die "Component", die neue Elemente erlaubt, nicht mehr gegeben? In openEHR unterscheidet man bei den Spezialisierungen: bei einer "Vererbung" kann man weitere Elemente hinzufügen, bei der Erzeugung einer Composition (heißt dort openEHR Template, nicht zu verwechseln mit CDA Templates :D ) jedoch wirklich nur Dinge genauer spezifizieren oder wegnehmen.
Birger (Aug 12 2019 at 21:20):
Mit dem richtigen Tooling möglicherweise, aber nicht, wenn ich 50 Profile einzeln anfassen und ändern muss. Wenn ich es richtig verstehe, muss ich diese neuen Profile auch dauerhaft vorhalten?
Simone Heckmann (Aug 13 2019 at 06:51):
Zwischenfrage: Was verstehst du unter "Component"?
Birger (Aug 13 2019 at 06:52):
Sowas hier: pasted image
Ist natürlich sehr spezifisch für Observationen, aber das macht ja einen sehr großen Anteil an Resources aus in der Praxis.
Simone Heckmann (Aug 13 2019 at 06:54):
Ok, es geht hier also um Observations in einem Bundle. Was ist das für ein Bundle? Transaction/Document/Batch...? Zu welchem Zweck werden die Observations gebundlet? Kannst du Deinen UseCase etwas konkreter beschreiben? Was modellierst du gerade?
Simone Heckmann (Aug 13 2019 at 06:58):
ad Vererbung: Die FHIR core Onservation hat 0..* components, keine davon hat irgendwelche constraints.
Nun kann ein abgeleitetes Profile die components "offen slicen", d.h. für vier der 0..* components werden constraints definiert, die Kardinalität von component ist aber immer noch 0..*
Nun kann win wiederum abgeleitetes Profile z.B. zwei weitere Slices auf component definieren, so dass nun insgesamt sechs definierte slices vorhanden sind. Technisch betrachtet ist das aber nur ein weiterer Constraint, obwohl es so aussieht, als wäre etwas hinzugefügt worden.
Mit Extensions ist es genau so: Das Hinzufügen von Extensions ist technisch betrachtet ein Constraint auf eine der 0..* Extensions, die jede core Ressource haben kann...
Simone Heckmann (Aug 13 2019 at 07:02):
ad Composition vs. Bundle: hier geht es hauptsächlich um die Frage, ob die Ressourcen nur zum Zwecke des Transports zusammengefasst werden (-> Bundle) oder ob es hier um eine persistente Sammlung heterogerner (-> Composition) oder homogener (->List) Ressourcen geht.
Birger (Aug 13 2019 at 07:04):
Ich versuche momentan zwei Dinge:
a) Mapping komplexer Archetypen auf FHIR Resources/Profile, so dass diese von unterschiedlichen Anwendern konsistent genutzt werden können. Dazu war bisher die Idee, dass man diese in einem Bundle zusammenfasst.
b) Zusammenstellen von Data Sets, um beispielsweise ein Dokument darzustellen (könnte aber auch eine Transaction sein). Hintergrund ist, dass wir uns überlegen, wie man FHIR nutzen kann, um Daten aus einem Formular im Webfrontend auf die JSON Objekte aus FHIR zu mappen und ins Backend zu bekommen. Bei openEHR erstelle ich hierzu ein Template, das die Archetypen mit weiteren Constraints belegt.
Zum Thema Vererbung: das ist soweit klar, dass neue Elemente auch nur "neue" Constraints sind. Das ist auch OK, wenn ich ein Profil eines Profils erstelle (bzw. in openEHR einen Archetype spezialisiere, damit die Elemente vererbe und dann weitere hinzufüge). Das Problem ist nur, dass ich dann natürlich nicht mehr interoperabel bin, wenn ich für jeden Use-Case neue Elemente hinzufüge. Das versucht openEHR durch den maximum data set Ansatz zu vermeiden, d.h. diese Elemente sollten schon Teile des "Ausgangs"-Archetypen sein.
Zum Thema Composition vs. Bundle: Ich habe hier bisher immer Document synonym für Composition verwendet, da hätte ich spezifischer sein müssen.
Simone Heckmann (Aug 13 2019 at 18:05):
Hintergrund ist, dass wir uns überlegen, wie man FHIR nutzen kann, um Daten aus einem Formular im Webfrontend auf die JSON Objekte aus FHIR zu mappen und ins Backend zu bekommen.
Das wiederum klingt nach einem Questionaire (Definition des Formulars) mit einem data extraction service (siehe http://build.fhir.org/ig/HL7/sdc/extraction.html)
Sylvia Thun (Nov 13 2019 at 13:49):
Call for :fire: Paper:
https://www.egms.de/static/de/news/news_0450.htm
Last updated: Apr 12 2022 at 19:14 UTC
