I’d rather not compete with HL7, but the current state leaves me no choice but to speak up.
Yes, it would be a step in the right direction if HL7’s IP was public. I have no issue with the idea of HL7 holding copyrights, charging for memberships, and voting rights. I just have an issue with its closed nature. W3C may be expensive but their standards are public and well adopted through industry. When HL7 adopts this model, I could perhaps embrace HL7 as a workable solution. Until then I’ll continue to beat the drum of using something else that is open source.
Hypothetically speaking if the ABBI content working group used CCDA as its format, then we would be forbidden by HL7 from actually putting the CCDA specification and the ABBI implementation guide out for public comment. In fact, some people within the ABBI working group may not even be able to review the work because they are not members of HL7 and thus forbidden to see the specification. Not a very transparent process.
Another issue with CCDA is the fact there are not complete XSDs (XML schemas) published by HL7. This makes its implementation subject to interpretation, which leads to interoperability problems. They do have a schema, but only a “top level”. The XSD should be exhaustive and it needs at a public URL so that there is one source of truth. This is how XML and XSD are supposed to work.
I’d make the point that there is a big difference between an “open source implementation” and an “open source specification”. To paraphrase HTML inventor, Tim Berners Lee, “Regardless if you play your music on a million dollar pipe organ, or on a toddler’s xylophone, everyone should have the right to learn how to read the music and know what the notes mean.” If the meaning of music notes was a closed secret requiring membership, we would have a lot less music in the world wouldn’t you say? I’m all for the rights of businesses and individuals to develop proprietary software, open source software, or something in between. The specification for information interchange, however, should be open and transparent.
I’m not so sure that either XML or JSON is the right format, because neither meet the ABBI goal of human readability without some sort of software transformation. This makes things more complicated for the patient.
I’m thinking it should look a lot closer to the VA’s existing Blue Button format with some tweaks to make it easier to transform into a machine-friendly format. In this way we are still building off what is already done and we are maintaining the goal of human readability.