Datatypes R2 Issue 4

Introduction

Add a “code” property to provide a simple mechanism of exchanging commonly-used and understood timing specifications.

Many common timings are known in the “real world” using codes. E.g. “TID”, “BID”, etc. Many of these can be formally encoded in multiple ways. Users would like to see the content rendered as a code. Also, sending a coded value significantly lessens the parsing and interpretation burden on the receiving system.

? backward compatible - only sort of

Pharmacy, Orders & Observations

Discussion

General Timing Specification (GTS) specializes SET<TS>

Definition 255: type GeneralTimingSpecification alias GTS specializes SET<TS> {

           IVL<TS>   hull;
           IVL<TS>   nextTo(TS x)
           IVL<TS>   nextAfter(TS x)
           GTS       periodicHull(GTS x);
           BL        interleaves(GTS x);
           SC        originalText;
 demotion  LIST<IVL<TS>>;
 literal   ST;

};

Code

Many GTS expressions are commonly represented and expressed by means of codes. This attribute returns the code equivalent for the GTS expression, if one exists. For the sake of interoperability, systems must communicate the full encoding of the GTS expression along with the originalText unless the code is expressed in the universal HL7 code system. In the event of a discrepancy between the code and the fully expressed GTS, the full expression takes precedence.

<x

 * = *                           
 operator = "I"|"E"|"A"|"H"|"P"
 code = CE
 >
 -->

</x>

Schema Fragment 171:

<gsd:templatename="SXCM">

   <gsd:paramname="T" type="ANY" />
   <xsd:complexType>
       <xsd:complexContent>
           <xsd:extension>
               <xsd:sequence>
                   <xsd:element name="code" type="CE" minOccurs="0" maxOccurs="1" …/>
               </xsd:sequence>
               <gsd:attributename="base" type="T" />
               <xsd:attributename="operator" type="cs_SetOperator" ... />
           </xsd:extension>
       </xsd:complexContent>
   </xsd:complexType>

</gsd:template>

Need to verify that the “code” attribute for SXCM doesn’t collide with “code” anywhere else (e.g. for unit).

Need to clarify whether code applies to only the current SXCM, or for current and all following which don’t have a code. What happens if you want an ‘embedded’ code. E.g. Here’s the code for this complex GTS, which by the way also has a component PIVL represented by this other code?

Need to be comfortable with using CE instead of CS. Is the requirement to send the fully encoded expression sufficient? There are legitimate use-cases where a system can’t handle parsing or interpreting the GTS, but needs to communicate timing via a pre-defined locally adopted set of codes.

Mead: I would like to sign on as a supporter of Lloyd's proposal for adding a code property to GTS. To touch on one detail, I agree with him that this should take on a CE rather than a CS datatype. Tom DeJong: Just so I understand it correctly: will this also be usable to express 'loosely defined times', like 'in the AM', or event-bound times, like 'half an hour before a meal'. I know the obvious answer is that this depends on the code set you use, but I would like to see an HL7 vocabulary defined that covers the universal cases (especially since EIVL is no longer to be used). Lloyd: GTS.code must have a 1..1 correspondance with a fully-encoded GTS. Thus you couldn't have a code for "in the AM", but you could have a code for "between 3am and 11am". Half-an-hour before meal would only work if we retain EIVL, which I thought we were punting. Tom DeJong I understand what you're saying, but that still leaves us with my examples (and many others that cannot be specified as a pure GTS, excluding EIVL) to cover. These 'fuzzy' timing specifications exist in real prescriptions, so we need to be able to communicate them (preferably in a coded fashion).

Why the restriction that the code needs to correspond to a fully encoded GTS? This would be a good topic to discuss during the next WGM (possibly during our joint session with O&O and Lab), because we're not there yet.

With EIVL supposedly off-limits, we need a way to cover 'fuzzy' timing specifications like the ones above. The use of the precondition relationship simply does not cover all of them (in my meal example the meal is not a precondition, but simply a rough marker for the time of administration).

Lloyd: The point of GTS is to allow computers to figure out when things need to happen. If you're just communicating a fuzzy concept that computers won't be able to understand, just use text. The agreement with Gunther to have code was based on there being a 1..1 correspondence with a fully-encoded GTS. We're not looking at expanding GTS capabilities by adding code, merely providing an alternate mechanism that significantly simplifies the parsing process.

Tom DeJong If I would use text to communicate 'take half an hour before meal', I would sacrifice any chance of international interoperability. Seems like a missed opportunity to me.

Lloyd: Your concern is about language translations? We sacrifice that anyhow. There's no way we can possibly have codes for all of the "extra instructions" a prescriber might give, and those are an essential part of the order. If you're not talking about language translations, then what interoperability have we lost?

Tom DeJong: No, it´s loss of semantics I´m worried about (subtle difference). Regardless of whether we can code for all possible instructions (which is actually current practice in Dutch primary care!), there are some 'time related' instructions that are obviously common to all realms. It is normal no prescribe '2 tablets per day; 1 at breakfast, 1 at bedtime'. Without EIVL or any other way to code 'fuzzy times', it would be impossible to express this in any way that would be commonly understood.

Lloyd: The concept "At breakfast" is meaningless to a computer. It can't be scheduled. The only timing information relevant from a decision support perspective is "once per day". The "at breakfast" can be clearly understood as text. The only time we run into difficulties is when we're talking language translation. However, as I pointed out earlier, there are *tons* of possible pre-conditions, post-conditions, etc. and we can't possibly have common international codes for all of them. Even if we could, it's not realistic for prescribers to wade through all the possibilities. Thus free text must remain a part of our prescriptions. I don't understand what you feel is lost by not having this content coded. In what situation would a computer or human act differently?

Tom DeJong: we’re obviously not on the same wavelength here. I really don’t have the time to discuss this at length right now, but I’ll give a few quick responses:

• The concept "At breakfast" is meaningless to a computer. It can't

be scheduled.

First of all, this is not true. In an inpatient setting, ‘at breakfast’ can default to a department-specific time without human intervention.

But that’s not my point. My point is that time-related instructions like this are common across all realms and all prescribers. We won’t be able to create a coded list that covers all of them, but it would be nice to interface the most common ones in a language-independent way. Isn’t that what coded values are there for in the first place?

But more importantly, like I said, in Dutch primary care, all of these instructions have in fact been coded and standardized (free text is only rarely added). With a code that is CWE, our local implementations could use this national code set to communicate ‘event-bound times’ etc. just like they do now. Without such a coded value, any time-related instruction that cannot be expressed as pure GTS can only be interfaced as free text. That would make the use of HL7 v3 a step back in terms of interoperability.

That’s all for now. We’ll have to allocate some time for this discussion during either the out-of-cycle meeting or the WGM proper.

Dan Russler: I would suggest that "qam with food" is the the semantic, not "qd"....

Gunther: I thought we had all this discussion at length in a recent Pharmacy SIG meeting (like 2 cycles ago) with Tom, Julie, Rob, Hugh, myself and many others in the room. I thought that we had gone through the EIVL cases and found that some *might* be retained but that the precondition can really do most of them.

Meal-related timings are traditionally in EIVL but they can certainly go to precondition.

GTS is strictly about timing and you can't invent codes there with a fuzzy meaning unless you have them in EIVL.

Tom DeJong: Yes, we did have this discussion, although I was not present (and not in agreement;-) when it was decided to punt EIVL altogether. But that's not the discussion Lloyd and I were having, which was about the need to code time-related concepts in the first place (whether as a precondition or in GTS).

If we can use precondition for most (or even all) of these cases, that's fine with me, but my point was that we need to be able to code them (preferably with some universal codes, but at least with the possibility to code them locally).

By the way, if I say 'administer at bedtime', the 'bedtime' is semantically NOT a precondition. If I'm an insomniac, I still have to swallow my pill. But again, this was not my point in the exchange with Lloyd. My point was that I need to be able to code for the 'at bedtime' instruction in my interfaces.

Let's finish this in Noordwijkerhout. Perhaps even at 'dinner time';-).

BOF: add originalText : SC

Lloyd: The challenge with making originalText "SC" here is that there's a proposal to add originalText to all PQs and we don't want to have code on INT, REAL, PQ, TS, etc.A lot of this discussion was a sidetrack related to EIVL which is fundamentally orthogonal to this proposal, as the proposal requires that the code be fully expressable using the formal GTS syntax. If GTS without code can't express what you need, you can't use code to express it.

The question of how code works with SXCM is a good one. There's a similar issue for originalText. Fundamentally, it should be possible to assert originalText or code on a full-blown GTS. There is also a need for originalText on the components as well (though probably not when they're part of an overall GTS).

Fundamentally, I think GTS needs to be represented as a single element with component parts. (This would also get rid of the wonky cardinality issue where effectiveTime has a logical cardinality of 0..1, but can repeat 20 times in an instance . . .

Status

Proposed

Links

Back to Data Types R2 issues