Stream: german (d-a-ch)
Topic: Namespaces
Simone Heckmann (Aug 24 2016 at 08:42):
um die im Stream "Leistungserbringer" begonnene Diskussion um die Namespaces weiterzuführen:
Das Votum war für canonical form, also nach dem Schema http://<domäne>/fhir/<Resource-Type>/<Identifier>
Simone Heckmann (Aug 24 2016 at 08:43):
Vorteil: Konsistentes URL-Format über Namespaces, ValueSet, Profile etc hinweg
Simone Heckmann (Aug 24 2016 at 08:46):
Vorteil: Mit einem redirect von http://<domäne>/fhir auf den Endpunkt unserer Registry (z.B. auf Simplifier.org) können die URLs unmittelbar aufgelöst werden und führen zu der jeweiligen Spezifikation inclusive aller Anmerkungen und Hinweise für die Entwickler, die wir dort hinterlegen. Anderenfalls müssten die Implementierer auf unserem Endpunkt die URL als Suchbegriff eingeben.
Simone Heckmann (Aug 24 2016 at 08:48):
NAchteil: die URL wird damit etwas unahndlicher (z.B.: http://hl7.de/fhir/NamingSystem/kbv-lanr vs. http://kbv.de/lanr)
Stefan Lang (Aug 24 2016 at 08:49):
Spricht etwas gegen http://<domäne>/fhir/<Resource-Type>/<Original-Issuer/<Identifier> ?
Beispiel: http://hl7.de/fhir/NamingSystem/KBV/LANR
(_noch_ unhandlicher ;-)
Simone Heckmann (Aug 24 2016 at 08:50):
Nachteil: Es werden Ding unter die HL7-Domäne gehängt, mit denen HL7 eigentlich nichts am Hut hat (siehe vorheriges Beispiel)
Das wiederum lässt sich jedoch damit mildern, dass man in der Resource selbst angeben kann, wer der "publisher" des jeweiligen NamingSystems, CodeSystems oder ValueSets ist.
Patrick Werner (Aug 24 2016 at 08:50):
fände ich besser, drückt die Hirarchie noch besser aus
Simone Heckmann (Aug 24 2016 at 08:52):
Da uns die Domäne fhir.de gehört, könnten wir auch alles unter http://fhir.de/fhir aufhängen. Das wäre etwas neutraler...
Stefan Lang (Aug 24 2016 at 08:53):
fhir.de klingt gut
Stefan Lang (Aug 24 2016 at 08:53):
Auch im Hinblick z.B. auf Interop und z.B. die AG Mobile Apps
Simone Heckmann (Aug 24 2016 at 08:56):
fhir.de/***fhir*** ist zwar etwas redundant, aber (ohne es genau zu wissen...) ich glaube, wenn wir alles direkt unter fhir.de aufhängen, wird das mit dem redirect schwierig. Dann könnten wir die Domäne zu nix anderem mehr nutzen. Wär schade drum...
Stefan Lang (Aug 24 2016 at 08:57):
d'accord
Simone Heckmann (Aug 24 2016 at 09:07):
Simone Heckmann (Aug 24 2016 at 12:24):
Proof-of-concept (unter der Annahme, dass das mit dem redirect irgendwie machbar ist):
Profil für Organization als KBV- Betriebsstätte: http://fhir.de/StructureDefinition/kbv/betriebsstaette
Profil für Practitioner als KBV-Leistungserbringer: http://fhir.de/StructureDefinition/kbv/leistungserbringer
Namespace für LANR: http://fhir.de/NamingSystem/kbv/lanr
Namespace für IKNR: http://fhir.de/NamingSystem/gkv/iknr
Namespace für KVNummer: http://fhir.de/NamingSystem/gkv/kvnr
Deutsche Erweiterung des ValueSets "observation-type": http://fhir.de/ValueSet/observation-type
KBV-ValueSet für Fachgruppen: http://fhir.de/ValueSet/kbv/fachgruppen
Namensraum der Codes darin: http://fhir.de/NamingSystem/kbv/s_bar2_wbo
...passt soweit ganz gut...
Patrick Werner (Aug 24 2016 at 12:30):
ich bin gerade am rumbasteln mit einem ValueSet für die Länderkennzeichung innerhalb der EGK Daten. Diese sind von der GKV festgelegt (und entsprechen keinem Standard :( )
URI wäre dann: http://fhir.de/ValueSet/gkv/countries
Stefan Lang (Aug 24 2016 at 13:06):
@Simone Heckmann Sieht auf jeden Fall schon mal sauber strukturiert aus :thumbs_up:
Stefan Lang (Aug 24 2016 at 13:07):
Aber jetzt doch ohne "/fhir/" ?
Simone Heckmann (Aug 24 2016 at 13:08):
Wenn wir uns damit technisch kein Bein stellen, würde ich es am liebsten weglassen. Ich hab da was von RegEx gehört...
Stefan Lang (Aug 24 2016 at 13:10):
Kann man machen, dann wären das ggf. mehrere Rewrite-Regeln (je 1x für die 1. Hierarchieebene, aber die sind ja in der Zahl begrenzt).
Simone Heckmann (Aug 24 2016 at 13:10):
Schlimmstenfalls müsste man eben die verschiedenen Resourcentypen gezielt an den Profil-Server-Endpunkt redirecten (.../(StructureDefinition|ValueSet|NamingSystem|CodeSystem|...) Die Liste der Conformance-Resourcen ist ja endlich...
Simone Heckmann (Aug 24 2016 at 13:10):
Ja eben. Zwei Dumme, ein Gedanke :D
Stefan Lang (Aug 24 2016 at 13:11):
sic!
Simone Heckmann (Aug 24 2016 at 13:12):
alea iacta est :D
Stefan Lang (Aug 24 2016 at 13:13):
Solange da kein "morituri te salutant" folgt ...
Stefan Lang (Aug 24 2016 at 13:14):
@Patrick Werner ist das die DEÜV Anlage 8?
Ich meine, auf dem letzten Interopforum hatten wir gesagt, wir gehen auf die ISO-Codes und wer intern GKV verwendet, soll auf ISO mappen
Patrick Werner (Aug 24 2016 at 13:19):
@Stefan Lang ganz genau diese. Ich bin auch voll für ISO 3611 Codes, aber die EGK benutzt die doofen GKV Codes. Möchte für diese ein ValueSet erstellen mit Mapping auf ISO Codes. Dadurch kann man die EGK auslesen und hat nach der Anwendung des Mappings vernünftige FHIR Ressourcen
Stefan Lang (Aug 24 2016 at 13:21):
Ah, so rum macht's natürlich absolut Sinn ;-)
Simone Heckmann (Aug 24 2016 at 13:31):
Absolut legitim. Wir können beide ValueSets definieren, dann eine ConceptMap die zwischen beiden konvertiert und dann nur eines davon an die Profile binden. Passt schon. Oder wir können im Profil sagen "Man kann beide CodeSysteme verwenden, es muss aber immer mindestens ein ISO-Code dabei sein. Macht dann Sinn, wenn das Zielsystem sonst wieder zurück-mappen müsste... Die Systeme, die KBV-Codes brauchen können dann die KBV-Codes direkt verwenden, alle anderen nehmen die ISO-Codes und ignorieren die KBV-Codes. "CodableConcept" erlaub ja stets ein Konzept auf verschiedene Art-und-Weise auszudrücken.
Patrick Werner (Aug 24 2016 at 13:34):
Bei den ISO Codes gabe es aber noch keine Konsens welche Darstellung wir nutzen wollen, oder? Es gäbe da numerisch oder 2 bzw. 3 Buchstaben. Am sprechendsten wäre imho die 3 Buchstaben Darstellung
Simone Heckmann (Aug 24 2016 at 13:36):
Das Basis-Profil müsste verlangen: Es muss mindestens einen ISO-Code geben (Slicing nach System, Open at End). Ein KBV/EGK oder sonst ein konkreteres Profile kann dann sagen: Es muss auch mindestens einen KBV-Code geben. Instanzen können dann ohne weiteres zu beiden Systeme kompatibel sein, indem beide Codes verwendet werden. Wir müssen nur aufpassen, dass wir die Profile nicht überladen und am Ende ein und das selbe Konzept mir fünf verschiedenen Codes kommuniziert werden muss :D Aber das sendende System erst von GKV auf ISO mappen zu lassen und das empfangende System muss dann wieder zurückmappen, da es an die KV exportieren muss, wäre albern.
Stefan Lang (Aug 24 2016 at 13:38):
@Patrick Werner ISO 3 Buchstaben ist in FHIR zumindest auch bei country empfohlen ("Country (can be ISO 3166 3 letter code)").
Die numerischen ISO-Codes habe ich in freier Wildbahn noch nicht gesehen. Also sehr gern ISO 3 Buchstaben.
Simone Heckmann (Aug 24 2016 at 13:38):
hier wird nur der 2-Buchstaben code gelistet: http://hl7-fhir.github.io/terminologies-systems.html !?
Stefan Lang (Aug 24 2016 at 13:39):
Gnah! Irgendwie auch nicht konsistent
Simone Heckmann (Aug 24 2016 at 13:40):
Ich mach einen Change Request... ist bestimmt keine Absicht....
Patrick Werner (Aug 24 2016 at 13:40):
mir persönlich wären die 3 Buchstaben auch am liebsten ;)
Stefan Lang (Aug 24 2016 at 13:41):
"The country codes can be represented either as a two-letter code (alpha-2) which is recommended as the general purpose code, a three-letter code (alpha-3) which is more closely related to the country name and a three digit numeric code (numeric -3) which can be useful if you need to avoid using Latin script."
Stefan Lang (Aug 24 2016 at 13:42):
Q: http://www.iso.org/iso/country_codes.htm
Stefan Lang (Aug 24 2016 at 13:43):
Die ISO selbst hätte also gern alpha-2
Stefan Lang (Aug 24 2016 at 13:45):
Und vor dem Hintergrund "more closely related to the country name" ist vielleicht auch der mögliche Code-Eintrag im String(!)-Feld country gedacht, wobei ich mich frage, welches System, das Codes da rein schreibt, diese dann noch von alpha-2 nach alpha-3 umsetzt, statt gleich in den Klartext ...
Patrick Werner (Aug 24 2016 at 13:49):
stimmt es gibt ja noch das String Feld. Nee dann eben wie von der ISO vorgeschlagen 2stelliger Country Code im CODE Feld, und im String den vollen
Ländernamen auf Deutsch
Stefan Lang (Aug 24 2016 at 13:51):
ACK
Simone Heckmann (Aug 24 2016 at 21:04):
Ich habe mal einige der NamingSystems, über die wir bisher diskutiert haben, eingefangen: https://simplifier.net/FHIRABENDSandbox?conformance=NamingSystem
Kommentare?
Simone Heckmann (Aug 31 2016 at 19:03):
Ping @dr Kai U. Heitmann :)
Last updated: Apr 12 2022 at 19:14 UTC
