Stream: german (d-a-ch)
Topic: rezept-zusatzinfos Extension
Alexander Zautke (Jul 05 2019 at 15:25):
Aufgrund der Tatsache, dass Complex Extensions nie so lustig sind zu implementieren, würde ich gerne verstehen, was die Überlegungen hier hinter waren:
https://simplifier.net/BasisprofilDE/rezept-zusatzinfos-0.2
1. Könnte man das ganze nicht vereinfachen, indem man die Tatsache das es ein Arbeitsunfall / Unfall per reasonCode / reasonReference modelliert und dann "gebuehrenfrei" als Extension eine Ebene höher zieht?
2. Falls Gründe hier gegensprechen wäre ich wenigstens dafür, dass die geslicten Extensions wenigstens ordentliche URLs bekommen um einen potentiellen Namenskonflikt zu vermeiden
Simone Heckmann (Jul 05 2019 at 15:39):
2. Falls Gründe hier gegensprechen wäre ich wenigstens dafür, dass die geslicten Extensions wenigstens ordentliche URLs bekommen um einen potentiellen Namenskonflikt zu vermeiden
...wäre aber eigentlich unüblich... !? Sub-Extensions müssen doch nur innerhalb ihrer umgebenden Extension eindeutig benamst werden...
Simone Heckmann (Jul 05 2019 at 15:41):
The url SHALL be a URL, not a URN (e.g. not an OID or a UUID), and it SHALL be the canonical URL of a StructureDefinition that defines the extension. Except for child extensions defined within complex extensions, the URL SHALL be an absolute URL.
Alexander Zautke (Jul 05 2019 at 16:21):
Den Satz kannte ich noch nicht, sorry. Fügt bei der Indexierung falls man ein Suchparameter drauf setzen möchte eine weitere Ausnahme hinzu. Aber dann ist das so :anguish:
Für mich wäre die Aussage jedoch trotzdem, dass der MedicationRequest existiert aufgrund der Tatsache, dass ein Unfall passiert ist. Ich finde das geht aus der Extension nicht so hervor.
Simone Heckmann (Jul 05 2019 at 16:32):
Fügt bei der Indexierung falls man ein Suchparameter drauf setzen möchte eine weitere Ausnahme hinzu. Aber dann ist das so :anguish:
Hmm? Ich blick's gerade nicht. Einen Suchparameter definiere ich doch mit einer FHIRPath-Expression
Also Suchparameter "rezept-unfall" wäre definiert als
path = MedicationRequest.extension('http://fhir.de/StructureDefinition/rezept-zusatzinfos/0.2').extension('unfall')
..warum braucht's dafür eine Ausnahme?
Simone Heckmann (Jul 05 2019 at 16:34):
Ich hab's noch nie wirklich getestet, aber ich könnte mir vorstellen, dass VONK so eine SearchParameter-Definition klaglos frisst...
Alexander Zautke (Jul 05 2019 at 16:36):
Die Logik die das Element nach dem Select per FHIRPath verarbeitet (d.h. den Index in der Datenbank erstellt) hat einen Edge Case in dem sie eine absolute URL erwartet
Simone Heckmann (Jul 05 2019 at 16:39):
Dez. '18 hat's anscheinend mal funktioniert... (auch wenn ich mich nicht mehr an den konkreten UseCase erinnere...) https://chat.fhir.org/#narrow/stream/179266-fhirpath/topic/FHIRPath.20for.20SearchParameter.20in.20complex.20extension
Simone Heckmann (Jul 05 2019 at 16:44):
Ja doch, ich weiß wieder. Ich hab in der Tat einen VONK am Start, der genau mit der o.g. FHIRPath-Expression-Syntax einen Suchparameter in einer komplexen Extension indiziert.
Alexander Zautke (Jul 05 2019 at 17:00):
Dann mach ich gerade irgendwas falsch. Danke für's raussuchen!
Alexander Zautke (Jul 05 2019 at 17:02):
Nur nochmal zur Bestätigung, die Extension wird verwendet weil separate Ressourcen für diese Info zu nehmen wäre over the top für einen simplen boolean?
Simone Heckmann (Jul 05 2019 at 17:04):
Zur Motivation der Extension habe ich leider keine Info ( @Stefan Lang ...?). Ich hab mich nur gewundert, was an einer komplexen Extension so schlimm ist ;-)
Patrick Werner (Jul 05 2019 at 17:09):
wäre eine simple extension mit valueCode und den 3 codes nicht einfacher?
Patrick Werner (Jul 05 2019 at 17:11):
ah nee, quatsch. Ist ja kein entweder oder.
Stefan Lang (Jul 05 2019 at 17:53):
Habe zwar nur halb gelesen, aber der Hintergrund für "Unfall" ist das Kreuzchen auf dem deutschen Rezept
Stefan Lang (Jul 05 2019 at 21:07):
(inclusive der sinnfreien, aber bestehenden Möglichkeit, mehrere widersprüchliche Kreuze auf dem Formular machen zu können ...)
Simone Heckmann (Jul 06 2019 at 09:15):
Ich denke, die Frage, ob zwei Informationen zu einer komplexen oder zwei separaten Extensions modelliert werden sollten, lässt sich analog zur Frage "Observation mit zwei components oder zwei Observations?" beantworten:
Gibt es Systeme/UseCases, die sich für die eine, aber nicht die andere Information interessieren, oder werden beide Informationen immer gemeinsam betrachtet?
Ich vermute, dass es im konkreten Fall der Rezept-Zusatzinfos um die Information geht, wie ein Rezept abzurechnen ist und dafür stets beide Informationen betrachtet werden müssen...
Stefan Lang (Jul 06 2019 at 14:00):
Das ist im Wesentlichen der Hintergrund
Last updated: Apr 12 2022 at 19:14 UTC
