ERR - Error Segment

The ERR segment is used to add error comments to acknowledgment messages.

Use Cases:

Severity: A receiving application needs to communicate 2 "error or exception statements." One is an "error;" the other is a "warning". To accomplish this, an acknowledgment message with 2 ERR segments is sent. Upon receipt, the sending application can display both, including the appropriate severity, to the user.

Application Error Code: A receiving application generates an error that reports an application error code and returns this information in its response. This code in turn is used by helpdesk staff to pinpoint the exact cause of the error, or by the application to prompt an appropriate response from the user. (Ex. Deceased date must be greater than or equal to birth date).

Application Error Parameter: A receiving application encounters an error during processing of a transaction. In addition to an error code, the application provides an error parameter that gives greater detail as to the exact nature of the error. The receiving application looks up the message corresponding to the error code, substitutes in the parameter, and displays the resulting message to the user.

Diagnostic Information: While processing a transaction, a receiving application encounters an exception. When the exception is thrown, it provides a volume of detailed information relating to the error encountered. The receiving application captures the information and sends it in its response. The user reports the error to the help desk, and on request, faxes a copy of the diagnostic information to assist analyzing the problem.

User Message: A user executes an application function that generates a transaction that is sent to another application for further processing. During this processing, the receiving application encounters an error and, as part of the error handling routine, retrieves a User Message that it returns in its response. The originating application receives the error and displays it to the end user with the intent that the error condition can be resolved and the user can re-execute the function without error.

Inform Person Code: After submitting a dispense transaction, a response is returned to the user indicating that the patient could be abusing drugs. Given the sensitivity of this warning, the error is returned with an indicator stating that the patient should not be informed of the error with the implication that steps should be taken to rule out or confirm the warning.

Override Type: If a business rule states that a prescription on hold cannot be dispensed, an override type might be "Dispense Held Prescription" to allow the prescription to be dispensed in exception to the rule.

Override Reason Codes: A patient is given a prescription; however, before completing the prescription, the remaining pills are spoiled. The patient returns to their pharmacy and explains the situation to their pharmacist. The pharmacist decides to replace the spoiled drugs; however, when attempting to record the event, a message is returned indicating that the dispense would exceed the maximum amount prescribed. The pharmacist overrides the rule and specifies an Override Reason Code indicating a replacement of lost product.

Help Desk Contact: Help desk contact information is stored in a database. When an application error is encountered, the database is queried and the most current help desk contact information is returned in the error message. This is displayed to the user by the receiving application.

Better Error Location Information: Receiving system detects an error with the 3rd repetition of the ROL.4 (Role Person - XCN).16 (Name Context – CE).4(Alternate Identifier – CWE). The application identifies the specific repetition and component when raising the error, simplifying diagnosis of the problem.

Support for multiple Error Locations: Two fields are marked as conditional, with the condition that one of the two must be specified. The sending application leaves both blank. The receiving application detects the problem, and sends back a single error indicating that one of the fields must be filled in. The ERR segment identifies both positions within the message that relate to the error.

HL7 Attribute Table - ERR - error segment

Seq#	Data Element Name	DataType	Usage	Vocabulary	Cardinality	Item #	Length	C.LEN	Flags
ERR
1	Error Code and Location		W		[0..1]	00024
2	Error Location	ERL	O		[0..*]	01812
3	HL7 Error Code	CWE	R	0357(R) Message Error Condition Codes(Required)	[1..1]	01813
4	Severity	ID	R	0516(R) Error Severity(Required)	[1..1]	01814	[1..1]
5	Application Error Code	CWE	O	0533 Application Error Code	[0..1]	01815
6	Application Error Parameter	ST	O		[0..10]	01816		80	#
7	Diagnostic Information	TX	O		[0..1]	01817		2048	#
8	User Message	TX	O		[0..1]	01818		250	#
9	Inform Person Indicator	CWE	O	0517(S) Inform Person Code(Suggested)	[0..*]	01819
10	Override Type	CWE	O	0518 Override Type	[0..1]	01820
11	Override Reason Code	CWE	O	0519 Override Reason	[0..*]	01821
12	Help Desk Contact Point	XTN	O		[0..*]	01822

ERR-1: Error Code and Location () 00024

Attention: The ERR-1 field was deprecated in V2.4 and is withdrawn in V2.7. Please refer to ERR-2 and ERR-3 instead.

ERR-2: Error Location (ERL) 01812

Definition: Identifies the location in a message related to the identified error, warning or message. If multiple repetitions are present, the error results from the values in a combination of places.

ERR-3: HL7 Error Code (CWE) 01813

Definition: Identifies the HL7 (communications) error code. Refer to HL7 Table 0357 – Message Error Condition Codes in Chapter 2C, Code Tables, for valid values.

ERR-4: Severity (ID) 01814

Definition: Identifies the severity of an application error. Knowing if something is Error, Warning or Information is intrinsic to how an application handles the content. Refer to HL7 Table 0516 - Error Severity in Chapter 2C, Code Tables, for valid values. If ERR-3 has a value of "0", ERR-4 will have a value of "I".

Example: a Warning could be used to indicate that notes were present, but ignored because they could not be automatically processed, and therefore information could have been missed.

Example of Information: When submitting a claim, a payor might indicate remaining coverage under limit.

ERR-5: Application Error Code (CWE) 01815

Definition: Application specific code identifying the specific error that occurred. Refer to User-Defined Table 0533 – Application Error Code in Chapter 2C, Code Tables, for suggested values.

If the message associated with the code has parameters, it is recommended that the message be indicated in the format of the java.text.MessageFormat approach.³ This style provides information on the parameter type to allow numbers, dates and times to be formatted appropriately for the language.

ERR-6: Application Error Parameter (ST) 01816

Definition: Additional information to be used, together with the Application Error Code, to understand a particular error condition/warning/etc. This field can repeat to allow for up to 10 parameters.

Example: If the application error code specified in ERR.5 corresponded with the English message "The patient has a remaining deductible of {0, number, currency} for the period ending {1, date, medium}.", and the first two repetitions of ERR.6 were "250" and "20021231", then a receiving application in the U.S. would display the message as "The patient has a remaining deductible of $250.00 for the period ending Dec 31, 2002."

ERR-7: Diagnostic Information (TX) 01817

Definition: Information that MAY be used by help desk or other support personnel to diagnose a problem.

ERR-8: User Message (TX) 01818

Definition: The text message to be displayed to the application user.

Example:

|This program is having trouble communicating with another system. Please contact the help desk.|

This differs from the actual error code and could provide more diagnostic information.

ERR-9: Inform Person Indicator (CWE) 01819

Definition: A code to indicate who (if anyone) SHOULD be informed of the error. This field MAY also be used to indicate that a particular person SHOULD NOT be informed of the error (e.g., Do not inform patient). Refer to User-defined table 0517- Inform Person Code in Chapter 2C, Code Tables, for suggested values.

ERR-10: Override Type (CWE) 01820

Definition: Identifies what type of override can be used to override the specific error identified. Refer to User-defined Table 0518 - Override Type in Chapter 2C, Code Tables, for suggested values.

ERR-11: Override Reason Code (CWE) 01821

Definition: Provides a list of potential override codes that can be used to override enforcement of the application rule that generated the error. Refer to User-defined table 0519 – Override Reason in Chapter 2C, Code Tables, for suggested values.

ERR-12: Help Desk Contact Point (XTN) 01822

Definition: Lists phone, e-mail, fax, and other relevant numbers for helpdesk support related to the specified error.