This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Implementation Guidance for the IVL TS data type"

From HL7Wiki
Jump to navigation Jump to search
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
 
===Issue===
 
===Issue===
The HL7 version 3 IVL_TS data type is used to express a date/time range. The interpretation of the boundary values goes counter to 'human every day interpretation'.
+
The HL7 version 3 IVL_TS data type is used to express a date/time range. The interpretation of the boundary values goes counter to 'every day human interpretation'.
  
 
An analogy: if we had an instance of the hypothetical data type called IVL_Number, and we had to express a >= 4 to <= 6 range:
 
An analogy: if we had an instance of the hypothetical data type called IVL_Number, and we had to express a >= 4 to <= 6 range:
 
  <low value="4"/><high value="6"/>
 
  <low value="4"/><high value="6"/>
*would 6.1 within the interval? no, clearly it is not.  
+
*would 6.1 be within the interval? no, clearly it is not.  
 
*would 6.0000 be within the interval? yes (one can quibble about precision, but our instinct tells us it's included)  
 
*would 6.0000 be within the interval? yes (one can quibble about precision, but our instinct tells us it's included)  
 
*would 4.0000 be within the interval? yes (one can quibble about precision, but our instinct tells us it's included)
 
*would 4.0000 be within the interval? yes (one can quibble about precision, but our instinct tells us it's included)
Line 11: Line 11:
 
Intuitively in order to specify the time interval from 1-jan-2012 up to and inclusive of 3-jan-2012 one would use:
 
Intuitively in order to specify the time interval from 1-jan-2012 up to and inclusive of 3-jan-2012 one would use:
 
  <effectiveTime><low value="20120101" inclusive="true"/><high value="20120103" inclusive="true"></effectiveTime>
 
  <effectiveTime><low value="20120101" inclusive="true"/><high value="20120103" inclusive="true"></effectiveTime>
*however, 20120103 (much like 6 in the example above) effectively means the very first picosecond of 20120103, i.e. exclusive of the remainder of that day. If 6.1 isn't within the interval in the first example, then it makes sense that 201301031200 would also not be within the interval in this example.
+
*however, 20120103 (much like 6 in the example above) effectively means the very first picosecond of 20120103, i.e. exclusive of the remainder of that day. If 6.1 isn't within the interval in the first example, then it makes sense that 201201031200 would also not be within the interval in this example.
*in order to define the upper boundary to be the end-of-day on 20130103, we'd have to set the upper boundary to 20130104.  
+
*in order to define the upper boundary to be the end-of-day on 20120103, we'd have to set the upper boundary to 20120104.  
 
The semantically correct expression of the interval would be:
 
The semantically correct expression of the interval would be:
 
   <effectiveTime><low value="20120101"/><high value="20120104" inclusive="false"/></effectiveTime>
 
   <effectiveTime><low value="20120101"/><high value="20120104" inclusive="false"/></effectiveTime>
Line 21: Line 21:
 
===Guidance===
 
===Guidance===
 
*When implementing IVL_TS, always express the boundaries at least up to a precision of a minute
 
*When implementing IVL_TS, always express the boundaries at least up to a precision of a minute
*The end-of-day should be expressed as 2359 - theoretically this is one second shorter than the semantically correct expression - which is good enough in almost all use cases.
+
*The end-of-day should be expressed as 2359 - theoretically this is one minute shorter than the semantically correct expression - which is good enough in almost all use cases.
  
  
Line 32: Line 32:
 
A detailed description of the issue (as well as the underlying reasons) can be found in Grahame's blogpost http://www.healthintersections.com.au/?p=707
 
A detailed description of the issue (as well as the underlying reasons) can be found in Grahame's blogpost http://www.healthintersections.com.au/?p=707
  
[[Category:RIMBAA Whitepaper]]
+
[[Category:AID Whitepaper]]

Latest revision as of 14:47, 25 March 2015

Issue

The HL7 version 3 IVL_TS data type is used to express a date/time range. The interpretation of the boundary values goes counter to 'every day human interpretation'.

An analogy: if we had an instance of the hypothetical data type called IVL_Number, and we had to express a >= 4 to <= 6 range:

<low value="4"/><high value="6"/>
  • would 6.1 be within the interval? no, clearly it is not.
  • would 6.0000 be within the interval? yes (one can quibble about precision, but our instinct tells us it's included)
  • would 4.0000 be within the interval? yes (one can quibble about precision, but our instinct tells us it's included)


Intuitively in order to specify the time interval from 1-jan-2012 up to and inclusive of 3-jan-2012 one would use:

<effectiveTime><low value="20120101" inclusive="true"/><high value="20120103" inclusive="true"></effectiveTime>
  • however, 20120103 (much like 6 in the example above) effectively means the very first picosecond of 20120103, i.e. exclusive of the remainder of that day. If 6.1 isn't within the interval in the first example, then it makes sense that 201201031200 would also not be within the interval in this example.
  • in order to define the upper boundary to be the end-of-day on 20120103, we'd have to set the upper boundary to 20120104.

The semantically correct expression of the interval would be:

 <effectiveTime><low value="20120101"/><high value="20120104" inclusive="false"/></effectiveTime>


The definition of the IVL_TS data type, whilst semantically sound, is counter intertuitive to humans. Therefore multiple implementers have concluded that the following workaround be used in order to have both software processable expressions of intervals, and to express those in a human readable fashion:

Guidance

  • When implementing IVL_TS, always express the boundaries at least up to a precision of a minute
  • The end-of-day should be expressed as 2359 - theoretically this is one minute shorter than the semantically correct expression - which is good enough in almost all use cases.


In order to specify the time interval from 1-jan-2012 up to and inclusive of 3-jan-2012 use

<effectiveTime><low value="20120101000000"/> <high value="20120103235959"/></effectiveTime> 

instead of (the semantically correct)

<effectiveTime><low value="20120101"/><high value="20120104" inclusive="false"/></effectiveTime>

Background

A detailed description of the issue (as well as the underlying reasons) can be found in Grahame's blogpost http://www.healthintersections.com.au/?p=707