HL7 Table HL70357: Message Error Condition Codes

HL70357 is the error-code table that gives structured, machine-readable reasons for why a message succeeded, errored, or was rejected. It is carried in ERR-3 HL7 Error Code (in older profiles it appeared in the deprecated ERR-1 legacy location) and travels alongside the acknowledgment code in MSA-1. Where MSA-1 says "accept / error / reject" at a coarse level, HL70357 says specifically what went wrong — a required field was missing (101), the version is unsupported (203), the key identifier is unknown (204). The codes are grouped into families: 0 (success), the 1xx codes (HL7 syntax/data errors), and the 2xx codes (rejections at the message/application level).

Purpose

HL70357 exists so that automated senders can react to failures without a human reading free text. A 203 "Unsupported version id" tells the sender to stop sending that version; a 205 "Duplicate key identifier" tells it the record already exists; a 101 "Required field missing" tells it to fix the content before resending. The code is meant to be paired with a human-readable message in ERR-8 and a severity from HL70516 in ERR-4.

Because the table is HL7-defined and normative, receivers should choose the closest standard code rather than inventing local error numbers, so that cross-vendor error handling remains interoperable.

Where it's used

• ERR-3 HL7 Error Code — the modern home of HL70357, a CWE reporting the specific condition. (Legacy profiles placed the code in ERR-1.)
• MSA-1 Acknowledgment Code — the coarse accept/error/reject that the ERR segment elaborates on.
• Automated retry and remediation logic — engines branch on the HL70357 code to decide whether to retry, hold, or escalate.

Code list

Code system OID

• OID: 2.16.840.1.113883.18.217
• Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0357

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

HL7-defined vs user-defined

HL70357 is HL7-defined and normative. The code set above is the complete standard set — receivers should map their internal errors to the closest standard code rather than mint local numbers, so that senders across vendors interpret errors consistently. Additional site-specific detail belongs in the free-text ERR-8 (User Message) and ERR-7 (Diagnostic Information), not in new HL70357 codes.

Version differences

• v2.1 – v2.3 — Error reporting was informal; the coarse MSA-1 code plus free text in MSA-3 carried most of the signal.
• v2.3.1 — The dedicated ERR segment and HL70357 error-condition codes were formalized, with the 0, 1xx, and 2xx families defined.
• v2.4 – v2.5 — The ERR segment was substantially expanded; ERR-3 (HL7 Error Code, CWE) became the canonical location and the older ERR-1 usage was deprecated.
• v2.6 – v2.8.1 — Additional granular codes were added, including 198 (Non-Conformant Cardinality) and 199 (Other HL7 Error), rounding out the 1xx family.
• v2.9 — HL70357 largely stable; error semantics increasingly aligned with FHIR OperationOutcome for systems bridging to FHIR.

Common mistakes

• Putting the numeric code in ERR-1 on a modern profile. ERR-1 is the deprecated legacy location; ERR-3 (CWE) is the correct home from v2.5 onward.
• Returning AA in MSA-1 while also emitting a non-zero HL70357 code. If the application errored, MSA-1 should be AE/AR (see HL70008); a 101 alongside AA is contradictory.
• Overusing 207 "Application error" as a default. 207 is a catchall; when a more specific code (101, 103, 204) applies, use it so the sender can react automatically.
• Confusing 103 "Table value not found" with 102 "Data type error". 103 means the value was the right type but not in the referenced code table; 102 means the value was the wrong data type entirely.
• Treating 204 "Unknown key identifier" as retryable. A missing patient/order ID will not resolve on resend; the sender must correct the identifier.

Examples

An application-level error reporting a missing required field, paired with a severity from HL70516:

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

An unsupported-version rejection:

MSH|^~&|EHR|CLINIC|SENDING_APP|SENDING_FAC|20260701140500||ACK^A01^ACK|MSG20002|P|2.5
MSA|AR|MSG10001
ERR||MSH^1^12|203^Unsupported version id^HL70357|E

A table-value error — a code failed lookup against its bound table:

MSH|^~&|EHR|CLINIC|SENDING_APP|SENDING_FAC|20260701141000||ACK^A01^ACK|MSG20003|P|2.8.1
MSA|AE|MSG10002
ERR||PID^1^8|103^Table value not found^HL70357|W|||Value 'X' not in HL70001

A duplicate-key rejection on a new-patient message:

MSH|^~&|EHR|CLINIC|SENDING_APP|SENDING_FAC|20260701141500||ACK^A28^ACK|MSG20004|P|2.8.1
MSA|AR|MSG10003
ERR||PID^1^3|205^Duplicate key identifier^HL70357|E|||MRN 10456 already exists

FHIR mapping

There is no official ConceptMap published for HL70357 in the HL7 v2-to-FHIR Implementation Guide. Conceptually the codes flow into a FHIR OperationOutcome: the specific condition maps to OperationOutcome.issue.code (bound to the issue-type value set) and OperationOutcome.issue.details, while the severity from ERR-4 / HL70516 maps to OperationOutcome.issue.severity.

The mapping below is engine-defined (not normative) and shows the typical correspondence:

Because there is no normative ConceptMap, engines should preserve the original HL70357 code in an OperationOutcome.issue.details.coding entry (system http://terminology.hl7.org/CodeSystem/v2-0357) so the precise v2 condition survives the transformation.

Engine considerations

• Code-then-text pairing — Always emit the numeric HL70357 code in ERR-3 alongside human-readable text in ERR-8; automated senders branch on the code, humans read the text.
• Specificity over catchall — Prefer the most specific applicable code; reserve 207 for genuinely uncategorized internal failures.
• MSA/ERR consistency — Keep MSA-1 (HL70008) and the ERR HL70357 code coherent: a rejection code (2xx) should accompany AR, an error code (1xx) should accompany AE.
• Retry classification — Classify codes as retryable (206 record locked — retry after backoff) vs terminal (101, 203, 204, 205 — do not retry without correction).
• Legacy field awareness — Read both ERR-3 (modern) and ERR-1 (legacy) on inbound so errors from older senders are not missed.

How Vorro handles HL70357

Vorro emits HL70357 codes in ERR-3 whenever it rejects or errors on an inbound message, choosing the most specific applicable code: 203 for a version its channel does not support, 101/102/103 for content that fails profile validation, 205 for a duplicate key on a create, and 207 only when no specific code fits. Each ERR carries a matching severity from HL70516 in ERR-4 and a human-readable explanation in ERR-8.

On the inbound side, Vorro keys its retry and remediation logic on the HL70357 code returned by downstream systems: 206 drives exponential-backoff retry, 1xx content errors open a remediation ticket with the offending field captured, and 2xx rejections pause the outbound channel until an operator intervenes. When errors are surfaced to FHIR consumers, the original HL70357 code is preserved in the OperationOutcome.issue.details coding so downstream tooling can inspect the exact v2 condition.

Related pages

• ERR segment — Error
• MSA segment — Message Acknowledgment
• HL70516 code table — Error Severity

Sources

• HL7 Terminology — CodeSystem v2-0357 Message Error Condition Codes
• HL7 v2 product brief