Stream: german (d-a-ch)
Topic: Adresse Basisprofile
dr Kai U. Heitmann (Jun 13 2017 at 09:34):
Warum sieht https://simplifier.net/BasisprofilDE/address-de-basis anders aus als https://simplifier.net/NictizDSTU2/nl-core-address? Ich verstehe nicht, warum in DE die extensions (Elemente) einen anderen Namen tragen als zB in NL. Sollten "extension (Hausnummer)" nicht auch als Elementnamen "housenumber" sein und auf die ISO 21090 ADXP Partikel verweisen?
Peter Scholz (Jun 13 2017 at 09:37):
Weil hier Building Number Suffix, unitId und additionalLocator nicht benötigt werden ?
Patrick Werner (Jun 13 2017 at 09:39):
Hausnummer und Strasse heißen anders verweisen aber auf die gleichen ADXP Extensions
Stefan Lang (Jun 13 2017 at 09:41):
Was Patrick sagt, plus, dass wir uns für die deutschen Profile dazu entschlossen haben, deutsche Bezeichner zu verwenden.
Simone Heckmann (Jun 13 2017 at 09:47):
Jap. Die Bezeichner tauchen auch in der Instanz nicht auf. In der Instanz einer Adresse würden Hausnummer in DE und NL gleich aussehen.
Simone Heckmann (Jun 13 2017 at 09:50):
Ups. Wir haben noch gar kein Beispiel für eine komplexe Addesse!
Simone Heckmann (Jun 13 2017 at 10:07):
Ich hab ein Tracker-Item erstellt: https://github.com/hl7germany/basisprofil-de/issues/14
Simone Heckmann (Jun 16 2017 at 09:06):
@Stefan Lang Ich habe Verständnis-Probleme mit https://github.com/hl7germany/basisprofil-de/issues/16
Warum müssen wir da Slicen? Unterscheidet sich die Struktur von Wohn-/und Postadressen im VSDM?
Stefan Lang (Jun 16 2017 at 09:12):
Die Wohnadresse (formal: "Strassenadresse") hat Straße, Hausnummer und Anschriftenzusatz.
Die PostfachAdresse hat stattdessen das Postfach.
Stefan Lang (Jun 16 2017 at 09:13):
Stefan Lang (Jun 16 2017 at 09:15):
Beides ist im VSDM 0..1, d.h. um VSDM-konform constrainen zu können, braucht man die Slices
Stefan Lang (Jun 16 2017 at 09:22):
Aus dem Bauch raus ist das wahrscheinlich mit 2 abgeleiteten Profilen (z.B. "address-de-vsdm-strassenadresse" und "address-de-vsdm-postfachadresse") am einfachsten möglich
Stefan Lang (Jun 16 2017 at 09:25):
Dabei wäre strassenadresse vom Typ physical|both, postfachadresse wäre postal.
Und ggf. muss irgendwo noch eine Invariante stehen, die besagt, dass "wenn both existiert, darf kein postal existieren"
Simone Heckmann (Jun 16 2017 at 09:33):
Das können wir doch mit einer invariante abbilden: Wenn typ = physical, dann extension hausnummer, wenn typ = postal, dann extension postfach.
Oder nö?
Simone Heckmann (Jun 16 2017 at 09:34):
Wollen wir "Both" überhaupt zulassen? in VSDM gäbe es ja bei identischer post- und wohnadresse auch zwei instanzen der Adresse, oder?
Stefan Lang (Jun 16 2017 at 09:35):
VSDM hat Strassen- und Postfachadresse. Wer kein Postfach hat, hat nur eine Adresse
Stefan Lang (Jun 16 2017 at 09:35):
"both" dürfte für Pat-Adressen der Regelfall sein. Ich fände es kontra-intuitiv für Implementer, das komplett zu verbieten
Simone Heckmann (Jun 16 2017 at 09:37):
Im basisprofil sicherlich nicht, aber wir reden ja hier über das VSDM-Profil, dass (mehroderweniger) 1:1 den VSDM-Datensatz abbildet. Und wenn's dort zweimal drinsteht, dann halt auch in der FHIR-Resource....
Stefan Lang (Jun 16 2017 at 09:38):
ad Invariante: war da nicht was, dass Datentypen keine Invarianten haben dürfen? Ich meine, genau diesen Punkt hätten wir in Madrid schon mal diskutiert ;)
Stefan Lang (Jun 16 2017 at 09:39):
Wenn wir "both" im VSDM-Profil verbieten, muss der Implementer u.U. die Strassenadresse dann 2x vorhalten, weil both halt der gefühlte Standardwert ist
Simone Heckmann (Jun 16 2017 at 09:40):
Nö, die Invarianten zur Address.line haben wir auch im Address-Profil drin. Das geht.
Patrick Werner (Jun 16 2017 at 09:40):
@wer kein Postfach hat, hat nur eine Adresse: Man kann laut EGK xsd auch gar keine Adresse haben, weder Postfach noch Straßenadresse
Stefan Lang (Jun 16 2017 at 09:41):
@Simone Heckmann Na dann gern auch per Invariante
Simone Heckmann (Jun 16 2017 at 09:43):
Einziger Nachteil beim nicht-Slicen: Wir könnten vermutl. nicht verhindern, dass jemand zweimal eine postal adresse verwendet, da wir kardinalität 0..2 auf Addresse brauchen. Aber ich glaube sogar das ginge notfalls mit einer invariante.
Simone Heckmann (Jun 16 2017 at 09:44):
DEN Preis wäre ich bereit zu zahlen :)
Patrick Werner (Jun 16 2017 at 09:46):
@Stefan Lang wieso sollte both der Standardwert sein?
Stefan Lang (Jun 16 2017 at 09:47):
@Simone Heckmann Einen Ausdruck, um 0..2 (physical|both 0..1 ; postal 0..1) zu constrainen, sollte man eigentlich bauen können.
Also erstmal d'accord
Patrick Werner (Jun 16 2017 at 09:47):
Ich vermute ja, dass in der freien Wildbahn die Postfachadresse noch nie benutzt wurde 
Peter Scholz (Jun 16 2017 at 10:00):
Ist mit irgendwie zu akademisch,
wenn es um den ausschliesslich um VSDM geht es um max 2 Adressen von denen beide auch ausschliesslich postal sein könnten. Warum also irgendwelche contrains ?
Patrick Werner (Jun 16 2017 at 10:02):
@Peter Scholz laut VDSM Datensatz gibt es eine "Strassenadresse" 0..1 und eine "Postfachadresse" 0..1. Zweimal postal geht also nicht
Stefan Lang (Jun 16 2017 at 10:02):
@Peter Scholz Du meinst, die VSDM-StrassenAdresse ist semantisch nicht gleichbedeutend mit einer physical address?
Peter Scholz (Jun 16 2017 at 10:04):
@Patrick Werner postal ist nicht zwangsläufig ein Postfach, es gibt auch Adressen bei denen die Postanschrift != der physikalischen Adresse ist.
Denkt mal an Menschen die in Pflegeeinrichtungen wohnen. Bei denen können sich Postanschrift von physikalischer Adresse definitiv unterscheiden
Stefan Lang (Jun 16 2017 at 10:05):
OK, d.h. die Annahme "Strassenadresse <=> physical|both, Postfachadresse <=> postal" ist falsch.
Patrick Werner (Jun 16 2017 at 10:06):
ja
Peter Scholz (Jun 16 2017 at 10:07):
Richtig, das einzige was wohlh sicher ist, ist die Tatsache das Postfach zwangsläufig immer postal sein muss.
Über die Strassenadresse kann man keine Annahmen treffen
Stefan Lang (Jun 16 2017 at 10:07):
In dem Fall gibt es keinen Kandidaten für einen Slice-Discriminator, und es muss zwangsläufig über Invarianten laufen, soweit wir das im Profil vertiefen
Peter Scholz (Jun 16 2017 at 10:08):
Muss man das unbedingt im Profil vertiefen ?
Stefan Lang (Jun 16 2017 at 10:08):
Diese Frage wollte ich mit dem Nebensatz provozieren ;-)
Patrick Werner (Jun 16 2017 at 10:09):
Und der VDSM kennt nur Straßen und Postfachadresse. Beim Beispiel mit dem Heimbewohner kann also nicht Postanschrift und physikalische Adresse unterschieden werden
Patrick Werner (Jun 16 2017 at 10:10):
Hier mal eine grafische Repräsentation der VSDM Daten der EGK:
vsdm.png
Stefan Lang (Jun 16 2017 at 10:10):
Jup, das ist Seite 79 aus der VSDM-Spez.
Patrick Werner (Jun 16 2017 at 10:11):
oh, ich bin blind. Zumindest nutzt die Gematik das gleiche Tool wie ich :-)
Stefan Lang (Jun 16 2017 at 10:12):
:D
Stefan Lang (Jun 16 2017 at 10:12):
Je weiter man dort reindenkt, desto mehr technische Komplexität braucht es, um alles schon im Profil genau so abzubilden wie in VSDM.
Von daher würde es mir auch genügen, wenn wir im Profil die address auf 0..2 constrainen, evtl. die line noch 0..2 constrainen und alle relevanten Extensions drin haben.
Den Rest dann in den Implementation Guide packen
Patrick Werner (Jun 16 2017 at 10:14):
Und wie weiter oben angesprochen einfach ein Profil für Straßenadresse und eines für Postfachadresse?
Stefan Lang (Jun 16 2017 at 10:17):
Wie bekämen wir die ohne Slicing-Discriminator sauber ins patient-de-vsdm-Profil?
Patrick Werner (Jun 16 2017 at 10:18):
Ich slice auf dem Profil der Adresse, oder denke ich gerade ganz verquer?
Stefan Lang (Jun 16 2017 at 10:19):
Ist das Profil der Adresse Bestandteil der Ressourcen-Instanz?
Stefan Lang (Jun 16 2017 at 10:22):
Die Instanz hat nur ein Meta-Element für die Ressource, aber nicht für jeden Datentyp.
D.h. die Adresse in der Instanz kann nicht behaupten "ich bin eine Strassenadresse".
Patrick Werner (Jun 16 2017 at 10:22):
stimmt :-(
Stefan Lang (Jun 16 2017 at 10:24):
Das ginge nur per Extension zur Definition des Typs, um dann darauf zu slicen.
Und das wäre mir dann ehrlich gesagt auch zu akademisch.
Stefan Lang (Jun 16 2017 at 10:31):
Ah, es lohnt sich, auf Seite 79 unter dem Diagramm zu schauen:
"Anmerkung: Ein Versicherter kann entweder eine Straßenadresse und/oder eine Postfachadresse haben. Im Infomodell wurde dies so abgebildet, dass beide optional sind. Für die Implementierung MUSS mindestens eine der Adressen gefüllt sein"
Stefan Lang (Jun 16 2017 at 10:31):
Also für patient-de-vsdm: address 1..2
Stefan Lang (Jun 16 2017 at 10:33):
Bzw. eigentlich für ein "patient-de-vsdm-closed", denn ein offenes Profil, wie wir sie eigentlichen bevorzugen, sollten auch andere Adressen (z.B. frühere Adressen) erlauben.
Patrick Werner (Jun 16 2017 at 10:35):
Das Profil VDSM soll einfach 1:1 die EGK abbilden oder? Damit fände ich closed prima. Wenn man alte Adressen halten will macht man das eher direkt mit dem BasisProfil-DE, oder?
Patrick Werner (Jun 16 2017 at 10:36):
Die Gematik hätte ihr XSD auch schöner bauen können damit man die Anmerkung auf Seite 79 nicht braucht....
Stefan Lang (Jun 16 2017 at 10:37):
Ein closed Profil macht es potentiell inkompatibel zur parallelen Verwendung mit anderen Profilen.
Zumindest würde ich bei einem closed-Profil dieser Tatsache durch die entsprechende Benennung darauf hindeuten.
Peter Scholz (Jun 16 2017 at 10:37):
nee closed wäre dumm, denn jemand sollte doch wohl einen Patienten mit eGK Daten kommunizieren können und kompatibilität zum Profil angeben dürfen, aber durchaus über das profil hinausgehende Informationen übermitteln. Es soll doch nur aussagen, das die Ressource in bezug auf die EGK Daten profilkonform ist.
Peter Scholz (Jun 16 2017 at 10:38):
Es soll hier doch nicht um eine Profil ausschliesslich für die eGK Daten gehen
Stefan Lang (Jun 16 2017 at 10:38):
Ein offenes VSDM-Profil sagt dann im wesentlichen nur aus, dass die betreffenden Extensions auf must-support stehen
Patrick Werner (Jun 16 2017 at 10:39):
@Peter Scholz du hast recht, man wird wohl keine EGK Karten aus einer übermittelten FHIR Ressource erstellen wollen. Also ist der Rückweg zum EGK Datensatz egal
Stefan Lang (Jun 16 2017 at 10:40):
Die Ableitungs-Hierarchie wäre:
patient-de-basis => patient-de-vsdm => patient-de-vsdm-closed
Wobei patient-de-vsdm-closed eher eine Fingerübung wäre.
Peter Scholz (Jun 16 2017 at 10:41):
oder akademische Ona.....
Patrick Werner (Jun 16 2017 at 10:46):
ja closed hat in der Praxis keine relevanz. (Außer die Gematik will das intern einsetzen in Richtung eGK Hersteller ;-) )
Peter Scholz (Jun 16 2017 at 10:47):
der war gut :rotfl:
Stefan Lang (Jun 16 2017 at 10:48):
Da würde ich dann mal ganz entspannt warten, bis die Gematik damit auf uns zukommt 
Simone Heckmann (Jun 16 2017 at 12:57):
Einwurf aus der Realo-Ecke: Eine Invariante, die die Verwendung der Postfach-Extension in Verbindung mit dem Adresstyp "physical" verbietet macht eigentlich immer Sinn (also schon im Basis-Profil)
Peter Scholz (Jun 20 2017 at 07:22):
Postfach extension kann sogar den Addresstype auf postal constrainen, nur für die Strassenadresse kann man keine Aussage treffen
Mathias Aschhoff (Jun 25 2017 at 18:58):
Hey zusammen, interessiert verfolge ich Eure Diskussion. Ich würde nochmal an die 80 / 20 Regel erinnern, denn ich glaube, dass eine Privatperson nur selten ein Postfach hat - muss das so? Kann man nicht sagen eine Adresse muss angegeben sein und alles weitere optional?
Stefan Lang (Jun 26 2017 at 06:16):
Bei Profilen im Allgemeinen und natürlich auch den deutschen Basisprofilen geht es ja darum, bestimmte Use Cases abzubilden.
In Bezug auf die Basisprofile also, verbreitete Datenstrukturen, wie VSDM-/eGK, einheitlich in FHIR abzubilden.
Insofern gilt 80/20 bei der Profilierung also nur bedingt.
In Bezug auf Postfächer bei Patienten sieht die Gematik-Spezifikation das nun mal so vor, und dementsprecht muss das zugehörige Profil bzw. ggf. auch nur der Implementation Guide das berücksichtigen.
Stefan Lang (Jun 26 2017 at 06:18):
Insgesamt folgen die deutschen Basisprofile ja dem Grundprinzip, offen zu sein, d.h. sie beschreiben, wie X gemacht werden sollte, wenn man X braucht, aber schränken nicht ein, dass jemand zusätzlich oder alternativ auch Y machen kann.
Stefan Lang (Jun 26 2017 at 06:21):
Demzufolge muss für das VSDM-konforme Basisprofil beschrieben sein, wie eine VSDM-Straßen- und -Postfach-Adresse aussieht. Ob sie dann verwendet wird, ist Sache des Implementierers im konkreten Use Case.
Stefan Lang (Jun 26 2017 at 06:24):
Sollte irgendwann die Gematik oder sonst jemand auf die Idee kommen, die eGKs direkt mit FHIR-Ressourcen zu befüllen, wie oben scherzhaft erwähnt, gäbe es ein geschlossenes (oder, wie Simone letztens a.a.O. vorschlug: "strict") Profil, das dann nur noch diese Strukturen erlaubt.
Peter Scholz (Jun 26 2017 at 07:48):
@Mathias Aschhoff das eine Privatepersion nur selten ein Postfach stimmt eben auch nur eingeschränkt, es gibt durchaus bei unseren älteren Patienten die in einer Einrichtung der Altenpflege wohnen die Situation das die Postanschrift eben die Postfachadresse der Einrichtung ist.
Die 80/20 regel sagt übrigens auch nicht aus, das der Anteil der Nachrichten die das betrifft mehr als 20% betragen muss, sondern das der Use Case eines Elements einer Ressource für weniger als 80% der beteiligten Systeme von Interesse sei. Der Use Case die eGK Daten abzubilden ist aber sicherlich für mehr als 20% von Interesse. Da die eGK auf der anderen Seite die Postfachadresse als eigenes Feld abbildet, muss das zugehörige Profil das auch hergeben.
Mathias Aschhoff (Jun 26 2017 at 08:47):
Betrachtet man den Use-Case eGK Adr. kommunizieren einverstanden.
Allerdings gibt es für die Adr ja mehr use-cases als nur eGK einlesen, daher dachte ich es wäre vllt gut es offener zu gestalten.
Dein Vorschlag (2 Profile) @Stefan Lang könnte ich mir gut vorstellen, das wäre auch für Implementierer einfacher zu verstehen.
Stefan Lang (Jun 26 2017 at 09:23):
@Mathias Aschhoff Grundsätzlich ist es seitens TC FHIR so gedacht, dass es immer ein offenes Profil gibt. Ein "Strict"-Profil macht nur dann Sinn, wenn es auch eingesetzt würde, was wir für VSDM derzeit nicht sehen.
Stefan Lang (Jun 26 2017 at 09:26):
Das grundlegende Profilierungskonzept, dem wir folgen wollen, ist:
xxx-de-basis: stellt die 80% zur Verfügung, schränkt wenig bis nichts ein
xxx-de-usecase: leitet von xxx-de-basis ab, ergänzt ggf. die 20% für den spezifischen Use Case, schränkt ebenso wenig ein
xxx-de-usecase-strict: leitet von xxx-de-usecase ab und schränkt exakt auf die Elemente des Use Case ein
Stefan Lang (Jun 26 2017 at 09:28):
Das kommt dann auch in unserer "FHIR-Best Practice" im Wiki, die wir in Bonn angesprochen hatten.
Simone Heckmann (Jun 26 2017 at 15:52):
Hi,
wir erweitern ja auch den komplexen Datentyp Address, nicht speziell den Patienten. Der Datentyp kommt dann in allen Basisprofilen zum Einsatz, also auch bei Organization. Und da sind Postfächer schon deutlich verbreiteter, daher macht das m.M.n schon Sinn...
Mathias Aschhoff (Jun 27 2017 at 10:23):
@Stefan Lang @Simone Heckmann Danke fürs abholen! Sorry für die blöden Fragen aber ich versuch mich gerade in Eure Gedankenwelt zu begeben, um auch die anderen Profile mal durchzusehen.
Also könnte man https://www.hl7.org/fhir/extension-iso21090-adxp-postbox.html nutzen und die Adress.line slicen, wie schon mit Str. und Hausnummer gemacht. Dann müsste man Prüfen was Simone sagte type- physical darf nicht und use home oder so dann sicher auch nicht?
Das geht über xpath invarianten? Aber auch nur zur Validierung der Ressourcen oder?
Stefan Lang (Jun 27 2017 at 10:55):
Och, die Fragen finde ich ganz hilfreich, als Basis für unseren FHIR-Profilierungs-Best-Practice-Wiki-Eintrag (OT: schönes Wort :D)
Postfach im Prinzip genau wie Du schreibst, außer, dass use="home" durchaus erlaubt sein sollte - use dient ja z.B. der Unterscheidung privat vs. geschäftlich ("home", "work"), insofern ist eine "home"-Postfachadresse eben das private Postfach.
Stefan Lang (Jun 27 2017 at 11:03):
Die Invarianten werden über FHIRpath ausgedrückt. Das ist nicht ganz dasselbe wie XPath, aber der Grundansatz ist natürlich gleich.
Die Invarianten dienen, genau wie Profile insgesamt, zur Validierung von Ressourcen-Instanzen.
Wann man validiert und wie Client bzw. Server auf nicht-profilkonforme Ressourcen reagieren, ist der Implementierung überlassen.
Simone Heckmann (Jun 28 2017 at 20:06):
Ich hab den Datentyp jetzt mit der Postfach-Extension erweitert.
Die Constraints sind drin, hab mich aber noch nicht getraut, sie zu testen :P
Stefan Lang (Jun 28 2017 at 20:11):
Zum Testen müsste auch erstmal ein Ressourcen-Profil upgedated werden, oder? Also patient-de-basis ... Ich mach das gerade mal
Stefan Lang (Jun 28 2017 at 20:38):
Fehler im Gedanken - Datentyp-Profile werden ja auch im Snapshot nur referenziert...
Stefan Lang (Jun 28 2017 at 20:40):
Hm, der hier sollte nicht valide sein: https://simplifier.net/LHITCSandbox/Patient-example342/~xml . Simplifier meint aber doch.
Simone Heckmann (Jun 28 2017 at 20:43):
Versteh ich nicht... was ist daran falsch:
line.extension('http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-postBox').empty() or line.exists()
Simone Heckmann (Jun 28 2017 at 20:43):
Das ist der gleiche Constraint wie bei Strasse und Hausnummer und da geht's doch auch...oder?
Stefan Lang (Jun 28 2017 at 20:47):
Hm, haben wir die schon getestet? ;)
Stefan Lang (Jun 28 2017 at 20:51):
Der hier validiert auch: https://simplifier.net/LHITCSandbox/Patient-example343/~xml
Sollte einen Fehler wg. add-4 werfen
Stefan Lang (Jun 28 2017 at 20:51):
Ich habe die leise Vermutung, dass das eher ein Problem in Simplifier ist. Mal prüfen
Simone Heckmann (Jun 28 2017 at 20:52):
Ich hab gerade versucht unsere Profile an test.fhir.org zu verfüttern, aber der mag die nicht :(
Simone Heckmann (Jun 28 2017 at 20:55):
Ich bin mir aber sicher, dass ich auf Simplifier schon mal eine Fehlermeldung wegen eines verletzen Constraints im Address-Profil gesehen habe, ich weiß nur nicht mehr, wie mein Testfall aussah...
Simone Heckmann (Jun 28 2017 at 20:55):
Ah warte, oder war das beim Namen!?!?
Stefan Lang (Jun 28 2017 at 20:56):
Ich hab gleich nen Testfall für add-2
Stefan Lang (Jun 28 2017 at 20:56):
Kann aber beim Namen gewesen sein
Stefan Lang (Jun 28 2017 at 20:57):
Der add-2-invalid-Test validiert ebenfalls: https://simplifier.net/LHITCSandbox/Patient-example345/~xml
Simone Heckmann (Jun 28 2017 at 20:59):
Äh. Unser HumanName-Profil hat gar keine Constraints mehr!?
Stefan Lang (Jun 28 2017 at 21:01):
Mal gucken, was Github dazu meint
Stefan Lang (Jun 28 2017 at 21:02):
Ich bin mir ziemlich sicher, dass wir in Madrid kurz gejubelt haben, als der erste Constraint ansprach. Und das war HumanName ...
Simone Heckmann (Jun 28 2017 at 21:02):
Hmm...ok. Aber ich glaube der Constrint ist unabhängig davon nicht korrekt.
Das Line-Attribut existiert ja, auch wenn es leer ist weil da ja die Extension drin steckt!
Line.exists() funktioniert hier nicht
Stefan Lang (Jun 28 2017 at 21:07):
Die HumanName-Constraints sind anscheinend nie im Github angekommen.
Aber: korrekt, exists() bringt nix.
Simone Heckmann (Jun 28 2017 at 21:07):
ich hab das jetzt in line.empty() geändert, aber die Beispiele validieren trotzdem immer noch
Stefan Lang (Jun 28 2017 at 21:09):
Versuch mal exists(f:*[starts-with(local-name(.), 'value')])
Stefan Lang (Jun 28 2017 at 21:11):
wobei das "starts-with"-Konstrukt wahrscheinlich oversized ist, das ist für value[x] gedacht. Sollte aber trotzdem funktionieren.
Simone Heckmann (Jun 28 2017 at 21:12):
also line='' tuts auch nicht
Stefan Lang (Jun 28 2017 at 21:13):
es ist ja auch nicht line, sondern line@value
Stefan Lang (Jun 28 2017 at 21:14):
[Ich hätte gern eine Session "FHIRpath für Dummies" in Amsterdam]
Simone Heckmann (Jun 28 2017 at 21:14):
Müsste doch gleiche Syntax sein wie hier:
verificationStatus='entered-in-error' or clinicalStatus.exists())
Simone Heckmann (Jun 28 2017 at 21:15):
http://hl7.org/fhir/condition.html#invs
Stefan Lang (Jun 28 2017 at 21:17):
aber wenn, dann line!=''
Stefan Lang (Jun 28 2017 at 21:19):
Schau Dir mal den Standard-Ausdruck ext-1 an:
<key value="ext-1" />
<severity value="error" />
<human value="Must have either extensions or value[x], not both" />
<expression value="extension.exists() != value.exists()" />
<xpath value="exists(f:extension)!=exists(f:*[starts-with(local-name(.), 'value')])" />
Simone Heckmann (Jun 28 2017 at 21:24):
klar, muss ja negiert werden!
Aber ich habe jetzt sowohl line.empty().not() bei street name als auch line!=" bei postfach zum testen
Simone Heckmann (Jun 28 2017 at 21:25):
Ich gebs auf. die validieren ALLE grrrr
Stefan Lang (Jun 28 2017 at 21:27):
Versuch doch mal:
extension('http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-postBox').exists() or value.exists()
Simone Heckmann (Jun 28 2017 at 21:30):
wir haben doch aber gar keine attribut das "value" heißt!?
Stefan Lang (Jun 28 2017 at 21:31):
Gnah! Wir haben ein XML-Attribut, aber kein XML-Element, das ein FHIR-Attribut ist :D
Stefan Lang (Jun 28 2017 at 21:32):
Stimmt natürlich, das "value" aus ext-1 ist ein XML-Element
Simone Heckmann (Jun 28 2017 at 21:34):
Die ursprüngliche Version folgt dem Konsens der Experten:
https://chat.fhir.org/#narrow/stream/conformance/topic/Need.20.20help.20with.20invariant.20on.20extensions
Simone Heckmann (Jun 28 2017 at 21:35):
Vielleicht ist es auch ein cache-Problem, dass das Validation-Tool die Änderungen so schnell nicht mitbekommt....?
Stefan Lang (Jun 28 2017 at 21:36):
Beim ersten fälschlichen "valid" hat er jedenfalls ziemlich lange gebraucht. Das sah nicht nach Caching aus.
Simone Heckmann (Jun 28 2017 at 21:44):
wie dem auch sei....ich mach Schluß für heute... vielleicht komme ich morgen drauf ...
Stefan Lang (Jun 28 2017 at 21:50):
Joah, Wachheit wäre gerade von Vorteil :D
Ich probiere morgen mal in Ruhe gegen den offiziellen Validator
Stefan Lang (Jun 29 2017 at 07:52):
Der offizielle Validator hält die invalid-examples add-2/add-3/add-4 auch alle für valide.
Simone Heckmann (Jun 29 2017 at 08:36):
Ich hab das Profil mit line.hasValue() aktualisiert
Simone Heckmann (Jun 29 2017 at 08:38):
...jetzt hängt sich der Validator auf 
Simone Heckmann (Jun 29 2017 at 08:39):
ah doch. Aber immer noch keine Fehlermeldung...
Stefan Lang (Jun 29 2017 at 11:52):
Ich hab gerade nochmal verschiedene Experimente gemacht: Constraint in der Hierarchie rauf und runter verschoben, Pfade in den Ausdruck ergänzt und wieder rausgenommen ... es validiert immer.
Und ich bin sicher, es ist am Ende ein ganz primitiver Bug. Wie immer.
Stefan Lang (Jun 29 2017 at 12:04):
Öhm, ich hatte gerade mal den Snapshot aus dem Profil rausgenommen und der Validator sagt mir:
"Differential contains path Address.line.extension which is not found in the base"
Stefan Lang (Jun 29 2017 at 12:04):
(deleted)
Stefan Lang (Jun 29 2017 at 12:17):
Mal abwarten, was an Antworten auf Simones Frage im conformance-Stream kommt.
Simone Heckmann (Jun 29 2017 at 19:32):
Hmpf.
Simone Heckmann (Jun 29 2017 at 19:32):
Man muss den Snapshot des Patient-Profils neu erzeugen.
Simone Heckmann (Jun 29 2017 at 19:35):
Jetzt funktionieren alle constraints:
https://simplifier.net/LHITCSandbox/Patient-example345/~xml
https://simplifier.net/LHITCSandbox/Patient-example342/~xml
https://simplifier.net/LHITCSandbox/Patient-example343/~xml
Ich habe nebenbei noch die Constraints von der Extension-Ebene auf die Address-Ebene gelüpft.
Ich weiß aber nicht, ob das ursächlich war.
Simone Heckmann (Jun 29 2017 at 19:48):
Übrigend habe ich eigenmächtig beschlossen, dass der Constraint auf Address.type bei Verwendung der Postfach-Extension nur eine Warnung und keinen Fehler ausgibt.
Ich finde, wenn die Address.line nicht gefüllt ist, dann ist das ein Programmier-Fehler, der jedem Entwickler sofort um die Ohren gehauen werden muss. Aber der falsche Address.type kann auf die fehlerhafte Eingabe eines Anwenders zurückzuführen sein. Ich denke nicht, dass FHIR diktieren sollte, ob und wie Benutzer-Eingaben zu validieren sind. Zumindest nicht, so lange wir uns auf einer UseCase-unabhängigen Ebene befinden.
Simone Heckmann (Jun 29 2017 at 19:50):
Hach. Endlich kann ich wieder ruhig schlafen. Ich hasse lose Enden!
Simone Heckmann (Jun 29 2017 at 19:52):
Erkenntnis des Tages: Bei der Snapshot-Generierung werden referenzierte Profile in den Snapshot eingebettet. 
Simone Heckmann (Jun 29 2017 at 19:54):
Können wir den hier damit schließen, oder müssen wir da noch was slicen?
https://github.com/hl7germany/basisprofil-de/issues/16
Simone Heckmann (Jun 29 2017 at 20:20):
...hat noch jemand was zu constrainen? Ich bin gerade im Flow... 
Stefan Lang (Jun 29 2017 at 20:20):
Also doch das Patient-Profil neu generieren? Sehr seltsam, der Diff gestern hat 0 Unterschiede gezeigt ... sei's drum.
Diese Sache mit den Snapshots nervt allerdings ein wenig. Ich hoffe, dass Simplifier bald differentials selbstständig zu Snapshots für die Ansicht verarbeiten kann ...
Stefan Lang (Jun 29 2017 at 20:21):
Die Constraints auf oberer Ebene finde ich OK, das passt.
Stefan Lang (Jun 29 2017 at 20:23):
Zu Issue 16: hast Du mal die ganzen Beispiele reviewed, ob die noch alle passen (speziell, da type jetzt quasi bedeutungslos ist?
Simone Heckmann (Jun 29 2017 at 20:25):
Auf oberer Ebene gefällt mir auch besser. Dann hat man eine schöne Übersicht, welche Regeln für ein Attribut gelten. Einzige Krux: Die location-Angabe beim Validierungsfehler ist dadurch etwas ungenau:
Instance failed constraint add-3 "Wenn diese Extension verwendet wird, muss auch Address.line gefüllt werden" Location: Patient.address[0]
Das lässt sich aber durch einen entsprechenden Fehlertext ausgleichen
Stefan Lang (Jun 29 2017 at 20:26):
Ich denke, die Fehlertexte zu individualisieren, dürfte das kleinste Problem sein :D
Simone Heckmann (Jun 29 2017 at 20:27):
Unsere Patient-Examples validieren alle
Mathias Aschhoff (Jun 29 2017 at 20:27):
Sehr schön, freut mich, dass ihr das hinbekommen habt. Wie schauts eigentlich aus wenn mir was auffällt, in github in den issue tracker oder hier rein?
Simone Heckmann (Jun 29 2017 at 20:29):
Wenns dir an unseren Profilen auffällt -> github
Wenns dir an der FHIR-Spezifikation auffällt -> gforge
Stefan Lang (Jun 29 2017 at 20:29):
Ich denke, offensichtliches kann gleich nach Github.
Inhaltliches oder prinzipielles (z.B. Dinge wie die OID vs. URL-Diskussion) sollte erst hier diskutiert werden
Stefan Lang (Jun 29 2017 at 20:31):
Wobei z.B. neue Issues zu patient-de-vsdm momentan relativ sinnfrei wären, weil das Profil einfach noch nicht nachgezogen wurde und ohnehin noch einige Probleme hat.
Simone Heckmann (Jun 29 2017 at 20:31):
Ich denke ein issue ist immer gut. Hier im Chat verliert man Themen gerne mal aus dem Blick. Das issue ist der reminder :)
Aber gerne zu jedem issue hier gleich auch einen Diskussions-Thread eröffnen, falls es noch keinen passenden gibt.
Stefan Lang (Jun 29 2017 at 20:32):
Oder so, gute Idee.
Mathias Aschhoff (Jun 29 2017 at 20:32):
Alles klar! Ich werd eh erstmal nur gucken, dass ich euren geistigen Kartoffelsalat verstehe bevor ich mir überhaupt anmaße da etwas rein zu schreiben ;-)
Stefan Lang (Jun 29 2017 at 20:33):
/me überlegt gerade, ob das Wort "Kartoffelsalat" positiv oder negativ belegt ist
Mathias Aschhoff (Jun 29 2017 at 20:33):
ist lecker, also natürlich positiv.
Mathias Aschhoff (Jun 29 2017 at 20:33):
Krautsalat mag ich nicht
Stefan Lang (Jun 29 2017 at 20:39):
OK, bei Krautsalat sind wir damit nicht semantisch interoperabel ;)
Stefan Lang (Jun 29 2017 at 20:40):
@Simone Heckmann Issue 16 würde ich noch offen lassen, weil für patient-de-vsdm das Adress-Slicing noch fehlt
Simone Heckmann (Jun 29 2017 at 20:42):
ok, ich war mir nicht mehr sicher, ob sich mit den constraints nicht schon die Notwendigkeit des Slicens erbrigt hatte..?
Stefan Lang (Jun 29 2017 at 20:45):
Ah stimmt, wir wollten ja dort nicht mehr slicen ... (Du hast Recht, man sollte an Dingen dran bleiben ...)
Dann werfe ich jetzt mal einen neuen Constraint in Deinen Flow:
Stefan Lang (Jun 29 2017 at 20:47):
add-5: wenn eine Adresse eine line mit streetName und/oder houseNumber hat, darf die Adresse keine line mit postBox haben und umgekehrt
Simone Heckmann (Jun 29 2017 at 20:50):
line.extension('http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-postBox').empty() or (line.extension('http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-streetName').empty() and line.extension('http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-houseNumber').empty())
Stefan Lang (Jun 29 2017 at 20:52):
Das wäre ein OR? wir brauchen ein XOR
Mathias Aschhoff (Jun 29 2017 at 20:53):
schließt or eine "und" verknüfung aus? Sodass nicht beides leer sein kann?
Stefan Lang (Jun 29 2017 at 20:53):
nee or === logisches OR, or !== XOR
Stefan Lang (Jun 29 2017 at 20:55):
Ach nee, Moment, das ist ja ein empty(). D.h. für TRUE muss mindestens eines leer sein. Also korrekt.
Simone Heckmann (Jun 29 2017 at 20:55):
Nö. m.E. passt das so. Damit der Constraint keinen Error auswirft muss der Ausruck "true" ergeben.
Also Postfach gefüllt, Str/Hnr leer -> false or (true and true) -> true
Str/Hnr gefüllt, Postfach leer -> true (false and false) -> true
Stefan Lang (Jun 29 2017 at 20:55):
Und wenn beide leer ist, ist es auch gut.
100% passend.
Stefan Lang (Jun 29 2017 at 20:56):
hm, empty() oder exists() ?
Simone Heckmann (Jun 29 2017 at 20:57):
empty() dürfte true sein sowohl wenn die extension nicht vorhanden ist als auch wenn sie vorhanden aber leer ist.
Simone Heckmann (Jun 29 2017 at 20:57):
Also in unserem Fall immer korrekt.
Simone Heckmann (Jun 29 2017 at 20:58):
Das Einbauen ins Profil überlasse ich Dir :)
Stefan Lang (Jun 29 2017 at 20:58):
Formal wäre ich für exists(). Eine leere Extension ist ja schon durch ele-1 abgedeckt
Simone Heckmann (Jun 29 2017 at 20:59):
müssten wir aber negieren. exists().not() ist irgendwie doof
Stefan Lang (Jun 29 2017 at 21:00):
Ei gut.
Ich werf's erstmal in issue 16 rein. Wenn mir gestern Abend eines gezeigt hat, dann wiedereinmal, dass ich nach 23:00 nicht versuchen sollte, zu denken oder zu coden :D
Mathias Aschhoff (Jun 29 2017 at 21:00):
Das ist wirklich ein 1ste Welt Problem. empty() ist doch top
Simone Heckmann (Jun 29 2017 at 21:01):
Das empty() kommt auch vom Meister: https://chat.fhir.org/#narrow/near/77892/stream/conformance/topic/Need.20.20help.20with.20invariant.20on.20extensions
Allerdings muss das nix heißen. Der zweite Teil des Ausdrucks war nämlich auch falsch :D
Mathias Aschhoff (Jun 29 2017 at 21:01):
hab mir nebenbei noch http://hl7.org/fhirpath/ - krasses Werkzeug. Weiterhin frohes schaffen! @Simone Heckmann bis morgen ;-)
Simone Heckmann (Jun 29 2017 at 21:01):
Gute Nacht! Bis morgen!
Stefan Lang (Jun 29 2017 at 21:02):
GN8 Mathias :)
Stefan Lang (Jun 29 2017 at 21:04):
@Simone Heckmann Man muss seine Meister immer mal hinterfragen :joy:
Stefan Lang (Jun 29 2017 at 21:31):
Zu Adresse fehlt uns noch eine Extension und Constraints, vgl. Kommentar in https://github.com/hl7germany/basisprofil-de/issues/7
Simone Heckmann (Jun 30 2017 at 04:29):
ähm... der Constraint für Postfach <> Str/HNr kann doch eigentlich als Warning ins Basisprofil, oder?
Im VSDM müsste dann nur die Severity erhöht werden (wenn das geht...)
Ah. Und so langsam dämmert mir auch warum die Profile der Datentypen im Snapshot eingebettet sind. Man kann im Profil der Resource ja auch die Datentypen weiter einschränken!!
Simone Heckmann (Jun 30 2017 at 04:58):
Adresszusatz sowie die weiteren Constraints sind drin...
Stefan Lang (Jun 30 2017 at 07:01):
Mit Warning bin ich erstmal glücklich.
Stefan Lang (Jul 11 2017 at 12:11):
Man kann im Profil der Resource ja auch die Datentypen weiter einschränken!!
@Simone Heckmann Hast Du gerade mal nen Tipp, wie das per Forge geht?
Stefan Lang (Jul 18 2017 at 13:44):
Zum Thema Address.country (https://github.com/hl7germany/basisprofil-de/issues/1):
=> https://chat.fhir.org/#narrow/stream/conformance/topic/ValueSet.20binding.20for.20string.20elements.3F
Stefan Lang (Jul 18 2017 at 17:03):
Und noch einen systematischen Bug im größeren Teil unserer Constraints gefunden + gefixt: https://github.com/hl7germany/basisprofil-de/issues/19
Zur allgemeinen Information: wenn ein Element mehrfach vorkommen kann, muss man die Constraint-Ausdrücke nochmal klammern, z.B. mittels all(). Beispiel:
line.all($this.extension('http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-houseNumber').empty() or $this.hasValue())
Stefan Lang (Jul 18 2017 at 17:04):
Die HumanName.family Constraints waren nicht betroffen, da family = 0..1
Mino Nordmann (Feb 21 2022 at 22:09):
Hallo, ich habe ein Problem mit der Erstellung mit Poco einer Extension. Gibt es eine Möglichkeit, dies zu erreichen ohne Umwege? ich erstelle die Extension, kann diese aber nicht zu >Adress.line< adden. Vielen Dank
Mit freundlichen Grüßen
Michael Nordmann
<address>
<line value="Musterstraße 1">
<extension url="http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-houseNumber">
<valueString value="1" />
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-streetName">
<valueString value="Musterstraße" />
</extension>
</line>
<city value="Musterstadt" />
<postalCode value="77777" />
<country value="DE" />
</address>
Patrick Werner (Feb 22 2022 at 16:06):
Die eigentliche Frage wird leider nicht direkt klar.
Patrick Werner (Feb 22 2022 at 16:06):
Wie man diese Extensions nutzt kann man hier schön sehen:
https://simplifier.net/basisprofil-de-r4/patient-example-address
Patrick Werner (Feb 22 2022 at 16:07):
das obige Beispiel sieht erstmal korrekt aus.
Patrick Werner (Feb 22 2022 at 16:08):
Wie man das mittels der .net library baut findet man hier: https://docs.fire.ly/projects/Firely-NET-SDK/model/extensions.html?highlight=extension#extensions
Last updated: Apr 12 2022 at 19:14 UTC
