HL7 Table HL70215: Publicity Code

HL70215 is the HL7 v2 mechanism for carrying a patient's preference about reminder and recall communications — the appointment nudges, immunization recalls, and screening reminders that registries and EHRs send to patients between visits. It rides on PD1-11 Publicity Code in the Patient Additional Demographics segment and has thirteen values that combine two axes: which kinds of notifications the patient permits (reminders, recalls, both, neither) and which channels are allowed (any, no calls, mail-only, phone-only).

Purpose

HL70215 lets a patient (or their proxy) constrain outbound communications without forcing the EHR to maintain a free-text preference field. The two-axis structure means a single code can carry both "what to send" and "how to send it." A code of 08 says "send both reminders and recalls, but only by mail" — no phone, no email, no SMS. A code of 01 is a complete opt-out from reminder/recall traffic.

Because the table is HL7-defined and widely used by public-health immunization registries (notably the CDC's HL7 v2.5.1 immunization implementation guide), conformant senders must use the two-digit codes exactly and must not invent local extensions like 00 or 99.

Where it's used

PD1-11 Publicity Code — the canonical home of HL70215, populated on ADT messages and on VXU (immunization update) messages going to public-health registries.
Some IIS (Immunization Information System) profiles repeat the publicity preference on a custom Z-segment for backwards compatibility; the underlying value set is still HL70215.

Code list

Code	Display	Comment/Description
01	No reminder/recall	Patient declines all reminder and recall notifications.
02	Reminder/recall — any method	Reminders and recalls allowed via any channel.
03	Reminder/recall — no calls	Reminders and recalls allowed via any channel except telephone.
04	Reminder only — any method	Only reminders (forward-looking nudges) allowed; recalls are suppressed.
05	Reminder only — no calls	Reminders allowed via any channel except telephone; recalls suppressed.
06	Recall only — any method	Only recalls (backward-looking "you missed this") allowed; reminders suppressed.
07	Recall only — no calls	Recalls allowed via any channel except telephone; reminders suppressed.
08	Reminder/recall — only by mail	Both allowed, postal mail only.
09	Reminder/recall — only by phone	Both allowed, telephone only.
10	Reminder only — only by mail	Reminders by postal mail only; recalls suppressed.
11	Reminder only — only by phone	Reminders by telephone only; recalls suppressed.
12	Recall only — only by mail	Recalls by postal mail only; reminders suppressed.
13	Recall only — only by phone	Recalls by telephone only; reminders suppressed.

Code system OID

OID: 2.16.840.1.113883.18.90
Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0215

The OID resolves on the HL7 Terminology server and is the value Vorro emits in CWE.14 when a downstream profile (such as a state immunization registry) demands OID-bound coded values.

HL7-defined vs user-defined

HL70215 is HL7-defined. The two-digit code range 01–13 is normative, and conformant receivers must accept all thirteen values. Sites occasionally see locally extended codes like 00 ("no preference recorded") or 14 ("email-only"); those are non-conformant. Email and SMS preferences are typically carried on a separate consent or communication-preference structure rather than by extending HL70215.

Version differences

v2.3.1 — HL70215 introduced for early immunization-registry interoperability.
v2.4 — Codes 08–13 added to cover channel-specific preferences (mail-only, phone-only).
v2.5 – v2.5.1 — Set frozen at thirteen codes. CDC's v2.5.1 immunization IG cemented the table as the de-facto consent vocabulary for IIS submissions.
v2.6 – v2.8.1 — No further additions. SMS, email, and patient-portal channels are intentionally left to richer Consent structures.

Common mistakes

Sending 0 instead of 01. HL70215 codes are zero-padded two-digit strings; a single 1 is not a valid code.
Treating absence of PD1-11 as opt-out. An empty PD1-11 means "no preference recorded," not 01. Engines that default missing values to 01 silently revoke consent.
Picking 02 as a generic default. Some IIS receivers treat 02 as explicit consent for any channel; senders should only emit 02 when the patient actually granted that permission.
Inventing 14 for email or 15 for SMS. HL70215 predates modern channels by design. Email/SMS preferences belong in Consent.provision or a Patient.telecom rank, not in HL70215.
Mapping 03 to "do not contact." 03 permits reminders and recalls by any non-phone channel — mail, email, portal — and is not an opt-out.

Examples

A PD1 with the patient declining all reminder/recall traffic:

PD1|||||||||||01^No reminder/recall^HL70215

A patient who accepts reminders only, by mail:

PD1|||||||||||10^Reminder only - only by mail^HL70215

A VXU header carrying immunization-registry publicity preference:

MSH|^~&|EHR|CLINIC|IIS|STATE|20260601120000||VXU^V04^VXU_V04|MSG00042|P|2.5.1
PID|1||10456^^^MRN^MR||DOE^JANE||19850412|F
PD1|||||||||||08^Reminder/recall - only by mail^HL70215

Translated to a FHIR Patient with a Consent reference:

{
  "resourceType": "Patient",
  "id": "10456",
  "extension": [{
    "url": "http://example.org/StructureDefinition/publicity-code",
    "valueCoding": {
      "system": "http://terminology.hl7.org/CodeSystem/v2-0215",
      "code": "08",
      "display": "Reminder/recall - only by mail"
    }
  }]
}

Because there is no first-class FHIR ValueSet, the HL70215 code is best preserved as an extension Coding so the original two-digit value survives downstream.

FHIR mapping

The HL7 v2-to-FHIR IG does not publish a direct ConceptMap for HL70215 because the concept cuts across two FHIR resources: Patient (communication preferences) and Consent (opt-out / channel restrictions). Implementers typically pick one of two strategies:

Extension on Patient — carry the HL70215 code on a project-defined extension; lossless but non-standard.
Consent resource — translate each HL70215 code into a Consent.provision that names the permitted action (reminder, recall) and channel (mail, phone). Higher fidelity for downstream systems that already consume Consent.

Either way, the original two-digit code should be preserved so an outbound v2 channel can reconstruct PD1-11 exactly.

Engine considerations

Zero-padded codes — 1 and 01 are different strings. Engines should normalize on ingest and emit zero-padded codes outbound.
Default semantics — Empty PD1-11 ≠ 01. Engines must distinguish "no preference recorded" from "patient declines" to avoid silently revoking consent.
Channel logic at the edges — HL70215 says what the patient permits, but the actual reminder dispatcher must enforce it. Engines should expose the parsed channel/action axes (reminder vs recall, mail vs phone) so downstream systems do not re-implement the table.
CWE upgrade path — In v2.7+ profiles PD1-11 is CWE; CWE.14 carries the OID 2.16.840.1.113883.18.90. Engines must handle both pre- and post-v2.7 shapes.

How Vorro handles HL70215

Vorro validates PD1-11 against the thirteen HL70215 codes on ingest. Values that match are forwarded to all downstream channels untouched. Single-digit variants (1 rather than 01) are auto-normalized to zero-padded form with a soft warning. Unknown codes — 00, 14, vendor-specific extensions — are routed to the terminology curation queue rather than silently dropped, because misinterpreting a publicity code can violate patient consent.

On outbound, Vorro emits HL70215 as CE for v2.5 and earlier profiles and as CWE with CWE.14 populated for v2.7+ destinations. When converting to FHIR, Vorro emits a Consent resource whose provision decomposes the HL70215 code into action and channel axes, and additionally preserves the raw HL70215 Coding on a Patient extension so the v2 outbound channel can reconstruct PD1-11 byte-for-byte.

Sources

← Back to HL7 v2 Guide