HL7 ARV Segment: Access Restriction

ARV carries access restrictions — the privacy and confidentiality flags that say a record or part of a record is sensitive and should not be shown to everyone. It declares restrictions that differ from the overall security level set on the Message Header: think VIP patients, employee records, behavioral-health or substance-use data, or anything an opt-out consent directive protects. ARV is a v2.6-and-later segment. It was introduced around v2.6 to replace the older practice of overloading PD1 (Patient Additional Demographic) restriction fields, and it can repeat so a message can express different restrictions on different elements. The frontmatter keeps version: "2.5.1" for consistency with the rest of this reference set, but ARV itself does not exist in 2.5.1 — see Version differences below.

Purpose

ARV tells the receiver that access to specific information is restricted by jurisdictional, organizational, patient-privacy, or legal policy. It names the action being taken on the restriction, the restriction value (the governing policy or consent code), the reason (the kind of sensitive information), any free-text handling instructions, and the date range over which the restriction applies.

Used in

ARV appears in patient-context messages where privacy flags apply — most commonly ADT (admit/discharge/transfer), and other patient- or order-scoped messages that carry confidentiality restrictions. In ADT it follows the patient-identifying segments (after PID, and after PD1/PV1 when present). See ADT messages and the messages index for context.

Field-by-field reference

Source: HL7 v2.6+/2.8 standard ARV definition (see Caristix ARV v2.8). R = required (cardinality min ≥ 1). Repeat = field may repeat. Lengths are not pinned here. ARV is a v2.6+ segment; it is not part of v2.5.1.

Most-used fields

ARV-3 Access Restriction Value is the field that matters. It carries a single code (from table HL70717) for the policy governing access — this is where an opt-in or opt-out consent directive is expressed. If a downstream system reads only one ARV field, it reads ARV-3.

ARV-4 Access Restriction Reason explains the sensitivity behind the restriction (for example, the type of sensitive information being protected) using codes from HL70719. It can repeat when more than one reason applies.

ARV-6 Access Restriction Date Range scopes the restriction in time, which matters when a restriction is temporary (for example, a sealed record that expires).

Version differences (2.3 to 2.8.2)

• 2.3 / 2.4 / 2.5 / 2.5.1: ARV does not exist. Access/confidentiality restrictions were carried on other segments — notably PD1 (Patient Additional Demographic) restriction fields and the PID confidentiality-related fields.
• ~2.6: ARV introduced as a dedicated Access Restriction segment, superseding the older PD1 restriction-field practice. The PD1 fields were deprecated in favor of ARV.
• 2.7 / 2.8 / 2.8.2: ARV refined; the CWE security-label fields (ARV-2 through ARV-4) align with HL7 security-label and information-sensitivity vocabularies. ARV is positioned to repeat and, in later versions, to sit immediately after MSH so message-level restrictions can be declared. Receivers built for 2.3–2.5.1 will not recognize ARV and should ignore it rather than fail.

Common mistakes

• Assuming ARV exists in 2.5.1. It is a v2.6+ segment; sending it to a 2.5.1-only receiver means it will be dropped or rejected.
• Continuing to use PD1 restriction fields and ARV at the same time, producing conflicting or duplicated restrictions.
• Treating ARV-3 as free text. It is CWE and should carry a coded value from HL70717; free text belongs in ARV-5.
• Ignoring repetition — ARV can repeat, and ARV-4 can repeat within an ARV, so a single read of the first value can miss restrictions.
• Dropping ARV silently on the receiving side, which removes a privacy flag the sender intended to enforce.

Examples

Minimal ARV (a single opt-out style restriction value):

ARV|1|A|R^Restricted^HL70717

Fully-populated ARV:

ARV|1|A|R^Restricted^HL70717|PSY^Psychiatry sensitivity^HL70719|Release only to attending psychiatrist|20260101000000^20261231235959

Annotated breakdown of the fully-populated example:

ARV                                  ← segment ID
1                                    ← ARV-1  Set ID
A                                    ← ARV-2  Access Restriction Action Code (e.g. Add)
R^Restricted^HL70717                 ← ARV-3  Access Restriction Value (governing policy)
PSY^Psychiatry sensitivity^HL70719   ← ARV-4  Access Restriction Reason
Release only to attending...         ← ARV-5  Special Access Restriction Instructions
20260101000000^20261231235959        ← ARV-6  Access Restriction Date Range (start^end)

In-context inside an ADT^A01 (admit), ARV after PID:

MSH|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609120000||ADT^A01^ADT_A01|MSG00001|P|2.8.2
EVN|A01|20260609120000
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
ARV|1|A|V^VIP^HL70717|VIP^Very important person^HL70719|Limit chart access to care team
PV1|1|I|ICU^101^A|||||||MED

In-context inside an ADT^A08 (update), ARV after PID and PV1:

MSH|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609131500||ADT^A08^ADT_A01|MSG00042|P|2.8.2
EVN|A08|20260609131500
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
PV1|1|I|ICU^101^A|||||||MED
ARV|1|U|R^Restricted^HL70717|ETH^Substance use sensitivity^HL70719|Sealed per consent directive|20260609000000

FHIR mapping

Target: the v2-to-FHIR IG does not publish a supported segment-level ConceptMap for ARV. Security concepts from ARV map to Resource.meta.security (security labels) on the relevant resource, and the restriction relates conceptually to the Consent resource.

Mapping caveat: because many distinct ARV concepts map onto Resource.meta.security, which is allowed to repeat, the labels can land in the same element without a clear indicator of which concept each represents (beyond its code system). The mapping is still in development in the IG, owned by the Security Working Group with FHIR-I. Treat the FHIR target as conceptual rather than a settled, supported map.

Engine considerations

• ARV is version-gated. Only emit it on channels negotiated at v2.6 or later; for v2.5.1-or-earlier partners, carry restrictions the legacy way (PD1) or strip ARV.
• Handle repetition: iterate every ARV occurrence and every ARV-4 repetition; do not read only the first.
• Preserve coded values. ARV-2/3/4 are CWE — keep code, text, and coding system intact rather than flattening to a display string.
• Failure mode: silently dropping ARV removes a privacy flag. Make non-passthrough of ARV an explicit, logged decision, not an accident of an old parse profile.
• On round-trips, do not double-encode restrictions in both PD1 and ARV.

How Vorro parses and produces ARV

Vorro parses ARV only when the channel's negotiated HL7 version supports it (v2.6+), reads every ARV repetition, and keeps ARV-2/3/4 as coded CWE values so the governing policy (ARV-3) and sensitivity reason (ARV-4) survive transformation. On the produce side, Vorro places ARV after the patient-identifying segments (after PID, and after PD1/PV1 in ADT), populates ARV-3 from the configured access-restriction value set, and — for partners that predate ARV — either maps the restriction back onto PD1 or drops ARV with an explicit, logged rule so a privacy flag is never lost by accident.

Related pages

• PID — the patient-identification segment ARV restricts.
• PD1 — the older segment whose restriction fields ARV supersedes.
• ADT messages — where ARV most commonly appears, after PID/PV1.

Sources

• HL7 v2-to-FHIR IG — segment maps index
• Caristix — ARV Access Restriction Segment (HL7 v2.8)