Stream: implementers
Topic: Voorvoegsels/Prefixes revisited
Alexander Henket (Oct 02 2017 at 11:56):
http://hl7.org/fhir/extension-humanname-partner-prefix.html
http://hl7.org/fhir/extension-humanname-own-prefix.html
Back in the V3 day, we used to say that "van Beethoven" would split into "van " and "Beethoven", whereas "d'Artagnan" would split into "d'" and "Artagnan".
In this split the space between the prefix and the surname, if any, would be part of the prefix value. In FHIR we do not specify any behavior like that yet. Any thoughts @Simone Heckmann, or @Jose Costa Teixeira?
Jose Costa Teixeira (Oct 02 2017 at 12:13):
thought, not solution: we should consider the optionality of those prefixes.
Jose Costa Teixeira (Oct 02 2017 at 12:16):
my last name is actually "da Costa Teixeira" but in Portugal they don't care.
Belgians /Dutch(?) however do care about "Mr. van der Sar" not really being the same as "Mr. Sar"
Jose Costa Teixeira (Oct 02 2017 at 12:21):
first thoughts: we could either have the same behaviour as you mention from v3, or some extra attributes that would condition the combination of the names as well as their optionality/importance
Simone Heckmann (Oct 02 2017 at 12:21):
I think the following expectations would apply:
family contains the full name with all pre/postfixes in the correct order, correct spacing as it would be used for representation in a letter etc.
the extensions can be used in addition, in order to be able to separate prefix from the actual name, in case this is relevant for sort order or name matching. Also, the extensions can add semantics to some name parts (e.g. mother's name, father's name, mother's name prefix etc.) which might be relevant for MPIs
Jose Costa Teixeira (Oct 02 2017 at 12:22):
yes, family name is the complete typed out form.
Stefan Lang (Oct 02 2017 at 12:23):
In additions to Simone: the conclusion we took for the German HumanName profile was that the extensions would contain no whitespace.
Especially, since we have a list of allowed voorvoegsels in Germany: https://www.gkv-datenaustausch.de/media/dokumente/arbeitgeber/deuev/rundschreiben_anlagen/GemRS_Anlage_06.pdf
Jose Costa Teixeira (Oct 02 2017 at 12:24):
we may have that a voorvoegsel has a different treatment than a portuguese equivalent, so I think this logic would end up in the extension space
Alexander Henket (Oct 02 2017 at 13:50):
The one and only reason for us to split prefix from surname at all is sorting. Nothing more, nothing less. But... we do not keep a full name field in addition to the name parts. So: when we only have parts and need to construct the full name, we need to know where the spaces are. If they are not in the parts then "van der Sar" will become “vanderSar”, or “d’Artagnan” will be “d’ Artagnan". So in our IG I have added the notion that spaces are relevant in the prefix, just like they were in V3 so nothing new there.
The question is: the FHIR extensions for prefix are silent on this. Should we ask to add wording on spacing? (again, just like there was wording on explicit and implicit spacing for V3 ENXP name parts)
Stefan Lang (Oct 02 2017 at 13:59):
If I remember the HumanName session at last year's DevDays correct, the conclusion was to have the full text family name (containing the correct whitespace/separating characters) plus any extensions you'd need for sorting or whatever other reason.
That is also the only way to ensure that a system that does not understand these extensions will be able to retrieve a family name.
Simone Heckmann (Oct 02 2017 at 14:08):
Also: If you only keep fragments of the name, how does search work if someone types "d'Arta.." into the searchbox!?
It'll mach neither the voorvoegsel nor the plain lastname!
That's the main reason why we want the full name in the "family" attribute
Plus, as Stefan mentioned, to maintain compatibility with systems that don't implement national extensions
Patrick Werner (Oct 02 2017 at 14:11):
+1 @Stefan Lang & @Simone Heckmann
Jose Costa Teixeira (Oct 02 2017 at 14:14):
I don't think using family name and prefixes are mutually exclusive. Are they?
Jose Costa Teixeira (Oct 02 2017 at 14:15):
you can use the family name and still have its decomposed form
Stefan Lang (Oct 02 2017 at 14:16):
They aren't. But the prefix is usually meant to be before the given name. The voorvoegsel is before the/the first part of the family name
Alexander Henket (Oct 02 2017 at 14:16):
We have both the full name in the family string and the parts, but a Dutch system, will only parse the parts, leaving the full name to unaware systems
Stefan Lang (Oct 02 2017 at 14:19):
@Jose Costa Teixeira
Like "Dr. Ludwig van Beethoven"
prefix: "Dr."
given: "Ludwig"
family: "van Beethoven"
family (humanname-own-prefix): "van"
family (humanname-own-name): "Beethoven"
Alexander Henket (Oct 02 2017 at 14:20):
@Stefan Lang yes all of that, except for
family (humanname-own-prefix): "van "
Stefan Lang (Oct 02 2017 at 14:20):
Yes, I believe that's the difference between the Dutch and the German interpretation ;-)
Alexander Henket (Oct 02 2017 at 14:21):
In a list "van Beethoven" comes before "Mendelssohn"
Stefan Lang (Oct 02 2017 at 14:22):
That depends on the country you're in, or better: the local sort conventions.
Alexander Henket (Oct 02 2017 at 14:22):
Probably. It's the reason that lots of programming languages support extending for sorting
Alexander Henket (Oct 02 2017 at 14:23):
But back to the parts: do you keep both the full name and the parts, then?
Stefan Lang (Oct 02 2017 at 14:24):
right
Alexander Henket (Oct 02 2017 at 14:25):
So in your case, you don't need to know about that space. I get it...
Stefan Lang (Oct 02 2017 at 14:26):
Exactly. Many systems here just don't support the splitted family name. They just take the full string.
Alexander Henket (Oct 02 2017 at 14:26):
And we support those systems too, mind you. The family/@value contains the same in your and our case
Stefan Lang (Oct 02 2017 at 14:30):
That's true.
On the other hand we have the VSDM specification used on the German health card (which also refers to the list I linked above). This limits the valid values of humanname-own-prefix to that list and nowhere mentions something like "add a whitespace where appropriate"
Jose Costa Teixeira (Oct 02 2017 at 14:33):
i am just imagining how much of these things (we're talking 2-3 languages) are going to be sufficient guidance for an international standard
Alexander Henket (Oct 02 2017 at 14:34):
We have a list like that too. http://publicaties.rvig.nl/dsresource?objectid=4793&type=org
It too does not say anything about spacing. A name is a name and the name determines the spacing. So the regular person in The Netherlands is called "van der Sar", but in Belgium that might have evolved into "Vandersar" (does not have prefix anymore, the whole thing is a surname), and "d'Artignan" might validly be "d' Artignan" in some cases too.
Alexander Henket (Oct 02 2017 at 14:34):
@Jose Costa Teixeira We might not be able to, in which case the current situation is good enough (doesn't mention spacing)
Jose Costa Teixeira (Oct 02 2017 at 14:35):
what happens to patronyms, short names (e.g. russian), different order of names (asian)...
Jose Costa Teixeira (Oct 02 2017 at 14:36):
a rule like "space is part of the voorvoegsel if any" seems clear enough, while not covering everything - which is ok.
Jose Costa Teixeira (Oct 02 2017 at 14:37):
if we'd look at expanding that to a comprehensive mechanism, I'd say we are looking at a wealth of extensions and perhaps that is an overkill
Alexander Henket (Oct 02 2017 at 14:38):
We have that rule, but would it make sense in the base extension was the question. I guess the answer is "no let's not open up a can of worms” :-)
Jose Costa Teixeira (Oct 02 2017 at 14:40):
by the way, @Simone Heckmann i would expect searches on names to be evenutally somewhat clever, using text search on "calculated" family names. So you can even have only the name parts and the system does the rest - determine the full name for searching, partial search, phonetic search...
Stefan Lang (Oct 02 2017 at 14:42):
@Alexander Henket agreed on the can ;-)
Jose Costa Teixeira (Oct 02 2017 at 14:43):
of course, that is a nice-to have in the systems, but we should not rely on that :)
Jose Costa Teixeira (Oct 02 2017 at 14:47):
@Alexander Henket My answer would be idd:
saying "the separators between components of a name should be included in the separators" (which is wwhat you are saying when you say "no space means that the words go together") is something that could work but may be only local.
Jose Costa Teixeira (Oct 02 2017 at 14:47):
separators can be a "-" , a " ", or nothing. That seems a local implementation thing, right?
Stefan Lang (Oct 02 2017 at 14:51):
@Jose Costa Teixeira the search argument was about a standard FHIR search query, which (for example) would look for "d'Artagnan" in all name sub-elements but not in all concetenated combinations of name extensions.
Of course every system may implement a more complex search algorithm.
Stefan Lang (Oct 02 2017 at 14:56):
But that's implementation specific. And, as Alexander pointed out, even the Dutch system that will ignore the full text family name still has that in the patient's representation in a Dutch profiled Patient resource.
Jose Costa Teixeira (Oct 02 2017 at 14:57):
yes, the search thing is that the standard search query may encounter all sorts of issues when finding names
Stefan Lang (Oct 02 2017 at 15:03):
Still most of them are ruled out when always filling HumanName.text and HumanName.family with the full text, like in my favorite example:
https://simplifier.net/BasisprofilDE/Example-patient-de-basis-humanname-komplex/~xml
Alexander Henket (Oct 02 2017 at 15:20):
I'm missing "Lord" in the list of titles 
Grahame Grieve (Oct 03 2017 at 02:19):
I didn't follow all of this discussion. In your application behind the API, you have the option of storing the full family name, or the parts of the family name, or both. if you choose to store just the parts, that means that when it comes to processing a family name search parameter, your algorithm will have to consider the parts structure. if you don't store the parts, your algorithm will have to consider the likely spelling variations (though you probably have to consider them either way)
Grahame Grieve (Oct 03 2017 at 02:21):
nor did I follow the bit about spacing - what would we need to say about that and why? the situation with whitespace is a little tricky because of XML, where leading and trailing whitespace is poorly controlled, where as in JSON it is nailed down precisely. So what we say is that leading and trailing whitespace is not allowed in string values, but internal whitespace is and is meaningful. isn't that what you want here?
Ewout Kramer (Oct 03 2017 at 08:12):
I think one of the main usecases Alexander is thinking about is that some prefixes get slapped straight in front of the name, and some need a space. E.g. prefix "d'" and name "Artagnan" -> "d'Artagnan". However "van den" and name "Broek" -> "van den Broek". So, to build a full name string from the separate parts, you'd need some info about how you join the parts. So, Alex is referring back to how this was done in v3, by explicitly including the space. I was not at the meeting at DevDays about European names, so I don't know what was concluded there about this....
Marten Smits (Oct 03 2017 at 09:34):
@Alexander Henket I thought we covered all of this during the DevDays: If you want to process the full name, you don't have to combine the parts, because the full name is right there in the family element. If you do store them separately, and discard the full name when you process the resource. You ARE going to have to combine them, but I would think programmers are smart enough to add a white space if a family prefix doesn't end with an apostrophe. Adding a trailing white space in XML is weird and will result in inconsistency because of reasons @Grahame Grieve mentioned.
Grahame Grieve (Oct 03 2017 at 11:46):
I don't think that bit was discussed - but I assumed that you would include the ' as part of the prefix. as for whether a space is included or not - I guess I would assume that if it finishes with punctuation it wouldn't have a space
Grahame Grieve (Oct 03 2017 at 11:47):
but it would be cosmetic either way. if my surname is Mc. Kenzie, I'm going to be completely used to getting 'McKenzie', 'Mckenzie', 'Mc.Kenzie', 'Mc. Kenzie' and 'Mc Kenzie'... you wouldn't hardly notice anymore...
Ewout Kramer (Oct 03 2017 at 11:58):
"(...) I guess I would assume that if it finishes with punctuation it wouldn't have a space, but it would be cosmetic either way. if my surname is Mc. Kenzie, I'm going to be completely used to getting 'McKenzie', 'Mckenzie', 'Mc.Kenzie', 'Mc. Kenzie' and 'Mc Kenzie'... you wouldn't hardly notice anymore..."
I think this is a candidate for the Most Pragmatic Solution of the Year award...
Michel Rutten (Oct 03 2017 at 11:59):
As @Marten Smits mentions, I seem to remember we already had an extensive discussion about this earlier. If I remember correctly, the text property is intended to be used for display purposes, as this contains the full name with proper formatting (honorary titles, prefixes, suffixes, spaces, apostrophes, hypens and what not). The separate fields given and family are useful for indexing, searching, sorting etc. I wouldn't try to combine the separate fields into a formatted name, as the specific formatting rules will widely differ per country/language.
Marten Smits (Oct 03 2017 at 12:00):
"(...) I guess I would assume that if it finishes with punctuation it wouldn't have a space, but it would be cosmetic either way. if my surname is Mc. Kenzie, I'm going to be completely used to getting 'McKenzie', 'Mckenzie', 'Mc.Kenzie', 'Mc. Kenzie' and 'Mc Kenzie'... you wouldn't hardly notice anymore..."
I think this is a candidate for the Most Pragmatic Solution of the Year award...
Hear! Hear!
Grahame Grieve (Oct 03 2017 at 12:01):
ha. with a name like Grahame Grieve (weird scottish spellings on both) I'm completely used to people getting both names wrong.
René Spronk (Oct 03 2017 at 13:50):
Just for fun: "The usual convention in the UK, in telephone directories etc is that Scottish surnames starting Mc are, for alphabetical purposes, treated as though there were an invisible a, between the M and the c. Thus our own telephone directory proceeds as McDonald, J.A., MacDonald J.C., McDonald J.M., MacDonald K. etc." - Mc is therefore a kind of voorvoegsel which doesn't end with an apostophe, but yet doesn't merit a trailing space.
Next to Mac (son of) there also Nc (daughter of), NcDonald, http://www.todayifoundout.com/index.php/2014/02/mac-mc-surnames-often-contain-second-capital-letter/ 
Alexander Henket (Oct 03 2017 at 15:24):
We have not covered this detail afaik. It has been the standing way of doing V3 for the last >10 years, and I don't see why this behavior needs change, just yet. Since the international need has not been identified here, let's discuss 'offline' in Dutch specific context.
Last updated: Apr 12 2022 at 19:14 UTC
