FHIR Chat · URL oder OID · german (d-a-ch)

Zwecks besserer Strukturierung würde ich gern das URL/OID-Thema aus https://chat.fhir.org/#narrow/stream/german.20(d-a-ch)/topic/Betriebsst.C3.A4tten hier weiterführen.
Die bisherige Diskussion dort dreht sich darum, ob wir für offiziell beim DIMDI registrierte "well known concepts" offizielle OIDs verwenden oder, wie bisher vorgesehen, jeweils ein NamingSystem mit URL definieren. Das ganze im Kontext der deutschen Basis-Profile.

Stefan Lang (May 12 2017 at 12:29):

Theoretische Möglichkeiten:
a) ausschließlich URL erlauben
b) ausschließlich OID erlauben
c) sowohl URL als auch OID in Identifiern erzwingen (möglich dank CodeableConcept)
d) URL und OID erlauben, mindestens eins davon muss verwendet werden
e) URL und OID erlauben, genau eins davon muss verwendet werden

Peter Scholz (May 12 2017 at 12:50):

c) geht nicht bei identifiern da hier system vom typ uri ist und nicht wiederholbar
zweimal derselbe identifer nur mit unterschiedlichem system value bei identischer Semantik ist überhaupt nicht gut

somit sind in dem Identifier Fall eigentlich nur noch die Varianten a,b und e möglich

Stefan Lang (May 12 2017 at 12:56):

(sorry, Unfug, ich war gedanklich bei Codes, nicht bei Identifiern)

Stefan Lang (May 12 2017 at 13:03):

Insofern richtig, was Du sagst, Peter.
Man könnte natürlich 2 Identifier vorschreiben, die auf das selbe Konzept mit Hilfe unterschiedlicher Systeme verweisen (das wäre das, was ich mit c/d meinte). Ist aber sicher nicht schön.

Stefan Lang (May 12 2017 at 13:34):

Möglichkeit e) bricht im Grunde genommen die Interoperabilität.
Wenn Software A nur URLs kennt (weil: das ist ja ausreichend) und Software B nur OIDs (weil: das ist ja ausreichend), können sie nicht miteinander kommunizieren. Außer, sie sind in der Lage, beides zu verstehen oder aber sie folgen einem abgeleiteten Profil, das von e) wiederum auf a) oder b) constrained.

Stefan Lang (May 12 2017 at 13:35):

Andererseits wäre der Charme von e), dass wir es den Implementierern überlassen können, was sie tatsächlich verwenden möchten. Mit anderen Worten: wir machen das Thema zu einem "Problem anderer Leute" ...

Stefan Lang (May 12 2017 at 13:47):

Wobei OID vs. URL natürlich in gleichem Maß auf Codes zutrifft.
Da kommt dann noch dazu, dass wir z.B. ICD-10-GM nach aktuellem Stand als system(URL) +version kennzeichnen (aus dem Grund, das Basisprofil genau nicht jährlich um eine OID zu erweitern).
Und das gilt analog auch für andere Codesysteme, z.B. OPS.

Peter Scholz (May 12 2017 at 13:49):

Ich glaube wir machen uns momentan da ein bischen zu sehr einen Kopf, das es für die Interoperabilität ein Problem wäre.
Im Ausgangsfall war es ja so, das system/@value für BSNR eine Konstante ist, die wir im Profil vorgeben.

Allgemein verbieten können wir ja eh nicht, auch HL7 sagt ja nur best practice. Zudem liefern viele Identifier Beispiele mehr oder minder gemischt mal URLs mal OIDs für system/@value. von daher sollten wir hier nicht zu viel Arbeit reinstecken.

Mein Ansatz war halt der, lediglich zu sagen, wenn wir in unserer Extension ein Codesystem, Valueset oder Identifikationsschema verwenden das bereits bei DIMDI mit einer OID registriert ist, so sollten wir diese OID auch verwenden und uns nicht eine eigene URL ausdenken, die wir dann auch noch pflegen müssen

btw. es ginge auch alle offiziellen OIDs mit einer resolveable URL darzustellen, der Code dazu findet sich auch beim DIMDI findet:

<system value="urn:oid:1.2.276.0.76.4.17"/>

ist equivalent zu

<system value="http://portal.dimdi.de/websearch/servlet/Gate?accessid=showOidDoc&query=oid=1.2.276.0.76.4.17"/>

Peter Scholz (May 12 2017 at 13:52):

bei Deinem Beispiel resolved die URL dann aber grade nicht auf die gültigen Inhalte des jeweiligen Codesystems sondern erst durch die Version wird es eindeutig.
Wobei wir da ja auf kein Problem laufen, da bei CodeableConcept URL und OID parallel existieren können.

Stefan Lang (May 12 2017 at 13:54):

Der Pflegeaufwand verschiebt sich letztlich nur, zumindest für Codesysteme (siehe oben).
Und für ICD-10-GM, OPS usw. wissen wir, dass da jährlich neue OIDs kommen. Dinge wie die BSNR sind tendenziell "ewig gleich"

Patrick Werner (May 12 2017 at 13:56):

generell präferiere ich URLs, aus dem Grund dass diese sprechend sind und somit intuitiver von Menschen zu verstehen. Wenn man dies automatisch mappen möchte muss man genau einmal nachschlagen, bzw in das NamingSystem Betriebstättennummer reinschauen und sich dort die oid holen. Wenn es als OID abgebildet wird muss jeder der nicht alle oids im Kopf jedes mal nachschlagen was die OID zu bedeuten hat.

Peter Scholz (May 12 2017 at 14:03):

@Patrick Werner zwei parallele Registries für identische Inhalte sind ein Konzeptfehler.

De jure ist das DIMDI und sein OID Register die Registratur für Codesysteme, Valuesets und Indentifiezierungsschemata. Von daher nicht an anderer Stelle noch einmal pflegen.

Die Menschenlesbarkeit von FHIR Nachrichten sollte jetzt nicht das Kriterium sein, zumal deutsche URL Namen auch nur in DACH verstanden werden, wogegen DIMDI registrierte OIDs zwingend auch eine englische Beschreibung haben.

Hannes Ulrich (May 15 2017 at 07:48):

Moin, ich würde mich der Meinung von @Patrick Werner anschließen. Das DIMDI ist de jure für die OIDs zuständig, aber deren Registry-Servlet passt konzeptuell nicht zu FHIR. Wenn man die Vorteile der maschinellen Prüfung von Instanzen mit FHIR beihalten möchte, muss man dann entweder das DIMDI bewegen ihre Registry ordentlich abfragbar zu machen oder in das NamingSystem Betriebstättennummer schauen!

Simone Heckmann (May 15 2017 at 17:48):

Ich denke,es wäre mal interessant zu erfahren, in wie weit das OID-Konzept schon bei den Implementieren angekommen ist. Ich habe das subjektive Gefühl, dass OIDs in vielen Implementierungen nicht mehr sind, als ein "unhandlicher hartcodierter string". Wenn dem so wäre, sehe ich die Verwendung von URL aus Sicht der Implementierer als Fortschritt an.
Klar macht das auf der Seite der Spezifizierung mehr (Verwaltungs-)Aufwand, aber das ist ja der Geist von FHIR:
You can move complexity around, but you can't make it go away
Und: Im Zweifel für den Implementierer...

Last updated: Apr 12 2022 at 19:14 UTC

Main menu