Stream: german (d-a-ch)
Topic: Patient VSDM-Profil
Stefan Lang (Jul 11 2017 at 14:43):
Ich habe eben mal versucht, patient-de-vsdm auf den aktuellen Stand zu heben und auch offen zu gestalten ( https://github.com/hl7germany/basisprofil-de/issues/10 ).
Der aktuelle Stand ist hier: https://simplifier.net/BasisprofilDE/patient-de-vsdm
Da ich im Moment nicht weiß, wie ich Datentyp-Profile innerhalb eines Ressourcen-Profils weiter constrainen kann (@Simone Heckmann hatte geschrieben, dass es geht, aber nicht, wie ;-), sind zumindest bis auf Weiteres auch zwei vSDM-Datentyp-Profile hinzugekommen:
https://simplifier.net/BasisprofilDE/humanname-de-vsdm
https://simplifier.net/BasisprofilDE/address-de-vsdm
Das ist auch schon der erste Punkt, den ich für suboptimal halte. Wenn man jeweils auch die Datentypen ableiten muss, um Constraints einzubauen, wird das sehr schnell unübersichtlich, vor allem, wenn Implementer das dann ihrerseits tun müssen. Von daher hoffe ich, dass Simone sagt, wie's besser geht ;-)
Stefan Lang (Jul 11 2017 at 14:48):
Um es offen zu halten, habe ich außerdem für Patient.name und Patient.address jeweils Slices eingebaut, die sicherstellen sollen, dass eine Patient-Instanz hinreichend konform zu VSDM ist, aber trotzdem noch andere Namen bzw. Adressen erlaubt.
Dafür habe ich den Discriminator-Typ "profile" versucht, mit Bezug auf $this, wie in der Doku erwähnt. Das scheint aber leider nicht richtig zu funktionieren. Jedenfalls validiert auch (mal wieder) ein nicht-valides Beispiel. Vorschläge erbeten :)
Stefan Lang (Jul 11 2017 at 14:50):
Davon abgesehen wäre theoretisch mit dem Slicing und zwei weiteren Adress-Profilen auch die Trennung der VSDM-Adressen auf Straßenadresse und Postfachadresse möglich, aber das wollten wir ja in Prosa fassen (und würde einiges noch mehr komplizieren)
Stefan Lang (Jul 11 2017 at 14:55):
Nebenbei bemerkt sollte man Vorsicht walten lassen, wenn man das Profil mit Forge bearbeitet - erneutes Speichern macht das Slicing kaputt.
Die Baum-Darstellung in Simplifier sieht auch teilweise merkwürdig aus.
Stefan Lang (Jul 11 2017 at 18:39):
OK, nach etwas Recherche: Slicing mit Discriminator-type "profile" ist in diesem Kontext sinnlos, da das wohl nur für Referenzen gilt (?).
Stefan Lang (Jul 17 2017 at 17:32):
Zur Info und Referenz bezüglich Datentyp-Profilen: ich habe die Frage mal international gestellt: https://chat.fhir.org/#narrow/stream/conformance/topic/Derived.20profile.20and.20custom.20data.20type
Stefan Lang (Jul 18 2017 at 10:38):
So, nachdem es dann letztlich irgendein (gerade nicht mehr reproduzierbares) Verhalten von Forge war, habe ich patient-de-vsdm nochmal aktualisiert. Die beiden nun überflüssigen VSDM-Profile für Address und HumanName sind damit auch wieder weg.
Das Adress-Slicing habe ich ebenfalls weggelassen - das Thema VSDM-konforme Adresse vs. weitere Adressen (old, work, ...) sollten wir dann IMHO wirklich schlicht im Leitfaden dokumentieren.
Stefan Lang (Jul 18 2017 at 10:44):
Es sind also jetzt letztlich, im Sinn der offenen Profile, nur einige "1.." statt "0.." sowie einige must-supports, die patient-de-vsdm von patient-de-basis unterscheiden.
Ich schließe damit dann auch https://github.com/hl7germany/basisprofil-de/issues/10
Korrekturvorschläge bitte ggf. als neues Github-Issue.
Last updated: Apr 12 2022 at 19:14 UTC
