Should Governments Rely on HL7?
by Matthew ~ August 3rd, 2007. Filed under: HL7 News.
Out of The Netherlands, Albert D.G. de Roos has an interesting blog about the issues that can arise when government places its faith in a single standards organization, like HL7. He also argues that the HL7 community tends toward isolation and is practically immune from outside criticism since most practitioners are also active members. de Roos writes, “Consultancy through HL7 is only possible for its active members that participate in the technical committees, making independent feed-back from the field virtually impossible.”
I’m not quite as critical as de Roos is but I do agree with most of his points. The reason I started this website was because the HL7 community seemed to made up of library science type academics - more interested in linguistic theory than in real-world application. I’ve even received emails telling me that this site is a waste of time - that no one will bother reading it because I’m not on some HL7 committee. A community that insulates itself from criticism cannot be successful. I do hope that the HL7 organization does a better job at fostering a more open, collaborative structure. Critical voices, like de Roos, are always welcome to any discussion. Take a look at posts from Barry Smith on his blog, HL7 Watch. This is a great example of the public forum at work.
I do differ from de Roos on a couple of points. I don’t see the HL7 organization as a potentially controlling, malevolent standards imposing body. HL7 fills a serious need in healthcare. I know that people can be ideologically opposed to any single organization having too much control over our lives. On a grand scale, HL7 is not very important. The goal is to get people to communicating. HL7, like the universal translator from Star Trek, helps people understand each other. I think that’s a good thing. Also, even though I’m not a member of the HL7 organization, I do make money from HL7 consulting. You don’t have to be an ivory tower linguist or committee member to participate in making the medical field a better place. I hope that more people like de Roos and Barry Smith take up the challenge and help make healthcare information exchange easier. HL7 isn’t saving the world but it will hopefully make it a little easier for those healthcare professionals that can.
Check out more writing on HL7 from de Roos:
- HL7 as standardization organization
- Some practical experiences with HL7 version 3
- Implementing an electronic health record in the Netherlands: pitfalls and challenges
August 6th, 2007 at 4:53 am
Whether or not a government should rely on one specific standard (be it HL7 or otherwise) is an interesting question, especially if it doesn’t control the standardization organization in question. The advantage of an open organization like HL7 is that no party (including govenrments) have a deciding vote - it is entirely up to the body of volunteers to create a set of internationally developed and harmonized models. Choosing to adhere to such a standard should promote re-use of clinical data in the long run.
As far as I’m aware of, although I can’t speak on their behalf, the Dutch national healthcare IT programme hasn’t made a commitment to any specific standard - they can pick and choose, whatever the most applicable standard seems to be to do the job in a particular area. That may be HL7 (messages and/or documents), DICOM, IHE, terminology standards such as SNOMED, or CEN’s 13606. The choice of standard will be impacted by things like best-fit-to-workflow and acceptance/familiarity by vendors. If one looks at the English NHS project one can see that they also use a portfolio of standards: from 13606 like HL7 v3 CDA models, to HL7 v2 IHE-profile based messaging in Radiology, and probably some others.
In general my problem with those that question the development and implementation of open standards (e.g. IHE, DICOM, HL7) is: show me an alternative that works, and has been rolled out successfully on a large scale in multiple projects in multiple countries. None can be found - although I’d like to be proven wrong. EHRs and healthcare messaging, if one has the ambition to do it well, are very hard to implement, be it on an international, a regional or nationwide scale. We’ll just have to accept that - this area needs a lot more work.
I agree with this post: in the large scheme of things a standard like HL7 isn’t that important - but the effort of many involved in healthcare to created a unified way of expressing things is important, regardless of the body where such work takes place. Individually these organizations will suffer from the “not invented here” problem, but there will always be persons that bridge the gaps between the various organizations, and the best ideas and practices will survive.
HL7 v3 may not be the best solution, only time will tell, but it’s one of the best options we have right now to achieve semantic interoperability.
-René
August 7th, 2007 at 8:53 am
René, thanks for sharing your thoughts. I’ve also consulted in banking and public utilities where syntactic transactions (via EDI) were solved long ago. I think the psychological paranoia of sharing healthcare information has contributed to the long delay of information exchange in this industry. I think once HL7 products appear that help ease the v3 pains we will see a much wider adoption. Currently, no vendor seems to be up to the task. Does anyone have experience with a software solution that works well with HL7 v3?
August 7th, 2007 at 10:14 am
Matthew, well, that topic may be worthy of a separate blog post: how does the workflow and combinatorial data complexity in banking and public utilities compare to the healthcare sector?
The relatively simple transactions can be easily covered (healthcare or not), we probably all agree on that. It’s the complex workflows where privacy, authentication, combinatorial data explosions and the terminology issue (not to mention the unwillingness for financial reasons or otherwise to share data) cause us issues - there can’t be a “perfect” technology solution for issues that healthcare workers/patients/lawmakers themselves don’t agree upon. Given that healthcare messaging standards such as HL7 are use-case driven the standard will be as precise/detailed as the workflow it is standardizing. (yes, I meant to express it exactly as it is stated above).
Regarding v3 tools: it all depends whether one regards v3 messages/documents as “just another XML format” in which case the usual XML tools can be used - although one may have to optimize/collapse some of the schema through a custom preprocessor to optimize the use of those tools. Those that use v3 objects within their own application (some of those have v3-inspired database models) tend to be rather flexible in the way they process v3 artefacts.
For those of you that are going to attend the HL7 Working Group Meeting in Atlanta in September: talk to the implementers, they’ll be able to tell you what tools (& how) they have used to implement v3. By now there’s quite a body of experience - we may not see most of it, for the details quite often are kept as a secret for commercial reasons. If one chats to the actual architects and progammers one can get a rather good sense of what tools vendors and providers are using to implement v3.
-René
August 10th, 2007 at 1:47 am
Not to lead this topic astray, but to comment on the “just another XML format”, we should remind ourselves that HL7 [the standards body] does not regard the XML schema artifacts as the ‘normative’. The RIM, RMIM, CMETs and DMIMs are the normative. The ‘tooling’ ,courtesy Beeler LLC, is notoriously plagued by flaws in its generatiion of XML Schemas that [hopefully] accurately reflect the models.
Another troublig fact is that every new ballot “edition”, whether substantively changed or not, bears the exact same XML Schema Target Namespace. This is a serious flaw.
To make matters worse, and to cause XML gurus to run and hide, localised schema packages in Canada with substantively altered base datatypes, RMIMS, CMETs, and other artefacts continue to use the exact same target namespaces as the HL7 base normative.
This is insane. How will this ever solve interoperability?
Let’s do the “pamphlet from airplane” test: An XML document representing a Client Registry Get Demographics Request falls from an airplane passing overhead. We pick it up and examine it. Is it a message we support? Apparently so… the namespace is “urn:hl7-org:v3″ and I recognize the interaction (root node for the xml folks) so it must be. The problem is this document is actually built from the Normative 2006 edition of the schemas, and we currently support the Normative 2005. How am I to know?
Substantive changes took place between these two editions.
The XML document does not reflect this fact.
This goes well against the grain of commonly accepted ‘best practices’ for XML Schema definitions.
Let’s now add Canada to the mix. We’re busy as bees “localizing” the RMIMs, DMIMS and CMETS. We’ve even tweaked the datatypes.xsd and voc.xsd. We’ve made substantive changes. In fact, I can’t really tell which International normative the messages are based upon. So how might a vendor go about implementing HL7v3 messaging support for Canada? The HL7 at the XML Schema level is substantively different, yet perhaps mappable from the normative international edition. But why the major differences? And why is Canada advertising these messages and the underlying models artefacts as belonging to the “urn:hl7-org:v3″ namespace? This is anarchy. And how is it that Canada Health Infoway can hijack the namespace used by the international standard? I dont’ get it. This is absurd.
It’s not much better than everyone implementing their own custom Z-segments in V2. What’s improved with V3 over V2?
HL7v3 is critized for being too complex. A big issue I see to support this criticism is that the RIM and its ontology and class modeling is literally and explicitly exposed in the defined Interactions. A message is a container of information delivered to someone that (hopefully) cares to receive it. The absurdity of exposing ‘classCodes’ and delcaring “place holder elements named abstractly ’subjectOf1′, ’subjectOf2′, or ‘identifiedEntity’ is exposing the class model.
The messages mixes up “is kind of” statements, i.e. class modeling, along with “contains ” expressions, i.e instance data. Person is kind of LivingSubject. There’s no need to expose an element named LivingSubject in the message. I could care less about knowing that a person in my client registration system derives from (is kind of) an identifiedEntity. What I care about is a bucket for the demographic for the person. The 6 levels-deep in the xpath that I need to drill into to get to the interesting demographics data is what give implementors grief. It’s what we percieve to be complex. We want compact, concise, lean, messages, free of superfluous ontological colorings. I don’t need to know that a Person Name is of type ‘PN’ in my instance XML messages. And we dont’ want to transmit mandatory, yet superflouous ‘classCode’ attributes, and the like. Implmentors are not interested in that when the message is flying over the wire and costing bandwidth and processing time!
Let’s talk about quality of the HL7 artefacts: Riddled with errors and inconsistencies and duplication.
For example, Canada recently published a ballot candidate release for Provider Registry messages. some of the XML Schemas had ZERO references to provider information (that the models showed). The xml artefacts are un-implementable. No one bothered to Q/A the XML Schemas. “Tooling problem”, we’re told. Nice. Q/A or lack thereof more like it. This is unacceptable. Everytime Beeler’s infamous XML ‘tooling’ engine is cranked we wind up with a substantively differing set of XML Schemas regardless of whether or not the actual RMIMs were altered. WTF.
Regardless, the ‘out’ for them is that the ‘model is normative’; not the XSDs. What BS. When would an implementor give two cents about the ‘normative’ model (a proprietary Visio model at that) over the W3C standards-based XSD package, which is bolstered by crude schematron assertions in support of modeling concepts otherwise un-implmentable with XSD alone?
Unless the HL7 community wakes up and listens to the criticisms of the implementors and the ontological [see http://ontology.buffalo.edu/HL7/doublestandards.pdf ] critics, the V3 goals will never be realised.
August 10th, 2007 at 8:26 am
Brad,
Well - this does lead the topic astray IMO. Suffice it to say that the non-normative nature of schema under the XML ITS (the specification that describes what XML instances are valid representations of the abstract v3 models) is -by now- a well known implementation issue.
The Dutch national healthcare IT infrastructure has simply chosen to publish a normative set of schema & schematron. The english NHS have been working with others to create a new ITS (a different way of expressing models in XML) that will result in collapsed (less verbose) and normative schema, as well as tools that have the capability to test XML instances directly against abstract models without having to rely on weak schema validation.
HL7 (as an organization) has a long history of listening very hard to the implementers; after all it was founded by implementers, not by academics. Implementers, whether national healthcare IT organizations, or individuals, will simply have to step on to the plate and let HL7 know how things can be improved.
-René
December 20th, 2007 at 6:40 am
René,
It is good to see that HL7 wants to be responsive to comments from implementers.
HL7 is working almost 12 years on HL7v3.
Can you explain to me:
- Why there was a fierce debate on the topic ” Is an Document and Act” last year. A debate that is undecided and made clear that definitions of the core classes were not used consistently in the HL7 committees?
- Why are there multiple versions of the RIM?
- Why has Mr Grainger, head of the NHS-England multi billion project, declared that: “In terms of the core Spine infrastructure, there was some mythology in the Health Informatics Community that the standards existed, HL7 was mature, and so forth. That was completely untrue.”?
- Why after so many years these problems surface?
AdG
December 26th, 2007 at 6:26 pm
With regards to the questions posed by ‘A. de Goei’ (which I have reason to believe is an alias of a well-known Dutch HL7 critic), when viewed in the context of the original posting of this blog:
The NHS, just like the Dutch national infrastructure, started
development in 2003. In 2003 probably none of the existing standards that were a candidate for the English infrastructure (e.g. SNOMED, HL7v3, 13606, IHE XDS) were suitable as-is for the type of complex inter-organizational architecture envisioned, nor were they finalized, nor were there tools to support implementation. If anybody thought one could use off the shelf standards and tools to implement such an architecture in 2003 they probably should have known better. Even today such a project would be (and is) daunting.
In 2003 HL7 v3 hadn’t even been officially released yet - the initial normative release of HL7 v3 was published late 2005. The NHS knowingly chose to implement a beta-version of the standard.
All standards require versioning, new insights have to be added and flaws have to be fixed. It therefore is a sign of maturity that multiple versions exist - because implementations are a driving force for enhancements and fixes. Whether programming language (e.g. C, Java) or industry standards (e.g. WDSL, SOAP, HTML) versioning is the best way to deal with new requirements.
Standards that don’t require updates or fixes probably are like ancient greek: nice from an academic standpoint, but dead as a doornail. Why do some of the issues with HL7 v3 surface right now? Two answers: a) HL7 v3 is a relatively new standard - being published initially in 2005, and b) governments of multiple countries now implement and rely on HL7v3. Implementation leads to the discovery of issues.
Implementation will have to show what combination of standards works best for the type of governmental projects as described by the initial post. Given that there are no equivalent alternatives any governmental project will surely study HL7v3 to see were it would be of benefit within their national healthcare infrastructure projects.
-René