FHIR Chat · http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifie · implementers

Stream: implementers

Topic: http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifie


view this post on Zulip Patrick Werner (Oct 27 2016 at 12:57):

we are currently creating FHIR profiles to map all the data from the germen electronic health insurance card to FHIR resources. In this data there is a "vorsatzwort" = family name prefix which i fail to map. I wanted to use the http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier extension. This Extension is using this ValueSet: http://hl7.org/fhir/ValueSet/name-part-qualifier which is a subset of http://hl7.org/fhir/v3/EntityNamePartQualifierR2. I wanted to use the Qualifier: PFX, which is only contained in the v3 Valueset but not in the FHIR Valueset

view this post on Zulip Patrick Werner (Oct 27 2016 at 12:57):

is there a reason why name-part-qualifier is only a subset of the v3 ValueSet?

view this post on Zulip Alexander Henket (Oct 27 2016 at 13:02):

We in The Netherlands created https://www.simplifier.net/NL-BasicComponents/nl-core-humanname-familyname-prefix

In a where I apparently did not pay attention it was decided that VV needed to be removed from ISO 21090 (DTr2), so now Spain, Germany, The Netherlands, Italy, Austria, Switserland and all other countries with prefixes similar to "voorvoegsels" now need an extension of their own

view this post on Zulip Patrick Werner (Oct 27 2016 at 13:40):

couldn't you just use ISO 21090 and use PFX as the qualifier on HumanName.name in the Extension? I really like this complex extension which contains qualifier and value. Much easier than having multiple names which must be sliced.
Am i right with the assumption that name-part-qualifier is just a subset of ISO 21090 ?

view this post on Zulip Alexander Henket (Oct 27 2016 at 19:07):

PFX just says something is a prefix, not what type of prefix

view this post on Zulip Grahame Grieve (Oct 27 2016 at 19:08):

we removed PFX from the extension because there's <prefix value=""/>

view this post on Zulip Simone Heckmann (Oct 28 2016 at 15:46):

So what do we do? Having different national extensions for the exact same thing is weird. Is there a way to get "VV" back into the ValueSet even if it's not part of the ISO Standard...? BTW: is there a particular reason why the extension doesn't reference a proper ValueSet or is that just work in progress?

view this post on Zulip Grahame Grieve (Oct 28 2016 at 20:39):

it does reference a proper value set

view this post on Zulip Grahame Grieve (Oct 28 2016 at 20:40):

which is actually a problem with VV. We removed VV because no one else is doing VV (eg. vCard). Can we just get the requirements for VV straight?

view this post on Zulip Simone Heckmann (Oct 28 2016 at 20:48):

Ah right. I was looking at "summary" instead of"full structure" and didn't see the valueSet reference.
As for the requirements: We have a "Vorsatzwort" on the German Health insurance card...

view this post on Zulip Grahame Grieve (Oct 28 2016 at 20:50):

as in, it's a part of the name pieces?

view this post on Zulip Simone Heckmann (Oct 28 2016 at 21:03):

it's the "van" in "van Beethoven"
However, in the health insurance card specification, "name" is not a complex type. All the name parts are just attributes of Person:
pasted image

view this post on Zulip Grahame Grieve (Oct 28 2016 at 21:07):

implicit name type then. And you need to round trip? so VV is not a part of the family name?

view this post on Zulip Simone Heckmann (Oct 28 2016 at 21:10):

I think it's considered part of the family name, however, "van Beethoven" is usually alphabetically listed under "B"

view this post on Zulip Simone Heckmann (Oct 28 2016 at 21:11):

What do you mean by "round trip"?

view this post on Zulip Simone Heckmann (Oct 28 2016 at 21:21):

Wow. I never knew there are so many of those https://www.gkv-datenaustausch.de/media/dokumente/arbeitgeber/deuev/rundschreiben_anlagen/GemRS_Anlage_06.pdf :astonished:

view this post on Zulip Grahame Grieve (Oct 28 2016 at 21:23):

Mehr als ich wusste

view this post on Zulip Grahame Grieve (Oct 28 2016 at 21:23):

round trip = need to be able to read the health insurance code, and then write back to it the same

view this post on Zulip Simone Heckmann (Oct 28 2016 at 21:39):

I guess it's a not-so-uncommon requirement to keep family name and VV separate in order to be able to maintain the correct sort order of the name. So round trip = yes, though we probably wouldn't want to write back to the card ;-) . I guess the major issue here is not that we can't keep the VV seperate from the name, the problem is that we can't tell VV and title apart, because in FHIR they'd both end up as prefixes...

view this post on Zulip Grahame Grieve (Oct 28 2016 at 21:42):

@Alexander Henket is this the same for Dutch? what about other places where VV applies? and what do you do in vCard (e.g. standard address book applications)?

view this post on Zulip Simone Heckmann (Oct 28 2016 at 21:57):

Tagging @Irma Jongeneel @dr Kai U. Heitmann @Oliver Egger for opinions...

view this post on Zulip Marc de Graauw (Oct 28 2016 at 22:25):

Yes, that's our 'voorvoegsel' (VV). Actually, Beethoven has 'van' because his family came from the Dutch speaking parts of Europe (Mechelen, Belgium). In German, 'von' would be the more common variant. And indeed, my name (de Graauw) is/should be listed under 'G'.

view this post on Zulip Simone Heckmann (Oct 28 2016 at 22:41):

How about this: We use HumanName.prefix for both academic titles AND all sorts of VVs but instead of adding a qualifier to the VV, we add it to the academic title. We could use the ISO qualifier extension on HumanName.prefix for that, as it has a suitable code "AC" and assume that all prefixes that are NOT academic titles are some sort of VV.... (Are there even other types of prefixes, that are neither titles nor VVs?) Systems not using the extension would not be able to distinguish title from VV and probably just concat all prefixes in sequence when displaying the name which would be correct in most cases. Sort order would be correct in both cases, too...
We'd then map our insurance card data as
Titel -> HumanName.prefix with extension = AC
Vorsatzwort -> HumanName.prefix without extension
Nachname -> HumanName.family

view this post on Zulip Simone Heckmann (Oct 28 2016 at 22:43):

That however would be in contradiction to the given example:
pasted image
Though that needs revision anyway, since the code VV doesn't exist for the extension...

view this post on Zulip Marc de Graauw (Oct 28 2016 at 22:46):

In Dutch, I am drs. Marc de Graauw (title, given name, voorvoegsel, family name). Voorvoegsel is part of the family name. Paper phone books would list this something like: "Graauw, de; drs. Marc". In English speaking conferences, my name card is always under "De Graauw" , which is plain wrong (but I've given up correcting that) .

view this post on Zulip Grahame Grieve (Oct 28 2016 at 22:58):

i think that adding a qualifier to normal prefixes is.. .odd

view this post on Zulip Grahame Grieve (Oct 28 2016 at 22:59):

I see this in the examples:

<name>
  <use value="official" />
  <family value="van">
    <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier" >
       <valueCode value="VV" />
    </extension>
  </family>
  <family value="Hentenryck" />
  <given value="Karen" />
</name>

view this post on Zulip Grahame Grieve (Oct 28 2016 at 23:01):

why don't we all just use that?

view this post on Zulip Marc de Graauw (Oct 28 2016 at 23:06):

@Simone Heckmann That might work for most cases. Some more complicated names:
A.F.Th. van der Heijden (Dutch writer, both 'van' and 'der'are voorvoegsels, order matters)
William Gates III (a non-VV and non-title postfix)
Berend-Jan baron van Voorst tot Voorst (first name, title, voorvoegel, last name - which contains the voorvoegsel 'tot' which has been collapsed into the last name)
Frank Sinatra junior (again a a non-VV and non-title postfix)

view this post on Zulip Marc de Graauw (Oct 28 2016 at 23:09):

To complicate matters: while in the Netherlands my name would be sorted under G as "Graauw, de", in Belgium they sort on voorvoegsels, so "Van den Casteele" would be under V. Sigh...

view this post on Zulip Grahame Grieve (Oct 28 2016 at 23:11):

so I still think that the example in the spec is that right way to do it. It seems to meet all the requirements we've canvassed, including those ones

view this post on Zulip Marc de Graauw (Oct 28 2016 at 23:13):

@Grahame Grieve Which prefixes count as 'normal' is a bit situation-dependent :-) VV's 'de' and 'van' are pretty common here...

view this post on Zulip Grahame Grieve (Oct 28 2016 at 23:13):

umm, yes but so?

view this post on Zulip Elliot Silver (Oct 28 2016 at 23:16):

What's the reason to be able to decompose the various parts? If it's just to order correctly, then what about something like:

<name>
    <family value="van Henterenryck">
    <extension url="http://hl7.org/fhir/sort-as" >
       <valueString value="Henterenryck; van" />
    </extension>
  </family>
  <given value="Karen" />
</name>

view this post on Zulip Marc de Graauw (Oct 28 2016 at 23:17):

Well, it think it would work when one distinguishes between titles and 'VV' in some way. One could not derive sort order, but that may be asking too much.

view this post on Zulip Grahame Grieve (Oct 28 2016 at 23:17):

the example in spec distinguishes, and allows sort order

view this post on Zulip Marc de Graauw (Oct 28 2016 at 23:22):

My name is "Marc de Graauw", but needs to be sorted as "Graauw, de; Marc". If I were Belgian, my name would be "Marc De Graauw" (or "de", they have both) and would need to be sorted as "De Graauw, Marc". Dutch names are not normally used in family-given order as Chinese names, that's only the phone book order. I don't think there's a way to derive sort order from the order of the name parts in the normal sequence.

view this post on Zulip Grahame Grieve (Oct 28 2016 at 23:23):

but you said before that the sort order changes from country to country, not from person to person

view this post on Zulip Marc de Graauw (Oct 28 2016 at 23:25):

Yes, and am still saying that, am I not?

view this post on Zulip Grahame Grieve (Oct 28 2016 at 23:26):

well, I wasn't sure. The example in the spec works for country to country order decisions.

view this post on Zulip Marc de Graauw (Oct 28 2016 at 23:27):

BTW, I don't mind if FHIR does not support all the niceties of Dutch name sorting - I think that's asking too much, and obviously there will be some community in the world with other niceties we've overlooked. Distinguishing 'title' from 'VV' with a qualifier though would be helpful.

view this post on Zulip Grahame Grieve (Oct 28 2016 at 23:27):

by default, the render order would be "De Graauw", since De is a family name. but for systems that are a VV aware, they can choose a different ordering where De is known as a VV and they can put it after or elsewhere

view this post on Zulip Marc de Graauw (Oct 28 2016 at 23:27):

Right, agree.

view this post on Zulip Grahame Grieve (Oct 28 2016 at 23:29):

the problem with the example in the spec is that it's not legal. but if I was to make it legal, then everyone could use that without any problems.

view this post on Zulip Marc de Graauw (Oct 28 2016 at 23:37):

Yes. Maybe 'VV' is too much based in Dutch? I guess the real distinction is between prefixes which are an inherent part of the (family) name (like 'de' and 'van', and the German/French/Spanish etc. ones) and acquired prefixes such as (academic) titles. Those are not inherent parts of the name, for instance children don't inherit them. (That leaves nobility a bit in the middle, maybe.)

view this post on Zulip Grahame Grieve (Oct 28 2016 at 23:46):

so we have <prefix> for them

view this post on Zulip Simone Heckmann (Oct 29 2016 at 06:51):

From what I could find, most of our systems would capture Marc as
title = Dr.
prefix= de
given = Marc
family = Graauw

The example could work for us, except the mapping for some systems would be a bit strange.
title -> prefix
prefix -> family (VV)

I guess for most vendors,
title -> prefix (AC)
prefix -> prefix
would be a more intuitive approach.

view this post on Zulip Grahame Grieve (Oct 29 2016 at 09:11):

well, for v3 compatibility, VV has always been regarded as part of a family name (a prefix to it(

view this post on Zulip Grahame Grieve (Oct 29 2016 at 09:11):

hence the example in the spec. And it seems to match the behaviour Marc described for non-VV aware systems

view this post on Zulip Stefan Lang (Oct 29 2016 at 12:05):

Ah, I oversaw the discussion here and answered in the german thread ;-)
To sum it up: to my understanding, prefix is meant to be before the complete name in FHIR while the VV has to be placed between given an family name parts since it actually is part of the family name.
So family(VV) seems more consistent to me, even if the naming differences might be irritating to implementers at their first glance.

view this post on Zulip Simone Heckmann (Oct 29 2016 at 15:21):

I agree with preferring VV as part of family, because otherwise, systems oblivious to the extension would get the display sequence mixed up. This was, they only get the sort order wrong. Can I make a motion to add VV (or an equivalent code) to the ValueSet? :)

view this post on Zulip Simone Heckmann (Oct 29 2016 at 15:49):

Interestingly, V2 even hat Subsubcomponents for "Prefix of Spouse Name", e.g.:
Jongeneel-de Haas is noted as
Jongeneel-de Haas&&Jongeneel&de&Haas
What would that look like in FHIR?

<family value=Jongeneel>
<family value="de">
    <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier" >
       <valueCode value="VV" />
    </extension>
  </family>
  <family value="Haas" />

...but where would the dash go...?

view this post on Zulip Simone Heckmann (Oct 29 2016 at 15:53):

Though, on second thought, this kind of differentiation is pretty pointless as it doesn't affect the sort order or the way the person is being addressed. So why would anyone care? The name is <family value = "Jongeneel-de Haas"> listed under "J" and that's it. Or am I missing something?

view this post on Zulip Simone Heckmann (Oct 29 2016 at 17:35):

Ok, after a few more hundred lines of Chat in the german stream, I think we are agreed, that our UseCase would be satisfied, if we had a code "VV" in the ValueSet for the ISO extension.
@Alexander Henket : Do you support this Change Request? Or does NL rather maintain a national extension?

view this post on Zulip Simone Heckmann (Oct 29 2016 at 17:49):

...and we'd use the extension on HumanName.family, not on HumanName.prefix

view this post on Zulip Grahame Grieve (Oct 29 2016 at 20:07):

well, do you want to make a task?

view this post on Zulip Alexander Henket (Oct 30 2016 at 10:36):

I don't get why we have a requirements discussion around VV again. It's been in there for ages because we had the requirements back then. Sigh. The discussion roundtrips perfectly at least.

Ok, so the voorvoegsels are part our national law stemming back from the times where Napoleon forced people into last names. This law is sort the same in Spain, Belgium, France, Italy, Germany, Netherlands and then some.

The voorvoegsel are part of the family name with explicit space, but do not count in sorting. The Americans and a number of Belgians have concatenated the voorvoegsel to their last names so in their case you can no longer distinguish voorvoegsel from last name and so it sorts on voorvoegsel too. "Vanderbroeken" was once "van der Broeken".

Voorvoegsels are supported in 100% of systems in The Netherlands and I assume in Germany and roundtrip sending in and coming out.

https://en.wikipedia.org/wiki/Tussenvoegsel (voorvoegsel and tussenvoegsel are interchangeable words for the same concept) The nationally recognized voorvoegsels are these http://www.vernoeming.nl/alle-333-voorvoegsels-tussenvoegsels-in-nederlandse-achternamen

view this post on Zulip Alexander Henket (Oct 30 2016 at 10:44):

As for VV: I'd love to get it back. It was removed in later versions of ISO 21090, and so it is missing from where it once was: http://build.fhir.org/v3/EntityNamePartQualifierR2/vs.html

view this post on Zulip Alexander Henket (Oct 30 2016 at 10:45):

As for the extension. We chose to sty close to the original datatype and extend under family to break a composite family name down into its parts. So a plain FHIR system handles it normally while a Dutch aware system handles it better

view this post on Zulip Alexander Henket (Oct 30 2016 at 10:47):

It is the same strategy for addrLines which we also used to break down into its constituents.

view this post on Zulip Robert McClure (Oct 30 2016 at 16:41):

This sort of discussion makes a terminologist's toes tingle (it's a bar discussion as to if that is a good or bad sensation ;-). It would be a good thing to also consider east asian names in all this. Is some sort of voorvoegsel used there too?

view this post on Zulip Marc de Graauw (Oct 30 2016 at 17:10):

@Alexander Henket The Belgians don't always concatenate, and if they don't , sorting is on voorvoegsel ("De Graauw" is under "D"). See https://nl.m.wikipedia.org/wiki/Tussenvoegsel

view this post on Zulip Marc de Graauw (Oct 30 2016 at 17:12):

I'm 100% pro getting "VV" back. Either in family name or prefix, I think it would work both ways.

view this post on Zulip Stefan Lang (Oct 30 2016 at 17:17):

Preferably in family, for the sake of systems not knowing about VVs (they exist, at least here in Germany)

view this post on Zulip Grahame Grieve (Oct 30 2016 at 20:22):

not as far as we are aware. There are different naming patterns there

view this post on Zulip Simone Heckmann (Oct 31 2016 at 09:35):

I think the iso extension is doing a pretty good job at covering the use cases describd here (except for the fact that the VV/PFX code is missing). If the Belgians don't use prefixes for sorting, that makes them the lucky candidates for simply ignoring the extension, so the prefix becomes just a regular part of the last name. Since the extension can be applied to any part of the name, I think even the Asian folks should be able to cover their bases. However, now would be a good time for someone to go through the ValueSet and see if there are codes missing to satisfy their requirements.

view this post on Zulip Patrick Werner (Oct 31 2016 at 10:32):

got a offline weekend and missed the discussion i've started.
After reading all comments i also would prefer to reinclude VV (or an english equivalent like "family name prefix")in the http://hl7.org/fhir/ValueSet/name-part-qualifier ValuesSet and use the ISO21090 Extension.
My only concern is how would i be able to profile a HumanName restrictive.

view this post on Zulip Patrick Werner (Oct 31 2016 at 10:38):

If i want to create a patient profile for the date of the german health insurance card . I want to have 1..1 family names, 1..1 given Names and 0..1 Vorsatzworte
If we insert Vorsatzwort as a extended family name i would have to slice family name use extension as the discriminator. Which is easy for the Vorsatzwort, but the regular family name doesn't has an extension

view this post on Zulip Patrick Werner (Oct 31 2016 at 10:38):

is there a way to profile this?

view this post on Zulip Ewout Kramer (Oct 31 2016 at 10:51):

What is it that you want to profile? That VV occurs at max once in <family>?

view this post on Zulip Patrick Werner (Oct 31 2016 at 10:57):

i want to profile the kardinalities of the HumanName part of a patient based on our electronic health card insurance dataset: given name 1..1, and yes VV max once in family, and 1..1 of the regular family name without a extension

view this post on Zulip Ewout Kramer (Oct 31 2016 at 11:04):

ah, so the total cardinality of <family> would be 1..2. If there are two, the first one would need to have the extension, and if there's only one the VV may not be present?

view this post on Zulip Patrick Werner (Oct 31 2016 at 11:05):

exactly

view this post on Zulip Ewout Kramer (Oct 31 2016 at 11:05):

interesting challenge.

view this post on Zulip Ewout Kramer (Oct 31 2016 at 11:05):

I think I would take the easy way out and formulate an FluentPath invariant

view this post on Zulip Ewout Kramer (Oct 31 2016 at 11:07):

(HumanName context) family.extension('whatever url').count() < family.count()

view this post on Zulip Ewout Kramer (Oct 31 2016 at 11:08):

Probably more readable than fancy slicing constructions

view this post on Zulip Patrick Werner (Oct 31 2016 at 11:11):

thanks for the input ewout. I'll dig into this

view this post on Zulip Patrick Werner (Oct 31 2016 at 11:13):

is there any starting point for the integration of FluentPath/FhirPath into profiles?

view this post on Zulip Ewout Kramer (Oct 31 2016 at 11:59):

Yes, in STU3, ElementDefinition.constraint.source is a FhirPath expression

view this post on Zulip Michel Rutten (Oct 31 2016 at 11:59):

Not-so fancy slicing may also work:

  • Optional slice A (0..1) with mandatory extension (1..1)
  • Mandatory slice B (1..1) without extension (0..0)

view this post on Zulip Ewout Kramer (Oct 31 2016 at 12:00):

and ordering

view this post on Zulip Michel Rutten (Oct 31 2016 at 12:00):

yup

view this post on Zulip Ewout Kramer (Oct 31 2016 at 12:02):

In DSTU2, it's done using an extension:

<constraint>
              <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-expression">
                <valueString value="sourceId or (targetId.count() + url.count() + params.count() = 1) or (type.code in ('conformance' | 'search' | 'transaction' | 'history'))" />
              </extension>

view this post on Zulip Patrick Werner (Oct 31 2016 at 14:55):

@Michel Rutten what would be the discriminator in your not-so fancy example? Patient.name.family.extension.url shouldnt work when i have a slice which doesn't has an extension defined, right?

view this post on Zulip Patrick Werner (Oct 31 2016 at 15:05):

related to the not-so fancy slicing: what is the proper way to set extension of an element to 0..0 in Forge. I can't find this option

view this post on Zulip Michel Rutten (Oct 31 2016 at 15:11):

@Patrick Werner I guess the discriminator would be empty, as in this case it is not necessary (greedy matching).
Forge does not (yet) provide UI for the common extension collection element, so you cannot set the cardinality of the collection to zero (expressing that no extensions whatsoever are allowed). However you can add a specific extension and then set the cardinality of that element to zero, expressing that this specific extension is prohibited.

view this post on Zulip Patrick Werner (Oct 31 2016 at 15:11):

thx

view this post on Zulip Grahame Grieve (Oct 31 2016 at 18:08):

@Simone Heckmann so I have added VV to the extension, though no one has created a task for this yet

view this post on Zulip Simone Heckmann (Oct 31 2016 at 19:28):

Ok, Thanks! I wanted to wait, if anyone finds another code missing. But that doesn't seem to be the case, so I will create the task.

view this post on Zulip Simone Heckmann (Oct 31 2016 at 19:35):

GF#12310

view this post on Zulip Alexander Henket (Oct 31 2016 at 20:50):

Hard to track everything in here. I think what you landed on is an extension of family and use the repetition on family right?

How then do you support "Monique van Wijk-de Boer" where:

http://www.hl7.nl/wiki/index.php?title=DatatypesR1:PN

"van" is voorvoegsel maiden name
"Wijk" maiden name
"-" is delimiter between maiden and partner name
"de" is voorvoegsel partner name
"Boer" is partner name

V2:
"van Wijk-de Boer&van&Wijk&de&Boer^Monique"

V3:
<name>
<given>Monique</given>
<prefix qualifier="VV BR">van </prefix>
<family qualifier="BR">Wijk</family>
<delimiter>-</delimiter>
<prefix qualifier="VV SP">de </prefix>
<family qualifier="SP">Boer</family>
</name>

FHIR:
<name>
<family value="van">
<extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier" >
<valueCode value="VV" />
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier" >
<valueCode value="BR" />
</extension>
</family>
<family value="Wijk">
<extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier" >
<valueCode value="BR" />
</extension>
</family>
<family value="-">
<extension url="http://hl7.org/fhir/v3/EntityNamePartTypeR2" >
<valueCode value="DEL" />
</extension>
</family>
<family value="de">
<extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier" >
<valueCode value="VV" />
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier" >
<valueCode value="SP" />
</extension>
</family>
<family value="Boer">
<extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier" >
<valueCode value="SP" />
</extension>
</family>
<given value="Monique"/>
</name>

And what about implicit spacing? How do I distinguish between "d'Artagnan" where "d'" is the voorvoegsel, and "de Boer" where "de" is the voorvoegsel? In the first case I do not want a space between d'Artagnan, but in the second I do... In V3 we explicitly added spaces as required, because <prefix/> did not have implicit spaces.

FHIR really explodes in your face with inefficiency for just about any Dutch system. Not a very good value proposition. I think I'd rather see HumanName enhanced than any extension related proposal. Datatypes for Names and Addresses really need to be more capable than the 20% basic functionality they now support.

Added this to GF#12310 too.

view this post on Zulip Stefan Lang (Oct 31 2016 at 22:19):

Which real life system would support that complexity? And what would be the use of doing so instead of putting "Wijk-de Boer" into (main) family?
This would be enough to get alphabetic sorting right as well as reproducing the data structure of the German insurance card (which was the origin of this thread).

view this post on Zulip Grahame Grieve (Nov 01 2016 at 06:02):

Right. were we to care, we could explode the complexity of HumanName in multiple directions. People who care might read my mother's name history in ISO 21090 under EN - we don't cater for that kind of stuff, and we don't need to

view this post on Zulip Alexander Henket (Nov 01 2016 at 09:01):

I don't ask for more than V2/V3 already handled and has been in use for 20+ years. I'm sure you'd agree that a FHIR HumanName does not stack up against a V2 FN (XPN)/V3 PN when you place them side by side

view this post on Zulip Grahame Grieve (Nov 01 2016 at 09:02):

those are 2 different things

view this post on Zulip Alexander Henket (Nov 01 2016 at 09:03):

Not sure how?

view this post on Zulip Grahame Grieve (Nov 01 2016 at 09:14):

all sorts of random junk made their way into v2/v3. We're trying to focus on what people use

view this post on Zulip Alexander Henket (Nov 01 2016 at 09:15):

And I'm telling you that distinguishing partner name, birth name and voorvoegsels thereof fits that profile :-)

view this post on Zulip Alexander Henket (Nov 01 2016 at 09:15):

100% of systems here do this.

view this post on Zulip Alexander Henket (Nov 01 2016 at 09:20):

Same is true for addresses. 100% of systems here can and will distinguish streetName from houseNumber and houseNumber from houseNumber additions.

The zipcode table works based on zip + houseNumber without additions so it is important to keep them apart.

1000 AA + 2 will lead to an address
1000 AA + 2B II will not necessarily

view this post on Zulip Alexander Henket (Nov 01 2016 at 09:21):

So, just like concatenated family names, we will need extensions to split addrLines too

view this post on Zulip Ewout Kramer (Nov 01 2016 at 09:39):

I did not really like the way v3 handled the delimiters, I don't think many systems disassemble names into that detail. And also, the fact that the name is partitioned into an ordered and mixed set of <given>, <prefix> and <family> is something that XML can model and represent, but it's pretty nasty for relational databases.

view this post on Zulip Ewout Kramer (Nov 01 2016 at 09:40):

But I do agree, we need to distinguish maiden name (which is done, using two separate <names> in FHIR). And of course separate the VV from the familyname.

view this post on Zulip Ewout Kramer (Nov 01 2016 at 09:44):

All the subteties around how to re-concatenate stuff you just carefully disassembled (e.g. d'Artagnan) - it makes me careful about doing too much disassembly. When I worked with v3, the handling of spaces and delimiters was a constant pain.

view this post on Zulip Ewout Kramer (Nov 01 2016 at 09:45):

It's easy for me to ask my colleagues what kind of input our market-leaders here take, e.g. Chipsoft and Epic.

view this post on Zulip Grahame Grieve (Nov 01 2016 at 09:45):

please do

view this post on Zulip Ewout Kramer (Nov 01 2016 at 10:03):

The set is: Birthname, Birthname voorvoegsel (VV), Partnername, Partnername voorvoegsel (VV), initials, firstname

view this post on Zulip Grahame Grieve (Nov 01 2016 at 10:04):

that's... eclectic.....

view this post on Zulip Ewout Kramer (Nov 01 2016 at 10:06):

But certainly not surprising, I think it's pretty representative. I expect even more systems will just have First + VV + Last. Where the patient gets to choose what lastname she wants to use, since there are many who really don't want their partners name to appear, and the converse is true too. There will be patients who really want to use their partners name. Mentioning both -at least to me- is very formal.

view this post on Zulip Ewout Kramer (Nov 01 2016 at 10:09):

But @Alexander Henket , we are meeting quite some dutch vendors this thursday, won't we? We can just ask what they are doing...

view this post on Zulip Marc de Graauw (Nov 01 2016 at 18:03):

I don't see a problem using extensions for Dutch house numbers and partner name handling. It's pretty hooked up to our national laws and customs. VV is different, that's multinational. And I have never seen a live lsystem which actually supports the different spacing in "d'" and "de" outside v3 messages.

view this post on Zulip Simone Heckmann (Nov 01 2016 at 19:16):

I think the difficult task right here is
a) to differentiate which name parts/qualifiers are in the international scope and thus should be core extensions an which are national extension scope. I agree we wouldn't want to have all of the national/regional excentrics in the core. But neither would we want different national extensions for the same concept.
b) we really need to educate implementers, that there is no one field in FHIR that holds the family name but instead the family name is always the concatenation of all repetitions of family. I guess that is the major change in comparison to V2/3.

view this post on Zulip Grahame Grieve (Nov 01 2016 at 19:38):

how is that a change to v2/v3?

view this post on Zulip Alexander Henket (Nov 02 2016 at 06:37):

I think it is not so much a change from V2/3 but from current thinking in FHIRs HumanName where, although <family/> repeats you normally think of just one.

view this post on Zulip Alexander Henket (Nov 02 2016 at 06:44):

But Alexander, we are meeting quite some dutch vendors this thursday, won't we? We can just ask what they are doing...

What type of question would you like to ask them? Whether or not they would mind if we did the extension in a different way than previously agreed so we align better with Germany and other countries?

view this post on Zulip Simone Heckmann (Nov 02 2016 at 17:36):

V2 had the full name with all parts/delimiters as first component and the individual parts in the following subfields. Implementations that "didn't care" just read the first field and ignored the rest. There was no need to "assemble" the family name from it's components. Don't know about V3, though...

view this post on Zulip Simone Heckmann (Nov 02 2016 at 20:35):

I am starting to wonder if - both from a profiling and an implementing perspective - it wouldn't be easier, to simply put the full family name (as it is supposed to be displayed) into family and use a flat list of distinct extensions for any part of the name that has a special meaning? The downside would be that there'd be a rather large catalogue of core extensions (one for each value in the Iso set) plus one for the "plain" name for sort order but then again only few of them would be relevant in one particular UseCase/Realm.

Sort of like this:

(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>

(Belgian version)
     <family value="van Wijk-de Boer"/>

That way, regional profiles could pick whatever extension they need, common concepts could be shared across borders, profiling would be as simple as adding an extension to the HumanName-Datatype, Spacing and Delimiters need no special handling (the name is displayed exactly the way it is spelled in HumanName.family) and even the dumbest of systems that ignore all extensions had a good chance to get it right...

view this post on Zulip Simone Heckmann (Nov 02 2016 at 20:37):

...not meaning to say that Belgian systems are the dumbest. The are just in the lucky position, that name parts don't seem to have any special meaning and don't affect sort order ;-)

view this post on Zulip Alexander Henket (Nov 02 2016 at 20:41):

That is what we landed on. 1 family, break down underneath.

Except that our breakdown is more complex. We don't just need VV, but "VV BR" and "VV SP". Otherwise you cannot distinguish "van" in "van Wijk" from "de" in "de Boer".

The current standard extensions do not support this.

view this post on Zulip Elliot Silver (Nov 02 2016 at 20:41):

This is sort of what I had suggested a couple of days ago. I think most systems are interested in two things: how to display, and how to sort. Does flagging a part of the name as VV have value, except as determining one of those things?

view this post on Zulip Alexander Henket (Nov 02 2016 at 20:43):

Sort order for systems that store separate name parts will need to depend on order in the break down (V3 style), or... we need yet another extension to tell us sort order

view this post on Zulip Elliot Silver (Nov 02 2016 at 20:45):

I think what I was asking was do you need the VV BR, VV SP, etc. extensions, when what you are really trying to derive is sort order? Or is there another need to identify the various parts?

view this post on Zulip Simone Heckmann (Nov 02 2016 at 20:45):

Yes, I do see a point in flagging:
There may be other name parts that also do not affect sort order (nobility) but should be distinguishable from VV. Also, I belive, MPIs would want to be able to separate the Spouse Name VV (as in Alexander's example) even though, it has no effect on sort order

view this post on Zulip Alexander Henket (Nov 02 2016 at 20:46):

Hang on... there two sort orders at play.
1. Maiden name before/after Partner name
2. Whether or not the voorvoegsel counts for sorting in name lists

view this post on Zulip Alexander Henket (Nov 02 2016 at 20:47):

I was solely talking about the first. As long as a Dutch system knows what the voorvoegsel is, it will never use that for sorting. Don't care if you are Belgian (I think)

view this post on Zulip Simone Heckmann (Nov 02 2016 at 20:48):

We are dealing with a health insurance card that distinguishes nobility and voorvoegsel. Not saying there's any point in that but that's the way it is :-/

view this post on Zulip Alexander Henket (Nov 02 2016 at 20:48):

Does nobility count for sorting?

view this post on Zulip Elliot Silver (Nov 02 2016 at 20:49):

Does sort order depend on the system's nationality, or the patient's?

view this post on Zulip Alexander Henket (Nov 02 2016 at 20:49):

Doesn't for us. King Willem-Alexander van Oranje Nassau sorts under "O"

view this post on Zulip Simone Heckmann (Nov 02 2016 at 20:50):

nope. Although: some systems may sort noble patients at the top of the list, no matter what name :D

view this post on Zulip Alexander Henket (Nov 02 2016 at 20:50):

I think a Dutch system works the same way regardless of patient nationality.

view this post on Zulip Alexander Henket (Nov 02 2016 at 20:51):

If you are called "Tom de Jong" and you want to be sorted under "de Jong", then all you can do is enter "de Jong" in the last name (birth/partner) field and skip usage of voorvoegsel

view this post on Zulip Alexander Henket (Nov 02 2016 at 20:52):

But better make sure you are registered like that at the national person registry too otherwise this prevails at certain points...

view this post on Zulip Simone Heckmann (Nov 02 2016 at 20:54):

Patient?family=Jong would always try to match at the beginning of the name, so it wouldn't show "de Jong" as a result, right?

view this post on Zulip Simone Heckmann (Nov 02 2016 at 20:54):

...unless you say /Patient?family:contains=Jong

view this post on Zulip Simone Heckmann (Nov 02 2016 at 20:56):

maybe that would be an argument for sticking to the original idea of splitting the name parts into multiple iterations of family...?

view this post on Zulip Simone Heckmann (Nov 02 2016 at 20:57):

that way: no matter what part of the name you search for, you'd alway get a hit as long as it matches any part of the name. (Assuming the extensions are not considered when searching on family)

view this post on Zulip Elliot Silver (Nov 02 2016 at 20:58):

Unless you happen to search for "Smith-Jones"

view this post on Zulip Simone Heckmann (Nov 02 2016 at 20:59):

Right. Maybe that's even worse! If you'd go the extra mile to type the full name into the search box, you wouldn't get any results if the name is stored only in fragments!!

view this post on Zulip Simone Heckmann (Nov 02 2016 at 21:01):

That's an even stronger reason to have the full name with all of it's parts stored in family and use only the extensions to break out the parts.

view this post on Zulip Simone Heckmann (Nov 02 2016 at 22:01):

I think Elliot just raised the most important issue with the current situation. Finding the Patient by Name (a) is more important than displaying the Name correctly (b) is more important that sorting the Name correctly (c).
The current solution (family repetitions with ISO-extension qualifier) is

  • failing at (a) - you type the full name correctly and get 0 results
  • shaky at (b) - proper display needs concatenation of all name parts (handling of delimiters/spacing is unclear)
  • doing okay at (c) - any system interpreting the ISO-Extension correctly will get the sort order right

The alternative suggestion (full name in family + flat list of extensions) would be

  • okay at (a) - typing the full name will get a match, omitting prefixes will only get yield results with the :contains-modifier
  • good at (b) - display as provided in family
  • okay at (c) - any system interpreting the flat extensions correctly will get the sort order right.

That IMHO disqualifies the ISO-Extension!

view this post on Zulip Grahame Grieve (Nov 02 2016 at 22:06):

The search point is interesting and I agree with your priority

view this post on Zulip Grahame Grieve (Nov 02 2016 at 22:06):

no one has mentioned HumanName.text with regard to (b)

view this post on Zulip Grahame Grieve (Nov 02 2016 at 22:07):

I don't think it disqualifies the extension, though

view this post on Zulip Simone Heckmann (Nov 02 2016 at 22:13):

I understand HumanName.text as the preferred representation of the full name, e.g. "King Willem-Alexander van Oranje Nassau". Systems may however need tho display names differently depending on context. In a letter, the Patient would be adressed as "Dear Mr. King van Oranje Nassau", so the system needs to be able to display the last name (and only the last name) correctly.

view this post on Zulip Patrick Werner (Nov 03 2016 at 09:26):

Extensions for the specific parts seems to be a nice granular option. It also would simplify profiling the HumanName-part of a Patient significantly compared to the previous discussed reuse of the same extension with different qualifiers.

view this post on Zulip Grahame Grieve (Nov 03 2016 at 09:27):

can you provide an example of what you mean?

view this post on Zulip Patrick Werner (Nov 03 2016 at 10:23):

its easier to define a restrictive profile slicing the family name with the discriminator on extension urls. Then to interprete some FHIR Path expressions.
One question regarding slicing on Extension URL regarding Simones example (german part): could this family name be sliced on the extension url and for the non-extended family entry just put an empty url in the slice? I guess not. So we would need a extension for the complete name as well?

view this post on Zulip Simone Heckmann (Nov 03 2016 at 10:23):

Example: "van Wijk-de Boer"

ISO-Extension with qualifiers:

<family value="van">
    <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier" >
       <valueCode value="VV" />
    </extension>
  </family>
<family value="Wijk"/>
<family value="de">
    <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier" >
       <valueCode value="VV" />
    </extension>
  </family>
<family value="Boer"/>

"Flat" version with string type extensions:

     <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" />
    </extension>
     <extension url="http://hl7.org/fhir/StructureDefinition/maiden-voorvoegsel">
         <valueString value="de" />
    </extension> 
      <extension url="http://hl7.org/fhir/StructureDefinition/maiden-plain">
         <valueString value="Boer" />
    </extension>

Alexander's proposal had the flat extensions nested unter "family", whereas my example has them directly unter "humanName" just like anyother name part.

view this post on Zulip Patrick Werner (Nov 03 2016 at 10:24):

@Simone Heckmann i'd prefer the flat version, than we don't have to care for my slicing problem mentioned in my last post

view this post on Zulip Patrick Werner (Nov 03 2016 at 10:25):

*then

view this post on Zulip Simone Heckmann (Nov 03 2016 at 10:29):

I don't really have a preference for placing the extensions directly under HumanName or under HumanName.family. Intuitively I'd say: the flatter, the simpler. The only reason I can think of in favor of deeper nesting is that there may be extensions that could be used both as extensions of family as well as given or any other name part. Though I can't currently think of an example...

view this post on Zulip Grahame Grieve (Nov 03 2016 at 10:31):

Simone you have 2 different issues here - full family name with breakdown, or building the family name, and extensions on family name or seperate

view this post on Zulip Grahame Grieve (Nov 03 2016 at 10:31):

at least it seems to that these are orthogonal issues

view this post on Zulip Grahame Grieve (Nov 03 2016 at 10:32):

the second of your options appears to address your issue #1

view this post on Zulip Simone Heckmann (Nov 03 2016 at 10:42):

I think we should stick to the paradigm to keep simple things simple.
Of course, names can be super complicated, if you're a Dutch MPI ;-)
But then again, most systems won't care. And for them, the flat extensions under HumanName are definitely the easiest to ignore. They will just want to read the content of HumanName.family and get the full/correct name and ignore everything else. That's what we need to take care of.

view this post on Zulip Marc de Graauw (Nov 03 2016 at 10:53):

The search issue is interesting, but I'm not sure it's as fundamental as it seems. I don't believe there are many Dutch systems which would support search on "van Wijk-de Boer" as an exact match. And any user searching for it and getting zero results would try "van wijk de boer". When searching on text, in practice one simply sometimes has to try some variants.

view this post on Zulip Ewout Kramer (Nov 03 2016 at 10:53):

But then again, most systems won't care

Right, which is the point I tried to make yesterday. Even the Dutch MPI (we don't really have one, but we have a national server that verifies your national patient ID and returns the demographics for the patient) has a *Very* simple name model. And guess what: many systems just copy that simple data into their database when they verify the dutch BSN.

view this post on Zulip Ewout Kramer (Nov 03 2016 at 10:54):

What you are doing in your "flat" representation is actually saying: decomposition of family name is outside the 80%. Heck, family may be limited to 0..1 in the HumanName.

view this post on Zulip Grahame Grieve (Nov 03 2016 at 10:56):

most implementers would like family name limited to 0..1. but the spanish cultures use multiple surnames a lot

view this post on Zulip Patrick Werner (Nov 03 2016 at 10:58):

and if you profile family name to 1..1 and forbid the use of extensions you should always have a family name. If you'd insert the additional name components as extended family parts and restrict the family name to 1..* you just could add "van" with Extension as a kind of valid family name

view this post on Zulip Simone Heckmann (Nov 03 2016 at 11:01):

Say Hello to Diego Mendez Gonzales: http://fhir2.healthintersections.com.au/open/Patient/1058

view this post on Zulip Ewout Kramer (Nov 03 2016 at 11:01):

Right, but that could be just one <family> with two components.

view this post on Zulip Ewout Kramer (Nov 03 2016 at 11:02):

Do Spanish systems actually have a textbox with a "+" to enter multiple family names separately?

view this post on Zulip Grahame Grieve (Nov 03 2016 at 11:02):

the point that is tricky about spanish multiple surnames is that they have flexible use and order

view this post on Zulip Simone Heckmann (Nov 03 2016 at 11:02):

now let the user type "Mendez Gonzales" into the Searchbox and run http://fhir2.healthintersections.com.au/open/Patient?family=mendez%20gonzales against the server -> 0 results

view this post on Zulip Grahame Grieve (Nov 03 2016 at 11:03):

really? taht sounds like a bug

view this post on Zulip Grahame Grieve (Nov 03 2016 at 11:03):

ah no, because it is split

view this post on Zulip Grahame Grieve (Nov 03 2016 at 11:03):

can search by either name, but not both

view this post on Zulip Simone Heckmann (Nov 03 2016 at 11:04):

That's the point. I the guys name is "Mendez Gonzales" and you search for "Mendez Gonzales" and get no results, then there's a flaw in the system, no?

view this post on Zulip Grahame Grieve (Nov 03 2016 at 11:05):

probably. I'm not sure what would make sense to do about it though

view this post on Zulip Simone Heckmann (Nov 03 2016 at 11:06):

If we'd write
<family value= "Mendez Gonzales">
and optionally add extensions for
<extension url="http://hl7.org/fhir/StructureDefinition/mothers-family-name">
<valueString value="Gonzales" />
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/fathers-family-name">
<valueString value="Mendez" />
</extension>
We'd have the full semantics of the name PLUS correct search results

view this post on Zulip Simone Heckmann (Nov 03 2016 at 11:07):

Full semantics for those who care, that is...

view this post on Zulip Grahame Grieve (Nov 03 2016 at 11:08):

not sure about that. I don't know that you always know which is which. Knowing which is which is not in the ISO 21090 requirements

view this post on Zulip Simone Heckmann (Nov 03 2016 at 11:08):

If in spanish speaking countries the name order is flexible, they may want to add the :contains modifier to their searches so they get all possible matches even if someone types the second part of the name into the searchbox

view this post on Zulip Grahame Grieve (Nov 03 2016 at 11:11):

@diego kaminker can you lead consultation with the Spansih community about this?

view this post on Zulip Simone Heckmann (Nov 03 2016 at 11:12):

Well, the extensions were just meant as an example. How the Spanish model their name parts is up to them. Might as well be just one extension "name-part" with a multiple cardinality...

view this post on Zulip James Agnew (Nov 03 2016 at 11:14):

My Mexican partner has 2 surnames, and sometimes uses one, sometimes uses the other and sometimes uses both. Certainly the current modelling suits her usage best..

Why not just do &family=Mendez&family=Gonzales if you want to match both?

view this post on Zulip Simone Heckmann (Nov 03 2016 at 11:14):

My point is: HumanName.family should always and in every country contain the full family name with all of it's parts, so systems that ignore every other extension still get correct search results (at least with a :contains-search) and are able to display the name correctly.

view this post on Zulip Ewout Kramer (Nov 03 2016 at 11:14):

I think the Dutch can live with Simone's solution. Fortunately, we are in the middle of the Dutch HL7 WGM, so it's easy to verify ;-)

view this post on Zulip Grahame Grieve (Nov 03 2016 at 11:15):

yes James comments is the classic Spanish approach on which the modelling is based

view this post on Zulip Simone Heckmann (Nov 03 2016 at 11:21):

Problem is: that only works if your search criteria can be decomposed into individual criterias (two words). In many other countries, double-names have a delimiter.
In Germany/Dutch... the guy's name would be "Gonzales-Mendes". If you decompose this into family parts (Gonzales, Mendes and Delimiter) and someone types "Gonzales-Mendes" into the searchbox...?

view this post on Zulip James Agnew (Nov 03 2016 at 11:24):

Sure, English also generally uses a hyphen between last names for people who elect to take two of them.

In that case though I'd expect both names to go in a single repetition of humanname.family. There's no reason they both need to be modelled the same way:

  • In Spanish, many people have two distinct family names
  • In English (and German/Dutch it sounds like) many people have one family name with two parts

view this post on Zulip Simone Heckmann (Nov 03 2016 at 11:26):

Thing is: if you need to qualify the name parts with the ISO-Extension, you HAVE to decompose hyphenated names.

view this post on Zulip Stefan Lang (Nov 03 2016 at 11:28):

Wouldn't the search issue on a FHIR server be covered by HumanName.text anyway? Grahame mentioned that earlier ...
One could simply profile it to 1..1
And when it comes to systems based on e.g. a relational model, wouldn't we leave to the system providers how they store their data and how they implement their search algorithms?
Just my 2 cent ;-)

view this post on Zulip James Agnew (Nov 03 2016 at 11:29):

Ah, I wasn't thinking of the ISO extension.. I've never seen that in the wild :)

view this post on Zulip Alexander Henket (Nov 04 2016 at 12:35):

I like the flat proposal in that it has exactly the type of qualifiers we need. I still feel a tendency towards qualifying name parts _under_ the family they break down, so:

<family value="van Wijk-de Boer">
<extension url="http://hl7.org/fhir/StructureDefinition/family-partner-voorvoegsel">
     <valueString value="van" />
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/family-partner-plain">
     <valueString value="Wijk" />
</extension>
 <extension url="http://hl7.org/fhir/StructureDefinition/family-maiden-voorvoegsel">
     <valueString value="de" />
</extension> 
  <extension url="http://hl7.org/fhir/StructureDefinition/family-maiden-plain">
     <valueString value="Boer" />
</extension>
</family>

or even for a breakdown of last name, not further specified:

<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" />
</extension>
</family>

view this post on Zulip Elliot Silver (Nov 04 2016 at 16:29):

I like this direction.

Without going too far down the rabbit's hole, what about nested extensions?

<family value="van Wijk-de Boer">
<extension url="http://hl7.org/fhir/StructureDefinition/family-partner">
    <valueString value="van Wilk">
        <extension url="http://hl7.org/fhir/StructureDefinition/family-voorvoegsel">
            <valueString value="van"/>
        </extension>
        <extension url="http://hl7.org/fhir/StructureDefinition/family-separator">
            <valueString value=" "/>
        </extension>
        <extension url="http://hl7.org/fhir/StructureDefinition/family-plain">
            <valueString value="Wilk"/>
        </extension>
    </valueString>
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/family-separator">
    <valueString value="-"/>
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/family-maiden">
    <valueString value="de Boer">
        <extension url="http://hl7.org/fhir/StructureDefinition/family-voorvoegsel">
            <valueString value="de"/>
        </extension>
        <extension url="http://hl7.org/fhir/StructureDefinition/family-separator">
            <valueString value=" "/>
        </extension>
        <extension url="http://hl7.org/fhir/StructureDefinition/family-plain">
            <valueString value="Boer"/>
        </extension>
    </valueString>
</extension>
</family>

This gives you total control, reduces the number of extension definitions needed (although increases the number of extensions used), and decomposes the name in a consistent manner (last name is made of partner-separator-maiden, partner and maiden are each made of VV-separator-plain).

For simplicity the family-separator extension could be implied when it is a space.

view this post on Zulip Simone Heckmann (Nov 04 2016 at 18:53):

@Elliot Silver :The only argument against nesting, that I can think of is that it may decrease interoperabiliy by hiding extensions that many systems might implement under a extension that only few care about. (Many systems may want to know that "van" is a VV to derive the fact that the name must be sorted under "Wijk" but fewer systems may care about distinguishing partner and spouse name). So the flatter the list, the better the chances for systems to be able to selectively "pick" the extensions they need.

view this post on Zulip Grahame Grieve (Nov 04 2016 at 18:58):

dont't follow? either you know the extensions or not

view this post on Zulip Simone Heckmann (Nov 04 2016 at 19:01):

in Elliot's example, a system that doesn't know the extension "family-partner" would ignore the first branch and subsequently miss the extension "family-voorvoegsel" nested therein, no?

view this post on Zulip Elliot Silver (Nov 04 2016 at 19:05):

@Simone Heckmann But @Alexander Henket 's example requires all systems to know all the extensions if they want to be able to do anything on a sub-complete name basis.

view this post on Zulip Simone Heckmann (Nov 04 2016 at 19:25):

Yes but Alexander's example could probably be enhanced toward interoperbility by renaming the extensions to "family-vv" and "partner-vv", so that systems that only differentiate the first vv, could understand that part of the story and ignore the partner-vv.

view this post on Zulip Grahame Grieve (Nov 04 2016 at 19:26):

you'd still need to know the extension - don't see what that gets you

view this post on Zulip Simone Heckmann (Nov 04 2016 at 19:46):

Ok, back to the drawing board :)

This is our name: van Wijk-de Boer
some systemy may care to know that "van" is a vv, because it affects the sort order
fewer systemy may care to know that "de" is a partner-vv,

if we'd model this as
vv= "van" (the general/primary extension)
partner-vv="de" (the specialized extension)

Both systems could get the information they need.

But if "van" is also modeled as a specialized extension (or nested under a specialized maiden-extension)
maiden-vv="van"
partner-vv="de"
then the unspecialized system can't extract the information it needs anymore.

The question is whether the assumption that "birth name" = "primary name" is legal in Alexander's example...

view this post on Zulip Simone Heckmann (Nov 04 2016 at 19:57):

Maybe we shoud skip this discussion and leave the decision about nesting and naming the extensions to the national affiliates. What's more important to me is that we have a globally agreed upon understanding of how and when a family name should be deconstructed into individual parts and how that affects search and display of the name...

view this post on Zulip Grahame Grieve (Nov 04 2016 at 19:58):

I haven't felt as though we're on a path towards such an understanding here

view this post on Zulip Simone Heckmann (Nov 04 2016 at 20:16):

If we agree that name extensions should be flat or nested string-types and the core family-attribute should hold the full family name with all of it's parts in correct order, I don't see a problem with display and search, even for systems that ignore all extensions or for Patients crossing borders.

But in consequence, most national profiles might choose to constrain the cardinality of family to ..1 in order to prevent confusion about where the parts of the name go and to prevent the issues with search and spacing/delimiters discussed earlier in this thread.

If, on the other hand, we prefer the qualifier approach of the ISO-Extension, resulting in deconstructed names, implementations will have to handle search and display differently.

If there is no international agreement to prefer the former or the latter approach for extending name, even the core family attribute may cause interoperability issues if Patient resources are shared across borders.

view this post on Zulip Simone Heckmann (Nov 08 2016 at 11:20):

The spec says

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.

Sticking to this rule makes it impossible to use the ISO-Extension to qualify the parts of a hyphenated name and it gives interesting results when applying that rule to our favourite example "van Wijk-de Boer".

view this post on Zulip Grahame Grieve (Nov 08 2016 at 11:28):

what wording would you propose then?

view this post on Zulip Simone Heckmann (Nov 08 2016 at 12:15):

I am currently wondering if it makes sense to generally prefer placing the whole name in family (regardless of spelling) and only break out individual parts into extensions, if the they need to be qualified as "birth name", "spouse name" , "nobility", "voorvoegsel" etc.

view this post on Zulip Simone Heckmann (Nov 08 2016 at 12:23):

That way, extensions could be applied to hyphenated and non-hyphenated names in the same mannor, the complexity of search would be reduced and systems had only one field to look for the correct and complete representation of the family name.

view this post on Zulip Simone Heckmann (Nov 08 2016 at 12:33):

What's the benefit of
<family value="Smith">
<family value="Jones">
compared to
<family value="Smith Jones">
?

view this post on Zulip James Agnew (Nov 08 2016 at 12:36):

I don't get why we need a single approach? Why not just do what makes the most sense for the given cultural context (i.e. one name for english/dutch/german/etc and two names for spanish)

view this post on Zulip James Agnew (Nov 08 2016 at 12:38):

If you join both names into a single string, you can't search by "second last name", which is something no English-hyphenated-lastname people would ever do, but is common practice in Spanish speaking countries.

view this post on Zulip Simone Heckmann (Nov 08 2016 at 19:38):

V2 didn't have repeatable family names. How were spanish names handled there?
I'd say using :contains modifier when searching for second last name is easier to implement than splitting the search words up and matching them against multiple iterations of family...?

view this post on Zulip Grahame Grieve (Nov 08 2016 at 21:18):

@diego kaminker can you comment? We're not getting any spanish input here...

view this post on Zulip diego kaminker (Nov 08 2016 at 21:27):

We had the same discussion for Spanish names when we wanted to implement V2.x and CDA. For v2.x some countries used Mother Maiden Name or other 'inventions'. For CDA R2 what I've taught was: First name goes in the first <given> second name goes in the second <given> and this was generally accepted but it would be good to have some kind of 'signal' to really know this regardless of the XML document order. Do not really know which is 'document order' in JSON, if there is such thing...so we could have problems...and may end up creating something (extension?) to slice the different names precisely. In my last FHIR IG I used our current logic (First is first, second is second, who is in third?)...but names where ancillary attributes (the sliced, hard one was the identifier). But given this discussion I may have to revise.. Here was your Spanish input, in English.

view this post on Zulip Grahame Grieve (Nov 08 2016 at 21:30):

thanks. do you mean <family> not <given>?

view this post on Zulip diego kaminker (Nov 08 2016 at 21:30):

On the 'reality check' side: in a lot of Spanish countries people has two to three given names and one to three family names. Two of each is very common. Two family names is LAW in some countries

view this post on Zulip Grahame Grieve (Nov 08 2016 at 21:31):

there is no order of properties in JSON, but there is order in arrays, so we are fine in JSON

view this post on Zulip diego kaminker (Nov 08 2016 at 21:31):

Both. You can have several given and several family names

view this post on Zulip diego kaminker (Nov 08 2016 at 21:35):

This is a part of the law in my country (may be different in other countries)

view this post on Zulip diego kaminker (Nov 08 2016 at 21:35):

Chap. 11: Surnames

When the parents request the inscription of the born with the surname composed of the father or the paternal and the maternal, in all cases, when the birth certificate is drawn up in the Circumscriptions, the following formula shall be recorded at the bottom of the record: "If Inscribes the compound name of the born at the request of the parents "
For the purposes of the application of art. 4¼ of Law 18248, the surname composed of the parents will be considered one, provided that it is proven that its use comes from time immemorial.
The surname of the grandparents will not be added unless the parents have added or request the same in their own minutes simultaneously.

view this post on Zulip diego kaminker (Nov 08 2016 at 21:36):

And you cannot register more than three <given>

view this post on Zulip Grahame Grieve (Nov 08 2016 at 21:38):

ok. so Spanish are using multiple surnames. But Simone does present an interesting idea that could be made to work:
- change family name to 0..1
- replace the ISO 21090 extension with something a bit more focused that allows you to additionally provide a break-down of the single family name
- it would be complex extension with code + string, where code is something like nobility prefix, vervoegsel, spouse name, spouse vervoegsel
- provide search guidance around use of names for Dutch, German, Spanish

view this post on Zulip Simone Heckmann (Nov 08 2016 at 21:38):

So when mapping a family name into a FHIR resource, you'd split up by whitespace and place the parts into iterations of family?
(assuming the current situation with family 0..*)

view this post on Zulip Grahame Grieve (Nov 08 2016 at 21:39):

though you could argue that taht extension might be core element

view this post on Zulip diego kaminker (Nov 08 2016 at 21:42):

Most 'non-legacy' systems have a specific place for First, Second Family and Given so parsing is not needed (well...second...third given are all in 'second'). I don´t know systems with a free part1,part2....partn structure of the names - maybe there are some...

view this post on Zulip diego kaminker (Nov 08 2016 at 21:42):

But again, some way to know 'this is the first' 'this is the second' other than document order may be welcome for clarity sake

view this post on Zulip diego kaminker (Nov 08 2016 at 21:45):

And a lot of times I have to face systems with only one field for given and family or only one field for given and two for family names, so you cannot really trust they will be able to split for storage or queries

view this post on Zulip diego kaminker (Nov 08 2016 at 21:45):

But we can give the chance to do it properly if they support that

view this post on Zulip Simone Heckmann (Nov 08 2016 at 21:48):

How do you normally search for family names? do you have individual search boxes for first/second family name or just one search box and you try to match against any part of the family name?

view this post on Zulip diego kaminker (Nov 08 2016 at 21:51):

Modern systems: separate search boxes. Legacy systems: only one box . Usually you would also indicate other demographics if the name is too common, example 'José Lopez' can bring hundreds of records, it's like 'John Smith'. So you would add Birth Date. In closed systems I can just ask for the last name (min. 3 letters) and build the selection from there.

view this post on Zulip Simone Heckmann (Nov 08 2016 at 21:58):

Ok, assuming the guy's family name(s) was "Kaminker Lopez":
the way it is now with FHIR, searching for \Patient?family=Kaminker%20Lopez would return 0 results, searching for \Patient?family=Kaminker&family=Lopez would return both "Kaminker Lopez" and "Lopez Kaminker".
Is that working for you?

view this post on Zulip diego kaminker (Nov 08 2016 at 22:01):

Both are controversial...I will search for Kaminker and refine afterwards :) but I am very tricky

view this post on Zulip diego kaminker (Nov 08 2016 at 22:01):

Most systems would expect that searching for "Kaminker Lopez" should work

view this post on Zulip diego kaminker (Nov 08 2016 at 22:02):

That's how we usually handle it even if our different name parts are stored in different columns

view this post on Zulip Grahame Grieve (Nov 08 2016 at 22:09):

which underlines that spanish search is different to international search - that will always be less clever

view this post on Zulip Pascal Pfiffner (Nov 08 2016 at 22:30):

Just an FYI, the W3C has some tips when it comes to person names, however they also don't have the one solution. https://www.w3.org/International/questions/qa-personal-names

view this post on Zulip Simone Heckmann (Nov 09 2016 at 08:13):

If we were to always split names at whitespace, and only at whitespace we could get consistent behaviour for display and search across the board. However, splitting at white space will in many cases not reflect the "logical" parts of the name.
(Think: van Weijk-de Boer). The logical splitting (along with the qualifying) would need to go into (national) extensions. Could that be a solution that fits most use cases?

view this post on Zulip Simone Heckmann (Nov 09 2016 at 08:16):

ex: (simplified representation of extensions)

<family value ="van"/>
<family value ="Weijk-de"/>
<family value ="Boer"/>
<birthname-extension value="van Weijk"/>
<spousename-extension value="de Boer"/>

view this post on Zulip Simone Heckmann (Nov 09 2016 at 08:19):

This however rules out the ISO-Extension to add qualifiers to the name parts, since the parts have no special meaning.

view this post on Zulip Simone Heckmann (Nov 09 2016 at 08:23):

For the Spanish names this would mean that -if a single name part contains whitespace (not sure if that is a thing in spanish names-, you'd get an extra iteration of family.
ex. "van Kaminker Lopez"

<family value ="van"/>
<family value ="Kaminker"/>
<family value ="Lopez"/>
<first-family-extension value="van Kaminker"/>
<second-family-extension value="Lopez"/>

view this post on Zulip diego kaminker (Nov 09 2016 at 12:55):

There are some Spanish last names with whitespace, like in "Alfredo De María" where last name is "De María"

view this post on Zulip diego kaminker (Nov 09 2016 at 12:56):

Last suggestion is good but implies 'writing twice' the names. Not sure it will be loved by the developers

view this post on Zulip Grahame Grieve (Nov 09 2016 at 12:59):

not at first look, but once you consider the full range of activities, it's appeal starts to show

view this post on Zulip diego kaminker (Nov 09 2016 at 13:02):

They will expect something along the lines of

view this post on Zulip diego kaminker (Nov 09 2016 at 13:03):

<family which-one="this one is the first family" value="First Family"/>

view this post on Zulip diego kaminker (Nov 09 2016 at 13:03):

But obviously is not possible so let's move with this if possible. I will consult with Fernando too and some other colleagues to see what they think

view this post on Zulip diego kaminker (Nov 09 2016 at 13:09):

This is too much overhead I think but I am not sure: <family> <class value="first"/> <value value="the first family name"/> </family> (class or whatever name you name it, and with whichever code binding strenght you define it)

view this post on Zulip Simone Heckmann (Nov 09 2016 at 13:11):

Thing is: if the logic for splitting the names into parts is not computable, theres no way to implement search.
If you split the names in a computable way (by whitespace)
family=Alfredo
family=De
family=Maria
and you use the same logic to split search terms (by whitespace)
Search for "Alfredo De Maria"would be sent to the Server as /Patient?family=Alfredo&family=De&family=Maria
and you' d get a match.

If you split by non-computable rules
family=Alfredo
family=De Maria
then how do you encode the Search for "Alfredo De Maria"?
/Patient?family=Alfredo&family=De&family=Maria won't match,
neither will /Patient?family=Alfredo%20De%20Maria
only /Patient?family=Alfredo&family=De%20Maria will return a match. But there's no way you can compute that.

view this post on Zulip Alexander Henket (Nov 10 2016 at 10:42):

I found disturbing wording in the FHIR base spec that says: "The parts of a name SHOULD NOT contain whitespace. 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." Source: http://hl7.org/fhir/datatypes.html#HumanName. I also found relevant examples: http://hl7.org/fhir/datatypes-examples.html#HumanName

<name>
    <use value="official" />
    <family value="van">
        <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier" >
            <valueCode value="VV" />
        </extension>
    </family>
    <family value="Hentenryck" />
    <given value="Karen" />
</name>

I have updated our current profiles to look more like the V2 datatype FN did:

<exampleHumanName>
    <family value="Jongeneel-de Haas">
        <extension url="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname-family-maiden">
            <valueString value="Jongeneel" />
        </extension>
        <extension url="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname-family-partner-prefix">
            <valueString value="de " />
        </extension>
        <extension url="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname-family-partner">
            <valueString value="Haas" />
        </extension>
        <extension url="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname-family-name-assembly">
            <valueCode value="NL4" />
        </extension>
    </family>
    <given value="Irma">
        <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier">
            <valueCode value="CL" />
        </extension>
    </given>
    <given value="I.">
        <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier">
            <valueCode value="IN" />
        </extension>
    </given>
</exampleHumanName>

Should we finalize our proposal at the DevDays? We are nearing implementation phase and I'd hate to have loose ends here.

view this post on Zulip Alexander Henket (Nov 10 2016 at 10:48):

The alternative is:

<exampleHumanName>
    <extension url="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname-family-name-assembly">
        <valueCode value="NL4" />
    </extension>
    <family value="Jongeneel">
        <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier">
            <valueCode value="BR" />
        </extension>
    </family>
    <family value="de">
        <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier">
            <valueCode value="VV" />
        </extension>
        <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier">
            <valueCode value="SP" />
        </extension>
    </family>
    <family value="Haas">
        <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier">
            <valueCode value="SP" />
        </extension>
    </family>
    <given value="Irma">
        <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier">
            <valueCode value="CL" />
        </extension>
    </given>
    <given value="I.">
        <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier">
            <valueCode value="IN" />
        </extension>
    </given>
</exampleHumanName>

Note: NL4 means: maiden name followed by name partner

view this post on Zulip Marc de Graauw (Nov 10 2016 at 14:59):

@Alexander Henket Your first proposal means that your last name would be serialized as:

<family value="Henket">
    <extension url="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname-family-maiden">
        <valueString value="Henket" />
    </extension>
</family>

which looks redundant, and that for all Dutch (and other) names without complicated issues like marriage or Napoleon-era prefixes.

The second one would serialize your last name as:

<family value="Henket">
    <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier">
        <valueCode value="BR"/>
    </extension>
</family>

which seems more frugal, and one could even argue that "BR" is not needed when birthname=familyname, so we could serialize you (well, your last name) as:

<family value="Henket"/>

A design principle is "make easy things easy, and hard things possible", and the first solution clearly violates the first clause, while both accomodate the second.

view this post on Zulip Alexander Henket (Nov 10 2016 at 15:03):

I think it is dangerous to say "when you don't specify the type of family name, it shall be a birth name"

view this post on Zulip Alexander Henket (Nov 10 2016 at 15:05):

My thinking is: when you don't specify the type, it is unknown.

view this post on Zulip Marc de Graauw (Nov 10 2016 at 15:05):

I'd be happy to sit down next week at DevDays with all those present and interested to see if we can draw a common proposal - I certainly agree that things are complicated, and no solution will cover all use cases.

view this post on Zulip Alexander Henket (Nov 10 2016 at 15:05):

I'm in

view this post on Zulip Stefan Lang (Nov 10 2016 at 15:05):

Me too ;-)

view this post on Zulip Marc de Graauw (Nov 10 2016 at 15:09):

I think it is dangerous to say "when you don't specify the type of family name, it shall be a birth name"

I didn't say that. I said if birthname=familyname, one could omit the BR name.

view this post on Zulip Alexander Henket (Nov 10 2016 at 15:12):

Well maybe you didn't mean that, but that is sure what it says... :-)

view this post on Zulip Stefan Lang (Nov 10 2016 at 15:12):

... if you look at it in reverse, true

view this post on Zulip Grahame Grieve (Nov 10 2016 at 21:59):

@Rien Wertheim we definitely want a session on this subject at DevDays. perhaps we can schedule this over the working dinner on Wed evening?

view this post on Zulip Alexander Henket (Nov 11 2016 at 14:54):

@simone heckmann: it will sure help if we can have some sheets that compresses our discussion into a digestible form. Can/will you or shall I take a stab?

view this post on Zulip Patrick Werner (Nov 12 2016 at 16:09):

hi. i now got some time again for this topic. I'll create some slides about this topic summarizing this discussion and the corelating discussion in the german stream

view this post on Zulip Patrick Werner (Nov 12 2016 at 16:14):

should be done by monday and i'll post the draft when it's ready?

view this post on Zulip Alexander Henket (Nov 12 2016 at 16:37):

Great! Thanks already @Patrick Werner

view this post on Zulip Grahame Grieve (Nov 13 2016 at 10:56):

thx

view this post on Zulip Simone Heckmann (Nov 14 2016 at 12:47):

Thanks @Patrick Werner !

view this post on Zulip Patrick Werner (Nov 16 2016 at 05:55):

i just uploaded some slides which try to condense the discussion:
https://drive.google.com/file/d/0B3xFZMHgJ7j0Qlk4akJHMW01c28/view?usp=sharing

view this post on Zulip Patrick Werner (Nov 16 2016 at 05:55):

@Grahame Grieve is there already a timeslot for the discussion?

view this post on Zulip Grahame Grieve (Nov 16 2016 at 08:50):

well, I think we said we'd talk about this over dinner

view this post on Zulip Grahame Grieve (Nov 16 2016 at 08:51):

@Ewout Kramer is that the best arrangement?

view this post on Zulip Patrick Werner (Nov 16 2016 at 09:09):

ok i'll search for you at 6pm in the dining area

view this post on Zulip Grahame Grieve (Nov 16 2016 at 17:07):

it's a little after 6pm. We should do this in Richard once we all have food.....

view this post on Zulip Elliot Silver (Nov 16 2016 at 17:17):

@Patrick Werner Good summary of the discussion.

view this post on Zulip Simone Heckmann (Nov 16 2016 at 19:54):

Thanks, everyone at the DevDays for the great discussion! I withdrew GF#12310 in favor of the proposal to create dedicated "flat" extensions for the most common family name parts and maintain the HumanName.family attribute as a single go-to field for the complete family name to search and display.

view this post on Zulip Grahame Grieve (Nov 16 2016 at 20:12):

GF#12351

view this post on Zulip Stefan Lang (Nov 16 2016 at 21:36):

What a day to remember ;-) :thumbs_up:

view this post on Zulip Grahame Grieve (Nov 22 2016 at 06:24):

@Simone Heckmann @diego kaminker @Patrick Werner @Alexander Henket @Jose Costa Teixeira I am about to commit these changes. Please review them:
- changes to definition of humanName
- changes to examples
- definition of 7 new extensions

view this post on Zulip Simone Heckmann (Nov 22 2016 at 14:54):

Thanks Grahame, we will discuss this internally but from my point of view, it looks good!
Where does the updated description of the behaviour of search on HumanName.family go? This hasn't been deployed yet, or am I just not seeing it?

view this post on Zulip Simone Heckmann (Nov 22 2016 at 15:00):

Oh wait, it's pretty much in the "It is at the discretion of the server ..." paragraph in http://build.fhir.org/search.html#string.
I was looking at the description of the family search parameter on the Patient resource page. But maybe an additional sentence there to emphasize the importance of a modified search behavior for family names (matching after whitespace/delimiters also) could help to alert implementers?

view this post on Zulip Elliot Silver (Nov 22 2016 at 16:59):

Is the Scandinavian example still correct? Mother's family name, Ostlund, is coded as a given name? (My Scandinavian is non existant, so I'm also not sure if Mellannamn, mellomnamn, and mellom navn are the same.)

view this post on Zulip Elliot Silver (Nov 22 2016 at 17:00):

Does own-name/partner-name include the prefix?

view this post on Zulip Alexander Henket (Nov 22 2016 at 17:27):

@Grahame Grieve
- I think the Karen van Hentenryck example is not correct yet. I think "VV" should be "van " (http://build.fhir.org/datatypes-examples.html#HumanName). Likely in that same example, if you split out the voorvoegsel, you will most certainly also split out the family name part too.

  • http://build.fhir.org/valueset-name-assembly-order.html looks ok to me, but when the extension now says "own name" for the same concept that the NLx codes refer to as "maiden name" then it is probably best to align them. In Dutch we call it "Geslachtsnaam".

  • You now have two ways of saying the same using the iso21090-EN-qualifier extension. ISO21090 "VV BR" equates to the humanname-own-prefix extension. Not sure yet how to avoid two types of solutions. Strip VV BR SP from the ValueSet?

view this post on Zulip Jose Costa Teixeira (Nov 23 2016 at 09:03):

@Grahame Grieve seems OK, just one question for confirmation, and 2 suggestions on examples:
Question: I assume we can repeat extensions in any sequence, right? E.g. Mother's family name is "Mother1 Mother2", Father's family name is "Father1 Father2" --> child may get not "Mother2 Father2", but "Father1 Mother2 Father2".

Changes to examples (I can commit but I am struggling with SVN and have not worked with examples, so I may break something. let me know if i should do it):

1. Replace
<family value="Eduardo Santos Tavares Melo Silva" /> <given value="José" />
with
<family value="Santos Tavares Melo Silva" /> <given value="José Eduardo" />

2. in the example below, replace "Carlos" by "Sanches" - Carlos is not seen as a family name (it's possible, but confusing).
<name>
<family value="Costa Teixeira Carlos" >
<extension url="http://hl7.org/fhir/StructureDefinition/humanname-fathers">
<valueString value="Costa" />
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/humanname-mothers">
<valueString value="Teixeira" />
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/humanname-partners-name">
<valueString value="Carlos" />
</extension>
</family>
<given value="Manuel" />
</name>

view this post on Zulip Stefan Lang (Nov 23 2016 at 09:38):

Another slightly incorrect example:
The "Complex example from Germany" at http://build.fhir.org/datatypes-examples.html#HumanName ) uses http://hl7.org/fhir/StructureDefinition/humanname-own-prefix for "Gräfin". But "Gräfin" would be covered by a national extension.
So better change the example to "Dr.phil. Regina Johanna Maria von Hochheim-Weilenfels, NCFSA" with the "von" in the humanname-own-prefix extension.

view this post on Zulip Patrick Werner (Nov 23 2016 at 16:25):

I just had a look at the examples: It seems that the discussed extensions: http://hl7.org/fhir/StructureDefinition/family-plain & http://hl7.org/fhir/StructureDefinition/maiden-plain are currently not used in the german example or elsewhere.

view this post on Zulip Patrick Werner (Nov 23 2016 at 16:36):

they were included in this example:

(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 just pointed me towards own-family-name, and partners-family name. Which are basically the same.

view this post on Zulip Patrick Werner (Nov 23 2016 at 16:42):

so it would look like this: ?

<name>
  <use value="official" />
  <family value="von Hochheim-Weilenfels">
    <extension url="http://hl7.org/fhir/StructureDefinition/humanname-own-prefix" >
      <valueString value="von" />
    </extension>
    <extension url="http://hl7.org/fhir/StructureDefinition/family-own-plain" >
      <valueString value="Hochheim-Weilenfels" />
    </extension>
  </family>
  <given value="Regina" />
  <given value="Johanna" />
  <given value="Maria" />
  <prefix value="Dr. phil.">
    <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier" >
      <valueCode value="AC" />
    </extension>
  </prefix>
  <suffix value="NCFSA" />
</name>
<name>
  <use value="maiden" />
  <family value="Hochheim" />
</name>

view this post on Zulip Stefan Lang (Nov 23 2016 at 17:01):

more like:

...
  <family value="von Hochheim-Weilenfels">
    <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>
...

view this post on Zulip Patrick Werner (Nov 24 2016 at 09:02):

yeah that's better @Stefan Lang but the point was, that the examples didn't include the plain family names

view this post on Zulip Stefan Lang (Nov 24 2016 at 09:15):

That's true. The humanname-own-name should be included in the "complex German example", just as Alexander mentioned it earlier for the Dutch example.

view this post on Zulip Grahame Grieve (Nov 24 2016 at 16:15):

now it's committed

view this post on Zulip Grahame Grieve (Nov 24 2016 at 16:16):

hmm. looks like the comment that was meant to followed got lost while on board my flight

view this post on Zulip Grahame Grieve (Nov 24 2016 at 16:16):

I fixed all the identified issues.

view this post on Zulip Grahame Grieve (Nov 24 2016 at 16:16):

please wait for version 10255+ and check it again

view this post on Zulip Patrick Werner (Nov 25 2016 at 11:13):

just checked revision 10260 - the german example is correct now - the dutch example is missing the humanname-own-name extension.
Fixed dutch example:

<name>
  <use value="official" />
  <family value="van Hentenryck" >
    <extension url="http://hl7.org/fhir/StructureDefinition/humanname-own-prefix" >
       <valueString value="van" />
    </extension>
 <extension url="http://hl7.org/fhir/StructureDefinition/humanname-own-name">
      <valueString value="Hentenryck" />
    </extension> 
  </family>
  <given value="Karen" />
</name>

view this post on Zulip Grahame Grieve (Nov 25 2016 at 13:26):

well, i do not think that it's necessary to add that, but in the interests of completeness, I have

view this post on Zulip Patrick Werner (Nov 25 2016 at 13:53):

i think it is good for completeness, to get an idea how these extensions are working together


Last updated: Apr 12 2022 at 19:14 UTC