Draft Website - For Review Purposes Only

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#	DataElement	Description	Must Implement	Flags	Cardinality	Length	C.LEN	Vocabulary	DataType
ERR
1	00024	Error Code and Location	SHALL NOT	W	[0..0]
2	01812	Error Location			[0..*]				ERL
3	01813	HL7 Error Code	SHALL		[1..1]			0357 Message Error Condition Codes	CWE
4	01814	Severity	SHALL		[1..1]	[1..1]		0516 Error Severity	ID
5	01815	Application Error Code			[0..1]			0533	CWE
6	01816	Application Error Parameter		#	[0..10]		80		ST
7	01817	Diagnostic Information		#	[0..1]		2048		TX
8	01818	User Message		#	[0..1]		250		TX
9	01819	Inform Person Indicator			[0..*]			0517 Inform Person Code	CWE
10	01820	Override Type			[0..1]			0518 Override Type	CWE
11	01821	Override Reason Code			[0..*]			0519	CWE
12	01822	Help Desk Contact Point			[0..*]				XTN

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.

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.

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

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.

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.

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."

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

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.

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.

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.

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.

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