OVR - Override Segment

Definition: This segment allows a sender to override specific receiving application's business rules to allow for processing of a message that would normally be rejected or ignored.

In many instances, business rules will be set as guidelines relative to patient care. In some instances it is in the patient's better interest to circumvent these guidelines. In other cases, business rules might exist to support normal process flow, but which couldbe bypassed or ignored under certain special circumstances. This segment is linked to the proposed ERR segment changes in that the first attempt to process a transaction that violates a business rule could result in an error that must be overridden. The ERR provides a mechanism to identify errors that MAY be overridden, as well as the allowed override codes.

Use case #1: A patient has received a prescription with a duration of 30 days and receives the full amount at their pharmacy. While at home the patient accidentally spills the container and spoils a significant proportion of the prescription. The patient returns to their pharmacy and explains the situation to the pharmacy technician. The technician consults with their supervising pharmacist. Knowing the patient, the pharmacist decides to override the business rule stating that the dispensed amount for a prescription can not exceed the prescribed amount. In recording the decision, the pharmacy technician specifies that the Override Type is a "Compassionate Refill" and that the Override Code, or reason for the override, is "Spoilage". The technician also provides Override Comments to provide an explanation of the situation for future reference. While recording the decision, the technician's user ID is automatically stored in an Override Recorded By field. The pharmacist's ID is stored in the Override Responsible Provider field.

Use case #2:A hospital wishes to submit an invoice to an insurer who is providing secondary coverage. The invoice is being submitted over a week after the service was performed, which is outside the insurer's normal accept time window. The insurer would normally reject the invoice. However, the submitter includes an Override Type of "late submission" as well as an Override Code indicating that the invoice is late due to delays with the primary payor. The secondary insurer examines the override reason and accepts the invoice.

Usage Note: The override segment SHOULD be included in messages adjacent to the segment(s) containing the information that would trigger the business rule(s) that needs to be overridden. The segment SHOULD be optional (you shouldn't always need to override business rules), and SHOULD be allowed to repeat in circumstances where there can be more than one business rule overridden at the same time. Committees MAY wish to provide suggested values for override types or codes for use with the OVR segment in different messages.

The following is an example of how the OVR segment might be used in a dispense message (RDS_O13):

MSH PID PV1 {ORC RXE {RXR} RXD {RXR} <RXC> <NTE> <FT1> <OVR>}

HL7 Attribute Table - OVR - override segment

Seq#	Data Element Name	DataType	Usage	Vocabulary	Cardinality	Item #	Length	C.LEN	Flags
OVR
1	Business Rule Override Type	CWE	O	0518 Override Type	[0..1]	01829
2	Business Rule Override Code	CWE	O	0521 Override Code	[0..1]	01830
3	Override Comments	TX	O		[0..1]	01831		200	#
4	Override Entered By	XCN	O		[0..1]	01832
5	Override Authorized By	XCN	O		[0..1]	01833

OVR-1: Business Rule Override Type (CWE) 01829

Definition: Identifies what type of business rule override is being performed. Refer to User-defined Table 0518 - Override Type in Chapter 2C, Code Tables, for suggested values. Given that an application provides end users with the ability to override business rules, there must be a way to communicate what business rule is being overridden.

OVR-2: Business Rule Override Code (CWE) 01830

Definition: Indicates the reason for the business rule override. Refer to User-defined Table 0521 – Override Code in Chapter 2C, Code Tables, for suggested values.

If users are allowed to override business rules in an application, the user will typically need to provide a reason why the rule is being overridden. The Override Code field in this segment will provide the mechanism to transmit a coded reason.

OVR-3: Override Comments (TX) 01831

Definition: Additional descriptive comments detailing the circumstances of the override.

When overriding a business rule there might be special circumstances that require a further explanation of the override action. The Override Comments field will allow users to provide more specific information in a free text format.

OVR-4: Override Entered By (XCN) 01832

Definition: Identifies the user entering the override in the system.

When a business rule is overridden, an application must be able to link the override with the user who made it in order to provide a complete audit history of the transaction, especially when there might be a risk associated with the override. In situations where the original message was submitted by batch, the overriding user MAY be different than the original author of the message.

OVR-5: Override Authorized By (XCN) 01833

Definition: Identifies the health services provider who accepts professional responsibility for overriding the business rule. This field SHOULD be left empty if the recording and responsible health care provider is the same as who entered the override.

In some cases, a business rule override might be entered by a data entry clerk on behalf of a health service provider who carries professional responsibility for the decision to override the rule. In order to represent this scenario, the segment must have a field identifying who is responsible for the override decision, in addition to the person recording the override.