This appeared last week and marks a really big milestone:
FHIR DSTU is published
Posted on February 3, 2014 by Grahame Grieve
We have now published the DSTU version (draft standard for trial use – effectively a beta) of FHIR at http://hl7.org/fhir.
Note that this is now stable and suitable for production implementations, and that development moves to http://hl7.org/fhir-develop, though I think we’ll all be taking a rest before starting work again.
Please note that we are serious about the draft standard for trial use. Implementers should read this section before depending on the specification: http://hl7.org/implement/standards/fhir/dstu.html.
Getting to this point has been a huge team effort, and so many people have contributed. There’s a formal credits page here: http://hl7.org/implement/standards/fhir/credits.html, though this doesn’t cover many people who contributed in a less formal – but not less real – fashion. I also wrote a brief foreword as a separate post.
The post is here:
FHIR Foreword
Posted on February 3, 2014 by Grahame Grieve
FHIR is not a book, and it was not written by a single author; it’s a draft standard, and it was produced by a whole team of people. The formal credits page lists a lot of people, and even that’s being selective. Even though so many people have contributed, I thought I’d post my own personal foreword here:
2½ years ago, I drafted a demonstration, a concept of something that we could do – a better approach to health interoperability. I had no idea that it would turn into a project and a specification that involved this much work, that showed so much promise, and most of all, that there would be so many people to thank.
Ewout Kramer came back to HL7 specifically for the FHIR project, and I’ve been ever so grateful to depend on Ewout for being able to see both the implementer and specification author perspective, and to see across the whole specification. Lloyd Mckenzie imagined the future first, and has been a steady hand editorially, and also has guided FHIR through the HL7 community and processes. Josh Mandel joined the team late, but brought a hard-nosed focus to serving implementation that I greatly appreciated.
Chuck Jaffe was the one who ensured that FHIR came to HL7 in the first place, and that the key, important and difficult stipulation – that FHIR be free – was accepted by the HL7 leadership and community. Without Chuck and the rest of the HL7 leadership (particularly John Quinn), the conditions that let FHIR grow would never have existed in the first place. Thanks.
Lots more of the team mentioned here:
This summary from HL7 explains what FHIR is.
1.7 Introducing HL7 FHIR
FHIR® – Fast Health Interoperable Resources (hl7.org/fhir) – is a next generation standards framework created by HL7. FHIR combines the best features of HL7’s Version 2, Version 3 and CDA® product lines while leveraging the latest web standards and applying a tight focus on implementability.FHIR solutions are built from a set of modular components called “Resources”. These resources can easily be assembled into working systems that solve real world clinical and administrative problems at a fraction of the price of existing alternatives. FHIR is suitable for use in a wide variety of contexts – mobile phone apps, cloud communications, EHR-based data sharing, server communication in large institutional healthcare providers, and much more.
1.7.1 Why FHIR is better
FHIR offers many improvements over existing standards:- A strong focus on implementation – fast and easy to implement (multiple developers have had simple interfaces working in a single day)
- Multiple implementation libraries, many examples available to kick-start development
- Specification is free for use with no restrictions
- Interoperability out-of-the-box– base resources can be used as is, but can also be adapted for local requirements
- Evolutionary development path from HL7 Version 2 and CDA – standards can co-exist and leverage each other
- Strong foundation in Web standards– XML, JSON, HTTP, Atom, OAuth, etc.
- Support for RESTful architectures and also seamless exchange of information using messages or documents
- Concise and easily understood specifications
- A Human-readable wire format for ease of use by developers
- Solid ontology-based analysis with a rigorous formal mapping for correctness
Full page here:
Be assured there is going to be a lot more come on this topic over the coming over the next few years.
Congratulations to all involved (especially Grahame and all the Australians) and isn’t it good to see what can be achieved without the dead hand of Government and such-like pushing their own agendas - which in Australia at least are looking a touch off the pace right now.
As I have been saying for a while the less complex the better and this is a major step in that direction.
David.
18 comments:
Thanks David. It's gradually going to start impacting, but these things take time. In terms of Australians:
* Richard Dixon Hughes and David Rowlands provided important strategic advice early in the piece, and were important behind-the-scenes supporters
* Nat Wong participated consistently in the patient administration design
* Brett Esler did important implementation work, and participated in various all night connectathons from Melbourne
* Brian Postlethwaite came to the party late, but made up for that with enthusiasm, and will be a leading developer in the next round
* Klaus Veil was an enthusiastic behind the scenes supporter for the concept (and partially responsible for the "FHIR" part)
* Heather Grain, Michael Legg, Linda Bird, an Stephen Chu provided support in their own domain of expertise, and gathered information and wisdom from their communities
* Several Australians ensured their company contributed to my time (muchly appreciated): Peter Young, Michael Legg, and Colleen Brooks
* Andrew Goodchild and Andy Bond provided really big picture perspective contributions
* Everyone who attended the Australian connectathon in October last year made an important contribution, and the Australian FHIR profile will make it's way into Standards Australia work
I'm sure I've overlooked someone that I'm going to regret, but I've tried
Ahhh - but wait till NEHTA tries to muscle in and claim some of the credits ............... then Andy Bond and his band of merry men will go ..... hi ho, hi ho, its off to work we go, hi ho, hi ho .... here we are to help show you what to do and how to use it - hi ho, hi ho,... excuse me I'm going to be sick.
This comment is both wrong and unfair. Andy contributed personally directly (and is a friend and a good guy), and many other NEHTA folks contributed a little as well, as they were able.
NEHTA has considered where FHIR fits into their work, but there has not (yet?) been any opportunity to align life cycles (FHIR is still beta)
But whatever happens, they will not muscle in, nor claim any undeserved credits.
... Someone is *wrong* on the internet ...
Best if the moderator removed both comments
While an option I am not keen to censor comments unless they are extreme. Anon has said something - Grahame has responded and I am sure that basically ends the matter.
From the horse's mouth Andy Bond (and other NEHTA people) were a positive contributors to FHIR. So let's just leave it at that.
David
A glimmer of hope is on the horizon.
Not me, but qualified others (Harvard et al no less) are now elevating the value of 'health outcome measurement'.
Now that USA Thought Leaders are leading the way, I can hold a glimmer of hope that qualified others in Australia might recognize the value of incorporating self-reported health outcomes in structured formats, directly from patients into their PCEHRs.
___________
VIDEO: The Power of Outcome Measures in Healthcare, Dr Jens Deerberger-Wittram
http://vimeo.com/72822275
___________
Why we do it
The Mission of ICHOM (International Consortium on Health Outcomes Measurement)
We believe that better health care always starts with clinicians improving the lives of their individual patients. ICHOM is transforming health care by empowering clinicians worldwide to measure and compare their patients’ outcomes and to learn from each other how to improve.
Reducing health care costs
If physicians make treatment decisions based on outcomes, patients are more likely to receive high quality care – at the right time. This reduces health care costs by preventing medical errors and unnecessary treatments.
We also believe this model is financially better for payers. It ensures payers only pay for services that achieve results – so they don’t spend money on avoidable costs.
Supporting informed decision-making
Normally, people choose physicians based on reputation or hearsay because that’s the information available. The problem is, their decision isn’t guided by data. If we publish health outcomes standards, patients could use valid data to find the best-fitting physicians for them.
At ICHOM, we also think it’s an ethical imperative for doctors to measure outcomes and compare the results of different treatments. Then they can discuss which treatments to pursue with their patients.
Improving health care quality
Physicians can use health outcomes data to evaluate how they’re doing compared to their peers worldwide. In turn, this gives physicians a unique opportunity to learn from one another and improve the way they provide care.
http://www.ichom.org/why-we-do-it/
Thought Leaders in Health Outcome Measurement
Thanks David. btw, in my acknowledgements, I forgot that NEHTA granted official permission for the underlying models from the pcEHR (which have lots of good things about them, including quite a lot of review) to be used as input to the FHIR design process. Other national program office equivalents couldn't do this, for a variety of reasons, and it was remiss of me to overlook this in my credits.
It's something we greatly appreciated, and alert readers may notice some rather strong alignment in places between the openEHR archetypes NEHTA publishes on http://dcm.nehta.org.au/ckm/ and the FHIR resource contents.
David, perhaps there is hope for the PCEHR after all or some derivative thereof.
As it is - I still think it is beyond saving.
With fundamental change and re-think something may be viable but then it would not be the PCEHR - except possibly in name!
David.
I agree with David that this is pretty big news globally. The FHIR development community, and Grahame, in particular has produced an incredible amount with FHIR and brought a specification that is simpler to implement than previous HL7 v2 and v3 products, is far more accessible than most standards in e-health, and is beautifully documented. I can understand why so many software developers are flocking to FHIR - it's new and very shiny and for many, I would think - fun. They are no longer embarrassed to tell their colleagues in other industries that they're working on a technological dinosaur.
However, there are some significant downsides.
1. We now have three very different HL7 standards available for sharing structured information between systems.
2. FHIR carries much of the terminology baggage that previous versions suffer from.
3. FHIR (like previous HL7 standards) provides no support ( as far as I can see) for languages other than American. Implementers will strike issues even anglicising/anglicizing for Australian conditions. The rest of the non-american world will have to struggle on with local language hacks if they are to adopt FHIR.
4. FHIR appears to have been developed to overcome shortcomings in the previous versions. But I would contend that the shortcomings of the previous versions were manifested in variability in implementations - predominantly code set usage, lack of tooling, and above all, a total lack of any conformance testing regime for the myriad profiles that have been developed around the world for other than tightly controlled point to point implementations. FHIR doesn't overcome these - it just makes things slightly easier. But FHIR as a specification is not enough. It's all the infrastructure to support implementations and conformance testing and governance around change management that is still missing. And we all know how hard that is going to be to change. The devil is in the detail and incomprehensible to the bureaucrats wielding the policy and funding sticks and carrots.
5. The FHIR development community is still driven predominantly by technical software people. It shows in the quality of the few clinical resources and samples that I've looked at. E.g. instance data not matching the resource profiles and incorrect LOINC codes and mismatches to units - mmol/L is a substance concentration not a mass concentration.
6. UNTIL and UNLESS the resource specifications and instance data can be displayed meaningfully - and with codes dereferenced to their meanings, only the die hard technical geeks will be able to examine many of FHIR's clinical and safety issues.
Hi Eric
Regarding the downsides:
1/ yes, we could have stuck with what we had. I tried and tried to make things better from within, but it's not possible
2/ I'm not happy with the terminology situation, but we had to be realistic, and so things remain the same there. It's something I'm planning to get to soon. However since the real problem is on the terminology side, it has to be dealt with there first
3/ From the beginning, the project team has been mainly non-americans, and it's had a strong dutch influence. We are not aware of the grounds on which you say "provides no support for languages other than american". It *is* monolingual, but there's no requirement that the language of the resource contents be en-US
4/ You're right that the devil is in the detail, but we've moved the yardstick along way along, though some parts of that are not yet very evident. I'll post about this on my blog
5/ "instance data not matching the resource profiles and incorrect LOINC codes and mismatches to units" - maintaining >1000 instances is a *genuine* challenge. We've tried really really hard to get them right. Please let me know the locations of the problems, and I'll mark them for correction. Note, however, that it's quite likely these are errors in source. I can also write some of these things into the tooling so it can't happen again
6/ The codes are dereferenced to their meanings, where that's possible (which means, not anywhere important :-(, see point #2 above). We remain open to improved representations, and we have the capability to produce them if we can design them.
Eric, it's really disappointing that you sit outside the process and make these comments after it's closed. Why not contribute during the process, and make the specification better?
Grahame,
There are errors in many of the FHIR examples just as there are errors in Standards Australia HL7 v2 examples, just as there were errors in the sample CDA discharge summary documents developed by NEHTA, just as there are errors in the ONC blue button HL7 samples produced under the S+I framework.
Most of these errors go undetected precisely because there are no viewers that display the computable parts. That is why, in the case of CDA I offered thousands of dollars for the HL7 CDA challenge. That is why I spent months writing the Healthbase viewer for V2 messages.
FHIR will be a quality and safety risk until this is addressed. I've given this feedback often before wrt CDA and payed a heavy price for so doing.
Now let me give just one simple example from the FHIR site:-
Observation-example-f201-bmi.xml
at:
http://hl7.org/implement/standards/fhir/observation-example-f201-bmi.xml.html.
One of the observations there is for the patient's weight, yet the SNOMED code is for BMI. This is probably a typical cut and paste error. Developers around the world will likely grab this sample and use it as the basis of their own BMI resource. Perhaps the error will be detected, perhaps not. This risk will be repeated time and time again, just as has happened with V2 and CDA.
Trawling through all the XML snippets by hand and "correcting" them is not the answer!
If we are going to improve structured information flows and provide the infrastructure for better decision support then we owe patients and clinicians more than half-baked, error-prone models. Meaningful visibility is key to quality and safety.
Hi Eric
"Most of these errors go undetected precisely because there are no viewers that display the computable parts"
There is for FHIR, and the example you refer to below even uses it (and you can see it as html at http://hl7.org/implement/standards/fhir/observation-example-f201-bmi.html)
"I've given this feedback often before wrt CDA and payed a heavy price for so doing."
I don't know what heavy price you refer to. In regard to FHIR, if you criticise, and you get it wrong, then you'll have been seen to be wrong in public. If you get it right, you'll get our thanks and we'll fix it. I don't see a heavy price there. But being involved in the process will always work better than criticising it from outside.
"Observation-example-f201-bmi.xml at [snip]. One of the observations there is for the patient's weight, yet the SNOMED code is for BMI."
No. There's a BMI with Snomed code 60621009 and LOINC code 39156-5, both of which are correct, and a reference to the source data, height and weight, both of which have the appropriate Snomed codes
"Trawling through all the XML snippets by hand and 'correcting' them is not the answer!"
Really? what is the answer? Any time we find a mistake in the instances, and there's a computable rule that we can use to detect it, I add the rule to the publishing tool (for instance, all Loinc and Snomed display names are verified correct). But there's no way to detect a mismatch between code and text in an automated fashion, so that has to be done by hand.
Any other issues you can find?
Grahame,
The HTML you describe at http://hl7.org/implement/standards/fhir/observation-example-f201-bmi.html only displays the narrative. It does not decode any codes!!!
Yes, there is a BMI encoded correctly with 60621009 from SNOMED and 39165-5 from LOINC.
BUT, there is an Observation immediately above that for weight, with the same SNOMED code 60621009 but a display value of "Weight". The SNOMED code is incorrect!
The fact that you can't see the error when you glance quickly at the XML proves my point!!
Yes, I have found other errors in the samples.
There are several errors in the sample NZ discharge summary document-example-dischargesummary(father).xml, including an invented UCUM code 'tbl'. I also recall in another sample, a code 'g/cm-2' also claiming to be a UCUM code.
there are also the LOINC mismatch errors I referred to previously.
I've only looked at a handful of clinical samples, and found a handful of errors.
"The HTML you describe does not decode any codes!!!"
well, in html pop ups, though that code does take the code/display at face value. I am still trying to figure out how to improve that
"There is an Observation immediately above that for weight, with the same SNOMED code 60621009 but a display value of "Weight". The SNOMED code is incorrect!"
oh. I thought I was validating all the snomed codes. There must be some bug in my validation for that to have slipped through
"The fact that you can't see the error when you glance quickly at the XML proves my point!!"
Don't know what your point actually is though - if it's that instances are hard to maintain, well, yes. But beyond that?
"Yes, I have found other errors in the samples."
I created a gforge task for this - see http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=2973&start=0 (and please don't bother criticising gforge - it's been imposed on us against our will. Stupid stupid tool). I'd be really happy if you add additional details to that task.
thanks for pointing out the error
"oh. I thought I was validating all the snomed codes. There must be some bug in my validation for that to have slipped through".
I think maybe you're bypassing anything inside a "contained" block because you don't want to generate narrative for it? Perhaps a feature rather than a bug?
"Don't know what your point actually is though - if it's that instances are hard to maintain, well, yes. But beyond that? "
It's not that instances are hard to maintain so much as they are opaque. This has two principle dire consequences.
1. Just as with earlier HL7 versions there is a strong risk of variability across vendors and implementations - if you've seen one FHIR Resource instance, you've seen one FHIR Resource instance. Interoperability will suffer. It happened with V2 and CDA.
2. Safety and Quality checking becomes very difficult. There will likely be a proliferation of errors or issues that go undetected.
It seems to me that the problem of opacity is much easier to deal with in FHIR than with CDA. But it needs to be. The US are burning $100s of millions if not billions on C-CDA based implementations at a rate that makes Andrew Howard's $1million per day on the PCEHR pale into insignificance. And it is still a disaster from a quality and interoperability perspective.
I'll take a look at your tracker, but I think for this exercise I'd be like the dutch boy at the dyke wall. It would be infinitely better for FHIR to have something akin to what I've done for v2 - have a viewer that presents resources clinically meaningfully. E.g.
1. For coded data display both the display value and the decoded code. [ I do this for SNOMED, LOINC, AMT, UCUM, ISO+, dozens of HL7 tables and a host of others. I've pre-translated UCUM, ISO+ from American to English ]
2. For OIDs dereference them. If they don't appear in the HL7 registry walk back up the tree and display the nearest proximal match with a warning. For FHIR URI's consider translating them
There are some really nice aspects of FHIR. I'm truly in awe of what you and your co-contributers have achieved in such a short time. But to me it seems that there is a heavy techno-junkie blanket covering FHIR, and the only thing escaping is a pall of XML smoke - of course the techno-junkies suck it in. An exaggeration, perhaps, but you get my drift. If you can shed the blanket - give it some end-user oxygen, then perhaps it will really burn.
For an example of what I mean:
http://pathology.healthbase.info/samples/Blood_Chemistry.html
While I quite like some parts of FHIR I think the Dinosaurs ruled the earth for a long time and V2 is everywhere. There is no comet in sight and I think this little underground creature show promise but needs a lot of evolution and the equivalent of a comet strike to actual wipe out the dinosaurs. It also promises to be easier, but the problem is hard. Starting might be easier but finishing the job will still be very difficult. It is also a distraction from actually implementing working standards well, which is what we really need.
"I think maybe you're bypassing anything inside a "contained" block"
no, it was much worse than that- I wasn't validating codings within a codeableConcept. I've fixed that and beefed up the validation, but the validation is independent of the presentation code.
"if you've seen one FHIR Resource instance, you've seen one FHIR Resource instance. "
Well, the underlying problem is that if you've seen one set of implementation requirements, you've seen one set of interface requirements. The variability problem has two components: the needless stuff that arises due to specification things, and the genuine underlying problems.
In v3, we didn't differentiate between these, and it turned out to be too difficult to allow the second. So what have we done in FHIR?
- we still allow flexibility
- we documented as shallowly and clearly as possible (particular, we focused on using the language of the domain)
- we provided lots of test case examples - and we want more
- we provide really deep validation tooling (this discussion is improving it further, though there is a long way to go yet)
- we provide test servers and encourage testing and test cases
- we provide a profiling mechanism, and already provide tools to test against profiles, and value set and profile designers are coming soon
Because of the underlying variability, we can't solve this, but I'm happy to hear ideas to go further.
"but I think for this exercise I'd be like the dutch boy at the dyke wall"
well, I think that might have something to do with pain, if I remember the story correctly.
"It would be infinitely better for FHIR to have something akin to what I've done for v2 - have a viewer that presents resources clinically meaningfully. E.g."
I guess you mean something along the lines of http://www.healthintersections.com.au/fhir/observation-example-f201-bmi.html, though I'm sure it can be improved upon yet.
"But to me it seems that there is a heavy techno-junkie blanket covering FHIR, and the only thing escaping is a pall of XML smoke"
hey - don't forget JSON - but what can we do to improve it? I guess you're more talking about the instances that the spec here?
Anonymous said...
"While I quite like some parts of FHIR I think the Dinosaurs ruled the earth for a long time"
Indeed, when we started work on FHIR, I thought this was true too. I really didn't expect any existing interface would ever be replaced by FHIR, no matter it's advantages, because don't fix what isn't broken.
However a comet has now been sighted - the forthcoming work on privacy and audit from the US/EU authorities - which seems likely to be highly impactful here too - has the potential to wipe out all the dinosaurs. Let's hope (to continue the analogy) that the comet either misses or delays long enough that we can evolve FHIR enough to be a really solid replacement, not just a DSTU (e.g. Beta)
"finishing the job will still be very difficult. It is also a distraction from actually implementing working standards well, which is what we really need."
Is it? finishing *is* difficult. But somethings are much harder to finish than others. I did FHIR because I became convinced that neither HL7 v2 or CDA had the legs to finish things (and I do know both of them well), and I didn't see any other prospects out there at all.
Post a Comment