HL7 is brooken.

A problem has been identified on the HL7 email lists concerning the degree to which the receiver of a message or document can reason out what its meaning is automatically, merely by inspecting what is received.

As Lloyd McKenzie puts it, under the current regime, "Converting a standard lab, pharmacy or other instance into a generic RIM instance will be easy. The tricky bit will be the reverse process - converting instances expressed as generic RIM in the content of a CDA and parsing them into the domain-specific structures. For many static model designs, there isn’t necessarily a deterministic path (due to looseness of constraints in the models)."

The very point of the RIM, however, is to provide determinate interpretations of messages. If such determinate interpretation is no longer available, then (as the Dutch say) HL7 is brooken.

We provide the context of Lloyd's remark in what follows. Minor corrections have been made for readability.

From: “McKnight, Lawrence (H USA)”

Date: 20 augustus 2009 23:26:51 GMT+02:00

To:

Subject: FW: What is the technical difference between a pattern, dmim, rmim, cmet, and template.

With the goal of making similar content look similar across domains or between organization[s] defining models or constraints, and regardless [of] which kind of exchange method is used, I’m asking for clarity on what logical differences exist between the modeling constraints on the RIM and how a CMET or RMIM is different from a Template. I for one am increasingly unclear on the hows and whys of this. Lloyd said he would provide the follow up answers.

To make things more concrete, here is a (mostly real) example which might provide better clarity to work from.

Org H (an organization independent of HL7) would like to take advantage [of] the great work that HL7 has done and write implementation guides that reference HL7 specifications and requirements it has been given by the US government.

The requirements given to Org H are:

1) At the point of discharge from the hospital, patients should receive a stuctured document that contains their meds, allergies, problems, and labs, and instructions that they could import into their PHR.

2) Primary care doctors receive a similar but different[ly] structured document that contains the meds, allergies, problems, but also a listing of vital signs, and a brief narrative of what happened in the hospital. This document should be available for future reference in a document archive.

3) The hospital should send labs and vital signs via unsolicited messages as real time feeds to the PCP’s office.

Org H would like to ensure that the structural representation look[s] the same in all the documents and messages (e.g. a med structure as similar as possible regardless of being passed in a message or document or service). They would like to ensure that the same terminologies get bound in all use cases (eg RxNorm SCD for meds, SNOMED for problems, LOINC for labs, etc.). Finally, to mix things up, they would like to use a constrained detailed clinical model of vital signs from an organization outside of HL7 (say IHE). To mix it up even further, let’s say that meds need to have conditional elements such as “hold if systolic BP is <100”, or “give 3 units for a glucose between 150 and 200”, where the same structured vital sign or lab observations are used in the model for the medication intent or the independent message.

Finally, there is a requirement that a certification agency be able to check and enforce that the implementation guides are being followed.

Now, let’s assume ideal conditions [where] we have CDAr3 with a new improved “right side” that references a generic RIM model and can represent everything.

How should the Org H implementation guides be written to reference the appropriate constraints from the various organizations while ensuring that the appropriate constraints from the HL7 domains gets used (e.g. the pharmacy RMIM is followed for meds in the patient summary document)? How does the pharmacy domain ensure that it references the correct models in its conditional element? How does the structured documents domain ensure that a document implementation guide uses the pharmacy model?

How does IHE place its constraints where Org H can apply it to the appropriate models?

In all of this, what gets done in a pattern, a RMIM, a CMET, or a template? And why (e.g [because] this constraint could not be [used] in XX because XX doesn’t have ...)?

Please help. I’m confused.

Larry.

-------------

From: Lloyd McKenzie

Date: 25 augustus 2009 07:55:14 GMT+02:00

To: “McKnight, Lawrence (H USA)”

Cc: clinicalstatement@lists.hl7.org, MNM List

Subject: Re: FW: What is the technical difference between a pattern, dmim, rmim, cmet, and template.

Reply-To: Lloyd McKenzie

Hi Larry,

Sorry for the delay in my promised answer. I’m copying MnM as the answer may be of interest there as well.

First off, DMIMs, RMIMs CMETs and Templates are all examples of static models. HL7 does not currently have (and has never had) an artifact called “pattern”. We use patterns in many of our artifacts and there is an MnM project that captures and documents common patterns that have been found to be useful in designs. However, these are generic structures such as “how do you capture the assigner of an identifier”. I therefore won’t talk about patterns further.

In the methodology, there are four different types of static models. They are:

RIM - Domain Information Model - there’s only one in the HL7 world, you’ve probably seen it once or twice ;>

DIM - Domain Information Model: These are high level models reflecting a group’s understanding of a particular healthcare domain. They frequently have multiple entry points and are not intended to be serialized. They may have a mapping to a committee’s Domain Analysis model. It is possible to create DIMs that are constraints of another DIM, though that doesn’t happen very often.

CIM - Constrained Information Model (possibly to be renamed SIM - Serializable Information Model): These are serializable models. In previous modeling terms, they were called RMIMs, HMDs and Message Types. In the new methodology, they’re all called CIMs and we aren’t limited to exactly 3 levels of constraint. I.e. a CIM can constrain another CIM which constrains another CIM which constrains  . . .  which constrains a DIM. You can have greater or fewer levels as necessary. CIMs tend to be balloted and they determine what the wire format of an instance will be. They are used by the ITS to generate schemas.

LIM - Localized Information Model: These include templates and the static portion of conformance profiles. They have the same rules as a CIM, but represent a set of constraints applied “on top of” a CIM, or for templates, for parts of a whole whack of CIMs. They don’t have any impact on the wire format which is determined by the parent CIM. LIMs aren’t usually balloted, though they can be. Some specifications, like CDA, depend on LIMs for interoperability because the base CIM (that determines the schema) is so generic it’s hard to conform with directly. Templates can be invoked at any node within a CIM. Profiles begin at the root node of an interaction and cover the entire model. Profiles define “what’s allowed/expected” in a particular implementation environment or what’s actually done by a specific system. While there may be 100s of balloted CIMs, there will be 10s or 100s of thousands of templates covering all sorts of detailed structures for various disciplines and needs.

CMETs (Common Model Element Types) are a way of referencing one CIM from another CIM. Essentially a CMET is an interface that can be referred to by multiple static models. It is bound to a specific static model in a particular release of a specification in a given realm (in the cmetinfo.txt file). E.g. For release X in Canada, the CMET “AssignedPerson-Informational” is bound to CMET COCT_MT123456CA. The point of CMETs is to allow common static model fragments to be re-used and applied consistently. So things like patients, locations, providers, etc. that are referenced by numerous models can be defined a few different ways to meet common use-cases and then get re-used all over the place.

Similar to CMETs are a structure called “stubs”. Like CMETs they are interfaces in a model that say “reference something like X here”. However, unlike CMETs, stubs aren’t bound for an entire release. Instead, they’re bound for the creation of an interaction. Models that contain stubs are called “wrappers”. That’s because they’re not complete in and of themselves. Interactions that reference them also need to ‘bind’ the stub (or stubs) in the wrapper to point to another model. The model pointed to might itself contain one or more stubs that also need to be bound. At the moment, we tend to have two layers of wrappers - transmission and controlAct. However, the methodology allows for more layers where it’s userful. For example a batch might contain a message which contains a controlAct which contains a claim which contains a billable act.

As to your more specific questions:

- The “profile” created for your document could (and should) reference separate sub-LIMs (templates) that represent constraints on the various domain models (pharmacy, patient care, lab, etc.)

- The conditional element within pharmacy would probably be defined solely within pharmacy. It’s a generic criterion and isn’t a model drawn from a particular healthcare discipline. The capturing of blood pressure would be patient care and the measuring of glucose would be lab. The conditional statement is still pharmacy.

- Structured documents can’t ensure that a document implementation guide developed and approved outside of HL7’s process uses the appropriate domain models. However, I’d like us to get to a place where there’s an expectation that implementation guides developed and balloted within HL7 *would* be expected to be aligned with the appropriate domain models and failure to align (without a documented and convincing reason :>) would be grounds for negative ballot.

- As for how IHE fits in, I have no clue. They’re just one organization that can create (and promote) implementation guides. I would hope they would follow good practices and leverage domain content rather than applying constraints on their own. Whether they always will, I don’t know.

Lloyd

-----------

From: “McKnight, Lawrence (H USA)”

Date: 25 augustus 2009 16:14:49 GMT+02:00

To: “Lloyd McKenzie”

Cc: , “MNM List”

Subject: RE: FW: What is the technical difference between a pattern, dmim, rmim, cmet, and template.

Thanks, Lloyd.

I learned a little, but still have questions.

I was unaware of the RMIM->CIM change, but welcome that. The remainder fits my understanding.

Unfortunately, the issue remains. In document profile, I know of mechanisms to use LIMs. For example, CCD uses “conformance statements”, which are currently executed in the form of a schematron check. Presumably, a similar mechanism could be applied to apply a LIM constraint to messages or services as well.

But I’m not clear on a mechanism to apply a CIM to a document, and that’s generally where the modeling differences arise. The need is to create a document profile, that might include for example a medications section, and in that medications section specify that an individual medication use[s] the same modeling [as] in the pharmacy CIM (perhaps with additional constraints from the LIM). My gap [is] in understanding how that would work using CIMs. It would seem that the CDA r3 spec would need to include not just the ‘RIM on the right side’ but also every CIM!

So, is it possible to apply the constraints of a CIM to a generic model outside of the HL7 tooling (e.g. use a CMET in a profile)? If not, is it possible to convert the constraints of a CIM to a LIM-like structure (e.g. as a template) and ensure alignment? It seems [as though], functionally, they are equivalent structures (they both apply a set of constraints on the RIM plus a starting base of constraint[s] defined by somebody else). The main difference seems to be that they are applied by different organizations at different points.

I think we all agree that we would like alignment. But, your statement

“... can’t ensure that a document implementation guide developed and approved outside of HL7’s process uses the appropriate domain ...”

doesn’t capture the issue. It’s not that these implementation guides could or need to be bound. Other organizations will do what is reasonable. But, it’s generally easier to re-use the same where they can. The issue is that we prevent them from doing this. Part of the problem is that, as you mention, the ‘right hand side’ of CDA is limiting. The other part is more pragmatic. Unless I’m misunderstanding how CIM’s can be applied, we are making it next to impossible for the domain models to be appropriately referenced by outside organizations. The statement above is saying, we can’t control this, therefore we don’t care. Is it any wonder other organizations don’t do the right thing and reference models appropriately? It’s true that we can’t control this, but we do care. Therefore, we should make it easy to do the right thing. Currently it doesn’t feel like we’re doing that.

Larry.

----------

From: Lloyd McKenzie

Date: 25 augustus 2009 17:13:42 GMT+02:00

To: “McKnight, Lawrence (H USA)”

Cc: clinicalstatement@lists.hl7.org, MNM List

Subject: Re: FW: What is the technical difference between a pattern, dmim, rmim, cmet, and template.

Hi Larry,

The RMIM/HMD/MT -> CIM change is part of the methodology but not the tooling or publication process yet.

In answer to your question, you can treat any CIM as a LIM. The only difference is the “intention to affect element names”. Personally I would welcome a situation where the actual wire format of a prescription in CDA was the same as it was in a message type. This could be done by making Entry a “stub” and the CDA structure into a wrapper. However, given the strong desire to see a single schema for all CDAs, that might not fly. (You could still have a single schema for generic CDA, but it would end up having xs:any for the entry content and I don’t [think] that would be acceptable to some.)

So our models certainly can be referenced. In most cases, they wouldn’t be referenced directly anyhow. Instead, someone would create a LIM that is a proper constraint on a CIM because odds are they’ll want to be a bit tighter than the UV message specifications for a given area (for example, specifying vocabularies, limiting some repetitions or recursions, etc.)

Lloyd

--------------------------------------

From: “Buitendijk, Hans (H USA)”

Date: 25 augustus 2009 18:17:06 GMT+02:00

To: “Dan Russler” , “Lloyd McKenzie”

Cc: “McKnight, Lawrence (H USA)” , , “MNM List”

Subject: RE: FW: What is the technical difference between a pattern, dmim, rmim, cmet, and template.

Reply-To: “Buitendijk, Hans (H USA)”

Can you expand the clarification such that we could see how the approach suggested for CDA R3 can be consistent with / be applied to Composite Order such that the same data communicated as part of a document is expressed the same when communicated as part of a Composite Order?

Hans J. Buitendijk

HS Standards & Regulations Manager

Siemens Healthcare

------

From: Lloyd McKenzie

Date: 25 augustus 2009 18:28:39 GMT+02:00

To: “Buitendijk, Hans (H USA)”

Cc: Dan Russler , “McKnight, Lawrence (H USA)” , clinicalstatement@lists.hl7.org, MNM List

Subject: Re: FW: What is the technical difference between a pattern, dmim, rmim, cmet, and template.

Hi Hans,

The idea would be that when sending data appropriate to a particular domain (lab, pharmacy, claims, whatever) the “template” applied to the entry portion of the CDA document would be a static model that is a proper constraint on the published CIMs (RMIMs, Message Types, etc.) of the appropriate domain. The wire format could still be a generic RIM syntax if that’s what’s decided by Structured Documents. Converting a standard lab, pharmacy or other instance into a generic RIM instance will be easy. The tricky bit will be the reverse process - converting instances expressed as generic RIM in the content of a CDA and parsing them into the domain-specific structures. For many static model designs, there isn’t necessarily a deterministic path (due to looseness of constraints in the models). Therefore we may need to take advantage of embedded template cues to assist in the parsing process.

Lloyd

BFO vs. HL7 RIM

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

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

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

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

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

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

Werner Ceusters and I have sought to address these challenges here (a new version, here, addresses comments made by Christos Louis and posted below). Responses from the HL7 community are welcome. At the same time we have issued to Cecil, and through him to all afficionados of the RIM, an analogous challenge:

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

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

Update November 3, 2009
From: <clynch@surewest.net>
To: "Werner Ceusters" <ceusters@buffalo.edu>; "Barry Smith"
<phismith@buffalo.edu> Cc: <R.Cornet@amc.uva.nl>
Sent: Tuesday, November 03, 2009 3:47 PM

Thanks to you both for the explanation (and education) and to Barry's point about my "unfortunate" criticism of BFO, I am beginning to be convinced but I am not sure I understand (or am yet convinced) that BFO would handle all that I would like to communicate, or could communicate in medical notes.
I suspect that my lack of convincing is more a case of my lack of use of BFO than anything else and I resolve to try a deeper application and comparison with the information model that I would normally use to define these parameters, namely an HL7 V3 model. I do think this would be a good follow on to this exercise, i.e. an expression of this same issue in a V3 model such as the CDA for Infectious disease case reports.
This has been a very enlightening exercise for me.
Thanks
Cecil

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

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

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

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

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

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

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

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

Can Microsoft Healthvault Do a Better Job than HL7?

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

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

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

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

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

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

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

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

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

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

Should an Organization like HL7 be Engaged in Building Standards?

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

The author begins by pointing to the long-standing assumption

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

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

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

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

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

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

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

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

timelines for delivery are notoriously unreliable;

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

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

"Non-ambulatory status" in HL7 Version 2

3.4.3.15 PV1-15 Ambulatory Status (IS) 00145

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

Examples:

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

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

HL7 and SNOMED CT - The Book

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The Multiple Joys of HL7 V3

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

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

• Care Record

• Clinical Genomics Pedigree


• Clinical Document Architecture


• Clinical Statement


• Common Message Element Types


• Public Health Reporting: Individual Case Safety Report


• Periodic Reporting of Clinical Trials


• Laboratory Results

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

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

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

Update August 12, 2009

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

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

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

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

Subject: Re: Use of Domain Models

Hi Keith,

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

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

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

Thanks,

Amnon.

Sent by: Lloyd McKenzie

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

07/08/2009 04:37

Subject: Re: Use of Domain Models

Hi Keith,

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

Lloyd

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

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

Subject: RE: Use of Domain Models

Amnon,

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

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

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

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

Keith

Would Tightening the Definitions in HL7 Make Things Worse?

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

As he points out:

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

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

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

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


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

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

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

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

hoot72: An Ontology for HL7 v. 2.3

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

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

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

On Problems with HL7 Documentation and with HL7 XML

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

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

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

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

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

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

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

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

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

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

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

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

Comment 2 (to Big HIT) (responding to the identification of major problems with HL7 XML):
KC: HL7 XML is standard. It follows published W3C standards, which as far as most are concerned are the standards about XML which matter.
BS: Correct. But not all standards are equally good, I'm afraid. See, as concerns HL7 XML, the arguments here (summarized already here).
KC: HL7 itself is a ANSI SDO, and anything that HL7 publishes as normative BY DEFINITION is a standard.
BS: An ANSI standard, yes; all the more reason, therefore, to ensure that everything is checked very carefully before publication as normative, for example to ensure consistency.
KC: Finally, HL7 contributes, collaborates and uses the same ISO standard (21090) for data types, which is by-and-large the XML which makes up "HL7 XML."
BS: Unfortunately most HL7v2 and HL7v3 message standards do not follow this ISO standard. Moreover 21090 is not a full ISO standard. It is in the DIS-stage and therefore under development: http://www.iso.org/iso/catalogue_detail.htm?csnumber=35646 [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.