Tuesday, May 21, 2013

Temporal Relationships Again

Today I spent a bit of time with the HQMF editorial team.  One of the issues that we spent quite a bit of time on was temporal relationships.  In the RIM, temporal relationships are represented by vocabulary terms, such as SBS or EAE (Starts before Start, Ends after End).  SBS implies that X.effectiveTime.low < Y.effectiveTime.low.  So now the question of how to deal with <= comes up, and we didn't have a good answer.

To deal with relationships such as "X occured within one hour of the start of Y", you have to deal with what the HL7 RIM calls the pauseQuantity associated with the act relationship.  The pauseQuanity is defined as being of type PQ.TIME (a physical quantity using units of time).  This is incredibly complicated to get right when you have multiple relationships between two different acts and the starting times and ending times associated with them.  If you set the pauseQuantity to 1 hour, and use the SBS act relationship type between act X and act Y, you are saying that X, if paused by one hour, still starts before the start of Y.  Since that is the exact opposite of what you want, what you would do would be to set pauseQuantity to -1 hour, and then use SAS.  That means that X, if moved backwards one hour in time, starts after the start of Y.  Are you confused?  I certainly still am.


<actCriteria>
  ... Criteria for Act X ...
  <temporallyPertains typeCode='SAS'>
    <pauseQuantity value='-1' unit='h'/>
    <actCriteria>

  ... Criteria for Act Y ...
    </actCriteria>

  </temporallyPertains>

</actCriteria>


One of the participants (Marc Hadley from MITRE) proposed that we change pauseQuantity from PQ.TIME to IVL_PQ.TIME, so that we could say from 1 to 2 hours.  I started to say that doesn't work to say what we want it to say, because ... and then realized that depending on what we are comparing, it certainly could work.  The key here are four vocabulary terms covering temporal relationships, SCW, SCWE, ECW and ECWS (Starts Concurrent With Start, Starts Concurrent with End, Ends Conncurrent with End, and Ends Concurrent with Start).

Now lets look at how you could say this:  If you want act Y if it started within 0-1 hours from X, you would have X be related to Y via SCW and would set the pause quantity from 0 - 1 hour.  X.start delayed by 0 to 1 hours is concurrent with Y.start means exactly what we want.

<actCriteria>
  ... Criteria for Act X ...
  <temporallyPertains typeCode='SCW'>
    <pauseQuantity xsi:type="IVL_PQ">
       <low value='0' unit='h'/>
       <high vaue='1' unit='h'/>
    </pauseQuantity>
    <actCriteria>

  ... Criteria for Act Y ...
    </actCriteria>

  </temporallyPertains>

</actCriteria>

The latter means the same as the former, is more flexible, and also has the advantage of allowing the use of the inclusive attribute on the low and high bounds, so now we can also get into the finer details of less than vs. less than or equal to.

The problem is that pauseQuantity is defined in the HL7 RIM to be of type PQ.  We cannot just magically change it to a different type like IVL_PQ.  However, we can certainly state that the pause quantity is some value within a particular range by using the uncertainRange capability of the HL7 Version 3 Datatypes Release 2.  That gives us:


<actCriteria>
  ... Criteria for Act X ...
  <temporallyPertains typeCode='SCW'>
    <pauseQuantity>
      <uncertainRange>
        <low value='0' unit='h'/>
        <high vaue='1' unit='h'/>
      </uncertainRange>
    </pauseQuantity>
    <actCriteria>

  ... Criteria for Act Y ...
    </actCriteria>

  </temporallyPertains>

</actCriteria>


And so, we have a much simpler representation for dealing with temporal relationships, without any RIM changes.  The next step is to restrict the allowed vocabulary when the uncertainRange portion appears to be SCW, SCWE, ECW, and ECWS.  In fact, by limiting to just those four terms we can address any kind of relationship needed between the end points of two events.

We have to bounce this past the Structured Documents workgroup, because it is a variation on the original solution, and we don't want to be making stuff up that the workgroup didn't agree to in reconciliation.  I think this will be pretty straight-forward.

0 comments:

Post a Comment