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 vocabulary list. (Dan played a key role in the development of the HL7 Reference Information Model.)  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 responsible 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, 2006 as part of the Annual Symposium of the American Medical Informatics Association in Washington DC. Panelists are:

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

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

Harmonisation: CEN and HL7

by Gerard Freriks, former chairman of CEN TC251 WG1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Is the HL7 RIM an ISO standard? Really?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

They have been used for :

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

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

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

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

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

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

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

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