Monthly Archives: November 2012

Question: v3 Lab Ordering Support


I have read about some articles utilizing some HL7 v3 Laboratory interactions such as Order Fulfillment Request (POLB_IN211100) and order confirm response (POLB_IN221000). But in current version of HL7 standard Laboratory domain only result related interactions are listed. Where can I find definitions of these interactions and trigger events? I searched them on internet but find few information.


Well, the key point is this quote from the v3 lab topic (part of the v3 specification):

The scope of Laboratory Release 1 is restricted to the Result Topic

In the earlier versions of the Laboratory topic, up until Sept 2006, the laboratroy cycle included these interactions, and a general ordering pattern. However they were withdrawn in January 2007 ballot, with this comment:

LabSIG has withdrawn the domain ballot for Lab with the intent to ballot by topic. The reason for this is to recognize the work being done by the Orders/Observations committee to develop a common order (now defined as Composite Order) and the work being developed by LabSIG to take the existing balloted material to create result topic. By splitting out the lab domain ballot by topic provides the flexibility to support the work in development by the multiple domains working with Orders/Observations to develop a common order with each domain adopting an implementation constraint for the common order for their area.

The composite order was balloted in May 2009. The direct link to this (HL7 members only) is: Note that a subsequent ballot was postponed – I don’t know where it stands now (though it is not normative).

FHIR Tutorials at the Phoenix Meeting

Unfortunately there is a problem with the description of the FHIR tutorials in the meeting brochure for the upcoming Phoenix meeting. The brochure describes 3 FHIR tutorials:

M4 Introduction to HL7 FHIR Mon, Jan 14 am Lloyd McKenzie
M7 FHIR for Implementers Mon, Jan 14 pm Ewout Kramer
F2 Hands on with FHIR Sun, Jan 13, Q3 FHIR Project Team

Unfortunately, due to some last minute confusion, the descriptions of the tutorials have got mixed up in the brochure. Here’s the correct descriptions:

M1 : Introduction to HL7 FHIR

Summary FHIR is the newest healthcare interoperability standard offered by HL7, providing domain friendly wire formats compatible across the document, messaging, services and RESTful paradigms.  This tutorial is aimed at those who want to learn more about FHIR, what it can do and how their organization might best take advantage of it.
The tutorial will benefit Analysts, Vendors, Project Managers
Upon completion of this tutorial the students will have obtained the following
  • Explain the main principles underlying the FHIR methodology
  • Describe the characteristics of a FHIR resource and understand the contents of a resource definition
  • Understand the relationship between FHIR and other HL7 standards such as v2, v3 messaging and CDA
  • List some of the key FHIR infrastructure resources and explain how they are used to support the 4 FHIR interoperability paradigms
  • Help their organization to determine if, when, where and how they might implement FHIR
Prerequisites None

M7: FHIR for Implementers

Summary A deep-dive into the infrastructure parts of the FHIR specification. Get insight in how to design, develop and test software that uses the FHIR interoperability standard, all the way from the wire-format up to validation and storage.
The tutorial will benefit Software developers, team leads, infrastructure architects
Upon completion of this tutorial the students will have obtained the following
  • Understand how Resources align with object-oriented and other common software-engineering principles.
  • List the four of interoperability paradigms supported by FHIR
  • Understand the FHIR REST service operations and how to implement them
  • Understand how the Atom, Xml and JSON wire formats are used in FHIR
  • Understand versioning and bundles
  • Compare strategies for using object models, validation and (de)serialization
  • Use relational or document-oriented storage for persistence of resources
  • Understand how to implement search functionality
  • Know and use the provided reference implementations
Prerequisites The “Introduction to HL7 FHIR” tutorial.

F2: Hands on with FHIR

This is a free tutorial – but focused on HL7 work group members.

Summary This hands-on tutorial covers the resource authoring process. It will be a working class where attendees will use the FHIR build environment to construct a resource and generate the published specification. The tutorial will focus on spreadsheet usage, and be divided into an example and a Q&A session.


The tutorial will benefit HL7 Committee members
Upon completion of this tutorial the students will have obtained the following
  • Understand how to work with the FHIR publishing tooling
  • Know how the various parts of a resource definition fit together
  • Know how to add resources to the FHIR specification
Prerequisites – Co-Chairs,Facilitators and HL7 Committee FHIR participants ONLY
– A working FHIR publication environment
– should be planning to author resources, or already experienced at
having done so

Please distribute these correct tutorial descriptions as you are able. Thanks.

Question: FHIR and JSON


Do you have any example of FHIR with JSon? I heard that FHIR JSon keys are CDA headers.  Is there a published list that are supported?


There are lots of JSON examples. You can get them from the specification itself, or from one of the test implementations.

FHIR Json Keys aren’t CDA headers, though there is a FHIR resource that replicates CDA.

And there’s not a really a published “list” because what is published in the resource content models that define the names of the json properties and where they can be used.


Upcoming HL7 Australia Seminar

There’s an HL7 Australia seminar next week:

Come and join us in Brisbane to gain valuable insight into some of the hot questions faced by those implementing CDA here in Australia.  As the national installed base of HL7 CDA grows and systems need to be certified, those implementing this technology have been seeking further information about the following:

  •   Presentation and Rendering of CDA Documents
Grahame Grieve of Health Intersections, HL7 International’s Volunteer of the Year, will summarise feedback on the experience to date around the content, presentation and rendering of CDA documents, and will lead discussion and provide advice on the major issues arising and how to address them.
  •  Open and Closed CDA Templates
Sarah Gaunt (Lantana Consulting Group) was a technical lead for NEHTA’s development of the Australian CDA implementation guides and will reveal the black arts of managing a family of CDA templates and making CDA a useful tool for real world.interoperability.
  •  CDA Implementation Lessons Learned
Paul Carr, Managing Director of Genie Solutions, will discuss some of the lessons learnt when a software developer with a large installed base is confronted by a new world of CDA documents, rendering, and conformity assessment.

Grahame Grieve will also give a FHIR Status Check, bringing us right up to date with FHIR, where it has been and where it is heading, with a focus on how FHIR is being

So, as well as providing an update on where we are with FHIR (shorter-version: busy like the bottom end of a rocket), I’m going to be discussing CDA Presentation and Rendering. Some of the specific issues that I’ll be discussing:

  • How is clinical safety maintained in a mixed system of data and narrative?
  • When can you ignore the data or narrative portions?
  • How should you go about populating both?
  • Why does NEHTA provide and mandate it’s own stylesheet?
  • Why is there a rendering specification? What does it actually do?
  • Why is there yet another document forthcoming called “Best Practices for Presenting CDA documents”? What does that do?

A lot of this is dealing with the questions that Eric Browne raised at the beginning of this year, but doing so based on actual implementation experience.

What I’m making is more than just a presentation – there’s a lot of consternation about various parts of the landscape here amongst actual implementers, and I’ll be laying out the foundations, and the ground work, and explaining the current situation, and then I’m expecting an open – and possibly stormy – discussion about the strengths and weakness of the current approach, and where we might go from here.




Cross-walk between HTML and CDA Narrative

As a followup to yesterday’s post about converting from html to CDA narrative, the following table summarises the differences between HTML and CDA narrative:

HTML CDA Comments
a linkHtml
area No direct equivalent, though there is RegionOfInterest which is similar
b <content styleCode=”Bold”
base CDA document itself is the base
body n/a
br br
caption caption
code NEHTA defines styleCode=”xPre” for this
col col
colgroup colgroup
del <content revised=”delete”
em <content styleCode=”Emphasis”
form No forms in CDA documents
h1 Headings are supposed to be subsumed into nested section titles.
i <content styleCode=”Italics”
img renderMultiMedia
ins <content revised=”insert”
li item
ol list listType=”ordered”
p paragraph
pre NEHTA defines styleCode=”xPre” for this
span content
style Can’t define styles in CDA
sub sub
sup sup
table table
tbody tbody
td td
tfoot tfoot
th th
thead thead
tr tr
u <content styleCode=”Underline”
ul list listType=”unordered”
footnote  No equivalent to foot notes in html (unfortunately!)


  • Most CDA elements have the attributes id, styleCode, and language on them. This is a much shorter list than the HTML equivalents. The available styles are much restricted.
  • NEHTA has defined a few additional styles as described in the Rendering Specification
  • HTML element list is from

Using Dates, Times, Timezones and Intervals in NEHTA Clinical Documents

There’s been a few queries from implementers about the best way to represent dates and times in the NETHA Clinical Documents. It’s not as obvious as it probably should be for several reasons:

  • Times, timezones, and dates are just hard stuff anyway
  • The flexibility of the underlying v3 types TS, IVL_TS, and GTS means that there’s a lot of possible ways to use the datatypes
  • Actual specific advice in the NEHTA specifications tends be terse and efficient, and also scattered around the different documents
  • Many of the implementations store a full date time in the database, and don’t explicitly track time precision and/or timezone (in fact, many systems are timezone illiterate)

In order to assist implementations, we’ve gathered together a single spreadsheet that summarises the rules that apply to the 5 common clinical documents, and also makes some pragmatic recommendations regarding how to populate these. Because some implementations are waiting for this advice now, and the publication processes take their time, here’s an interim copy of the advice. It’s not final, and I’ll make a note here on the blog when the final version is officially released through the official channels.


p.s. thanks to Brett Esler from Oridashi for doing the work on this one.

Incorporating HTML Diagnostic Reports in NEHTA CDA Documents

A vendor asks how to include a report like the one in this OBX into a NEHTA CDA document (copied from a real report, with only names and the link URL changed):

OBX|1|FT|HTML^Display format in HTML^AUSPDI|1|<HTML><P>This report has been 
forwarded to &quot;DUCK, Dr Daffy&quot; from &quot;MM&quot; with the following 
comments:<br />&quot;TEST REPORT IN HTML FORMAT&quot;<br /><br /></P><B><A 
</STRONG></U>: Frontal, lateral and cone-down lateral view of the lumbosacral
<br>junction.<br><br>There has been posterior decompression and fusion using 
paired rod and<br>pedicular screw fixation at L4 and L5 with a disc spacer. 
The hardware is in<br>the expected position without hardware fracture or 
surrounding lucency to<br>suggest loosening. There is marked disc height loss 
at L5/S1 without<br>subluxation. There is right convexity curvature centered 
at L3/L4. No gross<br>vertebral fracture or osseous destructive lesion. 
Sacroiliac joints show<br>mild degenerative change.<br><br><U><STRONG>CONCLUSION
</STRONG></U>: Posterior decompression and fusion at L4/L5 with disc spacer. No
<br>hardware complication seen. Right convexity lumbar curvature. No vertebral
<br>subluxation.<br><br><br><U><STRONG>X-RAYS RIGHT FOOT</STRONG></U><br><br>
<U><STRONG>Findings</STRONG></U>: Frontal, lateral and oblique views were 
obtained.<br><br>There is a transverse fracture minimally displaced involving 
the tuberosity<br>of the fifth metatarsal bone. The remaining osseous alignment 
is maintained.<br>There is flattening of the longitudinal plantar arch. No lesion 
or fracture<br>is evident. Small ankle joint effusion.<br><br><U><STRONG>CONCLUSION
</STRONG></U>: Acute transverse fracture of the fifth metatarsal base and<br>
displacement is only 1 cortical-thickness width.<br><br>Kind regards,<br>[Image 
"Donald Duck 2"]<br><U><STRONG>Dr Donald Duck  MBBS FRANZCR</STRONG></U><br>

The answer might have been to simple add the html source as an attachment, following the same method as for a PDF, as previously explained:

 <code code="102.16144" codeSystem=""/>
 <title>Pathology Test Result</title>
   <linkHtml href="[guid].html">Original Pathology Report</linkHtml>

This method is valid for sending documents to other clinical systems that are tested against the Rendering specification – it will display correctly. Unfortunately, primarily for security reasons, the pcEHR does not allow html attachments, so this isn’t a valid method for the pcEHR. For the pcEHR, you must do one of two things:

  • Convert the html to a PDF, and use the PDF method
  • Convert the html to CDA Narrative, and insert this directly in CDA

This is not an easy choice – my experience with html to PDF converters has been disappointing. Converting the html to CDA narrative is a better choice for the users – the diagnostic report is no longer a click away. However, converting this html to CDA narrative isn’t particularly easy.

HTML –> PDF is a generic industry thing, and I’ll leave the reader to navigate through the unhappy choices on offer. The rest of this post explores the process of converting HTML to CDA narrative

The first issue is that the html is not well formed xhtml. This is a pretty common case – the source programmer tests in the major browsers, HTML doesn’t have to be well formed. Whether this is a problem or not for conversion depends on how you intend to implement – but lets assume, for the sake of this post, that it is (we’re going to use an xml transform based on this description here, sowe need the content to be wellformed). So the first thing we do is fix that. There’s a number of libraries and web services to do that. This is the output from HTML tidy project (online at

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
<html xmlns="">
<p>This report has been forwarded to "Duck, Dr Daffy" from "Acme Diagnostics" with the following comments:<br />
<br /></p>
<b><a href="">CLICK HERE TO VIEW THE IMAGES (6)</a></b><br />
<br />
<u><strong>X-RAY LUMBOSACRAL SPINE</strong></u><br />
<br />
<u><strong>Findings</strong></u>: Frontal, lateral and cone-down lateral view of the lumbosacral<br />
junction.<br />
<br />
There has been posterior decompression and fusion using paired rod and<br />
pedicular screw fixation at L4 and L5 with a disc spacer. The hardware is in<br />
the expected position without hardware fracture or surrounding lucency to<br />
suggest loosening. There is marked disc height loss at L5/S1 without<br />
subluxation. There is right convexity curvature centered at L3/L4. No gross<br />
vertebral fracture or osseous destructive lesion. Sacroiliac joints show<br />
mild degenerative change.<br />
<br />
<u><strong>CONCLUSION</strong></u>: Posterior decompression and fusion at L4/L5 with disc spacer. No<br />
hardware complication seen. Right convexity lumbar curvature. No vertebral<br />
subluxation.<br />
<br />
<br />
<u><strong>X-RAYS RIGHT FOOT</strong></u><br />
<br />
<u><strong>Findings</strong></u>: Frontal, lateral and oblique views were obtained.<br />
<br />
There is a transverse fracture minimally displaced involving the tuberosity<br />
of the fifth metatarsal bone. The remaining osseous alignment is maintained.<br />
There is flattening of the longitudinal plantar arch. No lesion or fracture<br />
is evident. Small ankle joint effusion.<br />
<br />
<u><strong>CONCLUSION</strong></u>: Acute transverse fracture of the fifth metatarsal base and<br />
displacement is only 1 cortical-thickness width.<br />
<br />
Kind regards,<br />
[Image "Donald Duck 2"]<br />
<u><strong>Dr Donald Duck MBBS FRANZCR</strong></u><br />

So that’s bashed it into shape for running a transform. To convert this to CDA narrative, we need to:

  • Strip off the <html>, <head> and <body> tags
  • Rename <p> to <paragraph>
  • Rename <a> to <linkHtml>
  • Replace <u> with <content styleCode=”Underline”>
  • Replace <strong> with <content styleCode=”Bold”>
  • Put all the elements in the namespace urn:hl7-org:v3

Bingo: valid CDA Narrative:

  <paragraph>This report has been forwarded to "Duck, Dr Daffy" from "Acme Diagnostics" with the following comments:<br/>
    <linkHtml href="">CLICK HERE TO VIEW THE IMAGES (6)</linkHtml>
  <content styleCode="Underline">
    <content styleCode="Bold">X-RAY LUMBOSACRAL SPINE</content>
  <content styleCode="Underline">
    <content styleCode="Bold">Findings</content>
  </content>: Frontal, lateral and cone-down lateral view of the lumbosacral<br/>
There has been posterior decompression and fusion using paired rod and<br/>
pedicular screw fixation at L4 and L5 with a disc spacer. The hardware is in<br/>
the expected position without hardware fracture or surrounding lucency to<br/>
suggest loosening. There is marked disc height loss at L5/S1 without<br/>
subluxation. There is right convexity curvature centered at L3/L4. No gross<br/>
vertebral fracture or osseous destructive lesion. Sacroiliac joints show<br/>
mild degenerative change.<br/>
  <content styleCode="Underline">
    <content styleCode="Bold">CONCLUSION</content>
  </content>: Posterior decompression and fusion at L4/L5 with disc spacer. No<br/>
hardware complication seen. Right convexity lumbar curvature. No vertebral<br/>
  <content styleCode="Underline">
    <content styleCode="Bold">X-RAYS RIGHT FOOT</content>
  <content styleCode="Underline">
    <content styleCode="Bold">Findings</content>
  </content>: Frontal, lateral and oblique views were obtained.<br/>
There is a transverse fracture minimally displaced involving the tuberosity<br/>
of the fifth metatarsal bone. The remaining osseous alignment is maintained.<br/>
There is flattening of the longitudinal plantar arch. No lesion or fracture<br/>
is evident. Small ankle joint effusion.<br/>
  <content styleCode="Underline">
    <content styleCode="Bold">CONCLUSION</content>
  </content>: Acute transverse fracture of the fifth metatarsal base and<br/>
displacement is only 1 cortical-thickness width.<br/>
Kind regards,<br/>
[Image "Donald Duck 2"]<br/>
  <content styleCode="Underline">
    <content styleCode="Bold">Dr Donald Duck MBBS FRANZCR</content>

Additional NEHTA constraints

However there is one more problem – a significant one. The NEHTA Rendering specification says (CDA-RS 43):

Authoring Systems SHALL NOT populate the narrative block with free text that is not contained in an allowed narrative block element e.g. <paragraph> or <content>.

This narrative above has only one <paragraph> around the first paragraph, as provided into the source html. So it falls to the CDA builder to wrap any content – text, <content>, <linkHtml>, <br> – in a <paragraph>. There’s no need to try and figure out where the paragraphs start and end when doing this – just wrap them all in a single <paragraph>. Concerning this, the rendering specification says (CDA-RS 44):

Authoring Systems SHOULD use separate <paragraph> narrative block elements to separate paragraphs of text

This is a SHOULD not a SHALL for exactly this situation – it’s a compromise between proper rendering – have to have the <paragraph> and pragmatics – don’t want to force people to guess at paragraph boundaries. Hopefully over time the source systems will migrate towards valid xhtml, but that’s not something we can rely on any time soon.


Administrative Observations in NEHTA CDA Documents

All the NEHTA CDA Implementation Guides specify a section called “Administrative Observations”. This is where information that is logically part of the context of the document – administrative type things such as patient age – that don’t fit into the relatively tightly controlled CDA header go. A question has arisen over whether a document has to contain an administrative observation section or not. This arises because of this mapping in the CDA IG:

The key point is that the document says that the section is 1..1 – implying that one must be present. Since we said it’s 1..1, the conformance tests do – correctly – require the section to be present.

But that wasn’t the intent of the design. There’s really no need to have the section at all if there’s no entries to go in it (and none of them are mandatory). So there’s been some discussion about relaxing the conformance test in this regard.  However given that we said it’s required, and that it’s been tested to be required, some implementations may have assumed that it’s there, and may have errors if it becomes optional.

So for now, we won’t relax the testing – but it’s reasonably likely that in the future, the section will become explicitly optional, and the testing will follow that.

So I recommend, if you are extracting this admin data from a CDA document – don’t assume that the administrative observations section is present.

FHIR Ballot Issue: Alignment of demographics with v/xCard

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 ( / 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:


Here’s a FHIR representation of the same name:


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:

  <text>Mr Forrest Gump, Jr</text>    

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.


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).


  • 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.


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)


  • 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 This is a rather richer and more extensible way to represent names.


This is a FHIR ballot issue. Comments on this blog post are discouraged – unless to point out outright errors in this analysis. Discussion will be taken up on the FHIR email list, with substantial contributions added to this wiki page. A doodle poll will be held for the final vote – this will be announced on the FHIR email list.