HL7 Watch

And now even CDA is troubled

noreply@blogger.com (Barry Smith) — Thu, 01 Dec 2011 13:30:00 +0000

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Bob Dolin
Sent: 28 November 2011 19:07
To: Structured Documents WG
Subject: RE: CDA or greenCDA

Wes,

Who is asking to have greenCDA sent over the wire, and what is their rationale?

I don’t agree with your learning curve statement. I would expect that most recipients would use a general purpose CDA parsing algorithm. In fact, if you deal with many types of CDAs, it can be harder to receive greenCDA, because you must insert an intervening transform step.

As for the cover about 80% of the requiremen this is because greenCDA is a simplification, that removes some CDA bells and whistles. Is not that greenCDA cant express anything that is in CDA, but that we make design decisions when simplifying.

As for Robert Words proposed rule Every Green CDA instance should contain the URL of a transform to take it to the full CDA it is derived from I dont think that is sufficient. I think ll need to ballot greenCDA schemas (e.g. a greenConsolidation) if we are to use it as a wire format.

Thanks,

Bob

Bob Dolin, MD, FACP

President and Chief Medical Officer

Lantana Consulting Group

t: 714.532.1130

c: 949.466.4035

www.LantanaGroup.com

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of robert worden
Sent: Tuesday, November 29, 2011 3:33 AM
To: 'Bob Dolin'; 'Structured Documents WG'
Subject: RE: CDA or greenCDA

Hi Bob -

I think HL7 has two distinct groups of customers:

A. Those who understand the RIM and CDA; have several different use cases for CDA; and might have invested in a general-purpose CDA parsing algorithm

B. Those who don’t understand the RIM; have just one or two use cases to address; and want to do it as simply as possible.

We need to listen to all our customers, in both groups. I think those in group B greatly outnumber those in group A. In the UK I know they do, for a fact. Most healthcare providers and most IT suppliers simply dot want to know about the RIM; they just want to build the interfaces they need, with as little fuss as possible.

But it is the group A customers who have the time to invest in HL7 to come along to WGMs, attend weekly calls, follow threads like this, define the standards and take part in ballots. It is group A who have overwhelmingly defined the direction of HL7; whereas group B are the majority of our customers. I think this systematic bias in our process has misled us over the years.

Green CDA suits group B just fine. They look at a Green CDA instance and say Yeah, I can do that.; whereas a full CDA instance induces silence and shaking of heads. So recommending Green CDA, without even saying: full CDA is the real thing; yd better send that over the wire is what suits group B.

But the great thing about Green CDA is this: provided we have reliable transforms in both directions (full <=> Green) we don’t have to choose between our customers, because both groups A and B can work the way they want to. The issue of what goes down the wire should become as trivial as to zip or not to zip; you just apply a transform to get the form you want. Also, Green CDA is a handy migration path for group B users who want to move to group A.

On your last point (transforms alone are not enough) I fully agree. The proposed rule was an additional requirement if Green CDA is to go on the wire, not the only requirement. I had assumed without saying that to publish any Green CDA, you should at least publish a schema to define its structure; and also (more important) publish its semantics in a RIM-independent for so group B can know what it means.

Best wishes

Robert

mobile: 07970 197968

landline: 01353 777668

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Pratt, Douglas (H USA)
Sent: Tuesday, November 29, 2011 9:52 AM
To: robert worden; Bob Dolin; Structured Documents WG
Subject: RE: CDA or greenCDA

In my experience helping implementers, the most frequent request I had was for examples of "how do you represent..." that may or may not be helped by Green CDA (as there currently is no Green CDA to evaluate).

Some common ones:

- How do I represent no known food allergies?

- How do I represent that the patient has positively asserted no known allergies vs. no information (not asked, etc.)?

- How do I represent that this allergy had an onset of "adolescence", when CDA requires a date?

- How do I send legacy codes along with their translation to industry code(s)?

- What data pertains to visits, and which across visits (CCD)?

I found that if I could provide an example, they could work with it. The markup was not really an issue in that case.

- Doug

From: Rishel,Wes [mailto:Wes.Rishel@gartner.com]
Sent: Tuesday, November 29, 2011 10:33 AM
To: Pratt, Douglas (H USA); robert worden; Bob Dolin; Structured Documents WG
Subject: RE: CDA or greenCDA

Are all the how do you represent questions you listed explicitly spelled out now in the CCDA?

I would note that the only guidance on the CCDA on sending blood pressures is a textual note under vital signs that says blood pressures should be sent as observations.

Wes Rishel
Gartner

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Bob Dolin
Sent: Tuesday, November 29, 2011 12:55 PM
To: Rishel,Wes; Pratt, Douglas (H USA); robert worden; Structured Documents WG
Subject: RE: CDA or greenCDA

Hi Wes,

What is CCDA?

Thanks,

Bob

From: Moehrke, John (GE Healthcare) [mailto:John.Moehrke@med.ge.com]
Sent: Tuesday, November 29, 2011 11:53 AM
To: Bob Dolin; Rishel,Wes; Pratt, Douglas (H USA); robert worden; Structured Documents WG
Subject: RE: CDA or greenCDA

I presume it is Consolidated CDA

Seems this is an effort to make this seem like not-CDA.

We need to be very careful at how all of this is perceived by the thousands of people who only get to see these efforts when they come up to breath. By bringing in yet-another-acronym, there will be more confusion. We really dont need or want confusion, right? We need to be working together to bring down the FUD, not make more of it.

John

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Rishel,Wes
Sent: Tuesday, November 29, 2011 5:31 PM
To: Moehrke, John (GE Healthcare); Bob Dolin; Pratt, Douglas (H USA); robert worden; Structured Documents WG
Subject: significant concer re Moehke's response (was RE: CDA or greenCDA)

John: Seems this is an effort to make [Consolidated CDA] seem like not-CD

I take substantial umbrage that John implies that I have a deep and dark motive to somehow separate CCDA from CDA, particularly as my recent blog talked up the CCDA as a significant step forward for the CDA. This style of innuendo really does nothing to advance discussion on issues. Many people properly discount ad hominem jabs like this, whereas for others it tends to deepen schisms rather than finding narrow points to build bridges.

A simple statement such as we must be careful that the acronym leads people to believe that the Consolidated CDA is something different than C would have raised the issue without appealing to conspiracy theory or implying that I had baser motives.

I make no bones that I have fear, uncertainty and doubt about the ability of the US to pull off a high degree of interoperability with the C32, how I think that CCDA is an improvement but that there is still more that needs to be done. However I do my best to address the issues, not the people, bring other experience into discussion and look for solutions. These are the same issues that I shared privately with Board when I was a member and held reasonably close until I had been off for awhile. After a while, though, I felt that the better thing to do was to express my issues on an HL7 list server rather than only in other venues.

Some would say that casting FUD is a bad thing. It is, when it is an attempt to obscure discussion on the issues. Just the same, decrying FUD is a bad thing if it is done for the same purpose.

I have actually learned a lot in the discussions over the last few weeks, some of which has been reflected in my blog. I would say, however, that if there are specific rules of decorum or a general sense on the blog that it should only be used for discussions that are pro the group sentiment, I would have to conform by going elsewhere.

This not the HL7 that I remember.

Wes Rishel
Gartner

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

Subject: RE: significant concer re Moehke's response (was RE: CDA or greenCDA)

Date: 30 November 2011 05:03:10 CET

To: "Rishel,Wes" <Wes.Rishel@gartner.com>, "Moehrke, John (GE Healthcare)" <John.Moehrke@med.ge.com>, "Bob Dolin" < bob.dolin@lantanagroup.com>, "Pratt, Douglas (H USA)" <douglas.pratt@siemens.com>, "robert worden" <rpworden@me.com>, "Structured Documents WG" <strucdoc@lists.hl7.org>

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

Wes, frankly, I read something very different in what John had to say, and I’m certain it wasn’t intended as a personal attack on you.

I deal with CIOs and CMIOs frequently enough who still stumble over CDA, CCR, CCD and C32 and cannot tell the difference between them, yet are responsible for making sure they’ve got whatever ‘it’ is, implemented correctly for their facility or practice. We just shifted the ground from underneath them with a new acronym. After all, if Bob Dolin doesn’t know what CCDA is, how could they possibly be expected to know it. You don’t set out to create FUD, there is no conspiracy, and nobody (at least in my reading) has accused you of starting one.

When even Bob Dolin has to ask you what CCDA is, it clearly delivers the point that this thing we’ve been calling the Consolidated CDA Guide needs a better name, and needs some marketing and customer education to explain to folks what it is. Adding YAA (yet-another-acronym) to the alphabet soup isn’t going to help. I’m already getting questions from the people who follow you at a policy level about what is CCDA, and even worse, there’s been other industry press describing this work that misquotes and misrepresents what it is.

If there’s a failure to communicate what the Consolidated Guide is, and there’s more FUD because of it, it isn’t your problem Wes, and you didn’t cause it. It’s HL7’s problem, and we need to fix it. That’s what I take away from John’s point.

As for names, there was some discussion of renaming for publication. It might well be worth bringing that back up and thinking about how to market this effort professionally. There’s a brand to be built here, a story to tell about what when into this work and the communities that built it over the last six+ years, and a community to educate about these guides and what they mean for their end users. HL7 as an organization doesn’t have a great history at doing that sort of marketing, but somehow we need to figure it out.

Keith

Keith W. Boone
Standards Architect
GE Healthcare

Some random news items

noreply@blogger.com (Barry Smith) — Mon, 19 Sep 2011 17:22:00 +0000

1. Exciting stuff from Grahame Grieve at Health Intersections. Summary: "HL7 v3 has failed".

2. And here an email of September 18 from Thomas Beale (with emphasis added by me) responding to Grahame's description of developments regarding RFH:

At the HL7 meeting last week in San Diego, Grahame Grieve presented something called Resources for Healthcare (RFH), essentially a replacement model for much of HL7v3, for 'practical use'. The driver was the well-known over-complexity of HL7v3. According to his report on the reception of RFH at the HL7 meeting, there appears to be a real appetite for change at HL7, which is good to see.

3. And an announcement from Gartner: HL7 V3 Messaging "has fallen off the hype cycle".

Snippets from the analysis by Wes Rishel in the current Gartner Hype Cycle report:

The V3 Messages (V3M) standard was conceived as being the direct analog of the Version 2 Messages standard — that is, XML documents designed to support the information necessary to be transferred when a specific event occurs, such as a patient being admitted or a lab result being approved for delivery to the provider. ... we describe the messaging part of the V3 suite as "obsolete before the plateau."... uptake has been so small and narrow that we cannot justify leaving V3M on the Hype Cycle.
Business Impact: V3M will not have impact except, perhaps, in a few locales.
Market Penetration: 1% to 5% of target audience

4. What is an 'Implementation Guide'

HL7 seems not to know how to define 'Implementation Guide' even as it pertains to its own standards:

Discussions with others revealed that there is not really any specific definition as to what an Implementation Guide is. The general impression is that anything that constrains a model is an implementation guide. The level of constraint is determined by the level of the guide (i.e. normative of informative). Given this fuzziness, calling this an implementation guide is not out of line with common use. (See here)

5. And finally this:

From: "Helen Stevens Love"
Subject: HL7 International Council Proxies - San Diego WGM
Date: 8 september 2011 21:53:09 GMT+02:00
To: "HL7 Affiliate Council"

Dear International Council Members,
Based on the pre-registered attendees for the upcoming San Diego meeting we may fail to reach quorum for our Council meetings. ...

HL7 v3: Songs of Twilight

noreply@blogger.com (Barry Smith) — Tue, 16 Aug 2011 15:08:00 +0000

1. Exciting stuff from Grahame Grieve at Health Intersections. Summary: "HL7 v3 has failed".

2. And here an email of September 18 from Thomas Beale (with emphasis added by me) responding to Grahame's description of developments regarding RFH:

At the HL7 meeting last week in San Diego, Grahame Grieve presented something called Resources for Healthcare (RFH), essentially a replacement model for much of HL7v3, for 'practical use'. The driver was the well-known over-complexity of HL7v3. According to his report on the reception of RFH at the HL7 meeting, there appears to be a real appetite for change at HL7, which is good to see.

3. And an announcement from Gartner: "HL7 V3 Messaging has fallen off the hype cycle". Snippets from the analysis by Wes Rishel in the current Gartner Hype Cycle report.

The V3 Messages (V3M) standard was conceived as being the direct analog of the Version 2 Messages standard — that is, XML documents designed to support the information necessary to be transferred when a specific event occurs, such as a patient being admitted or a lab result being approved for delivery to the provider. ... we describe the messaging part of the V3 suite as "obsolete before the plateau."... uptake has been so small and narrow that we cannot justify leaving V3M on the Hype Cycle.

Business Impact: V3M will not have impact except, perhaps, in a few locales.

Market Penetration: 1% to 5% of target audience

4. And finally this:

From: "Helen Stevens Love" <helen.stevens@shaw.ca>Subject: HL7 International Council Proxies - San Diego WGMDate: 8 september 2011 21:53:09 GMT+02:00To: "HL7 Affiliate Council" <intl@lists.hl7.org>

Dear International Council Members,

Based on the pre-registered attendees for the upcoming San Diego meeting we may fail to reach quorum for our Council meetings. ...

U.K. Scrapping National Health IT Network

noreply@blogger.com (Barry Smith) — Thu, 04 Aug 2011 18:08:00 +0000

After nine years, and $18.7 billion in wasted expenditure, the British government is about to scrap its National Programme for IT, which was conceived as a massive, nationwide health IT network for the 52 million residents of England.
As we reported here already in 2007, one of the many reasons for this tragedy was an over-optimism on the part of Tony Blair and others as concerns the quality of available standards. If we use international standards, sanctioned by ISO, what, after all, can go wrong?
Yet as the head of the program, Richard Granger, expressed it in giving evidence to the UK House of Commons Select Committee on Health in 2007:

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

And as the UK Computing Research Committee pointed out in its evidence to the same Committee:

many of the technologies are new and have not been tested. In particular, at the heart of the EPR are two standards—HL7 v3 and SNOMED-CT. We understand that neither has ever been implemented anywhere on a large scale on their own, let alone together. Both have been criticised as seriously flawed. It is imprudent to base the Electronic Patient Record, which will be part of the UK's national critical infrastructure, on a technology experiment.

Sadly, as the many posts on this blog make clear, it seems that HL7 v3 is in no better shape now than it was in 2007.

Update October 3, 2011:

Lessons From Britain’s Health Information Technology Fiasco

(New York Times, September 27, 2011)

The Wreck of HL7

noreply@blogger.com (Barry Smith) — Sun, 31 Jul 2011 14:42:00 +0000

An interesting ditty by Jean-Henri Duteau, reposted from the ever excellent Health Intersections Pty Ltd (after: The Wreck of the Edmond Fitzgerald)

The legend lives on from ANSI on down
of the SDO they called “HL7”.
Health Standards, it is said, never gives up her dead
when the skies of November turn gloomy.
With a load of designers twenty-six thousand tons more
than when HL7 started early,
that good SDO was a bone to be chewed
when “Semantic Interoperability” came early.

The SDO was the pride of the American side
coming back from some place in Ann Arbor.
As SDOs go, it was bigger than most
with a crew and CEO well seasoned,
concluding some terms with a couple of projects
when they left fully loaded for Orlando.
And later that night when the supper bell rang,
could it be the north wind they’d been feelin’?

The wind in the wires made a tattle-tale sound
and a wave broke over the railing.
And ev’ry man knew, as the CEO did too
’twas witch of Interoperability come stealin’.
The dawn came late and the breakfast had to wait
when Semantic Interoperability came slashin’.
When afternoon came it was freezin’ rain
in the face of a hurricane west wind.

When suppertime came the old Board chair came on deck sayin’.
“Fellas, it’s too rough t’feed ya.”
At seven P.M. a main hatchway caved in; he said,
“Fellas, it’s bin good t’know ya!”
The CEO wired in he had water comin’ in
and the good SDO was in peril.
And later that night when ‘is lights went outta sight
came the wreck of HL7.

Does any one know where the love of God goes
when the requirements turn the minutes to hours?
The searchers all say they’d have made Normative
if they’d put fifteen more miles behind ’er.
They might have split up or they might have capsized;
they may have broke deep and took water.
And all that remains is the faces and the names
of the wives and the sons and the daughters.

In a musty old hall in Ann Arbor they prayed,
in the “Health Informatics’ Cathedral.”
The church bell chimed ’til it rang twenty-nine times
for each man on the HL7 Board.
The legend lives on from ANSI on down
of the big SDO they call “HL7”.
“Health Standards” they said, “never gives up her dead
when Semantic Interoperability come early!”

HL7 and the Services Aware Interoperability Framework

noreply@blogger.com (Barry Smith) — Sat, 23 Jul 2011 19:10:00 +0000

Jobst Landgrebe is formerly Enterprise Architect at the International Institute for the Safety of Medicines
(ii4sm) and Co-Chair of the HL7 Vocabulary Workgroup. He and I recently collaborated on a paper entitled "The HL7 Approach to Semantic Interoperability" which was presented at the 2nd International Conference on Biomedical Ontology. The abstract is as follows:

Health Level 7 (HL7) is an international standards development organisation in the domain of healthcare information technology. Initially the mission of HL7 was to enable data exchange via the creation of syntactic standards for point-to-point messaging. For some 10 years, however, HL7 has increasingly conceived its mission as one of creating standards for semantic interoperability in healthcare IT on the basis of its 'version 3' (v3) family of standards. Unfortunately, v3 has been marked since its inception by quality and consistency issues, and it has not been able to keep pace with recent developments either in semantics and ontology or in computer science and engineering. To address these problems, HL7 has developed what it calls the 'Services-Aware Interoperability Framework' (SAIF), which is intended to provide a foundation for work on all aspects of standardization in HL7 henceforth and which includes HL7's Reference Information Model as general purpose upper ontology. We here evaluate the SAIF in terms of design principles that must be satisfied by a semantic interoperability framework, principles relating both to ontology (static semantics) and to computational behaviour. We conclude that the SAIF fails to satisfy these principles.

A video of Dr. Landgrebe's presentation is available here, and contains a number of interesting side remarks, including this (at 13:20):

The SAIF does not meet the needs of an interoperability framework. It can’t overcome the crisis of HL7 – and that’s a big problem because for example the IHE, the big organization that the government agencies are looking at to create interoperability in healthcare – it’s called "Integrating the Healthcare Enterprise" – is telling industry that it should use HL7 for everything in healthcare exchange .. , but if industry would do this nothing could work … My theory is that the IHE is set up exactly to make sure that nothing can work (but that’s – you know – conspiracy theory) …

Update August 6, 2011:
I received the following comment:

Anonymous has left a new comment on your post "HL7 and the Services Aware Interoperability Framew...":
I am not certain why your paper was accepted, other than the provocative subject matter. Much of what you state as fact is unsubstantiated opinion. Several of your premises are also faulty.
I am concerned, as this paper is quite misleading and/or misguided.
You make sweeping generalizations without evidence of data or analysis. Many of these read more like bias rather than factual. Your paper contains several dubious citations. Many of the citations of your assertions don't logically support your argument. Some of the authoritative sources you cite are non-retrievable (404) URLs. Others simply not true.
You often get tied up in knots in your logic, often based on a trifle (or misunderstanding). The line of reasoning is not clear and is encumbered by jargon, which seems to obscure rather than clarify.

I can understand why correspondents who provide HL7 Watch with evidence of problems with HL7 request that they be allowed to remain anonymous -- criticizing HL7 can still, I am told, cause career problems in the health IT world. But why would someone who is taking the side of HL7 elect to remain anonymous in this way? Jobst Landgrebe and I provided arguments, and we provided an extensive list of references to support these arguments. (We regret that HL7 seems to have removed from the web some of the items for which we cited URLs since our contribution was first circulated.) Anonymous himself, however, provides assertions, which we would be more than happy to discuss. Perhaps he will reveal himself in order to allow such discussion to proceed.

Update August 18, 2011
One intriguing element of the SAIF literature is that it reveals that HL7 is now promoting the use of the word 'ontology' in application to the RIM. While in other circles there is increasing clarity as to the difference between an information model and an ontology (e.g. here and here), HL7 here seems to be once more muddying the waters.

HL7 attempts to get things clear about its own use of the word 'concept'

noreply@blogger.com (Barry Smith) — Thu, 30 Jun 2011 19:50:00 +0000

HL7 v3 has been under development since 1996. Now, at last, the HL7 organization is beginning to attempt to provide definitions for its basic terms. I provide the relevant document (in full) below, in the version of June 29, 2011. My comments are interspersed in red.

HL7 Nomenclature for Concept Representations

For many years, a number of words have been used to describe various bits and pieces of terminologies and their components. In an effort to precisely define these words, and use them consistently in the Core Principles document currently under ballot, this paper documents the current position of the Vocabulary WorkGroup with regards to these words, as used in the HL7 datatypes and the HL7 vocabulary model.

The fundamental unit of meaning in HL7 with respect to vocabulary is CONCEPT.

As defined in HL7, “a concept is a unitary mental representation of a real or abstract thing – an atomic unit of thought.”

So:

A concept is a fundamental unit of meaning.

A concept is a unitary mental representation.

A concept is an atomic unit of thought.

Are 1., 2. and 3. equivalent?

However, there is not yet technology able to directly transmit or manipulate abstract thought.

What is 'abstract thought'? Is it the same as: thought about what are referred to above as abstract things? Is this still thought of the sort that takes place in human brains? If yes, what sort of technology does the author of this sentence have in mind? If no, what sort of thought is it, that does not take place in human brains?

Furthermore, for useful computational interoperability, the set of concepts that can be captured, shared and manipulated must be standardized.

If concepts are mental representations, as according to 1., or units of thought, as according to 2., how -- leaving aside complex brain surgery -- could concepts be captured or shared or manipulated? How could concepts thus conceived (i.e. as creatures of human mental activity) play a role in computational interoperability?

Code Systems perform this function of concept standardization

Does this mean that the concepts which are the atomic units of thought -- the concepts, presumably, with which human thinkers operate when they have thoughts -- are to be replaced by other, standardized, concepts when Code Systems are introduced? If so, where do these new standardized concepts live? Are they still 'units of thought'? And if so, who or what is the thinker who is having the relevant thoughts?

and may perform other functions such as defining relationships between concepts. Most importantly, they provide representations for the concepts they standardize.

Our thoughts, or mental representations, are to be standardized by Code Systems. What does this mean? What is the end-result of such standardization? Concepts themselves, we are told, are representations of real or abstract things, and Code Systems provide representations of concepts. From this we can infer:

4. Code Systems provide representations of representations of real or abstract things.

But then a further problem arises; for if Code Systems provide representations of the very concepts they themselves standardize, does this mean that they provide representations of these concepts as they existed before standardization; or that they provide representations of the very concepts which they themselves have standardized? How can something be a representation of X and a standardization of X at one and the same time?

A Concept Representation is some form of symbol that, when interpreted in the context of a given Code System, is understood to stand in for the meaning associated with the Concept.

5. Meanings are associated with concepts.

According to 1. a concept is a unit of meaning. According to 5. there are meanings associated with concepts. Which is correct?

6. Symbols can stand in for meanings

What could this mean? Surely the symbols are the sorts of things that have meanings.

While these representations may be graphical, or other media (e.g. barcodes, video clips, etc.), in the context of HL7 they are generally limited to character strings. Code systems may provide multiple concept representations of different types for a single concept. Some concept representations might be intended for internal use by the code system, others for exchange by computer systems representing the concept, others for display to human users, and still others to "formally define" the underlying concept.

In many code systems, the same symbol might serve multiple purposes. For example, the symbol "F" in the HL7 code system AdministrativeGender can be used internally in the definition of a Value Set, can be sent over the wire between computer systems and can be displayed to users. In other code systems, a given concept representation might be intended for only a single use, or even variants of a given use. For example, a code system might define both short and long descriptive name concept representations for human display in different types of user interfaces. Depending on their intended use, types of concept representation may have varying characteristics in terms of whether they are unique within the code system and whether there can be multiple representations of that type for a given code system.

7. There are descriptive names which are concept representations.

This means, I think, that there are descriptive names such as 'person' or 'arm' which represent concepts. Such descriptive names, presumably, also have meanings. Are these meanings also concepts? If so, are they the same concepts as the concepts which the descriptive names represent? If not, are there some meanings of descriptive names which are concepts, and other meanings which are not concepts? And if so, how do we then tell the difference between the two?

In other code systems, it may be possible to construct a representation by combining other representations according to a code-system-specific grammar. This is called post-coordination. For example, the symbol for "arm" might be combined in some way with the symbol for "left" to construct a concept representation for "left arm".

There is an issue, here, of what is called the 'use-mention confusion', illustrated by the sentence "Swimming is healthy and has two vowels." The use-mention confusion occurs when it is not realized that "swimming" refers to swimming (and not to "swimming"), that "London" refers to London (and not to "London"), and so on.

We are told that we can put together the symbol for "arm" with the symbol for "left" in order to construct a concept representation for "left arm". Not so, however, The symbol for "arm" is '"arm"'. ("Arm" is the symbol, not for "arm", but for arm.)

[See the second comment by Spero melior below on a further problem raised by this paragraph -- which is that it suggests that the combination of the concepts arm and left would itself constitute a concept, which conflicts with HL7's own definition of concept as an atomic unit of thought.]

The [accompanying table] of three different names for concept representations attempts to disambiguate the nomenclature we commonly use in HL7. It also includes examples for these types of concept representations from some common healthcare-related code systems, including some post-coordinated examples.

Note that these terms [‘Code’, ‘ConceptID’, ‘Designation’] all refer to the use of a particular Concept Representation. In some code systems, such as the AdministrativeGender example given earlier, the same representation (e.g. "F") can be a considered a Code, a Concept Id and a Designation.

So that's clear, then.

Notes
1. The above continues my commentary here.
2. For an example of a set of definitions which, I believe, comes closer to the level of precision that is required, in this difficult field, see here, and especially the distinction between what are there called "levels 1, 2 and 3." For further discussion of the problems we face in understanding the meaning of the term 'concept' in computer science circles -- including arguments on behalf of the view that we should abandon this term entirely, see here.
3. For a discussion of the historical source of some of the confusions conveyed in the above document, including the delightful passage concerning "technology able to directly transmit or manipulate abstract thought", see here.
4. Update June 30, 2011: See now Grahame Grieve and Thomas Beale discussion here.

Does anybody out there love the RIM?

noreply@blogger.com (Barry Smith) — Thu, 16 Jun 2011 21:09:00 +0000

From Grahame Grieve at Health Intersections:

The most remarkable aspect about the wide feedback I’ve received about the HL7 Fresh Look taskforce is the comments about the RIM.

One person – just one solitary person – put it to me forcefully that the original direction of the RIM (+ design by constraint + the XML ITS) was the right direction, and that we should stay the course, becase in the end, the doubters will be overcome by the evidence.

Just one person. It’s someone I respect greatly. And it troubles me to disagree with him, because this person is often proved right. But he’s the only one (so far) (And I’m not going to name who it is since our discussion was private).

There was a long and at times passionate thread on the RIMBAA (RIM-based application architecture) email list defending the notion of the RIM, but even there the opinion there was pretty unanimous: the RIM should be reserved to specialists, and normal interoperability specifications should use simple forms where their innate RIM-ness is hidden from the normal population.

Generally, the feedback I got from my fresh look post told me loud and clear that HL7 is not reducing complexity, and that in particular, the RIM is not helping to tame complexity.
That should come as no surprise to anyone who’s read my piece on design by constraint: it simply externalises the complexity associated with achieving consistent semantics. But nevertheless, I was surprised at how one-sided the feedback was in this area.

Does anybody (else) out there love the RIM?

To keep track of the responses (if any) follow here.

Chocolate Teapot Not Otherwise Classified

noreply@blogger.com (Barry Smith) — Fri, 27 May 2011 17:10:00 +0000

The methodological approach which underlies this blog is based on the position of ontological realism. One standard objection from the HL7 community to this position is that the ontological realist strives for 'perfection', where HL7 and its ilk, more sensibly, strive for mere 'practical utility'.

Examination of the many concrete proposals made under the ontologically realist heading proves, however, that they are both (a) quite modest, and (b) of considerable practical utility.

In many respects these proposals echo the "Desiderata" advanced by Cimino in responding to the poor quality of many of the terminology artifacts created in the field of medical informations. In one central respect, however, they go beyond Cimino who still (in 1998, at least) sees the way forward as lying in a move from the orientation around terms to an orientation around what he calls "concepts". For inspection reveals that the concept orientation is itself one reason for the massive inconsistencies that exist, both between different specialist terminologies, and among the different versions of these terminologies produced at successive points in time. This is because the concepts in the minds of specialists are too etherial to serve as a constraint on the builders of terminologies, especially when the latter are themselves subject to the pressures of third-party payers, gatherers of public health statistics, patient groups and other stakeholder lobbies. The result is confusion; the waste of investment in the creation of poorly maintained mappings; ever more intensified forking leading to a failure of cumulativity of data and to a lack of IT support, for example, in areas such as continuity of care (for example when patients move from one hospital to another).

The solution proposed by ontological realism -- now embraced in part also by Cimino -- rests on the idea that terms in ontologies (or terminologies, or messaging standards) should as far as possible be oriented, not around concepts in people's heads, but rather around the types of entities in the corresponding domains of reality. In this respect, terminology work should mirror the practice of scientists, who as a matter of course use terms such as 'electron' or 'planet' or 'mammal' in describing their data, rather than terms such as 'electron NOS' or 'planet NEC' or 'mammal that is of interest to the human resources department'. Terms in the former group are used in remarkably stable ways, by multiple, ever expanding communities throughout the world, and there is empirical data associated with the corresponding types in reality deriving from large numbers of heterogeneous sources.

The proposal is (1) that representations of types of the mentioned sort should be used in terminology resources wherever possible, not merely as terms in their own right, but also in the definitions of further terms, and (2) that the term 'concept' should be avoided entirely. (A partial exception might be made in areas such as linguistics or psychology, where the scientists in question are able to define what the term 'concept' means.) In this way, terminologies will be anchored -- to some degree at least -- to a stable, empirical benchmark, following a pattern already realized by the OBO Foundry ontologies. Terminology resources will also be anchored to each other, through the use of a common set of feeder terms in their respective definitions, in ways which can support consistency over time and thereby also allow the more effective aggregation of data.

We do not see this solution as a magic bullet. But we do believe that it has the chance to constrain forking in some small areas of clinical research, and that putting it to the test in pilot experiments may provide a generalizable strategy for the formulation of coherent terminologies and associated definitions in broader areas in the future.

Moreover, we are absolutely sure that the negative results which have flowed from not following this proposal are immense. These results are visible, for example, when we examine some of the problems faced by users of SNOMED as a result of the fact that the latter has been subject to such a large number of changes in its successive versions -- changes that can be attributed precisely to the concept orientation, which infects SNOMED from the top down.

I now discover that these results have been documented in a beautiful piece by Malcolm Duncan entitled "Medical terminology version control discussion paper: The chocolate teapot (Version 2.3)" in relation to the Systematized Nomenclature of Kitchen Terminology (SNoKitch), and specifically to its two non-contiguous branches Crockery and Teamaking Related Findings in its n.3 release:

Crockery
---Teapot
----- Brown teapot
------White teapot
----------White china teapot
------Blue teapot
----------Blue china teapot
------China teapot
---------White china teapot
---------Blue china teapot
------Pink teapot
------Aluminium teapot
------Chocolate teapot
------Ornamental teapot
------Industrial teapot

Tea making related findings
---Teapot related findings
------Large teapot
------Full teapot
------Empty teapot
------Teapot with warm water
------Teapot with cold water.

The document in question is cited in a (long) HL7 discussion concerning the problems which arise in connection with the Cimino desideratum of "concept persistence". This discussion, incidentally, reveals one flaw in Cimino's formulation of his desiderata: for it shows that recommending "concept persistence" as a desideratum is a bit like recommending "life persistence" for the patients in your hospital. Life persistence is, certainly, a nice thing to recommend; but it would be even better, surely, if one can formulate a desideratum which identifies some specific strategy for achieving it -- in such a way that the desideratum of persistence will follow as by-product. It is something like this which ontological realism, in its stumbling fashion, is attempting to do. For its counterpart of 'concept persistence' -- to the effect that ontologies should be developed in such a way that versions should evolve gracefully in reflection of scientific advance -- follows immediately from the recommendation to use, as far as possible, the terms employed by scientists.

HL7 Refresh

noreply@blogger.com (Barry Smith) — Sat, 14 May 2011 20:39:00 +0000

Here, continuing the theme of "the fall of the RIM", are some recent contributions on the future of HL7:

From Tom Beale at Woland's Cat: How could HL7 refresh?
From Grahame Grieve at Health Intersections: HL7 Fresh Look Task Force
From Barry Smith in The Cancer Letter: caBIG has another fundamental problem: it relies on "incoherent" messaging standard

The Fall of the RIM

noreply@blogger.com (Barry Smith) — Sat, 02 Apr 2011 13:10:00 +0000

In his comment of 4/02/2011 to our "The Rise and Fall of HL7" thread, Graham Grieve argues that, in spite of all the objections advanced by Elliot Muir and in the associated comments, there is value in HL7 V3 nonetheless -- because the RIM provides a 'semantic standard', and "the future of HL7 isn't about syntax or technology, it's about semantics."

Grahame and Jobst and I (and, I am sure, also Thomas) agree that there is "benefit in commonly agreed semantics". The thesis that has served as the central pillar of this blog since its inception, however, is that after 14 years of development effort, and after so many failures, we should finally accept that the RIM is not able to serve as basis for the needed commonly agreed-upon semantics.
HL7 Watch and others have provided considerable documentation that the RIM is both counter-intuitive and unnecessarily complex; that it is thus difficult to teach and difficult to document (and thus inconsistently documented); and that it is therefore difficult if not impossible to implement.
Moreover, multiple arguments have been provided to demonstrate that, even if it were implemented, the RIM would still not bring about the end which its defenders seek, namely: consistency of semantics. This is because the RIM's own semantics is so counter-intuitive, and thus so inconsistently documented, that its different users will inevitably produce semantically inconsistent implementations, thereby resurrecting the very problems which had led to the conception of the RIM in the first place.
We have learned much in the field of semantics in the 14 RIM years, and what has been learned can now be used as the basis for a better and simpler solution. It is time to start again.

Postscript 4/2/2011, 11:19 AM

So, you keep quoting me, and I keep having to respond ...

In his comment of 4/02/2011 to our "The Rise and Fall of HL7" thread, Graham Grieve argues that, in spite of all the objections advanced by Elliot Muir and in the comments above, there is value in HL7 V3 nonetheless -- because the RIM provides a 'semantic standard', and "the future of HL7 isn't about syntax or technology, it's about semantics."

ummm no. I argued that there is value in a commonly agreed set of semantics. Elliot, if you look closely, didn't mention the need for it, and so that's what I was addressing. I didn't mention the RIM. But omission is not as clear as commission huh?

I do believe that the future of HL7 is semantics, not platform technologies. Well, duh. There's no need for HL7 to invent syntaxes and network protocols these days.

Is the RIM the future? I don't know yet.

I think that the primary debate should be about design by constraint. Tom (who commented in the other thread) did openEHR, which is totally different to v3 and also exactly the same (and also much better and not nearly so good!). The reference model is both more and less abstract than the HL7 RIM, but the methodology is the same: design by constraint.

First, we should figure out what kind of methodology can deliver consistent semantics where we need it, while allowing seamless customisation for particular use cases, where it is needed, without creating an engineering nightmare (one sequelae of that is that it should be usable in multiple architectures without building of extensive custom software stacks). Once we have that, then we can figure out what are the useful properties of an ontology that supports it.

However my view is that no current approach meets such a criteria. We have some candidates on the floor now, and they have the rather useful property of being concrete and usable. v3, and openEHR are the primary ones I know about in health. I work with them both, and they both have strengths and weaknesses. The primary weakness of both is that you have to be steeped in them to understand how to leverage them. But once you are - you can leverage them well. Both v3 and openEHR.

Only in the final paragraph does Graham address my specific arguments concerning what so many now see as the dire state of HL7 V3:

To address your concerns directly. The RIM is trying to do a complex thing. So it's hardly a surprise that it's complex. You've been critical of it, but your criticisms have either been rather fractional, or marginal given the RIM's intended use. What's the alternative?

Not sure what 'fractional' means when applied to criticism. I can well understand that many of the criticisms on this blog will seem 'marginal' to some of those who are caught up in the attempt to use and maintain the HL7 standards. On HL7's FAQ page, we find an odd entry headed "HL7's Mission", which reads as follows:

HL7 provides standards for interoperability that improve care delivery, optimize workflow, reduce ambiguity and enhance knowledge transfer among all of our stakeholders, including healthcare providers, government agencies, the vendor community, fellow SDOs and patients. In all of our processes we exhibit timeliness, scientific rigor and technical expertise without compromising transparency, accountability, practicality, or our willingness to put the needs of our stakeholders first.

It is evident to those, such as myself, who are viewing HL7's processes -- for example as illustrated by some of the more untamed contributions to the HL7 Vocabulary forum -- from the outside, that they exhibit a marked shortfall in timeliness, scientific rigor, transparency, accountability, and practicality. Why is this so? In part, surely, because of those marginal issues -- such as the inconsistency and counter-intuitive nature of the RIM -- which I have been attempting to draw attention to on this blog.
And what is the alternative?
I hope to address this question in more detail in a later post. But for the moment:

First, recognize that the RIM rests on a series of rather simple confusions (for example between a disease and its diagnosis, between an action and its documentation, between an entity in reality and information about that entity in some record).
Second, replace the RIM backbone hierarchy with an ontology that is not subject to these confusions, for example in the way that this is done in the Ontology for General Medical Science, which is based in turn on Basic Formal Ontology.
Third, study the principles of Referent Tracking.

Postscript April 4, 2011: On Grahame Grieve's Comment on "The Fall of the RIM"

I respond, here, to some of the remarks in Grahame Grieve's Comment of April 4 (reproduced in full below):

It may be, as you say, that the RIM confuses reality and information about reality. (Actually, I think you're confused. Reality is not a RIM - or even ontology - based existence. It may be that the RIM confuses information about reality and information about information about reality). But it's real hard for implementers to differentiate these things - so being strict about the difference actually makes things worse.

Grahame and I are addressing here what philosophers call the "use-mention confusion", as illustrated for example in: "Swimming is healthy and has two vowels" or "Our system is able to extract tumors from the patient database in 0.005 seconds". It is true that this confusion is common in many computer-related fields. But surely the goal, in message standardization, is to ensure accuracy of communication.

And it may also be that the RIM and the underlying terminologies (including ones that HL7 doesn't define) are not good at distinguishing instance and class, and defining which instance is intended efficiently - I agree with that.

But replacing the RIM backbone with something like the ontology you talk about would be a problem because it doesn't have the semantic breadth of the RIM. Whether or not some of the thinking in that ontology is better than what is evident in the RIM or not, it's a 5% coverage replacement. ...

If I am right, then the RIM will, sooner or later, have to be abandoned. At that point an alternative will be needed. I have suggested some elements of an alternative. Of these BFO certainly has sufficient semantic breadth to represent any of the types of entity, and to annotate any of the types of information, that are relevant in healthcare. It has also been thoroughly tested in use, especially in biology. Moreover, BFO stands up well along a number of dimensions when compared to the RIM, as is revealingly shown by the Cecil Lynch saga documented here. What BFO lacks is semantic depth -- though with the OGMS work we are beginning to fill this gap. The RIM has this semantic depth because it has been extended in so many different directions by so many for so long. But because the RIM lacks coherence, these extensions typically do not work either, and they certainly do not work well when taken together.

Finally, the real problem with your recommendations for what to do is that there is such a gap between your recommendations and the actual resistance and issues HL7 faces with v3. I continuously get feedback about what is not good about v3. Your prescriptions are something that would make a difference to playing the end-game with v3 - decision support, reasoning systems - but it costs so much to get to the field, that no one even sees the mid-game yet.

Again: if I am right, then the RIM will, sooner or later, have to be abandoned -- cost what it will. The groundswell of criticism can be held back for a bit longer, perhaps, through application of the existing strategies used to cow critics into anonymity. But what makes the case of Elliot Muir so interesting is that these strategies, too, are no longer working.

Postscript April 12, 2011

An interesting report on national health reporting standards in Norway contains the claim that:

"Most European countries that make use of HL7 messaging standards for new purposes uses HL7 version 3. This applies in particular [to] Britain, Germany and the Netherlands."

In fact, however, it seems that there is know one in Germany who is using v3 messaging, although CDA is in use in some places. In the UK there is some v3 legacy, but there seems to be no new development; rather, new work is being done within the framework of the 13606-based Logical Reporting Architecture (LRA), which seems (to me at least) to be a much more coherent modelling effort. Netherlands, it is true, is still using v3 messages, though it is not clear that they are actively developing anything new. And outside of those three countries? In Norway, for instance, plans were indeed announced to mandate v3 - solely, it seems, in light of its status as an 'international standard'. But from the above-cited report it seems that Norway has pulled back from the brink. In the rest of Europe it is CDA that is being used, or 13606 or LRA.

In a comment by Rene Spronk (provided in full below), the question is raised as to HL7 Watch's view of openEHR in light of the fact that the latter has certain similarities with HL7. openEHR, too, I believe, has need of a more sophisticated upper ontology-based approach: it is thus far marked by a lop-sided focus on information models at the expense of representations of reality of the sort which ontology can provide. But there are leading figures in openEHR who would agree with this diagnosis, and I remain optimistic that openEHR - and similar ventures under the CEN-13606 heading - will take the steps needed to rectify problems in this regard. The HL7 community, unfortunately, which is currently advancing the RIM as an 'upper ontology' in the context of its new 'Services-Aware Interoperability Framework’ or SAIF, still gives no evidence of having understood what a well-designed ontology might look like, and what such an ontology is able to achieve. As addressed at length already elsewhere in this blog the RIM has fatal shortcomings not only because it contravenes the very basic rules of information modelling, but also because its backbone taxonomy of Act, Entity and Role is too narrow to allow serious ontological work.

openEHR and similar approaches differ from HL7 v3, too, in that they can be critiqued as can any other ordinary object-oriented reference model approach, precisely because they conform to industry practices. This is not true of HL7 v3.

Referring to an earlier link posted by Rik Smithies listing 22 known software implementations based on the RIM, Rene argues that

This is just the tip of the iceberg in terms of known organizations that voluntarily embrace the RIM as either a persistence model or a in-memory business layer model. This is mainly done for research, public health and DSS purposes, although we've also seen implementations to support classic on line transaction processing applications. ... Calling the RIM "fallen" when at the same time it is increasingly being embraced as an internal model in all sorts of applications - your call, but curious to say the least.

One of the earliest posts on this blog, dated November 25, 2005 is entitled "Misleading Claims regarding HL7 V3" and concerns a 'white paper', edited by Rene, and containing a claim to the effect that "Significant V3 national implementations exist in many countries, e.g. in the UK (the English NHS), the Netherlands, Canada, Mexico, Germany and Croatia." Already at that time there were considerable grounds for scepticism concerning such claims. Now however we have a better view. In the UK, for example, we can see that at least one part of the reason for the massive failure of the Connecting for Health program was precisely that the use of HL7 v3 was imposed upon its designers.

Use of HL7 v3 messaging is, certainly, widespread within the community to which Rene belongs. But it is questionable whether this is a large community. And it is still more questionable whether the members of this community are exuding confidence that they are riding the wave of the future.

The Rise and Fall of HL7

noreply@blogger.com (Barry Smith) — Fri, 01 Apr 2011 00:07:00 +0000

Interfaceware is a Toronto-based HL7 solutions provider whose customers include the CDC, Cerner, GE Medical Systems, IBM, Johns Hopkins Medical, the Mayo Foundation, MD Anderson Cancer Center, Mount Sinai Hospital, Partners Healthcare Systems, Philips, Quest Diagnostics, the VA, and Welch Allyn.

At 2.57pm EDT today, March 31, 2011 -- on what will surely prove to be a historic day in the advance of healthcare information technology in the direction of reason and light -- Eliot Muir, founder and CEO of Interfaceware, posted the following comment, which I here reproduce in full:

The Rise and Fall of HL7

That might seem an unusual comment from what is supposed to be an HL7 middleware vendor. But times are changing and that is not where I see our future.

Standards do not exist in a vacuum. To be successful standards must address market needs and solve real problems so people can make or save money. Writing code costs money. Less than 0.01% of code gets written for free. The majority of code is written by people that are being paid to solve problems with it.

There are plenty of standards which are not worth the paper they are printed on because are are not sufficiently useful or practical.

Complicated standards can be pushed for a while but ultimately markets reject them. Even governments will ultimately reject complicated standards, through a democratic correction process. Although they usually waste a fair amount of other people's money along the way.

So back to HL7. Why was it successful?

Version 2.X of HL7 solved a very big problem for many people in healthcare IT back in the 90's. It replaced a lot of adhoc data sharing mechanisms used in the industry at the time. It gave three points of value. Ironically the first point is one which is not even an official part of the standard.

The so called "defacto LLP standard" defined a uniform way to transport HL7 over a TCP/IP socket - this meant vendors could write standard socket implementations to exchange data.
The EDI format of HL7 with it's classic | and ^ separators meant vendors could write standard HL7 parsers.
The HL7 definitions gave some good suggestions on places to look for data

And that is where the value stops.

It is a lie when a vendor tries to claim they are "HL7 compliant".

The term is meaningless.

The best any vendor can ever do is provide a stream of messages with fields that map adequately to most of the data from their application. HL7 interfaces always end up being a thin wrapper around the structure of the database of the application which feeds them. The standardization comes about because there are common ways of structuring a lot of the data. The pain comes from areas where it is unclear how to structure the data.

There are good reasons for the lack of "standard data models". Technology and society change which means data models must also be changed to best describe new data requirements. Medicine changes. New entrepreneurs come up with clever new solutions and invent ways of using data that improves on old models.

HL7 is working on creating the final solution for healthcare interoperability - the Reference Information Model (RIM) which underlies the structure of version 3 (v3) of HL7.

I think that effort is doomed to fail for these reasons:

1. There is no such thing a single optimal data model to serve all purposes. A formal data model is always going be a square peg going into a round hole. Some problems are best solved by small simple models. There are approximations which work for certain problems but are not valid for others. If there was a single solution to everything then one person would invent it and the rest of us would be out of work.
2. There is substantial academic criticism of RIM that points to the semantic inconsistency within the model itself.
3. It is creating complicated standards which are expensive to implement.

The only organisations spending money on v3 are governments and some big corporations like Oracle that based their health care transaction base (HTB) on it. Oracle salespeople can sell ice to eskimos but I have not heard a lot of great success stories for that product.

Now let us fast forward to what I think will become the future. JSON based web services over HTTPS. Let us look at the benefits:

1. HTTPS with authentication is analogous to LLP - only it comes with authentication and security baked in.
2. JSON - the simplest format imaginable with free parsers in every language and environment, including Javascript which is strategic as the language of the web.
3. JSON data names and values give good suggestions on places to look for data.

Hmmm. Notice something? The value is more than what HL7 offers. In fact a lot more since these are very mainstream technologies that extend far beyond just the healthcare market.

That is why I am not betting the future of my company on HL7. Our value was never really as an HL7 implementation tool. The value our tools provide is the wiggle room we provide for our customers to handle the incompatibilities that occur with real world data. The Iguana Translator is all about making it easy to grab data from anywhere – be it HL7, X12, XML, JSON, databases or web services and making it easy to munch, transform and consume that data.

That is the future I am betting on.

Eliot Muir - CEO of iNTERFACEWARE

Update April 5, 2011

A new comment on "The Rise and Fall of HL7" has appeared at http://blog.interfaceware.com/hl7/the-rise-and-fall-of-hl7/ responding to Elliot's assertion to the effect that "The only organisations spending money on v3 are governments and some big corporations like Oracle":

Eliot,

plenty of companies apart from Oracle are “spending money” on the V3 RIM. Here are just a few that are basing their strategy on it (and not just their interfaces):

http://wiki.hl7.org/index.php?title=Category:RIMBAA

Rik

As one might respond: this means that after more than ten years there are some 22 companies with RIM-based products. Are any of these products particularly impressive in nature? Have they demonstrated some exceptional power of the RIM?

An Australian View on HL7 V3

noreply@blogger.com (Barry Smith) — Sat, 26 Mar 2011 19:51:00 +0000

The Australian Health Information Technology blog has posted here a valuable discussion of the item headed Cries for Help published earlier in these pages. This discussion is interesting not least because of the large number of contributions it contains which -- unusually -- are signed by their authors. It seems that, in Australia at least, there are individuals who are willing to commit themselves publicly to a critical position as concerns the HL7 project (where the vast majority of my US informants are willing to have their views communicated only anonymously).

As David More points out in his introduction to the discussion, the implementation success of V3 thus far (and this means after some 14 years of development work) "has been somewhat patchy, with at least some proponents scaling back their enthusiasm for full adoption of the V3 Standard as some see it is lacking the necessary robustness and internal consistency for ongoing use." Dr More goes on to point out that, "While I am not sufficiently across the details of some of this to be able to form a trustworthy opinion a number of very smart people I have chatted with have expressed similar concerns."

In a comment, Grahame Grieve writes on behalf of HL7:

There's no reason for anyone to be afraid to comment. HL7 is not a police state, and there's an endless list of people who criticise and carp. They can expect a vigorous in kind response, but nothing more.

v3/RIM is not perfect. But it's not intended to be an ontology of everything. If only Barry would understand. It's just a model that has some use for interoperability. It's got some go-down-with-the ship type supporters, of course.

As does v2 (and all the other standards - they all have the folks who are going to go down with the ship). It's not enough to say it's simpler. There's more to it than that. The discussion is being had elsewhere, and here is not the place for it. HL7 continues to produce v2 (v2.7 is coming) but the community that is HL7 is switching to v3 because of it's power.

v3 itself does have a patchy record. I'm on record as saying that there won't be another full v3 implementation. People will cherry pick the parts that work - like CDA - and use them as they want.

I've got more to say but it's starting to rain and I'm out in the bush camping. Have a good weekend."

These remarks raise many interesting questions. Grahame asserts that commentators -- whom he divides into critics and carpers -- can expect nothing more than a "vigorous in kind response". Why, then, are so many people reluctant to use their names when commenting critically on HL7? I also fully understand that HL7 V3 is not intended to be an "ontology of everything". Indeed its scope is a tiny, tiny fraction even of the healthcare domain. The problem, as I see it, lies rather on the part of HL7's own advocates when they advance claims for example to the effect that HL7 is "the data standard for biomedical informatics". Such claims give rise in turn to multiple efforts to reinvent various well-functioning wheels in somewhat less-well-functioning proprietary versions inside the walls of HL7. Over time, in result, HL7 becomes ever more complicated, ever more difficult to teach, and ever more difficult to apply successfully. Raising the inevitable question: who benefits from such developments? The following remarks were sent to me by the Asian health IT specialist (henceforth 'S') who was the author of the Cries for Help which originally provoked Grahame's comments:

Grahame (henceforth: G): "v3/RIM is not perfect. But it's not intended to be a ontology of everything. If only Barry would understand. It's just a model that has some use for interoperability. It's got some go-down-with-the ship type supporters, of course."

It's just a model that has some use for interoperability -- That's pretty lame! When a patient's life is on the line "some use for interoperability" is not good enough. The system has to be 100% perfect. Imagine using "some interoperability" to loosely move data across hospitals with the possibility of data errors. The more complex and opaque a system, the more are the chances of errors.And this is simply because it could be almost impossible to detect the tiny but fatal coding flaw that could be hidden under tons of code, trying to helplessly interpret overly complex V3 rules.

G: "the community that is HL7 is switching to v3 because of it's power."

S: What power?!! V2.6 can actually do every thing that V3 does - only more elegantly, simply and transparently.

G: "I'm on record as saying that there won't be another full v3 implementation."

S: So does that mean that V3 is dead, long live V2?

G: "People will cherry pick the parts that work - like CDA - and use them as they want"

S: Why is HL7 diluting it's focus? It's main aim was to create and encourage a messaging standard for interoperability. Than why create a CDA? Why hijack a perfectly good CCR? The way it is going, tomorrow they may think of creating an EMR, EHR and later a HIS all of course based on the RIM!

S continues as follows:

I say, Focus dear friends, focus. Make HL7 simple enough to be easily implementable. And make the HL7 standards more open/accessible.

On accessibility, this is what I have to say. Have you seen the latest restrictions on use of the HL7 standards? They were restrictive in the past, it has now gotten worse. Today the standard is totally commercialized. You cannot use it to create a professional, usable, realworld (aka 'commercial') app till you pay the HL7 group with a pound of your flesh. You cannot teach HL7 to any one - ditto, share it with a colleague in your hospital? - ditto .

So how does one spread the message of interoperability far and wide, how does one advocate use of the HL7 standard world wide, how does one make hospitals share records, when at each step you are told to cough up money!

So let HL7 frankly admit that it is in it for the money or go truly open and offer the standards to all like say, LOINC or ICD.

So, in conclusion, here is the true (no hidden agendas) mantra to making HL7 (V2x) a truly international standard.

1. Drop V3, simplify V2x and make it easily implementable

2. Make the HL7 standard truly open by offering it free for use.

Amen...

Readers of this blog are warmly recommended to read the further comments at Australian Health Information Technology, which are of interest especially as concerns the views expressed on the potential implications of HL7 standards for the Australian National E-Health Transition Authority.

Postscript: March 27, 2011

Graham Grieve posted a comment here parts of which are addressed to the above-mentioned A>sian healthcare specialist, specifically:

S: HL7 becomes ever more complicated, ever more difficult to teach, and ever more difficult to apply successfully.

G: Yes. These are all true, and concerning. But complexity is complex. As are committee designed standards. Name a standard that hasn't got more complex over time...

S: That's pretty lame! When a patient's life is on the line "some use for interoperability" is not good enough

G: oh? Patient's lives are on the line? I'd never thought!

S: Imagine using "some interoperability" to loosely move data across hospitals with the possibility of data errors.

G: To be serious, it's hard to know how to respond to this. There's no context, no ground rules. As for this... "V2.6 can actually do every thing that V3 does - only more elegantly, simply and transparently" I can only assume that the "expert" hasn't implemented both CDA and v2. Perhaps not even read them. Or they have a very peculiar definition of "everything".

S: Have you seen the latest restrictions on use of the HL7 standards?

G: Errr, I've not heard that anything changed. What, specifically, has changed? I'm personally against charging for the standards, but developing standards is a costly business that has to be funded somehow. (Do I need to repeat for slow readers that I do *not* speak for HL7?)

S: So in conclusion here is the true (no hidden agendas)...

G: No hidden agendas? from an anonymous contributer? I don't even know why I'm bothering to respond.

S himself has now responded, as follows:

This is what I was afraid of ...I have deep respect for every individual who has worked on HL7(including Grahame), but what I have stated is based on 30 plus years of experience, both as a clinician and Healthcare informatician. Further, my knowledge, certification and work on HL7 over the last decade+ qualifies me, I think, to speak on this topic. This kind of blistering "who the hell do you think you are!" kind of a retort, including personal aspersions, are not conducive to scientific progress. If this is not a police state, then what is? This is the very reason for the cloak of anonymity. I have, very simply presented a point of view, and if one were in a responsible position, one should accept criticism and examination of how we could work at improving the usability of the standard.

Please convey to Mr. Grahame my respect for his point of view.I do assure all that I am just as eager as any HL7er to grow HL7 to be a highly usable standard (especially in a way that keeps costs under control. President Obama, I am sure, would appreciate this).I do hope HL7.org is also listening.Good bye. Over and out. End of transmission.

Two comments, received more or less simultaneously:

Dear "S",
Last I heard, police states involve imprisonment, torture and summary execution, whereas in free countries, we both say what we think. Which I do think is what is happening here.
I'm sorry that you felt my comments were a blistering attack on yourself. I certainly was sarcastic. It's hard not to be, given the circumstances, but I will try hard not to from now on. I don't know how I could make personal aspersions regarding yourself, when I do not know who you are (though I expect that I know you). Now you claim 30+ years of experience, including a decade of HL7, but how could this have qualified your comments when made anonymously without even identifying that fact? You say my response was a "who the hell do you think you are?", when in fact, I want to know, "who are you?"

Turning from that, I'm happy to work with you to accept criticism and examine how we could improve the standard. Where would you like to do that? Here, or at an HL7 meeting? Or somewhere else?
Grahame

From S:

I can understand, and see, that Grahame is a true V3 loyalist (I respect that), but unfortunately to the degree that he is perhaps unable (or unwilling?) to look at its fundamental flaws. I really did not want to get into a slanging match with a respected colleague since I believe that is not right. End of the day, we both have strong beliefs - only in different directions. As a professional and a board certified clinician, I do believe that at such a juncture the right thing for gentlemen to do is to discuss and come to an agreement or respectfully agree to disagree.

Thank you Grahame for agreeing to listen to my critique:Here are a few issues that I have with the fundamentals of V3 messaging (CDA not included) vis-a-vis the V2.6 standard. I shall be happy if you can resolve my issues:

(1) One of the strong points of V3 is conformance. Why does V3 bring about 'Conformance' in an extremely opaque, convoluted and complex process (using multiple tools which are proprietary (some open source, some commercial)), when V2.6 can do the same with just use of the standards document and an ASCII editor?

(2) As a clinician I require my clinical message to be transferred accurately to the recipient. How does V3 do a better job as compared to V2.6? (Please do not bring in points like conformance, security, permissions, confidentiality and encryption, since all of this can easily be configured in V2.6)

(3) V3 XML vis-a-vis V2.6 XML is massive and convoluted. How is this better?

a) The human readable component is so deeply buried in the code that it requires super human effort to extract it manually (even for a small message) so is it really human readable?

b) Coming to the next part, machine readable information - the effort required to human-engineer an application to ergonomically extract information from clinical data (as required by V3) puts a huge load on the end user (clinician). In fact there are studies that clearly show non-acceptance of HC IT apps by clinicians because of use of complex forms to input data in a way that is different from the normal flow of a clinician's writings. These are some of the problems that reduce acceptance of Healthcare IT apps by clinicians. Do you not think that by trying to make data machine readable for V3 you would be actually reducing adoption of HC IT apps by clinicians? End of day there are other methods by which data can be extracted from free flowing text for BI, CDSS and EBM (evidence based medicine). So why complicate?

(4) V2.6 can easily transport any kind of media with lower overheads as compared to V3. So why V3?

(5) V2.6 can, from the end user point of view, transfer the same clinical content as robustly as V3. So why V3?

(6) V2.6 messages can be coded by nothing more than Notepad and the standards document. Why this complex process in V3? Since in the end after all this goes through the grinder (Funnel the RIM to a DMIM (actors, story boards, acts, moods....) to a RMIM, CMETs yada, yada, yada, run it through automated tools) we are finally handed over ready message templates for each domain - as is present in V2x. This message (from the end user point of view) is nothing more than the equivalent of a ready made message from one of the chapters of the V2.6 standard (it is as as simple as simply selecting the appropriate V2.6 message from the standard and going ahead). So why would one waste time, effort and scarce manpower to do the same thing in a more complex way?

(7) Has a study been done on the cost overheads of V3 (in $ terms) vis-a-vis V2.6 (including conversion of data, maintaining of 2 standards, training, new apps,etc)? If so what is it and are the costs commensurate?

(8) What are the time overheads of changing over to V3 (in man days) vis-a-vis say, V2.5 to V2.6 (including training)?

(9) How much time does it take to train a productive HL7 analyst in V3 vis-a-vis V2.6? Is the time/cost commensurate?

(10) I am sure you agree that the more the parts, the more are the chances of a breakdown (or error or worse still a SILENT error). Complexity, if it improves outcomes to the end user, would be worth the risk. But how does V3, realistically, improve outcomes for the enduser (as compared to V2.6)?

(11) Do you think it would be a good idea to wrap up all the RIM based complexity into a black box (only to be handled by the WGs) and simply present ready message templates to the end user in the form of a 'V3Simplified' Standards Document, something similar to a V2x document? (This is, in any case, gradually happening.) These messages could be mapped to V2x messages for easy portability.

Grahame provides his responses here:
http://www.healthintersections.com.au/?p=33

NCI Report on caBIG

noreply@blogger.com (Barry Smith) — Tue, 08 Mar 2011 23:05:00 +0000

Just released:

AN ASSESSMENT OF THE IMPACT OF THE
NCI CANCER BIOMEDICAL INFORMATICS GRID

Report of the NCI Board of Scientific Advisors Ad Hoc Working Group

See: http://cancerletter.com/downloads/20110304_2/download

There is much that is of interest in this document, which does not however get to the heart of the reasons for the technical failures of so much of the caBIG software. About which more anon.

Update April 12, 2011

See now also here.

Cries for Help

noreply@blogger.com (Barry Smith) — Mon, 28 Feb 2011 16:20:00 +0000

One of the disturbing aspects of the HL7 phenomenon is the degree to which so many of those who have strong critical views are reluctant to express these criticisms in public. Here a sample criticism of the HL7 RIM, by a leading healthcare IT specialist in Asia who has given me permission to quote from his email communications, as follows:

It is abundantly clear that V3 is an unnecessarily complex, incoherent and confusing messaging standard while V2 is simple, workable, elegant and deployed at more than 95% of healthcare institutions wherever HL7 is used.

Why not scrap V3 and simply work on improving the V2.x standard (say V2.7)?

...

I am concerned about the growth and proliferation of a meaningless standard because it is fraught with danger and is leading to:
(a) Increase in the cost of Hospital IT implementation
(b) Making coding complex which could lead to errors and thereby lower care of (and even endanger) patients
(c) Increasing the cost of software
(d) Increasing the cost of training and implementation
(e) Forcing the use of two standards in parallel when one could have sufficed
(f) Diverts funds from useful IT apps to feed V3

The only people/groups that could possibly gain from this are:
(a) HL7 org and their collective egos
(b) Trainers who will make money from teaching this "complex" 'new' standard
(c) IT companies that make money from pushing newer versions and widgets to "upgrade" to V3

SADLY, it is finally the patient who pays (even if it is a govt or insurance run system) while the doctor, who is already overstressed, is made to learn 'new and improved' processes. As a doctor with more than 30 years of practice, this situation is clearly not acceptable to me.

We need to put together a strong official lobby consisting of sane minded people, organisations and vendors to be heard by the US govt and to forcefully close down such (criminally) wasteful activities.

...

Here is another example of a desperate push through a back door: Pushing and converting a perfectly good CCR to a CCD by unnecessarily insisting on a RIM based approach (where none was required) shows desperation to push the RIM, come what may.

It is my personal opinion that there should be no shame in accepting that a certain approach has failed. We are doctors and scientists and accept, humbly, that we do not always succeed. The real shame and loss would come from stubbornly trying to flog a dead horse putting time, money and people at stake, just so as not to declare failure. I say, be brave enough to move on and use the excellent collection of thinkers at HL7 to develop a fresh, focused and simple solution. To try and capture the complete medical domain (present and future) into one core model is not only foolish but also unachievable. We as doctors know that and therefore only focus on our core specialty.

One Last Effort to Save the Concept Orientation

noreply@blogger.com (Barry Smith) — Sun, 13 Feb 2011 15:18:00 +0000

I am grateful to Werner Ceusters for giving me permission to reproduce the following letter, which was sent by him to the HL7 Vocabulary List. The letter expresses Ceusters’ reaction to discussions (appended below) of HL7’s current attempts to clarify its Core Principles, specifically as these relate to the proper use of ‘concept’ and related terms. In sum: The concept orientation, because it encourages a focus on the heterogeneous perspectives of separate groups, is responsible for the extra effort required to connect distinct systems using V2 messages. This very same failed approach was then used as basis for a 15 year project to solve the problems of V2 by creating semantic interoperability in terms of the RIM, and it has led to what is now widely perceived as the disaster of version 3.

*******

On Sat, Feb 12, 2011 at 11:18 AM, Werner Ceusters wrote:

[To Ted, Lloyd, Jan and others posting to the HL7 Vocabulary List]

Allow me to say that I do understand, and so it seems gradually do others who are more deeply involved in the HL7 business than I, what the Core Principles of HL7 V3 are based on: mud and quicksand, precisely because HL7 has been completely built around the gazillion meanings people associate with the term ‘concept’. Trying to narrow these meanings down to just one, and this after thousands of pages of documentation have been written, message templates and specifications produced, is not going to help much. Unless of course the goal is to convince otherwise misinformed decision makers – I do hope indeed that they are misinformed and not accomplices – to get some more industry and taxpayers’ money poured into this never ending story. If you would succeed, and if you would then do a good job of replacing each occurrence of an ambiguous term by one with a unique and precise meaning, then you would see for yourselves that the entire framework is incoherent and inconsistent. But is that worth the money and effort?

This having been said, though, what I never really understood is why you got so deeply involved in this mess. Of course, when designing V3, you were clearly aware of the many ambiguities in the source data that had to be transferred by means of your messages from one information system to another. And you were aware of the many distinct ways in which V2 messages were created over and over again for the same sort of information that they were intended to transmit. And I guess you wanted to solve that problem. I can only imagine that you didn’t realize that the reasons for these ambiguities in source data and for the development of redundant V2 message templates was the concept-orientation. And so you, too, used the concept-orientation around which to build your framework, with consequences that now became clear. You are as far I am concerned forgiven for that. I was myself for a long time a victim of the concept-orientation. And so were, and still are the people trying to work with the mess created by anything coming out of ISO TC 37 in whose work we find conceptology all over the place.

What I could not forgive, however (although, who am I to make such judgments?), is that now that you are finally becoming aware of the intrinsic problems, you continue to follow the same path. Thus stop NOW with V3 and start thinking about V4. I am willing to provide assistance.

Werner Ceusters, MD
Professor, Department of Psychiatry
Director, Ontology Research Group
NYS Center of Excellence in Bioinformatics & Life Sciences
701 Ellicott street
Buffalo, NY 14214
http://www.referent-tracking.com

*********

The context of the above letter is an exchange on the HL7 Vocabulary List that is reproduced below. An early version of the Ted Klein document referred to therein has already been summarized on this blog here.

At 05:15 PM 2/11/2011, Lloyd McKenzie wrote:
Hi Ted,
... Thus far, we've identified 4 distinct uses for concept representations:

Exchange - A representation intended to represent a concept when persisting data or communicating between two systems (commonly called 'codes')
Internal reference - A representation intended for use in the development and maintenance of terminology artifacts (commonly called 'concept ids')
Display - A representation intended to convey the meaning of a concept to humans when the concept is rendered (commonly called 'designation', or (when restricted to text) 'display name'. Sometimes also referred to as 'term')
Semantic declaration - A representation intended to fully specify the semantic content of the concept (commonly called 'fully specified name')

A given concept representation must have one or more of these uses. In cases where more than one representation may satisfy a given use, it is good practice to designate one of the representations as preferred for that use. In addition, a given type of concept representation within a code system may have a number of characteristics:

comprehensiveness: Indicates whether a representation of that type exists for every concept expressible within the code system.
synonomy: Indicates whether it is possible for a single concept to have more than one representation of a given type. For example, multiple codes or display names for a single concept.
homonymy: Indicates whether it is possible for more than one concept to have a representation with the same type and value. E.g. Display names with the same value for more than one concept.

I would like to see the above represented in the document somehow.
Lloyd McKenzie

From: owner-vocab@lists.hl7.org [mailto:owner-vocab@lists.hl7.org] On behalf of W.Ted Klein
Sent: Friday, February 11, 2011 7:43 PM
To: Lloyd McKenzie
Subject: Re: concept representation

Lloyd,
Although I think I agree that all of what you say is true, this is not what I am attempting to solve with this document.

The proximate difficulty is that we were unable, on several calls, to reconcile several negative ballots on Core Principles to the satisfaction of the balloter, and there was general agreement of the participants that clarity was needed. The needed clarity was specifically around what the definition of, and difference between, the words 'concept representation', 'designation', 'concept identifier', 'display name', and 'code' being the specific words in question. The formal motioned request was for me to write a document explaining these words, and include a table that showed clearly their meanings and differences.

I have no interest at this time in attempting to boil the ocean before next Thursday's call. In this particular document, I want *ONLY* to clarify these five words to the satisfaction of the balloter, and get an agreement of which to use consistently in Core Principles. These are the last comments to be reconciled, and I want to be able to begin the narrow redrafting of only those portions that were negative balloted and reconciled; the plan is that all other parts of the document will remain unchanged from the last ballot.

The other ideas that you mention below are all worthy of further discussion, elucidation, and documentation. But I would argue that should be an additional effort, perhaps complementary, to this one. And how much of this conceptual definition needs to be added to this ballot cycle of Core Principles must also be decided (and my prejudice is to add as little as possible beyond the explicit addressing of the specific comments made on the last ballot, since if more than that is added, we are much more likely to fail to pass ballot this round). If we are unable to control our urges to constantly tinker with it before declaring "done for now", we will never pass ballot IMHO.
Ted

At 10:43 PM 2/11/2011, Wittenber, Jan wrote:
I think it’s reasonable to say that the HL7 “ballot” process (as well as in other standards) has some expected value as concerns getting people to pay closer attention so as to get robust vetting, hopefully spiriting out and prioritizing significant issues for further resolution, and this issue fits the bill, since it deals with first principles of a fundamental set of definitions on/with which potentially much will be built. What is “tinkering” in this case?

Jan

From: W.Ted Klein
Sent: Saturday, February 12, 2011 8:21 AM
Jan,
What I meant is that we *could* go on and on with deeper and fuller explanations until Core Principles becomes an encyclopedic reference for terminologic representation of meaning. And we would never finish. I want to resist the temptation to do this; the goal of Core Principles is to provide a foundation of understanding the principles upon which HL7 Version 3 is built, not a general explanation of terminology and modeling in computer science. We have been through five ballot cycles trying to get something to 'done', and I recognize that whatever we produce can always be improved. At some point we have to declare it 'good enough for this cycle' and move on to the next update. I do not intend Core Principles chapter 5 to be a general computer science terminology reference; only to illustrate where HL7 is using a subset of general terminology principles, and where it has a unique 'twist' on the more general uses of the technology and nomenclature. The places where we have added general definitions and references (at the request of balloters in earlier cycles) were only to make the text of chapter 5 readable, without constant cited references to external sources. It is intended to be illustrative prose, not a research paper. The document I distributed is intended to achieve agreement so that the redrafting of chapter 5 Core Principles addresses the last cycle negative comments on the use of these five words in a consistent and correct way.
Ted

HL7 Clarifies Everything

noreply@blogger.com (Barry Smith) — Fri, 04 Feb 2011 17:08:00 +0000

In my “Beyond Concepts”, published in 2004, I draw attention to a series of problems associated with the widespread use of the term ‘concept’ in knowledge representation circles. I show that the term is rarely defined by those who use it, with the result that it is used with a variety of conflicting and sometimes intrinsically incoherent interpretations, sometimes within one and the same sentence. The resultant problems affect not only human beings but also computer systems, since the latter must rely on artifacts afflicted with the same incoherence. These problems are now, increasingly, being acknowledged in other circles, for example by the IHTSDO, whose most recent (2010) release of SNOMED CT provides the following definition for ‘Concept’:

An ambiguous term. Depending on the context, it may refer to:

1. A clinical idea to which a unique ConceptId has been assigned.
2. The ConceptId itself, which is the key of the Concepts Table (in this case it is less ambiguous to use the term ‘concept code’).
3. The real-world referent(s) of the ConceptId, that is, the class of entities in reality which the ConceptId represents (in this case it is less ambiguous to use the term ‘meaning’ or ‘code meaning’).

As Solbrig and Chute point out:

The term “concept” continues to be used in models to reference categories, classes, universals, individuals and other less well defined artifacts. The fact that this obfuscates the purpose and usefulness of the model itself has already been well documented. Here, we show how the use of the term “concept” as a class name in a model can introduce serious confusion and propose a simple way that such confusion can be avoided. (2009, p. 123)

It is thus heartening that HL7, too, with its vision of ‘creating the best and most widely used standards in healthcare’ in a way that exhibits ‘timeliness, scientific rigor and technical expertise,’ should have turned its attention to its own use of the term ‘concept’. In a new draft document on the representation of concepts that has been posted by the HL7 Vocabulary Group we are told that the concept is ‘The fundamental unit of meaning in HL7 with respect to vocabulary’. We are told further that:

As defined in HL7, “a concept is a unitary mental representation of a real or abstract thing – an atomic unit of thought.” As such, we have to do some work to make concepts computationally tractable.

A concept, as used in HL7, has two fundamental characteristics (it often has other characteristics that are immaterial to this discussion, such as relationships to other concepts):

1. A concept can be identified

2. A concept can be represented

The HL7 model of concept covers #1 by having 1..m identifiers each one of which uniquely identifies the concept. These are required to be easily machine-processable with simple recognition and indexing algorithms.

The HL7 model of concept covers #2 by having 1..m representations, each of which represents the concept in some way. These are usually human-readable, and may or may not be easily machine processable, but are almost always machine renderable. For instance, an image, or video, that represents a particular concept would be a representation of that concept that can be consumed by a human being, and likely rendered by a machine, but generally not easily indexed or matched and recognized with 2011 technology.

... The HL7 model defines a group of concepts with their associated identifiers and representations that are handled as a managed collection. HL7 calls such managed collections Code Systems. The organizations that publish these often use different words to describe the identifiers and representations in their collection, but they all publish identifiers and representations of the concepts in their Code Systems.

HL7 has been using nomenclature for these for years, and some of it is also widely used in the informatics community – but often used slightly differently. It has been shown to be unclear how the different words used related to these fundamental characteristic items are precisely defined, and we have not had an easy way to ensure consistency of use. To make things more challenging, some words that we often use in everyday discussion of vocabulary may be used to mean either or both an identifier or a representation.

The following table attempts to disambiguate this nomenclature we commonly use in HL7:

HL7 Nomenclature Used	Is it an Identifier?	Is it a Representation?	Should it be our preferred nomenclature?
Code	Yes	Sometimes
Term	Sometimes	Yes
Designation	Generally Not	Yes
Concept Representation	Generally Not	Yes
Concept Identifier	Yes	No
Display Name	No	Yes

We conclude from the above that HL7 has a long way to go on the vocabulary front if its existing resources are to advance the sort of precision in use of language that would be required to support the ambitious goal of semantic interoperability in the complex domain of healthcare. We remain convinced that a helpful step towards achieving this goal would be to abandon entirely the use of the term ‘concept’.

Demographics: HL7 vs. Reality. Part 2 – Gender

noreply@blogger.com (Barry Smith) — Wed, 01 Dec 2010 16:13:00 +0000

(The second in a series of posts by William Hogan)

In my last post I showed, on the basis of the example of marital status, how standardization of demographic information is challenging and how typical information-modeling techniques fail to help the problem.

In this post, I show how HL7 handles gender. Again, we will see difficulties for standardization. Additionally, we will see resultant hindrances to informatics support of humane, competent patient care.

First, we must review how the HL7 Reference Information Model (RIM) structures demographic information. It does so primarily by structuring the information as “attributes” of key “classes”, including LivingSubject, Person, and NonPersonLiving-Subject. The latter two classes, according to HL7, “specialize” the LivingSubject class.

The HL7 definitions of these classes are relevant to our understanding of gender, so I reproduce them here.

LivingSubject: An organism, alive or not.

Person: A human being.

NonPersonLivingSubject: A subtype of LivingSubject that includes all living things except the species homo sapiens.

Next, we need to note that the RIM represents gender as the administrativeGenderCode “attribute” of the LivingSubject “class”. We also need to review the HL7 definition of this “attribute”:

The gender (i.e., the behavioral, cultural, or psychological traits typically associated with one sex) of a living subject as defined for administrative purposes.

We are then told of just one such administrative purpose: … the appropriate allocation of inpatient bed assignment.

Problem #1

First, a minor problem. Note that administrativeGenderCode is applicable to all organisms (LivingSubjects), not just human beings. However, the only administrative use case we are given for this attribute is hospital bed assignment, something relevant only to humans. Even if veterinary hospitals assigned “inpatient beds” to animals (as opposed to cages or pens), placing two animals in the same enclosure is the exception not the rule.

Which raises yet another problem.

Problem #2

For humans, single rooms now, too, have become the rule and not the exception, at least in the United States. With the only stated use case for this “attribute” fast becoming a relic of the past, should it remain? I am also struggling to imagine other, non-clinical, administrative uses for administrativeGenderCode.

But larger, much more relevant and important issues loom.

Problem #3

What are we to do for recording gender for “non-administrative” purposes, such as patient care? We are told in the notes for administrativeGenderCode that:

This attribute does not include terms related to clinical gender. Gender is a complex physiological, genetic, and sociological concept that requires multiple observations in order to be comprehensively described.

Thus we find out that, even for humans, the administrative-GenderCode “attribute” is not relevant for recording someone’s true gender! Why not instead call the attribute “bed assignment instruction” (or bedAssignmentInstructionCode), and have values “male bed” and “female bed”?

Here, HL7 has essentially recommended to us more than one way of recording a patient’s gender, with obvious implications for interoperability (more than one way to record something is always a risk to interoperability).

And how are we to record “clinical gender”? The RIM does not tell us (not here, anyway). It is not an “attribute” of a “class”, so presumably we must record it as an “Observation”, a different “class” in the RIM. But then we are allowed to record gender in any of the following non-interoperable ways, even when using HL7 and standard terminologies (with thanks to this document):

Obs.code	Code description	Code terminology	Obs.value	Value code description	Value code terminology
263495000	gender (observable entity)	SNOMED CT	248153007	male (finding)	SNOMED CT
365873007	gender finding	SNOMED CT	248153007	male (finding)	SNOMED CT
248153007	male (finding)	SNOMED CT	---*	---	---
---*	---	---	248153007	male (finding)	SNOMED CT
21840-4	Gender	LOINC	248153007	male (finding)	SNOMED CT

* The value in these cases is simply omitted, as opposed to being populated with one of HL7’s “flavors of null”.

Problem #4

But there is something wrong with my table above. The SNOMED CT code for “male (finding)” above is for the sex, not the gender of the individual. I was forced to use it because SNOMED CT provides no codes for male or female gender (although it does provide codes for “unknown gender” and “gender unspecified”). The code for “male” that I used in the table is a child of “finding related to biological sex”.

The World Health Organization explains sex and gender as follows :

“Sex” refers to the biological and physiological characteristics that define men and women. “Gender” refers to the socially constructed roles, behaviours, activities, and attributes that a given society considers appropriate for men and women.

To put it another way:

“Male” and “female” are sex categories, while “masculine” and “feminine” are gender categories.

We can further distinguish, at a minimum, phenotypic vs. genotypic sex, where the former refers to one’s gross anatomy and the latter refers to the configuration of sex chromosomes in one’s cells (XX vs. XY vs. anomalous configurations). It is possible to have female genitalia but a genotype of XY, for example, due to androgen insensitivity syndrome. Thus the distinction is real and worth making in EHRs. It will certainly be important for interoperability of data generated by chromosomal analyses.

In addition to SNOMED, both HL7 and LOINC also confuse gender and sex. For one, in previous versions of its standards (including the RIM), HL7 referred to this attribute as “administrative sex”. Furthermore, the HL7 NonPersonLivingSubject “class” has an attribute called genderStatusCode, defined as: The state of the primary reproductive organs of a non-person living subject. But of course, the state of an animal’s reproductive organs (and I am not really sure what this means, are they talking about spayed and neutered pets, for example?) has to do with its sex, not its gender. Recall that HL7 defines gender as …behavioral, cultural, or psychological traits typically associated with one sex.

LOINC has codes labeled “gender” for the sex of a baby as observed on ultrasound. It would be difficult indeed to elucidate, even by ultrasound, the “behavioral, cultural, or psychological traits typically associated with one sex” of a fetus. Codes 11882-8 and 11883-6 both have gender as the attribute measured by ultrasound (the “component” in LOINC-speak) but have a “related name” of ‘fetal sex’.

Problem #5

Now, some may say that the distinction does not really matter for “all practical purposes”. And true, in practice, it is only the administrativeGenderCode that gets collected and included as structured data in the EHR, claims submissions, hospital discharge data sets, and so on.

But this is a problem and not a virtue. For many practical purposes, it leads to great confusion and causes problems that physicians take seriously. For example, there was a recent listserv discussion of the Association of Medical Directors of Information Systems on gender vs. sex and how it applies to transgendered and transsexual individuals. One physician describes the following real-world, practical, scenario:

I don’t think there is a clear standard [with respect to representing sex and gender]. For what it is worth, I have a long term patient who went through this, male to female. There is a non ICD diagnosis in [our EMR system] (which I think you use) that I put on the problem list saying “History of sex reassignment male to female.” In registration system gender is as female, but we have discussed that we might need to change that back to male for medical coverage of some conditions in the future or face non coverage and higher [self] pay.

Like most, our preventive reminders aren’t sophisticated enough to pick up the unique issues here, so Pap smears are manually permanently deferred on this patient.

Our organization takes the view that we enter the gender race and ethnicity that you say you are.

So our state-of-the-art EHRs cannot even represent sex vs. gender, let alone reason appropriately with the data or exchange sex and gender data in an interoperable way. And HL7 and related terminology standards offer us no assistance, and even hinder us, in this regard.

With the net effect that our entire healthcare information system is really using an attribute—intended only for gender-specific bed assignment, an increasingly irrelevant task—for patient care, setting health care policy, and numerous other secondary uses of “administrative-but-forced-on-physicians-and-patients-as-clinical-at-least-in-part-because-IT-vendors-and-IT-departments-and-standards-organizations-cannot-figure-out-sex-vs-gender” data.

Demographics: HL7 vs. Reality. Part 1 – Marital Status

noreply@blogger.com (Barry Smith) — Mon, 22 Nov 2010 16:32:00 +0000

(First in a series on HL7 and Demographics from Bill Hogan.)

When it comes to demographic information, the conventional wisdom is that things like gender, race, marital status, birth date, etc. are fairly simple things to represent and collect. It should, then, be of little trouble to standardize demographic information, especially since demographic data have broad usage and applicability beyond just health care.

Unfortunately, the conventional wisdom is wrong. Like so much other data, demographic data are rarely standardized. A failure to account for what it is on the side of reality that we wish to capture in an information system plays an important role in creating this situation.

A brief review of the HL7 experience in harmonizing standards for demographic data as well as how the HL7 RIM handles demographic data, is illustrative. In this post, we consider marital status.

First, an HL7 effort to harmonize marital status codes with other standards development organizations (SDOs) has encountered problems, such as other SDOs going out of business, intellectual property issues, specifying which SDO will “own” and “maintain” various sets of code values, new suggestions for other standards for the task, and re-opening of discussions about the status of particular codes, their “meaning”, and their appropriateness for inclusion (see thread below). The ultimate status of the harmonization effort is that HL7 never formally adopted the harmonized codes for marital status. It appears that the Health Information Technology Standards Panel (HITSP) did adopt them prior to going out of business. It seems that no other standards organization has adopted them. What follows is from the HL7 Vocabulary Working Group listserv and highlights the issues (the context is supplied below):

Originally the plan was to have HITSP be the maintainer of this value set, but obviously that is not possible now with the ending of the funding for HITSP...

On the X12 side of the ledger, I have started to do the Data Maintenance to get the HITSP approved value set referenced in the X12 standard. The hold up for that is the need for X12 to know the maintaining organization…

It would not be good to have HL7 making changes to fit its implementation and that be different than the value set that gets recognized as the standard used by X12.

With respect to how the RIM represents marital status, first we note that HL7 places most demographic information as “attributes” (in HL7 lingo) of two classes: LivingSubject and Person. Note that the latter specializes the former.

LivingSubject “attributes”

administrativeGenderCode

birthTime

deceasedInd

deceasedTime

Person “attributes”

raceCode

ethnicGroupCode

maritalStatusCode

So, marital status is an “attribute” of the Person class. Note that the Person class, per the RIM, may be used to represent a group of people as well as a single person. What the marital status of a group of people might represent is not clear.

HL7 volunteers worked diligently to create a “harmonized” value set for the marital status “attribute”. In HL7, a “value set” is essentially a collection of codes that may serve as the value of an “attribute” of a “class” in the RIM. The harmonized value set, which draws marital status codes from SNOMED CT, is as follows:

SNOMED CT Code	SNOMED CT Fully Specified Name
125725006	Single, never married (finding)
20295000	Divorced (finding)
2326000	Marriage annulment (finding)
3353000	widowed (finding)
87915002	Married (finding)
13184001	Separated (finding)
430617007	Legaly Separated with Interlocutory Decree (finding)
22187004	polygamous (finding)
430618002	Domestic partnership (finding)
408821002	Lives with partner

(also available here:

http://publicaa.ansi.org/sites/apdl/Documents/Forms/DispForm.aspx?ID=65633&Source=http%3A%2F%2Fpublicaa%2Eansi%2Eorg%2Fsites%2Fapdl%2FDocuments%2FForms%2FAllItems%2Easpx%3FRootFolder%3D%252fsites%252fapdl%252fDocuments%252fStandards%2520Activities%252fHealthcare%2520Informatics%2520Technology%2520Standards%2520Panel%252fStandardization%2520Committees%252fFoundations%252fUp%2520for%2520Panel%2520Approval%26View%3D%257b21C60355%252dAB17%252d4CD7%252dA090%252dBABEEC5D7C60%257d&RootFolder=%2fsites%2fapdl%2fDocuments%2fStandards%20Activities%2fHealthcare%20Informatics%20Technology%20Standards%20Panel%2fStandardization%20Committees%2fFoundations%2fUp%20for%20Panel%20Approval

Note that the spelling mistakes are the fault not of SNOMED CT, but of whomever transcribed the codes into the set.)

So, what is wrong with this set of codes? Well, in reality, either one is married or not. Thus there are only two statuses. The remainder of the information has nothing to do with one’s marital status per se, but also includes information about one’s marital history and living arrangements. For example, if you are divorced, then your marital status is “not married”, but it so happens that your most recent marriage ended by legal dissolution. Similarly, if you are widowed, then you are “not married”, but your most recent marriage ended with the passing of your spouse. Living arrangements also come into play in “separated”, which means “married” but “living apart”. Note that a legal separation (which does not necessarily imply “living apart” – see the movie War of the Roses) requires a different code.

Capturing various subsets of the combinatorics of status plus history plus living arrangements plus etc. is what causes such divergence and diversity (and thus non-standardization). SNOMED CT, from which the value set was drawn, includes numerous other, interesting, and active-for-clinical-use “marital statuses” such as “Spinster”, “Eloped”, “Newlywed”, and “Cohabitee left home”.

Of course, we do not deny the need for ease of data entry. Yes, picking “divorced” from a list is easier than picking “not married” from one list and then picking “most recent marriage ended with legal dissolution” from another list.

Also, we do not deny the need for parsimonious display of information. “Divorced” can communicate the information needed quite efficiently (assuming that there is a use case for “divorced” vs. “widowed” vs. “annulled”).

However, parsimony in data entry and display does not mandate parsimony in representation. Furthermore, representational shortcuts that combine information about multiple entities in reality, as with these marital status codes, frustrate interoperability – an outcome which HL7 and other SDOs are presumably trying to avoid.

HL7 Vocabulary Working Group Thread on Marital Status

Whatever happened to the new marital status codes?

Sat, Aug 28, 2010 at 6:39 PM

Reply-To: tom@nova-pro.nl

To: vocab@lists.hl7.org

Hello vocab gurus,

A while ago (must be 2 years by now) I was part of a group that spent quite a bit of time coming up with a new and improved code system for marital status codes. This resulted (as far as I know) in a list that everyone involved was quite content with). To my amazement, when I looked up marital status in the current HL7 vocabulary, I found the same old codes there were before. What happened to the new set?

Thanks,

Tom

Cecil Lynch

Sat, Aug 28, 2010 at 7:48 PM

Reply-To: Cecil Lynch

To: tom@nova-pro.nl, vocab@lists.hl7.org

I remember that well and Bob Davis had the lead on it and I submitted the additonal SNOMED codes to round out the set.

Cecil

Kevin Coonan

Sun, Aug 29, 2010 at 9:04 AM

Reply-To: Kevin Coonan

To: Cecil Lynch

Cc: vocab@lists.hl7.org, tom@nova-pro.nl

I think one of the codes got caught fooling arround with one of the ActRelationshipType codes and they split up.

Bob Dolin

Sun, Aug 29, 2010 at 12:04 PM

Reply-To: Bob Dolin

To: Cecil Lynch

Cc: tom@nova-pro.nl, vocab@lists.hl7.org, Robert Davis

Greetings,

Attached is the set the Bob Davis developed (see section 4.1). I believe all the requested SNOMED codes were created, and are included here.

Take care,
Bob

HITSP Foundations Harmonization Notice Jun_090526-2.doc
163K

Ted Klein

Sun, Aug 29, 2010 at 5:32 PM

Reply-To: Ted Klein

To: Bob Dolin , Cecil Lynch

Cc: tom@nova-pro.nl, vocab@lists.hl7.org, Robert Davis

Thanks for posting this, Bob.

I don't ever recall seeing this material submitted to Harmonization, which is the only mechanism to get vocabulary updates into HL7 vocabulary.
The values that ARE in the v3 vocabulary are the most recent ones submitted by Bob Davis some years ago for Marital Status. Note that this is the Code System. The only Value Set in the HL7 published vocabulary built on this code system, also named 'MaritalStatus', contains all of the codes in the Code System, plus something odd apparently pulled in from UB92. I suspect this is some historical artifact, and represents an error that needs to be cleaned up. Or it might have been inserted in an attempt to cover the situation where local statue requires the codes in the UB92 form locator 16 to be used. Someone needs to examine this.

I note that the HITSP document does not list one of the concept from Bob's set, Interlocutory. And one of the concepts in your set, Separated (as distinct from Legally Separated), does not exist in the HL7 set. I recall some of the discussions in Vocab on these two, and am curious about the differences, since Vocab and Harmonization ended up agreeing with the set that is in the V3 vocabulary as of right now after quite compelling discussion about Interlocutory and the issues around some kind of 'separation' that is not 'legal separation' but is somehow distinct from 'married' as required for the data entry and processing. I can't recall all the discussions now.

If you want a Value Set added to the V3 vocabulary store, it MUST come through the Harmonization process, using a Vocabulary Facilitator. I know that there have been some challenges in the last two years with vocabulary facilitators in structured documents. I don't know how you intended for this to come through. But I've never seen this SNOMED value set ever show up.

Let me know.

-Ted

Orvis, Nancy, CIV, OASD(HA)/TMA

Mon, Aug 30, 2010 at 7:31 AM

Reply-To: "Orvis, Nancy, CIV, OASD(HA)/TMA"

To: clynch@surewest.net, tom@nova-pro.nl, vocab@lists.hl7.org, Gregg.Seppala@med.va.gov

Greg Seppala, did this get changed or harmonized at HITSP or with the SCO (Stds Coord Org)?
Nancy Orvis

Gregg Seppala

Mon, Aug 30, 2010 at 8:53 AM

Reply-To: Gregg Seppala

To: "Orvis, Nancy, CIV, OASD(HA)/TMA"

Cc: clynch@surewest.net, tom@nova-pro.nl, vocab@lists.hl7.org, Gregg.Seppala@med.va.gov

Nancy,
The value set was recommended by HITSP Foundations, accepted by the SDO's, approved by the Panel. That is where the cracks start showing up -- I am not aware of any firm process for updating HITSP constructs to reference the approved value set and adoption by SDO's was left to each SDO. I think the SDO's agreed to at least map their existing values to the value set some day.

Gregg Seppala
Patient Administration WG Co-chair

Orvis, Nancy, CIV, OASD(HA)/TMA

Mon, Aug 30, 2010 at 9:30 AM

Reply-To: "Orvis, Nancy, CIV, OASD(HA)/TMA"

To: Gregg Seppala

Cc: clynch@surewest.net, tom@nova-pro.nl, vocab@lists.hl7.org, Gregg Seppala

So Gregg, can't we initiate HL7 adoption via PA or vocab committee/org ballots and have the submitters be the HL7 reps that worked with HITSP and SCO (e.g. you and John Quinn)? To me, as the DoD Member of HIT Stds committee and the DoD lead on Federal Health Architecture, and a federal agency observer at the Sco, HL7 should take those specs back and incorporate for discussion as to whether HL7 wishes to change its internal vocabularies, change the vocab for the US domain, or have a mapping. I believe this is important to address this year starting this September. Any agreement or other thoughts?

Nancy J. Orvis, M.H.A, CPHIMS
Dir Health Stds Participation & IM/IT Integration
Office of Information Management
DoD(HA)/TMA

Gregg Seppala

Mon, Aug 30, 2010 at 10:57 AM

Reply-To: Gregg Seppala

To: "Orvis, Nancy, CIV, OASD(HA)/TMA"

Cc: clynch@surewest.net, tom@nova-pro.nl, vocab@lists.hl7.org, Gregg Seppala

Nancy,
Since Plan A (Bob Davis working with Vocabulary work group who approved the change) did not work then submitting a harmonization proposal from Patient Administration would be a reasonable Plan B. I can add it to the agenda for Cambridge to seek PA endorsement.

Orvis, Nancy, CIV, OASD(HA)/TMA

Mon, Aug 30, 2010 at 12:03 PM

Reply-To: "Orvis, Nancy, CIV, OASD(HA)/TMA"

To: Gregg Seppala

Cc: clynch@surewest.net, tom@nova-pro.nl, vocab@lists.hl7.org, Gregg Seppala

I can support that.
Nancy J. Orvis, M.H.A, CPHIMS

W.Ted Klein

Mon, Aug 30, 2010 at 6:21 PM

Reply-To: "W.Ted Klein"

To: Gregg Seppala , "Orvis, Nancy, CIV, OASD(HA)/TMA"

Cc: clynch@surewest.net, tom@nova-pro.nl, vocab@lists.hl7.org, Gregg Seppala

One nit that we still need to get run to ground: I am still waiting for a resolution from NLM on the IP issues surrounding publishing SNOMED Concept Identifiers in the HL7 Vocabulary, in Value Sets that are added to HL7 by HL7 members. The issue is that the vocabulary is published internationally to all HL7 member affiliates, and many of them are not SNOMED licensees. I have had some conversations with NLM on this and we are working towards a solution, but we are not there yet. Hopefully we'll have an update on this in Cambridge.
-Ted

Lloyd McKenzie

Mon, Aug 30, 2010 at 7:42 PM

Reply-To: Lloyd McKenzie

To: "W.Ted Klein"

Concept ids with no display names aren't terribly useful . . . And if the SNOMED codes are nicely structured, we should be able to define the value set by only referencing a single concept id.

Lloyd McKenzie

W.Ted Klein

Mon, Aug 30, 2010 at 8:57 PM

Reply-To: "W.Ted Klein"

To: Lloyd McKenzie

That is exactly what the discussion with NLM is all about. The current 'not terribly useful' format is the only one that we are certain will not violate IP restrictions. So that is what we are stuck with until we get clarification.
-Ted

Case, James (NIH/NLM) [E]

Tue, Aug 31, 2010 at 8:29 AM

Reply-To: "Case, James (NIH/NLM) [E]"

To: Lloyd McKenzie , "W.Ted Klein"

I took a look at the new hierarchy and unfortunately found some issues with it that relate more to the internal structure of SNOMED CT than to content coverage, but suffice to say that all of the concepts needed are under a single parent, so as Lloyd suggests, the value set can be defined by referencing a single concept ID.

Jim

James T. Case MS, DVM, PhD

Health Program Specialist, SNOMED CT

National Library of Medicine/NIH

rdavis@nahdo.org

Tue, Aug 31, 2010 at 9:35 AM

Reply-To: rdavis@nahdo.org

To: "Case, James (NIH/NLM) [E]"

Hi All,

I am sorry I was away yesterday to not weigh in on this discussion. Lots of history here. The list of concepts that was ultimately approved as a HITSP standards was originally created with a joint HL7 and X12 harmonization project. The key HL7 group was Vocabulary of which I have lots of thanks but a particular shout out to Ted and Cecil. That list of concepts was taken to HITSP and they gave their seal of approval on the work done by the joint HL7 and X12 work groups.

Originally the plan was to have HITSP be the maintainer of this value set, but obviously that is not possible now with the ending of the funding for HITSP. I had a conversation with Jim Case soon after HITSP ceased to exist. My concern then and persists today is who will be the maintainer / keeper of the data set. Since we want multiple SDO's to implement the HITSP approved standard, I believe we need to have a central authority determine the standards that will apply to health transactions. That is the conversation that I started with Jim.

On the X12 side of the ledger, I have started to do the Data Maintenance to get the HITSP approved value set referenced in the X12 standard. The hold up for that is the need for X12 to know the maintaining organization. To me that is the void left by not having a HITSP or some other entity to be a recognized central authority.

I would assume that much of this tread of discussion is about HL7's implementation of the HITSP Marital Status recommended standard. If that discussion leads to the need to make changes then it expedites the need to find a maintainer recognized by all the SDO's. It would not be good to have HL7 making changes to fit its implementation and that be different than the value set that gets recognized as the standard used by X12.

Bob Davis
518-456-1735

W.Ted Klein

Tue, Aug 31, 2010 at 9:40 AM

Reply-To: "W.Ted Klein"

To: rdavis@nahdo.org, "Case, James (NIH/NLM) [E]"

Cc: Lloyd McKenzie , Gregg Seppala , "Orvis, Nancy, CIV, OASD(HA)/TMA" , clynch , tom , vocab , Gregg Seppala , Don Bechtel , Bob Dolin

Nice summary of the history, Bob. Thanks!

That still leaves the question as to whether the final set is to use the HL7 codes, or the SNOMED equivalents that were developed, and still leaves the issue of whether or not the semantic between the HL7 concept for 'interlocutory' and the SNOMED 'separated' are identical or not. And if, as Nancy suggests, a mapping is to be maintained between the two of them, where should such a thing be housed? (HL7 does not persist nor distribute mappings at this time).

-Ted

Case, James (NIH/NLM) [E]

Tue, Aug 31, 2010 at 10:28 AM

Reply-To: "Case, James (NIH/NLM) [E]"

To: "W.Ted Klein" , "rdavis@nahdo.org"

Just from a definitional standpoint, I think that the semantics between "interlocutory" and "separated" are sufficiently different from each other that they should not be cross mapped. In thinking about it, I don't really think that Interlocutory belongs in the value set at all as it defines the procedural process rather than the marital status.

I think Bob's point about the maintenance authority is an essential one to resolve as well.

Jim
James T. Case MS, DVM, PhD
Health Program Specialist, SNOMED CT

Bron Kisler

Tue, Aug 31, 2010 at 12:10 PM

Reply-To: Bron Kisler

To: "Case, James (NIH/NLM) [E]"

Ted et al,

CDISC also worked on harmonizing with the HITSP recommendation for Marital Status. It seems like there was only a difference in 1-term, but I don't know if the final HITSP recommendation was made / implemented. We have Marital Status terms coded in NCI Thesaurus that are open and free for anyone to use in the world. Below are the terms we have. If we need to add something, we will be glad to in order to be harmonized with HL7 and accommodate your needs. Let me know if this is a solution you would be interested in.

See you tomorrow in DC -- Bron

Annulled

Divorced

Interlocutory

Separated

Married

Never Married

Widowed

Polygamous

Domestic Partnership

The National Cancer Institute Thesaurus and Its Errorsome Ways

noreply@blogger.com (Barry Smith) — Thu, 18 Nov 2010 15:21:00 +0000

In 2005 Werner Ceusters, Louis Goldberg and I published "A Terminological and Ontological Analysis of the NCI Thesaurus" in which we provided a catalog of different types of mistakes in the NCIt, including mistakes in applying its underlying OWL-based knowledge representation system. As a result, the National Cancer Institute commissioned a major overhaul of the Thesaurus using the list of types of errors we identified as basis.

A new study by Stefan Schulz and his colleagues on "The Pitfalls of Thesaurus Ontologization", however, suggests that the organization contracted to carry out this overhaul may in fact have made things worse. As Schulz et al. point out

more than 76,000 axioms in the OWL-DL version [of the NCIt] make incorrect assertions if interpreted according to description logics semantics. These axioms therefore constitute a huge source for unintended models, rendering most logic-based reasoning unreliable.

These problems are not unique to the NCIt – they affect other major clinical terminology resources employing one or other description logic-based approach.

As we believe we have demonstrated, for example, in the OGMS (Ontology for General Medical Science) initiative, the use of OWL-DL is compatible with a realistic representation of a complex domain; but it can be achieved only through a painstaking analysis of the types of entities in the domain in question and of the relations between them. Translation of natural language assertions into OWL, at the superficial level of the sort that we find in the NCIt, leads too often to errors.

The HL7 organization itself, for good or ill, has not yet embraced the description logic-based approach, and is thus gratifyingly free of the sorts of errors referred to in the above. It does, however,exert a certain influence on the NCI, which extends also to the NCI Thesaurus.

Comment (November 18, 2010) from JL (eHealth software architect):

Well in the end, the fundamental problem in eHealth is the lack of market incentives to embrace efficiently working solutions. The (partially inevitable) regulation of the health domain by the state creates a specific space in which the tyranny of mediocrity thrives. Hospitals and GPs have incentives to not use good software. The use cases are so primitive and can be met with simple measures because physicians do not want sophisticated eHealth systems. Business domains with market forces in place (logistics, transportation) are embracing clever software ... it is so depressing.

Comment (November 18, 2010) from Tom Beale:

This is bad. But there is likely a grain of truth in that statement, about corrections not changing the ability of NCIt to meet the uses cases. I know how this looks, especially to us cynics, but my observations of SNOMED CT/IHTSDO over the last 2 years (including going to committee, SIG meetings, etc.) is that there is almost no prospect of SNOMED CT being generally used for computational inferencing in a clinical or research environment in less than 5 years. The problem of the errors is almost secondary: the challenges of educating not just end users, but procurement people, software architects and developers, of getting terminology service interfaces agreed (i.e. CTS 2) and a myriad of other purely practical things mean that it could be a long time before all but the most progressive organisations start deploying anything like business intelligence apps or computerised clinical guidelines. I think nearly all computation for the short term will be done against IS-A relationships on ref sets carved out of SNOMED, removing specific errors on the way.

This is not necessarily all bad: it means there is a 5 year window to get SNOMED CT sorted out properly. The challenge is to come up with the right analysis and change programme to do this. 5 years will seem an amazingly and possibly unacceptably long time, but the evidence so far of uptake and engagement with complex technologies and standards in the e-health space is that 5 years is extremely realistic.

Reply (November 19, 2010) from Barry Smith:

I agree with the views of JL and Beale, above, to the effect that there is little prospect of SNOMED CT, or NCIt, being generally used for computational inferencing in the immediate future. In my view, however, this makes the task of providing a strategy for coherent evolution of these artifacts even more important. Currently, we are witnessing a situation in which large clinical terminologies are subjected to regular and poorly coordinated revisions, resulting in uncertain value of the information that is annotated in their terms. To create the possibility for coherent evolution and gradually increasing value of these artifacts – of the sort that has the chance of motivating the needed investment in a more sophisticated computational infrastructure – we need to identify a growing set of principles of good practice in terminology development, and to ensure as early as possible that the terminologies in question are developed in such a way as to satisfy these principles. One such principle is, surely: freedom from logical error.

Are the ISO 21090 Data Types Too Complex?

noreply@blogger.com (Barry Smith) — Tue, 09 Nov 2010 18:40:00 +0000

An interesting series of postings on this topic on the openEHR lists. Once again, it would seem, HL7 has succeeded in bringing about a situation in which an international standard is needlessly difficult to use.

As Thomas Beale puts it, while ISO 21090 ("Health Informatics — Harmonized data types for information interchange") presents itself as a general datatype specification, it is essentially an HL7 specification:

No-one could possibly have come up with 21090 as it is today without the starting point being the HL7v3 data types.

ISO 21090 is thus optimized only for HL7v3 messaging – which is hardly being used. It includes multiple attributes not useful to non-messaging users. And it is not defined in a normal object-oriented way. It is, accordingly, “a huge missed opportunity".

Some extracts from the discussion:

From: Thomas Beale

· Date: Sat, 06 Nov 2010 21:35:36

... my list of problems [with ISO 21090], from a cursory examination:

1. The model is defined [in such a way] that all data types inherit from HXIT and then ANY, which contain 7 attributes specific to HL7v3 messages. This means that any other types, such as BL (Boolean) inherits these attributes. This is a basic modelling error, since the normal approach is to separate context-specific attributes (e.g. specific to the use of data values in messages, but not other uses) into ‘wrapper’ classes. The practical effects of this modelling are twofold:

There is not a close correspondence between the 21090 idea of ‘ANY’ and the typical Any/Object or other root class of most object-oriented type systems – this name clash would have to be resolved in some way;

an implementation of the 21090 data types is forced to have HL7v3 specific attributes in its base classes, and it also complicates the use of more orthodox modelling for such purposes;

alternatively, to produce a version of 21090 for use outside of HL7v3, a ‘profile’ of some kind has to be developed by ISO and/or CEN.

2. It includes ‘types’ for name and address that are really compositional structures, and would normally be considered to be archetypable or otherwise configurable structures consisting of lists, trees etc of primitive types (String, Integer etc); (this problem has been around forever in HL7. I was in CEN meetings in 2002 or 2003 when people were complaining about this. It might make sense for HL7, but it doesn't in more generic modelling frameworks)

3. It uses a modelling notion called ‘flavours’ defined via ‘common constraint patterns on existing datatypes’, whereby e.g. the timestamp type TS can be constrained to TS.CA.BIRTH, i.e. a variant used in Canada for recording birth dates. The problems with this approach include:

is that it is not supported in any standard industry UML or related tools (e.g. Eclipse Modelling Framework); (It is sort of doable in OO languages, but it breaks the normal spirit of OO modelling, and is not conducive to maintainability)

class-names containing the ‘.’ character are not legal in most type systems;

it is not generally known or understood by IT practitioners;

it is not clear how such ‘constrained types’ should be implemented in normal object-oriented development technologies;

it mixes the concept of localised constraint that would normally be defined outside of the software, with ‘hard’ data types that would normally be implemented in the software (e.g. TS would normally be implemented in software, but implementing ‘Canadian birthdate’ is likely to make software brittle).

4. Due to the above problem, date/time types typically needed in clinical data, and archetypes, are defined using types: TS.DATE, TS.DATETIME, although there is no match for the logical type ‘Duration’ or ‘Time’.

5. The error of including context-specific attributes within base types occurs elsewhere in the specification. To give two examples:

The type TEL (telecommunications address) includes the attribute ‘useablePeriod’, intended to indicate when the address is useable. Normally such a context attribute would be found within a context specific information structure representing ‘Contact’ or some other typical demographic concept in which not only the date range, but also type / purpose (e.g. ‘business’, ‘home’) might be recorded. 21090 forces it to be in every instance, although it presumably can be empty (as is likely in most instances).

The type II (instance identifier) includes the coded attribute ‘reliability’ which indicates whether the identifier was ‘issued by the system’, ‘verified by system’ or ‘unverified by system’.

The modelling style seems to follow the strange HL7 obsession with non-object orientation, popularised in the RIM. In summary, I don't see 21090 as being at all appropriate for the title of the standard, which is "Health Informatics — Harmonized data types for information interchange". Instead, it should just have been called "Data types for HL7-based messaging". It doesn't make sense as an ISO standard; it is really an HL7 standard.

*From: Eric Browne

*Date: Mon, 8 Nov 2010 13:34:56 +1030

… I'd like to add my voice to Tom's concerns.

I certainly believe that the whole ISO process with respect to health informatics standards is deeply flawed. As Grahame [Grieve] implies with the datatypes standard, the process is politically driven and compromises in modelling, engineering, safety, implementability inevitably occur. The question is how significant are these compromises and what effect will they have on the evolution of e-health?

It is highly unlikely that we would have an ISO standard for "Health Informatics - Harmonized data types for information interchange" without the monumental effort of Grahame Grieve in producing and managing the draft. However, it is, first and foremost, an HL7 flavoured standard. The most recent draft I have seen is, according to its forward, "a shared document between Health Level Seven (HL7) and ISO". ISO 21090 is undoubtedly complex. One has to question the value of an international standard, if it is so complex that it has to be 'profiled' by different organisations before it can be used. By whom, for what purposes, and by what processes, will such profiling be managed?

ISO 21090 suffers some of the significant flaws that permeate much of HL7 specifications. Tom has already cited the peculiar inheritance hierarchy amongst others. Another engineering flaw is the pervasive use of cryptic, often ad hoc enumerations. Even the names of the types wouldn't pass muster in most quality engineering schools. Names like ENP, HXIT, CO, EN, EN.TN, CD.CV, URG are simply inexcusable. Levels of indirection never aid readability, and lead to difficulty in implementation and testing.

It is not necessarily sensible to compare openEHR datatypes with ISO 21090. They are designed for different purposes. openEHR datatypes underpin openEHR's reference implementation and archetype object models for building electronic health record software and so can be augmented by these additional artefacts, as described below. The ISO datatypes should be able to stand on their own in a diverse range of implementation environments. This is a much harder task, and bumps up against fundamental principles of information exchange, whereby the assumptions of participating systems need to be carefully considered. Constraints and constraint mechanisms are pivotal here.

A datatype embodies the "agreed" set of values and operations pertaining to that type. If an item of received data "211414" has been denoted to be of type integer, then the receiving system "knows" how to process it, and will process it differently than if it had been denoted as a date ( AKA TS.DATE in HL7/ISO/DIS 21090 HI-HDTII ). Healthcare includes a very rich vocabulary, and text-based value sets are common in information exchange. A datatype for coded text, say, needs to convey the agreed set of values of that type. Let's firstly consider values for "severity of adverse reaction to medication". Ideally, both a sending and a receiving system needs to agree on the set of values - and may behave sub-optimally if one system uses the set { "undetectable", "mild", "moderate" } and the other uses the set { "mild", "moderate", "severe", "extreme", "almost inevitably fatal" } , even if these values all came from the same terminology. In other words, the sending and receiving system are not actually using the same datatypes in this case.

How do we deal with this in real systems? The United Kingdom's Connecting for Health program has addressed this in their HL7 V3-based models by carrying the constraint within the datatype - in the coding scheme's identifier. So rather than say the values come from some specific version of SNOMED CT, they constrain the values to a specific subset using a Refset Identifier. And this can be carried in instance data.

Now whilst ISO 21090 is capable of constraining text-based value sets, such constraints are often done by other means - particularly through conformance statements in non-computable documents, most notably HL7 CDA Implementation Guides. We are seeing plenty of this in the US, as a result of their Meaningful Use provisions. In these cases, the datatype does not necessarily carry the constraint. It almost invariably doesn't. This means that in such transactions, the receiving system has no way of knowing the true datatype - i.e. the set of values - for each such data item. The only way for such constraints to be known to the receiving system is through access to HL7 templates - thus violating THE principal tenet of HL7's RIM-based information exchange paradigm.

*From: Thomas Beale

*Date: Mon, 08 Nov 2010 21:18:40 +0000

On 08/11/2010 18:51, Grahame Grieve wrote: It seems remarkable to me that people think it's a problem that ISO 21090 needs to be profiled. Who would've guessed that a full standard that meets many requirements is simpler to implement if you profile out the features that reflect requirements you don't have? I'm pretty sure that this is true of every other standard as well. It's certainly true of all my implementations of W3C, IETF, and OMG standards.

I know that in HL7 this profiling is normal. The only kind of 'profile' I know of elsewhere in other standards is of the kind 'we only implement x, y but not z'. In other words, choosing a subset of classes or features to implement. As soon as one has to actually chop up the classes in a model however, we are on different ground. The answers Grahame gave me last time I discussed how to profile 21090 for 13606 use are here, about half-way down. As you can see, it was not 100% clear on a cursory inspection what exactly the profile version would look like. .... This means that official users of 13606, e.g. Sweden, can't actually use the standard out of the box, and do not have any official version to use until that work is done.

I happen to know that Sweden, Singapore and the UK have created at least 3 different 'profiles' of 21090 over time, all to suit their own needs. There is no guarantee that data or software built on these home-grown profiles will talk to each other, nor that any of them would talk with software or data built on the pure 21090 specification. So in fact, we have N pseudo-standards, and no real standard. This can't be anybody's idea of an easy way to get started with a data types standard.

… Note that I am not particularly making criticisms as if it were me personally trying to address the problems; I am mainly reflecting common responses from others, e.g. in government departments, universities and so on. There is no escaping from the fact that having a type called 'Any' representing a concept that should be called something like 'AnyDataValue' (in openEHR it is DV_ANY) is annoying and has to be dealt with in some way.

[It is sometimes said that] In health informatics, standards are done differently.

I have not been tracking other vertical industry ICT standards. But I did offer examples of 'stacks' of standards which do not follow the strange world of HL7 modelling. Everyone else uses normal OO modelling, or else something accepted like XML schema (admittedly terrible for object models, but that's another story); but HL7 can't (it instead tries to get OMG to change UML). I fail to see why standards in e-health have to be done in such a bizarre way. There is nothing special about e-health requiring that.

*From: Thomas Beale

*Date: Tue, 09 Nov 2010 11:38:53 +0000

… RIM-based models are famously incomprehensible to people from all walks of life. Again, there are some people (including some clinicians) who understand them, and can author them, but they are a) not very intuitive and b) highly complex, for realistic examples. Due to the lack of basic data structures, e.g. the example of History/Events structure used in openEHR, such structures are avoided, or have to be manually created from Act / ActRelationship networks. The huge number of attribute nodes and code values also causes complications; I once calculated the value space of a single Act node with its 22 attributes to be 810 billion points. You can guess that the possible value space of a realistic RMIM is astronomical. This makes building models difficult. The traffic on the HL7 MnM list indicates the massive ongoing confusion around these models for a decade. If you don't believe me, try searching your archive simply for posts relating to 'context conduction'. If this modelling method were easy, everyone would be using it.

RIM "Effective Time": Still confusion after 14 years

noreply@blogger.com (Barry Smith) — Mon, 13 Sep 2010 09:57:00 +0000

From a recent discussion on an HL7 email list.

On Fri, Jul 2, 2010 at 3:53 PM, Bob Dolin wrote:

Greetings,

2-July-2010

3:53 pm

From: Bob Dolin

To: ?

Greetings,
Per the RIM, "for clinical Observations, the effectiveTime is the time at which the observation holds (is effective) for the patient". Does this mean that the effectiveTime for a date of birth observation is the same as the date of birth?

Thanks,
Bob

3-July-10

3:22 pm

From: Lloyd McKenzie

To: ?

If you chose to specify it, it would be an interval from date of birth to positive infinity. I.e. It has held since they were born and will hold forevermore. However, I'd generally omit effective time for observations whose values aren't expected to change and for which only one value can be "true".

Lloyd McKenzie

+1-780-993-9501

3-July-10

No Time Given

From: Rene Spronk

To: Lloyd McKenzie

Lloyd,
If I were to observe, without knowing the exact birthdate, the bithdate (i.e. I'm guessing), the associted effecive time might well be "(up to) the next week" if I assume we'll get hold of the true birthdate within that week. Correct? If I were to observe a known (true) birthdate then effectivetime doesn't make a lot of sense (it has no additional value).

TTYL,
Rene

3-July-2010

10:23 am

From: Lloyd McKenzie

To: Rene; Bob Dolin; mnm

Subj: Re: what is the effectiveTime for a date of birth observation

Hi Rene,

When you observe a birthdate you don't expect the value to change. If you're uncertain, you convey that with uncertainty code. The date of birth is effective forever even if you have 5 observations with different values. (Hopefully with the most recent superceding the others.)

Lloyd

3-July-10

No Time Given

From: Cecil Lynch

To: ?

I think the whole issue is that this is not an observation at all. It is a fixed characteristic of a person and is a TS, not an effectiveTime.IVL. It seems strange to think of this as an observation at all to me. You might be present in the delivery room and observe the birth, but there is still a fixed TS that represents the documentation of what you observed on the clock, a point in time.

Cecil

3-July-10

19:40

From: Lloyd McKenzie

To: Cecil Lynch; Rene Spronk (Ringholm); Bob Dolin; mnm
Subject: Re: what is the effectiveTime for a date of birth observation

Agree you wouldn't generally capture birth date as an observation. However, if you do, the effective time is the time the observation is deemed to hold true. The same would be true for something like a
paternity test. If the test says "you're almost certainly the dad", then the period of time that assertion is believed to be true is from time of conception to positive infinity.

4-July-10

4:26 am

From: Rik Smithies

To: Lloyd McKenzie

Hi Lloyd
Do we have to decide at record time how long something is likely to be true for?

Do we assume that some things are only true for an instant (eg a lab test) but some things are help to be true longer and so need an IVL with plus infinity? Are there any values in between?

What about a date observation for something that is less of a lifelong thing such as Last (most recent) Menstrual Period?

I'm used to using a TS for the event to mean the clinically relevant date/time. And if I am observing, say, a broken leg it would be leg break time. I wouldn't be saying how long that will be true for. I'm not even sure what that would mean.

Are my observations becoming untrue after that instant? ;-)

Rik

4-July-10

18:14

From: Lloyd McKenzie

To: Rik Smithies

CC: Cecil Lynch; Rene Spronk (Ringholm); Bob Dolin; mnm
Subject: Re: what is the effectiveTime for a date of birth observation

Hi Rik,
You never *have* to decide anything. You can always omit effectiveTime. In theory you can make a narrower observation than what you know to be true. E.g. "At this particular instant, I believe your date of birth to be X, but I make no assertions about what your birth date might be at any other time . . ."

Observation.effectiveTime indicates when the person/device/whatever believes the observed value holds true. So if you're making a retroactive diagnosis, the effective time would be the period of time when the patient had the condition. (e.g. I think that fever you had when you were 3 months old was really . . .). For something like "last menstrual cycle", that would usually be a point-in-time observation, though if you wanted to, it could be an interval from the start of the last menstrual cycle to now. It couldn't extend into the future because you have no idea when the next one will start. (Well, you could predict, but effectiveTime isn't about prediction.)

Some of it's based on "what's useful". So for the broken leg, you'd want to know when the break occurred - which may well be a couple of days ago. You'd probably want to know that the leg was still broken. You wouldn't know when the break would be fully healed. So the occurrence of the break would be IVL.low. The date of the observation could be expressed as IVL.any. And IVL.high would be UNK. Unfortunately, datatype R2 has a constraint that prevents you from populating low and any at the same time. So you'd probably have to settle for specifying the low value and leaving the high value as UNK.

Lloyd

5-July-2010

4:00 am

From: Tom de Jong

To: Lloyd McKenzie

Hi Lloyd,
The time the observation occurred (when different from the ‘clinically relevant time’) should go in Observation.activityTime. I would be very much opposed to trying to piggy-back that into effectiveTime, when we have an explicit attribute for it. In fact, this use case is the one that is always used to explain the difference between activityTime and effectiveTime (e.g. time of lab test versus time of blood sample).

That being said, I think you provide an excellent explanation of how effectiveTime should be interpreted. Now if only something to that effect would be included in the RIM narrative, we wouldn’t have so many misunderstandings in practice. A tricky edge case is the effectiveTime for a diagnosis or other assessment (which should be a separate specialization of OBS, for this and other reasons). Suppose I diagnose an ulcer, is the effectiveTime interval the time in which (I think) the ulcer was present, or the time in which my diagnosis was ‘actual’ (which starts later)? You seem to imply the first, but then how would I express the time in which I ‘held’ this diagnosis? Both activityTime and author.time don’t qualify for that purpose. Then there is availabilityTime, but the RIM narrative for that is more of a requirements analysis than a guideline!

Apologies (and thanks;-) for using this thread to raise something that has never stopped ‘bugging’ me.

Best,
Tom

5-July-2010

19:55

From: Lloyd McKenzie

To: Tom de Jong

CC: Cecil Lynch; Rene Spronk (Ringholm); Bob Dolin; mnm; Rik Smithies
Subject: Re: what is the effectiveTime for a date of birth observation

Hi Tom,
I wasn't suggesting that we piggy-back. Observation time should actually go in author.time. Activity time is the administrative time relevant for scheduling and billing. I can't imagine it ever being captured for something like "observed date of birth". Sometimes the clinically relevant time (the time the observed value is believed to hold) is tied to the time the observation is made, sometimes not.

In terms of the diagnosis, it depends how far the diagnosing clinician wants to go. If they want to make the safe statement and say "I think they have an ulcer today" and be totally silent about when they think the ulcer started, they can. If they think capturing an approximate onset date (possibly using URG for the low value to say "started 3-4 months ago"), they can.

Lloyd

5-July-2010

12:19 pm

From: Tom de Jong

To: Lloyd McKenzie

Hi Lloyd,

Ø Observation time should actually go in author.time. Activity time is the administrative time relevant for scheduling and billing.

I beg your pardon? I quote the RIM narrative for activityTime (first sentence): “A time expression specifying when an Observation, Procedure, or other Act occurs, or, depending on the mood, is supposed to occur, scheduled to occur, etc.“ Further on in the usage notes: “When an observation of a prior symptom is made, the activityTime describes the time the observation is made, as opposed to effectiveTime which is the time the symptom is reported to have occurred.

How is that limited to scheduling and billing? Once again, ‘lore’ is one of the great weaknesses of HL7. Sorry for being blunt, but if you think the RIM definition for activityTime is wrong, write a harmonization proposal
That being said, of course it could also go in author.time (assuming I want to report an author at all). But that wasn’t the main issue I raised… I see you just sent a response to the exchange I had with Rik about that

Best,

Tom

5-July-2010

20:28

From: Lloyd McKenzie

To: Tom de Jong

CC: Cecil Lynch; Rene Spronk (Ringholm); Bob Dolin; mnm; Rik Smithies
Subject: Re: observation time [was: what is the effectiveTime for a date of birth observation]

The activityTime includes the times of component actions (such as preparation and clean-up). For Procedures and SubstanceAdministrations, the activityTime can provide a needed administrative function by providing a more inclusive time to be anticipated in scheduling.

Usage Notes: The activityTime is primarily of administrative rather than clinical use. The clinically relevant time is the effectiveTime. When an observation of a prior symptom is made, the activityTime describes the time the observation is made, as opposed to effectiveTime which is the time the symptom is reported to have occurred. Thus the activityTime may be entirely different from the effectiveTime of the same Act. However, even apart from clinical use cases, designers should first consider effectiveTime as the primary relevant time for an Act.

Many applications track the time an observation is recorded rather than the precise time during which an observation is made, in which case Participation.time (e.g. of the Author) should be used. These recorded observations can take place during an encounter, and the time of the encounter often provides enough information so that activityTime isn't clinically relevant.

I think the existing definition is already fairly clear. It includes component actions like preparation and cleanup and provides a more inclusive time to be anticipated in scheduling. The definition doesn't mention finance explicitly, though that's a common part of "administration". Because it measures the entire time consumed by resources (including preparation & cleanup), it's appropriate for financial purposes.

Lloyd McKenzie

3-Oct-2010

5:45 pm

From: Tom de Jong

To: Lloyd McKenzie and MnM chairs

Hi Lloyd, MnM co-chairs,
I’m firing up an e-mail thread that ended a few months ago. The reason it ended back then was a combination of too much other work on my side and a sense of “we’re just reading different things in the same text, so we need some fresh input on this”. Fact is, I still think there is an issue whit the interpretation of activityTime. Based on the requirement ‘actual time of observation’, you say that’s not what it’s intended for, while I know that we promote exactly that interpretation in all Dutch projects (and believe me, I spell RIM narrative like it’s the Holy Book;-).
I know I’m late, but is there any chance of finding some time to discuss this as an MnM hot topic this week? I know you’re not going to be present in Cambridge (hope everything’s going well), so this question is directed at the MnM co-chairs on duty. Thanks for considering.

Best wishes,
Tom

4-Oct-2010

4:01

From: Lloyd McKenzie

To: Tom de Jong

CC: Cecil Lynch; Rene Spronk (Ringholm); Bob Dolin; mnm; Rik Smithies
Subject: Re: observation time [was: what is the effectiveTime for a date of birth observation]

Hi Tom,
activityTime is the "actual time of the observation", but as the definition says, it "includes preparation and clean-up time". Thus an activityTime is always expressed as an interval. It will include such tasks as unpacking the specimen, processing it, filtering it, letting it grow, preparing the slides, examining the slide, writing up the report and disposing of the specimen. If that's what you want, then activityTime is what you need. Most of the time this level of information is only relevant for scheduling, billing etc. What most people want is a simple timestamp of "when did the observation occur". And that's captured as an Observation.performer.time.

Don't know if MnM will be able to revise their schedule or not, as they normally do their final scheduling on Sunday and then release rooms for unused quarters.

Lloyd

4-Oct-2010

7:59 am

From: Tom de Jong

To: Lloyd McKenzie

Hi Lloyd,
I’m sorry for raising this red flag so late, but I never get around to running through old HL7 e-mails until I’m actually on the plane ;-).

There are several things in your response that make me raise the red flag even higher. You write:

Ø Thus an activityTime is always expressed as an interval.

Where is that specified in the normative text? We all know that no event on Earth is really a ‘point in time’ (unless you’re riding a photon), but we commonly approximate this by using a point in time anyway. I have seen numerous examples in the past, where Observation.activityTime was used to differentiate between ‘time of observation’ and ‘clinically relevant time’. In none of those examples was it ever mentioned that it is a requirement to include preparation and clean-up time (nobody really cares in a clinical context). So if this is a rule, we need to document it.

Ø What most people want is a simple timestamp of "when did the observation occur". And that's captured as an Observation.performer.time.

I hope we agree that this is just as much an approximation. What triggers me is the fact that you said it should be in Observation.author.time before! Now I know these are commonly the same person/device, but having two (or three) possible places doesn’t really help to promote interoperability. On top of that: what if I don’t care about the performer, but still want to capture the time of observation? Or the performer is conducted from a higher level object (e.g. Encounter) and I don’t want to duplicate it, just because I need to capture observation time?

Again, I hope the MnM co-chairs can find some time to discuss this. I have also copied Hans and Patrick, because maybe O&O could help.

Best,
Tom

4-Oct-2010

16:43

From: Lloyd McKenzie

To: Tom de Jong

CC: Cecil Lynch; Rene Spronk (Ringholm); Bob Dolin; mnm; Rik Smithies; Patrick E. Loyd; Buitendijk, Hans (MED US)
Subject: Re: observation time [was: what is the effectiveTime for a date of birth observation]

From the first paragraph of the definition: "The activityTime includes the times of component actions (such as preparation and clean-up)."

Note that it does not say "may include". It says "includes". Agree this is not usually of clinical interest. That's why activity time is rarely used in clinical messages (but always appears in scheduling messages).

The definition doesn't say that it must be an IVL. However, if it's always going to include component actions like preparation and cleanup, it's pretty hard to express that as an instant.

Lloyd McKenzie

4-Oct-10

12:08 pm

From: Tom de Jong

To: Lloyd McKenzie

Subject: Re: Observation Time [ was: what is the effective Time for date of birth observation]

Hi Lloyd,

I hear you, but we both know that the performer participation also doesn’t take place in an instant, yet you readily propose to use TS there.

So what I’m saying is: we should make it clear beyond a shadow of a doubt WHERE and HOW one should message ‘time of observation’. Personally, I’m not tied to using activityTime, but as I stated before, there are certainly issues with having to use a participation.time.

The reason I keep picking on this type of ambiguity, is that I honestly feel that it’s the greatest threat to continued success of HL7. Our materials (and underlying RIM) are enormously versatile, but the fact that we partly rely on ‘lore’ is not helping semantic interoperability.

I hope the O&O co-chairs can find an appropriate time for this in their schedule.

Best,

Tom

4-Oct-10

19:14

From: Lloyd McKenzie

To: Tom de Jong

Cc: Buitendijk, Hans (H USA); Patrick E. Loyd; Cecil Lynch; Rene Spronk (Ringholm); Bob Dolin; mnm; Rik Smithies
Subject: Re: observation time [was: what is the effectiveTime for a date of birth observation]

Hi Tom,

There is a strong use-case for a scheduling time that covers the whole time resources are occupied with an activity. That use-case is met by activityTime. It can't be met by any other attribute. I don't object to a harmonization proposal to add additional documentation in the RIM to help make it more clear. (Though I think the existing definition already covers it relatively well . . .)

Lloyd

4-Oct-10

8:24 pm

From: Hans Buitendijk

To: ?

Subject: Re: Observation Time [ was: what is the effective Time for date of birth observation]

Sounds indeed like this needs some in-person discussion considering that in this thread I've seen author time, performer time, activity time, effective time, some of them changing through the thread (e.g., author and performer time switched around), there is discussion of an interval in a way that may imply one has to provide the end of the interval, and that the level of granularity will determine whether prep and clean-up are included in the activity or tracked through separate but related activities.

For an observation, I kept it simple and hopefully we can stick somehow to that.
activity time - when the observation is being made - most of the times ignoring any prep and cleanup and therefore close enough as to when the observation was made - has clinical, administrative, financial relevance depending on what one is trying to say - impossible to consider one primary or secondary in general, only primary or secondary depending on who is looking at that time
effective time - when the observation value is relevant - most of the times just the start of the interval since it is not known until some time in the future when the observation may be contradicted, if ever
author time - when the observation was documented - typically later than the activity time and clinically not that relevant - only when it takes days to record an observation requiring administrative follow-up to resolve a documentation delinquency performer time - not sure what this can contribute given the above.

Problem this week is when we have time to review and get some consensus what it is and whether that means we have anything in the documentation to fix. Wednesday Q2 may have an opportunity for 15 minutes, but it would have to be time-boxed to ensure we get to other topics. Another option maybe Wednesday Q1 given the participants already there.

Hans J. Buitendijk

HS Standards & Regulations Manager
Siemens Healthcare
Siemens Medical Solutions USA, Inc.
51 Valley Stream Parkway,
Malvern, PA 19355-1406
Phone: +1 610 219 2087
Mobile: +1 484 354 6474
Fax: +1 610 219 1273

5-Oct-10

4:41 pm

From: Lloyd McKenzie

To: Hans Buitendijk

CC: Tom de Jong; Patrick E. Loyd; Cecil Lynch; Rene Spronk (Ringholm); Bob Dolin; mnm; Rik Smithies
Subject: Re: observation time [was: what is the effectiveTime for a date of birth observation]

Hi Hans,
I'm not comfortable with the idea that activity time "most of the time ignores preparation and cleanup". The definition clearly says it includes those things and doesn't indicate they can be omitted. If you're going to capture activity time, you have to include what activity time is supposed to cover. When used in scheduling, it *must* contain that information. And the RIM semantics of an attribute don't change in terms of scope of coverage based on what domain is using it.

Lloyd

23-Oct-10

6:09 pm

From: Tom de Jong

To: Lloyd McKenzie and Hans Buitendijk

Subject: Re: Observation Time [was: what is the effective Time for a date of birth observation]

Hi Lloyd, Hans,

I’m picking up some loose threads. The debate below started with some ‘innocent’ questions, but I think we can safely say there is no consensus on when to use which attribute. The semantics may be quite clearly specified, but it seems that doesn´t prevent people from having conflicting interpretations

I don’t want to start up the e-mail debate again (I’m still shocked by the avalanche ‘required’ caused;-), but I would like to raise this as a hot topic, to be discussed as a convenient opportunity arises (which could be either an MnM or O&O call). The ultimate result should be an even tighter RIM narrative.

Summarizing, the issues are:

·Can Act.activityTime be used to capture ‘time the act occurred, even when valued as a TS, and therefore not explicitly including preparation and clean-up time? In practice, we know that it is.

·If performer.time should be used for this purpose (as Lloyd states): what if I want to capture ‘time of occurrence’ but have no need to state the performer (or it is conducted from above)?

There may be some bias in my descriptions above, but there’s nothing that wasn’t stated before. A new element would be that we might need to clarify which aspect each participation deals with (e.g. performer is about the act of observing, author is about the result, data enterer is about recording it).

The reasons I’m following up on this are many:

· We know many groups (among them Lab) have used activityTime in a way that could be seen as conflicting with the RIM semantics (that’s the logical consequence of Lloyd’s statements).

·This is fundamental to any form of data exchange at EHR-level. It is essential to have a consistent interpretation across all domains for such basic features (of any observation).

-This strikes at the heart of the objections by some RIM critics. Especially, this relates to the distinction between ‘an observation occurring’ and ‘determining the result of an observation’.

Or am I wrong in seeing a problem here? I don’t want to cry wolf, just to agree about the semantics.

Thanks,

Tom

24-Oct-10

3:24 pm

Subject: RE: Observation Time [was: what is the effective Time for a date of birth observation]

From: Lloyd McKenzie

To: Tom de Jong
Subject: Re: observation time [was: what is the effectiveTime for a date of birth observation]

Hi Tom,

I'll answer the "what do I do if I don't want/know the performer" - you do the same thing as when you want to capture the author time but don't want to capture the author. Attach the participation to an empty Role. Happy to schedule this as one of our hot topics. Next couple of calls will be ballot reconciliation but after that we get back into hot topics. Do you want to put together the wiki page?

Lloyd

CDISC publishes BRIDG 3.0

noreply@blogger.com (Barry Smith) — Mon, 06 Sep 2010 15:42:00 +0000

A recent issue of the Bimonthly newsletter of XML4Pharma contains some interesting remarks on the recent release by CDISC of BRIDG 3.0 (downloads for this new release can be found here).

One of the things that the author of these remarks likes a lot about this new release is that the strong interweaving with the HL7 RIM has been removed: there is now a separate mapping available between BRIDG and the HL7-RIM. One of his criticisms of BRIDG had always been that it looked as though BRIDG is based on the HL7-RIM. Now he says that "it is very good that this separation has ... been made, as the HL7-RIM is strongly criticized by ontologists to be incorrect from the basis on. Also its XML implementation, HL7-v3-XML is strongly criticized as well by XML specialists ('bad-practice XML', 'abuse of XML') as well as by software architects and developers ('almost impossible to implement, or only at extremely high cost')."

As he goes on: "The current separation also allows mappings to other (and better) RIMs, such as the OpenEHR RIM. In my opinion, the next step for CDISC should be that it comes to alliances at the same level as the one with HL7, with other standardization organizations in healthcare such as ASTM (those who have followed the discussions about CCD versus CCR for EHRs know why) and with OpenEHR – and others."

There are still many problems with BRIDG, deriving from the fact it takes a static view of the clinical trial domain -- a view determined overwhelmingly from the perspective of the regulator. This makes it difficult, if not impossible, to use as a basis for clinical trial data capture and analysis. But at least BRIDG is now not subject to the dead hand of the RIM.

HL7 and the Electronic Health Record

noreply@blogger.com (Barry Smith) — Thu, 06 May 2010 18:17:00 +0000

It is understandable that HL7 is devoting increasing attention to the EHR topic. One result is the ANSI-approved "Electronic Health Record System Functional Model Normative Standard", which provides a reference list of 132 functions that is designed to enable the description and common understanding of the EHR functions needed or available in different settings. Version 1 of this standard was released in 2007. The revised version 1.1 is, I am told, still in development.

The original Electronic Health Record System Functional Model Normative Standard of 2007 is said to have received "an unprecedented amount of feedback from hundreds of reviewers from the standards community, the provider community, the international community, and other industry stakeholders". It is therefore troubling to see what has been provided by HL7 in the way of documentation for this standard.

Consider, for example, the Glossary made available on the EHR-S Functional Model website (select "EHR-S FM 2007" from the list of downloadable files on the right here). This is a list of more than 100 terms, together with definitions, some of them drawn from a potpourri of external sources, some of them created by the glossary's authors.

What is troubling is that not one of the hundreds of reviewers from the standards community, including those persons involved in the ANSI standards vetting process, seems to have noticed the quite peculiar mixture of ways in which the definitions in this glossary fall short not only of standard best practices but also of achieving HL7's own goals.

For some definitions:

Text =def. Computer functions that return a single value.

Uniquely identify =def. A standard that lets you specify a unique label to the set of element names.

it is difficult to conceive of how they could have survived even minimal scrutiny.

Other definitions, for instance:

Clinician =def. An expert clinical physician and teacher.

(from Dorland's Medical Dictionary for Health Care Consumers) seem not to correspond to the normal meaning of the term in question.

Others contain non-trivial typographical errors. For instance:

Health condition =def. An observable finding about or state of health that persists over time and tends to require intervention or management, and, therefore, distinguished from an Observation made at a point in time; may exist before an Observation of the Condition is made or after interventions to manage the Condition are undertaken. Examples: wellness, impairment, chronic illness.

where the error on line 1, when corrected (by replacing 'or' with 'a'), yields crucial problems for HL7. This is because 'Finding' is listed elsewhere in this Glossary as a subclass of 'Clinical Data/Information', and findings so defined cannot require management, and cannot exist before an observation of the condition is made.

Other definitions are mere lists of synonyms, for example as here (taken from answers.com):

Repudiate =def. To refuse to recognize or acknowledge: deny, disacknowledge, disavow, disclaim, disown, reject, renounce.

Others are circular (which means that they cannot address the primary need of glossary users, which is to be informed of the meanings of terms they do not already understand). Some are worse than circular, the logical equivalent of 'an apple = def. the eating of an apple' as for example:

Resource utilization =def. Measurement of the effectiveness of resource usage.

Yet others provide two or more logically conflicting definitions of a single term, as for example:

Result =def. The conclusion or end to which any course or condition of things leads, or which is obtained by any process or operation; an outcome. The act or process of applying general principles or formulae to the explanation of the results obtained in special cases.

Peculiarly, not one of the definitions in the glossary draws on HL7's own definitions and glossaries provided elsewhere. Indeed they seem to betray almost no awareness of the wider HL7 context within which this glossary was created, and some of the definitions are indeed inconsistent with definitions normatively required by HL7, most egregiously:

Entity = def. Something that has separate and distinct existence and objective or conceptual reality. Something that exists as a particular and discrete unit. An organization (as a business or governmental unit) that has an identity separate from those of its members (from Merriam-Webster),

where HL7 defines its RIM backbone class 'Entity' as: 'A physical thing, group of physical things or an organization capable of participating in Acts, while in a role.' This makes somewhat confusing HL7's assertion in the text of the EHR S FM 2007 glossary to the effect that terms in this glossary "will be submitted for inclusion in the HL7 Version 3.0 Edition 2006 Glossary".

Given that HL7 is being promoted as "the glue that will hold together the pieces of the electronic health record (EHR) of tomorrow", the question becomes all the more urgent as to what will serve as the glue that will hold together the pieces of HL7 itself.

How can HL7v3 modeling ever grow beyond a cottage industry for volunteers if the modeling material is not stable?

noreply@blogger.com (Barry Smith) — Wed, 28 Apr 2010 16:44:00 +0000

From: owner-vocab@lists.hl7.org [mailto:owner-vocab@lists.hl7.org] On Behalf Of Ann Wrightson (Informing Healthcare)
Sent: Wednesday, April 28, 2010 8:20 AM
To: Services Oriented Architecture; tooling; MNM List; HL7 Vocabulary List; editors; strucdoc; templates
Cc: Jane Curry
Subject: RE: Static Model Designer - validation requirements document

Lloyd,

I think you raise a serious issue here. As a potential user of the SMD, I can see an uncomfortable sort of risk in a situation where something as fundamental to practical modelling as the model constraints simply "can change at any harmonization meeting". How would the harmonization meeting take into account the potential impact of proposed changes on modelling tool users who already have a body of models?

As a wider issue, how can HL7v3 modelling ever grow beyond a cottage industry for WGM volunteers if the modelling material is not stable?

Regards,

Ann W.

Ann M Wrightson
Technical Architect / Pensaer TG
Informing Healthcare / Hysbysu Gofal Iechyd
Part of the NHS Wales Informatics Service / Rhan o Wasanaeth Gwybodeg GIG Cymru
Tel: 01745 448232 (Llanelwy) / 01656 678100 (Bridgend)
Mobile/Symudol: 07535 481797

From: owner-soa@lists.hl7.org [mailto:owner-soa@lists.hl7.org] On Behalf Of Lloyd McKenzie
Sent: 26 April 2010 17:08
To: Services Oriented Architecture; tooling; MNM List; HL7 Vocabulary List; editors; strucdoc; templates
Cc: Jane Curry
Subject: Re: Static Model Designer - validation requirements document
I'm concerned that many of these rules are for constraints currently maintained in the MIF for vocabulary or the RIM. Any one of these constraints can change at any harmonization meeting and therefore should never be hard-coded within a system. I would much rather see "formal" encodings of these rules submitted as harmonization proposals so that the tools can properly be driven from the source-of-truth artifacts.
--------------------------------------
Lloyd McKenzie