Stream: german/terminologien
Topic: Type-Codes in Basis-Namingsystems LANR und BSNR
Maximilian Reith (Aug 20 2019 at 07:06):
Hallo,
mir sind die verwendeten Codes in den Basis-Namingsystems aufgefallen:
<type>
<coding>
<system value="http://hl7.org/fhir/v2/0203"/>
<code value="PRN"/>
</coding>
</type>
Würde nicht der Code MD oder DN bei dem LANR-Namingsystem besser passen, sowie bei BSNR -> XX?
Tendenziell denke ich dass MD besser ist als DN...
Gruß Max Reith
Simone Heckmann (Aug 21 2019 at 12:38):
Ich glaube, das ist ein Fehler. Der IDentifier-Type für LANR müsste "LANR" lauten...
Sonst wüsste ich nicht, warum wir den Code "LANR" in das ValueSet http://fhir.de/ValueSet/identifier-type-de-basis aufgenommen hätten...
Simone Heckmann (Aug 21 2019 at 12:40):
@Stefan Lang ...?
Simone Heckmann (Aug 21 2019 at 12:41):
siehe dazu auch die Beschreibung im R4-Guide: https://simplifier.net/guide/basisprofil-de-r4/LebenslangeArztnummerLANR
Stefan Lang (Aug 21 2019 at 13:06):
Stimmt, das ist tatsächlich nicht konsistent ...
Die Frage ist: macht ein type "LANR" Sinn, wenn das system dies schon aussagt? Das stammt ja aus v2-Zeiten, wo es keine Namespaces im FHIR-Sinn gibt.
Von daher würde ich für Max' Vorschlag plädieren: type=MD für LANR und analog type=XX für BSNR.
Dies vorbehaltlich der Klärung, ob die Bedeutung "Medical License number" für MD eine spezifsche Bedeutung hat (z.B. nur für den US-Realm oder ähnliches).
LANR und BSNR würden dann nicht mehr im identifier_type-VS benötigt und wir würden uns dem originalen FHIR-VS wieder annähern.
Simone Heckmann (Aug 21 2019 at 13:28):
Dringend brauchen tun wir den Type-Code bei LANR nicht, aber
Die Angabe des Identifier-Types ist optional, da die LANR als solche anhand der einheitlichen Namespace-URL "http://fhir.de/NamingSystem/kbv/lanr" zu erkennen ist. Die Angabe des Types kann jedoch hilfreich sein, wenn sowohl LANRs als auch ZANRs (Zanharztnummern) verwaltet werden müssen, da letztere über keinen einheitlichen Namensraum verfügen und daher ausschließlich am Typ als ZANR erkennbar sind.
Simone Heckmann (Aug 21 2019 at 13:30):
Da wir bei ZANR mit "ZANR" zu typisieren und LANR mit "LANR" ist halt irgendwie konsistent und Intuitiv...
Mein Argument wäre: Unter "LANR" kann sich jeder in DE etwas vorstellen, unter "MD"/"PRN" nicht unbedingt...
und außerhalb von DE interessiert sich niemand für LANRs...
Simone Heckmann (Aug 21 2019 at 13:31):
ohne dabei gewesen zu sein würde ich vermuten, dass es in der Vergangenheit bereits die Diskussion gab, ob LANR=PRN/MD und man sich für "nein" entschieden hat, was dazu führte, dass die LANR in das V2-ValueSet aufgenommen wurde. Was auch immer die Gründe waren...
Stefan Lang (Aug 21 2019 at 16:57):
Ja richtig, ich glaube, die Differenzierung zur ZANR war der Grund, warum wir LANR als type eingebaut hatten (bzw. wollten ...).
Dann macht es wahrscheinlich doch Sinn, LANR zu nehmen.
Wobei ich im Rahmen der Basisprofile auch kein Problem hätte, MD als alternativen bzw. umfassenderen type code für LANR bzw. ZANR zu erlauben
Simone Heckmann (Aug 21 2019 at 18:58):
Ich hab den Type als Pattern hinterlegt, daher sind Alternative Codierungen problemlos möglich...
Maximilian Reith (Aug 22 2019 at 06:40):
Generell würde ich für den Raum DE zustimmen, allerdings möchte ich zumindest zur Diskussion stellen, dass man ja auch international verständlich sein könnte. Also dass man nicht NUR einen nationalen Code verwendet. Nach kurzer Recherche könnte der CODE MD allerdings doch eher einer Nummer für die Approbationsurkunde gleichen...
Maximilian Reith (Aug 22 2019 at 07:55):
Also um das nochmal weiter zu konkretisieren, auch wenn sich außerhalb von D niemand um LANR schert, wäre es für denjenigen zumindest gut zu wissen, dass er diese Nummer nicht benötigt.
Maximilian Reith (Aug 22 2019 at 07:58):
Und wenn man in Richtung medizinische Informationsobjekte denkt, dann könnte dieses Namingsystem auch bei ausländischen Empfängern landen, sei es zu Forschungszwecken (oder wenn Derjenige umgezogen ist)
Simone Heckmann (Aug 27 2019 at 13:59):
Ich vermute, dass außerhalb DE die LANR schlicht als Fremdschlüssel aufgefasst würde, ohne den Versuch zu unternehmen, diesem Semantik beizumessen. Aber wenn's der usecase erfordert, kann man den Type ja gerne doppelt codieren (type.coding 0..*), dann würde auch ein ausländisches System die LANR als PRN erkennen können.
Last updated: Apr 12 2022 at 19:14 UTC
