error when time/low/@value = time/high/@value

[DaveSS]

We are receiving the following error when the time/low/@value is the same as the time/high/@value for the Service Delivery Location of a Kontakt.

<time>
       <low value="20180611145400-0500"></low>
       <high value="20180611145400-0500"></high>
</time>

Engine name: ISO Schematron (XSLT 2.0)
Severity: error
Description: dtr1-6-IVL_TS: low/@value must not be equal to high/@value (not(hl7:low/@value = hl7:high/@value) / error) [assert]

While the low/@value is never greater than the high/@value, we were not aware of any LPR3 constraint on this data element that makes sure these values are not the same. We do see that some specific LPR3 concepts (like the Diagnosis Reporting Kontakts) that require the low time be strictly less than the high time, but for most cases, LPR seems to allow the low and high times to be equal. Is the requirement that the low and high times are not equal included in the LPR3 model or is this a CDA document constraint outside the LPR3 model?

[jkiddo]

It's a bit of both. The LPR submission guide is not specific in all areas in regard to the usage of 'datoTid' and at the same time the natural way of modelling a time interval in CDA is by using IVL and you can say the CDA modelling comes with some bylaws - among those that an interval needs to have a span - which could seem fair enough.

[DaveSS]

I'm not sure where CDA modeling assumes that an interval needs a non-zero span. The CDA R2 specification doesn't assert that to my knowledge and I haven't seen that specified in the Implementation Guides for various CDA documents that have been approved by HL7 over the years. And since many CDA documents are now template based and use schematrons to validate documents, it is very useful to model a time element that can be either a single point in time or an interval as an IVL_TS where time/low/@value = time/high/@value is used to indicate a single point in time rather than send the time/@value in those cases. That is because the specification for a document likely contains templates which conform to existing templates that might require the time/low element. Instead of creating an entirely new template just to require either the time/value or the time/low element, setting the low and high values to be equal specifies single point in time concept just as well, and allows the reuse of existing templates that require the low element.

Is this an important requirement for the LPR3 implementation? If our workflows built for LPR3 conformance allow a start and an end time to be the same, I would feel more comfortable reporting that rather than adding 1 second or 1 minute to a high/@value in order to be able to send it in a CDA document. Alternately, the LPR3 templates could be modified to require either a time/@value or a time/low/@value, unless that specific time in the LPR3 data model is defined as an interval with a low required to be less that a high.

Again, my understanding is that the requirement does not exist in LPR3 which is why I am looking for the ability to report this information. If my understanding is incorrect and LPR3 does define that all times with a start and end must have a non-zero span, than I can make sure our internal workflows conform to those LPR3 guidelines. I just don't want to be forced to report something other than what is stored in our system to satisfy a document requirement.

[jonigkeit]

"HL7 Data Types – Abstract Specification, Release 1, 2004".

invariant(IVL<T> x; T e)
      where x.nonNull.and(x.contains(e)) {
   e.lessOrEqual(x.high);

should allow low and high to be equals if all other T in x have the same value. We will talk to the art decor guys to find out why they have this restriction by default.

Nonetheless remember rule 02.01 etc. stating that the end has to be after the start, i.e. end > start and not end ≥ start

[jonigkeit]

@ahenket can you explain where dtr1-6-IVL_TS comes from?

[DaveSS]

I think the text above is from section 3.6.2 of the CDA Data Types and it is only defining what the high boundary means. It is not discussing the low boundary at all. It is stating that for some time "e" and interval "x", e must be less than or equal to x.high (the high boundary of the interval x).

In that same document section 3.6.8 describes how to promote a single time element T to an interval as follows:

A quantity of type T can be promoted into a trivial IVL where low and high are equal and boundaries closed. 

invariant(T x) {
   ((IVL<T>)x).low.equal(x);
   ((IVL<T>)x).high.equal(x);
   ((IVL<T>)x).highClosed;
   ((IVL<T>)x).lowClosed;
};

I haven't looked at these Data Types in a while, but that is my understanding. I do know that HL7 regularly publishes CDA-compliant Implementation Guides that allow low-high, so I don't think the requirement is from the base CDA R2.0.

[jonigkeit]

@DaveSS We do agree that low = high should be allowable for an IVL.

Your submission will still end up in a dynamic error nonetheless, e.g. rule 02.01

[DaveSS]

We will need to restrict that data element on our end to require a finite interval for the time low/high values, but where it is allowed in the business rules, will we be able to send the low=high for IVL_TS elements?

[jonigkeit]

There seems some special considerations regarding IVL\<TS> as opposed to IVL\<T>.

3.8 Interval of Point in Time (IVL\<TS>) specializes IVL Definition:      A set of consecutive values of time-stamps. The generic interval data type defines the interval of points in time too. However, there are some special considerations about literal representations and conversions of intervals of point in time, which are specified in this section.

low = high are not consecutive values

3.8.1 Promotion of Points in Time Values to Intervals : IVL\<TS>, inherited from IVL A TS can be promoted to an IVL\<TS> whereby the low boundary is the TS value itself, and the width is inferred from the precision of the TS and the duration of the least significant calendar period specified. The high boundary is open. For example, the TS literal "200009" is converted to an IVL\<TS> with low boundary 200009 and width 30 days, which is the interval "[200009;200010[".

There is your recipe.

[jonigkeit]

All objects with a start and an end time have a dynamic rule requiring start < end

• 02.01 for episode of care
• 05.11 for encounter
• 09.01 for service delivery location
• 10.01 for payment
• 11.01 for procedure

[DaveSS]

So it looks like even if we could send the low=high, a business rule error would result in all cases. I'm glad I can stop reading through the CDA standard to try and understand all the variants of IVL... Thank you for looking into this issue.

[jonigkeit]

Hi @DaveSS You cannot sent low = high in a IVL\<TS> according to the standard.

[jonigkeit]

@DaveSS please close this issue if you have no further comments.