Monthly Archives: September 2016

Support for Testing in the #FHIR Specification

On the last day of the baltimore meeting, a small group of us met to talk about the future of testing in the FHIR specification. In particular, the participants included both Aegis and Mitre, who develop Touchstone and Crucible respectively. Out small group made 3 decisions:

  1. We will work towards the adoption of a formal testing framework for FHIR interfaces
  2. We will simplify the existing TestScript resource
  3. We will draft and propose a TestReport resource

Taking these backwards:

The TestReport will contain a summary of the outcomes a test run – which tests were run, whether they passed, and references to a further information (logs, etc). It’s for helping to maintain current registries of implementations and outcomes. I’ll blog about this further once there’s a draft to look at.

I’ll comment on #2 in time, when we have a draft for people to consider.

For #1, a testing framework, we have several motivations for this:

  • It’s well known that a problem with testing processes like IHE is that under the right care (e.g. configuration) and with some judicious off-road modifications, systems can pass their IHE testing – but that often doesn’t equate to conformant implementations in practice
  • Many systems undergo stringent testing in-house in continuous builds, but real world integrations are extremely hard to test
  • As a consequence, applications are often poorly tested prior to upgrade
  • Every real clinical system I’ve worked with has had test patients so that staff can check how the system works. In Australia, custom is that the patients are called Donald Duck, Mickey Mouse, etc. Staff just have to magically ‘know’ that these are test patients, and they pollute stats etc a little
  • One near exception is the Australian MyHR, for which there was no test system, and no possibility of test patients. In practice, people trying to use it had to use their own personal records as test patients (many told me that they did this, and bits of those records drifted into the media)

We’d like to normalise testing – to make clear expectations about how production systems could be tested, and to start encouraging production systems to actually provide such support. Two key corollaries of this – administrators can download the official tests (e.g. IHE, or others) and run them against their system with robots playing the part of the the other system. And also, the testing framework starts to acquire a clinical safety role – adminstrators can add new tests to their own automated tests for the application (e.g. prior to upgrade or configuration change) and assure themselves that known system requirements with regard to system safety are assured. Note that this is something you can only do in the context of a fully configured and linked system of systems – which is why support for testing in production systems is so important in this regard.

Anywhere, he’s a set of ideas to get people thinking about how this all might work:

  • Resources on the FHIR API are either ‘Production’ or ‘Test’. There will be a ‘test’ tag that labels all the test resources accordingly. No tag = not testing
  • Resources labelled ‘test’ are allowed to refer to production records (e.g. for configuration) , but never the other way around
  • Requests may be labelled ‘test only’ or ‘test and production’. Default is production.
  • Clients that have either ‘test’ or ‘test-only’ on requests SHALL indicate clearly to users that this is the case
  • Operations on test resources that use production resources internally on the server (e.g. $expand) are allowed in ‘test only mode’
  • Conformance resource : add a ‘testCompartment’ : boolean flag where true means that the system offers the same services as in production, but in test mode
  • If a system supports a test compartment, it also supports a $clear operation on the test compartment – it clears all the records associated with the test compartment (including audit records), so to reset for an automated test run
  • Testable Systems can be the target of a test engine that executes a set of tests, and which can produce a test report for archival / comparison purposes
  • System administrators can write tests against their system – e.g. clinical safety focused using TestScripts – and these test scripts can cross multiple systems
  • Systems are allowed to make their own arrangements regarding multiple test compartents (e.g. per authorised user)

Anyone with any engineering experience will immediately recognise that implementing this set of requirements is a major design undertaking. It’s not going to happen quickly in existing EHRs, unless s conceptually similar system already exists – but I’ve never seen one.

But if we regularise the interface, and the test servers implement it (not too hard in my server) – then we might encourage movement in this direction gradually, and that would make it cheaper to deliver truly reliable systems….

#FHIR – Adding Identifier to Reference

One of the more controversial sessions at the Baltimore meeting was where we discussed task 10659:  Reference should support logical references

This is a difficult subject because it relates to handling and exchanging information where a formal URL based view of the world is incomplete. In effect, that means, from a purist point of view, the world is already broken. This makes effective resolution difficult; at best, the resolution is also going to be broken – but is it broken in the least unuseful way? – that’s a bad place to try and get consensus from.

Further, in the FHIR framework, the Reference data type is clearly FMM level 5 – it’s been hammered everywhere from the beginning and is production in all sorts of places. And we’ve said that we won’t make breaking changes to FMM level 5 artefacts without consultation with the users. What’s not clear, though, is whether any of the changes that were proposed in the extensive discussion leading up to the quarter devoted to the task (see, for example, here and here) were actually breaking changes.

The outcome of the meeting was that we would add an Identifier to the Reference data type. Given the background, there was fairly strong consensus for the change, but it wasn’t complete. As a consequence, we said that we would define the change, let everyone look at it for a month, and see if any argument comes up that we had not considered.

So I’ve made the changes: see the Reference data type in the current build. Implementers are encouraged to evaluate the impact of this addition in their implementations, and share their findings on the FHIR email list.

Note: since this is not strictly a breaking change, this is not strictly consulting the implementers before making a breaking change 😉

#FHIR DevDays event is coming up

I’m finally on the way home from the HL7 Baltimore meeting. That means that the next main event for the FHIR community is the DevDays meeting in Amsterdam, organised by Furore. This just gets better every year.

The 2016 edition of the International HL7 FHIR Developer Days (16-18 November in Amsterdam) includes a tracks on many subjects, and – as is the practice of the FHIR community – features collaborations with other communities. In particular, this year, we’ll be sharing tracks with the openEHR and The Continua Alliance communities. The speaker line-up is a hall of fame of FHIR and I’m proud to be part of it. Participants of DevDays are free to follow any of the tutorials and hands-on sessions.

If you are interested in “my” track or in FHIR in general, don’t forget to sign up before September 30th, which is the Early Bird deadline and saves you 300 Euro.

I really enjoy the DevDays style, and it’s one of the best meetings I go to. It’s also the best way to engage with the FHIR community and work if you’re in Europe. I’ll see you all there!


#FHIR: Comments in JSON

We use XML comments extensively in FHIR for the examples in the specification:

  <Patient xmlns="">
    <!-- this example patient shows how to use ... -->

Generally, comments are only useful in examples for the specification and implementation guides.

Unlike XML, JSON doesn’t have a comments syntax. Standing advice is to put the comment in some property, so that’s what we did:

    "resourceType" : "Patient",
    "fhir_comments" : "this example patient shows how to use ..."

But there’s problems with that approach – you’re parser has to parse them, and many people have trouble with the idea that you can truly ignore them. Then, if you’re using JSON schema, you have to allow for them. Also, if you’re round-tripping with XML, you lose the exact position of the comment. Finally, must human readers miss the comment anyway, since it’s in a property – and the human readers are the only point of having comments. (So many people use custom variations to include comments, but that’s not an option we have. The JSON community is discussing that, but it seems unlikely it will change, or if it changes, be widely adopted).

The cumulative effect of all this is that, as a consequence of a ballot comment (disclosure: from me) the HL7 ITS committee proposes to remove support for comments from the FHIR JSON format. Specifically, we propose to remove this paragraph:

There is no inherent support in JSON for a comment syntax. As a convention, content that would be comments in an XML representation is represented in a property with the name fhir_comments, which is an array of strings, which can appear on any JSON object. This is heavily used in example instances, e.g. in this specification, but not usually used in production systems (and production systems may choose to reject resources with comments in them)

We don’t know of anyone using this in practice, and for practical reasons, I removed comments from the actual JSON examples in the current version earlier this year, and we’ve had no comments about that. Never-the-less, the JSON format is labelled FMM 5 (see the specification definition), so we need to consult with the implementation community about this.

So we are calling for comment from implementers about this change. If you wish to comment on this change, please send an email to the FHIR email list before Octover 11th 2016. If you comment against this change, make sure you identify the production implementation that would be affected by the change, and how it would be affected.

Notes on #FHIR trademark usage

The FHIR trademark system is operational. There are 2 kinds of license to apply for:

You can use the name “FHIR” without applying for a trademark license in 2 circumstances.

Fair Use

You don’t need trademark permission to make use of the name “FHIR” to refer to the specification HL7 publishes, or the community that builds it. You can use “FHIR” as you like as long as you are referring to one of those things. That’s covered clearly under the “fair use” provisions of trademark law in most jurisdictions. HL7 asks that you mention that FHIR is a registered trademark, and provide attribution to HL7, but you don’t need to do those things under fair use law.

In practice, you can mostly differentiate between fair use and other kinds of use by inserting “HL7’s” into the sentence. For example, if you hold an event called “Learn about FHIR”, modifying the sentence doesn’t really change the meaning: “learn about HL7’s FHIR”. So that’s fair use. On the other hand, if adding “HL7’s” changes the meaning, it’s probably not fair use. For example, I maintain a server called the “FHIRServer” (and I don’t do that on behalf of HL7 as FHIR product director). Changing that to “HL7’s FHIRServer” is not correct – the FHIR Server is not ‘HL7’s server’. So that’s not fair use, and I need trademark permission (which I applied for).

We’re always happy to help members of the community determine what’s fair use – you can always ask me or Wayne Kubick (HL7 CTO) for assistance. (and we’ll be publishing an FAQ in the future on this)

Btw, using #FHIR on twitter is also definitely fair use.

HL7 Use

If you’re organising an event, or providing a resource, and the activity is organised by HL7 or an affiliate, and the activity is linked to a registered project in the HL7 database, or in an affiliate formal list, then you don’t need trademark permission – HL7 own the trademark for it’s own use.


HL7 has no choice but to enforce trademark protection, but we’re doing our best to make the trademark protection un-intrusive as possible. You don’t need any permission to talk about FHIR – even to be critical. But you need permission to use FHIR to describe something of your own. We’ll grant permission if you have a credible plan for alignment with the specification/community, and if you’re describing what you’re doing clearly, so that there’s no confusion about where the ultimate source of authority over the FHIR lies.


#FHIR Video Contest

We work hard to ensure that the FHIR specification is as easy to understand as possible. For example, we have several ‘getting started’ guides for different audiences. But never-the-less, getting orientated with the specification, and/or the FHIR connectathon process can still be a challenge. So today, HL7 is announcing a competition.

Contest entrants must post a video to Youtube that helps implementers ‘get started’ with the FHIR specification and/or the FHIR connectathons. Videos should be less than 5 minutes long, and be posted to Youtube by November the 1st.

Video entries will be judged by Ed Hammond (don’t know Ed? He’s “Mr HL7” is anyone is – see this award), and the winner will get free registration (or refund etc) for their next HL7 meeting.

Ed and I will be awarding some prizes for additional categories, including a ‘community preference’ award.

Call for comments: Logical references

Two tasks have been created from the current FHIR Ballot: 10354, and 10659. Both propose the same basic idea: to allow a reference to refer to an item by it’s logical identifier rather than a direct URL. This is a pretty significant change, so we’re calling for comments from the FHIR Implementer community.

The basic idea is pretty simple. A reference from one resource to another is a URL that identifies where the content of the resource can be found. For example, Observations nominate the patient that the observation is made on:

  <Observation xmlns="">
      <reference value=""/>

This means that the patient resource can be accessed at the given URL. A reference can also be relative, like this:

  <Observation xmlns="">
      <reference value="Patient/example"/>

This means that patient resource location is relative to the end-point at which the Observation was found. Both these approaches assume that the author of the resource knows exactly where the patient resource is found. In a purely RESTful environment, that’s a good safe assumption. But the FHIR community is encountering a number of situations where the address at which a resource is located is not know, even they key identifying information about the target is. In the case in point, this means that the application has a patient identifier, but it doesn’t know where the server for the patient is (or it doesn’t exist) and even if it does, the patient resource id the server uses it isn’t the same as the patient identifier, and there is no obvious conversion (in fact, it’s quite often that the patient identifier is not sufficiently reliable to use in the URL – they change…).

So the proposal is that FHIR should change so that this is valid:

  <Observation xmlns="">
        <system value=""/>
        <value value="5551234567"/>

This is a reference to a patient by their identifier. It’s the responsibility of the reader of the resource to decide how to resolve this reference to a resource (or some other kind of resource) – if they can. Or to decide what to do about it if there’s multiple candidate matches – which is also possible.

This is a fairly significant change. There’s already resources where this pattern is baked in by using a data type choice – see, for example, ExplanationOfBenefit:


Generalising this pattern so it applies anywhere there’s a reference – without having to be explicit in the design as above – is both good and bad, depending on who you are. Generally, it allows a resource writer to move work to the resource reader, but it also allows a resource writer to write resources it otherwise couldn’t?

We’re calling for comments on this issue from implementers, to help us decide. Please comment on the second task (10659)