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.