Stream: german/kbv
Topic: Ist es zulässig Extensions zu "verbieten"?
Volker Wick (Nov 09 2020 at 11:59):
Macht es eigentlich Sinn, ein System wie FHIR zu verwenden, das von sich aus einen großen Wert auf universelle Erweiterbarkeit legt (Extensions) aber dann gleichzeitig jegliche Erweiterung fremder Extensions zu verbieten?
Ich denke da an die KBV Verordnungssoftware-Schnittstelle (Anforderungskatalog Verordnungssoftware-Schnittstelle nach § 291d Absatz 1a Satz 1 Nr. 1 SGB V)
Hier werden diverse Profile und Extensions vorgegeben, allerdings mit folgender der Einschränkung:
Die KBV-Profile müssen ohne jegliche Modifikation eingesetzt werden. ... Bei der Realisierung der VoS müssen die KBV-Profile, -Extensions, -ValueSets und -CodeSystems eingesetzt werden. Einschränkungen, Erweiterungen und jegliche Modifikationen dieser Dokumente sind nicht erlaubt.
(Hervorhebung von mir)
Meiner Meinung nach steht das im Widerspruch zu Kapitel 2.5.0 in der FHIR Dokumentation, insbesondere im zweiten Abschnitt:
As such, extensibility is a fundamental part of the design of this specification. Every element in a resource can have extension child elements to represent additional information that is not part of the basic definition of the resource. Applications should not reject resources merely because they contain extensions, though they may need to reject resources because of the specific contents of the extensions.
(Hervorhebung von mir)
Wenn ich hier den letzten Abschnitt richtig lese bedeutet das doch daß man Extension nicht per se zurückweisen darf (also nur weil sie da sind), sondern höchstens weil etwas mit den vorhandenen Daten nicht in Ordnung ist. Bei ValueSets und CodeSystems würde ich eine solche Einschränkung verstehen aber bei Extensions finde ich macht diese Einschänkung wenig Sinn.
Oder habe ich da etwas falsch verstanden?
Alexander Zautke (Nov 09 2020 at 12:19):
Aus meiner Sicht lässt sich diese Frage nur aus dem Anwendungskontext heraus beantworten. Generell ist natürlich immer korrekterweise drauf hinzuweisen, dass Extensions in FHIR nicht als etwas "Spezielles" zu werten sind, sondern wie jedes anderen Element auch verarbeitet werden sollte. Jedoch befinden wir uns im KBV Kontext in einer sehr tiefen Ableitungshierarchie. Diese Profile sind Use-Case spezifisch. Und in diesem konkreten Fall sind Erweiterungen nicht vorgesehen, aus div. nachvollziehbaren Gründen. Genau aus diesem Grund steht in der FHIR Spezifikation ein SHOULD und kein MUST NOT. Solange gute Gründe vorliegen darf ein Implementation Guide Einschränkungen vornehmen.
Alexander Zautke (Nov 09 2020 at 12:19):
Vielleicht mag jemand anders noch ein wenig auf die Gründe eingehen :)
Frank Oemig (Nov 09 2020 at 12:46):
Diese Flexibilität ist genau das Problem für IGs. Wir arbeiten gerade an speziellen Extensions für mustSupport, die hier dann Näheres regeln, d.h. wann man was machen darf. Die vielen IGs haben hier eine derartige Komplexität entwickelt, die sich im Narrativ versteckt. Das muss formalisiert werden, damit man das in den Griff bekommt.
In sofern hat Alexander Recht, dass das use case spezifisch entschieden werden muss. Es ist mehr als legitim, das mitunter auch zu verbieten.
Simone Heckmann (Nov 10 2020 at 14:55):
Für die VoS-Schnittstelle kann ich es jetzt konkret nicht beantworten, beim eRezept war die (nachvollziehbare) Begründung für das rigorose verbieten von allem, was nicht ausdrücklich in der Spezifikation steht, dass auf dem eRezept aus Gründen des Datenschutzes und der Datensparsamkeit nichts draufstehen darf, was nicht auch auf dem Papierrezept stand. Klar widerspricht das der Philosophie von FHIR, die versucht, eine möglichst offene und interoperable Basis vorzugeben, aber Philosophie ist halt kein Gesetz und "Offenheit" beinhaltet eben auch, dass der Standard auch für extrem reglementierte Bereiche nutzbar ist.
Simone Heckmann (Nov 10 2020 at 15:04):
Ich verstehe aber, dass genau diese Einschränkungen die Entwickler in Zukunft viel Nerven kosten werden. Insbesondere da dies zu Inkompatibilitäten zwischen verschiedenen Spezifikationen führt.
Daher mein Tipp:
Implementiert FHIR immer so, dass ihr das Maximum dessen, was euer System an Daten liefern kann, liefert.
Baut euch einmal ein Skript/Modul/Microservice (was auch immer), das folgendes tut:
-
es nimmt zwei Parameter entgegen:
- Instanz einer Ressource die "bereinigt" werden soll
- Profil auf das bereinigt werden muss
-
in den Profilen (StructureDefinitions) steht in einfacher, maschinenlesbarer Form drin, wie die Kardinalitäten der einzelnen Elemente lauten
Das Skript muss also das Profil lesen, und aus der Instanz alles entfernen, was eine Kardinalität von 0..0 hat. -
Die Rückgabe ist die bereinigte Ressource
Das funktioniert dann mit x-beliebigen FHIR-Ressourcen und x-beliebigen Profilen. Einmal programmiert, kann man dann künftigen restriktiven Spezifikationen einigermaßen entspannt entgegenblicken.
Für jeden neuen Kommunikationskanal muss dem Skript dann bloß noch ein neues Zielprofil als Parameter übergeben werden.
Der/die erste, der/die das macht und es open source stellt, kriegt ein Eis von mir :smiley:
Simone Heckmann (Nov 10 2020 at 15:05):
Problematisch könnte an den o.g. Einschränkungen der VoS allerdings sein, wenn diese nur in Prosa im IG stehen, aber nicht maschinenlesbar im Profil. Muss ich mir mal anschauen...
Frank Oemig (Nov 10 2020 at 15:28):
So einfach wird es nicht werden - das gilt nur für lineare Einschränkungen wie von dir beschrieben. Profile führen auch andere Einschränkungen ein, die sich zT gegenseitig ausschließen und nicht additiv wirken.
Simone Heckmann (Nov 10 2020 at 18:08):
Hast du ein Beispiel?
Frank Oemig (Nov 10 2020 at 23:08):
Kodierungen, weitere oder alternative Extensions, Kardinalitäten, ..
Frank Oemig (Nov 10 2020 at 23:09):
Das maximal Lieferbare muss ja auch nicht immer ein Superset sein...
Frank Oemig (Nov 10 2020 at 23:14):
Es ist auch eine Frage, ob die Semantik der Instanz zum Profil passt...
Simone Heckmann (Nov 11 2020 at 08:30):
Frank Oemig said:
Kodierungen, weitere oder alternative Extensions, Kardinalitäten, ..
Alternative Kodierungen/Bindings stellen keine Inkompatibilität dar, so lange das Superset die entsprechende Mehrfachkodierung enthält.
Alternative Extensions dto.
Weitere Extensions sind bei der Validierung generell unproblematisch, (außer im o.g. Fall der KBV)
Kardinalitäten wurden ja genannt. Eine besondere Herausforderung könnte es jedoch sein, wie man in dem Skript mit begrenzenten Max-Kardinalitäten > 0 umgeht. Wenn die Anzahl der Adressen beim Patienten z.B. von 3 auf 1 reduzieren muss, weil das Zielprofil nur eine Adresse erlaubt.
Dabei müsste man dann eine qualifizierte Entscheidung treffen, welche Adressen gelöscht werden und welche das Zielproblem braucht.
Müsste aber technisch auch lösbar sein, sofern man im (HAPI-) Code eine Möglichkeit hat, einzelne Elemente gegen einzelne ElementDefinitions zu validieren, bzw. zu ermitteln, welches Element auf ein Slice passt. Ich meine, dass das geht, bin mir aber nicht 100% sicher...
Frank Oemig (Nov 11 2020 at 08:52):
Das erfordert eine semantische Beschreibung, um was es sich genau handelt. So bezweifele ich, dass irgendeine Observation gemäß eines beliebigen Profils einfach reduziert werden kann - und dann validiert es.
Ich muss zumindest ein Basisprofil haben. Dazu müssten wir aber Profilhierarchien einführen - wie ich es seit Jahren fordere. Aktuell sehe ich das aber nicht. Vielleicht kann man mir den Link mal geben...
Volker Wick (Nov 12 2020 at 08:01):
Vielen Dank an alle für das Feedback. Besonders der Vorschlag von Simone klingt ziemlich interessant. (Wenn wir die Zeit für einen solchen Bereinigungs-Service hätten würden wir es sicher angehen...)
In der Zwischenzeit werden wir die "verbotenen" Extensions erstmal wieder rauswerfen und fürs nächste Mal entsprechend vorsichtiger sein.
Last updated: Apr 12 2022 at 19:14 UTC
