Timing

• Datatypes
• Definitions
• Examples
• Mappings
• Profiles

Overview

See also Examples, Detailed Descriptions, Mappings, Profiles and Extensions

Describes the occurrence of an event that may occur multiple times. Timing schedules are used for specifying when events are expected or requested to occur and may also be used to represent the summary of a past or ongoing event. For simplicity, the definitions of Timing components are expressed as 'future' events, but such components can also be used to describe historic or ongoing events.

A Timing schedule can be a list of events and/or criteria for when the event happens, which can be expressed in a structured form and/or as a code. When both event and a repeating specification are provided, the list of events should be understood as an interpretation of the information in the repeat structure.

Note: The Timing datatype allows modifier extensions (though Timing.repeat does not).

[%dt Timing 13%]

If the timing schedule has repeating criteria, the repeat can occur a given number of times per the specified duration or in relation to some repeating real-world event.

Unless the Timing.repeat specifies a boundsPeriod, the bounds of the repeating cycle are at a time specified in the context where the Timing is used, or the cycle starts immediately. If the repeat is not limited by providing bounds[x] or count the bounds of the repeating cycle are expressed in some criteria elsewhere, either explicitly or implicitly.

Many systems avoid the complexity of the Timing structure by using a text field for timing instructions. This maps to Timing.code.text. For example, the text instruction "take medication in the morning on weekends and days off work' would be represented as:

"timing": { "code" : { "text" : "Take medication in the morning on weekends and days off work" } }

Other systems use a set of 'common' codes - including, but usually not limited to, widely understood acronyms such as "BID". If a Timing.code is provided, the code is understood to be a complete statement of whatever is specified in the structured timing data (except for Timing.repeat.bounds, which applies to the code), and either the code or the data may be used to interpret the Timing. A structured timing specification SHOULD be provided whenever possible, unless the code is BID, TID, QID, AM or PM, which have a ubiquitous meaning.

This table summarizes some common uses of the Timing Datatype criteria.

Note that there are two offsets here: offset which specifies the offset from event, where the event property relates to a regular event, such as before meals. The other kind of offset is startOffset and endOffset which relate to the regular events within the repeat window: if they occur with frequency > 1, the start and end offsets impose a gap in the schedule - see Dosage Examples for usage.

This table shows the relationship between the codes provided as part of the base specification, and the structured data portions of the Timing type:

These codes SHALL be understood as having the formal meanings documented in this table. Note that BID, etc. are defined as 'at institutionally specified times'. For example, an institution may choose that BID is "always at 7am and 6pm". If it is inappropriate for this choice to be made, the code BID should not be used. Instead, a distinct organization-specific code should be used in place of the HL7-defined BID code and/or a structured representation should be used (in this case, timeOfDay).

Constraints

[%dt.constraints Timing%]

Note that these constraints still allow for nonsensical timing specifications such as "Once per day at 2:00 and 4:00" or "every 3 days on Friday". Implementers must take care to ensure that their configuration and data collection designs do not lead to these non-interpretable timing specifications. The elements dayOfWeek, timeOfDay, and when are particularly likely to be at issue here.

[%tx Timing%]

Timing is used in the following places: [%dtusage Timing%]

Elements

• Timing.event [0..*]: dateTime Identifies specific times when the event occurs
• Timing.repeat [0..1]: - A set of rules that describe when the event is scheduled
• Timing.code [0..1]: CodeableConcept A code for the timing schedule (or just text in code.text). Some codes such as BID are ubiquitous, but many institutions define their own additional codes. If a code is provided, the code is understood to be a complete statement of whatever is specified in the structured timing data, and either the code or the data may be used to interpret the Timing, with the exception that .repeat.bounds still applies over the code (and is not contained in the code)

Bindings

• Timing.code: TimingAbbreviation | strength: code list | reference: #timing-abbreviation

Requirements

• Timing.event: In a Medication Administration Record, for instance, you need to take a general specification, and turn it into a precise specification
• Timing.repeat: Many timing schedules are determined by regular repetitions

Comments

• Timing.code: BID etc. are defined as 'at institutionally specified times'. For example, an institution may choose that BID is "always at 7am and 6pm". If it is inappropriate for this choice to be made, the code BID should not be used. Instead, a distinct organization-specific code should be used in place of the HL7-defined BID code and/or a structured representation should be used (in this case, specifying the two event times)

Mappings

• Timing.event: RIM Mapping: QLIST<TS>
• Timing.repeat: RIM Mapping: Implies PIVL or EIVL
• Timing.code: RIM Mapping: QSC.code