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.

If Hospitals ran like Restaurants

Yesterday, I gave a lecture about Healthcare Interoperability – and the lessons learned from FHIR – to a group of master’s students at Melbourne University HaBIC. In passing, I mentioned the danger of using bad metaphors to describe healthcare interoperability, and compared this to the danger of the whole “healthcare should be like the airlines”… and then today, I saw this (h/t HISTalk)

These things are basically pretty stupid – one day, I really want to see someone do this backwards, and do “what if a hospital worked like a restaurant?” – limited menus, shallow service, variable quality… healthcare is not like a restaurant.

On the other hand, the way the financials work in the USA.. that is pretty stupid; they sure have a point about that.

p.s, for a much more serious comparison, see Atul Guwunde’s Big Med

Question: Using #FHIR Medication Resources


To what extent should FHIR Medication resources be reused? Should they be reused across multiple patients’ records?


The general answer is that they should re-used as much as possible. The general expectation is that either a system has a formulary or drug dictionary, in which case there would be one medication resource per entry, and these commonly re-usable medications would be used across many patients, or that you are prescribing by some external code. In the second case, you wouldn’t re-use the medication resource at all.

Note- the resource design will change in the near future to make the second case easier – just put the code on the prescription directly, with no need for the medication resource.

New #FHIR Open License

Today, HL7 released an updated version of the FHIR™ Draft Standard, which is now covered under a Creative Commons License: No Rights Reserved. This marks the formal adoption of a recognized open license for the FHIR specification, and one that is truly open: this is an unencumbered license. Under the terms of the Creative Commons license, HL7:

… has dedicated the work to the public domain by waiving all of it’s rights to the work worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law. You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.

This is a truly open license – even more open than most open source projects, which usually require some form of attribution. However since FHIR is a standard, and many implementations will be required to implement it, it would be inappropriate to require acknowledgement of the specification. Note, though, that the reference implementations may require attribution – and most of them use a mix of BSD or Apache licenses that do.

It should be clear, though, that HL7 has not chosen the public domain license because we don’t care about FHIR – on the contrary, HL7 cares greatly about FHIR and is investing heavily in it. HL7 wants all health care systems, whether commercial or open source, to use the FHIR specification – hence the unencumbered license terms. Because HL7 cares about the specification, it means that HL7 needs to protect the Trademark carefully, since control of the FHIR specification is how HL7 derives value from it’s investment. So the specification itself makes this clear:

HL7 protects the “FHIR” trademark carefully. This means that:

  • You cannot publish an altered version of the FHIR specification unless it clearly identifies that it is a derivative specification, not FHIR itself
  • Derivative Specifications cannot redefine what conformance to FHIR means
  • The letter sequence “FHIR” can only appear as part of a product name with specific written agreement from HL7
  • You can only use the FHIR logo as part of a commercial product with specific written agreement from HL7
  • When used in other contexts, the word “FHIR” and the “FHIR” logo should bear the ™ symbol

The point isn’t to restrict the use of the name FHIR, but to prevent it from falling into ‘common use‘. Where FHIR is used as part of an existing product name – whether a commercial product, or an open source server or library, please contact to ask for this permission (I need to do this myself). Note: As a point of reference, you can compare these rules to the Mozilla Foundation’s equivalent policy.


In the past, FHIR was published under a different license, adapted from OMG (thanks for Richard Soley for allowing this), but using a custom license increased implementation costs, and caused perceptions that the FHIR license wasn’t a proper open license. This new license doesn’t change the effective license terms that apply to FHIR at all – it’s just an expression of the same intent in a form that is more aligned with the open software and standards communities. Changing the license was a process that involved agreement from a very large number of people with HL7, and the fact that this has happened shows the importance that HL7 places in FHIR’s openness. I’d like also to thank two people outside HL7 who particularly contributed to the process – Paul Biondich (from Regenstrief / OpenMRS) and Larry Rosen.

Specification Technical Correction

The update to the license was accompanied by a technical correction to the specification itself. Quoting from the version history entry:

Fix major bug in reading/writing JSON instances: the json equivalent for xml:id is specified as “id” but the java reference implementation had been using “_id”. This is a breaking changed for users of the JSON representation using the Java reference implementation. Note also that this means that all the example JSON instances in the specification were wrong; these have also been fixed in this update

Because of this, the reference implementations and the test servers accept either “id” or “_id”, but “id” is correct.

So the spec used to have, for JSON examples such as this one:

  "contained": [
      "resourceType": "Observation",
      "_id": "obx1-4",

and now it has

  "contained": [
      "resourceType": "Observation",
      "id": "obx1-4",

This only affected contained resources. Thanks for Doug Martin from Regenstrief for pointing this error out.

Reference Implementations

This updated version of the FHIR specification includes updated reference implementations, and an updated maven package has also been posted.

#FHIR DSTU2: Changing the Composition Resource

While in Chicago, one of the decisions that we made was to refactor the Composition resource. Here’s the design in DSTU #1:


The design can be summarised in prose:

  • A section has a title and a code that describe it, and it may have a section if the subject is different to the overall composition (documents that span multiple subjects are not that unusual)
  • A section can contain other sections, or a resource that contains the content for the section
  • The resource is allowed to be any kind of resource, but the most common kind is a List resource.

Observationally, almost all CDA sections are a list – medications, problems, diagnostic reports. There’s a few exceptions: a synopsis section, a care plan. But these are the minority.

There’s a major problem with this design, which revolves around the narrative/text dynamic in a document – what happens if there’s no entries, and only some narrative? Do you have to use a different resource type (other?) if you don’t have structured content (and actually, the way resources are defined pushes you in this direction, because many of them have required data elements, and you can’t use them if all you have is text (that’s a different issue for potential resolution elsewhere).

After a fairly long discussion about this problem, and consideration of a number of alternatives, the structured document working group decided to try this design:composition_dstu_2

This design can be summarised in prose:

  • A section has a title, a code, and an identifier that describe it. Note: the identifier should only be populated if it is persistent across different compositions (unlike CDA, where slippery ids are a source of confusion)
  • A section can have narrative, and an empty reason, or sub-sections or entries (can’t have sub sections and entries, and must have a narrative unless it has sub-sections
  • The narrative is the ‘attested content’ for the section (see CDA definition)
  • Entries provide supporting data for the section narrative
  • If there are no entries and no sub-sections, there can be an empty reason. This is for things like “No medications prescribed” or “None known”
  • A code can be provided indicating what order the entries are in (the narrative order should match the order of the entries, but what is that order – chronological?)

Essentially, the relevant capabilities of the list resource have been conflated into the section.

This has the following advantages:

  • All the attested narrative is inside a single resource
  • The structure much more closely matches CDA (this will help with CCDA/FHIR implementation efforts that are ramping up)
  • There is no ambiguity about what kind of resource to use
  • There’s no confusion about the list snapshot mode – some of the list capabilities don’t make sense in a composition

There’s some potential downsides to this structure – particularly around conformance, and these are the subject of active development and testing, so implementers shouldn’t assume that this is the last word on the matter.