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.
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.
… 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’.
... 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.