Stream: german (d-a-ch)
Topic: HumanName Prefix
Simone Heckmann (Oct 28 2016 at 09:41):
@Patrick Werner : Bezüglich des EGK-Feldes für das Namesprefix:
Das riecht nach "ChangeRequest". LAss uns hier mal darüber diskutieren, was wir brauchen/wollen...
Simone Heckmann (Oct 28 2016 at 09:42):
Kannst du das Problem nochmal kurz schildern, damit alle verstehen worum es geht...?
Simone Heckmann (Oct 28 2016 at 09:45):
Die Beispiele für HumanName sehen für den Namensvorsatz "van" eine Extenson vor:
http://build.fhir.org/extension-iso21090-en-qualifier.html
pasted image
Simone Heckmann (Oct 28 2016 at 09:47):
Kurioserweise ist der Wert "VV" im Beispiel gar nicht Bestandteil des ValueSets in der Extension
Stefan Lang (Oct 28 2016 at 09:56):
.. aber im FHIR-ValueSet:
http://hl7.org/fhir/v3/EntityNamePartQualifier/index.html
Simone Heckmann (Oct 28 2016 at 09:59):
...folglich würde ein ChangeRequest dahingehend, dass die o.g. Extension an das o.g. V3-ValueSet gebunden werden sollte, sowohl das Example validieren als auch unseren UseCase befriedigen...?
Simone Heckmann (Oct 28 2016 at 15:40):
Oh, sorry. Ich hatte gar nicht gesehen, dass es schon einen Stream gibt: https://chat.fhir.org/#narrow/stream/implementers/topic/http.3A.2F.2Fhl7.2Eorg.2Ffhir.2FStructureDefinition.2Fiso21090-EN-qualifie
Simone Heckmann (Oct 29 2016 at 07:58):
Behaupte ich etwas falsches, wenn ich sage, dass die meisten Systeme das Vorsatzwort als PREFIX erfassen? Ich habe versucht ein paar Eingabemasken zu googeln und das scheint mit die übliche Vorgehensweise zu sein. Wobei der Titel in einem separaten Feld erfasst wird.
Stefan Lang (Oct 29 2016 at 11:29):
@Grahame Grieve If your line in the "Leistungserbringer" thread was supposed to address the HumanName prefix issue:
Possibly Michael "the big" Ballack, too. But mainly Herman "van" Veen ;-)
Stefan Lang (Oct 29 2016 at 11:42):
@Simone Heckmann Im Prinzip ja. Woraus man schließen könnte, dass eigentlich der Titel Extension-würdig wäre und nicht das Vorsatzwort.
Allerdings ist in FHIR der Begriff Prefix anders gefasst ("Parts that come before the name").
Der Titel kommt in Deutschland tatsächlich vor dem Namen. Das Vorsatzwort kommt vor dem Nachnamen.
Ein System, das einen vollständigen Namen aus einem HumanName zusammensetzen wollte und die Extension nicht kennt, könnte sonst z.B. einen "Dr. van Herman Veen" generieren.
HumanName.text hilft für die korrekte Sortierung der Bestandteile insofern nicht weiter, als kein System, das ich kenne, den kompletten Namen nochmal separat ablegt.
Simone Heckmann (Oct 29 2016 at 15:16):
Ja. Einverstanden. Die Reihenfolgen-Problematik hat mich auch gestört. Also wollen wir tendendentiell die Aufnahme von "VV" oder einem gleichbedeutenden Code in das ValueSet für die Extension um dann den Datentyp HumanName.family damit zu erweitern...?
@Patrick Werner : Ich erinnere mich dunkel, dass du in deinem Vortrag erwähntest, diese Extension zu benutzen wäre umständlich, weil man Slicing benötigt. oder habe ich das falsch verstanden? Weil, wenn ich es richtig verstanden habe dann habe ich's nicht verstanden ;-)
Simone Heckmann (Oct 29 2016 at 15:19):
Eigentlich würde es ja genügen, das Attribut zu extenden. Den Anspruch, im Profil einschränken zu wollen, dass nur die erste Wiederholung von "family" die Extension verwenden darf, hätte ich gar nicht. Man kann ja auch mehrere Vorsätze haben... "von der Leyen", z.B.
Simone Heckmann (Oct 29 2016 at 15:29):
Das wäre doch mal eine schöne Übung für's "Best Practice": Durchgeknallte Namen modellieren:
Prof. Dr. Dr. Hans-Joachim "Hajo" van der Waals Gonzales der Jüngere MdB
Simone Heckmann (Oct 29 2016 at 15:37):
Ah. Jetzt hab ich endlich die entsprechende Spezifikation von V2 gefunden, zusammen mit nützlichen Hinweisen zur eGK:
http://wiki.hl7.de/index.php?title=HL7v2-Profile_gemeinsame_Elemente
Simone Heckmann (Oct 29 2016 at 15:37):
Kapitel "XPN.1: FN – Family Name"
Simone Heckmann (Oct 29 2016 at 16:00):
Interessant:
"Für die Übermittlung des Namenszusatzes (bspw. "Baron" oder "Prinz") und der Vorsatzworte (bspw. "auf der", "von") reicht diese Unterteilung nicht aus. Auf der eGK sind diese Informationen getrennt, auf der KVK durch Leerzeichen getrennt in einem Feld. Dies wird über den Präfix des Nachnamens abgebildet. Dazu werden der Namenszusatz und das Vorsatzwort von der eGK in dieser Reihenfolge durch ein Leerzeichen getrennt in FN.1.2 (Own Surname Prefix) geschrieben:
Beispiel 2: Herr Otto Graf Lambsdorff
Graf Lambsdorff&Graf&Lambsdorff^Otto^^^^^L^A^^^G
"
Ich hätte jetzt unter NamensZUSATZ auf der eGK eher so etwas wie "der Jüngere", "senior" oder "MdB" erwartet. Also etwas, was HINTER dem Familiennnamen steht. Laut diesem Beispiel wäre der "Graf" aber ein Namenszusatz und stünde VOR dem Nachnamen. Jetzt bin ich komplett verwirrt...
Simone Heckmann (Oct 29 2016 at 16:03):
Tatsache: der Namenszusatz steht ebenfalls VOR dem Nachnamen:
"Der Name des Versicherten wird in der natürlichen Schreibweise und Reihenfolge
auf die Karte gedruckt: Titel Vorname Namenszusatz/Vorsatzwort Familienname"
https://www.gematik.de/cms/media/dokumente/release_0_5_3/release_0_5_3_egk/gematik_eGK_Spezifikation_Teil3_V2_1_0.pdf
Simone Heckmann (Oct 29 2016 at 16:09):
...also wäre auch der Namenszusatz in FHIR ein Bestandteil von family mit einem Qualifier. Dafür bräuchten wir also auch einen Code.
Stefan Lang (Oct 29 2016 at 16:09):
d'accord
Simone Heckmann (Oct 29 2016 at 16:10):
NB ( nobility) würde für das konkrete Beispiel passen, wäre semantisch aber nicht deckungsgleich mit dem NAMENSZUSATZ auf der eGK
Stefan Lang (Oct 29 2016 at 16:10):
! genau
Stefan Lang (Oct 29 2016 at 16:10):
und: Dr. Fritz Graf von Müller m.d. geht per Definitionem der eGK z.B. nicht. Das wäre dann bestenfalls Dr. m.d. Fritz Graf von Müller
Armin Gayl (Oct 29 2016 at 16:11):
mDB ist ein Arbeitstitel
Simone Heckmann (Oct 29 2016 at 16:11):
Außerdem stört es mich, dass sämtliche Systeme, die die Extension nicht kennen, den Otto unter "G" einsortieren würden
Armin Gayl (Oct 29 2016 at 16:12):
also eher ein Berufstitel wie Steuerberater StB
Stefan Lang (Oct 29 2016 at 16:12):
@Armin Gayl ist richtig, und daher tendenziell nirgend gespeichert/übermittelt. Aber z.B. der m.d. ist ein US-Titel, den auch Deutsche tragen können (oder in Deutschland behandelte US-Bürger)
Stefan Lang (Oct 29 2016 at 16:14):
Aber gut, wenn die eGK das nicht braucht, müssen wir uns vielleicht erstmal nicht den Kopf über das in Deutschland fehlende Suffix zerbrechen.
Stefan Lang (Oct 29 2016 at 16:17):
@Simone Heckmann hm, wie verhält sich das empfangende System, wenn es mehrere family-Attribute bekommt?
Simone Heckmann (Oct 29 2016 at 16:17):
Karl-Heinz Graf von Dracula
<family value="Graf"> <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier" > <valueCode value="NB" /> </extension> </family> <family value="von"> <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier" > <valueCode value="VV" /> </extension> </family> <family value="Dracula" /> <given value = "Karl-Heinz"/>
ein System, das die Extensions ignoriert ,würde lesen:
<family value="Graf"/> <family value="von"/> <family value="Dracula" /> <given value = "Karl-Heinz"/>
Daraus ergäbe sich der Nachname "Graf von Dracula" mit Einsortierung unter "G".
Begeistert mich nur so mittel... 
Stefan Lang (Oct 29 2016 at 16:19):
Können wir beim Slicing die Reihenfolge erzwingen?
Stefan Lang (Oct 29 2016 at 16:20):
Also so:
<family value="Dracula" /> <family value="Graf"> <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier" > <valueCode value="NB" /> </extension> </family> <family value="von"> <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier" > <valueCode value="VV" /> </extension> </family> <given value = "Karl-Heinz"/>
Stefan Lang (Oct 29 2016 at 16:22):
Weil dann wäre es für das non-aware-System zumindest in der Hinsicht korrekt
Simone Heckmann (Oct 29 2016 at 16:22):
Du meinst, dass der sortierrelevante Teil des Namens immer zuerst genannt werden soll? Aber wie sollen die Systeme dann wissen, wie Sie den Namen zur korrekten Anzeige wieder zusammenbauen müssen? Die Reihenfolge "Graf von Dracula" ist ja korrekt, also würde ich das schon so übermitteln wollen. Sonst bekommt der Patient später Anschreiben in denen "Sehr geehrter Herr Dracula von Graf" steht. Auch nicht cool.
Simone Heckmann (Oct 29 2016 at 16:24):
Korrekte Anzeige > Korrekte Sortierung (IMHO)
Stefan Lang (Oct 29 2016 at 16:24):
Genau das meine ich. Einen der beiden Tode müssen wir aber wohl sterben, entweder Sortierung oder Reihenfolge.
Stefan Lang (Oct 29 2016 at 16:26):
Ich sag's mal so: viele Systeme (zumindest Subsysteme) kennen nicht mal das Vorsatzwort.
Die schreiben dann den Graf in Titel und das Vorsatzwort in den Nachnamen - und dann ist die Sortierung eh falsch
Stefan Lang (Oct 29 2016 at 16:26):
Insofern: d'accord, Reihenfolge > Sortierung
Simone Heckmann (Oct 29 2016 at 16:26):
In dem Fall würde ich auf die Sortierung verzichten. Die spielt ja en nur dann eine Rolle, wenn man Listen auf Papier ausdruckt...wer macht denn sowas??
Simone Heckmann (Oct 29 2016 at 16:28):
Außerdem: Wenn sich bei irgendeinem Hersteller die Kunden über die falsche Sortierung beschweren, dann kann dieser ja immer noch die Extension implementieren
Simone Heckmann (Oct 29 2016 at 16:28):
Bleibt das Problem eines semantisch äquivalenten Qualifiers für den Namenszusatz...
Stefan Lang (Oct 29 2016 at 16:29):
Jup, irgendwo müsste dann auch der Hersteller mal was tun, wenn wir es schon spezifieren ;-)
Stefan Lang (Oct 29 2016 at 16:29):
Das Problem ist, dass der Namenszusatz schon semantisch unsauber ist ...
Simone Heckmann (Oct 29 2016 at 16:30):
Wenn man wüsste, was außer einem Adelstitel da noch vorkommen könnte... Also mir fällt spontan nichts ein...
Stefan Lang (Oct 29 2016 at 16:31):
Künstlernamen?
Stefan Lang (Oct 29 2016 at 16:31):
Michael "the big" Ballack z.B.?
Simone Heckmann (Oct 29 2016 at 16:31):
:D
Stefan Lang (Oct 29 2016 at 16:32):
Auf dem Perso sind sie drauf
Stefan Lang (Oct 29 2016 at 16:32):
Muss doch irgendwo in der Spez. stehen ...
Simone Heckmann (Oct 29 2016 at 16:34):
Ich finde nichts...
Außer einem Beispiel, aber das wäre auch wieder aus der Serie "Nobility":
https://de.wikipedia.org/wiki/Datei:Krankenversichertenkarte_2009_VS.svg
Stefan Lang (Oct 29 2016 at 16:37):
Die muss es geben. In Teil 3, den Du oben verlinkt hast, wird ja nur darauf Bezug genommen. Also muss doch irgendwo anders beschrieben sein, wie lang z.B. ein Nachname sein darf usw.
Stefan Lang (Oct 29 2016 at 16:48):
https://www.gematik.de/cms/media/dokumente/release_0_5_3/gemSchema_VSDM_5_2_V130.pdf
Simone Heckmann (Oct 29 2016 at 16:49):
Ja, da war ich auch schon. Das Dokument geht aber anscheinend davon aus, dass der Begriff Namenszusatz selbsterklärend ist ;-)
Stefan Lang (Oct 29 2016 at 16:50):
Wollte gerade schreiben: sagt auch nix zur Bedeutung aus :D
Stefan Lang (Oct 29 2016 at 16:51):
Frag doch mal Christoph. Der sollte eigentlich zumindest wissen, wo man's findet (wenn es irgendwo steht)
Stefan Lang (Oct 29 2016 at 17:02):
Die KBV hat immerhin ein Mapping dafür: ftp://ftp.kbv.de/ita-update/Abrechnung/KBV_ITA_VGEX_Mapping_KVK.pdf
und verweist für Ausprägungen auf Anlage 7 DEÜV ...
Stefan Lang (Oct 29 2016 at 17:03):
Simone Heckmann (Oct 29 2016 at 17:04):
Ja, mache ich.
Aber nochmal zurück zu V2, da wurde das exakt gleiche Thema ja offensichtlich schon mal diskutiert:
"[...]Dazu werden der Namenszusatz und das Vorsatzwort von der eGK in dieser Reihenfolge durch ein Leerzeichen getrennt in FN.1.2 (Own Surname Prefix) geschrieben:
Beispiel 2: Herr Otto Graf Lambsdorff
Graf Lambsdorff&Graf&Lambsdorff^Otto^^^^^L^A^^^G
"
Übertragen auf unser Beispiel wäre das dann
Graf von Dracula&Graf von&Dracula^Karl-Heinz^^^^^L^A^^^G
Systeme, die hier also die V2-Subsubkomponenten nicht auslesen (also die meisten), sind genau so doof wie FHIR-Systeme, die keine Extensions implementieren und würden nur das erste Feld lesen, ergo Einsortierung unter "G" aber richtige Darstellung.
Das Round-Tripping würde hier auch nicht funktionieren, da ich auf dem Rückweg nicht mehr unterscheiden kann, was mal Vorsatzwort und was Namenszusatz war. Also vielleicht machen wir uns viel zu viele Gedanken. Ist es denn wirklich so wichtig, dass wie die eGK-Original-Datenstruktur wiederherstellen könnten? Was wäre denn der UseCase....?
Stefan Lang (Oct 29 2016 at 17:04):
ist 100% Nobility
Simone Heckmann (Oct 29 2016 at 17:05):
Stefan Lang (Oct 29 2016 at 17:05):
Thema geklärt? :D
Simone Heckmann (Oct 29 2016 at 17:06):
Hach, was hätten wir Lebenszeit sparen können, wenn das Feld einfach "Adelstitel" geheißen hätte :D
Simone Heckmann (Oct 29 2016 at 17:06):
Aber war auch so ein schöner Abend ;-)
Stefan Lang (Oct 29 2016 at 17:06):
Es gibt auch ne Anlage für die VVs: https://www.vdek.com/content/vdeksite/vertragspartner/arbeitgeber/deuev/_jcr_content/par/download_7/file.res/Anlage_06_Vers.pdf
Stefan Lang (Oct 29 2016 at 17:06):
Jaja, "Das ist unsere Freizeit, und die ist knapp" ;,D
Simone Heckmann (Oct 29 2016 at 17:07):
Ja, die Liste hatte ich lustigerweise heute morgen schon gefunden. Google ist anscheinend auch manchmal launisch...
Stefan Lang (Oct 29 2016 at 17:08):
Didum ...
Naja, jedenfalls gut, dass sich Leute da schon mal mit befasst haben :D
Simone Heckmann (Oct 29 2016 at 17:12):
Also dann fassen wir mal den Abend zusammen:
WIr brauchen die ISO-Extension als Qualifier für HumanName.family
Das Mapping der EGK wäre dann
Namenszusatz -> family (NB)
Vorsatzwort -> family(VV)
Nachname -> family (ohne Qualifier)
Unser Change Request wäre folglich darauf beschränkt, den Code "VV" oder einen äquivalenten Code in das ValueSet http://hl7.org/fhir/valueset-name-part-qualifier.html aufzunehmen.
Stefan Lang (Oct 29 2016 at 17:13):
So sei es 
Simone Heckmann (Oct 29 2016 at 17:14):
Amen.
Stefan Lang (Oct 29 2016 at 17:16):
Sie hörten das Wort zum Sonntag (scnr)
Simone Heckmann (Oct 29 2016 at 17:22):
What's in a name? that which we call a rose
By any other name would smell as sweet;
Simone Heckmann (Oct 29 2016 at 17:43):
Nachtrag:
Titel -> Prefix (das wurde übrigens bereits in V2 so gemapped, da in Deutschland der Titel VOR dem Vornamen stehen muss)
Patrick Werner (Oct 31 2016 at 10:42):
sorry ich hatte ein Offline Wochenende, ich denke der Hauptdiskussionsthread ist der englische: https://chat.fhir.org/#narrow/stream/implementers/subject/http.3A.2F.2Fhl7.2Eorg.2Ffhir.2FStructureDefinition.2Fiso21090-EN-qualifie hier habe ich gerade auch kommentiert.
Wenn wir VV als Extension auf family name modellieren wird es schwierig beim Profilieren: Um 0..1 für VorsatzWort und 1..1 für Nachname zu profilieren müsste man slicen.
Ich sehe hier nur die Extension als möglicher Discriminator. Der normale Nachname hat aber keine Extension. Ich warte aktuelle auf Feedback im englischen Thread von profilierungsprofis wie man dies lösen könnte.
Patrick Werner (Oct 31 2016 at 10:52):
@Simone Heckmann Anmerkung zu der Abendzusammenfassung: Ich habe in EGKfeuer Namenszusatz auf Patient.name.suffix gemappt. Das fand ich eindeutiger als family mit NB Qualifier. Namenszusatz ist auch nicht zwangsläufig ein Adelstitel, sondern auch etwas wie MdB oder M.D.
Patrick Werner (Oct 31 2016 at 10:52):
Adelstitel wie Sir oder Graf wäre für mich ein prefix des Namens
Patrick Werner (Oct 31 2016 at 10:55):
Künstlernamen wären ein kompletter zweiter Namen mit dem use "usual" der richtige Name hätte "official"
Stefan Lang (Oct 31 2016 at 11:01):
@Patrick Werner Gibt's für den MdB oder m.d. als Namenszusatz eine Quelle?
Das einzige, was wir gefunden hatten, war letztlich die Referenz auf die DEÜV Anlage 7 => "Tabelle der gültigen Namenszusätze", und das sind ausschließlich Adelstitel.
Simone Heckmann (Oct 31 2016 at 11:05):
Namenszusatz (eGK) -> Suffix (FHIR) geht m.M.n. nicht, da in FHIR ausdrücklich steht, dass Suffix HINTER dem Nachnamen steht, während die Darstellungreichenfolge der eGK den Zusatz VOR den Nachnamen stellt. Demnach wäre das Feld also auch für MdB/ m.d. nicht zu gebrauchen
Stefan Lang (Oct 31 2016 at 11:06):
ack
Stefan Lang (Oct 31 2016 at 11:07):
Suffix _könnte_ man reinmodellieren, ist aber nicht Bestandteil der Versichertenstammdaten (aka eGK-Daten)
Stefan Lang (Oct 31 2016 at 11:08):
Und an den m.d. als nachgesetzten Titel hat man bei den VSD offenbar nicht gedacht
Stefan Lang (Oct 31 2016 at 11:09):
Das Slicing-Thema ist allerdings korrekt. Schlimmstenfalls müsste man da eine Extension mit Code für den Haupt-Familennamen erzwingen
Patrick Werner (Oct 31 2016 at 11:09):
@Stefan Lang nein da hatte ich keine Quelle, dachte ich benutze meinen Menschenverstand, aber so läuft es in der Realität ja nicht :-)
Habe gerade auch hier nachgelesen: http://www.dkgev.de/media/file/10011.RS291-11_Anlage2-SGBV_291a_Anpassung.pdf
Namenszusatz is wirklich auf diesen Anhang reglementiert, also alles Adelstitel die vor dem Nachnamen stehen sollen.
Also ist das mit Nobility doch genau passend hier
Stefan Lang (Oct 31 2016 at 11:10):
Richtig, das gibt dann 3 Slices, mit dem o.g. Problem
Patrick Werner (Oct 31 2016 at 11:10):
@Stefan Lang war auch mein Gedanke, einen Code für Familienname, aber dann wären alle 3 möglichen family names extended. Bin mir gerade unsicher ob das doof wäre
Stefan Lang (Oct 31 2016 at 11:11):
Warum nicht? Ich glaube, bei SCIPHOX war das damals ähnlich gelöst (?)
Patrick Werner (Oct 31 2016 at 11:12):
Ewout hat im englischen stream gerade eine fluentpath variante vorgeschlagen. da muss ich mich allerdings erstmal schlau lesen ob man das so einfach in profile integriert bekommt
Simone Heckmann (Oct 31 2016 at 11:14):
Warum müssen wir das überhaupt restricten...?
Wenn ich eGK nach FHIR mappe, dann gibt es ja de facto maximal einen Vor/Zusatz. Das Problem ergibt sich ja nur dann, wenn ich von FHIR, was potentiell mehrere Vor/Zusätze haben könnte zurück nach eGK mappen wollte
Also das Problem, das Grahame so schn als "Round Tripping" bezeichnet hat.
Frage a) Haben wir überhaupt einen UseCase dafür,
b) angenommen wir hätten einen und der Patient hätte tatsächlich mal mehrere Vor/ZUsätze. Dann könnte man diese doch einfach per Konvention leerzeichensepariert auf die eGK mappen, oder? WÄre es da notwendig, die Kardinalität seitens FHIR zu beschränken?
Stefan Lang (Oct 31 2016 at 11:17):
Ach so, ja, KISS mal wieder ;-)
Hm, de jure sollen die Praxen auch die Versichertenstammdaten aktualisieren können. Das macht dann wohl das PDMS. Aber solange es keine Kartenleser gibt, die direkt FHIR sprechen ...
Patrick Werner (Oct 31 2016 at 11:17):
Ob man das wirklich muss weiß ich nicht. Aber wenn man jemandem eine technisch interpretierbare Beschreibung eines EGK Datensatzes in FHIR zukommen lassen will würde ich ein profil wählen. Diese definiert die Kardinalitäten und möglichen eignesetzten Extensions. Wenn ich als Implementer diese Profile implementiere kann ich sicher sein alle Daten korrekt zu verwenden. Und eben nicht Informationen aus den Extensions zu verlieren
Stefan Lang (Oct 31 2016 at 11:19):
Als Herausforderung fände ich's auf jeden Fall spannend, zu schauen, ob Ewouts Vorschlag umsetzbar ist (mit VV + NB + Haupt-Name)
Selbst wenn wir es hier nicht unbedingt brauchen
Patrick Werner (Oct 31 2016 at 11:20):
ich gebe zu aktuelle, angesichts der Realiät, eher ein akademisches Problem. Aber lieber von Anfang an einmal richtig definiert.
Generell könnte diese Problemart jo noch an anderen Stellen auftreten (Stringfelder welches sich wiederholen, die aber über Extensions zusätzliche Informationen enthalten)
Patrick Werner (Oct 31 2016 at 11:21):
und deren Kardinalitäten beschränkt werden müssen. Ein Resultat könnte sein, dass man merkt Slicing anhand der Extensions braucht auch einen Qualifier für "Item hat keine Extension"
Simone Heckmann (Oct 31 2016 at 11:23):
ok, verstanden: Wir können derzeit im Profil sagen: "Ein Patient muss mindestens einen Nachnamen haben", aber was wir eigentlich sagen wollen ist "mindestens einen Nachnamen ohne Extension". Man könnte die Validierung also überlisten, indem man einen Datensatz erzeugt, der nur einen Vorsatz und/oder einen Zusatz hat, aber keinen "echten" Nachnamen.
Patrick Werner (Oct 31 2016 at 11:23):
Simone Heckmann (Oct 31 2016 at 11:24):
Dazu braucht's ja fast schon kriminelle Energie :D
Stefan Lang (Oct 31 2016 at 11:24):
<OT>Clockwork Orange: er hörte regelmäßig "Ludwig van"</OT>
Stefan Lang (Oct 31 2016 at 11:26):
IMHO einfach mal schauen, wie weit man mit Fluentpath kommt und welche Probleme evtl. daraus entstehen.
Dann können wir immer noch entscheiden.
Simone Heckmann (Oct 31 2016 at 11:27):
Aliens blicken's auch nicht:
https://books.google.de/books?id=UgTgjYvN2y8C&pg=PA259&lpg=PA259&dq=%22jamesty+kirk%22&source=bl&ots=9ajBQVSW-f&sig=plcQl8DFWLO1OLYlUxK8YMjH9g8&hl=de&sa=X&ved=0ahUKEwj46Yq894TQAhVMOxQKHYXaD8gQ6AEIJzAB#v=onepage&q=%22jamesty%20kirk%22&f=false
Stefan Lang (Oct 31 2016 at 11:29):
Warum wird eigentlich nirgends :facepalm: in ein Emoji übersetzt? 
Stefan Lang (Oct 31 2016 at 11:30):
(Der Kursus für klingonische Grammatik bitte eine Tür weiter, danke)
Patrick Werner (Nov 02 2016 at 10:52):
mal ein kurzer Zwischenstand zur Profilierung:
- mit Slicing alleine bekommt man das Problem nicht zufriedenstellend gelöst
- Forge ist ein nettes Tool, kann aber soviele Dinge noch nicht (man kann z.B. nicht die Kardinalität von Extensions eines Elements generisch auf 0..0 setzen, nur für spezifische Extension URLs)
Workaround ist hier die Profilierung in FORGE zu beginnen und danach manuell im XML anzupassen.
- bleibt die Option mit Fluent/FHIR Path, die aber erst in STU3 ohne Extensions funktioniert. Ich werde mich in die Expressions mal einarbeiten und hoffe Forge kann bald STU3 und entählt fehlende Funktionen. Auch der Bug in Simplifier mit den META Elementen wird dabei hoffentlich gefixt.
Simone Heckmann (Nov 02 2016 at 17:40):
Leider befinden wir uns gerade im globalen Code Freeze, weil alle auf STU3 warten, bevor die Tools/Server/Frameworks weiterentwickelt werden. Ich bin sicher, dass wir auf den DevDays Neuigkeiten zur Roadmap der Tools erfahren werden. Anfang nächsten Jahres wird dann richtig Gas gegeben ;-)
Jan Schuster (Nov 03 2016 at 06:37):
Anbei mal eine Namenserfassung zu einem Patienten aus in einem deutschen KIS. name.JPG In HL7 würde das dann so aussehen "Örchestra^JCaps^^Edler^auf m^Dr.oec.". So ganz verstehe ich das Problem in FHIR wohl noch nicht. In meiner Naivität würde ich denken, dass suffix und prefix aus HumanName dafür ausreichen? Ich kenne mich "noch" nicht gut genug aus mit dem FHIR-Datenmodell. Da muss ich wohl noch Hausaufgaben machen.
Stefan Lang (Nov 03 2016 at 10:13):
Der Punkt ist, dass es in Deutschland Präfixe für den Gesamtnamen gibt ("Dr."), 2 verschiedene Präfixe für den Nachnamen ("Graf", "von") und kein Suffix (weil man z.B. den "m.d." nicht berücksichtigt). FHIRs prefix passt für den deutschen Titel-Präfix; um die beiden Nachnamens-Präfixe geht es in der Diskussion im wesentlichen
Stefan Lang (Nov 03 2016 at 10:15):
Der Screenshot entspricht auf jeden Fall dem, was man anhand der eGK-Daten erwarten würde.
Doppelnamen habe ich wirklich noch nie so aufgesplittet gesehen wie es im implementers-Thread diskutiert wird.
Patrick Werner (Nov 03 2016 at 10:18):
aufgesplittete Nachnamen sind in den Niederlanden nur ein Thema da jeder Nachnamensbestandteil sein eigenes VV hat. Ich Chile wird der Nachname übrigens auch oft gesplittet gespeichert.
Simone Heckmann (Nov 03 2016 at 10:35):
Der Punkt ist schlicht die Reihenfolge.
in FHIR:
<prefix> <given> <family> <suffix>
gemäß eGK:
<vorname> <namenszusatz> <vorsatzwort> <nachname>
Würden wir namenszusatz auf suffix und vorsatzwort auf prefix mappen, dann würde aus
Charles Prince of Wales -> of Charles Wales Prince
:D
Stefan Lang (Nov 03 2016 at 11:05):
Das versuchte ich oben auszudrücken ;-)
Simone Heckmann (Nov 03 2016 at 17:31):
Wollte Dir auch nicht widersprechen, lediglich Deine Aussage bebildern ;-)
Jan Schuster (Nov 03 2016 at 20:17):
Ich verstehe, dass Suffix und Prefix nicht ausreichen jeden theoretisch möglichen Namen abzubilden. Mal abgesehen davon, dass der Prince of Wales niemals mit Echtnamen in irgendeinem System auftauchen wird, bin ich der Meinung, dass derzeit mit HL7v2 keine relevanten Probleme mit der Namensübertragung bestehen. Das sollte auch mit HumanName bei FHIR möglich sein. Oder habe ich das Thema jetzt komplett verfehlt? Vielleicht sollte eine Extension eingeführt werden, die den kompletten Namen übertragen kann.
Simone Heckmann (Nov 03 2016 at 20:19):
Wir hätten ein Problem mit V2 wenn wir versuchen wollten, die Daten auf der eGK so abzubilden, dass wir hinterher noch nachvollziehen können was der Namenszusatz und was das Vorsatzwort war.
Simone Heckmann (Nov 03 2016 at 20:23):
Ich habe keinen Zweifel, dass der UseCase, in dem das wirklich eine Rolle spielt, sehr eng begrenzt ist. Deshalb reden wir ja auch ausschließlich über Extensions und nicht darüber, diese Sonderlocken in den Standard drücken zu wollen. Aber ich denke, wir sollten sicherstellen, dass wenn wir einen solchen UseCase antreffen, dass wir dann die nötigen Extensions haben, um die Anforderung abzudecken.
Simone Heckmann (Nov 03 2016 at 20:24):
Und das Sahnehäubchen wäre es dann, wenn diese Extensions noch international harmonisiert wären...
Jan Schuster (Nov 03 2016 at 20:27):
Mmh. Das ist wohl sehr schwer bei Namen... Danke für die Aufklärung. Um noch einmal auf die eGK zu kommen. Hier besteht doch das Problem, dass es schon dort manifestiert ist, oder?
Simone Heckmann (Nov 03 2016 at 20:32):
Ja, da wir aber normalerweise immer nur von der eGK lesen, wäre es nicht weiter tragisch, wenn wir die Namensbestandteile einfach konkatenieren oder undifferenziert als "irgendein nicht-sortierrelevanter Namensbestandteil" speichern würden. Wir hätten ja trotzdem noch die volle Information. Problematisch wäre es, wenn wir den eGK-Datensatz speichern wollten und dann nicht mehr wüssten, welchen Namensteil in welches Feld gehört.
Simone Heckmann (Nov 03 2016 at 20:34):
Jetzt könnte man einwenden: "Wer will schon eine eGK beschreiben!?" Aber ich befürchte, dass es andere KBV-Datensätze gibt und geben wird, die das gleiche Namensformat verwenden und von KIS-/PVS-Systemen erstellt werden müssen.
Jan Schuster (Nov 03 2016 at 20:36):
Das Systeme/Applikationen Daten von der eGK einlesen und und weitergeben, passiert laufend. Meiner Meinung nach liegt das Problem im eGK-Datensatz. Der wird nach dem Einlesen nicht besser. Und wenn eGK-Datensätze kommuniziert werden müssen, kommt man wohl oder übel nicht darum herum, den originalen Datensatz zu versenden, wie es schon von HL7-DE vorgesehen ist. Dann dürfte man beim Dokumentenaustausch sein.
Simone Heckmann (Nov 03 2016 at 20:47):
Gott, gib mir die Gelassenheit, Dinge hinzunehmen, die ich nicht ändern kann (KBV-Datensätze), den Mut, Dinge zu ändern, die ich ändern kann (FHIR-Extensions), und die Weisheit, das eine vom anderen zu unterscheiden.
:D
Simone Heckmann (Nov 03 2016 at 20:50):
Ja, der Gedanke, den eGK-Datensatz in einer Attachment-Resource Huckepack fahren zu lassen, ist sicherlich nicht verkehrt. Trotzdem hat es auch einen gewissen Reiz, die in der eGK vorhandenen Daten in FHIR nutzbar zu machen. Wobei man da wiederum nicht sklavisch an die KBV-Vorgaben halten müsste.
Jan Schuster (Nov 03 2016 at 20:51):
Da schließe ich mich an.
Simone Heckmann (Nov 03 2016 at 20:52):
Ja nu. Das schöne an Extensions ist ja: man kann sie ignorieren :)
Simone Heckmann (Nov 03 2016 at 21:01):
Wen's interessiert: in DE gibt es ~100.000 Adelige.
Simone Heckmann (Nov 03 2016 at 21:02):
[...]da ist der FDP-Finanzexperte Hermann Otto Solms, nach dem deutschen Namensrecht eigentlich Hermann Otto Prinz zu Solms-Hohensolms-Lich [...] O.o
Simone Heckmann (Nov 03 2016 at 21:03):
Leider ist ein erheblicher Teil des Deutschen Adels verarmt, so dass man sich nicht immer drauf verlassen kann, dass die unter Pseudonym in die Klinik einchecken :D
Simone Heckmann (Nov 03 2016 at 21:07):
...andererseits sollten wir uns nicht beklagen. Es gibt Länder die haben es schlimmer: https://de.wikipedia.org/wiki/Arabischer_Name
Stefan Lang (Nov 04 2016 at 09:08):
Um nochmal den aktuellen Stand meiner Meinung kund zu tun ;-) :
Aus der begrenzten deutschen Sicht sind wir glaube ich mit den eGK-Stammdaten am Maximum dessen, was die Systeme detailliert verarbeiten.
Ich tendiere zu multiplen family, denn
a) jedes System, das FHIR spricht, muss wissen, dass die Kardinalität von HumanName.family 0..* ist und sollte, falls es intern nur 0..1 verarbeitet, selbst wissen, wie es damit umgeht.
b) die ISO-Extension entspricht dem use-Attribut aus v3 und ist zugegebenermaßen "etwas" länger in der XML-Repräsentation. Aber damit hätten wir's (bis auf evtl. das Slicing-Problem, seufz - eventuell lösbar mit einer Extension für den "sortierfähigen Haupt-Nachnamensbestandteil")
c) für Vollnamen-Suche gibt es HumanName.text, das wir dann ggf. auf 1..1 profilieren sollten. Das löst auch alle für mein beschränktes Vorstellungsvermögen denkbaren Probleme von d'Artagnan bis de la Croix.
Was ich in FHIR einfach nicht sehe, ist, aus HumanName einen Datentyp für Namensforscher zu machen (sorry für die leichte Polemik ;-)
Stefan Lang (Nov 04 2016 at 09:09):
Von den Arabern oder den Chinesen mit ihrer Reihenfolge <Nachname> <Vorname> würde ich mich (zumindest für deutsche Profile) nicht wirklich beeinflussen lassen, wenn es nicht mal die Gematik tut
Stefan Lang (Nov 04 2016 at 09:12):
Und ist das nicht letztlich der Grund, warum FHIR die Sachen so einfach abbildet: es gibt einfach zu viele Sonderfälle, um das detailliert in den Standard zu bringen. Wer es detaillierter braucht kann/soll es profilieren.
Stefan Lang (Nov 04 2016 at 09:14):
(OT: nix gegen meinen Prinzen, von der Parteizugehörigkeit vielleicht abgesehen - ich sitze hier exakt in der Mitte zwischen Solms und Hohensolms :D)
Jan Schuster (Nov 04 2016 at 12:29):
Ich habe an dieser Stelle mal die Frage nach der konkreten Darstellung in JSON zu dem o.g. Herren. Wäre es so nach HumanName korrekt dargestellt? [{
"resourceType": "HumanName",
"use": "usual",
"text": "Hermann Otto Prinz zu Solms-Hohensolms-Lich",
"family": "Solms-Hohensolms-Lich",
"given": "Herman"
}, {
"resourceType": "HumanName",
"use": "usual",
"given": "Otto"
}, {
"resourceType": "HumanName",
"use": "usual",
"given": "Prinz"
}, {
"resourceType": "HumanName",
"use": "usual",
"given": "zu"
}]
Pascal Pfiffner (Nov 04 2016 at 17:13):
Ich misch mich da mal ungefragt ein: Nicht ganz korrekt. HumanName ist keine eigene Resource, darum hat es auch kein resourceType. Dann sind given und family arrays of strings, nicht einzelne Strings. Du hättest also eher sowas wie:
{
"use": "usual",
"text": "Hermann Otto Prinz zu Solms-Hohensolms-Lich",
"prefix": ["Prinz"],
"family": ["Solms-Hohensolms-Lich", "zu"],
"given": ["Hermann", "Otto"],
}
Nun einfach die Frage, wo denn jetzt "zu" zu stehen kommt. "Prinz" hätte ich ins Prefix genommen, ob das stimmt weiss ich aber auch nicht.
Stefan Lang (Nov 04 2016 at 17:55):
@Pascal Pfiffner gefragt sind immer alle, die eine Antwort geben können ;-)
Passt auf jeden Fall weitgehend, nur ist der Prinz leider kein prefix, da prefix per Definitionem vor dem Vornamen steht und Adelstitel korrekt vor dem Nachnamen stehen müssen, Das war ja einer der Auslöser dieser Diskussion, wobei momentan noch nicht klar ist, ob Prinz ein family mit ISO-Extension wäre oder eine Extension in sich, mit family 1..1 und "Prinz zu Solms-Hohensolms-Lich".
Simone Heckmann (Nov 04 2016 at 18:37):
@Stefan Lang : Zu Deinem Punkt c) HumanName.text löst Suchproblematik:
Da stimme ich nicht zu. Die meisten Suchmasken, die ich kenne, haben ein dediziertes Feld für Nachnamen und Vornamen. Als Implementierer würde ich also die Eingabe ins Vornamenfeld in das Suchkriterium "given" und die Eingabe ins Nachnamenfeld in "family" packen. Das Feld HumanName.text würde aber nur beim Suchkriterum "name" mit berücksichtigt, also bei einer Suche über alle Namensbestandteile. Davon könnte man nur profitieren, wenn man immer das globale Suchkriterium verwendet, egal welches Feld der Anwender befüllt. Damit hätte man aber Unmengen falsch-positiver Suchergebnisse!
Der Anwender wäre wohl kaum erfreut, wenn er auf der Suche nach "George Michael" "Michael" ins Nachnamenfeld tippt und lauter Suchergebnisse erhält, bei denen der Vorname "Michael" ist.
Simone Heckmann (Nov 04 2016 at 18:43):
@Pascal Pfiffner Bei deinem Beispiel hätte ich jetzt erwartet, dass bei der Zerlegung des Namens die Reihenfolge beibehalten wird, also "family": ["zu","Solms-Hohensolms-Lich"], Wie wüsste das empfangende System sonst, wie der Name wieder korrekt zusammengebaut werden muss. Allerdings hat die Reihenfolge der Attribute (zumindest in XML) keine besondere Bedeutung. Es könnte m.E. sogar passieren, dass die Reihenfolge z.B. bei der Konvertierung von XML <-> JSON durcheinandergewürfelt wird. Was mich in meiner Auffassung, dass "family" nichts anderes als den korrekten, vollständigen Nachnamen beinhalten sollte und jegliche Zerlegung desselben Systemen vorbehalten bleiben sollte, die die entsprechenden Extensions kennnen und verstehen, bekräftigt.
Pascal Pfiffner (Nov 04 2016 at 18:47):
Hätte ich auch so gemacht, habe die ganze VV Diskussion nur am Rande mitverfolgt und da wurde irgendwann auch diese Lösung erwähnt. Ich stürz mich da aber jetzt nicht rein... :)
Stefan Lang (Nov 04 2016 at 18:52):
@Simone Heckmann Point taken ;-)
Deswegen hatte ich allerdings auch im implementers-Thread, bezogen auf nicht primär FHIR-basierte Systeme, geschrieben, dass es letztlich den Systemen überlassen bleibt, wie sie die Suche umsetzen.
Wenn es ein separates Nachnamens-Suchfeld gibt und das System intern hierfür die 0..* family konkateniert oder andersrum mehrere Leerzeichen-getrennte Suchbegriffe mit entsprechenden Und-Verknüpfungen einzeln verwendet werden, ist das durchaus umsetzbar.
Wenn das System intern sowieso nur einen Nachnamen speichert und die Daten aus FHIR konkateniert, ist es ohnehin trivial.
Stefan Lang (Nov 04 2016 at 18:53):
Andererseits kann ich auf einem FHIR-Server eben gerade nach HumanName.text='George Michael' suchen ;-)
Simone Heckmann (Nov 04 2016 at 18:55):
...es sei denn, in HumanName.Text steht "Michael, George" drin :P
Stefan Lang (Nov 04 2016 at 18:56):
:D
Stefan Lang (Nov 04 2016 at 18:56):
Herr, gib mir Kraft ;,D
Stefan Lang (Nov 04 2016 at 18:58):
OK, der Flat-Ansatz würde am Ende auch bedeuten, dass es keinen Grund gibt, family auf 0..* zu lassen, oder?
Simone Heckmann (Nov 04 2016 at 19:13):
Nein, höchstens für die Spanier, die tatsächlich einzelne , gleichberechtigte Namesteile haben, die man in beliebiger Reihenfolge zusammenwürfeln darf :) Für Deutsche Profile würde ich das in der Tat auf 0..1 setzen wollen.
Stefan Lang (Nov 04 2016 at 19:14):
https://www.w3.org/International/questions/qa-personal-names
Stefan Lang (Nov 04 2016 at 19:15):
Wie intensiv müssen deutsche Profile mit z.B. niederländischen, ägyptischen oder indischen Profilen kompatibel sein?
Stefan Lang (Nov 04 2016 at 19:17):
Also ist ein Use Case vorstellbar, in dem ein holländisches System einem deutschen eine FHIR-Resource schickt?
Stefan Lang (Nov 04 2016 at 19:18):
(oder ein spanisches)
Simone Heckmann (Nov 04 2016 at 20:21):
...also wie ich gerade im Int' thread lamentiert habe, gebe ich den Anspruch darauf, dass deutsche und Niederländische Voorvoegsels mit der gleichen Extension modelliert werden sollten, auf :D
Aber die Interpretation der core Attribute sollte weltweit die gleiche sein. Und da sehe ich das Problem, wenn ein Profil den Namen komplett zerlegt und ein anderes nicht, da wir ja inzwischen erkannt haben, dass das die Implementierung der Suche beeinflusst.
Pascal Pfiffner (Nov 05 2016 at 13:56):
Zum Thema family 0..1: In der Schweiz war es bis 2013 möglich, bei Heirat den Namen des Ehepartners dazu zu nehmen ("Schmid" ➔ "Schmid Meier"), gibt/gab es das in Deutschland nicht? Sprich für Schweizer mit Doppelnamen würde 0..1 nicht funktionieren. Den "Allianznamen" mit Bindestrich ("Schmid-Meier") gibt es weiterhin, der ginge aber auch mit 0..1.
Stefan Lang (Nov 05 2016 at 15:46):
Meines Wissens gibt es in Deutschland nur den Doppelnamen mit Bindestrich, und der zählt als ein Name
Simone Heckmann (Nov 05 2016 at 19:19):
@Pascal Pfiffner : Der Plan wäre der, "Schmidt Meier" als ein String in 0..1 family zu speichern.
Wenn eine Differenzierung der Art "birth name"/"partner name" erforderlich wäre, dann würde das in den entsprechenden Extensions passieren. Der Vorteil gegenüber zwei Iterationen von family wäre, dass alle Systeme den Namen stets vollständig und in der richtigen Reihenfolge wiedergeben würden (sofern Reihenfolge überhaupt relevant ist) und für die Such-Eingabe "Schmidt M..." als Nachnamen auch einen Suchtreffer finden würden.
Pascal Pfiffner (Nov 07 2016 at 00:49):
Hmmm, kann man wohl so machen, hätte ich jetzt aber als separate Namen erwartet. Aber wie gesagt, nicht mein Gebiet. ;)
Jan Schuster (Nov 07 2016 at 21:34):
Ich meine das Nachname1 getrennt mit Leerzeichen Nachname 2 (oder mehr) nur mit einer Kardinalität 0..n abgebildet werden kann. Nach meinem Verständnis will der Standard es so...
Simone Heckmann (Nov 08 2016 at 11:17):
Streng genommen nicht. Der Datentyp string erlaubt whitespace (vorne, hinten und dazwischen). Genau genommen aber schon, da es in der Beschreibung des Feldes heißt "For family name, hyphenated names such as "Smith-Jones" are a single name, but names with spaces such as "Smith Jones" are broken into multiple parts." Damit ist die ISO-Extension für die Qualifizierung von Namensteilen bei Bindestrich-Namen also raus. Ich bin mir noch nicht sicher, ob es zumutbar ist, beide Namens-Varianten bei der Implementierung der Suche zu berücksichtigen. Außerdem: wir hatten dass tolle Beispiel "Van Wijk-de Boer" :)
Stefan Lang (Nov 08 2016 at 14:52):
Im Zweifel sollten wir m.E. der Spezifikation des komplexen Datentyps HumanName folgen, auch wenn diese nur eine verbale, aber keine technische Einschränkung in Bezug auf den verwendeten primitiven Datentyp string macht.
Um das Zitat nochmal zu erweitern: "The parts of a name SHOULD NOT contain whitespace" (klare Aussage), und in Bezug auf Suche:"Systems that operate across cultures should generally rely on the text form for presentation, and use the parts for index/search functionality. For this reasons, applications SHOULD populate the text element for future robustness."
Das ist zwar beides eine Stufe weicher als SHALL/SHALL NOT, aber ich denke nicht, dass die Argumente, es anders zu machen, stark genug sind.
Der Part zum Thema Suche sagt meines Erachtens jedenfalls klar aus, dass eine Applikation bei der Suche mit multiplen name parts umgehen können muss.
Jan Schuster (Nov 08 2016 at 19:20):
Ich glaube nicht, dass eine Suche abhängig von der Verwendung 1 : 1 oder 1 : n in der Komplexität steigt. Für Applikationen sehe ich den Vorteil, wenn der Standard wie vorgesehen verwendet wird. Damit steigt die Verlässlichkeit. Ich würde mir da nicht allzu viele Gedanken um die Patientenquellen machen.
Simone Heckmann (Nov 08 2016 at 21:12):
Ok, zurück ans Zeichenbrett. Wir verwenden also den Namen so, wie vom Standard empfohlen und trennen bei Leerzeichen, versuchen aber gleichzeitig, die Extensions für die eKG zu implementieren. Dann rennen wir als erstes in das Problem, dass einige der Vorsätze laut https://www.vdek.com/vertragspartner/arbeitgeber/deuev/_jcr_content/par/download_7/file.res/Anlage_06_Vers.pdf gar keine Leerzeichen habe (z.B. o'Connor, d'Agostino). Also Qualifier für die Parts zu verwenden fällt aus, da wir einige der Namen gar nicht in parts trennen können. Folglich bräuchten wir Extensions als zusätzliche Attribute. Der Einfachheit halber schreibe ich extensions jetzt mal wie normale Attribute:
<family value="van"/> <family value="Beethoven"/> <family-ex-vorsatz value="van"/>
<family value="o'Connor"/> <family-ex-vorsatz value="o'"/>
<family value="Graf"/> <family value="von"/> <family value="Dracula"/> <family-ex-vorsatz value="von"/> <family-ex-nobility value="Graf"/>
Simone Heckmann (Nov 08 2016 at 21:15):
geht soweit. Um den Nachnamen korrekt anzuzeigen, müssten die Systeme alle family-Attribute in der richtigen Reihenfolge mit Leerzeichen separiert zusammenpappen.
Die von der eGK gewünschte Differenzierung wäre vorhanden, zumindest für die Systeme, die's interessiert und die daher die Extensions implementiert haben.
Simone Heckmann (Nov 08 2016 at 21:17):
Subobtimal wäre die Tatsache, dass die Systeme nicht wirklich erkennen könnten, welcher Teil für die alphabetische Sortierung relevant ist. Aber das war ja das kleinste der Probleme.
Simone Heckmann (Nov 08 2016 at 21:21):
<given value="Otto"/> <family value="Prinz"/> <family value="zu"/> <family value="Solms-Hohensolms-Lich"/> <family-ex-vorsatz value="zu"/> <family-ex-nobility value="Prinz"/>
Simone Heckmann (Nov 08 2016 at 21:29):
Dr. Otto Graf Lambsdorff mdB a.D.
<prefix value ="Dr."/> <given value="Otto"/> <family value="Graf"/> <family value="Lambsdorff"/> <family-ex-nobility value="Graf"/> <suffix value="mdB a.D."/>
Stefan Lang (Nov 09 2016 at 10:19):
Die redundante Übermittlung der eigentlich identischen Information ("von" als family und "von" als family-ex-vorsatz) finde ich etwas unelegant.
HumanName definiert zwar Leerzeichen als Grund, den Familiennamen aufzusplitten, verbietet aber andererseits nicht ausdrücklich das Aufsplitten aus anderen Gründen (außer beim Doppelnamen, Beispiel "Smith-Jones").
Rein formal steht also der Separierung des "d'" aus "d'Agostino" nichts im Weg. Ob da ein Leerzeichen steht oder nicht, wird mittels HumanName.text eindeutig definiert.
Folgt man dem Wortlaut, muss ein System den Namen nicht zusammensetzen, denn:
text => Repräsentation (inclusive Leerzeichen oder eben halt keine Leerzeichen, wo sie nicht hingehören)
prefix, given, family, suffix => Suche, Sortierung.
Von daher sehe ich noch nichts, was gegen die ISO-Extension spricht.
Schlimmstenfalls könnten man ein "directly concatenated voorvoegsel" dort mit aufnehmen
Simone Heckmann (Nov 09 2016 at 10:37):
Die Regel, wann Namen getrennt werden und wann nicht, muss "computable" sein, wird sie aus Sicht der Programmlogik "beliebig" getroffen, kann man keine konsistente Suche implementieren.
Beispiel 1
family= "van Beethoven"
Suche nach Patient?family=Beethoven&family=van => 0 Treffer
Suche nach Patient?family=van%20Beethoven => 1 Treffer
Beispiel 2
family ="Gonzales"
family="Lopez"
Suche nach Patient?family=Gonzales&family=Lopez => 1 Treffer
Suche nach Patient?family=Gonzales%20Lopez => 0 Treffer
Simone Heckmann (Nov 09 2016 at 10:37):
Man bekommt also nur dann korrekte Suchergebnisse, wenn man
sich darauf verlassen kann, dass die Namen bei Leerzeichen getrennt werden,
denn nur dann kann man die Implementierung dafür sorgen, dass mehrteilige Sucheingaben ebenfalls in aufgesplittet werden somit korrekte treffer erzielen.
Beim Beispiel1 gibt die Suche nach "van Beethoven" nur dann korrekte Ergebnisse, wenn die Sucheingabe nicht gesplittet wird:
Suche nach Patient?family=van%20Beethoven => 1 Treffer
Beim Beispiel 2 gibt die Suche nur dann einen Treffer, wenn die Sucheingabe "Gonzales Lopez" in Einzelteile zerlegt wird:
Suche nach Patient?family=Gonzales&family=Lopez => 1 Treffer
Woher soll die Programmlogik nun wissen ob die Sucheingabe gesplittet werden muss oder nicht?
Simone Heckmann (Nov 09 2016 at 10:46):
Zur Verwendung von HumanName.Text:
Da hier der gesamte Name dargestellt wird, dann darauf nicht zurückgegriffen werden, wenn der Patient mit Nachnamen angesprochen werden soll, also klassischerweise die Briefanrede
"Sehr geehrter Herr <Nachname>".
HumanName.Text ist m.E. auch für die Suche nicht verwendbar, da ich da immer nur eine :contains Volltextsuche verwenden kann, da ich ja nicht weiß wo sich der gesuchte Namensteil befindet. Die Suche nach Patient?family=John implementiert als Patient?name:contains=John würde eben nicht nur Elton John finden sondern auch alle Leute, die "John" mit vor- oder Mittelnamen heißen. Das wäre viel zu ungenau.
Stefan Lang (Nov 09 2016 at 11:53):
Das Beispiel 2 ist konsistent und das würde ich spezifikationsgemäß auch genau so erwarten. Die Applikation darf genau genommen nicht nach Patient?family=Gonzales%20Lopez suchen (auch wenn eventuell ein freundlicher Server das intern als Patient?family=Gonzales&family=Lopez verarbeiten würde).
Allerdings ist die Frage, was beim ungekehrten Fall "d'Agostino" passieren würde, wenn es eGK-konform getrennt wäre, also:
...
family="d'"
family="Agostino"
....
In diesem Fall würde eine Suche nach "d'Agostino" 0 Treffer liefern.
In der Praxis würde wohl jeder User dann einfach nach "Agostino" suchen und das gewünschte finden. Oder die Applikation müsste so intelligent sein, die entsprechenden VVs laut DEÜV-Anlage herauszufiltern :-/
Die Frage ist: ist das ein zumutbarer Sonderfall? Ansonsten bleibt wohl wirklich nichts anderes übrig als die Redundanz zu akzeptieren.
Stefan Lang (Nov 09 2016 at 11:59):
Bei der Briefanrede bin ich ein wenig pessimistisch, ob das automatische Generieren eines konkatenierten Nachnamens immer korrekt wäre: http://www.knigge.de/themen/kommunikation/nicht-titulierte-adelsnamen-2051.htm
Stefan Lang (Nov 09 2016 at 12:06):
Was aus meiner Sicht noch gegen den "redundanten" Ansatz spricht, ist, dass der sortierrelevante (Haupt-)Teil des Nachnamens nicht klar als solcher gekennzeichnet ist. Ein System müsste den quasi aus den Differenzen zwischen den family-Elementen und den Extensions extrahieren.
Jan Schuster (Nov 09 2016 at 12:35):
D'Agostini ist meiner Meinung nach ein typisches Beispiel für einen Prefix. "Richtige" Systeme sollten die Namensbstandteile separat speichern (Siehe Anhang). Es stellt sich die Frage, woher Systeme z.B. den Unterschied in der Schreibweise von einem d' (ohne Freizeichen vor dem Namen) oder von (mit einem Freizeichen vor dem Namen) kennen soll. Das kann eigentlich nur durch den Textteil gelöst werden. Sind Ressourcen-Zugriffe wie ?family=name1&family=name2 in dieser Form überhaupt zulässig? Auch wenn im Datentype family 1..n definiert ist, müsste der Zugriff doch ?family=name1%20name2 sein. Das müsste eben in der angefragten Applikation aufgelöst werden.Namensvorsatz.JPG Namensvorsatz-hl7.JPG
Simone Heckmann (Nov 09 2016 at 12:39):
/?family=name1&family=name2 ist absolut zulässig. Es sind zwei separate, und-verknüpfte Bedingungen, die dann ein Ergebnis liefern, wenn ein Datensatz für beide Bedingungen einen Treffer hat.
Jan Schuster (Nov 09 2016 at 12:40):
Danke. Gut zu wissen. Ich bin halt ein Neuling.
Simone Heckmann (Nov 09 2016 at 12:46):
Kein Problem. Dafür ist der Chat ja da :)
Die Suche nach strings ist in FHIR übrigens als "Matching von links" definiert, also
Suche nach "Eve" liefert auch "Everywoman", aber nicht "Hever"
Erlaubt sind u.a. die modifier :contains und :exact, also
Patient?family:exact=Eve liefert nur "Eve" aber nicht "Everywoman"
Patient?family:contains=Eve liefert sowohl "Eve" als auch "Everywoman" als auch "Hever"
Stefan Lang (Nov 09 2016 at 15:36):
Da wir jetzt doch einige Varianten der möglichen Namens-Darstellung durchdiskutiert haben, denke ich, es wäre sinnvoll, die Optionen mal zur Wahrung der Übersicht in einem Dokument gegenüberzustellen, in Bezug auf die Vor- und Nachteile, die die Varianten unter Berücksichtigung der verschiedenen Use Cases/Workflows und der diversen Namens-Spezialfälle haben.
Ich denke, das könnte bei der finalen Entscheidungsfindung helfen ;-)
Meinungen dazu?
Stefan Lang (Nov 11 2016 at 08:29):
Laut Grahame ( https://chat.fhir.org/#narrow/stream/implementers/topic/http.3A.2F.2Fhl7.2Eorg.2Ffhir.2FStructureDefinition.2Fiso21090-EN-qualifie ) gibt es jetzt wohl eine Session zum Thema auf den DevDays.
Wer nicht vor Ort ist und etwas beitragen möchte, sollte das also am besten bis Dienstag tun, wobei der Termin für die Session noch nicht feststeht.
Patrick Werner (Nov 12 2016 at 16:04):
Servus, ich hatte aufgrund des letzten chilenischen FHIR Workshops leider keine Zeit für das Thema. Ich sichere gerade den deutschen und chilenischen Thread und schreibe während des Fluges mal etwas zusammen, die verschiedenen diskutierten Optionen.
Stefan Lang (Nov 13 2016 at 10:35):
Patrick Werner (Nov 16 2016 at 05:53):
Habe mal versucht die Diskussion zusammenzufassen: https://drive.google.com/file/d/0B3xFZMHgJ7j0Qlk4akJHMW01c28/view?usp=sharing
Simone Heckmann (Nov 16 2016 at 19:45):
Spoiler: Wir haben auf den DevDays gerade eine Lösung erarbeitet, die unserem UseCase sehr entgegen kommt. Details folgen, sobald Grahame den entsprechenden ChangeRequest erstellt hat. Danke nochmal an @Patrick Werner für die tolle Zusammenfassung!
Grahame Grieve (Nov 16 2016 at 20:22):
Thanks Simone for the leadership. See GF#12351
Simone Heckmann (Nov 16 2016 at 20:26):
https://twitter.com/ewoutkramer/status/798945605208932352
:)
Simone Heckmann (Nov 22 2016 at 14:47):
Ich denke, das können wir abnicken:
http://build.fhir.org/datatypes.html#humanname
"Nobility" wäre dann eine national Extension analog zu den bereits definierten.
Meinungen?
Stefan Lang (Nov 22 2016 at 16:11):
In Bezug auf Nobility bzw. unsere per eGK definierten 2 möglichen Nachnamens-Präfixe ("Graf" "von") ist da noch eine Inkonsistenz.
Das Beispiel ("Complex example from Germany" auf http://build.fhir.org/datatypes-examples.html#HumanName ) verwendet http://hl7.org/fhir/StructureDefinition/humanname-own-prefix für "Gräfin". Die Extension selbst ist 0..1.
In der Extension wird aber primär von Vorvoegsel gesprochen: http://build.fhir.org/extension-humanname-own-prefix.html . Das wird sicher auch von den Niederländern als Vorvoegsel interpretiert.
Da das Beispiel dem Besprechungsergebnis widerspricht, sollte man das noch ändern, also z.B. "Dr.phil. Regina Johanna Maria *von* Hochheim-Weilenfels, NCFSA".
Und dann hätten wir, wie besprochen, die National Extension für Nobility.
Simone Heckmann (Nov 22 2016 at 21:18):
Tadaaa: https://simplifier.net/BasisprofilDE/humanname-nobility/rendered
Stefan Lang (Nov 22 2016 at 22:41):
Peter Scholz (Nov 23 2016 at 10:58):
Als überzeugter Republikaner und Verfechter der Tatsache das es in Deutschland de jure bereits seit 98 Jahren keine Adelstitel mehr gibt
sollte dieser Begriff auch nicht in der extension auftauchen.
Bitte ausschliesslich den Begriff Namenszusatz verwenden
Simone Heckmann (Nov 23 2016 at 11:00):
Hm, ja hast recht. Wir waren an "Nobility" hängen geblieben, da dies der einzig zutreffende Code in der ISO-Extension war. Nun da diese Extension hinfällig ist, müssen wir uns auch nicht mehr an ISO-Nomenklatur halten
Simone Heckmann (Nov 23 2016 at 11:10):
korrigiert.
In der Beschreibung habe ich den Hinweis auf Adelstitel drin gelassen, damit der Namenszusatz vom Vorsatzwort unterscheid bar ist, welche ja in eine andere Extension gehört...
Simone Heckmann (Nov 23 2016 at 11:10):
Sind die Kardinalitäten auf der eGK eigentlich für beides 0..1 oder 0..* ?
Peter Scholz (Nov 23 2016 at 11:22):
sieht gut aus
Stefan Lang (Nov 23 2016 at 16:11):
The grumpy old man is right ;-)
@Simone Heckmann Die Kardinalität ist 0..1. Das wäre eines der Beispiele (given = "Jürgen", own-prefix = "von der", family="von der Lippe")
Stefan Lang (Nov 23 2016 at 16:14):
Ich hab gerade noch den URL-Key geändert, der lautete noch auf nobility. Jetzt also: https://simplifier.net/BasisprofilDE/humanname-namenszusatz/rendered
Stefan Lang (Nov 23 2016 at 16:17):
Den Verweis auf die own-name Extension im Beschreibungstext ersetze ich auch gerade mal durch own-prefix ;-)
Patrick Werner (Nov 23 2016 at 16:17):
Ich habe mir eben die Beispiele von Grahame angeschaut, meiner Meinung fehlt hier überall die family-plain & und maiden-plain Extensions
Stefan Lang (Nov 23 2016 at 16:25):
@Patrick Werner Liegt wahrscheinlich daran, dass wir die nicht defniert hatten?
Patrick Werner (Nov 23 2016 at 16:26):
während der Diskussion in Amsterdam wurde diese diskutiert. Um Simones Example nochmals zu posten:
(German version)
<family value="van Wijk-de Boer"/>
<extension url="http://hl7.org/fhir/StructureDefinition/family-voorvoegsel">
<valueString value="van" />
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/family-plain">
<valueString value="Wijk-de Boer" />
</extension>
(Dutch version)
<family value="van Wijk-de Boer"/>
<extension url="http://hl7.org/fhir/StructureDefinition/family-voorvoegsel">
<valueString value="van" />
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/maiden-voorvoegsel">
<valueString value="de" />
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/family-plain">
<valueString value="Wijk" />
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/maiden-plain">
<valueString value="Boer" />
</extension>
Stefan Lang (Nov 23 2016 at 16:29):
Ja, aber im Ergebnis sind sie nicht mehr drin:
"based on v2:
Own Family name Prefix
Own Family name
Family name Prefix from Partner/Spouse
Family name from Partner/Spouse
not based on v2, but for es:
Mother's Family Name
Father's Family Name
2a. add extension to core for HumanName:
Name Assembly Order per v2, wtih v2 and Dutch codes."
Stefan Lang (Nov 23 2016 at 16:32):
statt maiden und family sind's jetzt own und partner.
voorvoegsel => prefix
plain => name
Stefan Lang (Nov 23 2016 at 16:33):
Also semantisch gleich, nur anders benannt
Stefan Lang (Nov 23 2016 at 16:33):
Und die Reihenfolge ist durch humanname-assembly-order festgelegt
Patrick Werner (Nov 23 2016 at 16:41):
ich habe mal das German Example entsprechend angepasst:
https://chat.fhir.org/#narrow/stream/implementers/subject/http.3A.2F.2Fhl7.2Eorg.2Ffhir.2FStructureDefinition.2Fiso21090-EN-qualifie/near/47693
Stefan Lang (Nov 23 2016 at 17:17):
Da ich gerade mal ein maximal komplexes Beispiel zusammenzimmere: 2 Fragen.
(a) multiple Titel ("Prof. Dr. med. Dr. rer. nat.") zusammen in ein Prefix (realitätsnah und eGK-konform) oder auf mehrere Prefixe aufsplitten?
(b) fordern wir die ISO-Extension mit Code "AC" oder lassen wir die optional?
Stefan Lang (Nov 23 2016 at 17:37):
Als Grundlage: https://simplifier.net/BasisprofilDE/humanname-example-1/xmlview
Patrick Werner (Nov 24 2016 at 10:39):
a) würde ich zusammen belassen. Ich sehe keinen Vorteil Patienten nach der Anzahl ihrer akad. Titel zu sortieren 
b) was bedeutet fordern hier? In einem deutschen Profil würde ich die ISO Extension mit AC mit 0..1 einbinden
Patrick Werner (Nov 24 2016 at 10:44):
Ich habe noch 2 Kommentare zum Namenszusatz:
1) Wollen wir die Extension https://simplifier.net/BasisprofilDE/humanname-namenszusatz/rendered wirklich eine deutsche URL geben, oder wäre es nicht mehr im Sinne der Interoperabilität hier eine sprechende englische URL zu vergeben?
2) brauchen wir NamensZusatz überhaupt da wir eigentlich: http://hl7.org/fhir/StructureDefinition/humanname-own-prefix dafür nutzen könnten. Um beim (erweiterten) Beispiel von build.fhir.org zu bleiben:
... <family value="Gräfin von Hochheim-Weilenfels"> <extension url="http://hl7.org/fhir/StructureDefinition/humanname-own-prefix" > <valueString value="Gräfin" /> </extension> <extension url="http://hl7.org/fhir/StructureDefinition/humanname-own-prefix" > <valueString value="von" /> </extension> <extension url="http://hl7.org/fhir/StructureDefinition/humanname-own-name" > <valueString value="Hochheim-Weilenfels" /> </extension> </family> ...
Patrick Werner (Nov 24 2016 at 10:46):
Der NamensZusatz ist doch auch nur ein prefix vor dem Nachnamen, die Reihenfolge der prefixe in XML und JSON bleiben erhalten, da ein wiederholendes Element (humanname-own-prefix) als Liste gespeichert wird.
Patrick Werner (Nov 24 2016 at 10:48):
oder man schreibt es gleich so:
... <family value="Gräfin von Hochheim-Weilenfels"> <extension url="http://hl7.org/fhir/StructureDefinition/humanname-own-prefix" > <valueString value="Gräfin von" /> </extension> <extension url="http://hl7.org/fhir/StructureDefinition/humanname-own-name" > <valueString value="Hochheim-Weilenfels" /> </extension> </family> ...
Fände ich noch besser. Dann könnte man die prefix Extension auf 0..1 profilen
Patrick Werner (Nov 24 2016 at 10:54):
und hier noch ein angepasstes Beispiel der maximal komplexen Patientin:
<Patient> <name> <use value="official" /> <text value="Prof. Dr. med. Dr. rer. nat. Marianne Sabine Franziska Freifrau von und zu Rathenburg vor der Isar-Mayer, MdB" /> <family value="Freifrau von und zu Rathenburg vor der Isar"> <extension url="http://hl7.org/fhir/StructureDefinition/humanname-own-prefix"> <valueString value="Freifrau von und zu" /> </extension> <extension url="http://hl7.org/fhir/StructureDefinition/humanname-own-name"> <valueString value="Rathenburg vor der Isar" /> </extension> <extension url="http://hl7.org/fhir/StructureDefinition/humanname-partners-name"> <valueString value="Mayer" /> </extension> </family> <given value="Marianne" /> <given value="Sabine" /> <given value="Franziska" /> <prefix value="Prof. Dr. med. Dr. rer. nat."> <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier"> <valueCode value="AC" /> </extension> </prefix> <suffix value="MdB" /> </name> </Patient>
Wegen der Geschlechtergerechtigkeit habe ich mir erlaubt das Geschlecht zu ändern. Die family prefixe habe ich mal zusammengezogen, und der Dame einen Doppelnamen, incl. Extension für den Partnernamen verpasst.
Stefan Lang (Nov 24 2016 at 16:04):
b) "fordern" wäre 1..1. Sehe ich aber auch so, dass der ISO-Code hier optional ist.
Stefan Lang (Nov 24 2016 at 16:22):
(1) Das Namenszusatz-Präfix ist ja eine national extension, von daher darf das IMHO grundsätzlich auch deutsch heißen (ich sag nur: "voorvoegsel" ;-). Aber ich würde jetzt keine Grundsatzdiskussion darum anzetteln, abgesehen davon, dass wahrscheinlich niemand intuitiv so etwas wie "humanname-own-addendum-prefix" nachvollziehen kann, während der "Namenszusatz" zumindest in den deutschen Spezifikationen auftaucht.
Wenn man das Konzept, rein englisch zu bleiben, konsequent durchziehen will, wird das allerdings spätestens bei Begriffen wie "BSNR" oder "LANR" schwierig. Ich würde also eher auf die Zielgruppe fokussieren.
(2) Der ganze Hintergrund dieser national extension ist ja, zwischen Vorsatzwort und Namenszusatz (ex-nobility) unterscheiden zu können. Das wäre bei zweimal humanname-own-prefix nicht gegeben und schon gar nicht, wenn wir den auf 0..1 runterstreichen und alles in einen String schreiben. Das ist nämlich dann maschinell nicht mehr simpel auftrennbar - genau deshalb hatte ich das Beispiel "von und zu" mit Leerzeichen gewählt.
Simone Heckmann (Nov 24 2016 at 21:39):
Das mit der deutschen url habe ich auch überlegt. Aber im Prinzip ist die national extension ja deswegen nicht im Core, weil sie ja einen national begrenzten scope hat. Und selbst wenn wir die url englisch machen, ist die Basis immer noch "fhir.de", was wohl die meisten anderen Affiliates davon abhalten würde, die extension zu verwenden, selbst wenn der hintere Teil der URL passt :)
Simone Heckmann (Nov 24 2016 at 21:46):
@Patrick Werner zu deinem Beispiel: Ja könnte man machen, allerdings können wir die eGK-Daten dann nicht mehr exakt rekonstruieren, da nicht unterscheidbar ist, ob es sich bei "von der" und "Gräfin von" um Namenszusatz+Vorsatzwort oder Vorsatzwort+Vorsatzwort handelt. Ebenso könnte man, wenn es nur ein humanname-own-prefix gibt nicht entscheiden, ob es sich dabei um einen Namenszusatz oder ein Vorsatzwort handelt. Allerdings ist das ein Kompromiss, den man bei V2 auch schon eingegangen ist.
Weiß nicht, ob das jemals jemand bereut hat???
Stefan Lang (Nov 24 2016 at 23:29):
Wenn wir die Möglichkeit haben, die eGK exakt abzubilden, sollten wir das IMHO auch tun. Zumindest die Systeme, die Kartendaten verarbeiten, bilden das ja intern auch so ab, siehe Screenshot irgendwo viel weiter oben hier im Thread. Aus irgendeinem, sicher wohl bedachten, Grund sieht der eGK-Stammdatensatz es nun mal so vor.
Also warum einen Kompromiss machen?
Patrick Werner (Nov 25 2016 at 11:16):
Nein das passt so. Deutsche Extension mit deutschem Namen macht wahrscheinlich wirklich Sinn, sonst übersetzen wird die deutschen Begriffe ins englische und weder wir noch nicht-deutsch Sprechende verstehen nicht intutitiv worum es geht.
Zum zweiten Punkt, ich war gedanklich schon bei deutschen Basisprofilen. Es macht allerdings absolut Sinn erstmal die EGK Profile zu finalisieren.
Patrick Werner (Nov 25 2016 at 11:18):
Habt ihr schon mit deutschen Basisprofilen (Patient)begonnen? Ich wollte das mal die Tage angehen - dann könnte man auf dem nächsten InteropForum darüber diskutieren
Stefan Lang (Nov 25 2016 at 11:50):
Genau. Von der eGK rückwärts zum Basisprofil denken.
Wir hatten letzte Woche erstmal nur angefangen, die gesammelten Einzelteile aufzuarbeiten.
Grundsätzlichen wollen wir ja zu STU3 die Profile erstellen. Ich denke aber, es schadet nichts, dazu schon was zu sammeln. Tun wir ja im Prinzip schon die ganze Zeit ;-)
Patrick Werner (Nov 25 2016 at 12:56):
Dann werde ich mal schauen ob ich die EGK Profile auf STU3 umgestellt bekomme. ClinFhir kann ja schon STU3, zur not schreib ichs von Hand
Simone Heckmann (Nov 25 2016 at 15:53):
Keine Eile. So lange Simplifier nicht STU3 ist können wir's eh nicht publizieren.
dr Kai U. Heitmann (Nov 25 2016 at 18:16):
Gibt's für STU3 in Simplifier einen Zeitplan?
Simone Heckmann (Nov 28 2016 at 20:37):
Es gibt die Absicht, Simplifier auf STU3 zu aktualisieren, sobald STU3 final ist. Ein Datum gibt's aber nicht. Ich habe Martijn heute nochmal an das Problem mit der Auflösung der canonical URLs erinnert. Am Mittwoch wird ein Simplifier Update eingespielt, so dass wir das am Freitag präsentieren können sollten. (Ohne bei "US Lab" zu landen :D )
Stefan Lang (Nov 28 2016 at 21:36):
für das Resolve-Update ;)
Simone Heckmann (Nov 29 2016 at 14:46):
http://fhir.de/StructureDefinition/betriebsstaetten-hierarchie
Simone Heckmann (Nov 29 2016 at 14:47):
Hm...geht noch nicht.
aber das hier: https://simplifier.net/resolve?canonical=http://fhir.de/StructureDefinition/betriebsstaetten-hierarchie
Simone Heckmann (Nov 29 2016 at 14:48):
Ich glaube, wir müssen den redirect anpassen... vorher war's url=...
jetzt canonical=...
Simone Heckmann (Nov 29 2016 at 15:55):
Die syntax muss lauten https://simplifier.net/resolve?canonical=
Stefan Lang (Nov 29 2016 at 18:41):
Redirect ist angepasst und geht (auch wenn das jetzt wirklich gar nix mit "HumanName" zu tun hat :D)
Last updated: Apr 12 2022 at 19:14 UTC
