Question: Using FHIR for systems integration


Is there information (i.e., FHIR standards, whitepapers etc.) discussing FHIR from a systems integration perspective? For example, have approaches been discussed on how to implement FHIR to consolidate and integrate information from multiple backend legacy (i.e., non-FHIR) systems then forward the information bundles as FHIR REST services? Have any middleware approaches (e.g, ESB, message buses, data tools) been discussed? The integration may also have “Governance” ramifications because the integration would want to prevent direct access to backend systems


Well, this is certainly a core use case for FHIR, and we’ve had various participants to many connectathons trying these kind of scenarios out.

There’s some information published. In the specification itself, there’s Managing Resource Identity, and Push vs Pull. Here’s a list of blog links I could find:

There’s also some good information about this in the HL7 help desk (Under “FHIR Architecture”). Note that this material is HL7 members only


#FHIR Updates

A round of links and news about progess with FHIR

Draft For Comment Posted

I have just finished posting the final version on which the current draft for comment is based:

This version of FHIR is our first serious look at what we plan to release as DSTU2 for FHIR. From here, this candidate will undergo a round of comment and testing, including the HL7 “draft for comment”, where HL7 members can comment on the content of the ballot, and also will be tested through several connectathons and other implementation projects. Following that, we will gather all the feedback, and prepare the second candidate, which will be published around the start of April. This will get another cycle of testing, and then we’ll make further changes in response. We’re planning to publish the final version of DSTU 2 around the end of June.

DSTU 2 is clearly going to be a landmark release for FHIR; it will be the first full version that has relatively complete coverage of the healthcare space, and I know that a number of large vendor consortiums, national programs and standards projects are planning on using it for real. Our current plan is that the next version after that will be a full normative ballot. Given the amount of interest FHIR has attracted, and the size of the implementation pool FHIR will have, we expect getting full consensus for the first normative version to be a slow process.

So what I’m saying is that any work people put into reviewing this version of FHIR will be time well invested.

Btw, there are 3 main versions of FHIR posted now:

  1. – DSTU1, the current version of the DSTU
  2. – the draft for comment source, which is also the stable version for connectathons from Jan – March
  3. – the rolling current version; it runs about 20 minutes behind version control

Project Argonaut

If you’re interested in FHIR, but been living under a rock, you may not have heard about Project Argonaut. The original press release caused a great deal of excitement. My own comments, for the HL7 worker community, got posted to the public at least here and here. I’ll post more information here or elsewhere as it’s available.

Project Argonaut represents a significant validation of the FHIR project, and I thank the leaders of that group (particularly John Halamka, Aneesh Chopra, Arien Malec, Micky Tripathi, and most of all, Dave McCallie) for their willingness to stick their neck out and also – we definitely appreciate this bit – contribute real resources to our project. This kind of validation has certainly made everyone sit up and take notice, and it seems likely that the FHIR community will grow some more in both breadth and depth in the next few months.

FHIR for executives

Rene Spronk has prepared a very useful high level summary of FHIR for executives. (now all we need to do is complete the “FHIR for Clinicians” document – it’s in progress).




FHIR and Healthcare Informatics Education

One of the interesting things about FHIR is how it offers new prospects for real practical hands-on education.

This is about much more than that it’s much easier and more accessible than other health informatics standards. These are the reasons why:

  • the technology base of the implementation is much more open (browsers, etc)
  • there’s a great abundance of open source tools
  • the community’s focus on examples means that there’s already lots of examples
  • the general focus on patient access to data will mean that students are much more easily able to get access to real data (their own, and others – by permission, of course)

But so far, this has remained just a prospect.

Well, not any more.

Last week, at Furore DevDays, I met Simone Heckmann, from Heilbronn, who’s doing a bunch of real interesting stuff with her students. Ewout described it here:

Simone uses FHIR to teach her students about interoperability and show them the caveats and real-life problems involved in building connected systems. And that’s only part of her teaching curriculum; in addition to have them map one type of messages to another standard, she also asks her students to select any of the available open-source FHIR clients and servers, play with them for about a month and extend them. And this is just the prelude to the final part of the teaching program: she then organizes a hackathon at the Hochschule where the students bring their pet projects they have been working on and test them against each other

This is really cool – my immediate response was the same as Ewout’s: “I want to be a student at Heilbronn“. This is really teaching students something – real experience at getting information to flow between systems.

Simone told me that she’s planning to post her course notes etc on the web. I’ll be sure to post a link to them when she does. I’m impressed – this is exactly the kind of can-do practical work that FHIR is all about.

And if that’s not enough, she’s got a FHIR blog too (it’s in German – this is the English translation) .

Welcome, Simone, to the FHIR community.


Question: Clinical Documents in FHIR


Nice to see so many articles on FHIR to understand this new technology for interoperability. I have a very basic and silly question.
I want to understand i would like to transfer whole Clinical Document from one client to another using FHIR. Since in FHIR everything is being referred to Resource i am not able to find out the relation among them so that i can store it as a single record. and what is the mechanism to update individual Resources inside the Record. If possible please share some sample and case study.
Thanks a ton in advance.


There’s multiple things that “transfer” could mean. If you mean “transfer” in the XDS sense, of establishing a common registry/repository of documents, then you want DocumentReference (see the XDS Profile). This is the technical basis of the forthcoming MHD profile from IHE.

If you mean, some kind of “message” in a v2 push based sense, there isn’t a predefined approach, since no one has been asking for this.

Question: glasses prescription in FHIR


What FHIR resource should be used for eye-glasses prescription?


At the moment, there’s really no proper way. There is supply, which covers part of a glasses prescription, but that’s probably not the important bit. In general, as far as I know, there is no engagement between Ophthalmologists and HL7, and I don’t know where they are with regards to interoperability.

Question: Delphi Client for #FHIR


Thanks for making the source code available for a FHIR server (
Would you be happy to share Delphi code of a FHIR client?
I use Delphi XE7 Prof.


There’s a client library in the reference implementation – see the Pascal Reference Implementation. I don’t have an open source application that uses the library (yet).

Mapping to the FHIR Allergy/Intolerance Resource

I’ve just posted an updated Allergy/Intolerance resource for the candidate FHIR DSTU2. This is closely very based on the shared FHIR/openEHR achetype, though the resource has been renamed. As part of preparing it, a few of us surveyed existing systems, and it seems useful to post the details of these here. Here’s a variety of allergy/intolerance data entry screens from around the interwebs (only one betrays it’s original directly). Each of them is marked with a set of numbers that identify the fields in the Allergy/Intolerance resource:

  1. .type
  2. .substance
  3. .status
  4. criticality
  5. .event.manifestation
  6. .comments
  7. .event.onset
  8. .category
  9. .recorder









There’s several issues here.

The first is the way that the existing recording systems differentiate so poorly between the condition and the event – they are either completely silent about this, or they are quite confusing. The first 4 simply don’t address this – you could record either an actual adverse reaction event, or you could record a patient’s claim that they are likely to have one. The last 3 all quite confusing – they allow you to record a single onset date, but calls the concept a “patient allergy / effect”, or the completely ambiguous “adverse reaction”, (which some people believe absolutely means “an event” while other people absolutely think it means “a condition, a likelihood”. My daughter is quite allergic to cashew nuts, and my experience is that different doctors, nurses and educators use the terms interchangeably).

So is this date the onset of the allergy, or the onset of the first reaction, or the onset of a reaction? or the date of the last reaction. Faced with this UI, I think that different users would pick different dates, and also that it would depend on what the patient said. The last 2 add to this confusion by tracking “status” – which suggests the condition (since sometimes it can resolve)

I presume that particular communities of users have their own rules about how to use the input screens that they share, but the process of working through this between HL7 and openEHR has demonstrated that there’s a complete lack of consistency around this.

There’s a related issue – finding this kind of information – what systems are doing – is very difficult. In fact, in many cases, that’s protected information. That’s one additional great way to ensure that standards don’t match normal clinical practice (as, additional to the one above which shows that there is no normal clinical practice)

Finally, the severity of the effect is very difficult – grading severity is difficult and controversial, so many commenters suggest to us that it shouldn’t be done (or exchanged). But many systems track severity (by a variety of different names), and there’s quite a difference between a minor allergy to latex that causes irritation, and a very sensitive response to a common antibiotic that can cause system wide shock. We’ve currently got only 2 levels of what we ended up calling “criticality” but this will be an ongoing discussion (e.g. CCDA uses 6 snomed levels for severity, though CCDA isn’t entirely clear about whether this the severity of a past reaction, or a potential future severity – but how could it be, given the screenshots above (they’re not all from US systems, but they seem representative of the variance found in this space)


Preparing for the Australia #FHIR Connectathon

It’s 10 days or sp until the Australian FHIR Connectathon, which is Friday. This post is to help people who are preparing for that connectathon. There’s 3 tracks at the Australian Connectathon:

Track 1: Patient resource (Introductory)

This track serves as the simple introductory task for anyone who hasn’t been to a connectathon before, though previous attendees will find it useful for extending their experience and knowledge. The patient scenario is to write a client that can follow this simple sequence:

  • Search for a patient
  • Get a selected patient’s full details
  • Edit and Update the patient details
  • Create a new patient record

Or, alternatively, to write a server that is able to support some or all of these functions.

This is useful because the same patterns and problems apply to all the other resources, and very nearly everyone has to implement the patient resource.

If you’re writing a client, our experience is that your minimum preparation is to start the day with a functioning development environment of your choice – to be able to develop and execute. If you don’t have that set up, you can lose most of the day just getting that done. If you’re writing a server, then the minimum functionality is to have a working web server that you know how to extend

Beyond the ability to develop and execute, any additional work you do before hand to work non these scenarios means that on the day you’ll get further into the scenario, and you’ll get that much more out of it.

Track technical lead: Grahame Grieve

Track 2: Smart on FHIR

This track is more advanced; it uses more functionality and makes deeper use of the functionality that FHIR provides, and adds to this additional context and security related content. For further information about this track, see the Chicago Connectathon Details

Track technical lead: Josh Mandel

Track 3: Clinical Connectathon

The first 2 tracks are distinctively developer tracks – to participate, you really need to be able to develop product (which is not the same as “being a developer”). Still, there are many users of interoperability specifications who are interested in how FHIR works, and these participants have as much to gain from a hands on experience learning FHIR as developers do – and the FHIR specification and community have just as much to learn from them too. With this in mind, the FHIR core team is working towards a connectathon experience that is focused on the end-user experience with FHIR. We held our first “Clinical Connectathon” in Chicago – you can read the summary report from it.

The 3rd track will be a follow up to the Chicago connectathon. Participants in this track will use tools provided by the core team to match the capabilities of the FHIR specification against the requirements and tasks of routine clinical workflow. There’s no preparation needed, except to turn up with a working laptop (or even tablet) that has the latest version of your favourite web browser installed (no support for old versions of IE).

Participants should not that this whole clinical track is a work in progress – it needs mature tooling from the core team, and we are still working towards that goal. This connectathon will be exercising the tooling that supports it as much as it’s going to be exercising clinical scenarios against the FHIR specification.

String clinical lead: Stephen Chu. Stream technical lead: David Hay

#FHIR Updates

Several FHIR related updates:

Just a note in response to a question from an implementer: we are going through a period of making many substantial changes to the specification in response to user feedback. Right now, the test server ( is far behind – that’s work for next month. This doesn’t affect the DSTU test server (

p.s. someone asked why I put the Hash tag (#FHIR) in my blog post headings – that’s because I can’t see how to get my blog post auto-tweeter to add the # all by itself (and I don’t want to write my own)

Health Interoperability Webinar

David Booth, who’s working with the FHIR team on RDF format, asked me to post this to alert my readers to this:

I want to be sure you’re all aware of a free webinar series we are

producing at about the “Yosemite Project.” You can read
more about that project here:

The webinar details are below and you can sign up to attend the live
event here:

DATE: October 17, 2014*
*TIME: 2 PM Eastern / 11 AM Pacific*
*PRICE: Free to all attendees*
*Registration link:

*About the Webinar***

Interoperability of electronic healthcare information remains an
enormous challenge in spite of 100+ available healthcare information
standards. This webinar explains the Yosemite Project, whose mission is
to achieve semantic interoperability of all structured healthcare
information through RDF as a common semantic foundation. It explains the
rationale and technical strategy of the Yosemite Project, and describes
how RDF and related standards address a two-pronged strategy for
semantic interoperability: facilitating collaborative standards
convergence whenever possible, and crowd-sourced data translations when

*About the Speaker***

David Booth is a senior software architect at Hawaii Resource Group,
LLC, using Semantic Web technology to make clinical healthcare data
interoperable between diverse systems. He previously worked at KnowMED,
using Semantic Web technology for healthcare quality-of-care and
clinical outcomes measurement, and at PanGenX, applying Semantic Web
technology to genomics in support of personalized medicine. Before that
he worked on Cleveland Clinic’s SemanticDB project, which uses RDF and
other semantic technologies to perform cardiovascular research. Prior to
that was a software architect at HP Software, where his primary focus
was emerging technologies. He was a W3C Fellow from 2002 to 2005, where
he worked on Web Services standards before becoming involved in Semantic
Web technology. He has been programming for many years using a variety
of programming languages and operating systems. He holds a Ph.D. in
Computer Science from UCLA.


Integration and translation will remain part of what we do for many decades, at least. I know that a lot of what we have to do involves implicit knowledge, and special rules, but it will be interesting to see how a stable knowledge foundation might be able to be leveraged to make it easier to get  there.