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

British Computer Society report calls for overhaul of NHS IT project

A new report from the British Computer Society calls for a fundamental rethink of the NHS IT programme. Several of its proposals relate to standards, including the assertion that much more needs to be done to ensure that systems achieve semantic interoperability. Among the key additional tasks in the area are:

a) an electronic health record/electronic patient record (EHR/EPR) architecture that suppliers can converge towards. The ENV13606/CDA v2 standards would be sensible starting points. [ENV 13606 is a European pre-standard for exchanging electronic patient records. It is due to become a full European and ISO standard in 2007. CDA (clinical document architecture) version 2 is an HL7 v3 generic standard for messaging clinical documents. Like ENV13606, it comprises a recursive hierarchy of components.]

b) representation of content, especially clinical content. Particularly important are items most relevant to patient safety, such as allergies, adverse drug reactions and medication statements of all sorts. Again ENV13606/OpenEHR archetypes would be a sound starting point ...

f) representation of knowledge in general, and the clinical knowledge associated with drugs and prescribing in particular, i.e. indications, cautions, contraindications, side-effects, drug to drug interactions and so on. The latter needs to be accessible via the NHS Dictionary of Medicines & Devices (DM+D). ...

m) continuing the work NHS CFH is already engaged in with others to make the HL7v3 messaging standard easier (and safer) to use, which is timely and important. The claims made for HL7 v3 to be a basis for standards other than messaging should however be investigated thoroughly when considering their adoption.

n) a need to openly pilot SnomedCT, the terminology adopted as standard by the NPfIT, disseminate the outcomes and to publicize current plans to cope with and tackle long-term challenges, such as equivalence and negation. There will inevitably be significant generic issues in the introduction of compositional terminology as novel as SnomedCT, especially in real-time use, and it would be sensible to explore these centrally on behalf of all future users.

o) a need to check that the set of standards chosen form a coherent whole – given the variety of standards that exist and their overlapping scopes, e.g. HL7 v3 / SnomedCT & record architectures – and decide the deployment scope of each. The expression of negation in clinical records is a case in point.

The apparent incompatibility of SnomedCT's 2-valued logic with HL7's 3-valued logic is another case in point.

Alan Rector on SNOMED, HL7 and Quality Assurance

In an excellent keynote lecture at the recent Semantic Mining Conference on SNOMED CT, Alan Rector makes a number of points of direct relevance to HL7 and its continuing problems. As he puts it, 'Unless we can formalise the mutual constraints ... HL7 v3 + SNOMED = Chaos'. 'The documentation is beyond human capacity ... to write or to understand'.

Rector puts forward a series of proposals concerning Quality Assurance for the new SNOMED Standards Development Organization, from which the HL7 organization, too, could benefit immensely. What is needed is:

– Member of board for Quality Assurance - sole responsibility
– Senior member of operations unit for QA- sole responsibility
• Changes in process
– Fully open and honest QA process
– Public statement on problems and public health warning until fixed
– Public commitment to specific quality criteria and success in specific applications.
– Engagement with providers, vendors on key criteria for QA
• Major technical effort
– Set up an independent quality assessment unit
• The developers can’t lead it because they can’t see it!
– Invest in crash effort at improvement of quality
• Initial goal of say 25K guaranteed QAed & reliability assessed codes

Quality, as Rector points out, 'is best addressed by openness.' One might add (drawing on the experiences in England): HL7 v3 should refrain from promoting itself as an ISO standard until its own QA problems have been fixed.

AMIA Panel on the Future of HL7

This panel will take place at 3.30-5 p.m. on Tuesday November 14, 2006 as part of the Annual Symposium of the American Medical Informatics Association in Washington DC. Panelists are:

Barry Smith (organizer)
Werner Ceusters
Christopher G. Chute
Charlie Mead
Don E. Detmer (moderator)

Further information is available at: http://ontology.buffalo.edu/HL7/panel.htm
Audiotape of the presentations is here: http://ontology.buffalo.edu/HL7/AMIA_06_audio
Slides for Smith's presentation are here; those for Ceusters' presentation here.
Aftermath 1
The presentations from the four panel members generated a (sometimes heated) discussion. Several speakers pointed to existing implementations of the RIM (contradicting one claim in Smith's presentation, to the effect that there are no implementations of the RIM). In discussions subsequent to the public part of the meeting, however, it proved that in several of the mentioned cases it was not the RIM itself which had been implemented, but rather some version of the RIM which had been fixed up to make it implementable.
Aftermath 2
It is interesting that both of our interlocutors accepted that there are problems moving from design to implementation of HL7 V3. Yet still they see no problems in the fact that HL7 V3 has been declared an ISO standard.
Aftermath 3
Both of our interlocutors insisted that they want critics to join the HL7 movement, rather then throwing potshots at the RIM from the outside; otherwise, they say, HL7 will not pay attention to what we have to say. But some within HL7, including our friend Gunther Schadow, are already paying attention. And surely this is right: if problems are found in an endeavor of such importance for the future of healthcare and of healthcare information technology, then it should be incidental who points out these problems. What is important is that they are fixed.
Aftermath 4
We brought arguments to the effect that important aspects of HL7 RIM can be supported by no known reasoning systems; other aspects are incompatible with the reasoning systems underlying important terminology initiatives such as SNOMED CT and NCIT. In response, our interlocutors insisted that HL7 RIM it is just a messaging standard; thus it does not matter if it does not support reasoning. But does this jibe well with other claims being made on behalf of the RIM, including claims made at this very panel?

Harmonisation: CEN and HL7

by Gerard Freriks, former chairman of CEN TC251 WG1.

(a statement of opinions, extracted from the OpenEHR e-mail list)

Harmonisation between CEN EN13606 EHRcom and HL7v2 is not taking place.

Harmonisation between CEN EN13606 plus its Archetypes and HL7v3 message artefacts is not possible.

Harmonisation between CEN and HL7 on the level of Archetypes as performed by humans using the OpenEHR Archetype Editor Tool (and therefore EHRcom part 2) is possible. This is very much needed and taking place.

Harmonisation between CEN EN13606 EHRcom and HL7v3 work on the Clinical Statement might become possible but this has to be proven.

In general, mappings are possible only when both worlds share one or more meta-models that guide the transformation/mapping.

At the archetype level, when archetypes are presented to humans, only humans are able to translate in the absence of a formal complete and accepted ontology.

Part 1 of CEN TC251 EN13606 is not the same model as the HL7v3 RIM. A mapping between the two is not possible. They are certainly not the same.

It might perhaps be possible, with some considerable effort, to create a computational mapping between Archetypes expressing CEN TC251 EN13606 part 1 and an HL7 RMIM expressing the very same standard. By the nature of the process, these meta-models can be mapped, though only partially. And extra models would be needed to deal with all possible mappings of structural HL7v3 vocabularies and elements in part 1 of the CEN Reference Model to the CEN archetypes documented in part 3.

Requirements-based standards
CEN TC251 EHRcom (and OpenEHR) is the only EHR-related standard I know that is meticulously based on a well-researched set of requirements for the EHR as published by ISO. (EHRcom is a communication standard. OpenEHR is a specification to be used in an EHR-system.)

Proof of concept: working software
CEN TC251 EN13606 EHRcom is based on more than 15 years of research in Europe and Australia. Various proof of concept studies have been performed. The most recent one is OpenEHR, it is published functional software with open source specifications. There is also interoperable proprietary software produced by OceanInformatics from Australia based on CEN TC251 EN13606 EHRcom and OpenEHR.

The Message paradigm versus the Archetype (Two Level Model) Paradigm
Any solution derived from the RIM and expressed as a message using the HL7v3 MDF method will NEVER scale, since each vendor has to write specific software for each artifact and each version. Each clinical domain will consist of many messages, and there are many clinical domains.

Any solution based on the CEN TC251 EN13606 is scalable by the fact that only one schema based on part 1 has to be implemented by the vendor, ever.

Any CEN archetype or set of archetypes assembled in a Template can be read, stored, retrieved, presented and exchanged without the need to write any software by the vendor. Therefore EN13606 and OpenEHR provide build-in scalability.

Decision support
Systems that are conformant to EN13606 EHRcom have as an additional feature that software providing decision support is able to query ALL the data stored since all data in conformant systems is presented using one uniform method without any extra programming. Plug-and-play decision support becomes possible.

Plug-and-play
CEN TC251 EN13606 EHRcom makes real Plug-and-Play semantic interoperability possible.

Status
EN13606 EHRcom is not only becoming a European Standard and a National Standard in the various Member States of the EU; it is on its way to becoming an International ISO standard as well.

Background: The information/knowledge economy
Healthcare (like any other business) is part of the information or knowledge economy.
Phenomena enter the human mind as data.
The human transforms the data into information using expertise and knowledge.
The information is documented via statements in documents using systems such as the Electronic Healthcare Record System.

Semantic interoperability
Semantic interoperability is about documents that describe phenomena about the patient that happen, or are supposed to happen, or have happened, in the real world.

The data that is placed in any document by the healthcare provider expresses his personal view of what happened in the real world, and meta-models govern the way the healthcare provider is documenting this view.

Semantic interoperability is possible when two communicating healthcare providers share the same meta-models. Or models that can be mapped onto each other safely.

Only systems based on the same meta-model can be integrated easily. The following meta-models can be distinguished:

Meta-Model: Health Information System
E.g. CEN TC251 Health Information Services Architecture (HISA)

Meta-Model: Document
E.g. CEN TC251 EHRcom part one, HL7v3 CDA R2/3, HL7v3 Clinical Statement.

Meta-Model: Clinical Model
E.g. Archetypes and Templates as described by CEN TC251 EN13606 parts 2 and 3. Archetypes and Templates define the information model healthcare providers need to document their care where they need to share with others the salient information. Archetypes and Templates constrain a meta-model for a Document. It is because of this that Clinical Models can be transformed only when they share the same meta-model for the Document.

Meta-Model: Healthcare Provision
E.g. CEN TC251 WG2 System of Concepts for Continuity of Care. Only when healthcare providers use the same shared set of concepts that are needed to describe the provision of healthcare they are able to co-operate in the treatment of the same patient and documentation thereof.

Meta-Model: Coding Systems
In the meta-models and other models used by the healthcare providers and its EHR-system codes are used. Only when both sender and receiver (e.g. co-operating healthcare providers) use the same coding systems patient-safe exchange is possible.

Meta-Model: Semantic Links
E.g. CEN TC251 EHRcom part 3. In the various meta-models and models components will be linked with annotations. These annotations express the nature of the link between the components. Patient-safe exchange is possible when both communicating partners use the same meta-model used for describing the semantic links and the semantics of the links. The semantic links are used by the various models the EHR-system the Healthcare provider is using.

Ontology
Without a (implicitly or explicitly) shared ontology, it will not be possible to populate all the models in a way that makes possible patient-safe exchange of documented information.

The Message paradigm: HL7v2 and HL7v3 Message standards fold Meta-Models (and Models) 1, 2, 3, 4 , 5 and 6 together in one set of schemas, to be uniformly implemented by all vendors.

The Archetype paradigm: CEN TC251 and OpenEHR do not fold all these Meta-Models and Models together. Vendors only need to implement the Meta-Models of 1 and 2 only once. All other models can be used without any needed implementation effort by the vendor. Thereby enabling a better, more flexible, safer and plug-and-play interoperability.

Links
htttp://www.CENtc251.org
http://www.OpenEHR.org

Is the HL7 RIM an ISO standard? Really?

An announcement with the title "HL7 Reference Information Model Becomes ISO Standard" was recently posted at the http://www.hl7.org/ website by: Health Level Seven, Inc.

So that's clear, then. HL7 Reference Information Model has become an ISO standard.

Governments with centralized healthcare systems, as we know, like to embrace international standards; and they have been known to invest large amounts of money in systems based on such standards which have then failed.

This raises all the more urgently the question: are there clear examples of V3 implementations which actually work, to set alongside the conspicuous examples of failures?

It raises also the question: on what basis did the ISO make its decision to anoint the V3 as an ISO standard, given that the V3 documentation is, as representatives of the HL7 organization have admitted, of such low quality as to be practically unintelligible?

September 18, 2006—Health Level Seven (HL7), one of the world’s most prolific healthcare standards developers, today announced the August 3, 2006 publication of ISO/HL7 ... Reference Information Model (RIM) – Release 1.

HL7 became a Standards Partner of the International Organization for Standardization (ISO) through the American National Standards Institute (ANSI) in 1998. This arrangement allows HL7 to submit its ANSI approved standards directly to ISO to become joint ISO/HL7 standards. The standards are accepted and approved through the ISO Technical Committee 215 – Health Informatics. Through this process, HL7 can share its products with the International Standards community, thus reducing the need for duplicative work. Furthermore, HL7 standards are widely used by vendors who sell their health information technology
products internationally. Because many countries require the use of ISO standards (when they exist) a major regulatory and legal barrier will be removed when HL7 standards are approved as ISO standards.

“We are delighted with this first publication of an ISO/HL7 standard—the HL7 Reference Information Model,” said W. Ed Hammond, member of the HL7 Board of Directors and Vice Chair of the HL7 Technical Committee. “It is particularly important because it sets a direction for further HL7 standards to be shared internationally and defines the role of ISO in coordinating “a single standard for a single purpose.” HL7 appreciates the support and contributions of other standards development organizations and national member bodies in making this happen. It is significant that the HL7 RIM is the first standard to achieve this joint publication because of the role the RIM plays in harmonizing building blocks for additional data standards.”

From http://www.hl7.org/documentcenter/public/pressreleases/20060918.pdf

Does the RIM Really Protect HL7 from the Proliferation of ‘Local Segments’?

From the HL7 Terminfo forum we read the following (posted by Rik Smithies) about the extension to the RIM created by the Connecting for Health initiative in the UK:

Statement Relationships are a UK/CFH invention I believe, that hasn’t gained wide acceptance elsewhere, perhaps because there hasn’ been a strong push, perhaps because our requirements are different, and perhaps because there are other ways to achieve the same thing.

Background :
A Statement Relationship is an Act that works as an Act Relationship. It’s an Act plus a pair of Act Relationships to Act References, that all stands in for a single Act Relationship.

Since it is an Act in its own right and uses ActRefs, it’s doesn’t have to be ‘in-line’ in the XML, and so can be sent separately ie. in a different message. They can have authors that are different from the Acts they relate together and can be updated or removed like any Act.

They have been used for :

1. ‘after the fact’ assertions of links/relationships
a) to allow not having to resend the acts that are being linked
b) to allow breaking the link between two acts (remove the linking act, remove the relationship)
c) to allow a different author from either act to assert the link

2. Allowing coded vocabs of relationship types, rather than using the small group of ActRelationshipTypes

I don’t fully understand how other solutions to 1a) and 1b) work, but I have heard that it is covered by controlActs, possibly in conjunction with updateMode.

A driver for 1a) was to avoid sending the Acts that are being referenced, firstly for message size reasons (though in fact Statement Relationships are physically large). Secondly and more importantly to avoid sending other people’s Acts, so as not to appear to be authoring them, and to avoid re-stating them out of context, without their associated statements, participations etc. I’m prepared to believe there are more elegant solutions to those problems.

1a and 1b are particularly helpful for larger structures that are prone to needing re-organisation, eg problem lists. You may want to move Acts from one list to another, without changing (or ideally restating) any of the Acts themselves. This is common in UK General Practice.

I have heard it stated that 1c) isn’t a requirement that many people need, so perhaps the use case just hasn’t been recognised yet.

2) is the case the Ed mentions. If there is no act relationship type of ‘probable cause’ then you can make a SNOMED code of that and use a statement relationship. My worry is that this is a very CFH specific mechanism. But maybe this is a case that an only be covered with such a construct, and if so it needs exploring further.

I am not troubled by the extension of the RIM. Indeed, as will be already clear, I believe that the RIM is urgently in need of a number of major extensions (for example in order to eliminate its current identification of a disease with its own observation). But I am still puzzled by the idea of a ‘Statement Relationship’ as ‘an Act that works as an Act Relationship’.

Is HL7 v3 Teachable After All?

I am pleased to have the opportunity to include in this blog a report of positive experiences with the HL7 v3, received from Marek Vaclavik, who writes:

… most of my colleagues disagreed on your learnability assessment of the HL7 v3 technology. Using HL7 v3 as a messaging standard does not require a profound knowledge of the HL7 Development Framework or the RIM itself. Our team are of the opinion that HL7 v3 can be learned with a reasonable amount time and effort invested. We consider a training program of one week, such as one we received from an external consultancy company, sufficient for the first contact with the whole topic. Focusing on the messages, the HL7 v3 technology is not more complex than any other XML based document format defined per XML-Schema. Errors in the documentation are, of course, annoying. But as far as we can tell, they are not more frequent or more severe than in other specification we get to see, such as vendor documentations. We would like to thank you for sharing the results of your work with us and hope to see you continuing it. Constructive criticism and open discussion are necessary prerequisities to make HL7 v3 a fully mature and broadly accepted piece of standard.

With kind regards

Marek Václavík,
InterComponentWare AG, Walldorf, Germany.

Comments on this and other postings are more than welcome. One immediate thought is that, to create HL7 V3 implementations, and indeed to teach HL7 V3, it is still necessary to understand (for example) the documentation of the RIM itself. And this, as HL7 leaders have agreed, leaves much to be desired in the way of understandability.

Diseases as Dependent Continuants

In a comment submitted to this blog, Dr William Goossen, researcher and consultant at Acquest Research, Development and Consulting in the Netherlands quotes from my remark in a ">previous posting to the effect that the RIM could effect considerable improvements by adding a new backbone class, called ‘Dependent Continuant’ since this would allow a coherent treatment of diseases, which could be classified under this heading, leaving observations of disease to be classified, properly, as Acts. The new class of Dependent Continuant could then include not only diseases but also qualities such as temperature, blood pressure, etc.

As Dr Goossen would have it:

Currently the comments refer to the RIM. However, the actual standards are based on the RIM and formed in the Domain Message Information Models (D-MIM). For example the Care Provision D-MIM. The structure suggested above is already in there. It is called clinical or care statements and it allows to express any observation and each observation can be linked to another, e.g. a disease (value pneumonia) can be visible through observations of temperature (e.g. value 39 degrees Celcius), breathing pattern (e.g. shorness of breath), x-ray (showing the pneumonia in the lungs) etc. The suggestion to have this additional class is therefore not necessary at all. This disease and its underlying observations on which the clinician has based his conclusion of "pneumonia" can further be linked to the treatment given and can be tracked in the care statement collector. In other words: what you ask for is already in the HL7 v3 standard, but the RIM is not the whole standard. You look at the wrong sections .

As Werner Ceusters points out, however, if Dr Goossen is right about the Care Provision D-MIM, then this is one more reason why the Dependent Continuant class should indeed by added to the RIM forthwith. This is because HL7 itself asserts that:

The Domain Message Information Model (D-MIM) is a subset of the RIM that includes a fully expanded set of class clones, attributes and relationships that are used to create messages for any particular domain.

If the D-MIM is a subset, then surely it cannot add anything.

It is however gratifying to see that, by the evidence of this D-MIM, HL7-ers working in the area of patient care have recognized that entities such as diseases, temperature qualities and the like, which exist longer than any observation, cannot themselves be identified as observations. They have thus created the notion of Condition, which they define as:

An observable finding or state that persists over time and tends to require intervention or management and is, therefore, distinguished from an observation made at a point in time.

This definition is in line with our proposal according to which a Condition (Dependent Continuant) is something out there on the side of the patient.

But there are problems with the definition nonetheless. First, there are presumably (for example in the very early stages of most every disease) Conditions at the molecular level which are not observable. Second there are Conditions – for instance a normal temperature, a normal blood pressure – which do not ‘tend to require intervention or management’.

Moreover, there are problems with the D-MIM documentation, for example when it asserts that ‘if a state or observation is used as a “reason” for intervention or management, it qualifies as a “Condition.”’ First, what if a state (e.g. of chronic depression) is not ‘used as a “reason” for intervention or management’ – is it then not a Condition? Second, must it not quite generally be the case that Conditions exist prior to any Acts in which they are used as reasons for intervention? Thirdly, we are told in the just-quoted passage that observations themselves can be instances of Condition (which means, given what we assume to be the rules governing the RIM’s backbone classes) that Conditions themselves would have to be accepted, after all, as a subtype of Act, which brings us back to the very same confusions with which we started.

Question, therefore, for Dr Goossens and the authors of this D-MIM: Is what has been added here truly a special kind of Act, called ‘Condition’? And if so, is it reasonable to identify, e.g. a chest pain in a patient as an Act? And if so, who is the agent of this Act?

HL7 RIM: Still an Incoherent Standard ?

The paper

• Barry Smith and Werner Ceusters “HL7 RIM: An Incoherent Standard” (MIE 2006), Studies in Health Technology and Informatics, vol. 124, 133–138

was presented at the Medical Informatics Europe conference in Maastricht on August 28. The powerpoint slides from the presentation are available here.

Gratifyingly, Gunther Schadow's talk at the conference embraced the view that the RIM should henceforth be a standard based on realist ontology. Thus biomolecules, he argued, should be treated not as Acts of observation (as is done currently by HL7's Clinical Genomics WG), but rather as Entities. We are hoping that the two conflicting views of biomolecules and similar items in RIM-based artifacts will now be reconciled in these terms, so that biomolecules (etc.) will henceforth always be classified under Entity, while acts of observation of biomolecules will be classified, straightforwardly, as Acts of observation.

We are hoping, in the same spirit, that the RIM will now add a new superclass of the Act class, which I propose should be called 'Event'. 'Act' could then henceforth be applied only to those Events which are intentional actions. This new superclass could be applied for example to snakebites, floods, fires, processes of infection, and other items hitherto problematic for the RIM. HL7 could then use Event, for the snakebite event, and Act of observation for: Act of observation of the snakebite event.

We are hoping, finally, that the new more realistic RIM will add a new, class called Dependent Continuant (for those continuant items which are not Entities because they are not made of physical parts). This would allow a coherent treatment of diseases, which could be classified by the RIM as Dependent Continuants, leaving observations of disease to be classified, again, under: Act of observation. The new class of Dependent Continuant could then include not only diseases but also qualities such as temperature, blood pressure, etc.

Adding the two new classes of Event and Dependent Continuant would thereby bring the RIM still closer to a realist ontology, and thereby yield a great boost in coherence. For reasons stated briefly in part 2 of this, and at greater length here, it would also add to the RIM's ability to support logical reasoning -- since items in reality would no longer be confused with observations.

Postscript (July 16, 2008)

I still see no evidence that the small proposed changes described in the above have even been considered by the wider HL7 community, in spite of the recognition by Gunther Schadow of the benefits that they would bring. On the other hand, further evidence of the problems created by the existing dual framework continues to accumulate. Is the RIM a representation of healthcare information or a representation of the healthcare entities about which such information is collected? From one side HL7' s answer to this question seems to be (in my view, absurdly): there is no difference. From another side, there is confusion and consternation, as illustrated by the following exchange:

From: Koisch, John [USA]
Sent: Wednesday, July 09, 2008 1:17 PM
To: arb
Subject: FW: Entity states and Roles

ArB,

An issue has emerged in the context of the NCI specification of a Person Service (a specification that the ArB is planning on using as an example of the type of specifications that would be produced as ballotable specifications). In the current RIM world view, the creation of Entity instances is fundamentally linked to instances of Registration Acts and refers only to the actual thing rather than an electronic representation of that thing. From a RIM perspective, this means that Entities essentially only exist in the context of Roles and ultimately in Acts The issue emerges when one considers the Entity state diagram and what it means in the context of a Registration Act, i.e. how the semantics of the Entity instances life cycle and the Registration Acts process semantics are partitioned across RIM structures vs the partitioning of the same semantics in a services world.

Please feel free to simply comment on the above statement. However, for context and in the desire to express things completely, there are some attachments. I have included two alternate state diagrams that Charlie and I proposed in the longish email thread between Charlie, Lloyd, Grahame, and myself. And apologies in advance for the lack of presentation of those threads ... there were too many to include and it is difficult to really pull them apart. However, a rough representation of the issues are below
....

Issue #1

Proposition a - There is _at least_ support for having an electronic record that is created but not in the active state

Proposition b - It is likely that there is actually a "pending" state in addition to the inactive and active states that are defined.

Reply - There is a big difference between a person's record (business conception) and the RIM.Person. RIM Persons (and other RIM.entities) essentially only ever exist in the "Active" state or the "Nullified" state.

Conclusion - there seems to be a fundamental disconnect between RIM.Entity, its states, and the way most IT people see entity. The disjoin is exacerbated by the RIM.Entity state machine that does not seem to refer to real entities (it does refer to their representations), even though the RIM uses RIM.Entity only as it pertains to real people. Lloyd maintains that the RIM.Entity cannot, in fact, contain any metadata about the person.

Issue #2

Proposition a - Entities need to be able to express their own state.

Proposition b - Entities need to be able to have states separate from the modeled RIM.Acts in which they are contained.

Reply - Lloyd maintains that RIM.Entity State is trivial (either null or active) and that at any rate, it is only valid to speak of entities in the context of an Act, say, a registration Act.

Rejoinder - But this is a fundamentally different notion than that maintained by most, if not all, of the IT community. And this does not translate to an architecture where systems are distributed.

Reply to the Rejoinder - Grahame holds that it may be that in a services world, a lot of the context that is held in the Act may exist in the service contract.

Conclusion - If Grahame is correct, then this still begs the question of what it means to be compliant to the RIM. Additionally, since services support unity of purpose and non-arbitrary virtualization boundaries, it also is worth asking why we need to create an entity using an "Act"? These are really two ways of asking the same question, though.

Comments welcome and encouraged.

John Koisch

From
http://lists.hl7.org/read/messages?id=93429
http://lists.hl7.org/read/messages?id=93162

More Problems in UK Health IT Implementation Efforts

What follows (dating from earlier in the year) has a new relevance given current financial problems with the UK's multi-billion pound Connecting for Health initiative

31 Jan 06 10:54 Failure of due diligence
The LSP contracts were granted in the expectation that P1R2 deployments would begin in December 2004. The contracts were awarded a year or less before this date. EMR's have a development lifecycle of many years. These contracts should not have been awarded on promises, but on working software. P1R2 required systems to transmit clinical data within HL7 Version 3 messages, encoded in SNOMED Terminology and the UK Drugs and Medicines Dictionary. It was manifest that >no< supplier had a working system using any of these. Three years later on it seems none had even performed an adequate impact analysis of switching to these standards. (Even the Johnny-come-lately PACS systems have patchy if any support of the relevant 'spine' standards). In the first two years of NPfIT, even relatively simple 'ADT' (admission, transfer and discharge) transactions using HL7 V3 have proven challenging to implement. Legacy systems will never use these, placing another burden on LSPs to set up and operate heterogeneous messaging infrastructures of inordinate complexity. Contrary to popular belief, SNOMED was never going to drop effortlessly into the ICD-9 'slot' in existing systems. Meanwhile moving to the Drugs and Medicines Dictionary requires fundamental retooling of electronic drug formularies and systems using them. It is also fair to say that HL7 V3, SNOMED and DM+D remain, even now, immature as standards and a 'moving target' for LSP's and suppliers. All the above was known back in 2002-3, understood and documented by hundreds of people in the NHS, system suppliers and informatics community. (post edited by EHI)

31 Jan 06 12:50 What "standards"?
Why are SNOMED CT and the dm+d "immature" and in what sense are they "standards? Looking at the ISB web site, it appears that they have only got to the first hurdle in the standards approval process. It must be almost 7 years now since the SNOMED and Read merger began, a long time even by comparison with the much-maligned Read Codes version 3 project of the mid 1990s in which so many of us clinicians participated. As far as I can see, the issue is with the specification of HL7 v3, SNOMED CT etc as standards for CfH systems in the first place, when they appear not to have reached a stage of testing when their suitability could be confirmed. Let's not forget that the NAO report into the Read Codes showed how difficult developing new clinical codes could be. If the "moving target" of evolving standards is a significant factor in CfH delays, the perhaps it's time to revisit the so-called standards that are being specificed.

02 Feb 06 23:02 HL7 V3 standard
One of the problems with HL7 V3 'standard' is that is was 'farmed' out to the HL7 organisation by the NHS. This is a body of experts who are amateurs ,in the sense that they have 'day jobs' as well. Members of the HL7 organisation attend the meetings but very few, if any, members derive their main income from developing HL7 standards. The 'standards' are voted on by the members and such a process, is long winded and often seems to result in the lowest common denominator as a 'standard' i.e there is no weighting of votes for the expertise of the participant. As HL7 V3 messages are the basis for communications in the new NHS I would have thought it a good idea to get the messaging standardised and working before the s/w systems which depend on the messaging were developed. Then the systems would have been built on a firm foundation. Disasters I fear may be imminent.

08 Feb 06 16:18 SCRAP HL7
RE:"As HL7 V3 messages are the basis for communications in the new NHS I would have thought it a good idea to get the messaging standardised and working before the s/w systems which depend on the messaging were developed. ......." Better never than late. As anyone who is competent in IT messaging knows, If you want to send a message, just send the message. There is no justification for "translation" into a "messaging format" such as HL7, XML, EDIFACT et al. The scrapping of HL7 at this stage would have the advantage of reducing costs and timescales.

08 Feb 06 19:46 HL7 shoots itself in the foot
One of the main troubles with HL7 is that from a practical point of view, it goes out on a limb and is idiosyncratic. The basic metamodel is in UML - lots of people understand UML- it rapidly becoming an IT standard worldwide. So far so good. To produce messages however HL7 V3 goes it's own way. It devises it's own modelling methodology and representation - using MS Visio. It does not even use UML and all the HL7 'symbols' are color coded. Bad luck if you don't have a color printer or are color blind !!! Plus the, would be user/practitioner, must learn a completely new 'symbolology' which is only used by HL7 V3. There is thus a heavy learning curve, and who wants to learn an esoteric modelling language which is only used in the context of HL7 ? Having built your model you then process the Visio 'model' programmatically to produce the XML schema. It is not clear what the precise rules are for this transformation, but much of it seems to produce unnecessarily complex XML. The reliance on Visio and their own modelling symbols renders HL7 V3 unusable in the standard modelling tools for UML, which are well tried and trusted. If anyone had set out to complicate the description and generation of XML messages one couldn't do better than the HL7 V3 committee. They really have shot themselves and others in the foot. The trouble is, that if we continue in this fashion, the taxpayer will not be the only one to suffer.

From http://www.e-health-insider.com/news/item.cfm?ID=1670

Problems in UK Health IT Implementation Efforts

http://www.e-health-insider.com/news/item.cfm?ID=1670

provides an interesting perspective on difficulties currently being faced by the National Programme for IT in the UK National Health Service, which has invested huge resources in the creation of a new national health IT system based on HL7 V3 messaging before the V3 standard itself has been properly tested (or indeed properly implemented).

HL7 V3: In search of implementations

Oracle, familiarly, has embraced HL7 V3 as the central part of its Healthcare Transaction Base (HTB). Oracle itself refers to three implementations of HTB described as being 'live for EHR projects':

1) Byrraju Foundation (BSRF) in India (Live)
2) Stockholm County (planned to go live by May 2006)
3) Louisiana (planned to go live by May 2006)

Regarding the Byrraju case, I am told that there is no V3 application running in India today and that the Byrraju Foundation is presently not using any telemedicine application that utilizes HL7.

As to the Stockholm case, the HTB was purchased and deployed in late 2004. An attempt to port a pilot system was made during the spring of 2005. This attept was abandoned, as I understand from my Swedish colleagues, partly because of poor performance (the new application performed significantly less well than the system it was designed to replace, even though it was being run on considerably more expensive hardware), and partly because of a lack of fault tolerance, which made it inadequate as a mechanism for integrating legacy systems marked by a high degree of variation in data quality. During the spring of 2006, it seems, an attempt will be made to construct a new pilot application, this time with the more modest goal of handling referrals.

I have not, as yet, been able to find information concerning the Louisiana case.

Is there a difference between a person and a door?

In the paper "HL7 RIM: An Incoherent Standard" the RIM is criticized for failing to draw a clear distinction between entities in reality (patients, diseases, treatment acts, ...) and the records of such entities, for example in paper documents.

Mead Walker reacts to this criticism in an email as follows:

The paper puts a lot of effort into discussing HL7's mixing of what you call its "information model" with its "reference ontology". I agree that these are distinct concepts, and that HL7 tends to switch from one to another without warning. However, I do not believe the paper substantiates why this is a problem. I think that is its major flaw. It is almost as if you think the seriousness of the defect is self evident, but it is not. Perhaps, this is an omission that only a philosopher would make. Let me use an analogy. You can look at me to see if I have a mustache; you can also look at a mirror image of my face or at a photograph. In either case, the fact that I do have a mustache is evident, and the question of whether you know that by looking at me, or by looking at the picture is normally trivial. Why do you think it is important to know if the knowledge that is being transmitted comes from the thing itself, or from its representation? ... Isn't this simply a fundamental philosophic conundrum that really is not practically important?

My response was as follows:

Dear Mead,
You are right that this is, for me, a self-evident defect. You are right, too, that it sometimes does not matter where you get your knowledge of mustaches fr0m (though it might, e.g. for forensic purposes; and I would imagine that if you are building a messaging standard then these are precisely the sorts of purposes you should be bearing in mind). The main issue, though, relates to the question not of how we know but of what sorts of things our knowledge is about.

If I told you that your messaging standard cannot distinguish reliably between, say, a human being and a door, then you would rightly be troubled.

Why are you not similarly troubled if I tell you that your messaging standard cannot distinguish reliably between a human being and a social security number?

Or between an actual real-world case of cardiac arrest and the information content of a cardiac unit resuscitation note?

Or between John's elevated blood pressure (which endured for several hours) and the information recorded during an action of measuring this blood pressure at 4.07 pm?

Surely it is a serious problem when one does not know what basic categories of entity one is dealing with, so that one confuses real-world phenomena (which might make you sick) with information captured during the observation of such phenomena which sits inside computers. This latter distinction is, for me, as self-evident as the distinction between a real-life performance of Tosca and the musical score you might buy in a music shop.

But, you might still say, is the distinction of genuinely practical importance? Well, consider blood pressure:

On the one hand there is your blood pressure itself, the real-world phenomenon which obeys the laws described in a medical textbook (which will tell you about systemic arterial pressure, about systolic and diastolic phases, about fluid dynamics, etc., etc. complicated physics and physiology that will be of practical importance e.g. when designing an instrument that can accurately measure blood pressure or when dealing with a patient who has atrial fibrillation). On the other hand there is a blood pressure observation, another real-world phenomenon, but of an entirely different sort, involving factors such as:

• the position of the patient at the time of measuring (sitting, lying, etc.),
• the tilt of the surface on which the person is lying,
• the variation in measured blood pressure with respiration,
• the instrument used to measure the blood pressure,
• the size of the cuff if a sphygmomanometer is used,

and so forth, as well as the units in which measurements are taken. (One detailed representation of these factors is here.)

Note that blood pressure itself (including the sort of elevated blood pressure that can kill you) exists entirely independently of instruments or units of measure or acts of observation. Blood pressure itself exists as an endurant feature of the organism from one hour or day to the next (constantly rising and falling even while preserving its identity). A blood pressure observation, in contrast, is a process, which does not endure through time but rather unfolds through time in successive temporal phases. (See here.) Thus the features of the former are quite different from the features of the latter, as different as, say, a potato and the act of eating a potato.

Consider, now, for further evidence of the practical significance of this distinction, that there are some words (e.g. 'systolic') which appear both in textbook descriptions of blood pressure itself and in records of acts of observation. Sadly, even leading experts in medical terminology are often misled by this fact. For the two sets of occurrences of the same term refer to entities in reality which are of an entirely different sort. Descriptions of the first kind would be appropriate to ontologies of pathology (of the what it is on the side of the patient) such as we might hope to find in SNOMED-CT; descriptions of the second kind would be appropriate to message descriptions such as we might hope to find in HL7.

Is there anything positive to be said about HL7 V3 ?

Anonymous said...

Have you found any positive points about HL7 V3. You seem to be sitting on the "anti HL7" side of the fence? Which current standards do you think would be a better choice for messaging and EHRs?

2/13/2006 12:22 PM

Barry Smith said...

I think we can probably leave it to the HL7's own marketing arm to document positive features of HL7 V3.

I think also that, in the age of internet services, it is becoming increasingly unclear whether the technology of messaging standards is needed at all. But even leaving this aside, HL7 V2 is a reasonably good messaging standard for its scope (mainly pathology results and imaging), and it is ten times simpler than HL7 V3 and already quite widely implemented. Where, then, is the business case for Version 3?

As to the Electronic Health Record, we must bear in mind that HL7 itself does not in fact have an EHR solution. And I am tempted to say that more or less anything that has been designed in response to EHR requirements would represent an improvement on something which does not exist.