HL7 Table HL70177: Confidentiality Code

HL70177 flags how sensitive a patient's record is and what handling rules apply downstream. It is the v2 ancestor of FHIR's Resource.meta.security and _security Coding tags. The table lives in PV2-22 Visit Protection Indicator (and in some profiles on master-file and scheduling segments), and uses the IS data type. Values come in two flavors: general protection levels (U, R, V) and sensitive-category flags (AID, HIV, PSY, ETH, VIP).

Purpose

HL70177 answers: who is allowed to see this record, and under what handling rules? An R (Restricted) flag tells the EHR to suppress the record from the default view and require an explicit access reason. A VIP flag tells the registration desk to escalate any release-of-information request to compliance. A HIV flag invokes the heightened federal and state protections that apply to HIV-related care — protections that, in many US jurisdictions, require explicit patient consent for release that is more granular than ordinary PHI.

The two halves of the table answer different questions. U/R/V answer "what level of protection applies"; AID/HIV/PSY/ETH/VIP/UWV/EMP answer "what sensitive category triggered the protection." Real-world implementations frequently combine them (a record might be tagged both R and HIV) by repeating the field.

Where it's used

• PV2-22 Visit Protection Indicator — a common home in US ADT profiles.
• PD1-12 Protection Indicator (in some profiles) where the protection is patient-level rather than visit-level.
• SCH-25 Schedule Confidentiality (master-file scheduling profiles).
• MFE master-file messages that need to flag a record's protection level for downstream replication.

Code list

Code system OID

• OID: 2.16.840.1.113883.18.82
• Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0177

The OID resolves on the HL7 Terminology server. Sites that extend HL70177 with local categories (GENETIC, DOMESTIC, MINOR) should issue a local OID under their institution root.

HL7-defined vs user-defined

HL70177 is user-defined. The codes above are HL7-suggested values; sites routinely extend the table to reflect their own sensitivity policies (genetic testing, intimate-partner violence, minor consent). Receivers must accept local codes under trading-partner agreements.

That said, the general-protection-level codes (U, R, V) are widely treated as de-facto normative because they align directly with the FHIR confidentiality ValueSet — sites that need to interoperate via FHIR effectively must use them.

Version differences

• v2.2 — Table introduced with R, V, AID, ETH, HIV, PSY, UWV, EMP.
• v2.3 — U (Usual control) added as the explicit "no restriction" code.
• v2.4 — VIP added to capture high-profile-patient handling distinct from clinical sensitivity.
• v2.5 – v2.8.1 — Set stable; user-defined extensions vary by site.

Common mistakes

• Defaulting empty PV2-22 to U on ingest. An empty field means "not asserted"; substituting U silently asserts that no restriction applies, which is the opposite of safe-default behavior.
• Treating VIP as a clinical sensitivity. VIP is an administrative flag about who the person is, not what their record contains; it should not drive 42 CFR Part 2 or state-law protections.
• Conflating R and V. R (Restricted) is the standard suppression level; V (Very restricted) implies explicit authorization for every access. A receiver that treats them identically loses the difference.
• Sending sensitive-category codes (HIV, ETH, AID) without also sending a protection level (R or V). The category says what kind of data; the level says how to handle it. Both are typically needed.
• Extending HL70177 locally without publishing the mapping to receivers. A site-specific GENETIC flag that doesn't reach the downstream FHIR consumer either leaks the data or blocks legitimate access.

Examples

A standard ADT with no restriction:

PV2|||^Routine checkup||||||||||||||||||||U

A restricted record flagged for HIV sensitivity (repeating field):

PV2|||^Follow-up||||||||||||||||||||R~HIV

A VIP patient:

PV2|||^Annual physical||||||||||||||||||||VIP

Same R~HIV translated to FHIR security labels on the Patient (or Encounter) resource:

{
  "resourceType": "Encounter",
  "id": "vis-99821",
  "meta": {
    "security": [
      { "system": "http://terminology.hl7.org/CodeSystem/v3-Confidentiality", "code": "R", "display": "restricted" },
      { "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code": "HIV", "display": "HIV related information sensitivity" }
    ]
  }
}

Mapping failure example — unknown vendor code:

PV2|||^Visit||||||||||||||||||||SECRET

SECRET is not in HL70177 and has no trading-partner agreement. A conformant engine must route the message to a curation queue and, critically, must not default to U (Usual control) on the downstream — the safe failure mode is to preserve the unknown flag and treat the record as restricted until the operator resolves the mapping.

FHIR mapping

The HL7 v2-to-FHIR Implementation Guide publishes ConceptMap-table-hl70177-to-v3-confidentiality, which maps the general-protection-level codes to the FHIR confidentiality ValueSet (which is the v3 Confidentiality code system: N, R, V) and the sensitive-category codes to the v3 ActCode system as separate security labels:

In FHIR, security labels live on Resource.meta.security and apply to the resource as a whole; multiple labels coexist on a single resource.

Engine considerations

• Repeating field handling — PV2-22 repeats; engines must split on ~ and treat each repetition independently.
• Safe-default policy — Unknown HL70177 values must default to the restrictive side (treat as R), never to U. The default-to-open failure mode causes data leaks.
• Two-axis modeling — Engines should preserve both the protection-level axis (U/R/V) and the sensitive-category axis (HIV/ETH/PSY/etc.) on the FHIR side as separate security labels, not collapse them.
• CWE upgrade path — In v2.7+ profiles the field may be transmitted as CWE with OID metadata in CWE.14 (2.16.840.1.113883.18.82).
• Audit obligations — Every change to a HL70177 value is itself sensitive; engines should emit an audit event whenever a confidentiality flag is added, removed, or downgraded.

How Vorro handles HL70177

Vorro validates PV2-22 (and the equivalent PD1-12 and SCH-25 fields) against the HL70177 suggested codes plus each trading partner's registered local extensions. Unknown values are routed to the terminology curation queue and the record is treated as R (Restricted) downstream until the operator resolves the mapping — the safe-default policy is non-negotiable. Valid values are emitted as FHIR Resource.meta.security labels with both the protection-level Coding (v3 Confidentiality) and, where applicable, the sensitive-category Coding (v3 ActCode) preserved as separate entries.

On outbound, Vorro emits HL70177 as IS for v2.5 and earlier profiles and as CWE with CWE.14 populated for v2.7+ destinations. Every change to a confidentiality flag — whether on ingest, transformation, or outbound — emits a dedicated audit event so compliance can reconstruct the chain of custody for sensitive records.

Related pages

• PV2 segment — Patient Visit Additional Info
• HL70125 code table — Value Type
• IS data type — Coded Value for User-defined Tables

Sources

• HL7 Terminology — CodeSystem v2-0177 Confidentiality Code
• HL7 v2 product brief
• HL7 v2-to-FHIR IG — ConceptMap HL70177 to confidentiality