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".