HL7 Table HL70516: Error Severity

HL70516 is the small but operationally important table that classifies how serious an error is. It sits in ERR-4 Severity and qualifies the specific condition reported by HL70357 in ERR-3. Where HL70357 says what went wrong (a required field is missing, the version is unsupported), HL70516 says whether that finding is fatal, an error, a warning, or merely informational. It contains exactly four codes — W, I, E, F — and maps one-to-one onto the FHIR issue-severity value set, making it one of the cleanest v2-to-FHIR terminology correspondences in the standard.

Purpose

HL70516 lets a receiver communicate the gravity of each error independently of the acknowledgment code. A single ACK can carry multiple ERR segments — some W (warnings the sender may safely ignore) and one F (a fatal condition that stopped processing). This severity gradation is what lets an engine decide whether to accept-with-warnings, retry, or hard-fail. It is meant to be read together with ERR-3 (the condition) and ERR-8 (human-readable text).

Because the table is HL7-defined and normative, the four codes are the complete set; receivers must not invent additional severity levels.

Where it's used

ERR-4 Severity — the canonical and only home of HL70516, one severity per ERR repetition.
Multi-error acknowledgments — an ACK with several ERR segments uses HL70516 to distinguish blocking failures from advisory warnings.
Accept-with-warnings logic — engines use W/I to allow a message through while still surfacing advisories.

Code list

Code	Display	Comment/Description
W	Warning	Transaction successful, but there may be issues. The message was processed; the sender should review the advisory.
I	Information	Transaction was successful but includes information. Purely informational; no action required.
E	Error	Transaction was unsuccessful. The specific condition is reported in ERR-3 (HL70357).
F	Fatal Error	Message not processed due to an application or network failure condition. Processing stopped.

Code system OID

OID: 2.16.840.1.113883.18.337
Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0516

The OID resolves on the HL7 Terminology server and is the value Vorro emits in the CWE identifier-system component of ERR-4 when a downstream profile demands OID-bound coded values.

HL7-defined vs user-defined

HL70516 is HL7-defined and normative. The four codes above are the complete set — local extension is not permitted, and any receiver emitting a fifth severity value in ERR-4 is non-conformant. Sites needing finer gradation express it through the specific HL70357 condition code and the free-text ERR-8, not by adding severities to HL70516.

Version differences

v2.1 – v2.4 — No dedicated severity code table; the coarse MSA-1 acknowledgment code implied severity, and free text carried nuance.
v2.5 — The ERR segment was expanded with the ERR-4 Severity field and HL70516 was introduced with the four codes W, I, E, F.
v2.6 – v2.8.1 — Set frozen at four codes; no additions. ERR-4 severity became standard practice for multi-error acknowledgments.
v2.9 — HL70516 unchanged; its four codes continued to align exactly with the FHIR issue-severity value set as systems bridged v2 error reporting to FHIR OperationOutcome.

Common mistakes

Omitting ERR-4 entirely and leaving severity implicit. Without a HL70516 value, a receiver cannot tell an advisory warning from a blocking error; always populate ERR-4.
Sending E in ERR-4 while MSA-1 is AA. An E severity contradicts an application-accept; align the severity with the acknowledgment (see HL70008).
Using F for a content error that the sender could fix. F is for application/network failure that stopped processing; a fixable content problem is E.
Treating W as a failure. A warning means the transaction succeeded; engines that reject on W will drop valid messages.
Emitting lowercase (w, f). HL70516 codes are case-sensitive single uppercase characters.

Examples

A warning-severity ERR — the message was accepted but a code failed a table lookup:

MSH|^~&|EHR|CLINIC|SENDING_APP|SENDING_FAC|20260701150000||ACK^A01^ACK|MSG30001|P|2.8.1
MSA|AA|MSG10000
ERR||PID^1^8|103^Table value not found^HL70357|W|||Value 'O' accepted with warning

An error-severity ERR — a required field is missing and the message was not accepted:

MSH|^~&|EHR|CLINIC|SENDING_APP|SENDING_FAC|20260701150500||ACK^A01^ACK|MSG30002|P|2.8.1
MSA|AE|MSG10001
ERR||PID^1^3|101^Required field missing^HL70357|E|||PID-3 assigning authority required

A fatal-severity ERR — an application/network failure stopped processing:

MSH|^~&|EHR|CLINIC|SENDING_APP|SENDING_FAC|20260701151000||ACK^R01^ACK|MSG30003|P|2.8.1
MSA|AR|MSG10002
ERR||||207^Application error^HL70357|F|||Persistence layer unavailable

A multi-error acknowledgment mixing informational and error severities:

MSH|^~&|EHR|CLINIC|SENDING_APP|SENDING_FAC|20260701151500||ACK^A08^ACK|MSG30004|P|2.8.1
MSA|AE|MSG10003
ERR||PID^1^7|102^Data type error^HL70357|E|||PID-7 not a valid date
ERR||PID^1^11|103^Table value not found^HL70357|I|||Country code defaulted

FHIR mapping

There is no official ConceptMap published for HL70516 in the HL7 v2-to-FHIR Implementation Guide, but unlike most v2 error terminology the mapping is trivial and unambiguous: HL70516 and the FHIR issue-severity value set both have exactly four members and correspond one-to-one.

HL7 v2 (HL70516)	FHIR (issue-severity)
F	fatal
E	error
W	warning
I	information

OperationOutcome.issue.severity is a code element bound to http://hl7.org/fhir/ValueSet/issue-severity. Because the correspondence is exact, no information is lost in the round trip; the HL70357 condition code (which has no clean FHIR equivalent) is what should be preserved as an extension, not the severity.

Engine considerations

Always populate ERR-4 — Emit a HL70516 severity on every ERR repetition so receivers can distinguish advisory from blocking.
Severity/ack coherence — Keep ERR-4 consistent with MSA-1: F/E should accompany AR/AE; W/I are compatible with AA.
Accept-with-warnings — Treat W and I as non-blocking; forward the message and surface the advisory rather than rejecting.
Direct FHIR mapping — Map F/E/W/I straight to fatal/error/warning/information in OperationOutcome.issue.severity; no lossy collapse is required.
Case normalization — Validate that ERR-4 is a single uppercase character in the set {W, I, E, F}; reject or normalize other casings on ingest.

How Vorro handles HL70516

Vorro sets ERR-4 on every ERR segment it emits, pairing the HL70516 severity with the HL70357 condition in ERR-3: content-validation failures that block processing carry E, advisory findings (defaulted values, soft table mismatches accepted under a remap rule) carry W or I, and application/network failures that stop processing carry F. This lets downstream senders react proportionally instead of treating every ERR as fatal.

On the inbound side, Vorro branches on ERR-4 severity: F and E route the message to remediation and, for F, pause the channel; W and I are logged as advisories and do not block forwarding. When errors are surfaced to FHIR consumers, Vorro maps the severity directly to OperationOutcome.issue.severity (F→fatal, E→error, W→warning, I→information) and preserves the accompanying HL70357 condition code in the issue details.

Sources

← Back to HL7 v2 Guide