This wiki has undergone a migration to Confluence found Here

Datatypes R2 Issue 6

From HL7Wiki
Jump to navigation Jump to search

Data Types Issue 6: Add PIVL.frequency


Add a frequency property to Periodic Interval. This is needed to handle circumstances when the interval is properly expressed as a number of repetitions per time-period rather than a time-period width (period). For example, a frequency of 7 times/day is not cleanly expressible as a period. Furthermore, specifying it as a period is misleading.

Backwards compatibility: Any implementation expecting period and not knowing how to handle frequency will not be able to translate to extract the data.


Proposed changes to abstract:

Periodic Interval of Time (PIVL) specializes SET

Definition: An interval of time that recurs periodically. Periodic intervals have two properties, phase and period/frequency. The phase specifies the "interval prototype" that is repeated every period.

Name Type Description
Frequency RTO<INT,PQ> The number of repetitions to occur within a specified time-period.
displayFrequencyInd BL If true, indicates that frequency takes priority over period for display purposes
template<TS T>protected type PeriodicInterval<T> alias PIVL<T> specializes SET<T> {
  QTY      period;            
  RTO<INT,PQ>  frequency;            
  BL      frequencyDominates;            
  IVL<T>  phase;            
  CS      alignment;            
  BL      institutionSpecifiedTime;            
  BL      contains(TS);  
  literal   ST;

Frequency (frequency : RTO<INT,PQ>)

Definition: The number of times the periodic interval repeats (numerator) within a specified time-period (denominator). The denominator is a physical quantity in the dimension of time (TS.diffType.) For an uncertain periodic interval the numerator is a probability distribution.

 invariant(PIVL<T> x) where x.nonNull {
 invariant(PIVL x) {  
 invariant(PIVL<T> x) where x.nonNull {

Display Frequency Indicator (displayFrequencyInd : BL)

Definition: If true, indicates that frequency takes priority over period for display purposes While mathematically frequency and period are interchangeable, reliable human communication requires differentiation. For example “4 times per day” and “Every 6 hours” are mathematically equivalent. However, good clinical practice requires distinguishing which form was originally expressed as this conveys something of the intent.<May want to indicate something here about how the fuzziness often associated with frequencies relates to IST>


  nullFlavor = {nullFlavor}                    
  operator = "I"|"E"|"A"|"H"|"P"               
  alignment = {alignment}
  institutionSpecified = {institutionSpecified}


  <gsd:paramname="T" type="TS" />
      <gsd:templateas="base" name="SXCM">
        <gsd:attributename="type" type="T" />
       <xsd:elementname="phase" ... />
       <xsd:choice minOccurs="0" maxOccurs="1">
       <xsd:elementname="period" ... />
       <xsd:element name="frequency" … />
     <xsd:attributename="alignment" type="cs_CalendarCycle" ... />
     <xsd:attributename="institutionSpecified" type="bl" ... />

Frequency : RTO<INT, T.DIFF>

 <xsd:elementname="frequency" minOccurs="0" maxOccurs="1">
  <gsd:templateas="type" name="RTO">
    <gsd:attribute name="type" type="INT" />
   <gsd:attribute name="type" type="T" prop="diff" />

Display Frequency Indicator: BL The value of displayFrequencyInd is communicated by the choice of whether period or frequency is sent in the instance. If displayFrequencyInd is true, then frequency is sent. Otherwise, period is sent.


Tom DeJong: You have RTO<INT, T.DIFF> as the data type for the frequency, but further on it seems like you switch to Integer

Lloyd Actually, I started out with INT, then changed it to INT, thinking that clinicians might actually want to say "2.5 times/day". I recognize that saying it doesn't make a lot of sense, but wasn't sure we wanted to prevent it. If consensus is that INT is sufficient, I'm happy with that.


INM 2 May 2007:

Motion: INT is correct. In the XML you can only send one of period or frequency, not both. We approve this proposal. We note that the invariants need technical correction. Gunther / Lee. 8-0-1




Back to Data Types R2 issues