Regarding how to report frequencies using the effectiveTime as a PIVL_TS or EIVL_TS:

After some research and conversation, we do not think there is any specific guidance on this particular issue. While the QRDA Cat 1 base IG constrains the type to be PIVL_TS or EIVL_TS, the CMS IG is silent on the matter. Due to this lack of formal guidance, and the many variations of what can be represented, it's difficult to determine how well these complex frequencies will be supported by health IT systems.

Regarding two specific questions that were raised by the submitter:
How do you say things like "with breakfast", "10 minutes before breakfast", "between meals", etc?
How do you say "every 4 - 6 hours"? Do you apply an average ("every 5 hours")?

For event-based frequencies, like "before breakfast", an IVL_TS represent the period over which the medication is taken, and a EIVL_TS with an embedded event represents the timing of the medication. For example:

<!-- med started on 1/18/2014 and has not ended -->
<effectiveTime xsi:type="IVL_TS">
<low value="20140118"/> <!-- med started on 01/18/2014 -->
<high nullFlavor="NI"/> <!-- med has not stopped -->
</effectiveTime>

<!-- med frequency: before breakfast -->
<effectiveTime typeCode="EIVL_TS" operator="A"> <!-- where "A" stands for every -->
<event code="ACM"/> <!-- where "ACM" stands for "before breakfast" -->
</effectiveTime>

Together, these two effectiveTimes would be understood as follows: A medication that started on 1/18/2014 and is to be taken every morning before breakfast.

The event/@code uses codes from the "TimingEvent" concept domain. You can find a full list here: http://hl7.org/fhir/v3/TimingEvent/

For frequencies such as "every 4 - 6 hours", an IVL_TS represents the period over which the medication is taken, and a PIVL_TS with an embedded interval represents the timing of the medication. For example:

<!-- med started on 1/18/2014 and has not ended -->
<effectiveTime xsi:type="IVL_TS">
<low value="20140118"/>
<high nullFlavor="NI"/>
</effectiveTime>

<!-- med frequency of 4 - 6 hours -->
<effectiveTime typeCode="PIVL_TS" operator="A"> <!-- where "A" stands for every -->
<period xsi:type="IVL_PQ">
<low value="4" unit="h"/> <-- minimum 4 hours -->
<high value="6"StartFragment unit="h"/> <-- maximum 6 hours -->
</period>
</effectiveTime>

Together, these two effectiveTimes could be understood as follows: A med that started on 1/18/2014 and is to be taken every 4 - 6 hours.

Many thanks to Stan Rankins of Telligen and Rob Dingwell of MITRE, who helped us work through some of this. We hope that this helps you a bit. Let us know if you need to talk through this further.

I discussed this issue with Yan and Nelli and I believe the initial ticket description is overly complex.

When Nelli opened this ticket it was her belief that PQRS had to handle all possible variations of a 'Timing Event'. It turns out that, to support the Measures definitions for the 2015 submission period, PQRS only needs to handle the ‘PIVL_TS’ and ‘EIVL_TS’ xsi:types.

In light of this simplification, the question posed by this ticket should be…

"PQRS needs guidance on how to translate all the possible variations of the QRDA-1 ‘PIVL_TS’ and ‘EIVL_TS’ timing events into the number of doses a day that a person is taking so that we can support CMD calculations.”

Depending on the guidance that PQRS gets, calculating the 'number of doses a day' becomes increasingly complex. There are three levels complexity defined below, which I have labeled Options 1, 2, and 3.

PQRS hopes that we will be directed to follow Option 1. If it is necessary that we have to follow Option 2 or 3 then there is increasing amounts of additional guidance that will be required in order for PQRS to do the required calculations.

Here is a breakdown of the Options:

Options 1 (the most desirable guidance PQRS hopes to get):
==============================================
PQRS only has to handle the most basic form of the ‘PIVL_TS’ effectiveTime (only the ‘period’ sub-element and only the default xsi:type).

This means that…
• the ‘EIVL_TS’ xsi:type can be ignored
• the ‘phase’ element can be ignored
• the other attributes can be ignored
• All xsi:type varients can be ignored

A simple ‘PIVL_TS’ effective time looks like this…

<effectiveTime xsi:type="PIVL_TS" institutionSpecified="false" operator="A">
<period value="8" unit="h"/>
</effectiveTime>

A complex 'PIVL_TS' effectiveTime looks like this…

<effectiveTime xsi:type="PIVL_TS" institutionSpecified="true" operator="???">
<phase operator="??" value="?" xsi:type="????" />
<period xsi:type="???" value="6" unit="h"/>
</effectiveTime>

Options 2 (significantly more complex than Option 1):
========================================
In addition to handling the basic ‘PIVL_TS’ effectiveTime, PQRS must also handle the basic form of the 'EIVL_TS' effectiveTime.

This means that…
• PQRS must handle the basic 'PIVL_TS' effectiveTime as mentioned in Option 1
• PQRS also must also handle the basic 'EIVL_TS' effectiveTime
• Handling a basic 'EVIL_TS' effective time means…

• ‘offset’ element can be ignored
• Other attributes can be ignored
• All xsi:type varients can be ignored
  • PQRS requires guidance defining which timing codeSystems must be supported
  • PQRS requires a table that translates timing event codes in all codeSystems to 'doses per day'

A simple ‘EIVL_TS’ effective time looks like this…

<effectiveTime xsi:type="EIVL_TS" operator="A" value="?" >
<event code="AC" codeSystem="2.16.840.1.113883.5.139" sdtc:valueSet="2.16.840.1.113883.3.88.12.3221.8.11" />
</effectiveTime>

A complex 'EIVL_TS' effectiveTime looks like this…

<effectiveTime xsi:type="EIVL_TS" operator="A" value="4" >
<event code="AC" codeSystem="2.16.840.1.113883.5.139" sdtc:valueSet="2.16.840.1.113883.3.88.12.3221.8.11" xsi:type=”???”/>
<offset xsi:type="????" operator="A" value="3" unit="1" />
</effectiveTime>

Options 3 (most complex guidance):
============================
If PQRS needs to handle anything other than the most basic forms of ‘EVIL_TS’ and ‘PIVL_TS’ times then PQRS requires very detailed guidance for how the information should be translated into “number of doses per day”.