HealthCare

1. How has the IT industry solved the interoperability problem for transferring healthcare data between different devices? Give at least two solutions that have been tried and discuss their positive and negative attributes.

Don't use plagiarized sources. Get Your Custom Essay on

HealthCare

Just from $13/Page

Order Essay

2. Describe (primarily in your own words) the structure of an HL7v2 patient admission message. Objective here is not copy/paste information, but to verify that you understand HL7v2.

The Healthcare Domino Effect in
Electronic Medical Records
By Erin Benson, director of Market Planning, LexisNexis; part of the HIE &
Interoperability Call to Action initiative, January 25, 2019

Have you ever started a simple home improvement project that snowballed
into several more complex projects? Your goal may have been to only paint
the kitchen, but then you discovered termites in the wall, a leak in the
plumbing and mold in the cabinets. That sound you heard of plinking tiles was
the domino effect kicking in.

A similar progression happened recently to a health system in Pennsylvania.
As the organization experienced growth, they sought ways to lower costs
while ensuring positive patient outcomes and quality measures that met
Medicare Access and CHIP Reauthorization Act requirements.

They launched a population health strategy to better understand and treat
their patients. What started as a relatively simple project brought to light
problems not uncommon to health systems, such as interoperability and
patient record linking. Those issues would need to be solved before the new
strategy could be implemented. The domino effect was suddenly in full force.

Mergers Create Redundant Records

In recent years, the Pennsylvania health system acquired more than 50
primary care and specialty practices, adding to its 300-bed hospital. It had
also merged the electronic health records (EHRs) from six different health
systems. In all, it had 1.3 million patient records but thousands of those were
likely multiple files for the same patient.

Bringing together these disparate records into a single data source had
created a quality problem with the data. And without data integrity, the health
system would be unable to properly manage the care of its patient population,
detect trends or make decisions regarding how to allocate resources.
However, manually linking and matching patient records and resolving
duplicates could literally take years.

Patient Safety at Risk

In addition to the population health initiative, several other critical factors
were compelling the Pennsylvania health system to take swift action in
resolving patient record issues:

 Patient Safety – Physicians needed to see complete records to correctly
diagnose and treat their patients. Duplicate or unmatched records could
mean a patient’s information was spread across multiple records.

 Future Mergers and Acquisitions – The health system expected to
continue growing by acquiring practices in its service area. With each
new addition, the patient-matching and duplicate records problem
would become more complex.

 Payment Reform – In the evolving value-based healthcare system,
claims reimbursement rates could potentially drop in favor of incentive
payments. Provider compensation would increasingly be tied to
performance and quality data instead of fee for service. The health
system wanted to use its own real-time data to be proactive in assessing
its performance. Without accurate patient records data, it would be
unable to make informed decisions to improve and reduce costs.

 Gain-Sharing Risk – The health system intended to increase its use of
gain-sharing contracts with physician practices. Performance data was
critical to its negotiations. It needed accurate counts for the number of
patients and the cost of their care in order to determine fair value.

Linking Patient Records

By automating the matching and linking of patient records, the health system
was able to efficiently resolve its data integrity problem by identifying
common patients among the converging EHRs and eliminate duplicate
records.

The health system also assigned each patient a unique identifier, which helps
mitigate the risk of exposing a patient’s personal information.

A Fast, Reliable Process Was Needed

In a matter of weeks, the Pennsylvania health system had whittled its 1.3
million records down to 740,000, which accurately reflected its patient
population.

It now had the ability to offer more efficient and safe care across its
continuum of services. And it had a repeatable process in place to scrub
massive patient datasets to merge or remove duplicate records if additional
practices were added to the system.

While the domino effect initiated by the system’s population health strategy
seemed to cause a chain reaction of difficult, new problems, in reality it had
brought to light important concerns related to data integrity. Resolving those
issues was critical to patient care and the future success of the health system.

Discover More About Interoperability at HIMSS19

HIMSS Interoperability Showcase™ |
Women in Interoperability |
Interoperability Education Sessions |

Whatis Interoperability?
The following proposed interoperability definition is now available for public

comment. Comment period runs until March 23, 2019.

Defining Interoperability in the Health Ecosystem
Interoperability is the ability of different information systems, devices or applications to
connect, in a coordinated manner, within and across organizational boundaries to
access, exchange and cooperatively use data amongst stakeholders, with the goal of
optimizing the health of individuals and populations.

Health data exchange architectures and standards allow relevant data to be shared
effectively and securely across the complete spectrum of care, within all applicable
settings and with relevant stakeholders (including with the person whose information is
being shared). Optimally, interoperability facilitates connections and integrations across
these systems to occur regardless of the data’s origin or destination or the applications
employed, and ensures the data are usable and readily available to share without
additional intervention by the end user.

In the health ecosystem, interoperability furthers the goal of optimizing health by
providing seamless access to the right information needed to more comprehensively
understand and address the health of individuals and populations.

Systems participating in information exchange do so with varying degrees of
interoperability. Each component, described below, demonstrates the types of exchange
organizations may engage in and such exchanges may occur simultaneously within a
single healthcare setting:

 “Foundational” interoperability develops the building blocks of information
exchange between disparate systems by establishing the inter-connectivity
requirements needed for one system or application to share data with and
receive data from another. It does not outline the ability for the receiving
information technology system to interpret the data without interventions from
the end user or other technologies.

 “Structural” interoperability defines the structure or format of data exchange
(i.e., the message format standards) where there is uniform movement of
healthcare data from one system to another such that the clinical or operational
purpose and meaning of the data is preserved and unaltered. Structural
interoperability defines the syntax of the data exchange. It ensures that data
exchanges between information technology systems can be interpreted at the
data field level.

 “Semantic” interoperability is the ability of two or more systems to exchange
information and to interpret and use that information. Semantic interoperability
takes advantage of both the structuring of the data exchange and the
codification of the data, including standard, publicly available vocabulary, so that
the receiving information management systems can interpret the data. Semantic
interoperability supports the electronic exchange of patient data and information
among authorized parties via potentially disparate health information and

technology systems and products to improve quality, costs, safety, efficiency,
experience and efficacy of healthcare delivery.

 “Organizational” interoperability encompasses the technical components as
well as clear policy, social and organizational components. These components
facilitate the secure, seamless and timely communication and use of data within
and between organizations and individuals. Inclusion of these non-technical
considerations enables interoperability that is integrated into end-user processes
and workflows in a manner that supports efficiencies, relationships and overall
health and wellness through cooperative use of shared data both across and
within organizational boundaries.

Access previous versions of the HIMSS definition. This proposed definition is now
available for public comment. Comment period runs until March 23, 2019.

October, 2017

economy are in part reliant on ensuring the right people have the right access to the right
health information at the right time. While we have made great strides over the past generation,
seamless, secure, nationwide interoperable health information exchange continues to elude us.

For many years, HIMSS and our valued collaborators have worked relentlessly on ensuring
individuals and organizations routinely use secure, trust-worthy, interoperable technologies and
work flows to promote wellness, as well as protect and improve the health status of patients and
populations. e
building blocks and putting them in-place, our work is not complete. HIMSS asserts that we
must achieve secure, appropriate, and ubiquitous data access and electronic exchange of
health information: Now is the time for bold action. HIMSS publishes this Call to Action, guiding
principles to inform health policy and spur health sector to action. We welcome all
who share our commitment to join us in achieving better health through the best use of
information and technology.

HIMSS calls on the Department of Health and Human Services and the broader health
information and technology community to demonstrate the following leadership:

1) Demand Integration between the Interoperability Approaches and Trusted Exchange

Frameworks for the Public Good;
2) Educate the Community to Appropriately Implement Existing and Emerging Standards, Data

Formats, and Use Cases to Ensure a Comprehensive, Integrated Approach to Care;
3) Ensure Stakeholder Participation from Across the Care Continuum, Including Patients and

Caregivers;
4)

Coordination;
5) Standardize and Adopt Identity Management Approaches; and,
6) Improve Usability for Data Use to Support Direct Care and Research.

Note: The order of these six themes does not reflect any prioritization regarding their role in
achieving the goals outlined in this Call. HIMSS believes efforts to address these themes should
occur concurrently to achieve seamless, secure, interoperable health information exchange.

1) Demand Integration between the Interoperability Approaches and Trusted
Exchange Frameworks for the Public Good

HIMSS Call to Action: HIMSS strongly encourages HHS to demand integration between the
interoperability approaches and trusted exchange frameworks with the objective of achieving
semantic interoperability and data access that improves the quality and cost effectiveness of
care delivery for the public good.

Background: A common misperception exists that these interoperability approaches and
trusted frameworks operate in silos. Several examples of collaboration across these efforts are
currently underway and more opportunities are in the pipeline for the future. For example, many
of the existing interoperability approaches leverage DirectTrust and Carequality. Efforts that
originally focused on provider-driven exchange are exploring conversations with patient-directed

perspective and understand that many currently have to implement a multi-pronged exchange
approach to care for their patient population in a comprehensive manner. Used together or
independently, these approaches can solve the unique needs of the individual and the provider.

2) Educate the Community to Appropriately Implement Existing and Emerging
Standards, Data Formats, and Use Cases to Ensure a Comprehensive
Integrated Approach to Care

HIMSS Call to Action:
Education: Existing standards, data formats, and use cases must be leveraged. A
comprehensive integrated approach to care can recognize and build upon the many mature,
consensus-based standards and profiles already in place, while allowing innovation to pilot and
incorporate new and emerging standards. An important component of driving implementation of
interoperable systems is the proper education about the existing standards and use cases. HHS
and the Office of the National Coordinator (ONC) should support and encourage efforts and
convening opportunities for the health information and technology community, specifically
Standards Development Organizations (SDOs), to provide such education. The health
community increasingly includes non-traditional data sources (e.g. social determinants of health
gathered from public health registries, social services agencies, genomic information,
immunization information, quality reporting, environmental science, payer and billing
components and other non-traditional stakeholders). As a result, education is pivotal to ensuring
that these data are based on known and adopted standards; standards that will continue to
drive semantic interoperation and value for the broader healthcare community.

Implementation: Beyond education, HHS should lead efforts to ensure appropriate standards
are implemented, and used, consistently. Three of the biggest challenges limiting standards
implementation revolve around quality, the level of consistency in the use of the standards, and
the complexity of versioning (e.g. C-CDA Release 1.1 vs 2.0 vs 2.1). HIMSS supports continued
efforts to develop a Measurement Framework to understand and drive consistency in standards
implementation and use.

HHS should also work with community stakeholders to articulate the value proposition and
outcomes related to the use of these standards in how they improve aspects of care (e.g.
preventing duplicative tests, medication errors, adverse events, incorporation/reconciliation of
data, and data access). HHS should facilitate development of, or identify, existing clear and

comprehensive implementation guides (i.e. IHE technical frameworks) aligned with the
standards for all healthcare domains; these guides should align with setting and clinical domain,
and must address information exchange between entities that may have different levels of
health information and technology sophistication.

Background: Currently the work to achieve ubiquitous, interoperable health information
exchange has led to the creation and use of numerous standards, data formats and use cases.
These vary greatly in their scope of implementation and use. Understanding of the adoption and
use of these standards is limited at best, and inconsistency in the implementation of these
standards has created challenges in producing interoperable exchange. As the US health
system continues its push toward value-based care and the use of patient-generated health
data, more data sources must integrate into the patient record, including but not limited to,
social determinants of health, behavioral health data, genomic information, immunization data,
and quality reporting metrics.

3) Ensure Stakeholder Participation from Across the Care Continuum, Including

Patients and Caregivers

HIMSS Call to Action: The frameworks and approaches that currently exist include a wide
range of stakeholder groups. While the majority of these entities focus currently on provider-
directed exchange within the acute and ambulatory settings, many also discuss current and
future plans to engage individuals to enable access to their own health information. HIMSS
recognizes this as a critical step towards empowering patient-mediated exchange. HHS should
include consumers, patients, caregivers, payers, public health and non-traditional provider
groups (i.e., community-based providers, long-term/post-acute care), in these interoperability
approaches and trusted exchange frameworks. Unfortunately, existing frameworks mainly focus
on acute and ambulatory information exchange; gaps remain in Long Term Post-Acute Care,
Long-Term Service and Support, and Behavioral Health. These gaps must be addressed.

Emphasize the importance of engaging patients through patient-mediated exchange. In our
2017-2018 Public Policy Principles, HIMSS states that all individuals, their families, and
healthcare providers should be able to send, receive, find, and use electronic health information
in a manner that is appropriate, secure, timely, and reliable to support their health and wellness.

Background: There is a tremendous need to better understand how all healthcare stakeholders
can participate in these efforts, the value of the actors in these models, and identify the
business and legal exchange agreements needed to further advance ubiquitous semantic
interoperability. Some current approaches, such as DirectTrust, NATE, and the CARIN Alliance,
are driving efforts to place the patient at the center of data access and exchange.

4) to

Enhance Care Coordination

HIMSS Call to Action: Across all interoperability approaches, HIMSS endorses the creation of

leverage a baseline framework for trusted exchange. This baseline, which may be similar to the
Common Clinical Data Set, can simplify onboarding for participants, allowing for greater
involvement across the disparate exchange solutions and lead to better care coordination. In
addition, standards and protocols should be developed to address the information needs of

those users that need them the most those rules include addressing the needs of high-risk,
complex and costly populations. These populations highly value the business case for semantic
interoperability. Improved measurement and real-world testing are necessary to ensure the
identified and implemented standards, and existing testing and certification programs, are
leveraged to deliver value and serve their intended purpose for clinical use.

HIMSS urges the use of the Health Information Technology Advisory Committee to facilitate this
work, allowing for and obtaining public comment and feedback throughout the process. Once
identified, these approaches
those networks; this could be analogous to security clearances that occur within the federal
government.

Background: The current healthcare ecosystem consists of a variety of care settings, use
cases and stakeholders. There is no existing one-size-fits-all interoperability solution. With the
diversity across the ecosystem and the variety of interoperability initiatives that exist, it is not

of these unique scenarios and user needs.

5) Standardize and Adopt Identity Management Approaches

HIMSS Call to Action: Streamlining identity management to address the foundational needs for
interoperability is critical to achieving ubiquitous and secure data integration. Establishing a
common framework for patient identity matching is an important element to ensure further
consistency across disparate trusted exchange solutions. We advocate for the community to
identify, test, adopt and implement standards and their respective algorithms for matching
patients to their data across and between clinical and claims data sets.

Background: The ability to quickly and accurately identify and match patient records remains a
critical challenge across the health community. Standards to support specific activities regarding
patient identity matching are well established, yet one solution does not fully address the
standardization needed at the attribute level to sufficiently match patient records. This lack of a
solution remains one of the barriers to true interoperability. For three years, HIMSS has funded
an Innovator-in-Residence at HHS to advance the national dialogue on algorithm attributes and
approaches to strengthen algorithm accuracy. The resulting algorithm challenge has given the
healthcare community great insight into areas for improvement, which will help with adoption.

6) Improve Usability for Data Use to Support Direct Care and Research

HIMSS Call to Action: The health information and technology
must make improving usability a priority to ensure active engagement by individuals and
providers. Improved usability would ensure that data are consumed discretely, incorporated
seamlessly into workflow, help enable clinical decision-making, allow secondary use of data for
research, and limit the burden on the end-user. This enhanced exchange is fundamental to
promoting patient safety, achieving quality outcomes, facilitating care coordination as well as
transitions of care, and controlling costs. To achieve this end, semantic interoperability is
essential. Efforts to date have focused on syntactic aspects of exchange, i.e. the framework or
message format. Renewed focus on implementation and use of relevant terminology standards
and protocols is critical to improving usability.

Background: The inability to achieve semantic interoperability continues to be a barrier to
seamless exchange and data access. Often when data are shared, they are of low quality and
not useful in informing the delivery of care or improving patient outcomes. Each of the existing
frameworks and approaches offers solutions that improve the transportation and access to
documents and discrete data related to a variety of use cases. Any trusted exchange framework
needs to provide high quality, usable content in order for an end user to reap full participation
benefits.

HIMSS commits to activating this Call in real and practical ways. Leadership is needed at many
levels local, regional, and national. HIMSS applauds and honors the many individuals who
have literally dedicated their careers to building the foundations of a learning health system, and
the interdependencies of multiple networks, consortia, and trust frameworks. We thank the
tireless volunteers and subject matter experts from all areas of the health sector who
collaborated on our Call to Action. And, we welcome all collaborators to join us in our Call to
Action.

For more information, or to get involved, please contact Mari Greenberger MPPA, Director of
Informatics at HIMSS.

PatientHealth Information:
Connecting Electronic Medical
Records with External Apps
January 15, 2019 by Brian Levy, MD, president, Peak Informatics; a HIMSS
Interoperability & HIE Committee member

Imagine these three scenarios:

1. A patient stops by a busy urgent care center for concerning flu-like symptoms.
Rather than waiting a couple hours just to start being seen by the nurse, the patient
sits at a kiosk and interacts with an artificial intelligence (AI) assistant that asks the
patient some questions tailored to the signs and symptoms. The patient can even follow
easy instructions to take her own temperature, capture pictures of her ear drums using
a digital otoscope and record her heart and lung sounds. The AI system then records
this information, infers a probable diagnosis of influenza and sends the information to
the clinician’s electronic medical records (EMR) with the Subjective Objective
Assessment Plan (SOAP) note mostly filled out. Now, when the patient sees the
clinician, most of the work is done and the time can be spent between the patient and
clinician discussing the diagnosis and treatment plan.

2. Another busy patient is on a ranch and has developed a rash. It’s an hour drive to
the nearest doctor or urgent care. So instead, the patient uses his phone and sets up a
telehealth visit with a doctor right then. The doctor can review the patient’s previous
history obtained from the EMR, look at an uploaded picture of the rash sent by the
patient and converse with the patient over video. The document note would then be
sent back to the EMR along with the rest of the patient’s record. The patient’s regular
primary care provider can now access this encounter for follow up.

3. A busy doctor is seeing 30 patients a day in the clinic. Documentation and order
entry is time consuming in the EMR, but this doctor uses her phone and a special app to
record the patient/physician encounter and use natural language processing and
machine learning to turn this recording into a SOAP note. In addition, orders for labs
and x-rays are captured during the encounter and sent to the EMR along with the SOAP
note.

These scenarios are not science fiction. They represent new modalities of capturing
patient information outside of the typical EMR workflow – which I will call external apps
for now. These modalities are working to be interoperable with the rest of the patient’s
health information, which is typically stored in the EMR and claims databases. As their
prevalence grows within the health IT ecosystem, it is important to understand how
standards are being leveraged to integrate these applications within traditional EMRs.

Understanding the Role of Standards between EMRs
and External Apps
Some data sets are easier to capture and integrate into these external apps. Here are
some of the types of patient information being sent from and received by these external
applications:

 Demographics
 Scheduling
 Problem, procedure, medication and allergy information
 Notes, e.g., SOAP
 Lab and x-ray results and orders

HL7 V2 is often used to extract basic patient demographics and other patient
administration, or ADT, type data for use in these external applications. So, for
example, when the doctor walks into the patient room to record the encounter, these
external apps described above have already pulled visit and demographic information
from the EMR. These external apps also want to be able to book appointments and be
notified of visits through the clinicians’ schedule typically maintained in the EMR. I often
see proprietary EMR application program interfaces (APIs) used to handle the
scheduling.

When exchanging more clinically related data, additional challenges arise in the
semantic interoperability of these apps with EMRs. Structured and often codified
information such as the patient’s problems, procedures, medications and allergies are
shared and often have these semantic interoperability challenges. However, there are
several standard terminologies that can be used for coding to mitigate these
challenges. The below examples highlight the role of standards to ensure semantic
interoperability.

 A telemedicine application may want to extract a patient’s drug allergies from
the EMR and use it their application to alert of potential drug allergy warnings
when a doctor orders a prescription for a patient during a virtual visit. In order to
enable this workflow, the drug allergies need to be coded using the same
proprietary terminology or appropriately mapped to each other.

 The diagnosis recorded during virtual telemedicine encounters need to be coded
to help support the ability to perform orders and send the correct visit diagnosis
back into the EMR.

 Lab and radiology orders often require codification to proprietary EMR-specific
(and often provider-specific) order entry catalogs. Sometimes industry standard
names and codes can be accepted for lab orders, but more likely used for
reporting lab results.

For the free text notes generated by each of these systems, the HL7 CCD document
format serves as a syntactic bridge allowing notes to be extracted from these external
apps and sent to the EMR repository and well as received by these apps.

FHIR®’s Progress in Syncing These Technologies
There are several interface options when trying to sync the external app with the EMR.
Where does FHIR come into play? These application vendors are beginning to use FHIR
to transmit and receive information from various healthcare IT applications, such as
EMRs and payer data repositories. However, FHIR still has not reached ubiquitous use
across all the EMRs, so proprietary APIs are still predominantly being used to interface.
Many major EMR vendors have app-type stores that these external vendors are working
with to achieve interoperability. These stores may use FHIR interfaces, but proprietary
EMR APIs still appear to be more prominent.

Another potential channel that external apps are interested in using are the nationwide
services. Some initiatives are already aggregating patient information from the EMRs
and can be a data source for these applications.

These examples of new technology and healthcare interactions are really at the tip of
the iceberg – we will increasingly see all kinds of patient data being captured using
novel interfaces external to the traditional EMR. As standards like FHIR mature and are
increasingly adopted, hopefully we will be able to use a single interface to be
interoperable with any EMR.

NCPDP Electronic

Prescribing

Standards

September 2014

What is NCPDP?

• An ANSI-accredited standards development organization.

• Provides a forum and marketplace for a diverse membership focused on health

care

and pharmacy business solutions.

• A member driven organization that has been named in various government legislation

and rulings, such as HIPAA, the Medicare Prescription Drug Benefit, and healthcare

reform.

• One of several Standards Development Organizations (SDOs) involved in Healthcare

Information Technology and Standardization.

• Focus on pharmacy services, and has the highest member representation from the

pharmacy services sector of healthcare.

• NCPDP standards

are used in pharmacy processes, payer processes, electronic

prescribing, rebates, and more.

Products (see http://www.ncpdp.org/Products)

• NCPDP dataQ™ – provides healthcare stakeholders with up-to-date, comprehensive,

and in-depth pharmacy information.

• NCPDP Online – enumerator of the NCPDP Provider ID number.

• HCIdea – NCPDP’s relational healthcare prescriber database of over 2.1 million

prescribers created for the industry, by the industry.

• RxReconnTM – NCPDP’s legislative tracking product.

http://www.ncpdp.org/Products











Pharmaceutical

Manufacturer

Drug Wholesaler

Switch

Service

Intermediary

Processor/

PBM

Point of

Care Vendor

Patien

Physician

Prescriber

Card

Cardholder &

dependent(s

)

Payor/

Healthplan

Pharmacy

Eligibility

Electronic

Prescription

P
h

a
rm

a
c

C
la

M
a

n
u

fa
c

tu
re

R
e

b
a

ti
n

E
n

ro
ll
m

e
n

A
S

C
X

1
2

N
8

3
4

B
e

n
e

fi
t

E
n

ro
llm

e
n

t
a

n
d

M
a

in
te

n
a

n
c
e

,
V

e
rs

o
n

5
0

1
0

ASC X12N 834 Benefit Enrollment
and Maintenance, Version 5010 /
NCPDP Member Enrollment
Standard

(WG 45)

M
a
n
u
fa
c
tu
re

e
b

a
te

s
,

ti
li
z
a

ti
o

n
,

P
la

n
,
F

o
rm

u
la

ry
,

M
a

k
e

t
B

a
s

k
e

t,
a

n
d

e
c

o
n

c
il
ia

ti
o

n
F

la
t

F
il
e

S
ta

n
d

a
rd

G
7

)

Billing Unit Standard
(WG 2)

NCPDP SCRIPT
Standard
(WG 11)

N
C

P
D

T
e

le
c

o
m

m
u

n
ic

a
ti

o
n
S
ta
n
d
a
rd

n
iv

e
rs

a
l
C

la
im

F
o

rm
B

a
tc

h
T

ra
n

s
a

c
ti

o
n
S
ta
n
d
a
rd

G
1

)

Pharmacy ID
Card
(WG 3)

ASC X12N 835 Version 5010 Remittance Advice

(WG 45)

NCPDP Formulary and Benefit

Standard / NCPDP SCRIPT

Medication History (WG 11)

Eligiblity

Formulary

Drug History

NCPDP Standards Used in Electronic

Prescribing

• SCRIPT Standard
• Exchange between prescribers, pharmacies, intermediaries,

payers

• New prescription request

• Change of new prescription

• Cancel of prescription

• Refill/renewals request/response or Resupply in long term

care

• Fill Status notification

• Medication history exchange

• Drug Administration exchange in long term care

• Prescriber-reported samples for more robust medication

history

• Query functions for new prescriptions

CMS Regulations 2010-20

• July 1, 2010 published

• The Centers for Medicare and Medicaid Services (CMS) published to the Federal

Backward Compatible Version of Adopted Standard for E-Prescribing and the

Medicare Prescription Drug Program (NCPDP SCRIPT 10.6).”

• The regulation names NCPDP SCRIPT 10.6 effective for use July 1, 2010 and

continues to support NCPDP SCRIPT 8.1.

• See

http://www.ncpdp.org/Resources/ePrescribing

• Long term care may use the MMA standards, but are not required at this point

• October 24, 2011
• 42 CFR Chapter IV [CMS–9070–P] RIN 0938–AQ96 Medicare and Medicaid

Program; Regulatory Provisions To Promote Program Efficiency, Transparency,

and Burden Reduction.

• Section 4. E-Prescribing which proposes to move from the ASC X12 270-271

version 4010A1 to the 5010, and from the NCPDP Telecommunication Standard

version 5.1 to D.0, to be aligned with the HIPAA regulations for January 1, 2012.

• The industry had requested this regulatory update so that the electronic

prescribing and claims processing environments would be in sync for versions of

standards used.

http://www.ncpdp.org/Resources/ePrescribing

CMS Regulation 2012-20

• Final Rule published November 16, 2012 Federal Register. See

http://www.gpo.gov/fdsys/pkg/FR-2012-11-16/pdf/2012-26900
• Lifted the long term care exemption

• Finalization of NCPDP SCRIPT 10.6 and retiring of SCRIPT 8.1

• 2014 Physician Fee Scheduled – Formulary and Benefit Standard Version 3.0

• Adoption of NCPDP Formulary and Benefits 3.0 as the official Part D

eprescribing standard from February 10, 2014 through February 28,

2015.

• Compliance date March 1, 20

• http://www.gpo.gov/fdsys/pkg/FR-2013-12-10/pdf/2013-28696

http://www.ncpdp.org/Resources/ePrescribing under Federal Regulations and

Information, CMS ePrescribing Standards

See http://www.cms.gov/Medicare/E-Health/Eprescribing/index.html

http://www.gpo.gov/fdsys/pkg/FR-2012-11-16/pdf/2012-26900

http://www.gpo.gov/fdsys/pkg/FR-2013-12-10/pdf/2013-28696

http://www.ncpdp.org/Resources/ePrescribing

http://www.cms.gov/Medicare/E-Health/Eprescribing/index.html

Electronic Prescribing for Controlled Substances

March 31, 2010 published

• The Drug Enforcement Administration (DEA) issued an Interim Final

Rule (IFR) with Request for Comment to provide practitioners with the

option of writing prescriptions for controlled substances electronically

and permit pharmacies to receive, dispense and archive these

electronic prescriptions.

• See http://www.ncpdp.org/Resources/ePrescribing

• The effective date is June 1, 2010.

• The DEA has published guidance at

http://www.deadiversion.usdoj.gov/ecomm/e_rx/index.html

• The

SCRIPT Implementation Recommendations Document

contains guidance for the use of one of the DEA options in SCRIPT

8.1 and in SCRIPT 10.6

http://www.ncpdp.org/Resources/ePrescribing

http://www.deadiversion.usdoj.gov/ecomm/e_rx/index.html

DEA Regulation

September 9, 2010

• The DEA solicited public comments on how best to standardize the

specific internal code number associated with each individual

practitioner permitted by the hospital or other institutional practitioner

to administer, dispense, or prescribe controlled substances using that

institution’s DEA registration.

• DEA is taking this action in response to comments it received to its

Notice of Proposed Rulemaking regarding electronic prescriptions for

controlled substances. 21 CFR Part 1301 [Docket no. DEA–321a]

RIN 1117–AB22 Identification of Institution-based Individual

Practitioners.

http://www.access.gpo.gov/su_docs/fedreg/frcont10.html

DEA Regulation

October 19, 2011
• 21 CFR Parts 1300, 1304, 1306 and 1311 [Docket No. DEA–360] Electronic

Prescriptions for Controlled Substances Clarification

• DEA wishes to emphasize that third-party audits of software applications for

Electronic Prescriptions for Controlled Substances (EPCS) must encompass

all applicable requirements in our regulations, including security, and must

address ‘‘processing integrity’’ as set forth in our regulations.

• Likewise, where questions or gaps may arise in reviewing a particular

application, DEA recommends consulting federal guidelines set forth in NIST

Special Publication 800–53A.

• DEA is also announcing the first DEA approved certification process for

EPCS. Certifying organizations with a certification process approved by DEA

pursuant to the regulations are posted on DEA’s Web site once approved.

http://www.access.gpo.gov/su_docs/fedreg/frcont11.html

What do I need to implement SCRIPT

10.6?
All NCPDP published documents are available free of charge with annual

membership at http://www.ncpdp.org/Members/Standards-Lookup.aspx

http://www.ncpdp.org/Members/Standards-Lookup.aspx

11
What do I need to implement SCRIPT

10.6?

• Implementation Guide

• SCRIPT Version 10.6

• Format choice:

• EDI format

• Contained in SCRIPT

Implementation Guide

• XML

• Implementation rules contained in SCRIPT Implementation Guide

• XML zip file included in download

• Data Dictionary

• October 2008

•

External Code List

• Publications of October 2008 through most recent are

applicable

• It is recommended that ECLs through 201009 are used as reference

• SCRIPT Implementation Recommendations Document

NCPDP Standard Documents

NCPDP publishes the following three types of documents:

Standard Implementation Guide

Data Dictionary

External Code List

The documents are used together, to provide a complete picture of the

implementation of the standard.

See the “read me” document on the member CD or

http://www.ncpdp.org/Members/Standards-Lookup under the

SCRIPT Standards section.

Each document contains an appendix of the running list of changes

http://www.ncpdp.org/Members/Standards-Lookup

NCPDP Standard

Implementation Guide

The Standard Implementation Guide contains the

• business and technical definition of the transactions

• the actual transaction layouts, the syntax and formatting rules,

the transaction rules, usage,

• further information about the implementation of the standard by

the use of descriptive paragraphs, business situations, examples,

and frequently asked questions.

This one document combines what was in the Standard and in the

Implementation Guide in previous versions.

NCPDP SCRIPT Standard

Implementation Guide

Each section of the implementation guide builds lower level detail.

Section 6 describes the transactions.

Section 8 describes the EDI format layout.

Section 9 provides what segments are allowed/how used in each EDI format

transaction but can also be used as a guide of which XML segments are

supported in the xsd.

Section 10 describes the fields within each segment within each transaction. It

can be used as a guide of which XML fields are supported in the xsd per

segment per transaction.

NCPDP Data Dictionary

The Data Dictionary contains the actual field descriptions, sizes,

formats, comments, and usage instructions

Which Data Dictionary do I use?

• See the Matrix http://www.ncpdp.org/Members/Standards-

Lookup

– bottom left (or on the member CD)

Use of the correct publication of the data dictionary for a version of a

standard is critical as each publication directs the proper use of a data

element and data element values where applicable.

For SCRIPT 10.6

• Data Dictionary
• October 2008

• Important Note: For SCRIPT v10.6, the data elements and their

definitions are in

section 10 of the implementation guide.

http://www.ncpdp.org/Members/Standards-Lookup

NCPDP External Code List

The External Code List is a list of value codes with descriptions for data

elements.

The actual data elements still appear in the main Data Dictionary.

The External Code List process allows values to be added to a data

element without going through a ballot.

The timeline to incorporate a value into a business need is

shortened.

Versions are upgraded quarterly if needed and are available for

business use.

For SCRIPT 10.6

• External Code List

• Publications of October 2008 through most recent are applicable
• It is recommended that ECLs through 201009 are used as reference

NCPDP Data Dictionary and External

Code List and SCRIPT Transition

Of importance, the SCRIPT Standard version 8.1 – 10.11 contained both

“EDI” and “XML” syntax. The Data Dictionary and External Code Lists

published during this time reflect the “EDI” data elements.
• Important Note: For SCRIPT v10.6, the data elements and their definitions are in

section 10 of the implementation guide.

The industry requested that the SCRIPT Standard sunset the “EDI” and

only support the “XML” syntax post SCRIPT version 10.11.

The Data Dictionary and External Code Lists of 201012 and forward

contain only the XML data elements.

In the Data Dictionary of 201012 and future, we included Appendix B –

CROSS REFERENCE OF FIELDS USED IN NCPDP SCRIPT TO

THE MODEL-DRIVEN to assist as a cross reference between the old

EDI fields and the XML fields.

NCPDP Data Dictionary and External
Code List and SCRIPT Transition

SCRIPT 10.6 can use 201012 or 201104 ECL, but if implementers are

using only “EDI” syntax, it is recommended to reference the Data

Dictionary and External Code List of 200810 through 201009.

If you are implementing XML only, the current Data Dictionary and ECL

contain data element references. But if you are implementing SCRIPT in

“EDI” syntax, you hit a transition between the Data Dictionary and the

ECL.

It is recommended that implementers are aware that in SCRIPT 2014+

the field values have been constrained per transaction.

Please bear this in mind with the use of the values used in version 10.6.

We didn’t try to make it difficult, but we had to have a transition as new

data elements, code lists were approved for use.

Guidance

SCRIPT Implementation Recommendations Document

• See section “Quantity Qualifier Recommendations for Electronically

Created Prescriptions”. Implementers should be aware and

planning for the implementation timeframe.

• See section “Assistance with the Use of SCRIPT version 10.6 in the

Long Term and Post Acute Care Settings”.

• The document is updated as needed, so check back quarterly.

Guidance
SCRIPT Implementation Recommendations Document

• Provides guidance, recommendations that could not be put in an

“officially named version” of SCRIPT Implementation Guide but have

been incorporated in a subsequent Implementation Guide version.

• Of importance to industry for consistent use

• Best practices for prescription data elements

• Controlled Substance prescription data elements using one of the two

options of the DEA regulation

• RxNorm information

• Updated as needed, so check back quarterly
• Included in CD, and found under “SCRIPT Standard Guidance

Documents” at

http://www.ncpdp.org/Members/Standards-Lookup

or at

http://www.ncpdp.org/Resources/ePrescribing

http://www.ncpdp.org/Members/Standards-Lookup

http://www.ncpdp.org/Resources/ePrescribing

Guidance

Structured and Codified Sig Implementation Guide Version 1.2

• For implementing the Structured Sig Segment in SCRIPT versions

10.6 through 2011, the NCPDP Structured and Codified Sig

Implementation Guide Version 1.2 should be referenced for more

detailed explanation, situational rules and guidance. at

http://www.ncpdp.org/Members/Standards-Lookup

NCPDP Standards Used in Electronic
Prescribing

• Formulary and Benefit Standard

• Pharmacy benefit payers (including health plans and Pharmacy

Benefit Managers) to communicate formulary and benefit

information to prescribers via technology vendor systems.

Information for the prescriber to consider for the most appropriate

drug choice for the patient.

• Which drugs are considered to be “on formulary,” and

alternative medications for those drugs not on formulary

• Limitations that may impact whether the patient’s benefit will

cover a drug being considered (such as age limits, gender

limits, step therapy rules, benefit-specific coverage exclusions,

etc.)

• The cost to the patient for one drug option versus another

What do I need to implement Formulary

and Benefit 1.0?

• Implementation Guide

• Formulary and Benefit Implementation Guide Version 1.0

• Data Dictionary

• October 2005

• External Code List

• Publications of October 2005 through most recent are applicable

See slide “CMS Regulations 2012” for important new information.

What do I need to implement Formulary

and Benefit 3.0?

• Implementation Guide

• Formulary and Benefit Implementation Guide Version 3.0

• Data Dictionary

• December 2010

• External Code List

• Publications of December 2010 through most recent are

applicable

See slide “CMS Regulations 2012-2013” for important new information.

Code Lists Used

The NCPDP External Code List contains

• Values to NCPDP-defined data elements and

• Qualifiers for external code lists used in the standards, such as

drug databases, product identifiers, etc

• Links to other terminologies such as RxNorm, NCI (Strength,

Form, etc), SNOMED, ASC X12, etc

• Some external code sources are publicly available, others are not.

Medication Identification

Electronic prescribing functions require the exchange of medication

information. There are medication terminologies, databases,

products and services available – which may support different

perspectives.

For example, the medication a prescriber prescribes may be less specific

than the product a pharmacy dispenses. The medication information

exchanged in formulary files may represent a class of medications. All

are important perspectives and there is not one terminology that

satisfies all.

The industry has long used the NDC and other identifiers for the product

dispensed. A gap was identified years ago for a prescribed identifier.

The industry is moving toward the use of RxNorm for the prescribed

product. See the SCRIPT Implementation Recommendations

Document at http://www.ncpdp.org/Resources/ePrescribing

http://www.ncpdp.org/Resources/ePrescribing

Prior Authorization

• NCPDP SCRIPT Standard version 2013071 was approved with the new transactions

for ePA for the pharmacy benefit authorizations.

• The industry requested that SCRIPT v2013101 be named under the

appropriate regulations for the exchange between prescribers and

payers for the pharmacy benefit.

• See the SCRIPT Standard for information http://www.ncpdp.org/Members/Standards-

Lookup

• See webinar http://www.ncpdp.org/Education/Webinar

• Note: When the pharmacy needs to obtain a prior authorization directly, they use the

NCPDP Telecommunication Standard prior authorization transactions. This exchange

has been available for awhile, and was considered out of scope.

• Note: in An error was corrected in the xml schema. It affects version

201310 and above. Because the industry is actively implementing version 2013101 for ePA transactions, a new

version was created of 2013102 with the modification so that the change was noted. In version 201404 and above

the xml schema was republished since these versions were not in use. inadvertently dropped the

subelements of and in these versions. It has been corrected.


http://www.ncpdp.org/Members/Standards-Lookup
http://www.ncpdp.org/Members/Standards-Lookup
http://www.ncpdp.org/Members/Standards-Lookup
http://www.ncpdp.org/Education/Webinar
28

Specialized Standard

This implementation guide supports these business functions.

• Census Functions

• Medication Therapy Management Functions

• Query Functions

PHARMACY typically will:

• Respond to a request for census events

• initiate a request for clinical information

• initiate a response for clinical information

PRESCRIBER typically will:

• notify a pharmacy or other entity of drug administration events such as suspending

administration

• initiate a request for clinical information

• initiate a response for clinical information 
Entities (pharmacy, prescriber, intermediary, payer/health plan) typically will:

• initiate a request by the facility in a long term care environment to notify the

pharmacy about census events

• initiate a request for clinical information

• initiate a response for clinical information 
29

NCPDP Task Groups

• Task Groups are open to any interested party (NCPDP member or not) who are willing

to participate and work. They meet via conference calls.

• NCPDP Formulary and Benefit Task Group

• Meets to provide further clarification, enhancements to the Formulary and Benefit

Standard. (Participation: prescribing and payer systems) 
• Electronic Prescribing Best Practices Task Group

• Provides guidance to the industry for best practices in the implementation and use of

electronic prescribing transactions. Recommendations are in the SCRIPT

Implementation Recommendations Document at

http://www.ncpdp.org/Resources/ePrescribing. (Participation: prescribing and pharmacy systems)

• NCPDP Implementation of Structured and Codified Sig Task Group

• To provide guidance for the industry on implementation of the structured and codified

sig exchange. (Participation: prescribing and pharmacy systems)

• Specialty Requirements for ePrescribing Task Group

• Often additional information needed before a prescription can be dispensed.  This

information is provided by the prescribing system. This information includes additional

patient demographic and clinical information, order-specific clinical information and

instructions related to delivery of the medication (i.e. to the patient or the clinic, nursing

services. (Participation: prescribing and pharmacy systems).

http://www.ncpdp.org/ePrescribing.aspx
30

NCPDP Task Groups

• Meaningful Use and NIST Test Methods for ePrescribing Task Group

• This task group is providing feedback to NIST on their electronic prescribing test

procedures for EHR Certification and bringing forward implementation guidance points.

(Participation: prescribing, pharmacy, and payer systems).

• REMS and ePrescribingTask Group

• Evaluating the activities between pharmacy and prescriber, prescriber and manufacturer for

safe use programs. (Participation: prescribing and pharmacy systems). 
• Drug Description Task Group

• This task group created guidance for the use of the Drug Description and code sets. Their

recommendations are in the SCRIPT Implementation Recommendations Document at

http://www.ncpdp.org/Resources/ePrescribing   They are working with National Library of

Medicine to create editorial rules for creating eprescribing RxNorm medication names for

use. (Participation: prescribing, pharmacy systems, compendia). 
• Prior Authorization Workflow-to-Transactions Task Group

• Built transactions to exchange prior authorization needs for electronic prescribing. They are

working on enhancements to the electronic prior authorization transactions. (Participation:

prescribing, pharmacy, payer systems) 
http://www.ncpdp.org/Resources/ePrescribing
31

NCPDP Task Groups 
• NCPDP-HL7 Pharmacist Functional Profile Task Group

• Has built profiles for criteria for functions required/optional and the timeline for meeting

criteria for standalone eprescribing systems and pharmacy/pharmacist interfaces for input to

Certification Commission for Health Information Technology (CCHIT) criteria. Is working on

“Pharmacist/Pharmacy Provider systems” by creating one updated functional profile of the

HL7 EHR System-related functions release 2. (Participation: prescribing and pharmacy systems). 
• Long Term and Post Acute Care ePrescribing Task Group

• This task group is advancing the adoption of ePrescribing in the Long Term Care, Post Acute

Care and Hospice setting. WG11 is assisting this task group with understanding current

ePrescribing functionality and to provide assistance incorporating LTC needs into ePrescribing

standards. (Participation: prescribing and pharmacy systems).

Many other Task Groups – see http://www.ncpdp.org/Standards/Standards-Info –

bottom left.

http://www.ncpdp.org/Standards/Standards-Info
http://www.ncpdp.org/Standards/Standards-Info
http://www.ncpdp.org/Standards/Standards-Info
32

Of Interest

• NCPDP electronic prescribing web page for resources, industry

information, fact sheet, etc.

• http://www.ncpdp.org/Resources/ePrescribing

• NIST Health IT Standards and Testing Site

• E-prescription validator tool:

http://erx-testing.nist.gov/

• eRx Validator Google Group

• https://groups.google.com/forum/#!forum/erx-testing-tool

http://www.ncpdp.org/Resources/ePrescribing
http://www.ncpdp.org/Resources/ePrescribing
http://erx-testing.nist.gov/
http://erx-testing.nist.gov/
http://erx-testing.nist.gov/
https://groups.google.com/forum/#!forum/erx-testing-tool
https://groups.google.com/forum/#!forum/erx-testing-tool
https://groups.google.com/forum/#!forum/erx-testing-tool
https://groups.google.com/forum/#!forum/erx-testing-tool
https://groups.google.com/forum/#!forum/erx-testing-tool
33

Questions?

– NCPDP task groups – http://www.ncpdp.org/Standards/Standards-Info

– bottom left.

• Electronic prescribing info –

http://www.ncpdp.org/Resources/ePrescribing  
• See www.ncpdp.org

• Contact ncpdp@ncpdp.org

http://www.ncpdp.org/Standards/Standards-Info
http://www.ncpdp.org/Standards/Standards-Info
http://www.ncpdp.org/Standards/Standards-Info
http://www.ncpdp.org/Resources/ePrescribing
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 3/1/2014 Page 1

HL7 Version 2.5.1

Implementation Guide

for Immunization Messaging

Release 1.5

10/1/2014
Page Intentionally Blank  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 2 
Publication History of Previous Versions:

Implementation Guide for Immunization Data Transactions using Version 2.3.1 of the Health Level Seven

(HL7) Standard Protocol

Version Date

Version 2.0 June 1999

Version 2.1 September 2003

Version 2.2 June 2006

Publication History of HL7 Version 2.5.1 Implementation Guide for

Immunization Messaging.

Revision history

Revision Date Author

Release 1.0 5/1/2010 Rob Savage

Release 1.1 8/15/2010 Rob Savage

Release 1.2 2/15/2011 Rob Savage

Release 1.3 8/15/2011 Rob Savage

Release 1.4 8/1/2012 Rob Savage

Release 1.5 for comment 3/11/2014 Rob Savage

Release 1.5 10/1/2014 Rob Savage

A list of changes may be found at the end of Implementation Guide.

or information about HL7, contact:

Health Level Seven

3300 Washtenaw Avenue, Suite 227

Ann Arbor, MI 48104-4250

Phone:  (734) 677-7777

Fax:   (734) 677-6622

E-Mail:  hq@hl7.org

Website:  http://www.hl7.org

For information about the American

Immunization Registry Association, visit

http://www.immregistries.org

For information about this Guide, contact:

Rob Savage

rbsavage@cdc.gov

Warren Williams

wxw4@cdc.gov

Immunization Information Systems  Support

Branch, Immunization Services Division,

National Center for Immunization  and

Respiratory Diseases,

Centers for Disease Control and Prevention

Phone: (404) 639-8245

Fax:  (404) 639-8171

Website: http://www.cdc.gov/vaccines/programs/iis/index.html

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 3 
mailto:hq@hl7.org
http://www.hl7.org/
http://www.immregistries.org/
mailto:rbsavage@cdc.gov
mailto:wxw4@cdc.gov
http://www.cdc.gov/vaccines/programs/iis/index.html
Table of Contents

TABLE OF CONTENTS

TABLE OF CONTENTS …………………………………………………………………………………………………… 1

INDEX OF TABLES …………………………………………………………………………………………………………. 8

TABLE OF FIGURES ………………………………………………………………………………………………………. 1

1. INTRODUCTION …………………………………………………………………………………………………………. 2

Intended Audience …………………………………………………………………………………………………………………….. 3

Scope ………………………………………………………………………………………………………………………………………. 3

Organization and Flow ………………………………………………………………………………………………………………. 4

2. ACTORS, GOALS, AND MESSAGING TRANSACTIONS ……………………………………………….. 7

Actors and Goals ………………………………………………………………………………………………………………………. 7

High-Level View of Use Cases……………………………………………………………………………………………………10

Use Case Descriptions ………………………………………………………………………………………………………………. 11

Use Case 1—Send Immunization History ………………………………………………………………………………… 11

Use Case 2—Request Complete Immunization History ………………………………………………………………12

Use Case 3—Request Evaluated History and Forecast ……………………………………………………………….12

Use Case 4—Send Demographic Data ……………………………………………………………………………………..13

Use Case 5–Acknowledge Receipt ………………………………………………………………………………………….13

Use Case 6—Report Error ………………………………………………………………………………………………………13

Messaging in the Context of the Business Process …………………………………………………………………………13

Core Data Elements of an Immunization History …………………………………………………………………………..15

Key Technical Decisions ……………………………………………………………………………………………………………16

Pre-Adoption Of Some Features Of HL7 Version 2.7.1 ………………………………………………………………16

Use of Vocabulary Standards …………………………………………………………………………………………………..16

Processing Mode …………………………………………………………………………………………………………………..17

Message Profiles ……………………………………………………………………………………………………………………17

Conventions ………………………………………………………………………………………………………………………….17

3. HL7 MESSAGING INFRASTRUCTURE ………………………………………………………………………. 18

Keywords ………………………………………………………………………………………………………………………………..18

HL7 definitions …………………………………………………………………………………………………………………………18

Basic Message Processing Rules …………………………………………………………………………………………………20

Message Acknowledgement ……………………………………………………………………………………………………20

Encoding Rules for Sending ……………………………………………………………………………………………………20

Determining Usage of Segments, Fields and Components …………………………………………………………..22

Usage Conformance Testing Recommendations ……………………………………………………………………………22

Usage …………………………………………………………………………………………………………………………………..23

Definition Of Conditional Usage ……………………………………………………………………………………………..23

Sending And Receiving Application Conformance Requirements ………………………………………………..23

Message Element Attributes ……………………………………………………………………………………………………….26

4. HL7 DATA TYPES ……………………………………………………………………………………………………… 29

Data Types Used In This Implementation Guide ……………………………………………………………………………29

CE — Coded Element (most uses) ……………………………………………………………………………………………31

CE_TX — Coded Element (text only in RXA-9) ………………………………………………………………………..32

CQ — Composite Quantity with Units ………………………………………………………………………………………33

CWE — Coded With Exceptions ………………………………………………………………………………………………34

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page i 
Table of Contents

CX — Extended Composite ID With Check Digit ………………………………………………………………………36

DT — Date ……………………………………………………………………………………………………………………………38

DT_D — Date with precision to day …………………………………………………………………………………………38

DTM — Date/Time…………………………………………………………………………………………………………………39

EI — Entity Identifier ……………………………………………………………………………………………………………..40

ERL — Error Location ……………………………………………………………………………………………………………41

FN — Family Name ……………………………………………………………………………………………………………….43

FT – Formatted Text ………………………………………………………………………………………………………………43

HD — Hierarchic Designator …………………………………………………………………………………………………..44

ID — Coded Values for HL7 Tables ………………………………………………………………………………………….45

IS — Coded Values for User Defined Tables ………………………………………………………………………………45

LA2 — Location with Address Variation 2…………………………………………………………………………………46

MSG — Message Type ……………………………………………………………………………………………………………47

NM — Numeric ……………………………………………………………………………………………………………………..48

PT — Processing Type …………………………………………………………………………………………………………….49

SAD — Street Address ……………………………………………………………………………………………………………49

SI — Sequence Id …………………………………………………………………………………………………………………..50

ST – String ……………………………………………………………………………………………………………………………50

TS — Time Stamp ………………………………………………………………………………………………………………….51

TS_M — Time Stamp to Month ……………………………………………………………………………………………….51

TS_NZ — Time Stamp No Time Zone ………………………………………………………………………………………52

TS_Z — Time Stamp with Time Zone ………………………………………………………………………………………53

VID — Version Id …………………………………………………………………………………………………………………..54

XAD — Extended Address ………………………………………………………………………………………………………55

XCN – Extended Composite ID Number and Name for Persons …………………………………………………..57

XON – Extended Composite Name and ID Number and Name for Organizations ………………………….60

XPN — Extended Person Name ……………………………………………………………………………………………….61

XPN_M — Extended Person Name – Maiden Name …………………………………………………………………..63

XTN – Extended Telecommunication Number …………………………………………………………………………..65

5. PROFILE Z22-SEND UNSOLICITED IMMUNIZATION UPDATE USING A VXU ……………….. 68

Introduction: …………………………………………………………………………………………………………………………….68

Interaction Definition: ……………………………………………………………………………………………………………….68

Dynamic Definition: ………………………………………………………………………………………………………………….69

Static Definition—Message Level: ……………………………………………………………………………………………..71

Static Definition—Segment Level ……………………………………………………………………………………………….73

IN1—Insurance Segment ……………………………………………………………………………………………………….73

MSH—Message Header Segment ……………………………………………………………………………………………78

NK1—Next of Kin Segment …………………………………………………………………………………………………..84

NTE—Note Segment……………………………………………………………………………………………………………..88

OBX—Observation Result Segment ………………………………………………………………………………………..89

ORC—Order Request Segment ……………………………………………………………………………………………….98

PD1—Patient Demographic Segment …………………………………………………………………………………….103

PID—Patient Identifier Segment ……………………………………………………………………………………………107

PV1—Patient Visit Segment ………………………………………………………………………………………………… 114

RXA– Pharmacy/Treatment Administration Segment ……………………………………………………………… 114

RXR– Pharmacy/Treatment Route Segment……………………………………………………………………………122

6. PROFILE Z23 RETURN AN ACKNOWLEDGEMENT ………………………………………………….. 124

Introduction: …………………………………………………………………………………………………………………………..124

Interaction Definition: ……………………………………………………………………………………………………………..124

Dynamic Definition: ………………………………………………………………………………………………………………..125

Static Definition- Message Level ………………………………………………………………………………………………127

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page ii 
Table of Contents

Static Definition—Segment Level: ……………………………………………………………………………………………128

ERR—Error Segment …………………………………………………………………………………………………………..128

MSA—Message Acknowledgement Segment ………………………………………………………………………….131

MSH—Message Header Segment ………………………………………………………………………………………….131

7. PROFILE Z34 – REQUEST A COMPLETE IMMUNIZATION HISTORY ………………………….. 135

Introduction: …………………………………………………………………………………………………………………………..135

Interaction Definition: ……………………………………………………………………………………………………………..137

Dynamic Definition: ………………………………………………………………………………………………………………..138

Static Definition – Message Level: …………………………………………………………………………………………….141

Static Definition – Segment Level: ……………………………………………………………………………………………142

MSH – Message Header Specification …………………………………………………………………………………….142

QPD Input Parameter Specification ……………………………………………………………………………………….145

RCP – Response Control Parameter Segment ………………………………………………………………………….150

8. PROFILE Z32 RESPONSE PROFILE – RETURN COMPLETE IMMUNIZATION HISTORY 153

Introduction: …………………………………………………………………………………………………………………………..153

Interaction Definition ………………………………………………………………………………………………………………153

Dynamic Definition …………………………………………………………………………………………………………………153

Static Definition – Message Level ……………………………………………………………………………………………..154

Static Definition — Segment Level …………………………………………………………………………………………….156

ERR—Error Segment …………………………………………………………………………………………………………..156

IN1—Insurance Segment ……………………………………………………………………………………………………..158

MSA—Message Acknowledgement Segment ………………………………………………………………………….163

MSH – Message Header Specification …………………………………………………………………………………….164

NK1—Next of Kin Segment …………………………………………………………………………………………………167

NTE—Note Segment……………………………………………………………………………………………………………171

OBX—Observation Result Segment ………………………………………………………………………………………172

ORC—Order Request Segment ……………………………………………………………………………………………..177

PD1—Patient Demographic Segment …………………………………………………………………………………….181

PID—Patient Identifier Segment ……………………………………………………………………………………………184

PV1—Patient Visit Segment …………………………………………………………………………………………………189

QAK—Query Acknowledgement Segment ……………………………………………………………………………..189

QPD Input Parameter Specification ……………………………………………………………………………………….190

RXA– Pharmacy/Treatment Administration Segment ………………………………………………………………191

RXR– Pharmacy/Treatment Route Segment……………………………………………………………………………195

9. PROFILE Z31 — RETURN A LIST OF CANDIDATES PROFILE ……………………………………. 197

Introduction: …………………………………………………………………………………………………………………………..197

Interaction Definition ………………………………………………………………………………………………………………197

Dynamic Definition …………………………………………………………………………………………………………………197

Static Definition – Message Level ……………………………………………………………………………………………..197

Segment Level Profile ……………………………………………………………………………………………………………..199

ERR—Error Segment …………………………………………………………………………………………………………..199

MSA—Message Acknowledgement Segment ………………………………………………………………………….201

MSH – Message Header Specification …………………………………………………………………………………….202

NK1—Next of Kin Segment …………………………………………………………………………………………………205

QPD Input Parameter Specification ……………………………………………………………………………………….209

PID – Patient Identification Segment …………………………………………………………………………………….. 211

10. PROFILE Z33 –RETURN AN ACKNOWLEDGEMENT WITH NO PERSON RECORDS … 215

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/14 Page iii 
Table of Contents

Introduction: …………………………………………………………………………………………………………………………..215

Interaction Definition ………………………………………………………………………………………………………………215

Dynamic Definition …………………………………………………………………………………………………………………216

Static Definition – Message Level ……………………………………………………………………………………………..217

Static Definition — Segment Level …………………………………………………………………………………………….218

ERR—Error Segment …………………………………………………………………………………………………………..218

MSA—Message Acknowledgement Segment ………………………………………………………………………….220

MSH – Message Header Specification …………………………………………………………………………………….221

QPD Input Parameter Specification ……………………………………………………………………………………….223

11. PROFILE Z44–REQUEST EVALUATED IMMUNIZATION HISTORY AND FORECAST

QUERY PROFILE………………………………………………………………………………………………………… 225

Introduction ……………………………………………………………………………………………………………………………225

Interaction Definition ………………………………………………………………………………………………………………228

Dynamic Definition …………………………………………………………………………………………………………………228

Static Definition – Message Level: …………………………………………………………………………………………….231

Static Definition—Segment Level ……………………………………………………………………………………………..232

ERR—Error Segment …………………………………………………………………………………………………………..232

MSA—Message Acknowledgement Segment ………………………………………………………………………….234

MSH – Message Header Specification …………………………………………………………………………………….235

QPD Input Parameter Specification ……………………………………………………………………………………….237

RCP Response Control Parameter Field Description and Commentary ……………………………………….244

12. PROFILE Z42 — RETURN EVALUATED HISTORY AND FORECAST …………………………. 245

Introduction ……………………………………………………………………………………………………………………………245

Interaction Definition ………………………………………………………………………………………………………………245

Dynamic Definition …………………………………………………………………………………………………………………245

Static Definition –Message Level ……………………………………………………………………………………………..246

Static Definition — Segment Level …………………………………………………………………………………………….248

MSH – Message Header Specification …………………………………………………………………………………….248

OBX—Observation Result Segment ………………………………………………………………………………………250

ORC—Order Request Segment ……………………………………………………………………………………………..255

PID—Patient Identifier Segment ……………………………………………………………………………………………259

QAK—Query Acknowledgement Segment ……………………………………………………………………………..264

QPD Input Parameter Specification ……………………………………………………………………………………….265

RXA– Pharmacy/Treatment Administration Segment ………………………………………………………………266

RXR– Pharmacy/Treatment Route Segment……………………………………………………………………………270

13. BATCH FILE SPECIFICATIONS ……………………………………………………………………………… 272

Sending Messages in a Batch ……………………………………………………………………………………………………272

BHS—Batch Header Segment…………………………………………………………………………………………………..274

Conformance Statement ……………………………………………………………………………………………………….275

BHS field definitions ……………………………………………………………………………………………………………275

BTS—Batch Trailer Segment ……………………………………………………………………………………………………276

BTS field definitions ……………………………………………………………………………………………………………276

FHS—File Header Segment ……………………………………………………………………………………………………..277

Conformance Statement: ………………………………………………………………………………………………………277

FHS field definitions ……………………………………………………………………………………………………………278

FTS—File Trailer Segment ………………………………………………………………………………………………………278

CHANGE HISTORY DETAILS ………………………………………………………………………………………….. 1

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 3/1/2014 Page iv 
Table of Contents

Release 1.1……………………………………………………………………………………………………………………………. 1

Release 1.2……………………………………………………………………………………………………………………………. 1

Release 1.3……………………………………………………………………………………………………………………………. 2

Release 1.4……………………………………………………………………………………………………………………………. 4

Release 1.5……………………………………………………………………………………………………………………………. 5

APPENDIX A: …………………………………………………………………………………………………………………. 1

CODE TABLES ………………………………………………………………………………………………………………. 1

User-defined Table 0001 – Sex ……………………………………………………………………………………………………. 1

HL7-defined Table 0003 – Event type ………………………………………………………………………………………….. 2

User-defined Table 0004 – Patient class ……………………………………………………………………………………….. 2

User-defined Table 0005 – Race ………………………………………………………………………………………………….. 2

HL7-defined Table 0008 – Acknowledgment code …………………………………………………………………………. 2

User-defined Table 0010 – Physician ID ……………………………………………………………………………………….. 3

HL7-defined Table 0061 – Check digit scheme ……………………………………………………………………………… 3

User-defined Table 0063 – Relationship ……………………………………………………………………………………….. 3

User-defined Table 0064 – Financial class …………………………………………………………………………………….. 4

HL7-defined Table 0076 – Message type ………………………………………………………………………………………. 5

HL7-defined Table 0078 – Abnormal flags ……………………………………………………………………………………. 5

HL7-defined Table 0085 – Observation result status codes interpretation ………………………………………….. 6

User Defined Table 0086 – Plan Type ID ………………………………………………………………………………………. 6

HL7-defined Table 0091 – Query priority ……………………………………………………………………………………… 6

HL7-defined Table 0102 – Delayed acknowledgment type ……………………………………………………………… 6

HL7-defined Table 0103 – Processing ID ……………………………………………………………………………………… 6

HL7-defined Table 0104 – Version ID ………………………………………………………………………………………….. 7

HL7-defined Table 0119 – Order Control Codes ……………………………………………………………………………. 7

HL7-defined Table 0125 – Value Type …………………………………………………………………………………………. 7

HL7-defined Table 0126 – Quantity limited request ……………………………………………………………………….. 8

HL7-defined Table 0136 – Yes/No indicator ………………………………………………………………………………….. 8

HL7-defined Table 0155 – Accept/Application acknowledgment conditions ……………………………………… 9

NCI Thesaurus (NCIT) – Route of Administration ………………………………………………………………………… 9

HL7-defined Table 0162 – Route of administration …………………………………………………………………….. 9

HL7-defined Table 0163 – Administrative site ………………………………………………………………………………10

CDCREC – Ethnic Group ………………………………………………………………………………………………………….. 11

User-defined Table 0189 ……………………………………………………………………………………………………….. 11

HL7-defined Table 0190 – Address type ………………………………………………………………………………………. 11

HL7-defined Table 0200 – Name type ………………………………………………………………………………………….12

HL7-defined Table 0201 – Telecommunication use code ………………………………………………………………..12

HL7-defined Table 0202 – Telecommunication equipment type ………………………………………………………12

User-defined Table 0203 – Identifier type ……………………………………………………………………………………..13

User-defined Table 0204 – Organizational name type …………………………………………………………………….18

HL7-defined Table 0207 – Processing mode …………………………………………………………………………………18

User-defined Table 0208 – Query response status ………………………………………………………………………….18

User-defined Table 0215 – Publicity code …………………………………………………………………………………….19

User-defined Table 0220 – Living arrangement ……………………………………………………………………………..19

HL7-defined Table 0227 – Manufacturers of vaccines (code = MVX) ………………………………………………20

User-defined Table 0288 – Census tract ………………………………………………………………………………………..23

User-defined Table 0289 – County/parish ……………………………………………………………………………………..23

HL7-defined Table 0292 – Codes for Vaccines administered (code=CVX) ………………………………………..24

CVX – Vaccines Administered ……………………………………………………………………………………………………24

User-defined Table 0296 – Language……………………………………………………………………………………………38

User-defined Table 0297 – CN ID source ……………………………………………………………………………………..39

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page v 
Table of Contents

User-defined Table 0300 – Namespace ID …………………………………………………………………………………….39

HL7-defined Table 0301 – Universal ID type ………………………………………………………………………………..39

HL7-defined Table 0322 – Completion status ………………………………………………………………………………..39

HL7-defined Table 0323 – Action code ………………………………………………………………………………………..40

HL7-defined Table 0354 – Message structure ………………………………………………………………………………..40

HL7-defined Table 0356 – Alternate character set handling scheme …………………………………………………40

HL7-defined Table 0357 – Message error status codes ……………………………………………………………………40

User-defined Table 0360 – Degree ……………………………………………………………………………………………….42

User-defined Table 0361 – Application …………………………………………………………………………………………43

User-defined Table 0362 – Facility ………………………………………………………………………………………………43

User-defined Table 0363 – Assigning Authority …………………………………………………………………………….43

User-defined Table 0396 – Coding system ……………………………………………………………………………………45

User-defined Table 0441 – Immunization registry status …………………………………………………………………46

User-defined Table 0471 – Query Name ……………………………………………………………………………………….47

HL7 Table 0516 – Error Severity …………………………………………………………………………………………………47

User-defined Table 0533 – Application Error Code ………………………………………………………………………..47

CDC-defined NIP001- Immunization information source ………………………………………………………………48

CDC-defined NIP002 – Substance refusal reason…………………………………………………………………………..49

CDC-defined NIP003 – Observation identifiers …………………………………………………………………………….50

CDC-defined NIP004 – Contraindications, Precautions, and Immunities ………………………………………….53

Value Set Name – Immunization Funding Source ………………………………………………………………………….53

Value Set Name – Vaccination Contraindications ………………………………………………………………………….54

Value Set Name – Vaccination Reaction – IIS ……………………………………………………………………………….57

Value Set Name – Vaccination Special Indications – IIS …………………………………………………………………58

Value Set Name – Immunization Profile Identifiers – IIS ………………………………………………………………..58

Value Set Name – Immunization Schedule Identifiers – IIS …………………………………………………………….59

Value Set Name – History of Disease as Evidence of Immunity – IIS ……………………………………………….60

Value Set Name – Serological Evidence of Immunity – IIS …………………………………………………………….61

Value Set Code – PHVS_VISBarcodes_IIS ………………………………………………………………………………….62

Value Set Name – Funding Eligibility Observation Method (IIS) …………………………………………………….63

Value Set Name – VIS Vaccines (IIS) ………………………………………………………………………………………….63

APPENDIX B – GUIDANCE ON USAGE AND EXAMPLE MESSAGES ……………………………….. 1

Core Data Elements for an Immunization History …………………………………………………………………………. 2

Send Immunization History (VXU)……………………………………………………………………………………………… 5

Business Process ……………………………………………………………………………………………………………………….. 5

Example VXU # 1-Basic message:………………………………………………………………………………………………. 8

Storyboard: …………………………………………………………………………………………………………………………… 8

Message Example ………………………………………………………………………………………………………………….. 8

Example VXU #2 – Indicate client eligibility status for a funding program for vaccines administered: …10

Guidance for systems which collect eligibility at the encounter level: …………………………………………..10

Patient Eligibility Status: ………………………………………………………………………………………………………..10

Example VXU #3 – Include immunization history evaluation and forecast in VXU ……………………………13

Example VXU #4 – Send client specific conditions ……………………………………………………………………….13

Reaction Associated with a Previous Dose of Vaccine ………………………………………………………………..13

Evidence of immunity: …………………………………………………………………………………………………………..13

Contraindications to immunization: …………………………………………………………………………………………14

Factors which indicate the need for an immunization or a changed recommendation: …………………….14

Example VXU #6 –Delete an Immunization Record ……………………………………………………………………..15

VXU Example #7–Send Information About Vaccine Information Statement (VIS) ……………………………16

VXU Example #8—Send Information Indicating Immunization Refusal ………………………………………….17

VXU Example #9—Send Two Lot Numbers in RXA …………………………………………………………………….18

Two Vaccine Components Are Packaged Together And The Lot Numbers Are Inextricable Linked ….18

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page vi 
Table of Contents

Adjuvant Is Recorded Separately From Vaccine ………………………………………………………………………..18

VXU Example #10—Recording Birth Information ………………………………………………………………………..18

VXU Example #11—Recording an incompletely administered dose or a non-potent dose. …………………19

Send Acknowledgement ACK In Response To VXU ……………………………………………………………………..19

Send acknowledgement of success in ACK ……………………………………………………………………………….20

Send Error in ACK ………………………………………………………………………………………………………………..20

Example Return an Evaluated History and Forecast (RSP(Z42))……………………………………………………..22

Indicating the Schedule that was used: ……………………………………………………………………………………..26

Indicating Vaccine Group associated: ……………………………………………………………………………………….27

Reporting the Ordinal Position In A Series: ………………………………………………………………………………27

Reporting the Number of Doses in a Series: ……………………………………………………………………………..28

Reporting Next Dose Recommendation Dates (forecast only): …………………………………………………….28

Reporting Recommendation Reasons: ………………………………………………………………………………………29

Complete Example Of Evaluation And Forecasting: …………………………………………………………………..29

Important notes: …………………………………………………………………………………………………………………….32

Using The NTE Segment Associated With An OBX To Provide More Information: ……………………….32

Send Request for Complete Immunization History (QBP/RSP) ………………………………………………………32

Process for requesting Immunization History ……………………………………………………………………………32

Returning a list of candidate clients in response to QBP^Q11 query …………………………………………….33

Returning an immunization history in response to a Request for Immunization History query …………34

Acknowledging Query That Returns No Clients/Patients ……………………………………………………………….35

Acknowledging a Query that finds no candidate clients ……………………………………………………………..35

Acknowledging a query that finds more candidates than requested ………………………………………………36

Using a Two-step process to request an immunization history ……………………………………………………..36

Receiving system determines that message has errors ………………………………………………………………..38

Message Is Rejected Due to Unrecognized Message Type …………………………………………………………..39

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page vii 
Index of Tables

INDEX OF TABLES

Table 2-1 Actors and Goals for Messaging ………………………………………………………………………….. 8

Table 3-2 Receiving Application Conformance …………………………………………………………………… 25

Table 4.1 Data Types ……………………………………………………………………………………………………… 30

Table 4.2 Coded Element (CE) ………………………………………………………………………………………….31

Table 4.3 Coded Element (CE) for Text Only RXA-9 …………………………………………………………… 33

Table 4.4 Composite Quantity with Units (CQ) …………………………………………………………………… 33

Table 4.5 Coded with Exceptions (CWE)…………………………………………………………………………… 35

Table 4.6 Extended Composite ID with Check Digit (CX)………………………………………………………36

Table 4.7 Date (DT) ……………………………………………………………………………………………………….. 38

Table 4.8 Date With Precision to Day (DT_D) ……………………………………………………………………..39

Table 4.9 Date/Time (DTM) ………………………………………………………………………………………………39

Table 4.10 Entity Identifier (EI) ………………………………………………………………………………………….40

Table 4.11 Error Location (ERL) ………………………………………………………………………………………. 41

Table 4.12 Family Name …………………………………………………………………………………………………..43

Table 4.13 Formated Text ………………………………………………………………………………………………. 43

Table 4.14 Hierarchical Designator (HD)  ……………………………………………………………………………44

Table 4.15 ID Data Type …………………………………………………………………………………………………. 45

Table 4.16 Coded Values for User Defined Tables (IS) ………………………………………………………..45

Table 4.17 Location with Address Variation 2 …………………………………………………………………….. 46

Table 4.18 Message Type (MSG) …………………………………………………………………………………….. 47

Table 4.19 Numeric (NM) ………………………………………………………………………………………………… 48

Table 4.20 Processing Type (PT) …………………………………………………………………………………….. 49

Table 4.21 Street Address (SAD) ……………………………………………………………………………………….49

Table 4.22 Sequence Id (SI) ……………………………………………………………………………………………..50

Table 4-22 String (ST) ……………………………………………………………………………………………………. 50

Table 4.23 Time Stamp (TS) ……………………………………………………………………………………………..51

Table 4.24 Time Stamp Precision to Month (TS) ………………………………………………………………….52

Table 4.25 Time Stamp No Time Zone (TS_NZ) ………………………………………………………………… 52

Table 4.26 Time Stamp with Time Zone (TS_Z) …………………………………………………………………. 53

Table 4.27 Version ID (VID) …………………………………………………………………………………………….. 54

Table 4.28 Extended Address (XAD) ………………………………………………………………………………….55

Table 4.29 Extended Composite ID Number and Name (XCN) ……………………………………………..57

Table 4.30 Extended Composite ID Number and Name for Organizations (XON) ……………………60

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page viii 
Index of Tables

Table 4.31 Extended Person Name (XPN) ………………………………………………………………………….61

Table 4.32 Extended Person Name (XPN_M) ……………………………………………………………………..63

Table 4.33 XTN Extended Telecommunication Number (XTN) ………………………………………………65

Table 5.1 VXU Segment Usage ……………………………………………………………………………………….  71

Table 5-2 Insurance Segment (IN1)………………………………………………………………………………….. 74

Table 5-4 Message Header Segment (MSH) …………………………………………………………………….. 79

Table 5-5 Next of Kin Segment (NK1) ………………………………………………………………………………. 85

Table 5-6 Note Segment (NTE) ……………………………………………………………………………………….. 89

Table 5-7 Observation Segment (OBX) …………………………………………………………………………….. 90

Table 5-8 Application Conformance Statements ………………………………………………………………… 95

Table 5-9 Common Order Segment (ORC) ……………………………………………………………………….. 99

Table 5-10 Patient Demographic Segment (PD1) ………………………………………………………………104

Table 5-11 Patient Identifier Segment (PID) …………………………………………………………………….. 108

Table 5-12 Pharmacy/Treatment Administration (RXA) ………………………………………………………. 115

Table 5-13 Pharmacy/Treatment Route (RXR) …………………………………………………………………. 122

Table 6-1 Message Acknowledgement Segment (ACK) ……………………………………………………. 127

Table 6-2 Error Segment (ERR) …………………………………………………………………………………….. 128

Table 6-3 Message Acknowledgement Segment (MSA) ……………………………………………………. 131

Table 6-4 Message Header Segment (MSH) …………………………………………………………………… 132

Table 7-5 QPD Input Parameter Specification ………………………………………………………………….. 145

Table 7-7 Response Control Parameter ………………………………………………………………………….. 151

Table 8-1 Return Complete Immunization History Response GrammarSP^K11 …………………… 154

Table 8-3 Insurance Segment (IN1)………………………………………………………………………………… 159

Table 8-4 Message Acknowledgement Segment (MSA) ……………………………………………………. 163

Table 8-5 MSH for Request Complete Immunization History Query …………………………………….  164

Table 8-6 Next of Kin Segment (NK1) …………………………………………………………………………….. 168

Table 8-7 Note Segment (NTE) ……………………………………………………………………………………… 171

Table 8-8 Observation Segment (OBX) …………………………………………………………………………… 173

Table 8-10 Common Order Segment (ORC) ……………………………………………………………………..178

Table 8-11 Patient Demographic Segment (PD1) …………………………………………………………….. 182

Table 8-12 Patient Identifier Segment (PID) …………………………………………………………………….. 185

Table 8-13 Query Acknowledgement Segment (QAK) ………………………………………………………. 189

Table 8-14 QPD Input Parameter Specification (QPD) ……………………………………………………… 190

Table 8-15 Pharmacy/Treatment Administration (RXA) ………………………………………………………192

Table 8-16 Pharmacy/Treatment Route (RXR) …………………………………………………………………. 196

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/12014 Page ix 
Index of Tables

Table 9-1 Base Response Grammar RSP^K11 ……………………………………………………………….  198

Table 9-2 Error Segment (ERR) …………………………………………………………………………………….. 199

Table 9-3 Message Acknowledgement Segment (MSA) ……………………………………………………. 201

Table 9-4 MSH for Request Complete Immunization History Query ……………………………………. 202

Table 9-5 Next of Kin Segment (NK1) …………………………………………………………………………….. 206

Table 10-2 Error Segment (ERR) …………………………………………………………………………………… 218

Table 10-4 Message Acknowledgement Segment (MSA) ………………………………………………….. 220

Table 11-4 Error Segment (ERR) ……………………………………………………………………………………. 232

Table 11-5 Message Acknowledgement Segment (MSA) ………………………………………………….. 234

Table 12-3 Observation Segment (OBX) …………………………………………………………………………. 251

Table 12-5 Common Order Segment (ORC) ……………………………………………………………………. 256

Table 12-6 Patient Identifier Segment (PID) …………………………………………………………………….. 260

Table 12-7 Query Acknowledgement Segment…………………………………………………………………. 264

Table 12-8 QPD Input Parameter Specification………………………………………………………………….265

Table 12-9 Pharmacy/Treatment Administration (RXA) ………………………………………………………267

Table 12-10 Pharmacy/Treatment Route (RXR) …………………………………………………………………271

Table 13-1 Batch Header Segment (BHS) ………………………………………………………………………. 274

Table 13-2 Batch Trailer Segment (BTS) …………………………………………………………………………. 276

Table 13-3 File Header Segment (FHS) ………………………………………………………………………….. 277

Table 13-4 File Trailer Segment (FTS) ……………………………………………………………………………. 278

Release 1.1 Changes ………………………………………………………………………………………………………. 1

Release 1.2 Changes ………………………………………………………………………………………………………. 1

Release 1.3 Changes ………………………………………………………………………………………………………. 2

Release 1.4. Changes ……………………………………………………………………………………………………… 4

Release 1.5 Changes ………………………………………………………………………………………………………. 5

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page x 
Introduction

TABLE OF FIGURES

Figure 1 Immunization Messaging Use Cases ……………………………………………………………………. 11

Figure 2 VXU Process Model ………………………………………………………………………………………….. 15

Table 3-1 Receiving System Processing Rules ………………………………………………………………….. 21

Table 3-2 Sending Application Conformance …………………………………………………………………….. 23

Table 3-3 Message Element Attributes ……………………………………………………………………………… 26

Table 4-3 Coded Element (CE) for Text Only RXA-9 …………………………………………………………… 33

Figure 36  Send Immunization History Sequence Diagram …………………………………………………. 69

Figure 37 Send VXU Activity Diagram ………………………………………………………………………………. 70

Figure 38  Send Immunization History Sequence Diagram ……………………………………………….. 125

Figure 39 Activity Diagram-Return Acknowledgement ………………………………………………………. 126

Table 7-1 Request Complete Immunization History Query Profile ………………………………………. 136

Figure 40 Sequence Diagram-Return Complete Immunization History ……………………………….. 138

Figure 41 Request Complete History and Responses Activity Diagram ………………………………. 139

Table 7-3 Z34 Request Complete Immunization History ……………………………………………………. 141

Table 7-4 MSH Specification for Request Complete Immunization History Query ………………… 142

Table 7-6 QPD Input Parameter Field Description and Commentary ………………………………….. 146

Table 8-2 Error Segment (ERR) …………………………………………………………………………………….. 156

Table 9-1 Base Response Grammar RSPAK11…………………………………………………………………198

Table 9-6 QPD Input Parameter Specification ………………………………………………………………….. 209

Table 9-7 PID Patient Identification Segment ……………………………………………………………………. 211

Figure 42  Return Acknowledgement ……………………………………………………………………………… 216

Table 10-1 Base Response Grammar RSP^K11 ………………………………………………………………. 217

Table 10-3 Query Response Possibilities ………………………………………………………………………… 219

Table 10-5 MSH Specification for Request Complete Immunization History Query ………………. 221

Table 10-6 QPD Input Parameter Specification ………………………………………………………………… 223

Table 11-1 Request Evaluated Immunization History and Forecast Query Profile ………………… 226

Table 11-2 Response Grammar to Different Outcomes …………………………………………………….. 227

Figure 43 Return Immunization Evaluated History Sequence Diagram ……………………………….. 228

Figure 44 Activity Diagram -Response to Different Outcomes ……………………………………………. 229

Table 11-3 Response to Different Outcomes ……………………………………………………………………. 230

Table 11-4 Z44 Request Complete Immunization History ………………………………………………….. 231

Table 11-6 MSH Specification for Request Complete Immunization History Query ……………….. 235

Table 11-7 QPD Input Parameter Specification ………………………………………………………………… 237

Table 11-8 QPD Input Parameter Field Description and Commentary …………………………………. 239

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 1 
Introduction

Table 11-10 RCP Response Control Parameter Field Description and Commentary …………….. 244

Table 12-1 Return Evaluated Immunization History and Forecast Response Grammar RSP^K11

 ………………………………………………………………………………………………………………………….. 246

Table 12-2 MSH Specification for Return Evaluated Immunization History and Forecast Response

 ………………………………………………………………………………………………………………………….. 248

Table A-1 Appendix A Revision History ……………………………………………………………………………….. 1

Table B-1 Appendix B Revision History ………………………………………………………………………………. 1

Table B-2–Immunization History Core Data Elements ………………………………………………………….. 2

Figure B-45-VXU Business Process…………………………………………………………………………………… 6

Table B-2 — Eligibility Outcomes ……………………………………………………………………………………….. 11

Figure B-46 Sequence Diagram-Deleting an Immunization Record ……………………………………… 15

Table B-3–Birth Information Fields …………………………………………………………………………………… 18

Table B-3–Codes Supporting Messaging Evaluation and Forecasting ………………………………….. 23

Table B-4–Due Date Definitions ………………………………………………………………………………………. 28

Figure B-3–Sequence Diagram Acknowledging Response Indicating No Matchesa ………………. 35

Figure B-3– Sequence Diagram -Two Step Request ………………………………………………………….. 37

1. Introduction

Immunization Information Systems (IIS) are centralized population based repositories of immunization

related information. They receive and share data on individual clients/patients1 with a number of other

systems, including Electronic Health Record systems (EHR-S). Health Level Seven (HL7) is a nationally

recognized standard for electronic data exchange between systems housing health care data. The HL7

standard is a key factor that supports this two-way exchange of information because it defines a syntax or

grammar for formulating the messages that carry this information. It further describes a standard

vocabulary that is used in these messages. It does not depend on specific software, that is, it is platform

independent.

This document represents the collaborative effort of the American Immunization Registry Association

(AIRA) and the Centers for Disease Control and Prevention (CDC) to improve inter-system communication

of immunization records. The effort has received input from the National Institute of Standards and

Technology (NIST) to improve the capacity to test conformance with this Implementation Guide.  In

addition, this Guide addresses a need to specify usage requirements for data elements that are not included

in the standard HL7 usage designations. This implementation guide replaces the Implementation Guide for

Immunization Data Transaction Using Version 2.3.1 of the HL7 Standard Protocol, and previous versions

of this Guide. It is based on HL7 Version 2.5.1, as published by the HL7 organization (www.hl7.org). In

addition, it pre-adopts a number of features of HL7 Version 2.7.1, such as data types and the conformance

model (defined in Chapter 2B).

As HL7 has developed and published new versions of the standard, it has sought to maximize the ability of

implementations, based on newer versions to be able to accept messages from earlier versions. Based on

this, we anticipate that faithful implementations of this Guide will be able to accept most immunization

1 Note that client, patient and recipient are terms which we interchangeably in this document.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 2 
Introduction

messages based on the 2.3.1 Guide. Note that variations in current 2.3.1 interfaces increase the risk that

faithful 2.5.1 implementations will encounter problems with 2.3.1 messages.

Implementations that are supporting Version 2.3.1 messages should continue to follow the specifications of

2.3.1 messages described in the Implementation Guide Version 2.2, June 2006.

Intended Audience

This Guide has two audiences. The first is the system managers that must understand this process at a high

level. The second is the technical group from IIS and EHR-S that must implement these guidelines. For

them we strive for an unambiguous specification for creating and interpreting messages. Our goal is for this

Guide to be a bridge between the two.

It is important to note that HL7 specifies the interface between 2 systems. It does not specify how any

given system is implemented to accomplish the goals of messaging.

Scope

This Guide is intended to facilitate the exchange of immunization records between different systems2. This

includes

• sending and receiving immunization histories for individuals

• requesting immunization histories for individuals

• requesting an evaluated history and forecast for individuals

• responding to requests for immunization histories by returning immunization histories

• responding to requests for evaluated history and forecast

• acknowledging receipt of immunization histories and requests for immunization histories

• reporting errors in the messaging process

• sending observations about an immunization event (this may include patient eligibility for a

funding program, reactions, forecasts and evaluations).

The Guide is not intended to specify other issues such as

• business rules, which are not implicit in HL7, applied when creating a message

• business rules, which are not implicit in HL7, applied when processing a received message

• a standard transport layer

• search process used when responding to a query

• business rules used to deduplicate clients or events

• management of vaccine inventory

• maintenance of Master Person Index (MPI).3

2 The exchange partners could be IIS, EHR-S. or other health data systems.

3 Note that requesting an immunization history may require interaction with an MPI or other identity source. Those using these

services should consult with profiles or implementation guides that support this. Integrating the Healthcare Enterprise (IHE) has

profiles that support MPI maintenance and identity resolution. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 3 
Introduction

Local implementations are responsible for the important issues described above. One way to insure success

is to publish a local profile or implementation guide that outlines the local business rules and processes.

These guides may further constrain this Guide, but may not contradict it. This Guide will identify some of

the key issues that should be addressed in local profiles.

This Guide makes the following assumptions:

• Infrastructure is in place to allow accurate and secure information exchange between information

systems. 4

• Providers access immunization information through either an EHR-S or immunization information

system (IIS).

• Privacy and security has been implemented at an appropriate level.

• Legal and governance issues regarding data access authorizations, data ownership and data use are

outside the scope of this document.

• The immunization record and demographic record for each patient contains sufficient information

for the sending system to construct the immunization and demographic message properly.

• External business rules are assumed to be documented locally.  
It is important to be able to accept complete immunization histories from different sources and have a

method for integrating them. This implies that a system should not assume that any record sent is “new”. If

the system makes this assumption and receives a complete history that has overlapping immunization

records, there is a risk for duplicate records.

There is “best practice” guidance on handling this from the American Immunization Registry Association

(AIRA) in the Modeling Immunization Registry Operations Workgroup (MIROW) documents available the

AIRA website. (immregistries.org)

Organization and Flow

The first two chapters are meant to lay out what can be done and why. The chapters that follow them

describe and specify how. Message profiles will support the major use cases outlined below.  Each profile

will be in a separate chapter. All profiles will rely on the data type definitions in Chapter 4. Several

appendices support implementers with value sets and examples of use.

Boxed notes are used to call attention to areas where there are changes from the version 2.3.1

Implementation Guide or areas where readers should pay special attention.

Chapter 1-Introduction

This chapter describes the scope of the Guide and gives supporting background.

Chapter 2-Actors, Goals and Messaging Transactions

Chapter 2 describes the business motivations that this Guide will support. It will describe the entities

(actors) that will rely on the messages. It will lay out the transactions that will support the goals of these

4 This infrastructure is not specified in this document, but is a critical element to successful messaging. Trading partners must select a

methodology and should specify how it is used. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 4 
Introduction

actors (use cases). Finally, it will describe the broader context that this messaging occurs in. There are

supporting business processes outside of the actual messaging that are keys to success.

Chapter 3-Messaging infrastructure

Chapter 3 focuses on the underlying rules and concepts that are the basis for HL7 messaging. It will

illustrate the components of messages, the grammatical rules for specifying the components and

subcomponents.

Chapter 4-Data-type Definitions

This chapter will describe and specify all data types anticipated for use by the messages supported by this

Guide. Where there are subcomponents to a data type, it will specify any rules related to use. Elements that

require the use of coded values will draw on the value sets specified in appendix A.

Chapter 5-Profile Z22 Send Unsolicited Immunization Update Using a VXU

Chapter 5 is the profile specifying a constrained VXU message.

Chapter 6- Profile Z23 Return an Acknowledgement

Chapter 6 is the profile specifying a constrained ACK message.

Chapter 7- Profile Z34 Request a Complete Immunization History

Chapter 7 is the profile with the specifications for a query requesting a Complete Immunization History.

Chapter 8—Profile Z32 Return Complete History

Chapter 8 is the profile with the specifications for a response returning a Complete Immunization History.

Chapter 9-Profile Z31 Return List of Candidates

Chapter 9 is the profile with the specifications for a response returning a list of candidate matches.

Chapter 10- Profile Z33 Return Response with No Matches

Chapter 10 is the profile with the specifications for a response returning no matches.  It may return errors.

Chapter 11- Profile Z44 Request an Evaluated Immunization History and Forecast

Chapter 11 is the profile specifying a query requesting an evaluated history and forecast. It includes a child

profile for responses to this query.

Chapter 12-Profile Z42 Return Evaluated History and Forecast

Chapter 12 is the profile specifying the response to a Request for Evaluated Immunization History and

Forecast.

Chapter 13—Batch File Segments

This Chapter gives specifications for packaging messages into batches and files of batches.

Appendix A-Value Sets

This appendix lists expected values for all coded data elements used in this Guide. It is a point in time view

of the value sets.

Appendix B- Message examples

This appendix will show detailed examples of how to implement the messages specified in the body of the

Implementation Guide. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 5 
Introduction

Note that the focus of this guide is on the format and grammar of the messages between systems. The

activities shown within a system are intended to put the message in context and to highlight the local

responsibilities for successful messaging.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 6 
Chapter 2: Actors, Goals, and Messaging Transactions

2. Actors, Goals, and Messaging Transactions

This chapter will describe the actors (entities) that may be involved in sending or receiving immunization-

related messages. It will list and describe the use cases (goals) that they have that can be met by the

messages. It will illustrate the messaging interface in context. Finally, it will associate specific HL7

messages with these goals.

Note that there are a number of supporting processes that are not included within the messaging

specifications. They are vital to success, but do not belong in this Implementation Guide, but rather in local

business rules documentation.

Actors and Goals

There are a number of primary actors involved in data exchange. These include

• Immunization Information System (IIS)

• Electronic Health Record Systems (EHR-S) and other systems 5

• An actor with a supporting role may be a Master Person Index (MPI)6.

• An actor with a supporting role may be a Health Information Exchange (HIE)

We will focus on the first 2 actors but will illustrate how the MPI actor may be integrated. These actors can

be suppliers of information/data and consumers/requesters of data. We will consider the initiator of a

messaging conversation the sender and the target of this first message the receiver. Obviously, a sender may

receive messages. For instance, a sender initiates a request for an immunization history for a client. The

receiver responds with a message that is received by the initiating sender. For clarity, the initiator will keep

the label of sender.

Note that we do not assume that the sender or receiver is a specific data source (IIS or EHR). One IIS may

query another IIS or an EHR-S. Similarly, an EHR-S may send an immunization history to another EHR-S.

Other actors have an interest in the functions of an IIS and messaging. These include:

• Clients/patients

• Users

• Policy makers

• Researchers

• Public Health agencies

• Clinicians

• Billing systems

These actors will not be directly addressed in this Guide. They interact with the primary actors to

accomplish their needs.

5 The diagrams often show an IIS and an EHRs/other system. The other system may be an IIS.

6 A Master Person Index is used by some health data systems to cross-reference a person’s identifiers across these systems. If system A

needs the person’s id from system B, then it may retrieve it from the MPI. The Patient Idenitifying Cross-referencing (PIX)  query

asks for one system’s personal identifier, based on another system’s identifier. PIX is a profile published by Integrating the Healthcare

Enterprise (IHE). 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 7 
Table 2-1 Actors and Goals for Messaging

Chapter 2: Actors, Goals, and Messaging Transactions 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 8 
TABLE 2-1 ACTORS AND GOALS FOR MESSAGING

Actor Responsibility Messaging Goals

Immunization Information

System (IIS)

Provide access to a complete,

consolidated immunization record for

each person in its catchment area 
Supply individual immunization

records to authorized users and

systems 
Support aggregate reporting and

analysis 
Evaluate immunization history and

make recommendations for next

doses 
Store medical conditions that affect

what vaccines are recommended 
Receive immunization histories and

updates 
Receive demographic updates 
Receive requests for individual

records 
Receive observations about a person 
Send observations about a person 
Send immunization records to other

systems 
Send other systems evaluated

immunization histories and forecasts

of next doses due for a specific

person 
Request immunization record 
Request person id 
Acknowledge receipt of message 
Report processing errors from receipt

of message 
Chapter 2: Actors, Goals, and Messaging Transactions

TABLE 2-1 ACTORS AND GOALS FOR MESSAGING

Actor Responsibility Messaging Goals

Electronic Health Record

system (EHR-S)

House a person’s electronic health

record 
Make a person’s record available to

authorized persons 
Provide decision support for clinical

decisions. 
Receive immunization histories and

updates 
Receive demographic updates 
Receive requests for individual

records 
Send immunization records to IIS 
Send demographic data  
Receive observations about a person 
Send observations about a person 
Request Immunization record 
Request person id

Acknowledge receipt of message 
Report processing errors from receipt

of message 
Request evaluation on an

immunization history and

recommendations for next dose on a

given Schedule, such as ACIP

Master Person Index or

other identity broker.

Maintain a list of patients and

identifiers for a set of persons 
Supply identifiers for other system’s

use 
Be a central demographic supplier

for participating systems 
Provide cross-reference for

identifiers for participating systems.

Send id for an individual for use in a

record request or record update 
Receive request for person id. 
Return complete demographic data

for an individual from central

demographic store 
The table lists a number of messaging needs that relate to IIS and their trading partners. These are all

candidates for HL7 messaging. Some are not currently implemented, but give us the landscape that should 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 9 
Chapter 2: Actors, Goals, and Messaging Transactions

be considered. Note that the messaging for maintaining of an MPI is out of scope for this Implementation

Guide.

Another way to organize these tasks or goals is to decompose the goals of the entities (actors) into the

various roles they may play. These roles include:

1. Immunization history supplier

2. Immunization history consumer

3. Identity resolution broker

Each of the actors above may have the capacity and interest to support some constellation of these roles.

This approach is useful for system design and implementation and encourages a services approach to

development. Since the goal of this chapter is to provide a non-technical view to help system managers

understand how messaging can meet their needs, we will focus on the business entities and their goals.

High-Level View of Use Cases

We can map these actors and messaging goals to use cases. The following diagram maps the messaging

goals of the various players to use cases. These use cases will be defined below. These use cases are not

intended to be the basis of a software design process.

Several paths may accomplish the request for immunization history. Systems will return an immunization

history when they are confident that the person requested has been identified. One path separates identity

resolution from the request for immunization history. Another includes implicit identity resolution.  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 10 
Chapter 2: Actors, Goals, and Messaging Transactions 
Figure 1 Immunization Messaging Use Cases 
An IIS is an Immunization Information System. An IIS AO is an IIS Authorized Organization. It is an entity

that is authorized to submit data to an IIS and to request data from an IIS.

Use Case Descriptions

Use Case 1—Send Immunization History

Goal: To send an immunization history for an individual client from one system to another. In addition to

EHR-S and IIS, other systems such as vital records systems or billing systems could use this message to

send immunization histories. This goal includes receiving the immunization history.

Supporting HL7 version 2.5.1 Message Type: VXU – Profile Z22

Precondition: A user or other actor requests that the sending system send an immunization history.

Post-condition: The receiving system has accepted the immunization history. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 11 
Chapter 2: Actors, Goals, and Messaging Transactions

Use Case 2—Request Complete Immunization History

Goal: The goal of this use case is to request and receive a complete immunization history from another

system.

Supporting HL7 Version 2.5.1 Message Type: QBP –Profile Z34 and RSP –Profile Z32.

Precondition: A user or other actor requests that the sending system send a request for an immunization

history using demographic information and/or other identifiers.

Post-condition: The requesting system receives an immunization history.  Note that if no matches are

found or there are errors, no immunization history will be returned.

There are 5 possible results:

1. One client matches exactly7 the criteria sent

2. One or more clients match the criteria sent (inexact match) 8

3. No clients match the criteria sent

4. An exact match is found but they have requested that their data not be shared

5. There were errors or other problems

Note that systems must deal with the situation where a Client has indicated that his/her records must be

protected. (Only the owning provider may view)  This should be clearly documented.

Use Case 3—Request Evaluated History and Forecast

Goal: The goal of this use case is to request and receive an evaluated immunization history and forecast of

next doses due from another system.

Supporting HL7 Version 2.5.1 Message Type: QBP –Profile Z44 and RSP –Profile Z42.

Precondition: A user or other actor requests that the sending system send a request for an evaluated history

using demographic information and/or other identifiers.

Post-condition: The requesting system receives an evaluated immunization history and forecast.  Note that

if no matches are found or there are errors, no immunization history will be returned. Typically, this is

presented to the person who requested the evaluated history and forecast.

There are 5 possible results:

1. One client matches exactly9 the criteria sent

2. One or more clients match the criteria sent (inexact match) 10

3. No clients match the criteria sent

4. An exact match is found but they have requested that their data not be shared.

5. There were errors or other problems

7 The definition of “exact” is a local business rule and should be documented locally.

8 If more than one client has a high-confidence match with the query parameters, this is an inexact match.

9 The definition of “exact” is a local business rule and should be documented locally.

10 If more than one client has a high-confidence match with the query parameters, this is an inexact match. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 12 
Chapter 2: Actors, Goals, and Messaging Transactions

Note that systems must deal with the situation where a Client has indicated that his/her records must be

protected. (Only the owning provider may view)  This should be clearly documented. 
Use Case 4—Send Demographic Data

Goal: The goal of this use case is to send demographic data about a person. It may be an update or a new

record. This use case does not have responsibility for the processing of the message.

Precondition: A user or other actor requests that the sending system send demographic data.

Post-Condition: The receiving system processes and accepts the demographic data.

Demographic data may be sent in VXU messages (for example , the Z22 profile defined in this

Implementation Guide can be used to carry demographic only data)  or ADT messages.  Profiles for ADT

are not included in this Implementation Guide.  Refer to the HL7 Standard and to profiles published by

groups such as IHE.

Use Case 5–Acknowledge Receipt

Goal:

The goal of this use case is to acknowledge receipt of a message. This can be an immunization history,

request for immunization history, demographic update, observation report or request for personal id. It may

indicate success or failure. It may include error messages. One example occurs when a query is well-

formed, but finds no candidates. In this case the acknowledgement reports this fact.

Supporting HL7 Version 2.5.1 Message Type: ACK –Profile Z23 and RSP – Profile Z33.

Use Case 6—Report Error

Goal:

The goal of this use case is to send error messages related to messages. These errors could result in

rejection of the message or parts of the message.

Supporting HL7 Version 2.5.1 Message Type: ACK –Profile Z23 and RSP – Profile Z33.

Messaging in the Context of the Business Process

While this document focuses on the format and content of messages from one system to another, it is useful

to understand where this fits into the bigger picture of interoperable communication.

The following diagram illustrates the most common message exchange in the IIS context, the VXU

(unsolicited immunization record). When the sending system wishes to send a VXU to a receiving system,

it must do several steps in preparation:

o

o

o

o

Create message 11

Assemble data on person of interest

Build the VXU message with this data

Send the message

11 Identifying which client’s record to send is an important consideration, but outside the scope of this document. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 13 
Chapter 2: Actors, Goals, and Messaging Transactions

o

o

Connect to the receiving system. The partners must agree on how this is done.

The sending system now sends the message over the connection and the receiving system

catches the message.

The receiver accomplishes the following steps:

o Process the received message

o

o

o

Determine that the message is in the appropriate format.

Parse the message into a format that it uses.

Evaluate the message components to determine that these are correctly formatted and

specified.

o

o

Send an acknowledgement to the sender, indicating the message has been successfully processed.

Integrate the received record into the existing data base. 12

o

o

o

Deduplicate on client to be sure that each client only has one record.

Deduplicate the events (immunizations, for instance).

Insert or update data.

o The sending system accepts the acknowledgment and processes it.

Obviously, the interaction may be more complex than this13. The connection may be rejected or fail. The

message may be poorly formed or may not contain required information. Part of the message may contain

errors, but these errors are not sufficient to reject the entire message.

The business rules for both the sender and the receiver should be clearly specified so that each side

understands how the message will be handled.

When illustrating the processes involved in each message below, we will not elaborate on the processes that

occur outside the actual message exchange.

12 Local business rules determine how this occurs and should be documented clearly.

13 See Appendix B for illustrations of the processing rules expected when handling HL7 messages. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 14 
Chapter 2: Actors, Goals, and Messaging Transactions 
Figure 2 VXU Process Model

 Note: It is vital that each implementation clearly document the business rules and special

handling in a local Implementation Guide or Profile. Local implementers may place further

constraints on the specifications found in this Guide. Optional fields or required fields that are

allowed to be empty in this Guide may be made required. Repeating fields may be constrained to

fewer repetitions.

Core Data Elements of an Immunization History

Systems that support immunization information have a number of important responsibilities including:

• Consolidation of Immunization records from various sources

• Supplying consolidated immunization history to users 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 15 
Chapter 2: Actors, Goals, and Messaging Transactions

• Forecasting next doses due 14

• Evaluating vaccine doses administered15

• Supporting inventory management

• Supporting reports on vaccine usage by eligibility for funding programs

• Assessing coverage rates in a population

• Protecting the privacy of immunization data

• Supporting generation and sending of reminder notices

• Supporting tracking doses administered by lot so that recipients may be notified in the case where

the lot is recalled

Each if these requires specific data. The National Vaccine Advisory Committee (NVAC) has identified a

core set of data elements to support these responsibilities. These core data elements have been used to

determine the usage in this guide.  It is expected that systems that are using this Implementation Guide will

be able to support these data elements and include them in a message. See Core Data Elements in Appendix

B.

These core data elements will also be included in conformance statements. This may be at the HL7 message

component level or a data concept level. 16It is important that these data elements are supported by both

sender and receiver.

Key Technical Decisions

One of the primary features of this implementation guide is its focus on key points of broad

interoperability.

Pre-Adoption Of Some Features Of HL7 Version 2.7.1

This implementation Guide pre-adopts some features of HL7 Version 2.7.1 to support improved

consistency in implementation with the goal of improving interoperability. These include:

• Conformance statements

• Conditional predicates

• Usage guidance

• New fields in MSH segment

Use of Vocabulary Standards

This guide calls for specific vocabulary standards for the exchange of immunization information such as

LOINC and SNOMED. Standard vocabularies enable automated decision support for patient healthcare, as

well as for public health surveillance of populations. Terminology is updated periodically and it is best

practice to use the most current version of the coding system.

14 The ability to send in an HL7 message is required for systems the output from clinical decisions support engines.  The ability to

consume is required for systems requesting evaluated history and forecast.

15 The ability to send in an HL7 message is required for systems the output from clinical decisions support engines.  The ability to

consume is required for systems requesting evaluated history and forecast.

16 For instance, the vaccine administered is specified as a required element of the RXA segment by indicating a Usage of Required on

the RXA-5 field. The funding program eligibility is specified as conditionally required in a conformance statement not tied to a

specific HL7 message component. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 16 
Chapter 2: Actors, Goals, and Messaging Transactions

Processing Mode

Consolidation of immunization records from multiple sources is a complex process. Receiving systems

have varying rules for this process. They expect complete immunization histories (i.e. all immunization

information known to sender). They don’t process in Snapshot Mode. (Incoming data completely replaces

existing data)

Note that receiving systems are responsible for publishing the business rules they apply when consolidating

records from different sources.

Message Profiles

This implementation guide defines a number of constrainable profiles. These profiles will be identified in

the Message Header (MSH-21).

Conventions

This guide adheres to the following conventions:

• The guide is constructed assuming the implementer has access to the Version 2.5.1 of the HL7

Standard. Although some information from the standard is included in this implementation

guide, much information from the standard has not been repeated here.

• The rules outlined in HL7 2.7.1, Chapter 2B, Section 2B5, Conformance Using Message

Profiles, were used to document the use case for, and constraints applied to, the messages

described in this guide.

• Data types have been described separately from the fields that use the data types.

• No conformance information is provided for optional message elements. This includes length,

usage, cardinality, value sets and descriptive information. Implementers who want to use

optional message elements should refer to the base HL7 V2.5.1 Standard to determine how

these optional message elements will be used.

• This guide uses “X” as a conformance usage indicator very sparingly. Where the underlying

standard indicates the segments/field/component is present for backwards compatibility (“B”)

or withdrawn (“W”) an “X” will be used. Some conditional elements may have a usage of “X”

if the predicate condition is the only case where the element is used. For all other

fields/components “O” is used to enable trading partners to explore additional capabilities.

Note that without a clearly agreed to complementary profile between trading partners, a sender

does not have to send any elements marked as an “O”, nor does a receiver have to process any

elements marked as an “O”.  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 17 
Chapter 3: HL7 Messaging Infrastructure

3. HL7 Messaging Infrastructure

This section will contain a basic description of the terms and definitions, which are used in this document

in order to understand the Health Level 7 standard as it applies to immunization information systems. More

detail may be found in the HL7 2.5.1 standard in Chapters 1, 2 and 2A.

Keywords

The following keywords in this document are to be interpreted as follows:

MUST or the terms “REQUIRED” or “SHALL”, mean that the definition is an absolute requirement of the

specification.

MUST NOT or the phrase “SHALL NOT”, mean that the definition is an absolute prohibition of the

specification.

SHOULD or the adjective “RECOMMENDED”, mean that there may exist valid reasons in particular

circumstances to ignore a particular item, but the full implications must be understood and carefully

weighed before choosing a different course.

SHOULD NOT or the phrase “NOT RECOMMENDED” mean that there may exist valid reasons in

particular circumstances when the particular behavior is acceptable or even useful, but the full implications

should be understood and the case carefully weighed before implementing any behavior described with this

label.

MAY or the adjective “OPTIONAL”, mean that an item is truly optional. One software supplier may

choose to include the item to enable certain capabilities while another software supplier may omit the same

item. In either case, the communication partner cannot be expected to either provide it (sender) or process it

(receiver) without clear and voluntary agreement between the partners.

An implementation which does not include a particular segment/field/component marked as optional

MUST be prepared to interoperate with another implementation which does include the optional

segment/field/component, though perhaps with reduced functionality. In the same vein an implementation

which includes a particular segment/field/component marked as optional MUST be prepared to interoperate

with another implementation which does not include the optional segment/field/component.

HL7 definitions

The terms below are organized to move from the message to subsequently more granular components.

Message: A message is the entire unit of data transferred between systems in a single transmission. It is a

series of segments in a sequence defined by the message specifications. These specifications are based on

constraints to the HL7 specifications, as described in an Implementation Guide.

Example:

Segment Description

MSH|… Message Header

PID|… Personal Identifiers 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 18 
Chapter 3: HL7 Messaging Infrastructure

ORC|… Order Segment

RXA|… Vaccine administered segment 
The table above shows an immunization history for the patient identified in the PID. This person has one

immunization ordered and recorded.

Segment Group: A segment group is a logical collection of segments. Segment groups defined within a

message may be required or optional, may occur only once or may be allowed to repeat.

Segment: A segment is a logical grouping of data fields. Segments within a defined message may be

required or optional, may occur only once, or may be allowed to repeat. Each segment is named and is

identified by a segment ID, a unique 3-character code.

Example:

PID|||12322^^^Assigning authority^MR^||Savage^Robert^^^^^L^|

This PID segment includes a medical record number and a person’s name.

Field: A field is a string of characters and is of a specific data type. Each field is identified by the segment

it is in and its position within the segment; e.g., PID-5 is the fifth field of the PID segment. A field is

preceded by the | character.

Component: A component is one of a logical grouping of items that comprise the contents of a coded or

composite field. Within a field having several components, not all components are required to be valued.

Example: RXA-5 administered code is composed of 6 components.

Code 1^text 1^code set 1^alternate code 2^alt text 2^alt code set 2

Null and empty fields: The null value is transmitted as two double quote marks (“”). A null-valued field

differs from an empty field. An empty field should not overwrite previously entered data in the field, while

the null value means that any previous value in this field should be overwritten.

Value in Field Meaning

“”

|””|

Nullify the value recorded in the receiving system data base.



||

Make no changes to the record in the receiving data base. The sending system

has no information on this field. 
Null fields (“”) should not be sent in immunization messages. Systems which will send null fields (“”) must

specify their use in local implementation guides. Systems which will accept and process null fields, as

described above, must specify their use in local implementation guides.

Data type: A data type restricts the contents and format of the data field. Some data types are coded or

composite types with several components. The applicable data type is listed and defined in each field

definition.

Code Sets/Systems and Value sets: Most data elements will have associated lists of acceptable values in

tables supported by a standards organization such as HL7 or CDC. These code sets will include definitions

to support common usage.

Delimiters: Delimiter characters are used to separate segments, fields and components in an HL7 message.

The delimiter values are given in MSH-2 and used throughout the message. Applications must use agreed

upon delimiters to parse the message. Messages used in this Guide SHALL use the following delimiters:  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 19 
Chapter 3: HL7 Messaging Infrastructure

 = Segment Terminator;

| = Field Separator;

^ = Component Separator;

& = Sub-Component Separator;

~ = Repetition Separator;

\ = Escape Character.

Message syntax: Each message is defined in special notation that lists the segment 3-letter identifiers in

the order they will appear in the message. Braces, {}, indicate that one or more of the enclosed group of

segments may repeat, and brackets, [ ], indicate that the enclosed group of segments is optional.  Note that

segments may be nested within the braces and brackets. This will indicate that the nested segments are units

within a subgroup of segments. Their Usage is relative to the parent segment in the group.

Z segments: All message types, trigger event codes, and segment ID codes beginning with Z are reserved

for locally defined messages. No such codes will be defined within the HL7 Standard. The users of this

Guide have agreed to eliminate Z segments from their implementations in order to produce a standard

method that will be used nationally to transmit immunization data. The query profiled in this document

does have a name code which begins with Z as specified by HL7. This is not a Z segment.

Basic Message Processing Rules

Message Acknowledgement

Original Mode processing is supported by this Implementation Guide.  Enhanced Mode Acknowledgement

is not supported.

The conversation between a sending system and a receiving system consists of a Message (VXU, QBP) and

a response (ACK, RSP). Receiving systems are expected to process the message and send a response. The

system receiving the acknowledgement response does not acknowledge the response. In other words, the

system receiving a VXU is expected to return an ACK.  The system receiving that ACK is not expected to

respond back to that ACK. Receipt and processing of ACK messages has a number of significant benefits:

• Notification of errors and rejected data alerts sender that message has errors and may require

correction

• Alerting sending user that the data did not get into the receiver’s system

Some messages pass through intermediary systems like a Health Information Exchange (HIE). It is

important that the intermediary system pass the ACK back to the sending system to allow the sending

system to be aware of and deal with messaging errors.

The HL7 Standard has two ways to convey acknowledgements: standard mode and enhanced mode.

The scope of this document includes only standard mode acknowledgments, i.e. “application

acknowledgements” only, which means that the receiving system accept responsibility for the data or

identify the error in the message or reject the message for a reason not related to the message itself.

Encoding Rules for Sending

1. Encode each segment in the order specified in the abstract message format.

2. Place the Segment ID first in the segment.

3. Precede each data field with the field separator.

4. Encode the data fields in the order and data type specified in the segment definition table.

5. End each segment with the segment terminator (carriage return).  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 20 
Chapter 3: HL7 Messaging Infrastructure

6. Components, subcomponents, or repetitions that are not valued at the end of a field need not be

represented by component separators. The data fields below, for example, are equivalent:

|^XXX&YYY&&^| is equal to |^XXX&YYY^|

|ABC^DEF^^| is equal to |ABC^DEF|

7. Components, subcomponents, or repetitions that are not valued, but precede components,

subcomponents or repetitions that are valued must be represented by appropriate separators. For

example, the following CE data type element has the first triplicate empty and a populated second

triplicate:

|^^^ABC^Text^Codesystem|

8. If a field allows repetition (Cardinality maximum > 1), then the length of the field applies to

EACH repetition.

9. No field separator is required after the last required field unless other following fields have data.

The presence of a field separator after the last required field is NOT an error and may be ignored.

Processing Rules for Receiving System:

The following table contains the rules for processing received messages. Note that these outcomes may

cascade.  That is, if a required field has bad data, it is empty. If that required field is empty, the segment is

treated as empty. It that segment is not a part of a segment group and is empty, the message is rejected.

Table 3-1 Receiving System Processing Rules

TABLE 3-1 RECEIVING SYSTEM PROCESSING RULES

Condition Outcome Acknowledgment Action

Data fields are populated

after last required field in

segment.

Ignore the extra fields. No Error Continue processing

message.

Data field violates data type

specifications or contains

unacceptable data.

Treat the field as empty. Send Error Continue processing

message.

Required data field is

empty.

Treat the segment as

empty.

Send Error Continue processing

message.

Required But May Be

Empty field is empty.

No outcome No Error Continue processing

message.

Required or conditionally

required segment is empty

or missing.

All data fields in

segment are not present

Send Error Continue processing

message.

Optional segment or

unexpected segment17 is

included.

Ignore the segment.

This is not an error.

No error Continue processing

message.

Data segment out of proper Treat segment as empty. Send Error Continue processing

17 A segment is not expected if it has been deprecated or is unsupported. A segment that does not belong in the message is also not

expected.  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 21 
Chapter 3: HL7 Messaging Infrastructure

TABLE 3-1 RECEIVING SYSTEM PROCESSING RULES

Condition Outcome Acknowledgment Action

order. message.

Required segment that is

not part of a segment group

is empty.

Reject message Send Error Reject message

Required segment that is

part of a segment group is

empty or missing.

Treat segment group as

empty.

Send Error Continue processing

message.

Required segment group is

empty or missing.

Reject message Send Error Reject message 
Note that all errors in processing a message should be communicated back to the sending system.

Determining Usage of Segments, Fields and Components

Many fields and segments in HL7 are optional. This guide tightens constraints on some fields to support

functionality required for meaningful use of immunization data. The following lists the rules applied to the

decisions used to determine usage in this Guide.

1. Any segment, field, or component that is required by HL7 standard is required or required but may be

empty.

2. Any field or component that is a required National Vaccine Advisory Committee (NVAC) Core Data

element is required or required but may be empty18.

3. Any segment that contains a required NVAC Core data element is required but may be empty.

4. Any segment, field, or component that is retained for backward compatibility in Version 2.5.1 SHALL

be unsupported in this Guide.

5. Any segment, field, or component that is conditional but may be empty in Version 2.5.1 shall be

conditional or conditional but may be empty in this Guide, unless this conflicts with 2 or 3 above.

6. All other fields will be left optional.

Usage Conformance Testing Recommendations

The following text is pre-adopted from the HL7 V2.7.1 Conformance (Chapter 2B) Please refer to the base

standard documentation for a full explanation of conformance concepts. Usage is described here as it

introduces the revised approach to conditional element handling.

———- start citation———

18 In some cases they may not be empty. Client name may never be empty or null, for instance. The NVAC core data elements are

listed in the beginning of Appendix B. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 22 
Chapter 3: HL7 Messaging Infrastructure

Usage

Message content is governed by the cardinality specification associated (explicitly or implicitly) with each

element of an HL7 message. Usage rules govern the expected behavior of the sending application and

receiving application with respect to the element. The usage codes expand/clarify the optionality codes

defined in the HL7 standard. Usage codes are employed in a message profile to constrain the use of

elements defined in the standard. The usage code definitions are given from a sender and receiver

perspective and specify implementation and operational requirements.

The standard allows broad flexibility for the message structures that HL7 applications must be able to

receive without failing. But while the standard allows that messages may be missing data elements or may

contain extra data elements, it should not be inferred from this requirement that such messages are

conformant. In fact, the usage codes specified in a message profile place strict conformance requirements

on the behavior of the application.

Definition Of Conditional Usage

C(a/b) – “a” and “b” in the expression are placeholders for usage codes representing the true (“a”) predicate

outcome and the false (“b”) predicate outcome of the condition. The condition is expressed by a conditional

predicate associated with the element (“See the Error section in V2.7.1 Chapter 2B). “a” and “b” shall be

one of “R”, “RE”, “O” and/or “X”. The values of “a” and “b” can be the same.

The example C(R/RE) is interpreted as follows. If the condition predicate associated with the element is

true then the usage for the element is R-Required. If the condition predicate associated with the element is

false then the usage for the element is RE- Required but may be empty.

There are cases where it is appropriate to value “a” and “b” the same. For example, the base standard

defines the usage of an element as “C” and the condition predicate is dependent on the presence or non-

presence of another element. The profile may constrain the element that the condition is dependent on to X;

in such a case the condition should always evaluate to false. Therefore, the condition is profiled to C(X/X)

since the desired effect is for the element to be not supported. Note it is not appropriate to profile the

element to X since this breaks the rules of allowable usage profiling (see in V2.7.1 Chapter 2B table HL7

Optionality and Conformance Usage).

Sending And Receiving Application Conformance Requirements 
Table 3-2 Sending Application Conformance

TABLE 3-2 SENDING APPLICATION CONFORMANCE

Symbol Definition Operation Requirement

R Required The application SHALL implement

“R” elements.

The application SHALL populate “R”

elements with a non-empty value. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 23 
Implementation

Requirement 
Chapter 3: HL7 Messaging Infrastructure

TABLE 3-2 SENDING APPLICATION CONFORMANCE

Symbol Definition Implementation

Requirement

Operation Requirement

RE Required but

may be empty

The application SHALL

implement “RE” elements.

The application SHALL populate “RE”

elements with a non-empty value if there

is relevant data. The term “relevant” has

a confounding interpretation in this

definition19

C(a/b) Conditional An element with a conditional usage code has an associated condition

predicate that determines the operational requirements (usage code) of the

element. If the condition predicate associated with the element is true, follow

the rules for a which shall be one of “R”, “RE”, “O” or X”:  
If the condition predicate associated with the element is false, follow the rules

for b which shall be one of “R”, “RE”, “O” or X”. a and b can be valued the

same.  
Note: when C(O/X) or similar is used a condition predicate will not be provided. 
X Not supported

in this guide

The application (or as configured)

SHALL NOT implement “X”

elements. 
The application SHALL NOT populate

“X” elements.

O

Optional None. The usage indicator for this

element has not yet been defined.

For an implementation profile all

optional elements must be profiled

to R, RE, C(a/b), or X. 
Not Applicable 
Note: Implementation Requirement the capability of the system.  The Operation Requirement indicates

what is included in the message.

19 There are multiple interpretations of “RE” when a value is known. One is “the capability must always be supported and a value is

sent if known”, the other is “the capability must always be supported and a value may or may not be sent even when known based on a

condition external to the profile specification. The condition may be noted in the profile but cannot be processed automatically”. This

is what can be interpreted from the “relevant” part of the definition. Regardless of the interpretation the “RE” usage code, a set of test

circumstances can be developed to sufficiently test the “RE” element. See the “Conformity Assessment of Conformance Constructs”

section for more details. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 24 
Chapter 3: HL7 Messaging Infrastructure

Table 3-2 Receiving Application Conformance

TABLE 3-2 RECEIVING APPLICATION CONFORMANCE

Symbol Definition Operation Requirement

R

Required The application SHALL

implement “R” elements. 
The receiving application SHALL

process (save/print/archive/etc.) the

information conveyed by a required

element.20 
A receiving application SHALL raise an

exception due to the absence of a

required element. A receiving application

SHALL NOT raise an error due to the

presence of a required element. 
RE

Required but

may be empty

The application SHALL

implement “RE” elements.

The receiving application SHALL

process (save/print/archive/etc.) the

information conveyed by a required but

may be empty element. The receiving

application SHALL process the message

if the element is omitted (that is, an

exception SHALL NOT be raised

because the element is missing).

C(a/b)

Conditional The usage code has an associated condition predicate that determines the

operational requirements (usage code) of the element. 
If the condition predicate associated with the element is true, follow the rules

for a which SHALL be one of “R”, “RE”, “O” or X” (If the condition predicate

associated with the element is false, follow the rules for b which SHALL be

one of “R”, “RE”, “O” or X”.

a and b can be the same.) 
Note: when C(O/X) or similar is used a condition predicate will not be

provided.

X

Not supported in

this guide

The application (or as configured)

SHALL NOT implement “X”

None, if the element is not sent. 
20 Processing does not necessarily require permanent storage of the required element. For instance OBX-4 (sub-id) is used to group

associated OBX segments, but will probably not be stored. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 25 
Implementation

Requirement 
Chapter 3: HL7 Messaging Infrastructure

TABLE 3-2 RECEIVING APPLICATION CONFORMANCE

Symbol Definition Operation Requirement

elements. 
If the element is sent the receiving

application may process the message,

SHALL ignore the element, and MAY

raise an exception. The receiving

application SHALL NOT process

(save/print/archive/etc.) the information

conveyed by a not-supported element.

O

Optional None. The usage indicator for

this element has not yet been

defined. For an implementation

profile all optional elements must

be profiled to R, RE, C(a/b), or X.

None

——— end citation ——— 
Note that local implementations may constrain the requirements of this Implementation Guide.

These guides should indicate that an element that will be ignored by the local application should use

symbol IX (Element will be ignored) to indicate that the element will be ignored by the local application.

The Operation Requirement will be: If the element is not sent, no action is taken.  If the element is sent, it is

ignored.

Message Element Attributes

The following describe how message specifications will be illustrated in this Guide. These terms will be

used in the tables specifying messages throughout this Guide. 
Table 3-3 Sending Application Conformance

TABLE 3-3 MESSAGE ELEMENT ATTRIBUTES

Abbreviation Description

SEQ Sequence of the elements (fields) as they are numbered in the HL7 message element.

The SEQ attribute applies to the data type attribute table and the segment attribute table.

Segment 
Three-character code for the segment and the abstract syntax (i.e., the square and curly

braces)

[ XXX ]   Optional

{ XXX }   Repeating

 XXX   Required (not inside any braces)

 [{ XXX }] Optional and Repeating 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 26 
Implementation

Requirement 
Chapter 3: HL7 Messaging Infrastructure

TABLE 3-3 MESSAGE ELEMENT ATTRIBUTES

Abbreviation Description 
[ Begin segment group

XXX

 [YYY]

] End segment group 
YYY is nested within the segment block starting with XXX. It is an optional sub-segment to

XXX21 . The whole block is optional.

Note that for Segment Groups there will not be a segment code present, but the square

and curly braces will still be present.

Conditional

predicate

Logic for determining the usage of conditional usage for an element.

Data Type Data type used for HL7 element. Data type specifications can be found in Chapter 4.

Usage  Usage of the message element for this profile. Indicates whether the message element

(segment, segment group, field, component, or subcomponent) is R, RE, O, X or C(a/b) in

the corresponding message element. Usage applies to the message attribute table, data

type attribute table and the segment attribute table.

Cardinality Indicator of the minimum and maximum number of times the element may appear.

[0..0]  Element never present.

[0..1]  Element may be omitted and can have at most, one occurrence.

[1..1]  Element must have exactly one occurrence.

[0..n]  Element may be omitted or may repeat up to n times.

[1..n]  Element must appear at least once, and may repeat up to n times.

[0..*]  Element may be omitted or repeat for an unlimited number of times.

[1..*]  Element must appear at least once, and may repeat unlimited number of times.

[m..n] Element must appear at least m and, at most, n times.

Cardinality applies only to message attribute tables and segment attribute tables.

Value Set The set of coded values to be used with the field. The value set attribute applies only to the

data type attribute tables and the segment attribute tables. The value set may equate with

an entire code system part of a code system, or codes drawn from multiple code systems.

21 YYY may only be included if XXX is present. XXX may be present without YYY. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 27 
Chapter 3: HL7 Messaging Infrastructure

TABLE 3-3 MESSAGE ELEMENT ATTRIBUTES

Abbreviation Description

HL7 Element

Name

HL7 descriptor of the element in the segment.

Description

/Comment

Context and usage for the element. Description/Comments applies to the message

attribute table, data type attribute table and the segment attribute table. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 28 
Chapter 4: HL7 Data Types

4. HL7 Data Types

Data types are the building blocks that are the foundation of successful interoperability. Each field, component or subcomponent has a data type. Conforming systems

agree to adhere to the data type assigned to each component, assuring smooth communication. For example, dates may be formatted in many ways, but to assure

interoperability, these need to be constrained and defined. HL7 specifies several formats, but these are compatible with each other. They allow dates to be as granular as

needed. The format allows for just a year (YYYY) or for month, day, year, hour, minute, second, etc.

Appendix A contains the tables of value sets referenced by these data types.

Data Types Used In This Implementation Guide

Data types specify the format and type of data used. A data type may be as simple as a numeric data type, which allows a number. It may be a more complex coded entry

that requires a specific set of code values and the name of the code system. Data types may contain subcomponents that are specified by data types.

The following list of data types only includes those that are used by elements that are used in this guide. Data types for elements that are not used in this Guide are not

included, even if they are part of segment that is used.

Data types are further defined in this implementation guide for all elements that have a usage of R, RE, C(a/b). Data types used only for optional elements are not

included. Many of these data types place constraints on the data types from the base HL7 standard. These constrained data type specifications only apply to elements  that

have a usage of Required (R), Required But May be Empty (RE) or Conditional. All other elements do not have the constraints applied. Please refer to the base standard

for those data types. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 29 
Chapter 4: HL7 Data Types

Table 3 Data Types

Table 4-1 Data Types

Data type Data Type Name

CE Coded element

CE_TX Text only CE data type

CQ Composite Quantity with Units

CWE Coded with Exceptions

CX Extended Composite Id with Check digit

DT Date

DT_D Date with precision to day

DTM Date/Time

EI Entity Identifier

ERL Error Location

FN Family Name

FT Formatted text

HD Hierarchic Designator

ID Coded Values for HL7 Tables

IS Coded value for User-Defined Tables

LA2 Location with address variation 2

MSG Message Type

NM Numeric

PT Processing Type

SAD Street Address

SI Sequence ID

ST String

TS Time Stamp

TS_M Time Stamp with optional precision to the day and no time zone

TS_NZ Time Stamp with precision to the day and no time zone 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 30 
Chapter 4: HL7 Data Types

Table 4-1 Data Types

Data type Data Type Name

TS_Z Time Stamp requiring time zone

VID Version Identifier

XAD Extended Address

XCN Extended Composite ID Number and Name for Persons

XON Extended Name and Id Number for Organizations

XPN Extended Person Name

XTN Extended telephone number

CE — Coded Element (most uses)

Definition: This data type transmits codes and the text associated with the code.

Table 4 Coded Element (CE)

Table 4-2 Coded Element (CE)

SEQ Component

Name

Data

Type

Usage LEN Conditional Predicate Value

Set

Comments

1 Identifier ST R 1..50   Identifying Code.

2 Text ST RE 1..999   Human readable text that may be used to

review segment content.

3 Name of Coding

System

ID R 1..20  HL70396 Value set identifier

4 Alternate

Identifier

ST O 1..50    Alternate Identifying code. 
5 Alternate Text ST C(RE/X) 1..999 If CE-4 (Alternate Identifier) is

valued

 Human readable text.

6 Name of

Alternate Coding

system

ID C(R/X) 1..20 If CE-4 (Alternate Identifier) is

valued

HL70396 Value set identifier. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 31 
Chapter 4: HL7 Data Types

Note:

The alternate identifier (from the alternate coding system) should be the closest match for the identifier found in CE-1.

The order of the contents is not specified. In the previous guide, the first triplet was reserved for CVX codes in RXA-5. This is no longer true, based on HL7

usage of CE data type.

Identifier (ST)

Definition: Sequence of characters (the code) that uniquely identifies the item being referenced. Different coding schemes will have different elements here.

Text (ST)

Definition: The descriptive or textual name of the identifier, e.g., DTaP. This is not used by the sending or receiving system, but rather facilitates human

interpretation of the code. It may be used as the display text.

Name of Coding System (ID)

Definition: Identifies the coding system being used in the identifier component. The combination of the identifier and name of coding system components will

be a unique code for a data item. Each system has a unique identifier.

Alternate Identifier (ST)

Definition: An alternate sequence of characters (the code) that uniquely identifies the item being referenced. See usage note in section introduction.

Alternate Text (ST)

Definition: The descriptive or textual name of the alternate identifier, e.g., DTaP. This is not used by the sending or receiving system, but rather facilitates human

interpretation of the code.

Name of Alternate Coding System (ID)

Definition: Identifies the coding scheme being used in the alternate identifier component.

Example usage:

From RXA 5, Administered Code:

|50^DTAP-HIB^CVX^90721^DTAP-HIB^C4|

CE_TX — Coded Element (text only in RXA-9)

Definition: The CE_TX data type definition is used to transmit text only notes in RXA-9 (Administration Notes).  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 32 
Chapter 4: HL7 Data Types

Table 5 Coded Element (CE) for Text Only RXA-9

Table 4-3 Coded Element (CE) for Text Only RXA-9

SEQ Component

Name

Data

Type
Usage LEN Conditional Predicate Value

Set

Comments

1 Identifier ST X

2 Text ST R 999 Human readable text that is not further

processed. It may be stored by the receiving

system.

3 Name of Coding ID X

4 Alternate

Identifier

ST X

5 Alternate Text ST X

6 Name of

Alternate

ID X

Note: When transmitting text note only, only the first triplet shall be populated.

Text (ST)

Definition: Free text note regarding the immunization reported in this RXA.

CQ — Composite Quantity with Units

Definition: This data type carries a quantity and attendant units. Its’ primary use in this Guide will be for indicating the maximum number of records to return in a query

response.

Table 6 Composite Quantity with Units (CQ)

Table 4-4 Composite Quantity with Units (CQ)

SEQ COMPONENT

NAME

Usage LEN Conditional Predicate Value set COMMENTS

1 Quantity NM R 16

2 Units CE R HL7 0126

(constrained)

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 33

Data

Type 
Chapter 4: HL7 Data Types 
Conformance Statement:

IZ-1: CQ-1 (Quantity) shall be a positive integer.

IZ-2: CQ-2 (Units) shall be the literal value “RD”.

Examples:

|10^RD&records&HL70126|  10 records 
Reminder that the subcomponent separator is used when CE data type is a component of another data type

Quantity (NM)

Definition: This component specifies the numeric quantity or amount of an entity.

Units (CE)

Definition: This component species the units in which the quantity is expressed.

CWE — Coded With Exceptions

Definition: Specifies a coded element and its associated detail. The CWE data type is used when 1) more than one table may be applicable or 2) the specified

HL7 or externally defined table may be extended with local values or 3). 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 34 
Chapter 4: HL7 Data Types

Table 7 Coded with Exceptions (CWE)

Table 4-5 Coded with Exceptions (CWE)

SEQ Usage LEN Conditional Predicate Comments

1 Identifier ST R 1..999   Identifying Code.

2 Text ST RE 1..999   Human readable text that is not further used.

3 Name of Coding ID C(R/X) 1..20 If CWE.1(Identifier) is valued HL70396

4 Alternate

Identifier

ST O 1..999   Alternate Identifying coded. 
5 Alternate Text ST C(RE/X) 1..999 If CWE.4  (Alternate Identifier) is

valued

 Human readable text that is not further used. 
6 Name of

Alternate System

ID C(R/X) 1..20 If CWE.4 (Alternate Identifier) is

valued

HL70396

7 Coding

System

Version Id

ST O

8 Alternate

Coding

System

Version Id

ST O

9 Original Text ST O     
Note: The alternate identifier (from the alternate coding system) should be the closest match for the identifier found in component 1.

Identifier (ST)

Definition: Sequence of characters (the code) that uniquely identifies the item being referenced. Different coding schemes will have different elements here.

Text (ST)

Definition: The descriptive or textual name of the identifier, e.g., DTaP. This is not used by the sending or receiving system, but rather facilitates human

interpretation of the code. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 35 
Component

Name

Data

Type

Value

Set 
Chapter 4: HL7 Data Types

Name of Coding System (ID)

Definition: Identifies the coding scheme being used in the identifier component. The combination of the identifier and name of coding system components will

be a unique code for a data item. Each system has a unique identifier.

Alternate Identifier (ST)

Definition: An alternate sequence of characters (the code) that uniquely identifies the item being referenced. See usage note in section introduction.

Alternate Text (ST)

Definition: The descriptive or textual name of the alternate identifier, e.g., DTaP. This is not used by the sending or receiving system, but rather facilitates human

interpretation of the code.

Name of Alternate Coding System (ID)

Definition: Identifies the coding scheme being used in the alternate identifier component.

Example usage:

From RXR: |C28161^IM^NCIT^IM^INTRAMUSCULAR^HL70162|

CX — Extended Composite ID With Check Digit

Definition: This data type is used for specifying an identifier with its associated administrative detail. 
Table 8 Extended Composite ID with Check Digit (CX)

Table 4-6 Extended Composite ID with Check Digit (CX)

SEQ COMPONENT

NAME

Data

Type

Usage LEN Conditional Predicate Value

set

COMMENTS

1 ID Number ST R 15

2 Check Digit ST O

3 Check Digit

Scheme

ID C(O/X)  If CX. 2 (check digit) is valued HL70061

4 Assigning Authority HD R   HL70363

5 Identifier Type ID R 2..5  HL70203  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 36 
Chapter 4: HL7 Data Types

Table 4-6 Extended Composite ID with Check Digit (CX)

Code

6 Assigning Facility HD O  
7 Effective Date DT O

8 Expiration Date DT O

9 Assigning

Jurisdiction

CWE O

10 Assigning Agency

or Department

CWE O

Example:

|1234567^^^ME129^MR|

ID Number (ST)

Definition: The value of the identifier itself.

Assigning Authority (HD)

The assigning authority is a unique name of the system (or organization or agency or department) that creates the data. Refer to User-defined Table 0363 –

Assigning authority for suggested values. This table shall be populated by each IIS. The first component shall be used for this unique name. The second and third

may be used if OIDs22 are recorded.

Identifier Type Code (ID)

A code corresponding to the type of identifier. In some cases, this code may be used as a qualifier to the “Assigning authority” component. Refer to HL7 Table

0203 – Identifier type for suggested values.

22 OIDs are object identifiers. According to Wikipedia: “Health Level Seven (HL7), a standards-developing organization in the area of electronic health care data exchange, is an assigning authority at the

2.16.840.1.113883 (joint-iso-itu-t.country.us.organization.hl7) node. HL7 maintains its own OID registry, and as of January 1, 2008 it contained almost 3,000 nodes, most of them under the HL7 root. The Centers

for Disease Control and Prevention has also adopted OIDs to manage the many complex values sets or “vocabularies” used in public health. The various OIDs are available in the Public Health Information

Network (PHIN) Vocabulary Access and Distribution System (VADS).” 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 37 
Chapter 4: HL7 Data Types

DT — Date

Definition: Specifies the century and year with optional precision to month and day.

Table 9 Date (DT)

Table 4-7 Date (DT)

SEQ LEN Conditional Predicate Comments

1 Date   4..8

As of v 2.3, the number of digits populated specifies the precision using the format specification YYYY[MM[DD]]). Thus:

• Four digits are used to specify a precision of “year”

• Six are used to specify a precision of “month”

• Eight are used to specify a precision of “day.”

Examples:

|19880704|

|199503|

|2000| 
DT_D — Date with precision to day

Definition: Specifies the century and year with optional precision to month and day. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 38 
Component

Name

Data

Type

Usage Value

Set 
Chapter 4: HL7 Data Types

Table 10 Date With Precision to Day (DT_D)

Table 4-8 Date (DT_D)

SEQ  
Usage LEN Conditional Predicate  Comments

1 Date  
 4..8

The Precision of this DT_D data type has the following constraints. 
YYYY R

MM R    
DD R  
HH O

MM O

[SS[.S[S[S[S]]]]] O

+/-ZZZZ O

DTM — Date/Time

Table 11 Date/Time (DTM)

Table 4-9 Date/Time (DTM)

SEQ Component

Name

Data

Type

Usage LEN Conditional Predicate Value

Set

Comments

 Date/time   4..24    
The number of characters populated (excluding the time zone specification) specifies the precision.

Format: YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ].

Thus:

• Eight are used to specify a precision of “day.”

• the first ten are used to specify a precision of “hour”

• the first twelve are used to specify a precision of “minute”

• the first fourteen are used to specify a precision of “second” 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 39 
Component

Name

Data

Type

Value

Set 
Chapter 4: HL7 Data Types

• the first sixteen are used to specify a precision of “one tenth of a second”

• the first nineteen are used to specify a precision of ” one ten thousandths of a second”

When the time zone is not included, it is presumed to be the time zone of the sender.

Example: |199904| specifies April 1999.

Note that this data type will be constrained at the field level, depending on the use.

EI — Entity Identifier

Definition: The entity identifier defines a given entity within a specified series of identifiers.

Table 12 Entity Identifier (EI)

Table 4-10 Entity Identifier (EI)

SEQ COMPONENT

NAME

Data

Type

Usage LEN Conditional Predicate Value

Set

COMMENTS

1 Entity Identifier ST R 1..199

2 Namespace ID IS C(R/O) 20 If EI.3 (Universal Id) is not valued HL70363

3 Universal ID ST C(R/O) 199 If EI.2 (Namespace ID) is not

valued 
4 Universal ID Type ID C(R/X) 6 If EI.3 (Universal Id) is valued HL70301

(constrained

) 
Conformance Statement:

IZ-3: Conformance Statement: If populated EI.3 (Universal Id), it shall be valued with an ISO-compliant OID.

IZ-4: Conformance Statement: If populated EI.4 is populated (Universal ID Type), it shall contain the value “ISO”.

Entity Identifier (ST)

The first component, , is defined to be unique within the series of identifiers created by the , defined by a hierarchic

designator, represented by component 2.  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 40 
Chapter 4: HL7 Data Types

Namespace ID (IS)

The assigning authority is a unique identifier of the system (or organization or agency or department) that creates the data. Refer to User-defined Table 0363 –

Assigning authority for suggested values.

Universal ID (ST)

This is a universal id associated with this entity. It must be linked to the Universal Id Type below. If populated, it shall be an OID.

Universal ID Type (ID)

This universal id type is drawn from HL7 Table 0301. If populated, it shall be ISO.

Example:

From MSH 21 profile identifier:

|Z34^CDCPHINVS|

ERL — Error Location

Definition: This data type identifies the segment and its constituent where an error has occurred.

Table 13 Error Location (ERL)

Table 4-11 Error Location (ERL)

SEQ COMPONENT

NAME

Data

Type

Usage LEN Conditional Predicate Value

Set

COMMENTS

1 Segment ID ST R 3..3   The 3-character name for the segment (i.e.

PID)

2 Segment

Sequence

NM R 1.2

3 Field Position NM C(R/RE) 2 If ERL.4 (Field Repetition) is

valued

 This should not be populated if the error refers

to the whole segment.

4 Field Repetition NM C(R/RE) 2 If ERL.5 (Component Number)

is valued 
5 Component

Number

NM C(R/RE) 2 If ERL.6 (Sub-Component

Number) is valued

 Should be populated ONLY when a particular

component cause the error. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 41 
Chapter 4: HL7 Data Types

Table 4-11 Error Location (ERL)

SEQ COMPONENT

NAME

Data

Type

Usage LEN Conditional Predicate Value

Set

COMMENTS

6 Sub-Component

Number

NM RE 2   Should be populated ONLY when a particular

sub-component cause the error. 
Segment ID (ST)

Definition: Specifies the 3-letter name for the segment.

Segment Sequence (NM)

Definition: Identifies the segment occurrence within the message. That is, for the first instance of the segment in the message the number shall be 1 and for the

second 2.  It is not the sequence within a sequence group. For example if a message had 3 order groups and each order group had 3 OBX, the Sequence number

of the last OBX in the message would be 9.

Field Position (NM)

Definition: Identifies the number of the field within the segment. The first field is assigned a number of 1. Field number should not be specified when referring to

the entire segment.

Field Repetition (NM)

Definition: Identifies the repetition number of the field. The first repetition is counted as 1. If a Field Position is specified, but Field Repetition is not, Field

Repetition should be assumed to be 1. If Field Position is not specified, Field Repetition should not be specified.

Component Number (NM)

Definition: Identifies the number of the component within the field. The first component is assigned a number of 1. Component number should not be specified

when referring to the entire field.

Sub-Component Number (NM)

Definition: Identifies the number of the sub-component within the component. The first sub-component is assigned a number of 1. Sub-component number

should not be specified when referring to the entire component.

Example:

|RXA^1^5^1|

Error in the fifth field of the first occurrence. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 42 
Chapter 4: HL7 Data Types

FN — Family Name

Definition: This data type contains a person’s family name (i.e.  surname ).

Table 14 Family Name

Table 4-12 Family Name

SEQ COMPONENT

NAME

Data

Type

Usage LEN Conditional Predicate Value

Set

COMMENTS

1 Surname ST R 1..50

2 Own Surname

Prefix

ST O

3 Own Surname ST O

4 Surname Prefix

From

Partner/Spouse

ST O

5 Surname From

Partner/Spouse

ST O

Surname (ST)

This is the person’s last name.

FT – Formatted Text

Table 15 Formated Text

Table 4-13 Formatted Text

SEQ COMPONENT

NAME

Data

Type

Usage LEN Conditional Predicate Value

Set

COMMENTS

1 Formatted Text

Data

  1..65536    
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 43 
Chapter 4: HL7 Data Types

Usage Note

The FT data type allows use of the formatting escape sequences documented in HL7 Version 2.5.1, Chapter 2, Section 2.7.1 – Use of Escape Sequences in Text Fields. In

this implementation guide, the only allowed escape sequences are those allowed in HL7 Version 2.5.1, Chapter 2, Section 2.7.4 – Special Characters. These are the escape

sequences for the message delimiters (i.e., |^&~\ ).

HD — Hierarchic Designator

The use of OIDs in fields using this data type is encouraged. Note that either HD.1 (name space id) or HD.2 (universal id ) is required. 
Definition: HD identifies an (administrative or system or application or other) entity that has responsibility for managing or assigning a defined set of instance identifiers

(such as placer or filler number, patient identifiers, provider identifiers, etc.). This entity could be a particular health care application such as a registration system that

assigns patient identifiers, a governmental entity such as a licensing authority that assigns professional identifiers or drivers’ license numbers, or a facility where such

identifiers are assigned.

** Note that when HD is a sub-component of another data type, the Sub-component Separator (&) is used to separate the subcomponents rather than the component

separator (^).

Table 16 Hierarchical Designator (HD)

Table 4-14 Hierarchical Designator (HD)

SEQ COMPONENT

NAME

Data

Type

Usage LEN Conditional Predicate Value Set COMMENTS

1 Namespace ID IS C(R/O) 1..20 If the HD.2 (Universal ID) is not

valued

HL70300

HL70361

HL70362

HL70363

This field is used for a locally defined

name/id. It may be used as previous version

2.3.1 Implementation Guide specified.

The value set used depends on usage.

2 Universal ID ST C(R/O) 1..199 If the HD.1 (Namespace ID) is not

valued 
 3 Universal ID Type ID C(R/X) 1..6 If the HD.2 (Universal ID) is valued HL70301

(Constrained) 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 44 
Chapter 4: HL7 Data Types

Conformance Statement:

IZ-5: If populated, HD.2 (Universal ID) it SHALL be valued with an ISO–compliant OID.

IZ-6: If populated, HD.3 (Universal ID Type) SHALL be valued the literal value: “ISO”.

ID — Coded Values for HL7 Tables

Definition: This data type is used for coded values from an HL7 table.

Table 17 ID Data Type

Table 4-15 ID Data Type

SEQ COMPONENT

NAME

Data

Type

Usage LEN Conditional Predicate Value

Set

COMMENTS

1 Coded Value for

HL7-defined

Tables

  1..15    
The value of such a field follows the formatting rules for an ST field except that it is drawn from a table of legal values. There shall be an HL7 table number associated

with ID data types. An example of an ID field is PID 24 –Multiple Birth Indicator. This data type should be used only for HL7 tables (see Appendix A).

Example from PID Multiple Birth Indicator:

|Y|

IS — Coded Values for User Defined Tables

Definition: This data type is used for codes from User-defined Tables.

Table 18 Coded Values for User Defined Tables (IS)

Table 4-16 Coded Values for User Defined Tables (IS)

SEQ COMPONENT

NAME

Data

Type

Usage Leng

th 
Conditional Predicate Value

Sets

COMMENTS

1 Coded Value for

User-Defined

Tables

  1..20 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 45 
Chapter 4: HL7 Data Types 
The value of such a field follows the formatting rules for a ST field except that it is drawn from a site-defined (or user-defined) table of legal values. There shall be an

HL7 table number associated with IS data types. This data type should be used only for user-defined tables.

Example from PID Sex:

|F|

LA2 — Location with Address Variation 2

Definition: Specifies a location and its address.

Table 19  Location with Address Variation 2

Table 4-17 Location with Address Variation 2

SEQ COMPONENT

NAME

Data

Type

Usage LEN Conditional Predicate Value

Sets

COMMENTS

1 Point of Care IS O  
This represents the location within a facility

that the service was provided. This is not the

clinic site where an event occurred.

2 Room IS O  
 3 Bed IS O

4 Facility HD R HL70362 This represents the location that the service

was provided. For example the clinic.

5 Location Status IS O  
6 Patient Location

Type

IS O

7 Building IS O

8 Floor IS O

9 Street Address ST O

10 Other Designation ST O 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 46 
Chapter 4: HL7 Data Types

Table 4-17 Location with Address Variation 2

SEQ COMPONENT

NAME

Data

Type

Usage LEN Conditional Predicate Value

Sets

COMMENTS

11 City ST O

12 State or Province ST O

13 Zip or Postal

Code

ST O

14 Country ID O

15 Address Type ID O

16 Other Geographic

Designation

ST O     
Facility (HD)

This is the location that the service was provided, for example a clinic. This may be a clinic that is a part of a larger provider organization or a provider organization. It is

the location that is responsible for the inventory used for this immunization. If it provides Vaccine for Children funded vaccines, then it has a VFC PIN assigned.

MSG — Message Type

Definition: This field contains the message type, trigger event, and the message structure ID for the message.

Table 20  Message Type (MSG)

Table 4-18 Message Type (MSG)

SEQ COMPONENT

NAME

Data

Type

Usage LEN Conditional Predicate Value Set COMMENTS

1 Message Code ID R 3..3  HL70076

(constrained) 
2 Trigger Event ID R 3..3  HL70003

(constrained) 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 47 
Chapter 4: HL7 Data Types

Table 4-18 Message Type (MSG)

SEQ COMPONENT

NAME

Data

Type

Usage LEN Conditional Predicate Value Set COMMENTS

3 Message

Structure

ID R 3..7  HL70354

(constrained) 
Message Code (ID)

Definition: Specifies the message type code. Refer to HL7 Table – Message Type in section 2.17.1 for valid values.

This table contains values such as ACK, ADT, ORU etc.

See section 2.5.1- Messages for further discussion.

Trigger Event (ID)

Definition: Specifies the trigger event code. Refer to HL7 Table – Event Type in section 2.17.2 for valid values.

This table contains values like A01, V01, R01 etc.

Message Structure (ID)

Definition: Specifies the abstract message structure code. Refer to HL7 Table 0354. 
Example from MSH:

|VXU^V04^VXU_V04|

NM — Numeric

Definition: A number represented as a series of ASCII numeric characters consisting of an optional leading sign (+ or -), the digits and an optional decimal point.

In the absence of a sign, the number is assumed to be positive. If there is no decimal point the number is assumed to be an integer.

Table 21 Numeric (NM)

Table 4-19 Numeric (NM)

SEQ COMPONENT

NAME

Data

Type

Usage LEN Conditional Predicate Value

Set

COMMENTS

1 Numeric  R 1..16    
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 48 
Chapter 4: HL7 Data Types

Examples:

|999|

|-123.792|

Leading zeros, or trailing zeros after a decimal point, are not significant. For example, the following two values with different representations, “01.20” and “1.2,”

are identical. Except for the optional leading sign (+ or -) and the optional decimal point (.), no non-numeric ASCII characters are allowed. Thus, the value <12 
should be encoded as a structured numeric (SN) (preferred) or as a string (ST) (allowed, but not preferred) data type. 
PT -- Processing Type  
Definition: This data type indicates whether to process a message as defined in HL7 Application (level 7) Processing rules.  
Table 22 Processing Type (PT) 
Table 4-20 Processing Type (PT) 
SEQ COMPONENT 
NAME 
Data 
Type 
Usage LEN Conditional Predicate Value 
Set 
COMMENTS 
1 Processing ID ID R 1..1  HL70103  
2 Processing Mode ID O     
Processing ID (ID) 
A value that defines whether the message is intended for a production, training, or debugging system. Refer to HL7 Table 0103 - Processing ID for valid values. 
SAD -- Street Address  
Definition: This data type specifies an entity's street address and associated detail. 
Table 23 Street Address (SAD) 
Table 4-21 Street Address (SAD) 
SEQ COMPONENT 
NAME 
Data 
Type 
Usage LEN Conditional Predicate Value Set COMMENTS 
1 Street or Mailing 
Address 
ST R 1..120    
2 Street Name ST O     
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 49 
 


Chapter 4: HL7 Data Types 
Table 4-21 Street Address (SAD) 
SEQ COMPONENT 
NAME 
Data 
Type 
Usage LEN Conditional Predicate Value Set COMMENTS 
3 Dwelling Number ST O     
 
Note: Appears ONLY in the XAD data type 
Street or Mailing Address (ST) 
Definition: This component specifies the street or mailing address of a person or institution.  
SI -- Sequence Id  
Definition: A non-negative integer in the form of a NM field. The uses of this data type are defined in the chapters defining the segments and messages in which 
it appears.  
Table 24 Sequence Id (SI) 
Table 4-22 Sequence Id (SI) 
SEQ COMPONENT 
NAME 
Data 
Type 
Usage LEN Conditional Predicate Value 
set 
COMMENTS 
1 Sequence ID   1..4    
ST – String 
Definition: String data is left justified with trailing blanks optional. Any displayable (printable) ACSII characters (hexadecimal values between 20 and 7E, 
inclusive, or ASCII decimal values between 32 and 126), except the defined escape characters and defined delimiter characters. 
Table 4-22 String (ST) 
Table 4-22 String (ST) 
SEQ COMPONENT 
NAME 
Data 
Type 
Usage LEN Conditional Predicate Value 
set 
COMMENTS 
1 String Data       
 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 50 
 


Chapter 4: HL7 Data Types 
Usage Note 
The ST data type is normally used for short text strings. No leading blanks (space characters) are permitted. Trailing blanks are permitted. In this implementation guide, 
the only allowed escape sequences are those allowed in HL7 Version 2.5.1, Chapter 2, Section 2.7.4 - Special Characters. These are the escape sequences for the message 
delimiters (i.e., |^&~\ ) 
TS -- Time Stamp  
Definition: Specifies a point in time.  
Table 25 Time Stamp (TS) 
Table 4-23 Time Stamp (TS) 
SEQ COMPONENT 
NAME 
Data 
Type 
Usage LEN Conditional Predicate Value 
Set 
COMMENTS 
1 Time DTM R     
2 Degree of 
Precision 
ID X     
The DTM component of this Time Stamp has the following constraints: 
 YYYY  R     
 MM  R     
 DD  R     
 HH  O     
 MM  O     
 [SS[.S[S[S[S]]]]]  O     
 +/-ZZZZ  O     
TS_M -- Time Stamp to Month 
Definition: Specifies a point in time. This data type requires a precision to the month.  Precision to the day is optional. 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 51 
 


Chapter 4: HL7 Data Types 
Table 26 Time Stamp Precision to Month (TS) 
Table 4-24 Time Stamp Precision to Month (TS_M) 
SEQ COMPONENT 
NAME 
Data 
Type 
Usage LEN Conditional Predicate Value 
Set 
COMMENTS 
1 Time DTM R     
2 Degree of 
Precision 
ID X     
The DTM component of this Time Stamp has the following constraints: 
 YYYY  R     
 MM  R     
 DD  O     
 HH  O    
 MM  O     
 [SS[.S[S[S[S]]]]]  O     
 +/-ZZZZ  O     
TS_NZ -- Time Stamp No Time Zone 
Definition: Specifies a point in time. This data type requires a precision to the day. No Time zone is included. 
Table 27 Time Stamp No Time Zone (TS_NZ) 
Table 4-25 Time Stamp No time Zone (TS_NZ) 
SEQ COMPONENT 
NAME 
Data 
Type 
Usage LEN Conditional Predicate Value 
Set 
COMMENTS 
1 Time DTM R     
2 Degree of 
Precision 
ID X     
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 52 
 


Chapter 4: HL7 Data Types 
Table 4-25 Time Stamp No time Zone (TS_NZ) 
SEQ COMPONENT 
NAME 
Data 
Type 
Usage LEN Conditional Predicate Value 
Set 
COMMENTS 
The DTM component of this Time Stamp has the following constraints: 
 YYYY  R     
 MM  R     
 DD  R     
 HH  O     
 MM  O     
 [SS[.S[S[S[S]]]]]  O     
 +/-ZZZZ  X     
TS_Z -- Time Stamp with Time Zone 
Definition: Specifies a point in time. This data type requires a precision to the second and requires that the time zone be included. 
Table 28 Time Stamp with Time Zone (TS_Z) 
Table 4-26 Time Stamp with time zone (TS_Z) 
SEQ COMPONENT 
NAME 
Data 
Type 
Usage LEN Conditional Predicate Value 
Set 
COMMENTS 
1 Time DTM R     
2 Degree of 
Precision 
ID X     
The DTM component of this Time Stamp has the following constraints: 
 YYYY  R     
 MM  R     
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 53 
 


Chapter 4: HL7 Data Types 
Table 4-26 Time Stamp with time zone (TS_Z) 
SEQ COMPONENT 
NAME 
Data 
Type 
Usage LEN Conditional Predicate Value 
Set 
COMMENTS 
 DD  R     
 HH  O     
 MM  O     
 [SS[.S[S[S[S]]]]]  O     
 +/-ZZZZ  R     
VID -- Version Id  
Definition: This specifies the HL7 version.  
Table 29 Version ID (VID) 
Table 4-27 Version ID (VID) 
SEQ COMPONENT 
NAME 
Data 
Type 
Usage LEN Conditional Predicate Value 
Set 
 
COMMENTS 
1 Version ID ID R 5..5  HL70104 
(constrained
) 
 
2 Internationalization 
Code 
CE O     
3 International 
Version ID 
CE O     
Conformance Statement: 
IZ-7: VID-1 (Version Id) SHALL be valued with the literal “2.5.1” 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 54 
 


Chapter 4: HL7 Data Types 
Version ID (ID) 
Used to identify the HL7 version. Only “2.5.1” will be accepted. 
XAD -- Extended Address  
Definition: This data type specifies the address of a person, place or organization plus associated information.  
Table 30 Extended Address (XAD) 
Table 4-28 Extended Address (XAD) 
SEQ COMPONENT 
NAME 
Data 
Type 
Usage LEN Conditional Predicate Value 
Sets 
COMMENTS 
1 Street Address SAD RE     
2 Other Designation ST RE 1..120    
3 City ST RE 1..50    
4 State or Province ST RE 1..50  US Postal 
Service 
state codes 
Two character USPS codes, for example: 
AL, AK, ME 
5 Zip or Postal 
Code 
ST RE 1..12    
6 Country ID RE 3..3  HL70399 Empty defaults to USA 
7 Address Type ID R 1..3  HL70190  
8 Other Geographic 
Designation 
ST O     
9 County/Parish 
Code 
IS O     
10 Census Tract IS O     
11 Address 
Representation 
Code 
ID O     
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 55 
 


Chapter 4: HL7 Data Types 
Table 4-28 Extended Address (XAD) 
SEQ COMPONENT 
NAME 
Data 
Type 
Usage LEN Conditional Predicate Value 
Sets 
COMMENTS 
12 Address Validity 
Range 
DR X    deprecated as of v 2.5 
13 Effective Date TS O     
14 Expiration Date TS O     
Example of usage for US: 
|1000 Hospital Lane^Ste. 123^Ann Arbor ^MI^99999^^B| 
This would be formatted for postal purposes as  
1000 Hospital Lane 
Ste. 123 
Ann Arbor MI 99999 
Street Address (SAD) 
Definition: This is the street address. 
Other Designation (ST) 
Definition: Second line of address. In US usage, it qualifies address. Examples: Suite 555 or Fourth Floor. This can be used for dwelling number.  
City (ST) 
Definition: This component specifies the city, or district or place where the addressee is located depending upon the national convention for formatting addresses 
for postal usage. 
State or Province (ST) 
Definition: This component specifies the state or province where the addressee is located. State or province should be represented by the official postal service 
codes for that country. In the US it SHALL be the 2 character state codes (ie AK, ME, WI) 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 56 
 


Chapter 4: HL7 Data Types 
Zip or Postal Code (ST) 
Definition: This component specifies the zip or postal code where the addressee is located. Zip or postal codes should be represented by the official codes for that 
country. In the US, the zip code takes the form 99999[-9999], while the Canadian postal code takes the form A9A9A9, and the Australian Postcode takes the 
form 9999. 
Country (ID) 
Definition: This component specifies the country where the addressee is located. HL7 specifies that the 3-character (alphabetic) form of ISO 3166 be used for the 
country code. Refer to HL7 Table 0399 – Country code in section 2.15.9.17 for valid values.  
Address Type (ID) 
Definition: This component specifies the kind or type of address. Refer to HL7 Table 0190 - Address type for valid values. 
XCN - Extended Composite ID Number and Name for Persons 
Definition: This data type identifies a person using a unique id and name. The ID is associated with an entity such as an organization, which 
assigns the ID. This data type is used where there is a need to specify the ID number and name of a person. 
Table 31 Extended Composite ID Number and Name (XCN) 
Table 4-29 Extended Composite ID Number and Name (XCN) 
SEQ COMPONENT 
NAME 
Data 
Type 
Usage LEN Conditional Predicate Value 
Set 
COMMENTS 
1 ID Number ST C(R/RE) 1..15 If XCN.2.1 (Surname) and  XCN.3 
(Given Name) are not valued 
  
 
2 Family Name FN RE     
3 Given Name ST RE 30    
4 Second and 
Further Given 
Names or Initials 
Thereof 
ST RE 30    
5 Suffix (e.g., JR or 
III) 
ST O     
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 57 
 


Chapter 4: HL7 Data Types 
Table 4-29 Extended Composite ID Number and Name (XCN) 
SEQ COMPONENT 
NAME 
Data 
Type 
Usage LEN Conditional Predicate Value 
Set 
COMMENTS 
6 Prefix (e.g., DR) ST O     
7 Degree (e.g., MD) IS X    Use Professional suffix in  sequence 21. 
8 Source Table IS O     
9 Assigning Authority HD C(R/X)  If the XCN-1 (id number) is valued HL70363 Note that the subcomponent separator is & 
when HD is a component of another data type. 
10 Name Type Code ID RE 1  HL70200  
11 Identifier Check 
Digit 
ST O     
12 Check Digit 
Scheme 
ID C(O/X)  If XCN-11 (check digit identifier) is 
valued 
  
13 Identifier Type 
Code 
ID O     
14 Assigning Facility HD O     
15 Name 
Representation 
Code 
ID O     
16 Name Context CE O     
17 Name Validity 
Range 
DR X     
18 Name Assembly 
Order 
ID X     
19 Effective Date TS O     
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 58 
 


Chapter 4: HL7 Data Types 
Table 4-29 Extended Composite ID Number and Name (XCN) 
SEQ COMPONENT 
NAME 
Data 
Type 
Usage LEN Conditional Predicate Value 
Set 
COMMENTS 
20 Expiration Date TS O     
21 Professional Suffix ST O     
22 Assigning 
Jurisdiction 
CWE O     
23 Assigning Agency 
or Department 
CWE O     
 
Note: The ID Number component combined with the Assigning Authority (XCN.9) must uniquely identify the associated person.  
Note: If XCN-2.1 (Surname) and XCN-3 (Given Name) are populated then XCN-10 ( name type code) defaults to L, legal name. 
ID number (ST) 
This string refers to the coded ID assigned by the assigning authority. 
Family Name (FN)  
This component contains the person’s surname. 
Given Name (ST) 
First name. 
Second and Further Given Names or Initials Thereof  (ST)  
Multiple middle names may be included by separating them with spaces. 
Suffix (ST) 
Used to specify a name suffix (e.g., Jr. or III). 
Prefix (ST)  
Used to specify a name prefix (e.g., Dr.). 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 59 
 


Chapter 4: HL7 Data Types 
Assigning Authority (HD) 
The assigning authority is a unique identifier of the system (or organization or agency or department) that creates the identifier.. User-defined Table 0363 – 
Assigning authority is used as the HL7 identifier for the user-defined table of values for the first sub-component of the HD component, .

Note: When HD data type is used as a component of another data type, its components are demoted to subcomponents.  This means that each component is

separated by & rather than ^.  For example:

Name space id^some OID^ISO becomes Name space id&some OID&ISO

Note: User-defined Table 0363 is specified by this Implementation Guide for Assigning Authority.

Name Type Code (ID)

A code that represents the type of name. Refer to HL7 Table 0200 – Name type for valid values. If the field is not populated then the value is assumed to be L.

XON – Extended Composite Name and ID Number and Name for Organizations

Definition: This data type identifies an organization using a unique id and name. The ID is associated with an entity such as an organization, which assigns the

ID.

Table 32 Extended Composite ID Number and Name for Organizations (XON)

Table 4-30 Extended Composite ID Number and Name for Organizations (XON)

SEQ COMPONENT

NAME

Data

Type

Usage LEN Conditional Predicate Value

Set

COMMENTS

1 Organization Name ST RE 1..50

2 Organization Name

Type Code

IS O

3 ID Number  X

4 Check Digit  O

5 Check Digit

Scheme

 O

6 Assigning Authority HD C(R/O)  If XON.10 (Organization Identifier)

is valued

 The Assigning Authority is used to identify the

system, application or organization that

assigned the ID in Component 10. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 60 
Chapter 4: HL7 Data Types

Table 4-30 Extended Composite ID Number and Name for Organizations (XON)

SEQ COMPONENT

NAME

Data

Type

Usage LEN Conditional Predicate Value

Set

COMMENTS

7 Identifier Type

Code

ID C(R/X) 2..5 If XON.10 (Organization Identifier)

is valued

HL70203

8 Assigning Facility HD O

9 Name

Representation

Code

ID O

10 Organization

Identifier

ST C(R/RE) 1..20 If XON.1 (Organization Name) is

not valued 
XPN — Extended Person Name

Definition: This is used for representing a person’s name.

Table 33 Extended Person Name (XPN)

Table 4-31 Extended Person Name (XPN)

SEQ COMPONENT

NAME

Data

Type

Usage LEN Conditional Predicate Value

Sets

COMMENTS

1 Family Name FN R

2 Given Name ST R 30

3 Second and

Further Given

Names or Initials

Thereof

ST RE 30

4 Suffix (e.g., JR or

III)

ST O

5 Prefix (e.g., DR) ST O     
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 61 
Chapter 4: HL7 Data Types

Table 4-31 Extended Person Name (XPN)

SEQ COMPONENT

NAME

Data

Type

Usage LEN Conditional Predicate Value

Sets

COMMENTS

6 Degree (e.g., MD) IS X    Use Professional suffix in sequence 14

7 Name Type Code ID RE 1  HL70200

8 Name

Representation

Code

ID O

9 Name Context CE O

10 Name Validity

Range

DR X

11 Name Assembly

Order

ID O

12 Effective Date TS O

13 Expiration Date TS O

14 Professional

Suffix

ST O     
Note: Replaces PN data type as of v 2.3. 
Family Name (FN)

This is the person’s surname or family name.

Given Name (ST)

First name. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 62 
Chapter 4: HL7 Data Types

Second and Further Given Names or Initials Thereof (ST)

Multiple middle names may be included by separating them with spaces.

Suffix (ST)

Used to specify a name suffix (e.g., Jr. or III).

Prefix (ST)

Used to specify a name prefix (e.g., Dr.).

Name Type Code (ID)

A code that represents the type of name. Refer to HL7 Table 0200 – Name type for valid values.

Note: The content of Legal Name is country specific. In the US the legal name is the same as the current married name.

Professional Suffix (ST)

This is the person’s professional suffix. Replaces degree above.

XPN_M — Extended Person Name – Maiden Name

Definition: This is used for representing a mother’s maiden name.

Table 34 Extended Person Name (XPN_M)

Table 4-32 Extended Person Name (XPN_M)

SEQ COMPONENT

NAME

Data

Type

Usage LEN Conditional Predicate Value

Sets

COMMENTS

1 Family Name FN R

2 Given Name ST RE 30

3 Second and

Further Given

Names or Initials

Thereof

ST O 30

4 Suffix (e.g., JR or

III)

ST O     
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 63 
Chapter 4: HL7 Data Types

Table 4-32 Extended Person Name (XPN_M)

SEQ COMPONENT

NAME

Data

Type

Usage LEN Conditional Predicate Value

Sets

COMMENTS

5 Prefix (e.g., DR) ST O

6 Degree (e.g., MD) IS X Use Professional suffix in sequence 14

7 Name Type Code ID R 1 HL70200

8 Name

Representation

Code

ID O

9 Name Context CE O

10 Name Validity

Range

DR X

11 Name Assembly

Order

ID O

12 Effective Date TS O

13 Expiration Date TS O

14 Professional

Suffix

ST O

Note: Replaces PN data type as of v 2.3.

IZ-66: XPN_M.7 (Name Type code) SHALL be valued “M”.

Family Name (FN)

This is the person’s surname or family name.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 64 
Chapter 4: HL7 Data Types

Given Name (ST)

First name.

Second and Further Given Names or Initials Thereof (ST)

Multiple middle names may be included by separating them with spaces.

Name Type Code (ID)

A code that represents the type of name. This SHALL be  valued “M”. 
XTN – Extended Telecommunication Number

Definition: This contains the extended telephone number.

Table 35 XTN Extended Telecommunication Number (XTN)

Table 4-33 XTN Extended Telecommunication Number (XTN)

SEQ COMPONENT

NAME

Data

Type

Usage LEN Conditional Predicate Value

Set

COMMENTS

1 Telephone

Number

ST X    Deprecated as of 2.3

2 Telecommunicatio

n Use Code

ID R   HL70201

3 Telecommunicatio

n Equipment Type

ID RE   HL70202

4 Email Address ST C(R/X) 1..199 If the XTN-2 (Telecommunication

Use Code) is valued “NET” 
5 Country Code NM O  
6 Area/City Code NM C(RE/X) 5 If the XTN-2 (Telecommunication

Use Code) is valued not “NET” 
7 Local Number NM C(R/X) 9 If the XTN-2 (telecommunication   
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 65 
Chapter 4: HL7 Data Types

Table 4-33 XTN Extended Telecommunication Number (XTN)

SEQ COMPONENT

NAME

Data

Type

Usage LEN Conditional Predicate Value

Set

COMMENTS

use code) is valued not “NET”

8 Extension NM O

9 Any Text ST O

10 Extension Prefix ST O

11 Speed Dial Code ST O

12 Unformatted

Telephone

number

ST O

Note: The old implementation guide (2.3.1) allowed the first component to be used for phone number. This is not supported by this Guide.

Note: Replaces TN data type as of v 2.3

Example: A primary residence number

^PRN^PH^^^734^6777777

Telecommunication Use Code (ID)

A code that represents a specific use of a telecommunication number. Refer to HL7 Table 0201 – Telecommunication use code for valid values.

Telecommunication Equipment Type (ID)

A code that represents the type of telecommunication equipment. Refer to HL7 Table 0202 – Telecommunication equipment type for valid values.

Email Address (ST)

The email address for the entity.

Area/city Code (NM)

The telephone area code for the entity. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 66 
Chapter 4: HL7 Data Types

Phone Number (NM)

The phone number for the entity.

Extension (NM)

The extension to the phone. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 67 
Chapter 5: Segments and Message Details

5. Profile Z22-Send Unsolicited Immunization Update Using a VXU 
Introduction:

Profile Z22 – Send Unsolicited Immunization Update is a constrainable profile that supports messaging of immunization history of an individual. It has a

partner profile for acknowledging processing of the message, Z23 – Return Acknowledgment.

The goal of this interaction is to transfer immunization information from one health information system to another. The Sending System may be an Electronic

Health Record system (EHRs), an Immunization Information System (IIS) or another type of health information system.

See Use Case 1—Send Immunization History above for Use Case details.

Interaction Definition:

This sequence diagram illustrates the message flow. The sender sends an immunization record in a VXU message. The trigger may be an update or new record in

the sending system records or may be triggered by some other event.  The receiver accepts the message and processes it. The receiver sends an acknowledgment

message in an ACK message.  The transactions that are of interest are indicated by bold arrows.

It is important to note that the message may pass through intermediaries, such as a Health Information Exchange (HIE). The message comes from the initiating

sender and the acknowledgement MUST be returned to the initiating system. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 68 
Chapter 5: Segments and Message Details 
Figure 36  Send Immunization History Sequence Diagram 
Dynamic Definition:

The following diagram illustrates the expected flow of events. Some event triggers the sending system to create and send a VXU. The receiving system accepts

the VXU. If the message is of an unsupported message type, has an unsupported event code, has an unsupported processing ID or is unable to be processed for

reasons unrelated to format or content, then the acknowledgement code is set to “AR”. The receiving system returns an ACK with the acknowledgement code of

“AR”. Otherwise, the receiving system continues to process the message. It parses the message and processes according to the specifications of this profile and

applies local business rules. If there are no errors, the acknowledgment code is set to “AA”. If there are errors, the acknowledgement code is set to “AE”. If the

errors are fatal (See Processing Rules for Receiving Systems above), then the message is rejected, otherwise the data are integrated into the receiving system. The

acknowledgement code is returned to the sending system in an ACK message. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 69 
Chapter 5: Segments and Message Details 
Figure 37 Send VXU Activity Diagram 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 70 
Chapter 5: Segments and Message Details

Static Definition—Message Level:

Systems may send unsolicited immunization records using a VXU. This may be a record that is new to the receiving system or may be an update to an existing

record. The following table lists the segments that are part of a VXU. Some of the optional segments are not anticipated to be used. See Appendix B for detailed

example messages that illustrate the processing of this message.

Table 5-1 VXU Segment Usage

Table 5-1 VXU Segment Usage

Segment Cardinality Usage Comment

MSH

[1..1] R Every message begins with an MSH.

[SFT]

[0..*] O Not described in this Guide. May be locally specified.

PID

[1..1] R Every VXU has one PID segment.

[PD1 ]

[0..1] RE Every PID segment in VXU may have one or less PD1 segment

{[NK1]}

[0..*] RE The PID segment in a VXU may have zero or more NK1

segments.

[ Begin

Patient Visit

Group

[0..1] O Not described in this Guide. May be locally specified.

PV1

[1..1] R

PV2

[0..1] O

End Patient

Visit]

{GT1 }

[0..*] O Not described in this Guide. May be locally specified. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 71 
Chapter 5: Segments and Message Details

Table 5-1 VXU Segment Usage

[ Begin

Insurance

Group

[0..1] O The insurance group may not repeat.

IN1

[1..1] R 
IN2

[0..1] O

Not described in this Guide. May be locally specified.

IN3

[0..1] O Not described in this Guide. May be locally specified.

End Insurance group ]

{[Begin Order

group [0..*] RE Each VXU may have zero or more Order groups

ORC

[1..1] R The order group in a VXU must have one ORC segments.

[TQ1]

[0..1] O Not described in this Guide. May be locally specified.

[TQ2 ]

[0..1] O Not described in this Guide. May be locally specified.

RXA

[1..1] R Each ORC segment in a VXU must have one RXA segment.

Every RXA requires an ORC segment.

[RXR ]

[0..1] RE Every RXA segment in a VXU may have zero or one RXR

segments.

{[Begin

Observation

Group

[0..*] RE Every RXA segment in a VXU may have zero or more

observation groups.

OBX

[1..1] R 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 72 
Chapter 5: Segments and Message Details

Table 5-1 VXU Segment Usage

[NTE ]

[0..1] RE Every OBX segment in a VXU may have zero or one NTE

segment.

End Observation Group ]}

End Order Group ]}

Static Definition—Segment Level

IN1—Insurance Segment

Local implementations may document use for local purposes in local implementation Guide. Field level specifications follow. They have

been constrained, based on current usage. Local implementations that require IN1 should base requirements on this guide. Specifications

for IN1 are included because several IIS require this segment and this specification is intended to assure that implementations are

consistent across systems.

Note that only the current insurance data should be sent. Historical insurance information should not be sent. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 73 
Chapter 5: Segments and Message Details

Table 5-2 Insurance Segment (IN1)

Table 5-2 Insurance Segment (IN1)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional Predicate Value

Set

Description/Comment

1 Set ID – IN1 SI R [1..1] 4

2 Insurance Plan ID CE R [1..1] 250  HL70072

3 Insurance

Company ID

CX R  250

4 Insurance

Company Name

XON O  250

5 Insurance

Company

Address

XAD O  250

6 Insurance Co

Contact Person

XPN O  250

7 Insurance Co

Phone Number

XTN O  250

8 Group Number ST O  12

9 Group Name XON O  250

10 Insured’s Group

Emp ID

CX O  250

11 Insured’s Group

Emp Name

XON O  250

12 Plan Effective

Date

DT O  8

13 Plan Expiration

Date

DT O  8

14 Authorization

Information

AUI O  239    
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 74 
Chapter 5: Segments and Message Details

Table 5-2 Insurance Segment (IN1)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional Predicate Value

Set

Description/Comment

15 Plan Type IS R  3  HL70086

16 Name Of Insured XPN O  250

17 Insured’s

Relationship To

Patient

CE O  250  HL70063

18 Insured’s Date Of

Birth

TS O  26

19 Insured’s Address XAD O  250

20 Assignment Of

Benefits

IS O  2  HL70135

21 Coordination Of

Benefits

IS O  2  HL70173

22 Coord Of Ben.

Priority

ST O  2

23 Notice Of

Admission Flag

ID O  1  HL70136

24 Notice Of

Admission Date

DT O  8

25 Report Of

Eligibility Flag

ID O  1  HL70136

26 Report Of

Eligibility Date

DT O  8

27 Release

Information Code

IS O  2  HL70093

28 Pre-Admit Cert

(PAC)

ST O  15    
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 75 
Chapter 5: Segments and Message Details

Table 5-2 Insurance Segment (IN1)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional Predicate Value

Set

Description/Comment

29 Verification

Date/Time

TS_NZ RE  26   Precision shall be at least to the

day. [YYYYMMDD]

30 Verification By XCN O  250

31 Type Of

Agreement Code

IS O  2  HL70098

32 Billing Status IS O  2  HL70022

33 Lifetime Reserve

Days

NM O  4

34 Delay Before L.R.

Day

NM O  4

35 Company Plan

Code

IS O  8  HL70042

36 Policy Number ST O  15

37 Policy Deductible CP  O  12

38 Policy Limit –

Amount

CP  X  12

39 Policy Limit –

Days

NM O  4

40 Room Rate –

Semi-Private

CP X  12

41 Room Rate –

Private

CP X  12

42 Insured’s

Employment

Status

CE O  250  HL70066

43 Insured’s

Administrative

IS O  1  HL70001  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 76 
Chapter 5: Segments and Message Details

Table 5-2 Insurance Segment (IN1)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional Predicate Value

Set

Description/Comment

Sex

44 Insured’s

Employer’s

Address

XAD O  250

45 Verification Status ST O  2

46 Prior Insurance

Plan ID

IS O  8  HL70072

47 Coverage Type IS O  3  HL70309

48 Handicap  IS O  2  HL70295

49 Insured’s ID

Number

CX O  250

50 Signature Code IS O  1  HL70535

51 Signature Code

Date

DT O  8

52 Insured’s Birth

Place

ST O  250

53 VIP Indicator IS O  2  HL70099

IN1 Field Definitions

IN1-1   Set ID – IN1   (SI)   00426

Definition: IN1-1 – set ID contains the number that identifies this transaction.  For the first occurrence the sequence number shall be 1, for the second occurrence

it shall be 2, etc.  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 77 
Chapter 5: Segments and Message Details

IN1-2   Insurance Plan ID   (CE)   00368

Definition:  This field contains a unique identifier for the insurance plan.  Refer to User-defined Table 0072 – Insurance Plan ID for suggested values.  To

eliminate a plan, the plan could be sent with null values in each subsequent element.  If the respective systems can support it, a null value can be sent in the plan

field.

IN1-3   Insurance Company ID   (CX)   00428

Definition:  This field contains unique identifiers for the insurance company.  The assigning authority and identifier type code are strongly recommended for all

CX data types.

IN1-15   Plan Type   (IS)   00440

Definition:  This field contains the coding structure that identifies the various plan types, for example, Medicare, Medicaid, Blue Cross, HMO, etc.  Refer to

User-defined Table 0086 – Plan ID for suggested values.

IN1-29   Verification Date/Time   (TS)   00454

Definition:  This field contains the date/time that the healthcare provider verified that the patient has the indicated benefits.

MSH—Message Header Segment

This implementation guide pre-adopts the Version 2.7.1 MSH segment. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 78 
Chapter 5: Segments and Message Details

Table 5-3 Message Header Segment (MSH)

Table 5-4 Message Header Segment (MSH)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional

Predicate

Value set Description/Comment

1 Field Separator ST R [1..1] 1..1

2 Encoding Characters ST R [1..1] 4..4

3 Sending Application HD RE [0..1]   HL70361

4 Sending Facility HD RE [0..1]   HL70362

5 Receiving

Application

HD RE [0..1]   HL70361

6 Receiving Facility HD RE [0..1]   HL70362

7 Date/Time Of

Message

TS_Z R [1..1]

8 Security ST O

9 Message Type MSG R [1..1]

10 Message Control ID ST R [1..1] 1..199

11 Processing ID PT R [1..1]

12 Version ID VID R [1..1]

13 Sequence Number NM O

14 Continuation Pointer ST O [0..1]

15 Accept

Acknowledgement

Type

ID R [1..1]   HL70155

16 Application

Acknowledgment

Type

ID R [1..1]   HL70155

(constrained) 
17 Country Code ID O

18 Character Set ID O      
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 79 
Chapter 5: Segments and Message Details

Table 5-4 Message Header Segment (MSH)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional

Predicate

Value set Description/Comment

19 Principal Language

Of Message

CE O

20 Alternate Character

Set Handling

Scheme

ID O

21 Message Profile

Identifier

EI  R [1..*]

22 Sending

Responsible

Organization

XON RE [0..1]    The initiator of this message.

23 Receiving

Responsible

Organization

XON RE [0..1]    The final recipient of this

message.

24 Sending Network

Address

HD O

25 Receiving Network

Address

HD O      
MSH Conformance Statements:

IZ-12: The MSH.1 (Field Separator)  SHALL be valued “|”

IZ-13: The MSH.2 (Encoding Characters)  SHALL be valued “^~\& “

IZ-15: The MSH-12 (Version ID) SHALL be valued “2.5.1 “

IZ-17: MSH-9 (Message Type)  SHALL contain the constant value “VXU^VO4^VXU_V04”

IZ-41: The value of MSH-16 (Application Acknowledgement) shall be “AL”. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 80 
Chapter 5: Segments and Message Details

IZ-42: The value of MSH-15 (Accept Acknowledgement) shall be “ER” 23.

IZ-43: One occurrence of MSH-21(Message Profile Identifier)  SHALL contain the constant value “Z22^CDCPHINVS”

MSH field definitions

MSH-1 Field Separator (ST) 00001

Definition: This field contains the separator between the segment ID and the first real field, MSH-2-encoding characters. As such it serves as the separator and

defines the character to be used as a separator for the rest of the message. Required value is |, (ASCII 124).

Example:

MSH|

       

MSH-2 Encoding Characters (ST) 00002

Definition: This field contains the four characters in the following order: the component separator, repetition separator, escape character, and subcomponent

separator. Required values are ^~\& (ASCII 94, 126, 92, and 38, respectively).

MSH-3 Sending Application (HD) 00003

Definition: This field uniquely identifies the sending application. The value is locally define and often assigned by the IIS in  User-defined table 0361. This is not

the product, but rather the name of the specific instance. For instance, the IIS in Georgia(GRITS) is an instance based on the Wisconsin IIS (WIR). The code for

GRITS would be specific to GRITS.

MSH-4 Sending Facility (HD) 00004

Definition: This field identifies the organization responsible for the operations of the sending application. Locally defined codes accommodate local needs. The

first component shall be the name space id found in User-defined Table 0362. The second and third components are reserved for use of OIDs.

23 This applies when the message will trigger an “AR” in MSA-1 because the incoming message had one of the following issues: Unsupported message type,

Unsupported event code, Unsupported processing ID or Unable to process for reasons unrelated for format or content.  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 81 
Chapter 5: Segments and Message Details

MSH-5 Receiving Application (HD) 00005

Definition: This field uniquely identifies the receiving application. This is not the product, but rather the name of the specific instance. For instance, the IIS in

Georgia(GRITS) is an instance based on the Wisconsin IIS (WIR). The code for GRITS would be specific to GRITS. Locally defined codes accommodate local

needs.

MSH-6 Receiving Facility (HD) 00006

Definition: This field identifies the organization responsible for the operations of the receiving application. Locally defined codes will accommodate local needs.

MSH-7 Date/Time Of Message (TS_Z) 00007

Definition: This field contains the date/time that the sending system created the message. The degree of precision must be to the second and include time zone.

MSH-9 Message Type (MSG) 00009

Definition: This field contains the message type, trigger event, and the message structure ID for the message.

MSH-10 Message Control ID (ST) 00010

Definition: This field contains the identifier assigned by the sending application (MSH.3) that uniquely identifies a message instance. This identifier is unique

within the scope of the sending facility (MSH.4), sending application (MSH.3), and the YYYYMMDD portion of message date (MSH.7). The receiving system

echoes this ID back to the sending system in the Message acknowledgment segment (MSA). The content and format of the data sent in this field is the

responsibility of the sender.

MSH-11 Processing ID (PT) 00011

Definition: This field is used to decide whether to process the message as defined in HL7 Application (level 7) Processing rules. Reference Table HL7 0103 in

Appendix A. The choices are Production, Debugging and Training. In most cases, P or Production should be used.

MSH-12 Version ID (VID) 00012

Definition: This field contains the identifier of the version of the HL7 messaging standard used in constructing, interpreting, and validating the message. Only the

first component need be populated.

Messages conforming to the specifications in this Guide shall indicate that the version is 2.5.1.  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 82 
Chapter 5: Segments and Message Details

MSH-15 Accept Acknowledgment Type (ID) 00015

Definition: This field identifies the conditions under which accept acknowledgments are required to be returned in response to this message. It is Required for

enhanced acknowledgment mode. This Implementation Guide does not support Enhanced acknowledgement mode. Refer to HL7 Table 0155 – Accept/application

acknowledgment conditions for valid values.

Accept acknowledgement indicates if the message was safely received or not. It does not indicate successful processing. Application acknowledgement indicates

the outcome of processing.

MSH-16 Application Acknowledgment Type (ID) 00016

Definition: This field contains the conditions under which application acknowledgments are required to be returned in response to this message.

MSH-17 Country Code (ID) 00017

Definition: This field contains the country of origin for the message. The values to be used are those of ISO 3166,.24. The ISO 3166 table has three separate

forms of the country code: HL7 specifies that the 3-character (alphabetic) form be used for the country code. If this field is not valued, then assume that the code

is USA.

Refer to HL7 Table 0399 – Country code for the 3-character codes as defined by ISO 3166-1.

MSH-21 Message Profile Identifier (EI) 01598

Definition: Sites may use this field to assert adherence to, or reference, a message profile. Message profiles contain detailed explanations of grammar, syntax, and

usage for a particular message or set of messages. Chapter 7 describes the query profile for requesting an immunization history. It also includes child profiles that

constrain the response to the query.

MSH-22 Responsible Sending Organization

Definition: Business organization that originated and is accountable for the content of the message.

Currently, MSH provides fields to transmit both sending/receiving applications and facilities (MSH.3 – MSH.6). However, these levels of organization

do not necessarily relate to or imply a legal entity such as a business organization. As such, multiple legal entities (organizations) may share a service

bureau, with the same application and facility identifiers. Another level of detail is required to delineate the various organizations using the same service

bureau.

24  Available from ISO 1 Rue de Varembe, Case Postale 56, CH 1211, Geneve, Switzerland 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 83 
Chapter 5: Segments and Message Details

Therefore, the Sending Responsible Organization field provides a complete picture from the application level to the overall business level. The Business

Organization represents the legal entity responsible for the contents of the message.

MSH-23 Responsible Receiving Organization

Definition: Business organization that is the intended receiver of the message and is accountable for acting on the data conveyed by the transaction.

This field has the same justification as the Sending Responsible Organization except in the role of the Receiving Responsible Organization.  The

receiving organization has the legal responsibility to act on the information in the message.

NK1—Next of Kin Segment

The NK1 segment contains information about the patient’s other related parties. Any associated parties may be identified. Utilizing NK1-1 – set ID, multiple NK1

segments can be sent to patient accounts. That is, each subsequent NK1 increments the previous set ID by 1. So if 3 NK1 were sent in one message, the first

would have a set id of 1, the second would have 2 and the third would have 3. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 84 
Chapter 5: Segments and Message Details

Table 5-4 Next of Kin Segment (NK1)

Table 5-5 Next of Kin Segment (NK1)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional Predicate Value

set

Description/Comment

1 Set ID – NK1 SI R [1..1]

2 Name XPN R [1..*]    The first instance is the legal

name and is required.

3 Relationship CE R [1..1]   HL70063

4 Address XAD RE [0..*]    The first instance shall be the

primary address.

5 Phone Number XTN RE [0..*]    The first instance shall be the

primary phone number.

6 Business Phone

Number

XTN O

7 Contact Role CE O

8 Start Date DT O

9 End Date DT O

10 Next of Kin /

Associated

Parties Job Title

ST O

11 Next of Kin /

Associated

Parties Job

Code/Class

JCC O

12 Next of Kin /

Associated

Parties

Employee

Number

CX O

13 Organization XON O      
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 85 
Chapter 5: Segments and Message Details

Table 5-5 Next of Kin Segment (NK1)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional Predicate Value

set

Description/Comment

Name – NK1

14 Marital Status CE O

15 Administrative

Sex

IS O

16 Date/Time of

Birth

TS O

17 Living

Dependency

IS O

18 Ambulatory

Status

IS O

19 Citizenship CE O

20 Primary

Language

CE O

21 Living

Arrangement

IS O

22 Publicity Code CE O

23 Protection

Indicator

ID O

24 Student

Indicator

IS O

25 Religion CE O

26 Mother’s Maiden

Name

XPN O

27 Nationality CE O

28 Ethnic Group CE O

29 Contact Reason CE O      
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 86 
Chapter 5: Segments and Message Details

Table 5-5 Next of Kin Segment (NK1)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional Predicate Value

set

Description/Comment

30 Contact

Person’s Name

XPN O

31 Contact

Person’s

Telephone

Number

XTN O

32 Contact

Person’s

Address

XAD O

33 Next of

Kin/Associated

Party’s

Identifiers

CX O

34 Job Status IS O

35 Race CE O

36 Handicap IS O

37 Contact Person

Social Security

Number

ST O

38 Next of Kin Birth

Place

ST O

39 VIP Indicator IS O      
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 87 
Chapter 5: Segments and Message Details

NK1 field definitions

NK1-1   Set ID – NK1   (SI)   00190

Definition: This field contains the number that identifies this transaction. For the first occurrence of the segment, the sequence number shall be one, for

the second occurrence, the sequence number shall be two, etc.

NK1-2   Name   (XPN)   00191

Definition:  This field contains the name of the next of kin or associated party. Multiple names for the same person are allowed, but the legal name must

be sent in the first sequence. Refer to HL7 Table 0200 – Name Type for valid values.

NK1-3   Relationship   (CE)   00192

Definition:  This field contains the actual personal relationship that the next of kin/associated party has to the patient. Refer to User-defined Table 0063 –

Relationship for suggested values.

NK1-4   Address   (XAD)   00193

Definition:  This field contains the address of the next of kin/associated party. Multiple addresses are allowed for the same person. The mailing address

must be sent in the first sequence. If the mailing address is not sent, then the repeat delimiter must be sent in the first sequence.

Note that an NK1 with a relationship of Self, may contain the patient’s address, but the preferred location for a patient’s address

NK1-5   Phone Number   (XTN)   00194

Definition:  This field contains the telephone number of the next of kin/associated party. Multiple phone numbers are allowed for the same person. The

primary telephone number must be sent in the first sequence. If the primary telephone number is not sent, then the repeat delimiter must be sent in the

first sequence. Refer to HL7 Table 0201 – Telecommunication Use Code and HL7 Table 0202 – Telecommunication Equipment Type for valid values.

NK1-6   Business Phone Number   (XTN)   00195

Definition:  This field contains the business telephone number of the next of kin/associated party. Multiple phone numbers are allowed for the same

person. The primary business telephone number must be sent in the first sequence. If the primary telephone number is not sent, then the repeat delimiter

must be sent in the first sequence. Refer to HL7 Table 0201 – Telecommunication Use Code and HL7 Table 0202 – Telecommunication Equipment Type

for valid values.

NTE—Note Segment

The NTE segment is used for sending notes and comments.  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 88 
Chapter 5: Segments and Message Details

Table 5-5 Note Segment (NTE)

Table 5-6 Note Segment (NTE)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional Predicate Value

Set

Comment

1 Set ID – NTE SI O

2 Source of

Comment

ID O

3 Comment FT R [1..1]

4 Comment Type CE O

NTE field definitions

NTE-3 Comment (FT) 00098

Definition: This field contains the comment contained in the segment.

OBX—Observation Result Segment

The observation result segment has many uses. It carries observations about the object of its parent segment. In the VXU/RSP it is associated with the RXA or

immunization record. The basic format is a question (OBX-3) and an answer (OBX-5).

Consult Appendix B for detailed examples of each of the uses.  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 89 
Chapter 5: Segments and Message Details

Table 5-6 Observation Segment (OBX)

Table 5-7 Observation Segment (OBX)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional

Predicate

Value Sets Comment 
1 Set ID – OBX SI R [1..1] 1..4

2 Value Type ID R [1..1] 2..3  HL70125

(constrained) 
3 Observation

Identifier

CE R [1..1]

NIP003 
This indicates what this

observation refers to. It poses

the question that is answered by

OBX-5.

4 Observation

Sub-ID

ST R [1..1] 1..20  Constrain to

positive

integers 
5 Observation

Value

varies25 R [1..1]   varies This is the observation value and

answers the question posed by

OBX-3

6 Units CE C(R/O) [0..1]  If OBX-2(Value Type) is

valued “NM” or “SN”  
Note: If there is not a unit of

measure available while

the Condition Predicated is

true, then the value “NA”

SHALL be used in CE.1

and “HL70353” in CE.3.

UCUM

7 References ST O

25  The length of the observation field is variable, depending upon value type. See OBX-2 value type. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 90 
Chapter 5: Segments and Message Details

Table 5-7 Observation Segment (OBX)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional

Predicate

Value Sets Comment

Range

8 Abnormal

Flags

IS O

9 Probability NM O

10 Nature of

Abnormal Test

ID O

11 Observation

Result Status

ID R [1..1] 1 HL70085

(constrained)

12 Effective Date

of Reference

Range Values

TS O

13 User Defined

Access

Checks

ST O

14 Date/Time of

the

Observation

TS_NZ RE [0..1]

15 Producer’s

Reference

CE O

16 Responsible

Observer

XCN O

17 Observation

Method

CE C(RE/O) [0..1] If OBX-3.1 is “64994-7” CDCPHINVS 64994 -7 is a LOINC meaning

“funding program eligibility”. This

field is used to distinguish

between eligibility that is

captured at the visit level versus

at the immunization event level.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 91 
Chapter 5: Segments and Message Details

Table 5-7 Observation Segment (OBX)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional

Predicate

Value Sets Comment 
18 Equipment

Instance

Identifier

EI O

19 Date/Time of

the Analysis

TS O

20 Reserved for

harmonization

with V2.6

 X

21 Reserved for

harmonization

with V2.6

 X

22 Reserved for

harmonization

with V2.6

 X

23 Performing

Organization

Name

XON O

24 Performing

Organization

Address

XAD O

25 Performing

Organization

Medical

Director

XCN O

Conformance Statement:

IZ-20: The Value of OBX-1 (Set ID-OBX) SHALL be valued sequentially starting with the value “1” within a message.

IZ-44: The value of OBX-4 SHALL be a positive integer. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 92 
Chapter 5: Segments and Message Details

IZ-21: The value of OBX-2 (Value Type) SHALL be one of the following:

CE, NM, ST, DT, ID or TS

IZ-22: The value of OBX-11 (Observation Result Status) SHALL be “F”

IZ-35: If OBX-3.1 is “64994-7” and OBX-2 is “CE” then the value set for OBX-5 shall be HL70064.

IZ-36: If OBX-3.1 is “69764-9” and OBX-2 is “CE” then the value set for OBX-5 shall be cdcgs1vis.

IZ-37: If OBX-3.1 is “30956-7” and OBX-2 is “CE” then the value set for OBX-5 shall be CVX.

OBX field definitions

OBX-1 Set ID – OBX (SI) 00569

Definition: This field contains the sequence number. The first instance shall be set to 1 and each subsequent instance shall be the next number in

sequence. Numbering is not restarted within a message.  That is, if a message had 3 order groups and each had 3 OBX, the last OBX in the message

would have value of 9 for this field.

OBX-2 Value Type (ID) 00570

Definition: This field contains the format of the observation value in OBX. If the value is CE then the result must be a coded entry.

OBX-3 Observation Identifier (CE) 00571

Definition: This field contains a unique identifier for the observation. The format is that of the Coded Element (CE).

Example: |64994-7^funding pgm elig^LN|.

The identifier will point to a master observation table that will provide other attributes of the observation that may be used by the receiving system to process the

observations it receives. This may be thought of as a question that the observation answers. In the example above, the question is “what funding program was this

person eligible for when this vaccine was administered” The answer in OBX-5 could be “VFC eligible – MEDICAID”.

LOINC shall be the standard coding system for this field if an appropriate LOINC code exists. Appropriate status is defined in the LOINC Manual Section 11.2

Classification of LOINC Term Status. If a local coding system is in use, a local code should also be sent to help with identification of coding issues. When no

valid LOINC exists the local code may be the only code sent.  When populating this field with values, this guide does not give preference to the triplet in which

the standard (LOINC) code should appear.

The 2.3.1 Implementation Guide used suffixes on the first sequence in OBX-3 to group related observations. For instance, reporting a VIS publication date and VIS

receipt date each added a suffix of one LOINC code to a second LOINC code when recording VIS dates for a component vaccine. (38890-0&29768-9^DATE

VACCINE INFORMATION STATEMENT PUBLISHED^LN)  This is no longer acceptable. Grouping of related observations will be accomplished using Observation 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 93 
Chapter 5: Segments and Message Details

sub-id (OBX-4).

OBX-4 Observation Sub-ID (ST) 00572

Definition: This field is used to group related observations by setting the value to the same number. For example, recording VIS date and VIS receipt

date for a combination vaccination requires 6 OBX segments. One OBX would indicate the vaccine group. It would have a pair of OBX indicating the

VIS publication date and the VIS receipt date. These would have the same OBX-4 value to allow them to be linked. The second set of three would have

another OBX-4 value common to each of them.

This field may be used to link related components of an observation. Each related component of the observation would share an Observation sub-id. 
For example:

OBX|1|LN|^observation 1 part 1^^^^^|1|…

OBX|2|LN|^ observation 1 part 2^^^^^|1|…

OBX|3|DT|^a different observation^^^^^|2|…

Example:

OBX|1|CE|64994-7^Eligibility Status^LN|1|V02^Medicaid^HL70064||||||F|||20120113|||VXC40^vaccine

level^CDCPHINVS 
OBX|2|DT|29769-7^VIS presented^LN|2|20120113||||||F|||20120113 
OBX|3|CE|69764-9^Document Type^LN|2|253088698300026411121116^Multivaccine

VIS^cdcgs1vis||||||F|||20120113

OBX-5 Observation Value (varies) 00573

Definition: This field contains the value observed by the observation producer. OBX-2-value type contains the data type for this field according to

which observation value is formatted.

This field contains the value of OBX-3-observation identifier of the same segment. Depending upon the observation, the data type may be a number

(e.g., dose number), a coded answer (e.g., a vaccine), or a date/time (the date/time that the VIS was given to the client/parent). An observation value is

always represented as the data type specified in OBX-2-value type of the same segment. Whether numeric or short text, the answer shall be recorded in

ASCII text. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 94 
Chapter 5: Segments and Message Details

OBX-6 Units (CE) 00574

Definition: This shall be the units for the value in OBX-5. The value shall be from the UCUM list of units.

OBX-11 Observation Result Status (ID) 00579

Definition: This field contains the observation result status. The expected value is F or final.

OBX-14 Date/Time of the Observation (TS_NZ) 00582

Definition: Records the time of the observation. It is the physiologically relevant date-time or the closest approximation to that date-time of the

observation.

OBX-17 Observation Method (CE)

Definition: This optional field can be used to transmit the method or procedure by which an observation was obtained when the sending system wishes

to distinguish among one measurement obtained by different methods and the distinction is not implicit in the test ID.

In this Guide, it shall be used to differentiate the way that VFC Eligibility Status was collected. The two choices are:

• Recorded in the sending system at the visit level

• Recorded in the sending system at the immunization level

See examples in Appendix B (Example VXU #2)

Application Conformance Statement:

There are a number of core data elements that are important to support a complete immunization history and the functional requirements of a Immunization

Information System (IIS). Some of these utilize the OBX to carry their data. The following table lists the data elements and the usage responsibilities.

Table 5-7 Application Conformance Statements

Table 5-8 Application Conformance Statements

Core Data Element Description Observation

Identifier

(OBX-3)

Observation

Value Set

(OBX-5)

Conformance Statements

Patient Eligibility Category  for

Vaccine Funding Program This value represents the funding

program that should pay for a

64994-7 HL70064 IZ-23: If RXA-20 is valued “CP” or “PA”  and the

first occurrence of RXA-9.1 (Administration 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 95 
Chapter 5: Segments and Message Details

Table 5-8 Application Conformance Statements

Core Data Element Description Observation

Identifier

(OBX-3)

Observation

Value Set

(OBX-5)

Conformance Statements

given immunization. It is

determined based on

characteristics of the patient/client

and the type of vaccine

administered.

Note.code) is “00” then the message SHALL

include an OBX segment associated with the RXA

with OBX-3.1 shall equal “64994-7” . This OBX

will indicate the Patient Eligibility Category for

Vaccine Funding Program.

Vaccine Information Statement

(VIS) document type This value represents the vaccine

type that the statement provides

information about.

69764-9 cdcgs1vis See VIS related Conformance Statements below.

Vaccine Information Statement

(VIS) version date This value represents the date the

presented VIS was published

29768-9 
Note that this approach to reporting VIS document

type is maintained for backward compatibility. The

preferred method uses VIS document type approach

using code 69764-9. See VIS related Conformance

Statements below

VIS vaccine type

This value represents the vaccine

type that the statement provides

information about. In the cases

where there are multiple vaccines

that can be used, the correct

choice is the unspecified vaccine

CVX (e.g. CVX 17 (HIB,

unspecified formulation) for any

HIB vaccine administered.

30956-7 CVX Note that this approach to reporting VIS document

type is maintained for backward compatibility. The

preferred method uses VIS document type approach

using code 69764-9.

Vaccine Information Statement

(VIS) delivery date This value represents the date the

document was presented to the

29769-7 
See VIS related Conformance Statements below 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 96 
Chapter 5: Segments and Message Details

Table 5-8 Application Conformance Statements

Core Data Element Description Observation

Identifier

(OBX-3)

Observation

Value Set

(OBX-5)

Conformance Statements

patient/responsible person. 
NOTE: There are three things that need to be recorded for documenting VIS:

1. Date VIS was shared with patient or parent

2. Vaccine that the VIS refers to

3. Edition Date of VIS

There are 2 ways that this data is captured.  First, it may be captured as vaccine type, Edition/Version Date and presentation date. VIS is bar coded with a 2-d bar

code using a Global Document Type Identifier (GDTI). This bar code indicates the specific document type that has been presented and the edition date may be

inferred from the bar code.

The second approach (use the string representation of the GDTI) is preferred.  There is a multi-vaccine VIS that cannot be represented using the vaccine type

approach. The vaccine type approach is included in this Implementation Guide for backward compatibility.

VIS documentation is required for all patients, but only for specific vaccines.  Note that the most current list will be found on PHIN VADS.

See table Value Set Code: PHVS_VISVaccines_IIS in Appendix A.

VIS Conformance Statements:

IZ-24: If RXA-20 is valued “CP” or “PA”  and the first occurrence of RXA- 9.1 is valued “00” and RXA-5.1 is valued with a CVX code from table

PHVS_VISVaccines_IIS (See Appendix A) then for each vaccine information statement that was shared  there SHALL be:

• one OBX segment with OBX-3.1 valued “69764-9” (bar coded)  and one OBX with OBX-3.1 valued “29769-7” (presentation /delivery date)

associated. Both OBX shall have the same value in OBX-4

OR

• one OBX segment with OBX-3.1 valued “30956-7” (vaccine type) and one OBX segment with OBX-3.1 valued “29768-9” (version date)

and  one OBX with OBX-3.1 valued “29769-7” (presentation /delivery date) associated. All three OBX shall have the same value in OBX-4 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 97 
Chapter 5: Segments and Message Details

Note that 30956-7 (vaccine type) is preferred over the alternative 38890-0 (Component Vaccine Type) even when the vaccine administered is a combination

vaccine. For this reason, the test will compare to the 30956-7 value.

ORC—Order Request Segment

The Common Order segment (ORC) is used to transmit fields that are common to all orders (all types of services that are requested). While not all immunizations

recorded in an immunization message are able to be associated with an order, each RXA must be associated with one ORC, based on HL7 2.5.1 standard.  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 98 
Chapter 5: Segments and Message Details

Table 5-8 Common Order Segment (ORC)

Table 5-9 Common Order Segment (ORC)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional

Predicate

Value Set Comment

1 Order Control ID R [1..1] 2  HL70119

(constrained) 
2 Placer Order

Number

EI RE [0..1]    See Guidance below.

3 Filler Order

Number

EI R [1..1]    See Guidance below.

4 Placer Group

Number

EI O

5 Order Status ID O

6 Response Flag ID O

7 Quantity/Timin

g

TQ X

8 Parent EIP O

9 Date/Time of

Transaction

TS O

10 Entered By XCN RE [0..1]    This is the person that entered

this immunization record into the

system.

11 Verified By XCN O

12 Ordering

Provider

XCN C(RE/O) [0..1]  If the first occurrence of

RXA-9.1 is valued “00”

and RXA-20 is valued

“CP” or “PA”

 This shall be the provider

ordering the immunization. It is

expected to be empty if the

immunization record is

transcribed from a historical

record.

13 Enterer’s PL O      
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 99 
Chapter 5: Segments and Message Details

Table 5-9 Common Order Segment (ORC)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional

Predicate

Value Set Comment

Location

14 Call Back

Phone Number

XTN O

15 Order Effective

Date/Time

TS O

16 Order Control

Code Reason

CE O

17 Entering

Organization

CE RE    HL70362 This is the provider organization

that entered this record/order.

18 Entering

Device

CE O

19 Action By XCN O

20 Advanced

Beneficiary

Notice Code

CE O

21 Ordering

Facility Name

XON O

22 Ordering

Facility

Address

XAD O

23 Ordering

Facility Phone

Number

XTN O

24 Ordering

Provider

Address

XAD O

25 Order Status CWE O      
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 100 
Chapter 5: Segments and Message Details

Table 5-9 Common Order Segment (ORC)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional

Predicate

Value Set Comment

Modifier

26 Advanced

Beneficiary

Notice

Override

Reason

CWE O

27 Filler’s

Expected

Availability

Date/Time

TS O

28 Confidentiality

Code

CWE O

29 Order Type CWE O

30 Enterer

Authorization

Mode

CNE O

31 Parent

Universal

Service

Identifier

CWE O

Conformance Statement:

IZ-25: ORC.1 (Order Control) SHALL contain the value “RE “

IZ-45: If RXA-20 is valued “NA” or “RE” then ORC-3 SHALL be valued “9999”. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 101 
Chapter 5: Segments and Message Details

ORC field definitions

ORC-1   Order Control   (ID)   00215

Definition:  Determines the function of the order segment.

The value for VXU and RSP shall be RE.

Placer Order Number (ORC-2) and Filler Order Number (ORC-3) are unique identifiers from the system where an order was placed and where the order

was filled. They were originally designed for managing lab orders. These fields have a usage status of Conditional in Version 2.5.1. The condition for each

is that they must be present in either the OBR or ORC of a message. There has been confusion about usage for these fields. The Orders and

Observations workgroup has addressed this confusion. In the context that ORC will be used in Immunization messaging ORC-3 must be populated. They

may both be populated.

This Guide specifies that Placer Order Number is RE (required, but may be empty). The Filler Order Number SHALL be the unique immunization id of the

sending system.

ORC-2   Placer Order Number   (EI)   00216

The placer order number is used to uniquely identify this order among all orders sent by a provider organization.

ORC-2 is a system identifier assigned by the placer software application. The Placer Order Number and the Filler Order Number are essentially foreign

keys exchanged between applications for uniquely identifying orders and the associated results across applications.

In the case where the ordering provider organization is not known, the sending system may leave this field empty.

ORC-3   Filler Order Number   (EI)   00217

The filler order number is used to uniquely identify this order among all orders sent by a provider organization that filled the order.

This shall be the unique identifier of the sending system in a given transaction. In the case where system A sends the record to system B and system B

then forwards to system C, system B will send its’ own unique identifier.

Use of this foreign key will allow the initiating system to accurately identify the previously sent immunization record, facilitating update or deletion of that

record.

In the case where a historic immunization is being recorded (i.e. from an immunization card), the sending system SHALL assign an identifier as if it were

an immunization administered by a provider associated with the provider organization owning the sending system.

In the case where an RXA is conveying information about an immunization which was not given (e.g. refusal) the filler order number shall be 9999.

Note that the receiving system will need to store this value in addition to it’s own internal id in order for this to be used. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 102 
Chapter 5: Segments and Message Details

ORC-10   Entered By   (XCN)   00224

Definition: This identifies the individual that entered this particular order. It may be used in conjunction with an RXA to indicate who recorded a

particular immunization.

ORC-12   Ordering Provider   (XCN)   00226

Definition:  This field contains the identity of the person who is responsible for creating the request (i.e., ordering physician). In the case where this

segment is associated with a historic immunization record and the ordering provider is not known, then this field should not be populated.

ORC-17   Entering Organization   (CE)   00231

Definition:  This field identifies the organization that the enterer belonged to at the time he/she enters/maintains the order, such as medical group or

department. The person who entered the request is defined in ORC-10 (entered by).

ORC –28   Confidentiality Code   (CWE)   00615

This field allows a system to indicate if special privacy rules apply to the RXA that is associated with this ORC. For instance, if a state had special rules

about who may see records for HPV vaccinations, then this field could convey that. The recommended value to use in this case is R for restricted.

If this field is populated, it indicates the active choice of the patient or responsible person. In other words, if the value indicates that the information must

be protected, the person has stated that it must be protected. An empty field indicates that the client has not actively specified the way they want this data

to be handled.

Local implementation guides should describe the local usage of this field and value.

PD1—Patient Demographic Segment

The Patient Demographic Segment contains patient demographic information that may change from time to time. There are three primary uses PD1 for in

Immunization Messages. These include indicating whether the person wants his/her data protected, whether the person wants to receive recall/reminder notices

and the person’s current status in the registry. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 103 
Chapter 5: Segments and Message Details

Table 5-9 Patient Demographic Segment (PD1)

Table 5-10 Patient Demographic Segment (PD1)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional Predicate Value

Set

Comment

1 Living

Dependency

IS O

2 Living

Arrangement

IS O

3 Patient Primary

Facility

XON  O

4 Patient Primary

Care Provider

Name & ID No.

XCN  X

5 Student

Indicator

IS O

6 Handicap IS O

7 Living Will Code IS O

8 Organ Donor

Code

IS O

9 Separate Bill ID O

10 Duplicate

Patient

CX O

11 Publicity Code CE RE  [0..1]   HL70215

12 Protection

Indicator

ID RE  [0..1]   HL70136

13 Protection

Indicator

Effective Date

DT_T C(RE/X) [0..1]   If PD1-12 (Protection Indicator)

is valued 
14 Place of XON O       
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 104 
Chapter 5: Segments and Message Details

Table 5-10 Patient Demographic Segment (PD1)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional Predicate Value

Set

Comment

Worship

15 Advance

Directive Code

CE O

16 Immunization

Registry Status

IS RE [0..1]    HL70441

17 Immunization

Registry Status

Effective Date

DT_T C(RE/X) [0..1]   If the PD1-16 (Registry Status)

field is valued. 
18 Publicity Code

Effective Date

DT_T C(RE/X) [0..1]   If the PD1-11 (Publicity Code)

field is valued. 
19 Military Branch IS O

20 Military

Rank/Grade

IS O

21 Military Status IS O      
PD1 field definitions

PD1-3 Patient Primary Facility (XON) 00756

Definition: This field contains the name and identifier that specifies the “primary care” healthcare facility selected by the patient at the time of

enrollment in an HMO Insurance Plan.  It is not the Primary Care Practitioner or Medical Home.

The meaning of this field should not be expanded to include the concept of medical home.

PD1-11 Publicity Code (CE) 00743

Definition: This field contains a user-defined code indicating what level of publicity is allowed (e.g., No Publicity, Family Only) for the patient. In the

context of immunization messages, this refers to how a person wishes to be contacted in a reminder or recall situation. Refer to User-defined Table 0215

– Publicity Code for suggested values.  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 105 
Chapter 5: Segments and Message Details

PD1-12 Protection Indicator (ID) 00744

Definition: This field identifies whether a person’s information may be shared with others26. Specific protection policies are a local consideration (opt in

or opt out, for instance). This field conveys the current state in the sending system.

The protection state must be actively determined by the clinician. If it is not actively determined, then the protection indicator shall be empty.

There are 3 states: 
Protection State  Code

Yes, protect the data. Client (or guardian) has indicated that the

information shall be protected. (Do not share data)

Y

No, it is not necessary to protect data from other clinicians. Client (or

guardian) has indicated that the information does not need to be

protected. (Sharing is OK)

N

No determination has been made regarding client’s (or guardian’s) wishes

regarding information sharing

PD1-12 is empty. 
Notes on use of Y for Protection Indicator in 2.5.1 Guide vs. earlier Guides.

Note that the previous Implementation Guide stated that Y meant that a person’s information could be shared. This was an incorrect interpretation of the

use of this field. The meaning now aligns with the definition of HL7. That is, Y means data must be protected. Existing systems that use the old meaning

will need to determine how they will send the correct value in a 2.5.1 message.  
Note that the value sent in a message that is based on the 2.3.1 or 2.4 version of the HL7 standard shall continue to follow the old guidance. That is, Y

means sharing is allowed and N means sharing is not allowed.

26 Local policies determine how data are protected. In general, it indicates who may view the client’s data. It may be as narrow as just the provider that entered the information. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 106 
Chapter 5: Segments and Message Details 
Note on Null and Empty in HL7

See notes on null and empty fields in Chapter 3.

PD1-13 Protection Indicator Effective Date (DT) 01566

Definition: This field indicates the effective date for PD1-12 – Protection Indicator.

PD1-16 Immunization Registry Status (IS) 01569

Definition: This field identifies the current status of the patient in relation to the sending provider organization.. Refer to User-defined Table 0441 –

Immunization Registry Status for suggested values.

This field captures whether the sending provider organization considers this an active patient. There are several classes of responsibility. The status may

be different between the sending and receiving systems.  For instance, a person may no longer be active with a provider organization, but may still be

active in the public health jurisdiction, which has the Immunization Information System (IIS). In this case the provider organization would indicate that the

person was inactive in their system using this field in a message from them.  The IIS would indicate that person was active in a message from the IIS.

PD1-17 Immunization Registry Status Effective Date (DT) 01570

Definition: This field indicates the effective date for the registry status reported in PD1-16 – Immunization Registry Status.

PD1-18 Publicity Code Effective Date (DT) 01571

Definition: This is the effective date for PD1-11 – Publicity Code.

PID—Patient Identifier Segment

The PID is used by all applications as the primary means of communicating patient identification information. This segment contains permanent patient

identifying and demographic information that, for the most part, is not likely to change frequently.   
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 107 
Chapter 5: Segments and Message Details

Table 5-10 Patient Identifier Segment (PID)

Table 5-11 Patient Identifier Segment (PID)

SEQ Element

Name

Data

Type

Usag

e

Cardinality LEN Conditional Predicate Value

Set

Constraint

1 Set ID – PID SI R [1..1]      
2 Patient ID CX X

3 Patient

Identifier List

CX R [1..*]

4 Alternate

Patient ID –

00106

CX X

5 Patient Name XPN R [1..*]     The first repetition shall contain the

legal name. Multiple given names

or initials are separated by spaces.

6 Mother’s

Maiden Name

XPN_M RE [0..1]

7 Date/Time of

Birth

TS_NZ R [1..1]

8 Administrative

Sex

IS RE [0..1]   HL70001

9 Patient Alias XPN X

10 Race CE RE [0..*]   HL70005

11 Patient

Address

XAD RE [0..*]      The first repetition should be the

primary address.

12 County Code IS X     County belongs in address field. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 108 
Chapter 5: Segments and Message Details

Table 5-11 Patient Identifier Segment (PID)

SEQ Element

Name

Data

Type

Usag

e

Cardinality LEN Conditional Predicate Value

Set

Constraint

13 Phone

Number –

Home

XTN RE [0..*]      The first instance shall be the

primary phone number.

Only one item is allowed per

repetition.

14 Phone

Number –

Business

XTN O

15 Primary

Language

CE O

16 Marital Status CE O

17 Religion CE O

18 Patient

Account

Number

CX O

19 SSN Number –

Patient

ST X

20 Driver’s

License

Number –

Patient

DLN X

21 Mother’s

Identifier

CX X       
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 109 
Chapter 5: Segments and Message Details

Table 5-11 Patient Identifier Segment (PID)

SEQ Element

Name

Data

Type

Usag

e

Cardinality LEN Conditional Predicate Value

Set

Constraint

22 Ethnic Group CE RE [0..1]   CDCREC

23 Birth Place ST O

24 Multiple Birth

Indicator

ID

RE [0..1]

  HL70136 The acceptable values are Y and

N. If the status is undetermined,

then field shall be empty.

25 Birth Order NM C(RE/O

)

[0..1] 1..2 If PID-24 (Multiple Birth

Indicator) is valued “Y “ 
  This field contains a number

indicating the person’s birth order,

with 1 for the first child born and 2

for the second.

26 Citizenship CE O

27 Veterans

Military Status

CE O

28 Nationality  CE O

29 Patient Death

Date and Time

TS C(RE/X

)

[0..1]  If PID-30 (patient death

indicator) is valued “Y” 
30 Patient Death

Indicator

ID RE [0..1]   HL70136

31 Identity

Unknown

Indicator

ID O      
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 110 
Chapter 5: Segments and Message Details

Table 5-11 Patient Identifier Segment (PID)

SEQ Element

Name

Data

Type

Usag

e

Cardinality LEN Conditional Predicate Value

Set

Constraint

32 Identity

Reliability

Code

IS O

33 Last Update

Date/Time

TS O

34 Last Update

Facility

HD O

35 Species Code CE O

36 Breed Code CE O

37 Strain ST O

38 Production

Class Code

CE O

39 Tribal

Citizenship

CWE O      
Conformance Statement:

IZ-46: PID-1 (Set ID) SHALL have the literal value “1”

PID field definitions

PID-1 Set ID – PID (SI) 00104

Definition: This field contains the number that identifies this transaction. For the first occurrence of the segment, the sequence number shall be one, for

the second occurrence, the sequence number shall be two, etc.

PID-3 Patient Identifier List (CX) 00106

Definition: This field contains the list of identifiers (one or more) used by the healthcare facility to uniquely identify a patient (e.g., medical record

number, billing number, birth registry, national unique individual identifier, etc.).  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 111 
Chapter 5: Segments and Message Details

PID-5 Patient Name (XPN) 00108

Definition: This field contains the names of the patient, The primary or legal name of the patient is reported first. Therefore, the name type code in this

field should be “L – Legal”. Refer to HL7 Table 0200 – Name Type for valid values.

PID-6 Mother’s Maiden Name (XPN) 00109

Definition: This field contains the family name under which the mother was born (i.e., before marriage). It is used to distinguish between patients with

the same last name.

PID-7 Date/Time of Birth (TS_NZ) 00110

Definition: This field contains the patient’s date and time of birth.

PID-8 Administrative Sex (IS) 00111

Definition: This field contains the patient’s sex. Refer to User-defined Table 0001 – Administrative Sex for suggested values.

PID-10 Race (CE) 00113

Definition: This field refers to the patient’s race. Refer to User-defined Table 0005 – Race for suggested values. The second triplet of the CE data type

for race (alternate identifier, alternate text, and name of alternate coding system) is reserved for governmentally assigned codes.

PID-11 Patient Address (XAD) 00114

Definition: This field contains the mailing address of the patient. Address type codes are defined by HL7 Table 0190 – Address Type. Multiple addresses

for the same person may be sent in the following sequence: The primary mailing address must be sent first in the sequence (for backward compatibility);

if the mailing address is not sent, then a repeat delimiter must be sent in the first sequence.

This field is used for any type of address that is meaningfully associated with the client/patient. For instance Birth State is the state of the address of the

birthing location, address type = BDL.

A person’s address may be sent in this field or in the NK1 segment with a relationship code indicating Self. A patient’s address should be in PID-11. It

may also be in NK1.

PID-13 Phone Number – Home  (XTN) 00116

Definition: This field contains the patient’s personal phone numbers. All personal phone numbers for the patient are sent in the following sequence. The

first sequence is considered the primary number (for backward compatibility). If the primary number is not sent, then a repeat delimiter is sent in the

first sequence. Each type of telecommunication shall be in its’ own repetition. For example, if a person has a phone number and an email address, they 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 112 
Chapter 5: Segments and Message Details

shall each have a repetition. Refer to HL7 Table 0201 – Telecommunication Use Code and HL7 Table 0202 – Telecommunication Equipment Type for

valid values.

PID-14 Phone Number – Business (XTN) 00117

Definition: This field contains the patient’s business telephone numbers. All business numbers for the patient are sent in the following sequence. The

first sequence is considered the patient’s primary business phone number (for backward compatibility). If the primary business phone number is not

sent, then a repeat delimiter must be sent in the first sequence. Refer to HL7 Table 0201 – Telecommunication Use Code and HL7 Table 0202 –

Telecommunication Equipment Type for valid values.

PID-22 Ethnic Group (CE) 00125

Definition: This field further defines the patient’s ancestry. Refer to Table CDCREC – Ethnic Group.

PID-24 Multiple Birth Indicator  (ID) 00127

Definition: This field indicates whether the patient was part of a multiple birth. Refer to HL7 Table 0136 – Yes/No Indicator for valid values.

Y the patient was part of a multiple birth

N the patient was a single birth

Empty field multiple birth status is undetermined.

PID-25 Birth Order (NM) 00128

Definition: When a patient was part of a multiple birth, a value (number) indicating the patient’s birth order is entered in this field. If PID-24 is

populated, then this field should be populated.

PID-29 Patient Death Date and Time (TS) 00740

Definition: This field contains the date and time at which the patient death occurred.

PID-30 Patient Death Indicator (ID) 00741

Definition: This field indicates whether the patient is deceased. Refer to HL7 Table 0136 – Yes/no Indicator for valid values.

Y the patient is deceased

N the patient is not deceased

Empty status is undetermined 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 113 
Chapter 5: Segments and Message Details

PV1—Patient Visit Segment

The PV1 segment is used to convey visit specific information. The primary use in immunization messages in previous releases was to carry information

about the client’s eligibility status. This is now recorded at the immunization event (dose administered) level. Use of this segment for the purpose of

reporting client eligibility for a funding program at the visit level is not supported in the Implementation Guide.

RXA– Pharmacy/Treatment Administration Segment

The RXA segment carries pharmacy administration data. It is a child of an ORC segment, which a repeating segment in the RSP and VXU messages. Because

ORC are allowed to repeat an unlimited numbers of vaccinations may be included in a message. Each RXA must be preceded by an ORC.27

27 The HL7 Version 2.5.1 document clearly indicates that any RXA must be associated with an ORC. In the case of immunization, each immunization will have its own ORC. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 114 
Chapter 5: Segments and Message Details

Table 5-11 Pharmacy/Treatment Administration (RXA)

Table 5-12 Pharmacy/Treatment Administration (RXA)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional Predicate Value

Set

Comment

1 Give Sub-ID

Counter

NM R [1..1] 4

2 Administration

Sub-ID Counter

NM R [1..1] 4

3 Date/Time Start

of Administration

TS_NZ R [1..1]    This segment may be used in

cases where a vaccine has not

been administered. For

instance a patient may refuse a

vaccination or the sending

system may be forecasting a

next dose due. See notes

below for guidance on the

relevant date to include here.

4 Date/Time End

of Administration

TS O [0..1]    See not below

5 Administered

Code

CE R [1..1]   CVX  Support for CVX code is

strongly preferred. Local IG

may identify NDC or CPT as

acceptable alternative code

sets.

6 Administered

Amount

NM R [1..1] 20

7 Administered

Units

CE C(R/O) [0..1]  If Administered Amount is not

valued “999”

UCUM The preferred units of measure

for this is “mL”.

8 Administered

Dosage Form

CE O [0..1]

9 Administration varies C(R/O) [0..*]  If RXA-20 is valued “CP” or NIP 0001 If this field is used for a notes 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 115 
Chapter 5: Segments and Message Details

Table 5-12 Pharmacy/Treatment Administration (RXA)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional Predicate Value

Set

Comment

Notes “PA” only entry, then the data type

shall be CE_TX otherwise the

data type shall be CE. 
The primary use of this field it to

convey if this immunization

record is based on a historical

record or was given by the

provider recording the

immunization. All systems

should be able to support this

use. Other uses of this field are

permitted, but need to be

specified locally.

10 Administering

Provider

XCN C(RE/O) [0..1]  If the first occurrence of

RXA-9.1 is valued “00”

and RXA-20 is valued

“CP” or “PA”

 This is the person who gave the

administration or the vaccinator.

It is not the ordering clinician.

11 Administered-at

Location

LA2 C(RE/O) [0..1]  If the first occurrence of

RXA-9.1 is valued “00”

and RXA-20 is valued

“CP” or “PA”

 This is the clinic/site where the

vaccine was administered.

12 Administered

Per (Time Unit)

ST O

13 Administered

Strength

NM O

14 Administered

Strength Units

CE O

15 Substance Lot ST C(R/O) [0..*]  If the first occurrence of  Note that “00” is double zero. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 116 
Chapter 5: Segments and Message Details

Table 5-12 Pharmacy/Treatment Administration (RXA)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional Predicate Value

Set

Comment

Number RXA-9.1 is valued “00”

and RXA-20 is valued

“CP” or “PA”

16 Substance

Expiration Date

TS_M C(RE/O) [0..1]  If the first occurrence of

RXA-9.1 is valued “00”

and RXA-20 is valued

“CP” or “PA” 
17 Substance

Manufacturer

Name

CE C(R/O) [0..1]  If the first occurrence of

RXA-9.1 is valued “00”

and RXA-20 is valued

“CP” or “PA”

MVX

18 Substance/Treat

ment Refusal

Reason

CE C(R/X) [0..*]  If the RXA-20 (Completion

Status) is valued “RE “

NIP002

19 Indication CE O

20 Completion

Status

ID RE [0..1] 2  HL70322

21 Action Code –

RXA

ID C(R/O) [0..1] 2 If RXA-5.1 is not valued “998” HL70323

22 System Entry

Date/Time

TS O

23 Administered

Drug Strength

Volume

NM O

24 Administered

Drug Strength

Volume Units

CWE O

25 Administered CWE O      
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 117 
Chapter 5: Segments and Message Details

Table 5-12 Pharmacy/Treatment Administration (RXA)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional Predicate Value

Set

Comment

Barcode

Identifier

26 Pharmacy Order

Type

ID O      
Conformance Statement:

IZ-28: RXA-1 ( Give Sub-id counter)  SHALL be valued “0”  Note that “0” is zero.

IZ-29: RXA-2 (admin Sub-id) SHALL be valued “1 “

IZ-30: If RXA-4 (Date time of admin end ) is populated, then it SHALL be the same as Start time (RXA-3)

IZ-31: If RXA-20 is valued “CP” or “PA” then RXA-9.1 (admin notes) SHALL be valued one of the codes listed in NIP001 in the first occurrence

of this field and the following repetition should be empty or valued with a text notes.

IZ-32: If the RXA-18 (Refusal Reason) is populated, RXA-20  SHALL be valued “RE”.

IZ-47: If RA-20 is NOT valued “CP” or “PA” then the first occurrence of RXA-9.1 (admin notes) SHALL be empty and the following repetitions

should be empty or valued with text notes.

IZ-48: If RXA-20 is valued “RE” then RXA-6 shall be valued “999”.

IZ-49: If RXA-5.3 is valued “998” then RXA-6 shall be valued “999”.

IZ-50: If the first instance of RXA-9.1 is not valued “00” then RXA-6 (administered amount) SHALL be valued “999”

RXA field definitions

RXA-1 Give Sub-ID Counter (NM) 00342

Definition: This field is used to match an RXA and RXG. Not a function under IIS.

Constrain to 0 (zero). 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 118 
Chapter 5: Segments and Message Details

RXA-2 Administration Sub-ID Counter (NM) 00344

Definition: This field is used to track multiple RXA under an ORC. Since each ORC has only one RXA in immunization messages, constrain to 1. This

should not be used for indicating dose number, which belongs in an OBX.

Note that the previous Implementation Guide suggested that this be used for indicating dose number. This use is no longer supported.

RXA-3 Date/Time Start of Administration (TS_NZ) 00345

Definition: The date this vaccination occurred. In the case of refusal or deferral, this is the date that the refusal or deferral was recorded. In the case of a

forecast dose, this is the date the forecast was made.

RXA-4 Date/Time End of Administration (If Applies) (TS) 00346

Definition: In the context of immunization, this is equivalent to the Start date/time. If populated it should be = RXA-3.

Note: This field is specified as required in the HL7 standard. In spite of being Required by the standard, the standard acknowledges that it may be

empty.  For immunization records, this has no use.  An immunization is given at a point in time. For this reason, this Implementation Guide has relaxed

the usage to Optional.

RXA-5 Administered Code (CE) 00347

Definition: This field identifies the medical substance administered. If the substance administered is a vaccine, CVX codes are required (see CVX Table

– Codes for vaccines administered). The second set of three components may be used to represent the same vaccine using a different coding system.

NDC codes are preferred.

RXA-6 Administered Amount (NM) 00348

Definition: This field records the amount of pharmaceutical administered. The units are expressed in the next field, RXA-7. When the administered

amount is unknown, this field should record the value “999” in this field.

RXA-7 Administered units (CE) 00349

Definition: This field is conditional because it is required if the administered amount code does not imply units. This field must be in simple units that

reflect the actual quantity of the substance administered. It does not include compound units. This field is not required if the previous field is populated

with 999. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 119 
Chapter 5: Segments and Message Details

RXA-9 Administration Notes (CE) 00351

Definition: This field is used to indicate whether this immunization record is based on a historical record or was given by the reporting provider. It

should contain the information source (see NIP-defined Table 0001 – Immunization Information Source). The first component shall contain the code, the

second the free text and the third shall contain the name of the code system. (NIP001)  Sending systems should be able to send this information.

Receiving systems should be able to accept this information.

This field may be used for other notes if specified locally. The first repetition shall be the information source. If other notes are sent when information

source is not populated, then the first repetition shall be empty.

Other notes may include text only in component 2 of the repeat. Acceptance of text only is by local agreement only.  
Information source is an NVAC core data element. It speaks to the reliability of the immunization record. IIS rely on this information.

RXA-10 Administering Provider (XCN) 00352

Definition: This field is intended to contain the name and provider ID of the person physically administering the pharmaceutical.  
Note that previous Implementation Guide (2.3.1) overloaded this field by using local codes to indicate administering provider, ordering provider and

recording provider. This is a misuse of this field and not supported in this Guide. The ordering and entering providers are indicated in the associated ORC

segment.

RXA-11 Administered-at Location (LA2) 00353

Definition: The name and address of the facility that administered the immunization. Note that the components used are:

Component 4: The facility name/identifier.

Subcomponent 1: identifier 28

Subcomponent 2: Universal ID This shall be an OID, if populated. Note that this should not be a local code, but rather a universal id code.

Subcomponent 3: Universal ID type (specify which universal id type)

Component 9-15: Facility address.

28 This value should uniquely identify a specific facility. Systems may choose to publish a table with local values.  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 120 
Chapter 5: Segments and Message Details

Components not specifically mentioned here are not expected in immunization messages.

RXA-15 Substance Lot Number (ST) 01129

Definition: This field contains the lot number of the medical substance administered. It may remain empty if the dose is from a historical record.

Note:  The lot number is the number printed on the label attached to the container holding the substance and on the packaging which houses the

container. If two lot numbers are associated with a product that is a combination of different components, they may be included in this field. The first

repetition should be the vaccine.

RXA-16 Substance Expiration Date (TS_M) 01130

Definition: This field contains the expiration date of the medical substance administered. It may remain empty if the dose is from a historical record.

Note: Vaccine expiration date does not always have a “day” component; therefore, such a date may be transmitted as YYYYMM.

RXA-17 Substance Manufacturer Name (CE) 01131

Definition: This field contains the manufacturer of the medical substance administered.

Note:  For vaccines, code system MVX should be used to code this field.

RXA-18 Substance/Treatment Refusal Reason (CE) 01136

Definition: This field contains the reason the patient refused the medical substance/treatment. Any entry in the field indicates that the patient did not

take the substance. If this field is populated RXA-20, Completion Status shall be populated with RE.

RXA-20 Completion Status (ID) 01223

This field indicates if the dose was successfully given. It must be populated with RE if RXA-18.

RXA-21 Action Code – RXA (ID) 01224

This field indicates the action expected by the sending system. It can facilitate update or deletion of immunization records.

If this field is empty, no action is indicated.

ORC-3, Placer order number, may be used to link to a specific immunization if the system receiving the request has recorded this from the initial order.

Local implementers should specify its’ use in a local implementation guide. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 121 
Chapter 5: Segments and Message Details

The action code U (Update) is used to indicate to a subordinate receiver that a previously sent immunization should be changed. Most IIS have specific

criteria for determining whether to add or update an immunization that does not rely directly on this field. For this reason it is common practice to indicate

action as Add even if this vaccination has been previously reported. It is important to not assume that Updates will be or need to be specifically indicated.

RXR– Pharmacy/Treatment Route Segment

The Pharmacy/Treatment Route segment contains the alternative combination of route, site, administration device, and administration method that are

prescribed as they apply to a particular order.

Table 5-12 Pharmacy/Treatment Route (RXR)

Table 5-13 Pharmacy/Treatment Route (RXR)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional

Predicate

Value

Set

Constraint

1 Route CE R [1..1]   NCIT

2 Administration

Site

CWE RE [0..1]   HL70163

3 Administration

Device

CE O

4 Administration

Method

CWE O

5 Routing

Instruction

CE O

6 Administration

Site Modifier

CWE O      
RXR field definitions

RXR-1 Route (CE) 00309

Definition: This field is the route of administration. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 122 
Chapter 5: Segments and Message Details

RXR-2 Administration Site (CWE) 00310

Definition: This field contains the site of the administration route. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 123 
Chapter 6: Messages for Transmitting Immunization Information

6. Profile Z23 Return an Acknowledgement

Introduction:

Profile Z23 – Return Acknowledgement is a constrainable profile based on the ACK message.

The goal of this interaction is to acknowledge receipt and processing of a partner message (VXU or QBP). The Sending System may be an Electronic Health

Record system (EHRs), an Immunization Information System (IIS) or another type of health information system.

See Use Case 1—Send Immunization History.

Interaction Definition:

This sequence diagram illustrates the message flow. The sender sends an immunization record in a VXU message. The trigger may be an update or new record in

the sending system records or may be triggered by some other event.  The receiver accepts the message and processes it. The receiver sends an acknowledgment

message in an ACK message.  The transactions that are of interest are indicated by bold arrows.

It is important to note that the message may pass through intermediaries, such as a Health Information Exchange (HIE). The message comes from the initiating

sender and the acknowledgement MUST be returned to the initiating system. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 124 
Chapter 6: Messages for Transmitting Immunization Information 
Figure 38  Send Immunization History Sequence Diagram 
Dynamic Definition:

The following diagram illustrates the expected flow of events. Some event triggers the sending system to create and send a VXU. The receiving system accepts

the VXU. If the message is of an unsupported message type, has an unsupported event code, has an unsupported processing ID or in unable to be processed for

reasons unrelated to format or content, then the acknowledgement code is set to “AR”. The receiving system returns an ACK with the acknowledgement code of

“AR”. Otherwise, the receiving system continues to process the message. It parses the message and processes according to the specifications of this profile and

applies local business rules. If there are no errors, the acknowledgment code is set to “AA”. If there are errors, the acknowledgement code is set to “AE”. If the

errors are fatal (See Processing Rules for Receiving Systems above), then the message is rejected, otherwise the data are integrated into the receiving system. The

acknowledgement code is returned to the sending system in an ACK message. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 125 
Chapter 6: Messages for Transmitting Immunization Information 
Figure 39 Activity Diagram-Return Acknowledgement 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 126 
Chapter 6: Messages for Transmitting Immunization Information

Static Definition- Message Level

The ACK returns an acknowledgement to the sending system. This may indicate errors in processing.

Table 6-1 Message Acknowledgement Segment (ACK)

Table 6-1 Message Acknowledgement Segment (ACK)

Segment Cardinality Usage Comment

MSH

(1..1) R 
[{SFT}]

(0..1) O

Not anticipated for use in immunization messages.

MSA

(1..1) R 
[{ERR}]

(0..*) RE Include if there are errors. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 127 
Chapter 6: Messages for Transmitting Immunization Information

Static Definition—Segment Level:

ERR—Error Segment

Table 6-2 Error Segment (ERR)

Table 6-2 Error Segment (ERR)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional Predicate Value

Set

Description/Comment

1 Error Code

and Location

 ELD X Not supported for Version 2.5

and above.

2 Error Location ERL RE [0..1]29 18

3 HL7 Error

Code

CWE R [0..1] HL70357

4 Severity ID R [1..1] 1..1 HL70516

5 Application

Error Code

CWE RE HL70533

6 Application

Error

Parameter

ST O

7 Diagnostic

Information

TX O

8 User Message TX RE This is a locally specified

informative text message about

the error.

9 Inform Person

Indicator

IS O

10 Override Type CWE O

29 This Guide does not support repeat of this field. It assumes that each error will be contained in one ERR segment. If the same error occurs more than once, there will be one ERR for each.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 128

[0..1]

[0..1] 
Chapter 6: Messages for Transmitting Immunization Information

Table 6-2 Error Segment (ERR)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional Predicate Value

Set

Description/Comment

11 Override

Reason Code

CWE O

12 Help Desk

Contact Point

XTN O      
Note: If an error involves the entire message (e.g. the message is not parse-able.) then location has no meaning. In this case, ERR-2 is left empty.

ERR field definitions:

Note that ERR-1 is not supported for use in messages starting with version 2.5.

ERR-2 Error Location (ERL) 01812

Definition: Identifies the location in a message related to the identified error, warning or message. Each error will have an ERR, so no

repeats are allowed on this field. This field may be left empty if location is not meaningful. For example, if it is unable to be parsed, an

ERR to that effect may be returned.

ERR-3 HL7 Error Code (CWE) 01813

Definition: Identifies the HL7 (communications) error code. Refer to HL7 Table 0357 – Message Error Condition Codes for valid values.

ERR-4 Severity (ID) 01814

Definition: Identifies the severity of an application error. Knowing if something is Error, Warning or Information is intrinsic to how an

application handles the content. Refer to HL7 Table 0516 – Error severity for valid values. If ERR-3 has a value of “0”, ERR-4 will have a

value of “I”. The Severity code indicates if the system sending the ACK or RSP (with error) is reporting an error that caused significant

error loss.  For instance the message was rejected or an important segment was rejected (e.g. RXA). This allows the system that initiated

the message (VXU or QBP) to alert the user that there were issues with the data sent.

Note that the definitions of these codes has been clarified and corrected. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 129 
Chapter 6: Messages for Transmitting Immunization Information

ERR-5 Application Error Code (CWE) 01815

Definition: Application specific code identifying the specific error that occurred. Refer to User-Defined Table 0533 – Application Error Code

for appropriate values.

Note, this field is CWE data type. It includes 2 triplets for coded values. One triplet is reserved for Table 0533 values.  The other may optionally contain

more granular, but equivalent, local codes.

ERR-8 User Message (TX) 01817

Definition: The text message to be displayed to the application user.

Example with error in PID:

ERR||PID^1^3|101^Required field missing^HL70357^^^|E||||Patient Id is required, Message rejected 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 130 
Chapter 6: Messages for Transmitting Immunization Information

MSA—Message Acknowledgement Segment

Table 6-3 Message Acknowledgement Segment (MSA)

Table 6-3 Message Acknowledgement Segment (MSA)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional Predicate Value

Set

Description/Comment

1 Acknowledgment

Code

ID R [1..1] 2..2  HL70008

2 Message Control

ID

ST R [1..1] 1..199

3 Text Message ST X

4 Expected

Sequence

Number

NM O

5 Delayed

Acknowledgment

Type

 O

6 Error Condition CE X

MSA field definitions

MSA-1 Acknowledgment Code (ID) 00018

Definition: This field contains an acknowledgment code, see message processing rules. Refer to HL7 Table 0008 – Acknowledgment code for valid

values.

MSA-2 Message Control ID (ST) 00010

Definition: This field contains the message control ID of the message sent by the sending system. It allows the sending system to associate this response

with the message for which it is intended. This field echoes the message control id sent in MSH-10 by the initiating system.

MSH—Message Header Segment

This implementation guide pre-adopts the Version 2.7.1 MSH segment. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 131 
Chapter 6: Messages for Transmitting Immunization Information

Table 6-4 Message Header Segment (MSH)

Table 6-4 Message Header Segment (MSH)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional

Predicate

Value set Description/Comment

1 Field Separator ST R [1..1] 1..1

2 Encoding Characters ST R [1..1] 4..4

3 Sending Application HD RE [0..1] HL70361

4 Sending Facility HD RE [0..1] HL70362

5 Receiving

Application

HD RE [0..1] HL70361

6 Receiving Facility HD RE [0..1] HL70362

7 Date/Time Of

Message

TS_Z R [1..1]

8 Security ST O

9 Message Type MSG R [1..1]

10 Message Control ID ST R [1..1] 1..199

11 Processing ID PT R [1..1]

12 Version ID VID R [1..1]

13 Sequence Number NM O

14 Continuation Pointer ST O [0..1]

15 Accept

Acknowledgement

Type

ID R [1..1] HL70155 Default value is  NE (Never)

16 Application

Acknowledgment

Type

ID O [1..1] HL70155

(constrained)

17 Country Code ID O

18 Character Set ID O

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 132 
Chapter 6: Messages for Transmitting Immunization Information

Table 6-4 Message Header Segment (MSH)

SEQ ELEMENT

NAME

Data

Type

Usage Cardinality LEN Conditional

Predicate

Value set Description/Comment

19 Principal Language

Of Message

CE O

20 Alternate Character

Set Handling

Scheme

ID O

21 Message Profile

Identifier

EI  R [1..*]

22 Sending

Responsible

Organization

XON RE [0..1]    The initiator of this message.

23 Receiving

Responsible

Organization

XON RE [0..1]    The final recipient of this

message.

24 Sending Network

Address

HD O

25 Receiving Network

Address

HD O      
MSH Conformance Statements:

IZ-12: The MSH.1 (Field Separator) SHALL be valued “|”

IZ-13: The MSH.2 (Encoding Characters) SHALL be valued “^~\& “

IZ-15: The MSH-12 (Version ID) SHALL be valued “2.5.1 “

IZ-51: MSH-9 (Message Type) SHALL contain the constant value “ACK^VO4^ACK”

IZ-52: The value of MSH-16 (Application Acknowledgement) shall be “NE”. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 133 
Chapter 6: Messages for Transmitting Immunization Information

IZ-53: The value of MSH-15(Accept Acknowledgement) shall be “NE”

IZ-54: MSH-21(Profile Identifier ID) SHALL contain the constant value “Z23^CDCPHINVS”

MSH field definitions

See field definitions for MSH under Profile Z22 above.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 134 
Chapter 6: Messages for Transmitting Immunization Information

7.Profile Z34 – Request a Complete Immunization History

Introduction:

Profile Z34 – Request Complete Immunization History is a constrainable profile that supports request of an immunization history of an individual. It has a set

partner profiles which return the requested history, a list of candidate patients or an acknowledgement that no matches were found.

The goal of this query is to request a complete immunization history. This will support transferring a person’s immunization records from one information system

to another. The response will be very similar to a VXU message in content.

See Use Case 2—Request Immunization History above for Use Case details.

A complete immunization history consists of:

• demographic information about the patient,

• a list of the immunizations received,

• a list of any patient conditions that impact immunization (i.e. allergies, contraindications, history of vaccine preventable disease) 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 135 
Chapter 6: Messages for Transmitting Immunization Information

Table 7-1 Request Complete Immunization History Query Profile

Table 7-1 Request Complete Immunization History Query Profile

Query Statement ID (Query

ID=Z34):

Z34

Type: Query

Query Name: Request Immunization History

Query Trigger (= MSH-9): QBP^Q11^QBP_Q11

Query Mode: Both

Response Trigger (= MSH-9): RSP^K11^RSP_K11

Query Characteristics: The query parameters may include demographic and address data. No sorting is expected. 
This profile does not specify the logic used when searching for matching clients/patients.

The query parameter contents may be used for simple query or as input for probabilistic

search algorithms. The search methodology should be specified by local implementations.

Purpose: The purpose is to request a complete immunization history for one client.

Response Characteristics: • In the case where no candidates are found, the acknowledgement response will

indicate that no candidates were found.

• In the case where exactly one high-confidence candidate is found, an immunization

history may be returned.

• In the case where one or more clients could match the criteria sent, a list of

candidates may be returned to allow for refinement of the query. If the number of

candidates exceeds the maximum number requested or allowed for return, the

acknowledgement response will indicate too many matches and no records will be

returned.

• In the case where one high confidence candidate is found, but that candidate does

not allow sharing of data, the acknowledgement response will indicate no

candidates were found.

• In the case where receiving system can’t process the query, the receiving system

will indicate an error in an acknowledgement. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 136 
Chapter 6: Messages for Transmitting Immunization Information

Table 7-1 Request Complete Immunization History Query Profile

Query Statement ID (Query

ID=Z34):

Z34

Based on Segment Pattern: NA

Interaction Definition:

The following sequence diagram shows the message flows involved in this transaction. The sending system creates a query and sends it.  The responding system

sends a response. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 137 
Chapter 6: Messages for Transmitting Immunization Information 
Figure 40 Sequence Diagram-Return Complete Immunization History

Dynamic Definition:

The following activity diagram shows the flow of activities associated with this profile and its partners. This is described in the table below the diagram. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 138 
Chapter 6: Messages for Transmitting Immunization Information 
Figure 41 Request Complete History and Responses Activity Diagram 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 139 
Chapter 6: Messages for Transmitting Immunization Information

Table 7-2 Response to Different Outcomes

TTAABBLLEE  77–22  RREESSPPOONNSSEE  TTOO  DDIIFFFFEERREENNTT  OOUUTTCCOOMMEESS

Outcome of Query Response Message

No match found Response indicates that message was successfully processed and that no clients matched the

criteria that were sent in the query. See Acknowledgement Profile (Z33).

Exactly one high confidence match found 30 Response includes a complete immunization history as specified below.  
See Profile Return Immunization History (Z32).

At least one lower confidence match31 is found, but

<= maximum number allowed. 
If state law allows, the Response returns one PID with associated PD1 and NK1 segments for 
each potential match. No immunization history is returned. 
 
See Profile Return Candidate List (Z31). 
More than the maximum number allowed is found. Response indicates that the message was successfully processed, but that too many potential 
matches were found. See Return Acknowledgement Profile (Z33) 
 
The maximum number allowed is the lower of the maximum number requested and the 
maximum number that the receiving system will return. 
Message is not well formed and has fatal errors. Response indicates that the message was not successfully processed and may indicate errors. 
See Return Acknowledgement Profile (Z33). 
Message was rejected because one of the following 
occurred: 
• Unsupported message type 
Return ACK message with errors. 
30 Definition of match is left to local business rules. These rules should be documented in a local implementation guide. For example, a system may only return an immunization history when the match 
is exact, returning a list of 1 if one person for a lower probability match. 
31 More than one high confidence match is considered a set of lower confidence matches. 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 140 
 
                                                           


Chapter 6: Messages for Transmitting Immunization Information 
TTAABBLLEE  77--22  RREESSPPOONNSSEE  TTOO  DDIIFFFFEERREENNTT  OOUUTTCCOOMMEESS  
Outcome of Query Response Message 
• Unsupported event code 
• Unsupported processing ID 
• Unable to process for reasons unrelated for 
format or content 
Message can’t be identified as an HL7 message. No HL7 message is returned. 
 
Static Definition - Message Level: 
Table 7-3 Z34 Request Complete Immunization History 
TABLE 7-3 Z34 REQUEST COMPLETE IMMUNIZATION HISTORY 
 
QBP^Q11^QBP_Q11 
Query Grammar: QBP 
Message  
Usage Comment 
MSH Message Header Segment R  
[{SFT}] Software Segment O Local profile may 
specify 
QPD Query Parameter Definition R  
RCP Response Control Parameter R  
[ DSC ] Continuation Pointer X Not supported 
 
 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 141 
 


Chapter 6: Messages for Transmitting Immunization Information 
Static Definition – Segment Level: 
MSH - Message Header Specification 
Table 7-4 MSH Specification for Request Complete Immunization History Query 
Table 7-4 MSH Specification for Request Complete Immunization History Query 
SEQ LEN Data 
Type 
Cardinalit
y 
Value 
set 
ELEMENT NAME Usage Constraint 
1 1 ST [1..1] Field Separator R The MSH.1 field shall be | 
2 4 ST [1..1] Encoding Characters R The MSH.2 field shall be ^~\& 
3 HD [0..1] 0361 Sending Application RE No constraint 
4 HD [0..1] 0362 Sending Facility RE No constraint 
5 HD [0..1] 0361 Receiving Application RE No constraint 
6 HD [0..1] 0362 Receiving Facility RE No constraint 
7 26 TS_Z [1..1] Date/Time Of Message R The degree of precision must be 
at least to the second, (format 
YYYYMMDDHHMMSS+/-ZZZZ). 
8 40 ST [0..1] Security O 
9 15 MSG [1..1] Message Type R QBP^Q11^QBP_Q11 
10 199 ST [1..1] Message Control ID R 
11 3 PT [1..1] Processing ID R 
12 VID [1..1] Version ID R 2.5.1 
13 15 NM [0..1] Sequence Number O 
14 180 ST [0..1] Continuation Pointer O 
15 2 ID [0..1] 0155 Accept Acknowledgment 
Type 
R ER-Error 
16 2 ID [0..1] 0155 Application 
Acknowledgment Type 
R AL-Always 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 142 


Chapter 6: Messages for Transmitting Immunization Information 
Table 7-4 MSH Specification for Request Complete Immunization History Query 
SEQ LEN Data 
Type 
Cardinalit
y 
Value 
set 
ELEMENT NAME Usage Constraint 
17 3 ID [0..1] 0399 Country Code X blank 
18 16 ID [0..1] 0211 Character Set X blank 
19 CE [0..1] Principal Language Of 
Message 
X blank 
20 20 ID [0..1] 0356 Alternate Character Set 
Handling Scheme 
X blank 
21 EI [1..*] Message Profile Identifier R Z34^CDCPHINVS 
22 XON [0..1] 0362 Sending Responsible 
Organization 
RE 
23 XON 0362 Receiving Responsible 
Organization 
RE 
Conformance Statement:  
IZ-12: The MSH.1 (Field Separator)  SHALL be valued “|”  
IZ-13: The MSH.2 (Encoding Characters)  SHALL be valued “^~\& “ 
IZ-15: The MSH-12 (Version ID) SHALL be valued “2.5.1 “ 
IZ-55: MSH-9 (Message Type)  SHALL contain the constant value “QBP^Q11^QBP_Q11” 
IZ-56: One occurrence of MSH-21 (Message Profile Identifier) SHALL contain the constant value “Z34^CDCPHINVS” 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 143 
[0..1]


Chapter 6: Messages for Transmitting Immunization Information 
IZ-57: MSH-15 (Accept Acknowledgement) SHALL have a value of “ER”. 
IZ-58: MSH-16 (Application Acknowledgement) SHALL have a value of “AL” 
MSH field definitions 
See field definitions for MSH under Profile Z22 above.
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 144 
 


Chapter 6: Messages for Transmitting Immunization Information 
QPD Input Parameter Specification 
Table 7-5 QPD Input Parameter Specification 
Table 7-5 QPD Input Parameter Specification 
Field 
Seq 
(Query 
ID=Z34) 
Name Key/ 
Search 
Sort LEN TYPE Usage Rep Match 
Op 
TBL Segment 
Field 
Name 
Service 
Identif
ier 
Code 
Element 
Name or 
Value 
1 MessageQue
ryName 
   CE R      Z34^Request 
Complete 
Immunization 
History^CDCP
HINVS 
2 QueryTag   32 ST R       
3 PatientList    CX RE Y   PID.3  PID-3: Patient  
Identifier List 
4 PatientName    XPN RE    PID.5  PID-5: Patient 
Name 
5 PatientMothe
rMaidenNam
e 
   XPN_M RE    PID.6  PID-6: Mother’s 
maiden name 
6 Patient Date 
of Birth 
  26 TS_NZ RE    PID.7  PID-7: Patient 
date of birth 
7 Patient Sex   1 IS RE    PID.8  PID-8: Patient 
sex 
8 Patient 
Address 
   XAD RE    PID.11  PID-11: Patient 
Address 
9 Patient home 
phone 
   XTN RE    PID.13  PID-13: Patient 
home phone 
10 Patient   1 ID RE    PID-24  PID-24: Patient 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 145 
 


Chapter 6: Messages for Transmitting Immunization Information 
Table 7-5 QPD Input Parameter Specification 
Field 
Seq 
(Query 
ID=Z34) 
Name Key/ 
Search 
Sort LEN TYPE Usage Rep Match 
Op 
TBL Segment 
Field 
Name 
Service 
Identif
ier 
Code 
Element 
Name or 
Value 
multiple birth 
indicator 
multiple birth 
indicator 
11  Patient birth 
order 
  2 NM RE    PID-25  PID-25: Patient 
birth order 
12 Client last 
updated date 
   TS RE    PID-33  PID-33: Patient 
last update 
date 
13 Client last 
update 
facility 
   HD RE    PID-34  PID-34: Patient 
last update 
faciliity 
 
QPD Input Parameter Field Description and Commentary 
 
Table 7-6 QPD Input Parameter Field Description and Commentary 
Table 7-6 QPD Input Parameter Field Description and Commentary 
Input Parameter (Query 
ID=Z34) 
Comp. Name Data Type Usage Description 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 146 
 


Chapter 6: Messages for Transmitting Immunization Information 
Table 7-6 QPD Input Parameter Field Description and Commentary 
Input Parameter (Query 
ID=Z34) 
Comp. Name Data Type Usage Description 
MessageQueryName  CE R Z34^Request Immunization 
History^HL70471 
QueryTag  ST R Unique to each query message 
instance. 
PatientList  CX RE The combination of values for 
Patientlist.ID, 
patientlst.identifiercode and 
Patientlist.AssigningAuthority are 
intended to allow unique 
identification of a client, if the data 
are found in the responding 
system. 
 ID ST R If this field, PID.3.1, is not valued, 
PatientList is not considered when 
seeking matching clients. 
 Assigning Authority HD R If this field, PID.3.4, is not valued, 
PatientList is not considered when 
seeking matching clients. 
 IdentifierTypeCode IS R If this field, PID.3.5, is not valued, 
PatientList is not considered when 
seeking matching clients. 
PatientName  XPN R If this field, PID.5, is not valued, 
then the query will return an error, 
since this is a required field. 
 Family Name FN R If this field, PID.5.1, is not valued, 
then patient name is considered to 
contain no value.  
 Given Name ST R If this field, PID.5.2, is not valued, 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 147 
 


Chapter 6: Messages for Transmitting Immunization Information 
Table 7-6 QPD Input Parameter Field Description and Commentary 
Input Parameter (Query 
ID=Z34) 
Comp. Name Data Type Usage Description 
then patient name is considered to 
contain no value. Given name is 
required.  
 Second or further names ST RE If this field, PID.5.3, is not valued, 
then all values for this field are 
considered a match. 
 Suffix ST RE If this field, PID.5.4, is not valued, 
then all values for this field are 
considered a match. 
Mother’s Maiden Name  XPN_M RE If this field, PID.6, is not valued, 
Mother’s maiden name is not 
considered when seeking 
matching clients. 
 Family Name FN R If this field, PID.6.1, is not valued, 
then mother’s maiden name is 
considered to contain no value.  
 Given Name ST RE If this field, PID.6.2, is not valued, 
then all values for this field are 
considered a match. 
 Name Type Code ID RE If the field, PID-6.7, is not valued, 
then all values for this field are 
considered a match. 
DateOfBirth  TS_NZ R If this field, PID.7, is not valued to 
an accuracy of at least day, then 
this field is considered not valued.  
Sex  IS RE If this field, PID.8, is not valued, 
then all values for this field are 
considered a match. 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 148 
 


Chapter 6: Messages for Transmitting Immunization Information 
Table 7-6 QPD Input Parameter Field Description and Commentary 
Input Parameter (Query 
ID=Z34) 
Comp. Name Data Type Usage Description 
Address  XAD RE If this field, PID.11, is not valued, 
then address will not be 
considered when seeking 
matching clients. 
 Street Address SAD RE If this field, PID.11.1, is not valued, 
then all values for this field are 
considered a match. 
 City ST RE If this field, PID.11.3, is not valued, 
then address is considered to 
contain no value.  
 State ST RE If this field, PID.11.4, is not valued, 
then address is considered to 
contain no value.  
 ZIP ST RE If this field, PID.11.5, is not valued, 
then all values for this field are 
considered a match. 
 Address Type IS RE If this field, PID.11.7 is not valued, 
then it shall default to L, legal 
address. 
Phone  XTN RE This field will be considered the 
Home phone. If this field, PID.13, 
is not valued, then phone number 
is not considered when seeking 
matching clients. 
 Area code NM  If this field, PID.13.6, is not valued, 
then all values for this field shall 
be considered matches. 
 Local number NM  If this field, PID.13.7, is not valued, 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 149 
 


Chapter 6: Messages for Transmitting Immunization Information 
Table 7-6 QPD Input Parameter Field Description and Commentary 
Input Parameter (Query 
ID=Z34) 
Comp. Name Data Type Usage Description 
then address is considered to 
contain no value. 
Multiple Birth Indicator  ID RE If this field, PID.24, is not valued, 
then Multiple Birth Indicator is not 
considered when seeking 
matching clients.  
Birth Order  NM RE If this field, PID.25, is not valued, 
then birth order is not considered 
when seeking matching clients. 
Client last updated date  TS O If this field, PID.33, is not valued, 
then client last updated date is not 
considered when seeking 
matching clients.  
Client last update facility  TS O If this field, PID.34, is not valued, 
then client last updating facility is 
not considered when seeking 
matching clients. 
 
 
This Guide does not specify the methodology a system uses for searching. It specifies the structure and content of the message used to query. It is incumbent on 
systems to publically document their expectations within the constraints of this guide.  
RCP – Response Control Parameter Segment  
The RCP segment is used to restrict the amount of data that should be returned in response to query. It lists the segments to be returned. 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 150 
 


Chapter 6: Messages for Transmitting Immunization Information 
Table 7-7 Response Control Parameter 
Table 7-7 Response Control Parameter 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
set 
Comments 
1 Query Priority ID RE [0..1]   HL70091  
2 Quantity 
Limited 
Request 
CQ RE [0..1]   HL70126 This field may contain a 
maximum number of records 
that may be returned. The first 
component contains the count 
and the second contains “RD” 
for records. 
3 Response 
Modality 
CE O      
4 Execution and 
Delivery Time 
TS O      
5 Modify 
Indicator 
ID O      
6 Sort-by Field SRT O      
7 Segment 
group 
inclusion  
ID O      
Conformance Statement: 
IZ-27: Constrain RCP-1 (Query Priority) to empty or “I”. Immediate priority is expected. 
RCP field definitions 
RCP-1 Query Priority (ID) 00027  
Definition: This field contains the time frame in which the response is expected. Refer to HL7 Table 0091 - Query priority for valid values. Table values 
and subsequent fields specify time frames for response. Only “I” ( for immediate shall) be used for this field. 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 151 
 


Chapter 6: Messages for Transmitting Immunization Information 
RCP-2 Quantity Limited Request (CQ) 00031  
Definition: This field contains the maximum length of the response that can be accepted by the requesting system. Valid entries are numerical values (in 
the first component) given in the units specified in the second component. Default is LI (lines). The expected type is records, so the second component is 
constrained to RD. 
Note that this field is the maximum total records to return. The Version 2.5.1 standard indicates the maximum number to return in each batch. No batching 
of responses is permitted in this Guide. 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 152 
 


Chapter 6: Messages for Transmitting Immunization Information 
8.Profile Z32 Response Profile – Return Complete Immunization 
History  
Introduction: 
Profile Z32 – Return Complete Immunization History is a constrainable profile that supports return of an immunization history of an individual. It is a response 
to the Z34-Request Immunization History query. 
The goal of this response is to return a complete immunization history in response to a request for a person’s record. This will support transferring a person’s 
immunization records from one information system to another. The response will be very similar to a VXU message in content. 
Interaction Definition 
See Interaction Definition In previous chapter. 
Dynamic Definition 
See Activity Diagram in previous chapter. 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 153 
 


Chapter 6: Messages for Transmitting Immunization Information 
Static Definition – Message Level  
Table 8-1 Return Complete Immunization History Response GrammarSP^K11 
Table 8-1 Return Complete Immunization History Response Grammar RSP^K11 
Segment Cardinality Usage Comment 
MSH [1..1] R  
MSA [1..1] R  
[ERR] [0..1] RE If errors exist, then this segment is populated. 
QAK [1..1] R  
QPD [1..1] R Query Parameter Definition Segment32 
PID 
[1..1] R 
 
[PD1  ] 
[0..1] RE 
 
[{NK1 }] 
[0..*] RE 
 
[PV1] 
[0..1] O 
 
[IN1] 
[0..1] O 
 
 [{ 
[0..*] RE Begin Order 
ORC 
[1..1] R Required if client has immunization records 
(RXA). There is one ORC for each RXA 
RXA 
[1..1] R 
 
32 Matches the information in the requesting QBP message. 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 154 
 
                                                           


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-1 Return Complete Immunization History Response Grammar RSP^K11 
Segment Cardinality Usage Comment 
[RXR  ] 
[0..1] RE 
 
[{ 
[0..*] RE Begin Observation 
OBX 
[1..1] R 
 
[NTE ] 
[0..1] RE 
 
}]   
End observation 
}]   
End Order 
 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 155 
 


Chapter 6: Messages for Transmitting Immunization Information 
Static Definition -- Segment Level 
ERR—Error Segment 
Table 8-2 Error Segment (ERR) 
Table 8-2 Error Segment (ERR) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Description/Comment 
1 Error Code 
and Location 
 ELD X Not supported for Version 2.5 
and above. 
2 Error Location ERL RE [0..1]33 18 
3 HL7 Error 
Code 
CWE R [1..1] HL70357 
4 Severity ID R [1..1] 1..1 HL70516 
5 Application 
Error Code 
CWE RE HL70533 
6 Application 
Error 
Parameter 
ST O 
7 Diagnostic 
Information 
TX O 
8 User Message TX RE This is a locally specified 
informative text message about 
the error. 
9 Inform Person 
Indicator 
IS O 
10 Override Type CWE O 
33 This Guide does not support repeat of this field. It assumes that each error will be contained in one ERR segment. If the same error occurs more than once, there will be one ERR for each. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 156 
[0..1]
[0..1]


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-2 Error Segment (ERR) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Description/Comment 
11 Override 
Reason Code 
CWE O      
12 Help Desk 
Contact Point 
XTN O      
Note: If an error involves the entire message (e.g. the message is not parse-able.) then location has no meaning. In this case, ERR-2 is left empty. 
ERR field definitions: 
See field definitions for ERR under Profile Z23 above.
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 157 
 


Chapter 6: Messages for Transmitting Immunization Information 
IN1—Insurance Segment  
Local implementations may document use for local purposes in local implementation Guide. Field level specifications follow. They have 
been constrained, based on current usage. Local implementations that require IN1 should base requirements on this guide. Specifications 
for IN1 are included because several IIS require this segment and this specification is intended to assure that implementations are 
consistent across systems. 
Note that only the current insurance data should be sent. Historical insurance information should not be sent. 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 158 
 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-3 Insurance Segment (IN1) 
Table 8-3 Insurance Segment (IN1) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Description/Comment 
1 Set ID - IN1 SI R [1..1] 4    
2 Insurance Plan ID CE R [1..1] 250  HL70072  
3 Insurance 
Company ID 
CX R  250    
4 Insurance 
Company Name 
XON O  250    
5 Insurance 
Company 
Address 
XAD O  250    
6 Insurance Co 
Contact Person 
XPN O  250    
7 Insurance Co 
Phone Number 
XTN O  250    
8 Group Number ST O  12    
9 Group Name XON O  250    
10 Insured’s Group 
Emp ID 
CX O  250    
11 Insured’s Group 
Emp Name 
XON O  250    
12 Plan Effective 
Date 
DT O  8    
13 Plan Expiration 
Date 
DT O  8    
14 Authorization 
Information 
AUI O  239    
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 159 
 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-3 Insurance Segment (IN1) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Description/Comment 
15 Plan Type IS R  3  HL70086  
16 Name Of Insured XPN O  250    
17 Insured’s 
Relationship To 
Patient 
CE O  250  HL70063  
18 Insured’s Date Of 
Birth 
TS O  26    
19 Insured’s Address XAD O  250    
20 Assignment Of 
Benefits 
IS O  2  HL70135  
21 Coordination Of 
Benefits 
IS O  2  HL70173  
22 Coord Of Ben. 
Priority 
ST O  2    
23 Notice Of 
Admission Flag 
ID O  1  HL70136  
24 Notice Of 
Admission Date 
DT O  8    
25 Report Of 
Eligibility Flag 
ID O  1  HL70136  
26 Report Of 
Eligibility Date 
DT O  8    
27 Release 
Information Code 
IS O  2  HL70093  
28 Pre-Admit Cert 
(PAC) 
ST O  15    
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 160 
 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-3 Insurance Segment (IN1) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Description/Comment 
29 Verification 
Date/Time 
TS_NZ RE  26   Precision shall be at least to the 
day. [YYYYMMDD] 
30 Verification By XCN O  250    
31 Type Of 
Agreement Code 
IS O  2  HL70098  
32 Billing Status IS O  2  HL70022  
33 Lifetime Reserve 
Days 
NM O  4    
34 Delay Before L.R. 
Day 
NM O  4    
35 Company Plan 
Code 
IS O  8  HL70042  
36 Policy Number ST O  15    
37 Policy Deductible CP  O  12    
38 Policy Limit - 
Amount 
CP  X  12    
39 Policy Limit - 
Days 
NM O  4    
40 Room Rate - 
Semi-Private 
CP X  12    
41 Room Rate - 
Private 
CP X  12    
42 Insured’s 
Employment 
Status 
CE O  250  HL70066  
43 Insured’s 
Administrative 
IS O  1  HL70001  
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 161 
 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-3 Insurance Segment (IN1) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Description/Comment 
Sex 
44 Insured’s 
Employer’s 
Address 
XAD O  250    
45 Verification Status ST O  2    
46 Prior Insurance 
Plan ID 
IS O  8  HL70072  
47 Coverage Type IS O  3  HL70309  
48 Handicap  IS O  2  HL70295  
49 Insured’s ID 
Number 
CX O  250    
50 Signature Code IS O  1  HL70535  
51 Signature Code 
Date 
DT O  8    
52 Insured’s Birth 
Place 
ST O  250    
53 VIP Indicator IS O  2  HL70099  
 
IN1 Field Definitions 
See Field Definitions in Z22 Profile. 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 162 
 


Chapter 6: Messages for Transmitting Immunization Information 
MSA—Message Acknowledgement Segment 
Table 8-4 Message Acknowledgement Segment (MSA) 
Table 8-4 Message Acknowledgement Segment (MSA) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Description/Comment 
1 Acknowledgment 
Code 
ID R [1..1] 2..2  HL70008  
2 Message Control 
ID 
ST R [1..1] 1..199    
3 Text Message ST X      
4 Expected 
Sequence 
Number 
NM O      
5 Delayed 
Acknowledgment 
Type 
 O      
6 Error Condition CE X      
MSA field definitions 
See field definitions for MSA under Profile Z23 above. 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 163 
 


Chapter 6: Messages for Transmitting Immunization Information 
MSH - Message Header Specification 
Table 7-9 MSH Sp8-5 S for Request Complete Immunization History Query 
Table 8-5 MSH Specification for Return Complete Immunization History Response 
SEQ LEN Data 
Type 
Cardinality Value 
set 
ELEMENT NAME Usage Constraint 
1 1 ST [1..1] Field Separator R The MSH.1 field shall be | 
2 4 ST [1..1] Encoding Characters R The MSH.2 field shall be ^~\& 
3 HD [0..1] 0361 Sending Application RE No constraint 
4 HD [0..1] 0362 Sending Facility RE No constraint 
5 HD [0..1] 0361 Receiving Application RE No constraint 
6 HD [0..1] 0362 Receiving Facility RE No constraint 
7 26 TS_Z [1..1] Date/Time Of Message R The degree of precision must be 
at least to the second, (format 
YYYYMMDDHHMMSS+/-ZZZZ.  
8 40 ST [0..1] Security O 
9 15 MSG [1..1] Message Type R RSP^K11^RSP_K11 
10 199 ST [1..1] Message Control ID R 
11 3 PT [1..1] Processing ID R 
12 VID [1..1] Version ID R 2.5.1 
13 15 NM [0..1] Sequence Number O 
14 180 ST [0..1] Continuation Pointer O 
15 2 ID [0..1] 0155 Accept Acknowledgment 
Type 
R ER 
16 2 ID [0..1] 0155 Application 
Acknowledgment Type 
R AL 
17 3 ID [0..1] 0399 Country Code X blank 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 164 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-5 MSH Specification for Return Complete Immunization History Response 
SEQ LEN Data 
Type 
Cardinality Value 
set 
ELEMENT NAME Usage Constraint 
18 16 ID [0..1] 0211 Character Set X blank 
19 CE [0..1] Principal Language Of 
Message 
X blank 
20 20 ID [0..1] 0356 Alternate Character Set 
Handling Scheme 
X blank 
21 EI [1..*] Message Profile Identifier R Z32^CDCPHINVS 
22 XON [0..1] 0362 Sending Responsible 
Organization 
RE 
23 XON 0362 Receiving Responsible 
Organization 
RE 
Conformance Statement: 
IZ-12: The MSH.1 (Field Separator) SHALL be valued “|”  
IZ-13: The MSH.2 (Encoding Characters) SHALL be valued “^~\& “ 
IZ-15: The MSH-12 (Version ID) SHALL be valued “2.5.1 “ 
IZ-59: MSH-9 (Message Type) SHALL contain the constant value “RSP^K11^RSP_K11” 
IZ-52: The value of MSH-16 (Application Acknowledgement) SHALL be “NE”. 
IZ-53: The value of MSH-15 (Accept Acknowledgement) SHALL be “NE” 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 165 
[0..1]


Chapter 6: Messages for Transmitting Immunization Information 
IZ-60:  One occurrence of MSH-21 (Message Profile Identifier) SHALL contain the constant value “Z32^CDCPHINVS” 
 
MSH Field Definitions 
See field definitions for MSH under Profile Z22 above.
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 166 
 


Chapter 6: Messages for Transmitting Immunization Information 
NK1—Next of Kin Segment 
The NK1 segment contains information about the patient’s other related parties. Any associated parties may be identified. Utilizing NK1-1 - set ID, multiple NK1 
segments can be sent to patient accounts. That is, each subsequent NK1 increments the previous set ID by 1. So if 3 NK1 were sent in one message, the first 
would have a set id of 1, the second would have 2 and the third would have 3. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 167 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-6 Next of Kin Segment (NK1) 
Table 8-6 Next of Kin Segment (NK1) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
set 
Description/Comment 
1 Set ID - NK1 SI R [1..1] 
2 Name XPN R [1..*] The first instance is the legal 
name and is required. 
3 Relationship CE R [1..1] HL70063 
4 Address XAD RE [0..*] The first instance shall be the 
primary address. 
5 Phone Number XTN RE [0..*] The first instance shall be the 
primary phone number. 
6 Business Phone 
Number 
XTN O 
7 Contact Role CE O 
8 Start Date DT O 
9 End Date DT O 
10 Next of Kin / 
Associated 
Parties Job Title 
ST O 
11 Next of Kin / 
Associated 
Parties Job 
Code/Class 
JCC O 
12 Next of Kin / 
Associated 
Parties 
Employee 
Number 
CX O 
13 Organization XON O 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 168 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-6 Next of Kin Segment (NK1) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
set 
Description/Comment 
Name - NK1 
14 Marital Status CE O 
15 Administrative 
Sex 
IS O 
16 Date/Time of 
Birth 
TS O 
17 Living 
Dependency 
IS O 
18 Ambulatory 
Status 
IS O 
19 Citizenship CE O 
20 Primary 
Language 
CE O 
21 Living 
Arrangement 
IS O 
22 Publicity Code CE O 
23 Protection 
Indicator 
ID O 
24 Student 
Indicator 
IS O 
25 Religion CE O 
26 Mother’s Maiden 
Name 
XPN O 
27 Nationality CE O 
28 Ethnic Group CE O 
29 Contact Reason CE O 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 169 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-6 Next of Kin Segment (NK1) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
set 
Description/Comment 
30 Contact 
Person’s Name 
XPN O 
31 Contact 
Person’s 
Telephone 
Number 
XTN O 
32 Contact 
Person’s 
Address 
XAD O 
33 Next of 
Kin/Associated 
Party’s 
Identifiers 
CX O 
34 Job Status IS O 
35 Race CE O 
36 Handicap IS O 
37 Contact Person 
Social Security 
Number 
ST O 
38 Next of Kin Birth 
Place 
ST O 
39 VIP Indicator IS O 
NK1 field definitions 
See field definitions for NK1 under Profile Z22 above.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 170 


Chapter 6: Messages for Transmitting Immunization Information 
NTE—Note Segment 
The NTE segment is used for sending notes and comments. 
Table 8-7 Note Segment (NTE) 
Table 8-7 Note Segment (NTE) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Comment 
1 Set ID - NTE SI O 
2 Source of 
Comment 
ID O 
3 Comment FT R [1..1] 
4 Comment Type CE O 
NTE field definitions 
See field definitions for NTE under Profile Z22 above.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 171 


Chapter 6: Messages for Transmitting Immunization Information 
OBX—Observation Result Segment 
The observation result segment has many uses. It carries observations about the object of its parent segment. In the VXU/RSP it is associated with the RXA or 
immunization record. The basic format is a question (OBX-3) and an answer (OBX-5).  
Consult Appendix B for detailed examples of each of the uses. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 172 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-8 Observation Segment (OBX) 
Table 8-8 Observation Segment (OBX) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional 
Predicate 
Value Sets Comment 
1 Set ID – OBX SI R [1..1] 1..4 
2 Value Type ID R [1..1] 2..3 HL70125 
(constrained) 
3 Observation 
Identifier 
CE R [1..1] 
NIP003 
This indicates what this 
observation refers to. It poses 
the question that is answered by 
OBX-5. 
4 Observation 
Sub-ID 
ST R [1..1] 1..20 Constrain to 
positive 
integers 
5 Observation 
Value 
varies R [1..1] varies OBX-5  is the observation value 
and answers the question posed 
in OBX-3 
6 Units CE C(R/O) [0..1] If OBX-2(Value Type) is 
valued “NM” or “SN”  
Note: If there is not a unit of 
measure available while 
the Condition Predicated is 
true, then the value “NA” 
SHALL be used in CE.1 
and “HL70353” in CE.3. 
UCUM 
7 References 
Range 
ST O 
8 Abnormal 
Flags 
IS O 
9 Probability NM O 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 173 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-8 Observation Segment (OBX) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional 
Predicate 
Value Sets Comment 
10 Nature of 
Abnormal Test 
ID O 
11 Observation 
Result Status 
ID R [1..1] 1 HL70085 
(constrained) 
12 Effective Date 
of Reference 
Range Values 
TS O 
13 User Defined 
Access 
Checks 
ST O 
14 Date/Time of 
the 
Observation 
TS_NZ RE [0..1] 
15 Producer's 
Reference 
CE O 
16 Responsible 
Observer 
XCN O 
17 Observation 
Method 
CE C(RE/O) [0..1] If OBX-3.1 is “64994-7” CDCPHINVS 64994 “-7” is a LOINC meaning 
“funding program eligibility”. This 
field is used to distinguish 
between eligibility that is 
captured at the visit level versus 
at the immunization event level. 
18 Equipment 
Instance 
Identifier 
EI O 
19 Date/Time of 
the Analysis 
TS O 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 174 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-8 Observation Segment (OBX) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional 
Predicate 
Value Sets Comment 
20 Reserved for 
harmonization 
with V2.6 
X 
21 Reserved for 
harmonization 
with V2.6 
X 
22 Reserved for 
harmonization 
with V2.6 
X 
23 Performing 
Organization 
Name 
XON O 
24 Performing 
Organization 
Address 
XAD O 
25 Performing 
Organization 
Medical 
Director 
XCN O 
Conformance Statement:  
IZ-20: The Value of OBX-1 (Set ID-OBX) SHALL be valued sequentially starting with the value “1” within a message. 
IZ-21: The value of OBX-2 (Value Type) SHALL be one of the following: 
CE, NM, ST, DT, ID or TS  
IZ-22: The value of OBX-11 (Observation Result Status) SHALL be “F” 
IZ-35: If OBX-3.1 is “64994-7” and OBX-2 is “CE” then the value set for OBX-5 shall be HL70064. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 175 


Chapter 6: Messages for Transmitting Immunization Information 
IZ-36: If OBX-3.1 is “69764-9” and OBX-2 is “CE” then the value set for OBX-5 shall be cdcgs1vis. 
IZ-37: If OBX-3.1 is “30956-7” and OBX-2 is “CE” then the value set for OBX-5 shall be CVX. 
OBX field definitions 
See field definitions for OBX under Profile Z22 above.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 176 


Chapter 6: Messages for Transmitting Immunization Information 
ORC—Order Request Segment 
The Common Order segment (ORC) is used to transmit fields that are common to all orders (all types of services that are requested). While not all immunizations 
recorded in an immunization message are able to be associated with an order, each RXA must be associated with one ORC, based on HL7 2.5.1 standard.  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 177 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-9 Common Order Segment (ORC) 
Table 8-10 Common Order Segment (ORC) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional 
Predicate 
Value Set Comment 
1 Order Control ID R [1..1] 2 HL70119 
(constrained) 
2 Placer Order 
Number 
EI RE [0..1] See Guidance below. 
3 Filler Order 
Number 
EI R [1..1] See Guidance below. 
4 Placer Group 
Number 
EI O 
5 Order Status ID O 
6 Response Flag ID O 
7 Quantity/Timin
g 
TQ X 
8 Parent EIP O 
9 Date/Time of 
Transaction 
TS O 
10 Entered By XCN RE [0..1] This is the person that entered 
this immunization record into the 
system. 
11 Verified By XCN O 
12 Ordering 
Provider 
XCN C(RE/O) [0..1] If the first occurrence of 
RXA-9.1 is valued "00" 
and RXA-20 is valued 
"CP" or "PA" 
This shall be the provider 
ordering the immunization. It is 
expected to be empty if the 
immunization record is 
transcribed from a historical 
record. 
13 Enterer's PL O 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 178 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-10 Common Order Segment (ORC) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional 
Predicate 
Value Set Comment 
Location 
14 Call Back 
Phone Number 
XTN O 
15 Order Effective 
Date/Time 
TS O 
16 Order Control 
Code Reason 
CE O 
17 Entering 
Organization 
CE RE HL70362 This is the provider organization 
that entered this record/order. 
18 Entering 
Device 
CE O 
19 Action By XCN O 
20 Advanced 
Beneficiary 
Notice Code 
CE O 
21 Ordering 
Facility Name 
XON O 
22 Ordering 
Facility 
Address 
XAD O 
23 Ordering 
Facility Phone 
Number 
XTN O 
24 Ordering 
Provider 
Address 
XAD O 
25 Order Status CWE O 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 179 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-10 Common Order Segment (ORC) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional 
Predicate 
Value Set Comment 
Modifier 
26 Advanced 
Beneficiary 
Notice 
Override 
Reason 
CWE O 
27 Filler's 
Expected 
Availability 
Date/Time 
TS O 
28 Confidentiality 
Code 
CWE O 
29 Order Type CWE O 
30 Enterer 
Authorization 
Mode 
CNE O 
31 Parent 
Universal 
Service 
Identifier 
CWE O 
Conformance Statement: 
IZ-25: ORC.1 (Order Control) SHALL contain the value “RE “ 
ORC field definitions 
See field definitions for ORC under Profile Z22 above.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 180 


Chapter 6: Messages for Transmitting Immunization Information 
PD1—Patient Demographic Segment 
The Patient Demographic Segment contains patient demographic information that may change from time to time. There are three primary uses PD1 for in 
Immunization Messages. These include indicating whether the person wants his/her data protected, whether the person wants to receive recall/reminder notices 
and the person’s current status in the registry. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 181 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-10 Patient Demographic Segment (PD1) 
Table 8-11 Patient Demographic Segment (PD1) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Comment 
1 Living 
Dependency 
IS O 
2 Living 
Arrangement 
IS O 
3 Patient Primary 
Facility 
XON  O 
4 Patient Primary 
Care Provider 
Name & ID No. 
XCN  X 
5 Student 
Indicator 
IS O 
6 Handicap IS O 
7 Living Will Code IS O 
8 Organ Donor 
Code 
IS O 
9 Separate Bill ID O 
10 Duplicate 
Patient 
CX O 
11 Publicity Code CE RE  [0..1] HL70215 
12 Protection 
Indicator 
ID RE  [0..1] HL70136 
13 Protection 
Indicator 
Effective Date 
DT_D C(RE/X) [0..1] If PD1-12 (Protection Indicator) 
is valued 
14 Place of XON O 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 182 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-11 Patient Demographic Segment (PD1) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Comment 
Worship 
15 Advance 
Directive Code 
CE O 
16 Immunization 
Registry Status 
IS RE [0..1]  HL70441 
17 Immunization 
Registry Status 
Effective Date 
DT_D C(RE/X) [0..1] If the PD1-16 (Registry Status) 
field is valued. 
18 Publicity Code 
Effective Date 
DT_D C(RE/X) [0..1] If the PD1-11 (Publicity Code) 
field is valued. 
19 Military Branch IS O 
20 Military 
Rank/Grade 
IS O 
21 Military Status IS O 
PD1 field definitions 
See field definitions for PD1 under Profile Z22 above.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 183 


Chapter 6: Messages for Transmitting Immunization Information 
PID—Patient Identifier Segment 
The PID is used by all applications as the primary means of communicating patient identification information. This segment contains permanent patient 
identifying and demographic information that, for the most part, is not likely to change frequently.   
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 184 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-11 Patient Identifier Segment (PID) 
Table 8-12 Patient Identifier Segment (PID) 
SEQ Element 
Name 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Constraint 
1 Set ID - PID SI R [1..1] 
2 Patient ID CX X 
3 Patient 
Identifier List 
CX R [1..*] 
4 Alternate 
Patient ID - 
00106 
CX X 
5 Patient Name XPN R [1..*] The first repetition shall contain the 
legal name. Multiple given names 
or initials are separated by spaces. 
6 Mother’s 
Maiden Name 
XPN_
M 
RE [0..1] Only last name and name type are 
required. Set Name Type code to 
“M” for maiden name usage. 
7 Date/Time of 
Birth 
TS_N
Z 
R [1..1] 
8 Administrative 
Sex 
IS RE [0..1] HL70001 
9 Patient Alias XPN X 
10 Race CE RE [0..*] HL70005 
11 Patient 
Address 
XAD RE [0..*]  The first repetition should be the 
primary address. 
12 County Code IS X County belongs in address field. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 185 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-12 Patient Identifier Segment (PID) 
SEQ Element 
Name 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Constraint 
13 Phone 
Number - 
Home 
XTN RE [0..*]  The first instance shall be the 
primary phone number. 
Only one item is allowed per 
repetition. 
14 Phone 
Number - 
Business 
XTN O 
15 Primary 
Language 
CE O 
16 Marital Status CE O 
17 Religion CE O 
18 Patient 
Account 
Number 
CX O 
19 SSN Number - 
Patient 
ST X 
20 Driver's 
License 
Number - 
Patient 
DLN X 
21 Mother's 
Identifier 
CX X 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 186 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-12 Patient Identifier Segment (PID) 
SEQ Element 
Name 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Constraint 
22 Ethnic Group CE RE [0..1] CDCREC 
23 Birth Place ST O 
24 Multiple Birth 
Indicator 
ID 
RE [0..1] 
HL70136 The acceptable values are Y and 
N. If the status is undetermined, 
then field shall be empty. 
25 Birth Order NM C(RE/O) [0..1] 1..2 If PID-24 (Multiple Birth 
Indicator) is valued “Y “ 
This field contains a number 
indicating the person’s birth order, 
with 1 for the first child born and 2 
for the second. 
26 Citizenship CE O 
27 Veterans 
Military Status 
CE O 
28 Nationality CE O 
29 Patient Death 
Date and Time 
TS C(RE/X) [0..1] If PID-30 (patient death 
indicator) is valued “Y” 
30 Patient Death 
Indicator 
ID RE [0..1] HL70136 
31 Identity 
Unknown 
Indicator 
ID O 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 187 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-12 Patient Identifier Segment (PID) 
SEQ Element 
Name 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Constraint 
32 Identity 
Reliability 
Code 
IS O 
33 Last Update 
Date/Time 
TS O 
34 Last Update 
Facility 
HD O 
35 Species Code CE O 
36 Breed Code CE O 
37 Strain ST O 
38 Production 
Class Code 
CE O 
39 Tribal 
Citizenship 
CWE O 
Conformance Statement: 
IZ-46: PID-1 (Set ID) SHALL have the literal value “1” 
PID field definitions 
See field definitions for PID under Profile Z22 above.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 188 


Chapter 6: Messages for Transmitting Immunization Information 
PV1—Patient Visit Segment 
The PV1 segment is used to convey visit specific information. The primary use in immunization messages in previous releases was to carry information 
about the client’s eligibility status. This is now recorded at the immunization event (dose administered) level. Use of this segment for the purpose of 
reporting client eligibility for a funding program at the visit level is not supported in the Implementation Guide. 
QAK—Query Acknowledgement Segment 
Table 8-12 Query Acknowledgement Segment (QAK) 
Table 8-13 Query Acknowledgement Segment 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
set 
Comment 
1 Query Tag ST R [1..1] 32 
2 Query 
Response 
Status 
ID RE [0..1] 
3 Message 
Query Name 
CE R [1..1] 
4 Hit Count NM O [0..1] 
5 This payload NM O [0..1] 
6 Hits remaining NM O [0..1] 
QAK field definitions 
QAK-1 Query Tag (ST) 00696 
Definition: This field contains the value sent in QPD-2 (query tag) by the initiating system, and will be used to match response messages to the 
originating query. The responding system is required to echo it back as the first field in the query acknowledgement segment (QAK).  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 189 


Chapter 6: Messages for Transmitting Immunization Information 
QAK-2 Query Response Status (ID) 00708 
Definition: This field allows the responding system to return a precise response status. It is especially useful in the case where no data is found that 
matches the query parameters, but where there is also no error. It is defined with HL7 Table 0208 - Query Response Status.  
QAK-3 Message Query Name (CE) 01375 
Definition: This field contains the name of the query. This shall mirror the QPD-1 (Message Query Name) found in the query message that is being 
responded to. 
QPD Input Parameter Specification 
Table 8-13 QPD Input Parameter Specification (QPD) 
Table 8-14 QPD Input Parameter Specification 
Field 
Seq 
(Query 
ID=Z34) 
Name Key/ 
Search 
Sort LEN TYPE Usage Rep Match 
Op 
TBL Segment 
Field 
Name 
Service 
Identif
ier 
Code 
Element 
Name or 
Value 
1 MessageQue
ryName 
CE R Z34^Request 
Complete 
Immunization 
History^CDCP
HINVS 
2 QueryTag 32 ST R 
3 PatientList CX RE Y PID.3 PID-3: Patient  
Identifier List 
4 PatientName XPN RE PID.5 PID-5: Patient 
Name 
5 PatientMothe
rMaidenNam
e 
XPN RE PID.6 PID-6: Mother’s 
maiden name 
6 Patient Date 
of Birth 
26 TS_NZ RE PID.7 PID-7: Patient 
date of birth 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 190 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-14 QPD Input Parameter Specification 
Field 
Seq 
(Query 
ID=Z34) 
Name Key/ 
Search 
Sort LEN TYPE Usage Rep Match 
Op 
TBL Segment 
Field 
Name 
Service 
Identif
ier 
Code 
Element 
Name or 
Value 
7 Patient Sex 1 IS RE PID.8 PID-8: Patient 
sex 
8 Patient 
Address 
XAD RE PID.11 PID-11: Patient 
Address 
9 Patient home 
phone 
XTN RE PID.13 PID-13: Patient 
home phone 
10 Patient 
multiple birth 
indicator 
1 ID RE PID-24 PID-24: Patient 
multiple birth 
indicator 
11 Patient birth 
order 
2 NM RE PID-25 PID-25: Patient 
birth order 
12 Client last 
updated date 
TS RE PID-33 PID-33: Patient 
last update 
date 
13 Client last 
update 
facility 
HD RE PID-34 PID-34: Patient 
last update 
faciliity 
QPD Input Parameter Field Description and Commentary 
See Field Description under QPD in Profile Z34. 
RXA-- Pharmacy/Treatment Administration Segment 
The RXA segment carries pharmacy administration data.  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 191 


Chapter 6: Messages for Transmitting Immunization Information 
able 8-14 Pharmacy/Treatment Administration (RXA) 
Table 8-15 Pharmacy/Treatment Administration (RXA) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Comment 
1 Give Sub-ID 
Counter 
NM R [1..1] 4 
2 Administration 
Sub-ID Counter 
NM R [1..1] 4 
3 Date/Time Start 
of Administration 
TS_NZ R [1..1] This segment may be used in 
cases where a vaccine has not 
been administered. For 
instance a patient may refuse a 
vaccination or the sending 
system may be forecasting a 
next dose due. See notes 
below for guidance on the 
relevant date to include here. 
4 Date/Time End 
of Administration 
TS O [0..1] See not below 
5 Administered 
Code 
CE R [1..1] CVX Support for CVX code is 
strongly preferred. Local IG 
may identify NDC or CPT as 
acceptable alternative code 
sets. 
6 Administered 
Amount 
NM R [1..1] 20 
7 Administered 
Units 
CE C(R/O) [0..1] If Administered Amount is not 
valued “999”  
UCUM The preferred units of measure 
for this is “mL”. 
8 Administered 
Dosage Form 
CE O [0..1] 
9 Administration varies C(R/O) [0..*] If RXA-20 is valued “CP” or NIP 0001 If this field is used for a notes 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 192 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-15 Pharmacy/Treatment Administration (RXA) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Comment 
Notes “PA” only entry, then the data type 
shall be CE_TX otherwise the 
data type shall be CE. 
 
The primary use of this field it to 
convey if this immunization 
record is based on a historical 
record or was given by the 
provider recording the 
immunization. All systems 
should be able to support this 
use. Other uses of this field are 
permitted, but need to be 
specified locally. 
10 Administering 
Provider 
XCN C(RE/O) [0..1]  If the first occurrence of 
RXA-9.1 is valued "00" 
and RXA-20 is valued 
"CP" or "PA" 
 This is the person who gave the 
administration or the vaccinator. 
It is not the ordering clinician. 
11 Administered-at 
Location 
LA2 C(RE/O) [0..1]  If the first occurrence of 
RXA-9.1 is valued "00" 
and RXA-20 is valued 
"CP" or "PA" 
 This is the clinic/site where the 
vaccine was administered. 
12 Administered 
Per (Time Unit) 
ST O      
13 Administered 
Strength 
NM O      
14 Administered 
Strength Units 
CE O      
15 Substance Lot ST C(R/O) [0..*]  If the first occurrence of  Note that “00” is double zero. 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 193 
 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-15 Pharmacy/Treatment Administration (RXA) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Comment 
Number RXA-9.1 is valued "00" 
and RXA-20 is valued 
"CP" or "PA" 
16 Substance 
Expiration Date 
TS_M C(RE/O) [0..1] If the first occurrence of 
RXA-9.1 is valued "00" 
and RXA-20 is valued 
"CP" or "PA" 
17 Substance 
Manufacturer 
Name 
CE C(R/O) [0..1] If the first occurrence of 
RXA-9.1 is valued "00" 
and RXA-20 is valued 
"CP" or "PA" 
MVX 
18 Substance/Treat
ment Refusal 
Reason 
CE C(R/X) [0..*] If the RXA-20 (Completion 
Status) is valued “RE “ 
NIP002 
19 Indication CE O 
20 Completion 
Status 
ID RE [0..1] 2 HL70322 
21 Action Code - 
RXA 
ID O [0..1] 2 HL70323 
22 System Entry 
Date/Time 
TS O 
23 Administered 
Drug Strength 
Volume 
NM O 
24 Administered 
Drug Strength 
Volume Units 
CWE O 
25 Administered CWE O 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 194 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-15 Pharmacy/Treatment Administration (RXA) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Comment 
Barcode 
Identifier 
26 Pharmacy Order 
Type 
ID O 
Conformance Statement:  
IZ-28: RXA-1 ( Give Sub-id counter) ) SHALL be valued “0”  Note that “0” is zero. 
IZ-29: RXA-2 (admin Sub-id) SHALL be valued “1 “ 
IZ-30: If RXA-4 (Date time of admin end ) is populated, then it SHALL be the same as Start time (RXA-3) 
IZ-31: If RXA-20 is valued "CP" or "PA" then RXA-9.1 (admin notes) SHALL be valued one of the codes listed in NIP001 in the first occurrence 
of this field and the following repetition should be empty or valued with a text notes. 
IZ-32: If the RXA-18 (Refusal Reason) is populated, RXA-20  SHALL be valued to “RE”. 
IZ-47: If RXA-20 is NOT valued "CP" or "PA" then the first occurrence of RXA-9.1 (admin notes) SHALL be empty and the following repetitions 
should be empty or valued with text notes. 
IZ-48: If RXA-20 is valued “RE” then RXA-6 shall be valued “999”. 
IZ-49: If RXA-5.3 is valued “998” then RXA-6 shall be valued “999”. 
IZ-50: If the first instance of RXA-9.1 is not valued “00” then RXA-6 (administered amount) SHALL be valued “999” 
RXA field definitions 
See RXA  field definitions in the Z22 profile. 
RXR-- Pharmacy/Treatment Route Segment 
The Pharmacy/Treatment Route segment contains the alternative combination of route, site, administration device, and administration method that are 
prescribed as they apply to a particular order.  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 195 


Chapter 6: Messages for Transmitting Immunization Information 
Table 8-15 Pharmacy/Treatment Route (RXR) 
Table 8-16 Pharmacy/Treatment Route (RXR) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional 
Predicate 
Value 
Set 
Constraint 
1 Route CE R [1..1] NCIT 
2 Administration 
Site 
CWE RE [0..1] HL70163 
3 Administration 
Device 
CE O 
4 Administration 
Method 
CWE O 
5 Routing 
Instruction 
CE O 
6 Administration 
Site Modifier 
CWE O 
RXR field definitions 
See RXR field definitions in Profile Z22.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 196 


Chapter 6: Messages for Transmitting Immunization Information 
9. Profile Z31 -- Return a List of Candidates Profile
Introduction: 
Profile Z31 – Return List of Candidates is a constrainable profile that supports return of a list of candidate patients of interest. It is a response to the Z34-
Request Immunization History. 
The goal of this response is to return a complete list of candidate patents in response to a request for a person’s record. This will support re-query by the initiator, 
based on selection of a member of the list. 
Interaction Definition 
See Interaction Definition In previous chapter. 
Dynamic Definition 
See Activity Diagram in previous chapter. 
Static Definition – Message Level 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 197 


Chapter 6: Messages for Transmitting Immunization Information 
Table 7-10 Base Response Grammar RSP^K11 
Table 9-1 Return List Message Profile 
Table 9-1 Base Response Grammar RSP^K11 
Segment Cardinality Usage Comment 
MSH [1..1] R  
MSA [1..1] R  
[ERR] [0..1] RE If errors exist, then this segment is populated. 
QAK [1..1] R  
QPD [1..1] R Query Parameter Definition Segment34 
 [1..1] R --- Response begin 
      { [1..*] R Begin patient identifier list 
PID [1..1] R  
[PD1  ] [0..1] RE  
[{NK1 }] [0..*] O  
         End Patient Identifier 
}   Response end 
 
34 Matches the information in the requesting QBP message. 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 198 
 
                                                           


Chapter 6: Messages for Transmitting Immunization Information 
Segment Level Profile 
ERR—Error Segment 
Table 9-2 Error Segment (ERR) 
Table 9-2 Error Segment (ERR) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Description/Comment 
1 Error Code 
and Location 
 ELD X Not supported for Version 2.5 
and above. 
2 Error Location ERL RE [0..1] 18 
3 HL7 Error 
Code 
CWE R [1..1] HL70357 
4 Severity ID R [1..1] 1..1 HL70516 
5 Application 
Error Code 
CWE RE HL70533 
6 Application 
Error 
Parameter 
ST O 
7 Diagnostic 
Information 
TX O 
8 User Message TX RE This is a locally specified 
informative text message about 
the error. 
9 Inform Person 
Indicator 
IS O 
10 Override Type CWE O 
11 Override 
Reason Code 
CWE O 
12 Help Desk XTN O 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 199 
[0..1]
[0..1]


Chapter 6: Messages for Transmitting Immunization Information 
Table 9-2 Error Segment (ERR) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Description/Comment 
Contact Point 
Note: If an error involves the entire message (e.g. the message is not parse-able.) then location has no meaning. In this case, ERR-2 is left empty. 
ERR field definitions: 
See field definitions for ERR under Profile Z23 above.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 200 


Chapter 6: Messages for Transmitting Immunization Information 
MSA—Message Acknowledgement Segment 
Table 9-3 Message Acknowledgement Segment (MSA) 
Table 9-3 Message Acknowledgement Segment (MSA) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Description/Comment 
1 Acknowledgment 
Code 
ID R [1..1] 2..2 HL70008 
2 Message Control 
ID 
ST R [1..1] 1..199 
3 Text Message ST X 
4 Expected 
Sequence 
Number 
NM O 
5 Delayed 
Acknowledgment 
Type 
O 
6 Error Condition CE X 
MSA field definitions 
See field definitions for MSA under Profile Z23 above. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 201 


Chapter 6: Messages for Transmitting Immunization Information 
MSH - Message Header Specification 
Table 7-9 MSH Sp9-4 S for Request Complete Immunization History Query 
Table 9-4 MSH Specification for Return Complete Immunization History Response 
SEQ LEN Data 
Type 
Cardinality Value 
set 
ELEMENT NAME Usage Constraint 
1 1 ST [1..1] Field Separator R The MSH.1 field shall be | 
2 4 ST [1..1] Encoding Characters R The MSH.2 field shall be ^~\& 
3 HD [0..1] 0361 Sending Application RE No constraint 
4 HD [0..1] 0362 Sending Facility RE No constraint 
5 HD [0..1] 0361 Receiving Application RE No constraint 
6 HD [0..1] 0362 Receiving Facility RE No constraint 
7 26 TS_Z [1..1] Date/Time Of Message R The degree of precision must be 
at least to the second, (format 
YYYYMMDDHHMMSS+/-ZZZZ.  
8 40 ST [0..1] Security O 
9 15 MSG [1..1] Message Type R RSP^K11^RSP_K11 
10 199 ST [1..1] Message Control ID R 
11 3 PT [1..1] Processing ID R 
12 VID [1..1] Version ID R 2.5.1 
13 15 NM [0..1] Sequence Number O 
14 180 ST [0..1] Continuation Pointer O 
15 2 ID [0..1] 0155 Accept Acknowledgment 
Type 
R ER 
16 2 ID [0..1] 0155 Application 
Acknowledgment Type 
R AL 
17 3 ID [0..1] 0399 Country Code X blank 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 202 


Chapter 6: Messages for Transmitting Immunization Information 
Table 9-4 MSH Specification for Return Complete Immunization History Response 
SEQ LEN Data 
Type 
Cardinality Value 
set 
ELEMENT NAME Usage Constraint 
18 16 ID [0..1] 0211 Character Set X blank 
19 CE [0..1] Principal Language Of 
Message 
X blank 
20 20 ID [0..1] 0356 Alternate Character Set 
Handling Scheme 
X blank 
21 EI [1..*] Message Profile Identifier R Z31^CDCPHINVS 
22 XON [0..1] 0362 Sending Responsible 
Organization 
RE 
23 XON 0362 Receiving Responsible 
Organization 
RE 
Conformance Statement: 
IZ-12: The MSH.1 (Field Separator)  SHALL be valued “|”  
IZ-13: The MSH.2 (Encoding Characters)  SHALL be valued “^~\& “ 
IZ-15: The MSH-12 (Version ID) SHALL be valued “2.5.1 “ 
IZ-59: MSH-9 (Message Type)  SHALL contain the constant value “RSP^K11^RSP_K11” 
IZ-52: The value of MSH-16 (Application Acknowledgement) shall be “NE”. 
IZ-53: The value of MSH-15 (Accept Acknowledgemnt) shall be “NE” 
IZ-61:  One occurrence of MSH-21 (Message Profile Identifier) SHALL contain the constant value “Z31^CDCPHINVS” 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 203 
[0..1]


Chapter 6: Messages for Transmitting Immunization Information 
MSH Field Definitions 
See field definitions for MSH under Profile Z22 above.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 204 


Chapter 6: Messages for Transmitting Immunization Information 
NK1—Next of Kin Segment 
The NK1 segment contains information about the patient’s other related parties. Any associated parties may be identified. Utilizing NK1-1 - set ID, multiple NK1 
segments can be sent to patient accounts. That is, each subsequent NK1 increments the previous set ID by 1. So if 3 NK1 were sent in one message, the first 
would have a set id of 1, the second would have 2 and the third would have 3. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 205 


Chapter 6: Messages for Transmitting Immunization Information 
Table 9-5 Next of Kin Segment (NK1) 
Table 9-5 Next of Kin Segment (NK1) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
set 
Description/Comment 
1 Set ID - NK1 SI R [1..1] 
2 Name XPN R [1..*] The first instance is the legal 
name and is required. 
3 Relationship CE R [1..1] HL70063 
4 Address XAD RE [0..*] The first instance shall be the 
primary address. 
5 Phone Number XTN RE [0..*] The first instance shall be the 
primary phone number. 
6 Business Phone 
Number 
XTN O 
7 Contact Role CE O 
8 Start Date DT O 
9 End Date DT O 
10 Next of Kin / 
Associated 
Parties Job Title 
ST O 
11 Next of Kin / 
Associated 
Parties Job 
Code/Class 
JCC O 
12 Next of Kin / 
Associated 
Parties 
Employee 
Number 
CX O 
13 Organization XON O 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 206 


Chapter 6: Messages for Transmitting Immunization Information 
Table 9-5 Next of Kin Segment (NK1) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
set 
Description/Comment 
Name - NK1 
14 Marital Status CE O 
15 Administrative 
Sex 
IS O 
16 Date/Time of 
Birth 
TS O 
17 Living 
Dependency 
IS O 
18 Ambulatory 
Status 
IS O 
19 Citizenship CE O 
20 Primary 
Language 
CE O 
21 Living 
Arrangement 
IS O 
22 Publicity Code CE O 
23 Protection 
Indicator 
ID O 
24 Student 
Indicator 
IS O 
25 Religion CE O 
26 Mother’s Maiden 
Name 
XPN O 
27 Nationality CE O 
28 Ethnic Group CE O 
29 Contact Reason CE O 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 207 


Chapter 6: Messages for Transmitting Immunization Information 
Table 9-5 Next of Kin Segment (NK1) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
set 
Description/Comment 
30 Contact 
Person’s Name 
XPN O 
31 Contact 
Person’s 
Telephone 
Number 
XTN O 
32 Contact 
Person’s 
Address 
XAD O 
33 Next of 
Kin/Associated 
Party’s 
Identifiers 
CX O 
34 Job Status IS O 
35 Race CE O 
36 Handicap IS O 
37 Contact Person 
Social Security 
Number 
ST O 
38 Next of Kin Birth 
Place 
ST O 
39 VIP Indicator IS O 
NK1 field definitions 
See field definitions for NK1 under Profile Z22 above. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 208 


Chapter 6: Messages for Transmitting Immunization Information 
QPD Input Parameter Specification 
Table 9-6 QPD Input Parameter Specification 
Table 9-6 QPD Input Parameter Specification 
Field 
Seq 
(Query 
ID=Z34) 
Name Key/ 
Search 
Sort LEN TYPE Usage Rep Match 
Op 
TBL Segment 
Field 
Name 
Service 
Identif
ier 
Code 
Element 
Name or 
Value 
1 MessageQue
ryName 
CE R Z34^Request 
Complete 
Immunization 
History^CDCP
HINVS 
2 QueryTag 32 ST R 
3 PatientList CX RE Y PID.3 PID-3: Patient  
Identifier List 
4 PatientName XPN RE PID.5 PID-5: Patient 
Name 
5 PatientMothe
rMaidenNam
e 
XPN RE PID.6 PID-6: Mother’s 
maiden name 
6 Patient Date 
of Birth 
26 TS_NZ RE PID.7 PID-7: Patient 
date of birth 
7 Patient Sex 1 IS RE PID.8 PID-8: Patient 
sex 
8 Patient 
Address 
XAD RE PID.11 PID-11: Patient 
Address 
9 Patient home 
phone 
XTN RE PID.13 PID-13: Patient 
home phone 
10 Patient 
multiple birth 
1 ID RE PID-24 PID-24: Patient 
multiple birth 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 209 


Chapter 6: Messages for Transmitting Immunization Information 
Table 9-6 QPD Input Parameter Specification 
Field 
Seq 
(Query 
ID=Z34) 
Name Key/ 
Search 
Sort LEN TYPE Usage Rep Match 
Op 
TBL Segment 
Field 
Name 
Service 
Identif
ier 
Code 
Element 
Name or 
Value 
indicator indicator 
11 Patient birth 
order 
2 NM RE PID-25 PID-25: Patient 
birth order 
12 Client last 
updated date 
TS RE PID-33 PID-33: Patient 
last update 
date 
13 Client last 
update 
facility 
HD RE PID-34 PID-34: Patient 
last update 
faciliity 
QPD field definitions 
See QPD field definitions in Profile Z34. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 210 


Chapter 6: Messages for Transmitting Immunization Information 
PID – Patient Identification Segment 
Table 9-7 PID Patient Identification Segment 
Table 9-7 Patient Identification Segment 
SEQ Element 
Name 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Constraint 
1 Set ID - PID SI R [1..1] 
Each patient segment returned in 
this message will be numbered, 
starting with 1 for the first. 
2 Patient ID CX X 
3 Patient 
Identifier List 
CX R [1..*] 
4 Alternate 
Patient ID - 
00106 
CX X 
5 Patient Name XPN R [1..*] The first repetition shall contain the 
legal name. Multiple given names or 
initials are separated by spaces. 
6 Mother’s 
Maiden Name 
XPN_M RE [0..1] Only last name and name type 
are required. Set Name Type 
code to “M” for maiden name 
usage. 
7 Date/Time of 
Birth 
TS_NZ R [1..1] 
8 Administrative 
Sex 
IS RE [0..1] HL70001 
9 Patient Alias XPN X 
10 Race CE RE [0..*] HL70005 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 211 


Chapter 6: Messages for Transmitting Immunization Information 
Table 9-7 Patient Identification Segment 
SEQ Element 
Name 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Constraint 
11 Patient 
Address 
XAD RE [0..*]  The first repetition should be the 
primary address. 
12 County Code IS X County belongs in address field. 
13 Phone Number 
- Home 
XTN RE [0..*]  The first instance shall be the 
primary phone number. 
Only one item is allowed per 
repetition. 
14 Phone Number 
- Business 
XTN O 
15 Primary 
Language 
CE O 
16 Marital Status CE O 
17 Religion CE O 
18 Patient Account 
Number 
CX O 
19 SSN Number - 
Patient 
ST X 
20 Driver's 
License 
Number - 
Patient 
DLN X 
21 Mother's 
Identifier 
CX X 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 212 


Chapter 6: Messages for Transmitting Immunization Information 
Table 9-7 Patient Identification Segment 
SEQ Element 
Name 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Constraint 
22 Ethnic Group CE RE [0..1] HL70189 
23 Birth Place ST O 
24 Multiple Birth 
Indicator 
ID 
RE [0..1] 
HL70136 The acceptable values are Y and N. 
If the status is undetermined, then 
field shall be empty. 
25 Birth Order NM C(RE/O) [0..1] 1..2 If PID-24 (Multiple Birth Indicator) 
is valued “Y “ 
This field contains a number 
indicating the person’s birth order, 
with 1 for the first child born and 2 
for the second. 
26 Citizenship CE O 
27 Veterans 
Military Status 
CE O 
28 Nationality CE O 
29 Patient Death 
Date and Time 
TS C(RE/X) [0..1] If PID-30 (patient death date) is 
valued “Y” 
30 Patient Death 
Indicator 
ID RE [0..1] HL70136 
31 Identity 
Unknown 
Indicator 
ID O 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 213 


Chapter 6: Messages for Transmitting Immunization Information 
Table 9-7 Patient Identification Segment 
SEQ Element 
Name 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Constraint 
32 Identity 
Reliability Code 
IS O 
33 Last Update 
Date/Time 
TS O 
34 Last Update 
Facility 
HD O 
35 Species Code CE O 
36 Breed Code CE O 
37 Strain ST O 
38 Production 
Class Code 
CE O 
39 Tribal 
Citizenship 
CWE O 
Conformance Statement 
IZ-46: PID-1 SHALL be a positive integer. 
PID Field Definition 
See PID field definitions in Z22 Profile. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 214 


Chapter 6: Messages for Transmitting Immunization Information 
 
10.Profile Z33 --Return an acknowledgement with no person records  
Introduction: 
Profile Z33 – Return Acknowledgment is a constrainable profile that supports return of an acknowledgement indicating not patients being returned in response 
to the Z34-Request Immunization History. 
The goal of this profile is to return an acknowledgment message. It will indicate that either the message could be parsed, but there was an error processing the 
message or that no candidates were found. No demographic or immunization history will be returned. 
Interaction Definition 
An acknowledgement is returned when one of the 3 cases occur.  
1. An error has occurred when processing the query. 
2. No high confidence matches are found. This includes when a match is found but is not allowed to be shared for privacy reasons or the receiving system 
does not support the profile Z31-Return list of candidates. 
3. Too many matches are found and so none will be returned. 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 215 
 


Chapter 6: Messages for Transmitting Immunization Information 
Figure 42  Return Acknowledgement 
Dynamic Definition 
See Activity Diagram in profile Z34. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 216 


Chapter 6: Messages for Transmitting Immunization Information 
Static Definition – Message Level 
Table 10-1 Base Response Grammar RSP^K11 
Table 10-1 Base Response Grammar RSP^K11 
Segment Cardinality Usage Comment 
MSH [1..1] R 
MSA [1..1] R 
[ERR] [0..1] RE If errors exist, then this segment is populated. 
QAK [1..1] R 
QPD [1..1] R Query Parameter Definition Segment35 
35 Matches the information in the requesting QBP message. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 217 


Chapter 6: Messages for Transmitting Immunization Information 
Static Definition -- Segment Level 
ERR—Error Segment 
Table 10-2 Error Segment (ERR) 
Table 10-2 Error Segment (ERR) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Description/Comment 
1 Error Code 
and Location 
 ELD X Not supported for Version 2.5 
and above. 
2 Error Location ERL RE [0..1] 18 
3 HL7 Error 
Code 
CWE R [1..1] HL70357 
4 Severity ID R [1..1] 1..1 HL70516 
5 Application 
Error Code 
CWE RE HL70533 
6 Application 
Error 
Parameter 
ST O 
7 Diagnostic 
Information 
TX O 
8 User Message TX RE This is a locally specified 
informative text message about 
the error. 
9 Inform Person 
Indicator 
IS O 
10 Override Type CWE O 
11 Override 
Reason Code 
CWE O 
12 Help Desk XTN O 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 218 
[0..1]
[0..1]


Chapter 6: Messages for Transmitting Immunization Information 
Table 10-2 Error Segment (ERR) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Description/Comment 
Contact Point 
Note: If an error involves the entire message (e.g. the message is not parse-able.) then location has no meaning. In this case, ERR-2 is left empty. 
ERR field definitions: 
See field definitions for ERR under Profile Z23 above. 
HL7 Version 2.5.1 Message Profile for Returning an acknowledgement in Response to a Request Immunization History Query when no candidates are 
found or an error has been found in the query. 
Table 10-3 Query Response Possibilities 
Table 10-3 Query Response Possibilities 
Outcome Action 
No clients are found that match the requested person 
Send acknowledgement indicating no matches found. 
(See Z33 profile) 
The message is so poorly formed it can’t be 
processed.  That is, the message can’t be parsed as a 
query. 
Return error acknowledgement (ACK) 
The message can be parsed but has errors, such as 
missing data elements that are required to support 
query processing. 
Return acknowledgement indicating errors. (See Z33 
profile). 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 219 


Chapter 6: Messages for Transmitting Immunization Information 
MSA—Message Acknowledgement Segment 
Table 10-4 Message Acknowledgement Segment (MSA) 
Table 10-4 Message Acknowledgement Segment (MSA) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Description/Comment 
1 Acknowledgment 
Code 
ID R [1..1] 2..2 HL70008 
2 Message Control 
ID 
ST R [1..1] 1..199 
3 Text Message ST X 
4 Expected 
Sequence 
Number 
NM O 
5 Delayed 
Acknowledgment 
Type 
O 
6 Error Condition CE X 
MSA field definitions 
See MSA field definitions in Z23 Profile. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 220 


Chapter 6: Messages for Transmitting Immunization Information 
MSH - Message Header Specification 
Table 10-5 MSH Specification for Request Complete Immunization History Query 
Table 10-5 MSH Specification for Acknowledgement Response 
SEQ LEN Data 
Type 
Cardinality Value 
set 
ELEMENT NAME Usage Constraint 
1 1 ST [1..1] Field Separator R The MSH.1 field shall be | 
2 4 ST [1..1] Encoding Characters R The MSH.2 field shall be ^~\& 
3 HD [0..1] 0361 Sending Application RE No constraint 
4 HD [0..1] 0362 Sending Facility RE No constraint 
5 HD [0..1] 0361 Receiving Application RE No constraint 
6 HD [0..1] 0362 Receiving Facility RE No constraint 
7 26 TS_Z [1..1] Date/Time Of Message R The degree of precision must be 
at least to the second, (format 
YYYYMMDDHHMMSS+/-ZZZZ). 
8 40 ST [0..1] Security O 
9 15 MSG [1..1] Message Type R RSP^K11^RSP_K11 
10 199 ST [1..1] Message Control ID R 
11 3 PT [1..1] Processing ID R 
12 VID [1..1] Version ID R 2.5.1 
13 15 NM [0..1] Sequence Number O 
14 180 ST [0..1] Continuation Pointer O 
15 2 ID [0..1] 0155 Accept Acknowledgment 
Type 
R NE 
16 2 ID [0..1] 0155 Application 
Acknowledgment Type 
R 
17 3 ID [0..1] 0399 Country Code X blank 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 221 


Chapter 6: Messages for Transmitting Immunization Information 
Table 10-5 MSH Specification for Acknowledgement Response 
SEQ LEN Data 
Type 
Cardinality Value 
set 
ELEMENT NAME Usage Constraint 
18 16 ID [0..1] 0211 Character Set X blank 
19  CE [0..1]  Principal Language Of 
Message 
X blank 
20 20 ID [0..1] 0356 Alternate Character Set 
Handling Scheme 
X blank 
21  EI  [1..1]  Message Profile Identifier R Z33^CDCPHINVS 
22  XON [0..1] 0362 Sending Responsible 
Organization 
RE  
23  XON  0362 Receiving Responsible 
Organization 
RE  
Conformance Statement: 
IZ-12: The MSH.1 (Field Separator) SHALL be valued “|”  
IZ-13: The MSH.2 (Encoding Characters) SHALL be valued “^~\& “ 
IZ-15: The MSH-12 (Version ID) SHALL be valued “2.5.1 “ 
IZ-59: MSH-9 (Message Type) SHALL contain the constant value “RSP^K11^RSP_K11” 
IZ-52: The value of MSH-16 (Application Acknowledgement) shall be “NE”. 
IZ-53: The value of MSH-15 (Accept Acknowledgement) shall be “NE” 
IZ-63: One occurrence of MSH-21 (Message Profile Identifier) SHALL contain the constant value “Z33^CDCPHINVS” 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 222 
 
[0..1]


Chapter 6: Messages for Transmitting Immunization Information 
MSH Field Definitions 
See field definitions for MSH under Profile Z23 above. 
QPD Input Parameter Specification 
Table 10-6 QPD Input Parameter Specification 
Table 10-6 QPD Input Parameter Specification 
Field 
Seq 
(Query 
ID=Z34) 
Name Key/ 
Search 
Sort LEN TYPE Usage Rep Match 
Op 
TBL Segment 
Field 
Name 
Service 
Identif
ier 
Code 
Element 
Name or 
Value 
1 MessageQue
ryName 
CE R Z34^Request 
Complete 
Immunization 
History^CDCP
HINVS 
2 QueryTag 32 ST R 
3 PatientList CX RE Y PID.3 PID-3: Patient  
Identifier List 
4 PatientName XPN RE PID.5 PID-5: Patient 
Name 
5 PatientMothe
rMaidenNam
e 
XPN RE PID.6 PID-6: Mother’s 
maiden name 
6 Patient Date 
of Birth 
26 TS_NZ RE PID.7 PID-7: Patient 
date of birth 
7 Patient Sex 1 IS RE PID.8 PID-8: Patient 
sex 
8 Patient 
Address 
XAD RE PID.11 PID-11: Patient 
Address 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 223 


Chapter 6: Messages for Transmitting Immunization Information 
Table 10-6 QPD Input Parameter Specification 
Field 
Seq 
(Query 
ID=Z34) 
Name Key/ 
Search 
Sort LEN TYPE Usage Rep Match 
Op 
TBL Segment 
Field 
Name 
Service 
Identif
ier 
Code 
Element 
Name or 
Value 
9 Patient home 
phone 
XTN RE PID.13 PID-13: Patient 
home phone 
10 Patient 
multiple birth 
indicator 
1 ID RE PID-24 PID-24: Patient 
multiple birth 
indicator 
11 Patient birth 
order 
2 NM RE PID-25 PID-25: Patient 
birth order 
12 Client last 
updated date 
TS RE PID-33 PID-33: Patient 
last update 
date 
13 Client last 
update 
facility 
HD RE PID-34 PID-34: Patient 
last update 
faciliity 
QPD Field Definitions 
See QPD field definitions in Profile Z34.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 224 


Chapter 6: Messages for Transmitting Immunization Information 
11. Profile Z44--Request Evaluated Immunization History and
Forecast Query Profile 
Introduction 
Profile Z44 – Request Evaluated History and Forecast is a constrainable profile that supports request of an immunization evaluated immunization history and 
forecast  of an individual. It has a set partner profiles which return the requested history or an acknowledgement that no matches were found.  
The goal of this query is to request a evaluated immunization history and forecast of next doses due. I 
See Use Case 3—Request Evaluated  History above for Use Case details. 
An evaluated immunization history and forecast consists of: 
• Limited demographic information about the individual
• The history of immunizations administered with validation by a clinical decision support engine
• Forecast of what the person is due to receive next and the dates when due
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 225 


Chapter 6: Messages for Transmitting Immunization Information 
Table 11-1 Request Evaluated Immunization History and Forecast Query Profile 
Table 11- 1 Request Evaluated Immunization History and Forecast Query Profile 
Query Statement ID (Query ID=Z44): Z44 
Type: Query 
Query Name: Request Evaluated History and Forecast 
Query Trigger (= MSH-9): QBP^Q11^QBP_Q11 
Query Mode: Both 
Response Trigger (= MSH-9): RSP^K11^RSP_K11 
Query Characteristics: The query parameters may include demographic and address data. No sorting is expected. 
This profile does not specify the logic used when searching for matching clients/patients. 
The query parameter contents may be used for simple query or as input for probabilistic 
search algorithms. The search methodology should be specified by local implementations. 
Purpose: The purpose is to request an evaluated immunization history and forecast for one client. 
Response Characteristics: • In the case where no candidates are found, the acknowledgement response will
indicate that no candidates were found.
• In the case where exactly one high-confidence candidate is found, an evaluated
immunization history and forecast will be returned.
• In the case where one or more clients are a lower-confidence match for the criteria
sent, the acknowledgement response will indicate no matches and no records will
be returned.
• In the case where receiving system can’t process the query, the receiving system
will indicate an error in an acknowledgement.
Based on Segment Pattern: NA 
Each system will need to determine the business rules that deal with patients who wish to have their records protected. Some systems may choose to treat the 
person as if they are not in the system. Others may choose to send a response indicating that the person exists in the system but does not allow sharing. This rule 
should be clearly documented in the local profile. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 226 


Chapter 6: Messages for Transmitting Immunization Information 
Table 11-2 Response Grammar to Different Outcomes 
Table 11-2 Response Grammar to Different Outcomes 
Outcome of Query Response Message 
No match found 
Response indicates that message was successfully processed and that no clients matched the 
criteria that were sent in the query. See Acknowledgement Profile (Z33). 
Exactly one high confidence match found36 
Response includes an evaluated immunization history and forecast as specified below. 
See Profile Return Evaluated Immunization History and Forecast (Z42). 
A lower confidence match (or matches) is found. 
Response indicates that message was successfully processed and that no clients matched the 
criteria that were sent in the query. See Acknowledgement Profile (Z33). 
Message is not well formed and has fatal errors. 
Response indicates that the message was not successfully processed and may indicate errors. 
See Return Acknowledgement Profile (Z33). 
Message can’t be parsed. 
Return ACK, acknowledgement message indicating error, if message can be identified as an HL7 
message. 
36 Definition of match is left to local business rules. These rules should be documented in a local implementation guide. For example, a system may only return an immunization history when the match 
is exact, returning a list of 1 if one person for a lower probability match. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 227 


Chapter 6: Messages for Transmitting Immunization Information 
Interaction Definition 
Figure 43 Return Immunization Evaluated History Sequence Diagram 
This diagram illustrates the context of the messages. The messages specified in this profile are shown with bolded. 
Dynamic Definition 
The following activity diagram shows the flow of activities associated with this profile and its partners. This is described in the table below the diagram. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 228 


Chapter 6: Messages for Transmitting Immunization Information 
Figure 44 Activity Diagram -Response to Different Outcomes 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 229 


Chapter 6: Messages for Transmitting Immunization Information 
Table 11-3 Response to Different Outcomes 
TABLE 11-3 RESPONSE TO DIFFERENT OUTCOMES 
Outcome of Query Response Message 
No high confidence match found Response indicates that message was successfully processed and that no clients matched the 
criteria that were sent in the query. See Acknowledgement Profile (Z33). 
Exactly one high confidence match found 37 Response includes a complete immunization history as specified below. 
See Profile Return Evaluated  History and  Forecast (Z42). 
Message is not well formed and has fatal errors. Response indicates that the message was not successfully processed and may indicate errors. 
See Return Acknowledgement Profile (Z33). 
Message was rejected because one of the following 
occurred: 
• Unsupported message type
• Unsupported event code
• Unsupported processing ID
• Unable to process for reasons unrelated for
format or content
Return ACK message with errors. 
Message can’t be identified as an HL7 message. No HL7 message is returned. 
37 Definition of match is left to local business rules. These rules should be documented in a local implementation guide. For example, a system may only return an immunization history when the match 
is exact, returning a list of 1 if one person for a lower probability match. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 230 


Chapter 6: Messages for Transmitting Immunization Information 
Static Definition - Message Level: 
Table 11-4 Z44 Request Complete Immunization History 
 
QBP^Q11^QBP_Q11 
Usage Comment 
MSH Message Header Segment R  
[{SFT}] Software Segment O Local profile may 
specify 
QPD Query Parameter Definition R  
RCP Response Control Parameter R  
[ DSC ] Continuation Pointer X Not supported 
 
 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 231 
 
Query Grammar: QBP 
Message  
TABLE 11-4 Z44 REQUEST EVALUATED  IMMUNIZATION HISTORY AND 
FORECAST 


Chapter 6: Messages for Transmitting Immunization Information 
Static Definition—Segment Level 
ERR—Error Segment 
Table 11-5 Error Segment (ERR) 
Table 11-4 Error Segment (ERR) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Description/Comment 
1 Error Code 
and Location 
 ELD X Not supported for Version 2.5 
and above. 
2 Error Location ERL RE [0..1]38 18 
3 HL7 Error 
Code 
CWE R [1..1] HL70357 
4 Severity ID R [1..1] 1..1 HL70516 
5 Application 
Error Code 
CWE RE HL70533 
6 Application 
Error 
Parameter 
ST O 
7 Diagnostic 
Information 
TX O 
8 User Message TX RE This is a locally specified 
informative text message about 
the error. 
9 Inform Person 
Indicator 
IS O 
10 Override Type CWE O 
38 This Guide does not support repeat of this field. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 232 
[0..1]
[0..1]


Chapter 6: Messages for Transmitting Immunization Information 
Table 11-4 Error Segment (ERR) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Description/Comment 
11 Override 
Reason Code 
CWE O 
12 Help Desk 
Contact Point 
XTN O 
Note: If an error involves the entire message (e.g. the message is not parse-able.) then location has no meaning. In this case, ERR-2 is left empty. 
ERR field definitions: 
See field definitions for ERR under Profile Z23 above.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 233 


Chapter 6: Messages for Transmitting Immunization Information 
MSA—Message Acknowledgement Segment 
Table 11-6 Message Acknowledgement Segment (MSA) 
Table 11-5 Message Acknowledgement Segment (MSA) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Description/Comment 
1 Acknowledgment 
Code 
ID R [1..1] 2..2 HL70008 
2 Message Control 
ID 
ST R [1..1] 1..199 
3 Text Message ST X 
4 Expected 
Sequence 
Number 
NM O 
5 Delayed 
Acknowledgment 
Type 
O 
6 Error Condition CE X 
MSA field definitions 
See field definitions for MSA under Profile Z23 above. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 234 


Chapter 6: Messages for Transmitting Immunization Information 
MSH - Message Header Specification 
Table 11-7 MSH Specification for Request Complete Immunization History Query 
Table 11-6 MSH Specification for Request Evaluated History and Forecast Immunization History Query 
SEQ LEN Data 
Type 
Cardinality Value 
set 
ITEM 
# 
ELEMENT NAME Usage Constraint 
1 1 ST [1..1] 00001 Field Separator R The MSH.1 field shall be | 
2 4 ST [1..1] 00002 Encoding Characters R The MSH.2 field shall be ^~\& 
3 HD [0..1] 0361 00003 Sending Application RE No constraint 
4 HD [0..1] 0362 00004 Sending Facility RE No constraint 
5 HD [0..1] 0361 00005 Receiving Application RE No constraint 
6 HD [0..1] 0362 00006 Receiving Facility RE No constraint 
7 26 TS_Z [1..1] 00007 Date/Time Of Message R The degree of precision must be 
at least to the second, (format 
YYYYMMDDHHMMSS+/-ZZZZ). 
8 40 ST [0..1] 00008 Security O 
9 15 MSG [1..1] 00009 Message Type R QBP^Q11^QBP_Q11 
10 199 ST [1..1] 00010 Message Control ID R 
11 3 PT [1..1] 00011 Processing ID R 
12 VID [1..1] 00012 Version ID R 2.5.1 
13 15 NM [0..1] 00013 Sequence Number O 
14 180 ST [0..1] 00014 Continuation Pointer O 
15 2 ID [0..1] 0155 00015 Accept Acknowledgment 
Type 
R ER –On Error 
16 2 ID [0..1] 0155 00016 Application 
Acknowledgment Type 
R AL-Always 
17 3 ID [0..1] 0399 00017 Country Code X blank 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 235 


Chapter 6: Messages for Transmitting Immunization Information 
Table 11-6 MSH Specification for Request Evaluated History and Forecast Immunization History Query 
SEQ LEN Data 
Type 
Cardinality Value 
set 
ITEM 
# 
ELEMENT NAME Usage Constraint 
18 16 ID [0..1] 0211 00692 Character Set X blank 
19 CE [0..1] 00693 Principal Language Of 
Message 
X blank 
20 20 ID [0..1] 0356 01317 Alternate Character Set 
Handling Scheme 
X blank 
21 EI [1..*] 01598 Message Profile Identifier R Z44^CDCPHINVS 
22 XON [0..1] 0362 01823 Sending Responsible 
Organization 
RE 
23 XON 0362 01824 Receiving Responsible 
Organization 
RE 
Conformance Statement:  
IZ-64: One Occurrence of MSH-21 (Message Profile Identifier) SHALL contain the constant value “Z44^CDCPHINVS” 
IZ-12: The MSH.1 (Field Separator)  SHALL be valued “|”  
IZ-13: The MSH.2 (Encoding Characters)  SHALL be valued “^~\& “ 
IZ-15: The MSH-12 (Version ID) SHALL be valued “2.5.1 “ 
IZ-55: MSH-9 (Message Type)  SHALL contain the constant value “QBP^Q11^QBP_Q11” 
IZ-57: MSH-15 (Accept Acknowledgement) SHALL have a value of “ER”. 
IZ-58: MSH-16 (Application Acknowledgemnt) SHALL have a value of “AL” 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 236 
[0..1]


Chapter 6: Messages for Transmitting Immunization Information 
MSH field definitions 
See field definitions for MSH under Profile Z22 above. 
QPD Input Parameter Specification 
 
Table 11-8 QPD Input Parameter Specification 
Table 11-7 QPD Input Parameter Specification 
Field 
Seq 
(Query 
ID=Z34
) 
Name Key/ 
Search 
Sort LEN TYPE Usage Rep Match 
Op 
TBL Segment 
Field 
Name 
Service 
Identif
ier 
Code 
Element 
Name or 
Value 
1 MessageQueryN
ame 
   CE R      Z34^Request 
Complete 
Immunization 
History^HL7
0471 
2 QueryTag   32 ST R       
3 PatientList    CX RE Y   PID.3  PID-3: 
Patient  
Identifier List 
4 PatientName    XPN RE    PID.5  PID-5: 
Patient 
Name 
5 PatientMotherMa
idenName 
   XPN RE    PID.6  PID-6: 
Mother’s 
maiden 
name 
6 Patient Date of 
Birth 
  26 TS_NZ RE    PID.7  PID-7: 
Patient date 
of birth 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 237 
 


Chapter 6: Messages for Transmitting Immunization Information 
Table 11-7 QPD Input Parameter Specification 
Field 
Seq 
(Query 
ID=Z34
) 
Name Key/ 
Search 
Sort LEN TYPE Usage Rep Match 
Op 
TBL Segment 
Field 
Name 
Service 
Identif
ier 
Code 
Element 
Name or 
Value 
7 Patient Sex 1 IS RE PID.8 PID-8: 
Patient sex 
8 Patient Address XAD RE PID.11 PID-11: 
Patient 
Address 
9 Patient home 
phone 
XTN RE PID.13 PID-13: 
Patient home 
phone 
10 Patient multiple 
birth indicator 
1 ID RE PID-24 PID-24: 
Patient 
multiple birth 
indicator 
11 Patient birth 
order 
2 NM RE PID-25 PID-25: 
Patient birth 
order 
12 Client last 
updated date 
TS RE PID-33 PID-33: 
Patient last 
update date 
13 Client last 
update facility 
HD RE PID-34 PID-34: 
Patient last 
update 
faciliity 
QPD Field Definitions 
The likelihood of finding a particular person is improved when all known parameters are populated. Requesting systems should strive to include values for each 
query parameter. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 238 


Chapter 6: Messages for Transmitting Immunization Information 
Table 11-9 QPD Input Parameter Field Description and Commentary 
Table 11-8 QPD Input Parameter Field Description and Commentary 
Input Parameter (Query 
ID=Z34) 
Comp. Name DT Usage Description 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 239 


Chapter 6: Messages for Transmitting Immunization Information 
Table 11-8 QPD Input Parameter Field Description and Commentary 
Input Parameter (Query 
ID=Z34) 
Comp. Name DT Usage Description 
MessageQueryName CE R Z44^Request Immunization 
History^HL70471 
QueryTag ST R Unique to each query message 
instance. 
PatientList CX RE The combination of values for 
Patientlist.ID, 
patientlst.identifiercode and 
Patientlist.AssigningAuthority are 
intended to allow unique 
identification of a client, if the data 
are found in the responding 
system. 
ID ST R If this field, PID.3.1, is not valued, 
PatientList is not considered when 
seeking matching clients. 
Assigning Authority HD R If this field, PID.3.4, is not valued, 
PatientList is not considered when 
seeking matching clients. 
IdentifierTypeCode IS R If this field, PID.3.5, is not valued, 
PatientList is not considered when 
seeking matching clients. 
PatientName XPN R If this field, PID.5, is not valued, 
then the query will return an error, 
since this is a required field. 
Family Name FN R If this field, PID.5.1, is not valued, 
then patient name is considered to 
contain no value.  
Given Name ST R If this field, PID.5.2, is not valued, 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 240 


Chapter 6: Messages for Transmitting Immunization Information 
Table 11-8 QPD Input Parameter Field Description and Commentary 
Input Parameter (Query 
ID=Z34) 
Comp. Name DT Usage Description 
then patient name is considered to 
contain no value. Given name is 
required.  
Second or further names ST RE If this field, PID.5.3, is not valued, 
then all values for this field are 
considered a match. 
Suffix ST RE If this field, PID.5.4, is not valued, 
then all values for this field are 
considered a match. 
Mother’s Maiden Name XPN_MDN RE If this field, PID.6, is not valued, 
Mother’s maiden name is not 
considered when seeking 
matching clients. 
Family Name FN R If this field, PID.6.1, is not valued, 
then mother’s maiden name is 
considered to contain no value.  
Given Name ST RE If this field, PID.6.2, is not valued, 
then all values for this field are 
considered a match. 
Name Type Code ID RE If the field, PID-6.7, is not valued, 
then all values for this field are 
considered a match. 
DateOfBirth TS R If this field, PID.7, is not valued to 
an accuracy of at least day, then 
this field is considered not valued. 
Sex IS RE If this field, PID.8, is not valued, 
then all values for this field are 
considered a match. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 241 


Chapter 6: Messages for Transmitting Immunization Information 
Table 11-8 QPD Input Parameter Field Description and Commentary 
Input Parameter (Query 
ID=Z34) 
Comp. Name DT Usage Description 
Address XAD RE If this field, PID.11, is not valued, 
then address will not be 
considered when seeking 
matching clients. 
Street Address SAD RE If this field, PID.11.1, is not valued, 
then all values for this field are 
considered a match. 
City ST RE If this field, PID.11.3, is not valued, 
then address is considered to 
contain no value.  
State ST RE If this field, PID.11.4, is not valued, 
then address is considered to 
contain no value.  
ZIP ST RE If this field, PID.11.5, is not valued, 
then all values for this field are 
considered a match. 
Address Type IS RE If this field, PID.11.7 is not valued, 
then it shall default to L, legal 
address. 
Phone XTN RE This field will be considered the 
Home phone. If this field, PID.13, 
is not valued, then phone number 
is not considered when seeking 
matching clients. 
Area code NM If this field, PID.13.6, is not valued, 
then all values for this field shall 
be considered matches. 
Local number NM If this field, PID.13.7, is not valued, 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 242 


Chapter 6: Messages for Transmitting Immunization Information 
Table 11-8 QPD Input Parameter Field Description and Commentary 
Input Parameter (Query 
ID=Z34) 
Comp. Name DT Usage Description 
then address is considered to 
contain no value. 
Multiple Birth Indicator ID RE If this field, PID.24, is not valued, 
then Multiple Birth Indicator is not 
considered when seeking 
matching clients.  
Birth Order NM RE If this field, PID.25, is not valued, 
then birth order is not considered 
when seeking matching clients. 
Client last updated date TS O If this field, PID.33, is not valued, 
then client last updated date is not 
considered when seeking 
matching clients.  
Client last update facility TS O If this field, PID.34, is not valued, 
then client last updating facility is 
not considered when seeking 
matching clients. 
This Guide does not specify the methodology used by the responding system to search for a person. It specifies the structure and content of the message used to 
query. It is incumbent on systems to publically document their expectations within the constraints of this guide.  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 243 


Chapter 6: Messages for Transmitting Immunization Information 
RCP Response Control Parameter Field Description and Commentary 
Table 11-10 RCP Response Control Parameter Field Description and Commentary 
Table 11-9 RCP Response Control Parameter Field Description and Commentary 
Field 
Seq 
(Query 
ID=Z44) 
Name Component 
Name 
LEN DT Usage Description 
1 Query Priority 1 ID RE If this field is not valued then it 
shall default to I. The only value 
permitted is I. 
2 Quantity Limited Request 10 CQ X 
Quantity NM X 
Units CWE X 
3 Response Modality 60 CWE X 
7 Segment group inclusion 256 ID X 
RCP Field Definitions 
See Z34 Profile above for details.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 244 


Chapter 6: Messages for Transmitting Immunization Information 
12.Profile Z42 -- Return Evaluated History and Forecast 
Introduction 
The goal of this response is to return an evaluated immunization history and forecast. It is not intended to support transfer of complete immunization history. It is 
a partner to Profile Z44, Request Evaluated History and Forecast. 
Interaction Definition 
See Interaction Definition in Profile Z44 above. 
Dynamic Definition 
See Dynamic Definition in Profile Z44 above. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 245 


Chapter 6: Messages for Transmitting Immunization Information 
Static Definition --Message Level 
Table 12-1 Return Evaluated Immunization History and Forecast Response Grammar RSP^K11 
Table 12-1 Return Evaluated Immunization History and Forecast Response Grammar RSP^K11 
Segment Cardinality Usage Comment 
MSH [1..1] R 
MSA [1..1] R 
[ERR] [0..1] RE If errors exist, then this segment is populated. 
QAK [1..1] R 
QPD [1..1] R Query Parameter Definition Segment39 
PID 
[1..1] R 
 { 
[1..*] R IMMUNIZATION HISTORY and FORECAST 
GROUP 
ORC [O..1] O 
RXA 
[1..1] R 
[RXR  ] 
[0..1] RE 
[{ 
[1..*] R Begin Observation 
OBX 
[1..1] R 
39 Matches the information in the requesting QBP message. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 246 


Chapter 6: Messages for Transmitting Immunization Information 
Table 12-1 Return Evaluated Immunization History and Forecast Response Grammar RSP^K11 
Segment Cardinality Usage Comment 
}] 
End observation 
} 
End Immunization History 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 247 


Chapter 6: Messages for Transmitting Immunization Information 
Static Definition -- Segment Level 
MSH - Message Header Specification 
 TABLE 12-2 MSH SPECIFICATION FOR RETURN EVALUATED IMMUNIZATION HISTORY AND
FORECAST RESPONSE 
SEQ LEN Data 
Type 
Cardinality Value 
set 
ELEMENT NAME Usage Constraint 
1 1 ST [1..1] Field Separator R The MSH.1 field shall be | 
2 4 ST [1..1] Encoding Characters R The MSH.2 field shall be ^~\& 
3 HD [0..1] 0361 Sending Application RE No constraint 
4 HD [0..1] 0362 Sending Facility RE No constraint 
5 HD [0..1] 0361 Receiving Application RE No constraint 
6 HD [0..1] 0362 Receiving Facility RE No constraint 
7 26 TS_Z [1..1] Date/Time Of Message R The degree of precision must be 
at least to the second, (format 
YYYYMMDDHHMMSS+/-ZZZZ). 
8 40 ST [0..1] Security O 
9 15 MSG [1..1] Message Type R RSP^K11^RSP_K11 
10 199 ST [1..1] Message Control ID R 
11 3 PT [1..1] Processing ID R 
12 VID [1..1] Version ID R 2.5.1 
13 15 NM [0..1] Sequence Number O 
14 180 ST [0..1] Continuation Pointer O 
15 2 ID [0..1] 0155 Accept Acknowledgment R NE 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 248 
Table 12-2 MSH Specification for Return Evaluated Immunization History and Forecast Response 


Chapter 6: Messages for Transmitting Immunization Information 
TABLE 12-2 MSH SPECIFICATION FOR RETURN EVALUATED IMMUNIZATION HISTORY AND 
FORECAST RESPONSE 
SEQ LEN Data 
Type 
Cardinality Value 
set 
ELEMENT NAME Usage Constraint 
Type 
16 2 ID [0..1] 0155 Application 
Acknowledgment Type 
R AL 
17 3 ID [0..1] 0399 Country Code X blank 
18 16 ID [0..1] 0211 Character Set X blank 
19 CE [0..1] Principal Language Of 
Message 
X blank 
20 20 ID [0..1] 0356 Alternate Character Set 
Handling Scheme 
X blank 
21 EI [1..*] Message Profile Identifier R Z42^CDCPHINVS 
22 XON [0..1] 0362 Sending Responsible 
Organization 
RE 
23 XON 0362 Receiving Responsible 
Organization 
R 
Conformance Statement:  
IZ-65: One Occurrence of MSH-21 (Message Profile Identifier) SHALL contain the constant value  “Z42^CDCPHINVS” 
IZ-12: The MSH.1 (Field Separator)  SHALL be valued “|”  
IZ-13: The MSH.2 (Encoding Characters)  SHALL be valued “^~\& “ 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 249 
[0..1]


Chapter 6: Messages for Transmitting Immunization Information 
IZ-15: The MSH-12 (Version ID) SHALL be valued “2.5.1 “ 
IZ-55: MSH-9 (Message Type)  SHALL contain the constant value “QBP^Q11^QBP_Q11” 
IZ-53: MSH-15 SHALL have a value of “NE”. 
IZ-52: MSH-16 SHALL have a value of “NE”. 
MSH field definitions 
See field definitions for MSH under Profile Z22 above. 
OBX—Observation Result Segment 
The observation result segment has many uses. It carries observations about the object of its parent segment. In the VXU/RSP it is associated with the RXA or 
immunization record. The basic format is a question (OBX-3) and an answer (OBX-5).  
Consult Appendix B for detailed examples of each of the uses. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 250 


Chapter 6: Messages for Transmitting Immunization Information 
Table 12-3 Observation Segment (OBX) 
Table 12-3 Observation Segment (OBX) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional 
Predicate 
Value Sets Comment 
1 Set ID – OBX SI R [1..1] 1..4 
2 Value Type ID R [1..1] 2..3 HL70125 
(constrained) 
3 Observation 
Identifier 
CE R [1..1] 
NIP003 
This indicates what this 
observation refers to. It poses 
the question that is answered by 
OBX-5. 
4 Observation 
Sub-ID 
ST R [1..1] 1..20 Constrain to 
positive 
integers 
5 Observation 
Value 
varies40 R [1..1] varies This is the observation value and 
answers the question posed by 
OBX-3 
6 Units CE C(R/O) [0..1] If OBX-2(Value Type) is 
valued “NM” or “SN”  
Note: If there is not a unit of 
measure available while 
the Condition Predicated is 
true, then the value “NA” 
SHALL be used in CE.1 
and “HL70353” in CE.3. 
UCUM 
7 References ST O 
40 The length of the observation field is variable, depending upon value type. See OBX-2 value type. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 251 


Chapter 6: Messages for Transmitting Immunization Information 
Table 12-3 Observation Segment (OBX) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional 
Predicate 
Value Sets Comment 
 
Range 
8 Abnormal 
Flags 
IS O      
9 Probability NM O      
10 Nature of 
Abnormal Test 
ID O      
11 Observation 
Result Status 
ID R [1..1] 1  HL70085 
(constrained) 
 
12 Effective Date 
of Reference 
Range Values 
TS O      
13 User Defined 
Access 
Checks 
ST O      
14 Date/Time of 
the 
Observation 
TS_NZ RE [0..1]     
15 Producer's 
Reference 
CE O      
16 Responsible 
Observer 
XCN O      
17 Observation 
Method 
CE O [0..1]     
18 Equipment 
Instance 
Identifier 
EI O      
19 Date/Time of TS O      
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 252 
 


Chapter 6: Messages for Transmitting Immunization Information 
Table 12-3 Observation Segment (OBX) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional 
Predicate 
Value Sets Comment 
the Analysis 
20 Reserved for 
harmonization 
with V2.6 
X 
21 Reserved for 
harmonization 
with V2.6 
X 
22 Reserved for 
harmonization 
with V2.6 
X 
23 Performing 
Organization 
Name 
XON O 
24 Performing 
Organization 
Address 
XAD O 
25 Performing 
Organization 
Medical 
Director 
XCN O 
Conformance Statement:  
IZ-20: The Value of OBX-1 (Set ID-OBX) SHALL be valued sequentially starting with the value “1” within a message. 
IZ-21: The value of OBX-2 (Value Type) SHALL be one of the following: 
CE, NM, ST, DT, ID or TS  
IZ-22: The value of OBX-11 (Observation Result Status) SHALL be “F” 
IZ-37: If OBX-3.1 is “30956-7” and OBX-2 is “CE” then the value set for OBX-5 shall be CVX. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 253 


Chapter 6: Messages for Transmitting Immunization Information 
OBX field definitions 
See field definitions for OBX under Profile Z22 above.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 254 


Chapter 6: Messages for Transmitting Immunization Information 
ORC—Order Request Segment 
The Common Order segment (ORC) is used to transmit fields that are common to all orders (all types of services that are requested). While not all immunizations 
recorded in an immunization message are able to be associated with an order, each RXA must be associated with one ORC, based on HL7 2.5.1 standard.  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 255 


Chapter 6: Messages for Transmitting Immunization Information 
Table 12-4 Common Order Segment (ORC) 
Table 12-5 Common Order Segment (ORC) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional 
Predicate 
Value Set Comment 
1 Order Control ID R [1..1] 2 HL70119 
(constrained) 
2 Placer Order 
Number 
EI RE [0..1] See Guidance below. 
3 Filler Order 
Number 
EI R [1..1] See Guidance below. 
4 Placer Group 
Number 
EI O 
5 Order Status ID O 
6 Response Flag ID O 
7 Quantity/Timin
g 
TQ X 
8 Parent EIP O 
9 Date/Time of 
Transaction 
TS O 
10 Entered By XCN O [0..1] This is the person that entered 
this immunization record into the 
system. 
11 Verified By XCN O 
12 Ordering 
Provider 
XCN O [0..1] This shall be the provider 
ordering the immunization. It is 
expected to be empty if the 
immunization record is 
transcribed from a historical 
record. 
13 Enterer's PL O 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 256 


Chapter 6: Messages for Transmitting Immunization Information 
Table 12-5 Common Order Segment (ORC) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional 
Predicate 
Value Set Comment 
Location 
14 Call Back 
Phone Number 
XTN O 
15 Order Effective 
Date/Time 
TS O 
16 Order Control 
Code Reason 
CE O 
17 Entering 
Organization 
CE RE HL70362 This is the provider organization 
that entered this record/order. 
18 Entering 
Device 
CE O 
19 Action By XCN O 
20 Advanced 
Beneficiary 
Notice Code 
CE O 
21 Ordering 
Facility Name 
XON O 
22 Ordering 
Facility 
Address 
XAD O 
23 Ordering 
Facility Phone 
Number 
XTN O 
24 Ordering 
Provider 
Address 
XAD O 
25 Order Status CWE O 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 257 


Chapter 6: Messages for Transmitting Immunization Information 
Table 12-5 Common Order Segment (ORC) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional 
Predicate 
Value Set Comment 
Modifier 
26 Advanced 
Beneficiary 
Notice 
Override 
Reason 
CWE O 
27 Filler's 
Expected 
Availability 
Date/Time 
TS O 
28 Confidentiality 
Code 
CWE O 
29 Order Type CWE O 
30 Enterer 
Authorization 
Mode 
CNE O 
31 Parent 
Universal 
Service 
Identifier 
CWE O 
Conformance Statement: 
IZ-25: ORC.1 (Order Control) SHALL contain the value “RE “ 
ORC field definitions 
See field definitions for ORC under Profile Z22 above.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 258 


Chapter 6: Messages for Transmitting Immunization Information 
PID—Patient Identifier Segment 
The PID is used by all applications as the primary means of communicating patient identification information. This segment contains permanent patient 
identifying and demographic information that, for the most part, is not likely to change frequently.   
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 259 


Chapter 6: Messages for Transmitting Immunization Information 
Table 12-5 Patient Identifier Segment (PID) 
Table 12-6 Patient Identifier Segment (PID) 
SEQ Element 
Name 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Constraint 
1 Set ID - PID SI R [1..1] 
2 Patient ID CX X 
3 Patient 
Identifier List 
CX R [1..*] 
4 Alternate 
Patient ID - 
00106 
CX X 
5 Patient Name XPN R [1..*] The first repetition shall contain the 
legal name. Multiple given names 
or initials are separated by spaces. 
6 Mother’s 
Maiden Name 
XPN_
M 
O [0..1] Only last name and name type are 
required. Set Name Type code to 
“M” for maiden name usage. 
7 Date/Time of 
Birth 
TS_N
Z 
R [1..1] 
8 Administrative 
Sex 
IS RE [0..1] HL70001 
9 Patient Alias XPN X 
10 Race CE O [0..*] HL70005 
11 Patient 
Address 
XAD RE [0..*]  The first repetition should be the 
primary address. 
12 County Code IS X County belongs in address field. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 260 


Chapter 6: Messages for Transmitting Immunization Information 
Table 12-6 Patient Identifier Segment (PID) 
SEQ Element 
Name 
Usage Cardinality LEN Conditional Predicate Constraint 
13 Phone 
Number - 
Home 
XTN O [0..*]      The first instance shall be the 
primary phone number. 
Only one item is allowed per 
repetition. 
14 Phone 
Number - 
Business 
XTN O        
15 Primary 
Language 
CE O      
16 Marital Status CE O      
17 Religion CE O      
18 Patient 
Account 
Number 
CX O       
19 SSN Number - 
Patient 
ST X       
20 Driver's 
License 
Number - 
Patient 
DLN X       
21 Mother's 
Identifier 
CX X       
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 261 
 
Data 
Type 
Value 
Set 


Chapter 6: Messages for Transmitting Immunization Information 
Table 12-6 Patient Identifier Segment (PID) 
SEQ Element 
Name 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Constraint 
22 Ethnic Group CE O [0..1] CDCREC 
23 Birth Place ST O 
24 Multiple Birth 
Indicator 
ID 
O [0..1] 
HL70136 The acceptable values are Y and 
N. If the status is undetermined, 
then field shall be empty. 
25 Birth Order NM O [0..1] 1..2 This field contains a number 
indicating the person’s birth order, 
with 1 for the first child born and 2 
for the second. 
26 Citizenship CE O 
27 Veterans 
Military Status 
CE O 
28 Nationality CE O 
29 Patient Death 
Date and Time 
TS O [0..1] 
30 Patient Death 
Indicator 
ID RE [0..1] HL70136 
31 Identity 
Unknown 
Indicator 
ID O 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 262 


Chapter 6: Messages for Transmitting Immunization Information 
Table 12-6 Patient Identifier Segment (PID) 
SEQ Element 
Name 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Constraint 
32 Identity 
Reliability 
Code 
IS O 
33 Last Update 
Date/Time 
TS O 
34 Last Update 
Facility 
HD O 
35 Species Code CE O 
36 Breed Code CE O 
37 Strain ST O 
38 Production 
Class Code 
CE O 
39 Tribal 
Citizenship 
CWE O 
Conformance Statement: 
IZ-46: PID-1 (Set ID) SHALL have the literal value “1” 
PID field definitions 
See field definitions for PID under Profile Z22 above.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 263 


Chapter 13: Batch File Specifications 
QAK—Query Acknowledgement Segment 
12-6 Segment 
Table 12-7 Query Acknowledgement Segment 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
set 
Comment 
1 Query Tag ST R [1..1] 32 
2 Query 
Response 
Status 
ID RE [0..1] 
3 Message 
Query Name 
CE R [1..1] 
4 Hit Count NM O [0..1] 
5 This payload NM O [0..1] 
6 Hits remaining NM O [0..1] 
QAK field definitions 
QAK-1 Query Tag (ST) 00696 
Definition: This field contains the value sent in QPD-2 (query tag) by the initiating system, and will be used to match response messages to the 
originating query. The responding system is required to echo it back as the first field in the query acknowledgement segment (QAK).  
QAK-2 Query Response Status (ID) 00708 
Definition: This field allows the responding system to return a precise response status. It is especially useful in the case where no data is found that 
matches the query parameters, but where there is also no error. It is defined with HL7 Table 0208 - Query Response Status.  
QAK-3 Message Query Name (CE) 01375 
Definition: This field contains the name of the query. This shall mirror the QPD-1 (Message Query Name) found in the query message that is being 
responded to. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 264 


Chapter 13: Batch File Specifications 
QPD Input Parameter Specification 
12-7 S Specification 
Table 12-8 QPD Input Parameter Specification 
Field 
Seq 
(Query 
ID=Z34) 
Name Key/ 
Search 
Sort LEN TYPE Usage Rep Match 
Op 
TBL Segment 
Field 
Name 
Service 
Identif
ier 
Code 
Element 
Name or 
Value 
1 MessageQue
ryName 
        CE R Z34^Request 
Complete 
Immunization 
History^CDCP
HINVS 
2 QueryTag   32 ST R       
3 PatientList    CX RE Y   PID.3  PID-3: Patient  
Identifier List 
4 PatientName    XPN RE    PID.5  PID-5: Patient 
Name 
5 PatientMothe
rMaidenNam
e 
   XPN RE    PID.6  PID-6: Mother’s 
maiden name 
6 Patient Date 
of Birth 
  26 TS_NZ RE    PID.7  PID-7: Patient 
date of birth 
7 Patient Sex   1 IS RE    PID.8  PID-8: Patient 
sex 
8 Patient 
Address 
   XAD RE    PID.11  PID-11: Patient 
Address 
9 Patient home 
phone 
   XTN RE    PID.13  PID-13: Patient 
home phone 
10 Patient 
multiple birth 
  1 ID RE    PID-24  PID-24: Patient 
multiple birth 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 265 
 


Chapter 13: Batch File Specifications 
Table 12-8 QPD Input Parameter Specification 
Field 
Seq 
(Query 
ID=Z34) 
Name Key/ 
Search 
Sort LEN TYPE Usage Rep Match 
Op 
TBL Segment 
Field 
Name 
Service 
Identif
ier 
Code 
Element 
Name or 
Value 
indicator indicator 
11 Patient birth 
order 
2 NM RE PID-25 PID-25: Patient 
birth order 
12 Client last 
updated date 
TS RE PID-33 PID-33: Patient 
last update 
date 
13 Client last 
update 
facility 
HD RE PID-34 PID-34: Patient 
last update 
faciliity 
QPD Input Parameter Field Description and Commentary 
See Field Description under QPD in Profile Z34. 
RXA-- Pharmacy/Treatment Administration Segment 
The RXA segment carries pharmacy administration data.  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 266 


Chapter 13: Batch File Specifications 
able 12-8 Pharmacy/Treatment Administration (RXA) 
Table 12-9 Pharmacy/Treatment Administration (RXA) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Comment 
1 Give Sub-ID 
Counter 
NM R [1..1] 4    
2 Administration 
Sub-ID Counter 
NM R [1..1] 4    
3 Date/Time Start 
of Administration 
TS_NZ R [1..1]    This segment may be used in 
cases where a vaccine has not 
been administered. For 
instance a patient may refuse a 
vaccination or the sending 
system may be forecasting a 
next dose due. See notes 
below for guidance on the 
relevant date to include here. 
4 Date/Time End 
of Administration 
TS O [0..1]    See not below  
5 Administered 
Code 
CE R [1..1]   CVX  Support for CVX code is 
strongly preferred. Local IG 
may identify NDC or CPT as 
acceptable alternative code 
sets. 
6 Administered 
Amount 
NM R [1..1] 20    
7 Administered 
Units 
CE C(R/O) [0..1]  If Administered Amount is not 
valued “999”  
UCUM The preferred units of measure 
for this is “mL”. 
8 Administered 
Dosage Form 
CE O [0..1]     
9 Administration varies C(R/O) [0..*]  If RXA-20 is valued “CP” or NIP 0001 If this field is used for a notes 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 267 
 


Chapter 13: Batch File Specifications 
Table 12-9 Pharmacy/Treatment Administration (RXA) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Comment 
Notes “PA” only entry, then the data type 
shall be CE_TX otherwise the 
data type shall be CE. 
The primary use of this field it to 
convey if this immunization 
record is based on a historical 
record or was given by the 
provider recording the 
immunization. All systems 
should be able to support this 
use. Other uses of this field are 
permitted, but need to be 
specified locally. 
10 Administering 
Provider 
XCN C(RE/O) [0..1] If the first occurrence of 
RXA-9.1 is valued "00" 
and RXA-20 is valued 
"CP" or "PA" 
This is the person who gave the 
administration or the vaccinator. 
It is not the ordering clinician. 
11 Administered-at 
Location 
LA2 C(RE/O) [0..1] If the first occurrence of 
RXA-9.1 is valued "00" 
and RXA-20 is valued 
"CP" or "PA" 
This is the clinic/site where the 
vaccine was administered. 
12 Administered 
Per (Time Unit) 
ST O 
13 Administered 
Strength 
NM O 
14 Administered 
Strength Units 
CE O 
15 Substance Lot ST O [0..*] 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 268 


Chapter 13: Batch File Specifications 
Table 12-9 Pharmacy/Treatment Administration (RXA) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Comment 
Number 
16 Substance 
Expiration Date 
TS_M O [0..1]     
17 Substance 
Manufacturer 
Name 
CE C(R/O) [0..1]  If the first occurrence of 
RXA-9.1 is valued "00" 
and RXA-20 is valued 
"CP" or "PA" 
MVX  
18 Substance/Treat
ment Refusal 
Reason 
CE C(R/X) [0..*]  If the RXA-20 (Completion 
Status) is valued “RE “ 
NIP002  
19 Indication CE O      
20 Completion 
Status 
ID RE [0..1] 2  HL70322  
21 Action Code - 
RXA 
ID O [0..1] 2  HL70323  
22 System Entry 
Date/Time 
TS O      
23 Administered 
Drug Strength 
Volume 
NM O      
24 Administered 
Drug Strength 
Volume Units 
CWE O      
25 Administered 
Barcode 
Identifier 
CWE O      
26 Pharmacy Order 
Type 
ID O      
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 269 
 


Chapter 13: Batch File Specifications 
Conformance Statement:  
IZ-28: RXA-1 ( Give Sub-id counter) ) SHALL be valued “0”  Note that “0” is zero. 
IZ-29: RXA-2 (admin Sub-id) SHALL be valued “1 “ 
IZ-30: If RXA-4 (Date time of admin end ) is populated, then it SHALL be the same as Start time (RXA-3) 
IZ-31: If RXA-20 is valued "CP" or "PA" then RXA-9.1 (admin notes) SHALL be valued one of the codes listed in NIP001 in the first occurrence 
of this field and the following repetition should be empty or valued with a text notes. 
IZ-32: If the RXA-18 (Refusal Reason) is populated, RXA-20  SHALL be valued to “RE”. 
IZ-47: If RXA-20 is NOT valued "CP" or "PA" then the first occurrence of RXA-9.1 (admin notes) SHALL be empty and the following repetitions 
should be empty or valued with text notes. 
IZ-48: If RXA-20 is valued “RE” then RXA-6 shall be valued “999”. 
IZ-49: If RXA-5.3 is valued “998” then RXA-6 shall be valued “999”. 
IZ-50: If the first instance of RXA-9.1 is not valued “00” then RXA-6 (administered amount) SHALL be valued “999” 
RXA field definitions 
See RXA  field definitions in the Z22 profile. 
RXR-- Pharmacy/Treatment Route Segment 
The Pharmacy/Treatment Route segment contains the alternative combination of route, site, administration device, and administration method that are 
prescribed as they apply to a particular order.  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 270 


Chapter 13: Batch File Specifications 
Table 12-9 Pharmacy/Treatment Route (RXR) 
Table 12-10 Pharmacy/Treatment Route (RXR) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional 
Predicate 
Value 
Set 
Constraint 
1 Route CE R [1..1]   NCIT  
2 Administration 
Site 
CWE RE [0..1]   HL70163  
3 Administration 
Device 
CE O      
4 Administration 
Method 
CWE O      
5 Routing 
Instruction 
CE O      
6 Administration 
Site Modifier 
CWE O      
 
RXR field definitions 
See RXR field definitions in Profile Z22.
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 271 
 


Chapter 13: Batch File Specifications 
13.Batch File Specifications 
Sending Messages in a Batch 
Systems may choose to send messages in batches. A batch begins with a batch header statement (BHS) and ends with a Batch Trailer Segment. Batches may in 
turn be batched into files of batches using File Header Statement and File Trailer statement. If a system is sending a single batch, the FHS/FTS is not necessary. A 
stream of messages may be sent without use of either BHS or FHS. 
The generic layout of a batch message is as follows: 
BHS 
VXU 
VXU 
… 
BTS 
Similarly, a file of batches is laid out as follows: 
FHS 
BHS 
VXU 
VXU 
… 
BTS 
BHS 
VXU 
… 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 272 


Chapter 13: Batch File Specifications 
BTS 
… 
FTS 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 273 
 


Chapter 13: Batch File Specifications 
BHS—Batch Header Segment 
Table 13-1 Batch Header Segment (BHS) 
Table 13-1 Batch Header Segment (BHS) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
set 
Description/Comment 
1 Batch Field 
Separator 
ST R [1..1] 1,,1 | 
2 Batch 
Encoding 
Characters 
ST R [1..1] 4..4 ^~\& 
3 Batch Sending 
Application 
HD O 
4 Batch Sending 
Facility 
HD O 
5 Batch 
Receiving 
Application 
HD O 
6 Batch 
Receiving 
Facility 
HD O 
7 Batch Creation 
Date/Time 
TS O 
8 Batch Security ST O 
9 Batch 
Name/ID/Type 
ST O 
10 Batch 
Comment 
ST O 
11 Batch Control 
ID 
ST O 
12 Reference ST O 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 274 


Chapter 13: Batch File Specifications 
Table 13-1 Batch Header Segment (BHS) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
set 
Description/Comment 
Batch Control 
ID 
Conformance Statement 
IZ-8: BHS.1 (Batch Field Separator)  SHALL be |  
IZ-9: BHS.2 (Batch Encoding Characters)  SHALL be ^~\& 
BHS field definitions 
BHS-1 Batch Field Separator (ST) 00081 
Definition: This field contains the separator between the segment ID and the first real field, BHS-2-batch encoding characters. As such it serves as the 
separator and defines the character to be used as a separator for the rest of the message. The required value is |,(ASCII 124). Note that this field is 
different from other fields and immediately follows the Segment name code.  
BHS|        
       ⇑ 
separator 
BHS-2 Batch Encoding Characters (ST) 00082 
Definition: This field contains the four characters in the following order: the component separator, repetition separator, escape characters, and 
subcomponent separator. The required values are ^~\& (ASCII 94, 126, 92, and 38, respectively).  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 275 


Chapter 13: Batch File Specifications 
BTS—Batch Trailer Segment 
Table 13-2 Batch Trailer Segment (BTS) 
Table 13-2 Batch Trailer Segment (BTS) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Description/Comment 
1 Batch 
Message 
Count 
ST O      
2 Batch 
Comment 
ST O      
3 Batch Totals NM O      
BTS field definitions 
BTS-1 - BTS-3 Not anticipated to be used for immunization messages. 
 
Example: BTS|| 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 276 
 


Chapter 13: Batch File Specifications 
FHS—File Header Segment 
Table 13-3 File Header Segment (FHS) 
Table 13-3 File Header Segment (FHS) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
Set 
Description/Comment 
1 File Field 
Separator 
ST R [1..1] 1..1 | 
2 File Encoding 
Characters 
ST R [1..1] 4..4 ^~\& 
3 File Sending 
Application 
 HD O 
4 File Sending 
Facility 
 HD O 
5 File Receiving 
Application 
 HD O 
6 File Receiving 
Facility 
 HD O 
7 File Creation 
Date/Time 
TS O 
8 File Security ST O 
9 File Name/ID ST O 
10 File Header 
Comment 
ST O 
11 File Control ID ST O 
12 Reference File 
Control ID 
ST O 
Conformance Statement: 
IZ-10: The FSH.1 (File Field Separator) SHALL be | 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 277 


Chapter 13: Batch File Specifications 
IZ-11: The FSH.2 (File Encoding Characters) SHALL be ^~\& 
FHS field definitions 
FHS-1 File Field Separator (ST) 00067 
Definition: This field has the same definition as the corresponding field in the MSH segment. The value shall be |. 
Note that this field is different from other fields and follows the segment name code immediately. 
FHS| 
FHS-2 File Encoding Characters (ST) 00068 
Definition: This field has the same definition as the corresponding field in the MSH segment. The value shall be ^~\& 
FTS—File Trailer Segment 
Table 13-4 File Trailer Segment (FTS) 
Table 13-4 File Trailer Segment (FTS) 
SEQ ELEMENT 
NAME 
Data 
Type 
Usage Cardinality LEN Conditional Predicate Value 
set 
Description/Comment 
1 File Batch 
Count 
NM O 
2 File Trailer 
Comment 
ST O 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 278 


Change History 
Change History Details 
Release 1.1 
Release 1.1 Changes 
Release 1.1 Changes 
Location Change 
Page 100 
PD1-4 Primary Provider.  Corrected data type to XCN. 
Page 46 
Corrected usage definitions for EI-Entity Identifier data type. 
Page 124 
Clarified default action if RXA-21 Action Code is not populated. 
Appendix A-1 
Added copyright note on LOINC codes. Added reference to SNOMED.  
Added reference to PHIN VADS 
Appendix A-2 and A-3 
Removed links to dead web pages on Race and Ethnicity. 
Appendix A-33 
Added NCIT to codes 
Appendix A-2 
Corrected Value set OID for race. 
Appendix A-30 
Corrected code for Allergy to protein of rodent origin. 
Appendix A-30 
Removed duplicate row VXC28 
Appendix A-36 
Corrected LOINC code for contraindication 
Release 1.2 
Release 1.2 Changes 
Release 1.2 Changes 
Location Change 
Appendix A-18 
Added example of response to query that found too many candidates. 
Appendix A-multiple 
Corrected use of profile identifiers in the responses.  Changed  HL70396 
to CDCPHIVS. 
Chapter 6, page 129 
Corrected cardinality of GT1 and Insurance segment group. 
Chapter 5, p72 
Corrected spelling of BHS 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 1 


Change History 
Release 1.2 Changes 
Location Change 
Chapter 5, p72 and throughout Guide 
Changed “null” to “empty” in data types, fields and segments.  In some 
cases deleted contents of cell 
Chapter 7, p 140 
Corrected cardinality  
Chapter 7, page 156 
Removed extraneous RCP row in table. 
Chapter 7, page 157 
Include profile id in the text explaining Z32^CDCPHINVS  
Chapter 4, page 61 
Illustrated use of HD data type in XCN 
Appendix B, throughout 
Corrected Query name to Z34^Request Immunization 
History^CDCPHINVS 
Appendix B-15 
Corrected LOINC in example message. It was set to Reaction, but 
should be 59779-9, schedule used. 
Chapter 5, page 105 
Corrected cardinality of PID-1 
Chapter 5, various pages 
Corrected cardinality of fields with usage of X (not supported) from [0..1] 
to [0..0] 
Chapter 5, page 108 
Corrected data type of PID-39 Tribal citizenship from CE to CWE 
Chapter 5, page 101 
Corrected data types for all PD1 fields. 
Chapter 5, page 91 
Corrected usage of OBX-1 
Chapter 4, page 50 
Added reference to User defined tables 0361-0363 
Chapter 5, page 82-3 
Clarified usage of tables 0361 and 0362 
Chapter 5, page 96 
Corrected ORC-3 usage 
Appendix A, Table 0363 
Added table with value set 
Release 1.3 
Release 1.3 Changes 
Release 1.3 Changes 
Location Change 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 2 
 


Change History 
Release 1.3 Changes 
Location Change 
Chapter 2, Use Case 9 – report error 
Added clarifying statement. 
Chapter 3, usage guidance 
Clarified RE and CE usage.  These are SHOULD rather than SHALL 
Chapter 4, HD data type and 
Appendix A Changed references to Table HL70300 to the more specific HL70361-
HL70363 
Chapter 4, FT data  type 
FT data type added 
Chapter 5, MSH-11 
Clarify use of field and attendant table 
Chapter 5, PID 14 
Correct cardinality 
Chapter 5, PID-15 note box 
Clarified difference between V2.3.1 and V2.5.1 IG value sets. 
Chapter 5, RXA-10 
Added clarifying statement. 
Chapter 5, RXA 20 
Clarified definition and codes 
Chapter 5, NK1-20 and PID-15 
Corrected table reference for language to ISO 0639 
Appendix A, User-defined Table 0064 
Updated to accommodate change in eligibility coding. 
Appendix A, Table NIP 003 
Added new LOINC for eligibility 
Appendix A, 
Added new value set for client risk factors to be used for priority groups. 
Appendix B, immunization history 
table Added new concepts 
Appendix B, Example VXU #2 
Added description of messaging eligibility status using OBX, per 
immunization. 
Appendix B 
Forecast examples updated to include ORC segment for each RXA 
Appendix B, Forecasting messages 
Added new examples and improved existing examples 
Chapter  5, VXU table 
Changed PV1 to optional 
Chapter 5, page 112 
Note on changing PV1 to optional 
Chapter 5, page 115 
Note on changing PV1 to optional 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 3 


Change History 
Release 1.3 Changes 
Location Change 
Chapter 6, page 131 
Clarified cardinality and usage of Order group 
Chapter 7, page 142 
Changed cardinality and usage of PV1 in response grammar table 
Appendix A, table 0064 
Updated notes and definitions to reflect MIROW guidance 
Appendix B, Example VXU #2 
Extensive rewrite to reflect MIROW guidance 
Appendix B, Example VXU #2 
Removed guidance on use of PV1 for eligibility status 
Appendix A and Appendix B 
Removed references to messaging funding source. 
Chapter 7, response grammar 
Corrected usage of IN1 from RE to O. 
Appendix A, Table 0064 
And examples using VFC codes 
throughout Appendix B 
Corrected VFC codes. Deprecated V06 and V08 
Release 1.4 
Release 1.4. Changes 
Release 1.4 Changes 
Location 
Change 
Chapter 2 
Added documentation of core data elements 
XAD, table 4-23 
Specified use of US Postal Service state codes 
RXA, table 5-20, 
Specified use of NIP002 for RXA-18 
RXA-3 text, page 123 
Clarified appropriate date for forecast. 
Appendix A 
Set table title to be a header, so it is included in Table of Contents 
Table 0064-Financial Class 
Clarified use of V07 
Table 0289-County/Parish, page A-21 
Corrected codes for county. 
CDC-defined table NIP-003 
Added new observation code for document type 
Evidence of Immunity-IIS 
Added new codes for evidence of immunity 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 4 


Change History 
Release 1.4 Changes 
Location 
Change 
VIS Document Type-IIS 
Added new table for identifying VIS document types 
Appendix B-core data elements 
Updated table and added more data concepts. 
Appendix B- VXU #2 example 
Added guidance to incorporate guidance on eligibility from MIROW 
work. 
Appendix B-VXU #7 example 
Added guidance on using the new barcodes for VIS document type. 
Through out document 
Added conformance statements for key elements 
Chapter 3 
Modified usage descriptions to separate sender and receiver 
responsibilities. 
Throughout document 
Changed C and CE usage to use the pre-adopted Version 2.7.1 
conditional usage 
Throughout document 
Reformatted the tables for elements to support changes to Conditional 
usage 
Appendix B 
Restored table for indicating funding source for an immunization.  
Appendix A 
Added new table for VIS barcode, VIS vaccines and Eligibility 
Observation Method 
 
Release 1.5 
Release 1.5 Changes 
Release 1.5 Changes 
Location Change 
 Reorganized IG, creating a separate profile for VXU, ACK and queries 
ACK Z23 profile Set MSH-15 and MSH-16 to “NE” 
Appendix B Updated Message examples to align with RXA-21 changes and correct 
some RXA-20 positions. 
CE data type Changed CE.4 usage to O 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 5 
 


Change History 
Release 1.5 Changes 
Location Change 
Chapter 2, Preadoption of V 2.7.1 Dropped 2.7.1 guidance on field length. 
Chapter 3, HL7 definitions Added Segment Groups definition. 
CWE data type Changed CWE.4 usage to O (optional) 
ERL (Error Location) Data type Clarified how to count segment count when reporting error. 
ERL data type Clarified usage of subcomponents to harmonize across 
implementations. 
Ethnicity codes Removed reference to HL70189 code table and associated ethnicity 
codes (H,N,U) 
HD data type Added note on use of subcomponent separator when HD data type is a 
subcomponent of another data type. 
IN1 segment Added constrained field level specifications.  IN1 still optional segment. 
Insurance Group Optional, and not repeating 
IZ-14 removed 
IZ-16 Removed 
IZ-23 Updated to match in Addendum 
IZ-24 Updated to match in Addendum 
IZ-34 Corrected to match addendum 
MSH-15 
Usage is required (R) 
Z32,Z42,Z23,Z31 and Z33 set to “NE”, 
Z22,Z34 and Z44 set to “ER” 
MSH-16 
Usage is required (R) 
Z32,Z42,Z23,Z31 and Z33 set to “NE”, 
Z22,Z34 and Z44 set to “AL” 
MSH-21 
Applied conditional predicates to each MSH segment requiring the 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 6 


Change History 
Release 1.5 Changes 
Location Change 
appropriate profile ID. 
MSH-22, MSH-23 Preadopted MSH22 and MSH 23 from V 2.7.1 
MSH-7 (message date) Changed data type to TS_Z, requiring precision to second and time 
zone. 
MSH-7 examples Corrected all MSH-7 message examples to be TS_Z data type 
NIP003 
Added 59777-3, latest date to administer 
And 59778-1, date overdue 
And 59778-1, reason code 
OBX Correct typo from cdcgi1vis to cdcgs1vis 
OBX Application level conformance 
statements  Table 5-15 Clarified existing statements and added statements. 
OBX-1 Clarified numbering across segment.  Numbering is now continuous. 
Corrected example messages 
OBX-14 Changed data type to TS_NZ 
OBX-4 Conformance statement requires positive integer. 
ORC-12 Changed usage to C(RE/O) 
ORC-17 Changed usage to RE 
ORC-3 Conformance added 
PID, IZ-26 removed 
PID-1 for all profiles. Changed usage to R and added conformance statement. 
PID-29 Corrected conditional predicate 
PID-6 , Mothers maiden name Changed to XPN_M 
QUERY /RESPONSE  MSH-7 Changed data type to TS_Z 
QUERY /RESPONSE  PID-7 Changed Data type to TS_NZ 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 7 


Change History 
Release 1.5 Changes 
Location Change 
RXA conformance statement 
Added conformance statement: IZ-xx: If RXA-20 is NOT valued 
"CP" or "PA" then the first occurrence of RXA-9.1 (admin 
notes) SHALL be empty and the following repetitions should 
be empty or valued with text notes. 
 
RXA, IZ-34 removed 
RXA, IZ-37, IZ-38 Removed 
RXA-10 Updated conditional predicate 
RXA-11 Updated conditional predicate 
RXA-15 Updated conditional predicate and changed usage to C(R/0). 
RXA-16 Updated conditional predicate 
RXA-17 Updated conditional predicate and changed usage to C(R/0) 
RXA-21 Changed usage to C(R/O).  Deleted guidance indicating that an empty 
field meant “A”. 
RXA-3 Changed data type to TS_NZ 
RXA-4 Changed usage to O (optional). 
RXA-6 Conformance statement requiring “999” for non-administered doses. 
Table 2-1 Added new goal, send evaluated history and forecast. 
Table 2-1 Updated Use Cases. Collapse “send” and “receive” use cases into one 
use case. Added use case for request evaluated history and forecast. 
Table 2-1 Updated all use case narratives 
Table 6-2 Corrected Patient visit group and PV1 
TS_M data type Constrained version of the TS data type, requiring precision to the 
month and permitting to the day. 
TS_NZ data type Created a constrained version of the TS data type, requiring precision 
to the day. 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 8 
 


Change History 
Release 1.5 Changes 
Location Change 
TS_Z data type Created a constrained version of the TS data type, requiring precision 
to the second and time zone. 
XPN_M data type Added XPN_M to data types 
XTN data type Corrected typos in conditional predicates. 
Z32 RXA-21 Set RXA-21 (Action code) to O 
Z34 Message level definition Set Changed ORC to O 
Appendix B, VXU Example #9 Clarified when and how to send 2 lots number for one immunization 
Profile Z32-Return Complete history Loosened conditional predicates and removed conformance statements 
for OBX segment 
Profile Z42-Return Evaluated History 
and Forecast 
Loosened conditional predicates and removed conformance statements 
for OBX segment 
Profile Z42-Return Evaluated History 
and Forecast 
Loosened requirements and removed conditional predicates for ORC 
segment 
Profile Z42-Return Evaluated History 
and Forecast Loosened requirements and removed conditional predicates for PID 
Profile Z42-Return Evaluated History 
and Forecast Loosened requirements and removed conditional predicates for RXA 
CWE-1 Changed from RE to R 
MSH-21 for all profiles Change cardinality to [1..*] 
Appendix B, Example #4 Corrected Reaction observation. Removed Reaction to Current 
Immunization 
Table 0361, Table 0362 and Table 
0363 Added clarifying language 
Appendix B, VXU Example #9 
Clarified when and how to send 2 lots number for one immunization 
MSH-3, MSH-4, MSH-5, MSH-6 Modified field definitions to clarify that values in tables 0361, 0362 and 
0363 are defined locally. 
Table 0086 Values recorded 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 9 


Change History 
Release 1.5 Changes 
Location Change 
Value Set-Evidence of Immunity Deprecated existing table and created 2 new tables. One for history of 
disease and one for serological evidence of immunity.  
Observation Identifier table Added LOINC for Serological Evidence of Immunity 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 10 


Change History 
APPENDIX A:  
Code Tables 
Table A-1 Appendix A Revision History 
Revision History 
Author Revision Date 
Rob Savage Release 1 5/1/2010 
Rob Savage Release 1.1 8/15/2010 
Rob Savage Release 1.2 2/15/2011 
Rob Savage Release 1.3 8/15/2011 
Rob Savage Release 1.4 8/1/2012 
Rob Savage Release 1.5 10/1/2014 
 
NOTE:  In this appendix, values are selected from standard code sets where available.  The Value Sets 
are maintained in the PHIN VADS for use in Public Health. The main purpose of PHIN VADS is to 
distribute vocabulary subsets needed in Public Health. The latest version of value sets referenced in this 
Implementation Guide can be obtained from PHIN VADS at (http://phinvads.cdc.gov ).  Search using 
keyword “immunization”. 
Note that the PHIN VADS value sets are the source of truth for use in Meaningful Use testing. 
This material contains content from LOINC® (http://loinc.org). The LOINC table and LOINC 
codes are copyright © 1995-2010, Regenstrief Institute, Inc. and the Logical Observation Identifiers 
Names and Codes (LOINC) Committee. 
This material contains content from SNOMED CT. SNOMED CT (Systematized Nomenclature of 
Medicine--Clinical Terms) is a comprehensive clinical terminology, originally created by the College 
of American Pathologists (CAP) and, as of April 2007, owned, maintained, and distributed by the 
International Health Terminology Standards Development Organization (IHTSDO), a non-for-profit 
association in Denmark. The CAP continues to support SNOMED CT operations under contract to 
the IHTSDO and provides SNOMED-related products and services as a licensee of the terminology. 
User-defined Table 0001 - Sex  
This code reflects the self reported gender. Use in PID-8, NK1-15.  These codes are pre-adopted from HL7 
Version 3 Administrative Gender. 
Value set OID:  2.16.840.1.113883.1.11.1 
Value Description Definition 
F Female Person reports that she is female. 
M Male Person reports that he is male. 
U Unknown/undifferentiated No assertion Is made about the gender of the 
person. 
 
 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 1 
 

http://phinvads.cdc.gov/

http://loinc.org/


Change History 
HL7-defined Table 0003 - Event type  
This code indicates the trigger event. Refer to Chapter 3, Version 2.5.1 for further information on HL7 
event triggers. 
Each profile identifies the appropriate value for Event Type in a conformance statement. 
User-defined Table 0004 - Patient class 
Use in PV1-2. 
This code categorizes the patient in the current event. The only value supported is R for recurring patient.  
For a current list of HL7 values please reference the HL7 version 2.5.1 documents. 
User-defined Table 0005 - Race 
 These values are consistent with the OMB Notice of revised categories for collection of race and ethnicity 
data—the combined format.  Use in PID-10, NK1-35. 
This code represents the client’s self-reported race. 
https://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.113883.3.2074.1.1.3 
Value set OID: 2.16.840.1.113883.3.2074.1.1.3 
US race codes Description 
1002-5 American Indian or Alaska Native 
2028-9 Asian 
2076-8 Native Hawaiian or Other Pacific Islander 
2054-5 Black or African-American 
2106-3 White 
2131-1 Other Race 
 Unknown/undetermined

HL7-defined Table 0008 – Acknowledgment code

Use in MSA-1.

This code indicates the type of acknowledgement expected.

Value Description Comment

AA Original mode: Application Accept

Enhanced mode: Application acknowledgment: Accept

Message was accepted without

error.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 2 
https://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.113883.3.2074.1.1.3
Change History

Value Description Comment

AE Original mode: Application Error

Enhanced mode: Application acknowledgment: Error

Message was processed and

errors are being reported.41

AR Original mode: Application Reject

Enhanced mode: Application acknowledgment: Reject

Message was rejected because

one of the following occurred:

• Unsupported message type

• Unsupported event code

• Unsupported processing ID

• Unable to process for

reasons unrelated for

format or content

CA Enhanced mode: Accept acknowledgment: Commit Accept Not supported in this

Implementation Guide

CE Enhanced mode: Accept acknowledgment: Commit Error

CR Enhanced mode: Accept acknowledgment: Commit Reject

User-defined Table 0010 – Physician ID

Use in all XCN data types; including PV1-7,8,9,17, RXA-10.

Each registry should establish a system of coding its reporting physicians.  The National Provider Identifier

(NPI) adopted for the HIPAA legislation may be used for this purpose.

HL7-defined Table 0061 – Check digit scheme

Use in all CX data types; including PID-2,3,4,18,21.

Value Description

M10 Mod 10 algorithm

M11 Mod 11 algorithm

ISO ISO 7064: 1983

NPI Check digit algorithm in the US National Provider Identifier

User-defined Table 0063 – Relationship

  Use in NK1-3, IN1-17

41 AE is sent whenever an error is detected. This may range from data that are ignored because they are not wanted to rejection of the

entire message.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 3 
Change History

Value Description

BRO Brother

CGV Care giver

CHD Child

FCH Foster child

FTH Father

GRD Guardian

GRP Grandparent

MTH Mother

OTH Other

PAR Parent

SCH Stepchild

SEL Self

SIB Sibling

SIS Sister

SPO Spouse

User-defined Table 0064 – Financial class

Use in OBX-5 for client eligibility for a funding program at the dose administered level.

Financial class references a client’s eligibility status at the time of vaccine administration. It is the

eligibility of the client for the vaccine administered. The values in this table relate to eligibility for the

Vaccine for Children (VFC) program.

Local implementations may define and document local codes. Each state immunization program may have

locally specified funding programs for immunizations. In order to assure that each is unique across states,

codes should be created that begin with the grantee assigning authority code from table 0363 in the

Implementation Guide for Immunization Messaging, release 1.3. This would be followed by sequential

number, left padded to a length of 2. For example if Alaska had a funding program, they would create a

code of AKA01 for the first program. It is incumbent on the state or other jurisdiction to clearly describe

the requirements that qualify a person for that funding program.  For instance if the hypothetical funding

program in Alaska covered people who were too old for VFC program but would otherwise qualify because

they were Medicaid eligible, then they would define the code as:

“Client is currently on MEDICAID and is older than 19 years old.”

Note that funding source for a specific immunization is different from client eligibility for funding program

(Financial Class).

Code Label Definition

V01 Not VFC eligible Client does not qualify for VFC because they do not have one

of the statuses below.  (V02-V05)

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 4 
Change History

Code Label Definition

V02 VFC eligible-

Medicaid/Medicaid

Managed Care

Client is currently on Medicaid or Medicaid managed care and

< 19 years old and the vaccine administered is eligible for VFC 
funding. 
V03 VFC eligible- Uninsured Client does not have private insurance coverage and < 19 years 
old and the vaccine administered is eligible for VFC funding. 
V04 VFC eligible- American 
Indian/Alaskan Native 
Client is a member of a federally recognized tribe and < 19 
years old and the vaccine administered is eligible for VFC 
funding. 
V05 VFC eligible-Federally 
Qualified Health Center 
Patient (under-insured) 
Client has insurance, but insurance does not cover vaccines, 
limits the vaccines covered, or caps vaccine coverage at a 
certain amount and so client is eligible for VFC coverage at a 
Federally Qualified Health Center.  The client must be 
receiving the immunizations at the FQHC or a FQHC 
designated clinic and < 19 years old and the vaccine 
administered is eligible for VFC funding. 
V06 Deprecated [VFC 
eligible- State specific 
eligibility (e.g. S-CHIP 
plan)] 
Do not use this code. State specific funding should either use 
V07 or a state generated code. 
V07 Local-specific eligibility Client is eligible for state supplied vaccine based on local 
specific rules and the vaccine administered is eligible for state- 
funding.  It should only be used if the state has not published 
local codes for these programs. 
V08 Deprecated [Not VFC 
eligible-underinsured] 
Do not use this code. The MIROW effort determined that 
persons in this situation are V01, not VFC eligible. It is not 
necessary to differentiate this sub-class of Not VFC eligible. 
HL7-defined Table 0076 - Message type 
Only selected values listed. Use in MSH-9, first component. 
Only these values are expected. 
Value Description Usage in this 
guide 
ACK General acknowledgment Supported 
ADT ADT message Supported 
QBP Query by Parameter Supported 
RSP Response to Query by parameter Supported 
VXU Unsolicited vaccination record update Supported 
HL7-defined Table 0078 - Abnormal flags 
Use in OBX-8.  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 5 


Change History 
Fields using this code set are expected to be empty.  For a current list of HL7 values please reference the 
HL7 version 2.5.1 documents. 
HL7-defined Table 0085 - Observation result status codes 
interpretation 
 Use in OBX-11. 
Fields using this value  set are constrained  to F for Final.  For a current list of HL7 values please reference 
the HL7 version 2.5.1 documents. 
User Defined Table 0086 - Plan Type ID 
The values in this value set are drawn from the Source of Payment Typology 
(PHVS_SourceOfPaymentTypology_PHDSC). New values may be added from that value set. 
Value Description Usage in this guide 
5 Private Insurance 
2 Medicaid 
1 Medicare 
81 Self pay 
HL7-defined Table 0091 - Query priority  
Fields using this code set are expected to be I or empty, which indicates Immediate processing is expected.  
For a current list of HL7 values please reference the HL7 version 2.5.1 documents. 
HL7-defined Table 0102 - Delayed acknowledgment type 
 Use in MSA-5. 
Fields using this code set are expected to be empty.  For a current list of HL7 values please reference the 
HL7 version 2.5.1 documents. 
HL7-defined Table 0103 - Processing ID 
Use in MSH-11. 
Value Description 
D Debugging 
P Production 
T Training 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 6 


Change History 
HL7-defined Table 0104 - Version ID 
 Use in MSH-12. Only these values are expected. 
Value Description 
2.5.1 Release 2.5.1  April 2007 
HL7-defined Table 0119 - Order Control Codes 
Use in ORC-1. 
Value Description Usage 
OK Order accepted & OK Not supported 
RE Observations to follow Supported 
HL7-defined Table 0125 – Value Type 
Constrained for this Implementation Guide. 
Value Description 
CE Coded element 
CE_TX Text only CE data type 
CQ Composite Quantity with Units 
CWE Coded with Exceptions 
CX Extended Composite Id with 
Check digit 
DT Date 
DT_D Date with precision to day 
DTM Date/Time 
EI Entity Identifier 
ERL Error Location 
FN Family Name 
FT Formatted text 
HD Hierarchic Designator 
ID Coded Values for HL7 Tables 
IS Coded value for User-Defined 
Tables 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 7 


Change History 
Value Description 
LA2 Location with address variation 
2 
MSG Message Type 
NM Numeric 
PT Processing Type 
SAD Street Address 
SI Sequence ID 
ST String 
TS Time Stamp 
TS_M Time Stamp with optional 
precision to the day and no time 
zone 
TS_NZ Time Stamp with precision to 
the day and no time zone 
TS_Z Time Stamp requiring time zone 
VID Version Identifier 
XAD Extended Address 
XCN Extended Composite ID Number 
and Name for Persons 
XON Extended Name and Id Number 
for Organizations 
XPN Extended Person Name 
XTN Extended telephone number 
HL7-defined Table 0126 - Quantity limited request 
Use in RCP-2. 
Fields using this code set are expected to be set to RD for records.  For a current list of HL7 values please 
reference the HL7 version 2.5.1 documents. 
HL7-defined Table 0136 - Yes/No indicator 
Use in PID-24,30; PD1-12 
Value Description 
Y Yes 
N No 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 8 


Change History 
 
In fields that may be empty, such as PD1-12 no value should be entered if the value is not Y or N.  In HL7 
“” means remove the previous value.  If the field is empty, then it means do nothing to existing values. 
Note on Null and Empty in HL7 
Note that in the previous Implementation Guide, the undetermined state was signified by “” (HL7 
null). This has a specific meaning in HL7. It means “change the state in the receiving system to 
null”. The empty field means that the existing state should remain unchanged in the receiving 
system. 
Value in Field Meaning 
“” 
|””| 
Nullify the value recorded in the receiving system data base. 


||

Make no changes to the record in the receiving data base. The sending

system has no information on this field.

HL7-defined Table 0155 – Accept/Application acknowledgment

conditions

Use in MSH-15 and 16

Value Description

AL Always

NE Never

ER Error/Reject conditions only

SU Successful completion only

NCI Thesaurus (NCIT) – Route of Administration

HL7-defined Table 0162 – Route of administration  
Note that HITSP has specified the use of the FDA route of administration.  The following table

maps these to the HL7 table 0162 values. NCIT values should be used. 
FDA

NCI

Thesaurus

(NCIT)

HL7-0162 Description Definition

C38238 
ID Intradermal within or introduced between the layers of

the skin

C28161 IM Intramuscular within or into the substance of a muscle 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 9 
Change History

FDA

NCI

Thesaurus

(NCIT)

HL7-0162 Description Definition

C38284 NS Nasal Given by nose

IN Intranasal {Do not use this older code}

C38276 IV Intravenous administered into a vein

C38288 PO Oral administered by mouth

OTH Other/Miscellaneous

C38676 Percutaneous made, done, or effected through the skin.

C38299 SC Subcutaneous Under the skin or between skin and muscles.

C38305 TD Transdermal describes something, especially a drug, that

is introduced into the body through the skin

Example

|C28161^Intramuscular^NCIT|

HL7-defined Table 0163 – Administrative site

Only selected values listed. Use in RXR-2. Only these values are expected.

HL7 0163 Description

LT Left Thigh

LA Left Arm

LD Left Deltoid

LG Left Gluteous Medius

LVL Left Vastus Lateralis

LLFA Left Lower Forearm

RA Right Arm

RT Right Thigh

RVL Right Vastus Lateralis

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 10 
Change History

HL7 0163 Description

RG Right Gluteous Medius

RD Right Deltoid

RLFA Right Lower Forearm

CDCREC – Ethnic Group

User-defined Table 0189

Table 0189 values should not be used.  The codes from the CDCREC value set are the correct ones to use.

Legacy systems may still send HL70189, so receivers should be prepared to accept.

The US ethnicity codes are actually from the CDCREC table. They should be identified as CDCREC.

US ethnicity codes

(CDCREC)

Description

2135-2 Hispanic or Latino

2186-5 not Hispanic or Latino

Unknown

HL7-defined Table 0190 – Address type

Use in all XAD data types; including PID-11

Value Description

C Current or temporary

P Permanent

M Mailing

B Firm/Business

O Office

H Home

N Birth (nee)

F Country of origin

L Legal address

BDL Birth delivery location [use for birth facility]

BR Residence at birth [use for residence at birth]

RH Registry home

BA Bad address

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 11 
Change History

Recording of Birth State uses the BDL, birth delivery location code.

HL7-defined Table 0200 – Name type

 Use in all XCN, XPN data types; including PID-5, 6, 9

Value Description Definition

A Alias name This is a nickname or other assumed

name.

L Legal name This a person’s official name.  It is the

primary name recorded in the IIS.

D Display name This is the preferred name displayed on a

user interface.

M Maiden name This is a woman’s name before marriage.

C Adopted name This is the name of a person after

adoption.

B Name at birth This is name recorded at birth (prior to

adoption).

P Name of partner/spouse This is the name of the partner or spouse.

U Unspecified This is a name of unspecified type.

HL7-defined Table 0201 – Telecommunication use code

Use in all XTN data types including PID-13,14.

Value Description

PRN Primary residence number

ORN Other residence number

WPN Work number

VHN Vacation home number

ASN Answering service number

EMR Emergency number

NET Network (email) address

BPN Beeper number

HL7-defined Table 0202 – Telecommunication equipment type

 Use in all XTN data types; including PID-13,14

Value Description

PH Telephone

FX Fax

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 12 
Change History

Value Description

MD Modem

CP Cellular phone

BP Beeper

Internet Internet address: Use only if telecommunication use code is NET

X.400 X.400 email address: Use only if telecommunication use code is NET

TDD Telecommunications Device for the Deaf

TTY Teletypewriter

User-defined Table 0203 – Identifier type

Values suggested by HL7; with CDC-suggested additions. Use in all CX, XCN type codes; including PID-

2,3,4,18,21 and RXA-10

Value Description Comment

AN Account number An identifier that is unique to an account.

ANON Anonymous identifier An identifier for a living subject whose real

identity is protected or suppressed

Justification: For public health reporting

purposes, anonymous identifiers are

occasionally used for protecting patient

identity in reporting certain results. For

instance, a state health department may

choose to use a scheme for generating an

anonymous identifier for reporting a patient

that has had a positive human

immunodeficiency virus antibody test.

Anonymous identifiers can be used in PID

3 by replacing the medical record number

or other non-anonymous identifier. The

assigning authority for an anonymous

identifier would be the state/local health

department.

ANC Account number Creditor Class: Financial

A more precise definition of an account

number: sometimes two distinct account

numbers must be transmitted in the same

message, one as the creditor, the other as

the debtor.

AND Account number debitor Class: Financial

A more precise definition of an account

number: sometimes two distinct account

numbers must be transmitted in the same

message, one as the creditor, the other as

the debtor.

ANT Temporary Account Number Class: Financial

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 13 
Change History

Value Description Comment

Temporary version of an Account Number.

Use Case: An ancillary system that does not

normally assign account numbers is the

first time to register a patient. This ancillary

system will generate a temporary account

number that will only be used until an

official account number is assigned.

APRN Advanced Practice Registered

Nurse number

An identifier that is unique to an advanced

practice registered nurse within the

jurisdiction of a certifying board

BA Bank Account Number Class: Financial

BC Bank Card Number Class: Financial

An identifier that is unique to a person’s

bank card. Replaces AM, DI, DS, MS, and

VS beginning in v 2.5.

BR Birth registry number

CC Cost Center number Class: Financial

Use Case: needed especially for

transmitting information about invoices.

CY County number

DDS Dentist license number An identifier that is unique to a dentist

within the jurisdiction of the licensing

board

DEA Drug Enforcement Administration

registration number

An identifier for an individual or

organization relative to controlled

substance regulation and transactions.

Use case: This is a registration number that

identifies an individual or organization

relative to controlled substance regulation

and transactions.

A DEA number has a very precise and

widely accepted meaning within the United

States. Surprisingly, the US Drug

Enforcement Administration does not

solely assign DEA numbers in the United

States. Hospitals have the authority to issue

DEA numbers to their medical residents.

These DEA numbers are based upon the

hospital’s DEA number, but the authority

rests with the hospital on the assignment to

the residents. Thus, DEA as an Identifier

Type is necessary in addition to DEA as an

Assigning Authority.

DFN Drug Furnishing or prescriptive

authority Number

An identifier issued to a health care

provider authorizing the person to write

drug orders

Use Case: A nurse practitioner has

authorization to furnish or prescribe

pharmaceutical substances; this identifier is

in component 1.

DL Driver’s license number

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 14 
Change History

Value Description Comment

DN Doctor number

DPM Podiatrist license number An identifier that is unique to a podiatrist

within the jurisdiction of the licensing

board.

DO Osteopathic License number An identifier that is unique to an osteopath

within the jurisdiction of a licensing board.

DR Donor Registration Number

EI Employee number A number that uniquely identifies an

employee to an employer.

EN Employer number

FI Facility ID

GI Guarantor internal identifier Class: Financial

GL General ledger number Class: Financial

GN Guarantor external  identifier Class: Financial

HC Health Card Number

JHN Jurisdictional health number

(Canada)

Class: Insurance

2 uses: a) UK jurisdictional CHI number;

b) Canadian provincial health card number:

IND Indigenous/Aboriginal  A number assigned to a member of an

indigenous or aboriginal group outside of

Canada.

LI Labor and industries number

LN License number

LR Local Registry ID

MA Patient Medicaid number Class: Insurance

MB Member Number An identifier for the insured of an insurance

policy (this insured always has a

subscriber), usually assigned by the

insurance carrier.

Use Case: Person is covered by an

insurance policy. This person may or may

not be the subscriber of the policy.

MC Patient’s Medicare number Class: Insurance

MCD Practitioner Medicaid number Class: Insurance

MCN Microchip Number

MCR Practitioner Medicare number Class: Insurance

MD Medical License number An identifier that is unique to a medical

doctor within the jurisdiction of a licensing

board.

Use Case: These license numbers are

sometimes used as identifiers. In some

states, the same authority issues all three

identifiers, e.g., medical, osteopathic, and

physician assistant licenses all issued by

one state medical board. For this case, the

CX data type requires distinct identifier

types to accurately interpret component 1.

Additionally, the distinction among these

license types is critical in most health care 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 15 
Change History

Value Description Comment

settings (this is not to convey full licensing

information, which requires a segment to

support all related attributes).

MI Military ID number A number assigned to an individual who

has had military duty, but is not currently

on active duty. The number is assigned by

the DOD or Veterans’ Affairs (VA).

MR Medical record number An identifier that is unique to a patient

within a set of medical records, not

necessarily unique within an application.

MRT Temporary Medical Record

Number

Temporary version of a Medical Record

Number

Use Case: An ancillary system that does not

normally assign medical record numbers is

the first time to register a patient. This

ancillary system will generate a temporary

medical record number that will only be

used until an official medical record

number is assigned.

NE National employer identifier In the US, the Assigning Authority for this

value is typically CMS, but it may be used

by all providers and insurance companies in

HIPAA related transactions.

NH National Health Plan Identifier Class: Insurance

Used for the UK NHS national identifier.

In the US, the Assigning Authority for this

value is typically CMS, but it may be used

by all providers and insurance companies in

HIPAA related transactions.

NI National unique individual

identifier

Class: Insurance

In the US, the Assigning Authority for this

value is typically CMS, but it may be used

by all providers and insurance companies in

HIPAA related transactions.

NII National Insurance Organization

Identifier

Class: Insurance

In Germany a national identifier for an

insurance company. It is printed on the

insurance card (health card). It is not to be

confused with the health card number itself.

NIIP National Insurance Payor Identifier

(Payor)

Class: Insurance

Use case: a subdivision issues the card with

their identifier, but the main division is

going to pay the invoices.

NNxxx National Person Identifier where

the xxx is the ISO table 3166 3-

character (alphabetic) country code

NP Nurse practitioner number An identifier that is unique to a nurse

practitioner within the jurisdiction of a

certifying board.

NPI National provider identifier Class: Insurance

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 16 
Change History

Value Description Comment

In the US, the Assigning Authority for this

value is typically CMS, but it may be used

by all providers and insurance companies in

HIPAA related transactions.

OD Optometrist license number A number that is unique to an individual

optometrist within the jurisdiction of the

licensing board.

PA Physician Assistant number An identifier that is unique to a physician

assistant within the jurisdiction of a

licensing board

PCN Penitentiary/correctional institution

Number

A number assigned to individual who is

incarcerated.

PE Living Subject Enterprise Number An identifier that is unique to a living

subject within an enterprise (as identified

by the Assigning Authority).

PEN Pension Number

PI Patient internal identifier A number that is unique to a patient within

an Assigning Authority.

PN Person number A number that is unique to a living subject

within an Assigning Authority.

PNT Temporary Living Subject Number Temporary version of a Lining Subject

Number.

PPN Passport number A unique number assigned to the document

affirming that a person is a citizen of the

country. In the US this number is issued

only by the State Department.

PRC Permanent Resident Card Number

PRN Provider number A number that is unique to an individual

provider, a provider group or an

organization within an Assigning Authority.

Use case: This allows PRN to represent

either an individual (a nurse) or a

group/organization (orthopedic surgery

team).

PT Patient external identifier

QA QA number

RI Resource identifier A generalized resource identifier.

Use Case: An identifier type is needed to

accommodate what are commonly known

as resources. The resources can include

human (e.g. a respiratory therapist), non-

human (e.g., a companion animal),

inanimate object (e.g., an exam room),

organization (e.g., diabetic education class)

or any other physical or logical entity.

RPH Pharmacist license number An identifier that is unique to a pharmacist

within the jurisdiction of the licensing

board.

RN Registered Nurse Number An identifier that is unique to a registered

nurse within the jurisdiction of the

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 17 
Change History

Value Description Comment

licensing board.

RR Railroad Retirement number

RRI Regional registry ID

SL State license

SN Subscriber Number Class: Insurance

An identifier for a subscriber of an

insurance policy which is unique for, and

usually assigned by, the insurance carrier.

Use Case: A person is the subscriber of an

insurance policy. The person’s family may

be plan members, but are not the subscriber.

SR State registry ID

SS Social Security number

TAX Tax ID number

U Unspecified identifier

UPIN Medicare/CMS (formerly HCFA)’s

Universal Physician Identification

numbers

Class: Insurance

VN Visit number

WC WIC identifier

WCN Workers’ Comp Number

XX Organization identifier

User-defined Table 0204 – Organizational name type

Values suggested by HL7 Use in all XON data types

Value Description

L Legal name

D Display name

HL7-defined Table 0207 – Processing mode

Use in MSH-11

Fields using this code set are expected to be empty.  For a current list of HL7 values please reference the

HL7 version 2.5.1 documents.

User-defined Table 0208 – Query response status

 Values suggested by HL7. Use in QAK-2)

Value Description Comment

OK Data found, no errors (this is

the default)

Similar to AA in table HL70008

NF No data found, no errors

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 18 
Change History

Value Description Comment

AE Application error Query had an error in content of format.

AR Application reject Message was rejected because one of the

following occurred:

• Unsupported message type

• Unsupported event code

• Unsupported processing ID

Unable to process for reasons unrelated for

format or content

TM Too many candidates found

User-defined Table 0215 – Publicity code

Values suggested by CDC. (use in PD1-11)

Value Description

01 No reminder/recall

02 Reminder/recall – any method

03 Reminder/recall – no calls

04 Reminder only – any method

05 Reminder only – no calls

06 Recall only – any method

07 Recall only – no calls

08 Reminder/recall – to provider

09 Reminder to provider

10 Only reminder to provider, no recall

11 Recall to provider

12 Only recall to provider, no reminder

User-defined Table 0220 – Living arrangement

Fields using this code set are expected to be empty.  For a current list of HL7 values please reference the

HL7 version 2.5.1 documents.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 19 
Change History

HL7-defined Table 0227 – Manufacturers of vaccines (code =

MVX)

(use in RXA-17) The table below represents the February 2010 version of the MVX code set.  The CDC’s

National Center for Immunization and Respiratory Diseases (NCIRD) maintains the HL7 external code set

MVX. http://www2a.cdc.gov/vaccines/IIS/IISStandards/vaccines.asp?rpt=mvx 42

NOTE:  The MVX table reflects name changes and changes in corporate status.  Where there have been company

mergers/acquisitions, the affected old codes have been labeled “inactive.  The inactive manufacturer codes are retained

to allow manufacturer to be identified for historic immunization records.  They should not be used for current

immunizations.  Inactive codes should not be cross-walked to the code for the current manufacturer.

Alphabetized by manufacturer name

MVX CODE Manufacturer Name Notes

AB Abbott Laboratories

includes Ross Products Division,

Solvay

ACA Acambis, Inc acquired by sanofi in sept 2008

AD Adams Laboratories, Inc.

AKR Akorn, Inc

ALP Alpha Therapeutic Corporation

AR Armour part of CSL

AVB Aventis Behring L.L.C. part of CSL

AVI Aviron acquired by Medimmune

BA

Baxter Healthcare Corporation-

inactive

BAH Baxter Healthcare Corporation

includes Hyland Immuno, Immuno

International AG,and North

American Vaccine, Inc./acquired

some assets from alpha therapeutics

BAY Bayer Corporation

Bayer Biologicals now owned by

Talecris

BP Berna Products

BPC Berna Products Corporation

includes Swiss Serum and Vaccine

Institute Berne

BRR Barr Laboratories Subsidiary of Teva Pharmaceuticals

BTP Biotest Pharmaceuticals New owner of NABI HB as of

42 This link is current as of 2/15/2011.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 20 
Change History

MVX CODE Manufacturer Name Notes

Corporation December 2007, Does NOT replace

NABI Biopharmaceuticals in this

code list.

CEN Centeon L.L.C.

CHI Chiron Corporation Part of Novartis

CMP Celltech Medeva Pharmaceuticals Part of Novartis

CNJ Cangene Corporation

CON Connaught acquired by Merieux

CRU Crucell

acquired Berna,  now a J & J

company

CSL CSL Behring, Inc

CSL Biotherapies renamed to CSL

Behring

DVC DynPort Vaccine Company, LLC

EVN Evans Medical Limited Part of Novartis

GEO GeoVax Labs, Inc.

GRE Greer Laboratories, Inc.

GRF Grifols

IAG Immuno International AG Part of Baxter

IDB ID Biomedical

IM Merieux Part of sanofi

INT Intercell Biomedical

IUS Immuno-U.S., Inc.

JNJ Johnson and Johnson

acquired CRUCELL which acquired

Berna

JPN

The Research Foundation for

Microbial Diseases of Osaka

University (BIKEN)

KGC Korea Green Cross Corporation

LED Lederle

became a part of WAL, now owned

by Pfizer

MA

Massachusetts Public Health

Biologic Laboratories

MBL Massachusetts Biologic formerly Massachusetts Public 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 21 
Change History

MVX CODE Manufacturer Name Notes

Laboratories Health Biologic Laboratories

MED MedImmune, Inc.

acquisitions of U.S. Bioscience in

1999 and Aviron in 2002, as well as

the integration with Cambridge

Antibody Technology and the

strategic alignment with our new

parent company, AstraZeneca, in

2007.

MIL Miles

MIP

Emergent BioDefense Operations

Lansing

Bioport renamed. Formerly

Michigan Biologic Products Institute

MSD Merck and Co., Inc.

NAB NABI

formerly North American Biologicals,

Inc.

NAV North American Vaccine, Inc. part of Baxter

NOV

Novartis Pharmaceutical

Corporation

includes Chiron, PowderJect

Pharmaceuticals, Celltech Medeva

Vaccines and Evans Limited, Ciba-

Geigy Limited and Sandoz Limited

NVX Novavax, Inc.

NYB New York Blood Center

ORT Ortho-clinical Diagnostics

a J & J company (formerly Ortho

Diagnostic Systems, Inc.)

OTC Organon Teknika Corporation

OTH Other manufacturer

PD Parkedale Pharmaceuticals

no website and no news articles

(formerly Parke-Davis)

PFR Pfizer, Inc

includes Wyeth-Lederle Vaccines

and Pediatrics, Wyeth Laboratories,

Lederle Laboratories, and Praxis

Biologics,

PMC sanofi pasteur

formerly Aventis Pasteur, Pasteur

Merieux Connaught; includes

Connaught Laboratories and Pasteur

Merieux. Acquired ACAMBIS.

PRX Praxis Biologics

became a part of WAL, now owned

by Pfizer

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 22 
Change History

MVX CODE Manufacturer Name Notes

PSC Protein Sciences

PWJ PowderJect Pharmaceuticals See Novartis

SCL Sclavo, Inc.

SI Swiss Serum and Vaccine Inst. Part of Berna

SKB GlaxoSmithKline

 includes SmithKline Beecham and

Glaxo Wellcome

SOL Solvay Pharmaceuticals Part of Abbott

TAL Talecris Biotherapeutics includes Bayer Biologicals

UNK Unknown manufacturer

USA

United States Army Medical

Research and Material Command

VXG VaxGen

acquired by Emergent Biodefense

Operations Lansing, Inc

WA Wyeth-Ayerst became WAL, now owned by Pfizer

WAL Wyeth acquired by Pfizer 10/15/2009

ZLB ZLB Behring acquired by CSL

User-defined Table 0288 – Census tract

Use in all XAD; including PID-11

Fields using this code set are expected to be empty.  For a current list of HL7 values please reference the

HL7 version 2.5.1 documents.

User-defined Table 0289 – County/parish

Use in all XAD; including PID-11

A complete list of FIPS 6-4 county codes is available at

https://phinvads.cdc.gov/vads/ViewValueSet.action?id=20D34BBC-617F-DD11-B38D-

00188B398520

For example:

04001 = Apache County, Arizona

01001 = Autauga County, Alabama

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 23 
https://phinvads.cdc.gov/vads/ViewValueSet.action?id=20D34BBC-617F-DD11-B38D-00188B398520
https://phinvads.cdc.gov/vads/ViewValueSet.action?id=20D34BBC-617F-DD11-B38D-00188B398520
Change History

HL7-defined Table 0292 – Codes for Vaccines administered

(code=CVX)

Use in RXA-5

The table below represents the March 2014 version of the CVX code set. New codes are added as needed;

therefore, see the most current version of this code set at the website Web site:

http://www2a.cdc.gov/vaccines/IIS/IISStandards/vaccines.asp?rpt=cvx 43

The CDC’s National Center for Immunization and Respiratory Diseases (NCIRD) maintains the HL7

external code set CVX.

CVX – Vaccines Administered

CVX

Code

Short Description Full Vaccine Name Note

99 RESERVED – do not use RESERVED – do not use Code 99 will not be used in this

table to avoid confusion with

code 999.

998 no vaccine administered no vaccine administered Code 998 was added for use in

VXU HL7 messages where the

OBX segment is nested with

the RXA segment, but the

message does not contain

information about a vaccine

administration. An example of

this use is to report the

vaccines due next for a patient

when no vaccine

administration is being

reported.

999 unknown unknown vaccine or immune

globulin

This CVX code has little utility

and should rarely be used.

143 Adenovirus types 4 and 7

Adenovirus, type 4 and

type 7, live, oral

This vaccine is administered

as 2 tablets.

54 adenovirus, type 4

adenovirus vaccine, type 4,

live, oral

55 adenovirus, type 7

adenovirus vaccine, type 7,

live, oral

82

adenovirus, unspecified

formulation

adenovirus vaccine,

unspecified formulation

This CVX code allows

reporting of a vaccination

when formulation is

unknown (for example,

when recording a

43 Link is current as of 8/1/2011.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 24 
Change History

CVX

Code

Short Description Full Vaccine Name Note

adenovirus vaccination

when noted on a

vaccination card)

24 anthrax anthrax vaccine

801 AS03 Adjuvant AS03 Adjuvant This is the adjuvant that is

packaged with H5N1

vaccine, adjuvanted

19 BCG Bacillus Calmette-Guerin

vaccine

27 botulinum antitoxin botulinum antitoxin

26 cholera cholera vaccine

29 CMVIG cytomegalovirus immune

globulin, intravenous

56 dengue fever dengue fever vaccine

12 diphtheria antitoxin diphtheria antitoxin

28 DT (pediatric) diphtheria and tetanus

toxoids, adsorbed for

pediatric use

20 DTaP diphtheria, tetanus toxoids

and acellular pertussis

vaccine

106 DTaP, 5 pertussis antigens diphtheria, tetanus toxoids

and acellular pertussis

vaccine, 5 pertussis

antigens

107 DTaP, unspecified

formulation

diphtheria, tetanus toxoids

and acellular pertussis

vaccine, unspecified

formulation

This CVX code allows

reporting of a vaccination

when formulation is

unknown (for example,

when recording a DTaP

vaccination when noted on

a vaccination card)

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 25 
Change History

CVX

Code

Short Description Full Vaccine Name Note

146 DTaP,IPV,Hib,HepB Diphtheria and Tetanus

Toxoids and Acellular

Pertussis Adsorbed,

Inactivated Poliovirus,

Haemophilus b Conjugate

(Meningococcal Outer

Membrane Protein

Complex), and Hepatitis B

(Recombinant) Vaccine.

Note that this vaccine is

different from CVX 132.

110 DTaP-Hep B-IPV DTaP-hepatitis B and

poliovirus vaccine

50 DTaP-Hib DTaP-Haemophilus

influenzae type b

conjugate vaccine

120 DTaP-Hib-IPV diphtheria, tetanus toxoids

and acellular pertussis

vaccine, Haemophilus

influenzae type b

conjugate, and poliovirus

vaccine, inactivated (DTaP-

Hib-IPV)

130 DTaP-IPV Diphtheria, tetanus toxoids

and acellular pertussis

vaccine, and poliovirus

vaccine, inactivated

132 DTaP-IPV-HIB-HEP B,

historical

Historical record of vaccine

containing

* diphtheria, tetanus

toxoids and acellular

pertussis,

* poliovirus, inactivated,

* Haemophilus

influenzae type b

conjugate,

* Hepatitis B (DTaP-Hib-

IPV)

This is not the same as CVX

146, Hexavalent vaccine.

01 DTP diphtheria, tetanus toxoids

and pertussis vaccine

22 DTP-Hib DTP-Haemophilus

influenzae type b

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 26 
Change History

CVX

Code

Short Description Full Vaccine Name Note

conjugate vaccine

102 DTP-Hib-Hep B DTP- Haemophilus

influenzae type b

conjugate and hepatitis b

vaccine

57 hantavirus hantavirus vaccine

30 HBIG hepatitis B immune

globulin

52 Hep A, adult hepatitis A vaccine, adult

dosage

154 Hep A, IG Hepatitis A immune

globulin

Do not use this code. This

product may be used for

Hep A and other viral

infections. The correct

vaccine / CVX is 86 (IG).

83 Hep A, ped/adol, 2 dose hepatitis A vaccine,

pediatric/adolescent

dosage, 2 dose schedule

84 Hep A, ped/adol, 3 dose hepatitis A vaccine,

pediatric/adolescent

dosage, 3 dose schedule

This vaccine formulation is

inactive and should not be

used, except to record

historic vaccinations with

this formulation.

31 Hep A, pediatric,

unspecified formulation

hepatitis A vaccine,

pediatric dosage,

unspecified formulation

Do NOT use this code.  If

formulation is unknown,

use CVX 85.  There is only

one formulation of Hep A,

peds.

85 Hep A, unspecified

formulation

hepatitis A vaccine,

unspecified formulation

This CVX code allows

reporting of a vaccination

when formulation is

unknown (for example,

when recording a HepA

vaccination when noted on

a vaccination card)

104 Hep A-Hep B hepatitis A and hepatitis B

vaccine

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 27 
Change History

CVX

Code

Short Description Full Vaccine Name Note

08 Hep B, adolescent or

pediatric

hepatitis B vaccine,

pediatric or

pediatric/adolescent

dosage

This code applies to any

standard pediatric

formulation of Hepatitis B

vaccine. It should not be

used for the 2-dose

hepatitis B schedule for

adolescents (11-15 year

olds). It requires Merck’s

Recombivax HB® adult

formulation. Use code 43

for that vaccine

42 Hep B, adolescent/high

risk infant

hepatitis B vaccine,

adolescent/high risk infant

dosage

As of August 27, 1998,

Merck ceased distribution

of their adolescent/high risk

infant hepatitis B vaccine

dosage. Code 42 should

only be used to record

historical records. For

current administration of

hepatitis B vaccine,

pediatric/adolescent

dosage, use

43 Hep B, adult hepatitis B vaccine, adult

dosage

As of September 1999, a 2-

dose hepatitis B schedule

for adolescents (11-15 year

olds) was FDA approved for

Merck’s Recombivax HB®

adult formulation. Use code

43 for the 2-dose. This code

should be used for any use

of standard adult

formulation of hepatiti

44 Hep B, dialysis hepatitis B vaccine, dialysis

patient dosage

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 28 
Change History

CVX

Code

Short Description Full Vaccine Name Note

45 Hep B, unspecified

formulation

hepatitis B vaccine,

unspecified formulation

This CVX code allows

reporting of a vaccination

when formulation is

unknown (for example,

when recording a HepB

vaccination when noted on

a vaccination card)

58 Hep C hepatitis C vaccine

59 Hep E hepatitis E vaccine

60 herpes simplex 2 herpes simplex virus, type

2 vaccine

47 Hib (HbOC) Haemophilus influenzae

type b vaccine, HbOC

conjugate

46 Hib (PRP-D) Haemophilus influenzae

type b vaccine, PRP-D

conjugate

49 Hib (PRP-OMP) Haemophilus influenzae

type b vaccine, PRP-OMP

conjugate

48 Hib (PRP-T) Haemophilus influenzae

type b vaccine, PRP-T

conjugate

17 Hib, unspecified

formulation

Haemophilus influenzae

type b vaccine, conjugate

unspecified formulation

51 Hib-Hep B Haemophilus influenzae

type b conjugate and

Hepatitis B vaccine

61 HIV human immunodeficiency

virus vaccine

118 HPV, bivalent human papilloma virus

vaccine, bivalent

62 HPV, quadrivalent human papilloma virus

vaccine, quadrivalent

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 29 
Change History

CVX

Code

Short Description Full Vaccine Name Note

137 HPV, unspecified

formulation

HPV, unspecified

formulation

This CVX code allows

reporting of a vaccination

when formulation is

unknown (for example,

when recording a HPV

vaccination when noted on

a vaccination card)

86 IG immune globulin,

intramuscular 
14 IG, unspecified

formulation

immune globulin,

unspecified formulation 
87 IGIV immune globulin,

intravenous 
160 Influenza A monovalent

(H5N1), ADJUVANTED-

2013

Influenza A monovalent

(H5N1), adjuvanted,

National stockpile 2013

Approved by FDA 2013,

adjuvant is mixed at point of

adminstration.

151 influenza nasal,

unspecified formulation

influenza nasal,

unspecified formulation

This CVX should only be

used for historical records

where the formulation of

nasal flu vaccine is not

known.

123 influenza, H5N1-1203 influenza virus vaccine,

H5N1,

A/Vietnam/1203/2004

(national stockpile) 
135 Influenza, high dose

seasonal

influenza, high dose

seasonal, preservative-free 
153 Influenza, injectable,

MDCK, preservative free

Influenza, injectable,

Madin Darby Canine

Kidney, preservative free

ccIIV3

158 influenza, injectable,

quadrivalent

influenza, injectable,

quadrivalent, contains

preservative

New in 2013.  IIV4

150 influenza, injectable,

quadrivalent,

preservative free

Influenza, injectable,

quadrivalent, preservative

free

New in 2012.  IIV4

111 influenza, live, intranasal influenza virus vaccine,

live, attenuated, for

intranasal use

LAIV3 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 30 
Change History

CVX

Code

Short Description Full Vaccine Name Note

149 influenza, live, intranasal,

quadrivalent

influenza, live, intranasal,

quadrivalent

new in 2012.  LAIV4

155 influenza, recombinant,

injectable, preservative

free

Seasonal, trivalent,

recombinant, injectable

influenza vaccine,

preservative free

RIV

141 Influenza, seasonal,

injectable

Influenza, seasonal,

injectable

IIV3. This is one of two

codes replacing CVX 15,

which is being retired.

140 Influenza, seasonal,

injectable, preservative

free

Influenza, seasonal,

injectable, preservative

free

IIV3. This vaccine code is

one of two which replace

CVX 15, influenza, split

virus.

144 influenza, seasonal,

intradermal, preservative

free

seasonal influenza,

intradermal, preservative

free

IIV3

15 influenza, split (incl.

purified surface antigen)

influenza virus vaccine,

split virus (incl. purified

surface antigen)-retired

CODE

This code is being retired. It

will still be found in older

immunization records. It

included both preservative

free and non-preservative

free.

88 influenza, unspecified

formulation

influenza virus vaccine,

unspecified formulation

This CVX code allows

reporting of a vaccination

when formulation is

unknown (for example,

when recording a Influenza

vaccination when noted on

a vaccination card)

16 influenza, whole influenza virus vaccine,

whole virus

10 IPV poliovirus vaccine,

inactivated

134 Japanese Encephalitis IM Japanese Encephalitis

vaccine for intramuscular

administration

39 Japanese encephalitis SC Japanese Encephalitis

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 31 
Change History

CVX

Code

Short Description Full Vaccine Name Note

Vaccine SC

129 Japanese Encephalitis,

unspecified formulation

Japanese Encephalitis

vaccine, unspecified

formulation

This CVX code allows

reporting of a vaccination

when formulation is

unknown (for example,

when recording a JE

vaccination when noted on

a vaccination card)

63 Junin virus Junin virus vaccine

64 leishmaniasis leishmaniasis vaccine

65 leprosy leprosy vaccine

66 Lyme disease Lyme disease vaccine

04 M/R measles and rubella virus

vaccine

67 malaria malaria vaccine

05 measles measles virus vaccine

68 melanoma melanoma vaccine

103 meningococcal C

conjugate

meningococcal C conjugate

vaccine

148 Meningococcal C/Y-HIB

PRP

Meningococcal Groups C

and Y and Haemophilus b

Tetanus Toxoid Conjugate

Vaccine

147 meningococcal MCV4,

unspecified formulation

Meningococcal, MCV4,

unspecified

formulation(groups A, C, Y

and W-135)

This CVX should only be

used for historical doses of

meningococcal conjugate

vaccine where the

formulation is unknown

(oligosaccharide vs

polysaccharide). It is not the

same as CVX 108,

Meningococcal, unspecified

formulation.

136 Meningococcal MCV4O meningococcal

oligosaccharide (groups A,

C, Y and W-135) diphtheria

toxoid conjugate vaccine

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 32 
Change History

CVX

Code

Short Description Full Vaccine Name Note

(MCV4O)

114 meningococcal MCV4P meningococcal

polysaccharide (groups A,

C, Y and W-135) diphtheria

toxoid conjugate vaccine

(MCV4P)

32 meningococcal MPSV4 meningococcal

polysaccharide vaccine

(MPSV4)

108 meningococcal,

unspecified formulation

meningococcal vaccine,

unspecified formulation

This CVX code allows

reporting of a vaccination

when formulation is

unknown (for example,

when recording a

meningococcal vaccination

when noted on a

vaccination card)

03 MMR measles, mumps and

rubella virus vaccine

94 MMRV measles, mumps, rubella,

and varicella virus vaccine

07 mumps mumps virus vaccine

127 Novel influenza-H1N1-09 Novel influenza-H1N1-09,

injectable

128 Novel Influenza-H1N1-09,

all formulations

Novel influenza-H1N1-09,

all formulations

This code is used whenever

the actual formulation is

not determined or when

aggregating all Novel H1N1

Influenza-09 immunizations

for reporting to CRA. It

should not be used for

seasonal influenza vaccine

that is not otherwise

specified. (NOS)

125 Novel Influenza-H1N1-09,

nasal

Novel Influenza-H1N1-09,

live virus for nasal

administration

126 Novel influenza-H1N1-09,

preservative-free

Novel influenza-H1N1-09,

preservative-free,

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 33 
Change History

CVX

Code

Short Description Full Vaccine Name Note

injectable

02 OPV poliovirus vaccine, live,

oral

69 parainfluenza-3 parainfluenza-3 virus

vaccine

11 pertussis pertussis vaccine

23 plague plague vaccine

133 Pneumococcal conjugate

PCV 13

pneumococcal conjugate

vaccine, 13 valent

100 pneumococcal conjugate

PCV 7

pneumococcal conjugate

vaccine, 7 valent

152 Pneumococcal Conjugate,

unspecified formulation

Pneumococcal Conjugate,

unspecified formulation

This CVX should only be

used for historical records

where the formulation of

pneumococcal conjugate

vaccine is not known.

33 pneumococcal

polysaccharide PPV23

pneumococcal

polysaccharide vaccine, 23

valent

109 pneumococcal,

unspecified formulation

pneumococcal vaccine,

unspecified formulation

This CVX code allows

reporting of a vaccination

when formulation is

unknown (for example,

when recording a

pneumococcal vaccination

when noted on a

vaccination card)

89 polio, unspecified

formulation

poliovirus vaccine,

unspecified formulation

This CVX code allows

reporting of a vaccination

when formulation is

unknown (for example,

when recording a polio

vaccination when noted on

a vaccination card)

70 Q fever Q fever vaccine

40 rabies, intradermal

injection

rabies vaccine, for

intradermal injection

18 rabies, intramuscular rabies vaccine, for

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 34 
Change History

CVX

Code

Short Description Full Vaccine Name Note

injection intramuscular injection

90 rabies, unspecified

formulation

rabies vaccine, unspecified

formulation

This CVX code allows

reporting of a vaccination

when formulation is

unknown (for example,

when recording a rabies

vaccination when noted on

a vaccination card)

72 rheumatic fever rheumatic fever vaccine

159 Rho(D) – Unspecified

formulation

Rho(D) Unspecified

formulation 
157 Rho(D) -IG IM Rho(D) Immune globulin –

IM

This immune globulin may

be administered IM only.

156 Rho(D)-IG Rho(D) Immune globulin-

IV or IM

This immune globulin may

be administered either IM

or IV.

73 Rift Valley fever Rift Valley fever vaccine

34 RIG rabies immune globulin

119 rotavirus, monovalent rotavirus, live, monovalent

vaccine 
116 rotavirus, pentavalent rotavirus, live, pentavalent

vaccine 
74 rotavirus, tetravalent rotavirus, live, tetravalent

vaccine 
122 rotavirus, unspecified

formulation

rotavirus vaccine,

unspecified formulation 
71 RSV-IGIV respiratory syncytial virus

immune globulin,

intravenous 
93 RSV-MAb respiratory syncytial virus

monoclonal antibody

(palivizumab),

intramuscular 
145 RSV-MAb (new) respiratory syncytial virus

monoclonal antibody

(motavizumab), 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 35 
Change History

CVX

Code

Short Description Full Vaccine Name Note

intramuscular

06 rubella rubella virus vaccine

38 rubella/mumps rubella and mumps virus

vaccine

76 Staphylococcus bacterio

lysate

Staphylococcus

bacteriophage lysate

138 Td (adult) tetanus and diphtheria

toxoids, not adsorbed, for

adult use

Note that this Td is not

adsorbed.

113 Td (adult) preservative

free

tetanus and diphtheria

toxoids, adsorbed,

preservative free, for adult

use

09 Td (adult), adsorbed tetanus and diphtheria

toxoids, adsorbed, for

adult use

Note that this vaccine name

has changed.  See also Td

(adult). It is not adsorbed.

139 Td(adult) unspecified

formulation

Td(adult) unspecified

formulation

This CVX code allows

reporting of a vaccination

when formulation is

unknown (for example,

when recording a Td

vaccination when noted on

a vaccination card)

115 Tdap tetanus toxoid, reduced

diphtheria toxoid, and

acellular pertussis vaccine,

adsorbed

35 tetanus toxoid, adsorbed tetanus toxoid, adsorbed

142 tetanus toxoid, not

adsorbed

tetanus toxoid, not

adsorbed

112 tetanus toxoid,

unspecified formulation

tetanus toxoid, unspecified

formulation

77 tick-borne encephalitis tick-borne encephalitis

vaccine

13 TIG tetanus immune globulin

98 TST, unspecified

formulation

tuberculin skin test;

unspecified formulation

TB Skin test is not vaccine.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 36 
Change History

CVX

Code

Short Description Full Vaccine Name Note

95 TST-OT tine test tuberculin skin test; old

tuberculin, multipuncture

device

TB Skin test is not vaccine.

96 TST-PPD intradermal tuberculin skin test;

purified protein derivative

solution, intradermal

TB Skin test is not vaccine.

97 TST-PPD tine test tuberculin skin test;

purified protein derivative,

multi-puncture device

TB Skin test is not vaccine.

78 tularemia vaccine tularemia vaccine

25 typhoid, oral typhoid vaccine, live, oral

41 typhoid, parenteral typhoid vaccine,

parenteral, other than

acetone-killed, dried 
53 typhoid, parenteral, AKD

(U.S. military)

typhoid vaccine,

parenteral, acetone-killed,

dried (U.S. military) 
91 typhoid, unspecified

formulation

typhoid vaccine,

unspecified formulation

This CVX code allows

reporting of a vaccination

when formulation is

unknown (for example,

when recording a typhoid

vaccination when noted on

a vaccination card)

101 typhoid, ViCPs typhoid Vi capsular

polysaccharide vaccine 
131 typhus, historical Historical record of a

typhus vaccination 
75 vaccinia (smallpox) vaccinia (smallpox) vaccine

105 vaccinia (smallpox)

diluted

vaccinia (smallpox)

vaccine, diluted 
79 vaccinia immune globulin vaccinia immune globulin

21 varicella varicella virus vaccine

81 VEE, inactivated Venezuelan equine

encephalitis, inactivated 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 37 
Change History

CVX

Code

Short Description Full Vaccine Name Note

80 VEE, live Venezuelan equine

encephalitis, live,

attenuated

92 VEE, unspecified

formulation

Venezuelan equine

encephalitis vaccine,

unspecified formulation

This CVX code allows

reporting of a vaccination

when formulation is

unknown (for example,

when recording a VEE

vaccination when noted on

a vaccination card)

36 VZIG varicella zoster immune

globulin

117 VZIG (IND) varicella zoster immune

globulin (Investigational

New Drug)

37 yellow fever yellow fever vaccine

121 zoster zoster vaccine, live

User-defined Table 0296 – Language

ISO 639 shall be used for Language. It is available from PHIN-VADS at:

http://phinvads.cdc.gov/vads/ViewValueSet.action?id=43D34BBC-617F-DD11-B38D-

00188B398520#

The code used from HL70396 table is ISO6392.

Example codes are found in the table below, but use is not restricted to this list.

Value Description

ara Arabic

arm Armenian

cat Catalan; Valencian

chi Chinese

dan Danish

eng English

fre French

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 38 
http://phinvads.cdc.gov/vads/ViewValueSet.action?id=43D34BBC-617F-DD11-B38D-00188B398520
http://phinvads.cdc.gov/vads/ViewValueSet.action?id=43D34BBC-617F-DD11-B38D-00188B398520
Change History

Value Description

ger German

hat Haitian; Haitian Creole

heb Hebrew

hin Hindi

hmn Hmong

jpn Japanese

kor Korean

rus Russian

som Somali

spa Spanish; Castilian

vie Vietnamese

User-defined Table 0297 – CN ID source

Use in all XCN data types. [locally-defined]

User-defined Table 0300 – Namespace ID

Use in all EI, HD data types

[locally-defined]

See tables 0361-0363 for Application Identifier, Facility Identifier, and Assigning Authority.  These tables are

more specific than 0300 and are preferred.

HL7-defined Table 0301 – Universal ID type

Use in all HD data types.  Constrained to “OID”

HL7-defined Table 0322 – Completion status

Use in RXA-20

Value Description

CP Complete

RE Refused

NA Not Administered

PA Partially Administered

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 39 
Change History

HL7-defined Table 0323 – Action code

Use in RXA-21

Value Description

A Add

D Delete

U Update

HL7-defined Table 0354 – Message structure

Use in MSH-9, third component. [only selected values listed] These are the only values expected.

Value Events

ACK ACK

QBP_Q11 QBP

RSP_K11 RSP

VXU_V04 VXU

HL7-defined Table 0356 – Alternate character set handling

scheme

Use in MSH-20

Fields using this code set are expected to be empty.  For a current list of HL7 values please reference the

HL7 version 2.5.1 documents.

HL7-defined Table 0357 – Message error status codes

(use in ERR-3)

Status

code

Status text Description/Comment

Success

0 Message accepted Success. Optional, as the AA conveys

this. Used for systems that must always

return a status code.

Error status codes

100 Segment sequence error The message segments were not in the

proper order or required segments are

missing.

101 Required field missing A required field is missing from the

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 40 
Change History

Status

code

Status text Description/Comment

segment.

102 Data type error The field contained data of the wrong data

type, e.g., an NM field contained letters of

the alphabet.

103 Table value not found A field of data type ID or IS was

compared against the corresponding table,

and no match was found.

Rejection status codes

200 Unsupported message type The Message type is not supported.

201 Unsupported event code The Event Code is not supported.

202 Unsupported processing ID The Processing ID is not supported.

203 Unsupported version ID The Version ID is not supported.

204 Unknown key identifier The ID of the patient, order, etc. was not

found. Used for transactions other than

additions, e.g., transfer of a non-existent

patient.

205 Duplicate key identifier The ID of the patient, order, etc. already

exists. Used in response to addition

transactions (Admit, New Order, etc.).

206 Application record locked The transaction could not be performed at

the application storage level, e.g.,

database locked.

207 Application internal error A catchall for internal errors not explicitly

covered by other codes. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 41 
Change History

User-defined Table 0360 – Degree

 Selected values suggested by HL7. ; (use in all XPN data types, including PID-5, 6, 9)

Value Description

PN Advanced Practice Nurse

AA Associate of Arts

AS Associate of Science

BA Bachelor of Arts

BN Bachelor of Nursing

BS Bachelor of Science

BSN Bachelor of Science in Nursing

CER Certificate

CANP Certified Adult Nurse Practitioner

CMA Certified Medical Assistant

CNP Certified Nurse Practitioner

CNM Certified Nurse Midwife

CNA Certified Nurse’s Assistant

CRN Certified Registered Nurse

CNS Certified Nurse Specialist

CPNP Certified Pediatric Nurse Practitioner

DIP Diploma

PHD Doctor of Philosophy

MD Doctor of Medicine

DO Doctor of Osteopathy

EMT Emergency Medical Technician

EMT-P Emergency Medical Technician – Paramedic

FPNP Family Practice Nurse Practitioner

HS High School Graduate

JD Juris Doctor

LPN Licensed Practical Nurse

MA Master of Arts

MBA Master of Business Administration

MPH Master of Public Health

MS Master of Science

MSN Master of Science – Nursing

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 42 
Change History

Value Description

MDA Medical Assistant

MT Medical Technician

NG Non-Graduate

NP Nurse Practitioner

PharmD Doctor of Pharmacy

PA Physician Assistant

PHN Public Health Nurse

RMA Registered Medical Assistant

RN Registered Nurse

RPH Registered Pharmacist

SEC Secretarial Certificate

TS Trade School Graduate 
User-defined Table 0361 – Application

No suggested values defined. The values are locally defined by the Immunization Information System (IIS)

or by mutual agreement.

Note: In most cases, the value set will be managed by the IIS.

User-defined Table 0362 – Facility

No suggested values defined. The values are locally defined by the Immunization Information System (IIS)

or by mutual agreement.

Note: In most cases, the value set will be managed by the IIS. 
User-defined Table 0363 – Assigning Authority

Local implementations will need to add codes to this table to identify local assigning authorities.  The

values in this table are intended to be used by state and regional immunization programs. In the case of an

ID generated by a facility, such as a medical record number, the identifier from Table 0362 should be used. 
Code Grantee

AKA ALASKA

ALA ALABAMA

ARA ARKANSAS

ASA AMERICAN SAMOA

AZA ARIZONA 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 43 
Change History

Code Grantee

BAA NEW YORK CITY

CAA CALIFORNIA

CHA CHICAGO

COA COLORADO

CTA CONNECTICUT

DCA DISTRICT OF

COLUMBIA

DEA DELAWARE

FLA FLORIDA

FMA FED STATES MICRO

GAA GEORGIA

GUA GUAM

HIA HAWAII

IAA IOWA

IDA IDAHO

ILA ILLINOIS

INA INDIANA

KSA KANSAS

KYA KENTUCKY

LAA LOUISIANA

MAA MASSACHUSETTS

MDA MARYLAND

MEA MAINE

MHA REP MARS ISLANDS

MIA MICHIGAN

MNA MINNESOTA

MOA MISSOURI

MPA NO. MARIANA ISLAND

MSA MISSISSIPPI

MTA MONTANA

NCA NORTH CAROLINA

NDA NORTH DAKOTA

NEA NEBRASKA

NHA NEW HAMPSHIRE

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 44 
Change History

Code Grantee

NJA NEW JERSEY

NMA NEW MEXICO

NVA NEVADA

NYA NEW YORK STATE

OHA OHIO

OKA OKLAHOMA

ORA OREGON

PAA PENNSYLVANIA

PHA PHILADELPHIA

PRA PUERTO RICO

RIA RHODE ISLAND

RPA REPUBLIC PALAU

SCA SOUTH CAROLINA

SDA SOUTH DAKOTA

TBA SAN ANTONIO

THA HOUSTON

TNA TENNESSEE

TXA TEXAS

UTA UTAH

VAA VIRGINIA

VIA VIRGIN ISLANDS

VTA VERMONT

WAA WASHINGTON

WIA WISCONSIN

WVA WEST VIRGINIA

WYA WYOMING

User-defined Table 0396 – Coding system

[only selected values listed] See Version 2.5.1 Table 0396 for other values. Use in CE data types to denote

the coding system used for coded values 
Value Description

99zzz or L Local general code (where z is an alphanumeric character)

ART WHO Adverse Reaction Terms

C4 CPT-4 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 45 
Change History

Value Description

C5 CPT-5

CDCA CDC Analyte Codes

CDCM CDC Methods/Instruments Codes

CDCPHINVS PHIN VS (CDC Local Coding System)

CDS CDC Surveillance

CPTM CPT Modifier Code

CST COSTART

CVX CDC Vaccine Codes

E EUCLIDES

E5 Euclides  quantity codes

E6 Euclides Lab method codes

E7 Euclides Lab equipment codes

ENZC Enzyme Codes

HB HIBCC

HCPCS HCFA Common Procedure Coding System

HHC Home Health Care

HL7nnnn HL7 Defined Codes where nnnn is the HL7 table number

HPC HCFA Procedure Codes (HCPCS)

I10 ICD-10

I10P ICD-10  Procedure Codes

I9 ICD9

I9C ICD-9CM

ISOnnnn ISO Defined Codes where nnnn is the ISO table number

LB Local billing code

LN Logical Observation Identifier Names and Codes (LOINC)

MCD Medicaid

MCR Medicare

MEDR Medical Dictionary for Drug Regulatory Affairs (MEDDRA)

MVX CDC Vaccine Manufacturer Codes

NDC National drug codes

NCIT NCI Thesaurus

NPI National Provider Identifier

SNM Systemized Nomenclature of Medicine (SNOMED)

SCT SNOMED Clinical Terminology

SCT2 SNOMED Clinical Terms alphanumeric codes

SNM3 SNOMED International

SNT SNOMED topology codes (anatomic sites)

UML Unified Medical Language

UPC Universal Product Code

UPIN UPIN

W1 WHO record # drug codes (6 digit)

W2 WHO record # drug codes (8 digit)

W4 WHO record # code with ASTM extension

WC WHO ATC

User-defined Table 0441 – Immunization registry status

 Use in PD1-16.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 46 
Change History

Value Description

A Active

I Inactive–Unspecified

L Inactive-Lost to follow-up (cannot contact)

M Inactive-Moved or gone elsewhere (transferred)

P Inactive-Permanently inactive (do not re-activate or add new entries to this

record)

U Unknown 
The code O (Other) has been removed, do not use

User-defined Table 0471 – Query Name 
Value Description

Z34 Request Immunization History

Z44 Request Evaluated History and Forecast

HL7 Table 0516 – Error Severity  
Value Description Comment

I Information Transaction successful, but

includes returned information.

W Warning Transaction successful, but there

may be issues.  These may

include non-fatal errors with

potential for loss of data.

E Error Transaction was not successful.

The application rejected data that

it views as important.  This could

include required fields or the

entire message. The sender

should be alerted to review and

correct the message.

User-defined Table 0533 – Application Error Code

This User-defined table has values agreed to by the Immunization Information System Community.

Status code Status text Description/Comment 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 47 
Change History

Status code Status text Description/Comment

1 Illogical Date error Date conflicts with another date in the

message.

2 Invalid Date Date is not valid or lacks required

precision.

3 Illogical Value error The value conflicts with other data in

the message

4 Invalid value The value is not valid. This applies for

fields that are not associated with a

table of values.

5 Table value not found The value is not found in the associated

table.

6 Required observation missing A required observation, such as VFC

eligibility status, is missing.

Illogical Date Error would include:

• Before birth immunization date

• Immunization date in the future

Invalid Date Error would include:

• 20130230 (February 30, 2013)

• 201302 (lacks required precision)

CDC-defined NIP001- Immunization information source

Use in RXA-9

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 48 
Change History

Value Description Operational Definition

00 New immunization record The record of a newly administered dose of

vaccine. The dose was administered by the

organization that is reporting this dose.

01 Historical information – source

unspecified

The record of a vaccine dose from a reliable

historical source, such as an immunization card.

02 Historical information – from other

provider

The record of a vaccine dose from another health

care provider’s historical records.

03 Historical information – from

parent’s written record

The record of a vaccine dose from parentally

maintained written records.

04 Historical information – from

parent’s recall

The record of a vaccine dose from a parents

recall. The reliability of this record is considered

low.

05 Historical information – from other

registry

The record of a vaccine dose from another

Immunization Information System (IIS).

06 Historical information – from birth

certificate

The record of a vaccine dose from a birth record.

07 Historical information – from

school record

The record of a vaccine dose from a written

school record.

08 Historical information – from public

agency

The record of a vaccine dose from a written

public health agency record.

CDC-defined NIP002 – Substance refusal reason

 Use in RXA-18

Value Description

00 Parental decision

01 Religious exemption

02 Other (must add text component of the CE field with description)

03 Patient decision

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 49 
Change History

CDC-defined NIP003 – Observation identifiers

Use in OBX-3)44

LOINC

® Code 45

Description Correspondin

g data type

(indicate in

OBX-2)

Corresponding  observation value

EXAMPLE OR code table to use (value in

OBX-5)

Vaccine Funding Program Eligibility Category—Use in OBX-3 to indicate that OBX-5 will contain the

funding program eligibility category for a given immunization.

64994-7 Vaccine funding program

eligibility category

(CE) HL70064

Vaccine Funding Source – Use in OBX-3 to indicate that OBX-5 will contain the funding source for a

given immunization.

30963-3 Vaccine funding source (CE) Value Set OID –  2.16.840.1.114222.4.11.3287

Value Set Code::

PHVS_ImmunizationFundingSource_IIS

Vaccine Type Identifier

30956-7 Vaccine Type (Vaccine

group or family)

(CE) CVX

(CVX codes – use the codes described as

“unspecified formulation” as needed.)

NOTE: this code is preferred over 38890-0.

38890-0 Component Vaccine Type (CE) CVX

(CVX codes – use the codes described as

“unspecified formulation” as needed.)

Contraindications, Precautions, Indications and Immunities

44 All VAERS-only items removed.

45 This material contains content from LOINC® (http://loinc.org ). The LOINC table and LOINC codes are

copyright © 1995-2010, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and

Codes (LOINC) Committee.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 50 
http://loinc.org/
Change History

LOINC

® Code 45

Description Correspondin

g data type

(indicate in

OBX-2)

Corresponding  observation value

EXAMPLE OR code table to use (value in

OBX-5)

30946-8 Vaccination

contraindication/precautio

n effective date

(DT) 19970522

30944-3 Vaccination temporary

contraindication/precautio

n expiration date

(DT) 19990523

30945-0 Vaccination

contraindication/precautio

n

(CE) Value Set OID – 2.16.840.1.114222.4.11.3288

Value Set Code::

PHVS_VaccinationContraindication_IIS 
31044-1 Reaction (CE) Value Set OID – 2.16.840.1.114222.4.11.3289

Value Set Code::

PHVS_VaccinationReaction_IIS 
59784-9 Disease with presumed

immunity

(CE) Value Set OID – 2.16.840.1.114222.4.11.3293

Value Set Code::

PHVS_EvidenceOfImmunity_IIS 
75505-8 Diseases with serological

evidence of immunity

(CE) Value Set OID – 2.16.840.1.114222.4.11.7245

Value Set Code::

PHVS_SerologicalEvidenceOfImmunity_IIS 
59785-6 Indications to immunize (CE) Value Set OID – 2.16.840.1.114222.4.11.3290

Value Set Code::

PHVS_VaccinationSpecialIndications_IIS 
Vaccine Information Statement (VIS) Dates

69764-9 
Document type CE Value Set OID: 2.16.840.1.114222.4.11.6041

Value Set Code: PHVS_VISBarcodes_IIS 
29768-9 Date Vaccine Information

Statement Published

(TS) 19900605

29769-7 Date Vaccine Information

Statement Presented

(TS) 199307311615

Forecasting and Evaluating Immunizations 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 51 
Change History

LOINC

® Code 45

Description Correspondin

g data type

(indicate in

OBX-2)

Corresponding  observation value

EXAMPLE OR code table to use (value in

OBX-5)

30973-2 30973-2 — Dose number

in series

(NM) 2

30979-9 Vaccines due next (CE) HL70292 (CVX)

30980-7 30980-7 – Date vaccine

due

(TS_NZ) 19980526

30981-5 30981-5 – Earliest date to

give

(TS_NZ) 19980522

30982-3 30982-3 – Reason applied

by forecast logic to project

this vaccine

(CE) or (ST) Codes for forecast logic reason locally

defined.

59779-9 Immunization Schedule

used

CE Value Set OID –

2.16.840.1.114222.4.11.23292

Value Set Code::

PHVS_ImmunizationScheduleIdentifier_II

S

59777-3 Latest date next dose may

be given

TS_NZ 19980522

59778-1 Reason Code CE Locally Defined

59780-7 Immunization Series name CE Locally Defined

59782-3 Number of doses in

primary series

NM 2

59781-5 Dose validity ID Y, N or empty

59783-1 Status in immunization

series

CE Locally defined value set

Smallpox Take Read: These codes allow information about evaluation of a smallpox vaccination,

called the take response.

46249-9 VACCINATION TAKE-

RESPONSE TYPE

(ST) Major Take, Equivocal, Not Available

46250-7 VACCINATION TAKE-

RESPONSE DATE

(TS) 20091221

LOINC® codes are copyright 1995-2009, Regenstrief Institute and the Logical Observation Identifier

Names and Codes (LOINC®) Committee.  All rights reserved.

The following CDC defined tables are not included in this Guide.  They support VAERS reporting,

which is not within the scope of this Guide.

• NIP 005 – Event Consequences

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 52 
Change History

• NIP 007 – Vaccinated at Location

• NIP 008 – Vaccine purchased with Funds

• NIP 009 – Adverse event previously reported

• NIP 010 – Report type

The following value sets replace a number of CDC defined tables. These have been registered in the CDC

local value set, CDCPHINVS.  Where appropriate, existing codes are used.  For example SNOMED codes

are used for some contraindications.  Local codes (VXCxx) will be replaced as new SNOMED codes are

published.

CDC-defined NIP004 – Contraindications, Precautions, and

Immunities

This table has been replaced by separate tables for contraindications, indications, reactions and immunities.

Value Set Name – Immunization Funding Source

Used in OBX- 5

Value Set OID –  2.16.840.1.114222.4.11.3287

Value Set Code:: PHVS_ImmunizationFundingSource_IIS

Value set definition: Indicates funding source for an immunization. This is used to support vaccine inventory

management. 
Code Set OID:

NULLFL: 2.16.840.1.113883.5.1008

CDCPHINVS:  2.16.840.1.114222.4.5.274 
Local implements may expand this list.

Concept

Code

Concept Name Definition HL7 Table 0396

Code

V 2.3.1 Value

NIP008 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 53 
Change History

Concept

Code

Concept Name Definition HL7 Table 0396

Code

V 2.3.1 Value

NIP008

PHC70 Private funds Immunization

was funded by

private funds,

including

insurance.

CDCPHINVS PVF

VXC1 Federal funds Immunization

was funded with

public funds

from the federal

government.

CDCPHINVS

VXC2 State funds Immunization

was funded with

public funds

from a state.

CDCPHINVS

PHC68 Military funds Immunization

was paid for

with military

funds.

CDCPHINVS MLF

VXC3 Tribal funds Immunization

was paid for

with tribal funds.

CDCPHINVS

OTH Other Immunization

was paid for by

funding not

listed above.

NULLFL OTH

UNK Unspecified Funding source

for

immunization is

not specified.

NULLFL

Examples:

|PHC70^Private funds^CDCPHINVS|

|OTH^Other^NULLFL|

Value Set Name – Vaccination Contraindications

Used in OBX- 5

Value Set OID – 2.16.840.1.114222.4.11.3288

Value Set Code:: PHVS_VaccinationContraindication_IIS

Value set definition: indicates a contraindication to vaccination.

Code Set OID:

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 54 
Change History

SNOMED: 2.16.840.1.113883.6.96

CDCPHINVS:  2.16.840.1.114222.4.5.274

Concept Code Concept Name Definition HL7 Table 0396

Code

V 2.3.1

Value

NIP004

VXC30 allergy (anaphylactic)  to

proteins of rodent or neural

origin

allergy (anaphylactic)

to proteins of rodent

or neural origin

CDCPHINVS

VXC17 allergy (anaphylactic) to 2-

phenoxyethanol

allergy (anaphylactic)

to 2-phenoxyethanol

CDCPHINVS

VXC18 allergy to baker’s yeast

(anaphylactic)

allergy to baker’s

yeast (anaphylactic)

CDCPHINVS 03

91930004 Allergy to eggs (disorder) allergy to egg

ingestion

(anaphylactic)

SCT 04

294847001 Gelatin allergy (disorder) allergy to gelatin

(anaphylactic)

SCT 05

294468006 Neomycin allergy (disorder) allergy to neomycin

(anaphylactic)

SCT 06

294466005 Streptomycin allergy

(disorder)

allergy to

streptomycin

(anaphylactic)

SCT 07

VXC19 allergy to thimerosal

(anaphylactic)

allergy to thimerosal

(anaphylactic)

CDCPHINVS 08

VXC20 allergy to previous dose of

this vaccine or to any of its

unlisted vaccine

components (anaphylactic)

allergy to previous

dose of this vaccine

or to any of its

unlisted vaccine

components

(anaphylactic)

CDCPHINVS 09

402306009 Allergy to aluminum

(disorder)

allergy (anaphylactic)

to alum

SCT

300916003 Latex allergy (disorder) allergy (anaphylactic)

to latex

SCT

294530006 Polymyxin B allergy

(disorder)

allergy (anaphylactic)

to polymycin B

SCT

VXC21 Previous history of

intussusception

Previous history of

intussusception

CDCPHINVS

VXC22 encephalopathy within 7

days of previous dose of

DTP or DTaP

encephalopathy

within 7 days of

previous dose of DTP

or DTaP

CDCPHINVS 15

VXC23 current fever with moderate- current fever with CDCPHINVS 16

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 55 
Change History

Concept Code Concept Name Definition HL7 Table 0396

Code

V 2.3.1

Value

NIP004

to-severe illness moderate-to-severe

illness

VXC24 current acute illness,

moderate to severe (with or

without fever) (e.g.,

diarrhea, otitis media,

vomiting)

current acute illness,

moderate to severe

(with or without

fever) (e.g., diarrhea,

otitis media,

vomiting)

CDCPHINVS 21

27624003 Chronic disease (disorder) chronic illness (e.g.,

chronic

gastrointestinal

disease)

SCT 22

VXC25 History of Arthus

hypersensitivity reaction to

a tetanus-containing vaccine

administered < 10 yrs 
previously 
History of Arthus 
hypersensitivity 
reaction to a tetanus-
containing vaccine 
administered < 10 yrs 
previously 
CDCPHINVS 
VXC26 underlying unstable, 
evolving neurologic 
disorders, (including seizure 
disorders, cerebral palsy, 
and developmental delay) 
underlying unstable, 
evolving neurologic 
disorders, (including 
seizure disorders, 
cerebral palsy, and 
developmental delay) 
CDCPHINVS 37 
VXC27 immunodeficiency due to 
any cause, including HIV 
(hematologic and solid 
tumors, congenital 
immunodeficiency, long-
term immunosuppressive 
therapy, including steroids) 
immunodeficiency 
due to any cause, 
including HIV 
(hematologic and 
solid tumors, 
congenital 
immunodeficiency, 
long-term 
immunosuppressive 
therapy, including 
steroids) 
CDCPHINVS 36 
77386006 Patient currently pregnant 
(finding) 
pregnancy (in 
recipient) 
SCT 39 
302215000 Thrombocytopenic disorder 
(disorder) 
thrombocytopenia SCT 40 
161461006 History of - purpura 
(situation) 
thrombocytopenic 
purpura (history) 
SCT 41 
Examples: 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 56 


Change History 
|VXC18^allergy to bakers yeast^CDCPHINVS| 
|77386006^patient currently pregnant^SCT| 
Value Set Name – Vaccination Reaction - IIS 
Used in OBX- 5 
Value Set OID - 2.16.840.1.114222.4.11.3289 
Value Set Code:: PHVS_VaccinationReaction_IIS 
Value set definition: indicates a reaction or adverse event associate in time with an immunization. 
Code Set OID: 
SNOMED: 2.16.840.1.113883.6.96 
CDCPHINVS:  2.16.840.1.114222.4.5.274 
Concept Code Concept Name Definition HL7 Table 0396 
Code 
V 2.3.1 
Value 
NIP004 
39579001 Anaphylaxis (disorder) Anaphylaxis SCT 
81308009 Disorder of brain (disorder) Encephalopathy SCT 
VXC9 persistent, inconsolable 
crying lasting > 3 hours

within 48 hours of dose

persistent,

inconsolable crying

lasting > 3 hours

within 48 hours of

dose

CDCPHINVS

VXC10 collapse or shock-like state

within 48 hours of dose

collapse or shock-like

state within 48 hours

of dose

CDCPHINVS

VXC11 convulsions (fits, seizures)

within 72 hours of dose

convulsions (fits,

seizures) within 72

hours of dose

CDCPHINVS

VXC12 fever of >40.5C (105F)

within 48 hours of dose

fever of >40.5C

(105F) within 48

hours of dose

CDCPHINVS

VXC13 Guillain-Barre syndrome

(GBS) within 6 weeks of

dose

Guillain-Barre

syndrome (GBS)

within 6 weeks of

dose

CDCPHINVS

VXC14 Rash within 14 days of dose Rash within 14 days

of dose

CDCPHINVS

VXC15 Intussusception within 30

days of dose

Intussusception

within 30 days of

dose

CDCPHINVS

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 57 
Change History

Examples: 
|39579001^anaphylaxis^SCT|

|VXC14^Rash within 14 days^CDCPHINVS|

Value Set Name – Vaccination Special Indications – IIS

Used in OBX- 5

Value Set OID – 2.16.840.1.114222.4.11.3290

Value Set Code:: PHVS_VaccinationSpecialIndications_IIS

Value set definition: Describes a factor about the client which may impact forecasting of next dose of vaccine

needed. 
Code Set OID:

CDCPHINVS:  2.16.840.1.114222.4.5.274 
Concept Code Concept Name Definition HL7 Table 0396

Code

V 2.3.1

Value 
VXC7 Rabies exposure within

previous 10 days.

Rabies exposure

within previous 10

days.

CDCPHINVS

VXC8 Member of special group Member of special

group

CDCPHINVS  
Example: 
|VXC7^Rabies exposure^CDCPHINVS|

Value Set Name – Immunization Profile Identifiers – IIS

Used in MSH-21

Value Set OID – 2.16.840.1.114222.4.11.3291

Value Set Code:: PHVS_ImmunizationProfileIdentifier_IIS

Value set definition: Identifies the profile used by the message. 
Code Set OID:

CDCPHINVS:  2.16.840.1.114222.4.5.274 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 58 
Change History

Concept Code Concept Name Definition HL7 Table 0396

Code

Z31 Return Candidate Clients Return Candidate

Clients

CDCPHINVS

Z32 Return Immunization

History

Return Immunization

History

CDCPHINVS

Z33 Return acknowledgment Return

acknowledgement

(no match, too many

match, error)

CDCPHINVS

Z34 Request Immunization

History

Request

Immunization

History

CDCPHINVS

Z44 Request Evaluated History

and Forecast

Request Evaluated

History and Forecast

CDCPHINVS

Z42 Return Evaluated History

and Forecast

Return Evaluated

History and Forecast

CDCPHINVS

Example:

|Z34^ CDCPHINVS|

Value Set Name – Immunization Schedule Identifiers – IIS

Used in OBX-5

Value Set OID – 2.16.840.1.114222.4.11.3292

Value Set Code:: PHVS_ImmunizationScheduleIdentifier_IIS

Value set definition: Identifies the schedule used for immunization evaluation and forecast.

Code Set OID:

CDCPHINVS:  2.16.840.1.114222.4.5.274

Concept Code Concept Name Definition HL7 Table 0396

Code

V 2.3.1

Value

VXC16 ACIP Schedule This indicates that the

current ACIP Schedule of

recommendations were used

to forecast next doses due.

CDCPHINVS

Example:

|VXC16^ACIP Schedule^CDCPHINVS|

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 59 
Change History 
Local Implementations may add local codes for local schedules.  In order to do this, the local

implementation guide should publish the code in a local table.  The code system identifier

(CDCPHINVS use above is an example) needs to be included in a local copy of Table 0396.  See first

row for example.  The local schedule code should be recorded as follows: 
|yourLocalcode^your schedule name here^99xxx|

The 99xxx is the local code table identifier.  xxx are alpha characters. 
Value Set Name – History of Disease as Evidence of Immunity –

IIS

Used in OBX- 5

Value Set OID – 2.16.840.1.114222.4.11.7244

Value Set Code:: PHVS_HistoryOfDiseaseAsEvidenceOfImmunity_IIS

Value set definition: History of Disease as Evidence of immunity indicates that a person has been

diagnosed with  a particular disease.

Code Set OID:

SNOMED: 2.16.840.1.113883.6.96 
Concept Code Concept Name Definition HL7 Table

0396 Code

V 2.3.1

Value

NIP004

409498004 Anthrax (disorder) History of anthrax infection. SCT

397428000 Diphtheria

(disorder)

History of diphteria infection. SCT 24

76902006 Tetanus (disorder) History of tetanus infection. SCT 32

27836007 Pertussis (disorder) History of pertussis infection. SCT 29

40468003 Viral hepatitis, type

A (disorder)

History of Hepatitis A infection. SCT

66071002 Type B viral

hepatitis (disorder)

History of Hepatitis B infection. SCT 26

91428005 Haemophilus

influenzae

infection (disorder)

History of HIB infection. SCT 25

240532009 Human papilloma

virus infection

(disorder)

History of HPV infection. SCT

6142004 Influenza

(disorder)

History of influenza infection. SCT  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 60 
Change History

Concept Code Concept Name Definition HL7 Table

0396 Code

V 2.3.1

Value

NIP004

52947006 Japanese

encephalitis virus

disease (disorder)

History of Japanese encephalitis

infection.

SCT

14189004 Measles (disorder) History of measles infection. SCT 27

36989005 Mumps (disorder) History of mumps infection. SCT 28

36653000 Rubella (disorder) History of rubella infection. SCT 31

23511006 Meningococcal

infectious disease

(disorder)

History of meningococcal infection. SCT

16814004 Pneumococcal

infectious disease

(disorder)

History of pneumococcal infection. SCT

398102009 Acute poliomyelitis

(disorder)

History of polio infection. SCT 30

14168008 Rabies (disorder) History of rabies infection. SCT

18624000 Disease due to

Rotavirus

(disorder)

History of rotavirus infection. SCT

4834000 Typhoid fever

(disorder)

History of typhoid infection. SCT

111852003 Vaccinia (disorder) History of vaccinia infection. SCT

38907003 Varicella (disorder) History of Varicella infection. SCT

16541001 Yellow fever

(disorder)

History of yellow fever infection. SCT

Value Set Name – Serological Evidence of Immunity – IIS

Used in OBX- 5

Value Set OID – 2.16.840.1.114222.4.11.7245

Value Set Code:: PHVS_SerologicalEvidenceOfImmunity_IIS

Value set definition: Serological Evidence of immunity to a particular disease indicates that a person

immunity to that  disease.

Code Set OID:

SNOMED: 2.16.840.1.113883.6.96

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 61 
Change History

Concept Code Concept Name Definition HL7 Table

0396 Code

V 2.3.1

Value

NIP004 
341112003 Mumps (finding) Serology confirmed mumps SCT

278968001 Rubella (finding) Serology confirmed rubella SCT

371111005 Measles (finding) Serology confirmed measles SCT

371113008 Varicella (finding)  Serology confirmed varicella SCT

271511000 Hepatitis B

(finding)

Serology confirmed hepatitis B SCT

278971009 Hepatitis A

(finding)

Serology confirmed hepatitis A SCT

341112003 Mumps (finding) Serology confirmed mumps SCT

Value Set Code – PHVS_VISBarcodes_IIS

Value Set Name: VIS Bar Codes (IIS)

Value Set OID: 2.16.840.1.114222.4.11.6041

Value Set Definition:  The purpose of the barcode on the bottom of the Vaccine Information Statement

(VIS) is to provide an opportunity to electronically capture the VIS document type (e.g. influenza, MMR)

and the edition date of the VIS, as required by the National Childhood Vaccine Injury Act (NCVIA). For

more information, please visit – http://www.cdc.gov/vaccines/pubs/vis/vis-barcodes.htm 
VIS Document Type

Description / Concept Name

Edition Date VIS Fully-encoded text string

(Concept Code)

Code System

Code (HL7

Table 0396)

Adenovirus VIS 7/14/2011 253088698300001111110714 cdcgs1vis

Anthrax VIS 3/10/2010 253088698300002811100310 cdcgs1vis

Hepatitis A VIS 10/25/2011 253088698300004211111025 cdcgs1vis

Hepatitis B VIS 2/2/2012 253088698300005911120202 cdcgs1vis

Haemophilus Influenzae type

b VIS

12/16/1998 253088698300006611981216 cdcgs1vis

Human papillomavirus

Vaccine (Cervarix) VIS

5/3/2011 253088698300007311110503 cdcgs1vis

Human papillomavirus

Vaccine (Gardasil) VIS

2/22/2012 253088698300008011120222 cdcgs1vis

Influenza Vaccine – Live,

Intranasal VIS

7/2/2012 253088698300009711120702 cdcgs1vis

Influenza Vaccine –

Inactivated VIS

7/2/2012 253088698300010311120702 cdcgs1vis 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 62 
http://www.cdc.gov/vaccines/pubs/vis/vis-barcodes.htm
Change History

VIS Document Type

Description / Concept Name

Edition Date VIS Fully-encoded text string

(Concept Code)

Code System

Code (HL7

 Japanese Encephalitis VIS 12/7/2011 253088698300011011111207 cdcgs1vis

Measles/Mumps/Rubella VIS 4/20/2012 253088698300012711120420 cdcgs1vis

Measles/Mumps/Rubella/Vari

cella VIS

5/21/2010 253088698300013411100521 cdcgs1vis

Meningococcal VIS 10/14/2011 253088698300014111111014 cdcgs1vis

Pneumococcal Conjugate

(PCV13) VIS

4/16/2010 253088698300015811100416 cdcgs1vis

Pneumococcal

Polysaccharide VIS

10/6/2009 253088698300016511091006 cdcgs1vis

Polio VIS 11/8/2011 253088698300017211111108 cdcgs1vis

Rabies VIS 10/6/2009 253088698300018911091006 cdcgs1vis

Shingles VIS 10/6/2009 253088698300020211091006 cdcgs1vis

Tetanus/Diphtheria/(Pertussis

) VIS

1/24/2012 253088698300022611120124 cdcgs1vis

Typhoid VIS 5/29/2012 253088698300023311120529 cdcgs1vis

Value Set Name – Funding Eligibility Observation Method (IIS)

Value Set OID – 2.16.840.1.114222.4.11.6039

Value Set Code: PHVS_FundingEligibilityObsMethod_IIS

Value set definition: The Funding Eligibility Observation Method identifies the method for capturing

funding program eligibility. Note that it is always reported at the immunization level. Used in OBX- 17

Concept Names Concept code Code System Identifier –

HL7 Table 0396

Eligibility captured at the immunization

level

VXC40 CDCPHINVS

Eligibility captured at the visit level VXC41 CDCPHINVS

Value Set Name – VIS Vaccines (IIS)

Value Set OID – 2.16.840.1.114222.4.11.6040

Value Set Code:: PHVS_VISVaccines_IIS

Value set definition: This table lists the vaccines which require that a Vaccine Information Statement (VIS)

be shared with a patient/parent. The VIS document type, edition date and presentation date are reported in a

set of OBX. The current list will be found on PHIN VADS, as the list may change over time.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 63 
Change History

Table 1 — CVX Codes of Vaccines Requiring VIS Recording

CVX Description Code System Table 0396 code

106 DTaP, 5 pertussis antigens CVX

146 DTaP,IPV,Hib,HepB CVX

110 DTaP-Hep B-IPV CVX

50 DTaP-Hib CVX

120 DTaP-Hib-IPV CVX

130 DTaP-IPV CVX

52 Hep A, adult CVX

83 Hep A, ped/adol, 2 dose CVX

104 Hep A-Hep B CVX

08 Hep B, adolescent or pediatric CVX

42 Hep B, adolescent/high risk infant CVX

43 Hep B, adult CVX

44 Hep B, dialysis CVX

49 Hib (PRP-OMP) CVX

48 Hib (PRP-T) CVX

51 Hib-Hep B CVX

118 HPV, bivalent CVX

62 HPV, quadrivalent CVX

135 Influenza, high dose seasonal CVX

111 influenza, live, intranasal CVX

141 Influenza, seasonal, injectable CVX

140 Influenza, seasonal, injectable,

preservative free

CVX

144 influenza, seasonal, intradermal,

preservative free

CVX

10 IPV CVX

148 Meningococcal C/Y-HIB PRP CVX

136 Meningococcal MCV4O CVX

114 meningococcal MCV4P CVX

32 meningococcal MPSV4 CVX

03 MMR CVX

94 MMRV CVX

133 Pneumococcal conjugate PCV 13 CVX

100 pneumococcal conjugate PCV 7 CVX 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 64 
Change History

CVX Description Code System Table 0396 code

119 rotavirus, monovalent CVX

116 rotavirus, pentavalent CVX

138 Td (adult) CVX

113 Td (adult) preservative free CVX

09 Td (adult), adsorbed CVX

115 Tdap CVX

21 varicella CVX

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 65 
Appendix B: Guidance on Usage and Example Messages

Appendix B – Guidance on Usage and

Example Messages

Table B-1 Appendix B Revision History

Revision History

Author Revision Date

Rob Savage Release 1 5/1/2010

Rob Savage Release 1.1 2/15/2011

Rob Savage Release 1.3 8/15/2011

Rob Savage Release 1.4 8/1/2012

Rob Savage Release 1.5 10/1/14

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 1 
Appendix B: Guidance on Usage and Example Messages

Core Data Elements for an Immunization History

A number of core data elements are messaged in OBX (observation segments). While they are not directly

specified in the HL7 standards, they are crucial to support immunization information systems. The

following table lists all core data elements and indicates their usage.  
Table B-2–Immunization History Core Data Elements

Data Element Description Support

Status46

Location in

Message

Client Related Data Elements

Client Id A list of client identifiers for the

person that is the subject of a

given immunization history. The

id includes both a unique

identifier and the context/owner

of the identifier.

Required PID-3

Client Name A list of names for the subject of

the immunization history. The

name is composed of both the

names and the name type (legal,

alias, etc.)

Required PID-5

Mother’s Maiden Name The family name of the person’s

mother. This is an important key

to assuring an accurate match.

Required PID-6

Race Patient’s self reported race. Required PID-10

Ethnicity Patient’s self reported ethnicity Required PID-22

Gender Patients gender Required PID-8

Birth date Date patient was born Required PID-7

Birth order If patient was part of a multiple

birth, this indicates the ordinal

position in that birth.

Required PID-24

Multiple Birth Indicator Indicates if person was member

of multiple birth.

Optional PID-25

Birth State The state the person was born in. Required PID-11

Birth facility  The name of the facility where

the person was born.

Required

Client address Address of the client’s residence Required PID-11

Client Phone List of telecommunication

numbers/address

Required PID-13

Client IIS status Indicates if client is currently Required PD1-16

46 Support Status indicates whether the field must be supported by the information system and messaged if known. It does not indicate

whether all messages must contain the data element. That is indicated in the usage column for each field. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 2 
Appendix B: Guidance on Usage and Example Messages

Data Element Description Support

Status46

Location in

Message

associated with the IIS

Client Provider organization status

(Registry status)

Indicates if client is currently

associated with the provider

organization

Required PD1-1647

Responsible person name A list of names of a responsible

person

Required NK1-2

Responsible person address Address of the responsible

person

Optional NK1-4

Responsible person relationship Relationship of the responsible

person to the patient/client

Required NK1-3

Responsible person phone Phone number of responsible

person

Optional NK1-5

Client Primary language Primary language of

client/patient

optional PID-15

Vaccination Related Data Elements

Vaccine administered product type Indicates which product

(vaccine) was administered

Required RXA-5

Vaccine product manufacturer Indicates the company which

manufactured the vaccine

Required RXA-17

Vaccine administered date Indicates the date that the

vaccine was administered

Required RXA-3

Vaccine Lot Number Indicates the lot number for the

vaccine administered

Required RXA-15

Vaccine Lot Expiration Date Indicates the expiry date for the

vaccine administered

Required RXA-16

Vaccine site of administration Indicates the body site where the

vaccine was administered

Required RXR-2

Vaccine route of administration Indicates the route that was used

to administer the vaccine

Required RXR-1

Vaccine ordering provider Indicates the clinician who

ordered the vaccination

Required ORC-12

Vaccine administering provider Indicates the clinician who

administered the vaccine

Required RXA-10

Vaccine Event information source Indicates whether the vaccine

was administered by the provider

organization recording the

immunization or obtained from a

Required RXARXA-9

47 PD1-16 indicates the status from the message sender’s perspective.  In the case of a message coming from a provider, it indicates if

the client is an active patient of that sender.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 3 
Appendix B: Guidance on Usage and Example Messages

Data Element Description Support

Status46

Location in

Message

historical record

Vaccine Information Sheet (VIS)

type

Indicates the subject of the VIS,

that is which vaccine(s) it refers

to

Required OBX-5

Vaccine Information Sheet (VIS)

version date

Indicates the publication date of

the VIS

Required OBX-5

Vaccine information Sheet date

given to client/responsible person

Indicates the date the VIS was

given to the patient/responsible

person

Required OBX-5

Patient Eligibility Category  for

Vaccine Funding Program

This value represents the funding

program that should pay for a

given immunization. It is

determined based on

characteristics of the

patient/client and the type of

vaccine administered.

Required OBX-5

Vaccine Funding Source Indicates the Funding Source of

the vaccine administered.  That is

was the vaccine administered

federally funded, privately

funded, etc.

Optional OBX-5

Observations About the Client

Contraindications/precautions A contraindication is categorical

indicator of the medical

conditions of the patient which

has that indicate that the patient

should not receive a vaccine.  A

precaution is a medical condition

of the patient that indicates the

clinician should make a

determination whether the

patient should receive the

vaccine.

Required OBX-5

Contraindication observation date Indicates the date that the

contraindication was noted

Required OBX-14

Exemption/refusal reason Indicates the reason the patient is

either exempt from the

immunization or refuses the

immunization.

Required RXA-18

Exemption / refusal date Date the patient refused or was

exempted from vaccination

Required RXA-3

Vaccine reaction A categorical indicator of an

adverse health consequence with

onset that follows immunization

Optional OBX-5

History of vaccine preventable Indicates a vaccine preventable Required OBX-5 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 4 
Appendix B: Guidance on Usage and Example Messages

Data Element Description Support

Status46

Location in

Message

disease disease that a patient has had

Date of history of vaccine

preventable disease

Indicates the date the disease

occurred (or was noted if onset is

uncertain)

Required OBX-14

Send Immunization History (VXU)

Business Process

The following activity diagram illustrates the process of sending and receiving an immunization history.  It

is meant to be illustrative and not prescriptive.  With the exception of the HL7 message structure processing

and the return of an acknowledgement, the activities are based on local business rules.  These rules must be

documented for smooth interoperability.  HL7 only addresses the messages, VXU and ACK.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 5 
Appendix B: Guidance on Usage and Example Messages 
Figure B-45-VXU Business Process 
1. The process for sending a VXU (Immunization history) begins with the sending system building

the VXU message.

2. The sending system connects to the receiving system and sends the VXU.

3. The receiving system accepts the message.

4. The receiving system parses the message and validates.

a. Determine if message meets HL7 rules

b. Validate based on local business rules48

5. Seek matching client in receiver data base

48 See Send Error in ACK for dealing with errors if either of these two tasks identifies problems. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 6 
Appendix B: Guidance on Usage and Example Messages

a. No match is found 49

i. Add the client to the receiver database.

ii. Send acknowledgement message50

b. Exactly one match found

i. Determine if client in receiver data base has indicated that his/her data is to be

protected (protection indicator = Y)51

ii. Protection indicator = Y

1. Do not integrate record into receiver data base

2. Send acknowledgement52

iii. Protection indicator = N

1. Based on local business rules, integrate incoming record into receiver

data base.

2. Send acknowledgement

c. More than one match found

i. Send acknowledgement53

6. Send acknowledgment to sending system

7. Sending system accepts acknowledgement message. 54

Note that sending system may indicate that it does not accept acknowledgement messages.  In this case, no

acknowledgement is returned.  This is not recommended.

It is expected that a client’s immunization history is the complete history known to the sending system, and

not just updates on new information in the sending system.  While some systems may send updates only,

the receiving system should make no assumptions about this. This has important implications for

processing those incoming records.  At the same time, the sending system may not know of all

immunizations, so receiving system must have a process for integrating the received data into an existing

record.  The Modeling Immunization Registry Operations Workgroup (MIROW) has produced a chapter of

best practices on this process. This is available on the American Immunization Registry Association web

site (www.immregistries.org).

The following example messages represent straightforward immunization history messages.  They do not

illustrate dealing with specific use cases, such as messaging reactions, client specific conditions or vaccine

forecasts.  Clearly, these may be components of a VXU, but will be addressed separately to simplify the

messages.

It is important to reiterate here that conformant systems should be able to successfully populate and process

the VXU message segments and fields identified as Required or Required but may be empty.  They should

be able to populate and process conditional items when the predicate conditions are met.  If segments or

fields are optionally repeating, they should be able to gracefully handle the repetitions.  Systems that do not

conform to these expectations risk missed data.

49 Local business rules determine what happens next, but we assume that it is a simple insert of the client record. The receiving system

may require review and confirmation prior to insertion.  Other systems may choose to require human review before adding to data

base.

50 See Send Acknowledgement with no error.

51 Locally, this may be known as the sharing indicator.  In this case, the equivalent value is sharing = N.

52 Local business rules may vary.  In general, the acknowledgement may reject the client record, but not indicate the existence of the

client record in the receiver system.

53 Local business rules will determine how the multiple matches are to be handled.  The record could be put into a pending state,

rejected outright, loaded in as a new record for clean up later.

54 The sending system response to an acknowledgement message (ACK) is locally determined.  Good practice would be to have a way

to use the ACK to alert user to outcome and to allow trouble-shooting of problem messages.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 7 
Appendix B: Guidance on Usage and Example Messages

Example VXU # 1-Basic message:

Note that all example messages that follow are hand-crafted and may contain errors. They are not

the source of truth for message format and content.

Storyboard:

On 01/13/2012 Mom brought her son ,Johnny New Patient (male), to the clinic. He was born 4/14/11 has

had 1 dose of Hep B on 4/15/11, according the medical record brought in by Mom (Sally Patient).  They

live at 123 Any Street, Somewhere, Wisconsin 54000.  Mom gives her maiden name as Lastname. Johnny’s

mom indicates that his Native American and not Hispanic. There home phone number is (111)232-0112.

Mom was given the Vaccine Information Sheet (VIS) that covered the following vaccine types:

• DTaP, IPV, Hib, PCV, Hepatitis B, and Rotavirus (publication date 11/16/12)

The clinician scanned the VIS bar code on the VIS (253088698300026411121116).

Nurse Sticker at Dalittle Clinic (name space id =DCS_DC), administers the following shots on 1/13/2012:

DTAP-Hep B-IPV (Pediarix), 0.5 mL,  lot # xy3939, lot expiration 12/12/14,  IM, right thigh

HIB (ActHIB) , 0.5 mL,  lot # 33k2a, lot expiration 03/09/13,  IM, left thigh

They were all ordered by Dr. Mary Pediatric who belongs to Dabig Clinical System (DCS).  Mom

acknowledged that his data may be shared with other providers.  Johnny is eligible for Medicaid.  His

medical record number in Dabig Clinical System is 432155.  Myron Clerk entered the information into the

EHRs (MYEHR).

The information was sent from Dabig Clinical System to the State IIS

Note that we will indicate the end of each segment with a .  Segments may wrap around in this

document.  We will insert a blank line between each segment for increased readability. 
Message Example

MSH|^~\&|MYEHR|DCS|MYIIS||201201130000-

500||VXU^V04^VXU_V04|45646ug|P|2.5.1|||ER|AL|||||Z22^CDCPHINVS  
PID|1||432155^^^dcs^MR||Patient^Johnny^New^^^^L|Lastname^Sally^^^^^M

|20110411|M||1002-5^Native American^HL70005|123 Any

St^^Somewhere^WI^54000^^L||^PRN^PH^^^111^2320112|||||||||2186-5^not

Hispanic^CDCREC 
NK1|1|Patient^Sally^^^^^L|MTH^Mom^HL70063|123 Any

St^^Somewhere^WI^54000^^L 
ORC|RE||65929^DCS|||||||^Clerk^Myron|| 
RXA|0|1|20110415||85^hep B,

unspec^CVX|999|||01^historical^NIP001|||||||||||CP|A 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 8 
Appendix B: Guidance on Usage and Example Messages

ORC|RE||65930^DCS||||||20120113|^Clerk^Myron||^Pediatric^Mary^^^^^^^

^^^^^^^^^^^MD|||||||||Dabig Clinic System

RXA|0|1|20120113||110^DTaP HIB IPV^CVX|0.5|mL^^UCUM||00^New

admin^NIP001|^Sticker^Nurse^^^^^^^^^^^^^^^^^^RN|^^^DCS_DC||||xy3939|

20141212|SKB^GlaxoSmithKline^MVX|||CP|A

RXR|C28161^IM^NCIT^IM^^HL70162|RT^Right Thigh^HL70163

OBX|1|CE|64994-7^Eligibility

Status^LN|1|V02^Medicaid^HL70064||||||F||||||VXC40^vaccine

level^CDCPHINVS

OBX|2|DT|29769-7^VIS presented^LN|2|20120113||||||F

OBX|3|CE|69764-9

^Document type^LN|2|253088698300026411121116^Multivaccine

VIS^cdcgs1vis||||||F

ORC|RE||65949^DCS||||||20120113|^Clerk^Myron||^Pediatric^Mary^^^^^^^

^^^^^^^^^^^MD|||||||||Dabig Clinic System

RXA|0|1|20120113||48^HIB PRP-T^CVX|0.5|mL^^UCUM||00^New

admin^NIP001|^Sticker^Nurse^^^^^^^^^^^^^^^^^^RN|^^^DCS_DC||||32k2a|2

0130309|PMC^sanofi^MVX|||CP|A

RXR|C28161^IM^NCIT^IM^^HL70162|LT^left Thigh^HL70163

OBX|4|CE|64994-7^Eligibility

Status^LN|1|V02^Medicaid^HL70064||||||F||||||VXC40^vaccine

level^CDCPHINVS

OBX|5|DT|29769-7^VIS presented^LN|2|20120113||||||F

OBX|6|CE|69764-9^Eligibility

Status^LN|2|253088698300026411121116^Multivaccine

VIS^cdcgs1vis||||||F

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 9 
Appendix B: Guidance on Usage and Example Messages

Example VXU #2 – Indicate client eligibility status for a funding

program for vaccines administered:

Federal regulations specify that Patient Eligibility status be assessed at each immunization encounter. It is a

key data element for creating the Vaccines for Children (VFC) report on vaccine usage. Support for this

report requires that systems store a history of eligibility statuses at the dose administered level.

Immunization messages must be able to convey the eligibility status of a recipient when they received

immunizations. That is, for each dose administered, the person’s eligibility should be recorded. Eligibility

refers to what funding program should pay for the vaccine.  This is distinctly different from funding source,

which refers to what funding program actually paid for the vaccine. This document will illustrate the

former.

Guidance for systems which collect eligibility at the encounter level:

Some systems may not have the capability to capture eligibility for each immunization administered. The

eligibility should be messaged using the OBX with each immunization record. Ideally, these systems would

know the vaccines that are VFC eligible (or state program eligible) and correctly associate VFC eligibility

with each vaccine administered. In practical terms if the person was VFC eligible because they were

covered by MEDICAID, and received 2 doses of vaccine, each vaccine record would have an associated

OBX segment. These segments would indicate V02 as the eligibility.

Patient Eligibility Status:

In the past, eligibility was recorded for each visit where a patient received an immunization. Recent

guidance from the Modeling Immunization Registry Operations Workgroup (MIROW) 55 has clarified that

the eligibility status of the patient should be recorded for each vaccine dose administered. It does not need

to be recorded for immunizations that represent a historical record of an immunization.

Sending systems which collect the eligibility status for each visit will need to associate the status recorded

for that visit on each immunization administered at that visit. They should consider if the vaccine

administered was eligible for the funding program when deciding what to assign as the eligibility for each

immunization.

The method of capture is messaged in OBX-17 (observation method). If the eligibility is captured by

vaccine dose, OBX-17 will be valued:

“VXC40^per immunization^CDCPHINVS”

If the method of capture is per visit, OBX-17 shall be valued:

“VXC41^per visit^CDCPHINV”

Patient Eligibility Status is conveyed in an OBX segment for each vaccine dose administered. While this

document will describe how to accomplish this in an HL7 message and give a high-level view of patient

eligibility status, readers should refer to the MIROW document for a complete understanding of correct

usage.

As described in the MIROW document, a variety of factors play a role in determination of Patient

Eligibility Status: VFC and grantee policies, age, private insurance coverage, type of provider, and type of

vaccine to be administered. For instance a person who was an Alaska Native receiving an MMR would

have an eligibility status code of V04. The following table gives a simplified view of the most common

cases.

55 http://www.aira.browsermedia.com/resources/AIRA-MIROW_DQA_Selected_Aspects_best_practice_guide_05-17-2013  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 10 
Appendix B: Guidance on Usage and Example Messages

Technical Note: The design of the information systems interface and validation functionality should ensure

a match between reported/messaged Patient Eligibility Status and administered Vaccine Eligibility Status –

they have to be eligible for the same funding program.  The following table is an illustration of the logic

found in table 0064.

Note that a person can’t be eligible for VFC and a state program for the same immunization. That is, only

one eligibility should apply to a given immunization.

Table B-2 — Eligibility Outcomes

Determined Patient

Eligibility

Vaccine type eligibility Record for patient

eligibility for vaccine

dose administered

VFC eligible (V02-V05) Vaccine type is eligible

for VFC (e.g. DTAP,

MMR, etc.)

V02-V05

Any patient eligibility

reason

Vaccine type is not

eligible for VFC ( e.g.

Yellow fever)

V01

Not VFC eligible (V01)

and no state or local

program applies.

Any V01

Eligible for state or

local vaccine program

and not eligible for VFC

Vaccine is eligible for

state or local program.

State or local eligibility

code.

The funding programs listed in table HL70064 are those associated with the Vaccines for Children program.

Local funding program eligibility would be published in the local Implementation Guide in table 0064. The

code V07 may be used if the person is not eligible for VFC funding program, but is eligible or a state or

local funding program. The use of locally specified codes may be preferable to provide more granular

information. If a locally defined funding program eligibility code is sent, then the person is presumed to be

not eligible for VFC funded vaccine.

The coding scheme uses codes in table HL70363 to indicate the assigning authority. The code is composed

of the code from table HL70363 and 2 character number assigned by the state (The state may add to this list

for other local assigning authorities. )

For example, if Alaska had a funding program and the person and vaccination met the eligibility criteria,

the code in OBX-5 would be as follows:

|AKA01^Alaska special eligibility^AKA|

AKA01 is the code. AKA in the third triplet is the assigning authority. The text is the second triplet is not

processed and so may be any text.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 11 
Appendix B: Guidance on Usage and Example Messages

The OBX segment indicating patient eligibility in association with the dose administered is composed of a

number of data elements. OBX-3 indicates that the segment contains patient eligibility status (LOINC

64994-7).  OBX-5 indicates the eligibility status. OBX-17 indicates the method of observation (per visit or

per immunization).

Technical note on LOINC code 64994-7:   
The formal short name for this LOINC code is “Vaccine fund pgm elig cat”, this means it is the

patient eligibility status associated with a vaccine dose administered.

The following message fragment indicates that the patient was eligible for VFC vaccine for the associated

vaccination because they were Native American/Alaskan Native and the vaccine administered was an

eligible vaccine type. The method of capture was per immunization.

VFC Eligible Client Received Vaccine That Is VFC eligible

RXA|0|1|…. 
RXR| … 
OBX|1|CE|64994-7^vaccine fund pgm elig cat^LN|1|V04^VFC eligible

NA/AN^HL70064||||||F|||20090531|||XVC40XVC40^per imm^CDCPHINVS  
VFC Ineligible Client Received Vaccine That Is VFC eligible

RXA… 
RXR … 
OBX|1|CE|64994-7^vaccine fund pgm elig cat^LN|1|V01^Not VFC eligible

^HL70064||||||F|||20090531||| XVC40XVC40^per imm^CDCPHINVS  
VFC Eligible Client Received Vaccine That Is Not VFC eligible

RXA… 
RXR… 
OBX|1|CE|64994-7^vaccine fund pgm elig cat^LN|1|V01^Not VFC elig

^HL70064||||||F|||20090531|XVC40XVC40^per imm^CDCPHINVS  
VFC Eligible Client Received Vaccine That Is Eligible for Local Funding Program

RXA… 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 12 
Appendix B: Guidance on Usage and Example Messages

RXR…

OBX|1|CE|64994-7^vaccine fund pgm elig cat^LN|1|AKA01^Alaska Special

Funding Program^AKA||||||F|||20090531|XVC40XVC40^per imm^CDCPHINVS



Example VXU #3 – Include immunization history evaluation and

forecast in VXU

It is uncommon that a VXU will include an evaluated history and forecast. Therefore there it is not an

example shown. The example has been removed. See QBP/RSP example below.

Example VXU #4 – Send client specific conditions

Evaluation of immunization history and forecasting next dose due are important services provided by many

IIS.  There are a number of factors that can impact these evaluations and forecasts. In general terms, some

factors contraindicate next doses, while others recommend next doses.  These factors may be messaged in

OBX segments associated with an RXA.

Reaction Associated with a Previous Dose of Vaccine

Some people experience adverse events after receipt of an immunization.  In many cases, Immunization

Information Systems (IIS) record these in conjunction with a specific immunization event.  Occasionally,

the exact immunization event information is unknown. (e.g. anaphylaxis occurred after a previous dose,

years in the past.)

Definition:

An adverse reaction is a negative physical condition that occurs shortly after one or more immunizations

have been received.

Adverse Reaction:

ORC|RE||9999^DCS|||||||^Clerk^Myron| 

RXA|0|1|20090412|20090412|998^No vaccine

administered^CVX|999||||||||||||||NA

OBX|1|CE|31044-1^Reaction^LN|1|39579001^Anaphylaxis^SCT

||||||F|||20090412

Evidence of immunity:

Infection with the diseases that are the target of immunizations leads to long-term immunity.  Further

immunization against the disease is not likely to provide benefit.

Definition:

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 13 
Appendix B: Guidance on Usage and Example Messages

Evidence of immunity indicates that a person has plausible evidence that they have already developed

immunity to a particular disease.  The strongest evidence of immunity is when serological evidence

indicates immunity. An alternative evidence of immunity is when a clinician has determined that the patient

has a history of the disease.

The example below shows that no dose of vaccine was given because the person had evidence of previous

infection with Hep B. 
ORC|RE||9999^DCS|||||||^Clerk^Myron|  
RXA|0|1|20090412|20090412|998^No vaccine

administered^CVX|999||||||||||||||NA 
OBX|1|CE|59784-9^Disease with presumed immunity ^LN|1|66071002^HISTORY

OF HEP B INFECTION^SCT||||||F|||20090412 
Contraindications to immunization:

There are a number of contraindications to immunization.  These may be temporary or permanent.  One is a

history of reactions to previous immunization.  That is dealt with above.  Others include allergies to

components of vaccines, physical conditions, current medication and current illnesses. 
Definition:

A contraindication is any physical condition, current medication or other factor that indicates that a person

should not receive an immunization that may be associated with the contraindication.  This contraindication

may be temporary or permanent.

LOINC: 30945-0 
Examples: 
OBX|1|CE|30945-0^Vaccination contraindication^LN|1|91930004^allergy

to eggs^SCT||||||F|||20090415 
OBX|1|CE|30945-0^Vaccination contraindication^LN|1|VXC19^allergy to

thimerasol(anaphylactic)^CDCPHINVS||||||F|||20090415 
Factors which indicate the need for an immunization or a changed

recommendation:

Several factors can drive the need for a specific immunization or a change in the normal schedule for

immunization.  These may be an exposure to an infection, such as rabies. Other risk factors may include

membership in a risk group. 
Definition:

A risk factor is some characteristic of an individual, which may lead to a recommendation for a specific

vaccine. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 14 
Appendix B: Guidance on Usage and Example Messages

OBX|1|CE|59785-6^Special Indication for

vaccination^LN|1|VXC7^exposure to

rabies^CDCPHINVS||||||F|||20090415

Example VXU #6 –Delete an Immunization Record

There are occasions when a system that has sent an immunization record to another system wishes to delete

the record on the other system.  Each system may have rules about the requester’s right to delete records.

If a system allows deletions by HL7 message, use the RXA-21, Action Code to request deletion of a

specific record.  The following diagram illustrates how the ORC-3 may be used to identify an

immunization record for deletion56.  Note that the sending system includes the sending system unique id for

the immunization in the ORC-3 first component.  The second component is the assigning authority, in this

case a system that is labeled MYIIS.  In order for a later delete request to be successful, the receiving

system must store those values.  A subsequent request to delete an immunization record includes the

sending system id and assigning authority.  The receiving system searches for an immunization record with

the same sending system id and assigning authority.  In this case we show that the record match is made

and the record is deleted from the receiving system.

Figure B-46 Sequence Diagram-Deleting an Immunization Record

56 The other approaches will not be further illustrated here.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 15 
Appendix B: Guidance on Usage and Example Messages

VXU Example #7–Send Information About Vaccine Information

Statement (VIS)

The Vaccine Information Statement (VIS) is a document that explains the reasons for a vaccine and the

potential risks from receiving the vaccine.  IIS track the fact that a VIS was shared with the client or parent.

There are three pieces of information about each event.

• The focus of the VIS or the VIS document type

• The date that the VIS was presented to the client/parent.

• The publication date (also known as Edition Date) of the VIS that was presented. 
These are carried in separate OBX segments associated with a vaccination event (RXA).  These OBX are

linked by the value in the sub-id field. (OBX-4) 
The VIS type may be indicated in one of two ways. The original way is to indicate the vaccine type in an

OBX using a CVX code. For a vaccine that is a combination of vaccines, there are often separate VIS for

each vaccine.  This may be handled by sending 2 sets of OBX, one for each vaccine component.  
This method will not allow reporting of presentation of the multi-vaccine VIS and so all systems are urged

to support the bar code approach illustrated below. 
The preferred method for indicating VIS type is based on a scanned bar code of a Global Document Type

Identifier (GDTI). The GDTI is composed of a document owner, an application, a document type identifier

and a check digit. The fully encoded text string of the GDTI will be sent in an OBX segment.  The mapping

of the fully encoded string will be found in a table supported by the CDC.  The publication date maybe

inferred from the fully encoded GDTI. Therefore only the presentation date and GDTI need to be sent. 
Example 1-Single vaccine (GDTI approach) 
RXA|…

OBX|1|CE| 69764-9^document type^LN|1|253088698300012711120420^MMR^

cdcgs1vis||||||F|||20091010 
OBX|2|TS|29769-7^VIS Presentation

Date^LN|1|20091010||||||F|||20091010 
In this example the person received a dose of MMR on 10/10/2009.  They received a VIS sheet on the same

day. The document had a publication date of 1/10/2008 (determined from the lookup table of VIS GDTI. 
Example 2-Combination vaccine, 2 VIS (GDTI approach) 
RXA|0|1|20091010||94^MMRV^CVX|… 
OBX|1|CE|69764-9^Document Type^LN|1|253088698300012711120420^MMR^

cdcgs1vis ||||||F|||20091010 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 16 
Appendix B: Guidance on Usage and Example Messages

OBX|2|TS|29769-7^VIS Presentation

Date^LN|1|20101010||||||F|||20091010

OBX|3|CE|69764-9^Document

Type^LN|2|253088698300024011080313^varicella^ cdcgs1vis

||||||F|||20091010

OBX|4|TS|29769-7^VIS Presentation Date^LN|3|20101010||||||F

This example shows that a person received an MMRV on 10/10/2009.  They received 1 VIS document for

MMR and one for Varicella.

Example 3-Single vaccine (vaccine type approach)

RXA|…

OBX|1|CE|30956-7^vaccine type^LN|1|03^MMR^CVX||||||F|||20120223

OBX|2|TS|29768-9^VIS Publication

Date^LN|1|20080110||||||F|||20120223

OBX|3|TS|29769-7^VIS Presentation

Date^LN|1|20091010||||||F|||20120223

In this example the person received a dose of MMR on 10/10/2009.  They received a VIS sheet on the same

day. The document had a publication date of 1/10/2008.

VXU Example #8—Send Information Indicating Immunization

Refusal

Clients or their parents may choose not to be immunized against a particular disease or diseases.  It is

important to share this information when sending immunization histories using HL7.  There are several

components to messaging a refusal.  The refusal reason is indicated in RXA-18.  The Completion Status in

RXA-20 indicates that the vaccine was not given. The amount given should be 0. The following example

illustrates how to accomplish this.

ORC|RE||9999^DCS|||||||^Clerk^Myron 

RXA|0|1|20091010||107^DTAP-NOS^CVX|999||||||||||||00^Parental

refusal^NIP002||RE

This example shows that on 10/10/2009 this client’s parent refused to have the child receive a DTAP

immunization.  Note that the ORC is still required. Filler Order Number is still required, but meaningless.

Note that RXA-2 is NOT used to indicate dose number, as it had in the past 2.3.1 Guide.  It is constrained

to have a value of 1.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 17 
Appendix B: Guidance on Usage and Example Messages

VXU Example #9—Send Two Lot Numbers in RXA

There are a number of situations when a vaccine has more than one lot number. The way these are recorded

depends on the specific situation. Each is defined below and guidance is given for recording lot number.

Two Vaccine Components Are Packaged Together And The Lot Numbers

Are Inextricable Linked 
There are occasions when two vaccines or a vaccine component, such as a diluent are combined at the time

of administration. This does not apply to the case where an adjuvant must be reported as well as the

vaccine. (See below) In most cases, the components are packaged together and the lot numbers of each

component are linked by the manufacturer. In this case record it is not necessary to message both lot

numbers.

For example, if we needed to include an immunization record where the vaccine was Pentacel, we would

put the lot number from the first component in sequence 15. The specific RXA field is highlighted below in

yellow.

Example:

RXA|0|1|20080907|20080907|120^DTAP-IPV-HIB^CVX^^^

|0.5|mL^^UCUM||00^NEW

IMMUNIZATION RECORD^NIP001|1234567890^SMITH^SALLY^S||

|||1234ad||PMC^Sanofi^MVX|||CP|A 
Adjuvant Is Recorded Separately From Vaccine

When a vaccine has an adjuvant added at the time of administration and their lot numbers are not

inextricably linked, it may be important to record each component as a separate event.  That is, each is

recorded in a separate RXA. The vaccine is recorded in one order group (ORC/RXA) and the adjuvant is

recorded in a second order group (ORC/RXA).

Example:

RXA|0|1|20140907|20140907|160^Influenza H5N1 -2013^CVX^^^

|0.5|mL^^UCUM||00^NEW

IMMUNIZATION RECORD^NIP001|1234567890^SMITH^SALLY^S||

|||1234ad||IDB^ID Biomedical^MVX|||CP|A  
RXA|0|1|20140907|20140907|801^AS03^CVX^^^ |0.5|mL^^UCUM||00^NEW

IMMUNIZATION RECORD^NIP001|1234567890^SMITH^SALLY^S||

|||455sd|| |||CP|A| 
VXU Example #10—Recording Birth Information

Birth information can be a powerful tool in identity resolution.  Components of birth information are listed

in the NVAC core data elements.  The information that can be carried in an HL7 message includes:

Table B-3–Birth Information Fields

Field HL7 message Component Example

Birth date PID-7 19500512

Birth Registration PID-3 (as one identifier in list) 12345^^^assigning authority^BR 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 18 
Appendix B: Guidance on Usage and Example Messages

Field HL7 message Component Example

Number

Birth order PID-24 2

Multiple Birth

Indicator

PID-25 Y

Birth State PID-11 (as one address in list, use

address type BDL)

^^^WI^^^BDL

Birth facility PID-23 Children’s Hospital

Note that Birth Facility is not used for Birth State.

VXU Example #11—Recording an incompletely administered

dose or a non-potent dose.

There are occasions when a dose is not completely administered.  For example a child may jump away

during injection and an unknown quantity was administered.  In this case, the dose needs to be recorded to

support accurate inventory management and to allow for recall of the client if there is a recall of the

vaccine.  This is accomplished using the Completion status in RXA-20.  The RXA is completed as usual,

but the completion status is set to PA.  If more details are of interest, then this information may be placed in

an NTE segment under an OBX segment.

RXA|0|1|20091010||03^MMR^CVX|0.5|mL^^UCUM||||||||A23E1||MSD^^MVX|||P

A|A

Send Acknowledgement ACK In Response To VXU

Sending an acknowledgement can accomplish one of a number of tasks.  It can indicate that the message

that was sent was successfully received and processed.  It can also indicate that the message had errors.

The ability to accept ACK messages allows sending system managers to trouble-shoot communications.  It

allows them to identify systematic problems with message creation.  Being able to send ACK allows

receiving system managers to inform sending system managers about the nature of errors received.  The

process can keep senders informed that some or all of the data they had sent did not make into the receiving

system.

It is vital that when messages are passed on by an intermediary, like a Health Information Exchange (HIE),

the ACK is passed back to the initiating system.

Errors may be of a number of types. The error may be caused by:

• a violation of an HL7 standard

• a violation of local processing rules

• a failure in the transport layer between the 2 systems

• a failure by the sending system to be authenticated by the receiving system

Only the first 2 types of errors are addressed by this Implementation Guide.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 19 
Appendix B: Guidance on Usage and Example Messages

Send acknowledgement of success in ACK

Initiating system may expect to receive an acknowledgment message, regardless of whether the receiving

system had problems with the message.  There is a straightforward response.

MSH|^~\&|DCS|MYIIS|MYIIS||200906040000-

0500||ACK^V04^ACK|1234567|P|2.5.1|||NE|NE|||||Z23^CDCPHINVS 

MSA|AA|9299381

In the example above, the system with the code DCS is sending an acknowledgement to the system with the

code MYIIS on June 4, 2009.  The message indicates that there were no errors in processing.  Note that

MSH-10 (Message Control ID) is unique identifier generated by the system sending the ACK.

Send Error in ACK

An error may be as serious as rejection of an entire message or as trivial as receipt of an

unexpected field of data. ACK messages are intended to inform the original sender of the

outcome of the message they had sent.

Acknowledging An Error That Causes Message Rejection ( AR response):

If a system received a message with an unrecognized version id (10.0, for instance) the system

would return an ACK with an application reject message.

MSH|^~\&|DCS|MYIIS|MYIIS||200906040000-

0500||ACK^V04^ACK|12343467|P|2.5.1|||

MSA|AR|9299381

ERR||MSH^1^12|203^unsupported version id^^HL70357|E||||Unsupported

HL7 Version ID—Message rejected

The AR response is reserved by HL7 for 4 errors:

o

o

o

o

Unsupported message type

Unsupported event code

Unsupported processing ID

Unable to process for reasons unrelated for format or content

Acknowledging An HL7 Processing Error That Causes Message Rejection (AE

response)

There are a number of errors that may cause message rejection when processing an HL7 message

that are based on HL7 rules.

• Empty or missing required (R) segment group

• Empty or missing PID segment or MSH segment (Required segments not in segment

group)

The following example reports that the PID-5 (patient name) was missing.  It is a required field.

This leads to rejection of the PID segment.  Because this is an error, the MSA-1 reports an error

(“AE”) . This error caused the receiving system to identify this as a serious error with data loss.

ERR-4 (severity) is set to ‘E’. Note that ERR-8 contains a free text note about the error.  These

are generated locally by the responding system. They may be standardized locally.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 20 
Appendix B: Guidance on Usage and Example Messages

MSH|^~\&|DCS|MYIIS|MYIIS||200906040000-

0500||ACK^V04^ACK|13434534|P|2.5.1||| 

MSA|AE|9299381

ERR||PID^1^5|101^required field missing^HL70357|E|7^required data

missing^HL70533||||Patient name is required 

ERR||PID|100^required segment missing^HL70357|E||||PID is required

segment. Message rejected 

Acknowledging An HL7 Processing Error That Causes Segment Group Rejection:

The following error illustrates a case where a required (R) field in a required(R) segment is

treated as empty. The segment is a child of a segment group.  The value in RXA-5 (administered

vaccine) is not valid causing the field to be treated as empty. Since it is an R field the segment is

treated as empty. RXA is child of the Order Segment group. Any segments in that order group

would be treated as empty. (RXR, OBX, NTE). If this is the only order group in the message,

then the entire message would be rejected.  The following assumes that there were other order

groups in the message.

MSH|^~\&|DCS|MYIIS|MYIIS||200906040000-

0500||ACK^V04^ACK|49348812|P|2.5.1

MSA|AE|9299381

ERR||RXA^1^5|103^table value not found^HL70357|E|5^table value not

found^HL70533||||Vaccine code not recognized—field rejected 

ERR||RXA^1^5|101^required field missing^HL70357|E|7^required data

missing^HL70533||||RXA-5 is required segment rejected

ERR||RXA|100^required segment missing^HL70357|E||||RXA is required

segment segment-group rejected 

Acknowledging An HL7 Processing Error That Causes Segment Rejection:

The following error illustrates a case where a required (R) field in a required but may be empty

(RE) segment is treated as empty. The value in NK1-3 (Relationship) is empty. Since it is an R

field the segment is treated as empty. NK1 is not a child of a Segment group. The message is not

rejected.

MSH|^~\&|DCS|MYIIS|MYIIS||200906040000-

0500||ACK^V04^ACK|49348812|P|2.5.1

MSA|AE|9299381

ERR||NK1^3|101^required field missing^HL70357|E|7^required data

missing^HL70533||||Relationship missing — segment rejected 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 21 
Appendix B: Guidance on Usage and Example Messages

Acknowledging An HL7 Processing Error That Caused a Warning :

A non-fatal error may occur for a number of reasons.  One example would occur when a field is

not supported and the message contains data in that field.  For instance, PID-2 (Patient Id) is not

supported. If the message had an identifier, then the system would generate an error.

MSH|^~\&|DCS|MYIIS|MYIIS||200906040000-

0500||ACK^V04^ACK|1234886|P|2.5.1

MSA|AA|9299381 
ERR||PID^2| |W||||PID-2 is not supported — data ignored 
The example above indicates that an error occurred in PID-2 (patient id).  The data were ignored,

but the initiating system is notified of the error.

Acknowledging an Application Error That Causes Message Rejection Due to Local

Business Rule Violation;

The following example shows an error that causes an error based on the application rules or

functioning. A local business rule may be that “The date of birth shall be on or before today.” If a

message were received with a birth date in the future for the patient, the application would

generate an error. The field would be treated as empty.  The field is a Required field in a Required

Segment (Not part of a segment group).  The message is rejected.

MSH|^~\&|DCS|MYIIS|MYIIS||200906040000-

0500||ACK^V04^ACK|9492823|P|2.5.1 
MSA|AE|9299381 
ERR||PID^1^7|101^required field missing^HL70357 |E|1^illogical date

error^HL700533|||| Birth data after today  
ERR||PID|100^required segment missing^HL70357|E||||PID is required

segment. Message rejected 

Example Return an Evaluated History and Forecast (RSP(Z42))

Evaluating an immunization history, based on the recommendations of the ACIP schedule or other schedule

is an important function provided by many IIS. Based on this evaluation and other factors,

recommendations may be made for next doses due. Some of their trading partners would like to receive the

outcome of this evaluation.  The previous implementation guide included a method for accomplishing this

using OBX segments, but showed it in a VXU.  This document illustrates how this is done in response to a

request and expands on the types of information that may be messaged.

A requesting system sends a query requesting and evaluated history and forecast for a specific person.

(QBP^Q11^QBP_Q11, profile id = Z44) If that person is found in the responding system, the responding

system evaluates the immunizations administered against a schedule (e.g. ACIP) and forecasts when next

doses are due. These are returned in an RSP message. (RSP^K11^RSP_K11, profile id = Z42) If an exact

match can’t be found an acknowledgement message is returned indicating no match or errors in the

message.

This document does not describe nor specify the functionality or accuracy of the forecasting service.  The

focus is only on the content of the messages.  Implementations should publish documentation on local

specifics. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 22 
Appendix B: Guidance on Usage and Example Messages

This document is not meant to support a call to a forecasting and evaluation service.  It is meant to support

existing applications that message vaccine forecasts and evaluation as a part of a complete immunization

history.

When a clinician evaluates a person’s immunization history and makes recommendations, she/he must use

a standard (schedule).  Traditionally, clinicians have evaluated based on vaccine groups or families.  The

schedule has one or more sets of immunization events that can be satisfied to indicate protection against the

diseases of the vaccine group of interest.  These constitute a series.

The following table lays out the information needed to convey an evaluation and forecast.

Table B-3–Codes Supporting Messaging Evaluation and Forecasting

Data element Use OBX-3 Value Optionality for

meaningful evaluation

and forecast57.

Schedule Identifies the standards

used.  ACIP is the

prototypical example.

59779-9 Required

Vaccine

group/family

Identifies which diseases

are expected to be

prevented by completion

of series.

Vaccine type 30956-7

Combination vaccine

component 38890-058

Required

Series name Name of the specific set

of doses and

recommendations that

were used to evaluate

this dose and make

recommendations.

59780-7 Optional

Ordinal position

in primary

series

Indicates which dose in

a series this given

immunization fulfills.

30973-2 Required

Dose Validity Indicates if this dose was

given appropriately for

this series in this

schedule.

59781-5 Optional

Number of

doses in

primary Series

Indicates how many

appropriately given

doses are required to

meet the goals of this

series.

59782-3 Optional

57 This does not mean that every message must have one of the required OBX.  It just means that this concept needs to be known to put

the evaluation and forecast in context.

58 Vaccine type 30956-7 is preferred, but support for 38890-0 is needed to support backward compatibility.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 23 
Appendix B: Guidance on Usage and Example Messages

Data element Use OBX-3 Value Optionality for

meaningful evaluation

and forecast57.

Note that in the case

where there are doses

that may be skipped, due

to the age of the

client/patient, the

number shall reflect the

adjusted number of

doses.

Series Status This indicates the status

of the client’s progress

toward meeting the

goals of the series

selected.  This could be

complete, overdue, in

progress, etc.

59783-1 optional

Next dose

forecast

Earliest date dose should

be given.

30981-5 Required for forecast

Date next dose

recommended

30980-7

Latest date next dose

should be given

59777-3

Date dose is overdue 59778-1

Reason code This can indicate why a

dose is not valid or that

the recommendation was

changed because of a

special circumstance.

30982-3 Optional

It is important to note that evaluation relates to doses received, but recommendations relate to doses not yet

given.  Each will be addressed separately.  Evaluation will be associated with an immunization received.

Recommendations will be associated with future events.  That is, they will be associated with an RXA that

indicates that no dose was given.  They will not be associated with existing immunization records (RXA).

This means that if a person has received one hep B dose (valid).  The evaluation will be associated with the

first RXA indicating that she/he received the dose.  The OBX following this will indicate the evaluation.

The recommendations for the next dose due will be associated with a second RXA.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 24 
Appendix B: Guidance on Usage and Example Messages

There are other factors relating to forecasting, such as exemption and previous immunity.  These are dealt

with in the client specific conditions impacting forecasting.

When a given dose is evaluated against a schedule, we can make a number of observations about it.  Each

dose of vaccine recorded is transmitted in an RXA segment.  Each RXA segment may have one or more

OBX, observation segments.  Each distinct piece of information is found in its own OBX segment and

follows its associated RXA.

Note that the order of the OBX segments is not regulated. The receiving system will need to link the OBX

with the appropriate data elements.

The basic structure for including evaluation in a message is:

ORC-Order segment

RXA-the immunization and vaccine

OBX-vaccine group

OBX-the schedule

OBX-series used

OBX-dose number in series (ordinal position)

OBX-doses in series

OBX-dose validity

OBX-series status

The basic structure for evaluation of combination vaccine components is:

ORC-order segment

RXA-the immunization and vaccine

OBX-vaccine group one59

OBX-the schedule

OBX-series used

OBX-dose number in series (ordinal position)

OBX-doses in series

OBX-dose validity

OBX-vaccine group two 60

OBX-the schedule

OBX-series used

59 All of the related observations are linked to the vaccine group using the OBX-4, observation sub-id.

60 All of the related observations are linked to the vaccine group using the OBX-4, observation sub-id.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 25 
Appendix B: Guidance on Usage and Example Messages

OBX-dose number in series (ordinal position)

OBX-doses in series

OBX-dose validity

OBX-series status

The basic structure for the recommendation in the message is:

ORC-order segment

RXA-vaccine, CVX-Unspecified formulation (no dose given)

OBX-the schedule

OBX-the series used

OBX-dose number in the series

OBX-number of doses in the series

OBX-earliest next dose due

OBX-recommended next dose due

OBX-overdue next dose due

OBX-series status

This document will first illustrate how to build each OBX to support reporting the key information. The

next section will show how to put these pieces together to create evaluation and recommendations in RSP

message.  Note that the same approach may be used in a VXU.

Indicating the Schedule that was used:

Evaluation is only meaningful in the context of a defined schedule. Schedule is a required element in a

message that is carrying evaluation or recommendation information.

The only schedule supported by CDC is the ACIP schedule.  Some systems may choose to develop other

schedules that meet local needs.  We assume that ACIP is the schedule used in our examples.

There are no differences between recommendation and evaluation in the OBX indicating the schedule used.

The following example shows that the ACIP schedule was used to evaluate this immunization.

ORC|RE||197027^DCS|||||||^Clerk^Myron||^Pediatric^MARY^^^^^^^L^^^^^^

^^^^^MD

RXA|0|1|20090412|20090412|48^HIB PRP-T^CVX|0.5|mL^^UCUM||00^new

immunization

record^NIP0001|^Sticker^Nurse|^^^DCS_DC||||33k2a||PMC^sanofi^MVX|||C

P|A

RXR|C28161^IM^NCIT^IM^IM^HL70162|

OBX|1|CE|59779-9^Schedule

used^LN|1|VXC16^ACIP^CDCPHINVS||||||F|||20090415

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 26 
Appendix B: Guidance on Usage and Example Messages

Indicating Vaccine Group associated:

Evaluation and forecast are considered by vaccine group.  Some immunizations are composed of one

vaccine group while others are combinations of several vaccine groups.  The first is more straightforward

when constructing a message.  The second requires 2 sets of observations, one for each vaccine group. The

vaccine group is indicated in an OBX.  All following OBX relate to that vaccine group, using the OBX-4

Observation sub-id.

Single Vaccine group Vaccine:

RXA|0|1|20091010||03^MMR^CVX|0.5|mL^^UCUM||||||||EZ342|20111001|MSD^

^MVX|||CP|A

OBX|1|CE|30956-7^vaccine type^LN|1|03^MMR^CVX||||||F|||20091010

In the case where a combination vaccine is given, each vaccine group is identified and has segments

describing its evaluation.  This case requires that the information about each vaccine group be handled

separately.  Each vaccine group is associated with a group of OBX, using the OBX-4 observation sub-id.

Combination vaccine:

RXA|0|1|20091010||94^MMRV^CVX|0.5|mL^^UCUM||||||||EZ342|20111001|MSD

^^MVX|||CP|A

OBX|1|CE|30956-7^vaccine type^LN |1|21^Varicella^CVX||||||F

… evaluation observations about this vaccine group

OBX|4|CE|30956-7^vaccine type^LN |2|03^MMR^CVX||||||F

… evaluation observations about this vaccine group

Note that the vaccine group could also be indicated with 38890-0^Component Vaccine Type^LN.

Reporting the Ordinal Position In A Series:

Evaluation:

Reporting the ordinal position in a selected series may be reported in an OBX segment.  The ordinal

position is the dose number being satisfied by a given immunization.  (dose #1 in a 3 dose series)  The next

section illustrates how to report the expected number of doses in the series. (3 in the example above)  It

would be empty for a booster dose and for doses which are not valid.

ORC|RE||197027^DCS|||||||^Clerk^Myron||^Pediatric^MARY^^^^^^^L^^^^^^^^^

^^MD

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 27 
Appendix B: Guidance on Usage and Example Messages

RXA|0|1|20090412|20090412|48^HIB PRP-T^CVX|0.5|mL^^UCUM||00^new

immunization

record^NIP0001|^Sticker^Nurse|^^^DCS_DC||||33k2a||PMC^sanofi^MVX|||CP|A



RXR|C28161^IM^NCIT^IM^IM^HL70162|

OBX|1|CE|30956-7^vaccine type^LN|1|17^HIB, NOS^CVX||||||F

OBX|2|CE|59779-9^Immunization Schedule

used^LN|1|VXC16^ACIP^CDCPHINVS||||||F|||20090415

OBX|3|NM|30973-2^dose number in series^LN|1|1||||||F|||20090415

Recommendation:

There is a different code to be used for indicating the number of the next dose due.

Note that the preferred LOINC codes are not vaccine group specific.  The use of old vaccine specific

LOINC should not occur.  For example, 30936-9 DTaP/DTP dose count in combination vaccine

should not be used.

Reporting the Number of Doses in a Series:

There are no differences between recommendations and evaluations when reporting number of doses in

series.  This numeric field indicates the number of doses required to meet the goals of the primary series for

this vaccine group.  It would be empty for a booster dose.

OBX|1|NM|59782-3^number of doses in

series^LN|1|1||||||F|||20090415

Reporting Next Dose Recommendation Dates (forecast only):

Forecasting next dose due is an important function that can be reported in a message.  There are a number

of key dates that can be communicated:

Table B-4–Due Date Definitions

Date type Definition

The earliest acceptable date based on the schedule

used

This is the earliest date that a person should

receive the next dose for the vaccine group.  It

does not include any grace period.  For example,

the earliest data a person should receive a DTAP is

age 42 days.

The recommended date This is the date that a person should ideally receive

the next dose for the vaccine group.

The overdue date (the date the person is considered

late for getting the vaccine)

This is the date that the person is considered late

for getting the next dose for the vaccine group.  It

is a locally defined value.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 28 
Appendix B: Guidance on Usage and Example Messages

Date type Definition

The latest date that a dose should be given (e.g. for

HIB it is currently 5 years old)

This is the last possible date that a person should

receive the next dose for the vaccine group.

Generally, this is related to age of recipient.  For

example the oldest a person should receive a dose

of HIB is 5 years old.

Not all dates may be relevant and so may be omitted.

RXA|0|1|20090412|20090412|998^No vaccine administered^CVX|999|||

||||||||||NA

OBX|1|CE|30956-7^vaccine type^LN|1|17^HIB, NOS^CVX||||||F

OBX|2|CE|59779-9^Immunization Schedule

used^LN|1|VXC16^ACIP^CDCPHINVS||||||F|||20090415

OBX|3|DT|30980-7^Date vaccination

due^LN|1|20090615||||||F|||20090415

OBX|4|DT|59777-3^Latest date to give

vaccine^LN|1|20100615||||||F|||20090415

Reporting Recommendation Reasons:

Sometimes a dose may break a specific rule in the schedule. Alternatively conditions may trigger special

rules, such as the need for accelerating the recommendations to catch up with the preferred schedule.  This

may be reported from the system in a message.  The list of values is locally determined.  These should be

documented locally.

Local Codes drive the answers.

Complete Example Of Evaluation And Forecasting:

MSH|^~\&|MYEHR|DCS|||200910311452-

0500||RSP^K11^RSP_K11|3533469|P|2.5.1|||NE|NE|||||Z42^CDCPHINVS|DCS



MSA|AA|793543

QAK|37374859|OK|Z44^request evaluated Immunization

history^CDCPHINVS

QPD| Z44^Request Evaluated Immunization History^CDCPHINVS

|37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20090

214|M|10 East Main St^^Myfaircity^GA^^^L

PID|1||123456^^^MYEHR^MR|| Child^Bobbie^Q^^^^L||20090214|M|||10 East

Main St^^Myfaircity^GA^^^L

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 29 
Appendix B: Guidance on Usage and Example Messages 
ORC|RE||197023^DCS|||||||^Clerk^Myron|||||||DCS^Dabig Clinical

System^StateIIS 
RXA|0|1|20090415132511|20090415132511|31^Hep B Peds

NOS^CVX|999|||01^historical record^NIP0001|||||||||||CP|A  
OBX|1|CE|30956-7^vaccine type^LN|1|31^Hep B Peds NOS^CVX ||||||F 
OBX|2|CE|59779-9^Immunization Schedule

used^LN|1|VXC16^ACIP^CDCPHINVS||||||F|||200900531 
OBX|3|NM|30973-2^dose number in series^LN|1|1||||||F|||200900531 
OBX|4|NM|59782-3^number of doses in series^LN|1|3||||||F|||20090531 
ORC|RE||197027^DCS|||||||^Clerk^Myron||^Pediatric^MARY^^^^^^^L^^^^^^

^^^^^MD 
RXA|0|1|20090731132511|20090731132511|48^HIB PRP-

T^CVX|0.5|ML^^UCUM||00^new immunization

record^NIP0001|^Sticker^Nurse|^^^DCS_DC||||33k2a||PMC^sanofi^MVX|||C

P|A 
RXR|C28161^IM^NCIT^IM^IM^HL70162| 
OBX|5|CE|30956-7^vaccine type^LN|2|17^HIB NOS^CVX ||||||F 
OBX|6|CE|59779-9^Immunization Schedule

used^LN|2|VXC16^ACIP^CDCPHINVS||||||F|||200900731 
OBX|7|NM|30973-2^dose number in series^LN|2|1||||||F 
OBX|8|NM|59782-3^number of doses in series^LN|2|4||||||F 
ORC|RE||197028^DCS|||||||^Clerk^Myron||^Pediatric^MARY^^^^^^^L^^^^^^

^^^^^MD 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 30 
Appendix B: Guidance on Usage and Example Messages

RXA|0|1|20091051132511|20091051132511|110^DTAP-Hep B-

IPV^CVX|0.5|ML^^UCUM||00^new immunization

record^NIP0001|^Sticker^Nurse|^^^DCS_DC||||xy3939||SKB^GSK^MVX|||CP<
CR>

RXR|IM^IM^HL70162^C28161^IM^NCIT|

OBX|9|CE|30956-7^vaccine type^LN|1|31^Hep B Peds NOS^CVX ||||||F

OBX|10|CE|59779-9^Immunization Schedule

used^LN|3|VXC16^ACIP^CDCPHINVS||||||F|||200900531

OBX|11|NM|30973-2^dose number in series^LN|3|2||||||F

OBX|13|NM|59782-3^number of doses in series^LN|3|3||||||F

OBX|14|CE|30956-7^vaccine type^LN|4|10^IPV^CVX ||||||F

OBX|15|CE|59779-9^Immunization Schedule

used^LN|2|VXC16^ACIP^CDCPHINVS||||||F|||200901031

OBX|16|NM|30973-2^dose number in series^LN|4|1||||||F

OBX|17|NM|59782-3^number of doses in series^LN|4|4||||||F

OBX|18|CE|30956-7^vaccine type^LN|5|20^DTAP^CVX ||||||F

OBX|19|CE|59779-9^Immunization Schedule

used^LN|5|VXC16^ACIP^CDCPHINVS||||||F

OBX|20|NM|30973-2^dose number in series^LN|5|1||||||F

OBX|21|NM|59782-3^number of doses in series^LN|5|5||||||F

ORC|RE||197023^DCS|||||||^Clerk^Myron|||||||DCS^Dabig Clinical

System^StateIIS

RXA|0|1|20091031|20091031|998^no vaccine admin^CVX|999|||

|||||||||||NA 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 31 
Appendix B: Guidance on Usage and Example Messages 
OBX|22|CE|30956-7^vaccine type^LN|1|31^Hep B Peds NOS^CVX ||||||F 
OBX|23|CE|59779-9^Immunization Schedule

used^LN|1|VXC16^ACIP^CDCPHINVS||||||F 
OBX|24|DT|30980-7^Date vaccination due^LN|1|20091015||||||F

Important notes:

1. Note that the OBX set id increases for each OBX through out the message

2. The observation sub-id holds to one value for each related set of observations under the vaccine

group OBX.

3. Either of the LOINC for vaccine group could have been used under the combination vaccine

(30956-7 (vaccine type) or 38890-0 (component vaccine type)), but 30956-7 is preferred.

4. If VIS observation (OBX) is included in the above message, it requires its’ own OBX with vaccine

group and has a different sub-id from the evaluation observations.

Using The NTE Segment Associated With An OBX To Provide More

Information:

Each OBX may have an associated NTE segment.  This may be used for sending notes or comments that

the receiving system may choose to display to a user.  Any use of this is local and requires local

documentation. 
Issues That Are Outside Of Messaging But Impact The Value Sent In A Message

1. There are some series where doses may be skipped.  For instance a person who gets significantly

behind on some HIB series may skip a dose and complete “early”.  Local profiles should specify

how these doses will be handled and messaged.

2. Some vaccines have a numbered primary series and are followed by intermittent booster doses.

These do not increase the number of doses in the primary series.

3. Persons who have been previously infected may not need further doses of vaccine.  This can be

messaged in an OBX reporting client immunity.

Send Request for Complete Immunization History (QBP/RSP)

Process for requesting Immunization History

Requesting an immunization history is a key function supported by messaging.  As described above, a

complete immunization history includes all the information needed for evaluating what immunizations

have been received and what ones are needed next.  This query is defined in a Query Profile in Chapter 7 of

the Implementation Guide.  The requesting system sends a request with some combination of demographic

and identifier information.

When a client is does not want his/her data shared and is found, local business rules need to be applied.  For

instance, some applications may behave as if the client record does not exist in the system.  That is, it

would respond with a “no records found” message.  The exception to this would be if the requesting

provider were the one who set the protection indicator.  In this case, the person may be a candidate that is 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 32 
Appendix B: Guidance on Usage and Example Messages

returned.  Another response might be to send limited information notifying the requesting system that the

person exists, but wants his/her records protected.

The sending system must deal with the returned messages.  While it is outside the scope of this

implementation guide, there are some logical actions.  These actions should be documented locally. The

following indicate some of the possibilities.  The list is neither prescriptive nor complete.

• One candidate immunization history is returned.

o

o

o

User reviews and accepts

User reviews and rejects

Requesting system accepts and marks for review.

• A list of candidates are returned

o

o

o

User reviews and selects one

· New QBP is sent using the identifying information from the RSP list

User reviews and rejects all

· User creates a new query with more or different information

Requesting system accepts and stores the list for later review.

The following is an example query using the QBP^Q11 Z34 query profile specified in the Implementation

Guide.

MSH|^~\&|||||201405150010-

0500||QBP^Q11^QBP_Q11|793543|P|2.5.1|||||||||Z34^CDCPHINVS 

QPD| Z34^Request Immunization History^CDCPHINVS

|37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050

512|M|10 East Main St^^Myfaircity^GA^^^L

RCP|I|5^RD&records&HL70126 

This query is being sent from a system with a name space identifier of MYEHR.  It is requesting an

immunization history for a person named Bobbie Q Child.  His mother’s maiden name was Suzy Que.  He

was born 5/12/2005 and lives at 10 East Main St, Myfaircity, Georgia.  His medical record number with

MYEHR is 12345. The most records that the requesting system wants returned if lower confidence

candidates are returned is 5.  Processing is expected to be “immediate”.

Local implementations will specify which fields are required in the QPD. All fields have a usage of RE

(required, but may be empty).  This means that sending systems may populate any or all of these fields.

Receiving systems must accept values in any of these fields, but may specify which are required and which

will be ignored.

Returning a list of candidate clients in response to QBP^Q11 query

When a system receives a QBP^Q11 Request for Immunization History query, it may find one or more,

lower confidence candidates.  In this case it returns an RSP that contains a list of these candidates.  It

includes all pertinent information in PID, NK1 and PD1 segments.  If the number of candidates is greater

than the maximum number requested by the querying system or greater than the maximum number the

responding system allows to be returned, then an error acknowledgment will be sent. (See below)

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 33 
Appendix B: Guidance on Usage and Example Messages

Note that PID-1, Set Id, is required when returning a list of PID. It is incremented for each PID returned

(i.e. 1,2,3…)

The following example RSP message illustrates the case when 2 candidates have been found by the

responding system.  All known information for each candidate that can be included in PID, NK1 and PD1

segments is returned.  We assume that the medical record number sent in the query is not known to the

responding system.  If it were, it is unlikely that the responding system would find lower confidence

candidates.

The actual logic used to find the candidates is not specified by this document.  It may be as simple as exact

string and date matching or as complex as a probabilistic search algorithm.

MSH|^~\&|SOME_SYSTEM|A_Clinic |MYIIS|MyStateIIS|200911051000-

0500||RSP^K11^RSP_K11|37374859|P|2.5.1|||NE|NE|||||Z31^CDCPHINVS|

A_Clinic 

MSA|AA|793543

QAK|37374859|OK

QPD| Z34^Request Immunization History^CDCPHINVS

|37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050

512|M|10 East Main St^^Myfaircity^GA^^^L

NK1|1|Child^Susan|MTH^Mother^HL70063|^^Myfaircity^GA

PID|2||123456^^^MYStateIIS^SR||Child^Robert^^^^^L||20050512|M

This response includes 2 candidates that must be reviewed by the person requesting records.  If

they select a specific client and repeat the Request Immunization History query with the refined

information, they should receive a response that includes the complete immunization history from

the IIS.  Note the use of PID-1, set id.

Returning an immunization history in response to a Request for

Immunization History query

When the Request Immunization History query finds one high-confidence match, the matching client’s

immunization history is returned in the response.  The following example message shows a simple

response.  Note that this query could have been a secondary query that occurred after preliminary identity

resolution or a primary query with sufficient demographic data to permit matching.

MSH|^~\&|MYIIS|MyStateIIS|MYEHR|Myclinic|200911300200-

0500||RSP^K11^RSP_K11|7731029|P|2.5.1|||NE|NE|||||Z32^CDCPHINVS|MySt

ateIIS|Myclinic

MSA|AA|793543

QAK|37374859|OK| Z34^Request Immunization History^CDCPHINVS 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 34 
Appendix B: Guidance on Usage and Example Messages

QPD| Z34^Request Immunization History^CDCPHINVS

|37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050

512|M|10 East Main St^^Myfaircity^GA^^^L 
PD1||||||||||||N|20091130 
NK1|1|Child^Suzy^^^^^L|MTH^Mother^HL70063 
ORC|RE||142324567^YOUR_EHR|||||||^Shotgiver^Fred||^Orderwriter^Sally

^^^^^^^^^^^^^^^^^^MD 
RXA|0|1|20050725||03^MMR^CVX|0.5|mL^^UCUM||00^New Immunization

Record^NIP001 
RXR|SC^^HL70162 
Note that the response returned the medical record number from the MYEHR system. It also returned the

IIS id.

Acknowledging Query That Returns No Clients/Patients

Acknowledging a Query that finds no candidate clients

A well-formed query may find no matching candidates.  This is not an error, but should be acknowledged in

a response message.  The following example message shows how this may be done.  Note that the Request

Immunization History response grammar indicates that MSH, MSA, QAK and QPD are required segments. 
Figure B-47–Sequence Diagram Acknowledging Response Indicating No Matchesa 
QAK-2 indicates that no data were found that matched the query parameters. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 35 
Appendix B: Guidance on Usage and Example Messages

MSH|^~\&|MYIIS|MyStateIIS||MYEHR|200911302300-

0500||RSP^K11^RSP_K11|7731029|P|2.5.1|||NE|NE|||||Z33^

CDCPHINVS|MyStateIIS|MYEHR

MSA|AA|793543

QAK|37374859|NF|Z34^request Immunization history^CDCPHINVS

QPD| Z34^Request Immunization History^CDCPHINVS

|37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050

512|M|10 East Main St^^Myfaircity^GA^^^L

Acknowledging a query that finds more candidates than requested

The sending system sets an upper limit on the number of candidates it will accept in response to a query in

RCP-2. It expects that a responding system will send no more candidates that this number. In addition, the

responding system may have an upper limit on the number of candidates that it will return. This number

may be lower than the requesting system. It will trump the requesting system upper limit. In either case, if

the responding system finds more candidates than the upper limit, then it responds with and

acknowledgement indicating that too many candidates were found.  QAK-2 indicates that there were too

many candidates found that matched the query parameters.

MSH|^~\&|MYIIS|MyStateIIS||MYEHR|200911300000-

0500||RSP^K11^RSP_K11|7731029|P|2.5.1|||NE|NE|||||Z33^CDCPHINVS|MySt

ateIIS|MYEHR 

MSA|AA|793543

QAK|37374859|TM|Z34^request Immunization history^CDCPHINVS

QPD| Z34^Request Immunization History^CDCPHINVS

|37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050

512|M|10 East Main St^^Myfaircity^GA^^^L

Using a Two-step process to request an immunization history

The IHE profile defines 2 queries for obtaining an ID of interest.  One query requests an id based on the

demographic information included in the query (PDQ, using the Pediatric Demographic profile).  When a

match is found, it returns the relevant id and demographic information. The other query seeks an id for a

person from one registered provider based on the id from another registered provider (PIX).

The use of the IHE Patient Identification Cross-Referencing (PIX) and

Patient Demographic Query (PDQ) transactions is an alternative approach

which separates retrieval/update of a patient identifier and

retrieval/update of immunization data into two messaging transactions.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 36 
Appendix B: Guidance on Usage and Example Messages

A Patient Demographic Supplier may be a Master Person Index or other source of patient demographic and

identification information.  While we will focus on an MPI below, any Patient Demographic Supplier may

be substituted.

A Master Person Index is a database that contains demographic and locating information of registered

persons and associates each person with the identifiers for the person from each of the participating

systems.  This allows one system to request the identifier for a person that was assigned by another system.

This id may be used to request data from that second system and assures a positive match.

Systems that participate in an MPI should register each person they are interested in with the MPI.  An

excellent profile for maintaining and interacting with an MPI has been published by the group, Integrating

the Healthcare Enterprise (IHE).  That profile will not be replicated here.  However, the process for

requesting personal identifier outlined below is based on that profile.

Adding a patient record to an MPI is done by a PIX transaction using an ADT message.  This method may

be used by an EHR or by an IIS, or both, to add a patient identifier to an MPI.  The PIX profile, described

in the IHE Technical Framework Volume I, includes specific transactions that describe the segments and

fields to be used.   These ADT-based transactions are described in the IHE Technical Framework Volume

II.   The standard transaction used by PIX is ITI-8, which uses an HL7 V2.3.1 ADT.  The Pediatric

Demographics Option, described at this writing in a supplement to PIX and PDQ, is preferred for

interactions with MPIs managing IIS data. The use of the Pediatric Demographics Option adds ITI-30,

which uses an HL7 V2.5 ADT.

Once a person has been registered with the MPI, a PIX Query may be used to retrieve the cross-referenced

IIS identifier (if any).

The following diagram illustrates the use of the PIX query to get a pre-registered patient identifier.  This

requires that the cross-referenced identifiers are registered using the ADT message. 
Figure B-48– Sequence Diagram -Two Step Request 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 37 
Appendix B: Guidance on Usage and Example Messages

Note that this interaction is simplified. The initiating system sends a request for a patient identifier. The

request includes one identifier in a PID-3. The identity supplier looks for a matching identifier of interest

and returns it along with the patient name (PID-5).  This information is included in the request

immunization history query (QBP^Q11).  Assuming that the identifier used is the one in the immunization

history supplier, there should be a one to one match.

If the EHR wishes to retrieve the IIS id without previously registering the patient with the MPI, or if it

wishes to query the MPI by demographics for some other reason, it may use a Patient Demographics Query

to do so.

The following diagram illustrates the use of PDQ to obtain an id and how this would be used to request an

immunization record.  The record seeker uses a Patient Demographic Query (PDQ) to a Master Person

Index (MPI), requesting the identifiers for the person of interest.  The MPI finds the person of interest and

returns the demographic information and identifiers. The record seeker system uses this information to

create a request for immunization history, which it sends to the record source.  The record source uses this

information to find the immunization history for the person of interest.

Figure B-49—Sequence Diagram- Request Immunization History using PDQ

Note that this interaction is simplified. The client of interest would be selected and that client’s information

would populate the query requesting an immunization history.  To be assured of success, the record source

system would need to have registered the person in the MPI.  In that way the person id in the record source

would be available in the MPI.

Receiving system determines that message has errors

HL7 Message Rule Errors

There are two classes of error related to HL7 message rules.  The first is when a message is well formed,

but the query has errors in content or format. The second occurs when the message is malformed and

cannot be parsed by the recipient.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 38 
Appendix B: Guidance on Usage and Example Messages

The following examples illustrate how each is reported.

Content or Format Error

Initiating Query:

MSH|^~\&||SendingOrg||ReceivingOrg|20091130000-

0500||QBP^Q11^QBP_Q11|793543|P|2.5.1|||ER|AL|||||Z34^CDCPHINVS|

SendingOrg|ReceivingOrg

QPD|Z34^Request Immunization

History^CDCPHINVS||123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^

^^M|20050512|M|10 East Main St^^Myfaircity^GA^^^L

Note that only the MSH and QPD segments will be displayed above. The QPD does not have data in a

required field, the Query Tag field (QPD-2).

MSH|^~\&|MYIIS|ReceivingOrg||SendingOrg|200911300000-

0500||RSP^K11^RSP_K11|7731029|P|2.5.1|||NE|NE|||||

Z33^CDCPHINVS|ReceivingOrg|SendingOrg 

MSA|AE|7731029

ERR||QPD^1^2|101^required field missing^HL70357|E

QAK||AE|Z34^CDCPHINVS

QPD| Z34^Request Immunization History^CDCPHINVS

||123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050512|M|10

East Main St^^Myfaircity^GA^^^L

Note that QAK-1 Query tag is empty in this case, because it was missing in the initiating query.

Message Is Rejected Due to Unrecognized Message Type

When a message is received that is an unrecognized message type, the response is an ACK with AR in the

MSA-1 (Acknowledgement Code)

MSH|^~\&|MYIIS|MyStateIIS||MYEHR|200911301000-0500||ACK^Q11^ACK||P



MSA|AR|

This message indicates that the application rejected the message.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5) 10/1/2014 Page 39 
	Table of Contents

	Index of Tables

	Table of Figures

	1.  Introduction

	Intended Audience

	Scope

	Organization and Flow

	2.  Actors, Goals, and Messaging Transactions

	Actors and Goals

	High-Level View of Use Cases

	Use Case Descriptions

	Use Case 1—Send Immunization History

	Use Case 2—Request Complete Immunization History

	Use Case 3—Request Evaluated History and Forecast

	Use Case 4—Send Demographic Data

	Use Case 5–Acknowledge Receipt

	Use Case 6—Report Error

	Messaging in the Context of the Business Process

	Core Data Elements of an Immunization History

	Key Technical Decisions

	Pre-Adoption Of Some Features Of HL7 Version 2.7.1

	Use of Vocabulary Standards

	Processing Mode

	Message Profiles

	Conventions
	3.  HL7 Messaging Infrastructure

	Keywords

	HL7 definitions

	Basic Message Processing Rules

	Message Acknowledgement

	Encoding Rules for Sending

	Processing Rules for Receiving System:

	Determining Usage of Segments, Fields and Components

	Usage Conformance Testing Recommendations

	Usage

	Definition Of Conditional Usage

	Sending And Receiving Application Conformance Requirements

	Message Element Attributes

	4.  HL7 Data Types

	Data Types Used In This Implementation Guide

	CE — Coded Element (most uses)

	Identifier (ST)

	Text (ST)

	Name of Coding System (ID)

	Alternate Identifier (ST)

	Alternate Text (ST)

	Name of Alternate Coding System (ID)

	CE_TX — Coded Element (text only in RXA-9)

	Text (ST)

	CQ — Composite Quantity with Units

	Conformance Statement:

	Quantity (NM)

	Units (CE)

	CWE — Coded With Exceptions

	Identifier (ST)

	Text (ST)

	Name of Coding System (ID)

	Alternate Identifier (ST)

	Alternate Text (ST)

	Name of Alternate Coding System (ID)

	CX — Extended Composite ID With Check Digit

	ID Number (ST)

	Assigning Authority (HD)

	Identifier Type Code (ID)

	DT — Date

	DT_D — Date with precision to day

	DTM — Date/Time

	EI — Entity Identifier

	Conformance Statement:

	Entity Identifier (ST)

	Namespace ID (IS)

	Universal ID (ST)

	Universal ID Type (ID)

	ERL — Error Location

	Segment ID (ST)

	Segment Sequence (NM)

	Field Position (NM)

	Field Repetition (NM)

	Component Number (NM)

	Sub-Component Number (NM)

	FN — Family Name

	Surname (ST)

	FT – Formatted Text

	Usage Note

	HD — Hierarchic Designator

	Conformance Statement:

	ID — Coded Values for HL7 Tables

	IS — Coded Values for User Defined Tables

	LA2 — Location with Address Variation 2

	Facility (HD)

	MSG — Message Type

	Message Code (ID)

	Trigger Event (ID)

	Message Structure (ID)

	NM — Numeric

	PT — Processing Type

	Processing ID (ID)

	SAD — Street Address

	Street or Mailing Address (ST)

	SI — Sequence Id

	ST – String

	TS — Time Stamp

	TS_M — Time Stamp to Month

	TS_NZ — Time Stamp No Time Zone

	TS_Z — Time Stamp with Time Zone

	VID — Version Id

	Conformance Statement:

	Version ID (ID)

	XAD — Extended Address

	Street Address (SAD)

	Other Designation (ST)

	City (ST)

	State or Province (ST)

	Zip or Postal Code (ST)

	Country (ID)

	Address Type (ID)

	XCN – Extended Composite ID Number and Name for Persons

	ID number (ST)

	Family Name (FN)

	Given Name (ST)

	Second and Further Given Names or Initials Thereof  (ST)

	Suffix (ST)

	Prefix (ST)

	Assigning Authority (HD)

	Name Type Code (ID)

	XON – Extended Composite Name and ID Number and Name for Organizations

	XPN — Extended Person Name

	Family Name (FN)

	Given Name (ST)

	Second and Further Given Names or Initials Thereof (ST)

	Suffix (ST)

	Prefix (ST)

	Name Type Code (ID)

	Professional Suffix (ST)

	XPN_M — Extended Person Name – Maiden Name

	Family Name (FN)

	Given Name (ST)

	Second and Further Given Names or Initials Thereof (ST)

	Name Type Code (ID)

	XTN – Extended Telecommunication Number

	Telecommunication Use Code (ID)

	Telecommunication Equipment Type (ID)

	Email Address (ST)

	Area/city Code (NM)

	Phone Number (NM)

	Extension (NM)
	5.  Profile Z22-Send Unsolicited Immunization Update Using a VXU

	Introduction:

	Interaction Definition:

	Dynamic Definition:

	Static Definition—Message Level:

	Static Definition—Segment Level

	IN1—Insurance Segment

	IN1 Field Definitions

	IN1-1   Set ID – IN1   (SI)   00426

	IN1-2   Insurance Plan ID   (CE)   00368

	IN1-3   Insurance Company ID   (CX)   00428

	IN1-15   Plan Type   (IS)   00440

	IN1-29   Verification Date/Time   (TS)   00454
	MSH—Message Header Segment

	MSH Conformance Statements:

	MSH field definitions

	MSH-1 Field Separator (ST) 00001

	MSH-2 Encoding Characters (ST) 00002

	MSH-3 Sending Application (HD) 00003

	MSH-4 Sending Facility (HD) 00004

	MSH-5 Receiving Application (HD) 00005

	MSH-6 Receiving Facility (HD) 00006

	MSH-7 Date/Time Of Message (TS_Z) 00007

	MSH-9 Message Type (MSG) 00009

	MSH-10 Message Control ID (ST) 00010

	MSH-11 Processing ID (PT) 00011

	MSH-12 Version ID (VID) 00012

	MSH-15 Accept Acknowledgment Type (ID) 00015

	MSH-16 Application Acknowledgment Type (ID) 00016

	MSH-17 Country Code (ID) 00017

	MSH-21 Message Profile Identifier (EI) 01598

	MSH-22 Responsible Sending Organization

	MSH-23 Responsible Receiving Organization
	NK1—Next of Kin Segment

	NK1 field definitions

	NK1-1   Set ID – NK1   (SI)   00190

	NK1-2   Name   (XPN)   00191

	NK1-3   Relationship   (CE)   00192

	NK1-4   Address   (XAD)   00193

	NK1-5   Phone Number   (XTN)   00194

	NK1-6   Business Phone Number   (XTN)   00195
	NTE—Note Segment

	NTE field definitions

	NTE-3 Comment (FT) 00098
	OBX—Observation Result Segment

	Conformance Statement:

	OBX field definitions

	OBX-1 Set ID – OBX (SI) 00569

	OBX-2 Value Type (ID) 00570

	OBX-3 Observation Identifier (CE) 00571

	OBX-4 Observation Sub-ID (ST) 00572

	OBX-5 Observation Value (varies) 00573

	OBX-6 Units (CE) 00574

	OBX-11 Observation Result Status (ID) 00579

	OBX-14 Date/Time of the Observation (TS_NZ) 00582

	OBX-17 Observation Method (CE)

	Application Conformance Statement:

	ORC—Order Request Segment

	Conformance Statement:

	ORC field definitions

	ORC-1   Order Control   (ID)   00215

	ORC-2   Placer Order Number   (EI)   00216

	ORC-3   Filler Order Number   (EI)   00217

	ORC-10   Entered By   (XCN)   00224

	ORC-12   Ordering Provider   (XCN)   00226

	ORC-17   Entering Organization   (CE)   00231

	ORC –28   Confidentiality Code   (CWE)   00615
	PD1—Patient Demographic Segment

	PD1 field definitions

	PD1-3 Patient Primary Facility (XON) 00756

	PD1-11 Publicity Code (CE) 00743

	PD1-12 Protection Indicator (ID) 00744

	PD1-13 Protection Indicator Effective Date (DT) 01566

	PD1-16 Immunization Registry Status (IS) 01569

	PD1-17 Immunization Registry Status Effective Date (DT) 01570

	PD1-18 Publicity Code Effective Date (DT) 01571
	PID—Patient Identifier Segment

	Conformance Statement:

	PID field definitions

	PID-1 Set ID – PID (SI) 00104

	PID-3 Patient Identifier List (CX) 00106

	PID-5 Patient Name (XPN) 00108

	PID-6 Mother’s Maiden Name (XPN) 00109

	PID-7 Date/Time of Birth (TS_NZ) 00110

	PID-8 Administrative Sex (IS) 00111

	PID-10 Race (CE) 00113

	PID-11 Patient Address (XAD) 00114

	PID-13 Phone Number – Home  (XTN) 00116

	PID-14 Phone Number – Business (XTN) 00117

	PID-22 Ethnic Group (CE) 00125

	PID-24 Multiple Birth Indicator  (ID) 00127

	PID-25 Birth Order (NM) 00128

	PID-29 Patient Death Date and Time (TS) 00740

	PID-30 Patient Death Indicator (ID) 00741
	PV1—Patient Visit Segment

	RXA– Pharmacy/Treatment Administration Segment

	Conformance Statement:

	RXA field definitions

	RXA-1 Give Sub-ID Counter (NM) 00342

	RXA-2 Administration Sub-ID Counter (NM) 00344

	RXA-3 Date/Time Start of Administration (TS_NZ) 00345

	RXA-4 Date/Time End of Administration (If Applies) (TS) 00346

	RXA-5 Administered Code (CE) 00347

	RXA-6 Administered Amount (NM) 00348

	RXA-7 Administered units (CE) 00349

	RXA-9 Administration Notes (CE) 00351

	RXA-10 Administering Provider (XCN) 00352

	RXA-11 Administered-at Location (LA2) 00353

	RXA-15 Substance Lot Number (ST) 01129

	RXA-16 Substance Expiration Date (TS_M) 01130

	RXA-17 Substance Manufacturer Name (CE) 01131

	RXA-18 Substance/Treatment Refusal Reason (CE) 01136

	RXA-20 Completion Status (ID) 01223

	RXA-21 Action Code – RXA (ID) 01224
	RXR– Pharmacy/Treatment Route Segment

	RXR field definitions

	RXR-1 Route (CE) 00309

	RXR-2 Administration Site (CWE) 00310
	6.  Profile Z23 Return an Acknowledgement

	Introduction:

	Interaction Definition:

	Dynamic Definition:

	Static Definition- Message Level

	Static Definition—Segment Level:

	ERR—Error Segment

	ERR field definitions:

	ERR-2 Error Location (ERL) 01812

	ERR-3 HL7 Error Code (CWE) 01813

	ERR-4 Severity (ID) 01814

	ERR-5 Application Error Code (CWE) 01815

	ERR-8 User Message (TX) 01817
	MSA—Message Acknowledgement Segment

	MSA field definitions

	MSA-1 Acknowledgment Code (ID) 00018

	MSA-2 Message Control ID (ST) 00010
	MSH—Message Header Segment

	MSH Conformance Statements:

	MSH field definitions
	7. Profile Z34 – Request a Complete Immunization History

	Introduction:

	Interaction Definition:

	Dynamic Definition:

	Static Definition – Message Level:

	Static Definition – Segment Level:

	MSH – Message Header Specification

	Conformance Statement:

	MSH field definitions

	QPD Input Parameter Specification

	QPD Input Parameter Field Description and Commentary

	RCP – Response Control Parameter Segment

	Conformance Statement:

	RCP field definitions

	RCP-1 Query Priority (ID) 00027

	RCP-2 Quantity Limited Request (CQ) 00031
	8. Profile Z32 Response Profile – Return Complete Immunization History

	Introduction:

	Interaction Definition

	Dynamic Definition

	Static Definition – Message Level

	Static Definition — Segment Level

	ERR—Error Segment

	ERR field definitions:

	IN1—Insurance Segment

	IN1 Field Definitions

	MSA—Message Acknowledgement Segment

	MSA field definitions

	MSH – Message Header Specification

	Conformance Statement:

	MSH Field Definitions

	NK1—Next of Kin Segment

	NK1 field definitions

	NTE—Note Segment

	NTE field definitions

	OBX—Observation Result Segment

	Conformance Statement:

	OBX field definitions

	ORC—Order Request Segment

	Conformance Statement:

	ORC field definitions

	PD1—Patient Demographic Segment

	PD1 field definitions

	PID—Patient Identifier Segment

	Conformance Statement:

	PID field definitions

	PV1—Patient Visit Segment

	QAK—Query Acknowledgement Segment

	QAK field definitions

	QAK-1 Query Tag (ST) 00696

	QAK-2 Query Response Status (ID) 00708

	QAK-3 Message Query Name (CE) 01375
	QPD Input Parameter Specification

	QPD Input Parameter Field Description and Commentary

	RXA– Pharmacy/Treatment Administration Segment

	Conformance Statement:

	RXA field definitions

	RXR– Pharmacy/Treatment Route Segment

	RXR field definitions
	9.  Profile Z31 — Return a List of Candidates Profile

	Introduction:

	Interaction Definition

	Dynamic Definition

	Static Definition – Message Level

	Segment Level Profile

	ERR—Error Segment

	ERR field definitions:

	MSA—Message Acknowledgement Segment

	MSA field definitions

	MSH – Message Header Specification

	Conformance Statement:

	MSH Field Definitions

	NK1—Next of Kin Segment

	NK1 field definitions

	QPD Input Parameter Specification

	QPD field definitions

	PID – Patient Identification Segment

	Conformance Statement

	PID Field Definition
	10. Profile Z33 –Return an acknowledgement with no person records

	Introduction:

	Interaction Definition

	Dynamic Definition

	Static Definition – Message Level

	Static Definition — Segment Level

	ERR—Error Segment

	ERR field definitions:

	MSA—Message Acknowledgement Segment

	MSA field definitions

	MSH – Message Header Specification

	Conformance Statement:

	MSH Field Definitions

	QPD Input Parameter Specification

	QPD Field Definitions
	11.  Profile Z44–Request Evaluated Immunization History and Forecast Query Profile

	Introduction

	Interaction Definition

	Dynamic Definition

	Static Definition – Message Level:

	Static Definition—Segment Level

	ERR—Error Segment

	ERR field definitions:

	MSA—Message Acknowledgement Segment

	MSA field definitions

	MSH – Message Header Specification

	Conformance Statement:

	MSH field definitions

	QPD Input Parameter Specification

	QPD Field Definitions

	RCP Response Control Parameter Field Description and Commentary

	RCP Field Definitions
	12. Profile Z42 — Return Evaluated History and Forecast

	Introduction

	Interaction Definition

	Dynamic Definition

	Static Definition –Message Level

	Static Definition — Segment Level

	MSH – Message Header Specification

	Conformance Statement:

	MSH field definitions

	OBX—Observation Result Segment

	Conformance Statement:

	OBX field definitions

	ORC—Order Request Segment

	Conformance Statement:

	ORC field definitions

	PID—Patient Identifier Segment

	Conformance Statement:

	PID field definitions

	QAK—Query Acknowledgement Segment

	QAK field definitions

	QAK-1 Query Tag (ST) 00696

	QAK-2 Query Response Status (ID) 00708

	QAK-3 Message Query Name (CE) 01375
	QPD Input Parameter Specification

	QPD Input Parameter Field Description and Commentary

	RXA– Pharmacy/Treatment Administration Segment

	Conformance Statement:

	RXA field definitions

	RXR– Pharmacy/Treatment Route Segment

	RXR field definitions
	13. Batch File Specifications

	Sending Messages in a Batch

	BHS—Batch Header Segment

	Conformance Statement

	BHS field definitions

	BHS-1 Batch Field Separator (ST) 00081

	BHS-2 Batch Encoding Characters (ST) 00082
	BTS—Batch Trailer Segment

	BTS field definitions

	FHS—File Header Segment

	Conformance Statement:

	FHS field definitions

	FHS-1 File Field Separator (ST) 00067

	FHS-2 File Encoding Characters (ST) 00068
	FTS—File Trailer Segment

	Change History Details

	Release 1.1

	Release 1.2

	Release 1.3

	Release 1.4

	Release 1.5

	APPENDIX A:

	Code Tables

	User-defined Table 0001 – Sex

	HL7-defined Table 0003 – Event type

	User-defined Table 0004 – Patient class

	User-defined Table 0005 – Race

	HL7-defined Table 0008 – Acknowledgment code

	User-defined Table 0010 – Physician ID

	HL7-defined Table 0061 – Check digit scheme

	User-defined Table 0063 – Relationship

	User-defined Table 0064 – Financial class

	HL7-defined Table 0076 – Message type

	HL7-defined Table 0078 – Abnormal flags

	HL7-defined Table 0085 – Observation result status codes interpretation

	User Defined Table 0086 – Plan Type ID

	HL7-defined Table 0091 – Query priority

	HL7-defined Table 0102 – Delayed acknowledgment type

	HL7-defined Table 0103 – Processing ID

	HL7-defined Table 0104 – Version ID

	HL7-defined Table 0119 – Order Control Codes

	HL7-defined Table 0125 – Value Type

	HL7-defined Table 0126 – Quantity limited request

	HL7-defined Table 0136 – Yes/No indicator

	HL7-defined Table 0155 – Accept/Application acknowledgment conditions

	NCI Thesaurus (NCIT) – Route of Administration

	HL7-defined Table 0162 – Route of administration

	HL7-defined Table 0163 – Administrative site

	CDCREC – Ethnic Group

	User-defined Table 0189

	HL7-defined Table 0190 – Address type

	HL7-defined Table 0200 – Name type

	HL7-defined Table 0202 – Telecommunication equipment type

	User-defined Table 0203 – Identifier type

	User-defined Table 0204 – Organizational name type

	HL7-defined Table 0207 – Processing mode

	User-defined Table 0208 – Query response status

	User-defined Table 0215 – Publicity code

	User-defined Table 0220 – Living arrangement

	HL7-defined Table 0227 – Manufacturers of vaccines (code = MVX)

	User-defined Table 0288 – Census tract

	User-defined Table 0289 – County/parish

	HL7-defined Table 0292 – Codes for Vaccines administered (code=CVX)

	CVX – Vaccines Administered

	User-defined Table 0296 – Language

	User-defined Table 0297 – CN ID source

	User-defined Table 0300 – Namespace ID

	HL7-defined Table 0301 – Universal ID type

	HL7-defined Table 0322 – Completion status

	HL7-defined Table 0323 – Action code

	HL7-defined Table 0354 – Message structure

	HL7-defined Table 0356 – Alternate character set handling scheme

	HL7-defined Table 0357 – Message error status codes

	User-defined Table 0360 – Degree

	User-defined Table 0361 – Application

	User-defined Table 0362 – Facility

	User-defined Table 0363 – Assigning Authority

	User-defined Table 0396 – Coding system

	User-defined Table 0441 – Immunization registry status

	User-defined Table 0471 – Query Name

	HL7 Table 0516 – Error Severity

	User-defined Table 0533 – Application Error Code

	CDC-defined NIP001- Immunization information source

	CDC-defined NIP002 – Substance refusal reason

	CDC-defined NIP003 – Observation identifiers

	CDC-defined NIP004 – Contraindications, Precautions, and Immunities

	Value Set Name – Immunization Funding Source

	Value Set Name – Vaccination Contraindications

	Value Set Name – Vaccination Reaction – IIS

	Value Set Name – Vaccination Special Indications – IIS

	Value Set Name – Immunization Profile Identifiers – IIS

	Value Set Name – Immunization Schedule Identifiers – IIS

	Value Set Name – History of Disease as Evidence of Immunity – IIS

	Value Set Name – Serological Evidence of Immunity – IIS

	Value Set Code – PHVS_VISBarcodes_IIS

	Value Set Name – Funding Eligibility Observation Method (IIS)

	Value Set Name – VIS Vaccines (IIS)

	Smallpox Take Read: These codes allow information about evaluation of a smallpox vaccination, called the take response.

	Appendix B – Guidance on Usage and Example Messages

	Core Data Elements for an Immunization History

	Send Immunization History (VXU)

	Business Process

	Example VXU # 1-Basic message:

	Storyboard:

	Message Example

	Example VXU #2 – Indicate client eligibility status for a funding program for vaccines administered:

	Guidance for systems which collect eligibility at the encounter level:

	Patient Eligibility Status:

	VFC Eligible Client Received Vaccine That Is VFC eligible

	VFC Ineligible Client Received Vaccine That Is VFC eligible

	VFC Eligible Client Received Vaccine That Is Not VFC eligible

	VFC Eligible Client Received Vaccine That Is Eligible for Local Funding Program
	Example VXU #3 – Include immunization history evaluation and forecast in VXU

	Example VXU #4 – Send client specific conditions

	Reaction Associated with a Previous Dose of Vaccine

	Adverse Reaction:

	Evidence of immunity:

	Contraindications to immunization:

	Factors which indicate the need for an immunization or a changed recommendation:

	Example VXU #6 –Delete an Immunization Record

	VXU Example #7–Send Information About Vaccine Information Statement (VIS)

	VXU Example #8—Send Information Indicating Immunization Refusal

	VXU Example #9—Send Two Lot Numbers in RXA

	Two Vaccine Components Are Packaged Together And The Lot Numbers Are Inextricable Linked

	Adjuvant Is Recorded Separately From Vaccine

	VXU Example #10—Recording Birth Information

	VXU Example #11—Recording an incompletely administered dose or a non-potent dose.

	Send Acknowledgement ACK In Response To VXU

	Send acknowledgement of success in ACK

	Send Error in ACK

	Acknowledging An Error That Causes Message Rejection ( AR response):

	Acknowledging An HL7 Processing Error That Causes Message Rejection (AE response)

	Acknowledging An HL7 Processing Error That Causes Segment Group Rejection:

	Acknowledging An HL7 Processing Error That Causes Segment Rejection:

	Acknowledging An HL7 Processing Error That Caused a Warning :

	Acknowledging an Application Error That Causes Message Rejection Due to Local Business Rule Violation;
	Example Return an Evaluated History and Forecast (RSP(Z42))

	Indicating the Schedule that was used:

	Indicating Vaccine Group associated:

	Reporting the Ordinal Position In A Series:

	Evaluation:

	Recommendation:

	Reporting the Number of Doses in a Series:

	Reporting Next Dose Recommendation Dates (forecast only):

	Reporting Recommendation Reasons:

	Complete Example Of Evaluation And Forecasting:

	Important notes:

	Using The NTE Segment Associated With An OBX To Provide More Information:

	Send Request for Complete Immunization History (QBP/RSP)

	Process for requesting Immunization History

	Returning a list of candidate clients in response to QBP^Q11 query

	Returning an immunization history in response to a Request for Immunization History query

	Acknowledging Query That Returns No Clients/Patients

	Acknowledging a Query that finds no candidate clients

	Acknowledging a query that finds more candidates than requested

	Using a Two-step process to request an immunization history

	Receiving system determines that message has errors

	HL7 Message Rule Errors

	Content or Format Error

	Message Is Rejected Due to Unrecognized Message Type
	Untitled

	Untitled

	Untitled
Question Sub-Part

Possible

Points Score Comments

1a) How IT has

solved healthcare

interoperability?

5 5

1b) Solution 1 Explain 4 4

Pro 3 3

Con 3 3

1c) Solution 2 Explain 4 4

Pro 3 3

Con 3 3

2. Describe in your

own words HL7v2

patient message

25 25

TOTAL 50

100.0%

Assignment 3 Scores




    
        
            
                
                    What Will You Get?
                    We provide professional writing services to help you score straight A’s by submitting custom written assignments that mirror your guidelines.
                    
                
            
            
        
        
        
            
                
                    
                    
                        Premium Quality 
                        Get result-oriented writing and never worry about grades anymore. We follow the highest quality standards to make sure that you get perfect assignments.
                    
                
            
            
            
                
                    
                    
                        Experienced Writers
                        Our writers have experience in dealing with papers of every educational level. You can surely rely on the expertise of our qualified professionals.
                    
                
            
            
            
                
                    
                    
                        On-Time Delivery 
                        Your deadline is our threshold for success and we take it very seriously. We make sure you receive your papers before your predefined time. 
                    
                
            
            
            
                
                    
                    
                        24/7 Customer Support 
                        Someone from our customer support team is always here to respond to your questions. So, hit us up if you have got any ambiguity or concern.
                    
                
            
            
            
                
                    
                    
                        Complete Confidentiality
                        Sit back and relax while we help you out with writing your papers. We have an ultimate policy for keeping your personal and order-related details a secret.
                    
                
            
            
            
                
                    
                    
                        Authentic Sources
                        We assure you that your document will be thoroughly checked for plagiarism and grammatical errors as we use highly authentic and licit sources. 
                    
                
            
            
            
                
                    
                    
                        Moneyback Guarantee
                        Still reluctant about placing an order? Our 100% Moneyback Guarantee backs you up on rare occasions where you aren’t satisfied with the writing.
                    
                
            
            
            
                
                    
                    
                        Order Tracking 
                        You don’t have to wait for an update for hours; you can track the progress of your order any time you want. We share the status after each step.
                    
                
            
            
        
        
        
            Order Now
             Talk to Us
        
    
    
        
            
                
                
            
        
    





    
        
            
                
                    Areas of Expertise
                    Although you can leverage our expertise for any writing task, we have a knack for creating flawless papers for the following document types.
                
            
            
        
        
        
        
            
                
                
                
                
            
            
                
                    
                        
                            
                                
                                
                                
                                    Essay
                                
                            
                        
                        
                        
                            
                                
                                
                                
                                    Thesis
                                
                            
                        
                        
                            
                                
                                
                                
                                    Presentation
                                
                            
                        
                        
                            
                                
                                
                                
                                    Dissertation
                                
                            
                        
                    
                
                
                    
                        
                            
                                
                                
                                
                                    Term Paper
                                
                            
                        
                        
                        
                            
                                
                                
                                
                                    Research Paper
                                
                            
                        
                        
                            
                                
                                
                                
                                    Book Review
                                
                            
                        
                        
                            
                                
                                
                                
                                    Assignment
                                
                            
                        
                    
                
                
                    
                        
                            
                                
                                
                                
                                    Report
                                
                            
                        
                        
                        
                            
                                
                                
                                
                                    Case Study
                                
                            
                        
                        
                            
                                
                                
                                
                                    Letter
                                
                            
                        
                        
                            
                                
                                
                                
                                    Article
                                
                            
                        
                    
                
                
                    
                        
                            
                                
                                
                                
                                    Coursework
                                
                            
                        
                        
                        
                            
                                
                                
                                
                                    Speech
                                
                            
                        
                        
                            
                                
                                
                                
                                    Q & A
                                
                            
                        
                        
                            
                                
                                
                                
                                    Critical Thinking
                                    
                                
                            
                        
                    
                
            
            
                
                Previous
            
            
                
                Next
            
        
        
    
    





    
        
            
                
                    Areas of Expertise
                    Although you can leverage our expertise for any writing task, we have a knack for creating flawless papers for the following document types.
                
            
            
        
        
        
            
                
                    
                        
                            
                                
                                
                                
                                    Essay
                                
                            
                        
                    
                
                
                    
                        
                            
                                
                                
                                
                                    Thesis
                                
                            
                        
                    
                
                
                    
                        
                            
                                
                                
                                
                                    Presentation
                                
                            
                        
                        
                    
                
                
                    
                        
                            
                                
                                
                                
                                    Dissertation
                                
                            
                        
                        
                    
                
                
                    
                        
                            
                                
                                
                                
                                    Term Paper
                                
                            
                        
                        
                    
                
                
                    
                        
                            
                                
                                
                                
                                    Research Paper
                                
                            
                        
                        
                    
                
                
                    
                        
                            
                                
                                
                                
                                    Book Review
                                
                            
                        
                        
                    
                
                
                    
                        
                            
                                
                                
                                
                                    Assignment
                                
                            
                        
                        
                    
                
                
                    
                        
                            
                                
                                
                                
                                    Report
                                
                            
                        
                        
                    
                
                
                    
                        
                            
                                
                                
                                
                                    Case Study
                                
                            
                        
                        
                    
                
                
                    
                        
                            
                                
                                
                                
                                    Letter
                                
                            
                        
                        
                    
                
                
                    
                        
                            
                                
                                
                                
                                    Article
                                
                            
                        
                        
                    
                
                
                    
                        
                            
                                
                                
                                
                                    Coursework
                                
                            
                        
                        
                    
                
                
                    
                        
                            
                                
                                
                                
                                    Speech
                                
                            
                        
                        
                    
                
                
                    
                        
                            
                                
                                
                                
                                    Q & A
                                
                            
                        
                        
                    
                
                
                    
                        
                            
                                
                                
                                
                                    Critical Thinking 
                                
                            
                        
                    
                
            
            
                
                Previous
            
            
                
                Next
            
        
        
    
    



    
        
            
                
            
        
        
    
    
        
            
                
                    
                        
                            Trusted Partner of 9650+ Students for Writing 
                            From brainstorming your paper's outline to perfecting its grammar, we perform every step carefully to make your paper worthy of A grade.
                        
                    
                    
                
                
                    
                        
                            
                            Preferred Writer 
                            Hire your preferred writer anytime. Simply specify if you want your preferred expert to write your paper and we’ll make that happen.
                        
                        
                            
                            Grammar Check Report 
                            Get an elaborate and authentic grammar check report with your work to have the grammar goodness sealed in your document.
                        
                        
                            
                            One Page Summary 
                            You can purchase this feature if you want our writers to sum up your paper in the form of a concise and well-articulated summary.
                        
                        
                            
                            Plagiarism Report
                            You don’t have to worry about plagiarism anymore. Get a plagiarism report to certify the uniqueness of your work.
                        
                    
                    
                    
                        
                            Free Features $66FREE
                            
                                
                                    
                                    Most Qualified Writer
                                    $10FREE
                                
                                
                                    
                                    Plagiarism Scan Report
                                    $10FREE
                                
                                
                                    
                                    Unlimited Revisions
                                    $08FREE
                                
                                
                                    
                                    Paper Formatting
                                    $05FREE
                                
                                
                                    
                                    Cover Page
                                    $05FREE
                                
                                
                                    
                                    Referencing & Bibliography
                                    $10FREE
                                
                                
                                    
                                    Dedicated User Area
                                    $08FREE
                                
                                
                                    
                                    24/7 Order Tracking
                                    $05FREE
                                
                                
                                    
                                    Periodic Email Alerts
                                    $05FREE
                                
                            
                        
                    
                
            
        
    
    



    
        
            
                
            
        
        
    
    
        
            
                
                    Our Services
                    Join us for the best experience while seeking writing assistance in your college life. A good grade is all you need to boost up your academic excellence and we are all about it.
                    
                        On-time Delivery
                        24/7 Order Tracking 
                        Access to Authentic Sources
                    
                
            
            
            
                
                    
                        
                            
                                
                                    
                                        Academic Writing
                                        
                                            We create perfect papers according to the guidelines.
                                        
                                    
                                
                            
                        
                    
                    
                        
                            
                                
                                    
                                        Professional Editing
                                        
                                            We seamlessly edit out errors from your papers.
                                        
                                    
                                
                            
                            
                                
                                    
                                        Thorough Proofreading
                                        
                                            We thoroughly read your final draft to identify errors.
                                        
                                    
                                
                            
                            
                                
                                    
                                        Thorough Proofreading
                                        We thoroughly read your final draft to identify errors. 
                                    
                                
                            
                        
                    
                
            
        
        
    
    
        
            
                
                
            
        
        
    
 




    
        
            
                
                    Delegate Your Challenging Writing Tasks to Experienced Professionals
                    Work with ultimate peace of mind because we ensure that your academic work is our responsibility and your grades are a top concern for us!
                
            
            
        
        
        
            Sign Up 
             Talk to Us
        
    
    



    
        
            Check Out Our Sample Work
            Dedication. Quality. Commitment. Punctuality
        
        
            
                
                    
                        Categories
                        
                            All samples
                            Essay (any type)
                        
                    
                    
                
                    Essay (any type)
                    The Value of a Nursing Degree
                    Undergrad. (yrs 3-4)
                    Nursing
                    2
                    View this sample
                    
                
            
                
            
            



    
        
            
                
                    It May Not Be Much, but It’s Honest Work!
                    Here is what we have achieved so far. These numbers are evidence that we go the extra mile to make your college journey successful.
                
            
            
        
        
        
            
                
                    
                    0+
                    Happy Clients
                
                
            
            
                
                    
                    0+
                    Words Written This Week
                
                
            
            
                
                    
                    0+
                    Ongoing Orders
                
                
            
            
                
                    
                    0%
                    Customer Satisfaction Rate
                
                
            
        
        
    
    
    
        
            
                
            
        
        
    
 



    
        
            
                
                    Process as Fine as Brewed Coffee
                    We have the most intuitive and minimalistic process so that you can easily place an order. Just follow a few steps to unlock success.
                
            
            
        
        
        
            
                
                
                
                
            
            
            
                
                    
                        
                        
                        
                        
                    
                
            
            
            
        
        
        
             Call Us +1 (877) 657-8180
             Discuss Order Details Now 
        
    



    
        
            
                
                    See How We Helped 9000+ Students Achieve Success
                
            
            
        
        
            
                
            
            
            
                
                    We Analyze Your Problem and Offer Customized Writing 
                    We understand your guidelines first before delivering any writing service. You can discuss your writing needs and we will have them evaluated by our dedicated team. 
                    
                        Clear elicitation of your requirements.
                        Customized writing as per your needs.
                    
                
            
            
        
        
    
    
    
        
            
                
                    We Mirror Your Guidelines to Deliver Quality Services
                    We write your papers in a standardized way. We complete your work in such a way that it turns out to be a perfect description of your guidelines. 
                    
                        Proactive analysis of your writing.
                        Active communication to understand requirements.
                    
                
            
            
            
                
            
            
        
        
    
    
    
        
            
                
            
            
            
                
                    We Handle Your Writing Tasks to Ensure Excellent Grades
                    We promise you excellent grades and academic excellence that you always longed for. Our writers stay in touch with you via email.
                    
                        Thorough research and analysis for every order.
                        Deliverance of reliable writing service to improve your grades.
                    
                
            
            
        
        
    
    
    
        Place an Order
         Start Chat Now
    
    
        
            
                
            
        
        
    
 


    
        
            
                Why Choose Us
                Thousands of students and professionals rely on us for their writing tasks to achieve their goals in academic life. Our services are offered as a fusion of quality, affordability, reliability and utmost dedication.
                
                    
                
                
            
            
            
                Quick Links 
                
                    Home
                    Benefits
                    Areas of Expertise
                    Areas of Expertise
                    Why Choose Us
                    Services
                     Features
                     Our Process
                     Testimonials
                     FAQs
                
            
            
                            
                      
                    
                                                                                     Home
                                                             Pricing.
                                                             Privacy and policy
                                                                        
                
                        
            
                Connect with Us 
                
                                            Support@assignmentresearchwriter.com
                     

                                             +1 763 309 4299
                    
                    Start Live Chat
                
                
                    
                        Payment Options
                    
                    
                

            
        
    




    
        
            
                Disclaimer: All Original and Custom Writing Services are solely for the purpose of your understanding and information.
                Copyrights © 2025 Assignment Research Writer. All Rights Reserved.
            
            
                
                    Follow Us |
                                            
                    
                    
                    
                    
                                    
            
        
    



                
                    
                        
                            Order your essay today and save 30% with the discount code Happy
                            
                                Order Now

HealthCare

What Will You Get?

Premium Quality

Experienced Writers

On-Time Delivery

24/7 Customer Support

Complete Confidentiality

Authentic Sources

Moneyback Guarantee

Order Tracking

Areas of Expertise

Essay

Thesis

Presentation

Dissertation

Term Paper

Research Paper

Book Review

Assignment

Report

Case Study

Letter

Article

Coursework

Speech

Q & A

Critical Thinking

Areas of Expertise

Essay

Thesis

Presentation

Dissertation

Term Paper

Research Paper

Book Review

Assignment

Report

Case Study

Letter

Article

Coursework

Speech

Q & A

Critical Thinking

Trusted Partner of 9650+ Students for Writing

Preferred Writer

Grammar Check Report

One Page Summary

Plagiarism Report

Free Features $66FREE

Our Services

Academic Writing

Professional Editing

Thorough Proofreading

Thorough Proofreading

Delegate Your Challenging Writing Tasks to Experienced Professionals

Check Out Our Sample Work

It May Not Be Much, but It’s Honest Work!

0+

Happy Clients

0+

Words Written This Week

0+

Ongoing Orders

0%

Customer Satisfaction Rate

Process as Fine as Brewed Coffee

Share Your Requirements

Place Order & Deposit Funds

Release Payment to Your Writer

See How We Helped 9000+ Students Achieve Success

We Analyze Your Problem and Offer Customized Writing

We Mirror Your Guidelines to Deliver Quality Services

We Handle Your Writing Tasks to Ensure Excellent Grades