FHIR: to DSTU or not DSTU, that is the question

When I started this blog, my motivation was two fold: I wanted to continue to learn more about FHIR, and I wanted to capture all the great information that was being captured in the various channels – skype conversations and the HL7 list in particular. In other words a very ‘technical’ blog that could act as an information resource for those new to FHIR. I definitely didn’t intend to comment on the ‘process’ aspects of the standard (those who know me know that I’m not good at that stuff).

I’ve been privileged to be a member of the FHIR Management Group, and our intention for some time has been for the standard to be DSTU (Draft Standard for Trial Use) in January this year (we originally aimed for last September, but that was just too soon) – and from an HL7 procedural perspective we are ready.

However, there have been a number of blog posts in the last couple of days commenting on whether FHIR is actually ready for DSTU now, or whether another ballot round is needed. If you’ve not seen them, then here are the links:  Keith Boone (aka motorcycle guy) and John Moehrke (Security Guru).  Lloyd McKenzie (FHIR expert) has presented the case for the defence.

Now no-one is questioning of the value of FHIR as an upcoming standard – all agree that it is the right way forward – just the actual readiness for DSTU now.

I’ve come to FHIR from the perspective of an implementer – and what attracted me to FHIR was not just the elegance of the approach, but also that it would be available to me soon – I have interoperability issues I need to resolve now. I accept the risks of a draft standard – it WILL change (not MAY change) before it’s a done deal.

But that’s going to be the case anyway – even if there is another round of balloting before DSTU.

And after DSTU then there will be other ballot rounds, and changes WILL continue to occur before normative (where it is fixed) – that’s the consequence of using a standard early on in the development cycle. (The benefits include the value you gain from the work of others, and the ability to affect the development of the standard before it becomes fixed).

And if these risks are too great, then you need to wait for normative in a couple of years, and use something else in the mean time – whatever that may be – and make any changes then.

Whether we go DSTU now or in another 4 months, change is inevitable. So the question for me is: Is FHIR useable for my needs now?

And, for me anyway, it is.


About David Hay
I'm an independent contractor working with a number of Organizations in the health IT space. I'm an HL7 Fellow, Chair Emeritus of HL7 New Zealand and a co-chair of the FHIR Management Group. I have a keen interest in health IT, especially health interoperability with HL7 and the FHIR standard. I'm the author of a FHIR training and design tool - clinFHIR - which is sponsored by InterSystems Ltd.

2 Responses to FHIR: to DSTU or not DSTU, that is the question

  1. hsedidin says:

    I can see a definite need, although not what FHIR is being designed for.

    Many Healthcare companies have legacy databases. Creating the CCD from these databases can sometimes be a nightmare. Mapping the data to the FHIR schemas would simplify the process. The next step is to map from FHIR to the CCD.

  2. Brett Esler says:

    FHIR works for me already – DSTU helps me sell it to others. A complete specification of what shape and how to obtain health data is a great time saver explaining this to others. The extension mechanism is another thing that just makes it some much easier to manage incorporating needed content without breaking interop.
    There will be some serious trial use for me regardless of the ballot status….

Leave a Reply

%d bloggers like this: