V3 and CDA proponents [along with proponents of other standards] could register resources and see who uses them. Over time natural selection will occur – people will gravitate to the resources that are most common and useful. … Some resources will be easier to do quality validation on. This will impact on the value that people see in those resources – for instance very large CDA documents are difficult to validate effectively so that may impact on the value that people see in them.
FHIR as currently conceived, in
contrast, is to be, like other parts of HL7, centrally defined:
I’m just sitting on a group that is looking at device integration with FHIR. It’s a beautiful example of how problematic it is trying to make centrally defined standards to handle device data. There are so many different types of devices and the area is always changing. On the other side most of the EMRs don’t have the capability to display the data.
On why healthcare information
standards need to be as simple as possible:
… the complexity and problems of the healthcare business itself provide more than enough craziness. Also crazy healthcare standards tend to help competing vendors that are willing to hold their nose and make specialized tools to deal with the niches they helped to create.
… Truth is that there are lots of incentives for different economic actors in healthcare to make interoperability and standards more complicated. The reality is that some times these create barriers to entry for competitors. What happens though is at some point a tipping point occurs when suddenly it becomes in everyone’s interest to make inter-operability easier rather than harder.
You have to look at the players realistically to try understand what their motivations are. Follow the money. One area that people make money in is being a consultant to government organizations in terms of helping them with developing interoperability with all the various programs they want to do. There are perverse incentives to make the standards a little complex and obtuse because it creates barriers to entry for competitors to do the work you want to do.
Of course you can have too much of a good thing. One beautiful example was the NHS Spine. I had the joy of reading the spec on that one time to see if we could implement it. It was a nutty amalgam of LDAP, V3, ebXML combined into an impenetrable mess.
There were consulting companies associated with the development of that spec that had then developed products to implement connection to it. They were a little too effective; though in the sense I think in the end the NHS saw through it all and realized that it was too complicated to succeed. It was a classic example of ‘consultant capture’.
What would it take for FHIR to be successful:
... all participants have to able to only use the tools they are already comfortable with. One of the numerous reasons that V3 failed to get widespread market adoption was that it required a large investment in time to learn all the tools that were developed internally by HL7.
… An engineer in Mumbai that is working on a glucometer for medical device start up needs to be able to easily find or create a FHIR profile and be able to discuss it online without finding the equivalent of 3 months salary to come to WGM in order to find out they will need to come to six meetings and lobby like crazy before they even get a shot at contributing to the standard.
One of the things I noticed at the HL7 working group is how daunted a lot of the people were with even the current full tool set get going with FHIR. You have to install subversion and have the right version of Java. All of this stuff comes with a whole learning curve associated with it. Right now I can’t even really locate where the tools can be downloaded from the FHIR site.
6 comments:
Oh dear, not an industry-standard tech stack! I can't believe that we might have to actually develop software. If people are complaining about needing to know subversion and java, they are missing the point of a reference implementation.
That particular criticism sticks with me, because these tools have been established for a decade or more, and while might not be the latest and greatest, aren't exactly obscure.
@Jim I think you need to read the entire thread to really understand the context or better still come and participate in an actual HL7 working group meeting. It's expensive - the meeting fees alone are quite costly, forget airfare and hotel.
The people that are close to understanding the actual data that needs to be shared have too many barriers to actually participate. It's not worth it for most people.
The overall standards process for HL7 is just not keeping up with the needs that exist in the marketplace - so in the real world it's a whole adhoc mess of one off solutions. The costs to collaborate on standards are too high.
I don't usually comment on blogs (and I suspect I'm going to regret this one) - but just to clarify, you DON'T need to download the spec from SVN, install java etc to start with FHIR - that is only for those developing the core resources or extending the standard.
For everyone else, just point a browser at one of the on-line servers and get started.
The spec itself (Including the links to the test servers) is online at http://www.hl7.org/implement/standards/fhir/ and fully hyperlinked (it even includes examples)
cheers
I'm not defending HL7 or their processes (There's no reason for me to start now), it just sounds like the tech stack is the most approachable part of the whole thing.
There's a series of tensions inherent in what FHIR is:
* simple enough vs rich enough
* useable enough vs reusable enough
* easy enough to author vs easy enough to use
* pragmatic enough vs theoretically right enough
* suitable for new development style vs old development style
* extensible enough vs interoperably-enough (I can make up words too)
From the beginning, all these tensions have existed, and it's a compromise all the way. If we don't make compromise, then there's no value, but if we do make compromises, someone will be unhappy.
Many people said that I was nuts to take FHIR to HL7, and to work it through a standards organization. In particular, they predicted that the committee process would ensure that the set of compromises that FHIR was from the beginning would be lost. And that was a very real risk. But any community driven process that is not a personal fiefdom is subject to that risk. And the alternative - some (semi-)ungoverned process - would doom FHIR to complete irrelevance. The community process brings value to the table, but has it's own price.
In practice, it's worked out ok. I think that the original compromises that made people like FHIR still hold true. On the other hand, FHIR is a work in progress, and there is still so much to do. So many of these criticisms have some validity, and some of the things we have done have not yet born fruit. But they will.
@David implementing a one off FHIR client isn't hard - we've all done that. The issues to light when you look at what is required to implement a FHIR server.
Read my blog and you'll be able to see the issues.
@Grahame I think you have to open up a little and explain more what the reality of the HL7 community is today.
The big issue that HL7 has is that the grassroots supporters have stopped coming to HL7 long ago. You don't see the small start ups or the smaller hospitals. There are nice people participating, I know many of them but...
The majority are:
1) Consultants to government.
2) Government.
3) Massive vendors
You don't see the energetic, go getter innovative small start up companies. Unintentionally HL7 repels those types of companies. If you want to change the world you need to attract those types of people to FHIR.
You've done a good thing for the industry in that FHIR has killed V3. Only problem is that looking at who is on the governance board it's all the same people that made V3. So left along FHIR looks to go the same way.
The high level messaging on FHIR I could identify with - I heard what I you wanted me to hear. But when I went to the AGM I saw the reality of how this is being developed I saw a very different picture.
Having a centralized committee which is controlled by a very small number of people that are too removed from the problem will never work.
Unless you can narrow the scope of what FHIR is going to target and fix all the other problems FHIR is not going to be successful. Trouble is your team members, at least one of them seems extremely unwilling to do that.
What I just want to make sure is that HL7 does not force FHIR on the industry by getting governments to mandate it as a standard.
Post a Comment