FHIR Ballot Issue: Alignment of demographics with v/xCard

Nov 7, 2012

One of the ballot comments received on FHIR was this:

FHIR should adopt common mechanisms to express names, such as vCard, FOAF. These also have RDF bindings

xCard is an xml rendition of the vCard specification (http://en.wikipedia.org/wiki/VCard / http://tools.ietf.org/html/rfc6350). A vCard contains:

  • Name
  • Photograph
  • Birthday
  • Address + Time Zone
  • Contact Details
  • Title / Role / Occupation
  • Agent (i.e. secretary)
  • Organisation
  • Keys and Identifiers

Because of the difference between what vCard is doing (managing business contacts) and FHIR is doing (interoperability/integration for healthcare business), there isn’t going to be a single FHIR resource that matches this in scope – there’s patient, person, agent, and more in there. The HL7 Patient Administration committee is actively considering how the demographic resources should be structured, and this is out of scope for this ballot comment (though a good mapping between these resources and the vCard specification will be important).

However all these resources will use the Name, Address, and Contact data types, which is what the comment was about, and any mapping will require mappings between the structures used to represent these ideas in vCard and those in FHIR.

Note that it may be necessary for them to be different, as FHIR may need to meet different requirements. For instance, the vCard specification is somewhat English language/1st world centric, which FHIR is trying to avoid (and the FHIR data types are based on the extensive worldwide requirements gathering that occurred during the development of the v3 data types). Also, healthcare has different basic requirements for handling names driven by the use for healthcare rather than business. For instance, a focus on retaining past names, past errors in names, the difference between the correct name for addressing the person, and the correct name for billing for the person. Note, though, that the v3 data types didn’t have a formal requirements tracking process, so many of the features are not easily related to clearly defined requirements.

First, names.

The vCard specification has for name:

  • Formatted name (a plain string containing the “formatted name string”)
  • Nickname – a single string – a descriptive or familiar name
  • Structured Name: family names, given names, additional names, prefixes and suffixes

The vCard specification doesn’t explain exactly what an additional name is. Outlook maps it to “middle name”, which makes me unsure what multiple given names are. Middle name is a rather confusing term outside English languages, and HL7 members from other countries have had some strong comments to make about outlook support for contacts L. The vCard specification also doesn’t say anything about order – whether the order of the name parts is significant within their peers – one assumes that it is. But more importantly, nor does it say anything about the relative order of the different parts, and this varies greatly around the world. It does, however, provide the formatted name where the name parts can be provided in the correct order, though that’s not a perfect solution – must the exact names in the parts match the text in the formatted name, so the order can be known? Or is the order only exchanged in an unprocessible form?

FHIR, on the other hand, has

  • A text representation of the name
  • A sequence of parts, each a string with a type. The known types are family, given names, and prefixes and suffixes.
  • There can be multiple fully or partially structured names with various uses, include usual, official, temporary, anonymous, old (superceded), and maiden
  • A period during which the name was used

So the FHIR name structure has more capacity than the vCard one for name types and period, but the base name type is similar. Specific differences:

  • FHIR parts have a specific order. vCard ones don’t
  • FHIR doesn’t have an “additional name”. Should it?

There’s a price for the specific order. Here’s the xCard representation of a name:

 <n>
  <surname>Gump</surname>
  <given>Forrest</given>      
  <additional/>      
  <prefix>Mr</prefix>      
  <suffix>Jr</suffix>
 </n>

Here’s a FHIR representation of the same name:

 <n>      
  <part>        
   <type>family</type>        
   <value>Gump</value>      
  </part>      
  <part>        
   <type>given</type>        
   <value>Forrest</value>    
  </part>      
  <part>        
   <type>prefix</type>     
   <value>Mr</value>    
  </part>    
  <part>     
   <type>suffix</type>     
   <value>Jr</value>    
  </part>   
 </n>

This is much complicated by the need to maintain order (and some unrelated but important issues to do with the way the XML and json and other things are specified, which means that elements must come in order in FHIR. I’m not discussing that here). If we didn’t think that order was important, then we could have a simpler structure in FHIR:

 <n>    
  <text>Mr Forrest Gump, Jr</text>    
  <family>Gump</family>    
  <given>Forrest</given>    
  <prefix>Mr</prefix>    
  <suffix>Jr</suffix>    
 </n>

We’ve (HL7) always maintained that the order of name parts is important – but is it? How many non-v3 based systems maintain name order? Usually, in my experience, they simply assign the prevailing name order of the local culture in which they run, and visitors from overseas simply live with that (many adopt localised names for general use).

So there might be a good argument to simplify name, which improves alignment with vCard, and push order into extensions. Note that this also improves alignment with v2, which doesn’t really support order either.

Address

A rather similar argument applies to address. The vCard address specification has:

  • post office box;
  • extended address (e.g., apartment or suite number);
  • street address;
  • locality (e.g., city);
  • region (e.g., state or province);
  • postal code;
  • country name

FHIR has:

  • line         A line of an address.
  • city         The name of the city, town, village, or other community or delivery centre.
  • state      Sub-unit of a country with limited sovereignty in a federally organized country.
  • country
  • zip          A postal code designating a region defined by the postal service.
  • dpid       A value that uniquely identifies the postal address. (Often used in barcodes).

Differences:

  • vCard has POBox and extended address, FHIR just treats this as part of the line content
  • FHIR has dpid, which vCard doesn’t (presently) have

There’s an interesting twist to the vCard spec which isn’t discussed in the FHIR spec – that of end of lines – can the address parts in FHIR contain end of lines? The intent is that there would be multiple parts, but this is not stated. Similar to the order question, there is variation amongst cultures in the proper physical layout of addresses – where line breaks should be, in addition to order. However, typically, an address for a foreign location must pass through both the local and foreign mail systems. So in my experience, systems use local postal address layout.

Contacts

The picture with contact is rather more complicated because vCard doesn’t take a single approach to contacts. vCard has:

  • Telephone number with one or more types: text voice fax cell video pager textphone work home
  • Email

FHIR has a contact with:

  • A value, along with a marker for whether it is phone, fax, email, or url
  • A use code (home, work, temp, old, and mobile)

Differences:

  • vCard has text, video, pager, and textphone.
  • FHIR has old, and temp

Other Specifications

Note that the ballot comment referenced FOAF. One of the great things about standards is that there’s so many you’ve never heard of. FOAF is an ontology for expressing relationships that might be useful and relevant for next of kin etc, but isn’t relevant  to the data types discussion above.

There’s also the Oasis CIQ specification at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ciq#technical. This is a rather richer and more extensible way to represent names.