The following requirement had been identified:

• 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 that two.
  This requirement applies also to other Germanic domains.

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.

The following requirement had been identified:

• Enable XPN to identify the nickname (or "call-me" name as used in Holland) of a person. This is important, as patients in Holland will insist to be verbally addressed by their "call-me" name, never by their display name or legal name. Note that this is not an alias name.

Initially, again the creation of a new XPN component was proposed. However, it was found that a new name type would satisfy the requirements better, especially as the case of multi-component nick-names could not be excluded. It was therefore agreed to expand the HL7 Table 200 "Name Type" by "N" for "Nickname/Call-me name".

Use case 1: Johannes Frans Smit; his "call-me" name is "Hans".

The following requirement had been identified:

• Enable XPN to identify the context in which a name is used. 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 "name context" component has been agreed to, however, the datatype is currently being reviewed. "CE", "HD", "CX" have been mentioned.
David has identified that we need the following component parts:

• Context ID
• Context description
• Context type code
• Context type description

Also, to fulfil the US use case the addition of a new name type code for "licensing name" has been agreed to. The actual one-letter code still needs to be determined.

• Review data type for "name context" component.
• Find 1-letter code for "Licensing Name".

• Finalise data type for "name context" component.
• Agree on 1-letter code for "Licensing Name".
• Discuss Partner/Spouse name-type
• Any other naming issues

The next tele-conference is on Thursday, April 1, at 4pm EST, 10pm in Holland and 8am (Friday) in Australia