V3DT conference call worksheet for Wed, Feb 24, 1999.

Person Name

Summary of contributions

Bidgood DW Jr, Tracy WR. In search of the name. Proc Annu Symp Comput Appl Med Care, 1993; p. 54-58.
Bidgood DW Jr, Tracy WR. ANSI HISPP MSDS: COMMON DATA TYPES for harmonization of communication standards in medical informatics. Final Draft. 10/30/1993. Available as Postscript or Word.
Hopkins R. Strategic short study: names and numbers as identifiers. CEN TC251. Available as PDF or Word.
There are two comments that were sent from the Netherlands. One A Study on names in the US and in the Netherlands. The other is a comment from Irma Jongeneel.

Starter

The HL7 v2 person name data types (PN, XPN) have basically the same problems as the data type for addresses. I.e., it ties to make slots for data so that whatever name parts exist must be fitted in one of the available slots. This has the same disadvantages: that name part types do not classify in a simple and interchangeable way throughout all cultures, but still everyone must use the same classification. Second problem is that the meaning of a name part and the positioning of a name part are orthogonal (independent) aspects of a name. As an additional problem, person names may occur in different ordering and some name parts are or are not used depending on the use case (e.g., formal vs. familiar style).

A different design

The motivation for my somewhat radically different design was:

Since the proper ordering of names and prefixes is dependent on culture for which to give rules is very hard, I want to have one name component that includes almost the entire name of the person in some natural order. (This is the single character string I was talking about in my question)
Of course there are use cases for breaking down the name into parts. However, the applicable parts may again be dependent on culture. That's why I did not want a fixed structure, but more a keyword-value-pair type of construct.
That list of names was meant to be ordered. That is, if two name parts occur with the same name part type (e.g. two "given" names) then the first one is more important. Thus, if U.S. people have their first and middle name, two given names would appear in the list of name parts where the first one is the first and the second one is the middle name.
There are different orthogonal properties of name parts. For instance in the U.S. the first name is not necessarily the one to be printed in full. "Wayne R. Tracy" is the typical first - middle initial - last name. But "W. Dean Bidgood" is just the opposite, here the middle name is spelled out in full and the first name is the one to wonder about.
Name changes rarely affect the entire name with all of its parts. For instance, if a typical U.S. woman back in the 1950 married, she changed her last name to the last name of her husband, but kept her first names unchanged. Rather than creating an entirely new person name instance with all of its parts, my construct created just a new part and readjusted the name part types, so that her former family name would now become the maiden name while her husband's family name would becom her family name. Other examples of minor name changes are legion, for instance the Philippinian Woman who widowed and now carries a "Vedova" prefix in her name. Also, a nickname is not an entirely new name. It most often affects the main given name "Wesley-Wes", but may of course be a synthetic name "Charles-Skip"
The construct of "legal name" is also dependent on culture. Not all possible name part types can be part of a legal name but we can not necessarily preclude name types from being part of the legal name. For instance, the nickname is almost never part of the legal name (unless by coincidence) whereas the maiden name is a must in every official legal name in Germany.
I removed the concept of a "display name" entirely, because it all depends on the type of display. Of course from an intra-institutional point of view, a display name is a convenience since all labels may contain just the display name. However, that doesn't work in an inter-institutional perspective since display name styles do vary.

Thus, my conclusion was to have one ordered list of typed name parts that, where the name parts appear in the culturally natural order. When names are printed, some style rule would select the name parts according to their types. Could retain the order, or rearrange the order depending on whether a buaurocratic uniformity of name part order matters more than the culture of the patient. It can all be done.

Details

Let's first start the discussion about "what's in a name" before we elaborate on whether or not we should do something more than a data type. In my oppinion a name type is a pretty essential attribute of a name. My rough scetch of what I think a new PN data type should look like goes as follows:

[please excuse the non-standard description here]

This structure seems very different from what we had. But we have to keep in mind, that PN never was international. There have been numerous comments on that by the collegues from the Netherlands.

Names are quite difficult in an international context. Even those things like "last name" vs. "first name" does not exist in many cultures. I have had friends from Africa (Etiopia and Kenia) whose German visa showed different names than their school record from their home country, all because their names didn't fit into our European schema.

Now this name structure does the following:

The parts of the full name appear in one ordered list. This list is ordered according to the natural order dependent on the culture. E.g. in the U.S. academic titles are printed after the name:

"George W. Beeler, Ph.D."

while in Germany we would say:

"Dr. phil. Georg Wilhelm Bieler"

Thus the names would appear in the name list as follows:

Wes Rishel's true first name is "Wesley", but he is called Wes by almost everyone. So:

This could be printed as "Wesley Rishel" on a formal address, but "Hi Wes!" would appear inside the letter. On a badge of the HL7 meeting one would print "Wes (Wesley Rishel)". On a more formal symposion one might print "Wesley (Wes) Rishel".

Japanese names are very often used in the reverse order (family name first):

What's important here is that if you just want to print an address label on a letter, and you do not care about any particular name style, you can just print the name parts in the order occuring in the list:

"George W. Beeler Ph.D." (N name parts are not printed)
"Dr. phil. Georg Wilhelm Bieler"
"Wesley Rishel"
"Iketani Sahoko"

Other countries can define more name part types as needed. For instance in Germany we want to separate the "Dr." from the "phil." because normally we say "Herr Dr. Biehler" instead of "Herr Dr. phil. Bieler".

The bottom line is that name type is now a smaller code table. Maiden name is gone into name part type, for instance, my mother's name would be:

So that in an official notary document one could print:

It doesn't make sense to repeat the first names as part of the maiden name, because those stay the same when the familiy name changes. If in any given culture this assumption does not hold, we can always define other codes of NameType or NamePartType. For aliases (pseudonyms) we need the full name though.

"D" for "display name" is gone entirely, since it depends on the kind of display, what name is displayed. As shown in the badge examples above. If precisely defined NamePartType codes are used, the display name can always be recreated using some simple style rules.

Further Work

Probably my construct is limited in the sense that each name part could have only one name part type. It should have more than one so that more than one orthogonal properties can be assigned to each name part.

The axes that come to mind are: 1st axis (semantics):

2nd axis (use):

3rd axis (legal stuff):

4th axis (change):

I didn't summarize the many interesting issues that people brought up (e.g. whether spaces are a part of a name or a delimiter of name parts).

One more curiosity that I saw in the SSS

Appendix C of SSS describes the EULER rules of dealing with author's names. One example is "A. de L'Aigle" which is rearranged into "L'Aigle, A. de" From my knowledge of French language I would think that "de L'Aigle" is a contraction form for "de-la-aigle". Where "de la" belongs together in the category "aristocracy stuff" (like "van der Waals" or "Wolfgang von der Vogelweide"). Thus the rearranged form should probably be "Aigle, A, de la". If so, the name decomposition and recomposition machinery must take care about the language dependent peculiarities of contractions. Gee, it becomes further difficult!

Greg Forbes found some nice words for our problem here:

The defining the Lexical structure of a universal 'name' for the sake of accurate parsing is starting to sound like a career. This is one area were we may not be able to be all things, to all peoples. [...] If we cannot achieve a truely universal concept of Name, would it possibly be more doable to define from a Business perspective what data is required:

That sounds like a good thing to keep in mind while we search for the best solution.

A 'Legal' name - usually defined by some clerk in the Government (Social Security, Birth Registrations, Immagration Service)(here again, foreign name contructs are often butchered), and a 'Common' Name: usually used in conversation and mailing addresses etc.

I don't know if this is sufficient, though, since the common name is what people use at the registration desk in the hospital. And the common name is subject to all those variabilities. The legal name is often a butchered common name as you say and it may be wise for the rules for "legal names" to be redesigned more prudently. That's what we currently do in HL7. We may end up with a pretty good (if not the best) name structure that the world has never seen before, and that would probably also improve the SSN business.

Using this type of approach, it may be possible to make the actual format/lexical elements of each 'name' element a vocabulary issue, to be dealt with at a lower level (nationally).

That is what my proposal includes. Using name part type codes. However, I also want to point out that we do not solve any problem by ending up with the statement: "this is a vocabulary issue". There is not an "oracle of delphi" to which you can go and ask for sensible term lists. The same domain experts have to make those terms who could as well define all the slots for name parts. The bottomline is, there is no science of "applied onomatology" from which we could recruit experts. As always, we have to aquire the neccessary expertise to solve those issues (or at least to evaluate expert oppinions).

Irma Jongeneel (Irma Corine Jongeneel-de Haas) issues:

We need to distinguish the following name type codes:

Call it "birth name" not "maiden name", since men too can take the name of their partner when they marry.
Name of spouse can be part of your own name, not as a next of kin.
Men and women are allowed to use the name of their (registered) partner and their birth name in arbitrary sequence. So you're not sure what part of the name is where.
GS: That's a problem. If we identify all those name parts like last-name-at-birth and last-name-of-spouse but registration clerks can not map the names "Jongeneel" and "de Haas" since they don't know which name is what, we get into trouble. Fine semantic differences that can not be adhered to is not only useless it is dangerous. What can we do about this?
Example: my full name is "Irma Corine Jongeneel-de Haas". I have chosen to use my husband's name "Jongeneel" firts, followed by my birthname "de Haas". I can also say my name is "Irma Corine de Haas-Jongeneel" or "Irma de Haas" or "Irma Jongeneel". My husband, "Gerard" has the same choices. He can also say his name is "Gerard Jongeneel", or "Gerard Jongeneel-de Haas" or "Gerard de Haas-Jongeneel" or even "Gerard de Haas". And, to make it even more complicated, in the Netherlands it is possible for two people of the same sex to get married.
"legal name" vs. "preferred name to address the person" I think we don't have a real legal name in the Netherlands. When you get married, you may say how you want to be registered, but there is no law that says you have to use this name. And most legal correspondance refer to a person by the name of birth, sometimes followed by "e.g." for "echtgenote van" which means "spouse of" followed by the name of the spouse.
GS: Interesting. We will of course have a preferred name, but legal name seems to exist in some way (or more?) in the Netherlands too. You speak of being "registered", isn't this registry a legally enacted institution? In Germany it is, which does not mean that it's the same in the Netherlands. So, what are those registries in the Netherlands? Interestingly highly official legal correspondence have their own naming style that seems to be different from the names you use in, say, your bank account. Seems like we have almost a continuum of styles between:
```
N - nickname (familiar)    Billy
F - formal name		   Bill Clinton
L - legal name		   William J. Clinton
H - highly official name   William Jefferson Clinton
```
But it seems like every culture has its own ways to construct names given the parts are known. Thus, for the person name a good analysis of the semantics of name parts is important.
About first (given) names: My first names are "Irma" and "Corine". That is easy, since there are only two names and the first of those is how they call me. But there are many persons who have 3, 4 or even more first names, so middle initial will not be good enough. And there's also the possibility that one of your first names is "Johannes" and you're called "Jan".
This is the same with U.S. "William" vs. "Bill", "Robert" vs. "Bob", etc.