The National Cancer Institute Thesaurus and Its Errorsome Ways

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?

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

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

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

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?

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

HL7 is brooken.

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

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

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

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

From: “McKnight, Lawrence (H USA)”

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

To:

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

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

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

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

The requirements given to Org H are:

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

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

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

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

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

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

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

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

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

Please help. I’m confused.

Larry.

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

From: Lloyd McKenzie

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

To: “McKnight, Lawrence (H USA)”

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

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

Reply-To: Lloyd McKenzie

Hi Larry,

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

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

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

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

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

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

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

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

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

As to your more specific questions:

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

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

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

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

Lloyd

-----------

From: “McKnight, Lawrence (H USA)”

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

To: “Lloyd McKenzie”

Cc: , “MNM List”

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

Thanks, Lloyd.

I learned a little, but still have questions.

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

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

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

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

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

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

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

Larry.

----------

From: Lloyd McKenzie

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

To: “McKnight, Lawrence (H USA)”

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

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

Hi Larry,

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

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

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

Lloyd

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

From: “Buitendijk, Hans (H USA)”

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

To: “Dan Russler” , “Lloyd McKenzie”

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

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

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

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

Hans J. Buitendijk

HS Standards & Regulations Manager

Siemens Healthcare

------

From: Lloyd McKenzie

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

To: “Buitendijk, Hans (H USA)”

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

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

Hi Hans,

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

Lloyd

BFO vs. HL7 RIM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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