Stream: DIT-Community-a-thon
Topic: Adressen
Lars Heyden (Oct 27 2020 at 11:01):
Gibt es klare Empfehlungen, wann Adressangaben auf mehrere lines aufgeteilt werden sollen? Gemäß KBV soll der Adresszusatz in einer separaten line stehen - angeblich aufgrund von Vorgaben seitens HL7
Simone Heckmann (Oct 27 2020 at 11:17):
Im Prinzip gelten die Empfehlungen der Deutschen Post. Allerdings ist mir soeben aufgefallen, dass sowohl MI-I als auch ISIK die Anzahl der Lines auf 1..1 begrenzen, während die KBV bis zu zwei Zeilen zulässt.
Simone Heckmann (Oct 27 2020 at 11:17):
Diese Beschränkung bei MI-I und ISIK wäre in Frage zu stellen...
Kilian Krockauer (Oct 27 2020 at 11:21):
EDIT:
Halt. Hatte noch das KBV mit drin. Wenn ich nur das ISIK drin habe, meckert er. Jetzt ist die Frage, warum es bei dem doppelten Profil keine Einwände seitens des Validators gibt.
Patrick Werner (Oct 27 2020 at 11:24):
Ich habe es eben gegengetestet: ERROR: Instance count for 'Patient.address.line' is 2, which is not within the specified cardinality of 1..1
Patrick Werner (Oct 27 2020 at 11:24):
Bekomme ich direkt sobald mehr als eine line existiert
Kilian Krockauer (Oct 27 2020 at 11:25):
Ja, hatte noch das KBV-Profil mit drin. Aber warum meckert er nicht, wenn beide Profile drin sind? Sollte er doch, oder verstehe ich das falsch?
Patrick Werner (Oct 27 2020 at 11:26):
Doch sollte er, macht er auch bei mir. Ich validier mit dem Java Code gegen den VONK Server
Patrick Werner (Oct 27 2020 at 11:26):
also per REST
Patrick Werner (Oct 27 2020 at 11:27):
Wenn mehrer profile angegeben werden wird gegen alle profile validiert.
Kilian Krockauer (Oct 27 2020 at 11:27):
Ja, das dachte ich auch. Aber anscheinend ist die Reihenfolge der Angabe der Profile wichtig. Tauschen Sie mal die Reihenfolge.
Lars Heyden (Oct 27 2020 at 11:30):
Es ist ja an sich eine nette Idee, wenn Adressangaben auf mehrere lines aufgeteilt werden können - aber ist das in der Praxis bei maschineller Verarbeitung nicht eher von Nachteil, wenn nicht klar ist in welcher line welche Information steht? Ich finde daher die Einschränkung auf 1..1 sehr nachvollziehbar.
Lars Heyden (Oct 27 2020 at 11:31):
Es sei denn, es ist schon durch das Profil klar vorgegeben, welche Information in welcher line stehen darf.
Kilian Krockauer (Oct 27 2020 at 11:31):
Habe meinen Fehler gefunden. Funktioniert so wie es sollte :+1:
Kilian Krockauer (Oct 27 2020 at 11:32):
@Lars Heyden vor allem, da es ja die Extension dafür schon gibt. Da sollte die KBV mal überlegen, das zu übernehmen, oder?
Patrick Werner (Oct 27 2020 at 11:33):
Lars Heyden said:
Es ist ja an sich eine nette Idee, wenn Adressangaben auf mehrere lines aufgeteilt werden können - aber ist das in der Praxis bei maschineller Verarbeitung nicht eher von Nachteil, wenn nicht klar ist in welcher line welche Information steht? Ich finde daher die Einschränkung auf 1..1 sehr nachvollziehbar.
ich persönlich sehe das ebenso. Solange ich die lines nicht unterschiedlich codiere macht eine aufsplitten in mehrere Lines wenig Sinn.
Lars Heyden (Oct 27 2020 at 11:33):
Im KBV-Profil für die eAU ist zudem die Straße ein Pflichtfeld in jeder line, das ergibt dann ganz sicher keinen Sinn...
Patrick Werner (Oct 27 2020 at 11:34):
Das aufsplitten der Lines für einen Briefbogen wäre für mich business-logic, und damit außerhalb von FHIR.
Simone Heckmann (Oct 27 2020 at 11:35):
Lars Heyden said:
Es ist ja an sich eine nette Idee, wenn Adressangaben auf mehrere lines aufgeteilt werden können - aber ist das in der Praxis bei maschineller Verarbeitung nicht eher von Nachteil, wenn nicht klar ist in welcher line welche Information steht? Ich finde daher die Einschränkung auf 1..1 sehr nachvollziehbar.
Im Prinzip sagt die Aufteilung in lines bloß: "Drucke das so auf's Kuvert", das ist ja in den häufigsten Fällen der Grund, weshalb man Adressdaten austauscht. Wenn die Semantik wichtig ist, weil z.B. die Hausnummer anders behandelt werden soll als andere Teile der line, dann müssen die Extensions verwendet werden.
Solche UseCases sind aus meiner Sicht aber eher rar.
Lars Heyden (Oct 27 2020 at 11:36):
Alles klar, danke für die Einschätzung.
Simone Heckmann (Oct 27 2020 at 11:36):
Ich hatte mir immer vorgestellt, dass jemand versuchen könnte, die Verteilung von Patienten auf einer Karte zu plotten, und dazu die Trennung von Straße und Hausnummer benötigt, aber dann ist mir eingefallen, dass nicht mal die Google Maps API eine strukturierte Trennung erfordert.
:grinning_face_with_smiling_eyes:
Simone Heckmann (Oct 27 2020 at 11:37):
Ich schätze in DE ist das einfach ein Fall von "Das haben wir schon immer so gemacht".
Alexander Zautke (Oct 27 2020 at 12:05):
Da die Informationen auch in die Extensions aufgeteilt werden können, wurde sich entschieden alles einheitlich in eine line zu schreiben.
Simone Heckmann (Oct 27 2020 at 12:08):
Also im schlimmsten Falle
Milchstr. 42 Appartment 345b c/o Familie Mustermann :oh_no:
Simone Heckmann (Oct 27 2020 at 12:13):
Ich glaube ich hätte es schöner gefunden, wenn das sendende System zumindest die Möglichkeit hätte, eine sinnvolle Unterteilung in Zeilen vorzuschlagen. Wenn das Zielsystem keine mehrzeiligen Adressen unterstützt, kann es ja die Zeilen immer noch konkatenieren, aber man müsste zumindest nicht raten, wo eine sinnvolle Trennung stattfinden könnte, wenn die Zeile zu lang wird für den Druck. Wenn man's anhand fester Längen aufsplitten würde, käme dann solcher Quark bei raus:
Milchstr. 42 Appartment
345b c/o Familie Musterman
Simone Heckmann (Oct 27 2020 at 12:16):
m.E. widerspricht das ein wenig der 80%-Regel
einfaches Problem -> einfache Lösung
komplexes Problem -> komplexe Lösung
Das einfache Problem (80%) ist: Ich will die Adresse drucken ohne herumzuraten, wie ich die einzelnen Bestandteile zusammensetzen/aufsplitten muss -> line 0..*
Das komplexe Problem (20%) ist: Ich muss die einzelnen Adressbestandteile unterschiedlich behandeln/gewichten -> extensions
Simone Heckmann (Oct 27 2020 at 12:17):
In diesem Fall ist der einfach UseCase eingeschränkt mit dem Argument: "nimm doch die komplexe Lösung",
daher :oh_no:
Lars Heyden (Oct 27 2020 at 12:22):
Das Problem ist, dass die Extensions Bestandteil der lines sind. Vielleicht wäre es am Besten gewesen, die Extensions an die Adressen zu definieren. Dann gäbe es pro Adresse genau eine Straße und Hausnummer, und nicht eine Straße pro line.
Simone Heckmann (Oct 27 2020 at 12:24):
...das stünde dann aber im Widerspruch zu der internationalen Definition der Extensions... So weit wollen wir uns dann doch nicht aus dem Fenster lehnen ;-)
Simone Heckmann (Oct 27 2020 at 12:26):
Ich denke aber, dass es seitens der Implementierung unproblematisch wäre.
Man kann recht einfach festlegen:
Strasse+Hausnummer - > line 1
Adresszusatz-> line 2
und die Extensions dann entprechend an die jeweiligen lines hängen
Andersherum sollte es Möglichkeiten geben, auf z.B. die Inhalte der Hausnummer-Extension zugreifen zu können, ohne wissen zu müssen, an welcher line sie hängt (@Patrick Werner ?)
Lars Heyden (Oct 27 2020 at 12:27):
und die Extensions dann entprechend an die jeweiligen lines hängen.... geht das tatsächlich, dass für line 1 andere Extensions vorgegeben sind als für line 2 ?
Patrick Werner (Oct 27 2020 at 12:27):
Simone Heckmann said:
Strasse+Hausnummer - > line 1
Adresszusatz-> line 2
mit dieser Guidance :+1:
Simone Heckmann (Oct 27 2020 at 12:27):
...zumindest die entsprechende FHIRPath-Expression Patient.address.line.extension(http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-houseNumber) sollte immer die Hausnummer zurückliefern, unabhängig davon, an welcher line sie hängt...
Simone Heckmann (Oct 27 2020 at 12:29):
Lars Heyden said:
und die Extensions dann entprechend an die jeweiligen lines hängen.... geht das tatsächlich, dass für line 1 andere Extensions vorgegeben sind als für line 2 ?
Wir müssten line dafür slicen, aber:ja.
Alternativ könnte man einfach an allen lines alle drei Extensions zulassen, aber mit Hilfe einer Regel (Constraint) prüfen, dass die Extensions nicht doppelt verwendet werden dürfen.
Patrick Werner (Oct 27 2020 at 12:30):
In Java (oder anderen Sprachen) würde man mittels streaming API auch entsprechend auf die extension filtern.
Diese Pattern benötigt man recht häufig in FHIR, z.b. auch bei "Gib mir eine spezifische Resource(definiertes Profil) aus einer Composition.
Mit filter und AnyMatch geht das fast so komfortabel wie mit FHIRpath. FHIRpath für Java ist leider noch nicht feature-complete
Lars Heyden (Oct 27 2020 at 12:35):
ok! Besten Dank für die Antworten.
Last updated: Apr 12 2022 at 19:14 UTC
