Monthly Archives: December 2017

Re-platforming the MyHR

A couple of months ago I made a post proposing that the MyHR could be reworked to use the Argonaut interface. This change could open up the MyHR infrastructure so that providers and vendors could collaborate to build innovative local solutions without being bound to national political concerns about what is possible or not.

That caused quite a bit of discussion and media interest (e.g. in Pulse IT). This week I met with Tim Kelsey (CEO, Australian Digital Health Agency) as part of the follow up, and he pointed out an as-yet under-appreciated aspect of the Agency’s work plan for next year.

Quoting from the Budget Measure:

This measure allows the Australian Digital Health Agency to implement plans that will increase efficiency and sustainability and reduce the ongoing operational costs of the system in the longer term through the transition of Department of Human Services’ support functions to the Agency, the re-tender of the national infrastructure operator and delivery of a new, more flexible platform.

I’ve heard lots of discussion about efficiency and sustainability, but it seems that the commentariat haven’t picked up on the significance of ‘a new, more flexible platform’.

The Agency will be conducting community consultation around this subject in the first half of next year. In advance of that, the community of interest in digital health in Australia – which is a pretty wide set of people and institutions – should start thinking about these questions:

  • How should the Agency conduct the consultation to ensure that it gets good, honest open input from the community, without political noise overwhelming the process?
  • What kinds of improvements could be made to the MyHR to make it a more flexible platform that are both politically and financially realistic? (and that align with the digital health strategy, since that’s that the official national strategy)
  • How should the technical specifications that underpin a more flexible system be managed (e.g. what’s the standards process for digital health in Australia)?

Tim will be commenting in public about this subject too – I’ll link to his comment from here once he makes it (maybe later in January)

Note: I have a contract with the Agency, to provide advice around strategic direction with regard to the Secure Messaging project, which overlaps a little with regard to this subject. But in this case, I’m not speaking on behalf of the agency in any official sense.

#FHIR Paradigms

Many of the FHIR tutorials show this diagram:

The goal of this diagram is to show that FHIR defines 3 different ways to exchange FHIR resources:

  • Using the RESTful interface – the most high profile way to exchange data
  • Packaging the resources in messages, and pushing them between systems (similar architecture as HL7 v2)
  • Packaging the resources in documents, with a managed presentation (similar architecture as CDA)

Also, what this diagram is intending to show is that in addition to the 3 ways defined by the FHIR specification itself, there’s other ways to exchange resources. Since the most common alternative method is to use some enterprise web services framework (say. some kind of SOAPy thing) – we called it ‘services’.

But that’s misleading; a ‘service’ is some orchestration of exchange of FHIR resources, and most implementation projects build their services using some combination of RESTful interfaces, messages, and documents, along with other methods of transfer. And that’s a combination that the FHIR community thinks is perfectly valid. So calling the 4th ‘other’ category “services” is… misleading… to say the least.

However there’s something beyond that missing from this diagram. In the last year or so, the FHIR community has gradually become more focused on what is emerging as a distinct 4th paradigm: using persistent data stores of some kind or other to exchange data between systems. Classically, this is associated with analytics – but it doesn’t actually need to be. The typical pattern is:

  • Create some kind of persistent store (can be an SQL database, a nosql db, a big data repository, an RDF triple store)
  • Applications generating data commit resources to the store
  • Applications using the data to the store find and retrieve data from the store at a later time

We haven’t really acknowledged this paradigm of exchange in the specification – but it’s what the RDF serialization is really about. And all the uses I’ve seen have one uniting characteristic: there’s a need to reconcile the data when it is committed, or later, to help with subsequent data analysis. There’s 2 kinds of reconciliation that matter:

  • detecting, preventing or repairing duplicate records
  • matching references (e.g. resolving URLs to their target identity in the database, and storing the native link)

One of the subjects I’d like to discuss in New Orleans next month is to gather the various disparate strands of work in the community around a ‘storage paradigm’ into a single coherent whole – if that’s possible. It’s something that we’ve been slow to take up, mainly because HL7 classically agrees to focus on the ‘interface’ and keep away from vendor design. But that’s happening in the community now has moved past this.

In particular, there’s really interesting and energetic work using new databases (or new features of old databases) to store FHIR resources directly in the database, and performing the analysis directly on the resources. Google presented some really interesting work around this at DevDays in Amsterdam a couple of weeks ago, and we’re working towards hosting a publicly usable example of this.

Clearly, we’ll need a new diagram to keep up with all these changes.


(Chinese Translation)

Question: LOINC code for smoking start date


My team is currently working with FHIR DSTU2, and part of the project that we are working on requires  SMOKING information, particularly the date the patient started smoking.  Part of this work is also mapping this particular information to LOINC, and basically our issue is that we are unable to find anything that refers to a patient’s smoking start date in LOINC.  What would be your suggested work around for the above?

We did find quit date, which good – just not start date.


Well, there’s no LOINC code to match 74010-0 (Date quit tobacco smoking). So the best option is to make up your own code, and propose that LOINC add a matching code, then change to use that once that’s done.

You can propose new LOINC codes here: