UAC carries the authentication credential of the user or system that triggered a message. It exists so that simple transport protocols — MLLP especially — which have no built-in notion of "who is this user", can still convey an authentication token alongside the message itself. The credential is an opaque blob (a Kerberos service ticket, a SAML assertion, or similar), tagged with a code that says what kind of credential it is. UAC was introduced after v2.5.1; it is a v2.6+ segment and you will not find it in a strict 2.5.1 message structure. When present, it appears immediately after MSH (and after SFT, when SFT is also present), before the event and clinical content begins.
Purpose
UAC lets a sender attach proof of the triggering user's or system's identity to a message traveling over a protocol that cannot carry that proof on its own. The receiver uses the credential to look up or verify user identity before acting on the message. It is a security/envelope construct, not clinical data: UAC says who is asking, not what they are asking for. HL7 explicitly scopes UAC to protocols like MLLP that lack authentication semantics — implementations over WSDL/SOAP or similar are expected to use the authentication facilities of the transport instead of UAC.
Used in
UAC is optional. When used, it appears after MSH (and after SFT, if SFT is present) in v2.6+ messages where an authentication context must travel with the message. It is not tied to one message type; any message sent over an authentication-less transport may carry it. See the messages index for message structures; UAC, when present, sits in the envelope group right after the header.
Field-by-field reference
Source: HL7 v2.6+/2.8 standard UAC definition (v2+ segment definition). R = required (cardinality min ≥ 1). Repeat = field may repeat. No segment-level ConceptMap is published in the v2-to-FHIR IG for UAC. Length is not reproduced here (—).
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| UAC-1 | User Authentication Credential Type Code | CWE | — | R | — | HL70615 | Identifier code for the type of credential carried in UAC-2 (e.g. a Kerberos service ticket or a SAML assertion). |
| UAC-2 | User Authentication Credential | ED | — | R | — | — | The credential itself — opaque encapsulated data supplied by the sender's operating platform. Its internal structure is defined by the external authentication standard (Kerberos, SAML, etc.), not by HL7. |
Both fields are required when the segment is present. The HL70615 table reference for UAC-1 is well-established in the standard; treat any other table assignment as a local extension.
Most-used fields
There are only two fields, and both are mandatory, so neither is "optional" in practice. UAC-1 is the discriminator: the receiver reads it to know how to interpret UAC-2. UAC-2 is the payload — a base64-or-binary credential whose meaning is entirely external to HL7. Because UAC-2 is encapsulated data (ED), it can name an encoding and may itself reference an external source; receivers should be prepared for both inline and by-reference forms.
Version differences (2.3 to 2.8.2)
- 2.3 / 2.3.1 / 2.4 / 2.5 / 2.5.1: UAC does not exist. There is no User Authentication Credential segment in these releases; authentication, where needed, was handled out-of-band or in MSH-8 (Security), which is free text and rarely used.
- ~2.6: UAC introduced as a new control/envelope segment, with UAC-1 (CWE, HL70615) and UAC-2 (ED), to give MLLP and similar transports a way to carry a user/system credential.
- 2.7 / 2.7.1 / 2.8 / 2.8.x: UAC carried forward essentially unchanged — two required fields, same data types and table.
Because UAC is a v2.6+ segment, a receiver built strictly to 2.5.1 will not recognize it and should ignore it as a trailing/unknown segment rather than fail. The frontmatter on this page pins version: 2.5.1 for catalog consistency with the rest of this reference set, but UAC itself is only defined from v2.6 onward.
Common mistakes
- Expecting UAC in a 2.5.1 (or earlier) message — it does not exist before v2.6.
- Using UAC over a transport that already authenticates (WSDL/SOAP, mutual-TLS web services). HL7 scopes UAC to protocols without authentication semantics; doubling up is unnecessary and can confuse receivers.
- Treating UAC-2 as parseable HL7 content. It is opaque encapsulated data; do not try to split it on
^or~as if it were normal field structure. - Logging or persisting UAC-2 in the clear. It is a live credential (ticket/assertion) and must be handled as a secret.
- Placing UAC before SFT or before MSH. UAC follows the header group: MSH, then SFT (if present), then UAC.
Examples
Minimal valid UAC (both required fields):
UAC|KERB^Kerberos Service Ticket^HL70615|^^^^^^Base64^^WY7s... (opaque ticket bytes)
Fully-populated UAC with a SAML assertion in UAC-2:
UAC|SAML^SAML Assertion^HL70615|TEXT^application/samlassertion+xml^^^^Base64^^PHNhbWw6QXNzZXJ0aW9u... (opaque assertion bytes)
Annotated breakdown of the minimal example:
UAC ← segment ID
KERB^Kerberos...^HL70615 ← UAC-1 Credential Type Code (CWE, table HL70615)
^^^^^^Base64^^WY7s... ← UAC-2 Credential (ED, opaque encapsulated data)
In-context after MSH (UAC immediately follows the header):
MSH|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609120000||ADT^A01^ADT_A01|MSG00001|P|2.6
UAC|KERB^Kerberos Service Ticket^HL70615|^^^^^^Base64^^WY7s... (opaque ticket bytes)
EVN|A01|20260609120000
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
In-context after MSH and SFT (UAC follows SFT when software identification is also sent):
MSH|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609131500||ORU^R01^ORU_R01|CTRL-9931|P|2.7
SFT|Vorro^L|3.2.0|Interface Engine|build-20260601||20260601
UAC|SAML^SAML Assertion^HL70615|TEXT^application/samlassertion+xml^^^^Base64^^PHNhbWw6QXNzZXJ0aW9u...
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
OBR|1||ORD123|CBC^Complete Blood Count^L
FHIR mapping
Target: Not mapped at the segment level. No segment-level ConceptMap is published in the v2-to-FHIR IG for UAC — it does not appear in the IG's segment maps index.
Conceptually, UAC carries a security/authentication context rather than clinical content. Where a downstream FHIR representation needs it, the natural home is the security and provenance layer — for example a FHIR AuditEvent describing the authenticated agent, or Provenance.agent on the resources derived from the message. The opaque credential in UAC-2 generally is not surfaced as a stored FHIR element; it is consumed at the trust boundary (verified, then discarded), and only the resolved identity carries forward. Any mapping is therefore implementation-specific, not standard.
Engine considerations
- Recognize UAC only for v2.6+ feeds; for 2.5.1-and-earlier configurations it should never be emitted, and an inbound UAC on such a feed is an anomaly worth flagging.
- Verify before trust: UAC-2 must be validated against the relevant authority (KDC for Kerberos, IdP/signature check for SAML) before any message content is acted upon. A syntactically valid UAC is not an authenticated message.
- Treat UAC-2 as a secret. Redact it from logs, audit trails, and persisted message copies; the credential is short-lived and sensitive.
- Do not parse UAC-2 as HL7 structure. It is ED — read the encoding/type components of the ED, then hand the body to the appropriate security library untouched.
- Failure mode: an engine that re-emits a stored message including a stale UAC-2 can replay an expired or invalid credential. Strip or refresh UAC on store-and-forward.
How Vorro parses and produces UAC
On inbound, Vorro recognizes UAC in the header group of v2.6+ channels, reads UAC-1 to select the credential validator, and hands UAC-2 to that validator at the trust boundary — the raw credential is never written to channel logs. The resolved identity, not the credential, is what flows into downstream routing and audit. On produce, Vorro only emits UAC on channels explicitly configured for an authentication-less transport that requires it; it sets UAC-1 to the configured credential type code (HL70615) and populates UAC-2 from the platform-issued token at send time, so a replayed or stored message never carries a stale credential.
Related pages
- MSH — the message header UAC follows; UAC sits in the envelope right after it.
- SFT — software identification that, when present, precedes UAC in the header group.
- ARV — access restriction segment, the other security-flavored control segment in modern v2.
Sources
- HL7 v2-to-FHIR IG — segment maps index (UAC is not listed; no segment-level ConceptMap exists)
- HL7 v2+ UAC segment definition
- HL7 Version 2.8 product brief </content>
