OVR records that a business rule or safety check was deliberately overridden. When a pharmacy system flags a problem — a drug-drug interaction, an early refill, a dose ceiling — and a user chooses to proceed anyway, OVR captures what rule was overridden, why, who recorded the override, and who authorized it. It is a control/envelope segment: it carries no clinical order data of its own, only the audit trail of a human decision to bypass an automated check. OVR is optional and appears adjacent to the segment whose data triggered the rule, most often near RXE or RXD in a dispense message.
Purpose
OVR answers four questions about an override: which business rule was overridden (OVR-1), the reason for overriding it (OVR-2), any free-text explanation (OVR-3), and the two people accountable — the user who recorded the override (OVR-4) and the provider who authorized it (OVR-5). It exists so that a bypassed safety check is never silent: the override travels with the order or dispense as a permanent record.
Used in
OVR is used in pharmacy/treatment order and dispense messages where an override must be recorded — most commonly the dispense message RDS^O13, and pharmacy order messages such as RDE^O11 and RGV^O15. It is placed next to the segment carrying the data that triggered the rule, so it sits near RXE, RXD, or the relevant ORC/RXO grouping. See the messages index for the full list.
Field-by-field reference
Source: HL7 v2.5.1+ standard OVR segment definition (see HL7 v2+ OVR and Caristix OVR). No segment-level ConceptMap is published in the v2-to-FHIR IG for OVR. R = required (cardinality min ≥ 1); all OVR fields are optional in the base standard. Repeat = field may repeat. Length pending authoritative v2.5.1 data.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| OVR-1 | Business Rule Override Type | CWE | — | O | — | HL70518 | What business rule is being overridden, e.g. a compassionate refill or an interaction warning. |
| OVR-2 | Business Rule Override Code | CWE | — | O | — | HL70521 | The reason for the override, e.g. spoilage. |
| OVR-3 | Override Comments | TX | — | O | — | — | Free-text explanation of why the rule was overridden. |
| OVR-4 | Override Entered By | XCN | — | O | — | — | The user who recorded the override (often the technician). Sometimes labeled "Override Recorded By". |
| OVR-5 | Override Authorized By | XCN | — | O | — | — | The provider accountable for authorizing the override (often the pharmacist). Sometimes labeled "Override Responsible Provider". |
Most-used fields
OVR-1 Business Rule Override Type and OVR-2 Business Rule Override Code are the core pair: together they say what was overridden and why. A common pharmacy example is OVR-1 carrying a "Compassionate Refill" type with OVR-2 carrying a reason such as "Spoilage". Both are CWE, so they typically arrive as code^text^codingsystem.
OVR-4 Override Entered By and OVR-5 Override Authorized By split accountability between the person who keyed the override and the licensed provider who is responsible for it. In many workflows these are two different people — a technician records, a pharmacist authorizes — which is exactly why the standard provides two separate XCN fields rather than one.
OVR-3 Override Comments is free text and tends to be the field auditors actually read, since it explains the human reasoning the coded fields cannot.
Version differences (2.3 to 2.8.2)
- 2.3 / 2.4: OVR does not exist. Overrides, where captured at all, were recorded informally in comment segments (NTE) or order-level fields.
- 2.5 / 2.6: OVR was introduced into the pharmacy/treatment chapter to formalize business-rule overrides, with OVR-1 through OVR-5 as defined here. (The exact introduction point is around v2.5/2.6; treat the precise version as approximate.)
- 2.7 / 2.7.1: OVR is well established in the order entry: pharmacy/treatment/vaccination chapter; CWE/XCN component definitions track the broader 2.7 data-type updates.
- 2.8.x: No structural change to the five OVR fields. Receivers built before OVR existed simply do not expect the segment; senders must confirm the receiver's supported version before emitting it.
Common mistakes
- Emitting OVR to a receiver on v2.3/2.4 that has no concept of the segment — it will be ignored or rejected. Confirm the negotiated version first.
- Collapsing OVR-4 and OVR-5 into one person. They are deliberately distinct: who recorded versus who authorized.
- Placing OVR far from the triggering segment. It should sit adjacent to the segment (e.g. RXE or RXD) whose data tripped the rule, so the link between rule and override is unambiguous.
- Sending only OVR-3 free text without the coded OVR-1/OVR-2 pair, leaving downstream systems unable to classify the override.
- Treating override reasons as fixed HL7 codes. OVR-1 (Table 0518) and OVR-2 (Table 0521) are user-defined; values are site/vendor-specific.
Examples
Minimal OVR (an override type and reason only):
OVR|RF^Compassionate Refill^HL70518|SP^Spoilage^HL70521
Fully-populated OVR:
OVR|RF^Compassionate Refill^HL70518|SP^Spoilage^HL70521|Patient lost medication in transit; refill authorized early per protocol.|9921^TECH^ALEX^^^^^^HOSP^^^^PRN|4471^PHARM^JORDAN^M^^^^^HOSP^^^^DN
Annotated breakdown of the fully-populated example:
OVR ← segment ID
RF^Compassionate Refill^HL70518 ← OVR-1 Business Rule Override Type (code^text^system)
SP^Spoilage^HL70521 ← OVR-2 Business Rule Override Code (reason)
Patient lost medication in transit; ... ← OVR-3 Override Comments (free text)
9921^TECH^ALEX^...^HOSP^...^PRN ← OVR-4 Override Entered By (recording user)
4471^PHARM^JORDAN^M^...^HOSP^...^DN ← OVR-5 Override Authorized By (responsible provider)
In-context inside an RDS^O13 (pharmacy dispense), with OVR adjacent to the dispense data it qualifies:
MSH|^~&|PHARM|HOSP_A|EHR|HOSP_A|20260609120000||RDS^O13^RDS_O13|CTRL-7781|P|2.5.1
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
ORC|RE|ORD555^PHARM|FILL555^PHARM
RXE|1^^^20260609|ACE001^Amoxicillin 500mg^L|500||mg
RXD|1|ACE001^Amoxicillin 500mg^L|20260609120000|30|mg
OVR|RF^Compassionate Refill^HL70518|SP^Spoilage^HL70521|Early refill approved; original supply spoiled.|9921^TECH^ALEX^^^^^^HOSP|4471^PHARM^JORDAN^M^^^^^HOSP
In-context inside an RDE^O11 (pharmacy encoded order), with OVR next to the encoded order segment:
MSH|^~&|CPOE|HOSP_A|PHARM|HOSP_A|20260609131500||RDE^O11^RDE_O11|CTRL-7799|P|2.5.1
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
ORC|NW|ORD777^CPOE||GRP777^CPOE
RXE|1^^^20260609|WAR010^Warfarin 5mg^L|5||mg
OVR|DDI^Drug-Drug Interaction^HL70518|MD^Provider Reviewed^HL70521|Interaction with existing aspirin reviewed and accepted.|3310^NURSE^SAM^^^^^^HOSP|4471^PHARM^JORDAN^M^^^^^HOSP
FHIR mapping
No segment-level ConceptMap is published in the v2-to-FHIR IG for OVR. There is no single FHIR resource that OVR maps to as a whole.
In practice, override semantics surface across several FHIR elements rather than one target. The substitution/override decision on a dispense is commonly represented on MedicationDispense.substitution (with .substitution.reason and .substitution.responsibleParty), while the underlying safety check that was overridden aligns conceptually with DetectedIssue and its mitigation. The two accountable parties (OVR-4, OVR-5) map naturally onto Practitioner/PractitionerRole references on whichever resource carries the override.
| OVR field | Likely FHIR target (no official map) |
|---|---|
| OVR-1 Business Rule Override Type | DetectedIssue.code / MedicationDispense.substitution.type (approximate) |
| OVR-2 Business Rule Override Code | MedicationDispense.substitution.reason / DetectedIssue.detail (approximate) |
| OVR-3 Override Comments | .note.text on the carrying resource (approximate) |
| OVR-4 Override Entered By | Practitioner reference (recorder) — approximate |
| OVR-5 Override Authorized By | MedicationDispense.substitution.responsibleParty / Practitioner (approximate) |
All rows above are interpretive guidance, not an authoritative mapping. Confirm the target against your FHIR profile before relying on it.
Engine considerations
- Treat OVR as optional and version-gated: only emit it to receivers negotiated at the version that defines it (~v2.5/2.6 and later).
- Preserve adjacency. The override is meaningful only in relation to the segment it qualifies; keep OVR positioned next to that RXE/RXD/ORC grouping during transforms rather than hoisting it elsewhere.
- OVR-1 and OVR-2 are user-defined (Tables 0518 and 0521). Map them through a site-specific value-set table; do not assume a fixed HL7 code set.
- Audit value: because OVR is the record of a bypassed safety check, log it on receipt even when downstream processing ignores it.
- Failure mode: dropping OVR during a downgrade transform to an older version silently erases the override audit trail. Flag rather than discard.
How Vorro parses and produces OVR
On parse, Vorro reads OVR as a control segment attached to its preceding dispense/order grouping, decomposes the CWE pair (OVR-1/OVR-2) against the configured override value sets, and retains OVR-3 comments plus both XCN parties (OVR-4, OVR-5) as a structured override record linked to the order. On produce, Vorro emits OVR only when the target channel's negotiated version supports it, places it adjacent to the triggering RXE/RXD, and maps internal override types and reasons back into the receiver's expected Table 0518/0521 codes. If a downgrade would strip OVR, Vorro raises a transform warning rather than dropping the audit data silently.
Related pages
- RXD — the pharmacy/treatment dispense segment OVR most often qualifies.
- RXE — the pharmacy/treatment encoded order segment OVR sits beside in order messages.
- ORC — the common order segment that anchors the order/dispense grouping OVR belongs to.
