Question: Multi-part surnames

Nov 20, 2013

Question:

How do we handle multiple family/last names? Andhow to re-construct the complete family name with multiple parts stored in db? How about, for an example: Josep Puig i Cadafalch – Puig is the last name of his father, Cadafalch of his mother; i means “and” (see Iberian naming customs).

Answer:

Human Names are quite difficult in healthcare standards, because there’s fairly wide variety of cultural practices, and because they get involved ubiquitously across the process - and because most implementations work within a narrow cultural profile.

Let start with the simple case - how should this be represented in v2, CDA, and FHIR:

|V2.7|XPN|Puig i Cadafalch^JosepPuig i Cadafalch^Josep |CDA|PN|<name> <family>Puig</family> <family>i</family> <family>Cadafalch</family> <given>Josep</given> </name> Puig i Cadafalch Josep |FHIR|HumanName|<name> <family value="Puig"/> <family value="i"/> <family value="Cadafalch"/> <given value="Josep"/> </name>

So these are different. You can’t reproduce the CDA/FHIR structure in v2, but you can represent the v2 structure in CDA and FHIR:

So that creates an inherent problem: there’s no one right way to represent this name in CDA (for FHIR, this is something you SHOULD NOT do - see below). The first form is preferred, but the second is still legal. Well, the thing is, we can’t make it illegal, because maybe the space really is part of a single surname (that would play out in a legal/jurisdictional system where pragmatic solutions aren’t always possible). So why do we even allow it to be broken up? That’s because not all parts of the surname have equal meaning, and the different meaning impacts on how you use names (searching and matching considerations). So you can break names up in CDA and FHIR to allow parts to be marked up. CDA provides qualifier for this, and in FHIR it would be extensions.

But there’s two different forms that are (in the case above), identical. How does this work in practice? Well, that brings the database question into focus. In practice, there’s a range of approaches. There are applications out there that handle names exactly as CDA/FHIR/ISO 21090 handle them- but in my experience, these were written from scratch to be conformant, not to solve particular real world problems. But mostly, there’s some combination of single or multiple given and surnames, with prefixes, sometimes suffixes, and occasionally surname prefixes (“van”). In english speaking countries, applications mostly only have a single surname.

So the ambiguity in the specification is faithfully reproducing variation in practice. We’d like to impose a single model of naming, but there isn’t one. In fact, the situation is much complicated by a person with a name from one culture trying to represent their name in another culture’s systems (tourists, or immigrants. Immigrants actually often take different name just to get by), which leads to some weird intersections of practice.

Implementation in FHIR

In FHIR, we’ve make this implementation note:

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

and this one:

Systems that do not support as many name parts as are provided in an instance they are processing may wish to append parts together using spaces, so that this becomes “van Hentenryck”.

This makes things workable - it doesn’t matter how you store it, there’s guidance for interoperating with other applications, and in most circumstances, this will work fine.

But its’ SHOULD not SHALL because we know of edge cases like the jurisdictional one above where you mightn’t be able to follow the simple rules.