Monthly Archives: December 2013

FHIR DSTU Candidate Posted & Version Question

So today, to mark the end of the year, we’ve posted the final DSTU candidate version of FHIR.

This is not the DSTU itself: it’s the editors draft, which is now undergoing several weeks of QA review for ballot completion, technical errors, layout issues, and spelling mistakes etc.

Our intent is that we won’t be making substantiative changes to the DSTU any more, but if there’s changes that really are justified, we’ll still make them – we have one last connectathon to test everything out. Btw, early registration for that connectathon closes today.

Today’s version of FHIR is the product of 100’s of hours of review, argument, and work., and many people have contributed to the process. We (the FHIR project team – myself, Lloyd, and Ewout) would like to thank all of the contributers (they are named in the specification). We decided to turn FHIR into a real standard very nearly 2 years ago. We originally targeted the end of this year, but earlier this year we reset to the end of January, to give us one more meeting to work on it. I’m pretty pleased that we’ve pretty much stuck to the schedule, though it’s certainly been a grind.

When I compare the final version of FHIR to what we first envisaged 2 years ago, the principle difference is how deep the specification is. There’s some technical stuff there we didn’t anticipate, like the strength of the terminology under-pinnings, and the amount of work the publication tooling does to validate what is published. But the real difference in depth is the amount of interest that we’ve had, the amount of review that we’ve had. And now, adoption, implementation, engagement: these are our focus from now.

A question for any readers: we’ve been discussing what version to call the DSTU version of the specification. There’s a variety of views in the team on the matter. Here’s some relevant facts:

  • The existing version is 0.12 – I started at 0.01, and I’ve incremented the minor version only when we’ve needed a version break for connectathons
  • We plan to implement Semantic Versioning from here on, though with a significant proviso: our current plan is that there won’t be breaking change once the normative version is published (DICOM has run for many years like this)
  • The existing framework is solid and really well tested. Far more than other full standards I’ve worked on, even though it’s only a DSTU
  • We don’t want implementers to think that this is a shaky alpha release that can’t be relied on
  • The domain resources are far less baked than the framework – there’s definitely draft content here
  • We’d usually plan to go to 1.00 as the first full normative standard, though I’m not aware of any formal rules in this regard

If there was any consensus in the team, it would be for calling the DSTU v0.8 – the 80 number has this ring for us. But if we’re not going to target 1.00 for the first normative (which seems unlikely if we follow semantic versioning during the DSTU period), then why not just call it v1.00? Comments welcome on this below, and I’ll feed them back to the team for consideration.

Finally, if you would like to make QA type comments on the DSTU candidate, you’d be welcome. Download this template: FHIR DSTU Review Template, and submit it to me by email (see right) when you’re done (deadline: January 12th 2014).

Turtles all the way down

It’s a common pattern in IT: recursion, where a pointer for what to do next brings you back to where you already are.

Of course, there’s recursion in programming:

Procedure DoSomething(a)

But it occurs elsewhere. One of the most frustrating is when you are troubleshooting some network problem, and the instructions end up saying:

“To solve this problem, contact your network administrator”

Err, I am the network administrator, and I already consulted myself….

This is called Turtles all the way down (see!).

Well, today, I’ve found a new form of it. I’m reviewing a clinical document, and the example medication instructions in the patient advice reads:

“Use as directed by the Doctor in your notes”


Question: RDF versions of FHIR


Are you aware of any plans/efforts to create an RDF version of FHIR? (I see that the W3C website has what looks to be a “dead” page on the subject).


There has been solid interest in an RDF representation for both the resource definitions and for the resources themselves. I’ve seen some preliminary drafts, but the people involved haven’t had time to bring that work to fruition, and we’ve resisted adding it to our core commitments for the DSTU. The DSTU is nearly done now, so I expect this will start the drive towards completion early next year.


Question: translating v2 to FHIR


  1. the proper way of converting XCN segment data into FHIR Practitioner resource (to fill encounter.participants) is unclear.
  2. I can’t find neither the proper segment nor the way of creating FHIR Location resource (to fill encounter.locations) and FHIR Organization resource (to fill encounter.service_provider).
  3. I would like to know if there are mappings from v2 value set 0112 to FHIR value set encounter-discharge-disposition and from v2 value set 0023 to FHIR value set encounter-admit-source. If I’m not mistaken, these mappings are required to fill encounter.hospitalization.discharge_disposition and encounter.hospitalization.admit_source.


1. XCN – this table summarises the mappings from XCN to practitioner:

1 Person Identifier Practitioner.identifier.value
2 Family Name
3 Given Name
4 Second and Further Given Names or Initials Thereof (see notes about name parts at
5 Suffix (e.g., JR or III)
6 Prefix (e.g., DR)
7 Degree (e.g., MD) Practitioner.qualification.code
8 Source Table No equivalent in FHIR (e.g. extension if really necessary)
9 Assigning Authority Practitioner.identifier.system and/or
10 Name Type Code
11 Identifier Check Digit No equivalent in FHIR (e.g. extension if really necessary)
12 Check Digit Scheme No equivalent in FHIR (e.g. extension if really necessary)
13 Identifier Type Code Practitioner.identifier.value
14 Assigning Facility Maybe Practitioner.identifier.assigner
15 Name Representation Code Helps to build
17 Name Validity Range Practitioner.identifier.period
18 Name Assembly Order Helps to build
19 Effective Date Practitioner.identifier.period
20 Expiration Date Practitioner.identifier.period
21 Professional Suffix Practitioner.qualification.code
22 Assigning Jurisdiction Practitioner.qualification.issuer
23 Assigning Agency or Department Practitioner.qualification.issuer
24 Security Check No equivalent in FHIR (e.g. extension if really necessary)
25 Security Check Scheme No equivalent in FHIR (e.g. extension if really necessary)

There’s nothing in practitioner that’s mandatory that’s not in this table (actually, nothing is mandatory anyway). Note that the v2 mapping table for practitioner takes a different approach.

What this table doesn’t address is the url used to identify the practitioner. This has to be synthesized from a repository of practitioners. In some circumstances, you might be able to construct the URL purely from XCN.1, but you couldn’t take this generally for granted.

2. Encounter.location. According to the existing mappings: PV1-3-assigned patient location / PV1-6-prior patient location / PV1-11-temporary location / PV1-42-pending location / PV1-43-prior temporary location, and for the service provider: PV1-10-hospital service / PL.6 Person Location Type & PL.1 Point of Care (though see the notes in the mapping)

3a. v2 tables 0023 and 0112 are place holders for locally defined codes (in FHIR parlance, a terminology binding with just a description, no reference). So there’s no way to provide general mappings

Question: v2 optionality


I am confused by the HL7 V2.7 specification documentation “V27_CH02_Control ” around optionality definition. A data element can have three population states {Not populated.,Null,Populated,}

R represents “required”; if a data element is defined with “R”, could I represent it with || in the instance or always like |something|?

RE represents “required but may be empty”.  If data element is defined with “RE”, I can represent it with |””| in the instance and like || and |something|?
Firstly, clarifications. A field can have 3 states:
  • Populated. The sending system sends a value in the field, e.g. |1234567^^^MR^KP-CA|
  • Not Populated: The sending system does not supply a value for the field, i.e. ||
  • Null: Any existing value for the corresponding data base element in the receiving application should be deleted, i.e. |””|

Before I go on, a couple of comments about the business of null. The definition is implicitly transactional – it says nothing about what it means for a field to be “null”, only that it’s an instruction to delete any data you have. Logically, then, a field |””| should only be used in a message stream where the transactional context is known – in other words, the sending system knows what it means to “delete” the data, and why it is saying to do so. However it’s common in practice for systems to send |””| outside that context, to try and actually mean something. Because the definition doesn’t say anything about it means, there’s a wide variation of views on how to interpret this, and it’s a fruitful area for non-interoperability (I suppose you could blame the spec for this, but people are not conforming when they use |””| outside a narrow context).

With regard to conformance, this table summarises how conformance and state interact:

Code Description Populated (|xx|) Not populated (||) Null (|””|)
R Required Yes Not allowed Not allowed
RE Required but may be empty Yes Yes, provided conditions are met Yes, provided conditions are met
O Optional Yes Yes Yes
C Conditional Yes, provided conditions are met Yes, provided conditions are met Yes, provided conditions are met
X Not used with this trigger event Not allowed Not allowed Not allowed
B Backwards Compability Depends on notes Depends on notes Depends on notes
W Withdrawn No Yes No

The rules for not populated and null are exactly the same because null is an implicit statement that the field is not populated, and for the receiver to remove previous data. From a conformance point of view, then, it’s no different – and a system that sends |””| in order to not send an empty field is using the field completely wrongly.

Note that R and RE have implications for the way applications behave beyond just the implications for what can be in the instance.

FHIR Server Updated

I have upgraded my test FHIR server to the latest FHIR version. The server is found at

My server and the specification will roll in synchronisation for the next few weeks in the lead in to the connectathon.

Note that this is pretty much the stable version for the connectathon, so we can all start working on that now.


Question: Exchanging CDA


I am a CDA newbie; my task is to include a report (in PDF format) in a CDA document. I have managed to find the right implementation guide (for unstructured documents); so what I have managed to do so far is successful construction of a CDA document. My question is: what are some of the best practices for distributing the CDA document? I am especially interested in sending it via HL7 V2 messaging scheme. Please shed some light on CDA distribution


Well, if I was asked to rank exchange methods for CDA in order or importance/prevalence, the order would look like this

  • XDS – This the major mechanism for distributing CDA documents
  • MDM messages (HL7 v2.x chapter 9) – Messages for managing documents (we use these in Australia for exchanging CDA documents0, and they would be a logical choice where you have v2 exchange already set up
  • If you in USA: Direct – Using Encrypted SMTP. This had a big push from ONC in the recent past, but I’m hearing that it’s falling out of focus (I say that as a non-US observer)

There’s a bunch of other ways – sneakernet, or FTP, for instance.

There’s a new way coming too: With FHIR there’s a way to store a CDA document, and make an entry about it to a registry so it can easily be found. David Hay has been explaining how to do this:

Fhir is not done and ready – yet. But it will be soon.

Open Sourcing my FHIR Server

Since early in the FHIR development process, I’ve maintained a FHIR server at Everyone in the community uses this for learning FHIR, testing their implementations, and it’s the de facto reference server (which was my intent).

As part of preparing the DSTU version of FHIR, I’ve open sourced the server. You can find it here:

Some notes on the server:

  • To compile it, you need any edition of Delphi, any unicode version (in practice, XE+)
  • To run it, you need windows / MSSQLServer. MySQL (and therefore OSX) support would be nice, but requires a new data access layer (it works at the SQL level). I’m hoping someone will do the work to make that happen
  • I had hoped to support the Free Pascal compiler and therefore *nix, but the way they handled unicode makes my head spin
  • The source is based on today’s build of FHIR, and I’ll be updating the spec and the server in sync for a little while
  • Not all the functionality is fully in sync in the DSTU – in particular, searching hasn’t yet been updated for the many changes the DSTU version contains
  • The design of the server favors a complete implementation of the specification against pure performance (note: this is not to say that the specification can’t be implemented well – more that I only have a limited amount of time, and I prefer features over outright performance, consistent with being a reference implementation)
  • At the moment, the reference server is still running old server until the upcoming UK FHIR Connectathon happens on Dec 13. After that, it will be upgraded to this version

The license on the server is a permissive BSD-3-clause – while I’d like people who use it to contribute to the source base, I’ll be very happy for commercial vendors to take the server and integrate it (or parts of it) into their own product suite.

Question: Past Medications in FHIR


When the application I work with receives medication information for a particular patient from a GP clinical system we differentiate between current medication and past medication. I’m not aware of a published definition of ‘current’ and ‘past’ in this context and I’m sure it’s not the job of FHIR resources to provide one but is it the intention that the MedicationStatement resource be used to record medicines that the patient is currently taking (or has available to take if needed) – i.e. ‘current medicines’, as well as those that have been stopped and are no longer exerting a physiological effect on the body – i.e. ‘past medicines’?


Well, this is not a straight forward answer. There are some complicating factors:

  • Systems (and clinicians) vary wildly whether “medication” refers to prescribed and/or dispensed medications, records of administration, or just claimed belief on the part of the patient and/or the clinician that the patient routinely takes, or expects to take (or something) a particular medication. In FHIR, there are specific resources for all 4 of those things. I think that medication statement is the right one (and it’s intended to be the right one), but the context of the source system cannot be ignored
  • There’s a real lack of clarity about “past” – what makes a medication “past?” This is both a theoretical question, and a practical one.
    • On the theory side, simply because a medication is not longer being administered it cannot be considered to be past until all physiological consequences are finished. This can be a long time (e.g. Amiodarone)
    • On the practical side, how do you know? You have a prescription, it’s expired, so you automatically call it past? Tricky stuff

Having said that, the basic answer is that in FHIR, the anticipation is that there will be lists (a list resource), a (probably curated) list of current medications, and a list of past medications. You can tell by which list a medication statement is in whether it’s considered past or current.

I don’t find that answer entirely convincing, and we’ll be trying to get a clearer picture of this during the trial use period, but I suspect that this won’t be possible- the sheer variation in approach to tracking medication usage continues to astound me. In the end, what you do will have to be driven by local policy or business practice.


Question: RIM XMI Files


The RIM spec has a zip containing a set of XMI files (rim0241i) presumably which contain UML data so that one can use the modeling information as a base for hl7v3 development.  I have not had a ton of luck importing and using these files – a lot of errors from the importing tools.  After some research I found this “At the moment there are several incompatibilities between different modeling tool vendor implementations of XMI, even between interchange of abstract model data. The usage of Diagram Interchange is almost nonexistent. Unfortunately this means exchanging files between UML modeling tools using XMI is rarely possible.” (from  So my question is how can I extract the information from these XMI files?  Is there a recommended tool to use?


These files were produced by an old version of Rational. There are plans to update to a more recent version, but even this won’t help much. The whole area of XMI support is very disappointing – it feels to me as if this was a spec that the tooling vendors were never serious about supporting: getting it right was never mission critical to any of them.

You could hand-write a transform from that version to an XMI that your tool supports (not that they really ever document that either). Alternatively, I’ve posted my working EAP file for this RIM diagram at



Unfortunately, I don’t know which RIM version this is.

I don’t know if anyone can suggest a better option in the comments – has anyone ever actually done anything with these XMI files?