BFO vs. HL7 RIM

Basic Formal Ontology is increasingly being used as a tool to foster semantic interoperability of data resources in the biomedical domain, and experiments are now being initiated at the fringes of the HL7 world to examine the potential benefits of BFO over the RIM as backbone ontology framework for HL7. The RIM, familiarly, recognizes only two upper-level categories, of Act and Entity. Since diseases, drug interactions, pains, ruptures, hemorrhages, fractures, and so forth, are not Entities, the RIM categorizes all of them as Acts. BFO, in contrast, has a more resourceful set of upper-level categories, including:

• Independent Continuants (roughly corresponding to HL7 Entity)
• Dependent Continuant (missing from HL7)
• Occurrents (of which HL7 Act would form a subclass, alongside those occurrents which are not Acts, such as parasomnias, involuntary muscle contractions, erosion of teeth due to persistent vomiting, and so forth)

Reasonably, the question is now being raised by some in the HL7 community, as to whether new problems would be created through the use of BFO in place of the RIM. In this connection, Cecil B. Lynch has raised an objection to the effect that, as he sees it,

BFO has shortcomings for representing medical information at the granular level. Like many philosophy based upper ontologies, it suffers from defining accidental properties when they are not. This leads to issues in maturation of organisms through development cycles such as parasites go through and leads to erroneous classifications.

Cecil agreed to formulate his concerns in relation to a concrete case, in which John, a person on rotation living in the Congo, has a blood test drawn that shows sporozoites on the smear. The challenge for BFO is then to answer the following questions:

1. How does BFO deal with the question whether John has malaria when there are sporozoites detected on his blood smear?
2. How can BFO be used to classify an immature life form as a cause of a disease when the causative agent develops internally to the organism and changes its stage of life?

Werner Ceusters and I have sought to address these challenges here, and responses from the HL7 community are welcome. At the same time we have issued to Cecil, and through him to all afficionados of the RIM, an analogous challenge:

1. How does HL7 RIM deal with the question whether John has malaria when there are sporozoites detected on his blood smear?
2. How can HL7 RIM be used to classify an immature life form as a cause of a disease when the causative agent develops internally to the organism and changes its stage of life?

Responses to this challenge can be submitted as comments to this posting, or by email to phismith@buffalo.edu. All responses will be published here.

Update November 16, 2009:
Response from Prof. Christos (Kitsos) Louis (IMBB-FORTH / Department of Biology, University of Crete)

Overall, I think that this is a very nice idea in order to prove that BFO is indeed a powerful tool. I really liked it. But...

1) Diagnosis of malaria is extremely easy, so why make a doctor “think” first, when the only thing he has to do is a blood smear? The only possibility of mis-diagnosis is for MDs in the North who may simply not think of the disease. Also, in the opposite case cited in the abstract, if malaria is asymptomatic for whatever reason, this usually happens only in hyperendemic areas (almost exclusively the tropics) and it is of no clinical or epidemiological importance other than on a purely academic level. If, on the other hand, the audience is specialists of medical informatics (the emphasis is on informatics, i.e. people who for whatever reason don’t “like” BFO), my guess is that after taking care of the stuff below, this could certainly have positive consequences in terms of a potential global acceptance of BFO.

2) The biology of the disease and medical/diagnostic consequences: Sporozoites, as you mention in the intro, are very “short lived” in the blood. Also, due to their very low number (malaria can be caused even by one sporozoite!), they are almost impossible to detect in the blood (see wrong sentence in second paragraph of Methods)! Thus, they play zero role in the diagnostic process (and diagnosis) of malaria, which is initiated only after the first or second bout of fever. This happens days after the infectious mosquito bite and certainly not within 30 minutes. As a matter of fact, even if one rich tourist were bitten close to a hospital/clinic one would not find a single doctor willing to do a “smear” because it would be completely useless. Thus, although indeed true, anything that lies between ID#3 and right after ID#10 is absolutely irrelevant in terms of diagnosis. Furthermore, Table 3 is not only simplified but oversimplified. Malaria (disease, disposition, whatever), unless we talk about a relapse or a medically-induced one, has to start with an infectious mosquito bite, thus somehow I feel that this should be somehow be mentioned between IDs #2 and #3. Moreover, one of the crucial aspects of malaria is the recurrence of fever attacks the first of which is the one that starts the disease from the point of view of pathology. These recurring fevers make up the crucial feature that routinely leads doctors to either diagnose it as malaria or initiate the relevant diagnostic procedures. Therefore, I think that the recurring fevers should somehow find their way to Table 3. Concluding this part, I would rewrite the whole thing “starting” from the diagnostically and clinically relevant point, which is the presence of blood-stages (several kinds, and in no way called “mature”) in the peripheral blood.

3) Other comments:
i) The existence of “surviving liver stages”, i.e. hypnozoites, can only be inferred a posteriori. This may be crucial in the definition of disease (see penultimate sentence of the Discussion). Would one talk about disease solely because there may or may not be a few hypnozoites present in a few liver cells, that may or may not ever wake up?

ii) I have a big problem with Stedman’s definitions, as these first, exclude autoimmune diseases or second, are cyclical: D3 defines, among others, a disease as being a disorder while D5 says that a disorder may result from a disease! I would therefore prefer to concentrate entirely on either CDC definitions or WHO.

iii) The title’s second part is completely misleading. There is nothing about the Plasmodium life cycle here, as only part (and only part) of the vertebrate component of the life cycle is “discussed”

iv) You state “...or have no physiological counterpart at all (e.g. inflammation).” Given that inflammation is a normal response of the human body, I have certain doubts whether this should not also be “physiological” similar to the hyperventilation stated immediately before that.

Can Microsoft Healthvault Do a Better Job than HL7?

Part II of the Wolandscat series on "The Crisis in E-Health Standards" continues the argument of Part I, discussed already here, to the effect that software engineers should be the ones engaged in building e-Health standards -- and not (for example) quasi-governmental committees involving members with 'limited engineering skills' and utilizing a methodology based on democratic votes. The task, as should by now be clear, is orders of magnitude too complex to be left to committees and to committee votes.

But there is a worry which arises in connection with this general strategy, which is that software engineers -- even when given all the resources they need, and even when walled off from committee interference and popularity contests -- often seem to produce work that is affected by the very same confusions about which Wolandscat himself is complaining. Consider, for instance, the Microsoft Healthvault list of Health Item Types, which informs us that:

Allergic Episode is an occurrence of an allergy which is defined by the Allergy type.symptoms

At the same time we are told that Allergic Episode inherits Health Record Item, where the latter is defined as:

A single piece of data in a health record that is accessible through the HealthVault service.

Is 'Allergic Episode' so defined really a good name for something that is (a) a single piece of data, that is (b) in a health record that is (c) accessible through Microsoft Healthvault?

Further examples of Health Record Items provided by Microsoft include: a blood pressure measurement, an exercise session, or an insurance claim. But is a blood pressure measurement or an insurance claim or an exercise session truly a good example of a 'single piece of data'? Are any of these things data at all?

A potentially even more serious problem for Microsoft turns on the fact that the definitions offered on this page by its engineers are static programming class definitions -- suggesting that their authors think that they can create a representation of the medical domain by means of a monotonically growing set of classes deployed in software. But medicine is constantly changing in polydirectional ways, and software conceived along the given lines will be so sensitive to such changes that it will require constant maintenance, re-testing and re-deployment.

If, therefore, much HL7 standards-building offers evidence of a lack of overarching software infrastructure that could make the standard work in any kind of serious deployment, so the Microsoft material on the Healthvault pages is evidence of an equal and opposite lack of understanding of the domains within which such deployment would need to take place (vast and changing content; complex semantics).

As I am sure Wolandscat would agree, the real need, if we are to get all the separate pieces of this gigantic puzzle to work together, has to be an organisation that is something like a mini-university, or a cross between a university and a company (to avoid becoming detached from reality) involving at least: ontologists, software engineers, medical domain experts, and persons with experience of and a track-record of success in implementing and brutally testing healthcare IT systems in real-world environments. The organisation should have cross-disciplinary mechanisms that force each kind of person involved to understand the outputs and meaning of the others' work. And this work should be implemented in tools -- not just in its vision -- and subject to rigorous real-world testing in advance of any eventual release in the form of 'standards'.

Should an Organization like HL7 be Engaged in Building Standards?

A nice summary of problems with current approaches to standards development in the eHealth domain is presented here.

The author begins by pointing to the long-standing assumption

that we should rely on official standards bodies to standardise things, and indeed, our entire modern civilisation does rely on this. From the thickness of car-window glass (look carefully for the standards mark etched into the window next to you get in your car) to power voltage and frequency, to mobile phone and internet communication standards, the sanity of our world today relies on successful standardisation of every conceivable physical and electromagnetic phenomenon which comes into play when one object or person interacts with another.

He then goes on to point out that there is an abnormal situation in the eHealth domain, which consists in the fact that standards are being developed by official agencies, including HL7 (an "ansi-accredited standards developing organizations"). This is in contrast to what has been the normal situation elsewhere, where standards were initially developed by engineering organisations, such as telecommunications companies, IT companies, or universities and research networks, and became standards only after they had been not only specified, but also implemented and thoroughly tested. The author provides a variety of reasons why a committee process of the type employed by HL7 and similar standards organizations is an unsuitable approach for addressing the problems of semantic interoperability. The reasons include:

a consistent ecosystem of standards is not likely to emerge from multiple standards organisations, with significantly different rules, and cultures, and which are quite competitive;

the international standards organisations in the e-health area are large enough that even internally they generate inconsistent standards;

development of technical artefacts by committee is almost destined to fail;

good technical artefacts can only be developed by an engineering process (that is to say: requirements, analysis, design, implementation and validation – as old-style or agile as you like);

most standards in e-health are being developed without a sound model of the ecosystem, in other words, they are developed as ‘point-to-point’ specifications, or responses to specific problems, with no reference to an underlying design framework;
there is in general very little culture of implementation or testing – many e-health standards are issued untested;

there is little or no organisational commitment to maintenance, in the sense that software developers understand – i.e. if a bug is found, there should be a way to report it, and track its progress, and on the development side, the organisation should be capable of issuing new releases in a timely fashion (organisations that do do this always have two things you can find – an online version control repository and an online issue tracker);

timelines for delivery are notoriously unreliable;

the groups created for delivering a given work item typically do not contain people with the required engineering competence, but rather enthusiasts ...

I am pleased to see that the OBO (Open Biomedical Ontologies) Foundry, an initiative in which I am involved, has embraced an approach which avoids the majority of these problems in its attempt to create a standard set of semantically interoperable ontology resources to support biomedical research. Two principal marks of the OBO effort are 1. its striving for logical consistency and for non-redundancy even as the suite of involved ontologies grows, and 2. its commitment to thorough testing of all OBO artifacts and to careful peer review before ontologies are accredited for use by the OBO Foundry community.

"Non-ambulatory status" in HL7 Version 2

3.4.3.15 PV1-15 Ambulatory Status (IS) 00145

Definition: This field indicates any permanent or transient handicapped conditions.

Examples:

A0 No functional limitations
A1 Ambulates with assistive device
A2 Wheelchair/stretcher bound
A3 Comatose; non-responsive
A4 Disoriented
A5 Vision impaired
A6 Hearing impaired
A7 Speech impaired
A8 Non-English speaking
A9 Functional level unknown

B1 Oxygen therapy
B2 Special equipment (tubes, IVs, catheters)
B3 Amputee
B4 Mastectomy
B5 Paraplegic
B6 Pregnant

HL7 and SNOMED CT - The Book

One long-standing complaint of this blog is the absence of clear, simple, explanatory, helpful and reliable literature on the HL7 RIM. It is thus a pleasure to note the appearance on-line of a pre-publication version of the new book by Tim Benson entitled Principles of Health Interoperability - HL7 and SNOMED, which is to be published in the Springer Health Informatics Series in November 2009. This is, I believe, the first book to provide extensive coverage of HL7 v3. (Mike Henderson's introduction to HL7 Messaging, with a practical focus, reaches only as far as v2.5.)

Benson's book is well-written and well-structured, and will provide a good starting point to those who are interested in the role of HL7 and SNOMED CT in current endeavors to realize interoperability in the realm of health information. Unfortunately in his treatment of HL7 RIM Benson still stays too close to the in many places confusing wording of the HL7 organization's own documents, and thus he does not provide the necessary level of clarity which would be needed for a more generally useful introduction to HL7 v3. In some cases there are outright contradictions, so that the reader is left with no reliable way of determining what is meant.

The problems at issue will by now be all too clear to the readers of this blog, but I will reiterate them nonetheless:

a. Confusing use of 'Act' to mean in some cases intentional action and in other cases anything that happens.

b. Confusing use of 'Act' (the same word) to mean in some cases a record and in other cases that which is recorded.

I provide passages to illustrate these problems below, confining myself to Benson's Chapter 7 – The HL7 V3 RIM, with one example taken from his Glossary. Emphases have been added by me. While the passages from ch. 7 are provided in their order of appearance, they are, inevitably, taken out of context. If someone can provide me with a key to the relevant context or contexts which will enable me to understand them consistently I would be more than grateful.

1. In his Glossary, Benson defines 'Act' as:

Any action of interest. Something that has happened or may happen.

(Interestingly, HL7 itself does not include the term 'Act' in its own Glossary, though it does include several of Act's children, and it presupposes an understanding of what 'Act' might mean in its definitions of the corresponding terms.)

The passages from Benson's chapter 7 are as follows:

2. "In HL7 V3, every happening is an Act, which is analogous to a verb in English. Each Act may have any number of Participations, which are Roles, played by Entities. These are analogous to nouns." [Act = any action of interest?, or any happening whatsoever (for example, a drug interaction, or an event in which someone dies as a result of a shooting accident)?]

3. "Act is a record of something that has happened or may happen. Full representation of an Act identifies the kind of act (what happens), the actor who performs the deed, and the objects or subjects (e.g. patients) that the act affects." [An Act is a record; an act affects patients; so 'Act' and 'act' are not synonymous; yet elsewhere in this chapter (for instance under 'Status Code') Benson uses 'Act' and 'act' interchangeably.]

4. "Information in a document is treated as an Act – the act being the creation of the document content." [Does this mean that information is the act of creating information? What, more generally, is HL7's view of the relationship between an Act, and what is treated as an Act? And is the act the record, or the creation of the record?]

5. "Each transaction is a kind of act." [I presume that this means that each transaction is an act (or Act?) of a certain kind.] "An account is a record of a set of transactions." [Does this, by 3., mean that an account is a record of a set of records?]

6. "Observation is defined as an Act of recognizing and noting information about the subject, and whose immediate and primary outcome (post‐condition) is new data about a subject. Observations often involve measurement or other elaborate methods of investigation, but may also be simply assertive statements, such as a diagnosis." [Are observations events of recognizing and noting? Or are they the results of events in the form of records or statements, as would be implied by 3. above and by the fact that Observation is a kind of Act? Or are they sometimes one and sometimes the other? Are some Observations records of Observations?]

7. "A Procedure is defined as an Act whose immediate and primary outcome (post‐condition) is the alteration of the physical condition of the subject." [Again, how can this be consistent with 3. above? How can a record alter the physical condition of its subject?]

8. "A particular Entity in a particular Role can participate in an Act in many ways. Thus, a person in the role of surgeon may participate in an act as primary surgeon or as assistant surgeon." [Is the surgeon participating then exclusively as record keeper, as is implied by 3. above, or also as surgeon?]

In summary, the RIM documentation creates for us a continuum of Acts, Events, Happenings, Recordings, and Records which are the Results of Recordings. It then posts different items to different points on this continuum on the basis of principles which seem unclear because the relevant distinctions between the different segments of this continuum are obfuscated in confusing ways.

Does this matter? Well, perhaps. There is currently much activity on the HL7 front in light of urgent efforts to bring about the needed interoperability between HL7 and the SNOMED CT vocabulary. How, under the conditions described above, will the Acts at the heart of HL7 v3 be callibrated in relation to what SNOMED calls 'procedures'?

The Multiple Joys of HL7 V3

An intelligent post from Keith Boone on his Healthcare Standards blog on the need for greater architectural oversight in the HL7 v3 community, to protect against burgeoning modeling inconsistencies:

One of the joys of HL7 Version 3 are the many different ways that you can say the same thing depending upon the context of your message. Let's look at a laboratory test result for example. Using the HL7 RIM, this will be encoded as an observation. Using the 2008 Normative Edition there are at least 7 ways within the published standards to say the same thing. These seven different ways appear in the following HL7 Version 3 standards:

• Care Record
  
• Clinical Genomics Pedigree


• Clinical Document Architecture


• Clinical Statement


• Common Message Element Types


• Public Health Reporting: Individual Case Safety Report


• Periodic Reporting of Clinical Trials


• Laboratory Results

The picture [here] shows how these HL7 standards support this concept slightly differently in each case.

I've shown how the names of the XML Element, and the constraints on the content of the Observation class vary using a bold red font, or where the RIM attribute is missing, a red background

As Boone points out, "Arguably, there's a reason for this [multiplicity], but I challenge anyone to determine why."

Update August 12, 2009

Some interesting responses to Boone on the HL7 Listserv, illustrating (inter alia) the problems which arise when 'observation' is made to do duty for so many different things.

From: Amnon Shabo [mailto:SHABO@il.ibm.com]

Sent: Wednesday, August 12, 2009 3:38 AM

To: Lloyd McKenzieCc: austin.j.kreisler@saic.com; charlie.mead@booz.com; Boone, Keith W (GE Healthcare); owner-strucdoc@lists.hl7.org; strucdoc@lists.hl7.org

Subject: Re: Use of Domain Models

Hi Keith,

Regarding documenting requirements - I fully agree that it's the most important task in the standards development process and we should do a better job here.You start with saying "Let's look at a laboratory test result for example"and then bring a list of specs that presumably have the capacity of representing lab test results. However, none of those specs is the Lab spec which should be the natural & first choice for that purpose. You then continue to show that there are differences in the way the RIM Observation class was refined in each of the specs on your list. But isn't it looking at the empty half of the glass? After all - we can think of it in this way: here are specs that serve a broad spectrum of use cases (from clinical trials through healthcare to public health) and they all use the same class! And if you add to it the availability of a dedicated lab spec then the example you bring up is nicely covered I believe.

Regarding domain models, I don't think that 'all-in-one' new CDA is the way to bring about consistency across various domain models nor does a very generic Clinical Statement (CS) model which in fact becomes another 'RIM'in the attempt to accommodate so many requirements from all domains. Instead, a CS spec that is modeled to serve a single statement as part of some larger composition (in analogy to natural language) is perhaps a way to achieve consistency across domains at the statement level.

By the way, in the Pedigree spec, the clinical observation we put there was meant to be replaced by the CS CMET which wasn't available yet at the time we finalized this spec.

Thanks,

Amnon.

Sent by: Lloyd McKenzie

To: "Boone, Keith W (GE Healthcare)" <keith.boone@ge.com>

07/08/2009 04:37

Subject: Re: Use of Domain Models

Hi Keith,

I don't think this has anything to do with issues embedding domain models in CDA R3. You can express the same content in a CDA model 50 different ways if you like. Clinical statement is nearly (though unfortunately notquite) as expressive as the RIM. There's no question that increased consistency on representing equivalent data would be useful. However, there are also circumstances where the same piece of information needs to be represented at different levels of granularity. When referencing a diagnosis as the indication for prescribing a drug you don't need the same level of detail as you do when you're capturing the diagnosis as the focus of a trackable problem. The benefit of leveraging domain models in CDA R3 is that at least there is *some* guidance on how to model the content and consistency with a given domain. 7 models is better than 50+. And for a given document, it should be possible to narrow down which domain model more appropriately covers the document content which means you'll be working with less than 7 choices.

Lloyd

From: "Boone, Keith W (GE Healthcare)" <keith.boone@ge.com>Date: 12 augustus 2009 16:24:55 GMT+02:00

To: "Amnon Shabo" <SHABO@il.ibm.com>, "Lloyd McKenzie" <lloyd@lmckenzie.com>Cc: <austin.j.kreisler@saic.com>, <charlie.mead@booz.com>, <strucdoc@lists.hl7.org>

Subject: RE: Use of Domain Models

Amnon,

On your first point, that I should have used the lab spec, I would point out that my analysis was only covering published standards and DSTUs from the 2008 Normative edition. Lab isn't in there, so I didn't use it. Yes, it would have been the obvious choice. The fact that after 10 years we still don't have a balloted standard for laboratory reporting is another topic for another time.

On your second point, I would have to agree with what you've said below if they used the same class consistently. However they do not, and some of the differences are critical for interoperability.

For example, two of the published standards disagree on what the vocabulary domain should be for observation.code. Most seem to agree that it should be ObservationType, but Clinical Genomics doesn't restrict it and Clinical Trials Lab uses the broader ActCode. So what happens when I try to tranfer data from a Clinical Genomics message that uses something not in the Observation Type domain to another message that has the restricted domain? Lack of interoperability. Yes, I can certainly impose those limitations on a system that uses two or more of the standards, but WHY should I have to?

Finally, the point of this post was not to pat HL7 on the back. I still honestly believe that it's doing a decent job fulfilling its mission of providing the best standards for healthcare. However, there are still challenges that it needs to address, and I'd like to be able to exchange the word "decent" for "good" and eventually "great". The whole point of the post was to identify some of the current deficiences, and offer a possible solution or two.

Keith

Would Tightening the Definitions in HL7 Make Things Worse?

In a recent post I pointed to errors created by the flexibility of HL7, for example because it allows the NK code for 'next of kin' to be used in a message also, for example, when referring to a nurse. Graham Grieve has entered a Comment to this post, defending a view of the NK code as 'a field that users can put what they need into'.

As he points out:

The question is, for any particular use, is that use consistent with the definition of the field? I don't think it is in the hoot example. But consulting the standard, the definition is loose - like the definition of next of kin in the real world. Of course, in a competition to find the worst case of egragarious mis-use of a standard, HL7 regulars would line up to bring forward their favorite cases. But HL7 is not alone here. HTTP is the same too. As for web services ... . What this does betray is a flaw in the whole picture: the standards body defines a logical structure, but business use cases require things to be done, and how are they going to be done? So some partially educated analyst makes a (variably) bad decision under considerable pressure, usually with some input from actual implementers. The outcomes are unpredictable. Actually tightening the definitions (like in a proper ontology) can make things worse, and so can loosening them. Though either can make things better for at least some users in some circumstances. It's just something we have to live with.

I fear that Graham's relaxed attitude to the dilemmas of bad coding ignores an overwhelming problem in the current (v3) architecture of HL7, a problem which does much to explain the peculiar features of some of the discussions on HL7's email lists, and which explains also why HL7 needs to devote so much effort to the consideration of questions like 'Is Diet a subclass of SupplyAct?' or 'Is a car accident an intentional action?'

The problem is that the RIM rests on a counter-intuitive upper level ontology, one in which anything that is not an Entity has to be classified as an Act. This counter-intuitive ontology -- in which a disease, for want of any more appropriate category, is identified with an act of observation of a disease -- not only makes it hard for HL7 analysts to avoid making bad decisions; it is also likely to be responsible for medical (coding) errors downstream, and it also places obstacles in the way of simple remedies for such errors.

Consider, for example, the case described in part 4 of the interesting series "Are Health IT Designers, Testers and Purchasers Trying to Kill People?" by Scot M. Silverstein. The chart below represents a problem list presentation page generated in an Electronic Medical Record system via auto-population based on what its makers refer to as an 'artificial intelligence' function.


As Silverstein points out, a number of issues are illustrated here. For present purposes we focus only on those pertaining to the diagnosis 'atrial fibrillation.' This is, as Silverstein notes, an important piece of information for the clinician to know.

Except, however, when the patient does not have atrial fibrillation. This entry was auto-populated when a nurse ordered a blood clotting test and erroneously entered the reason for the test as "atrial fibrillation" (a common reason, just not the case here) to expedite the order's completion. Voila! Now Mrs. Jones carries this diagnosis, and the next clinician to come along might order her anticoagulated with heparin or coumadin for a history of A. fib, introducing yet more chance of an iatrogenic injury.

And I am told it takes going back to the vendor to have this erroneous entry permanently removed. Sheer idiocy! For instance, if the patient moves to a different unit, is discharged and returns to this hospital, or to an outpatient clinic or another hospital branch with this on the record, the chances of a screwup are not insignificant

HL7 was not, for all I know, involved in any way in the creation either of this system or of the specific problem list here illustrated. But consider the difficulties created by the RIM for any rectification. Suppose, for instance, one wished to have a facility to allow users of the EMR to generate different sorts of problem lists for different purposes. These might include, for example, problem lists that would include only those entries in which a disease is ascribed to a patient on the basis of some act of observation by a clinician. To achieve this end, we would need to keep records of observations by clinicians clearly separate from records of diseases on the side of the patient, along the lines illustrated for example here. We have attempted to identify a way in which the RIM could allow a programme do this coherently. But thus far we have not been successful.

hoot72: An Ontology for HL7 v. 2.3

hoot72 is an interesting experiment by CDC to create an OWL ontology to capture in a coherent fashion the major entities recognized in HL7 v. 2.3.

The ontology is associated with a blog, which draws attention to some of the unfortunate consequences which flow from the fact that HL7 is flexible in the familiar ways (thus it allows the NK code for next of kin to be used also, for example, for nurses).

The OWL framework provides a clear perspective on HL7 v. 2.3, and avoids the usual problems (with act, observation, etc.) which plague v.3.

On Problems with HL7 Documentation and with HL7 XML

I respond below to two critical comments from Kevin Coonan which, following the earlier comments from Graham Grieve, point to a welcome new trend for those submitting comments to this blog, in that they are submitted non-anonymously. (Comments to HL7 Watch are moderated, but all signed comments are passed through automatically.)

Comment 1 (to HL7 RIM: still no coherent way to track concerns):

KC: I too wish to echo's Grahame concern that you seem quite liberal in quoting comments out of context and seem all to eager to find the most minute publication error as further evidence to support your "interesting" theory about how HL7 works or what you can do with the organizations work products.

BS: I am afraid I do not yet have a theory about how HL7 works, because, like many others, I do not understand the HL7 documentation. This is in part because it is unclear -- a problem which HL7 has already acknowledged and is itself attempting to ameliorate -- but in part, and more seriously, because it is inconsistent. Gunther Schadow, Charlie Mead and Mead Walker defend this state of affairs by arguing that:

As different people edit parts of the specification, inconsistencies in form and quality may emerge; as some ambiguities are clarified, other previous systematic ideas may be corrupted; and well meant glossary entries may cause confusion. Sometimes irreconcilably opposed conceptualizations may coexist and one resorts to vague or ambiguous language in the interest of moving forward in areas where parties can not agree.

Some would argue, however, that this is a state of affairs that raises questions for an organization that is proposing standards for information exchange, especially in a critical domain such as health care, and especially in a context in which large government investments depend on making the right sorts of standards decisions.

KC: While you at times do happen upon a legitimate concern about HL7, you do a great disservice to those who read your blog by misconstruing ongoing self critique by HL7, and discussion of very difficult technical issues as flaws.

BS: Such self-critique is of course an entirely positive thing. It would be a flaw in a system only if actual errors or inconsistencies or unclarities or ambiguities identified through such critique would be ignored at the stage where the artifacts in question become normative.

KC: Should more people read (or care) what you publish, it could have a detrimental effect by stiffing the public discourse which marks a healthy SDO.

BS: Good point. I hereby commit to closing down this blog just as soon as there is evidence that it is succeeding in becoming influential.

KC: Since you are such an ardent lurker of the lists, perhaps you might wish to attend some of the frequent tutorials to give you a better working knowledge of HL7 methods and models, and then consider directly contributing to the ongoing efforts to find workable solutions.

BS: I devote a lot of time to the OBO Foundry standards efforts (we also organize many interesting tutorials). The developers of all the ontologies within the Foundry recognize the value of criticism from outsiders, since outsiders are able to provide a fresh perspective -- for example by exposing ways in which our documentation falls short. Science, I believe, makes progress only to the degree that it maintains a healthy culture of criticism from outsiders.

Comment 2 (to Big HIT) (responding to the identification of major problems with HL7 XML):

KC: HL7 XML is standard. It follows published W3C standards, which as far as most are concerned are the standards about XML which matter.

BS: Correct. But not all standards are equally good, I'm afraid. See, as concerns HL7 XML, the arguments here (summarized already here).

KC: HL7 itself is a ANSI SDO, and anything that HL7 publishes as normative BY DEFINITION is a standard.

BS: An ANSI standard, yes; all the more reason, therefore, to ensure that everything is checked very carefully before publication as normative, for example to ensure consistency.

KC: Finally, HL7 contributes, collaborates and uses the same ISO standard (21090) for data types, which is by-and-large the XML which makes up "HL7 XML."

BS: Unfortunately most HL7v2 and HL7v3 message standards do not follow this ISO standard. Moreover 21090 is not a full ISO standard. It is in the DIS-stage and therefore under development: http://www.iso.org/iso/catalogue_detail.htm?csnumber=35646

KC: Please, when you make statements such as that, you should constrain yourself to the facts, and not make such invalid and irresponsible statements.

BS: I hope, with respect, that we are both doing our best to confine ourselves to the facts.

Still no coherent way to track concerns?

I am grateful to Graham Grieve for posting the following comment to the entry ""HL7 RIM: still no coherent way to track concerns":

I think your quoting Dan's email in this way is highly inappropriate. You have also cherry picked the various responses to Dan. For instance, you didn't include mine. Your comment is: "Why was the change of adding CONC and COND not made to the official RIM standard" is highly disingenuous - trying to portray a technical mistake as a policy issue.

I think you may have a point about condition vs act, but the continued errors of reporting and perspective this blog entry shows make it really hard to bother listening to your point.

I am happy to provide a link to the requested larger set of responses here (no letter from Graham among them, however, for the reason given below). I am also happy to withraw my portrayal of what Graham certifies is a technical mistake as if it were a policy issue. My reason for jumping to conclusions in this way turned on the repeated reports which I receive from persons with a much better knowledge of HL7 than I, to the effect that, when proposals to simplify HL7 are put to ballot, there is a tendency for such proposals to be voted down.

Postscript July 7, 2009:
In a further comment, Graham now writes:

It's certainly true that repeated proposals to simply HL7 are voted down. There's several reasons for this which could be variously categorised as the good, the bad and the ugly. But by and large it appears to be an inevitable part of the standards process: you only ever add scope and requirements. And refactoring is always hard to pull off, let alone when other people get to vote on the outcome in a consensus based process ...

Somewhat embarrassingly, it turns out that my email to Dan was private, not cc:ed to the list (I think by accident). Whoops, so my apologies on this count Anyway, this one was a technical mistake, and it appears that it will be rectified as a technical error.

I look forward to seeing evidence of the rectification. And I hope that it is done right -- i.e. that 'condition' gets to mean 'condition' and not, for example, 'observation of condition', 'worry about condition' -- so that the existing problems with 'disease' are not simply recreated under a new heading. A condition is not an act.

HL7 RIM: still no coherent way to track concerns

One standing theme of this blog is the inability of HL7 v3, and its RIM 'reference information model', to represent clinical concerns, problems, conditions -- including diseases, such as your influenza and my diabetes. The RIM, familiarly, leaves us only two options for the coding of such information: either to identify diseases as Acts (which we take to mean 'intentional actions on the part of human beings'), or to identify diseases as Entities (roughly, those things -- such as persons, bedding, pills -- which are 'made of molecules').

To normal persons both of these options seem equally unacceptable. To the RIM, however, a stunningly creative work-around is at hand: diseases are identified as Acts of Observation. Roughly: a disease is an observation of a disease.

One of the many problems with this work-around is that there are often many observations of one and the same disease (for instance of my diabetes or Jim's arthritis), and the RIM provides us with no satisfactory answer to the question of how we can identify what each given series of such observations have in common. The obvious answer -- that they are all observation of the same disease / problem / condition -- is ruled out.

When Werner Ceusters and I made this surely obvious point at the Medical Informatics Europe meeting in August 2006 (see here), Günther Schadow responded on behalf of HL7 to the effect that steps would be taken to add new classes to the RIM in order to address the obvious need to refer to items such as diseases, medical problems, clinical conditions which are not Entities, and thus not made of molecules, but yet such as to endure self-identically through time.

Two new classes -- of Concern and Condition (with abbreviations 'CONC' and 'COND') -- were selected, and a number of important HL7v3 players have been using these classes -- in reflection of the fact that they address an urgently felt need. Unfortunately, the ISO RIM standard and the ANSI HL7v3 standard did not see fit to support such usage.

We therefore have a new bifurcation of different RIMs (where the RIM itself was introduced 13 years ago precisely in order to solve the problem of multiple different dialects plaguing HL7v2).

Why was the change of adding CONC and COND not made to the official RIM standard, given the obvious benefits of simplicity and greater ontological coherence such a change would bring? This question is being raised also inside the HL7 community, as for example in the following email exchange, which hints at serious problems regarding the quality of HL7's decision-making process:

From: Dan Russler dan.russler@oracle.com
Date: 23 May
2009 4:52:26 GMT+02:00
To: Jean-Henri Duteau jean.duteau@gpinformatics.com
Cc: "patientcare@lists.hl7.org" , MNM List , HL7terminfo ,
"vocab@lists.hl7.org " vocab@lists.hl7.org
Subject: Modifying
Problem list in the CCD standard: was Patient care harmonization Was:Re: NIB
forms for next ballot

I am semi-retired now fom HL7, but I am still heavily involved in HL7-based implementations and feel a need to help avert a "crisis of confidence" in HL7. There have been important events since the Nov. 2006 harmonization votes on Concern (CONC), Condition Node (CNOD), and Condition (COND) despite the missing voting records regarding CONC in the RIM. One of the most important is that the CCD, with the Patient Care Concern Tracking Structure embedded in the Problem List and Allergy List (Alert) sections is now named in US HITSP-based regulations and is live in State government-based patient care activities such as in Alabama Medicaid HIE and the State of Tennessee Shared Health HIE. It would be horrible for a relatively minor missing voting record incident to cause a crisis of confidence in HL7 in the middle of the US Federal Recovery Act initiatives. CCD training, Schematron testing, registered templateID OIDs all support the Concern Tracking Structure in the CCD.

History: As referenced in this Cover document for the HL7 RIM proposal introducing the new Act.classCode "CONC (Concern)," a great amount of consensus building preceded the introduction to harmonization. The use of the term "Concern" rather than Condition Node in the patient care models for problem and allergy lists was suggested by OO (by then representative Gunther Schadow). Patient Care accepted the recommendation and brought the proposal to harmonization. At the same time, Structured Documents implemented a highly constrained version of the newly renamed "Concern Tracking Structure" in the CCD. Due to the limited ability of CDAR2 to support new classCodes, the instance of the "Concern Class" in the CCD had to be implemented as an "Act Class." However, the CCD Act.classCode used in the problem list and alert sections of the CCD is structurally the same as the CONC class in the Patient Care Concern Tracking Structure. The intent at that time was to implement the CONC class in the CCD with CDA R3 when new classCodes were supported. I was the harmonization steward for Patient Care and submitted the harmonization proposal. During discussion, I accepted a friendly ammendment from Woody Beeler to hold off on formally deprecating CNOD until we could make sure that no other committee wanted to use the class. In addition, it was thought wise by others to maintain the COND class as was. My recollection of the vote was that all clinical committees including PC, OO, Structured Docs voted to accept the CONC class as defined in the RIM and leave CNOD and COND in place. It might be helpful to poll the other stewards and find any who recollected voting against the proposal. In January, 2007, the Patient Care minutes show that Woody agreed to submit a definition modification proposal to harmonization to change the definition of CONC by substituting "issue" for "worry." This vote indicates that Woody at that time understood CONC to be "in the RIM."

Comment: Since Nov, 2006, no other TC has decided to utilize CNOD. After being present in the RIM, but unused for almost 10 years now, it seems reasonable to consider removing CNOD from the RIM. A number of implementations that I am aware of have found COND to be valuable in subtyping OBS (thereby differentiating a diagnosis from other kinds of observations). It seems reasonable at this time to continue RIM support of COND. However, in my humble opinion, it seems risky to HL7's reputation for M&M/Vocab to demand revoting on an established standard simply because someone misplaced some voting documents. It seems better to ask
the stewards who were present if anyone remembers voting against adding CONC to the RIM. If a majority do not remember voting against CONC, the reasonable solution is to add CONC to the HL7 RIM as a technical correction rather than requiring the whole process to be repeated. Again, this is no minor decision on
the part of an HL7 committee. This decision has ramifications throughout the US Federal Government, the vendor community, and the user communities using CCD in patient care. It is fair to consider a backwards-compatible revisions to the Concern Tracking Structure in the future based on the evidence from real users of the CCD. However, these revisions should occur through careful HL7 revision processes and with the representation of real CCD users, and not through clumsy process repair efforts in a single HL7 committee, most of whom are not direct users of the standard today.

Respectfully,

Dan Russler, MDVP Clinical
InformaticsOracle Global Health Sciences Strategy

Jean-Henri Duteau wrote:

Although I agree with Keith that we should try to locate the final consensus, I do want to point out that the intent of a new submission was less due to the fact that it was missed so many years ago and more to do with the fact that the world has probably changed since the proposal was raised. Woody's point at the MnM Facilitator's Roundtable was that rather than PC stating that the old proposal should be resurrected and simply actioned, that PC should instead work to find the proposal and then resubmit it after ensuring that it is still valid with today's RIM and vocabulary and model requirements. It could very well be that the previous agreed direction is entirely valid and PC just needs the original proposal actioned. But it behooves us to ensure that is true.
Sincerely,
Jean DuteauBoone

Keith W (GE Healthcare) wrote: I would push back on this. This was a rather long discussion over several months that was resolved and closed. We should make appropriateefforts to locate the final consensus. Re-opening this as a new Harmonization proposal because someone failed to keep up with the discussion seems to be an abuse of the process that we went through to come to that consensus. I'd be concerned that the direction it takes would be different from what was agreed upon previously.
Keith

Further reading:

Werner Ceusters and Barry Smith, “What do Identifiers in HL7 Identify? An Essay in the Ontology of Identity”, Proceedings of InterOntology 2009 (Tokyo, Japan, February 27-March 1, 2009), 77-86.

Richard H. Scheuermann, Werner Ceusters, and Barry Smith, “Toward an Ontological Treatment of Disease and Diagnosis”, Proceedings of the 2009 AMIA Summit on Translational Bioinformatics, 2009, 116-120.

The Data Model That Nearly Killed Me

A very interesting post:

The Data Model That Nearly Killed Me

in which Joe Bugajski describes how far we are from an electronic health record environment that would serve the patient. The situation described is one in which the patient, as he moves through the healthcare system, is called upon to answer questions, over and over again, in ways that give rise to multiple opportunities for inconsistency. Authoritative data about the patient's condition from the patient's own doctor is treated, at best, as just one minor ingredient in the mix.

One heroic medical professional, the first nurse I met in ICU, worked to create a consistent record of my condition, allergies, and medications in the hospital’s electronic health information system. She spent over one hour searching for previously entered data, correcting errors, and moving or reentering data. She argued with one doctor whose concurrent access to the hospital’s system blocked my nurse’s access to my information. She called the hospital’s pharmacy repeatedly to get my medications delivered. She met and called doctors several times. She even convinced one doctor and a pharmacist to come to my room to resolve data errors in person. Despite these heroic efforts, I never received correct medications during my stay. Indeed, my wife snuck one of my inhalers into my room. After I used it, I finally began to recover.

The inconsistencies arise, in part at least, from the absence of any consistent common framework for data entry on the side of the electronic health record. The HL7 RIM might conceivably contribute to filling this gap; but the RIM, as we know, is focused not on the patient's condition, or on the events transpiring on the side of the patient, but rather on the transactions of healthcare professionals. It rests, in other words, on a view of the electronic health record as a collection of statements “not about what was true of the patient but [about] what was observed and believed by clinicians” [1].

The exact causes of the problems documented by Bugajski are still to be determined. One way of summarizing the argument of this blog is that it seeks to make the case for a more incremental, evidence-based, and patient-centered approach to the EHR, and for a regime in which standards are imposed only when they have been proven in use.

[1] Rector AL, Nolan WA, and Kay S. Foundations for an Electronic Medical Record. Methods of
Information in Medicine 30: 179-86, 1991.

Postlude (1) May 1, 2009
Another version of Bugajski's narrative can be found here, which points to do major problems which must be addressed if the vision of seemless interoperability of healthcare records is to be realized: the problem of building a consistent ontology of the enormous and rapidly evolving medical domain; and the shortage of people with the skills and training needed to realize this goal:

The first problem with modeling healthcare data is that models must represent certain concepts (and not others) that will remain stable and true long enough to be built into computer software then used by healthcare providers and patients. Mr. Obama, have you noticed just how much knowledge has, is, and will be accumulating in the medical sciences? Knowledge is codified using words - medical knowledge uses copious quantities of difficult words taken from several languages. Words that recur frequently in a particular context become imbued with a meaning that includes the context (e.g., the White House). Such words then come to symbolize a bigger idea than originally intended (i.e., a "house" that happens to be "white", versus your administration and not the house). In medicine, how many stable words exist? These words - nay, well-formed concepts, repeatable, agreed by the medical community - can be modeled and added to computers to store records. Go one step further. Specialization in ER, ICU, cardiac care, pulmonology, oncology, radiology, and other medical subjects exists because the cumulative knowledge defines a large ontology. The ontology, taxonomy, skills, and knowledge of an medical subject area then can be referenced with one word - the name of the specialty. Unfortunately, words that refer to a concept in one specialty often mean something different in another specialty.

The second problem is the lack of good modelers. These people, specialists in data engineering, a subfield of software engineering, transform concepts into graphical and lexical patterns that are used to create computer records. The concepts they model are words (nouns and verbs) plus concepts used by practitioners to describe a patient's medical condition, or a critical care pathway, medications, instructions to patients and nursing staff, tests, and diagnoses. Who among us has the modeling skills to encode this data? As information varies across specialties, how should it be encoded? Empirical evidence suggests that engineers who built the electronic health records network at the two facilities that "cared for me" tried to do this, but they failed. Their data model had irreconcilable silos of information spread across specialties and expressed as incomplete taxonomies (entities), inadequate ontologies (attributes), and poor associativity (relationships). Hence, when programmers added those bad data models to the health information systems, those systems later lost critical information about patients' condition, listed wrong medications,isolated prior diagnoses from current observations, in short, made very bad medicine.

Postlude (2): July 4, 2009
Joe Bugajski's Reply to "Proper Perspective Needed..." (April 21, 2009):

I admire, voted for, and strongly support President Obama. I support his vision of a National Health Network (NHN). I strongly disagree with his administration’s $20 billion conclusion that technology and technologists stand ready to build the NHN today. While I know little about practicing medicine, I am an authority (30 experience and many publications) in data interoperability and system integration. Hence, I cannot comment about treatment effectiveness - you and others generously provided these insights. I can write about data in the context of a system design.

The crux of the data model issue is this. If data cannot be made reliably available across silos in a single EHR, then this data cannot be made reliably available to a huge, heterogeneous collection of networked systems. Furthermore, poor quality data models and low quality user interface design convolve into serious data access and use problems for practitioners and their patients. Data models are my immediate concern relative to the NHN, but interface design also needs attention (also a fit subject for study in the NHN context). Further to data models, integration of information across an exceedingly complex, networked, data storage and retrieval topology remains an area of active research. (Indeed, my clients in every industry worldwide struggle with the issues daily - just for in-house systems.) Contrast data integration for NHN with the technology and expertise used to build the interstate highway system – 30 years of networked data knowledge versus 3000 years of road building knowledge. Consider too that technologically advanced, caring, and world-class medical institutions own and operate the troubled systems in question. These experts have immediate access to the best minds in computer, data, and network technologies. If they cannot reliably move data from one department to another, or across the street to from one to the other, how then do the rest of us cope?

--

New HL7 Ballot: Signs of Hope, but Confusion Remains

In 2007 the HL7 Board of Directors identified the need to review existing HL7 documentation in light of multiple unclarities and inconsistencies, some of them referred to in this blog (and also here). In the recently released Ballot Version 0226 of May 2009, we are perhaps beginning to see some evidence of the workings of this review, most notably in the fact that a much-cited nonsense passage present in earlier versions of the RIM documentation, according to which

there is no distinction between an activity and its documentation,

has been removed.

This is an important step, given the fundamental unclarity which has pervaded the RIM hitherto as concerns whether the items which the RIM calls 'Acts' are real processes (intentional actions) or records of such processes. HL7's official answer to this question thus far has been, absurdly, that the issue is moot, because there is no distinction between real processes and the records of such processes.

We hope now that the opportunity will be taken for further steps towards much needed clarity as concerns the interpretation of 'Act'. In the mentioned Ballot documentation we read:

Acts are the pivot of the RIM: domain information and process records are represented primarily in Acts. Any profession or business, including healthcare, is primarily constituted of intentional and occasionally non-intentional actions, performed and recorded by responsible actors. An Act-instance is a record of such an action.

Contrast earlier versions, where we were told that: "An Act-instance is a record of such an intentional action" (italics added). Are there now also some non-intentional actions the records of which we are allowed to count as Act-instances? If so, which ones? And what is a 'non-intentional action'? And what of of non-intentional events of other sorts, for instance snake bites, accidental poisonings, processes of infection, drug interactions, symptoms of disease?

Following on in the text, we read:

An Act-instance represents a "statement," according to Rector and Nowlan (1991) [Foundations for an electronic medical record. Methods Inf Med. 30.]

What is the meaning of 'represents' in such assertions? And what (if any) is the distinction between an Act and an Act-instance? Are we to accept three distinct entities: the action performed in the real world, the record of this action (which record?), the statement in the electronic medical record? Or is the record identical with the statement in the electronic medical record.

Acts as statements are the only representations of real world facts or processes in the HL7 RIM. The truth about the real world is constructed through the combination (and arbitration) of such attributed statements only ...

Do the authors of this documentation really mean 'The truth about the real world'? Or do they rather mean something like: the picture of or beliefs about the real world implied by a given body of documentation? What if the patient is dead, but the records do not show it?

A factual statement may be made about recent (but past) activities, authored (and signed) by the performer of such activities, e.g. a surgical procedure report, clinic note, etc. Similarly, a status update may be made about an activity that is presently in progress, authored by the performer (or a close observer), and later superseded by a full procedure report. Both status update and procedure report are acts, distinguished by mood and state (see Act.statusCode) and completeness of information: neither has any epistemological priority over the other except as judged by the recipient of the information.

Is a surgical procedure report truly an activity? Are a status update and a procedure report truly 'acts, distinguished by mood and state'? If so, are they also Acts? Lingering unclarities such as these are not resolved by the list of 'examples' presented by HL7 in the same document to help us understand correct usage:

Examples:
The kinds of acts that are common in health care include (1) clinical observations, (2) assessments of health condition (such as problems and diagnoses), (3) healthcare goals, (4) treatment services (such as medication, surgery, physical and psychological therapy), (5) acts of assisting, monitoring or attending, (6) training and education services to patients and their next of kin, (7) notary services (such as advanced directives or living will), (8) editing and maintaining documents, and many others.

If editing and maintaining documents are acts, then are the records (and if so which records?) of these processes of editing and maintaining documents Acts? What is the relation between 'acts' and 'Acts', and between both of these and activities (and actions)? And how can a goal be a kind of act? (or Act?)

Big HIT

In an article in the New England Journal of Medicine [1], Kenneth Mandl and Isaac Kohane argue that spending billions of dollars of federal funds to stimulate the adoption of existing forms of health record software would be a costly policy mistake -- because current health record suppliers are offering pre-Internet era software, which are costly and wedded to proprietary technology standards that make it difficult for customers to switch vendors and for outside programmers to make upgrades and improvements. (We note that exactly this mistake was made in the United Kingdom with its Connecting for Health program.)

Mandl and Kohane propose instead that the government should be a rule-setting referee whose role would be to encourage the development of an open software platform on which innovators could write electronic health record applications in a way which would open the door to competition, flexibility and lower costs. They point to an analogy with Apple's IPhone platform, that anyone can use or write applications for.

This is, of course, a good idea, since it would bring in its wake the opportunity for thorough testing of particular applications before they are extended to larger communities of users. The potential flaw, of course, is that it leaves open the question of what the government-imposed framework of rules should be. The HL7 organization (founded in 1987) continues to be mightily influential in government circles. Consider, to take one simple example, the case of XML. Will it be XML itself that is government imposed? Or will it be HL7-XML, a peculiarly complicated non-standard version of XML resting on an idiosyncratic approach to development that is at odds with the approaches taken by developers with XML expertise?

[1] Kenneth D. Mandl, M.D., M.P.H., and Isaac S. Kohane, M.D., Ph.D. "No Small Change for the Health Information Economy", New England Journal of Medicine, Volume 360:1278-1281, March 26, 2009. See also New York Times, "Doctors Raise Doubts on Digital Health Data", March 25, 2009.

Why Make It Simple If It Can Be Complicated?

In a document entitled

Ten good reasons why an HL7-XML message is not always the best solution as a format for a CDISC standard

Jozef Aerts, an XML expert at XML4Pharma, has examined the on-going attempts to format new CDISC standards as HL7-XML messages.

These attempts reflect the desire for integration, given that HL7 is well-established in the healthcare world, that XML is itself a global standard of growing importance, and that the FDA is already using a number of HL7-XML-based standards.

As Aerts points out, however, there are a number of problems: 1. it is an XML-free HL7 v2.x that is well-established; 2. HL7-XML is an embarrassingly complex non-standard version of XML, with little in the way of software tool support; 3. HL7-XML causes problems which standard versions of XML avoid; 4. the movement to HL7-XML seems to be especially supported by people that have never been actively been involved in XML development (and to be supported often for reasons political rather than computational, clinical or economic).

HL7-XML messages take years to develop and are nearly always overcomplicated:

Those who have ever inspected an HL7 aECG-XML file in detail, may have been surprised by the enormous complexity of the XML. One of the reasons for this is that the XML structure (as defined in its XML-Schema) is not developed by XML specialists, but is derived from UML diagrams. I have been teaching a lot of XML in the last ten years and have experienced that CDISC ODM can be learned in a one day course. No chance however to accomplish this with aECG. Therefore, the amount of people that really understand aECG-XML is very limited, this in contradiction to the amount of people that understand ODM-XML.

Similarly, though XML is usually defined as being “as well machine-readable as human-readable”, one may question whether the latter is applicable to some HL7-XML messages such as aECG: not only the complexity is overwhelming, but it also uses a lot of code ununderstandable for the human reader.

In 2006, Gartner issued a Note entitled "HL7 V3 Messages Need a Critical Midcourse Correction", stating that “HL7 must act vigorously to make Version 3 messages easier to use and more compact” (See e.g. here.)

The direct consequence of this overcomplexity is that it is much harder (and thus much more expensive) to develop software to read and write HL7-XML than it is for ODM-XML. From my personal experience (30 years) in software development, I estimate that the cost of developing softwarefor a complex HL7-XML message is at least the twentyfold than it is for ODM-XML.

Once again, therefore, HL7 chooses an idiosyncratic approach to development that is at odds with the approaches that have been tried and tested elsewhere -- with results which might have been anticipated (some of which were indeed anticipated on this blog, for example here).

As Aerts continues:

HL7-XML messages are developed in a somewhat curious way: first of all one or
more UML diagrams are developed, and then the XML-Schema is derived from the
UML. The UML is derived from the RIM (HL7 Reference Information Model) which
currently has over 70 versions (!). Though the use of UML may be the perfect
and well-established way for translating a software design to software classes, it is considered bad practice by XML specialists. Transformation of UML to XMLSchema
in general leads to “spaghetti XML”, introducing unnecessary complexity. Of course it is an “easy” way: the world has much more UML specialists than it has XML-Schema specialists.

Personally, I would consider transformation of UML to XML-Schema the “lazy man's way”. The result can however be catastrophical. By the way, none of the most popular XML-based standards, such as MathML, VoiceXML, XHTML or XForms etc. have ever been developed using UML.

Aerts provides a series of examples to illustrate the problems and costs caused through use of HL7-XML, problems which are avoided if one uses XML in the standard way recommended by XML experts.

Addendum (April 10, 2009):

Some comments on Hacker News:

I don't know anything about HL7 or HL7-XML, but this sounds like letting loose people that dont know zilch about the implementation side of things. In this case HL7 is translated into UML because the people involved know UML, not XML. Then the UML is translated into XML by the push of a button, generating monstrous XML. Rant: dont let your tools substitute for personal knowledge of the domain.

How can someone not know XML when it's actually relevant to their job? It's just a tree with a fairly simple structure. Anybody who avoids learning XML because they already know UML is just not even trying. Seriously, learning it takes like half an hour at most.

HL7... what a nightmare! I remember having to work with it, and it was a convoluted solution where every provider and vendor had a different interpretation. As bad as 2.3.1 is, it's still worlds better than 3. The best thing that can happen is for 3 to be scrapped. The worst part is its model. I worked with it for the purposes of PHIN-LDM, and I've never seen a worse clusterfuck. It made dailywtf look positively logical.

I've written my own HL7 (pre-XML v2.x) message parser and generator in Java for work. I'd really like to not have to touch that code again, if possible. My code is easy enough to understand, but I don't want to have to rewrite it support this non-standard XML. Just putting XML on the name of something doesn't instantly make it all easier.

Information and Communication Technologies Standards in the Health Sector

A new study has been released on behalf of the Enterprise & Industry Directorate General of the European Commission on the topic of ICT standards in the health sector: current situation and prospects.

The study contains a number of interesting remarks on HL7, for example welcoming the current initiative towards greater collaboration between HL7, ISO and CEN.

But there are also critical remarks, for example to the effect that:

Small or medium-sized ICT manufacturers may not be willing to adopt commonly used standards because these are very complex and thus difficult and expensive to implement. This applies for example to HL7 version 3. It may be less costly to develop proprietary standards on their own. (p. 21)

And also this:

HL7’s v2.x standards were important steps towards standardising clinical messaging. However, several issues caused difficulties, above all different options to implement the standard. To correct this issue, the RIM was developed for v3.0, eliminating most of the implementation options. The concept behind HL7 v3.0 has been generally well received. However, the RIM caused new problems. Firstly, it is unlikely that the defined RIM classes and attributes could be applied to every domain in healthcare – which is what they are intended to do. Secondly, the RIM documentation is described as being “disastrously unclear”, poorly integrated with HL7 v3.0 documentation, and inconsistent.

Under these circumstances, it may be difficult for HL7 v3.0 to establish a large user base. ... HL7’s involvement in the joint initiative with ISO and CEN may have the objective to move faster to international adoption of HL7 standards. The outcome of this convergence work as well as the organisation’s ability to create a satisfactory RIM may determine the future importance of HL7. (p. 37f.; emphasis added)

Does the emperor have clothes?

This set of slides from a recent presentation by Eric Browne at an Australian national e-health conference provides some reassurance that the arguments I have been making on this blog are perhaps not simply the product of my own ignorance. Summary: "Basing clinical information interoperability on the HL7 v3 RIM is severely flawed. It is too complex; the underlying principles are unproved and highly suspect. The complexity leads to bad models, glacial progress, compromised quality and safety."

Postscript: Feb. 15, 2009
A more recent post by Eric Browne documenting problems with HL7 Clinical Document Architecture (CDA) is here.

Barriers, approaches and research priorities for integrating biomedical ontologies

Alan Rector has published an impressive survey of what we can expect for terminologies and ontologies in healthcare in the next ten years. Summarizing a long document, Rector believes:

• HL7 (a mix of versions) will dominate the standards for messaging.
  
• The standard for EHRs is likely to be a combination or amalgam of the HL7 CDA and Archetype based standards from OpenEHR, CEN EN 13606.
  
• Terminologies from biomedicine, particularly the Gene Ontology and the associated ontologies in the Open Biomedical ontologies consortium will become of increasing importance to clinical medicine.
  
• Following the example of the bioinformatics community, open systems “owned” by their community are likely to make an increasing contribution.

Rector echoes a number of what one might be tempted to call 'philosophical' points addressed in this blog as concerns the relations between ontologies and information models. He nicely summarizes these points as follows:

The relationship between knowledge representation and ontologies remains controversial and plagued by confusion of substance compounded by loose use of language. A second closely related notion is that of an “information model” of “model of data structures”. Both Archetypes and HL7 V3 Messages are examples of data structures. Formalisms for data structures bear many resemblances to formalisms for ontologies. ... However, there is a clear difference.

• Ontologies are about the things being represented – patients, their diseases. They are about what is always true, whether or not it is known to the clinician.For example, all patients have a body temperature (possibly ambient if they are dead); however, the body temperature may not be known or recorded. It makes no sense to talk about a patient with a “missing” body temperature.
  
• Data structures are about the artefacts in which information is recorded. Not every data structure about a patient need include a field for body temperature, and even if it does, that field may be missing for any given patient. It makes perfect sense to speak about a patient record with missing data for body temperature.

A key point is that “epistemological issues” – issues of what a given physician or the healthcare system knows – should be represented in the data structures rather than the ontology. This causes serious problems for terminologies coding systems, which often include notions such as “unspecified” or even “missing”. This practice is now widely deprecated but remains common.

Under 'desirable outcomes', he lists:

The methods will become increasingly formal. The conflict between the scaling problems presented by pre-coordinated terminologies and the difficulty of maintaining consistency with post-coordinated terminologies will be overcome. To this end, the formal structure of SNOMED-CT and will be radically revised to take advantage of its purported underpinnings in description logic. HL7 v3 and/or Archetypes will likewise be reformulated to take advantage of modern technologies to ensure their mutual consistency and consistent binding to the new terminologies. Common links to terminologies from OBO and others used in molecular biology will be forged.

And under 'outcomes to be avoided':

enormous resources will be spent on over-ambitious plans for semantic interoperability that inevitably fail. In either case, communication will take place by going around rather than via the clinical information systems. In countries where it is mandated, SNOMED and HL7 V3 will become taxes on healthcare, absorbing significant resources while returning no, or in some cases negative, benefits.

The document as a whole contains a wealth of important material on HL7 V3 -- and SNOMED CT -- and on the problems associated with each. It draws special attention to HL7 15 year-long planning process designed to produce a '“version 3” that is not yet in routine use'.

Flavors of Null

Interesting post from Ananda Mohan concerning the problems created by HL7 v3's lack of support for any kind of optionality. One result of this policy is that codes need to be provided in advance to cover all cases where information is missing -- hence the multiple 'flavors of null', which, are listed by Mohan on the basis of the latest HL7 v3 ballot pack as follows:

1. NI: "no information" - this is the most general and default exceptional value. There is no information which can be inferred from this exceptional value.

2. MSK: "masked" - this particular item has a known proper value, but it cannot be released in a given context due to security, privacy or other reasons.

3. OTH: "other" - there is a value, but it is not an element in the value domain of a variable, with particular cases:

- NINF: "negative infinity of numbers"

- PINF: "positive infinity of numbers"

4. UNK: "unknown" - a proper value is applicable, but not known. In particular:

- ASKU: "asked but unknown" – information was sought from the source but not known (e.g., patient was asked but didn't know)

- NAV: "temporarily not available" - information is not available at this time but it is expected that it will be available later.

- NASK: "not asked" - the Information was not requested from the patient

- QS: "sufficient quantity" – The actual quantity is not known but sufficient enough to achieve a specific goal. For example the advice can be: add a sufficient quantity of water to 10 mg of medicine.

- TRC: "trace" – The content is too small to measure but still a non-zero value.

5. NA: "not applicable" – There is no proper value for this data item for this patient; for example, the date of the last menstrual period is not applicable for a male.

All of these “flavors” are provided for every data type. Thus for example “null” is a possible value of an integer or real alongside actual integer and real values As Mohan points out, this might lead to reasoning problems: the HL7 definition of 'Boolean', in contrast to every working formalism, implies a 3-valued logic. The null flavors are causing problems also for the (surely in any case premature) attempts by ISO to model its health data types standard (ISO 20190) on HL7 v3 data types. Organizations such as CEN have, it seems, opposed the current ISO draft, in part because of the problems generated by the usage of null flavors.

These problems were described in detail already five years ago in a document on the openEHR Data Types Information Model, the latest version of which is here:

All HL7 data types inherit from the ANY class (equivalent to the DATA_VALUE class in openEHR) which contains the attributes:

BL nonNull;
CS nullFlavor;
BL isNull;

The purpose of these attributes is to indicate whether a datum is Null, and for what reason. Since some data type classes also appear as the attributes of other data types, the Null markers also ndicate whether any part of a datum is null. ... this allows an interval with missing ends and width to exist as a structured type. The consequence of the approach is that the entire model is essentially a model of "partial" data types; any attribute and any function call may return a Null value, as well as the true values of its type (in fact, in the specification, Null values are defined to be valid values of all data types).

This design decision was taken in HL7 so that any datum, no matter how unknown, would be structurally representable in the same way as completely known data, enabling it to be processed in the same way as all other instances of the same type. However, an important object-oriented design principle has been ignored in this approach. In the proper design of classes, properties and class invariants are stated. Invariants are statements which describe the correctness conditions of instances of the class; the general rule is that the post-condition of a creation routine (constructor) of a class must be that the invariants are satisfied. For example, an invariant of the HL7 IVL class could be:

(exists(low) and exists(high)) or else
(exists(low) and
exists(width)) or else
(exists(width) and exists(high))

When an instance of this class is created, this condition should be satisfied, and remain satisfied for the life of the instance. To do otherwise is to create instances ofdata which other software can make no assumptions about, and is forced to check every single field, and then determine what to do in an ad hoc way. ... Possible consequences of the built-in Null marker design approach include:

• since even HL7’s basic types ST, INT, REAL, LIST<>, SET<> include null markers, processing of null values will be pervasive at the lowest level;

• software will be more complex, both implementations of the data types, and of software which handle them. This is because the software always has to deal with the possibility of calls to routines and attributes returning Null values. Most clinical information systems to date have taken the approach that a datum is either represented as an instance of a formal type if fully known, or else as narrative text if only partial;

• data may not be always be safely processable, since some software may not properly handle the null values associated with attributes of partially known data items.

Essentially, all software which processes the data has to be “null-value aware”, and make no assumptions at all about whether a particular data instance is valid or not.

For all of these reasons the HL7 data type model is in stark contrast with the much simpler approaches used in CEN and in openEHR.

How does one refer to an organism in a microbiology report?

Is an organism an entity? Or an observation of an entity (thus, presumably, an observation of an organism)? Can it really be true that, after ten years of HL7 RIM development, the answer to this question is still not clear?

As the useful Resources page of HL7 Australia makes clear:

At first site the RIM is quite simple. The RIM backbone has just five core classes and a number of permitted relationships between them.In HL7 V3, every happening is an Act, which is analogous to a verb in English. Each Act may have any number of Participations, in Roles, played by Entities. These are analogous to nouns. Each Act may also be related to other Acts, via Act-Relationships.Act, Role and Entity classes also have a number of specialisations. For example, Entity has a specialisation called Living Subject, which itself has a specialisation called Person. Person inherits the attributes of both Entity and Living Subject.

Organism, too, is a specialization of Entity, we might reasonably suppose. Thus an organism is not a Role, not a Participation, not a Relationship, and also, we presume, not an Act. That an organism is an Entity is indeed the view embraced by advocates of HL7 in their oral discussions with me over the question whether the RIM can be taken seriously as a representation of the healthcare domain.

Not so for everyone in the world of HL7, however – at least not according to what we can infer from this:

Hi,
I have been working with people at CDC on using V3 messaging to convey microbiology reports among other things. In discussions today, the question came up of where in the Microbiology specification was the observation that identified the organism for which susceptibility results were being passed. I said, well no, the organism was indicated as an entity playing the role of isolate and participating in the "specimen observation cluster". But, I was told, the CDA hospital acquired infection report carried this as an observation, and indeed it does. Is this a problem to be addressed? Or a characteristic of V3 to be managed? It does seem clear that the two specifications have been underway in parallel [*], so it is, if not pointless at least difficult, to say which should be allotted precedence. What ideas do people have?
Mead

*This is exactly the thesis defended here.

News from Stockholm

More from Stockholm County Council, and its ambitious healthcare IT system, the GVD, sometimes advanced as a success story of HL7 V3:

We chose Oracle Healthcare Transaction Base because it complies with the worldwide HL7 standard for clinical data, and because it comes from a major international company, committed to supporting, developing, and refining the product over time. When we conducted a market evaluation, Oracle also came in at the right price. – Jack Robinson, IT Manager, Stockholm County Council

In an article entitled "Missarna som knäckte GVD" (roughly: Flaws in the Cracked GVD"), Madeleine Bäck reports on the recent history of the GVD project, which continues to move from crisis to crisis:

Heavy criticism is directed towards the choice of storage system for GVD, the so-called HTB database, which was acquired from WM-Data and its partner Oracle in 2004. 'Our pilot tests point to catastrophic performance when loading data to the system. We also observed that it would be incredibly complicated and expensive to adapt HTB to the GVD', explains one involved person (who however chose to remain anonymous). The suppliers who built the GVD are aware of the criticism, but they do not agree with all aspects: Pia Kullstrom, head of Public Sector and Healthcare at WM-Data, pushes back specifically as regards criticism of the HTB system. This is not based on facts she claims, but rather on people having a different product-religion.

I am told that features of the GVD marked out as problematic include:

1. The poorly functioning BAT&Portal (for authentication and authorisation services), which uses HL7's CCOW (Clinical Context Object Workgroup) standard protocol, and is supposed to be a web-based, single point of entry and single sign-on access route to the different parts of the system.

2. For writing data to HTB the performance is 'still horrendous', even though Oracle re-wrote the whole implementation for reading data through their API after Stockholm had already accepted the HTB product.

3. GVD has a strongly centralized architecture, but its protagonists did not address the question of how to handle the legacy systems during the transition period. Many of the latter are fully functional, mission critical, clinical systems. Centralized architectures, in which the attempt is made to consolidate semantically non-interoperable data from hundreds of databases into one, are show-stoppers.

As a whole, GVD is a classical "big bang" project, where the thinking has been quantitative, not qualitative, and the Stockholm political leadership has admitted that GVD is an "IT-fiasco".

But the responsible civil servants remain in denial, and there have not as yet been any signals to the effect that they are going to back down from HTB. This raises one further problem: GVD has Oracle HTB, and thus HL7 V3, as central component. One can state with high confidence that HL7 V3 is not going to be the standard at national level for interchange of clinical data in Sweden. So what is Stockholm going to do?

The weight of the baby

HL7 RIM, as we have pointed out on too many occasions, confuses observations with the entities observed. To illustrate this confusion once again, we provide the following scenario, from Werner Ceusters (WC), with reactions from Dan Russler (DR), as they appeared on the HL7 vocab list. We added some small clarifications and corrected some spelling errors (and perhaps, by trying to work our way through the numerous levels of comments on comments, we might have overlooked some dependencies). Dan and Werner are free to suggest corrections. (To access the Archives of HL7 lists one can go to: http://www.hl7.org/listservice)

Here we go:

WC to DR: I am in a delivery room, and there is that baby and his weight. When I want to register something about that baby's weight, I will use the symbol "#w-1234" to denote that baby's weight. The numbers are there to differentiate that baby's weight from some other baby's weight. The baby's weight is something that has different values at different times. The baby's weight endures through time. It is a continuant.

I want to obtain a value for the baby's weight, for which I have to perform an act of measurement, for which I will use the symbol "#m-5678". The ID numbers are there to differentiate that measurement from other measurements I might perform, even from the measurement which I might do a few minutes later when I weigh the same baby for a second time. The act of measuring occurs at a time. It is an occurrent.

The act of measuring gives me a magnitude, which in this case is something we have been taught to register as "4.7 kg". Now registering that (entering "4.7" into a computer, for instance) is an act in its own right, and when I want to refer to that registering act, I will use the symbol #r-881 (you get the picture, I hope).

Now you (Dan) seem to argue that I am not allowed to assign some of these symbols, though I can't figure out from your comments which one(s) precisely you object to. You should clarify. Here are the symbols again, for easy reference:

#w-1234 : THAT baby's weight
#m-5678 : THAT process (which occurred during THAT time) of measuring THAT baby's weight
4.7 kg : the value obtained for THAT baby's weight through THAT process
#r-881 : the further process of entering the obtained value in some record

DR: The baby is a collection of molecules ...

WC: Sure; but that is not relevant here.

DR: Why isn't the fact that the baby is made of molecules relevant? ... The baby wouldn't have a weight without being made of molecules.

WC: If the task is to register the magnitude of that baby's weight in a record, there is no reason to mention his molecules. We also don't talk about those other molecules on the side of the Earth that attract the baby's molecules, do we ?

DR: The weight is the measurement of the force of attraction between the baby's molecules and the earth at that location and at that point in time.

WC: "No" on several things. First, the weight of the baby is not a measurement at all.

DR: You will need to go back to the physics definition of weight. Objects have mass, which create a mutual force of attraction.

WC: Thanks for this lesson, again; although I said in my mail that I knew that. It is simply not relevant.

DR: Weight is simply the concept of putting a scale in between two masses and measuring the force of attraction between two masses, the baby and the earth. You could abstract out the idea of measurement, but then we would just say "force of attraction," not weight. Of course the force of attraction between the baby and the earth is less in Denver than at sea level. So perhaps you could alter your discussion to match the real physics of the situation?

WC: That doesn't change anything to the simple task at hand: putting a baby on the scale, and reading what the instrument gives as weight. Dan, stick to the topic.

DR: Now this illustrates the problem with comparing "your reality" to "my reality."

WC: There is only one reality, but we can describe it in different ways. Your way seems to be to lump important things together (e.g. that baby's weight and my activity of measuring that weight), and to add irrelevant things (such as the molecules of the Earth)

DR: You invent things in your mind in the discussion below that I have not invented in my mind.

WC: I didn't invent anything. I gave a description of a simple scenario and I introduced 4 symbols. You started to mix and confuse the symbols, and bring in others.

DR: When you communicate what you invent, you use words that mean something different to me (and to many other people). Although I respect the inventions of your mind, I don't understand them, and when you explain them, I don't always agree with them.

WC: Then, if you still don't understand the scenario I described, and what the four symbols stand for, give me a language in which I can describe it so that you will understand it.

There is something that you can measure (the baby's weight), and an act of measurement, which is a different thing. The value for the weight that you obtain by measuring it is yet another thing. The word "measurement" is often used ambiguously to denote the last two things: the measuring act and the value obtained through the measuring act. It would be good for everybody's understanding not to use language ambiguously in this way. (Compare it with the noun phrase "the cut" which is used for both the act of cutting and the gap that results from this act.)

[Ceusters here tries to describe what at first might seem hard to swallow: the weight of this baby is the same entity from one time to the next. It is an enduring attribute of the baby. Certainly the baby's weight changes over time, but then so also does the baby. But just as the baby stays the same individual from one time to the next as it changes, so also does its weight. The baby's weight is a continuant. At any point in time, that weight has a precise magnitude, but which magnitude this is changes from one time to the next. - BS]

The discussion continues:

WC: All that gravity stuff is irrelevant here, because if I or a nurse put a baby on a scale to measure it's weight, I know what I'm measuring. I was and I am not talking about other stuff you can measure.
Again, I will use the symbol "#w-1234" to denote that baby's weight.

DR: Werner has in his mind the idea of "the force of attraction" and created a symbol #w-1234 to communicate the force of attraction between the baby's molecules and the earth at that point in time.

WC: No on several things, again: I had nothing regarding forces of attraction in my mind. In fact, I was describing a concrete delivery room situation.

DR: Doesn't gravity exist in the delivery room? Gravity sounds pretty concrete to me.

WC: Sure, but this fact is irrelevant. There are at least a billion other things in that room, such as the molecules in the door knob. I used explicitly demonstrative particles to make it clear: There is "THAT" baby. I'm not talking about conceptual representations of babies and delivery rooms, but simple things: babies and rooms.

"#w-1234" is the symbol that I use to denote that baby's weight in a description, NOT the magnitude of the weight.

DR: Now this symbol "#w-1234" has attributes associated with the symbol, such as:

time (since the weight will vary with time);
location (since the weight will vary with the location, e.g. altitude);
identity of the baby (weight will vary with different babies).

WC: Many more "no's". The symbol "#w-1234" may have attributes associated with it, but I did not talk about that.

DR: on the contrary, you gave the symbol attributes "the symbol #w-1234 ... to denote that baby's weight". To transform to a formal propositional grammar:

the symbol #w-1234 dentotes the weight of that baby
object of the predicate: "that baby"
predicate: "denotes the weight"

WC: Dan, the symbol I introduced here is "#w-1234". I told you what the symbol stands for: that baby's weight. You can decompose that in as many ways as you want and I can give fifteen other grammars and NLU paradigms for you to analyse the way I said things; but you must at some stage get back to the topic. We are not analysing the lines of text that I produced, we are analysing what the lines of text try to convey. But the fact that you insist on analysing it this way, demonstrates that you are not able to get passed the language level.

Let's try it this way: "#w-1234" is a symbol. It is composed of the characters "#", "w", etc. I use it in a language to refer to / to stand for that particular baby's weight, a particular entity in reality, not an element of a language. I could use another symbol for that baby's weight. Thus I could use the symbol "that baby's weight'. I could then say "that baby's weight" stands for that baby's weight.

Attributes of the symbol may be the number of characters, the font used, etc. I am not studying symbols for the sake of this discussion. But interestingly, Dan, it is becoming clear at this point that you (perhaps because of the inadequacy of the representation language you choose to use) confuse the symbol with what the symbol stands for, a common mistake made by people who misunderstand semiotics, and a confusion which pervades the entire RIM, as we and others have shown.

Dan, it is surely the case that the words I used in the language of that paragraph are symbols, but we are not talking about the language in that paragraph. We are talking about the state of affairs in reality of which that paragraph is a linguistic representation. And you darned well know it, Dan, come on.

DR: I just tried to understand what you mean (perhaps not always in the same way as what is in your mind) or what the relationship is in your mind to what is occurring in the delivery room.

WC: I told you: that is irrelevant. That is "Wusteria". If I am talking to you about my mother, then I am not talking to you about some neuronal blurb in my brain. I am talking about my flesh and blood mother.

DR: If there is a problem with me understanding what you created in your mind, is that your problem, my problem or both our problems?

WC: If I was obscure or ambiguous, it would be my problem. But I was, repetitititititively, quite specific.

DR: Surely, my difficulty in understanding what you invented doesn't change what happened in the delivery room!

WC: The weight of the baby will change over time, the symbol will not. You may perhaps not like my symbol and would use another one. That is fine with me, as long as we make it clear for each other that these symbols denote the weight of THAT baby, not the magnitude of THAT baby's weight.

Thus, again, I use the symbol ONLY for THAT baby's weight, not for any other baby's weight. I made that quite clear, but you ignore it, and I am interested in knowing why you ignore it. I repeat thus about that symbol: "The numbers are there to differentiate that baby's weight from some other baby's weight."

DR: I am happy to be corrected on what you meant to say. Can you explain how I know how to figure out the baby's identity and the name of the force of attraction (not the magnitude of the force as you suggest) from the symbol #w-1234?

WC: Excuse me ? Do you not know how a baby looks like ? If I am in a delivery room, and they ask me to take the weight of that baby, I don't think I would grasp some bucket and measure its diameter. Or do you mean literally what the name is of that baby? I don't see what that has to do with that baby's weight. It has to do of course with putting the value in the right record. But again, that adds nothing here to the discussion.

DR: Symbol #w-1234 has common name: "weight"

WC: No! that symbol denotes the weight of THAT baby. The symbol itself certainly does not have the common name "weight". It might be given the common name "symbol" though. You can use the common name "weight" to denote that baby's weight, but that is imprecise and may lead to exactly the sort of confusions that you exhibit.

DR: I can agree to narrowing down my understanding of #w-1234 if you can teach me how to make sure the symbol unambiguously represents the baby's identity and other things that affect the force of attraction between the baby and the earth.

WC: Because I told you. "#w-1234" is the symbol that I use to denote that baby's weight. If you were there, I would have pointed to the baby. If not, I could show you a picture, or you would get other information related to the parents, etc. All that information could be put in some symbol dictionary or look-up table. And no, the idea is NOT to infer it from the form of the symbol itself. I think that the notion of no meaning IN the code is broadly accepted.

DR: Symbol #w-1234 has definition: "the force of attraction between the baby's molecules and the earth at that location and at that point in time

Symbol #w-1234 "has location: delivery room "latitude-longitude-altitude"

Symbol #w-1234 has time: TS

Symbol #w-1234 has baby: identity of baby

WC: No ! I did not give a definition. And if I would have done so, it would have been a quite different one.

DR: Since a physicist, or a physician, would give the definition I inferred from your use case, which would you supply?

WC: That is irrelevant in this case. We are talking about the simple notion of weight.

DR: Once the symbol "#w-1234" is created in Werner's mind and written down and re-created in my mind ...

WC: The symbol is on some bearer medium. Whatever happens in my brain is irrelevant here. The symbol is for sure not "created" there. Something will happen there, of course, some state of affairs involving neurons and neuro-transmitters and so forth, and there is some relationship between the symbol on the medium and the state of affairs in my brain. If I would wish to say something about that particular state, I would use another symbol for that. At that point, I could imagine that you would say: "Ah, you see, you assign another symbol to that symbol", but if you did, then clearly you did not get the point.

DR: We can communicate using the symbol.

WC: Right, and independently of whatever our brain does in this case, because we agreed (I hope, finally) that we use "#w-1234" ONLY to refer in descriptions to THAT baby's weight (NOT its magnitude, NOT the act of measuring in order to determine this magnitude, ...)

DR: However, the weight is still the force of attraction between the baby's molecules and the earth.

WC: probably, but irrelevant.

DR: Not irrelevant to me, because the force of attraction, the earth, the baby, the people like you and me, are the only things really existing in my reality. Everything else is made up in your mind. What is in your mind is important to me, but I don't confuse what is in your mind with my reality.

...

DR: When you say "obtain a value for the baby's weight, for which I have to do a measurement" you add a new attribute to the symbol for weight: "value"

WC: no ! In the sentence above, I didn't mention or introduce another symbol at all. The symbols I introduced were:

#w-1234 : THAT baby's weight
#m-5678 : THAT process (which occurred during THAT time) of measuring THAT baby's weight
4.7 kg : the value obtained for THAT baby's weight through THAT process
#r-881 : the process of entering the obtained value in some record

I did not introduce the symbol "value".

DR: Your whole paragraph is made up of symbols. Above, you just pick out several symbols from the paragraph and throw away the rest.

WC: Try not to confuse the readers by throwing in another level of symbols. I was quite specific about what the symbols I was talking about are. All, except the "4.7 kg" started explicitly with #.

DR: In any case, I now see you added to your story the term "process".

WC: ... in a humble attempt to make you see the difference between (1) what is to be measured, (2) measuring itself, (3) and the value obtained through the measuring.

DR: ... and defined 2 processes:

1) #m-5678 : THAT process (which occurred during that time) of measuring THAT baby's weight
2) #r-881 : the process of entering the obtained value in some record

WC: I didn't define these processes. In the scenario, these are two processes which are relevant to our discussion (because you confused them) and for which I introduced two different symbols.

DR: It is helpful for me to know that you feel these are two processes, which represent the movement between three states. Thank you for the extra detail. In my mind, that communicates the standard state transition model where process describes the movement from state to state.

WC: I am not responsable for the limitations in your language of choice, i.e. the standard language of state transition models. If you don't get the right results by using that state transition stuff when addressing this scenario, then don't blame me; blame your language.

DR:
State 1: pre-condition to Process #1

Process #1: #m-5678 : THAT process (which occurred during that time)of measuring THAT baby's weight

4.7 kg : the value obtained for THATbaby's weight through THAT process

State 2 is both the post-condition of Process #1 and the pre-condition to Process #2

Process #2: #r-881 : the process of entering the obtained value in some record

State 3: is the post-condition of Process #2.

DR: You said, "When I want to register something about that particular measurement, I will use the symbol #m-5678".

Here you identify the measurement with a symbol and fill in the value with a symbol:

#m-5678{symbol #w-1234
has common name: "weight"
has definition: "the force of attraction between the baby's molecules and the earth at that location and at that point in time ...

The act of measurement, which gives a magnitude which in this case is something that we have been taught to register as '4.7 kg' , he identifies with the symbol

r-881
has location: delivery room "latitude-longitude-altitude"
has time: TS
has baby: identity of baby
measurer: Werner
value: #r-881

WC: No ! Again, you confuse the measurement (the act of measuring) with the weight of the baby. It is for THAT measurement act, that was performed to get a value for THAT baby's weight, that I use the symbol "#m-5678". I can then use that symbol to document, for instance, that the measuring act took 55 seconds to perform.

Furthermore, I didn't fill in any value.

Furthermore, you erroneously equate #r-881 with that weight, which I clearly (or so I thought) explained r-881 to be the act of registering the obtained value in a record. I wrote that:

The measurement gives me a magnitude which in this case is something that we have been taught to register as '4.7 kg'". Now that act of registering (entering "4.7" into a computer, for instance) is an act in its own right, and when I want to refer to that act, I use the symbol #r-881 (you get the picture, I hope).

But clearly, you didn't get the picture, confusing now THREE things.

DR: I must apologize for not clearly discovering what is in your mind. Again, is that my problem or our problem? If what you want to achieve is good communication, you have to be very clear for those of us who can't read your mind.

WC: You didn't have to read my mind. You only had to read what appeared on your screen after opening my message. Again, if you are not able to distinguish the symbols that I introduced from the natural language that I used to try to describe to you what they stand for, then suggest a better language.

DR: I see from your explanation of process above, that you meant to use the symbol "#r-881" to represent "the process of entering the obtained value in some record".

WC: Yes !!!!!!!! Great !!!!!!!!!

DR: ... and not the magnitude of the force of attraction. I would ask however, other than communicating the symbol"#r-881," what gets communicated along with the symbol in process #2, the process of entering the value in the record?

WC: I didn't say anything about that, as yet. But stuff that might go there is, for example, how long it takes to enter weight values in a record (interesting for comparing user interfaces from an ergonomic and effort required perspective) or who entered the data (that gives you the culprit in case of mistyping) or when the data was entered (the weight was taken at time t, but the registration at t+1).

DR: Summary: I believe these are the symbols you assigned in your own mind and communicated in your paragraph.

WC: As I explained above, your belief is wrong.

DR: Here is how I created the communication in my mind and communicated it back -- is my creation in my mind wrong from your point of view?

WC: yes, indeed. You confused several different entities.

DR:

Act.ii = #m-5678
Act.code = "3-1234 (weight--the force of attraction between the baby's molecules and the earth at that location and at that point in time)
Act.effectiveTime = TSAct.observation.value = #r-881
Act.participantMeasurer = Werner
EntityPatientRole = identity of baby
Entity.location = "latitude-longitude-altitude"

WC: On the basis of what I described above, you must identify at least 2 acts in HL7-speak, and not just one as you came up with: one is for measuring the weight of that baby, the other for registering the value obtained through the former in a record. Furthermore, there must be at least three non-act entities: the baby, its weight and the magnitude of this weight at the time of the measurement (i.e., first act). Now I can accept that this detail is not relevant for many purposes and that therefore you don't want to register these things (although then I don't understand why you consider the baby's molecules and the gravity of the earth to be of relevance here - and please, don't take the latter statement as an indication that I don't know what weight physically is about, it is simply irrelevant). But you should NOT come up with a representation as you did - in HL7-speak, I believe - that CONFUSES the different elements.

Compare with this analogy: if you take a picture of some scene (say of your best friend and his wife), and parts of the scene are irrelevant (say his wife), you can cut out these parts of the picture. The remaining parts (the picture of your friend) still depict faithfully the corresponding parts of the scene. One should not, in contrast, use some analogous technique of removing irrelevant parts if this means that the relevant parts will get distorted as well.

Your analysis of my use case was clearly wrong: I pointed out precisely where you went off track. The $60M question is now: WHY ? I can come up with several possibilities, but prefer, as Anthony asked and we agreed to, to keep the discussion germane to the issue. Thus I argue here (as before and as a few others have done earlier) that the semiotic and speech act theories and architecture of the "HL7-language" are such that they mislead even experts like you: HL7, in many cases, lets you build representations which are such that removing irrelevant detail leads to distortion of what is relevant.

DR: Certainly, I have learned more about how your mind works in this exchange.

WC: Sure ?

DR: That is important because as I communicate back to you what I heard from you, I make misinterpretations unless your language is VERY clear.

WC: Wasn't it ? I think the problem is that from the very beginning you lumped different things together. As you know, getting things-lumped-together apart is harder than lumping things together. Third time: propose me a more formal language then.

DR: Of course, our communication patterns don't change what happens in the delivery room, and we have to decide why we are bothering to communicate if it doesn't change what happens in the delivery room!

WC: I don't get your point.

DR: Perhaps you can try again to make clearer language, and we can see if you succeed in getting a more accurate return communication. I've given you some hints of how my mind works such that you can craft a more understandable version for my brain.

WC: It seems, as I indicated above, that you cannot make, or do not wish to make, links from what is IN language, to what it is in reality which the language is ABOUT. I guess that is the brain-washing effect of HL7.

HL7 Watch Watch

In the first two years of its existence this weblog has drawn a significant response from the wider HL7-interested community. Positive appreciations are to be found inter alia in the following weblogs:

HL7 Connection
"Should Governments Rely on HL7?"

Future of Health IT: Trends and Scenarios
"HL7 Watch: Is HL7v3 Overrated by being rated at all?"

Australian Health Information Technology
"Is SNOMED CT a Practical Usable Clinical Terminology Today?"
Here Alan Rector is also quoted, with his wise words to the effect that:

Unless we can formalise the mutual constraints ... HL7 v3 + SNOMED = Chaos.
The documentation is beyond human capacity ... to write or to understand.

Update March 2008:

Gratifying post also at Trusted.MD:

The argument that HL7 RIM is incoherent is compelling. I'll admit that I've found HL7 RIM to be impossibl[y] confusing for years. The problem is that as a foundation for all-things-HL7, RIM causes a lot of trouble.

Update February 2009:

See also Health Informatics Blog

Update October 2009:

Interesting post from Bruce Lemma:

If you want to get something done - just stick with version 2.x. Version 3.0 was meant to remove the ambiguity that exists in version 2.x by following a more rigorous theoretical modeling framework. In practice though it doesn't. v3 is more ambiguous than v2 ever was. v3 is very complicated. A lot of effort is required just to understand the basic concepts of version 3.0.

The only people game enough to really try and work with HL7 version 3.0 are governments and universities - organizations which can afford to dissipate a lot of resources without tangible results. It's very hard to find a real v3 success story. Have a look into what the NHS (UK) and Infoway (Canada) are doing.

Both organizations have a lot in common - billion dollar budgets, strong advocates of v3 and almost nothing tangible to show for it. It will take a few more billions before people will start to admit that v3 has serious problems.

It's a bit like the children's fairy tale - "The Emperor's New Clothes". Because so many people close to the standard have invested so much into it no one wants to admit it's not working as a standard. You'll find that people from HL7 get extremely defensive if you even hint at the idea that v3 has problems. You've gotten a taste of it already on this list.

Most vendors are extremely careful to avoid being openly negative about the standard because they are afraid of being seen as anti HL7. No one wants to risk annoying organizations like the NHS and Infoway or members of the HL7 organization that have influence over buying decisions at hospitals.

Infoway practically bank rolls the HL7 organization these days. They almost managed to stop v2 education from happening at the next HL7 meeting in Canada.

So it's a pretty pickle that the HL7 organization has gotten itself into - it is almost
impossible politically for it back down at this stage.

To get a more objective view of v3 you need to look at the opinions of people that do not have so much invested in it. One amusing website I can suggest is

http://hl7-watch.blogspot.com/

Good luck with your integration - and don't feel embarrassed about the problems you have with version 3.0 - you're just the little boy that's pointing out that the emperor is not wearing any clothes.

Source: HL7 Anwendergruppe Österreich.

The OBO Foundry: Coordinated Evolution of Ontologies to Support Biomedical Data Integration

The Open Biomedical Ontologies (OBO) Foundry is an attempt to develop a suite of reference ontologies to support data integration across the entire domain of biomedical research. Thus it shares some of the goals of HL7, including the desire to bring about prospective standardization in support of interoperability and cumulativity of biomedical data. In contrast to HL7, however, the Foundry takes a modular approach that is rooted in the division of expertise of biological scientists.

The OBO Foundry welcomes criticism, and a description of the initiative, published in Nature Biotechnology, is now available here. Alternative link here.

The Dialects of RIM

The latest Minutes of Evidence of the House of Commons Select Committee on Health, on the UK National Programme for IT, contain this comment from Richard Granger:

In terms of the core Spine infrastructure, there was some mythology in the Health Informatics Community that the standards existed, HL7 was mature, and so forth. That was completely untrue.

Dr Granger goes on:

We have had to put an awful lot of effort into specifying the standards for messages, around demographics, around booking, around prescriptions, and then the software that BT have built with a number of sub-contractors is brand new software that has been custom-built for the NHS; so that is high-risk, new build software. There was no other way of doing it. I am very pleased a number of other jurisdictions are getting very interested in using that.

He thereby inadvertently touches on another issue currently causing concern in HL7 circles. The HL7 Reference Information Model or 'RIM' was, we will remember, introduced as the solution to the problems created by the appearance of multiple dialects in earlier versions of the HL7 standard. HL7 would prevent the appearance of dialect versions by enforcing conformity to the RIM. Now, however, it is becoming increasingly clear that the RIM itself exists in multiple dialects.

This is more than just a problem of successive, incremental improvements. As the RIM Document Editorial Assessment from 8 June 2007 points out:

... the 2006 Normative Edition contains a RIM document based on the last balloted RIM [from 2003]: this gap creates the opportunity for conceptual conflict between the document and current practice. A reader must choose between a normative edition of the RIM published for ANSI, which contains nothing extraneous but is out of date; an extract of the current RIM as maintained by MnM, which will be the most up-to-date, but which is not readily available to the membership at large; or, which is most probable, the RIM document published in the Normative Edition, which both contains extraneous information and is out of date.

It seems, in fact, that we have at least:

1. the version of the RIM adopted by ISO as an international standard

2. the balloted RIM document that describes those parts of the RIM designated as 'normative', the latest (and still current) version of which, it seems, dates back to June 2003

3. an ANSI publication based on 2.

4. a CEN Standard EN 14822-1:2005 Health informatics - General purpose information components - Part 1: Overview (see also CEN Standard EN 14720-1:2005), based on 3.

5. the 'living' RIM UML model (regularly updated through harmonization) as it exists at any given stage. This RIM contains content that existed at the time of balloting in 2003 but was not then balloted, together with four years worth of cumulated changes. Some of this material is, I am told, intended to be balloted in the future; some (e.g. in CoreInfrastructure subject area) is not.

6. an idealized 'frozen' version consisting of those parts of 5. which have, at any given stage, passed through the process of harmonization,

7. the UK rebuild.

As I understand matters (and as always this understanding may be for various reasons imperfect) the RIM documentation included in any publication of the V3 standard more recent than 2003 should be based on the latest working version of the model as maintained by the Modeling and Methodology (MnM) committee. The publication label “Normative Edition” may cause confusion, however, if it is taken by the reader as suggesting that the contents so labeled are all normative (though this issue should be addressed in the relevant document preface).

Normativity, Completeness and Flexibility

As we have argued at some length, there is a fundamental incompatibility between the claims made on behalf of HL7 as "the data standard for biomedical informatics" and the need for openness to new discoveries that lies at the heart of the scientific method. To repeat: HL7 V2 is an in some ways impressively successful tool for supporting messaging between healthcare institutions, but with one central flaw: it did not prevent the proliferation of local dialects. HL7 V3 was born to overcome this flaw, effectively by removing the possibility of optionality in the formulation of messages, by imposing a 'normative' set of coding options from which all messages must be derived through combination. And it does not work:

Mead,
Yes - it is possible and most of the information is available, it is just not as easy for implementers to find and use as it would be if things were optimal. From what is in the repository, it sure looks like someone intended to put in a definitive list, but it never got completed.

There are some problems, though, as Rene has pointed out: there exists no definitive list of all Trigger Events or Interactions. We could generate one for those that are explicitly defined in the normative ballot, but then it would produce a different kind of problem for implementers: the supplied table (value set) would be incomplete, even though it would be presented as complete. I am trying to start a conversation about whether we need something to indicate that a value set for the normative ballot material is known to be incomplete and is not intended to be used 'as is', but is intended to be extended. Other than creating a new value set and redefining the binding for a realm, we don't have other machinery to do this with (to my knowledge). This tells me that either we need to describe and document this for implementers, or we need to explicitly assert the value sets as 'examples' or
a 'starter set'. Which means that they would NOT be bound in the universal realm, and would not be used in strict conformance.

There are a lot of loose gears floating around in the machinery from my viewpoint. I don't know how an implementer can find all the reference material and necessary vocabulary to actually sit down and build an implementation prescriptively based on what we have currently. There is a lot of stuff that is referenced in the normative sections that is not normative or not complete, yet not erroneous. This is very confusing to me, and I don't really know what the right answer is.

-Ted

See http://lists.hl7.org/read/messages?id=113501.

A piece of good news

The HL7 leadership has not merely recognized the problems of (un)intelligibility of the V3 documentation adverted to on this blog and elsewhere; they have also set in train a strategy to rectify these problems. We send our good wishes to all of these involved in realizing this strategy:

cc August 31, 2007
To: HL7 Co-chairs
FR: Chuck Meyer, Chair, HL7 Board of Directors
RE: Version 3 Editing project

Dear Co-chairs:

The HL7 Board of Directors has identified the need to review the existing V3 portfolio of standards for clarity, consistency, and ease of use. To that end, it has approved a renewal of contract to review existing documentation, identify issues, and propose tactics for making the V3 standard and supporting materials easier to understand and use. It is important to note that the members of the editing team are just that: editors. They will not be authoring materials. They will work with committees to enhance and organize existing materials and make suggestions for new content. Each committee continues to be responsible for its own content. The current effort is beginning at the Atlanta WGM after taking a hiatus since the Spring WGM.

In addition, an advisory group is being formed to act as a liaison between the V3 editors and the membership. Details about that group, meetings and other means of communication will be made shortly. We are seeking volunteers to participate in this group. Please contact HL7 HQ if you are interested in aiding in this critical endeavor. This should require about 2 hour per month of your time

The work is being performed by Ockham Information Services, and the primary contacts are Sarah Ryan and Jay Lyle, under the HL7 direction of Charlie Mead. The team expects that you, as technical committee members, have some issues you would like to ensure are addressed, or that you are already addressing. They will be contacting you to coordinate their activities and to ensure they do not spend time on deprecated assets, perform redundant work, or proceed with assumptions you believe are incorrect.

The timeframe for the entire V3 review is still under development, so don't be surprised if it takes a while for your specific committee to be contacted. The Board has recommended that the focus for review in fall '07 be vocabulary, datatypes and the RIM. The editorial team will endeavor to make their inquiries as specific as possible: we invite you to share your observations and issues with them. If it seems that their process is less efficient than it might be, do not hesitate to provide them any ideas you may have for improving it. Thank you for your help.

Sarah Ryan: ryansaraha1@earthlink.net
Jay Lyle: jay@lyle.net

At the same time we cannot resist the temptation to express our scepticism. How, for example, will the editorial team make intelligible such gems as the recent proposal "to treat telephone as an Observation, with value having datatype Telecom". And how will they make intelligible the long list of org.hl7.rim.decorators, as defined for example in passages such as the following Class AcknowledgementDecorator:

Implementation of org.hl7.rim.Acknowledgement as an abstract decorator, i.e., a class that returns NULL/NA or nothing for all property accessprs [sic] amd [sic] that raises UnsupportedOperationExceptions for all mutators. This is used to adapt custom application classes to the RIM class interfaces and only bother about mapping those properties that actually apply to the application class. This can be done in one of two ways: (1) the client class can extend the decorator directly, and implement the applicable properties, or (2) the abstract decorator can be extend [sic] to a concrete decorator, which would hold a reference to the client object and method bodies to delegate and adapt the applicable properties. (See already here May 17, 2007.)

Dutch HL7 Concerns

In his HL7 Connection blog the Dutch healthcare management consultant Matthew Clapp seeks to provide an open forum for collaboration between and dialog between advanced and beginner professionals in the HL7 field. In his posting "Should Governments Rely on HL7?" of August 3, 2007 he points to what he sees as the the HL7 organization's failure to foster a more open, collaborative structure:

I’ve even received emails telling me that this site is a waste of time - that no one will bother reading it because I’m not on some HL7 committee. A community that insulates itself from criticism cannot be successful.

The Course of Life blog by the Dutch scientist and entrepreneur Albert de Roos contains two recent postings in a similar vein. The first, Some practical experiences with HL7 version 3, concludes that HL7v3 seems 'too complex to work with in a multidisciplinary environment":

The complexity of HL7v3 is a general problem and also causes delays in implementation at the technical level. I hoped it has been solved now, but in 2006 not all XML schemes that were distributed could be read by the most common XML parsers available, indicating some of the problems with the complexity of HL7v3 messages. ... These apparently trivial issues may cause many delays and frustration for software developers, I can tell you.

The release frequency is also a problem, introducing problems with the different versions. This can be illustrated by the many different versions of the DMIM and RMIMs that are available on the web. I don’t think any of these have been implemented in the field, so while trying to get the thing to work, the international organization rolls out new normative editions. The Dutch implementation of HL7v3 does not follow the international release schemes, but has been frozen in an earlier version. Trying to keep up with the updates is a full-time job. Combine this with the two releases of the complete Dutch documentation each year, which may include changes in the HL7 messages, and the chaos is complete. Of course, we are only in the proof-of-concept phase, so we can expect changes but is there a any guarantee that HL7 enters a relatively stable phase? What will happen to HL7v3 messages when HL7 international moves on to the clinical document architecture, is there a migration path?

In HL7 as standardization organization de Roos points to certain problematic consequences of the fact that the Dutch government "seems to have completely outsourced the entire process of healthcare standardization to HL7:

The different members of the technical committees of HL7 version 3 modeling are employees of software suppliers, consultant or work in a hospital or other health institution. Given the complexity of the modeling in HL7v3 and the limited number of people or organizations involved, it is doubtful whether the models represent indeed a consensus standard way of working. For instance, the involvement of commercial software suppliers may cause the models to closely represent their own software giving them a competitive edge.

To me, it is clear that HL7 is a lobby organization for its own products and that they try to sell their product wherever possible. There is nothing wrong with a lobby organization and its members can spend their money how they want. The problem here is that HL7v3 is sold as a finished product and as a de facto standard, but in fact is not a complete and finished product and never successfully implemented outside of a laboratory setting. It changes continually, indicated by the fact that the organization now moves towards a new product, clinical document architecture, to largely replace the HL7v3 framework. This shift of HL7 has consequences for the national EHRs that are based on HLv3, showing that national governments are not in control of the apparently evolving requirements for the EHR and its implementation. It is strange that the government puts its ambitions in the hands of an organization that they can’t control and where its members clearly have commercial interests or other ambition that are not in line with public or governmental ambitions.

Adverse Events are Not Observations

A further HL7-relevant issue discussed at the recent Clinical Trial Ontology workshop concerned the peculiar HL7 practice of identifying events (for example events of drug interaction) with their observations. This practice is, gratifyingly, less pervasive in the BRIDG model of protocol-driven clinical research than in HL7, but it raises its head even there, for example in the identification of adverse events as adverse event assessments at:

CTOM (imported package)::AdverseEvent
Type: Class Extends: Assessment.
Status: Proposed. Version 1.0. Phase 1.0.
Package: CTOM (imported package)
Details: Created on 1/5/2005 11:17:58 PM. Modified on 9/26/2005 2:22:53 PM.

in BRIDG Model Version 1.41.

The issue raised at the Bethesda workshop was: why does HL7 persist in instituting what, on the face of it, is an obviously false assertion, as a central pillar of its information model?

This question becomes all the more important given that, increasingly, the task of adverse event assessment will occur at geographical sites remote from the adverse events themselves -- something which is logically impossible where adverse events are identified with their own assessments. How, on the basis of such an identification could we track shortfalls (for example in hospital practices or equipment) leading to adverse events in the hospitals themselves in such a way as to distinguish them from shortfalls in practices or equipment leading to poor assessments at remote assessor sites?

Perhaps the ever resourceful ingenuity of HL7's coders can find some complex coding procedure to keep these things apart even after having already identified them; but why not keep them apart from the very start, as simplicity and realism (and learnability and economy and patient safety) would suggest?

Two answers present themselves:

1. that we have here yet one more example of the influence on early HL7 of the focus on healthcare billing -- adverse events themselves, unlike observations and assessments, cannot be billed.

2. that HL7 RIM (and to this degree also HL7 tout court) is an information model -- so that 'adverse event' means: 'information about an adverse event', 'adverse event assessment' means 'information about an adverse event assessment', and so on.

But answer 1. seems not to be in keeping with HL7's current, and much more ambitious, goals. And answer 2. does not, in fact, support the given identification, since even on this meta-level, information about an adverse event and information about adverse event assessments remain distinct, and the former is not a subtype of the latter.

HL7 and BRIDG

The NCBO organized a Clinical Trial Ontology Workshop at the NIH in Bethesda, MD on 16-17 May. Two talks, especially, were of relevance to HL7, given HL7's influential role in the BRIDG project. The first, by Werner Ceusters, pointed to certain problems with BRIDG, which might be resolved by means of a principled ontology of the clinical trial domain.
The second, by Barry Smith, raised certain issues as to the apparent conflict between what seem to be two goals underlying BRIDG, to serve both as a descriptive representation of protocol-driven clinical research and to serve as a prescriptive standardization of such research.
BRIDG representatives at the meeting pointed to the new release of BRIDG, which is due in June 2007, and in which, we are told, some of these problems will be addressed.

HL7: A Package of Decorators

"Implementation of org.hl7.rim.Role as an abstract decorator, i.e., a class that returns NULL/NA or nothing for all property accessprs (sic) amd (sic [indeed many times sic]) that raises UnsupportedOperationExceptions for all mutators. This is used to adapt custom application classes to the RIM class interfaces and only bother about mapping those properties that actually apply to the application class. This can be done in one of two ways: (1) the client class can extend the decorator directly, and implement the applicable properties, or (2) the abstract decorator can be extend (sic) to a concrete decorator, which would hold a reference to the client object and method bodies to delegate and adapt the applicable properties."

Update: July 9, 2009
The quoted package, now here, was originally posted here, where it remained for almost two years before being taken down in 2009. The misprints which it contains (including misspellings of 'and') are of interest only because they are repeated over 6o times in a single document, suggesting that the document itself was never (proof)read by any human being.

The Mysteries of HL7 and Object Oriented Modeling, from Gerard Freriks

(Posted with permission.)

Reading
http://informatics.mayo.edu/wiki/index.php/Adding_Record_Target_to_ControlAct
I noticed the following exchange:

Rene: using this argument, all kinds of commonly used payload participations and associations would end up at the entry Act of the static model (whatever that entry Act would be, given that the Wrappers R2 project may introduce a Conversation/Contractual Act as the static entry point). Whilst introducing a common XPATH expression to access the recordTarget, (a) for other things one would still have to go to the payload model, (b) it increases reliance on sender/receiver understanding the inheritance and propagation mechanism thereof in the models - the understanding of which is currently probably limited to a dozen people worldwide. From an implementation standpoint this is not desirable.

Lloyd: Receivers must understand propagation between the wrappers period. That is not optional. Placing patient in a consistent place for all models actually makes implementation easier, not harder. This isn't about "common usage", but rather about data that has specific uses other than merely pertaining to the payload.

If I'm interpreting correctly, one expert (Rene) is of the opinion that the inheritance and propagation mechanism in the HL7v3 models is understood by no more than a dozen people worldwide. This means that only a few persons know how HL7 is deploying Object Oriented Modeling. I don't think that I'm wrong in thinking that millions of people know the Object Oriented Modeling techniques made popular by OMG and UML. Why, then, is HL7 using an abnormal, rather than a standard, way to deal with classes and propagation of attributes? Do they do this in order to ensure that only a handful of people will understand it properly?

Reading Lloyd's reaction, it is clear that he expects all implementers to know what only a handful know.
Poor implementers of HL7v3 artefacts.
My conclusion: A handful of experts has created a very nice niche for themselves to provide valued and needed expertise.
Gerard

On HL7 V2, from Ira Kalet

(posted with permission)

You probably will recall my reluctance to say much about HL7 at the very interesting panel discussion at the AMIA meeting last Fall. It was largely because of my lack of familiarity with it. Recently, in an effort to write a section on HL7 and laboratory data for my book, I have delved a lot further into it. I now take issue with only one statement you made. You said you have no complaint about HL7 version 2.x; your objections were directed to HL7 V3 and the RIM. Now that I understand version 2.3.1 and have had some in depth discussion with Dave Chou, my local source of HL7 expertise, I must note that version 2 is a disaster as well.

Version 2 has the virtue that it does not have ontological pretensions, and only claims to be a message transmission protocol. It appears at first sight to have been well thought out, even having an appendix with BNF definitions for messages and segments. On closer inspection, these definitions are wimpy. The text says that they are not to be relied on, that variants not precisely described are allowed. Further, while the overall structure of a message is somewhat specified, the actual content uses a very incompletely specified vocabulary. This is rather like saying we agree to more or less use English grammar but we don't have a common dictionary. It is really true. Some HL7 implementations generate messages using a vocabulary that is unknown to the receiving systems. Sometimes there are synonyms, sometimes not. It is a lot like the differences between different dialects of English (British, Scottish, Bostonian, East Coast American, Southern, Texan, Australian, etc.). Humans handle this reasonably well, but it is a lot of work for a computer program to deal with it. The so-called HL7 interface engines apparently do a lot more than just relay messages, they actually (according to Dave) do translations of messages on the fly. Much work is expended to create these custom translations, so that implementing HL7 is much costlier than implementing DICOM. There are many more dialects of the data vocabulary than there are of English.

DICOM is truly plug and play - if a DICOM data source claims to be able to send certain classes of data and another claims to be able to receive it, all you do is put in the sending system the destination address of the receiving system, turn them on and you are done. If they don't work together one or both of them has violated the specification and should be fixed. Not so with HL7. The HL7 documentation admits as much.

It is interesting that this service of getting data from place to place is so important that people are willing to pay the price of implementing an undisciplined, unruly communication scheme, but they are unwilling to agree on a precise common language.

I needed to vent to someone, and I expect that you would be sympathetic.

Thanks,
Ira Kalet

PS: The success of DICOM is that while it has an "object model", the model is about the image data and not about the things radiologists see in the images (i.e disease processes, etc.). An image is an array of numbers, along with some other data that are also describable without resort to inconsistent meanings. Things like the settings on the Xray tube (voltage, current, energy) when the image was produced, the size in patient space of the pixels, whether contrast was used, the name of the patient being "imaged". I see no fundamental obstacles to taking the same concrete approach to laboratory data and all the other things that HL7 talks about. In all my conversations, it seems to come down to a resignation to live with and evolve what was done already. It reminds me of the joke: "Why did it take God only 6 days to create the entire universe?" Answer: "He didn't have to make it backward compatible with an installed base."

PPS: See now Ira Kalet, Order and Chaos in Medical Data Communication: DICOM and HL7

Interesting Post from HL7 Connection re HL7 V3

From the HL7 Connection blog:

"Has anyone successfully implemented version 3? In my spare time I have been reading everything I can find on best practices and potential pitfalls."
Posted 3 days ago #
leaf999Member

"Why? There is no viable business model. The vendors with current market share have been quite sucessful with v2 interfaces. There are no clear advantages. The v3 data model is not a model of the interface record but rather of an application database. Why would vendors abandon their proprietary advantages developed at significant expense in order to re-develop their product as a comomdity offering, particularly when there is limited, if any, consumer demand (at least in the US).

The only US vendor (if you can call them that since they have no application product that has been implemented in a sucessful domestic healthcare setting) is Oracle. Last time I looked their only sign-up was Quadramed - which has since abondoned the effort (or so I was told by one of their application develoment managers.

Right now, if I were starting fresh, I'd implement v2 using XML.

While I'm at it, where is the formal transition strategy for mixed v2 & v3 interface settings. In my thirty some years in the field I've learned that the transitions are a very big deal.
This issue has popped up at the technical steering committee meetings for well over half a decade with no progress seen, or am I wrong?

What made HL7 such a success was its proclivity for the practicle real world needs of healthcare organizations and vendors. Now we have the Europeans mucking up HL7 the way they did CEN TC251.

The English NHS project is several years behind schedule, over budget, and gaining a reputation for 'shooting the sled dog vendors in the head' (thats a direct quote from a the senior english Government offical) - and they have taken v3 and bastardized it to the point that it could not be considered a standard approach to application interfaces outside the NHS.

The proof comes when one learns that the HL7 Board tried several years ago to discontinue further iterative enhancements to v2 telling committee chairs (I was one)that they should abandon additional v2 development. This edict was later recinded. I would see this as a clear indication that it was the result of the healthcare community having their say.

In my humble opinion, after more than a decade of development, HL7v3 is stillborn. I'm very unhappy about the situation and I very much hope I'm wrong. Please show me the error of my thinking - believe me when I say I'd be delighted. Until then I'll continue to recommend the use of v2 interfaces using XML."

Connecting for Health: A Glimmer of Light: Part 2

Tim Benson has posted the following Comment on my "Connecting for Health: A Glimmer of Light":

You obviously did not read my article carefully. NHS Connecting for Health has resolved to base future clinical messages on HL7 CDA Release 2 - not CDA release 1 as you imply. HL7 CDA Release 2 is an implementation of HL7 V3, which includes structured clinical data, using the HL7 Clinical Statement Pattern, together with an additional human-readable rendering of each part of the message. This is valuable for recipients with legacy systems who cannot yet process fully structured messages. As such, CDA Release 2, which became a standard in 2005, is an enhancement on earlier HL7 V3 messages, which do not have a human-readable component.

Nowhere, however, did I state that CfH was planning to use Release 1 of CDA. Rather, I merely expressed the thesis that Release 1 is a well-crafted HL7 artifact because it is free of the peculiarities of the RIM.

Here is the news item I cited concerning the change at issue:

CfH simplifies HL7 implementation

NHS Connecting for Health (CfH) has confirmed industry reports that it is planning changes to the implementation of HL7 within the National Programme. The planned changes will make greater use of the clinical document architecture (CDA) and will allow messages to be exchanged through electronic documents rather than through the fully encoded HL7 messaging format.

A spokesperson for CfH played down the significance of the change, describing it as ‘technical’: “We’ve not abandoned SNOMED coding or HL7v3 messaging. The CDA is a small technical change that better facilitates the carrying of fully coded messages in some circumstances." (Emphasis added)

From this I infer that the use of CDA will allow messages to avoid the 'fully encoded HL7 messaging format'. A glimmer of light, then, as is testified to also by the following Comment to Tim Benson's article:

Eureka!
The adoption of the Clinical Document Architecture standard by CfH is a great move albeit an inexplicably belated one. It massively reduces the barrier to entry for system suppliers. CDA is implementable now (indeed it has been in other countries in Version 1.n). The NPfIT message implementation manual has previously mandated a 'hardcore' HL7 V3 Clinical Statement approach. This was fine for suppliers with a team of Regenstrief Institute post-docs on their development staff, no legacy to consider and a decade to produce something functional. Those vendors without these advantages can now deliver something of immediate major clinical utility while remaining consistent with more sophisticated standards as a final destination. Tim, when/where is the official announcement of this change?

In the article itself, Tim Benson writes:

The NHS Connecting for Health programme has recently resolved to use HL7 CDA (Clinical Document Architecture) for future clinical messages.

So, not fully encoded HL7 v3 messages, then. Sounds good to me. Tim goes on:

The central idea of CDA is that each message includes a human readable representation of its content, which has persistence and can be authenticated, and may also contain structured clinical data, defined using the HL7 V3 clinical statement model.

Is what is being stated here that each document shall include both a message and a human readable representation of the content of this message? And that, in addition to both of these, it may contain also structured clinical data, defined using the HL7 V3 clinical statement model? So three sorts of content? The last of which is optional?

Tim writes:

If you want managers’ support, the computer system has to help the bean counters. If you want clinicians’ support, the information system has to help clinicians communicate efficiently and effectively. CDA provides a way of supporting both requirements.

... The innovative aspect of CDA is that all CDA documents can be rendered in a human-readable way for viewing using a browser, while coded and other structured data can also be included to enable clinical decision support, audit and analysis.

As I understand matters, the NHS is using CDA release 2 mainly because they want to be able to have human readable rendition of the data in the document. No structured data is allowed that does not have a corresponding text rendition. What I am unclear about is whether textual portions are allowed in CDA documents without any corresponding structured data (as Tim seems to imply with his use of phrases like 'can also'). Will those whose legacy systems cannot yet process fully structured messages be allowed not only to process (i.e. read) these human-readable renderings, but also to incorporate (i.e. write) human-readable material of their own into CDA documents?

And what, precisely, is the formal relationship between the textual part of an NHS-style CDA and the structured part? What is the 'standard structure for exchanging data' that is provided by the CDA (other than, say, English) to which Tim is referring for example here:

CDA provides a standard structure for exchanging data in a way that supports person-to-person communication alongside structured countable data.

These questions are not trivial. They relate to the very core of the relation between CDA and HL7 v3 messaging.

Here is what HL7 itself has to say about the matter:

A CDA document is wrapped by the element, and contains a header and a body. The header lies between the and the elements, and identifies and classifies the document and provides information on authentication, the encounter, the patient, and the involved providers. The body contains the clinical report, and can be either an unstructured blob, or can be comprised of structured markup. A CDA document section is wrapped by the

element. Each section can contain a single narrative block and any number of CDA entries and external references. The CDA narrative block is wrapped by the element within the

element, and provides a slot for the human readable content needing to be rendered. Within a document section, the narrative block represents content to be rendered, whereas CDA entries represent structured content provided for a computer. CDA entries encode content present in the narrative block of the same section. CDA external references always occur within the context of a CDA entry, and are wrapped by the element. External references refer to things that exist outside the CDA document — such as some other image, some other procedure, or some other observation (which is wrapped by the element). The CDA entry that wraps the external reference can be used to encode the specific portions of the external reference that are addressed in the narrative block.

All of this speaks in favor of optionality, it seems to me. So light is glimmering still.

Connecting for Health: A Glimmer of Light

Interesting news from the United Kingdom, where so much effort and treasure have been expended in the last two years in attempting to base a national system for health information exchange on HL7 v3 messages. The HL7 approach is based on the requirement that a new kind of message should be created for each of the many separate kinds of information transmission. Once again, this requirement has proved economically unfeasible to implement in a non-toy environment.

Miracle of miracles: the UK National Health Service has decided not to use HL7v3 for clinical messages.

The NHS describes this as "a small technical change that better facilitates the carrying of fully coded messages in some circumstances." This is, however, to downplay the huge significance of the choice. It means that the NHS, after huge efforts on the part of some of the best minds in health IT, has found that HL7v3 messages are just too painful and difficult to use. Connecting for Health will use instead the Clinical Document Architecture (CDA), which is the HL7 document format, and which -- in version 1 at least -- is one of the few well crafted pieces of HL7 artefact. This means, in effect, that CfH is moving to a single generic message that is able to take anything as payload. This is a complete dis-endorsement of the HL7v3 message approach by HL7's biggest supporter (by far) -- hence the attempt to downplay it politically.

Unfortunately, there are still issues remaining. CDA is a single-document specification; thus it has no provision for cross-document linking or for EHR repository versioning. CDA is heavily text oriented, and although it can store some structured content, the definition of that content at the entry level is limited to RIM types. Thus, we predict, many of the familiar problems of v3 will be thrown up once again.

Death by UML

As is well known, HL7 v3 follows, in some uncertain way, an object-oriented developmental methodology modelled on the UML approach. The essay "Death by UML Fever" by Alex E. Bell of the The Boeing Company throws interesting light on UML, which may help us in understanding also some of the peculiar phenomena associated with HL7:

UML fever: A potentially deadly illness plaguing many software-engineering efforts today, the most important strains of which are:

Blind adopter fever consists in a loss of judgment on the part of software engineers "when it comes to assessing appropriate usage of available technologies and processes for their own programs. ... Engineers afflicted with blind adopter fever have been observed to blindly force state machine semantics into all of their classes just so they can take advantage of forward engineering technologies that convert UML diagrams into code. ... A side effect of using such processes is wasting time and money on producing many unnecessary artifacts."

Curator fever: "Much as a museum curator has a fascination and passion for paintings, those in the software engineering realm afflicted with curator fever have a similar absorption in UML diagrams. This absorption is fueled by curator fever's propensity to delude its victims into believing that production of UML diagrams, as opposed to the engineering content behind them, is the single most important activity in the software-development life cycle. A commonly observed behavior by those in the grips of curator fever occurs when domain analysts create volumes of use-case diagrams but remain oblivious to the fact that the most important artifact of use-case modeling is developing the supporting text. UML interaction diagrams with messages analogous to 'solve world hunger' between objects are of little value to any stakeholders."

Desperation fever is associated with project traumas such as slipped schedules, low productivity, and poor product quality. "A symptom of those plagued with desperation fever is flattened ears that result from spending inordinate amounts of time on the telephone speaking with vendors in search of products that will solve all known project woes. ... The severity of desperation fever typically escalates as the result of highly paid consultants telling afflictees that newly purchased products will not bring benefits without major overhauls to existing software-development practices."

Open loop fever: "The effects of open loop fever stimulate the urge for rampant creation of UML diagrams with no traceable objective or having no obvious stakeholder. Victims of open loop fever believe that the act of creating UML diagrams alone is a guarantee of value-added activity. Clinical research has suggested that individuals most susceptible to open loop fever are those who have never been end users of UML diagrams and those whose ride on the software life cycle has been very limited."

Gnat's eyebrow fever is recognized "by a very strong desire to create UML diagrams that are extremely detailed. ... afflictees of gnat's eyebrow fever emphatically believe that it is important to model to very low levels of detail because doing so increases the probability that the resulting code will be more correct. Because of variables such as flux in system requirements and dependent design activities occurring in parallel, for example, the time spent on low-level modeling is often better applied to actual implementation. Clinical research has shown a high affliction rate of gnat's eyebrow fever in those modelers who have not actually participated in coding activities."

Round trip fever: "a complete loss of the ability to use abstraction as a means of managing the complexities of software design."

For Bell , the above maladies derive not so much from problems with UML itself, but rather from poor process, no process, or sheer incompetence of its users. For more background regarding UML itself, however, see Bertrand Meyer, "UML: The Positive Spin".

British Computer Society report calls for overhaul of NHS IT project

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

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

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

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

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

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

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

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

Alan Rector on SNOMED, HL7 and Quality Assurance

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

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

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

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

AMIA Panel on the Future of HL7

This panel will take place at 3.30-5 p.m. on Tuesday November 14 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 Lanches 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.