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 [See update below]
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.

Update August 2011: http://www.iso.org/iso/catalogue_detail.htm?csnumber=35646 now published as an ISO standard.

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.


Postscript May 23, 2011

See also now here: http://wolandscat.net/2011/05/18/the-hl7-null-flavor-debate-part-2/

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