FHIR Chat · Alpha-ID Canonical URI · german/terminologien

Gibt es eine jahresspezifische "hübsche" canonical URL für Alpha-IDs oder eine "Platzhalter" canonical URL für Alpha-IDs, so wie http://fhir.de/CodeSystem/dimdi/icd-10-gm für ICD-10 GM in den STU3 Basisprofil? Ich würde das sonst über die oid (urn:oid:1.2.276.0.76.5.479 für Alpha-ID 2019) abbilden.

Patrick Werner (Nov 16 2019 at 15:56):

Bislang ist noch keine definiert. Wir sollten aber eine definieren um von den OIDs weg zu kommen. Analog würde sich http://fhir.de/CodeSystem/dimdi/alpha-id anbieten.

Simone Heckmann (Nov 18 2019 at 08:30):

D'accord. Ich würde es hier auch wie bei ICD-10 halten und anstelle von Jahresspezifischen URLs mit versionierten URLs arbeiten, also dann z.B.: http://fhir.de/CodeSystem/dimdi/alpha-id|2018
Wäre natürlich schön, wenn das DIMDI diese URLs vergeben würde, aber da spüre ich nach wie vor keine Ambitionen...

Patrick Werner (Nov 18 2019 at 09:12):

soll ich das Namingsystem mit http://fhir.de/CodeSystem/dimdi/alpha-id zu den basisprofilen STU3/R4 hinzufügen?

Simone Heckmann (Nov 18 2019 at 09:13):

Gerne!

Frank Oemig (Nov 20 2019 at 09:47):

'2018' ist keine Version. Das ist die Grundproblematik mit Klassifikationen.
So ist icd_10_gm_2019rel1 ein eigenes Kodesystem.
Es bringt uns nicht wirklich weiter, wenn wir die korrekte Versionierung von Klassifikationen, nur weil es bequem ist, konstant ignorieren.

Simone Heckmann (Nov 20 2019 at 10:29):

In FHIR werden unterschiedliche Versionen von CodeSystemen als separate Instanzen repräsentiert, die lediglich eine gemeinsame CanonicalURL teilen.
Da wir über Profile erzwingen können, dass die Versionsnummer in der Instanz immer mitgeführt wird, gibt es keine semantische Überlappungen. Ich habe bisher noch keinen guten Grund gehört, weshalb wir auf die "bequeme" Lösung verzichten sollten. An welcher Stelle würde das konkret zu Problemen führen?
Durch die Änderungen am Canonical Datatype in R4 haben wir auch die Möglichkeit, den ICD-Katalog explizit versions-spezifisch zu adressieren (z.B.: http://fhir.de/CodeSystem/dimdi/icd-10-gm|2019)

Was jetzt genau der Vorteil wäre, statt dessen die Canonical bei jeder Version hartcodiert zu ändern (z.B. http://fhir.de/CodeSystem/dimdi/icd-10-gm/2019) leuchtet mir nicht ein.
Die Nachteile liegen hingegen auf der Hand: Wir verlieren die Möglichkeit, versions-unabhängige ValueSets zu definieren, die Semantisch bedeuten "jeder ICD-10-GM Code aller bekannten ICD-Kataloge ist zulässig". Wir müssten die Definition des ValueSets mit jeder neu erscheinenden ICD Version ändern. Außerdem kann ein konkretes Profil im Einzelfall oft gar nicht wissen, welcher Katalog gerade gilt, da das von Rahmenbedingungen wie z.B. dem Aufnahmedatum abhängt.

Konkret gefragt:
Warum ist

                <valueCoding>
                    <system value="http://fhir.de/CodeSystem/dimdi/icd-10-gm" />
                    <version value="2019" />
                    <code value="U69.32" />
                </valueCoding>

schlechter als

                <valueCoding>
                    <system value="http://fhir.de/CodeSystem/dimdi/icd-10-gm/2019" />
                    <code value="U69.32" />
                </valueCoding>