HL7 Watch Watch

In the first two years of its existence this weblog has drawn a significant response from the wider HL7-interested community. Positive appreciations are to be found inter alia in the following weblogs:

HL7 Connection
"Should Governments Rely on HL7?"

Future of Health IT: Trends and Scenarios
"HL7 Watch: Is HL7v3 Overrated by being rated at all?"

Australian Health Information Technology
"Is SNOMED CT a Practical Usable Clinical Terminology Today?"
Here Alan Rector is also quoted, with his wise words to the effect that:

Unless we can formalise the mutual constraints ... HL7 v3 + SNOMED = Chaos.
The documentation is beyond human capacity ... to write or to understand.

Update March 2008:

Gratifying post also at Trusted.MD:

The argument that HL7 RIM is incoherent is compelling. I'll admit that I've found HL7 RIM to be impossibl[y] confusing for years. The problem is that as a foundation for all-things-HL7, RIM causes a lot of trouble.

Update February 2009:

See also Health Informatics Blog

Update October 2009:

Interesting post from Bruce Lemma:

If you want to get something done - just stick with version 2.x. Version 3.0 was meant to remove the ambiguity that exists in version 2.x by following a more rigorous theoretical modeling framework. In practice though it doesn't. v3 is more ambiguous than v2 ever was. v3 is very complicated. A lot of effort is required just to understand the basic concepts of version 3.0.

The only people game enough to really try and work with HL7 version 3.0 are governments and universities - organizations which can afford to dissipate a lot of resources without tangible results. It's very hard to find a real v3 success story. Have a look into what the NHS (UK) and Infoway (Canada) are doing.

Both organizations have a lot in common - billion dollar budgets, strong advocates of v3 and almost nothing tangible to show for it. It will take a few more billions before people will start to admit that v3 has serious problems.

It's a bit like the children's fairy tale - "The Emperor's New Clothes". Because so many people close to the standard have invested so much into it no one wants to admit it's not working as a standard. You'll find that people from HL7 get extremely defensive if you even hint at the idea that v3 has problems. You've gotten a taste of it already on this list.

Most vendors are extremely careful to avoid being openly negative about the standard because they are afraid of being seen as anti HL7. No one wants to risk annoying organizations like the NHS and Infoway or members of the HL7 organization that have influence over buying decisions at hospitals.

Infoway practically bank rolls the HL7 organization these days. They almost managed to stop v2 education from happening at the next HL7 meeting in Canada.

So it's a pretty pickle that the HL7 organization has gotten itself into - it is almost
impossible politically for it back down at this stage.

To get a more objective view of v3 you need to look at the opinions of people that do not have so much invested in it. One amusing website I can suggest is

http://hl7-watch.blogspot.com/

Good luck with your integration - and don't feel embarrassed about the problems you have with version 3.0 - you're just the little boy that's pointing out that the emperor is not wearing any clothes.

Source: HL7 Anwendergruppe Österreich.

The OBO Foundry: Coordinated Evolution of Ontologies to Support Biomedical Data Integration

The Open Biomedical Ontologies (OBO) Foundry is an attempt to develop a suite of reference ontologies to support data integration across the entire domain of biomedical research. Thus it shares some of the goals of HL7, including the desire to bring about prospective standardization in support of interoperability and cumulativity of biomedical data. In contrast to HL7, however, the Foundry takes a modular approach that is rooted in the division of expertise of biological scientists.

The OBO Foundry welcomes criticism, and a description of the initiative, published in Nature Biotechnology, is now available here. Alternative link here.

The Dialects of RIM

The latest Minutes of Evidence of the House of Commons Select Committee on Health, on the UK National Programme for IT, contain this comment from Richard Granger:

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.

Dr Granger goes on:

We have had to put an awful lot of effort into specifying the standards for messages, around demographics, around booking, around prescriptions, and then the software that BT have built with a number of sub-contractors is brand new software that has been custom-built for the NHS; so that is high-risk, new build software. There was no other way of doing it. I am very pleased a number of other jurisdictions are getting very interested in using that.

He thereby inadvertently touches on another issue currently causing concern in HL7 circles. The HL7 Reference Information Model or 'RIM' was, we will remember, introduced as the solution to the problems created by the appearance of multiple dialects in earlier versions of the HL7 standard. HL7 would prevent the appearance of dialect versions by enforcing conformity to the RIM. Now, however, it is becoming increasingly clear that the RIM itself exists in multiple dialects.

This is more than just a problem of successive, incremental improvements. As the RIM Document Editorial Assessment from 8 June 2007 points out:

... the 2006 Normative Edition contains a RIM document based on the last balloted RIM [from 2003]: this gap creates the opportunity for conceptual conflict between the document and current practice. A reader must choose between a normative edition of the RIM published for ANSI, which contains nothing extraneous but is out of date; an extract of the current RIM as maintained by MnM, which will be the most up-to-date, but which is not readily available to the membership at large; or, which is most probable, the RIM document published in the Normative Edition, which both contains extraneous information and is out of date.

It seems, in fact, that we have at least:

1. the version of the RIM adopted by ISO as an international standard

2. the balloted RIM document that describes those parts of the RIM designated as 'normative', the latest (and still current) version of which, it seems, dates back to June 2003

3. an ANSI publication based on 2.

4. a CEN Standard EN 14822-1:2005 Health informatics - General purpose information components - Part 1: Overview (see also CEN Standard EN 14720-1:2005), based on 3.

5. the 'living' RIM UML model (regularly updated through harmonization) as it exists at any given stage. This RIM contains content that existed at the time of balloting in 2003 but was not then balloted, together with four years worth of cumulated changes. Some of this material is, I am told, intended to be balloted in the future; some (e.g. in CoreInfrastructure subject area) is not.

6. an idealized 'frozen' version consisting of those parts of 5. which have, at any given stage, passed through the process of harmonization,

7. the UK rebuild.

As I understand matters (and as always this understanding may be for various reasons imperfect) the RIM documentation included in any publication of the V3 standard more recent than 2003 should be based on the latest working version of the model as maintained by the Modeling and Methodology (MnM) committee. The publication label “Normative Edition” may cause confusion, however, if it is taken by the reader as suggesting that the contents so labeled are all normative (though this issue should be addressed in the relevant document preface).

Normativity, Completeness and Flexibility

As we have argued at some length, there is a fundamental incompatibility between the claims made on behalf of HL7 as "the data standard for biomedical informatics" and the need for openness to new discoveries that lies at the heart of the scientific method. To repeat: HL7 V2 is an in some ways impressively successful tool for supporting messaging between healthcare institutions, but with one central flaw: it did not prevent the proliferation of local dialects. HL7 V3 was born to overcome this flaw, effectively by removing the possibility of optionality in the formulation of messages, by imposing a 'normative' set of coding options from which all messages must be derived through combination. And it does not work:

Mead,
Yes - it is possible and most of the information is available, it is just not as easy for implementers to find and use as it would be if things were optimal. From what is in the repository, it sure looks like someone intended to put in a definitive list, but it never got completed.

There are some problems, though, as Rene has pointed out: there exists no definitive list of all Trigger Events or Interactions. We could generate one for those that are explicitly defined in the normative ballot, but then it would produce a different kind of problem for implementers: the supplied table (value set) would be incomplete, even though it would be presented as complete. I am trying to start a conversation about whether we need something to indicate that a value set for the normative ballot material is known to be incomplete and is not intended to be used 'as is', but is intended to be extended. Other than creating a new value set and redefining the binding for a realm, we don't have other machinery to do this with (to my knowledge). This tells me that either we need to describe and document this for implementers, or we need to explicitly assert the value sets as 'examples' or
a 'starter set'. Which means that they would NOT be bound in the universal realm, and would not be used in strict conformance.

There are a lot of loose gears floating around in the machinery from my viewpoint. I don't know how an implementer can find all the reference material and necessary vocabulary to actually sit down and build an implementation prescriptively based on what we have currently. There is a lot of stuff that is referenced in the normative sections that is not normative or not complete, yet not erroneous. This is very confusing to me, and I don't really know what the right answer is.

-Ted

See http://lists.hl7.org/read/messages?id=113501.

A piece of good news

The HL7 leadership has not merely recognized the problems of (un)intelligibility of the V3 documentation adverted to on this blog and elsewhere; they have also set in train a strategy to rectify these problems. We send our good wishes to all of these involved in realizing this strategy:

cc August 31, 2007
To: HL7 Co-chairs
FR: Chuck Meyer, Chair, HL7 Board of Directors
RE: Version 3 Editing project

Dear Co-chairs:

The HL7 Board of Directors has identified the need to review the existing V3 portfolio of standards for clarity, consistency, and ease of use. To that end, it has approved a renewal of contract to review existing documentation, identify issues, and propose tactics for making the V3 standard and supporting materials easier to understand and use. It is important to note that the members of the editing team are just that: editors. They will not be authoring materials. They will work with committees to enhance and organize existing materials and make suggestions for new content. Each committee continues to be responsible for its own content. The current effort is beginning at the Atlanta WGM after taking a hiatus since the Spring WGM.

In addition, an advisory group is being formed to act as a liaison between the V3 editors and the membership. Details about that group, meetings and other means of communication will be made shortly. We are seeking volunteers to participate in this group. Please contact HL7 HQ if you are interested in aiding in this critical endeavor. This should require about 2 hour per month of your time

The work is being performed by Ockham Information Services, and the primary contacts are Sarah Ryan and Jay Lyle, under the HL7 direction of Charlie Mead. The team expects that you, as technical committee members, have some issues you would like to ensure are addressed, or that you are already addressing. They will be contacting you to coordinate their activities and to ensure they do not spend time on deprecated assets, perform redundant work, or proceed with assumptions you believe are incorrect.

The timeframe for the entire V3 review is still under development, so don't be surprised if it takes a while for your specific committee to be contacted. The Board has recommended that the focus for review in fall '07 be vocabulary, datatypes and the RIM. The editorial team will endeavor to make their inquiries as specific as possible: we invite you to share your observations and issues with them. If it seems that their process is less efficient than it might be, do not hesitate to provide them any ideas you may have for improving it. Thank you for your help.

Sarah Ryan: ryansaraha1@earthlink.net
Jay Lyle: jay@lyle.net

At the same time we cannot resist the temptation to express our scepticism. How, for example, will the editorial team make intelligible such gems as the recent proposal "to treat telephone as an Observation, with value having datatype Telecom". And how will they make intelligible the long list of org.hl7.rim.decorators, as defined for example in passages such as the following Class AcknowledgementDecorator:

Implementation of org.hl7.rim.Acknowledgement as an abstract decorator, i.e., a class that returns NULL/NA or nothing for all property accessprs [sic] amd [sic] that raises UnsupportedOperationExceptions for all mutators. This is used to adapt custom application classes to the RIM class interfaces and only bother about mapping those properties that actually apply to the application class. This can be done in one of two ways: (1) the client class can extend the decorator directly, and implement the applicable properties, or (2) the abstract decorator can be extend [sic] to a concrete decorator, which would hold a reference to the client object and method bodies to delegate and adapt the applicable properties. (See already here May 17, 2007.)

Dutch HL7 Concerns

In his HL7 Connection blog the Dutch healthcare management consultant Matthew Clapp seeks to provide an open forum for collaboration between and dialog between advanced and beginner professionals in the HL7 field. In his posting "Should Governments Rely on HL7?" of August 3, 2007 he points to what he sees as the the HL7 organization's failure to foster a more open, collaborative structure:

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.

The Course of Life blog by the Dutch scientist and entrepreneur Albert de Roos contains two recent postings in a similar vein. The first, Some practical experiences with HL7 version 3, concludes that HL7v3 seems 'too complex to work with in a multidisciplinary environment":

The complexity of HL7v3 is a general problem and also causes delays in implementation at the technical level. I hoped it has been solved now, but in 2006 not all XML schemes that were distributed could be read by the most common XML parsers available, indicating some of the problems with the complexity of HL7v3 messages. ... These apparently trivial issues may cause many delays and frustration for software developers, I can tell you.

The release frequency is also a problem, introducing problems with the different versions. This can be illustrated by the many different versions of the DMIM and RMIMs that are available on the web. I don’t think any of these have been implemented in the field, so while trying to get the thing to work, the international organization rolls out new normative editions. The Dutch implementation of HL7v3 does not follow the international release schemes, but has been frozen in an earlier version. Trying to keep up with the updates is a full-time job. Combine this with the two releases of the complete Dutch documentation each year, which may include changes in the HL7 messages, and the chaos is complete. Of course, we are only in the proof-of-concept phase, so we can expect changes but is there a any guarantee that HL7 enters a relatively stable phase? What will happen to HL7v3 messages when HL7 international moves on to the clinical document architecture, is there a migration path?

In HL7 as standardization organization de Roos points to certain problematic consequences of the fact that the Dutch government "seems to have completely outsourced the entire process of healthcare standardization to HL7:

The different members of the technical committees of HL7 version 3 modeling are employees of software suppliers, consultant or work in a hospital or other health institution. Given the complexity of the modeling in HL7v3 and the limited number of people or organizations involved, it is doubtful whether the models represent indeed a consensus standard way of working. For instance, the involvement of commercial software suppliers may cause the models to closely represent their own software giving them a competitive edge.

To me, it is clear that HL7 is a lobby organization for its own products and that they try to sell their product wherever possible. There is nothing wrong with a lobby organization and its members can spend their money how they want. The problem here is that HL7v3 is sold as a finished product and as a de facto standard, but in fact is not a complete and finished product and never successfully implemented outside of a laboratory setting. It changes continually, indicated by the fact that the organization now moves towards a new product, clinical document architecture, to largely replace the HL7v3 framework. This shift of HL7 has consequences for the national EHRs that are based on HLv3, showing that national governments are not in control of the apparently evolving requirements for the EHR and its implementation. It is strange that the government puts its ambitions in the hands of an organization that they can’t control and where its members clearly have commercial interests or other ambition that are not in line with public or governmental ambitions.

Adverse Events are Not Observations

A further HL7-relevant issue discussed at the recent Clinical Trial Ontology workshop concerned the peculiar HL7 practice of identifying events (for example events of drug interaction) with their observations. This practice is, gratifyingly, less pervasive in the BRIDG model of protocol-driven clinical research than in HL7, but it raises its head even there, for example in the identification of adverse events as adverse event assessments at:

CTOM (imported package)::AdverseEvent
Type: Class Extends: Assessment.
Status: Proposed. Version 1.0. Phase 1.0.
Package: CTOM (imported package)
Details: Created on 1/5/2005 11:17:58 PM. Modified on 9/26/2005 2:22:53 PM.

in BRIDG Model Version 1.41.

The issue raised at the Bethesda workshop was: why does HL7 persist in instituting what, on the face of it, is an obviously false assertion, as a central pillar of its information model?

This question becomes all the more important given that, increasingly, the task of adverse event assessment will occur at geographical sites remote from the adverse events themselves -- something which is logically impossible where adverse events are identified with their own assessments. How, on the basis of such an identification could we track shortfalls (for example in hospital practices or equipment) leading to adverse events in the hospitals themselves in such a way as to distinguish them from shortfalls in practices or equipment leading to poor assessments at remote assessor sites?

Perhaps the ever resourceful ingenuity of HL7's coders can find some complex coding procedure to keep these things apart even after having already identified them; but why not keep them apart from the very start, as simplicity and realism (and learnability and economy and patient safety) would suggest?

Two answers present themselves:

1. that we have here yet one more example of the influence on early HL7 of the focus on healthcare billing -- adverse events themselves, unlike observations and assessments, cannot be billed.

2. that HL7 RIM (and to this degree also HL7 tout court) is an information model -- so that 'adverse event' means: 'information about an adverse event', 'adverse event assessment' means 'information about an adverse event assessment', and so on.

But answer 1. seems not to be in keeping with HL7's current, and much more ambitious, goals. And answer 2. does not, in fact, support the given identification, since even on this meta-level, information about an adverse event and information about adverse event assessments remain distinct, and the former is not a subtype of the latter.

HL7 and BRIDG

The NCBO organized a Clinical Trial Ontology Workshop at the NIH in Bethesda, MD on 16-17 May. Two talks, especially, were of relevance to HL7, given HL7's influential role in the BRIDG project. The first, by Werner Ceusters, pointed to certain problems with BRIDG, which might be resolved by means of a principled ontology of the clinical trial domain.
The second, by Barry Smith, raised certain issues as to the apparent conflict between what seem to be two goals underlying BRIDG, to serve both as a descriptive representation of protocol-driven clinical research and to serve as a prescriptive standardization of such research.
BRIDG representatives at the meeting pointed to the new release of BRIDG, which is due in June 2007, and in which, we are told, some of these problems will be addressed.

HL7: A Package of Decorators

"Implementation of org.hl7.rim.Role as an abstract decorator, i.e., a class that returns NULL/NA or nothing for all property accessprs (sic) amd (sic [indeed many times sic]) that raises UnsupportedOperationExceptions for all mutators. This is used to adapt custom application classes to the RIM class interfaces and only bother about mapping those properties that actually apply to the application class. This can be done in one of two ways: (1) the client class can extend the decorator directly, and implement the applicable properties, or (2) the abstract decorator can be extend (sic) to a concrete decorator, which would hold a reference to the client object and method bodies to delegate and adapt the applicable properties."

Update: July 9, 2009
The quoted package, now here, was originally posted here, where it remained for almost two years before being taken down in 2009. The misprints which it contains (including misspellings of 'and') are of interest only because they are repeated over 6o times in a single document, suggesting that the document itself was never (proof)read by any human being.

The Mysteries of HL7 and Object Oriented Modeling, from Gerard Freriks

(Posted with permission.)

Reading
http://informatics.mayo.edu/wiki/index.php/Adding_Record_Target_to_ControlAct
I noticed the following exchange:

Rene: using this argument, all kinds of commonly used payload participations and associations would end up at the entry Act of the static model (whatever that entry Act would be, given that the Wrappers R2 project may introduce a Conversation/Contractual Act as the static entry point). Whilst introducing a common XPATH expression to access the recordTarget, (a) for other things one would still have to go to the payload model, (b) it increases reliance on sender/receiver understanding the inheritance and propagation mechanism thereof in the models - the understanding of which is currently probably limited to a dozen people worldwide. From an implementation standpoint this is not desirable.

Lloyd: Receivers must understand propagation between the wrappers period. That is not optional. Placing patient in a consistent place for all models actually makes implementation easier, not harder. This isn't about "common usage", but rather about data that has specific uses other than merely pertaining to the payload.

If I'm interpreting correctly, one expert (Rene) is of the opinion that the inheritance and propagation mechanism in the HL7v3 models is understood by no more than a dozen people worldwide. This means that only a few persons know how HL7 is deploying Object Oriented Modeling. I don't think that I'm wrong in thinking that millions of people know the Object Oriented Modeling techniques made popular by OMG and UML. Why, then, is HL7 using an abnormal, rather than a standard, way to deal with classes and propagation of attributes? Do they do this in order to ensure that only a handful of people will understand it properly?

Reading Lloyd's reaction, it is clear that he expects all implementers to know what only a handful know.
Poor implementers of HL7v3 artefacts.
My conclusion: A handful of experts has created a very nice niche for themselves to provide valued and needed expertise.
Gerard

On HL7 V2, from Ira Kalet

(posted with permission)

You probably will recall my reluctance to say much about HL7 at the very interesting panel discussion at the AMIA meeting last Fall. It was largely because of my lack of familiarity with it. Recently, in an effort to write a section on HL7 and laboratory data for my book, I have delved a lot further into it. I now take issue with only one statement you made. You said you have no complaint about HL7 version 2.x; your objections were directed to HL7 V3 and the RIM. Now that I understand version 2.3.1 and have had some in depth discussion with Dave Chou, my local source of HL7 expertise, I must note that version 2 is a disaster as well.

Version 2 has the virtue that it does not have ontological pretensions, and only claims to be a message transmission protocol. It appears at first sight to have been well thought out, even having an appendix with BNF definitions for messages and segments. On closer inspection, these definitions are wimpy. The text says that they are not to be relied on, that variants not precisely described are allowed. Further, while the overall structure of a message is somewhat specified, the actual content uses a very incompletely specified vocabulary. This is rather like saying we agree to more or less use English grammar but we don't have a common dictionary. It is really true. Some HL7 implementations generate messages using a vocabulary that is unknown to the receiving systems. Sometimes there are synonyms, sometimes not. It is a lot like the differences between different dialects of English (British, Scottish, Bostonian, East Coast American, Southern, Texan, Australian, etc.). Humans handle this reasonably well, but it is a lot of work for a computer program to deal with it. The so-called HL7 interface engines apparently do a lot more than just relay messages, they actually (according to Dave) do translations of messages on the fly. Much work is expended to create these custom translations, so that implementing HL7 is much costlier than implementing DICOM. There are many more dialects of the data vocabulary than there are of English.

DICOM is truly plug and play - if a DICOM data source claims to be able to send certain classes of data and another claims to be able to receive it, all you do is put in the sending system the destination address of the receiving system, turn them on and you are done. If they don't work together one or both of them has violated the specification and should be fixed. Not so with HL7. The HL7 documentation admits as much.

It is interesting that this service of getting data from place to place is so important that people are willing to pay the price of implementing an undisciplined, unruly communication scheme, but they are unwilling to agree on a precise common language.

I needed to vent to someone, and I expect that you would be sympathetic.

Thanks,
Ira Kalet

PS: The success of DICOM is that while it has an "object model", the model is about the image data and not about the things radiologists see in the images (i.e disease processes, etc.). An image is an array of numbers, along with some other data that are also describable without resort to inconsistent meanings. Things like the settings on the Xray tube (voltage, current, energy) when the image was produced, the size in patient space of the pixels, whether contrast was used, the name of the patient being "imaged". I see no fundamental obstacles to taking the same concrete approach to laboratory data and all the other things that HL7 talks about. In all my conversations, it seems to come down to a resignation to live with and evolve what was done already. It reminds me of the joke: "Why did it take God only 6 days to create the entire universe?" Answer: "He didn't have to make it backward compatible with an installed base."

PPS: See now Ira Kalet, Order and Chaos in Medical Data Communication: DICOM and HL7

Interesting Post from HL7 Connection re HL7 V3

From the HL7 Connection blog:

"Has anyone successfully implemented version 3? In my spare time I have been reading everything I can find on best practices and potential pitfalls."
Posted 3 days ago #
leaf999Member

"Why? There is no viable business model. The vendors with current market share have been quite sucessful with v2 interfaces. There are no clear advantages. The v3 data model is not a model of the interface record but rather of an application database. Why would vendors abandon their proprietary advantages developed at significant expense in order to re-develop their product as a comomdity offering, particularly when there is limited, if any, consumer demand (at least in the US).

The only US vendor (if you can call them that since they have no application product that has been implemented in a sucessful domestic healthcare setting) is Oracle. Last time I looked their only sign-up was Quadramed - which has since abondoned the effort (or so I was told by one of their application develoment managers.

Right now, if I were starting fresh, I'd implement v2 using XML.

While I'm at it, where is the formal transition strategy for mixed v2 & v3 interface settings. In my thirty some years in the field I've learned that the transitions are a very big deal.
This issue has popped up at the technical steering committee meetings for well over half a decade with no progress seen, or am I wrong?

What made HL7 such a success was its proclivity for the practicle real world needs of healthcare organizations and vendors. Now we have the Europeans mucking up HL7 the way they did CEN TC251.

The English NHS project is several years behind schedule, over budget, and gaining a reputation for 'shooting the sled dog vendors in the head' (thats a direct quote from a the senior english Government offical) - and they have taken v3 and bastardized it to the point that it could not be considered a standard approach to application interfaces outside the NHS.

The proof comes when one learns that the HL7 Board tried several years ago to discontinue further iterative enhancements to v2 telling committee chairs (I was one)that they should abandon additional v2 development. This edict was later recinded. I would see this as a clear indication that it was the result of the healthcare community having their say.

In my humble opinion, after more than a decade of development, HL7v3 is stillborn. I'm very unhappy about the situation and I very much hope I'm wrong. Please show me the error of my thinking - believe me when I say I'd be delighted. Until then I'll continue to recommend the use of v2 interfaces using XML."

Connecting for Health: A Glimmer of Light: Part 2

Tim Benson has posted the following Comment on my "Connecting for Health: A Glimmer of Light":

You obviously did not read my article carefully. NHS Connecting for Health has resolved to base future clinical messages on HL7 CDA Release 2 - not CDA release 1 as you imply. HL7 CDA Release 2 is an implementation of HL7 V3, which includes structured clinical data, using the HL7 Clinical Statement Pattern, together with an additional human-readable rendering of each part of the message. This is valuable for recipients with legacy systems who cannot yet process fully structured messages. As such, CDA Release 2, which became a standard in 2005, is an enhancement on earlier HL7 V3 messages, which do not have a human-readable component.

Nowhere, however, did I state that CfH was planning to use Release 1 of CDA. Rather, I merely expressed the thesis that Release 1 is a well-crafted HL7 artifact because it is free of the peculiarities of the RIM.

Here is the news item I cited concerning the change at issue:

CfH simplifies HL7 implementation

NHS Connecting for Health (CfH) has confirmed industry reports that it is planning changes to the implementation of HL7 within the National Programme. The planned changes will make greater use of the clinical document architecture (CDA) and will allow messages to be exchanged through electronic documents rather than through the fully encoded HL7 messaging format.

A spokesperson for CfH played down the significance of the change, describing it as ‘technical’: “We’ve not abandoned SNOMED coding or HL7v3 messaging. The CDA is a small technical change that better facilitates the carrying of fully coded messages in some circumstances." (Emphasis added)

From this I infer that the use of CDA will allow messages to avoid the 'fully encoded HL7 messaging format'. A glimmer of light, then, as is testified to also by the following Comment to Tim Benson's article:

Eureka!
The adoption of the Clinical Document Architecture standard by CfH is a great move albeit an inexplicably belated one. It massively reduces the barrier to entry for system suppliers. CDA is implementable now (indeed it has been in other countries in Version 1.n). The NPfIT message implementation manual has previously mandated a 'hardcore' HL7 V3 Clinical Statement approach. This was fine for suppliers with a team of Regenstrief Institute post-docs on their development staff, no legacy to consider and a decade to produce something functional. Those vendors without these advantages can now deliver something of immediate major clinical utility while remaining consistent with more sophisticated standards as a final destination. Tim, when/where is the official announcement of this change?

In the article itself, Tim Benson writes:

The NHS Connecting for Health programme has recently resolved to use HL7 CDA (Clinical Document Architecture) for future clinical messages.

So, not fully encoded HL7 v3 messages, then. Sounds good to me. Tim goes on:

The central idea of CDA is that each message includes a human readable representation of its content, which has persistence and can be authenticated, and may also contain structured clinical data, defined using the HL7 V3 clinical statement model.

Is what is being stated here that each document shall include both a message and a human readable representation of the content of this message? And that, in addition to both of these, it may contain also structured clinical data, defined using the HL7 V3 clinical statement model? So three sorts of content? The last of which is optional?

Tim writes:

If you want managers’ support, the computer system has to help the bean counters. If you want clinicians’ support, the information system has to help clinicians communicate efficiently and effectively. CDA provides a way of supporting both requirements.

... The innovative aspect of CDA is that all CDA documents can be rendered in a human-readable way for viewing using a browser, while coded and other structured data can also be included to enable clinical decision support, audit and analysis.

As I understand matters, the NHS is using CDA release 2 mainly because they want to be able to have human readable rendition of the data in the document. No structured data is allowed that does not have a corresponding text rendition. What I am unclear about is whether textual portions are allowed in CDA documents without any corresponding structured data (as Tim seems to imply with his use of phrases like 'can also'). Will those whose legacy systems cannot yet process fully structured messages be allowed not only to process (i.e. read) these human-readable renderings, but also to incorporate (i.e. write) human-readable material of their own into CDA documents?

And what, precisely, is the formal relationship between the textual part of an NHS-style CDA and the structured part? What is the 'standard structure for exchanging data' that is provided by the CDA (other than, say, English) to which Tim is referring for example here:

CDA provides a standard structure for exchanging data in a way that supports person-to-person communication alongside structured countable data.

These questions are not trivial. They relate to the very core of the relation between CDA and HL7 v3 messaging.

Here is what HL7 itself has to say about the matter:

A CDA document is wrapped by the element, and contains a header and a body. The header lies between the and the elements, and identifies and classifies the document and provides information on authentication, the encounter, the patient, and the involved providers. The body contains the clinical report, and can be either an unstructured blob, or can be comprised of structured markup. A CDA document section is wrapped by the

element. Each section can contain a single narrative block and any number of CDA entries and external references. The CDA narrative block is wrapped by the element within the

element, and provides a slot for the human readable content needing to be rendered. Within a document section, the narrative block represents content to be rendered, whereas CDA entries represent structured content provided for a computer. CDA entries encode content present in the narrative block of the same section. CDA external references always occur within the context of a CDA entry, and are wrapped by the element. External references refer to things that exist outside the CDA document — such as some other image, some other procedure, or some other observation (which is wrapped by the element). The CDA entry that wraps the external reference can be used to encode the specific portions of the external reference that are addressed in the narrative block.

All of this speaks in favor of optionality, it seems to me. So light is glimmering still.

Connecting for Health: A Glimmer of Light

Interesting news from the United Kingdom, where so much effort and treasure have been expended in the last two years in attempting to base a national system for health information exchange on HL7 v3 messages. The HL7 approach is based on the requirement that a new kind of message should be created for each of the many separate kinds of information transmission. Once again, this requirement has proved economically unfeasible to implement in a non-toy environment.

Miracle of miracles: the UK National Health Service has decided not to use HL7v3 for clinical messages.

The NHS describes this as "a small technical change that better facilitates the carrying of fully coded messages in some circumstances." This is, however, to downplay the huge significance of the choice. It means that the NHS, after huge efforts on the part of some of the best minds in health IT, has found that HL7v3 messages are just too painful and difficult to use. Connecting for Health will use instead the Clinical Document Architecture (CDA), which is the HL7 document format, and which -- in version 1 at least -- is one of the few well crafted pieces of HL7 artefact. This means, in effect, that CfH is moving to a single generic message that is able to take anything as payload. This is a complete dis-endorsement of the HL7v3 message approach by HL7's biggest supporter (by far) -- hence the attempt to downplay it politically.

Unfortunately, there are still issues remaining. CDA is a single-document specification; thus it has no provision for cross-document linking or for EHR repository versioning. CDA is heavily text oriented, and although it can store some structured content, the definition of that content at the entry level is limited to RIM types. Thus, we predict, many of the familiar problems of v3 will be thrown up once again.

Death by UML

As is well known, HL7 v3 follows, in some uncertain way, an object-oriented developmental methodology modelled on the UML approach. The essay "Death by UML Fever" by Alex E. Bell of the The Boeing Company throws interesting light on UML, which may help us in understanding also some of the peculiar phenomena associated with HL7:

UML fever: A potentially deadly illness plaguing many software-engineering efforts today, the most important strains of which are:

Blind adopter fever consists in a loss of judgment on the part of software engineers "when it comes to assessing appropriate usage of available technologies and processes for their own programs. ... Engineers afflicted with blind adopter fever have been observed to blindly force state machine semantics into all of their classes just so they can take advantage of forward engineering technologies that convert UML diagrams into code. ... A side effect of using such processes is wasting time and money on producing many unnecessary artifacts."

Curator fever: "Much as a museum curator has a fascination and passion for paintings, those in the software engineering realm afflicted with curator fever have a similar absorption in UML diagrams. This absorption is fueled by curator fever's propensity to delude its victims into believing that production of UML diagrams, as opposed to the engineering content behind them, is the single most important activity in the software-development life cycle. A commonly observed behavior by those in the grips of curator fever occurs when domain analysts create volumes of use-case diagrams but remain oblivious to the fact that the most important artifact of use-case modeling is developing the supporting text. UML interaction diagrams with messages analogous to 'solve world hunger' between objects are of little value to any stakeholders."

Desperation fever is associated with project traumas such as slipped schedules, low productivity, and poor product quality. "A symptom of those plagued with desperation fever is flattened ears that result from spending inordinate amounts of time on the telephone speaking with vendors in search of products that will solve all known project woes. ... The severity of desperation fever typically escalates as the result of highly paid consultants telling afflictees that newly purchased products will not bring benefits without major overhauls to existing software-development practices."

Open loop fever: "The effects of open loop fever stimulate the urge for rampant creation of UML diagrams with no traceable objective or having no obvious stakeholder. Victims of open loop fever believe that the act of creating UML diagrams alone is a guarantee of value-added activity. Clinical research has suggested that individuals most susceptible to open loop fever are those who have never been end users of UML diagrams and those whose ride on the software life cycle has been very limited."

Gnat's eyebrow fever is recognized "by a very strong desire to create UML diagrams that are extremely detailed. ... afflictees of gnat's eyebrow fever emphatically believe that it is important to model to very low levels of detail because doing so increases the probability that the resulting code will be more correct. Because of variables such as flux in system requirements and dependent design activities occurring in parallel, for example, the time spent on low-level modeling is often better applied to actual implementation. Clinical research has shown a high affliction rate of gnat's eyebrow fever in those modelers who have not actually participated in coding activities."

Round trip fever: "a complete loss of the ability to use abstraction as a means of managing the complexities of software design."

For Bell , the above maladies derive not so much from problems with UML itself, but rather from poor process, no process, or sheer incompetence of its users. For more background regarding UML itself, however, see Bertrand Meyer, "UML: The Positive Spin".