The RI (Repeat Interval) data type was introduced in HL7 v2.3 to carry the "how often" portion of an order schedule. It is a two-component composite that pairs a coded repeat pattern (HL70335: QD, BID, TID, QID, Q4H, Q6H, Q8H, Q12H, PRN, AC, PC, HS, STAT …) with an optional list of explicit clock times. RI is the inner shape that appears in TQ.2 and in the modern TQ1 timing fields.
Purpose
A repeat pattern alone ("Q6H") tells the receiver the cadence but not the clock alignment — Q6H could start at 00:00, 02:00, or whenever the dose was first given. RI.2 lets the sender pin the schedule to wall-clock times (0600,1200,1800,0000) so two systems consuming the same order land on the same administration windows. The pattern code is mnemonic and human-readable; the explicit times are machine-actionable.
Component table
Source: HAPI HL7v2 v2.8.1 javadocs (RI). Length is shown as — because v2.7+ deprecated fixed maximum lengths in favour of conformance-profile constraints.
| Comp | Name | Sub-type | Length | Required | Description |
|---|---|---|---|---|---|
| RI.1 | Repeat Pattern | is (HL70335) | — | O | Coded repeat pattern: QD, BID, TID, QID, Q4H, Q6H, Q8H, Q12H, PRN, AC (before meals), PC (after meals), HS (bedtime), STAT. |
| RI.2 | Explicit Time Interval | st | — | O | Comma-separated HHMM clock times, e.g. 0600,1200,1800,0000. Pins RI.1 to the calendar. |
Most-used components
- RI.1 Repeat Pattern — the mnemonic frequency code; the most common values are
QD,BID,TID,QID, and theQnHfamily. - RI.2 Explicit Time Interval — the comma-separated
HHMMlist that makes the schedule deterministic across systems.
Where it's used
- TQ.2 Interval — the legacy carrier of repeat-interval semantics inside ORC-7 / OBR-27 in v2.3 and v2.4.
- TQ1-3 Repeat Pattern — modern field with an RI-shaped composite (or RPT in v2.5+ for richer semantics).
- ORC-7 (v2.3 / v2.4) — by way of TQ.2.
- Any custom Z-segment carrying an "interval" composite (many vendor extensions reuse RI verbatim).
Version differences
- HL7 v2.3 — RI introduced with the two-component layout shown above.
- HL7 v2.4 — HL70335 value set expanded; structure unchanged.
- HL7 v2.5 — TQ-segment family (TQ1/TQ2) introduced; RPT (Repeat Pattern) added as a richer alternative that can sit alongside or in place of RI for new profiles.
- HL7 v2.6 / v2.7 / v2.8 / v2.8.1 — structure stable; fixed maximum lengths deprecated. HAPI v2.8.1 javadoc shows the two-component layout above.
Common mistakes
- Writing English in RI.1 ("every six hours") instead of the coded
Q6H— receivers parsing HL70335 will treat the value as unknown. - Using non-HHMM times in RI.2 (
6:00 AM,06:00) — the format is strictly four-digit 24-hourHHMMwith no separator. - Mixing time-of-day lists with PRN —
PRN^0600,1200is contradictory; PRN means "as needed" and has no fixed clock. - Forgetting that
Q6Hdivides evenly into a day butQ5Hdoes not — emittingQ5Hwithout explicit times leaves the receiver guessing how to align doses. - Treating RI as flat string
Q6H 0600,1200(space-separated) — the components are^-separated in HL7 v2 encoding.
Examples
Minimal — coded pattern only:
BID
Populated — Q6H pinned to four clock times:
Q6H^0600,1200,1800,0000
In context — TQ1 segment carrying RI in TQ1-3 for a TID schedule at 08:00 / 14:00 / 20:00:
MSH|^~&|EHR|MERCY|PHARM|MERCY|20260624075500||OMP^O09^OMP_O09|MSG0212|P|2.8.1
ORC|NW|ORD-5502^MERCY|||IP
TQ1|1|1^tablet^UCUM|TID^0800,1400,2000||1H|20260624080000|20260628080000|R
RXO|309029^Amoxicillin 500 mg oral capsule^RXNORM|500^mg^UCUM||CAP^Capsule^HL70162|PO^Oral^HL70162
Common pitfall — non-HHMM explicit times:
Q6H^6:00 AM,12:00 PM,6:00 PM,12:00 AM
The receiver expects 0600,1200,1800,0000. The clock-with-AM/PM form will fail strict parsing and most engines will either drop RI.2 or reject the message.
FHIR mapping
The v2-to-FHIR IG publishes ConceptMap-datatype-ri-to-timing. RI maps into Timing.repeat so the FHIR consumer sees the schedule in canonical form:
| RI component | FHIR element | Notes |
|---|---|---|
| RI.1 Repeat Pattern | Timing.repeat.frequency + Timing.repeat.period + Timing.repeat.periodUnit | QD → frequency 1 / period 1 / d; Q6H → frequency 1 / period 6 / h; BID → frequency 2 / period 1 / d, and so on. |
| RI.1 PRN | Timing.code = "PRN" | Falls outside Timing.repeat — encoded as a Timing.code instead. |
| RI.2 Explicit Time Interval | Timing.repeat.timeOfDay[] | Each HHMM becomes a time value (06:00, 12:00, 18:00, 00:00). |
Engine considerations
- HL70335 churns across versions: the value set has accreted codes (
Q1H,Q2H,Q3H,QOD…) over time. Maintain a translation table from coded pattern to (frequency, period, periodUnit) rather than a hard-coded switch. - PRN, AC, PC, HS — these are clinical-context codes, not periodic intervals. Engines must route them to
Timing.codeor an extension; otherwise they vanish during FHIR mapping. - RI vs RPT: a v2.5+ partner may use either. RI.1 is an IS code; RPT.1 is a CWE that wraps the same code with a system. Vorro and similar engines should accept both and normalize internally.
- Time-zone trap: RI.2 is wall-clock with no offset. Resolve the offset from the host message (MSH-7 or the patient's facility) before emitting
Timing.repeat.timeOfDay.
How Vorro parses and produces RI
Vorro decodes RI.1 against the full HL70335 catalog into a (frequency, period, periodUnit, isAsNeeded, clinicalContext) tuple, and parses RI.2 into a typed list of local times. Inbound Q6H becomes frequency=1, period=6, periodUnit=h; inbound BID becomes frequency=2, period=1, periodUnit=d; inbound PRN sets the as-needed flag. Explicit times are validated as four-digit HHMM and rejected loudly if malformed.
On outbound, Vorro prefers the coded RI.1 form for human readability and pins it to explicit times in RI.2 whenever the source carried them. When the schedule cannot be expressed in HL70335 (e.g. Q7H or "every Tuesday at 09:00"), Vorro escalates to RPT in TQ1-3 rather than mangling RI.1.
