At the Orlando PAFM Meeting 1999, a Work Group was formed to review and expand the V2.3.1 person name definition (data type XPN) in response to a proposal put forward by the Dutch delegation and some input provided by PAFM members from Australia.

This Work Group has been holding teleconference meetings on a weekly basis. All minutes and working papers have been published at http://OurWorld.CompuServe.com/Homepages/KVeil/Names.htm. The efforts of the Work Group work have been monitored and endorsed by HL7 Germany and HL7 Finland; HL7 Australia has also formally endorsed the draft of this proposal.

The following issues were addressed in the Work Group:

1. Enable XPN to hold more than two given names (eg. in "given name" and "middle initial or name"). Proposed by Holland, where patients are registered with all their given names and initials - often more than two. This requirement applies also to other Germanic countries.
   Initially, the creation of a new XPN component was proposed. However, with regard to structural and data backward-compatibility, it was agreed to expand the scope of the "middle initial or name" component to "second and further given names or initials thereof". The HL7 ST data-type will remain and the second and further given names will be separated by spaces.
2. The requirement to enable XPN to designate the context in which a name is used had been identified. The main use case is in Australian healthcare of mainly indigenous patients who prefer to use different names when attending different healthcare institutions. Another use case is in the US where health practitioners can be licensed under slightly different names and the reporting of the correct name is vital for administrative purposes.
   The creation of a new XPN component "name context" has been agreed to. The datatype is CE.
3. It was agreed that this name type and description "Name of Partner/Spouse" is misleading and invites confusion with Next-of-Kin. The actual use for this name-type is "Name part adopted from Partner/Spouse". As this is a means of identifying parts of the Family Name (similar to the Last Name Prefix), it was suggested to add a XPN component "family name from partner/spouse" for this and to obsolete the "P" name type. Also, to accommodate the Dutch "voorvoegsel" a "family name prefix from partner/spouse" subcomponent is proposed.
4. The Call-me Name /Nickname/Street Name has been identified as a new name type "N". It is of particular relevance in the Dutch health system where patients are addressed with a shortened version of their legal name. This is different from the display name, which is used for correspondence.
5. The name type "tribal/community" will be expanded to "indigenous/tribal/community".
6. For consistency, "Last_name_prefix" will be renamed "Family Name Prefix".

The above proposals would change the XPN datatype to:

The above proposals would change the HL7 Table 200 "Name Type" to:

Name type "B" holds the name information on the birth certificate.

Name type "L" contains the "official" name information in its most complete form - this may have been changed from the name on the birth certificate by adoption or legalized name change.

'D' is halfway between 'L' and 'N' in representing the name that would be used in correspondence and computer listings.

Name type 'N' is used to communicate the nickname or "call-me" name, in the sense that it describes everyday-use names instead of official information.

The distinction between the 'N' and 'D' name types is not very strict; both sending and receiving systems might use one or the other for both purposes (???).

Also, it is open for discussion whether or not information should be duplicated in the components that do not differ between the 'L' name types and the other name types. In the examples below this information is repeated, since it would allow a receiving system to focus on just, say, the 'D' messages and still obtain sufficient information to fill their database sufficiently. This should not be assumed by definition though.

In conclusion, it should be clear that both sending and receiving systems should at least support the 'L' data type, but should not be dependent on the use of any of the other name types or the information they contain.

Irma Corine de Haas is registered as a patient. To communicate her legal name, the ADT system sends out the following "XPN" (Note that V2.3.1 has established that if the family name prefix is used, only the family name "root" is placed in the family name field, not the "complete" family name):

Now Irma marries Gerard Jongeneel and adopts his family name as part of her own. This is a common practice in several European countries. Her "new" legal name would now be sent as:

This does not specify the exact last name she has chosen, since at marriage a Dutch citizen (both male and female) can chose from four options, resulting in either of the following last names for Irma:

1. Irma de Haas (no change)
2. Irma Jongeneel (adopts name of partner)
3. Irma de Haas-Jongeneel (own name first)
4. Irma Jongeneel-de Haas (partner name first)

To specify her 'call-me' name, there are several possibilities the ADT system could send out an XPN:

Only the parts of the name that relate to the way the person wants to be addressed are mentioned.

In this example all other information is repeated. This creates some extra overhead, but it does allow a system that decides to focus on the N name type to obtain most of the relevant components from a single XPN.

Margreet van der Werf is a girl who doesn't like her given name and uses the name Claudia in everyday life instead. The name Margreet remains in all official records (e.g. passport) though. Upon registering in a hospital the XPN sent by the ADT system would be:

For children, most hospitals will register the "call-me" name in order to call them from a waiting room or address them during an in-patient stay. In Claudia's case this could be communicated as follows:

Now suppose that Claudia marries her boyfriend Tom de Jong, and chooses to adopt his family name behind her own (option 3 above). The following XPNs would then specify her legal name and her "call-me" name respectively:

Jacobus Cornelis (nickname Kees) de Wit and his boyfriend Jean-Pierre van Damme decide to get married. They choose to adopt each other’s names as follows:

Kees de Wit-van Damme: Wit&de&Damme&van^Jacobus^Cornelis^^^^L~Wit&de&Damme&van^Kees^^^^^N

Jean-Pierre de Wit-van Damme: Damme&van&Wit&de^Jean-Pierre^^^^^L~Wit&de&Damme&van^Jean-Pierre^^^^^N

• A distinction between the "A" name type and the PID-9 needs to be reviewed. Should PID-9 – similar to PID-2, PID-4 and PID-19 – be obsoleted and all patient names placed in PID-5?
• The XCN and PPN data types should also be modified as above.
• The "name context" data type CE does not convey the context type – maybe a separate field should be added for this? Or a new data type.
• Should differences in the reported patient date-of-birth and sex also be catered for?

* * *