Stream: german (d-a-ch)
Topic: Zahnarztnummern
Simone Heckmann (Aug 16 2019 at 08:56):
Ich habe in den letzten Tagen etwas an der Migration des Practitioner-Profils herumgetüftelt, und folgendes überlegt:
Ich würde es uns gerne ersparen, künftig drölfzig NamingSystems für die verschiedenen Zahnarztnummernkreise in den Basisprofilen pflegen zu müssen, daher habe ich mal versucht, ob man das nicht bei der Validierung mit einem Pattern-Matching abfangen kann.
Tatsächlich funktioniert das mit einer Invariante: matches('http://fhir.de/NamingSystem/kzv/[0-9][0-9]/zahnarztnummer') im Identifier-Profil: https://simplifier.net/basisprofil-de-r4/identifierzanr
Die Spezifikation de NamingSystems könnte ungefähr folgendermaßen aussehen: https://simplifier.net/basisprofil-de-r4/zahnarztnummer
Die Absicht ist es, in die Beschreibung des Naming-Systems eine Tabelle mit den möglichen Werten für "XX" einzufügen, allerdings rendert Simplifier im Moment den Markup-Code noch nicht (ist in künftigen Releases jedoch vorgesehen)
Damit wäre in der Validierung sichergestellt, dass nur gültige URLs für ZANRs angegeben werden können, ohne dass wir alle einzeln aufzählen müssen. Sieht jemand darin einen Nachteil...?
Patrick Werner (Aug 16 2019 at 08:59):
ich finde es elegant und sinnvoll. Evtl. wird manches Tooling das noch nicht beherrschen. Der Java Validator sollte es aber können, .NET war der code auch schon da aber nicht verlinkt/oder auskommentiert.
Simone Heckmann (Aug 16 2019 at 10:31):
Aktuell funktioniert es in .NET. Wenn ich diese Ressource (https://simplifier.net/basisprofil-de-r4/practitioner-example) auf Simplifier validiere, greift die Invariante und weist auf die ungültige URL hin.
Simone Heckmann (Aug 16 2019 at 10:33):
Wir könnten das Pattern theoretisch noch verfeinern, um ungültige ZKV-Nummern rauszufiltern, aber ich denke, das ginge zu weit :).
Ich wäre aber nicht abgeneigt, die Severity von aktuell "warning" auf "error" zu erhöhen...
Simone Heckmann (Aug 16 2019 at 10:34):
Besser, als die Tabelle im NamingSystem zu pflegen, wäre es auch, auf einer extern verwaltete, autoritative Quelle von ZKV-Nummern zu verweisen, sofern jemand eine kennt....
Stefan Lang (Aug 16 2019 at 10:46):
Pattern macht Sinn, denke ich.
Ich würde allerdings dann doch so weit gehen, ausschließlich die erlaubten in der RegEx zu listen. Es sind ja nicht so viele.
Die offizielle Liste suche ich gleich mal
Stefan Lang (Aug 16 2019 at 10:57):
(Seite 77)
Simone Heckmann (Aug 16 2019 at 11:54):
...wenn wir die RegEx konkreter machen, dann müssen wir halt auch immer unser Profil anpassen, wenn sich an den Nummern etwas ändert. Davor graust's mir ein wenig, zumal wir vermutlich die letzten wären, die das mitbekommen...
Simone Heckmann (Aug 16 2019 at 12:15):
Beim Practitioner stellt sich übrigens mal wieder die Frage nach dem Wert des Basisprofils...
Ich habe aktuell eines im R4-Projekt, bei dem ich völlig sinnfrei die LANR und die ZANR auf 1..1 gesetzt habe, da dich die Validierung testen wollte.
Sobald ich beides wieder auf 0..1 setzte verliert sich m.E. der Sinn, da der Validator alles durchwinken würde (open Slicing!). Für abgeleitete Profile ist das Basisprofil denkbar ungünstig, da in den seltensten Fällen sowohl ZANR als auch LANR benötigt würde. Die abgeleiteten Profile wären also nur unnötig aufgebläht.
Ich tendiere daher dazu, es bei den Identifier-Profilen zu belassen und die Best-Practise-Ansätze im Leitfaden zu beschreiben (https://simplifier.net/guide/basisprofil-de-r4/ZahnarztnummerZANR).
Gerne hätte ich auch ein oder zwei konkretere Profile, mit denen man anständig validieren kann (z.B. Profil für "Kassenzahnarzt") , aber ich wüsste nicht, was man da außer dem Identifier sinnvollerweise als Pflichtfeld definieren könnte/sollte...
Stefan Lang (Aug 16 2019 at 13:06):
Dass sich die Struktur der KVen bzw. KZVen ändert, passiert glaube ich extrem selten. Das dürfte vertretbarer Aufwand sein ;-)
Simone Heckmann (Aug 16 2019 at 13:58):
Mir war die Tatsache, dass vier davon schon durchgestrichen sind verdächtig. Würden wir die denn auch erlauben wollen? Könnte ja sein, dass jemand historische Daten exportieren muss, aus Zeiten als es diese noch gab. Wir müssten dann zwei Invarianten machen, eine mit Error, falls komplett ungültig und eine mit Warnung, falls deprecated :headscratch:
Stefan Lang (Aug 16 2019 at 15:44):
Ich hatte die durchgestrichenen (die Bezirke der KZV BW) seinerzeit nicht als NamingSystem aufgenommen.
In der Annahme, dass die KZV BW die Aufgaben der früheren 4 Bezirke übernimmt, sollte das ausreichend, ganz besonders im Kontext eines NamingSystems.
Da würde ich also eher abwarten, bis sich jemand beschwert.
Stefan Lang (Aug 17 2019 at 09:08):
Im Übrigen bin ich ebenfalls dafür, es für Practitioner bei Identifier-Profilen zu belassen.
Soweit ich den praktischen Einsatz der aktuellen Basisprofile im Blick habe, bestehen da doch divergente Anforderungen, ob/wann man die diversen Identifier (und auch die spezifischen HumanName- und Address-Profile) tatsächlich benötigt. Es ergibt sich also eher eine "0..0-Hell".
Davon ab werden gerade für Practitioner (und auch Organisationen) gern mal logische Referenzen verwendet (vulgo: reference by identifier), d.h. man müsste in letzter Konsequenz auch überall, wo Referenzen auf z.B. Practitioner möglich sind, entsprechende Slices einführen ...
Ich bin weit davon entfernt, das für wartbar oder gar sinnvoll zu halten.
Last updated: Apr 12 2022 at 19:14 UTC
