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.