HL7 Version 2.5.1 

Implementation Guide 

for Immunization Messaging
Page Intentionally Blank 

Last Reviewed Feb 2016
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

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

For 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
Table of Contents

1. INTRODUCTION ...............................................................................................................1

INTENDED AUDIENCE.............................................................................................1

SCOPE..................................................................................................................2

ORGANIZATION AND FLOW.....................................................................................3

2. ACTORS, GOALS, AND MESSAGING TRANSACTIONS .........................................................6

ACTORS AND GOALS.............................................................................................6

HIGH-LEVEL VIEW OF USE CASES..........................................................................9

USE CASE DESCRIPTIONS....................................................................................11

USE CASE 1—SEND IMMUNIZATION HISTORY ............................................11

USE CASE 2—RECEIVE IMMUNIZATION HISTORY .......................................12

USE CASE 3—REQUEST IMMUNIZATION HISTORY ......................................12

USE CASE 4—RETURN IMMUNIZATION HISTORY ........................................14

USE CASE 4A—FIND CANDIDATE CLIENTS................................................15

USE CASE 5--ACCEPT REQUESTED HISTORY: ............................................18

USE CASE 6—SEND DEMOGRAPHIC DATA ................................................19

USE CASE 7—ACCEPT DEMOGRAPHIC DATA.............................................19

USE CASE 8--ACKNOWLEDGE RECEIPT .....................................................20

USE CASE 9—REPORT ERROR................................................................. 21

MESSAGING IN THE CONTEXT OF THE BUSINESS PROCESS....................................21

CORE DATA ELEMENTS OF AN IMMUNIZATION HISTORY.........................................23

KEY TECHNICAL DECISIONS.................................................................................24

PRE-ADOPTION OF SOME FEATURES OF HL7 VERSION 2.7.1 .....................24

USE OF VOCABULARY STANDARDS...........................................................24

SNAPSHOT MODE ....................................................................................25

FIELD LENGTH AND TRUNCATION..............................................................25

CONVENTIONS .........................................................................................25

3. HL7 MESSAGING INFRASTRUCTURE ...............................................................................27

KEYWORDS.........................................................................................................27

HL7 DEFINITIONS ................................................................................................27

BASIC MESSAGE CONSTRUCTION RULES .............................................................30

ENCODING RULES FOR SENDING ..............................................................30

ENCODING RULES FOR RECEIVING............................................................30

IMPLICATIONS OF THE ENCODING RULES ...................................................31

DETERMINING USAGE OF SEGMENTS, FIELDS AND COMPONENTS ...............32

USAGE CONFORMANCE TESTING RECOMMENDATIONS ...........................32

USAGE ....................................................................................................32

DEFINITION OF CONDITIONAL USAGE ........................................................33

SENDING AND RECEIVING APPLICATION CONFORMANCE REQUIREMENTS....33

MESSAGE ELEMENT ATTRIBUTES.........................................................................36

4. HL7 DATA TYPES............................................................................................................39

DATA TYPES FOR IIS USE....................................................................................39
CE -- CODED ELEMENT (MOST USES) ........................................................41

CE_TX -- CODED ELEMENT (TEXT ONLY IN RXA-9) ...................................42

CQ -- COMPOSITE QUANTITY WITH UNITS..................................................43

CWE -- CODED WITH EXCEPTIONS...........................................................44

CX -- EXTENDED COMPOSITE ID WITH CHECK DIGIT..................................46

DT -- DATE..............................................................................................48

DTM -- DATE/TIME...................................................................................49

EI -- ENTITY IDENTIFIER............................................................................49

ERL -- ERROR LOCATION .........................................................................51

FN -- FAMILY NAME..................................................................................52

FT – FORMATTED TEXT............................................................................53

HD -- HIERARCHIC DESIGNATOR...............................................................53

ID -- CODED VALUES FOR HL7 TABLES .....................................................55

IS -- CODED VALUES FOR USER DEFINED TABLES .....................................56

LA2 -- LOCATION WITH ADDRESS VARIATION 2 ..........................................56

MSG -- MESSAGE TYPE ...........................................................................57

NM -- NUMERIC .......................................................................................59

PT -- PROCESSING TYPE..........................................................................59

SAD -- STREET ADDRESS ........................................................................60

SI -- SEQUENCE ID...................................................................................60

ST – STRING ...........................................................................................60

TS -- TIME STAMP....................................................................................61

VID -- VERSION ID ...................................................................................61

XAD -- EXTENDED ADDRESS ....................................................................62

XCN - EXTENDED COMPOSITE ID NUMBER AND NAME FOR PERSONS.........65

XON - EXTENDED COMPOSITE NAME AND ID NUMBER AND NAME FOR 

ORGANIZATIONS ......................................................................................68

EXTENDED PERSON NAME (XPN) .............................................................70

XTN - EXTENDED TELECOMMUNICATION NUMBER .....................................72

5. SEGMENTS AND MESSAGE DETAILS ...............................................................................75

BHS—BATCH HEADER SEGMENT........................................................................81

BHS FIELD DEFINITIONS ...........................................................................83

BTS—BATCH TRAILER SEGMENT........................................................................83

BTS FIELD DEFINITIONS............................................................................84

ERR—ERROR SEGMENT.....................................................................................84

ERR FIELD DEFINITIONS: ..........................................................................86

EVN - EVENT TYPE SEGMENT..............................................................................87

EVN FIELD DEFINITIONS ...........................................................................87

FHS—FILE HEADER SEGMENT............................................................................88

FHS FIELD DEFINITIONS ...........................................................................90

FTS—FILE TRAILER SEGMENT ............................................................................90

IN1—INSURANCE SEGMENT (IN2, IN3) ................................................................90

MSA—MESSAGE ACKNOWLEDGEMENT SEGMENT................................................91

MSA FIELD DEFINITIONS...........................................................................91

MSH—MESSAGE HEADER SEGMENT...................................................................92

MSH FIELD DEFINITIONS...........................................................................95

NK1—NEXT OF KIN SEGMENT.............................................................................99

NK1 FIELD DEFINITIONS..........................................................................102

NTE—NOTE SEGMENT......................................................................................104
NTE FIELD DEFINITIONS .........................................................................104

OBX—OBSERVATION RESULT SEGMENT ...........................................................104

OBX FIELD DEFINITIONS .........................................................................108

ORC—ORDER REQUEST SEGMENT ...................................................................114

CONFORMANCE STATEMENT: ..................................................................117

ORC FIELD DEFINITIONS.........................................................................118

PD1—PATIENT DEMOGRAPHIC SEGMENT ..........................................................120

PD1 FIELD DEFINITIONS..........................................................................122

PID—PATIENT IDENTIFIER SEGMENT ................................................................. 125

PID FIELD DEFINITIONS...........................................................................129

PV1—PATIENT VISIT SEGMENT .........................................................................132

QAK—QUERY ACKNOWLEDGEMENT SEGMENT..................................................132

QAK FIELD DEFINITIONS .........................................................................133

QPD – QUERY PARAMETER DEFINITION .............................................................134

QPD FIELD DEFINITIONS.........................................................................134

RCP – RESPONSE CONTROL PARAMETER SEGMENT ..........................................135

CONFORMANCE STATEMENT: ..................................................................136

RCP FIELD DEFINITIONS .........................................................................137

RXA-- PHARMACY/TREATMENT ADMINISTRATION SEGMENT................................137

RXA FIELD DEFINITIONS .........................................................................142

RXR-- PHARMACY/TREATMENT ROUTE SEGMENT ..............................................146

RXR FIELD DEFINITIONS .........................................................................147

6. MESSAGES FOR TRANSMITTING IMMUNIZATION INFORMATION ................................. 148

INTRODUCTION..................................................................................................148

SEND IMMUNIZATION HISTORY--VXU..................................................................148

REQUESTING INFORMATION (IMMUNIZATION HISTORY) – QBP .............................150

RESPOND TO REQUEST FOR INFORMATION– RSP ...............................................150

REQUESTING AN IMMUNIZATION HISTORY FROM ANOTHER SYSTEM VXQ.............151

THE USE OF VXQ IS NOT SUPPORTED FOR 2.5.1 IMMUNIZATION MESSAGING.

.............................................................................................................151

ACKNOWLEDGING A MESSAGE--ACK ................................................................. 151

SENDING DEMOGRAPHIC INFORMATION – VXU OR ADT ......................................152

SENDING MESSAGES IN A BATCH .......................................................................153

7. QUERY AND RESPONSE PROFILE (QBP/RSP) ................................................................. 155

REQUEST IMMUNIZATION HISTORY QUERY PROFILE –Z34^CDCPHINVS ............155

RETURN A LIST OF CANDIDATES PROFILE -- Z31^CDCPHINVS ..........................167

INTRODUCTION: .....................................................................................167

USE CASE: ............................................................................................168

STATIC DEFINITION ................................................................................169

SEGMENT LEVEL PROFILE ......................................................................171

FIELD LEVEL PROFILE ............................................................................171

DYNAMIC DEFINITION .............................................................................171

ACKNOWLEDGEMENT RESPONSIBILITIES .................................................172

RETURN AN IMMUNIZATION HISTORY – Z32^CDCPHINVS ..................................172

INTRODUCTION: .....................................................................................172

USE CASE: ............................................................................................172

STATIC DEFINITION ................................................................................174

SEGMENT LEVEL PROFILE ......................................................................175
FIELD LEVEL PROFILE ............................................................................175

DYNAMIC DEFINITION .............................................................................176

CHANGE HISTORY DETAILS ................................................................................................. 177

APPENDIX A: 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 ..........................................3

USER-DEFINED TABLE 0010 - PHYSICIAN ID ...........................................................3

HL7-DEFINED TABLE 0061 - CHECK DIGIT SCHEME .................................................4

USER-DEFINED TABLE 0063 – RELATIONSHIP.........................................................4

USER-DEFINED TABLE 0064 - FINANCIAL CLASS .....................................................4

HL7-DEFINED TABLE 0076 - MESSAGE TYPE ..........................................................5

HL7-DEFINED TABLE 0078 - ABNORMAL FLAGS......................................................6

HL7-DEFINED TABLE 0085 - OBSERVATION RESULT STATUS CODES INTERPRETATION

............................................................................................................................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................................................................6

HL7-DEFINED TABLE 0105 - SOURCE OF COMMENT ................................................7

HL7-DEFINED TABLE 0119 – ORDER CONTROL CODES...........................................7

HL7-DEFINED TABLE 0126 - QUANTITY LIMITED REQUEST .......................................7

HL7-DEFINED TABLE 0136 - YES/NO INDICATOR.....................................................7

HL7-DEFINED TABLE 0155 - ACCEPT/APPLICATION ACKNOWLEDGMENT CONDITIONS

............................................................................................................................8

HL7-DEFINED TABLE 0162 - ROUTE OF ADMINISTRATION ........................................8

USER-DEFINED TABLE 0189 - ETHNIC GROUP.........................................................9

HL7-DEFINED TABLE 0190 - ADDRESS TYPE ........................................................10

HL7-DEFINED TABLE 0202 - TELECOMMUNICATION EQUIPMENT TYPE ....................11

USER-DEFINED TABLE 0203 - IDENTIFIER TYPE .....................................................12

USER-DEFINED TABLE 0204 - ORGANIZATIONAL NAME TYPE ................................. 16

HL7-DEFINED TABLE 0207 - PROCESSING MODE ..................................................16

USER-DEFINED TABLE 0208 - QUERY RESPONSE STATUS......................................16

HL7-DEFINED TABLE 0211 - ALTERNATE CHARACTER SETS ..................................16

USER-DEFINED TABLE 0215 - PUBLICITY CODE.....................................................17

USER-DEFINED TABLE 0220 - LIVING ARRANGEMENT ............................................17

HL7-DEFINED TABLE 0227 - MANUFACTURERS OF VACCINES (CODE = MVX) .........17

USER-DEFINED TABLE 0288 - CENSUS TRACT.......................................................20

USER-DEFINED TABLE 0289 - COUNTY/PARISH .....................................................20

HL7-DEFINED TABLE 0292 - CODES FOR VACCINES ADMINISTERED (CODE=CVX) ..21

USER-DEFINED TABLE 0296 - LANGUAGE.............................................................32

USER-DEFINED TABLE 0297 - CN ID SOURCE .......................................................32

USER-DEFINED TABLE 0300 - NAMESPACE ID ......................................................32

HL7-DEFINED TABLE 0301 - UNIVERSAL ID TYPE..................................................32

HL7-DEFINED TABLE 0322 - COMPLETION STATUS ...............................................33

HL7-DEFINED TABLE 0323 - ACTION CODE...........................................................33
HL7-DEFINED TABLE 0354 - MESSAGE STRUCTURE..............................................34

HL7-DEFINED TABLE 0356 - ALTERNATE CHARACTER SET HANDLING SCHEME.......34

HL7-DEFINED TABLE 0357 - MESSAGE ERROR STATUS CODES..............................34

USER-DEFINED TABLE 0360 – DEGREE ................................................................36

USER-DEFINED TABLE 0361 – APPLICATION.........................................................37

USER-DEFINED TABLE 0362 – FACILITY ...............................................................37

USER-DEFINED TABLE 0363 – ASSIGNING AUTHORITY ..........................................37

USER-DEFINED TABLE 0396 – CODING SYSTEM ....................................................39

USER-DEFINED TABLE 0441 - IMMUNIZATION REGISTRY STATUS ............................40

USER-DEFINED TABLE 0471 – QUERY NAME ........................................................40

HL7 TABLE 0516 - ERROR SEVERITY (USE IN ERR-4)..........................................40

USER-DEFINED TABLE 0533 – APPLICATION ERROR CODE....................................41

CDC-DEFINED NIP001 - IMMUNIZATION INFORMATION SOURCE..............................41

CDC-DEFINED NIP002 - SUBSTANCE REFUSAL REASON .......................................41

CDC-DEFINED NIP003 - OBSERVATION IDENTIFIERS.............................................42

CDC-DEFINED NIP004 - CONTRAINDICATIONS, PRECAUTIONS, AND IMMUNITIES.....45

VALUE SET NAME – IMMUNIZATION FUNDING SOURCE ..........................................45

VALUE SET NAME – VACCINATION CONTRAINDICATIONS.......................................46

VALUE SET NAME – VACCINATION REACTION - IIS................................................48

VALUE SET NAME – VACCINATION SPECIAL INDICATIONS - IIS...............................48

VALUE SET NAME – IMMUNIZATION PROFILE IDENTIFIERS - IIS ...............................49

VALUE SET NAME – IMMUNIZATION SCHEDULE IDENTIFIERS - IIS ...........................49

VALUE SET NAME – EVIDENCE OF IMMUNITY - IIS .................................................50

VALUE SET CODE: PHVS_VISBARCODES_IIS .....................................................52

VALUE SET NAME – FUNDING ELIGIBILITY OBSERVATION METHOD (IIS) .................53

VALUE SET NAME – VIS VACCINES (IIS) ..............................................................54

APPENDIX B – GUIDANCE ON USAGE AND EXAMPLE MESSAGES ............................................55

CORE DATA ELEMENTS FOR AN IMMUNIZATION HISTORY.........................................1

SEND IMMUNIZATION HISTORY (VXU) .....................................................................4

BUSINESS PROCESS..............................................................................................4

SUPPORTED MESSAGE SEGMENTS.........................................................................7

EXAMPLE VXU # 1-BASIC MESSAGE: .....................................................................8

EXAMPLE VXU #2 - INDICATE CLIENT ELIGIBILITY STATUS FOR A FUNDING PROGRAM 

FOR VACCINES ADMINISTERED: ..............................................................................9

PATIENT ELIGIBILITY STATUS: ...................................................................10

EXAMPLE VXU #3 - INCLUDE IMMUNIZATION HISTORY EVALUATION AND FORECAST IN 

VXU...................................................................................................................13

INDICATING THE SCHEDULE THAT WAS USED: .............................................18

INDICATING VACCINE GROUP ASSOCIATED: ...............................................18

REPORTING THE ORDINAL POSITION IN A SERIES: .....................................19

REPORTING THE NUMBER OF DOSES IN A SERIES: .....................................20

REPORTING NEXT DOSE RECOMMENDATION DATES (FORECAST ONLY):......20

REPORTING RECOMMENDATION REASONS: ...............................................21

COMPLETE EXAMPLE OF EVALUATION AND FORECASTING: ........................21

IMPORTANT NOTES: ..................................................................................23

USING THE NTE SEGMENT ASSOCIATED WITH AN OBX TO PROVIDE MORE 

INFORMATION: .........................................................................................23

EXAMPLE VXU #4 - SEND CLIENT SPECIFIC CONDITIONS........................................24

EVIDENCE OF IMMUNITY: ...........................................................................24
CONTRAINDICATIONS TO IMMUNIZATION: ....................................................24

FACTORS WHICH INDICATE THE NEED FOR AN IMMUNIZATION OR A CHANGED 

RECOMMENDATION: ..................................................................................25

EXAMPLE VXU #5 – SEND IMMUNIZATIONS ASSOCIATED WITH REACTIONS (ADVERSE 

EVENTS) .............................................................................................................25

EXAMPLE VXU #6 –DELETE AN IMMUNIZATION RECORD .......................................26

VXU EXAMPLE #7--SEND INFORMATION ABOUT VACCINE INFORMATION STATEMENT 

(VIS) ..................................................................................................................27

VXU EXAMPLE #8—SEND INFORMATION ABOUT IMMUNIZATION REFUSAL .............29

VXU EXAMPLE #9—SEND TWO LOT NUMBERS IN RXA ........................................29

VXU EXAMPLE #10—RECORDING BIRTH INFORMATION ........................................29

VXU EXAMPLE #11—RECORDING AN INCOMPLETELY ADMINISTERED DOSE OR A 

NON-POTENT DOSE. .............................................................................................30

SEND ACKNOWLEDGEMENT ACK IN RESPONSE TO VXU ......................................30

SEND ACKNOWLEDGEMENT OF SUCCESS IN ACK .......................................31

SEND ERROR IN ACK ...............................................................................31

SEND REQUEST FOR VACCINE HISTORY (QBP/RSP) ............................................32

PROCESS FOR REQUESTING IMMUNIZATION HISTORY ................................. 32

DESCRIPTION OF THE VXQ/VXX/VXR PROCESS FROM VERSION 2.3.1 .......32

USING QBP QUERY TO REPLICATE VXQ/VXX/VXR....................................34

RETURNING A LIST OF CANDIDATE CLIENTS IN RESPONSE TO QBP^Q11

QUERY ....................................................................................................37

RETURNING AN IMMUNIZATION HISTORY IN RESPONSE TO A REQUEST FOR 

IMMUNIZATION HISTORY QUERY ................................................................38

ACKNOWLEDGING A QUERY THAT FINDS NO CANDIDATE CLIENTS.................38

ACKNOWLEDGING A QUERY THAT FINDS MORE CANDIDATES THAN REQUESTED

...............................................................................................................39

USING A TWO-STEP PROCESS TO REQUEST AN IMMUNIZATION HISTORY.......40

RETURNING A LIST OF CANDIDATE CLIENTS IN RESPONSE TO PDQ QUERY ...43

RECEIVING SYSTEM DETERMINES THAT MESSAGE HAS ERRORS...................44

MALFORMED MESSAGE.............................................................................44

NO MATCH IS FOUND ...............................................................................45
Table of Figures

Revision history.....................................................................................................3

Table 2-1 Actors and Goals for Messaging ...........................................................7

Figure 2-1 Use Case Diagram ............................................................................10

Figure 2-2 Finding a Client ..................................................................................11

Figure 2-3-Use Cases 1 and 2: Send and Receive Immunization History ..........12

Figure 2-4-Use Cases 3, 4 and 5: Request Immunization History, Respond to 

Request and Accept Requested History ......................................................14

Figure 2-5--Using PDQ to Resolve Identity Prior to Request for Immunization 

History .........................................................................................................16

Figure 2-6--Implicit Identity Resolution in Response to a Request for 

Immunization History When One High-confidence Match Is Found .............17

Figure 2-7--Implicit Identity Resolution in Response to a Request for 

Immunization History When Lower Confidence Candidates Are Found ......18

Figure 2-8--Send Demographic Data Via VXU or ADT .......................................20

Figure 2-9--VXU Process Model .........................................................................23

Table 3-1 Outcome of Encoding Rule Breaches .................................................31

Table 3-2--Sending Application Conformance ....................................................33

Table 3-3--Receiving Application Conformance ..................................................35

Table 3-1--Message Element Attributes ..............................................................36

Table 4-1-- Data Types .......................................................................................40

Table 4-2 Coded Element (CE) ...........................................................................41

Table 4-3 Coded Element (CE) for Text Only RXA-9 .........................................43

Table 4-4 Composite Quantity with Units (CQ) ..................................................43

Table 4-5 Coded with Exceptions (CWE) ...........................................................45

Table 4-6 Extended Composite ID with Check Digit(CX) ...................................46

Table 4-7 Date (DT) ...........................................................................................48

Table 4-8 Date/Time (DTM) ...............................................................................49

Table 4-9 Entity Identifier (EI) .............................................................................50

Table 4-10 Error Location (ERL) ........................................................................51

Table 4-11 Family Name ....................................................................................52

Table 4-1 Formatted Text ...................................................................................53

Table 4-12 Hierarchical Designator (HD) ............................................................54

Table 4-13 --ID Data Type ..................................................................................55

Table 4-14 Coded Values for User Defined Tables (IS) ......................................56

Table 4-15 Location with Address Variation 2 .....................................................56

Table 4-16 Message Type (MSG) .......................................................................58

Table 4-17 Numeric (NM) ...................................................................................59

Table 4-18 Processing Type (PT) ......................................................................59

Table 4-19 Street Address (SAD) .......................................................................60

Table 4-20 Sequence Id (SI) ...............................................................................60

Table 4-21 String (ST) ........................................................................................61

Table 4-22 Time Stamp (TS) ..............................................................................61

Table 4-23 Version ID (VID) ................................................................................62

Table 4-24 Extended Address (XAD) ..................................................................62
Table 4-26 Extended Composite ID Number and Name (XCN) ..........................65

Table 4-26 Extended Composite ID Number and Name for Organizations (XON)

.....................................................................................................................69

Table 4-27 Extended Person Name (XPN) .........................................................70

Table 4-28 XTN Extended Telecommunication Number (XTN) ..........................72

Table 5-1 Message Segments ............................................................................75

Table 5-2 Batch Header Segment (BHS) ............................................................82

Table 5-3 Batch Trailer Segment (BTS) ..............................................................84

Table 5-4 Error Segment (ERR)..........................................................................85

Table 5-5 Event Segment (EVN).........................................................................87

Table 5-6 File Header Segment (FHS) ...............................................................89

Table 5-7 File Trailer Segment (FTS) ................................................................. 90

Table 5-8 Message Acknowledgement Segment (MSA) .....................................91

Table 5-9 Message Header Segment (MSH) ......................................................93

Table 5-10-Next of Kin Segment (NK1) ............................................................100

Table 5-11 Note Segment (NTE) ......................................................................104

Table 5-12 Observation Segment (OBX) ..........................................................105

Table 5-14 Common Order Segment (ORC) ....................................................115

Table 5-15-Patient Demographic Segment (PD1).............................................121

Table 5-16-Patient Identifier Segment (PID) .....................................................126

Table 5-17-Query Acknowledgement Segment ................................................133

Table 5-18-Query Parameter Definition (QPD) .................................................134

Table 5-19-Response Control Parameter .........................................................136

Table 5-20 Pharmacy/Treatment Administration (RXA) ....................................139

Table 5-21 Pharmacy/Treatment Route (RXR) .................................................147

Table 6-1-Supported Messages ........................................................................148

Table 6-2--VXU Segment Usage ......................................................................148

Table 6-3 QBP/RSP – Query By Parameter/Segment Pattern Response ........150

Table 6-4-Segment Pattern Response (RSP) ...................................................151

Table 6-5 Message Acknowledgement Segment (ACK) ...................................151

Table 6-6-ADT A04 Message ...........................................................................153

Table 7-1 Request Immunization History Query Profile ....................................156

Table 7-2-Response Grammar to Different Outcomes ......................................157

Table 7-3 Response Grammar RSP^K11 .........................................................159

Table 7-4 MSH Specification for Request Immunization History Query ............161

Table 7-5 QPD Input Parameter Specification ..................................................162

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

Table 7-7 RCP Response Control Parameter Field Description and Commentary

...................................................................................................................166

Table 7-8 Query Response Possibilities ...........................................................167

Figure 7-1--Return Candidate List.....................................................................168

Table 7-9 Response Grammar RSP^K11 .........................................................169

Figure 7-2 Return Candidate List (RSP^K11) ...................................................171

Figure 7-3 Return Immunization History Use Case ...........................................173

Figure 7-4 Return Immunization History Response Grammar ..........................174

Figure 7-5 Return Immunization History Sequence Diagram ............................176
Table 1--Release 1.1 Changes .........................................................................177

Table 2--Release 1.2 Changes .........................................................................177

Table 3--Release 1.3 Changes .........................................................................178

Table 4--Release 1.4 ........................................................................................179

Table B-1--Immunization History Core Data Elements .........................................1

Figure 6-VXU Business Process ...........................................................................5

Table B-2 --Segment Usage .................................................................................7

Table B-3 --Eligibility Outcomes ..........................................................................11

Table B-4--Codes Supporting Messaging Evaluation and Forecasting ...............13

Table B-5--Due Date Definitions .........................................................................20

Table B-6--Birth Information Fields .....................................................................30

Figure 7--VXQ/VXX/VXR processes ...................................................................33

Figure 8--Request Immunization History .............................................................35
Chapter 1: Introduction 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 1

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 usage. 

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 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 

 

1

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

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 2

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 

 sending and receiving demographic information about the individuals 

 requesting immunization histories for individuals 

 responding to requests for immunization histories by returning immunization 

histories 

 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.3

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. 

 

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. 
Chapter 1: Introduction 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 3

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. They start at the most granular level and 

proceed to the message level. 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. 

 

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. 
Chapter 1: Introduction 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 4

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 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. The values used in messages are specified in appendix A. Data 

types are the building block for segments, described in the next chapter. 

Chapter 5-Message Segments 

Chapter 5 gives specifications for message segments. Segments are units of the message 

that carry specific types of information. For instance PID carries patient identifying 

information. The segments included in this chapter are those that are needed by the 

messages specified in Chapter 6. 

Chapter 6- Message Details for Immunization 

Chapter 6 specifies how to use the building blocks of data types and segments to meet 

the business needs to convey immunization records. It will include specification for 

requesting an immunization history and acknowledging message receipt or errors. 

Chapter 7- Query Profile for Requesting an Immunization History 

HL7 has a template for specifying a query. This chapter uses that template to give the 

specifications for a query requesting an Immunization History. It is built on the previous 

4 chapters. Two child profiles, which support response to the query, are also found in 

this chapter. 

Appendix A-Code Tables 

This appendix lists expected values for all coded data elements used in this Guide. 

Appendix B- Message examples 

This appendix will show detailed examples of how to implement the messages specified 

in the body of the Implementation Guide. 
Chapter 1: Introduction 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 5

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.
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 6

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 systems5

 An actor with a supporting role may be a Master Person Index (MPI)6. 

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 

 

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 PIX query asks for one system’s personal identifier, based on 

another system’s identifier. 
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 7

 Clinicians

 Billing systems 

These actors will not be directly addressed in this Guide. They interact with the primary 

actors to accomplish their needs. 

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 demographic data

Request immunization record

Request person id

Acknowledge receipt of 

message

Report processing errors from 

receipt of message
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 8

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
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 9

Actor Responsibility Messaging Goals

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 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: 

 Immunization history supplier 

 Immunization history consumer 

 Demographic information supplier 

 Demographic information consumer 

 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. Note that some of these use cases are logically related. For instance, Request 

Immunization History is paired with Return Immunization History. Send Immunization 

History needs the receiver to Receive Immunization History. These use cases are not 

intended to be the basis of a software design process. 
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 10

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. For details, see use case 3, 4A and 

4 below. 

Figure 2-1 Use Case Diagram 
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 11

The following diagram illustrates a more detailed view of the request immunization 

history and return immunization history. It breaks the Find Candidate Clients use case 

out. Note that a system may request identity resolution (find client) prior to requesting 

an immunization history. Alternatively, a system may request an immunization history. 

This can trigger an implicit request to find a client. 

Figure 2-2 Finding a Client 

The following lists the HL7 Messages shown below in the Use Cases: 

ACK-Acknowledgement message 

ADT-Admit, Discharge and Transfer message 

QBP-Query by parameter 

RSP-Respond to QBP 

VXU-Unsolicited vaccine history 

The following are profiled queries supported by IHE for identity resolution: 

PDQ-A specific type of QBP that facilitates identify resolution based on demographic 

information 

PIX- A specific type of QBP that accomplishes id cross reference 

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. 

HL7 version 2.5.1 Message Type: VXU 
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 12

Precondition: A user or other actor requests that the sending system send an 

immunization history. 

Figure 2-3-Use Cases 1 and 2: Send and Receive Immunization History 

This sequence diagram illustrates the message flow. The sender sends an immunization 

record (Use Case 1). The receiver accepts the message (Use Case 2) and processes it. 

The receiver may send an acknowledgment message. (See Use Case 9) The transactions 

that are of interest are indicated by bold arrows. 

Use Case 2—Receive Immunization History 

Goal: To receive an unsolicited immunization history. It may be an update or a new 

record. This use case does not have responsibility for the processing of the message. The 

receiving system may review and accept the immunization history if it chooses, but this 

outside the scope of this use case. 

HL7 version 2.5.1 Message Type: VXU 

Precondition: A VXU is received by the receiving system. 

Use Case 3—Request Immunization History 

 

Goal: To request an immunization history from another system. 

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. 
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 13

The old VXQ query included implicit identity resolution. If a high confidence candidate 

was identified, based on demographics and other identifiers, an immunization history 

was returned in a VXR. If lower confidence candidates were found, a list of candidates 

was returned for further selection in a VXX. The selection from the VXX informed the requery with a new VXQ. The approach outlined in this Guide allows this process to be 

followed using different messages. 

Another approach that is common in the informatics world is to separate the identity 

resolution from the request for content (immunization history in this case). Here the 

requester sends a query seeking a candidate, based on demographics and other 

identifiers. The requester selects from the candidates returned and then sends the 

request for content based on that selection. The identity may be sought from a separate 

Master Person Index or from the content provider. One industry standard, which 

supports this approach, is the PDQ query profile by Integrating the Healthcare 

Enterprise (IHE). The approach outlined in this Guide allows this process to be followed. 

A third situation occurs when the requester already knows an identifier meaningful to 

the responding system. This may occur when the sending system has already sent a 

record for the person of interest that includes the sender’s identifier. Alternatively, it 

may occur if the requester knows the unique identifier used by the responding system. 

The approach outlined in this Guide allows this process to be followed. 

Since identity resolution is required either implicitly or explicitly, a use case is described 

for finding a client/candidate (Use Case 4A). That use case contains the alternate flows 

for the different paths. 

Note that more detailed information about the flow of events and options is available in 

Appendix B. 

HL7 version 2.5.1 Message Type: QBP using Request Immunization History query 

profile. 
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 14

Figure 2-4-Use Cases 3, 4 and 5: Request Immunization History, Respond to Request and 

Accept Requested History 

Note that the sending system process may include confirming that the record returned 

is the one being sought. This process is not specified here. 

Use Case 4—Return Immunization History 

Goal: To return an immunization history. It does not include the processes used to find 

candidate clients for return. 

There are 4 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. 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. 

See Figure 2-6. 

 

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. 
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 15

Standard Reference HL7 version 2.5.1 Message Type: RSP 

Precondition: A receiving system receives a request for an immunization history. 

HL7 version 2.5.1 Message Type: 

 QBP using Request Immunization History query profile 

Use Case 4A—Find Candidate Clients 

 

Goal: To find one or more candidate clients from another system and select one to be 

used when requesting an immunization history. 

Precondition: 

There are two potential preconditions. 

1. A user or other actor requests that the sending system send a request for one or 

more candidate clients using demographic information and/or other identifiers. 

(This is well specified in the IHE PDQ profile) 

2. A receiving system receives a request for immunization history using a request 

for immunization history query. 

If exactly one high confidence match is found then an immunization history is returned. 

If this query does not find one high confidence candidate, but rather finds one or more 

lower confidence candidates then a list of candidates are returned. If more than one 

high confident match is found, then this is treated as a lower confidence match. 

Note that the diagrams below are intended to put the messages in context and do not 

accurately reflect the architecture that would support the activities. 

Request Identity Resolution Prior to Requesting an Immunization History 

The following diagram illustrates the process and messages where a system uses a PDQ 

query to request identifiers and demographics for a client. The result of this process is 

then used to populate a Request for Immunization History query. Messages have bolded 

arrows. Other processes are not bolded. It should be noted that the immunization 

history supplier may also act as the id supplier, but this is not required. This particular 

Use Case focuses on the interactions between the requester and the id supplier. The 

other transactions illustrate how this fits into the rest of the process. We assume that 

the identifier used in the QBP^Q11 is unique within the immunization history supplier. 
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 16

Figure 2-5--Using PDQ to Resolve Identity Prior to Request for Immunization History 

Requesting an Immunization History Using Implicit Identity Resolution 

The following 2 diagrams illustrate how a system, which uses a Request for 

Immunization History, relies on implicit identity resolution. 

The first drawing illustrates the case when one high confidence candidate is found. The 

outcome of the find client process is a call for the system to send the immunization 

history back to the requesting system. Messages are bolded. 
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 17

Figure 2-6--Implicit Identity Resolution in Response to a Request for Immunization History 

When One High-confidence Match Is Found 

When the find client process finds lower confidence candidates, then the system returns 

a list of candidate clients. The user reviews these and selects the one of interest. The 

selection is used to populate a second Request for Immunization History query. The 

identity resolution process points to the correct client and an immunization history is 

returned. The user may choose to refine the search criteria and submit a new query, if 

he/she believes that a match should have been found. 
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 18

Figure 2-7--Implicit Identity Resolution in Response to a Request for Immunization History 

When Lower Confidence Candidates Are Found 

HL7 version 2.5.1 Message Type: 

 QBP using Request Immunization History query profile 

Or

 QBP using PDQ (IHE) 

Use Case 5--Accept requested history: 

Scope: 

The goal of this use case is to accept an immunization history in response to a query for 

an immunization history from another system. 

Standard Reference HL7 version 2.5 Message Type: RSP

Preconditions: A sending system receives a requested immunization history. 

Sequence Diagram: 

See sequence diagrams for use case 3 above. 
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 19

Use Case 6—Send Demographic Data 

Goal: 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. The 

message will include an indication of the expected/requested acknowledgement. 

Standard Reference HL7 version 2.5 Message Type: 

The standard messages that may be used for carrying demographic data are VXU and 

ADT. 

Precondition: A user or other actor requests that the sending system send demographic 

data. 

Sequence Diagram: 

See Figure 2.7. 

Use Case 7—Accept Demographic Data 

Goal: To accept 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. The 

message will include an indication of the expected/requested acknowledgement. 

Standard Reference HL7 version 2.5 Message Type: 

The standard messages that may be used for carrying demographic data are VXU, ADT. 

Precondition: The receiving system receives demographic data. 

Sequence Diagram: 

See Figure 2-7. 
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 20

Figure 2-8--Send Demographic Data Via VXU or ADT 

Use Case 8--Acknowledge Receipt 

Scope: 

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. 

Standard Reference HL7 version 2.5 Message Type: ACK, RSP 

Precondition: A system has processed a message and determined the success of receipt. 

Sequence Diagram: 

See sequence diagrams for use cases above. 
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 21

Use Case 9—Report Error 

Scope: 

The goal of this use case is to send error messages related to messages. These errors 

could result of rejection of message or parts of message. 

Standard Reference HL7 version 2.5 Message Type: ACK, RSP 

Precondition: A system has processed a message and found errors. 

Sequence Diagram: 

See sequence diagrams for use cases above. 

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 Create message9

o Assemble data on person of interest 

o Build the VXU message with this data 

o Send the message 

o Connect to the receiving system. The partners must agree on how this is 

done. 

o 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 Determine that the message is in the appropriate format. 

o Parse the message into a format that it uses. 

o Evaluate the message components to determine that these are correctly 

formatted and specified. 

 

9

 Identifying which client’s record to send is an important consideration, but outside the scope of 

this document. 
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 22

o Send an acknowledgement to the sender, indicating the message has been 

successfully processed. 

o Integrate the received record into the existing data base.10

o Deduplicate on client to be sure that each client only has one record. 

o Deduplicate the events (immunizations, for instance). 

o Insert or update data. 

Obviously, the interaction may be more complex than this11. 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. 

 

10 Local business rules determine how this occurs and should be documented clearly. 

11 See Appendix B for illustrations of the processing rules expected when handling HL7 

messages. 
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 23

Figure 2-9--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. 

Appendix B gives detailed example messages and has illustration of the business 

processes surrounding other message transactions. 

Core Data Elements of an Immunization History 

Systems that support immunization information have a number of important 

responsibilities including: 
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 24

 Consolidation of Immunization records from various sources 

 Supplying consolidated immunization history to users 

 Forecasting next doses due 

 Evaluating vaccine doses administered 

 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.12It 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. 

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. 

 

12 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. 
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 25

Snapshot Mode

Immunization history messages should be sent in snapshot mode, meaning that all 

information related to the smallest individually identifiable unit are complete. That is, 

the complete immunization history known to the sender should be sent each time the 

immunization history is messaged. Because consolidated immunization histories may 

come from more than one source and each source may have incomplete information, 

the receiving system will need to have process for integrating snapshots from different 

sources. 

Field Length And Truncation

This guide pre-adopts field length definition conventions and the stated lengths from 

HL7 Version 2.7.1, Chapter 2 Control; it also provides further constraints to support the 

use case and scope defined in this guide. 

The Conformance Length parameter (Version 2.7.1, Chapter 2 Control, Section 2.5.5.3, 

Conformance Length) has also been adopted in this guide and is defined in this excerpt 

from the base standard: 

--------- start citation ---------

If populated, the conformance length column specifies the minimum length that 

applications must be able to store. Conformant applications SHALL not truncate a 

value that is shorter than the length specified. 

--------- end citation ---------

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 
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 26

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". 
Chapter 3: HL7 Messaging Infrastructure 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 27

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 
Chapter 3: HL7 Messaging Infrastructure 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 28

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

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: 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 bounded 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. 
Chapter 3: HL7 Messaging Infrastructure 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 29

Value in Field Meaning

“”

|””|

Nullify the value recorded in the receiving system data base.

<empty field>

||

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. Data types are 

given a 2- or 3-letter code. 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: 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: 

<CR> = 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. 
Chapter 3: HL7 Messaging Infrastructure 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 30

Basic Message Construction Rules 

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. 

 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. 

Encoding Rules for Receiving 

 1. If a data segment that is expected is not included, treat it as if all data fields within 

were not present. 

 2. If a data segment is included that is not expected, ignore it; this is not an error. 

 3. If data fields are found at the end of a data segment that are not expected, ignore 

them; this is not an error. 
Chapter 3: HL7 Messaging Infrastructure 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 31

Implications of the Encoding Rules 

The following table lists the expected outcome implied by the encoding rules above. 

Table 3-1 Outcome of Encoding Rule Breaches 

Condition Immediate Outcome Secondary Outcome

Required segment not 

present.

Message rejected. Error message returned to 

sending system.

Segments not in correct 

order

Out of sequence segment 

ignored.

If this segment is required, 

then message rejected.

Segment not expected Segment is ignored

Non-repeating segment is 

repeated

Repeated segment is 

ignored. First segment is 

processed normally.

Information in the repeated 

segment is lost to receiving 

system.

Required segment has 

required fields that are not 

present or rejected due to 

errors

Message is rejected. Error message returned to 

sending system.

Optional segment has 

required field that is not 

present or rejected due to 

errors.

Segment is ignored Message is not rejected 

because of this error. Error 

message returned.

Required field is not 

present.

Segment is 

ignored/rejected.

If segment is required, then 

message is rejected. If 

segment is not required, 

the information in the 

segment is lost to receiving 

system.

Required field is rejected 

due to errors.

Segment is 

ignored/rejected.

If segment is required, then 

message is rejected. If 

segment is not required, 

the information in the 

segment is lost to receiving 

system.

Incoming data value is not 

in the list of expected 

values for a field that is 

constrained to a list of 

values.

Incoming data are treated 

as empty.
Chapter 3: HL7 Messaging Infrastructure 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 32

Note that all errors in processing a message should be communicated back to the 

sending system unless the initiating system has indicated that no response is desired. 

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 from meaningful use of immunization data. The 

following list 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. 

2. Any field or component that is a required National Vaccine Advisory Committee 

(NVAC) Core Data element is required or required but may be empty13

. 

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) Draft 

Version (Aug 31, 2011) as revised by the S&I Framework Lab Implementation Guide 

Recommendations (Sept 2, 2011). 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; upon successful ballot and 

publication this material will be replaced with a reference to the normative 

documentation. 

---------- start citation---------

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 

 

13 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. 
Chapter 3: HL7 Messaging Infrastructure 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 33

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 RERequired 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 

Symbol Definition Implementation 

Requirement

Operation Requirement

R Required The application SHALL 

implement “R” elements.

The application SHALL populate 

“R” elements with a non-empty 

value.

RE Required but The application SHALL The application SHALL populate 
Chapter 3: HL7 Messaging Infrastructure 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 34

may be 

empty

implement “RE” elements. “RE” elements with a non-empty 

value if there is relevant data. The 

term “relevant” has a confounding 

interpretation in this definition14

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. 

 

14 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.
Chapter 3: HL7 Messaging Infrastructure 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 35

Table 3-3--Receiving Application Conformance 

Symbol Definition Implementation 

Requirement

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.15

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.

 

15 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. 
Chapter 3: HL7 Messaging Infrastructure 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 36

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.

None, if the element is not 

sent.

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 notsupported 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 --------- 

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-1--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.
Chapter 3: HL7 Messaging Infrastructure 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 37

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

[

XXX

[YYY]

]

YYY is nested within the segment block starting with XXX. It is an

optional sub-segment to XXX16 . 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.

Length –

(V2.7.1)

For each component in the data type table and field in a segment there 

is a normative length column (LEN) and conformance length (C.LEN). 

This guide follows the length definitions and conventions from V2.7.1.

LEN – If populated, defines the minimum and maximum length that 

must be supported. The minimum or the maximum may be blank, e.g., 

“..20” or “2..”. indicating there is no minimum or maximum.

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.

 

16 YYY may only be included if XXX is present. XXX may be present without YYY. 
Chapter 3: HL7 Messaging Infrastructure 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 38

Abbreviation Description

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. 

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.
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 39

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 for IIS Use 

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 fields that are anticipated for IIS use. Data types for fields 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 fields that have a usage of R, RE, C(a/b). Data types used only for optional 

fields are not included. Please refer to the base standard for those data types. 

Depending on the components used, the usage of data type components for some data types varies. To clearly indicate when to use specific 

data type components, each data type that has a varying definition based on profile will be documented with multiple variations, e.g., CE vs. 

CE_TX. Composite data types indicate which variety of the component's data type is applicable, while the data type of a field is marked as 

"varies" where the comment indicates the data type choices based on the declared profile or component.
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 40

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

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

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
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 41

XTN Extended telephone number

CE -- Coded Element (most uses) 

Definition: This data type transmits codes and the text associated with the code. 

The following specifications apply to all uses of CE data type EXCEPT RXA-9, Administration Notes. That field may use this specification or 

the specification that follows this section. 

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 is not further used.

3

Name of Coding

System ID R 1..20 HL70396

4

Alternate 

Identifier ST RE 1..50

Alternate Identifying coded.

5 Alternate Text ST RE 1..999 Human readable text that is not further used. 

6

Name of 

Alternate

Coding system ID C(R/X) 1..20

If CE-4 (Alternate Identifier) is 

valued

HL70396

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.
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 42

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.

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 RXA 5, Administered Code: 

|50^DTAP-HIB^CVX^90721^DTAP-HIB^C4| 

CE_TX -- Coded Element (text only in RXA-9)

Definition: This data type may be used to transmit text only notes. 

The following specifications apply to use of CE data type for RXA-9, administration notes only. 
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 43

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.

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 4-4 Composite Quantity with Units (CQ) 

SEQ COMPONENT 

NAME

Data 

Type

Usage LEN Conditional Predicate Value set COMMENTS

1 Quantity NM R 16

2 Units CE R HL7 0126 

(constrained)
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 44

Conformance Statement: 

IZ-1: CQ-1 (Quantity) shall be a positive integer. 

IZ-2: CQ-2 (Units) shall be the literal value “RD”.

 

Maximum Length: 500 

Note: CQ cannot be legally expressed when embedded within another data type. Its use is constrained to a segment field. 

Examples:

|10^RD| 10 records

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. Field-by-field, default units may be defined within the 

specifications. When the quantity is measured in the default units, the units need not be transmitted. If the quantity is recorded in units different 

from the default, the units must be transmitted. 

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) when text is in place, the code may be omitted.
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 45

Table 4-5 Coded with Exceptions (CWE) 

SEQ Component 

Name

Data 

Type

Usage LEN Conditional Predicate Value Set Comments

1 Identifier ST RE 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 RE 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.
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 46

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 

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
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 47

SEQ COMPONENT 

NAME

Data 

Type

Usage LEN Conditional Predicate Value 

set

COMMENTS

5 Identifier Type 

Code

ID R 2..5 HL70203

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

Definition: This data type is used for specifying an identifier with its associated administrative detail.

Note: The check digit and check digit scheme are empty if ID is alphanumeric.

Example:

|1234567^^^ME129^MR|

ID (ST) 

Definition: The value of the identifier itself.

Check Digit (ST) 

This component should be valued empty.

Check Digit Scheme (ID) 

This component should be valued if Check digit is populate, otherwise it should be empty.
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 48

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 maintained by each IIS. The first component shall be used for this 

unique name. The second and third may be used if OIDs17 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.

DT -- Date 

Definition: Specifies the century and year with optional precision to month and day.

Table 4-7 Date (DT) 

SEQ

Component 

Name

Data 

Type Usage LEN Conditional Predicate

Value 

Set Comments

1 Date R 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|

 

17 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).” 
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 49

DTM -- Date/Time 

Table 4-8 Date/Time (DTM) 

SEQ

Component 

Name

Data 

Type Usage LEN Conditional Predicate Value Set Comments

Date/time R 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: 

 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." 

 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”

 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.
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 50

Table 4-9 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.1 (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, <entity identifier>, is defined to be unique within the series of identifiers created by the <assigning authority>, defined by a 

hierarchic designator, represented by component 2. 

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| 
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 51

ERL -- Error Location 

 

Table 4-10 Error Location (ERL) 

Definition: 

This data type identifies the segment and its constituent where an error has occurred.

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.

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 RE 2 This should not be populated if the error refers to 

the whole segment.

4 Field Repetition NM C(R/X) 2 If ERL.3 (Field Position) is valued

5 Component 

Number

NM RE 2 Should be populated ONLY when a particular 

component cause the error.

6 Sub-Component 

Number

NM RE 2 Should be populated ONLY when a particular 

sub-component cause the error.
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 52

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^3| 

FN -- Family Name 

Definition: This data type contains a person’s family name or surname.

Table 4-11 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
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 53

SEQ COMPONENT 

NAME

Data 

Type

Usage LEN Conditional Predicate Value Set COMMENTS

4 Surname Prefix 

From 

Partner/Spouse

ST O

5 Surname From 

Partner/Spouse

ST O

Surname (ST) 

This is the person's last name.

Example from PID: |Anyperson| 

FT – Formatted Text 

Table 4-1 Formatted Text 

SEQ COMPONENT 

NAME

Data 

Type

Usage LEN Conditional Predicate Value Set COMMENTS

1 Formatted Text 

Data

R 1..65536

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., |^&~\ or |^&~\#).

HD -- Hierarchic Designator 

The use of OIDs in fields using this data type is encouraged. 
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 54

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.

Table 4-12 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)

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”. 

IS -- Namespace ID 

User-defined Table 0300/0361/0362/0363 - Namespace ID is used as the HL7 identifier for the user-defined table of values for this component. 

Note: When the HD is used in a given segment (either as a field or as a component of another data type) this table may be re-defined (given a different userdefined table number and name) by the technical committee responsible for that segment.

Tables 0361-0363 are preferred for most instances. For instance for identifying the assigning authority, use 0363.
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 55

Universal ID (ST) 

The HD’s second component, <universal ID> (UID), is a string formatted according to the scheme defined by the third component, <universal ID 

type> (UID type). The UID is intended to be unique over time within the UID type. It is rigorously defined. Each UID must belong to one of the 

specifically enumerated schemes for constructing UIDs (defined by the UID type). The UID (second component) must follow the syntactic rules of 

the particular universal identifier scheme (defined by the third component). Note that these syntactic rules are not defined within HL7 but are 

defined by the rules of the particular universal identifier scheme (defined by the third component).

Universal ID Type (ID) 

The third component governs the interpretation of the second component of the HD. If the third component is a known UID refer to HL7 Table 0301 

- Universal ID type for valid values, then the second component is a universal ID of that type. Since the second component is constrained to OID, 

then the value of component 3 shall be ISO, when populated.

Example from MSH: 

|CA12^^| 

ID -- Coded Values for HL7 Tables 

Definition: This data type is used for coded values from an HL7 table. 

Table 4-13 --ID Data Type 

SEQ COMPONENT 

NAME

Data 

Type

Usage LEN Conditional Predicate Value Set COMMENTS

1 Coded Value for 

HL7-defined 

Tables

R 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| 
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 56

IS -- Coded Values for User Defined Tables 

Definition: This data type is used for codes from User-defined Tables. 

Table 4-14 Coded Values for User Defined Tables (IS) 

SEQ COMPONENT 

NAME

Data 

Type

Usage Length Conditional Predicate Value Sets COMMENTS

1 Coded Value for 

User-Defined 

Tables

1..20

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 4-15 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 This represents the location that the service was 

provided. For example the clinic. 

5 Location Status IS O
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 57

SEQ COMPONENT 

NAME

Data 

Type

Usage LEN Conditional Predicate Value Sets COMMENTS

6 Patient Location 

Type

IS O

7 Building IS O

8 Floor IS O

9 Street Address ST O

10 Other 

Designation

ST O

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

MSG -- Message Type 

Definition: This field contains the message type, trigger event, and the message structure ID for the message.
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 58

Table 4-16 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)

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| 

The third component was not required in version 2.3.1. It is now required. 
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 59

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 4-17 Numeric (NM) 

SEQ COMPONENT 

NAME

Data 

Type

Usage LEN Conditional Predicate Value Set COMMENTS

1 Numeric R 1..16

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 4-18 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 part of a production, training, or debugging system. Refer to HL7 Table 0103 - Processing ID for valid 

values.
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 60

SAD -- Street Address 

Definition: This data type specifies an entity's street address and associated detail.

Table 4-19 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

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 4-20 Sequence Id (SI) 

SEQ COMPONENT 

NAME

Data 

Type

Usage LEN Conditional Predicate Value set COMMENTS

1 Sequence ID R 1..4

ST – String 

Definition:
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 61

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-21 String (ST) 

SEQ COMPONENT 

NAME

Data 

Type

Usage LEN Conditional Predicate Value set COMMENTS

1 String Data R

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., |^&~\ or |^&~\#).

TS -- Time Stamp 

Definition: Specifies a point in time.

Table 4-22 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

VID -- Version Id 

Definition: This specifies the HL7 version. 
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 62

Table 4-23 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

C(O/O) O

3 International 

Version ID

C(O/O) O

Conformance Statement: 

IZ-7: VID-1 (Version Id) SHALL be valued with the literal “2.5.1”

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 4-24 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
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 63

SEQ COMPONENT 

NAME

Data 

Type

Usage LEN Conditional Predicate Value Sets COMMENTS

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

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
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 64

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)

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.

County/Parish Code (IS) 

A code that represents the county in which the specified address resides. User-defined Table 0289 - County/parish is used as the HL7 identifier for 

the user-defined table of values for this component. When this component is used to represent the county (or parish), component 8 <other 

geographic designation> should not duplicate it (i.e., the use of <other geographic designation> to represent the county is allowed only for the 

purpose of backward compatibility, and should be discouraged in this and future versions of HL7).

Allowable values: codes defined by government.
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 65

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 4-25 Extended Composite ID Number and Name (XCN) 

SEQ COMPONENT 

NAME

DT 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

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
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 66

SEQ COMPONENT 

NAME

DT Usage LEN Conditional Predicate Value Set COMMENTS

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

20 Expiration Date TS O

21 Professional 

Suffix

ST O

22 Assigning 

Jurisdiction

CWE O
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 67

SEQ COMPONENT 

NAME

DT Usage LEN Conditional Predicate Value Set COMMENTS

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 XCX-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.).

Source Table (IS) 

User-defined Table 0297 – CN ID source is used as the HL7 identifier for the user-defined table of values for this component. Used to delineate the 

first component.
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 68

Assigning Authority (HD) 

The assigning authority is a unique identifier of the system (or organization or agency of department) that creates the data. 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, 

<namespace ID>.

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: When the HD data type is used in a given segment as a component of a field of another data type, User-defined Table 0300 - Namespace ID (referenced 

by the first sub-component of the HD component) may be re-defined (given a different user-defined table number and name) by the technical committee 

responsible for that segment. User-defined Table 0363 is specified by this Implementation Guide for Assigning Authority.

By site agreement, implementers may continue to use User-defined Table 0300 – Namespace ID for the first sub-component.

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.

Identifier Type Code (IS) 

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.

Professional Suffix (ST) 

Definition: Used to specify an abbreviation, or a string of abbreviations denoting qualifications that support the person’s profession, (e.g., licenses, 

certificates, degrees, affiliations with professional societies, etc.). The Professional Suffix normally follows the Family Name when the Person 

Name is used for display purposes. Please note that this component is an unformatted string and is used for display purposes only. 

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.
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 69

Table 4-26 Extended Composite ID Number and Name for Organizations (XON) 

SEQ COMPONENT 

NAME

DT 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 is valued The Assigning Authority is used to identify the 

system, application or organization that assigned 

the ID in Component 10.

7 Identifier Type 

Code

ID C(R/X) 2..5 If XON.10 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 is not valued
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 70

Extended Person Name (XPN) 

Definition: This is used for representing a person’s name.

Table 4-27 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

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
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 71

SEQ COMPONENT 

NAME

Data 

Type

Usage LEN Conditional Predicate Value Sets COMMENTS

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.

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.
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 72

XTN - Extended Telecommunication Number 

Definition: This contains the extended telephone number. 

Table 4-28 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 Telecommunicati

on Use Code

ID R HL70201

3 Telecommunicati

on Equipment 

Type

ID RE HL70202

4 Email Address ST C(R/X) 1..199 If the XTN-2 (telecommunication 

type code) is valued “NET”

5 Country Code NM O

6 Area/City Code NM C(RE/X) 5 If the XTN-2 (telecommunication 

type code) is valued not “NET”

7 Local Number NM C(R/X) 9 If the XTN-2 (telecommunication 

type 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
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 73

SEQ COMPONENT 

NAME

Data 

Type

Usage LEN Conditional Predicate Value Set COMMENTS

12 Unformatted 

Telephone 

number 

ST O

Note: Components five through nine reiterate the basic function of the first component in a delimited form that allows the expression of both local and 

international telephone numbers. As of 2.3, the recommended form for the telephone number is to use the delimited form rather than the unstructured form 

supported by the first component .

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.

Phone Number (NM) 

The phone number for the entity.
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 74

Extension (NM) 

The extension to the phone.
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 75

5. Segments and Message Details

This chapter will contain specifications for each segment used. It will indicate which fields are supported or required and describe 

any constraints on these fields. Chapter 6 will then address how these building blocks are assembled into specific messages that 

meet the use cases listed in Chapter 2. 

Table 5-1 Message Segments 

Segment

(Name/Role)

Definition Message Usage Usage Note

BHS

(Batch Header 

Segment)

The Batch Header Segment 

wraps a group of 1 or more

messages. These may be a 

mixture of acceptable message 

types. This segment is not 

required for real-time 

messaging. That is, a stream of 

messages may be sent without a 

BHS. A system may choose to 

require BHS for all groups of 

messages, but should specify 

this requirement in a local 

implementation Guide.

Any Optional Used at the beginning of any batch of 

messages.

BTS

(Batch Trailer 

Segment)

The BTS segment defines the 

end of a batch. It is required if 

the message has a matching 

BHS.

Any Required if 

message 

starts with 

BHS.

Used to mark the end of any batch of 

messages. If the batch of messages 

starts with a BHS, then this segment is 

required.

ERR

(Error Segment)

The error segment reports 

information about errors in 

ACK, RSP Ability to 

create and 

Used to return information about 

errors.
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 76

Segment

(Name/Role)

Definition Message Usage Usage Note

processing the message. The 

segment may repeat. Each error 

will have its’ own ERR segment.

process is 

required for 

conformant 

systems.

EVN

(Event Segment)

The EVN segment is used to 

communicate necessary trigger 

event information to receiving 

applications. Valid event types 

for all chapters are contained in 

HL7 Table 0003 - Event Type

ADT Required for 

ADT 

message.

Used to convey event trigger 

information.

FHS

(File Header

Segment)

The file header segment may be 

used to group one or more 

batches of messages. This is a 

purely optional segment, even if 

batches are sent. Its’ use is not 

anticipated for use in real-time 

transactions. Any system that 

anticipates its use should 

specify this in a local 

implementation Guide.

Any Optional Used to mark the beginning of a file of 

batches.

FTS

(File Trailer 

Segment)

The FTS segment defines the 

end of a file of batches. It is only 

used when the FHS segment is 

used.

Any Required to 

terminate a 

file of 

batches. 

(Matches 

FHS)

Used to mark the end of a file of 

batches. If a file of batches has an FHS 

at the beginning, then this segment is 

required.

IN1-3 The IN1-IN3 segments contain VXU Optional This segment is specified for local use, 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 77

Segment

(Name/Role)

Definition Message Usage Usage Note

(Insurance 

Segment)

insurance policy coverage 

information necessary to 

produce properly pro-rated and 

patient and insurance bills.

based on state requirements.

MSA

(Message 

Acknowledgement 

Segment)

This segment is included in the 

query response (RSP) and

acknowledgment

(ACK) messages. It contains 

information used to identify the

receiver’s acknowledgement 

response to an identified prior 

message. 

RSP, ACK Ability to 

create and 

process is 

required for 

conformant 

systems.

MSH

(Message 

Segment 

Header)

The MSH segment defines the 

intent, source, destination, and 

some specifics of the syntax of a 

message.

All Ability to 

create and 

process is 

required for 

conformant 

systems.

This begins every message and 

includes information about the type of 

message, how to process it and who it 

was created by.

NK1

(Next of Kin 

Segment)

The NK1 segment contains 

information about the patient’s 

next of kin or other related 

parties. Any associated parties 

may be identified.

VXU, ADT, RSP Ability to 

create and 

process is 

required for 

conformant 

systems.

Used to carry information about the 

next of kin for a client.

NTE

(Note Segment)

The NTE segment is used for 

sending notes and comments. It 

is used in relation to OBX in the 

VXU, ADT, RSP Ability to 

create and

process is 

Used to carry a note related to the 

parent segment.
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 78

Segment

(Name/Role)

Definition Message Usage Usage Note

VXU and RSP. required for 

conformant 

systems.

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 and an answer.

ADT, VXU, RSP Ability to 

create and 

process is 

required for 

conformant 

systems.

Used to report one atomic part of an 

observation.

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. 

VXU, RSP Ability to 

create and 

process is 

required for 

conformant 

systems.

Used to give information about a 

group of one or more orders (typically 

RXA).

PD1

(Patient 

Demographic 

Segment)

The patient additional 

demographic segment contains 

demographic information that is 

likely to change about the 

patient. In immunization 

VXU, RSP, ADT Ability to 

create and 

process is 

required for 

conformant 

Used to give information about a 

patient. A primary use in immunization 

messages is to give information about 

privacy and whether contact is 

allowed.
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 79

Segment

(Name/Role)

Definition Message Usage Usage Note

messages, this is information 

about the need to protect the 

client’s information, how they 

should be part of reminder 

efforts and their current status 

in the IIS.

systems.

PID

(Patient 

Identifier 

Segment)

This segment contains 

permanent patient identifying 

and demographic information 

that, for the most part, is not 

likely to change. Used by all 

applications as the primary 

means of communicating 

patient identification 

information. frequently.

VXU, ADT, RSP Ability to 

create and 

process is 

required for 

conformant 

systems.

Used to carry information about the 

patient/client.

PV1

(Patient Visit 

Segment)

This segment contains 

information related to a specific 

visit.

VXU, ADT, RSP Optional Previously used to carry funding 

program eligibility status. Use OBX for 

this purpose now.

QAK

(Query 

acknowledgeme

nt segment)

The QAK segment contains 

information sent with responses 

to a query.

RSP Ability to 

create and 

process is 

required for 

conformant 

systems.

QPD Query parameter definition QBP, RSP Ability to 

create and 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 80

Segment

(Name/Role)

Definition Message Usage Usage Note

process is 

required for 

conformant 

systems.

RCP Response control parameter 

segment

QBP Ability to 

create and 

process is 

required for 

conformant 

systems.

RXA Pharmacy/Treatment 

Administration Segment

VXU, RSP Ability to 

create and 

process is 

required for 

conformant 

systems.

RXR Pharmacy/Treatment Route 

Segment

VXU, RSP Ability to 

create and 

process is 

required for 

conformant 

systems.
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 81

BHS—Batch Header Segment 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 82

Table 5-2 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/Ty

pe

ST O

10 Batch 

Comment

ST O
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 83

SEQ ELEMENT 

NAME

Data 

Type

Usage Cardinality LEN Conditional Predicate Value set Description/Comment

11 Batch 

Control ID

ST O

12 Reference 

Batch 

Control ID

ST O

Conformance Statement 

IZ-8: BHS.1 (Batch Field Separator) field SHALL be | 

IZ-9: BHS.2 (Batch Encoding Characters) field 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). 

BTS—Batch Trailer Segment 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 84

Table 5-3 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|| 

ERR—Error Segment 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 85

Table 5-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]18 18

3 HL7 Error 

Code

CWE R [1..1] HL70357

4 Severity ID R [1..1] 1..1 HL70516

5 Application 

Error Code

CWE O

6 Application 

Error 

Parameter

ST O

7 Diagnostic 

Information

TX O

8 User 

Message

TX O

9 Inform 

Person 

Indicator

IS O

10 Override 

Type

CWE O

 

18 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. 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 86

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".

Example with error in PID: 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 87

ERR||PID^1^5|101^Required field missing^HL70357^^^|E| 

EVN - Event Type Segment 

.

Table 5-5 Event Segment (EVN) 

SEQ ELEMENT 

NAME

Data 

Type

Usage Cardinality LEN Conditional Predicate Value set Description/Comment

1 Event Type 

Code

ID O

2 Recorded 

Date/Time 

TS R [1..1]

3 Date/Time 

Planned 

Event

TS O

4 Event 

Reason 

Code

IS O

5 Operator ID XCN O

6 Event 

Occurred

TS O

7 Event 

Facility

HD O

EVN field definitions 

EVN-2 Recorded Date/Time (TS) 00100 

Definition: Most systems will default to the system date/time when the transaction was entered, but they should also permit an override.
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 88

FHS—File Header Segment 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 89

Table 5-6 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
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 90

Conformance Statement: 

IZ-10: The FSH.1 (File Field Separator) field SHALL be | 

IZ-11: The FSH.2 (File Encoding Characters) field 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 5-7 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

IN1—Insurance Segment (IN2, IN3) 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 91

These segments are not anticipated for use in immunization messaging. They are not described or specified further in this Guide. Local 

implementations may document use for local purposes in local implementation Guide.

MSA—Message Acknowledgement Segment 

Table 5-8 Message Acknowledgement Segment (MSA) 

SEQ ELEMENT 

NAME

Data 

Type

Usage Cardinality LEN Conditional Predicate Value 

Set

Description/Comment

1 Acknowledgme

nt 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 

Acknowledgme

nt 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.
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 92

MSH—Message Header Segment 
Chapter 5: Segments and Message Details

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 93

HL7 ATTRIBUTE TABLE - MSH - MESSAGE HEADER

Table 5-9 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 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 RE [0..1] HL70155
Chapter 5: Segments and Message Details

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 94

SEQ ELEMENT NAME Data 

Type

Usage Cardinality LEN Conditional 

Predicate

Value set Description/Comment

16 Application 

Acknowledgment 

Type

ID RE [0..1] HL70155

(constrained)

17 Country Code ID O 

18 Character Set ID O 

19 Principal 

Language Of 

Message

CE O 

20 Alternate 

Character Set 

Handling Scheme

ID O 

21 Message Profile 

Identifier

EI C(R/O) [0..*] If MSH-9.1 is 

valued “QBP” or 

“RSP”

This field will be required for 

use whenever a Profile is 

being used.

Base Conformance Statements: 

IZ-12: The MSH.1 (Field Separator) field SHALL be valued “|” 

IZ-13: The MSH.2 (Encoding Characters) field SHALL be valued “^~\& “ 

IZ-14: MSH-7 (Date/time of Message) SHALL have a degree of precision that must be at least to the minute. (Format

YYYYMMDDHHMM).

IZ-15: The MSH-12 (Version ID) SHALL be valued “2.5.1 “ 

IZ-16: The value of MSH-16 (Application Acknowledgement Type) SHALL be one of the following:

AL-always, NE-Never, ER-Error/reject only, SU successful completion only
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 95

VXU Conformance Statement: 

IZ-17: MSH-9 (Message Type) SHALL contain the constant value “VXU^VO4^VXU_V04”

QBP Conformance Statement: 

IZ-18: MSH-9 (Message Type) SHALL be contain the constant value “QBP^Q11^QBP_Q11”

RSP Conformance Statement: 

IZ-19: MSH-9 (Message Type) SHALL be contain the constant value “RSP^K11^RSP_K11”

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. In the case of an IIS, it will be found in the list of IIS applications in 

Appendix A, 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. Additional locally 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 96

defined codes may be added to accommodate local needs. The first component shall be the name space id found in User-defined 

Table 0361, including local additions to this table. The second and third components are reserved for use of OIDs. 

MSH-4 Sending Facility (HD) 00004

Definition: This field identifies the organization responsible for the operations of the sending application. Locally defined codes may 

be added to 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. 

MSH-5 Receiving Application (HD) 00005

Definition: This field uniquely identifies the receiving application. In the case of an IIS, it will be found in the list of IIS applications in 

Appendix A, 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. Additional locally 

defined codes may be added to accommodate local needs. The first component shall be the name space id found in User-defined 

Table 0300. The second and third components are reserved for use of OIDs. 

MSH-6 Receiving Facility (HD) 00006

Definition: This field identifies the organization responsible for the operations of the receiving application. Locally defined codes may 

be added to 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. 

MSH-7 Date/Time Of Message (TS) 00007

Definition: This field contains the date/time that the sending system created the message. The degree of precision must be at least 

to the minute. The time zone must be specified and will be used throughout the message as the default time zone. 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 97

MSH-9 Message Type (MSG) 00009 

Definition: This field contains the message type, trigger event, and the message structure ID for the message. 

Message structure component is required. 

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. The receiver returns exactly what was 

sent in response messages. 

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. 

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. Required for enhanced acknowledgment mode. Refer to HL7 Table 0155 - Accept/application acknowledgment conditions

for valid values. 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 98

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. 

Required for enhanced acknowledgment mode. 

Note: If MSH-15-accept acknowledgment type and MSH-16-application acknowledgment type are omitted (or are both empty), the 

original acknowledgment mode rules are used. This means that, unless otherwise specified, the receiving application will send 

acknowledgment when it has processed the 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,.19. 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.

 

19 Available from ISO 1 Rue de Varembe, Case Postale 56, CH 1211, Geneve, Switzerland 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 99

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. 

This field will be required whenever a profile is being used to constrain 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. 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 100

Table 5-10-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
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 101

13 Organization 

Name - NK1

XON O

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
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 102

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/Associate

d 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 

NK1-1 Set ID - NK1 (SI) 00190 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 103

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.

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.

NK1-15 Administrative Sex (IS) 00111 

Definition: This is the sex of the next of kin.
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 104

NK1-16 Date/Time of Birth (TS) 00110 

Definition: This is the data of birth of the next of kin.

NTE—Note Segment 

The NTE segment is used for sending notes and comments. It is used in relation to OBX in the VXU and RSP. It is also used in ADT in 

relation to various segments.

Table 5-11 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). 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 105

Table 5-12 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

5 Observation 

Value

varies

20

R [1..1] varies This is the observation 

value and answers the 

question posed by OBX-3

6 Units CE C(R/RE) [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 

CWE.1 and “HL70353” 

in CWE.3.

 

20 The length of the observation field is variable, depending upon value type. See OBX-2 value type. 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 106

SEQ ELEMENT 

NAME

Data 

Type

Usage Cardinality LEN Conditional Predicate Value Sets Comment

7 References 

Range

ST O

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 RE [0..1]

15 Producer's 

Reference

CE O

16 Responsible 

Observer

XCN O
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 107

SEQ ELEMENT 

NAME

Data 

Type

Usage Cardinality LEN Conditional Predicate Value Sets Comment

17 Observation 

Method

CE C(R/O) [0..1] If OBX-3.1 is “64994-7” CDCPHINVS Note that value set is 

pending. It will be a 

PHINVADS owned value 

set.

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

20 Reserved 

for 

harmonizati

on with V2.6

O

21 Reserved 

for 

harmonizati

on with V2.6

O

22 Reserved 

for 

harmonizati

on with V2.6

O
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 108

SEQ ELEMENT 

NAME

Data 

Type

Usage Cardinality LEN Conditional Predicate Value Sets Comment

23 Performing 

Organizatio

n Name

XON O

24 Performing 

Organizatio

n Address

XAD O

25 Performing 

Organizatio

n 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 given segment group.

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”

Note: If there are multiple OBX segments that have the same OBX-3.1 or OBX-3.4 values, then this field shall be populated. 

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. 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 109

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|. 

In most systems 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 

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.
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 110

This field may be used to link related components of an observation. Each component of the observation would share an Observation subid.

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|38890-0^COMPONENT VACCINE TYPE^LN|1|45^HEP B, NOS^CVX||||||F|<CR> 

OBX|2|TS|29768-9^DATE VACCINE INFORMATION STATEMENT PUBLISHED^LN|1|20010711||||||F|<CR> 

OBX|3|TS|29769-7^DATE VACCINE INFORMATION STATEMENT 

PRESENTED^LN|1|19901207||||||F|<CR> 

OBX|4|CE|38890-0^COMPONENT VACCINE TYPE^LN|2|17^HIB,NOS^CVX||||||F|<CR> 

OBX|5|TS|29768-9^DATE VACCINE INFORMATION STATEMENT 

PUBLISHED^LN|2|19981216||||||F|<CR> 

OBX|6|TS|29769-7^DATE VACCINE INFORMATION STATEMENT 

PRESENTED^LN|2|19901207||||||F|<CR> 

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. 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 111

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.

Coded values 

When an OBX segment contains values of CE data types, the observations are stored as a combination of codes and/or text. 

OBX-6 Units (CE) 00574 

Definition: This shall be the units for the value in OBX-5. The value shall be from the ISO+ 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) 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 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) 
Chapter 5: Segments and Message Details

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 112

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.

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 given 

immunization. It is 

determined based on 

characteristics of the 

patient/client and the type 

of vaccine administered.

64994-7 HL70064

IZ-23: If RXA-9.1 (Administration 

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 cdcgi1vis

See VIS related Conformance Statements 

below

Vaccine Information 

Statement (VIS) version 

date

This value represents the 

date the presented VIS was 

published

29768-9

See VIS related Conformance Statements 

below

VIS vaccine type This value represents the 

vaccine type that the 

statement provides 

information about

30956-7 CVX

Vaccine Information 

Statement (VIS) delivery 

This value represents the 

date the document was 29769-7 See VIS related Conformance Statements below
Chapter 5: Segments and Message Details

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 113

Core Data Element Description Observation 

Identifier 

(OBX-3)

Observation 

Value Set

(OBX-5)

Conformance Statements

date presented to the 

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. 

Recently, VIS has started to be bar coded with a 3-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. 

VIS documentation is required for all patients, but only for specific vaccines. The current list includes the following types of vaccine: 

• diphtheria, 

• tetanus, 

• pertussis, 

• measles, 

• mumps, 

• rubella, 

• polio, 

• hepatitis A, 

• hepatitis B, 

• Haemophilus influenzae type b (Hib), 

• influenza, 
Chapter 5: Segments and Message Details

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 114

• pneumococcal conjugate, 

• meningococcal, 

• rotavirus, 

• human papillomavirus (HPV), 

• varicella (chickenpox) vaccine 

Note that the most current list will be found on PHIN VADS. See table PHVS_VISBarcodes_IIS in Appendix A below. 

See table Value Set Code: PHVS_VISBarcodes_IIS in Appendix A. 

VIS Conformance Statements:

IZ-24: If 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 there SHALL 

be:

• an OBX segment with OBX-3.1 valued “64764-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

• an OBX segment with OBX-3.1 valued “30956-7” (vaccine type) and an 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. Both OBX shall have the same value in OBX-4 

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. 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 115

Table 5-13 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/Tim

ing

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 RE [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.
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 116

SEQ ELEMENT 

NAME

Data 

Type

Usage Cardinality LEN Conditional Predicate Value Set Comment

13 Enterer's 

Location

PL O

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 O 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 

XTN O
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 117

SEQ ELEMENT 

NAME

Data 

Type

Usage Cardinality LEN Conditional Predicate Value Set Comment

Phone 

Number

24 Ordering 

Provider 

Address

XAD O

25 Order Status 

Modifier

CWE O

26 Advanced 

Beneficiary 

Notice 

Override 

Reason

CWE O

27 Filler's 

Expected 

Availability 

Date/Time

TS O

28 Confidentiali

ty Code

CWE O

29 Order Type CWE O

30 Enterer 

Authorizatio

n Mode

CNE O

31 Parent 

Universal 

Service 

Identifier

CWE O

Conformance Statement: 

IZ-25: ORC.1 (Order Control) SHALL contain the value “RE “
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 118

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 either ORC-2 or ORC-3 must be populated. They may both be populated. 

In the immunization context, it is not common to have one system placing and one filling an immunization order. In some cases 

neither is known. The use case that these have supported is to allow a system that sent an immunization record to another system 

to identify an immunization that needs to be changed using the Filler Order Number it had sent. 

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. 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 119

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.

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-21 Ordering Facility Name (XON) 01311 

Definition: This field contains the name of the facility placing the order. It is the organization sub-unit that ordered the immunization. (i.e. 

the clinic)

ORC-22 Ordering Facility Address (XAD) 01312 

Definition: This field contains the address of the facility requesting the order.
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 120

ORC-23 Ordering Facility Phone Number (XTN) 01312 

Definition: This field contains the phone number of the facility requesting the order.

ORC-24 Ordering Provider Address (XAD) 01314 

Definition: This field contains the address of the care provider requesting the order.

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 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.
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 121

Table 5-14-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 O

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 

DT C(RE/X) [0..1] If PD1-12 (Protection 

Indicator) is valued
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 122

SEQ ELEMENT 

NAME

Data 

Type

Usage Cardinality LEN Conditional Predicate Value 

Set

Comment

Effective Date

14 Place of 

Worship

XON O

15 Advance 

Directive 

Code

CE O

16 Immunization 

Registry 

Status

IS RE [0..1]

HL70441

17 Immunization 

Registry 

Status 

Effective Date

DT C(RE/X) [0..1] If the PD1-16 (Registry 

Status) field is valued.

18 Publicity 

Code 

Effective Date

DT 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. Use may 

be specified locally.
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 123

PD1-4 Patient Primary Care Provider Name & ID No. (XCN) 00757

Definition: Identifier for primary care provider. Use may be specified locally.

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. 

PD1-12 Protection Indicator (ID) 00744

Definition: This field identifies whether a person’s information may be shared with others21. 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

 

21 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. 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 124

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.

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.
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 125

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. 

 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 126

Table 5-15-Patient Identifier Segment (PID) 

SEQ Element 

Name

Data 

Type

Usage Cardinality LEN Conditional Predicate Value 

Set

Constraint

1 Set ID - PID SI RE [0..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 RE [0..1]

7 Date/Time 

of Birth

TS R [1..1]

8 Administrati

ve 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.
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 127

SEQ Element 

Name

Data 

Type

Usage Cardinality LEN Conditional Predicate Value 

Set

Constraint

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
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 128

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 

ID O
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 129

SEQ Element 

Name

Data 

Type

Usage Cardinality LEN Conditional Predicate Value 

Set

Constraint

Indicator

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

CW

E

O

Conformance Statement: 

IZ-26: PID-7 (birth date) SHALL be accurate at least to the day. (YYYYMMDD) 

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.
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 130

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.). 

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) 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.
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 131

A person’s address may be sent in this field or in the NK1 segment with a relationship code indicating Self. Local implementations should 

clarify how these addresses will be handled.

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 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 User-defined Table 0189 - Ethnic Group. The second triplet of the CE 

data type for ethnic group (alternate identifier, alternate text, and name of alternate coding system) is reserved for governmentally 

assigned codes. 

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.
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 132

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

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 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 133

Table 5-16-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.
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 134

QPD – Query Parameter Definition 

The QPD segment defines the parameters of the query.

Table 5-17-Query Parameter Definition (QPD) 

SEQ ELEMENT 

NAME

Data 

Type

Usage Cardinality LEN Conditional Predicate Value Set Comment

1 Message 

Query Name 

CE R [1..1] HL70471

2 Query Tag ST R 32 Generated by the initiating 

system.

3-n User 

Parameters 

(in 

successive 

fields) 

varies R The specification of this 

sequence is found in the 

profile specific to the use 

case.

QPD field definitions 

QPD-1 Message Query Name (CE) 01375 

Definition: This field contains the name of the query. These names are assigned by the function-specific chapters of this specification. It is 

one to one with the conformance statement for this query name, and it is in fact an identifier for that conformance statement. 

QPD-2 Query Tag (ST) 00696 

Definition: This field must be valued by the initiating system to identify the query, and may 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). 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 135

This field differs from MSA-2-Message control ID in that its value remains constant for each message (i.e. all continuation messages) 

associated with the query, whereas MSA-2-Message control ID may vary with each continuation message, since it is associated with each 

individual message, not the query as a whole.

QPD-3 User Parameters (Varies) 01435 

Definition: These successive parameter fields hold the values that the Client passes to the Server. 

The client data is presented as a sequence of HL7 fields. Beginning at QPD-3-User parameters, the remaining fields of the QPD segment 

carry user parameter data. Each QPD user parameter field corresponds to one parameter defined in the Conformance Statement, where 

each name, type, optionality, and repetition of each parameter has been specified. While these parameters are understood to be usually 

“and-ed” together, the user must inspect the required Conformance Statement to properly understand each. Except in the QSC variant, 

the parameter names do not need to be stated in the query; they are understood to be positional based on the Conformance Statement.

Each parameter field may be specified in the Conformance Statement to be of any single data type, including the complex QIP and QSC 

types. Parameter fields in the QPD segment appear in the same order as in the Conformance Statement.

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.
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 136

Table 5-18-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. 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 137

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.

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.

RCP-3 Response Modality (CE) 01440 

Definition: This field specifies the timing and grouping of the response message(s). Refer to HL7 Table 0394 – Response modality for valid 

values.

RCP-7 Segment Group Inclusion (ID) 01594 

Definition: Specifies those optional segment groups which are to be included in the response. Refer to HL7 Table 0391—Segment group

for values for Segment Group. This is a repeating field, to accommodate inclusion of multiple segment groups. The default for this field, 

not present, means that all relevant groups are included. 

Note: Although the codes for segment groups are taken from HL7 Table 0391, the exact segment-level definition of a segment group (e.g. PIDG) is 

given only in the conformance statement of the query in which this segment group appears. 

RXA-- Pharmacy/Treatment Administration Segment 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 138

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.22

 

There is a change requiring an ORC conflicts with the Version 2.3.1 implementation Guide. In that, ORC is optional and in fact rarely 

included in a VXU. 

 

22 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. 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 139

Table 5-19 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 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 RE [0..1]

5 Administered 

Code

CE R [1..1] CVX CVX code is required for 

Meaningful Use. Other 

codes may also be used 

but will not be part of 

conformance testing.

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

8 Administered 

Dosage Form

CE O [0..1]
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 140

SEQ ELEMENT 

NAME

Data 

Type

Usage Cardinality LEN Conditional Predicate Value Set Comment

9 Administration 

Notes

varies C(R/O) [1..*] If RXA-20 is valued “CP” or 

“PA”

NIP 0001 If this field is used for a 

notes 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 RE [0..1] This is the person who 

gave the administration or 

the vaccinator. It is not the 

ordering clinician.

11 Administeredat LocationLA2 RE [0..1] This is the clinic/site where 

the vaccine was 

administered.

12 Administered 

Per (Time 

Unit)

ST O

13 Administered 

Strength

NM O
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 141

SEQ ELEMENT 

NAME

Data 

Type

Usage Cardinality LEN Conditional Predicate Value Set Comment

14 Administered 

Strength Units

CE O

15 Substance 

Lot Number

ST C(R/O) [0..*] If the value in RXA-9.1

(Administration Notes) is 

valued “00”

Note that “00” is double 

zero.

16 Substance 

Expiration 

Date

TS C(RE/O

)

[0..1] If the RXA-15 (lot number)

is valued

17 Substance 

Manufacturer 

Name

CE C(R/O) [0..*] If the value in RXA-9.1

(Administration Notes) is 

valued “00”, 

MVX

18 Substance/Tr

eatment 

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 RE [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
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 142

SEQ ELEMENT 

NAME

Data 

Type

Usage Cardinality LEN Conditional Predicate Value Set Comment

25 Administered 

Barcode 

Identifier

CWE O

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 

repetition of this field. 

IZ-32: If the RXA-18 (Refusal Reason) is populated, this field SHALL be valued to “RE”.

NOTE: If RXA-6 (administered amount) is not known or meaningful, use “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).

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. 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 143

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) 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. In the case of a refusal, it is the 

date the refusal was noted.

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. If empty, the date/time 

of RXA-3-Date/Time Start of Administration is assumed.

RXA-5 Administered Code (CE) 00347

Definition: This field identifies the medical substance administered. If the substance administered is a vaccine, CVX codes 

should be used in the first triplet to code this field (CVX Table - Codes for vaccines administered). The second set of

three components could be used to represent the same vaccine using a different coding system, such as Current 

Procedural Terminology (CPT). CVX code is the strongly preferred code system.

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. Registries 

that do not collect the administered amount 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.

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 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 144

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:identifier23

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)

 

23 This value should uniquely identify a specific facility. Systems may choose to publish a table with local values. 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 145

Note that if subcomponent 1 is populated, 2 and 3 should be empty. If subcomponent 2 is populated with an OID, subcomponent 3 must 

be populated with ISO.

Component 9-15: Facility address.

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) 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.
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 146

RXA-20 Completion Status (ID) 01223 

This field indicates if the dose was successfully given. It must be populated with RE if RXA-18 is populated with NA. If a dose was not 

completely administered or if the dose were not potent this field may be used to label the immunization. If this RXA has a CVX of 998 (no 

vaccine administered) then this shall be populated with NA.

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. This field has a 

usage of RE. If it is left empty, then receiving systems should assume that the action code is A.

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.

The action code U ( Update system) 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.

RXA-22 System Entry Date/Time (TS) 01225 

This field records the date/time that this record was created in the originating system. Local implementations should specify its’ use.

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. 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 147

Table 5-20 Pharmacy/Treatment Route (RXR) 

SEQ ELEMENT 

NAME

Data 

Type

Usage Cardinality LEN Conditional Predicate Value Set Constraint

1 Route CE R [1..1] HL70162

2 Administratio

n Site

CWE RE [0..1] HL70163

3 Administratio

n Device

CE O

4 Administratio

n Method

CWE O

5 Routing 

Instruction

CE O

6 Administratio

n Site 

Modifier

CWE O

RXR field definitions 

RXR-1 Route (CE) 00309

Definition: This field is the route of administration.

Refer to User-Defined Table 0162 - Route Of Administration for valid values.

This will change, based on HITSP. They specify use of FDA list. Systems should be prepared to accept either FDA or 

HL7 codes. 

RXR-2 Administration Site (CWE) 00310

Definition: This field contains the site of the administration route. 
Chapter 6: Messages for Transmitting Immunization Information 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 148

6. Messages for Transmitting Immunization Information

Introduction 

This chapter describes each of the messages used to accomplish the use cases described 

in previous chapters. These messages are built from the segments described in Chapter 

5, Segments and Message Details. The Segments are built using the Data Types specified 

in Chapter 4. Readers are referred to these chapters for specifics on these components. 

Issues related to segments and fields, which are message specific will be addressed in 

this chapter. 

 

Table 6-1-Supported Messages 

Message Purpose Related Messages Associated Profiles

VXU Send Immunization 

History

ACK

QBP Request 

Immunization 

History and Request 

Person Id

RSP Z34^CDC

RSP Respond to Request

for Immunization 

Record and 

Respond to Request 

for Person Id

QBP Z31^CDC

Z32^CDC

ACK Send Message 

Acknowledgement

VXU, ADT, QBP

ADT Send Person 

Demographic Data

ACK

Send Immunization History--VXU 

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 activity diagrams and 

example messages that illustrate the processing of this message. 

Table 6-2--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.
Chapter 6: Messages for Transmitting Immunization Information 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 149

Segment Cardinality Usage Comment

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.

PV1 [0..1] O Not described in this Guide. May be locally 

specified.

PV2 [0..1] O Not described in this Guide. May be locally 

specified.

GT1 [0..*] O Not described in this Guide. May be locally 

specified.

Begin 

Insurance 

group

[0..*] O The insurance group may repeat.

IN1 [0..1] O Not described in this Guide. May be locally 

specified.

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..*] 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.

OBX [0..*] RE Every RXA segment in a VXU may have zero or 

more OBX segments.

NTE [0..1] RE Every OBX segment in a VXU may have zero or 

one NTE segment.

End Order Group

The following diagram illustrates the relationships of the segments. The cardinality is 

displayed on the association links. Note that in order for a segment to be present in a 

message, it must be associated with any parent segments. For example, the NTE 
Chapter 6: Messages for Transmitting Immunization Information 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 150

segment can only be included in a message as a sub-segment to an OBX. Further, the 

OBX can only be present as a child of an RXA. Finally, a segment that is required and a 

child of another segment must be present if the parent is present. If the parent is not 

present, it is NOT permitted. 

Requesting Information (Immunization History) – QBP 

This description will specify the use of QBP for messaging, but is not specific to the use 

cases in this Guide. Formal Query and Response Profiles for specifying the structure to 

support the use cases will follow in Chapter 7. The QBP query has a matching RSP 

response. (See below) 

QBP/RSP – query by parameter/segment pattern response (events vary )

Table 6-3 QBP/RSP – Query By Parameter/Segment Pattern Response 

Segment Cardinality Usage Comment

MSH [1..1] R The MSH must include an 

identifier which indicates 

the Query Profile used.

[{SFT}] [0..1] O Not anticipated for use in 

immunization messages.

QPD [1..1] R

[ --- QBP begin

[...] [1..*] R The Query Profile will 

specify the list of fields 

and their components in 

the order that they will be 

expected for this query.

] --- QBP end

RCP Response Control Parameters R The Query Profile will list 

the segments that are 

expected to be returned in 

response to this query.

[ DSC ] Continuation Pointer O Not anticipated for use in 

immunization messages.

Respond to Request for Information– RSP 

The specifications below are not specific to the request for immunization history, but 

are the foundation on which those specifications are based. The Query profile for 

requesting an immunization history and the associated Response may be found in 

Chapter 7 of this Guide. 

Formal Profiles based on the Query Profile in Chapter 7 will allow the requesting system 

to be informed if the response is a list of candidate clients or a single immunization 

history. 
Chapter 6: Messages for Transmitting Immunization Information 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 151

Table 6-4-Segment Pattern Response (RSP) 

Segment Cardinality Usage Comment

MSH [1..1] R The MSH will indicate 

which query is being 

responded to and 

what Query Profile it 

was based on.

[{SFT}] [0..1] O Not anticipated for 

use in immunization 

messages.

MSA [1..1] R

[ ERR ] [0..1] O

QAK [1..1] R

QPD [1..1] R This segment echoes 

the Query Parameter 

Definition Segment

sent in the requesting 

query.

[ --- SEGMENT_PATTERN begin

... [0..1] O The specified 

segments and their 

contents as specified 

in the Segment 

Pattern from Query 

Profile, are returned 

here. May be empty if 

no records returned.

] --- SEGMENT_PATTERN end

[ DSC ] Continuation Pointer O Not anticipated for 

use in immunization 

messages.

Requesting An Immunization History from Another System VXQ 

The use of VXQ is not supported for 2.5.1 immunization messaging. 

Version 2.5.1 implementations are expected to support QBP style query. 

Acknowledging a Message--ACK 

The ACK returns an acknowledgement to the sending system. This may indicate errors in 

processing. 

Table 6-5 Message Acknowledgement Segment (ACK) 

Segment Cardinality Usage Comment

MSH (1..1) R
Chapter 6: Messages for Transmitting Immunization Information 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 152

Segment Cardinality Usage Comment

[{SFT}] (0..1) O Not anticipated for use in immunization 

messages.

MSA (1..1) R

[{ERR}] (0..*) RE Include if there are errors.

Note: For the general acknowledgment (ACK) message, the value of MSH-9-2-Trigger event is 

equal to the value of MSH-9-2-Trigger event in the message being acknowledged. The value of 

MSH-9-3-Message structure for the general acknowledgment message is always ACK.

Sending Demographic Information – VXU or ADT 

Use of the ADT message is required for participation in the PIX/PDQ profile for 

maintenance of the Master Person Index. In addition, it may be used to populate an IIS 

with data from systems that do not contain immunization data or that can’t produce 

immunization messages. 

In most cases, at present, use of the ADT message is not anticipated for widespread use 

outside of this context. Since this Implementation Guide focuses on messaging 

immunization information, those interested in use of the ADT are referred to Chapter 3 

of the Version 2.5.1 documentation. In addition, the IHE profiles include clear guidelines 

on using an ADT. The VXU message may be used to convey demographic information 

without inclusion of immunization information, since ORC are optional segments. 

ADT messages shall not be used for transmitting immunization records. They may be 

used for transmitting demographic information. 

This Guide will give specifications for the Register Patient (A04) message. The only 

differences between A04 and A28 are the Message Type (MSH-9) and the addition of a 

PDA (Patient Death and Autopsy) segment for the A04 variant of the ADT. The Guide will 

not provide specifications for the full suite of patient management activities. Systems 

that will support these more extensive activities should adopt an existing profile or 

develop an implementation guide or profile specifying their local use. 

Integrating the Healthcare Enterprise (IHE) has published a profile that provides support 

for the transactions that support interaction with a Master Person Index (MPI). Those 

planning extensive use of ADT are urged to consult these documents. 

http://www.ihe.net/profiles/index.cfm 

http://www.ihe.net/Technical_Framework/index.cfm 24

 

24 These links are current as of 5/1/2010. 
Chapter 6: Messages for Transmitting Immunization Information 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 153

Table 6-6-ADT A04 Message 

Segment Cardinality Usage Comment

MSH [1..1] R Every message begins with an MSH.

[{SFT }] [0..*] O

EVN [1..1] R Every ADT has one EVN segment.

PID [1..1] R Every ADT has one PID segment.

[ PD1 ] [0..1] RE Every PID segment in ADT may have zero or one 

PD1 segment

[{ROL}] [0..*] O

[{ NK1 }] [0..*] O The PID segment in a ADT may have zero or more 

NK1 segments.

PV1 [1..1] R The PID segment in an ADT must have one PV1 

segment. 

[ PV2 ] [0..1] O

[{ ROL }] [0..*] O

[{ DB1 }] [0..*] O

[{ OBX }] [0..*] O The PID segment in an ADT may have zero or more 

OBX segments.

[{ AL1 }] [0..*] O

[{ DG1 }] [0..*] O

[ DRG ] [0..*] O

[{

PR1 [0..1] O

[{ ROL }] [0..*] O

}]

[{ GT1 }] [0..*] O

[{

IN1 [0..1] O

IN2 [0..1] O

IN3 [0..1] O

[{ ROL }] [0..*] O

}]

[ ACC ] [0..1] O

[ UB1] [0..1] O

[UB2 ] [0..1] O

[ PDA ] [0..1] O

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 
Chapter 6: Messages for Transmitting Immunization Information 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 154

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 

...

BTS 

...

FTS 
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 155

7. Query and Response Profile (QBP/RSP)

Request Immunization History Query Profile –Z34^CDCPHINVS 

The following query profile supports replication of the functionality of the VXQ/VXX/VXR query and responses25. Implicit in this 

profile is identity resolution as it was in VXQ. 

Some systems may wish to separate this functionality using the Patient Demographic Query (PDQ) profile from IHE. The results of 

the identity resolution accomplished with the PDQ can be used with this query profile to request an immunization history. It is 

anticipated that one high confidence match will be the results of this effort and the return response will be one immunization 

history. IHE also has a query profile to support interaction with an MPI. The PIX query requests patient identifier cross-reference. It 

assumes that the pertinent identifiers have been registered using ADT messages. 

Integrating the Healthcare Enterprise (IHE) has published a profile that provides support for the PDQ query. In addition, they have 

published a supplemental Pediatric Demographic Profile that optimizes the PDQ query to support queries for children’s identifiers. 

http://www.ihe.net/profiles/index.cfm 

http://www.ihe.net/Technical_Framework/index.cfm 26

See Appendix B for more details on the processes. 

Three profiles will be supported by CDC. One profile will reflect the query as specified below. In addition two profiles will specify 

constraints on the responses returned in a response to the query. One will specify a single immunization history returned. The 

second will specify a list of candidate clients and their identifiers. 

 

25 This functionality entails a query that uses demographic and other identifying information to request an immunization history. If one or more 

lower confidence candidates are found a list of candidates is returned. If a single high-confidence match is found, an immunization history is 

returned. 

26 These links are current as of 5/1/2010. 
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 156

Request Immunization History Query Profile

Table 7-1 Request 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 

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 

response will indicate too many 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.

Based on Segment Pattern: NA
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 157

Note that when one patient is found, a Receiving system may choose to send an immunization history or a list of one patient 

identifiers depending on the local business rules. This should be clearly documented in a local profile. 

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.

Query Grammar 

Response Grammar 

Table 7-2-Response Grammar to Different Outcomes 

Outcome of Query Response Message

No match found Response indicates that message was successfully processed and that no 

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
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 158

clients matched the criteria that were sent in the query.

Exactly one high confidence match found27 Response includes a complete immunization history as specified below. 

See Profile Return Immunization History.

At least one lower confidence match28 is 

found, but <= maximum number allowed.

Response returns one PID with associated PD1 and NK1 segments for each 

potential match. No immunization history is returned.

See Profile Return Candidate List.

More than the maximum number allowed is 

found.

Response indicates that the message was successfully processed, but that 

too many potential matches were found. 

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.

The response grammar below will accommodate each of the cases above. If one high confidence candidate is found then an entire 

immunization history may be returned. If one or more lower confidence candidates are found, then a list of patient identifiers may 

be returned. 

The usage of segments will be specified in two separate profiles. The first profile will address the case where one or more lower 

confidence matches are found. In this case a list of candidates will be returned. These will not have immunization histories. (Similar 

 

27 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. 

28 More than one high confidence match constitutes is considered a set of lower confidence matches. 
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 159

to V2.3.1 VXX) The other profile will handle the case where the receiving system finds one high confidence match. In this case one 

client immunization record will be returned (similar to V2.3.1 VXR). 

Response Grammar RSP^K11 

Table 7-3 Response Grammar RSP^K11

Segment Cardinality HL7 Optionality29 Comment

MSH [1..1] R

MSA [1..1] R

[ERR] [0..1] O If errors exist, then this segment is 

populated.

QAK [1..1] R

QPD [1..1] R Query Parameter Definition Segment30

[{ [0..1] O --- Response begin31

 [{ [0..*] O Begin patient identifier

PID [1..1] R

[PD1 ] [0..1] RE

[{NK1 }] [0..*] RE

 }] End Patient Identifier

[ [0..1] O Begin immunization history

[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

Begin Pharmacy Administration

RXA [1..1] R

 

29 Optionality is not the same as Usage, but rather the standard definitions of HL7. 

30 Matches the information in the requesting QBP message. 

31 If a query errors out or if no matching persons are found the segments in the Response group will not be returned. 
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 160

[RXR ] [0..1] RE

[{ [0..*] RE Begin Observation

OBX [1..1] R

[NTE ] [0..1] RE

}] End observation

}]

End Pharmacy Administration 

End Order

] End Immunization History

}] Response end
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 161

MSH - MESSAGE HEADER SPECIFICATION 

Table 7-4 MSH Specification for Request 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 [1..1] 00007 Date/Time Of Message R The degree of precision 

must be at least to the 

second, and the time zone 

must be included 

(format 

YYYYMMDDHHMMSS[.S[S[

S[S]]]]+/-ZZZZ). 

8 40 ST [0..1] 00008 Security O

9 15 MSG [1..1] 00009 Message Type R QBP^Q11^QBP_Q11

10 20 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

RE NE-Never
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 162

SEQ LEN Data 

Type

Cardinality Value 

set

ITEM # ELEMENT NAME Usage Constraint

16 2 ID [0..1] 0155 00016 Application 

Acknowledgment Type

RE AL-Always

17 3 ID [0..1] 0399 00017 Country Code O blank

18 16 ID [0..1] 0211 00692 Character Set O blank

19 CE [0..1] 00693 Principal Language Of 

Message

O blank

20 20 ID [0..1] 0356 01317 Alternate Character Set 

Handling Scheme

O blank

21 EI [1..1] 01598 Message Profile 

Identifier

R Z34^ CDCPHINVS

QPD Input Parameter Specification

Table 7-5 QPD Input Parameter Specification 

Field Seq 

(Query 

ID=Z34)

Name Key/

Search

Sort LEN TYPE Opt Rep Match 

Op

TBL Segment 

Field 

Name

Service 

Identifier 

Code

Element Name or 

Value

1 MessageQueryName CE R Z34^Request 

Immunization 

History^HL70471

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 PatientMotherMaiden

Name

XPN RE PID.6 PID-6: Mother’s 

maiden name

6 Patient Date of Birth 26 TS RE PID.7 PID-7: Patient date of 

birth

7 Patient Sex 1 IS RE PID.8 PID-8: Patient sex
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 163

Field Seq 

(Query 

ID=Z34)

Name Key/

Search

Sort LEN TYPE Opt Rep Match 

Op

TBL Segment 

Field 

Name

Service 

Identifier 

Code

Element Name or 

Value

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 

Table 7-6 QPD Input Parameter Field Description and Commentary 

Input Parameter (Query ID=Z34) Comp. Name DT Description
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 164

Input Parameter (Query ID=Z34) Comp. Name DT Description

MessageQueryName CE Z34^Request Immunization History^HL70471

QueryTag ST Unique to each query message instance.

PatientList CX 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 If this field, PID.3.1, is not valued, PatientList is not considered 

when seeking matching clients.

Assigning Authority HD If this field, PID.3.4, is not valued, PatientList is not considered 

when seeking matching clients.

IdentifierTypeCode IS If this field, PID.3.5, is not valued, PatientList is not considered 

when seeking matching clients.

PatientName XPN If this field, PID.5, is not valued, then the query will return an error, 

since this is a required field.

Family Name FN If this field, PID.5.1, is not valued, then patient name is considered 

to contain no value. 

Given Name ST If this field, PID.5.2, is not valued, then patient name is considered 

to contain no value. Given name is required. 

Second or further names ST If this field, PID.5.3, is not valued, then all values for this field are 

considered a match.

Suffix ST If this field, PID.5.4, is not valued, then all values for this field are 

considered a match.

Mother’s Maiden Name XPN If this field, PID.6, is not valued, Mother’s maiden name is not 

considered when seeking matching clients.

Family Name FN If this field, PID.6.1, is not valued, then mother’s maiden name is 

considered to contain no value. 

Given Name ST If this field, PID.6.2, is not valued, then all values for this field are 

considered a match.

DateOfBirth TS If this field, PID.7, is not valued to an accuracy of at least day, 
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 165

Input Parameter (Query ID=Z34) Comp. Name DT Description

then this field is considered not valued. 

Sex IS If this field, PID.8, is not valued, then all values for this field are 

considered a match.

Address XAD If this field, PID.11, is not valued, then address will not be 

considered when seeking matching clients.

Street Address SAD If this field, PID.11.1, is not valued, then all values for this field are 

considered a match.

City ST If this field, PID.11.3, is not valued, then address is considered to 

contain no value. 

State ST If this field, PID.11.4, is not valued, then address is considered to 

contain no value. 

ZIP ST If this field, PID.11.5, is not valued, then all values for this field are 

considered a match.

Address Type IS If this field, PID.11.7 is not valued, then it shall default to L, legal 

address.

Phone XTN 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, then address is considered to 

contain no value.

Multiple Birth Indicator ID If this field, PID.24, is not valued, then Multiple Birth Indicator is 

not considered when seeking matching clients. 

Birth Order NM If this field, PID.25, is not valued, then birth order is not 

considered when seeking matching clients.

Client last updated date TS 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 If this field, PID.34, is not valued, then client last updating facility
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 166

Input Parameter (Query ID=Z34) Comp. Name DT Description

is not considered when seeking matching clients.

All of the fields used for searching in the query parameters are listed as Required but may be empty (RE) in the Guide. However, 

local business rules may constrain this. For instance, a system may require name, date of birth and patient id. Alternatively, it may 

require that at least four fields are populated or some other business rule. This must be documented in a local implementation guide 

or profile. 

This Guide does not specify search logic. 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 Field Description and Commentary

Table 7-7 RCP Response Control Parameter Field Description and Commentary 

Field Seq 

(Query 

ID=Z34)

Name Component Name LEN DT Description

1 Query Priority 1 ID If this field is not valued then it shall default to I. The only value 

permitted is I.

2 Quantity Limited Request 10 CQ

Quantity NM The maximum number of patients that may be returned. This value 

is set by the requester. The sender may send up to this number. 

Units CWE This value shall be RD (records)

3 Response Modality 60 CWE Real time or Batch. Default is R.

7 Segment group inclusion 256 ID This field shall be empty. 
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 167

Return a List of Candidates Profile -- Z31^CDCPHINVS 

HL7 Version 2.5.1 Message Profile for Returning a List of Candidates in Response to a Request Immunization History Query 

Introduction: 

A key task that must be accomplished for immunization messaging is requesting an immunization history from another information 

system. There are 4 possible outcomes to a request for immunization query. 

Table 7-8 Query Response Possibilities 

Outcome Action

No clients are found that match the 

requested person

Send acknowledgement indicating no 

matches found.

Exactly one high confidence match is 

found.

Return Immunization history (See Z32 

profile)

One or more lower confidence persons 

match the criteria sent. Matching more 

than one high confidence candidate 

constitutes a lower confidence match.

Return a list of candidates for further 

refinement of selection.

The message is not well-formed and can’t 

be processed.

Return error acknowledgement

This profile constrains the QBP Query, Request Immunization History Query Z34 , that is specified above. The goal of this profile is to 

constrain the response specified in the Request Immunization History query profile to a list of patients and their identifiers. In all 

other aspects it conforms completely with the specifications described in that query profile. 
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 168

Use Case: 

Figure 7-1--Return Candidate List 

Name: Return Candidate List 

Actors: 

1. Immunization History Requester—is a system that requests an immunization history for a specific individual. In this use case, 

it receives the candidate list sent. 

2. Immunization History Supplier—returns candidate list to a requester for in response to a request for immunization history. 

Preconditions: 

1. The History Supplier has found records for one or more persons who match the parameters in the query. 

2. The History Supplier has created the response message. 

Flow of Events: 

1. The History Supplier sends the RSP response message. 

2. The History Requester receives the RSP response message. 
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 169

Post-Conditions: 

1. The History Requester has a list of candidates for review and selection. 

Static Definition 

Response Grammar RSP^K11 Constrained by This Profile 

This profile constrains the Request for Immunization Query Response Grammar by changing the cardinality of the Immunization 

History block to [0..0]. None of the segments within that block will be returned. 

Response Grammar RSP^K11 

Table 7-9 Response Grammar RSP^K11 

Segment Cardinality HL7 

Optionality

Comment

MSH [1..1] R

MSA [1..1] R

[ ERR] [0..1] O If errors exist, then this 

segment is populated.

QAK [1..1] R

QPD [1..1] R Query Parameter Definition 

Segment32

[{ [1..1] R --- Response begin33

 [{ [1..*] R Begin patient identifier

PID [1..1] R

[PD1 ] [0..1] RE

 

32 Matches the information in the requesting QBP message. 

33 If a query errors out or if no matching persons are found the segments in the Response group will not be returned. 
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 170

[{NK1 }] [0..*] RE

 }] End Patient Identifier

[ [0..0] X Begin immunization history

All segments below are not 

returned because this group is 

not supported in this response 

profile. The cardinality and usage 

for each segment below is not 

changed.

[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

Begin Pharmacy Administration

RXA [1..1] R

[RXR ] [0..1] RE

[{ [0..*] RE Begin Observation

OBX [1..1] R

[{NTE }] [0..*] RE

}] End observation

}]

End Pharmacy Administration 

End Order

] End Immunization History

}] Response end

This profile indicates that a list of patient identification shall be returned. It shall be identified in MSH-21 by its profile identifier. 
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 171

Segment Level Profile 

This profile makes no changes to the parent query profile. 

Field Level Profile 

This profile makes no changes to the parent query profile, with the exception of the MSH-21 field, which contains the profile 

identifier, Z31^CDCPHINVS. 

Dynamic Definition 

Sequence Diagram 

Figure 7-2 Return Candidate List (RSP^K11) 
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 172

This diagram illustrates the context of the message. The message specified in this profile is in Bold and labeled Return Candidate 

List(RSP^K11). 

Acknowledgement Responsibilities 

Application level acknowledgement is allowed, but not required. 

Return an Immunization History – Z32^CDCPHINVS 

HL7 Version 2.5.1 Message Profile for Returning an Immunization History 

Introduction: 

A key task that must be accomplished for immunization messaging is requesting an immunization history from another information 

system. One component of that process is returning an immunization history. This profile constrains the QBP Query, Request 

Immunization History Query Z34 , that is specified above. That query profile specifies the query for requesting an immunization 

history and is intended to support 2 types of response. One response returns a list of candidate client/patients to be the basis of 

further selection. That selection is then used to re-query for an immunization history. The second is a response that returns an 

immunization history. This second is the focus of this message profile. The goal of this profile is to constrain the response specified in 

the Request Immunization History query profile to a single immunization history. In all other aspects it conforms completely with the 

specifications described in the implementation Guide for this query profile. 

Use Case: 

Name: Return Immunization History 
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 173

Figure 7-3 Return Immunization History Use Case 

Actors: 

1. Immunization History Requester—is a system that requests an immunization history for a specific individual. In this use case, 

it receives the immunization history sent. 

2. Immunization History Supplier—returns an immunization history to a requester for a specific individual in response to a 

request for immunization history. 

Preconditions: 

1. The History Supplier has found the records for the requested person. 

2. The History Supplier has created the response message. 

Flow of Events: 

1. The History Supplier sends the RSP response message. 

2. The History Requester receives the RSP response message. 

Post-Conditions: 

1. The History Requester has the immunization history. 
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 174

Static Definition 

Response Grammar RSP^K11 Constrained by This Profile 

This profile constrains the Request for Immunization Query Response Grammar by changing the cardinality of the response to one 

repetition. 

Response Grammar RSP^K11 

Figure 7-4 Return Immunization History Response Grammar 

Segment Cardinality Comment

MSH [1..1]

MSA [1..1]

[ERR] [0..*] If errors exist, then this 

segment is populated.

QAK [1..1]

QPD [1..1] Query Parameter Definition 

Segment34

[ [0..1] --- Response control parameter 

begin

Note Changed Cardinality

Begin patient identifier

PID (1..1)

[PD1 ] (0..1)

[{NK1 }] (0..*)

End Patient Identifier

 

34 Matches the information in the requesting QBP message. 
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 175

[ Begin patient visit

PV1 (0..1)

]

[ Begin Insurance

IN1 (0..1)

] End Insurance

[{ (0..*) Begin Order

ORC [1..1] Required if client has 

immunization records (RXA). 

There is one ORC for each RXA

Begin Pharmacy Administration

RXA (1..1)

[RXR ] (0..1)

[{ (0..*) Begin Observation

OBX (1..1)

[{NTE }] (0..*)

}] End observation

}]

End Pharmacy Administration 

End Order

] --- Response control parameter end

This profile indicates that only one repetition of an entire immunization history shall be returned. It shall be identified in MSH-21 by 

its profile identifier, Z32^CDCPHINVS. 

Segment Level Profile 

This profile makes no changes to the parent query profile. 

Field Level Profile 

This profile makes no changes to the parent query profile, with the exception of the MSH 21 profile identifier, Z32^CDCPHINVS. 
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 176

Dynamic Definition 

Sequence Diagram 

Figure 7-5 Return Immunization History Sequence Diagram 

This diagram illustrates the context of the message. The message specified in this profile is in Bold and labeled Return Immunization 

History(RSP^K11). 

Acknowledgement Responsibilities 

Application level acknowledgement is allowed, but not required.
Change History 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 177

Change History Details

Table 1--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

Table 2--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

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]
Change History 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 178

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

Table 3--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 PID15Corrected 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
Change History 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 179

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

Table 4--Release 1.4 

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

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 
Change History 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 8/1/2012 180

Location Change

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
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

APPENDIX A: Code Tables

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

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

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.
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

U Unknown/undifferentiat

ed

No assertion Is made about the gender of the 

person.

HL7-defined Table 0003 - Event type 

Only selected values listed Use in MSH-9, second component. Only these values are 

expected. 

This code indicates the trigger event. Refer to Chapter 3, Version 2.5.1 for further 

information on HL7 event triggers. 

Value Description

A28 ADT/ACK - Add person information

A08 ADT/ACK – Update person information

A04 ADT/ACK – Register a patient

Q11 QBP - Query by parameter requesting an RSP segment pattern response (Query 

for vaccination record)

K11 RSP - Segment pattern response in response to QBP^Q11 (Response to 

vaccination query) 

V04 VXU - Unsolicited vaccination record update

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. 

Value set OID: 2.16.840.1.114222.4.11.836

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

<empty field> Unknown/undetermined
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

The following table is included for reference. The NIP original race codes are still 

accepted for backwards compatibility. The numeric code US race codes should be used. 

US race codes Description

NIP original 

race codes Description

1002-5 American Indian or 

Alaska Native

I American Indian 

or Alaska Native

2028-9 Asian A Asian or Pacific 

Islander

2076-8 Native Hawaiian or 

Other Pacific Islander

A Asian or Pacific 

Islander

2054-5 Black or AfricanAmericanB Black or AfricanAmerican

2106-3 White W White

2131-1 Other Race O Other

Unknown U Unknown

HL7-defined Table 0008 - Acknowledgment code 

Use in MSA-1.

This code indicates the type of acknowledgement expected. 

Value Description

AA Original mode: Application Accept

Enhanced mode: Application acknowledgment: Accept

AE Original mode: Application Error

Enhanced mode: Application acknowledgment: Error

AR Original mode: Application Reject

Enhanced mode: Application acknowledgment: Reject

CA Enhanced mode: Accept acknowledgment: Commit Accept

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. 
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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

Value Description

BRO Brother

CGV Care giver

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 
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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)

V02 VFC eligibleMedicaid/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 eligibleUninsuredClient does not have private insurance coverage and 

< 19 years old and the vaccine administered is 

eligible for VFC funding.

V04 VFC eligibleAmerican 

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 eligibleFederally 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 

eligibleunderinsured]

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 
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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. 

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 code set are expected to be F for Final. For a current list of HL7 values 

please reference the HL7 version 2.5.1 documents. 

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-defined Table 0104 - Version ID 

 Use in MSH-12. Only these values are expected. 
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

Value Description

2.5.1 Release 2.5.1 April 2007

HL7-defined Table 0105 - Source of comment 

 Use in NTE-2.

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 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 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

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.
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

|””|

<empty field>

||

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

HL7-defined Table 0162 - Route of administration 

Only selected values should be used. Use in RXR-1.

Note that HITSP has specified the use of the FDA route of administration. The following 

table maps these to the HL7 table 0162 values. 

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

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
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

Example 

|C28161^Intramuscular^NCIT| 

|SC^Subcutaneous^HL70162| 

HL7-defined Table 0163 - Administrative site 

Only selected values listed. Use in RXR-2. Only these values are expected. 

HITSP has recommended the use of SNOMED codes. At this point not all of these 

concepts have pre-coordinated SNOMED codes. The post-coordinated are longer than 

the nominal length of the first component of the CE data type. Therefore, this guide will 

continue to support the HL7 0163 codes. 

SNOMED 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

RG Right Gluteous Medius

RD Right Deltoid

RLFA Right Lower Forearm

User-defined Table 0189 - Ethnic Group 

These values are consistent with the OMB Notice of revised categories for collection of 

race and ethnicity data and with HL7’s Version 2.4. Use in PID-22, NK1-28. 

US ethnicity codes HL7 Version 2.4 

ethnicity codes

Description

2135-2 H Hispanic or Latino

2186-5 N not Hispanic or Latino

U Unknown
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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

Recording of Birth State uses the BDL, birth delivery location code.
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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

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
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

 

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

HL7 Table 0203 - Identifier type

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

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
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

Value Description Comment

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

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
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

Value Description Comment

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 

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

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.
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

Value Description Comment

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 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
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

Value Description Comment

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

OK Data found, no errors (this is the default)

NF No data found, no errors

AE Application error

AR Application reject

TM Too many candidates found

HL7-defined Table 0211 - Alternate character sets 

 Use in MSH-18

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. 
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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-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 35

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 Status

AB Abbott Laboratories includes Ross Products Division, 

Solvay Active

ACA Acambis, Inc acquired by sanofi in sept 2008 Inactive

AD Adams Laboratories, Inc. Active

ALP Alpha Therapeutic Corporation Active

 

35 This link is current as of 2/15/2011. 
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

AR Armour part of CSL Inactive

AVB Aventis Behring L.L.C. part of CSL Inactive

AVI Aviron acquired by Medimmune Inactive

BA Baxter Healthcare Corporationinactive Inactive

BAH Baxter Healthcare Corporation

includes Hyland Immuno, Immuno 

International AG,and North 

American Vaccine, Inc./acquired 

some assets from alpha therapeutics

Active

BAY Bayer Corporation Bayer Biologicals now owned by 

Talecris Inactive

BP Berna Products Inactive

BPC Berna Products Corporation includes Swiss Serum and Vaccine 

Institute Berne Active

BTP Biotest Pharmaceuticals 

Corporation

New owner of NABI HB as of 

December 2007, Does NOT replace 

NABI Biopharmaceuticals in this 

code list.

Active

MIP Emergent BioDefense Operations 

Lansing

Bioport renamed. Formerly 

Michigan Biologic Products Institute Active

CSL CSL Behring, Inc CSL Biotherapies renamed to CSL 

Behring Active

CNJ Cangene Corporation Active

CMP Celltech Medeva Pharmaceuticals Part of Novartis Inactive

CEN Centeon L.L.C. Inactive

CHI Chiron Corporation Part of Novartis Inactive

CON Connaught acquired by Merieux Inactive

DVC DynPort Vaccine Company, LLC Active

EVN Evans Medical Limited Part of Novartis Inactive

GEO GeoVax Labs, Inc. Active

SKB GlaxoSmithKline includes SmithKline Beecham and 

Glaxo Wellcome Active

GRE Greer Laboratories, Inc. Active

IAG Immuno International AG Part of Baxter Inactive

IUS Immuno-U.S., Inc. Active

INT Intercell Biomedical Active

KGC Korea Green Cross Corporation Active

LED Lederle became a part of WAL, now owned 

by Pfizer Inactive

MBL Massachusetts Biologic 

Laboratories

formerly Massachusetts Public 

Health Biologic Laboratories Active

MA Massachusetts Public Health 

Biologic Laboratories Inactive
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

MED MedImmune, Inc.

acquired U.S. Bioscience in 1999 and 

Aviron in 2002, integrated with 

Cambridge Antibody Technology 

strategic alignment with new parent 

company, AstraZeneca, in 2007.

Active

MSD Merck & Co., Inc. Active

IM Merieux Part of sanofi Inactive

MIL Miles Inactive

NAB NABI formerly North American 

Biologicals, Inc. Active

NYB New York Blood Center Active

NAV North American Vaccine, Inc. part of Baxter Inactive

NOV Novartis Pharmaceutical 

Corporation

includes Chiron, PowderJect 

Pharmaceuticals, Celltech Medeva 

Vaccines and Evans Limited, CibaGeigy Limited and Sandoz Limited

Active

NVX Novavax, Inc. Active

OTC Organon Teknika Corporation Active

ORT Ortho-clinical Diagnostics a J & J company (formerly Ortho 

Diagnostic Systems, Inc.) Active

PD Parkedale Pharmaceuticals no website and no news articles 

(formerly Parke-Davis) Inactive

PWJ PowderJect Pharmaceuticals See Novartis Inactive

PRX Praxis Biologics became a part of WAL, now owned 

by Pfizer Inactive

JPN

The Research Foundation for 

Microbial Diseases of Osaka 

University (BIKEN)

Active

PMC sanofi pasteur

formerly Aventis Pasteur, Pasteur 

Merieux Connaught; includes 

Connaught Laboratories and Pasteur 

Merieux. Acquired ACAMBIS.

Active

SCL Sclavo, Inc. Active

SOL Solvay Pharmaceuticals Part of Abbott Inactive

SI Swiss Serum and Vaccine Inst. Part of Berna Inactive

TAL Talecris Biotherapeutics includes Bayer Biologicals Active

USA United States Army Medical 

Research and Material Command Active

VXG VaxGen acquired by Emergent Biodefense 

Operations Lansing, Inc Inactive

WA Wyeth-Ayerst became WAL, now owned by Pfizer Inactive

WAL Wyeth acquired by Pfizer 10/15/2009 Active

ZLB ZLB Behring acquired by CSL Inactive

OTH Other manufacturer Active

UNK Unknown manufacturer Active
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

AKR Akorn, Inc Active

PFR Pfizer, Inc

includes Wyeth-Lederle Vaccines 

and Pediatrics, Wyeth Laboratories, 

Lederle Laboratories, and Praxis 

Biologics,

Active

BRR Barr Laboratories Subsidiary of Teva Pharmaceuticals Active

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 
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

HL7-defined Table 0292 - Codes for Vaccines administered (code=CVX) 

Use in RXA-5 

The table below represents the August 2011 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 36

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 VaccineStatus

99 RESERVED - do not use RESERVED - do not use

Code 99 will not be used in 

this table to avoid confusion 

with code 999.

Inactive

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.

Inactive

999 unknown unknown vaccine or 

immune globulin

This CVX code has little 

utility and should rarely be 

used.

Inactive

143 Adenovirus types 4 and 7 Adenovirus, type 4 and 

type 7, live, oral

This vaccine is administered 

as 2 tablets. Active

54 adenovirus, type 4 adenovirus vaccine, type 4, 

live, oral Inactive

55 adenovirus, type 7 adenovirus vaccine, type 7, 

live, oral Inactive

 

36 Link is current as of 8/1/2011. 
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

82 adenovirus, unspecified 

formulation

adenovirus vaccine, 

unspecified formulation

This CVX code is intended to 

allow reporting of 

adenovirus vaccinations 

where the formulation is 

not known. For example, 

this may occur if a historic 

record of an adenovirus 

vaccination is recorded 

from a vaccination card.

Inactive

24 anthrax anthrax vaccine Active

19 BCG Bacillus Calmette-Guerin 

vaccine Active

27 botulinum antitoxin botulinum antitoxin Active

26 cholera cholera vaccine Inactive

29 CMVIG cytomegalovirus immune 

globulin, intravenous Active

56 dengue fever dengue fever vaccine Never 

Active

12 diphtheria antitoxin diphtheria antitoxin Active

28 DT (pediatric)

diphtheria and tetanus 

toxoids, adsorbed for 

pediatric use

Active

20 DTaP

diphtheria, tetanus toxoids 

and acellular pertussis 

vaccine

Active

106 DTaP, 5 pertussis 

antigens

diphtheria, tetanus toxoids 

and acellular pertussis 

vaccine, 5 pertussis 

antigens

Active

107 DTaP, unspecified 

formulation

diphtheria, tetanus toxoids 

and acellular pertussis 

vaccine, unspecified 

formulation

This CVX code is intended to 

allow reporting of DTAP 

vaccinations where the 

formulation is not known. 

For example, this may occur 

if a historic record of an 

DTAP vaccination is 

recorded from a vaccination 

card.

Inactive

110 DTaP-Hep B-IPV DTaP-hepatitis B and 

poliovirus vaccine Active

50 DTaP-Hib

DTaP-Haemophilus 

influenzae type b 

conjugate vaccine

Active
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

120 DTaP-Hib-IPV

diphtheria, tetanus toxoids 

and acellular pertussis 

vaccine, Haemophilus 

influenzae type b 

conjugate, and poliovirus 

vaccine, inactivated (DTaPHib-IPV)

Active

130 DTaP-IPV

Diphtheria, tetanus 

toxoids and acellular 

pertussis vaccine, and 

poliovirus vaccine, 

inactivated

Active

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-HibIPV)

Inactive

01 DTP diphtheria, tetanus toxoids 

and pertussis vaccine Inactive

22 DTP-Hib

DTP-Haemophilus 

influenzae type b 

conjugate vaccine

Inactive

102 DTP-Hib-Hep B

DTP- Haemophilus 

influenzae type b 

conjugate and hepatitis b 

vaccine

Inactive

57 hantavirus hantavirus vaccine Never 

Active

30 HBIG hepatitis B immune 

globulin Active

52 Hep A, adult hepatitis A vaccine, adult 

dosage Active

83 Hep A, ped/adol, 2 dose

hepatitis A vaccine, 

pediatric/adolescent 

dosage, 2 dose schedule

Active

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.

Inactive
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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.

Inactive

85 Hep A, unspecified 

formulation

hepatitis A vaccine, 

unspecified formulation

This CVX code is intended to 

allow reporting of Hep A 

vaccinations where the 

formulation is not known. 

For example, this may occur 

if a historic record of an Hep 

A vaccination is recorded 

from a vaccination card.

Inactive

104 Hep A-Hep B hepatitis A and hepatitis B 

vaccine Active

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.

Active

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 code 08.

Inactive
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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 hepatitis B 

vaccine.

Active

44 Hep B, dialysis hepatitis B vaccine, dialysis 

patient dosage Active

45 Hep B, unspecified 

formulation

hepatitis B vaccine, 

unspecified formulation

This CVX code is intended to 

allow reporting of hepatitis 

B vaccinations where the 

formulation is not known. 

For example, this may occur 

if a historic record of a Hep 

B vaccination is recorded 

from a vaccination card.

Inactive

58 Hep C hepatitis C vaccine Never 

Active

59 Hep E hepatitis E vaccine Never 

Active

60 herpes simplex 2 herpes simplex virus, type 

2 vaccine

Never 

Active

47 Hib (HbOC)

Haemophilus influenzae 

type b vaccine, HbOC 

conjugate

Inactive

46 Hib (PRP-D)

Haemophilus influenzae 

type b vaccine, PRP-D 

conjugate

Inactive

49 Hib (PRP-OMP)

Haemophilus influenzae 

type b vaccine, PRP-OMP 

conjugate

Active

48 Hib (PRP-T)

Haemophilus influenzae 

type b vaccine, PRP-T 

conjugate

Active

17 Hib, unspecified 

formulation

Haemophilus influenzae 

type b vaccine, conjugate 

unspecified formulation

Inactive

51 Hib-Hep B

Haemophilus influenzae 

type b conjugate and 

Hepatitis B vaccine

Active

61 HIV human immunodeficiency 

virus vaccine

Never 

Active
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

118 HPV, bivalent human papilloma virus 

vaccine, bivalent Active

62 HPV, quadrivalent human papilloma virus 

vaccine, quadrivalent Active

137 HPV, unspecified 

formulation

HPV, unspecified 

formulation

This CVX code is intended to 

allow reporting of HPV 

vaccinations where the 

formulation is not known. 

For example, this may occur 

if a historic record of an 

HPV vaccination is recorded 

from a vaccination card.

Inactive

86 IG immune globulin, 

intramuscular Active

14 IG, unspecified 

formulation

immune globulin, 

unspecified formulation Inactive

87 IGIV immune globulin, 

intravenous Active

123 influenza, H5N1-1203

influenza virus vaccine, 

H5N1, 

A/Vietnam/1203/2004 

(national stockpile)

Inactive

135 Influenza, high dose 

seasonal

influenza, high dose 

seasonal, preservative-free Active

111 influenza, live, intranasal

influenza virus vaccine, 

live, attenuated, for 

intranasal use

Seasonal Influenza Active

141 Influenza, seasonal, 

injectable

Influenza, seasonal, 

injectable

This is one of two codes 

replacing CVX 15, which is 

being retired.

Active

140

Influenza, seasonal, 

injectable, preservative 

free

Influenza, seasonal, 

injectable, preservative 

free

This vaccine code is one of 

two which replace CVX 15, 

influenza, split virus.

Active

144

influenza, seasonal, 

intradermal, preservative 

free

seasonal influenza, 

intradermal, preservative 

free

Active

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.

Inactive
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

88 influenza, unspecified 

formulation

influenza virus vaccine, 

unspecified formulation

This CVX code is intended to 

allow reporting of seasonal 

flu vaccinations where the 

formulation is not known. 

For example, this may occur 

if a historic record of an 

seasonal flu vaccination is 

recorded from a vaccination 

card.

Inactive

16 influenza, whole influenza virus vaccine, 

whole virus Inactive

10 IPV poliovirus vaccine, 

inactivated Active

134 Japanese Encephalitis IM

Japanese Encephalitis 

vaccine for intramuscular 

administration

Active

39 Japanese encephalitis SC Japanese Encephalitis 

Vaccine SC Active

129 Japanese Encephalitis, 

unspecified formulation

Japanese Encephalitis 

vaccine, unspecified 

formulation

This CVX code is intended to 

allow reporting of JE 

vaccinations where the 

formulation is not known. 

For example, this may occur 

if a historic record of an JE 

vaccination is recorded 

from a vaccination card.

Inactive

63 Junin virus Junin virus vaccine Never 

Active

64 leishmaniasis leishmaniasis vaccine Never 

Active

65 leprosy leprosy vaccine Never 

Active

66 Lyme disease Lyme disease vaccine Inactive

04 M/R measles and rubella virus 

vaccine Inactive

67 malaria malaria vaccine Never 

Active

05 measles measles virus vaccine Inactive

68 melanoma melanoma vaccine Never 

Active

103 meningococcal C 

conjugate

meningococcal C 

conjugate vaccine Inactive
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

136 Meningococcal MCV4O

meningococcal 

oligosaccharide (groups A, 

C, Y and W-135) diphtheria 

toxoid conjugate vaccine 

(MCV4O)

Active

114 meningococcal MCV4P

meningococcal 

polysaccharide (groups A, 

C, Y and W-135) diphtheria 

toxoid conjugate vaccine 

(MCV4P)

Active

32 meningococcal MPSV4

meningococcal 

polysaccharide vaccine 

(MPSV4)

Active

108 meningococcal, 

unspecified formulation

meningococcal vaccine, 

unspecified formulation

This CVX code is intended to 

allow reporting of 

meningococcal vaccinations 

where the formulation is 

not known. For example, 

this may occur if a historic 

record of meningococcal 

vaccination is recorded 

from a vaccination card.

Inactive

03 MMR measles, mumps and 

rubella virus vaccine Active

94 MMRV measles, mumps, rubella, 

and varicella virus vaccine Active

07 mumps mumps virus vaccine Active

127 Novel influenza-H1N1-09 Novel influenza-H1N1-09, 

injectable Inactive

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)

Inactive

125 Novel Influenza-H1N1-09, 

nasal

Novel Influenza-H1N1-09, 

live virus for nasal 

administration

Inactive

126 Novel influenza-H1N1-09, 

preservative-free

Novel influenza-H1N1-09, 

preservative-free, 

injectable

Inactive

02 OPV poliovirus vaccine, live, 

oral Inactive
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

69 parainfluenza-3

parainfluenza-3 virus 

vaccine Inactive

11 pertussis pertussis vaccine Inactive

23 plague plague vaccine Active

133 Pneumococcal conjugate 

PCV 13

pneumococcal conjugate 

vaccine, 13 valent Active

100 pneumococcal conjugate 

PCV 7

pneumococcal conjugate 

vaccine, 7 valent Active

33 pneumococcal 

polysaccharide PPV23

pneumococcal 

polysaccharide vaccine, 23 

valent

Active

109 pneumococcal, 

unspecified formulation

pneumococcal vaccine, 

unspecified formulation

This CVX code is intended to 

allow reporting of 

pneumoccoccal 

vaccinations where the 

formulation is not known. 

For example, this may occur 

if a historic record of an 

pneumococcal vaccination 

is recorded from a 

vaccination card.

Inactive

89 polio, unspecified 

formulation

poliovirus vaccine, 

unspecified formulation Inactive

70 Q fever Q fever vaccine Never 

Active

40 rabies, intradermal 

injection

rabies vaccine, for 

intradermal injection Active

18 rabies, intramuscular 

injection

rabies vaccine, for 

intramuscular injection Active

90 rabies, unspecified 

formulation

rabies vaccine, unspecified 

formulation Inactive

72 rheumatic fever rheumatic fever vaccine Never 

Active

73 Rift Valley fever Rift Valley fever vaccine Never 

Active

34 RIG rabies immune globulin Active

119 rotavirus, monovalent rotavirus, live, monovalent 

vaccine Active

116 rotavirus, pentavalent rotavirus, live, pentavalent 

vaccine Active

74 rotavirus, tetravalent rotavirus, live, tetravalent 

vaccine Inactive

122 rotavirus, unspecified 

formulation

rotavirus vaccine, 

unspecified formulation Inactive
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

71 RSV-IGIV

respiratory syncytial virus 

immune globulin, 

intravenous

Active

93 RSV-MAb

respiratory syncytial virus 

monoclonal antibody 

(palivizumab),

intramuscular

Active

06 rubella rubella virus vaccine Active

38 rubella/mumps rubella and mumps virus 

vaccine Inactive

76 Staphylococcus bacterio 

lysate

Staphylococcus 

bacteriophage lysate Inactive

138 Td (adult)

tetanus and diphtheria 

toxoids, not adsorbed, for 

adult use

Note that this Td is not 

adsorbed. Active

113 Td (adult) preservative 

free

tetanus and diphtheria 

toxoids, adsorbed, 

preservative free, for adult 

use

Active

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.

Active

139 Td(adult) unspecified 

formulation

Td(adult) unspecified 

formulation

This CVX code is intended to 

allow reporting of Td 

vaccinations where the 

formulation is not known. 

For example, this may occur 

if a historic record of an Td 

vaccination is recorded 

from a vaccination card.

Inactive

115 Tdap

tetanus toxoid, reduced 

diphtheria toxoid, and 

acellular pertussis vaccine, 

adsorbed

Active

35 tetanus toxoid, adsorbed tetanus toxoid, adsorbed Active

142 tetanus toxoid, not 

adsorbed

tetanus toxoid, not 

adsorbed Active

112 tetanus toxoid, 

unspecified formulation

tetanus toxoid, 

unspecified formulation Inactive

77 tick-borne encephalitis tick-borne encephalitis 

vaccine Inactive

13 TIG tetanus immune globulin Active

98 TST, unspecified 

formulation

tuberculin skin test; 

unspecified formulation TB Skin test is not vaccine. Inactive
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

95 TST-OT tine test

tuberculin skin test; old 

tuberculin, multipuncture 

device

TB Skin test is not vaccine. Inactive

96 TST-PPD intradermal

tuberculin skin test; 

purified protein derivative 

solution, intradermal

TB Skin test is not vaccine. Inactive

97 TST-PPD tine test

tuberculin skin test; 

purified protein derivative, 

multipuncture device

TB Skin test is not vaccine. Inactive

78 tularemia vaccine tularemia vaccine Inactive

25 typhoid, oral typhoid vaccine, live, oral Active

41 typhoid, parenteral

typhoid vaccine, 

parenteral, other than 

acetone-killed, dried

Active

53 typhoid, parenteral, AKD 

(U.S. military)

typhoid vaccine, 

parenteral, acetone-killed, 

dried (U.S. military)

Active

91 typhoid, unspecified 

formulation

typhoid vaccine, 

unspecified formulation Inactive

101 typhoid, ViCPs typhoid Vi capsular 

polysaccharide vaccine Active

131 typhus, historical Historical record of a 

typhus vaccination Inactive

75 vaccinia (smallpox) vaccinia (smallpox) vaccine Active

105 vaccinia (smallpox) 

diluted

vaccinia (smallpox) 

vaccine, diluted Inactive

79 vaccinia immune globulin vaccinia immune globulin Active

21 varicella varicella virus vaccine Active

81 VEE, inactivated Venezuelan equine 

encephalitis, inactivated Inactive

80 VEE, live

Venezuelan equine 

encephalitis, live, 

attenuated

Inactive

92 VEE, unspecified 

formulation

Venezuelan equine 

encephalitis vaccine, 

unspecified formulation

Inactive

36 VZIG varicella zoster immune 

globulin Active

117 VZIG (IND)

varicella zoster immune 

globulin (Investigational 

New Drug)

Inactive

37 yellow fever yellow fever vaccine Active

121 zoster zoster vaccine, live Active
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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

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 
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

Use in all HD data types 

Value Description

DNS An Internet dotted name -- either in ASCII or as integers.

GUID Same as UUID.

HCD The CEN Healthcare Coding Scheme Designator. (Identifiers used in DICOM 

follow this assignment scheme.)

HL7 Reserved for future HL7 registration schemes.

ISO An International Standards Organization Object Identifier.

L,M,N These are reserved for locally defined coding schemes.

Random Usually a base64 encoded string of random bits. The uniqueness depends on the 

length of the bits. Mail systems often generate ASCII string “unique names,” 

from a combination of random bits and system names. Obviously, such 

identifiers will not be constrained to the base64 character set.

UUID The DCE Universal Unique Identifier.

x400 An X.400 MHS format identifier.

x500 An X.500 directory name.

HL7-defined Table 0322 - Completion status 

Use in RXA-20

Value Description

CP Complete

RE Refused

NA Not Administered

PA Partially Administered

HL7-defined Table 0323 - Action code 

Use in RXA-21

Value Description

A Add

D Delete

U Update
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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 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.
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

Status 

code

Status text Description/Comment

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.
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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

MDA Medical Assistant

MT Medical Technician

NG Non-Graduate

NP Nurse Practitioner

PharmD Doctor of Pharmacy

PA Physician Assistant
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

Value Description

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. 

User-defined Table 0362 – Facility 

No suggested values defined. 

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. 

Code Grantee

AKA ALASKA

ALA ALABAMA

ARA ARKANSAS

ASA AMERICAN SAMOA

AZA ARIZONA

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
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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

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
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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

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)
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

Value Description

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. 

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

HL7 Table 0516 - Error Severity (use in ERR-4)

Value Description Comment

W Warning Transaction successful, but 

there may be issues. These 

may include non-fatal 

errors with potential for 

loss of data.

I Information Transaction successful, but 

includes returned 

information.

E Error Transaction was not 

successful.
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

User-defined Table 0533 – Application Error Code 

There are no suggested values for this code. Local implementations need to create a 

table of local application error codes. 

CDC-defined NIP001 - Immunization information source 

Use in RXA-9 

Value Description

00 New immunization record

01 Historical information - source unspecified

02 Historical information - from other provider

03 Historical information - from parent’s written record

04 Historical information - from parent’s recall

05 Historical information - from other registry

06 Historical information - from birth certificate

07 Historical information - from school record

08 Historical information - from public agency

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
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

CDC-defined NIP003 - Observation identifiers 

Use in OBX-3)37

LOINC®

Code38

Description Corresponding 

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) HL70292 

(CVX codes – use the codes 

described as “unspecified 

formulation” as needed.)

38890-0 Component Vaccine Type (CE) HL70292 

(CVX codes – use the codes 

described as “unspecified 

formulation” as needed.)

Contraindications, Precautions, Indications and Immunities

 

37 All VAERS-only items removed. 

38 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.
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

30946-8 Vaccination 

contraindication/precaution 

effective date

(DT) 19970522

30944-3 Vaccination temporary 

contraindication/precaution 

expiration date

(DT) 19990523

30945-0 Vaccination 

contraindication/precaution

(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

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
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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) 19980526

30981-5 30981-5 – Earliest date to 

give 

(TS) 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.3291

Value Set Code:: 

PHVS_ImmunizationScheduleIdentifier_IIS

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 TAKERESPONSE TYPE (ST) Major Take, Equivocal, Not 

Available

46250-7 VACCINATION TAKERESPONSE 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 not within the scope of this Guide. 

 NIP 005 – Event Consequences

 NIP 007 – Vaccinated at Location

 NIP 008 – Vaccine purchased with Funds

 NIP 009 – Adverse event previously reported

 NIP 010 – Report type
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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

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: 
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

|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: 

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
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

Concept 

Code

Concept Name Definition HL7 Table 

0396 Code

V 2.3.1 Value

NIP004

VXC23

current fever with moderateto-severe illnesscurrent fever with 

moderate-to-severe 

illness CDCPHINVS

16

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 tetanuscontaining 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: 

|VXC18^allergy to bakers yeast^CDCPHINVS| 

|77386006^patient currently pregnant^SCT| 
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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

Examples: 

|39579001^anaphylaxis^SCT| 

|VXC14^Rash within 14 days^CDCPHINVS| 

Value Set Name – Vaccination Special Indications - IIS 

Used in OBX- 5 
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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

Concept 

Code

Concept Name Definition HL7 Table 

0396 Code

V 2.3.1 Value

Z31 Return Candidate Clients

Return Candidate 

Clients CDCPHINVS

Z32

Return Immunization 

History

Return 

Immunization 

History CDCPHINVS

Z34

Request Immunization History Request Immunization 

History CDCPHINVS

Example: 

|Z34^ CDCPHINVS| 

Value Set Name – Immunization Schedule Identifiers - IIS 
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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| 

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 – Evidence of Immunity - IIS 

Used in OBX- 5 

Value Set OID - 2.16.840.1.114222.4.11.3293

Value Set Code:: PHVS_EvidenceOfImmunity_IIS

Value set definition: Evidence of immunity indicates that a person has plausible evidence 

that they have already developed immunity to a particular disease. The definition of 

plausible evidence is a local decision, but best practice would suggest that serological 

evidence of immunity is the strongest indicator of immunity.

Code Set OID: 

SNOMED: 2.16.840.1.113883.6.96
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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

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
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

Concept 

Code

Concept 

Name

Definition HL7 

Table 

0396 

Code

V 2.3.1 Value

NIP004

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

271511000 Hepatitis B 

immune (finding)

Immunity to hepatitis B SCT

Examples: 

|38907003^Varicella infection^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)
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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

Japanese Encephalitis 

VIS 12/7/2011 253088698300011011111207 cdcgs1vis

Measles/Mumps/Rubella 

VIS 4/20/2012 253088698300012711120420 cdcgs1vis

Measles/Mumps/Rubella

/Varicella 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/(Pert

ussis) 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
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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. 

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
Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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

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

Appendix B – Guidance on Usage and Example

Messages 

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
Appendix B 1 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

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-1--Immunization History Core Data Elements 

Data Element Description Support 

Status39

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

 

39 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. 
Appendix B 2 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

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 associated with 

the IIS

Required PD1-16

Client Provider organization 

status

Indicates if client is 

currently associated with 

the provider organization

Required

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
Appendix B 3 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

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 historical record

Required OBX-5

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 Required OBX-5
Appendix B 4 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

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.

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 

disease

Indicates a vaccine 

preventable disease that a 

patient has had

Required OBX-5

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. 
Appendix B 5 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

Figure 6-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 rules40

 

40 See Send Error in ACK for dealing with errors if either of these two tasks identifies problems. 
Appendix B 6 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

5. Seek matching client in receiver data base 

a. No match is found41

i. Add the client to the receiver database. 

ii. Send acknowledgement message42

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)43

ii. Protection indicator = Y 

1. Do not integrate record into receiver data base 

2. Send acknowledgement44

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 acknowledgement45

6. Send acknowledgment to sending system 

7. Sending system accepts acknowledgement message.46

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). 

 

41 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. 

42 See Send Acknowledgement with no error. 

43 Locally, this may be known as the sharing indicator. In this case, the equivalent value is 

sharing = N. 

44 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. 

45 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. 

46 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. 
Appendix B 7 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

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. 

Supported Message Segments 

The following table lists the segments and their usage. 

Table B-2 --Segment Usage 

Segment Cardinality Usage47 Notes

MSH [1..1] R Every message begins 

with an MSH

PID [1..1] R Every VXU requires 

one PID

PD1 [0..1] RE

NK1 [0..*] RE NK1 may repeat and 

may include the client 

with a relationship of 

self.

PV1 [0..1] O

IN1 [0..1] O IN1-3 are not specified 

IN2 [0..1] O in this guide.

IN3 [0..1] O

All of the following segments are part of the ORDER group. A 

VXU does not require an ORC group, allowing update of 

patient/client related data in the absence of updated RXA 

data. Each RXA does require an ORC.

ORC [0..*] RE

RXA [1..1]48 R Each RXA is the child of 

on ORC

 

47 R means it is required. RE means it is required if known/available. X means not supported in 

this Guide. O means optional. 

48 Each ORC must have 1 RXA and each RXA belongs to exactly 1 ORC. 
Appendix B 8 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

RXR [0..1] RE Each RXR is the child of 

one RXA

OBX [0..*] RE Each OBX is the child 

of one RXA. Each RXA 

may have more than 

one OBX segment.

NTE [0..1] RE Each NTE is the child of 

one OBX

Example VXU # 1-Basic message: 

Storyboard: 

Johnny New Patient (male), born 4/14/09 has had 1 dose of Hep B on 4/15/09, 

according the record brought in by Mom (Sally Patient). They live at 123 Any Street, 

Somewhere, Wisconsin 54000. Nurse Sticker at Dalittle Clinic (DCS_DC), administers the 

following shots on 5/31/09: 

 DTAP-Hep B-IPV (Pediarix) lot # xy3939 IM

 HIB (ActHIB) lot # 33k2a IM 

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 <CR>. Segments may wrap 

around in this document. We will insert a blank line between each segment for 

increased readability. 

Note that this message does not include all elements expected for Meaningful Use 

certification. 

MSH|^~\&|MYEHR|DCS|||20090531145259||VXU^V04^VXU_V04|3533469|P|2.5.1

||||AL <CR> 

PID|1||432155^^^DCS^MR||Patient^Johnny^New^^^^L||20090414150308|M|||

123 Any St^^Somewhere^WI^54000^^L<CR> 

PD1||||||||||||N|20090531<CR> 

NK1|1|Patient^Sally|MTH^mother^HL70063|123 Any 

St^^Somewhere^WI^54000^^L<CR> 

PV1|1|R||||||||||||||||||V02^20090531<CR> 
Appendix B 9 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

ORC|RE||197023^DCS|||||||^Clerk^Myron|||||||DCS^Dabig Clinical 

System^StateIIS<CR> 

RXA|0|1|20090415132511|20090415132511|31^Hep B Peds 

NOS^CVX|999|||01^historical record^NIP0001|||||||| <CR> 

ORC|RE||197027^DCS|||||||^Clerk^Myron||^Pediatric^MARY^^^^^^^L^^^^^^

^^^^^MD<CR> 

RXA|0|1|20090531132511|20090531132511|48^HIB PRP-T^CVX|999|||00^new 

immunization 

record^NIP0001|^Sticker^Nurse|^^^DCS_DC||||33k2a||PMC^sanofi^MVX<CR> 

RXR|C28161^IM^NCIT^IM^IM^HL70162|<CR> 

ORC|RE||197028^DCS|||||||^Clerk^Myron||^Pediatric^MARY^^^^^^^L^^^^^^

^^^^^MD<CR> 

RXA|0|1|20090531132511|20090531132511|110^DTAP-Hep BIPV^CVX|999|||00^new immunization 

record^NIP0001|^Sticker^Nurse|^^^DCS_DC||||xy3939||SKB^GSK^MVX<CR> 

RXR|IM^IM^HL70162^C28161^IM^NCIT|<CR> 

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. Some states require that 

this information be included in each immunization history. 

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 
Appendix B 10

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

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) 49 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. 

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. 

 

49 Reference MIROW document 
Appendix B 11

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

Table B-3 --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 0363 to indicate the assigning authority. The 

code is composed of the code from table 0363 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. 

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: 
Appendix B 12

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

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|20090531132511|20090531132511|48^HIB PRPT^CVX|999||||^Sticker^Nurse|^^^DCS_DC||||33k2a||PMC^sanofi^MVX<CR> 

RXR| C28161^IM^NCIT^IM^IM^HL70396<CR> 

OBX|1|CE|64994-7^vaccine fund pgm elig cat^LN|1|V04^VFC eligible 

NA/AN^HL70064||||||F|||20090531132511|||CVX40^per imm^CDCPHINVS <CR> 

VFC Ineligible Client Received Vaccine That Is VFC eligible 

RXA|0|1|20090531132511|20090531132511|48^HIB PRPT^CVX|999||||^Sticker^Nurse|^^^DCS_DC||||33k2a||PMC^sanofi^MVX<CR> 

RXR| C28161^IM^NCIT^IM^IM^HL70396<CR> 

OBX|1|CE|64994-7^vaccine fund pgm elig cat^LN|1|V01^Not VFC eligible 

^HL70064||||||F|||20090531132511||| CVX40^per imm^CDCPHINVS <CR> 

VFC Eligible Client Received Vaccine That Is Not VFC eligible 

RXA|0|1|20090531132511|20090531132511|37^yellow 

fever^CVX|999||||^Sticker^Nurse|^^^DCS_DC||||33k2a||PMC^sanofi^MVX<C

R>

RXR| C28161^IM^NCIT^IM^IM^HL70396<CR> 

OBX|1|CE|64994-7^vaccine fund pgm elig cat^LN|1|V01^Not VFC elig^VFC 

eligible NA/AN^HL70064||||||F|||20090531132511 CVX40^per 

imm^CDCPHINVS <CR> 

VFC Eligible Client Received Vaccine That Is Eligible for Local Funding Program 

RXA|0|1|20090531132511|20090531132511|37^yellow 

fever^CVX|999||||^Sticker^Nurse|^^^DCS_DC||||33k2a||PMC^sanofi^MVX<C

R>

RXR| C28161^IM^NCIT^IM^IM^HL70396<CR> 
Appendix B 13

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

OBX|1|CE|64994-7^vaccine fund pgm elig cat^LN|1|AKA01^Alaska Special 

Funding Program^AKA||||||F|||20090531132511 CVX40^per imm^CDCPHINVS

<CR> 

Example VXU #3 - Include immunization history evaluation and forecast in 

VXU 

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. This document illustrates how this is done and expands on the types of 

information that may be messaged. 

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. 

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-4--Codes Supporting Messaging Evaluation and Forecasting 

Data 

element

Use OBX-3 Value Optionality for 

meaningful evaluation 

and forecast50.

 

50 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. 
Appendix B 14

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

Data 

element

Use OBX-3 Value Optionality for 

meaningful evaluation 

and forecast50.

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.

Single vaccine type use 

30956-7

Combination vaccine 

use 38890-0

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
Appendix B 15

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

Data 

element

Use OBX-3 Value Optionality for 

meaningful evaluation 

and forecast50.

Number of 

doses in 

primary 

Series

Indicates how many 

appropriately given 

doses are required 

to meet the goals of 

this series. 

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.

59782-3 Optional

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
Appendix B 16

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4) 

Last Updated on 8/1/2012

Data 

element

Use OBX-3 Value Optionality for 

meaningful evaluation 

and forecast50.

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. 

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 
Appendix B 17

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

The basic structure for evaluation of combination vaccine components is: 

ORC-order segment 

RXA-the immunization and vaccine 

OBX-vaccine group 51

OBX-the schedule 

OBX-series used 

OBX-dose number in series (ordinal position) 

OBX-doses in series 

OBX-dose validity 

OBX-vaccine group 52

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 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 VXU. Note that the same approach may be used in 

an RSP that returns an immunization history. 

 

51 All of the related observations are linked to the vaccine group using the OBX-4, observation 

sub-id. 

52 All of the related observations are linked to the vaccine group using the OBX-4, observation 

sub-id. 
Appendix B 18

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

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<CR> 

RXA|0|1|20090412|20090412|48^HIB PRP-T^CVX|999|||00^new immunization 

record^NIP0001|^Sticker^Nurse|^^^DCS_DC||||33k2a||PMC^sanofi^MVX|||C

P<CR> 

RXR|C28161^IM^NCIT^IM^IM^HL70162|<CR> 

OBX|1|CE|59779-9^Schedule 

used^LN|1|VXC16^ACIP^CDCPHINVS||||||F|||20090415<CR> 

Indicating Vaccine Group associated: 

Evaluation is 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 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^^ISO+||||||||EZ342|20111001|MSD^^MVX|||CP<CR> 

OBX|1|TS|30956-7^vaccine type^LN|1|03^MMR^CVX||||||F<CR> 

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. 
Appendix B 19

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

Combination vaccine: 

RXA|0|1|20091010||94^MMRV^CVX|0.5|ML^^ISO+||||||||EZ342|20111001|MSD^^MVX|||CP<CR> 

OBX|1|TS|38890-0^Component Vaccine Type^LN|1|21^Varicella^CVX||||||F<CR> 

... stuff about this vaccine group 

OBX|4|TS|38890-0^Component Vaccine Type^LN N|2|03^MMR^CVX||||||F<CR> 

... stuff about this vaccine group 

Note that the vaccine group could also be indicated with the 30956-7^vaccine type^LN 

LOINC.

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<CR>

RXA|0|1|20090412|20090412|48^HIB PRP-T^CVX|999|||00^new immunization 

record^NIP0001|^Sticker^Nurse|^^^DCS_DC||||33k2a||PMC^sanofi^MVX|||CP<C

R>

RXR|C28161^IM^NCIT^IM^IM^HL70162|<CR>

OBX|1|TS|30956-7^vaccine type^LN|1|17^HIB, NOS^CVX||||||F<CR>

OBX|2|CE|59779-9^Immunization Schedule 

used^LN|1|VXC16^ACIP^CDCPHINVS||||||F|||20090415<CR>

OBX|3|N|30973-2^dose number in series^LN|1|1||||||F|||20090415<CR>

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. 
Appendix B 20

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

Reporting the Number of Doses in a Series: 

There are no differences between recommendations and evaluations. 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|x|N|59782-3^number of doses in series^LN|1|1||||||F|||20090415<CR>

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-5--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.

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. 

ORC|RE||123^DCS|||||||^Clerk^Myron<CR> 

RXA|0|1|20090412|20090412|998^No vaccine administered^CVX|999||| 

||||||||||NA<CR> 

OBX|1|TS|30956-7^vaccine type^LN|1|17^HIB, NOS^CVX||||||F<CR>

OBX|2|CE|59779-9^Immunization Schedule 

used^LN|1|VXC16^ACIP^CDCPHINVS||||||F|||20090415<CR>
Appendix B 21

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

OBX|3|DT|30980-7^Date vaccination 

due^LN|1|20090615||||||F|||20090415<CR>

OBX|4|DT|59777-3^Latest date to give 

vaccine^LN|1|20100615||||||F|||20090415<CR>

Note that the filler order number is meaningless in this case since no immunization is 

associated with it. 

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: 

Note that the following message does not contain all elements required for Meaningful 

Use Stage 2 certification. 

MSH|^~\&|MYEHR|DCS|||20091031145259||VXU^V04^VXU_V04|3533469|P|2.5.1

||||AL <CR> 

PID|1||432155^^^DCS^MR||Patient^Johnny^New^^^^L||20090214150308|M|||

123 Any St^^Somewhere^WI^54000^^L<CR> 

PD1||||||||||||N|20090531<CR> 

NK1|1|Patient^Sally|MTH^mother^HL70063|123 Any 

St^^Somewhere^WI^54000^^L<CR> 

PV1|1|R||||||||||||||||||V02^20090531<CR> 

ORC|RE||197023^DCS|||||||^Clerk^Myron|||||||DCS^Dabig Clinical 

System^StateIIS<CR> 

RXA|0|1|20090415132511|20090415132511|31^Hep B Peds 

NOS^CVX|999|||01^historical record^NIP0001|||||||| <CR> 

OBX|1|CE|30956-7^vaccine type^LN|1|31^Hep B Peds NOS^CVX ||||||F<CR> 

OBX|2|CE|59779-9^Immunization Schedule 

used^LN|1|VXC16^ACIP^CDCPHINVS||||||F|||200900531<CR>

OBX|3|N|30973-2^dose number in series^LN|1|1||||||F|||200900531<CR>

OBX|4|N|59782-3^number of doses in series^LN|1|3||||||F|||20090531<CR>
Appendix B 22

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

ORC|RE||197027^DCS|||||||^Clerk^Myron||^Pediatric^MARY^^^^^^^L^^^^^^

^^^^^MD<CR> 

RXA|0|1|20090731132511|20090731132511|48^HIB PRP-T^CVX|999|||00^new 

immunization 

record^NIP0001|^Sticker^Nurse|^^^DCS_DC||||33k2a||PMC^sanofi^MVX|||C

P<CR> 

RXR|C28161^IM^NCIT^IM^IM^HL70162|<CR> 

OBX|1|CE|30956-7^vaccine type^LN|1|17^HIB NOS^CVX ||||||F<CR>

OBX|2|CE|59779-9^Immunization Schedule 

used^LN|1|VXC16^ACIP^CDCPHINVS||||||F|||200900731<CR>

OBX|3|N|30973-2^dose number in series^LN|1|1||||||F<CR>

OBX|4|N|59782-3^number of doses in series^LN|1|4||||||F<CR>

ORC|RE||197028^DCS|||||||^Clerk^Myron||^Pediatric^MARY^^^^^^^L^^^^^^

^^^^^MD<CR> 

RXA|0|1|20091031132511|20091031132511|110^DTAP-Hep BIPV^CVX|999|||00^new immunization 

record^NIP0001|^Sticker^Nurse|^^^DCS_DC||||xy3939||SKB^GSK^MVX|||CP<

CR>

RXR|IM^IM^HL70162^C28161^IM^NCIT|<CR> 

OBX|1|CE|30956-7^vaccine type^LN|1|31^Hep B Peds NOS^CVX ||||||F<CR> 

OBX|2|CE|59779-9^Immunization Schedule 

used^LN|1|VXC16^ACIP^CDCPHINVS||||||F|||200900531<CR>

OBX|3|N|30973-2^dose number in series^LN|1|2||||||F<CR>

OBX|4|N|59782-3^number of doses in series^LN|1|3||||||F<CR>

OBX|5|CE|30956-7^vaccine type^LN|2|10^IPV^CVX ||||||F<CR>

OBX|6|CE|59779-9^Immunization Schedule 

used^LN|2|VXC16^ACIP^CDCPHINVS||||||F|||200901031<CR>

OBX|7|N|30973-2^dose number in series^LN|2|1||||||F<CR>

OBX|8|N|59782-3^number of doses in series^LN|2|4||||||F<CR>

OBX|9|CE|30956-7^vaccine type^LN|3|20^DTAP^CVX ||||||F<CR>

OBX|10|CE|59779-9^Immunization Schedule 

used^LN|3|VXC16^ACIP^CDCPHINVS||||||F<CR>
Appendix B 23

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

OBX|11|N|30973-2^dose number in series^LN|3|1||||||F<CR>

OBX|12|N|59782-3^number of doses in series^LN|3|5||||||F<CR>

ORC|RE||197023^DCS|||||||^Clerk^Myron|||||||DCS^Dabig Clinical 

System^StateIIS<CR> 

RXA|0|1|20091031|20091031|998^no vaccine admin^CVX|999||| 

|||||||||||NA <CR> 

OBX|1|CE|30956-7^vaccine type^LN|1|31^Hep B Peds NOS^CVX ||||||F<CR> 

OBX|2|CE|59779-9^Immunization Schedule 

used^LN|1|VXC16^ACIP^CDCPHINVS||||||F<CR>

OBX|3|DT|30980-7^Date vaccination due^LN|1|20091231||||||F<CR>

Important notes: 

1. Note that the OBX set id increases for each set of OBX under a given RXA, but 

restart at one for the next set of OBX. 

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)) 

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. 
Appendix B 24

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

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. 

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: 

Evidence of immunity indicates that a person has plausible evidence that they have 

already developed immunity to a particular disease. The definition of plausible evidence 

is a local decision, but best practice would suggest that serological evidence of immunity 

is the strongest indicator of immunity. 

The example below shows that no dose of Hep B vaccine was given because the person 

had evidence of previous infection with Hep B. 

ORC|RE||197027^DCS|||||||^Clerk^Myron| <CR> 

RXA|0|1|20090412|20090412|998^No vaccine administered^CVX|999|||NA<CR>

OBX|1|CE|59784-9^Disease with presumed immunity ^LN|1|66071002^HISTORY 

OF HEP B INFECTION^SCT||||||F<CR>

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: 
Appendix B 25

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

OBX|1|CE|30945-0^Vaccination contraindication^LN|1|91930004^allergy 

to eggs^SCT||||||F|||20090415<CR> 

OBX|1|CE|30945-0^Vaccination contraindication^LN|1|VXC19^allergy to 

thimerasol(anaphylactic)^CDCPHINVS||||||F|||20090415<CR> 

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. 

OBX|1|CE|59785-6^Special Indication for 

vaccination^LN|1|VXC7^exposure to 

rabies^CDCPHINVS||||||F|||20090415<CR> 

Example VXU #5 – Send immunizations associated with reactions (adverse 

events) 

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. 

LOINC code: 31044-1 

Value Set is Vaccination Reaction in CDCPHINVS 

ORC|RE||197027^DCS|||||||^Clerk^Myron||^Pediatric^MARY^^^^^^^L^^^^^^

^^^^^MD<CR> 

RXA|0|1|20090412|20090412|48^HIB PRP-T^CVX|999|||00^new immunization 

record^NIP0001|^Sticker^Nurse|^^^DCS_DC||||33k2a||PMC^sanofi^MVX|||C

P<CR> 

RXR|C28161^IM^NCIT^IM^IM^HL70162|<CR> 

OBX|1|CE|31044-1^reaction^LN|1|VXC12^fever > 40.5 

C^CDCPHINVS||||||F|||20090415<CR> 
Appendix B 26

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

OBX|1|CE|31044-1^reaction^LN|1|81308009^encephalopathy, disorder of 

brain^SCT||||||F|||20090415<CR> 

This example describes a dose of HIB given on 4/12/2009. On 4/15/2009, the client 

experienced a fever > 40.5C and encephalopathy. 

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. There are several approaches 

that may be taken. The approach selected depends on the rules and capabilities of both 

systems. 

One approach uses a snap shot approach. Each time an immunization history is sent, it 

replaces the entire immunization history on the receiving side. 

Another approach is to use the RXA-21, Action Code to request deletion of a specific 

record. Some systems will match the request with an existing immunization record 

based on vaccine, vaccination date and other factors implicit in the record and the 

request. They may also use the ORC-3, Filler Order Number, to uniquely delete the 

record of interest. 

The following diagram illustrates how the ORC-3 may be used to identify an 

immunization record for deletion53. Note that the sending system includes the sending 

system unique id 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. 

 

53 The other approaches will not be further illustrated here. 
Appendix B 27

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

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. See example below. 

A new 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. 
Appendix B 28

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

Example 1-Single vaccine (vaccine type approach) 

RXA|0|1|20091010||03^MMR^CVX|0.5|ML^^ISO+||||||||EZ342|20111001|MSD^^MVX|||CP<CR> 

OBX|1|CE|30956-7^vaccine type^LN|1|03^MMR^CVX||||||F<CR> 

OBX|2|TS|29768-9^VIS Publication Date^LN|1|20080110||||||F<CR> 

OBX|3|TS|29769-7^VIS Presentation Date^LN|1|20091010||||||F<CR> 

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. 

Example 2-Combination vaccine (vaccine type approach) 

RXA|0|1|20091010||94^MMRV^CVX|0.5|ML^^ISO+||||||||EZ342|20111001|MSD^^MVX|||CP<CR> 

OBX|1|CE|38890-0^Component Vaccine Type^LN|1|21^Varicella^CVX||||||F<CR> 

OBX|2|TS|29768-9^VIS Publication Date^LN|1|20091010||||||F<CR> 

OBX|3|TS|29769-9^VIS Presentation Date^LN|1|20101010||||||F<CR> 

OBX|4|CE|38890-0^Component Vaccine Type^LN N|2|03^MMR^CVX||||||F<CR> 

OBX|5|TS|29768-9^VIS Publication Date^LN|2|20071010||||||F<CR 

OBX|6|TS|29768-9^VIS Presentation Date^LN|2|20101010||||||F<CR> 

Example 3-Single vaccine (GDTI approach) 

RXA|0|1|20091010||03^MMR^CVX|0.5|ML^^ISO+||||||||EZ342|20111001|MSD^^MVX|||CP<CR> 

OBX|1|CE| 69764-9^document type^LN|1|253088698300012711120420^MMR^ cdcgs1vis||||||F<CR> 

OBX|3|TS|29769-7^VIS Presentation Date^LN|1|20091010||||||F<CR> 

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 4-Combination vaccine (GDTI approach) 

RXA|0|1|20091010||94^MMRV^CVX|0.5|ML^^ISO+||||||||EZ342|20111001|MSD^^MVX|||CP<CR> 

OBX|1|CE|69764-9^Document Type^LN|1|253088698300013411100521^MMRV^ cdcgs1vis ||||||F<CR> 

OBX|3|TS|29769-9^VIS Presentation Date^LN|1|20101010||||||F<CR> 

Note that not all combination vaccines have a single VIS. They would require that an 

OBX pair be sent for each VIS given to the patient. 
Appendix B 29

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

This example shows that a person received an MMRV on 10/10/2007. They received 1 

VIS document for MMRV. The publication date was 5/21/2010. (Determined from 

lookup table. 

VXU Example #8—Send Information About 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||197027^DCS|||||||^Clerk^Myron <CR> 

RXA|0|1|20091010||107^DTAP-NOS^CVX|999||||||||||||00^Parental refusal^NIP002||RE<CR> 

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 Guide. It is 

constrained to have a value of 1. 

VXU Example #9—Send Two Lot Numbers in RXA 

There are occasions when two vaccines are combined at the time of administration. 

The RXA segment should be used to capture this information, specifically the RXA-15 

field. This field allows repetition. Each separate Lot number can be placed here with a ~ 

separating the two lot numbers. Each component belongs to one or more vaccine 

groups or families. 

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, 

followed by a ~ and then the second lot number. The specific RXA field is highlighted 

below in yellow. 

Example: 

RXA|0|1|20080907|20080907|120^DTAP-IPV-HIB^CVX^^^ |.5|ML^^ISO+||00^NEW 

IMMUNIZATION RECORD^NIP001|1234567890^SMITH^SALLY^S|| 

|||1234ad~455sd||PMC^Sanofi^MVX|||CP |<CR>

VXU Example #10—Recording Birth Information 
Appendix B 30

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

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-6--Birth Information Fields 

Field HL7 message Component Example

Birth date PID-7 19500512

Birth 

Registration 

Number

PID-3 (as one identifier in 

list)

12345^^^assigning 

authority^BR

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. If the reason is a non-potent dose, then this 

information may be included in an OBX. 

RXA|0|1|20091010||03^MMR^CVX|0.5|ML^^ISO+||||||||A23E1||MSD^^MVX|||PA<CR> 

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. When a message is sent, it can indicate when an 

acknowledgement is expected. The choices may include always, only on error or never. 

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. 
Appendix B 31

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

Send acknowledgement of success in ACK 

Some systems may wish to receive an acknowledgment message, regardless of whether 

the receiving system had problems with the message. In that case, there is a relatively 

straightforward response. 

MSH|^~|&|DCS|MYIIS|MYIIS||20090604||ACK^V04^ACK|9299381|P|2.5.1|||ER<CR>

MSA|AA|9299381<CR> 

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. DCS only wants an acknowledgement if MYIIS encounters an 

error in processing the acknowledgement. 

Send Error in ACK 

When there are errors, these can either be fatal or non-fatal. Fatal errors indicate that 

the message that was sent was not able to be processed. Non-fatal means that the 

message that was sent had some type of error, which did not prevent the message from 

being processed. Some data may have been lost as a result of the error. In addition, the 

error may have been in the processing of the HL7 or violation of a local business rule. 

Acknowledging A Fatal HL7 Processing Error: 

There are a number of problems that may cause a fatal error when processing an HL7 

message that are based on HL7 rules. These include missing required segments. If a 

required field is missing, then the segment is treated as missing. If this is a required 

segment, then the error becomes fatal. 

MSH|^~|&|DCS|MYIIS|MYIIS||20090604||ACK^V04^ACK|9299381|P|2.5.1|||ER<CR> 

MSA|AR|9299381<CR> 

ERR||PID^5|101^required field missing^HL70357|E<CR> 

ERR||PID|100^required segment missing^HL70357|E<CR> 

In the example message above, we see that the PID-5 (patient name) field was missing. 

Since this is a required field in a PID, the PID is ignored and therefore is missing. 

Note that local violation of local business rules may by returned in an acknowledgement 

message. Those rules are best represented in codes that are referenced in a local table. 

These may be recorded in the ERR segment. A local business rule may lead to rejection 

of parts or all of a message. For instance, a local business rule may state that the system 

requires a first name for every person. If no first name is included in the message, then 

the system rejects the field for name (PID-5). Since this is a required field in a required 

message, the entire message is rejected. There would be a third ERR segment indicating 

that a locally required component was missing. (No example is given, as there is no 

local table of errors in this appendix. 
Appendix B 32

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

Acknowledging A Non-Fatal HL7 Processing Error: 

A non-fatal error may occur for a number of reasons. One example would occur when a 

non-required component or field is malformed. For instance, Last Update Date is not a 

required field. If the message indicated that the last update occurred on February 31, 

2009, then that field would be ignored. Since the field is not required, the segment 

would not be rejected. 

Local business rules should specify what will occur for each type of error. In the case 

above, the field could be ignore, it could be accepted and flagged for further follow-up , 

the entire message could be rejected or the bad data could be stored in the data base 

as. 

MSH|^~|&|DCS|MYIIS|MYIIS||20090604||ACK^V04^ACK|9299381|P|2.5.1|||ER 

MSA|AE|9299381 

ERR||PID^33|207^application internal error^HL70357|I 

The example above indicates that an error occurred in PID-33 (last updated date). It did 

not cause the message to be rejected. 

Send Request for Vaccine 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. This Implementation Guide replicates the functionality of the 

VXQ/VXX/VXR query and responses. 

Description of the VXQ/VXX/VXR Process From Version 2.3.1 

The following describes the process that was used when responding to a VXQ and is 

included to give background. As described in the use cases in Chapter 2 of this Guide, 

requesting an immunization history requires the responding system to find a matching 

client. The old VXQ query required implicit identity resolution. That is, the responding 

system used locally defined methods to find a person and if exactly one high-confidence 

match was found, returned an immunization history. If lower confidence matches were 

found, it returned a list of clients with their identifiers (PID,NK1) for review by a person 

on the requesting system. If one of the candidates was selected and returned in a 

second VXQ, then the one high-confidence match is returned. The following diagram 

illustrates the flow. (The messages between systems are bolded arrows.) 
Appendix B 33

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

Figure 7--VXQ/VXX/VXR processes 

The receiving system applies locally defined search logic. There are 4 possible outcomes 

if the message is successfully processed: 

1. The search finds exactly one high confidence candidate client to return. 

a. Immunization history is returned. 

b. If sending system user may choose to accept the immunization history, 

the sending system follows local protocols for incorporating the new 

record. 

2. The search finds one or more candidate clients. 

a. Sending system user selects the one of interest and resends the VXQ with 

the more complete information. 

3. The search finds no candidates to return. 

a. An acknowledgement is returned to the sending system. 

4. The message is malformed and no query is processed. 

a. An acknowledgement is returned to the sending system. 

Step 2 is the step where the implicit identity resolution occurs. 
Appendix B 34

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

The newer QBP-style query allows identity resolution to be separated from request for 

content. This is accomplished using a two-step approach. It mirrors the flow of the VXQ 

when lower confidence candidates are found and returned. One industry standard for 

accomplishing this two-step approach is the Patient Demographic Query (profile by IHE). 

This Guide allows either exact replication of the VXQ/VXX/VXR approach or a two-step 

approach. The two-step process accomplishes the same goal as the old process, but 

separates the request for immunization history and the request for identity resolution. 

The two-step approach takes the results of the selection from the identity resolution 

and requests the immunization history for the selected person. Note that this two-step 

approach also facilitates interaction with a Master Patient index (MPI). 

This Guide and Appendix does NOT prescribe the search methods, so these should be 

described in a local profile or implementation guide. 

In addition, this guide does not define the meaning of exact matches. This needs to be 

specified locally. 

Using QBP query to replicate VXQ/VXX/VXR 

The diagram for the new query is very similar to the previous diagram. The only real 

differences are the messages used. In place of the VXQ, a Request Immunization History 

query (QBP^Q11^QBP_Q11) is sent. It has an MSH-21, profile id of Z34^CDCPHINVS. In 

place of a VXX, a Return Candidate List response is returned (profile id of 

Z31^CDCPHINVS). In place of a VXR, a Return Immunization History response is 

returned (profile id of Z32^CDCPHINVS). 
Appendix B 35

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

Figure 8--Request Immunization History 

1. The process for sending a query requesting an Immunization history begins with 

the sending system building the message. 

2. The sending system connects to the receiving system and sends the query 

message. 

3. The receiving system accepts the message. 

4. The receiving system parses the message and validates. 

a. Determine if message meets HL7 rules 
Appendix B 36

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

b. Validate based on local business rules54

5. Seek matching client in receiver data base55

a. No match is found 

b. Exactly one match is found. 

c. One or more inexact matches and less than maximum plus 1 allowed56

matches found. 

d. More than the maximum allowed matches found. 

e. One or more clients are found, but they do not want their records shared. 

6. The receiving system responds (see below). 

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 

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 User reviews and accepts 

o User reviews and rejects 

o Requesting system accepts and marks for review. 

 A list of candidates are returned 

o User reviews and selects one 

· New QBP is sent using the identifying information from the RSP 

list 

o User reviews and rejects all 

· User creates a new query with more or different information 

o Requesting system accepts and stores the list for later review. 

The following is an example query using the QBP^Q11 query profile specified in the 

Implementation Guide. 

 

54 The process for responding is documented below. 

55 Each case will be detailed below. Note that this is an area that should clearly be documented 

by each system in a local profile or implementation guide. 

56 This maximum may be set by the sending system and may be determined by the receiving 

system. The maximum will be the smaller of the two. 
Appendix B 37

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

MSH|^~\&|||||||QBP^Q11^QBP_Q11|793543|P|2.5.1|||||||||Z34^CDCPHINVS <CR> 

QPD| Z34^Request Immunization History^CDCPHINVS 

|37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050512|M|10 East Main 

St^^Myfaircity^GA^^^L<CR> 

RCP|I|5^RD^HL70126|R^real-time^HL70394<CR> 

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) 

Note that PID-1, Set Id, is required when returning a list of PID. 

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|20091105||RSP^K11^RSP_K11|37374859|P|2.5.1|||||||||Z31^CDC

PHINVS<CR> 

MSA|AA|793543<CR> 

QAK|37374859|AA<CR> 

QPD| Z34^Request Immunization History^CDCPHINVS 

|37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050512|M|10 East Main 
Appendix B 38

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

St^^Myfaircity^GA^^^L<CR 

PID|1||99445566^^^MYStateIIS^SR||Child^Robert^^^^^L||20050512|M<CR> 

NK1||Child^Susan|MTH^Mother^HL70063|^^Myfaircity^GA<CR> 

PID|2||123456^^^MYStateIIS^SR||Child^Robert^^^^^L||20050512|M<CR> 

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|20091130||RSP^K11^RSP_K11|7731029|P|2.5.1|||||||||Z32^CDCPHINVS<CR> 

MSA|AA|793543<CR> 

QAK|37374859|OK| Z34^Request Immunization History^CDCPHINVS <CR> 

QPD| Z34^Request Immunization History^CDCPHINVS 

|37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050512|M|10 East Main 

St^^Myfaircity^GA^^^L<CR 

PID|1||123456^^^MYEHR^MR||Child^Robert^Quenton^^^^L|Que^Suzy^^^^^M|||||10 East Main St^^Myfaircity^GA<CR> 

PD1||||||||||||N|20091130<CR> 

NK1|1|Child^Suzy^^^^^L|MTH^Mother^HL70063<CR> 

PV1||R||||||||||||||||||V03^20091130<CR> 

ORC|RE||142324567^YOUR_EHR|||||||^Shotgiver^Fred||^Orderwriter^Sally^^^^^^^^^^^^^^^^^^MD<CR> 

RXA|0|1|20050725||03^MMR^CVX|0.5|ML^^ISO+||^New Immunization Record^NIP001<CR> 

RXR|SC^^HL70162<CR> 

Note that the response returned the medical record number from the MYEHR system. It 

could also have returned the IIS id. This is a policy decision set locally. 

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. 
Appendix B 39

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

QAK-2 indicates that no data were found that matched the query parameters. 

MSH||MYIIS|MyStateIIS||MYEHR|20091130||RSP^K11^RSP_K11|7731029|P|2.5.1|||||||||Z34^Request Immunization 

History^CDCPHINVS<CR> 

MSA|AE|793543<CR> 

QAK|37374859|NF|Z34^request Immunization history^CDCPHINVS<CR> 

QPD| Z34^Request Immunization History^CDCPHINVS 

|37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050512|M|10 East Main 

St^^Myfaircity^GA^^^L<CR> 

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|20091130||RSP^K11^RSP_K11|7731029|P|2.5.1|||||||||Z34^Request Immunization 

History^CDCPHINVS <CR> 

MSA|AE|793543<CR> 

QAK|37374859|TF|Z34^request Immunization history^CDCPHINVS<CR> 

QPD| Z34^Request Immunization History^CDCPHINVS 

|37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050512|M|10 East Main 

St^^Myfaircity^GA^^^L<CR> 
Appendix B 40

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

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. 

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). 
Appendix B 41

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

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. 

 

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. 
Appendix B 42

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

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. 

The diagrams illustrating the PIX Query and Patient Demographics Query (PDQ) 

approaches share similar flow to the original VXQ message. PIX Query followed by a 

Request Immunization History using the retrieved identifier is similar to a VXQ/VXR. 

PDQ followed by an Request Immunization History replicates a VXQ/VXX and 

VXQ/VXR.57

 

The following illustrates one of the above-described messages, the Patient 

Demographics Query. For examples of other messages, IHE documentation should be 

consulted. 

MSH|^~\&| MYIIS|MyStateIIS|SOME_SYSTEM|A_Clinic |20091105||QBP^Q22^ ||P|2.5.1||||||||| <CR> 

 

57 It is possible that even with the two-step process, an exact match may not be found for the 

record of interest. This is especially true if the source of identity resolution is not exactly in synch 

with the source of the immunization history. Local rules should dictate the response to this 

situation. 
Appendix B 43

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

QPD|^IHE PDQ Query^ 

|37374859|@PID.3.1^123456~@PID.3.4^MYEHR~@PID.3.5^MR~@PID.5.1.1^Child~@PID.5.2^Bobbie~@PID.5.3^Q 

~@PID.6.1.1^Que~@PID.6.2^Suzy ~@PID.7^20050512~@PID.8^M~@PID.11.1.1^10 East Main 

St^~@PID.11.3^Myfaircity~@PID.11.4^GA <CR> 

RCP|I|5^RD^HL70126|R^real-time^HL70394<CR> 

Note that the intent of the Quantity Limited Request differs from its use in the Request 

Immunization History query. Here it means send me batches of 5 records until you have 

sent them all. In the Request Immunization History query it means return a list of up to 

five clients, but if you find more, then send me an error indicating too many records 

found. 

Returning a list of candidate clients in response to PDQ query 

The response to a PDQ query is very similar to that of a Request for Immunization 

History query which finds lower confidence matches. The most significant differences 

include: 

 No NK1 is returned. MPIs implementing the Pediatric Demographics Option 

use Mother's Maiden name in the PID segment to provide equivalent value 

in patient record matching.

 If more than the maximum records are found they are returned in batches of up 

to the maximum records specified in the query 

 Potential use of DSC segment to support return of batches of records 

The following example shows a return similar to the response message returned by the 

request for immunization history query (above). Note that in both cases, the response 

message returns all information that it knows about each client in the segments 

required for each response. 

MSH|^~\&|SOME_SYSTEM|A_Clinic|MYIIS|MyStateIIS|20091105||RSP^K22^ |37374859|P|2.5.1||||||||| <CR> 

MSA|AA|793543<CR> 

QAK|37374859|AA<CR> 

QPD|^IHE PDQ Query^ 

|37374859|@PID.3^123456^^^MYEHR^MR~@PID.5^Child^Bobbie^Q^^^^L~PID.6^Que^Suzy^^^^^M~@PID.7^20050512

@PID.8^M~@PID.11^10 East Main St^^Myfaircity^GA^^^L~@PID.18^<CR> 

PID|1||99445566^^^MYStateIIS^SR||Child^Robert^^^^^L||20050512|M<CR> 

PID|2||123456^^^MYStateIIS^SR||Child^Robert^^^^^L||20050512|M<CR> 

Using PIX in preparation for reporting an Immunization Record to an IIS 

In the case where an IIS participates in an MPI, the EHR may use a PIX Query to retrieve 

the IIS identifier from the MPI prior to sending an immunization record to the IIS. 
Appendix B 44

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

In the case where the IIS identifier is returned by the MPI, the VXU message sent to the 

IIS may contain the IIS ID 

A user may believe that a candidate does exist and may choose to refine the query 

parameters and re-query. 

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. 

The following examples illustrate how each is reported. 

Malformed Query: 

Initiating Query: 

MSH|^~\&|||||||QBP^Q11^QBP_Q11|793543|P|2.5.1|||||||||Z34^CDCPHINVS. <CR> 

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<CR> 

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|MyStateIIS||MYEHR|20091130||RSP^K11^RSP_K11|7731029|P|2.5.1||||||||| Z34^Request Immunization 

History^CDCPHINVS <CR> 

MSA|AE|7731029<CR> 

ERR||QPD^1^2|101^required field missing^HL70357|E<CR> 

QAK||AE|Z34^request Immunization history^CDCPHINVS<CR> 

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<CR> 

Note that QAK-1 Query tag is empty in this case, because it was missing in the initiating 

query. 

Malformed message 

When a malformed message is received, the response is an ACK with AR in the MSA-1 

(Acknowledgement Code) 

MSH|^~\&|MYIIS|MyStateIIS||MYEHR|20091130||ACK||P <CR> 
Appendix B 45

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.4)

Last Updated on 8/1/2012

MSA|AR|<CR> 

This message indicates that the application rejected the message. 

Receiving System Business Rule Errors 

Fatal Error: 

Date sent in a required field is not legitimate (February 30, 2009) 

Non-fatal error: 

No Match Is Found 

If no match is found, then the receiving system sends a response that indicates that the 

message was accepted and found no data. Note that this might occur if one client was 

found, but does not want his/her data shared with a different provider. 

MSH|^~\&|MYIIS|MyStateIIS||MYEHR|20091130||RSP^K11^RSP_K11|7731029|P|2.5.1|||||||||| 

MSA|AA|7731029<CR> 

QAK|37374859|NF|Z34^request Immunization history^PHINVS<CR> 

QPD|Z34^Request Immunization 

History^HL70471|37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050512|M|10 East Main 

St^^Myfaircity^GA^^^L<CR>