Sunday, May 26, 2013

Cecil: FIHR will be fine with PHIN VADS VASC; no need to worry at all

To: HL7 Vocabulary List
Cc: fhir <>
Subject: (FHIR) Value Set -> Code Set


At present, FHIR has a "value set" resource that is a simple representation of what the core principles defines a value set to be (In addition to this, it also allows a single resource that defines both a code system and a value set that includes the entire code system as an implementation convenience). 

From an implementer perspective, "value set" is a completely opaque term. What's a value set-  a set of values? Values of what...? 

I propose to rename the FHIR ValueSet resource to "CodeSet" - this is actually what it defines - a set of codes that may be used in some context.


On Sun, May 19, 2013 at 9:48 PM, <> wrote:

I am opposed to this as I think it just adds confusion when the implementer looks at anything else such as PHIN VADS VASC, CTS2 or the core principles. At some point it is just better to say that the implementers need to learn the jargon rather than trying to change every other group to use yet another ambiguous term.


The 'core principles' referred to are documented here.  

Friday, May 10, 2013

FHIR: Let's Make Things Difficult Again

More interesting material on Eliot Muir's Interfaceware blog, in a thread on the topic of FIHR integration. Here Eliot proposes a strategy to counteract the looming redifficultization of FIHR, by opening up and democratizing the standards process and thus lowering the transaction costs in collaborating: 
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.