Monday, September 13, 2010

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



Monday, September 06, 2010

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.