Vaccine Exemptions and Deferrals

In brief

Many jurisdictions let a parent or guardian claim a formal exemption from vaccines that a school or childcare program requires. Immunization information systems (IIS) increasingly hold those exemptions, and schools, providers, and other systems want to exchange them through the HL7 v2 interfaces they already use. National HL7 v2 immunization guidance does not say how, and does not distinguish an exemption from a refusal or a clinical contraindication.

This document sets out a technical template for communicating exemptions, parts of which are implemented in at least one IIS, and frames the rest of the topic: submitting exemptions in unsolicited updates (VXU), defining deferrals, and moving toward formal standards.

What this project covers

• Definitions that separate exemptions, deferrals, refusals, contraindications, and other reasons a vaccine is not given.
• The use cases and actors that need exemption or deferral information exchanged.
• A transport-independent information model for exemption state.
• A query and response pattern for exemptions.
• The questions a VXU design must answer, and a path to formal standards.

What this project does not cover

This document defines how exemption information is communicated. It does not define:

• who qualifies for an exemption, which exemption types a jurisdiction recognizes, or which vaccines a school requires;
• how an exemption is collected, validated, deduplicated, expired, or revoked;
• who may send or receive exemption information, or how exchanged information is used, disclosed, or protected, which are matters of IIS and jurisdictional policy; or
• any effect on immunization evaluation or forecasting, which belongs to a separate clinical decision support proposal.

A jurisdiction’s exemption process can therefore change without changing the message design, as long as its exemption types map to the shared vocabulary. This document is not an HL7 implementation guide or conformance profile.

Related work

Concepts

An IIS can hold several kinds of statement about a vaccine that was not given. In HL7 v2 they share the non-administration form, but they mean different things and must not be used to carry one another.

Terminology cautions

• A medical exemption is a formal exemption with a medical basis. It is still an administrative status, separate from any clinical contraindication record, even when the same condition underlies both. Its LOINC answer is labeled “Medical contraindication”; prose and displays should say “medical exemption.”
• For personal-belief exemptions, “Philosophical objection” is preferred over “Parent/patient refusal” so the exemption is not read as a refusal.
• Jurisdictions use different names for the same exemption types, so display names should be agreed separately from codes.

Deferrals

“Deferrals” are in this topic’s name, but no one has yet said what a deferral is or which use cases need one exchanged. This document does not fit deferrals into the exemption structure until these are answered (OQ-1):

• Is a deferral a temporary clinical delay, an administrative delay (such as a grace period for school entry), a forecast recommendation, or something else?
• Does it apply to a vaccine category, a dose, a series, or a period of time?
• What creates, updates, ends, or supersedes one?
• How does it differ from a contraindication, precaution, refusal, or forecast status?
• Which use cases need an IIS to receive a deferral, return one, or both?

Actors

Parents and guardians claim exemptions but do not take part in the HL7 exchange.

Use cases

The first use cases are kindergarten through grade 12 school requirements, where a school reviewing compliance needs to know whether a student holds an exemption, its type, and the vaccine categories it covers.

Structure

A person has zero or more exemption items. Each item states that one vaccine category is exempted, with a type and a filing date. One exemption form usually produces several items. The type may differ from item to item, even where a jurisdiction’s own process applies one type to every vaccine selected.

A response may instead state that no exemptions are documented as of a date. That statement is itself exemption information.

Data elements

Every element should have an operational reason to exist. Elements were left out of the query design because no consumer needed them, not because they were judged unimportant.

Current-state semantics

A query response is a snapshot of the IIS’s current exemption state, with no history or lifecycle events. An exemption that has ended is simply absent from later responses, and consumers query again to see changes. The IIS manages expiration and revocation in its own process, for example through grade-based rules or later vaccination. Unsolicited updates need more; see Unsolicited updates.

Vocabulary

Exemption type uses answers from LL4353-0, the example answer list for LOINC 100282-3. The list covers reasons a vaccine was not given generally; only these are used:

LA27167-8 (Parent/Patient refusal) is in the list but is not used for exemptions. Whether these LOINC codes are the best fit is open (OQ-4).

Exempted vaccine category uses CVX, preferring “unspecified formulation” codes or the code that represents a CDC vaccine group, because an exemption covers a category, not a product. CVX is not a disease-group vocabulary: MMR and varicella, for example, have no “unspecified” code. A disease-group vocabulary could replace this later without changing the rest of the model (OQ-3).

Requested explicitly

Exemption content is returned only when the query explicitly asks for it. Whether the IIS returns it to a particular requester is IIS policy, outside this document; the exchange only signals that exemptions were requested and whether they are included (OQ-8).

Existing querying systems do not expect exemptions, and most people have none, so adding exemption content (or “none” statements) to every response would add size and processing for no benefit. Returning exemptions based only on the requester’s settings in the IIS was considered and set aside, so that a querying system always knows exemptions may be present.

Requesting exemptions

The request adds an exemption profile in repeating MSH-21, alone or with an existing query profile:

Order of the repeated values carries no meaning. Only listed combinations are valid (OQ-7). Z34 and Z44 keep their current meanings.

At least one implementation uses Z99^CDCPHINVS, assigned locally, as its request profile. A complete design needs a pair: a query profile meaning “exemption content is requested” and a response profile meaning “exemption content is included,” so the response’s MSH-21 repeats as well (for example Z42 with the exemption response profile). No national pair has been agreed (OQ-5). Whether QPD-1 also carries the combined intent is open (OQ-6).

Example: evaluated history and forecast plus exemptions, with QPD-1 carrying the primary intent only. Identifiers and demographics are illustrative.

MSH|^~\&|SCHOOLSYS|SCHOOL01|IIS|IIS01|20260115093000-0700||QBP^Q11^QBP_Q11|Q0001|T|2.5.1|||ER|AL|||||Z44^CDCPHINVS~Z99^CDCPHINVS
QPD|Z44^Request Evaluated History and Forecast^CDCPHINVS|Q0001|STU1001^^^SCHOOL01^MR|Example^Pat^^^^^L||20190601|F
RCP|I|1^RD&records&HL70126

Response order group

Exemptions go in one dedicated ORC/RXA[/RXR]/OBX... order group, however many vaccine categories are exempted, as long as all items share the same administrative context. In an evaluated-history response it sits with the other non-administration groups, after immunization history and before forecast.

The ORC and RXA follow the pattern already used for contraindications and history of disease:

RXR may appear where the structure calls for it and adds no meaning. NK1 may be returned under the underlying query profile to help confirm a match. NTE is optional; omit it without a defined need.

Paired observations

Each exemption item is two OBX segments sharing an OBX-4 sub-ID:

Example: two religious exemption items, for hepatitis A and DTaP. In a complete response, OBX-1 continues the numbering of earlier groups.

ORC|RE||9999^IIS
RXA|0|1|20260115||998^No Vaccination Administered^CVX|999||||||||||||||NA
OBX|1|CE|100282-3^Vaccine exemption certificate^LN|1|LA27171-0^Religious exemption^LN||||||F|||20250901
OBX|2|CE|30956-7^Vaccine type^LN|1|85^HepA Unspecified^CVX||||||F
OBX|3|CE|100282-3^Vaccine exemption certificate^LN|2|LA27171-0^Religious exemption^LN||||||F|||20250901
OBX|4|CE|30956-7^Vaccine type^LN|2|107^DTaP Unspecified^CVX||||||F

No exemptions documented

When exemptions were requested and are being returned but none are on file, the IIS may send the order group with a single exemption-type observation whose value is LA137-2^None^LN and whose OBX-14 is the response date. The ORC and RXA are still required. When exemption content is not being returned, send no exemption group at all.

OBX|1|CE|100282-3^Vaccine exemption certificate^LN|1|LA137-2^None^LN||||||F|||20260115

Unsolicited updates

Exemptions could also be submitted to an IIS in VXU messages. A VXU should carry the same payload as a response: the order group and paired observations.

The query mechanism does not transfer. A response is a snapshot the IIS builds from its own data; a VXU tells a receiver about something it may already hold. A VXU design must therefore decide:

• whether a message reports one event or the sender’s complete current set (OQ-11);
• what identifies an exemption so it can be replaced, revoked, or deleted (OQ-12);
• whether a sender may assert “none,” which could erase exemptions from another source (OQ-13); and
• provenance and acknowledgement behavior (OQ-14).

Candidate artifacts

This Topic Reference is the shared starting point. Formal artifacts will be separate and will cite it.

The sponsoring body and publication path are open (OQ-15).

Validation

• Experience from existing implementations is the first test of the query design and is recorded as review input.
• Other IIS should review the design before profiles are assigned, so the identifiers do not collide with local profiles.
• Message examples should be validated against national conformance tools once profiles exist.

Steps

1. Review definitions, scope, and use cases with the community.
2. Confirm the explicit request and payload as the common design, or record objections.
3. Gather requirements from IIS and submitters interested in VXU.
4. Agree on a definition of deferral, or narrow the topic.
5. Choose a sponsoring body and prepare the first formal proposal.

Working decisions

Open questions

Each question needs discussion before the affected text is settled. Questions that belong to a related topic are referred there rather than answered here.