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.

HL7 Launches Marketing Effort for Katrina Relief

Thomas Beale points to this press release:

HL7 Launches eHealth Effort for Katrina Relief
HL7 standards make an impact on the ground in the wake of Hurricane Katrina

as an illustration of how HL7 people say different things to different people to suit their political/marketing purposes. Are HL7 standards making an impact on the ground in Louisiana? Or rather just members of HL7 wearing other sorts of hats?:

"This press release is hardly responsible or ethical representation of a supposed standards body.

"A similarly exaggerated claim is contained in the HIMSS announcement (see extracts below) which starts with the statement:

• Health Level Seven’s Version 3 Normative Edition 2005 standards, dubbed The Foundation of Healthcare Interoperability, have been made available on ...
  

"Here, HL7 is claiming that its specifications are the basis of healthcare interoperability. That's a pretty big claim for an organisation that doesn't know much about EHRs, has only just started doing service models in the last year or so, and made its v3 message offering so complicated that almost no-one can understand it – and which somehow managed to ignore all of the previous health standards work in Corbamed, CEN, UN/CEFACT, and work in GEHR, PICNIC, openEHR, and also managed to ignore basic norms of object-oriented modelling!

"Further down in the same announcement, HL7 is claimed to have provided the standards for workflow, documentation and security in health:

• Since its inception in 1987, HL7 has worked to address the unique needs of the healthcare IT industry by developing a variety of pioneering standards ­ from messaging to documentation to security to workflow.

"None of the HL7 specifications that I know of contains anything to do with the large amount of workflow research available today; certainly there is little workflow thinking in the RIM or RMIMs (an exception being the state model of Acts). There are various doctoral theses and projects around the world which have treated the problem of workflow in healthcare directly, yet none of this work is used in HL7 to my knowledge. I guess the existence of CDA is the basis of the claim that HL7 has pioneered standards in documentation, even though projects like GEHR, CEN and openEHR have been working in this sphere for years using object-oriented models rather than just XML schemas. I don't know of any HL7 standard to do with security.

"I can only take these kinds of claims (especially intermingled with a menu of prices for buying sponsoring opportunities) as marketing, not connected with reality.

"HL7 speaks with a forked tongue also when it comes to the issue of its support for or use of specific software systems. On the one hand it maintains the official position that it is agnostic with regard to software (to preserve compatibility with different systems or when systems change). When it suits them, however, they make repeated claims to the effect that they have the standards for the "foundation of healthcare interoperability" and the like.

"They have tried very hard to make their unpopular (even within HL7) data type model an ISO standard for data types in health computing. This attempt has temporarily been blocked by members of CEN TC/251 and others in 2005, on the basis of unsuitability. I wouldn't even mind if the world standard for clinical data types came from HL7 – if it were any good – but their models are close to unimplementable, as many users of the XML-ITS have discovered. In any case, the numerous objections in principle should be enough to stop them being used for software or standards.

"To see the problems, consider this simple example: to record observations properly, you need to be able to record:

– a history of events, since observations are in past time, and multiple samples are often taken

– the data at each timepoint, which may be structurally complex, as in the case of Apgar, microbiology, BP etc

– the state of the patient at given times, which is often needed to correctly interpret the data (e.g. was the patient lying in bed or standing when the BP was taken?)

– the protocol/method of performing the observation (e.g. instrumentation used).

"So, in the openEHR model of Observation you will find all of these things (see here, entry section and the data structures supporting this model here).

"None of these requirements are particular to the EHR. Whether you are making an observation in a laboratory, in a doctor's surgery, or at home, they would all apply; they also apply regardless of how and where the data are being stored. These requirements are not specific to the EHR, only to the scientific process of clinical investigation.

"I challenge anyone to show where such requirements are clearly met in the HL7 models.

"I think something has to be done about HL7's marketing arm – it seems to be getting out of control. Should standards bodies even have marketing arms?

regards,

Thomas"

-----------
*Since its inception in 1987, HL7 has worked to address the unique needs of the healthcare IT industry by developing a variety of pioneering standards ­ from messaging to documentation to security to workflow.*

*Today, we proudly invite you to join us in the HL7 exhibit at the Healthcare Information and Management Systems Society (HIMSS) 2006 Annual Conference and Exhibition.*

*Come be a part of this exciting opportunity as we educate the industry about HL7 and its role in the NHIN, and bring vendors and providers together to showcase how HL7 standards are used to provide real-life solutions every day in care-giving settings across the country.*

*Applications are now being accepted for participation in the Health Level Seven (HL7) HIMSS 2006 Exhibit.*

Go to to see all the ways your organization can partner with HL7 at HIMSS 2006 and tell your HL7 story to HIMSS attendees. Or contact Jonathan Himlin at 734-677-7777 x165 / jhimlin@HL7.org to inquire further.

*Sponsorship Opportunities*

Whether or not you’re participating in the Provider Solutions Showcase, sponsoring an element of the HL7 2006 HIMSS Exhibit is a fantastic way to partner your company and its brand with the preeminent healthcare information technology standards development organization in the U.S. and abroad. Choose from among the following sponsorship opportunities:

*SOLD **HL7 Educational Theater - $10,000*

*SOLD* *HL7 Provider Solutions Showcase - $10,000*

*HL7 HIMSS Exhibit Brochure - $5,000 (ONE AVAILABLE)*

*General Exhibit Sponsorship - $3,000 (AVAILABLE ­ NO LIMIT)*

*Individual HL7 Educational Session Sponsorship - $1,000 (AVAILABLE)*

HL7 V3 dubbed "The Foundation of Healthcare Interoperability"

Health Level Seven’s Version 3 Normative Edition 2005 standards have been made available in the Members' Area of www.HL7.org. They are dubbed "The Foundation of Healthcare Interoperability". The HL7 RIM, in particular, is asserted to be a critical component of the V3 development process.

"The rules require that all information structures in derived models be traceable back to the RIM and that their semantic and related business rules not conflict with those specified in the RIM. The RIM therefore is the ultimate source for all information content in HL7 V3 standards." It is the "root of all information models and structures developed as part of the V3 development process", including those information models and structures in areas such as Clinical Genomics.

On the other hand the RIM contains definitions such as the following:

Living Subject: A subtype of Entity representing an organism or complex animal, alive or not.

Animal: A subtype of Living Subject representing any animal-of-interest to the Personnel Management domain.

Person: A subtype of Living Subject representing single human being [sic] who, in the context of the Personnel Management domain, must also be uniquely identifiable through one or more legal documents (e.g. Driver’s License, Birth Certificate, etc.).

[It seems that in the latest version of the RIM documentation the last two definitions have been removed; however they survive in the HL7 Glossary.]

This leads immediately to the question whether the biology which is incorporated in the RIM is able to bear the load which has been placed upon it. It may also lead to some scepticism concerning the process of design-by-ballot which led to these and similarly questionable outcomes.

The following piece of nonsense suggests also that the authors of the RIM have problems with understanding what is meant by 'definition':

QueryBySelection: This class contains the definition of a Query by Selection. This is an HL7 query in which a request can specify any or all of the variables offered by a data server and may additionally specify any permissible operators and values for each variable as published in a query conformance statement. This query format is considered an open query because it allows a selection specification against a published data base schema.

Here the definiens is asserted to be 'contained in' the definiendum. (As if one were to formulate a definition of number by writing: 'a number contains the definition of a number'.)

The second sentence contains a dangling anaphora (what does 'this' refer to?) In addition, it identifies the entire class which is to be defined with one of its instances.

The third sentence confuses 'query format' with 'query', and contains the vague expression 'is considered is'. (Compare 'an even number is considered as a number that is divisible by 2'.)

HL7 and Object Oriented Programming

In the HL7 V3 Introduction/Backbone document (Published 12/30/2004) it is claimed that:

"HL7 V3 adopts an Object Oriented (OO) approach using Unified Modeling Language (UML) principles. HL7 employs a completely new development approach with V3. HL7 V3 uses an OO approach that is model and repository-based. This OO approach is supported with trained facilitators, formal education classes, and computerized tools. This approach leads to increased detail, clarity and precision of the specification and finer granularity in the ultimate message. This helps functional committees meet the challenges of de novo interface design, and increases functional breadth and evolution of assumptions. It helps new members become productive in fewer meetings. This is an enormous aid to providing institutional memory and sharing work in progress across committees and to the membership at large. "

We know of only one peer-reviewed publication addressing the degree to which HL7 V3, does in fact correspond to OO modeling principles. This is:

Eduardo Fernandez and Tami Sorgente, "An analysis of modeling flaws in HL7 and JAHIS", Proceedings of the 2005 ACM symposium on Applied Computing, Santa Fe, New Mexico, 2005, pp. 216 - 223

whose authors (F&S) assert:

"Instead of using the Unified Modeling Language (UML), the standard notation for object-oriented software development, these two organizations (HL7 and JAHIS) have developed specialized object-oriented models. This has resulted in languages which are incompatible with the current use of UML. The consequences of this choice are the loss of the possible use of a large variety of existing models and patterns. What is worse, it will be difficult to add security specifications in their models, a critical aspect in the electronic interchange of medical records. We discuss here the shortcomings of HL7 and JAHIS as modeling languages and as languages in which to add security specifications."

"HL7 is complex and designed for implementation, not for conceptual modeling. We show below some of the sources of complexity. Although the designers deny having a software orientation, it is clear that the model contains artifacts normally used in the design stage of software systems. A measure of their complexity is that their documentation is hard to understand."

Specific problems identified by F&S can be summarized as follows:

1. Because of its ad hoc variation of UML, HL7 V3 becomes incompatible with the conceptual models already developed for medical systems.
   
   
2. V3 has an explicit concept of entity, which is not appropriate for a UML conceptual model, where everything is an entity; thus adding an entity class does not add anything to the semantics of the model. The class is present in V3 because 'entity' is there used, idiosyncratically to mean entities of a specific type (people, places, organizations, ...).
   
   
3. V3 treats associations in an idiosyncratic way, giving them no name and no semantic value, and placing their semantics in a separate class. UML associations have semantic value and association classes can be used to add details to links.
   
   
4. In V3 states are hidden as mood codes: UML uses state diagrams to describe the stages in the lifecycle of an object. In HL7 these stages are implicitly encoded using mood codes. This precludes any analysis of state correctness and correlation with sequence (scenario) diagrams.
   
   
5. V3 is cumbersome and inefficient: As a result of its misuse of associations the models are unnecessarily complex. Models that in UML take a few classes and associations require a much larger number of classes in HL7 V3.
   
   
6. V3 uses arbitrary software-dictated names to distinguish the different types of classes in their model and these classes, e.g. by using a prefix letter, as in 'P_patient', to indicate a class of type Participation. In this way the benefits of compositionality are lost. The same effect can be achieved much more naturally in UML by using stereotypes, e.g., of the form '[Participation] Patient', which allow easy extension to new cases, so that one does not need to predefine all the class names one will need from the very start.
   
   
7. Loss of the possibility of using security patterns and models: Given the importance of security when medical records are fully computerized and exchanged through the Internet, this may be V3's most serious flaw.

As F&S point out,

"Some of these deficiencies were already noted by Mead (see C. Mead, "HL7: Challenges, Benefits, and Applications", HL7 UK, December 2003), who said that the following may be true about HL7:

HL7 has assembled a considerable amount of process and number of artifacts without too much concern to UML. [F&S: Exactly, they invented their own notation.]

HL7 is not (in general) interested in software systems. [F&S: While they do use software-oriented aspects in the model, their approach does not follow the rules of software engineering.]

HL7 does not have extensive internal modeling/UML expertise. [F&S: Clearly]"

List of Problem Areas

A more precise specification of areas of focus reads as follows:

• problems of documentation in relation to the factors of intelligibility by the human beings who must create software and refined messages and domain information models on its basis;
  
  
• the steep learning curve: does HL7 V3 have the ability of to be taught and therefore engaged with, and used (evidence so far in this category is that it is highly problematic, and the perceived complexity is a major barrier to engagement and easy use)?
  
  
• problems of implementation: the decision by HL7 to adopt the new RIM-based methodology was adopted already in 1997, and versions of the RIM were available already in 1999; why, after six years of effort, and considerable investment, is it so difficult to name even one successful large-scale implementation of V3?
  
  
• problems of quality of the HL7v3 artifacts and methods in terms of whether they convey intended (or even sensible) meanings and can be used with well-designed ontologies for functions like computerised decision support (and in general for the sorts of sophisticated tasks which will increasingly become necessary with the advance of genomics-based biomedical (informatics) research);
  
  
• external problems concerning the relationship of the HL7 V3 corpus to the outside world; is the very methodology of HL7 V3 appropriate to the world as it is today, with increasing migration towards web-based technology?
  
  
• problems of internal consistency of the HL7 RIM from an ontological point of view: for while the RIM is presented officially as an information model (so that the instances of its classes would be information/data items), its documentation is formulated in such a way that the examples given are in very many cases examples not of information about real objects / processes but of these real objects / processes themselves;
  
  
• software problems, for example concerning the degree to which shortfalls in consistency and clarity of documentation may lead to the further problem of message and software developers creating incompatible / buggy / unworkable solutions; is HL7 V3 able to support the economic production of maintainable, reusable and extendible software?
  
  
• functional problems concerning the fitness of v3 for its claimed purposes (messaging and apparently EHR and decision support at least); here we will attempt a comparison of what v3 actually offers with current requirements in the various functional areas of the health computing platform -- to what degree is V3 appropriate for satisfying well-known requirenments in clinical informatics?
  
  
• technical probems concerning the quality of HL7v3 with respect to accepted practice in information modelling, object-orientation, software engineering and data management. Items in this category talk about whether v3 supports the construction of good quality, re-usable software, integration into modern computing infrastructures and development environments;
  
  
• problems of usability of the V3 domain models (RMIMs etc) by specialists in the corresponding domains, and problems relating to the ability of clinical and other domain specialists to engage directly, given the specific methodology of HL7 V3 for producing new specialized information models for each new domain, models which differ in unanticipatable ways from the RIM which serves as their starting point;
  
  
• problems of appropriateness: to what degree is HL7 V3 specifically appropriate to the US case and to what degree can it be applied in other countries, where issues of third party invoicing play a less central role?
  
  
• terminology problems relating to the ability of HL7 V3 to integrate properly with clinical terminologies such as SNOMED CT;
  
  
• problems with the HL7 business model: is there some conflict of interest involved in the fact that those, such as consultants, who stand to benefit from overly complex standards or unclearly formulated documentation (and from the fact that documentation is not publicly available for peer review by the wider community), are also involved in the balloting process which determines what the standards and documentation should be?
  
  
• problems with HL7 governance processes: decisions on modifications to HL7 standards are based on a balloting procedure involving a number of distinct constituencies, which means that any change must be slow, and this may be problematic in an age of rapid technological change; are those members of the relevant constituencies working with new technologies able to influence the development of HL7 V3 in a timely fashion?
  

Misleading Claims regarding HL7 V3

As an example under the heading "problems with HL7 V3", consider the following claim,

• HL7 V3 is the standard of choice for countries and their initiatives to create national EHR and EHR data exchange standards as it provides a level of semantic interoperability unavailable with previous versions and other standards. Significant V3 national implementations exist in many countries, e.g. in the UK (e.g. the English NHS), the Netherlands, Canada, Mexico, Germany and Croatia. Within the US, jurisdictional agencies needing support for large scale integration (e.g. CDC, FDA) have adopted V3.

from a 'white paper' issued by a group of European messaging experts in November 2005. Again, we believe that the claim that there exist 'significant V3 national implementations' is at best misleading. The NHS is certainly attempting a national implementation of V3 in the United Kingdom, though this is for the purposes of messaging (for which HL7 was of course originally designed) not as a 'national EHR ... standard'. Even in regard to the fulfilment of these purposes, moreover, the NHS is confronting considerable difficulties in implementing V3.

We are sceptical that there are significant 'national implementations' of V3 which would justify the claim that it is the EHR 'standard of choice' in the other countries mentioned. In particular, none of the countries mentioned is using the "functional specifications" for EHR under development within the V3 framework (which may have something to do with the fact that the specifications in question were designed with the rather special case of the USA in mind).

Misleading Claims regarding HL7 and EHR

As an example under the heading "HL7 and EHR", consider the document entitled "HL7 EHR System Functional Model and Standard: Draft Standard for Trial Use" (see also the revised version here). This document does not, in spite of its title, contain a functional model for an EHR system. Rather, it is merely specification of requirements - a profile of what would be needed to create such a functional model.

To call something a "model" is to suggest that it belongs on the solution side of the fence, rather than on the side of problem description, which is where these functional specifications belong. There is nothing in these specifications which provides information about how an EHR system could be built, only information about what it might be required to do, in the specific US-case.

In fact, the main intention of this work was not as requirements for building systems – for this more technical requirements are needed, like ISO 18308. Rather it is intended as a checklist for system procurers to determine whether a given product satisfied some particular functional profile. It was designed as a way of a) comparing systems and b) determining system compliance.

We suspect, however, that the very title of the mentioned document has led to misleading assumptions. Thus the US Department of Health and Human Services (HHS) published a report on national health IT developments in 2004 containing the statement that:

• "With HHS participation, HL7 has also created a functional model and standards for electronic health records."

We would be pleased to see HL7's "standard for electronic health records".

The Australia HealthConnect Clinical Information Project (CIP) considered the RIM in a report which came to the following conclusions [3]:

adopting HL7 RIM as a foundation for representing all HealthConnect EHR concepts will:

• Significantly increase the complexity of concept representation;
  
  
• Entail considerable burden upon HealthConnect staff to map clinical concepts to the RIM;

and

• Likely lead to confusion in communication with HealthConnect stakeholders who are not well versed in HL7 concepts and methodologies.

HealthConnect (Australia). Clinical Information Project Phase 1 Report, PART A Stream 1: Clinical Information Framework. 2004.

Areas of Focus

We shall concentrate especially on two areas:

1. HL7 and the Electronic Health Record

2. HL7 Version 3 and its problems regarding

• intellectual coherence

• ability to support software

Rationale

HL7 (Health Level 7) is a standard for healthcare-specific data exchange between computer applications.

Considerable resources are being invested in the HL7 project by governments and industry as part of national health IT projects with expenditures running into the billions of dollars.

Many claims are made on behalf of HL7 by its advocates. The goal of this blog is to investigate the merits of these claims, and to provide some needed independent perspective on the HL7 project.