HL7 Version 2.5.1

Implementation Guide  

for Immunization Messaging

Release 1.2

02/15/2011

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

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

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:  www.hl7.org  

For information about the American

Immunization Registry Association, visit  

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:

www.cdc.gov/vaccines/programs/iis/default.htm
Table of Contents

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

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

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

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

INTRODUCTION TO DIAGRAMS AND MODELS ............................................................ 5

ACTOR AND USE CASE DIAGRAMS AND TABLES ............................................ 5

SEQUENCE DIAGRAMS ................................................................................. 6

ACTIVITY DIAGRAMS .................................................................................... 7

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

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

ACTORS AND GOALS .............................................................................................. 9

USE CASE DESCRIPTIONS ..................................................................................... 14

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

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

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

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

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

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

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

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

USE CASE 8--ACKNOWLEDGE RECEIPT ...................................................... 22

USE CASE 9—REPORT ERROR .................................................................. 23

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

3. HL7 MESSAGING INFRASTRUCTURE ................................................................................ 26

BASIC MESSAGE CONSTRUCTION RULES .............................................................. 28

HL7 DEFINITIONS .................................................................................................. 26

ENCODING RULES FOR SENDING................................................................ 28

ENCODING RULES FOR RECEIVING ............................................................. 29

IMPLICATIONS OF THE ENCODING RULES .................................................... 29

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

MESSAGE ATTRIBUTES COMMON TO ALL MESSAGES ............................................ 35

SEGMENT ATTRIBUTES COMMON TO ALL SEGMENTS ............................................. 36

4. HL7 DATA TYPES ............................................................................................................. 38

CE -- CODED ELEMENT (MOST USES) ......................................................... 39

DATA TYPES FOR IIS USE ..................................................................................... 38

CE -- CODED ELEMENT (TEXT ONLY IN RXA-9) ........................................... 41

CQ -- COMPOSITE QUANTITY WITH UNITS .................................................. 41

CWE -- CODED WITH EXCEPTIONS ............................................................ 42

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

DT -- DATE ............................................................................................... 45

DTM -- DATE/TIME .................................................................................... 46

EI -- ENTITY IDENTIFIER ............................................................................. 46
ERL -- ERROR LOCATION .......................................................................... 47

FN -- FAMILY NAME ................................................................................... 49

FC -- FINANCIAL CLASS ............................................................................. 49

HD -- HIERARCHIC DESIGNATOR ................................................................ 50

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

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

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

MSG -- MESSAGE TYPE ............................................................................ 53

NM -- NUMERIC ......................................................................................... 54

PT -- PROCESSING TYPE ........................................................................... 54

SAD -- STREET ADDRESS .......................................................................... 55

SI -- SEQUENCE ID .................................................................................... 55

ST – STRING ............................................................................................. 56

TS -- TIME STAMP ..................................................................................... 56

VID -- VERSION ID ..................................................................................... 56

XAD -- EXTENDED ADDRESS ..................................................................... 57

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

EXTENDED PERSON NAME (XPN) .............................................................. 62

XTN - EXTENDED TELECOMMUNICATION NUMBER ...................................... 63

5. SEGMENTS AND MESSAGE DETAILS ................................................................................ 66

BHS FIELD DEFINITIONS............................................................................. 72

BHS—BATCH HEADER SEGMENT ......................................................................... 72

BTS—BATCH TRAILER SEGMENT ......................................................................... 73

BTS FIELD DEFINITIONS ............................................................................. 73

ERR—ERROR SEGMENT ...................................................................................... 73

ERR FIELD DEFINITIONS: ........................................................................... 75

EVN - EVENT TYPE SEGMENT ............................................................................... 76

EVN FIELD DEFINITIONS............................................................................. 76

FHS—FILE HEADER SEGMENT ............................................................................. 77

FHS FIELD DEFINITIONS ............................................................................. 77

FTS—FILE TRAILER SEGMENT ............................................................................. 78

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

MSA—MESSAGE ACKNOWLEDGEMENT SEGMENT ................................................ 79

MSA FIELD DEFINITIONS ............................................................................ 79

MSH—MESSAGE HEADER SEGMENT .................................................................... 80

MSH FIELD DEFINITIONS ............................................................................ 81

NK1—NEXT OF KIN SEGMENT .............................................................................. 86

NK1 FIELD DEFINITIONS ............................................................................. 89

NTE—NOTE SEGMENT ......................................................................................... 90

NTE FIELD DEFINITIONS ............................................................................. 90

OBX—OBSERVATION RESULT SEGMENT .............................................................. 90

OBX FIELD DEFINITIONS ............................................................................ 93

ORC—ORDER REQUEST SEGMENT ...................................................................... 95

ORC FIELD DEFINITIONS ............................................................................ 98

PD1—PATIENT DEMOGRAPHIC SEGMENT ........................................................... 100

PD1 FIELD DEFINITIONS ........................................................................... 102

PID—PATIENT IDENTIFIER SEGMENT................................................................... 104

PID FIELD DEFINITIONS ............................................................................ 108

PV1—PATIENT VISIT SEGMENT........................................................................... 111
PV1 FIELD DEFINITIONS ........................................................................... 114

QAK FIELD DEFINITIONS .......................................................................... 115

QAK—QUERY ACKNOWLEDGEMENT SEGMENT ................................................... 115

QPD – QUERY PARAMETER DEFINITION .............................................................. 116

QPD FIELD DEFINITIONS .......................................................................... 116

RCP – RESPONSE CONTROL PARAMETER SEGMENT ........................................... 117

RCP FIELD DEFINITIONS .......................................................................... 118

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

RXA FIELD DEFINITIONS........................................................................... 122

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

RXR FIELD DEFINITIONS .......................................................................... 126

6. MESSAGES FOR TRANSMITTING IMMUNIZATION INFORMATION ................................. 128

SEND IMMUNIZATION HISTORY--VXU ................................................................... 128

INTRODUCTION.................................................................................................... 128

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

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

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

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

............................................................................................................... 132

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

ACKNOWLEDGING A MESSAGE--ACK .................................................................. 132

SENDING MESSAGES IN A BATCH ........................................................................ 134

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

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

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

INTRODUCTION: ....................................................................................... 148

USE CASE: .............................................................................................. 149

STATIC DEFINITION .................................................................................. 150

SEGMENT LEVEL PROFILE ....................................................................... 152

FIELD LEVEL PROFILE .............................................................................. 152

DYNAMIC DEFINITION............................................................................... 153

ACKNOWLEDGEMENT RESPONSIBILITIES .................................................. 153

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

INTRODUCTION: ....................................................................................... 154

USE CASE: .............................................................................................. 154

STATIC DEFINITION .................................................................................. 156

SEGMENT LEVEL PROFILE ....................................................................... 157

FIELD LEVEL PROFILE .............................................................................. 158

DYNAMIC DEFINITION............................................................................... 158

CHANGE HISTORY DETAILS................................................................................................... 159

APPENDIX A: CODE TABLES................................................................................................... 1

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

SEND IMMUNIZATION HISTORY (VXU) ...................................................................... 2

IMMUNIZATION HISTORY DEFINITION ........................................................................ 1
BUSINESS PROCESS ............................................................................................... 2

SUPPORTED MESSAGE SEGMENTS .......................................................................... 5

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

EXAMPLE VXU #2 - INDICATE VACCINE FUNDING SOURCE AND CLIENT ELIGIBILITY 

STATUS: ................................................................................................................. 7

ELIGIBILITY STATUS: .................................................................................... 7

FUNDING SOURCE: ...................................................................................... 8

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

VXU ..................................................................................................................... 10

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

INDICATING VACCINE GROUP ASSOCIATED: ................................................ 15

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

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

REPORTING NEXT DOSE RECOMMENDATION DATES: .................................. 16

REPORTING RECOMMENDATION REASONS: ................................................ 17

USING THE NTE SEGMENT ASSOCIATED WITH AN OBX TO PROVIDE MORE 

INFORMATION: ........................................................................................... 17

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

EVIDENCE OF IMMUNITY: ............................................................................ 18

CONTRAINDICATIONS TO IMMUNIZATION: .................................................... 18

FACTORS WHICH INDICATE THE NEED FOR AN IMMUNIZATION OR A CHANGED 

RECOMMENDATION: ................................................................................... 19

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

EVENTS) ............................................................................................................... 19

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

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

(VIS) .................................................................................................................... 21

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

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

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

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

NON-POTENT DOSE................................................................................................ 23

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

SEND ACKNOWLEDGEMENT OF SUCCESS IN ACK ........................................ 24

SEND ERROR IN ACK ................................................................................ 24

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

PROCESS FOR REQUESTING IMMUNIZATION HISTORY.................................. 25

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

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

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

QUERY ...................................................................................................... 30

RETURNING AN IMMUNIZATION HISTORY IN RESPONSE TO A REQUEST FOR 

IMMUNIZATION HISTORY QUERY ................................................................. 31

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

ACKNOWLEDGING A QUERY THAT FINDS MORE CANDIDATES THAN REQUESTED

................................................................................................................. 32

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

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

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

MALFORMED MESSAGE .............................................................................. 37

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

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

Figure 1-2-Simple Sequence Diagram .................................................................. 7

Figure 1-1 Simple Use Case Diagram ................................................................. 6

Figure 1-3 Simple Activity Diagram ....................................................................... 8

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

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

Figure 2-2 Finding a Client .................................................................................. 14

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

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

Request and Accept Requested History ...................................................... 17

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

History ......................................................................................................... 18

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

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

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

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

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

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

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

Table 3-1--Usage Code Interpretations for Fields, Components and Subcomponents ................................................................................................. 31

Table 3-3--Message Attributes ............................................................................ 35

Table 3-2--Usage Code Interpretation for Segments .......................................... 34

Table 3-4--Segment Attributes ............................................................................ 36

Table 4-1-- Data Types ....................................................................................... 39

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

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

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

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

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

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

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

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

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

Table 4-11 Financial Class (FC) ......................................................................... 49

Table 4-12 Family Name .................................................................................... 50

Table 4-13 Hierachical Designator (HD) ............................................................. 50

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

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

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

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

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

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

Table 4-20 Sequence Id (SI) ............................................................................... 56
Table 4-21 Time Stamp (TS) .............................................................................. 56

Table 4-23 Extended Address (XAD) .................................................................. 57

Table 4-22 Version ID (VID) ................................................................................ 56

Table 4-24 Extended Composite ID Number and Name (XCN) .......................... 59

Table 4-25 Extended Person Name (XPN) ......................................................... 62

Table 4-26 XTN Extended Telecommunication Number (XTN) .......................... 63

Table 5-1 Message Segments ............................................................................ 66

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

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

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

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

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

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

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

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

Table 5-10 Message Types ................................................................................ 83

Table 5-11-Next of Kin Segment (NK1) .............................................................. 87

Table 5-12 Note Segment (NTE) ........................................................................ 90

Table 5-13 Observation Segment (OBX) ............................................................ 91

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

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

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

Table 5-17-Patient Visit (PV1) .......................................................................... 112

Table 5-18-Query Acknowledgement Segment ................................................ 115

Table 5-19-Query Parameter Definition (QPD) ................................................. 116

Table 5-20-Response Control Parameter ......................................................... 118

Table 5-21 Pharmacy/Treatment Administration (RXA) .................................... 120

Table 5-22 Pharmacy/Treatment Route (RXR) ................................................. 126

Table 6-1-Supported Messages ........................................................................ 128

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

Figure 6-1-VXU Domain Diagram ..................................................................... 130

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

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

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

Table 6-6-ADT A04 Message ........................................................................... 134

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

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

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

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

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

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

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

................................................................................................................... 147

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

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

Table 7-9 Response Grammar RSP^K11 ......................................................... 150
Figure 7-2 Return Candidate List (RSP^K11) ................................................... 153

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

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

Figure 7-5 Return Immunization History Sequence Diagram ............................ 158

Table 40--Release 1.1 Changes ....................................................................... 159

Table 41--Release 1.2 Changes ....................................................................... 159

Table 41-Immunization History Definition ............................................................. 1

Figure 6-VXU Business Process ........................................................................... 3

Figure 7-Segment Usage ...................................................................................... 6

Figure 8--VXQ/VXX/VXR processes ................................................................... 26

Figure 9--Request Immunization History ............................................................. 28
Chapter 1: Introduction 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

1

1. Introduction 

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

immunization related information. They receive and share data on individual

clients/patients 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. This implementation

guide will replace the existing Implementation Guide for Immunization Data Transaction

Using Version 2.3.1 of the HL7 Standard Protocol, and will be based on HL7 Version

2.5.1, as published by the HL7 organization (www.hl7.org). The existing 2.3.1 Guide has

a number of successful implementations that exchange messages with other IIS and

EHR‐S. The experience of these implementations has identified a number of areas of the

existing Guide that would benefit from an update of the Guide.

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.

The benefits from moving to 2.5.1 should encourage migration to this standard.  

Implementations that are supporting Version 2.3.1 messages should continue to follow

the specifications of 2.3.1 messages described in the Implementation Guide Version 2.2,

June 2006.  

Intended Audience

This Guide has two audiences. The first is the system managers that must understand

this process at a high level. The second is the technical group from IIS and EHR‐S that

must implement these guidelines. For them we strive for an unambiguous specification

for creating and interpreting messages. Our goal is for this Guide to be a bridge between

the two.  
Chapter 1: Introduction 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

2

2

                                                      

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 systems1

. 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

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

• the 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.

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.

The Guide is meant to support and integrate with standards harmonization efforts.

These efforts include the Health Information Standards Panel (HITSP), HITSP has

selected a number of items which support interoperability between health systems.

Among these is selection of preferred vocabulary. This Guide will adopt these standard

vocabularies as they apply. Another effort, which promotes standards harmonization, is

1

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

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

1/31/2011

3

his Guide makes the following assumptions:  

te and secure information exchange

formation through either an EHR‐S or

ed at an appropriate level.  

ta

t contains

ed to be documented locally.  

is important to be able to accept complete immunization histories from different

an organization called Integrating the Healthcare Enterprise (IHE)3

. They produce

profiles, which define how to accomplish various goals with common components.  

T

• Infrastructure is in place to allow accura

between information systems. 4

• Providers access immunization in

immunization information system (IIS).  

• Privacy and security has been implement

• Legal and governance issues regarding data access authorizations, da

ownership and data use are outside the scope of this document.  

• The immunization record and demographic record for each patien

sufficient information for the sending system to construct the immunization and

demographic message properly.  

• External business rules are assum

It

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

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

ts

T

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 se

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.

                                                      

3

 IHE is an industry-supported group, which creates implementable specifications, based on 

existing standards, to support accomplishment of selected use cases. 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.2) 

1/31/2011

4

s the business motivations that this Guide will support. It will

escribe the entities (actors) that will rely on the messages. It will lay out the

(use cases). Finally, it will

HL7

essaging. It will illustrate the components of messages, the grammatical rules for

Chapter 1‐Introduction

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

includes a description of the diagrams that will be used to illustrate business processes

and transactions.

Chapter 2‐Actors, Goals and Messaging Transactions

Chapter 2 describe

d

transactions that will support the goals of these actors

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

m

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

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

5

grams to illustrate the transactions and their

omponents. These include Use Case model, Sequence Diagram and Activity Diagram.

These are based on the Unified Modeling Language (UML). The illustrations below are

in the appropriate sections later in the

formation systems or components of information systems that produce,

anage, or act on categories of information required by operational activities in the

enterprise. In our context, use cases are tasks or goals that actors use to communicate

s‐based messages. The diagrams and tables

or

eir relationship. The diagram below shows 2 actors that use the Send

munization History Use Case. In this use case we see that both IIS and EHR‐S use the

Appendix B‐ Message examples

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

in the body of the Implementation Guide.

Introduction to Diagrams and Models

This document makes use of models or dia

c

examples only. Detailed models will be found

document.

Actor and Use Case Diagrams and Tables  

Actors are in

m

the required information through standard

of actors and transactions in subsequent sections indicate which transactions each act

performs.  

The use cases shown on the diagrams are identified by their name. Supporting text will

define the goal of a use case. The actors associated with each use case will be included

and show th

Im

Send Immunization History use case. It does not imply that the IIS sends an

immunization history to an EHR‐S.
Chapter 1: Introduction 

Figure 1-1 Simple Use Case Diagram 

Sequence Diagrams  

The descriptions of the use cases that follow include sequence diagrams that illustrate

how the use case is accomplished as a sequence of transactions between relevant

actors.  

These diagrams are intended to provide an overview so the transactions can be seen in

the context of the participating institution’s workflows. These diagrams are not

intended to present the only possible scenario, just those required to accomplish the

goals of communicating between information systems.  

In some cases the sequence of transactions may be flexible. Where this is the case there

will generally be a note pointing out the possibility of variations. Transactions are shown

as arrows oriented according to the flow of the primary information handled by the

transaction. In the diagram below we see that one system (it could be IIS or EHR‐S)

sends an immunization record to another system. The message sent is a VXU

(Unsolicited Update of Immunization Record). The receiver processes the message and

sends an acknowledgment of the receipt. The processing is not part of the messaging

and may vary from application to application. The acknowledgement could be as simple

as “I got it, all is OK” or “The message has errors and I can’t accept it”

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

6
Chapter 1: Introduction 

Figure 1-2-Simple Sequence Diagram 

Activity Diagrams

Activity diagrams are another way of showing what is happening within systems and

between systems. They are most useful for showing the decision logic used. The

diagram includes “swim‐lanes”, which separate the tasks of cooperating systems. The

purpose of the following diagram is to illustrate the components of an activity diagram,

not to design a system.

In this case, the sending system sends a VXU. The receiving system parses the message

and decides what to do with it. We assume that parsing was successful to simplify this

diagram. There are a number of decisions that are made and each leads to an action or

actions. The diamonds represent decision points. In the first decision point, the system

branches follows different paths, depending on the results of the client search. If no

matches are found, it follows its local process for integrating a new record into the data

base. If a lower confidence match is found (for instance, more than one client matches

the incoming record) it follows local business rules for the situation. If a high confidence

match is found, it follows local business rules for merging the incoming data into an

existing client record. All actions then move to acknowledge the results of the activity.  

The actual activity of a real system may be very different from this.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

7
Chapter 1: Introduction 

Figure 1-3 Simple Activity Diagram 

Note that the focus of this guide is on the format and grammar of the messages

between systems. The activities shown within a system are intended to put the message

in context and to highlight the local responsibilities for successful messaging.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

8
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

9

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

1/31/2011

10

• 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

Electronic Health

Record system (EHR‐

S)

House a person’s electronic

health record

Make a person’s record

available to authorized

persons

Receive immunization

histories and updates

Receive demographic updates

Receive requests for individual
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

11

Actor Responsibility Messaging Goals

Provide decision support for

clinical decisions.

records

Send immunization records to

IIS

Send demographic data  

Receive observations about a

person

Send observations about a

person

Request Immunization record

Request person id

Acknowledge receipt of

message

Report processing errors from

receipt of message

Request evaluation on an

immunization history and

recommendations for next

dose on a given Schedule, such

as ACIP

Master Person Index

or other identity

broker.

Maintain a list of patients and

identifiers for a set of persons

Supply identifiers for other

system’s use

Be a central demographic

supplier for participating

systems

Provide cross‐reference for

identifiers for participating

systems.

Send id for an individual for

use in a record request or

record update

Receive request for person id.

Return complete demographic

data for an individual from

central demographic store

The table lists a number of messaging needs that relate to IIS and their trading partners.

These are all candidates for HL7 messaging. Some are not currently implemented, but
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

12

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.

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

Figure 2-1 Use Case Diagram 

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.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

13
Chapter 2: Actors, Goals and Messaging Transactions 

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 

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

immunization history.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

14
Chapter 2: Actors, Goals and Messaging Transactions 

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.

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

query with a new VXQ. The approach outlined in this Guide allows this process to be

followed using different messages.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

15
Chapter 2: Actors, Goals and Messaging Transactions 

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. 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

16
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

17

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

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.  

                                                      

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 

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.

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

Requesting an Immunization History Using Implicit Identity Resolution 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

18
Chapter 2: Actors, Goals and Messaging Transactions 

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.

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.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

19
Chapter 2: Actors, Goals and Messaging Transactions 

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.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

20
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

21

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

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.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

22
Chapter 2: Actors, Goals and Messaging Transactions 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

23

                                                      

Use Case 9—Report Error   

Scope: 

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

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.

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

successfully processed.

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

1/31/2011

24

                                                      

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 

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.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

25
Chapter 3: HL7 Messaging Infrastructure 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

26

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.

HL7 definitions

The terms below are organized to move from the message to subsequently more

granular components.

Message: A message is the entire unit of data transferred between systems in a single

transmission. It is a series of segments in a sequence defined by the message

specifications. These specifications are based on constraints to the HL7 specifications, as

described in an Implementation Guide.

Example:

Segment Description

MSH|... Message Header

PID|... Personal Identifiers

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 maximum length of the field is stated as normative information.

Exceeding the listed length should not be considered an error. A field is bounded by the

| character.
Chapter 3: HL7 Messaging Infrastructure 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

27

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 

Item number: Each field is assigned a unique item number. Fields that are used in more

than one segment will retain their unique item number across segments.

Null and empty fields: The null value is transmitted as two double quote marks (“”). A

null‐valued field differs from an empty field. An empty field should not overwrite

previously entered data in the field, while the null value means that any previous value

in this field should be overwritten.  

Value in Field Meaning 

“” 

|””| 

Nullify the value recorded in the receiving system data base. 

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

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

28

\ = 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.

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

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

29

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.  

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

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

30

Condition Immediate Outcome Secondary Outcome

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.

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 but may be empty12.

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.

                                                      

12 In some cases they may not be empty. Client name may never be empty or null, for instance. 
Chapter 3: HL7 Messaging Infrastructure 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

31

6. All other fields will be left optional.

Table 3-1--Usage Code Interpretations for Fields, Components and Sub-components 

Usage Code Interpretation Comment

R Required A conforming sending application shall populate all

“R” elements with a  

non‐empty value.  

Conforming receiving application shall process or

ignore the information conveyed by required

elements.  

A conforming receiving application must not raise

an error due to the presence of a  

required element, but may raise an error due to

the absence of a required element.  

RE Required but may

be empty

The element may be missing from the message,

but must be sent by the sending application if

there is relevant data.  

A conforming sending application must be capable

of providing all "RE" elements. If the  

conforming sending application knows the

required values for the element, then it must send

that element. If the conforming sending  

application does not know the required values,

then that element will be omitted.  

Receiving applications will be expected to process

or ignore data contained in the element, but must

be able to successfully process the message if the

element is omitted (no error message should be

generated  

because the element is missing).  
Chapter 3: HL7 Messaging Infrastructure 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

32

Usage Code Interpretation Comment

C Conditional This usage has an associated condition predicate.

This predicate is an attribute within the message.

If the predicate is satisfied:  

A conformant sending application must always

send the element.  

A conformant receiving application must process

or ignore data in the element. It may raise an error

if the element is not present.  

If the predicate is NOT satisfied:  

A conformant sending application must NOT send

the element.  

A conformant receiving application must NOT raise

an error if the condition predicate is false and the

element is not present, though it may raise an

error if the element IS present.  
Chapter 3: HL7 Messaging Infrastructure 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

33

Usage Code Interpretation Comment

CE Conditional but

may be empty

This usage has an associated condition predicate.

This predicate is an attribute within the message.  

If the predicate is satisfied:

If the conforming sending application knows the

required values for the element, then the

application must send the element.  

If the conforming sending application does not

know the values required for this element,  

then the element shall be omitted. The

conforming sending application must be capable

of knowing the element (when the predicate is

true) for all ‘CE’ elements.  

If the element is present, the conformant receiving

application shall process or ignore the values of

that element. If the element is not present.  

The conformant receiving application shall not

raise an error due to the presence or absence of

the element.  

If the predicate is not satisfied:

The conformant sending application shall not

populate the element.  

The conformant receiving application may raise an

application error if the element is present.

O Optional This element may be present if specified in local

profile. Local partners may develop profiles that

support use of this element. In the absence of a

profile, conformant sending applications will not

send the element.  

Conformant receiving applications will ignore the

element if it is sent, unless local profile specifies

otherwise. Conformant receiving applications may

not raise an error if it receives an unexpected

optional element.

X Not Supported The element is not supported. Sending

applications should not send this element.

Receiving applications should ignore this element

if present. A receiving application may raise an
Chapter 3: HL7 Messaging Infrastructure 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

34

Usage Code Interpretation Comment

error if it receives an unsupported element. Any

profile based on this Guide should not specify use

of an element that is not supported in this Guide.

Elements that are optional or are not supported for use in immunization messages will

be noted in the element table, but not in the element definition text that follow.

Table 3-2--Usage Code Interpretation for Segments 

Usage Code Interpretation Comment

R Required A conforming sending application shall include all

“R” segments.  

Conforming receiving application shall process all

required segments.  

A conforming receiving application must process

all required segments. It should raise an error due

to the absence of a required  

segment.  

RE Required but may

be empty

The segment may be missing from the message,

but must be sent by the sending application if

there is relevant data.  

A conforming sending application must be capable

of providing all "RE" segments. If the  

conforming sending application has data for the

required segment, then it must send that

segment.  

Receiving applications will be expected to process

the data contained in the segment. It must be able

to successfully process the message if the segment

is omitted (no error message should be generated

because the segment is missing).  

O Optional This segment may be present if specified in local

profile. Local partners may develop profiles that

support use of this segment. In the absence of a

profile, conforming sending applications will not

send the element. Conformant receiving

applications will ignore the element if it is sent,

unless local profile specifies otherwise.
Chapter 3: HL7 Messaging Infrastructure 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

35

Usage Code Interpretation Comment

X Not Supported The segment is not supported. Sending

applications should not send this element.

Receiving applications should ignore this element

if present. Any profile based on this Guide should

not specify use of an element that is not

supported in this Guide.

Message Attributes Common to All Messages

The following describe how message specifications will be illustrated in this Guide.

These terms will be used in the tables specifying messages throughout this Guide.

Table 3-3--Message Attributes 

Message Attributes

Attribute Description

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

Segment

Name Name of the Segment or Segment group element.

Usage

Usage of the segment. Indicates if the segment is required,

optional, or not supported in a message. See table with Usage

Code Interpretation above.

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 it can have at most, one

Cardinality

                                                      

13 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.2) 

1/31/2011

36

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.

Segment Attributes Common to All Segments

The abbreviated terms and their definitions, as used in the segment table headings, are

as follows:

Table 3-4--Segment Attributes 

Abbreviation Description

Seq Sequence of the elements (fields) as they are numbered in the segment

Recommended maximum length of the element. Lengths are provided

only for primitive data types.  

Len Lengths should be considered recommendations, not absolutes. The

receiver may truncate fields, components, and sub‐components longer

than the recommended length. The receiver should not fail to process a

message simply because fields, components, or sub‐components are too

long.

Data Type Data type used for HL7 element. Data type specifications can be found in

Chapter 4.

Indicates whether the field is supported in this Guide. Indicates if the

field, component, or subcomponent is required, optional, or conditional

in the corresponding segment, field, or component. See Usage Code

Interpretation, above.

Usage

Note: A required field in an optional segment does not mean the

segment must be present in the message. It means that if the segment is

present, the required fields within that segment must be populated. The

same applies to required components of optional fields. If the field is

populated, then the required component must be populated. The same

applies to required sub‐components of optional components. If a

component is populated, the required sub‐components of that

component must also be populated.
Chapter 3: HL7 Messaging Infrastructure 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

37

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.

Item # Unique item identifier in HL7

HL7 Element

Name HL7 descriptor of the element in the segment.

Comment Lists any constraints imposed and other comments in this Guide

Abbreviation Description
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 38

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

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 39

Table 4-1-- Data Types 

Data type Data Type Name 

CE Coded element 

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 

FC Financial Class 

FN Family Name 

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 

XPN Extended Person Name 

XTN Extended telephone number 

CE ‐‐ Coded Element (most uses)

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

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

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 40

Table 4-2 Coded Element (CE) 

SEQ LEN 

Data 

Type Usage 

Value 

Set 

Component 

Name Comments 

1 999 ST RE Identifier Identifying Code. 

2 999 ST CE Text 

Human readable text that is not 

further used. If Sequence 1 is 

populated, this should also be 

populated. 

3 20 ID C 0396 Name of Coding 

 If sequence 1 is populated, this 

field must be populated. 

4 999 ST RE 

Alternate 

Identifier 

 Alternate Identifying coded. 

5 999 ST CE Alternate Text 

Human readable text that is not 

further used. If Sequence 4 is 

populated, this should also be 

populated. 

6 20 ID C 0396 

Name of 

Alternate 

 If sequence 4 is populated, this 

field must be populated. 

Note: Sequence 1,2, and 3 are one triplet that are treated as a unit. The other triplet is a separate unit. 

Either may be populated, but should mean the same thing if both are populated. 

The order of the contents is not specified. In the previous guide, the first triplet was reserved for CVX 

codes in RXA-5. This is no longer true, based on HL7 usage of CE data type. 

Identifier (ST) 

Definition: Sequence of characters (the code) that uniquely identifies the item being referenced. 

Different coding schemes will have different elements here. 

Text (ST) 

Definition: The descriptive or textual name of the identifier, e.g., DTaP. This is not used by the 

sending or receiving system, but rather facilitates human interpretation of the code. 

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

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 41

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

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

SEQ LEN 

Data 

Type Usage 

Value 

Set 

Component 

Name Comments 

1 999 ST X Identifier 

2 999 ST R Text 

Human readable text that is not 

further processed. 

3 20 ID X 0396 Name of Coding 

4 999 ST X 

Alternate 

Identifier 

5 999 ST X Alternate Text 

6 20 ID X 

HL7039

0396 

Name of 

Alternate 

Note: Sequence 1,2, and 3 are one triplet that are treated as a unit. The other triplet is a separate unit. 

Either may be populated, but should mean the same thing if both are populated. 

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

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 42

Table 4-4 Composite Quantity with Units (CQ) 

SEQ LEN Data 

Type 

Usage Value 

set 

COMPONENT NAME COMMENTS 

1 16 NM R Quantity The value shall be a positive 

integer. 

2 CE R 0126 Units The value shall be RD 

(records). 

 

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.2) 1/31/2011 43

Table 4-5 Coded with Exceptions (CWE) 

SEQ LEN 

Data 

Type Usage 

Value 

Set Component Name Comments 

1 999 ST RE Identifier Identifying Code. 

2 999 ST CE Text 

Human readable text that is not 

further used. If Sequence 1 is 

populated, this should also be 

populated. 

3 20 ID CE 0396 Name of Coding 

 If sequence 1 is populated, this 

field must be populated. 

4 999 ST RE Alternate Identifier Alternate Identifying code. 

5 999 ST CE Alternate Text 

Human readable text that is not 

further used. If Sequence 4 is 

populated, this should also be 

populated. 

6 20 ID CE 0396 Name of Alternate 

 If sequence 4 is populated, this 

field must be populated. 

7 10 ST O Coding System 

Version Id 

8 10 ST O Alternate Coding 

System Version Id 

9 199 ST O Original Text 

Note: Sequences 1,2 and 3 are one triplet that are treated as a unit. The other triplet is a separate unit. 

Either may be populated, but should mean the same things if both are populated. 

The order of the contents is not specified. In the previous guide, the first triplet was reserved for CVX 

codes in RXA-5. This is no longer true, based on HL7 usage of CE data type. 

Identifier (ST) 

Definition: Sequence of characters (the code) that uniquely identifies the item being referenced. 

Different coding schemes will have different elements here. 

Text (ST) 

Definition: The descriptive or textual name of the identifier, e.g., DTaP. This is not used by the 

sending or receiving system, but rather facilitates human interpretation of the code. 

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

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 44

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

Type 

Usage Value set COMPONENT 

NAME 

COMMENTS 

1 15 ST R ID Number 

2 1 ST O Check Digit 

3 3 ID CE 0061 Check Digit 

Scheme 

If sequence 2 is populated, 

then this sequence must be 

populated. 

4 HD R 0363 Assigning Authority 

5 5 ID R 0203 Identifier Type 

Code 

6 HD O Assigning Facility 

7 8 DT O Effective Date 

8 8 DT O Expiration Date 

9 CWE O Assigning 

Jurisdiction 

10 CWE O Assigning Agency 

or Department 

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

detail. 

Maximum Length: 1913 

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

Example: 

|1234567^^^ME129^MR| 
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 45

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. 

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

Data 

Type Usage 

Value 

Set 

Component 

Name Comments 

1 8 R Date 

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| 

                                                      

14 OIDs are object identifiers. According to wikipeida: “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.2) 1/31/2011 46

DTM ‐‐ Date/Time  

Table 4-8 Date/Time (DTM) 

SEQ LEN 

Data 

Type Usage 

Value 

Set 

Component 

Name Comments 

24 R Date/time 

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. 

EI ‐‐ Entity Identifier  

Definition: The entity identifier defines a given entity within a specified series of identifiers. 

Table 4-9 Entity Identifier (EI) 

SEQ LEN Data 

Type 

Usage Value 

Set 

COMPONENT 

NAME 

COMMENTS 

1 199 ST RE Entity Identifier 

2 20 IS C 0363 Namespace ID If Universal Id is not populated, then this field 

shall be populated. 

3 199 ST CE Universal ID If Namespace ID is not populated, then this 

field shall be populated. When populated, it 

shall be an OID. 

4 6 ID C 0301 Universal ID Type If Universal Id is populated, this field must also 

be populated. When populated, it shall be 

constrained to ISO. 

Maximum Length: 427 
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 47

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|

ERL ‐‐ Error Location

  

Table 4-10 Error Location (ERL) 

SEQ LEN Data 

Type

Usage Value Set COMPONENT NAME COMMENTS

1 3 ST R Segment ID The 3-character name 

for the segment (i.e. 

PID) 

2 2 NM R Segment Sequence

3 2 NM RE Field Position This should not be 

populated if the error 

refers to the whole 

segment. 

4 2 NM RE Field Repetition This should be 

populated whenever 

Field Position is 

populated. 

5 2 NM RE Component Number Should be populated 

ONLY when a particular 

component cause the 

error. 
Chapter 4: HL7 Data Types 

6 2 NM RE Sub-Component Number Should be populated 

ONLY when a particular 

sub-component cause 

the error. 

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

Maximum Length: 18 

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. 

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. 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 48
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 49

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

FC ‐‐ Financial Class  

Definition: This data type identifies the financial class a person belongs to.

Table 4-11 Financial Class (FC) 

SEQ LEN Data 

Type 

Usage Value 

Set 

COMPONENT NAME COMMENTS 

1 20 IS R 0064 Financial Class Code 

2 TS RE Effective Date 

Maximum Length: 47 

Financial Class Code (IS) 

This component contains the financial class assigned to a person. User-defined Table 0064 - 

Financial class is used as the HL7 identifier for the user-defined table of values for this 

component. 

Effective Date (TS) 

This component contains the effective date/time of the person’s assignment to the financial class 

specified in the first component. For instance, this is used to indicate when a person’s financial 

class was determined. 

Example from PV1: |V01^20090101|

FN ‐‐ Family Name  

Definition: This data type contains a person’s family name or surname.
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 50

Table 4-12 Family Name 

SEQ LEN Data 

Type 

Usage Value 

Set 

COMPONENT NAME COMMENTS 

1 50 ST R Surname 

2 20 ST O Own Surname Prefix 

3 50 ST O Own Surname 

4 20 ST O Surname Prefix From 

Partner/Spouse 

5 50 ST O Surname From Partner/Spouse 

Surname (ST) 

This is the person's last name. 

Example from PID: |Anyperson|

HD ‐‐ Hierarchic Designator  

HITSP is recommending the use of OIDs in fields using this data type. 

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-13 Hierachical Designator (HD) 

SEQ LEN Data Usage Value Set COMPONENT COMMENTS 

Type NAME 

1 20 IS CE 0300

0361 

0362 

0363 

Namespace ID This field is used for a locally 

defined name/id. It may be used 

as previous version 2.3.1 

Implementation Guide 

specified. If the field or 

component is required, then this 

field shall be populated if 

components 2 and 3 are not 

populated. The value set used 

depends on usage. 
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 51

SEQ LEN Data 

Type 

Usage Value Set COMPONENT 

NAME 

COMMENTS 

2 199 ST CE Universal ID This field shall be populated if 

component 3 is populated. This 

field must be populated if field 1 

is empty. This field shall used 

OID if populated 

3 6 ID CE 0301 Universal ID Type This field shall be populated if 

component 2 is populated. If 

populated the value is 

constrained to 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 user-defined 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. 

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.

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

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 52

example of an ID field is PID 24 –Multiple Birth Indicator. This data type should be used only for 

HL7 tables (see Appendix A). 

Example from PID Multiple Birth Indicator:

|Y|

IS ‐‐ Coded Values for User Defined Tables  

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

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

SEQ Length Data 

Type 

Usage Value Sets COMPONENT NAME COMMENTS 

20 

(Max.) 

Coded Value for User-Defined 

Tables 

Maximum Length: 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 (see 

Section 2.5.3.6 - Table). 

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 

1 20 IS O 0302 Point of Care This represents the location 

within a facility that the service 

was provided. This is not the 

clinic site where an event 

occurred. 

2 20 IS O 0303 Room 

3 20 IS O 0304 Bed 

4 HD RE Facility This represents the location 

that the service was provided. 

For example the clinic. 

5 20 IS O 0306 Location Status 

6 20 IS O 0305 Patient Location 

Type 

LEN Data 

Type

Usage Value 

Sets 

COMPONENT 

NAME 

COMMENTS 
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 53

SEQ LEN Data 

Type 

Usage Value 

Sets 

COMPONENT 

NAME 

COMMENTS 

7 20 IS O 0307 Building 

8 20 IS O 0308 Floor 

9 120 ST O Street Address 

10 120 ST O Other Designation 

11 50 ST O City 

12 50 ST O State or Province 

13 12 ST O Zip or Postal Code 

14 3 ID O 0399 Country 

15 3 ID O 0190 Address Type 

16 50 ST O Other Geographic 

Designation 

Maximum Length: 790 

Note: Replaces the CM data type used in 4.14.5.13 RXD-13, 4.14.6.11 RXG-11 and 4.14.7.11 RXA-11 as 

of V 2.5. 

MSG ‐‐ Message Type  

Definition: This field contains the message type, trigger event, and the message structure ID for 

the message. 

Table 4-16 Message Type (MSG) 

SEQ LEN Data 

Type 

Usage Value Set COMPONENT NAME COMMENTS 

1 3 ID R 0076 Message Code 

2 3 ID R 0003 Trigger Event 

3 7 ID R 0354 Message Structure 

Maximum Length: 15. 

Note: Replaces the CM data type used in 2.16.9.9 MSH-9 as of v 2.5. 

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

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 54

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.

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

Type 

Usage Value 

Set 

COMPONENT NAME COMMENTS 

16 Numeric 

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

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 55

 

Table 4-18 Processing Type (PT) 

SEQ LEN Data 

Type 

Usage Value Set COMPONENT NAME COMMENTS 

1 1 ID R 0103 Processing ID 

2 1 ID X 0207 Processing Mode Constrain to empty, 

which implies 

current processing. 

Maximum Length: 3 

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. 

SAD ‐‐ Street Address  

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

 

Table 4-19 Street Address (SAD) 

SEQ LEN Data 

Type 

Usage Value 

Set 

COMPONENT NAME COMMENTS 

1 120 ST R Street or Mailing Address 

2 50 ST O Street Name 

3 12 ST O Dwelling Number 

Maximum Length: 184 

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

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 56

 

Table 4-20 Sequence Id (SI) 

SEQ LEN Data 

Type 

Usage Value set COMPONENT NAME COMMENTS 

4 Sequence ID 

Maximum Length: 4. This allows for a number between 0 and 9999 to be specified. 

ST – String

Definition: 

String data is left justified with trailing blanks optional. Any displayable (printable) ACSII 

characters (hexadecimal values between 20 and 7E, inclusive, or ASCII decimal values between 

32 and 126), except the defined escape characters and defined delimiter characters. 

TS ‐‐ Time Stamp  

Definition: Specifies a point in time. 

 

Table 4-21 Time Stamp (TS) 

SEQ LEN Data 

Type 

Usage Value Set COMPONENT NAME COMMENTS 

1 24 DTM R Time 

2 1 ID X 0529 Degree of Precision 

Maximum Length: 26 

Time (DTM) 

Definition: The point in time. 

VID ‐‐ Version Id  

Definition: This specifies the HL7 version.

 

Table 4-22 Version ID (VID) 

SEQ LEN Data 

Type 

Usage Value Set COMPONENT NAME COMMENTS 

1 5 ID R 0104 Version ID 

2 CE O 0399 Internationalization Code 

3 CE O International Version ID 
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 57

Maximum Length: 973 

Version ID (ID) 

Used to identify the HL7 version. Refer to HL7 Table 0104 – Version ID in section 2.15.9.12 for 

valid values. 

XAD ‐‐ Extended Address  

Definition: This data type specifies the address of a person, place or organization plus associated 

information. 

 

Table 4-23 Extended Address (XAD) 

SEQ LEN Data 

Type 

Usage Value 

Sets 

COMPONENT NAME COMMENTS 

1 SAD RE Street Address 

2 120 ST RE Other Designation 

3 50 ST RE City 

4 50 ST RE State or Province 

5 12 ST RE Zip or Postal Code 

6 3 ID O 0399 Country Empty defaults to 

USA 

7 3 ID R 0190 Address Type 

8 50 ST O Other Geographic 

Designation 

9 20 IS O 0289 County/Parish Code 

10 20 IS O 0288 Census Tract 

11 1 ID O 0465 Address Representation Code 

12 DR X Address Validity Range deprecated as of v 

2.5 

13 TS O Effective Date 

14 TS O Expiration Date 

Maximum Length: 631 

Note: Replaces the AD data type as of v 2.3. 
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 58

Example of usage for US: 

|1000 Hospital Lane^Ste. 123^Ann Arbor ^MI^99999^^B| 

This would be formatted for postal purposes as 

1000 Hospital Lane 

Ste. 123 

Ann Arbor MI 99999 

Street Address (SAD) 

Definition:This is the street address. 

Other Designation (ST) 

Definition: Second line of address. In US usage, it qualifies address. Examples: Suite 555 or 

Fourth Floor. This can be used for dwelling number. 

City (ST) 

Definition: This component specifies the city, or district or place where the addressee is located 

depending upon the national convention for formatting addresses for postal usage. 

State or Province (ST) 

Definition: This component specifies the state or province where the addressee is located. State 

or province should be represented by the official postal service codes for that country. 

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.2) 1/31/2011 59

Effective Date (TS) 

Definition: The first date, if known, on which the address is valid and active. 

Expiration Date (TS) 

Definition: The last date, if known, on which the address is valid and active. 

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. 

Table 4-24 Extended Composite ID Number and Name (XCN) 

SEQ LEN DT Usage TBL# COMPONENT NAME COMMENTS 

1 15 ST C ID Number If name fields below are not 

populated, then this field 

must be populated. 

2 FN RE Family Name 

3 30 ST RE Given Name 

4 30 ST RE Second and Further 

Given Names or Initials 

Thereof 

5 20 ST O Suffix (e.g., JR or III) 

6 20 ST O Prefix (e.g., DR) 

7 5 IS X 0360 Degree (e.g., MD) Use Professional suffix in 

sequence 21. 

8 4 IS O 0297 Source Table Since we are requiring 

assigning authority, this field 

may be left empty. 

9 HD C 0363 Assigning Authority If the id field is populated, 

then this field must be 

populated. 

10 1 ID O 0200 Name Type Code If the name fields are 

populated and this is empty, 

then the type defaults to L, 

legal name. 

11 1 ST O Identifier Check Digit 
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 60

SEQ LEN DT Usage TBL# COMPONENT NAME COMMENTS 

12 3 ID C 0061 Check Digit Scheme If check digit identifier is 

populated, then this field 

must indicate the check digit 

scheme. 

13 5 ID O 0203 Identifier Type Code Constrain to values in the 

published HL7 table 0203 

only. 

14 HD O Assigning Facility 

15 1 ID O 0465 Name Representation 

Code 

16 CE O 0448 Name Context 

17 DR X Name Validity Range 

18 1 ID X 0444 Name Assembly Order 

19 TS O Effective Date 

20 TS O Expiration Date 

21 ST O Professional Suffix 

22 CWE O Assigning Jurisdiction 

23 CWE O Assigning Agency or 

Department 

Maximum Length: 3002 

Note: Replaces CN data type as of v 2.3. 

This data type is used where there is a need to specify the ID number and name of a person. 

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

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 61

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. 

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. 

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 Check Digit (ST) 

The check digit in this data type is not an add-on produced by the message processor. It is the 

check digit that is part of the identifying number used in the sending application. If the sending 

application does not include a self-generated check digit in the identifying number, this 

component should be valued empty. 

Check Digit Scheme (ID) 

Definition: Contains the code identifying the check digit scheme employed. 

Refer to HL7 Table 0061 - Check digit scheme for valid values. 

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

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 62

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. 

Extended Person Name (XPN)

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

Table 4-25 Extended Person Name (XPN) 

SEQ LEN Data 

Type 

Usage Value Sets COMPONENT NAME COMMENTS 

1 FN R Family Name 

2 30 ST R Given Name 

3 30 ST RE Second and Further 

Given Names or Initials 

Thereof 

4 20 ST O Suffix (e.g., JR or III) 

5 20 ST O Prefix (e.g., DR) 

6 6 IS X 0360 Degree (e.g., MD) Use Professional suffix in 

sequence 14 

7 1 ID RE 0200 Name Type Code 

8 1 ID O 0465 Name Representation 

Code 

9 CE O 0448 Name Context 

10 DR X Name Validity Range 

11 1 ID O 0444 Name Assembly Order 

12 TS O Effective Date 

13 TS O Expiration Date 

14 199 ST O Professional Suffix 

Maximum Length: 1103 

Note: Replaces PN data type as of v 2.3. 
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 63

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. 

XTN ‐ Extended Telecommunication Number

Definition: This contains the extended telephone number.

Table 4-26 XTN Extended Telecommunication Number (XTN) 

SEQ LEN Data 

Type 

Usage Value 

Set 

COMPONENT NAME COMMENTS 

1 199 ST X Telephone Number Deprecated as

of 2.3 

2 3 ID R 0201 Telecommunication Use

Code 

3 8 ID RE 0202 Telecommunication

Equipment Type 

4 199 ST CE Email Address If the 

telecommunicati

on type code is 

NET, then this 

field shall be 

populated. 

5 3 NM O Country Code 
Chapter 4: HL7 Data Types 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 64

SEQ LEN Data 

Type 

Usage Value 

Set 

COMPONENT NAME COMMENTS 

6 5 NM CE Area/City Code If the 

telecommunicati

on type code is 

not NET, then 

this field shall be 

populated. 

7 9 NM CE Local Number If the 

telecommunicati

on type code is 

not NET, then 

this field shall be 

populated. 

8 5 NM O Extension 

9 199 ST O Any Text 

10 4 ST O Extension Prefix 

11 6 ST O Speed Dial Code 

12 199 ST O Unformatted Telephone 

number 

Maximum Length: 850 

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

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 65

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. 

Extension (NM) 

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

5. Segments and Message Details This chapter will contain specifications for each segment used. It will indicate which fields are supported or reqany constraints on these fields. Chapter 6 will then address how these building blocks are assembled into specif

meet the use cases listed in Chapter 2.

Table 5-1 Message Segments 

Segment(Name/Role)

Definition Message Usage Usage Note

BHS(Batch HeaderSegment)

The Batch Header Segment wraps

a group of 1 or more messages.These may be a mixture ofacceptable message types. This

segment is not required for real‐

time messaging. That is, a streamof messages may be sent without

a BHS. A system may choose to

require BHS for all groups ofmessages, but should specify this

requirement in a local

implementation Guide.

Any Optional Used at the beginning 

messages.

BTS(Batch TrailerSegment)

The BTS segment defines the end

of a batch. It is required if the

message has a matching BHS.

Any Required if

messagestarts withBHS.

Used to mark the end 

messages. If the batc

starts with a BHS, the

required.

ERR(ErrorSegment)

The error segment reports

information about errors in

processing the message. The

segment may repeat. Each error

ACK, RSP Ability to

create andprocess is

required for

Used to return inform

errors.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

Segment Definition Message Usage Usage Note(Name/Role)

will have its’ own ERR segment. conformant

systems.

EVN(EventSegment)

The EVN segment is used to

communicate necessary trigger

event information to receivingapplications. Valid event types for

all chapters are contained in HL7Table 0003 ‐ Event Type

ADT Required for

ADTmessage.

Used to convey event 

information.

FHS(File HeaderSegment)

The file header segment may be

used to group one or morebatches of messages. This is a

purely optional segment, even if

batches are sent. Its’ use is not

anticipated for use in real‐timetransactions. Any system thatanticipates its use should specify

this in a local implementation

Guide.

Any Optional Used to mark the beg

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 ofbatches.(Matches

FHS)

Used to mark the end 

batches. If a file of ba

at the beginning, then 

required.

IN1‐3(InsuranceSegment)

The IN1‐IN3 segments containinsurance policy coverage

information necessary to produce

VXU Optional This segment is not a

in immunization messspecified for local use

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

Segment Definition Message Usage Usage Note(Name/Role)

properly pro‐rated and patient

and insurance bills.

MSA(Message

Acknowledgement Segment)

This segment is included in thequery response (RSP) andacknowledgment(ACK) messages. It containsinformation used to identify thereceiver’s acknowledgementresponse to an identified prior

message.

RSP, ACK Ability to

create andprocess isrequired forconformantsystems.

MSH(MessageSegmentHeader)

The MSH segment defines the

intent, source, destination, andsome specifics of the syntax of amessage.

All Ability to

create andprocess isrequired for

conformantsystems.

This begins every mes

includes information 

message, how to proc

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

required for

conformantsystems.

Used to carry informa

next of kin for a client

NTE(NoteSegment)

The NTE segment is used for

sending notes and comments. It is

used in relation to OBX in the VXU

and RSP.

VXU, ADT, RSP Ability to

create andprocess is

required for

conformant

Used to carry a note r

parent segment.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

Segment Definition Message Usage Usage Note(Name/Role)

systems.

OBX(ObservationResultSegment)

The observation result segment

has many uses. It carries

observations about the object ofits parent segment. In the

VXU/RSP it is associated with the

RXA or immunization record. Thebasic format is a question and ananswer.

ADT, VXU, RSP Ability to

create andprocess is

required forconformantsystems.

Used to report one at

observation.

ORC(Order RequestSegment)

The Common Order segment(ORC) is used to transmit fieldsthat are common to all orders (all

types of services that arerequested). 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 andprocess is

required forconformantsystems.

Used to give informat

group of one or more 

RXA).

PD1(PatientDemographicSegment)

The patient additionaldemographic segment containsdemographic information that is

likely to change about the patient.

In immunization messages, this is

information about the need to

protect the client’s information,how they should be part of

VXU, RSP, ADT Ability to

create andprocess is

required forconformantsystems.

Used to give informat

patient. A primary us

messages is to give in

privacy and whether allowed.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

Segment Definition Message Usage Usage Note(Name/Role)

reminder efforts and their current

status in the IIS.

PID(PatientIdentifierSegment)

This segment contains permanentpatient identifying anddemographic information that, for

the most part, is not likely to

change. Used by all applications

as the primary means of

communicating patientidentification information.frequently.

VXU, ADT, RSP Ability to

create andprocess is

required forconformantsystems.

Used to carry informa

patient/client.

PV1(Patient VisitSegment)

This segment contains

information related to a specific

visit.

VXU, ADT, RSP Ability to

create andprocess isrequired for

conformantsystems.

Used to carry informa

given visit. Used in im

messages to carry inf

client eligibility for va

sources.

QAK(Queryacknowledgement segment)

The QAK segment contains

information sent with responses

to a query.

RSP Ability to

create andprocess isrequired for

conformantsystems.

QPD Query parameter definition QBP, RSP Ability to

create andprocess is

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

Segment Definition Message Usage Usage Note(Name/Role)

required forconformantsystems.

RCP Response control parameter

segment

QBP Ability to

create andprocess is

required for

conformantsystems.

RXA Pharmacy/Treatment

Administration Segment

VXU, RSP Ability to

create andprocess is

required for

conformantsystems.

RXR Pharmacy/Treatment Route

Segment

VXU, RSP Ability to

create andprocess is

required for

conformantsystems.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

BHS—Batch Header Segment

Table 5-2 Batch Header Segment (BHS) 

SEQ LEN Data 

Type 

Cardinality Value 

set 

ITEM # ELEMENT NAME Usage Constraint 

1 1 ST [1..1] 00081 Batch Field Separator R The BHS.1 field 2 3 ST [1..1] 00082 Batch Encoding Characters R The BHS.2 field 3 HD [0..1] 00083 Batch Sending Application O 4 HD [0..1] 00084 Batch Sending Facility O 5 HD [0..1] 00085 Batch Receiving Application O 6 HD [0..1] 00086 Batch Receiving Facility O 7 TS [0..1] 00087 Batch Creation Date/Time O 8 40 ST [0..1] 00088 Batch Security O 9 20 ST [0..1] 00089 Batch Name/ID/Type O 10 80 ST [0..1] 00090 Batch Comment O 11 20 ST [0..1] 00091 Batch Control ID O 12 20 ST [0..1] 00092 Reference Batch Control ID O 

BHS field definitionsBHS-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 serves as the separator and defines the character to be used as a separator for the rest of the message. The requi124). Note that this field is different from other fields and immediately follows the Segment name code. BHS| 

⇑

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

separator 

BHS-2 Batch Encoding Characters (ST) 00082 

Definition: This field contains the four characters in the following order: the component separator, repetition separaand subcomponent separator. The required values are ^~\& (ASCII 94, 126, 92, and 38, respectively). 

BTS—Batch Trailer Segment

Table 5-3 Batch Trailer Segment (BTS) 

SEQ LEN Data 

Type 

Cardinality Value Set ITEM # ELEMENT 

NAME 

Usage Constr

1 10 ST [0..1] 00093 Batch Message 

Count 

O 

2 80 ST [0..1] 00090 Batch Comment O 3 100 NM [0..1] 00095 Batch Totals O 

BTS field definitions

BTS-1 - BTS-3 Not anticipated to be used for immunization messages. 

Example: BTS||ERR—Error SegmentNote that the ERR‐1 field is not supported in Version 2.5.1.It may continue to be used for versions 2.4 and earlier as specified in the earlier Implementation Guide. It is the be included in an ERR segment if the MSH indicates that the message with the error was a version prior to 2.5.HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

Table 5-4 Error Segment (ERR) 

SEQ LEN Data 

Type 

Cardinality Value 

Set 

ITEM # ELEMENT 

NAME 

Usage Constra

1 ELD [0..0] 00024 Error Code and 

Location 

X Not supp

2.5 and 

2 18 ERL [0..1]15 01812 Error Location RE If an erro

entire mmessagable.) thmeaningfield is le

3 CWE [1..1] 0357 01813 HL7 Error Code R 4 2 ID [1..1] 0516 01814 Severity R 5 CWE [0..1] 0533 01815 Application Error 

Code 

O 

6 80 ST [0..1] 01816 Application Error 

Parameter 

O 

7 2048 TX [0..1] 01817 Diagnostic 

Information 

O 

8 250 TX [0..1] 01818 User Message O This field 

text that to a usefor any f

9 20 IS [0..1] 0517 01819 Inform Person 

Indicator 

O 

10 CWE [0..1] 0518 01820 Override Type O 11 CWE [0..1] 0519 01821 Override Reason 

Code 

O 

15 This Guide does not support repeat of this field. It assumes that each error will be contained in one ERR segment. If the 

than once, there will be one ERR for each. 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

SEQ LEN Data Cardinality Value ITEM # ELEMENT Usage Constra

Type Set NAME 

12 XTN [0..1] 01822 Help Desk 

Contact Point 

O 

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 ha

repeats are allowed on this field. This field may be left empty if location is not meaningful. For example, if is unparseffect 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 Co

ERR-4 Severity (ID) 01814 

Definition: Identifies the severity of an application error. Knowing if something is Error, Warning or Information is intapplication handles the content. Refer to HL7 Table 0516 - Error severity for valid values. If ERR-3 has a value of "value of "I". 

ERR-5 Application Error Code (CWE) 01815 

Definition: Application specific code identifying the specific error that occurred. Refer to User-Defined Table 0533 – for suggested values. If the message associated with the code has parameters, it is recommended that the message be indicated in the f.text.MessageFormat approach16. This style provides information on the parameter type to allow numbers, dates a

formatted appropriately for the language. 

16 Details on MessageFormat can be found at http://java.sun.com/products/jdk/1.2/docs/api/java/text/MessageFormat.html. HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

ERR-6 Application Error Parameter (ST) 01816 

Definition: Additional information to be used, together with the Application Error Code, to understand a particular ercondition/warning/etc. This field can repeat to allow for up to 10 parameters. 

ERR-8 User Message (TX) 01818 

Definition: The text message to be displayed to the application user. This is not intended to be processed further by 

Example with error in PID:ERR||PID^1^5|101^Required field missing^HL70357^^^|E|EVN ‐ Event Type Segment

. 

Table 5-5 Event Segment (EVN) 

SEQ LEN Data Type Cardinality Value set ITEM# ELEMENT NAME Usage Co1 3 ID [0.. 1] 0003 00099 Event Type Code O 2 TS [1..1] 00100 Recorded Date/Time R 3 TS [0..1] 00101 Date/Time Planned Event O 4 3 IS [0..1] 0062 00102 Event Reason Code O 5 XCN [0..*] 0188 00103 Operator ID O 6 TS [0..1] 01278 Event Occurred O 7 HD [0..1] 01534 Event Facility O 

EVN field definitionsEVN-2 Recorded Date/Time (TS) 00100 

Definition: Most systems will default to the system date/time when the transaction was entered, but they should als

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

FHS—File Header Segment

Table 5-6 File Header Segment (FHS) 

SEQ LEN Data 

Type 

Cardinality Value 

Set 

ITEM # ELEMENT NAME Usage 

1 1 ST [1..1] 00067 File Field Separator R 2 4 ST [1..1] 00068 File Encoding 

Characters 

R 

3 HD [0..1] 00069 File Sending 

Application 

O 

4 HD [0..1] 00070 File Sending Facility O 5 HD [0..1] 00071 File Receiving 

Application 

O 

6 HD [0..1] 00072 File Receiving 

Facility 

O 

7 TS [0..1] 00073 File Creation 

Date/Time 

O 

8 40 ST [0..1] 00074 File Security O 9 20 ST [0..1] 00075 File Name/ID O 10 80 ST [0..1] 00076 File Header 

Comment 

O 

11 20 ST [0..1] 00077 File Control ID O 12 20 ST [0..1] 00078 Reference File 

Control ID 

O 

FHS field definitionsFHS-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 |. 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

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

Type 

Cardinality Value set ITEM # ELEMENT NAME Usage 

1 10 NM [0..1] 00079 File Batch Count O2 80 ST [0..1] 00080 File Trailer Comment O

IN1—Insurance Segment (IN2, IN3)

These segments are not anticipated for use in immunization messaging. They are not described or specified furthe

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

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

MSA—Message Acknowledgement Segment

Table 5-8 Message Acknowledgement Segment (MSA) 

SEQ LEN Data Type Cardinality Value 

Set 

ITEM # ELEMENT NAME Usage C

1 2 ID [1..1] 0008 00018 Acknowledgment Code R 2 20 ST [1..1] 00010 Message Control ID R 3 80 ST [0..1] 00020 Text Message O 4 15 NM [0..1] 00021 Expected Sequence 

Number 

O 

5 [0..1] 00022 Delayed 

Acknowledgment Type 

O 

6 CE [0..0] 0357 00023 Error Condition 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 - 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 senassociate this response with the message for which it is intended. This field echoes the message control id sent in system. 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

MSH—Message Header Segment

HL7 ATTRIBUTE TABLE - MSH - MESSAGE HEADER 

Table 5-9 Message Header Segment (MSH) 

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 TS [1..1] 00007 Date/Time Of 

Message 

R The degree of precision m

the minute, and the time included(format YYYYMMDDHHMM[SSZZZZ).

8 40 ST [0..1] 00008 Security O 9 15 MSG [1..1] 00009 Message Type R 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.1, 2.2, 2.3,2.3.1, 2.4,2.5.1 13 15 NM [0..1] 00013 Sequence Number O 14 180 ST [0..1] 00014 Continuation Pointer O 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

SEQ LEN Data Cardinality Value ITEM ELEMENT NAME Usage Constraint 

Type set # 

15 2 ID [0..1] 0155 00015 Accept 

Acknowledgement Type 

RE 

16 2 ID [0..1] 0155 00016 Application 

Acknowledgment Type 

RE AL-always, NE-Never, ER-Er

successful completion only 

17 3 ID [0..1] 0399 00017 Country Code O Use 3 character country cod

If is empty, assume USA 

18 16 ID [0..1] 0211 00692 Character Set O blank defaults to ASCII printa19 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 [0..*] 01598 Message Profile 

Identifier 

O This field will be required for 

Profile is being used. 

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 ch

serves as the separator and defines the character to be used as a separator for the rest of the message. Require

124).

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

Example:MSH|

MSH-2 Encoding Characters (ST) 00002 

Definition: This field contains the four characters in the following order: the component separator, repetition s

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 o

Appendix A, User‐defined table 0361. This is not the product, but rather the name of the specific instance. For 

Georgia(GRITS) is an instance based on the Wisconsin IIS (WIR). The code for GRITS would be specific to GRITS. 

defined codes may be added to accommodate local needs. The first component shall be the name space id fou

Table 0361, including local additions to this table. The second and third components are reserved for use of OI

MSH-4 Sending Facility (HD) 00004 

Definition: This field identifies the organization responsible for the operations of the sending application. Local

be added to accommodate local needs. The first component shall be the name space id found in User‐defined T

second and third components are reserved for use of OIDs or other universal identifiers.

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 

Appendix A, User‐defined table 0361. This is not the product, but rather the name of the specific instance. For 

Georgia(GRITS) is an instance based on the Wisconsin IIS (WIR). The code for GRITS would be specific to GRITS. 

defined codes may be added to accommodate local needs. The first component shall be the name space id fou

Table 0300. The second and third components are reserved for use of OIDs.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

MSH-6 Receiving Facility (HD) 00006 

Definition: This field identifies the organization responsible for the operations of the receiving application. Locabe added to accommodate local needs. The first component shall be the name space id found in User‐defined T

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 precis

to the minute. The time zone must be specified and will be used throughout the message as the default time zo

Note: This field was made required in version 2.4. Messages with versions prior to 2.4 are not required to valuusage supports backward compatibility.

MSH-9 Message Type (MSG) 00009 

Definition: This field contains the message type, trigger event, and the message structure ID for the message. R

0076 ‐ Message type for valid values for the message type code. This table contains values such as ACK, ADT, VX

following table lists those anticipated to be used by IIS.

Table 5-10 Message Types 

Transaction Message typeUnsolicited update of immunization record VXUUnsolicited update of demographic data ADTQuery to another system QBPResponse to query RSPRefer to HL7 Table 0003 ‐ Event type for valid values for the trigger event. This table contains values like A01, OHL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

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 

This identifier is unique within the scope of the sending facility (MSH.4), sending application (MSH.3), and the Y

message date (MSH.7). The receiving system echoes this ID back to the sending system in the Message acknow(MSA). The content and format of the data sent in this field is the responsibility of the sender. The receiver retu

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

Reference Table HL7 0103 in Appendix A. The choices are Production, Debugging and Training. In most cases, P 

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

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. Messages indica

shall follow the specifications in the 2.3.1 Guide.

MSH-15 Accept Acknowledgment Type (ID) 00015 

Definition: This field identifies the conditions under which accept acknowledgments are required to be returned message. Required for enhanced acknowledgment mode. Refer to HL7 Table 0155 ‐ Accept/application acknow

for valid values.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

Accept acknowledgement indicates if the message was safely received or not. It does not indicate successful pracknowledgement 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 retu

this message.Required for enhanced acknowledgment mode.

Note: If MSH‐15‐accept acknowledgment type and MSH‐16‐application acknowledgment type are omitted (or 

original acknowledgment mode rules are used. This means that, unless otherwise specified, the receiving applicacknowledgment 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

table has three separate forms of the country code: HL7 specifies that the 3‐character (alphabetic) form be use

code. If this field is not valued, then assume that the code is USA.

Refer to HL7 Table 0399 – Country code for the 3‐character codes as defined by ISO 3166‐1.

MSH-21 Message Profile Identifier (EI) 01598 

Definition: Sites may use this field to assert adherence to, or reference, a message profile. Message profiles con

explanations of grammar, syntax, and usage for a particular message or set of messages. Chapter 7 describes th

requesting an immunization history. It also includes child profiles that constrain the response to the query.

17 Available from ISO 1 Rue de Varembe, Case Postale 56, CH 1211, Geneve, Switzerland HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

This field will be required whenever a profile is being used to constrain the message.NK1—Next of Kin SegmentThe NK1 segment contains information about the patient’s other related parties. Any associated parties may be 

NK1‐1 ‐ set ID, multiple NK1 segments can be sent to patient accounts. That is, each subsequent NK1 incrementby 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 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

Table 5-11-Next of Kin Segment (NK1) 

SEQ LEN Data 

Type 

Cardinality Value 

set 

ITEM# ELEMENT NAME Usage C

1 4 SI [1..1] 00190 Set ID - NK1 R 2 XPN [1..*] 00191 Name R Th

this 

3 CE [1..1] 0063 00192 Relationship R 4 XAD [0..*] 00193 Address RE Th

shad

5 XTN [0..*] 00194 Phone Number RE Th

shph

6 XTN [0..*] 00195 Business Phone Number O 7 CE [0..1] 0131 00196 Contact Role O 8 8 DT [0..1] 00197 Start Date O 9 8 DT [0..1] 00198 End Date O 10 60 ST [0..1] 00199 Next of Kin / Associated 

Parties Job Title 

O 

11 JCC [0..1] 0327/ 

0328 

00200 Next of Kin / Associated 

Parties Job Code/Class 

O 

12 CX [0..1] 00201 Next of Kin / Associated 

Parties Employee Number 

O 

13 XON [0..1] 00202 Organization Name - NK1 O 14 CE [0..1] 0002 00119 Marital Status O 15 1 IS [0..1] 0001 00111 Administrative Sex O 16 TS [0..1] 00110 Date/Time of Birth O 17 2 IS [0..1] 0223 00755 Living Dependency O 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

SEQ LEN Data Cardinality Value ITEM# ELEMENT NAME Usage C

Type set 

18 2 IS [0..1] 0009 00145 Ambulatory Status O 19 CE [0..1] 0171 00129 Citizenship O 20 CE [0..1] 0296 00118 Primary Language O 21 2 IS [0..1] 0220 00742 Living Arrangement O 22 CE [0..1] 0215 00743 Publicity Code O 23 1 ID [0..1] 0136 00744 Protection Indicator O 24 2 IS [0..1] 0231 00745 Student Indicator O 25 CE [0..1] 0006 00120 Religion O 26 XPN [0..1] 00109 Mother’s Maiden Name O 27 CE [0..1] 0212 00739 Nationality O 28 CE [0..1] 0189 00125 Ethnic Group O 29 CE [0..1] 0222 00747 Contact Reason O 30 XPN [0..1] 00748 Contact Person’s Name O 31 XTN [0..1] 00749 Contact Person’s 

Telephone Number 

O 

32 XAD [0..1] 00750 Contact Person’s Address O 33 CX [0..1] 00751 Next of Kin/Associated 

Party’s Identifiers 

O 

34 2 IS [0..1] 0311 00752 Job Status O 35 CE [0..1] 0005 00113 Race O 36 2 IS [0..1] 0295 00753 Handicap O 37 16 ST [0..1] 00754 Contact Person Social 

Security Number 

O 

38 ST [0..1] 01905 Next of Kin Birth Place O 39 2 IS [0..1] 0099 00146 VIP Indicator O 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

NK1 field definitionsNK1-1 Set ID - NK1 (SI) 00190 

Definition: This field contains the number that identifies this transaction. For the first occurrence of the segment, the 

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

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 thmailing address must be sent in the first sequence. If the mailing address is not sent, then the repeat delimiter mussequence. 

NK1-5 Phone Number (XTN) 00194 

Definition: This field contains the telephone number of the next of kin/associated party. Multiple phone numbers arperson. The primary telephone number must be sent in the first sequence. If the primary telephone number is not sdelimiter must be sent in the first sequence. Refer to HL7 Table 0201 - Telecommunication Use Code and HL7 TabTelecommunication 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 nu

the same person. The primary business telephone number must be sent in the first sequence. If the primary telephthen the repeat delimiter must be sent in the first sequence. Refer to HL7 Table 0201 - Telecommunication Use Co- Telecommunication Equipment Type for valid values. 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

NK1-15 Administrative Sex (IS) 00111 

Definition: This is the sex of the next of kin. 

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 

relation to various segments. 

Table 5-12 Note Segment (NTE) 

SEQ LEN Data 

Type 

Cardinality Value 

Set 

ITEM # ELEMENT NAME Usage 

1 4 SI [0..1] 00096 Set ID - NTE O 2 8 ID [0..1] 0105 00097 Source of 

Comment 

O 

3 FT [1..1] 00098 Comment R 4 CE [0..1] 0364 01318 Comment Type O 

NTE field definitionsNTE-3 Comment (FT) 00098 

Definition: This field contains the comment contained in the segment. 

OBX—Observation Result SegmentThe observation result segment has many uses. It carries observations about the object of its parent segment. I

associated with the RXA or immunization record. The basic format is a question (OBX‐3) and an answer (OBX‐5)

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

Table 5-13 Observation Segment (OBX) 

SEQ LEN Data 

Type 

Cardinality Value Sets ITEM# ELEMENT NAME Usage Comment 

1 4 SI [1..1] 00569 Set ID – OBX R 2 2 ID [1..1] 0125 00570 Value Type R CE, NM, ST, 3 CE [1..1] 00571 Observation 

Identifier 

R This indicates 

observation rthe question by OBX-5. 

4 20 ST [0..1] 00572 Observation SubID RE 5 varies18 [1..1] 00573 Observation Value R This is the ob

and answers posed by OB

6 CE [0..1] 00574 Units CE If the observa

requires an inunits, they ar

7 60 ST [0..1] 00575 References Range O 8 5 IS [0..1] 0078 00576 Abnormal Flags O 9 5 NM [0..1] 00577 Probability O 10 2 ID [0..1] 0080 00578 Nature of Abnormal 

Test 

O 

11 1 ID [1..1] 0085 00579 Observation Result 

Status 

R Constrain to 

12 TS [0..1] 00580 Effective Date of 

Reference Range Values 

O 

18 The length of the observation field is variable, depending upon value type. See OBX-2 value type. HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

SEQ LEN Data Cardinality Value Sets ITEM# ELEMENT NAME Usage Comment 

Type 

13 20 ST [0..1] 00581 User Defined 

Access Checks 

O 

14 TS [1..1] 00582 Date/Time of the 

Observation 

R 

15 CE [0..1] 00583 Producer's 

Reference 

O 

16 XCN [0..1] 00584 Responsible 

Observer 

O 

17 CE [0..1] 00936 Observation 

Method 

O 

18 EI [0..1] 01479 Equipment 

Instance Identifier 

O 

19 TS [0..1] 01480 Date/Time of the 

Analysis 

O 

20 [0..1] Reserved for 

harmonization with V2.6 

O 

21 [0..1] Reserved for 

harmonization with V2.6 

O 

22 [0..1] Reserved for 

harmonization with V2.6 

O 

23 XON [0..1] 02283 Performing 

Organization Name 

O 

24 XAD [0..1] 02284 Performing 

Organization Address 

O 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

SEQ LEN Data Cardinality Value Sets ITEM# ELEMENT NAME Usage Comment 

Type 

25 XCN [0..1] 02285 Performing 

Organization Medical Director 

O 

OBX field definitionsOBX-1 Set ID - OBX (SI) 00569 

Definition: This field contains the sequence number. The first instance shall be set to 1 and each subsequent instannumber in sequence. 

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 

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). 3^Vaccine purchased with^LN|. In most systems the identifier will point to a master observation table that will provide other attributes of the observby the receiving system to process the observations it receives. This may be thought of as a question that the obse

example above, the question is “how was this immunization paid for” The answer in OBX-5 could be “Public Fundin

The 2.3.1 Implementation Guide used suffixes on the first sequence in OBX‐3 to group related observations. For instance, reporting a 

VIS receipt date each added a suffix of one LOINC code to a second LOINC code when recording VIS dates for a component vaccine. (3VACCINE INFORMATION STATEMENT PUBLISHED^LN) This is no longer acceptable. Grouping of related observations will be accomplisub‐id (OBX‐4).HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

OBX-4 Observation Sub-ID (ST) 00572 

Definition: This field is used to group related observations by setting the value to the same number. F

recording VIS date and VIS receipt date for a combination vaccination requires 6 OBX segments. Onindicate the vaccine group. It would have a pair of OBX indicating the VIS publication date and the V

These would have the same OBX-4 value to allow them to be linked. The second set of three would value common to each of them. This field may be used to link related components of an observation. Each component of the observation would sh

id. For example: OBX|1|LN|^observation 1 part 1^^^^^|1|... OBX|2|LN|^ observation 1 part 2^^^^^|1|... OBX|3|DT|^a different observation^^^^^|2|... Example: 

OBX|1|CE|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 STATEMENTPRESENTED^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 STATEMENTPUBLISHED^LN|2|19981216||||||F|<CR>HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

OBX|6|TS|29769‐7^DATE VACCINE INFORMATION STATEMENTPRESENTED^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 according to which observation value is formatted. This field contains the value of OBX-3-observation identifier of the same segment. Depending upon the observatio

a number (e.g., dose number), a coded answer (e.g., a vaccine), or a date/time (the date/time that the VIS was giv

An observation value is always represented as the data type specified in OBX-2-value type of the same segment. Wshort 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 a

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 approximathe observation. 

ORC—Order Request SegmentThe Common Order segment (ORC) is used to transmit fields that are common to all orders (all types of service

While not all immunizations recorded in an immunization message are able to be associated with an order, eac

associated with one ORC, based on HL7 2.5.1 standard.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

Table 5-14 Common Order Segment (ORC) 

SEQ LEN Data 

Type 

Cardinality Value Set ITEM# ELEMENT NAME Usage Comment 

1 2 ID [1..1] 0119 00215 Order Control R use RE 2 EI [0..1] 00216 Placer Order Number RE See Guidanc3 EI [1..1] 00217 Filler Order Number R See Guidanc4 EI [0..1] 00218 Placer Group 

Number 

O 

5 2 ID [0..1] 0038 00219 Order Status O 6 1 ID [0..1] 0121 00220 Response Flag O 7 TQ [0..0] 00221 Quantity/Timing X 8 EIP [0..1] 00222 Parent O 9 TS [0..1] 00223 Date/Time of 

Transaction 

O 

10 XCN [0..1] 00224 Entered By RE This is the pe

this immunizathe system. 

11 XCN [0..1] 00225 Verified By O 12 XCN [0..1] 00226 Ordering Provider RE This shall be 

ordering the iexpected to bimmunization transcribed frrecord. 

13 PL [0..1] 00227 Enterer's Location O 14 XTN [0..1] 00228 Call Back Phone 

Number 

O 

15 TS [0..1] 00229 Order Effective 

Date/Time 

O 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

SEQ LEN Data Cardinality Value Set ITEM# ELEMENT NAME Usage Comment 

Type 

16 CE [0..1] 00230 Order Control Code 

Reason 

O 

17 CE [0..1] 00231 Entering 

Organization 

O This is the pr

organization record/order. 

18 CE [0..1] 00232 Entering Device O 19 XCN [0..1] 00233 Action By O 20 CE [0..1] 0339 01310 Advanced 

Beneficiary Notice Code 

O 

21 XON [0..1] 01311 Ordering Facility 

Name 

O 

22 XAD [0..1] 01312 Ordering Facility 

Address 

O 

23 XTN [0..1] 01313 Ordering Facility 

Phone Number 

O 

24 XAD [0..1] 01314 Ordering Provider 

Address 

O 

25 CWE [0..1] 01473 Order Status Modifier O 26 CWE [0..1] 0552 01641 Advanced 

Beneficiary Notice Override Reason 

O 

27 TS [0..1] 01642 Filler's Expected 

Availability Date/Time 

O 

28 CWE [0..1] 0177 00615 Confidentiality Code O 29 CWE [0..1] 0482 01643 Order Type O 30 CNE [0..1] 0483 01644 Enterer Authorization 

Mode 

O 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

SEQ LEN Data Cardinality Value Set ITEM# ELEMENT NAME Usage Comment 

Type 

31 CWE [0..1] 02286 Parent Universal 

Service Identifier 

O 

ORC field definitionsORC-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 aand where the order was filled. They were originally designed for managing lab orders. These fields have a usagConditional in Version 2.5.1. The condition for each is that they must be present in either the OBR or ORC of a mbeen confusion about usage for these fields. The Orders and Observations workgroup has addressed this confuthat ORC will be used in Immunization messaging either ORC‐2 or ORC‐3 must be populated. They may both be In the immunization context, it is not common to have one system placing and one filling an immunization ordeneither is known. The use case that these have supported is to allow a system that sent an immunization record 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 SHAimmunization 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 Oessentially foreign keys exchanged between applications for uniquely identifying orders and the associated results 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

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 

This shall be the unique identifier of the sending system in a given transaction. In the case where system A sends t

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 recorddeletion of that record. In the case where a historic immunization is being recorded (i.e. from an immunization card), the sending system Sidentifier as if it were an immunization administered by a provider associated with the provider organization owning In the case where an RXA is conveying information about an immunization which was not given (e.g. refusal) the fibe 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 us

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 

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 ph

where this segment is associated with a historic immunization record and the ordering provider is not known, then 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 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 tthe clinic) 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

ORC-22 Ordering Facility Address (XAD) 01312 

Definition: This field contains the address of the facility requesting the order. 

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 special rules about who may see records for HPV vaccinations, then this field could convey that. The recommendecase 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 valuinformation must be protected, the person has stated that it must be protected. An empty field indicates that the cliespecified 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 SegmentThe Patient Demographic Segment contains patient demographic information that may change from time to tim

primary uses for in Immunization Messages. These include indicating whether the person wants his/her data pr

person wants to receive recall/reminder notices and the person’s current status in the registry.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

Table 5-15-Patient Demographic Segment (PD1) 

SEQ LEN Data 

Type 

Cardinality Value Set Item # ELEMENT NAME Usage Commen

1 2 IS [0..1] 0223 00755 Living Dependency O 2 2 IS [0..1] 0220 00742 Living Arrangement O 3 250 XON [0..1] 00756 Patient Primary Facility O 4 250 XCN [0..1] 00757 Patient Primary Care 

Provider Name & ID No. 

 O 

5 2 IS [0..1] 0231 00745 Student Indicator O 6 2 IS [0..1] 0295 00753 Handicap O 7 2 IS [0..1] 0315 00759 Living Will Code O 8 2 IS [0..1] 0316 00760 Organ Donor Code O 9 1 ID [0..1] 0136 00761 Separate Bill O 10 250 CX [0..1] 00762 Duplicate Patient O 11 250 CE [0..1] 0215 00743 Publicity Code RE 12 1 ID [0..1] 0136 00744 Protection Indicator RE 13 8 DT [0..1] 01566 Protection Indicator 

Effective Date 

CE If protect

valued, thshould be 

14 250 XON [0..1] 01567 Place of Worship O 15 250 CE [0..1] 0435 01568 Advance Directive Code O 16 1 IS [0..1] 

0441 

01569 Immunization Registry 

Status 

RE 

17 8 DT [0..1] 01570 Immunization Registry 

Status Effective Date 

CE If the reg

filled, thevalued. 

18 8 DT [0..1] 01571 Publicity Code Effective 

Date 

CE If the pub

filled then be valued

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

SEQ LEN Data Cardinality Value Set Item # ELEMENT NAME Usage Commen

Type 

19 5 IS [0..1] 0140 01572 Military Branch O 20 2 IS [0..1] 0141 00486 Military Rank/Grade O 21 3 IS [0..1] 0142 01573 Military Status O 

PD1 field definitionsPD1-3 Patient Primary Facility (XON) 00756 

Definition: This field contains the name and identifier that specifies the “primary care” healthcare facility selected by 

be specified locally. 

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

patient. In the context of immunization messages, this refers to how a person wishes to be contacted in a reminder 

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 others19. Specific protection polic

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 empty. There are 3 states: 

19 Local policies determine how data are protected. In general, it indicates who may view the client’s data. It may be as nar

that entered the information. 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

Protection State Code 

Yes, protect the data. Client (or guardian) has indicated that the information shall be protected. (Do not share data) 

Y 

No, it is not necessary to protect data from other clinicians. Client (or guardian) has indicated that the information does not need to be protected. (Sharing is OK) 

N 

No determination has been made regarding client’s (or guardian’s) wishes regarding information sharing 

PD1-12 is empty. 

Notes on use of Y for Protection Indicator in 2.5.1 Guide vs. earlier Guides. Note that the previous Implementation Guide stated that Y meant that a person’s information could be shared. This was an incouse of this field. The meaning now aligns with the definition of HL7. That is, Y means data must be protected. Existing systemwill 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 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. 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

PD1-16 Immunization Registry Status (IS) 01569 

Definition: This field identifies the current status of the patient in relation to the sending provider organization.. Refe0441 - Immunization Registry Status for suggested values. This field captures whether the sending provider organization considers this an active patient. There are several claThe status may be different between the sending and receiving systems. For instance, a person may no longer be organization, but may still be active in the public health jurisdiction, which has the Immunization Information System provider organization would indicate that the person was inactive in their system using this field in a message from indicate that person was active in a message from the IIS. 

PD1-17 Immunization Registry Status Effective Date (DT) 01570 

Definition: This field indicates the effective date for the registry status reported in PD1-16 - Immunization Registry S

PD1-18 Publicity Code Effective Date (DT) 01571 

Definition: This is the effective date for PD1-11 - Publicity Code. 

PID—Patient Identifier SegmentThe PID is used by all applications as the primary means of communicating patient identification information. Tpermanent patient identifying and demographic information that, for the most part, is not likely to change freqHL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

Table 5-16-Patient Identifier Segment (PID) 

SEQ LEN Data 

Type 

Cardinality Value Set ITEM# Element Name Usage Constrai

1 4 SI [0..1] 00104 Set ID - PID RE 2 CX [0..0] 00105 Patient ID X 3 CX [1..*] 00106 Patient Identifier List R 4 CX [0..0] 00107 Alternate Patient ID - 

00106 

X 

5 XPN [1..*] 00108 Patient Name R the first r

contain thMultiple ginitials arspaces. 

6 XPN [0..1] 00109 Mother’s Maiden Name RE 7 TS [1..1] 00110 Date/Time of Birth R Required

month, d

8 1 IS [0..1] 

0001 

00111 Administrative Sex RE M= male

not determinnown. 

9 XPN [0..0] 00112 Patient Alias X This field 

used. It earlier im

10 CE [0..*] 0005 00113 Race RE The first t

for the alsecond trdata type identifier, name of 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

SEQ LEN Data Cardinality Value Set ITEM# Element Name Usage Constrai

Type 

system) sgovernmnumeric c

11 XAD [0..*] 00114 Patient Address RE The first 

be the pr

12 4 IS [0..0] 0289 00115 County Code X County b

field. 

13 XTN [0..*] 00116 Phone Number - Home RE The first 

the primaOnly one per repet

14 XTN [0..1] 00117 Phone Number - 

Business 

O 

15 CE [0..1] 0296 00118 Primary Language O Use ISO 16 CE [0..1] 0002 00119 Marital Status O 17 CE [0..1] 0006 00120 Religion O 18 CX [0..1] 00121 Patient Account Number O 19 16 ST [0..0] 00122 SSN Number - Patient X 20 DLN [0..0] 00123 Driver's License Number 

- Patient 

X 

21 CX [0..0] 00124 Mother's Identifier X 22 CE [0..1] 0189 00125 Ethnic Group RE First triple

H,N,U if ptriplet shagovernmfrom tablIf both armust mat

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

SEQ LEN Data Cardinality Value Set ITEM# Element Name Usage Constrai

Type 

23 60 ST [0..1] 00126 Birth Place O Use may 

locally. 

24 1 ID [0..1] 0136 00127 Multiple Birth Indicator RE The acce

Y and N. undetermshall be e

25 2 NM [0..1] 00128 Birth Order CE If Multiple 

populated field shounumber iperson’s for the firfor the se

26 CE [0..1] 0171 00129 Citizenship O 27 CE [0..1] 0172 00130 Veterans Military Status O 28 CE [0..1] 0212 00739 Nationality O 29 TS [0..1] 00740 Patient Death Date and 

Time 

RE 

30 1 ID [0..1] 0136 00741 Patient Death Indicator CE If patient 

populatedshould be 

31 1 ID [0..1] 0136 01535 Identity Unknown 

Indicator 

O 

32 20 IS [0..1] 0445 01536 Identity Reliability Code O 33 TS [0..1] 01537 Last Update Date/Time O May be lo34 HD [0..1] 01538 Last Update Facility O Use is loc35 CE [0..1] 0446 01539 Species Code O 36 CE [0..1] 0447 01540 Breed Code O 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

SEQ LEN Data Cardinality Value Set ITEM# Element Name Usage Constrai

Type 

37 80 ST [0..1] 01541 Strain O 38 CE [0..1] 0429 01542 Production Class Code O 39 CWE [0..1] 0171 01840 Tribal Citizenship O 

PID field definitionsPID-1 Set ID - PID (SI) 00104 

Definition: This field contains the number that identifies this transaction. For the first occurrence of the segment, the 

shall be one, for the second occurrence, the sequence number shall be two, etc. 

PID-3 Patient Identifier List (CX) 00106 

Definition: This field contains the list of identifiers (one or more) used by the healthcare facility to uniquely identify a 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. Thcode 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 

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. 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

PID-8 Administrative Sex (IS) 00111 

Definition: This field contains the patient’s sex. Refer to User-defined Table 0001 - Administrative Sex for suggested 

PID-9 Patient Alias (XPN) 00112 

Not anticipated for use in immunization messages. This field was used in the 2.3.1 Implementation Guide. Alias names should be placed in the patient name field. 

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 CE data type for race (alternate identifier, alternate text, and name of alternate coding system) is reserved for govecodes. 

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 Multiple addresses for the same person may be sent in the following sequence: The primary mailing address must sequence (for backward compatibility); if the mailing address is not sent, then a repeat delimiter must be sent in the This field is used for any type of address that is meaningfully associated with the client/patient. For instance Birth Saddress of the birthing location, address type = BDL. A person’s address may be sent in this field or in the NK1 segment with a relationship code indicating Self. Local imclarify how these addresses will be handled. 

PID-12 County Code (IS) 00115 

Not anticipated for use in immunization messages. County code belongs in the Address field (PID-11). 

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 sequence. The first sequence is considered the primary number (for backward compatibility). If the primary numberepeat delimiter is sent in the first sequence. Each type of telecommunication shall be in its’ own repetition. For exaphone number and an email address, they shall each have a repetition. Refer to HL7 Table 0201 - TelecommunicatTable 0202 - Telecommunication Equipment Type for valid values. 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

PID-14 Phone Number - Business (XTN) 00117 

Definition: This field contains the patient’s business telephone numbers. All business numbers for the patient are sesequence. The first sequence is considered the patient’s primary business phone number (for backward compatibibusiness phone number is not sent, then a repeat delimiter must be sent in the first sequence. Refer to HL7 Table Telecommunication Use Code and HL7 Table 0202 - Telecommunication Equipment Type for valid values. 

PID-15 Primary Language (CE) 00118 

Definition: This field contains the patient’s primary language. HL7 recommends using ISO table 639 as the suggest

defined Table 0296 - Primary Language. 

PID-22 Ethnic Group (CE) 00125 

Definition: This field further defines the patient’s ancestry. Refer to User-defined Table 0189 - Ethnic Group. The sedata type for ethnic group (alternate identifier, alternate text, and name of alternate coding system) is reserved for gassigned 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 IndY 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 entere

is populated, then this field should be populated. 

PID-29 Patient Death Date and Time (TS) 00740 

Definition: This field contains the date and time at which the patient death occurred. 

PID-30 Patient Death Indicator (ID) 00741 

Definition: This field indicates whether the patient is deceased. Refer to HL7 Table 0136 - Yes/no Indicator for valid 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

Y the patient is deceased N the patient is not deceased Empty status is undetermined 

PID-33 Last Update Date/Time (TS) 01537 

Definition: This field contains the last update date and time for the patient’s/person’s identifying and demographic d

PID segment. 

PID-34 Last Update Facility (HD) 01538 

Definition: This field identifies the facility of the last update to a patient’s/person’s identifying and demographic datasegment. 

PV1—Patient Visit Segment

The PV1 segment is used to convey visit specific information. The primary use in immunization messages is to car

client’s eligibility status. 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 

Table 5-17-Patient Visit (PV1) 

SEQ LEN Data 

Type 

Cardinality Value Set ITEM# ELEMENT NAME Usage Con

1 4 SI [0..1] 00131 Set ID - PV1 O If po

shou

2 1 IS [1..1] 0004 00132 Patient Class R R 3 PL [0..1] 00133 Assigned Patient 

Location 

O 

4 2 IS [0..1] 0007 00134 Admission Type O 5 CX [0..1] 00135 Pre-admit Number O 6 PL [0..1] 00136 Prior Patient 

Location 

O 

7 XCN [0..1] 0010 00137 Attending Doctor O 8 XCN [0..1] 0010 00138 Referring Doctor O 9 XCN [0..1] 0010 00139 Consulting Doctor O 10 3 IS [0..1] 0069 00140 Hospital Service O 11 PL [0..1] 00141 Temporary Location O 12 2 IS [0..1] 0087 00142 Preadmit Test 

Indicator 

O 

13 2 IS [0..1] 0092 00143 Re-admission 

Indicator 

O 

14 6 IS [0..1] 0023 00144 Admit Source O 15 2 IS [0..1] 0009 00145 Ambulatory Status O 16 2 IS [0..1] 0099 00146 VIP Indicator O 17 XCN [0..1] 0010 00147 Admitting Doctor O 18 2 IS [0..1] 0018 00148 Patient Type O 19 CX [0..1] 00149 Visit Number O 20 FC [1..*] 0064 00150 Financial Class R 
ter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 

21 2 IS [0..1] 0032 00151 Charge Price 

Indicator 

O 

22 2 IS [0..1] 0045 00152 Courtesy Code O 23 2 IS [0..1] 0046 00153 Credit Rating O 24 2 IS [0..1] 0044 00154 Contract Code O 25 8 DT [0..1] 00155 Contract Effective 

Date 

O 

26 12 NM [0..1] 00156 Contract Amount O 27 3 NM [0..1] 00157 Contract Period O 28 2 IS [0..1] 0073 00158 Interest Code O 29 4 IS [0..1] 0110 00159 Transfer to Bad 

Debt Code 

O 

30 8 DT [0..1] 00160 Transfer to Bad 

Debt Date 

O 

31 10 IS [0..1] 0021 00161 Bad Debt Agency 

Code 

O 

32 12 NM [0..1] 00162 Bad Debt Transfer 

Amount 

O 

33 12 NM [0..1] 00163 Bad Debt Recovery 

Amount 

O 

34 1 IS [0..1] 0111 00164 Delete Account 

Indicator 

O 

35 8 DT [0..1] 00165 Delete Account 

Date 

O 

36 3 IS [0..1] 0112 00166 Discharge 

Disposition 

O 

37 DLD [0..1] 0113 00167 Discharged to 

Location 

O 

38 CE [0..1] 0114 00168 Diet Type O 

Chap
ter 5: Segments and Message Details 

Definition: This field contains the financial class(es) assigned to the patient. It reflects the current eligibility status. include the eligibility status for the Vaccines for Children program (VFC). This field has 2 components: financial clasthe date that the status was assessed. Refer to User-defined Table 0064 - Financial Class for suggested values. 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 

39 2 IS [0..1] 0115 00169 Servicing Facility O 40 1 IS [0..1] 0116 00170 Bed Status O 41 2 IS [0..1] 0117 00171 Account Status O 42 PL [0..1] 00172 Pending Location O 43 PL [0..1] 00173 Prior Temporary 

Location 

O 

44 TS [0..1] 00174 Admit Date/Time O 45 TS [0..1] 00175 Discharge 

Date/Time 

O 

46 12 NM [0..1] 00176 Current Patient 

Balance 

O 

47 12 NM [0..1] 00177 Total Charges O 48 12 NM [0..1] 00178 Total Adjustments O 49 12 NM [0..1] 00179 Total Payments O 50 CX [0..1] 0203 00180 Alternate Visit ID O 51 1 IS [0..1] 0326 01226 Visit Indicator O 52 XCN [0..1] 0010 01274 Other Healthcare 

Provider 

O 

Definition: This field is used by systems to categorize patients by site. It shall be constrained to R. 

PV1-20 Financial Class (FC) 00150 PV1-2 Patient Class (IS) 00132 PV1 field definitionsChap
This field does not indicate how each immunization was paid for on this visit. That information may be carried in an 

associated with each RXA segment. 

ter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 

Definition: This field allows the responding system to return a precise response status. It is especially useful in the found that matches the query parameters, but where there is also no error. It is defined with HL7 Table 0208 - QueDefinition: This field contains the value sent in QPD-2 (query tag) by the initiating system, and will be response messages to the originating query. The responding system is required to echo it back as thquery acknowledgement segment(QAK). 

QAK—Query Acknowledgement Segment

Table 5-18-Query Acknowledgement Segment 

SEQ LEN Data Type Cardinality Value set ITEM# ELEMENT NAME Usage Co1 32 ST [1..1] 00696 Query Tag R 2 2 ID [0..1] 0208 00708 Query Response Status O 3 CE [0..1] 0471 01375 Message Query Name O 4 10 NM [0..1] 01434 Hit Count O 5 10 NM [0..1] 01622 This payload O 6 10 NM [0..1] 01623 Hits remaining O 

QAK-2 Query Response Status (ID) 00708 QAK-1 Query Tag (ST) 00696 QAK field definitionsChap
ter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 

Definition: This field contains the name of the query. This shall mirror the QPD-1 (Message Query Name) found in tis being responded to. Definition: This field contains the name of the query. These names are assigned by the function-specific chapters oone to one with the conformance statement for this query name, and it is in fact an identifier for that conformance s

Definition: This field must be valued by the initiating system to identify the query, and may be used to match responoriginating query. 

QAK-3 Message Query Name (CE) 01375 QPD – Query Parameter Definition

The QPD segment defines the parameters of the query. 

Table 5-19-Query Parameter Definition (QPD) 

SEQ LEN Data 

Type 

Cardinality Value Set ITEM# ELEMENT NAME Usage Comment 

1 CE [1..1] 0471 01375 Message Query 

Name 

R 

2 32 ST 00696 Query Tag R Generated by the in3-n varies 01435 User Parameters 

(in successive fields) 

R The specification of 

found in the profile case. 

The responding system is required to echo it back as the first field in the query acknowledgement segment (QAK). 

QPD-1 Message Query Name (CE) 01375 QPD-2 Query Tag (ST) 00696 QPD field definitionsChap
The client data is presented as a sequence of HL7 fields. Beginning at QPD-3-User parameters, the remaining field

carry user parameter data. Each QPD user parameter field corresponds to one parameter defined in the Conformaeach name, type, optionality, and repetition of each parameter has been specified. While these parameters are und

“and-ed” together, the user must inspect the required Conformance Statement to properly understand each. Excep

parameter names do not need to be stated in the query; they are understood to be positional based on the Conform

ter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 

This field differs from MSA-2-Message control ID in that its value remains constant for each message (i.e. all contin

associated with the query, whereas MSA-2-Message control ID may vary with each continuation message, since it 

individual message, not the query as a whole. The RCP segment is used to restrict the amount of data that should be returned in response to query. It lists the se

Each parameter field may be specified in the Conformance Statement to be of any single data type, including the ctypes. Parameter fields in the QPD segment appear in the same order as in the Conformance Statement. Definition: These successive parameter fields hold the values that the Client passes to the Server. 

RCP

– Response Control Parameter Segment

QPD-3 User Parameters (Varies) 01435 Chap
ter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 

Definition: This field contains the time frame in which the response is expected. Refer to HL7 Table 0091 - Query pTable values and subsequent fields specify time frames for response. Only I for immediate shall be used for this fieDefinition: This field contains the maximum length of the response that can be accepted by the requesting system. numerical values (in the first component) given in the units specified in the second component. Default is LI (lines). records, so the second component is constrained to RD. 

Table 5-20-Response Control Parameter 

SEQ LEN Data Type Cardinality Value set ITEM# ELEMENT NAME Usage Comment1 1 ID [0..1] 0091 00027 Query Priority O Constrain 

Immediate expected. 

2 CQ [0..1] 0126 00031 Quantity Limited Request O This field m

maximum that may bfirst compocount and contains R

3 CE [0..1] 0394 01440 Response Modality O 4 TS [0..1] 01441 Execution and Delivery 

Time 

O 

5 1 ID [0..1] 0395 01443 Modify Indicator O 6 SRT [0..1] 01624 Sort-by Field O 7 ID [0..*] 01594 Segment group inclusion O 

RCP-2 Quantity Limited Request (CQ) 00031 RCP-1 Query Priority (ID) 00027 RCP field definitionsChap
Note that this field is the maximum total records to return. The Version 2.5.1 standard indicates the maximum numb

batch. No batching of responses is permitted in this Guide. 

There is a change requiring an ORC conflicts with the previous implementation Guide. In that, ORC is optional aincluded in a VXU.

Note: Although the codes for segment groups are taken from HL7 Table 0391, the exact segment-level definition of a segmegiven only in the conformance statement of the query in which this segment group appears. 

ter 5: Segments and Message Details 

Definition: This field specifies the timing and grouping of the response message(s). Refer to HL7 Table 0394 – Resvalues. 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 

Definition: Specifies those optional segment groups which are to be included in the response. Refer to HL7 Table 0

for values for Segment Group. This is a repeating field, to accommodate inclusion of multiple segment groups. The not present, means that all relevant groups are included. 

The RXA segment carries pharmacy administration data. It is a child of an ORC segment, which a repeating segm

VXU messages. Because ORC are allowed to repeat an unlimited numbers of vaccinations may be included in a 

must be preceded by an ORC.20

RCP-3 Response Modality (CE) 01440 RCP-7 Segment Group Inclusion (ID) 01594 RXA‐‐ Pharmacy/Treatment Administration Segment20 The HL7 Version 2.5.1 document clearly indicates that any RXA must be associated with an ORC. In the case of immuni

immunization will have its own ORC. 

Chap
ter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 

Table 5-21 Pharmacy/Treatment Administration (RXA) 

SEQ LEN Data 

Type 

Cardinality Value Set ITEM # ELEMENT NAME Usage Comm

1 4 NM [1..1] 00342 Give Sub-ID Counter R Constra2 4 NM [1..1] 00344 Administration Sub-ID 

Counter 

R Constra

3 TS [1..1] 00345 Date/Time Start of 

Administration 

R 

4 TS [0..1] 00346 Date/Time End of 

Administration 

RE If popu

be the (RXA-3

5 CE [1..1] 0292 00347 Administered Code R CVX co

preferre

6 20 NM [1..1] 00348 Administered Amount R If admi

not rec

7 CE [0..1] 00349 Administered Units CE If previ

populatexcept 

8 CE [0..1] 00350 Administered Dosage Form O 9 CE [0..*] NIP 0001 00351 Administration Notes RE The pri

field it timmunbased record the proimmunshould this usethis fielbut neelocally. 

Chap
Chapter 5: Segments and Message Details 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 

SEQ LEN Data 

Type 

Cardinality Value Set ITEM # ELEMENT NAME Usage Comm

10 XCN [0..1] 00352 Administering Provider RE This is 

gave th

11 LA2 [0..1] 00353 Administered-at Location RE 12 20 ST [0..1] 00354 Administered Per (Time 

Unit) 

O 

13 20 NM [0..1] 01134 Administered Strength O 14 CE [0..1] 01135 Administered Strength 

Units 

O 

15 20 ST [0..*] 01129 Substance Lot Number RE 16 TS [0..1] 01130 Substance Expiration Date CE If the lo

populatshould 

17 CE [0..*] 0227 01131 Substance Manufacturer 

Name 

RE 

18 CE [0..*] 01136 Substance/Treatment 

Refusal Reason 

C If the C

is RE, tpopulat

19 CE [0..1] 01123 Indication O 20 2 ID [0..1] 0322 01223 Completion Status RE If this fi

populatto be Cthe Refpopulatbe set t

21 2 ID [0..1] 0323 01224 Action Code - RXA RE 22 TS [0..1] 01225 System Entry Date/Time O 23 5 NM [0..1] 01696 Administered Drug Strength 

Volume 

O 
Chapter 5: Segments and Message Details 

SEQ LEN Data Cardinality Value Set ITEM # ELEMENT NAME Usage Comm

Type 

24 CWE [0..1] 01697 Administered Drug Strength 

Volume Units 

O 

25 CWE [0..1] 01698 Administered Barcode 

Identifier 

O 

26 1 ID [0..1] 0480 01699 Pharmacy Order Type O 

RXA field definitionsRXA-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 immunizatconstrain to 1. This should not be used for indicating dose number, which belongs in an OBX. Note that the previous Implementation Guide suggested that this be used for indicating dose number. This use is n

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 twas recorded.

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-3of RXA-3-Date/Time Start of Administration is assumed. 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

RXA-5 Administered Code (CE) 00347 

Definition: This field identifies the medical substance administered. If the substance administered is a 

should be used in the first triplet to code this field (see HL7 Table 0292 - Codes for vaccines adminisset of three components could be used to represent the same vaccine using a different coding systeProcedural 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 fi

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 

units that reflect the actual quantity of the substance administered. It does not include compound units. This field is 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 reco

the reporting provider. It should contain the information source (see NIP-defined Table 0001 - ImmunizaSource). The first component shall contain the code, the second the free text and the third shall cont

code system. (NIP001) Sending systems should be able to send this information. Receiving systems accept this information. This field may be used for other notes if specified locally. The first repetition shall be the information 

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 Information source is an NVAC core data element. It speaks to the reliability of the immunization recinformation. 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

RXA-10 Administering Provider (XCN) 00352 

Definition: This field is intended to contain the name and provider ID of the person physically adminispharmaceutical. Note that previous Implementation Guide (2.3.1) overloaded this field by using local codes to indicaprovider, ordering provider and recording provider. This is a misuse of this field and not supported in 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 useComponent 4: The facility name/identifier. Subcomponent 1:identifier21

Subcomponent 2: Universal ID This shall be an OID, if populated. Note that this should not be a local code, but rat

Subcomponent 3: Universal ID type (specify which universal id type) Note that if subcomponent 1 is populated, 2 and 3 should be empty. If subcomponent 2 is populated with an OID, sbe 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 dosrecord. 

21 This value should uniquely identify a specific facility. Systems may choose to publish a table with local values. HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

Note: The lot number is the number printed on the label attached to the container holding the substance and on the packaging container. If two lot numbers are associated with a product that is a combination of different components, they may be included 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 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 patient did not take the substance. If this field is populated RXA-20, Completion Status shall be populated with RE. 

RXA-20 Completion Status (ID) 01223 

This field indicates if the dose was successfully given. It must be populated with RE if RXA-18 is populated. If a do

administered or if the dose were not potent this field may be used to label the immunization. 

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 rusage 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 hainitial 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 immunizatiMost IIS have specific criteria for determining whether to add or update an immunization that does not rely directly 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

reason it is common practice to indicate action as Add even if this vaccination has been previously reported. It is imthat 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 shoul

RXR‐‐ Pharmacy/Treatment Route Segment

The Pharmacy/Treatment Route segment contains the alternative combination of route, site, administration device, method that are prescribed as they apply to a particular order. 

Table 5-22 Pharmacy/Treatment Route (RXR) 

SEQ LEN Data 

Type 

Cardinality TBL# ITEM # ELEMENT NAME Usage Constraint 

1 CE [1..1] 0162 00309 Route R 2 CWE [0..1] 0163 00310 Administration Site RE 3 CE [0..1] 0164 00311 Administration Device O 4 CWE [0..1] 0165 00312 Administration Method O 5 CE [0..1] 01315 Routing Instruction O 6 CWE [0..1] 0495 01670 Administration Site Modifier O 

RXR field definitionsRXR-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 acceHL7 codes. HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 5: Segments and Message Details 

RXR-2 Administration Site (CWE) 00310 

Definition: This field contains the site of the administration route. 

RXR-3 Administration Device (CE) 00311 

Not anticipated for IIS use. 

RXR-4 Administration Method (CWE) 00312 

Not anticipated for IIS use. 

RXR-5 Routing Instruction (CE) 01315 

Not anticipated for IIS use. 

RXR-6 Administration Site Modifier (CWE) 01670 

Not anticipated for IIS use. 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 6: Messages for Transmitting Immunization Information 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

128

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.
Chapter 6: Messages for Transmitting Immunization Information 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

129

Segment Cardinality Usage Comment

PID [1..1] R Every VXU has one PID segment.

PD1   [0..1] RE Every PID segment in VXU may have one or less

PD1 segment

NK1   [0..*] RE The PID segment in a VXU may have zero or more

NK1 segments.

PV1 [0..1] RE The PID segment in a VXU may have zero or one

PV1 segment. Subsequent messages regarding

the same patient/client may have a different PV1

segment.

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 Each VXU may have zero or more Order groups

ORC [1..*] RE The order group in a VXU may have one or more

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
Chapter 6: Messages for Transmitting Immunization Information 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

130

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

Requesting Information (Immunization History) – QBP

Figure 6-1-VXU Domain Diagram 

message, it must be associated with any parent segments. For example, the NTE

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.
Chapter 6: Messages for Transmitting Immunization Information 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

131

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

1/31/2011

132

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

[{SFT}] (0..1) O Not anticipated for use in immunization 
Chapter 6: Messages for Transmitting Immunization Information 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

133

Segment Cardinality Usage Comment

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 22

                                                      

22 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.2) 

1/31/2011

134

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

1/31/2011

135

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 

7. Query and Response Profile (QBP/RSP) Request Immunization History Query Profile –Z34^CDCPHINVSThe following query profile supports replication of the functionality of the VXQ/VXX/VXR query and responses2

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 

the identity resolution accomplished with the PDQ can be used with this query profile to request an immunizat

anticipated that one high confidence match will be the results of this effort and the return response will be one history. IHE also has a query profile to support interaction with an MPI. The PIX query requests patient identifi

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 apublished a supplemental Pediatric Demographic Profile that optimizes the PDQ query to support queries for ch

http://www.ihe.net/profiles/index.cfm

http://www.ihe.net/Technical Framework/index.cfm 24See 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 prconstraints on the responses returned in a response to the query. One will specify a single immunization history second will specify a list of candidate clients and their identifiers.23 This functionality entails a query that uses demographic and other identifying information to request an immunization hist

lower confidence candidates are found a list of candidates is returned. If a single high-confidence match is found, an immu

returned. 

24 These links are current as of 5/1/2010. HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 7:Query and Response Profile 

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 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 7:Query and Response Profile 

Note that when one patient is found, a Receiving system may choose to send an immunization history or a list oidentifiers 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 psystems may choose to treat the person as if they are not in the system. Others may choose to send a response person exists in the system but does not allow sharing. This rule should be clearly documented in the local profQuery GrammarResponse Grammar

Table 7-2-Response Grammar to Different Outcomes 

Outcome of Query Response MessageNo match found Response indicates that message was successfully processed and 

clients matched the criteria that were sent in the query.

QBP^Q11^QBP Q11 Query Grammar: QBP Message Usage Comment

MSH Message Header Segment R 

[{SFT}] Software Segment O Local profile ma

specify 

QPD Query Parameter Definition R 

RCP Response Control Parameter R 

[ DSC ] Continuation Pointer X Not supported 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 7:Query and Response Profile 

Exactly one high confidence match found25 Response includes a complete immunization history as specified 

See Profile Return Immunization History.

At least one lower confidence match26 is

found, but <= maximum number allowed.

Response returns one PID with associated PD1 and NK1 segment

potential match. No immunization history is returned.

See Profile Return Candidate List.

More than the maximum number allowed isfound.

Response indicates that the message was successfully processed

too many potential matches were found.The maximum number allowed is the lower of the maximum num

requested and the maximum number that the receiving system w

Message is not well formed and has fatalerrors.

Response indicates that the message was not successfully proces

may indicate errors.

The response grammar below will accommodate each of the cases above. If one high confidence candidate is fo

immunization history may be returned. If one or more lower confidence candidates are found, then a list of pat

be returned.The usage of segments will be specified in two separate profiles. The first profile will address the case where on

confidence matches are found. In this case a list of candidates will be returned. These will not have immunizatio

to V2.3.1 VXX) The other profile will handle the case where the receiving system finds one high confidence mat

client immunization record will be returned (similar to V2.3.1 VXR).

25 Definition of match is left to local business rules. These rules should be documented in a local implementation guide. For 

may only return an immunization history when the match is exact, returning a list of 1 if one person for a lower probability m

26 More than one high confidence match constitutes is considered a set of lower confidence matches. HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 Response Grammar RSP^K11

Table 7-3 Response Grammar RSP^K11 

Segment Cardinality HL7 Optionality27 Comment 

MSH [1..1] R MSA [1..1] R [ERR] [0..1] O If errors exist, then this s

populated. 

QAK [1..1] R QPD [1..1] R Query Parameter Definition [{ [0..1] O --- Response begi

[{ [0..*] O Begin patient identi

PID [1..1] R[PD1 ] [0..1] RE[{NK1 }] [0..*] RE

}] End Patient Identif

[ [0..1] O Begin immunization h

[PV1] [0..1] RE[IN1] [0..1] RE

[{ [0..*] RE Begin Order

ORC [1..1] R Required if client has immuniz

(RXA). There is one ORC fo

Begin Pharmacy Admini

RXA [1..1] R[RXR ] [0..1] RE

[{ [0..*] RE Begin ObservatioOBX [1..1] R[NTE ] [0..1] RE

27 Optionality is not the same as Usage, but rather the standard definitions of HL7. 28 Matches the information in the requesting QBP message. 29 If a query errors out or if no matching persons are found the segments in the Response group will not be returned. 
ter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 

}] End observation

}]

End Pharmacy Adminis

End Order

] End Immunization Hi

}] Response endChap
Chapter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 

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 Constrain

1 1 ST [1..1] 00001 Field Separator R The MSH.2 4 ST [1..1] 00002 Encoding Characters R The MSH.

^~\& 

3 HD [0..1] 0361 00003 Sending Application RE No constra4 HD [0..1] 0362 00004 Sending Facility RE No constra5 HD [0..1] 0361 00005 Receiving Application RE No constra6 HD [0..1] 0362 00006 Receiving Facility RE No constra7 26 TS [1..1] 00007 Date/Time Of Message R The degre

must be asecond, amust be in(format YYYYMMS[S]]]]+/-Z

8 40 ST [0..1] 00008 Security O 9 15 MSG [1..1] 00009 Message Type R QBP^Q1110 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 
ter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 

SEQ LEN Data 

Type 

Cardinality Value 

set 

ITEM # ELEMENT NAME Usage Constrain

16 2 ID [0..1] 0155 00016 Application 

Acknowledgment Type 

RE AL-Alway

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

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 

1 MessageQueryName CE R 2 QueryTag 32 ST R 3 PatientList CX RE Y PID.3 4 PatientName XPN RE PID.5 5 PatientMotherMaiden

Name 

XPN RE PID.6 

6 Patient Date of Birth 26 TS RE PID.7 7 Patient Sex 1 IS RE PID.8 

Chap
ter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 

Field Seq (Query ID=Z34) 

Name Key/ 

Search 

Sort LEN TYPE Opt Rep Match 

Op 

TBL Segment 

Field Name 

Service Identifier Code 

8 Patient Address XAD RE PID.11 9 Patient home phone XTN RE PID.13 10 Patient multiple birth 

indicator 

1 ID RE PID-24 

11 Patient birth order 2 NM RE PID-25 12 Client last updated 

date 

TS RE PID-33 

13 Client last update 

facility 

HD RE PID-34 

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 Chap
ter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 Input Parameter (Query ID=Z34) Comp. Name DT Description MessageQueryName CE Z34^Request Immunization History^HL7047QueryTag ST Unique to each query message instance. PatientList CX The combination of values for Patientlist.ID, 

patientlst.identifiercode and Patientlist.Assignintended to allow unique identification of a clfound in the responding system. 

ID ST If this field, PID.3.1, is not valued, PatientList 

when seeking matching clients. 

Assigning Authority HD If this field, PID.3.4, is not valued, PatientList 

when seeking matching clients. 

IdentifierTypeCode IS If this field, PID.3.5, is not valued, PatientList 

when seeking matching clients. 

PatientName XPN If this field, PID.5, is not valued, then the que

since this is a required field. 

Family Name FN If this field, PID.5.1, is not valued, then patien

to contain no value. 

Given Name ST If this field, PID.5.2, is not valued, then patien

to contain no value. Given name is required. 

Second or further names ST If this field, PID.5.3, is not valued, then all va

considered a match. 

Suffix ST If this field, PID.5.4, is not valued, then all va

considered a match. 

Mother’s Maiden Name XPN If this field, PID.6, is not valued, Mother’s ma

considered when seeking matching clients. 

Family Name FN If this field, PID.6.1, is not valued, then moth

considered to contain no value. 

Given Name ST If this field, PID.6.2, is not valued, then all va

considered a match. 

DateOfBirth TS If this field, PID.7, is not valued to an accuracChap
ter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 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 valu

considered a match. 

Address XAD If this field, PID.11, is not valued, then addres

considered when seeking matching clients. 

Street Address SAD If this field, PID.11.1, is not valued, then all v

considered a match. 

City ST If this field, PID.11.3, is not valued, then addr

contain no value. 

State ST If this field, PID.11.4, is not valued, then addr

contain no value. 

ZIP ST If this field, PID.11.5, is not valued, then all v

considered a match. 

Address Type IS If this field, PID.11.7 is not valued, then it sha

address. 

Phone XTN This field will be considered the Home phone

is not valued, then phone number is not consmatching clients. 

Area code NM If this field, PID.13.6, is not valued, then all v

shall be considered matches. 

Local number NM If this field, PID.13.7, is not valued, then add

contain no value. 

Multiple Birth Indicator ID If this field, PID.24, is not valued, then Multip

not considered when seeking matching clien

Birth Order NM If this field, PID.25, is not valued, then birth o

considered when seeking matching clients. 

Client last updated date TS If this field, PID.33, is not valued, then client 

not considered when seeking matching clien

Client last update facility TS If this field, PID.34, is not valued, then client Chap
All of the fields used for searching in the query parameters are listed as Required but may be empty (RE) in the 

local business rules may constrain this. For instance, a system may require name, date of birth and patient id. Arequire that at least four fields are populated or some other business rule. This must be documented in a local or profile.

ter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 Input Parameter (Query ID=Z34) Comp. Name DT Description 

is not considered when seeking matching clie

This Guide does not specify search logic. It specifies the structure and content of the message used to query. It 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. Th

permitted is I. 

2 Quantity Limited Request 10 CQ 

Quantity NM The maximum number of patients that may be retu

is set by the requester. The sender may send up to 

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. Chap
ter 7:Query and Response Profile 

This profile constrains the QBP Query, Request Immunization History Query Z34 , that is specified above. The g

constrain the response specified in the Request Immunization History query profile to a list of patients and thei

other aspects it conforms completely with the specifications described in that query profile.

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 A key task that must be accomplished for immunization messaging is requesting an immunization history from 

system. There are 4 possible outcomes to a request for immunization query.

HL7 Version 2.5.1 Message Profile for Returning a List of Candidates in Response to a Request Immunizat

Outcome Action

No clients are found that match therequested person

Send acknowledgement indicating nomatches found.

Exactly one high confidence match isfound.

Return Immunization history (See Z32profile)

One or more lower confidence personsmatch the criteria sent. Matching more

than one high confidence candidateconstitutes a lower confidence match.

Return a list of candidates for furtherrefinement of selection.

The message is not well‐formed and can’tbe processed.

Return error acknowledgement

Table 7-8 Query Response Possibilities 

Return a List of Candidates Profile ‐‐ Z31^CDCPHINVSIntroduction:Chap
ter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 

1. Immunization History Requester—is a system that requests an immunization history for a specific indivi

it receives the candidate list sent.

2. Immunization History Supplier—returns candidate list to a requester for in response to a request for im

1. The History Supplier has found records for one or more persons who match the parameters in the query

Use Case:Figure 7-1--Return Candidate List Name: Return Candidate List

Actors:Preconditions:

2. The History Supplier has created the response message.

1. The History Supplier sends the RSP response message.

2. The History Requester receives the RSP response message.

Flow of Events:

Chap
ter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 

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 

Segment30

[{ [1..1] R --- Response begin31

[{ [1..*] R Begin patient identifier

PID [1..1] R[PD1 ] [0..1] RE[{NK1 }] [0..*] RE

This profile constrains the Request for Immunization Query Response Grammar by changing the cardinality of t

History block to [0..0]. None of the segments within that block will be returned.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

Response Grammar RSP^K11

Table 7-9 Response Grammar RSP^K11 

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. Chap
ter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 This profile indicates that a list of patient identification shall be returned. It shall be identified in MSH‐21 by its 

}] 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] RE[IN1] [0..1] RE

[{ [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 ObservationOBX [1..1] R[{NTE }] [0..*] RE}] End observation

}]

End Pharmacy Administration

End Order

] End Immunization History

}] Response endChap
ter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 This profile makes no changes to the parent query profile, with the exception of the MSH‐21 field, which contai

identifier, Z31^CDCPHINVS.

This profile makes no changes to the parent query profile.

Segment Level ProfileField Level Profile

Chap
ter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 This diagram illustrates the context of the message. The message specified in this profile is in Bold and labeled 

List(RSP^K11).

Application level acknowledgement is allowed, but not required.Figure 7-2 Return Candidate List (RSP^K11) Acknowledgement ResponsibilitiesSequence Diagram Dynamic DefinitionChap
A key task that must be accomplished for immunization messaging is requesting an immunization history from 

system. One component of that process is returning an immunization history. This profile constrains the QBP Q

Immunization History Query Z34 , that is specified above. That query profile specifies the query for requesting a

history and is intended to support 2 types of response. One response returns a list of candidate client/patients 

further selection. That selection is then used to re‐query for an immunization history. The second is a response 

immunization history. This second is the focus of this message profile. The goal of this profile is to constrain the 

the Request Immunization History query profile to a single immunization history. In all other aspects it conform

specifications described in the implementation Guide for this query profile.

ter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 

HL7 Version 2.5.1 Message Profile for Returning an Immunization History

Return an Immunization History – Z32^CDCPHINVSName: Return Immunization HistoryIntroduction:Use Case:Chap
ter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 

1. Immunization History Requester—is a system that requests an immunization history for a specific indivi

it receives the immunization history sent.

2. Immunization History Supplier—returns an immunization history to a requester for a specific individual 

request for immunization history.

1. The History Supplier has found the records for the requested person.

Figure 7-3 Return Immunization History Use Case Actors:Preconditions:

2. The History Supplier has created the response message.

1. The History Supplier sends the RSP response message.

2. The History Requester receives the RSP response message.

Post‐Conditions:

Flow of Events:

Chap
ter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 This profile constrains the Request for Immunization Query Response Grammar by changing the cardinality of t

repetition.

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 

Segment32

[ [0..1] --- Response control parameter 

begin 

Note Changed Cardinality 

Begin patient identifier

PID (1..1)[PD1 ] (0..1)[{NK1 }] (0..*)

End Patient Identifier

Figure 7-4 Return Immunization History Response Grammar 

1. The History Requester has the immunization history.

Response Grammar RSP^K11 Constrained by This Profile

Static DefinitionResponse Grammar RSP^K11

32 Matches the information in the requesting QBP message. Chap
ter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 This profile indicates that only one repetition of an entire immunization history shall be returned. It shall be ide

its profile identifier, Z32^CDCPHINVS.

[ 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 endThis profile makes no changes to the parent query profile.

Segment Level Profile

Chap
ter 7:Query and Response Profile 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011 This diagram illustrates the context of the message. The message specified in this profile is in Bold and labeled History(RSP^K11).This profile makes no changes to the parent query profile, with the exception of the MSH 21 profile identifier, ZApplication level acknowledgement is allowed, but not required.Figure 7-5 Return Immunization History Sequence Diagram Acknowledgement Responsibilities Sequence Diagram Dynamic DefinitionField Level ProfileChap
Change History 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

159

Change History Details 

Table 10--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 111--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]

Chapter 5, page 108 Corrected data type of PID‐39 Tribal citizenship from CE

to CWE
Change History 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

1/31/2011

160

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
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A1

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

NOTE: Where only selected values are listed for HL7 tables, please refer to the HL7

Standard for complete listings.  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”.

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 [values suggested by HL7] (use in PID‐8, NK1‐15)

This code reflects the self reported gender.

Value set OID:   2.16.840.1.113883.1.11.1

Value Description Definition

F Female Person reports that she is female.

M Male Person reports that he is male.

U Unknown/undifferentiat

ed

No assertion Is made about the gender of the

person.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A2

HL7‐defined Table 0003 ‐ Event type [only selected values listed] (use in MSH‐9, second

component)

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 [values suggested by HL7] (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

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.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A3

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

American

B Black or African‐

American

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)

[locally‐defined] Each registry should establish a system of coding its reporting

physicians.  The National Provider Identifier (NPI) adopted for the HIPAA legislation may

be used for this purpose.

HL7‐defined Table 0061 ‐ Check digit scheme (use in all CX data types; including PID‐

2,3,4,18,21)

Value Description
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A4

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 [as defined in HL7’s Version 2.4] (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 [NIP suggested values] (use in PV1‐20)

Financial class references a client’s eligibility status at a point in time.  The values in this

table relate to eligibility for the Vaccine for Children (VFC) program.  Local

implementations may define and document local codes.   

Note that funding source for a specific immunization is different from Financial Class.  

These are documented in CDC local codes table, CDCPHINVS (Value set OID

2.16.840.1.114222.4.11.3287).

Code Lable Definition 

V01 Not VFC eligible Client does not qualify for VFC because they do not 

have one of the statuses below. This category does 

not include the underinsured (see V08). 

V02 VFC eligibleMedicaid/Medicaid 

Managed Care 

Client is currently on Medicaid or Medicaid 

managed care. 

V03 VFC eligibleUninsured Client does not have insurance coverage for 

vaccinations. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A5

V04 VFC eligibleAmerican 

Indian/Alaskan 

Native 

Client is a member of a federally recognized tribe. 

V05 VFC eligibleFederally Qualified 

Health Center Patient 

(under-insured) 

Client has insurance that partially covers vaccines 

received on visit and so is eligible for VFC coverage 

at a Federally Qualified Health Center. The client 

must be receiving the immunizations at the FQHC. 

V06 VFC eligible- State 

specific eligibility 

(e.g. S-CHIP plan) 

Client is eligible for VFC, based on State-specific 

rules, such as S-CHIP. 

V07 VFC eligibilityLocal-specific 

eligibility 

Client is eligible for VFC, based on local-specific 

rules. 

V08 Not VFC eligibleUnder-insured Client has insurance that partially covers vaccines 

received on visit. The immunizations were not 

administered at a Federally Qualified Health Center 

(FQHC) 

HL7‐defined Table 0076 ‐ Message type [only selected values listed] (use in MSH‐9, first

component)

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 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A6

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)

Value Description

2.1 Release 2.1

2.2 Release 2.2

2.3 Release 2.3       March 1997

2.3.1 Release 2.3.1  May 1999

2.4 Release 2.4     October 2000

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
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A7

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. 

<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 listed] (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
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A8

IN Intranasal {Do not use this older code}

C38276 IV Intravenous administered into a vein

C38288 PO Oral administered by mouth

OTH Other/Miscellaneous

C38676 Percutaneous made, done, or effected through the

skin.

C38299 SC Subcutaneous Under the skin or between skin and

muscles.

C38305 TD Transdermal describes something, especially a

drug, that is introduced into the

body through the skin

Example

|C28161^Intramuscular^NCIT|

|SC^Subcutaneous^HL70162|
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A9

HL7‐defined Table 0163 ‐ Administrative site [only selected values listed] (use in RXR‐2)

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

LD Left Deltoid

LG Left Gluteous Medius

LVL Left Vastus Lateralis

LLFA Left Lower Forearm

RA Right Upper 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

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
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A10

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.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A11

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 

  
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A12

User‐defined Table 0203 ‐ Identifier type [values suggested by HL7; with NIP‐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 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A13

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 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A14

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. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A15

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 subscr ber 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 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A16

Value Description Comment 

WC WIC identifier 

WCN Workers’ Comp Number 

XX Organization identifier 

User‐defined Table 0204 ‐ Organizational name type [values suggested by HL7] (use in

all XON data types)

Value Description

L Legal name

D Display name

HL7‐defined Table 0207 ‐ Processing mode (use in MSH‐11)

Fields using this code set are expected to be empty.  For a current list of HL7 values

please reference the HL7 version 2.5.1 documents.

User‐defined Table 0208 ‐ Query response status [values suggested by HL7] (use in

QAK‐2)

Value Description

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.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A17

User‐defined Table 0215 ‐ Publicity code [values suggested by NIP] (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/nip/IIS/IISStandards/vaccines.asp?rpt=mvx 33

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

AB Abbott Laboratories TRUE includes Ross Products Division

ACA Acambis, Inc FALSE acquired by sanofi in sept 2008

AD

Adams Laboratories,

Inc. TRUE

AKR Akorn, Inc TRUE

ALP

Alpha Therapeutic

Corporation TRUE

AR Armour FALSE

                                                      

33 This link is current as of 2/15/2011. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A18

AVB

Aventis Behring

L.L.C. FALSE

AVI Aviron FALSE acquired by medimmune

BA

Baxter Healthcare

Corporation FALSE

BAH

Baxter Healthcare

Corporation TRUE

includes Hyland Immuno, Immuno

International AG,and North American

Vaccine, Inc./acquired some assets

from alpha therapeutics

BAY Bayer Corporation FALSE

bayer biologicals now owned by

talecris

BP Berna Products FALSE

BPC

Berna Products

Corporation TRUE

includes Swiss Serum and Vaccine

Institute Berne

MIP Bioport Corporation TRUE

formerly Michigan Biologic Products

Institute

BTP

Biotest

Pharmaceuticals

Corporation TRUE

New owner of NABI HB as of

December 2007, Does NOT replace

NABI Biopharmaceuticals in this code

list.

CNJ

Cangene

Corporation TRUE

CMP

Celltech Medeva

Pharmaceuticals FALSE

CEN Centeon L.L.C. FALSE

CHI Chiron Corporation FALSE

CON Connaught FALSE acquired by Merieux

CSL CSL Biotherapies, Inc TRUE

CSL Biotherapies renamed to CSL

Behring

DVC

DynPort Vaccine

Company, LLC TRUE

EVN

Evans Medical

Limited FALSE

GEO GeoVax Labs, Inc. TRUE

SKB GlaxoSmithKline TRUE

includes SmithKline Beecham and

Glaxo Wellcome

GRE

Greer Laboratories,

Inc. TRUE

IAG

Immuno

International AG FALSE

IUS Immuno‐U.S., Inc. TRUE

INT Intercell Biomedical TRUE

KGC

Korea Green Cross

Corporation TRUE

LED Lederle FALSE

MBL Massachusetts TRUE formerly Massachusetts Public Health
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A19

Biologic Laboratories Biologic Laboratories

MA

Massachusetts

Public Health

Biologic Laboratories FALSE

MED MedImmune, Inc. TRUE

acquisitions of U.S. Bioscience in 1999

and Aviron in 2002, as well as the

integration with Cambridge Antibody

Technology and the strategic

alignment with our new parent

company, AstraZeneca, in 2007.

MSD Merck & Co., Inc. TRUE

IM Merieux FALSE

MIL Miles FALSE

NAB NABI TRUE

formerly North American Biologicals,

Inc.

NYB

New York Blood

Center TRUE

NAV

North American

Vaccine, Inc. FALSE

NOV

Novartis

Pharmaceutical

Corporation TRUE

includes Chiron, PowderJect

Pharmaceuticals, Celltech Medeva

Vaccines and Evans Limited, Ciba‐

Geigy Limited and Sandoz Limited

NVX Novavax, Inc. TRUE

OTC

Organon Teknika

Coporation TRUE

ORT

Ortho‐clinical

Diagnostics TRUE

a J & J company (formerly Ortho

Diagnostic Systems, Inc.)

OTH Other manufacturer TRUE

PD

Parkedale

Pharmaceuticals FALSE

no website and no news articles

(formerly Parke‐Davis)

PFR Pfizer TRUE

PWJ

PowderJect

Pharmaceuticals FALSE

PRX Praxis Biologics FALSE

PMC sanofi pasteur TRUE

(formerly Aventis Pasteur, Pasteur

Merieux Connaught; includes

Connaught Laboratories and Pasteur

Merieux)

SCL Sclavo, Inc. TRUE

SOL

Solvay

Pharmaceuticals TRUE

SI

Swiss Serum and

Vaccine Inst. FALSE

TAL

Talecris

Biotherapeutics TRUE includes Bayer Biologicals
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A20

JPN

The Research

Foundation for

Microbial Diseases

of Osaka University

(BIKEN) TRUE

USA

United States Army

Medical Research

and Material

Command TRUE

UNK

Unknown

manufacturer TRUE

VXG VaxGen TRUE

WA Wyeth‐Ayerst FALSE

WAL Wyeth‐Ayerst FALSE

includes Wyeth‐Lederle Vaccines and

Pediatrics, Wyeth Laboratories,

Lederle Laboratories, and Praxis

Biologics, acquired by Pfizer

10/15/2009

ZLB ZLB Behring FALSE

includes Aventis Behring and Armour

Pharmaceutical Company, Child of CSL

User‐defined Table 0288 ‐ Census tract (use in all XAD; including PID‐11)

Fields using this code set are expected to be empty.  For a current list of HL7 values

please reference the HL7 version 2.5.1 documents.

User‐defined Table 0289 ‐ County/parish (use in all XAD; including PID‐11)

A complete list of FIPS 6‐4 county codes is available at

<www.itl.nist.gov/div897/pubs/fip6‐4.htm>. According to the FIPS guidance, the 2‐letter

state code (available at <www.itl.nist.gov/div897/pubs/fip5‐2.htm>) plus the numeric

county code should be used (e.g., AZ001 represents Apache County, Arizona and AL001

represents Autauga County, Alabama).
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A21

HL7‐defined Table 0292 ‐ Codes for Vaccines administered (code=CVX) (use in RXA‐5)

The table below represents the February 2010 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/nip/IIS/IISStandards/vaccines.asp?rpt=cvx 34

The CDC’s National Center for Immunization and Respiratory Diseases (NCIRD) maintains

the HL7 external code set CVX.  

CVX – Vaccines Administered

Vaccine Name Long Name CVX code Current

Status

adenovirus, NOS adenovirus vaccine, NOS 82 Inactive

adenovirus, type 7 adenovirus vaccine, type 7,

live, oral

55 Inactive  

adenovirus, type 4 adenovirus vaccine, type 4,

live, oral

54 Inactive

anthrax anthrax vaccine 24 Active

BCG Bacillus Calmette‐Guerin

vaccine

19 Active

botulinum antitoxin botulinum antitoxin 27 Inactive

cholera cholera vaccine 26 Inactive

CMVIG cytomegalovirus immune

globulin, intravenous

29 Active

dengue fever dengue fever vaccine 56 Inactive

diphtheria antitoxin diphtheria antitoxin 12 Inactive

DT (pediatric) diphtheria and tetanus

toxoids, adsorbed for pediatric

use

28 Active

DTaP diphtheria, tetanus toxoids

and acellular pertussis vaccine

20 Active

DTaP, 5 pertussis

antigens

diphtheria, tetanus toxoids

and acellular pertussis

vaccine, 5 pertussis antigens

106 Active

DTaP, NOS diphtheria, tetanus toxoids

and acellular pertussis

vaccine, NOS

107 Inactive

DTaP‐Hep B‐IPV DTaP‐hepatitis B and

poliovirus vaccine

110 Active

DTaP‐Hib DTaP‐Haemophilus influenzae

type b conjugate vaccine

50 Active

DTaP‐Hib‐IPV diphtheria, tetanus toxoids 120 Active

                                                      

34 Link is current as of 5/1/2010. 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A22

and acellular pertussis

vaccine, Haemophilus

influenzae type b conjugate,

and poliovirus vaccine,

inactivated (DTaP‐Hib‐IPV)

DTaP‐IPV Diphtheria, tetanus toxoids

and acellular pertussis

vaccine, and poliovirus

vaccine, inactivated

130 Active

DTP diphtheria, tetanus toxoids

and pertussis vaccine

1 Inactive

DTP‐Hib DTP‐Haemophilus influenzae

type b conjugate vaccine

22 Inactive

DTP‐Hib‐Hep B DTP‐ Haemophilus influenzae

type b conjugate and hepatitis

b vaccine

102 Inactive

hantavirus hantavirus vaccine 57 Inactive

HBIG hepatitis B immune globulin 30 Active

Hep A, adult hepatitis A vaccine, adult

dosage

52 Active

Hep A, NOS hepatitis A vaccine, NOS 85 Inactive

Hep A, ped/adol hepatitis A vaccine,

pediatric/adolescent dosage,

2 dose schedule

83 Active

Hep A, ped/adol, 3

dose

hepatitis A vaccine,

pediatric/adolescent dosage,

3 dose schedule

84 Inactive

Hep A, pediatric,

NOS

hepatitis A vaccine, pediatric

dosage, NOS

31 Inactive

Hep A‐Hep B hepatitis A and hepatitis B

vaccine

104 Active

Hep B, adolescent or

pediatric

hepatitis B vaccine, pediatric

or pediatric/adolescent

dosage

8 Active

Hep B,

adolescent/high risk

infant

hepatitis B vaccine,

adolescent/high risk infant

dosage

42 Inactive

Hep B, adult hepatitis B vaccine, adult

dosage

43 Active

Hep B, dialysis hepatitis B vaccine, dialysis

patient dosage

44 Active

Hep B, NOS hepatitis B vaccine, NOS 45 Inactive
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A23

Hep C hepatitis C vaccine 58 Inactive

Hep E hepatitis E vaccine 59 Inactive

herpes simplex 2 herpes simplex virus, type 2

vaccine

60 Inactive

Hib (HbOC) Haemophilus influenzae type

b vaccine, HbOC conjugate

47 Inactive

Hib (PRP‐D) Haemophilus influenzae type

b vaccine, PRP‐D conjugate

46 Inactive

Hib (PRP‐OMP) Haemophilus influenzae type

b vaccine, PRP‐OMP conjugate

49 Active

Hib (PRP‐T) Haemophilus influenzae type

b vaccine, PRP‐T conjugate

48 Active

Hib, NOS Haemophilus influenzae type

b vaccine, conjugate NOS

17 Inactive

Hib‐Hep B Haemophilus influenzae type

b conjugate and Hepatitis B

vaccine

51 Active

HIV human immunodeficiency

virus vaccine

61 Inactive

HPV, bivalent human papilloma virus

vaccine, bivalent

118 Active

HPV, quadrivalent human papilloma virus

vaccine, quadrivalent

62 Active

IG immune globulin,

intramuscular

86 Active

IG, NOS immune globulin, NOS 14 Active

IGIV immune globulin, intravenous 87 Active

influenza, H5N1‐

1203

influenza virus vaccine, H5N1,

A/Vietnam/1203/2004

(national stockpile)

123 Inactive

influenza, live,

intranasal

influenza virus vaccine, live,

attenuated, for intranasal use

111 Active

influenza, NOS influenza virus vaccine, NOS8 88 Active

Influenza, seasonal,

high dose

Japanese Encephalitis vaccine

for intramuscular

administration

134 Active

influenza, split (incl.

purified surface

antigen)

influenza virus vaccine, split

virus (incl. purified surface

antigen)

15 Active

influenza, whole influenza virus vaccine, whole

virus

16 Inactive

IPV poliovirus vaccine, inactivated 10 Active
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A24

Japanese

encephalitis

Japanese Encephalitis Vaccine

SC

39 Active

Junin virus Junin virus vaccine 63 Inactive

leishmaniasis leishmaniasis vaccine 64 Inactive

leprosy leprosy vaccine 65 Inactive

Lyme disease Lyme disease vaccine 66 Inactive

M/R measles and rubella virus

vaccine

4 Active

malaria malaria vaccine 67 Active

measles measles virus vaccine 5 Active

melanoma melanoma vaccine 68 Inactive

meningococcal C

conjugate

meningococcal C conjugate

vaccine

103 Active

meningococcal

MCVP4

meningococcal polysaccharide

(groups A, C, Y and W‐135)

diphtheria toxoid conjugate

vaccine (MCV4)

114 Active

meningococcal

MPSV4

meningococcal polysaccharide

vaccine (MPSV4)

32 Active

meningococcal, NOS meningococcal vaccine, NOS 108 Active

MMR measles, mumps and rubella

virus vaccine

3 Active

MMRV measles, mumps, rubella, and

varicella virus vaccine

94 Active

mumps mumps virus vaccine 7 Active

OPV poliovirus vaccine, live, oral 2 Inactive

parainfluenza‐3 parainfluenza‐3 virus vaccine 69 Inactive

pertussis pertussis vaccine 11 Inactive

plague plague vaccine 23 Active

Pneumococcal

conjugate PCV 13

pneumococcal conjugate

vaccine, 13 valent

133 Active

pneumococcal

conjugate PCV 7

pneumococcal conjugate

vaccine, 7 valent

100 Active

pneumococcal

polysaccharide

PPV23

pneumococcal polysaccharide

vaccine

33 Active

pneumococcal, NOS pneumococcal vaccine, NOS 109 Active

polio, NOS poliovirus vaccine, NOS 89 Active

Q fever Q fever vaccine 70 Inactive

rabies, intradermal

injection

rabies vaccine, for intradermal

injection

40 Active

rabies, rabies vaccine, for 18 Active
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A25

intramuscular

injection

intramuscular injection

rabies, NOS rabies vaccine, NOS 90 Inactive

rheumatic fever rheumatic fever vaccine 72 Inactive

Rift Valley fever Rift Valley fever vaccine 73 Inactive

RIG rabies immune globulin 34 Active

rotavirus,

monovalent

rotavirus, live, monovalent

vaccine

119 Active

rotavirus, NOS rotavirus vaccine, NOS 122 Active

rotavirus,

pentavalent

rotavirus, live, pentavalent

vaccine

116 Active

rotavirus,

tetravalent

rotavirus, live, tetravalent

vaccine

74 Inactive

RSV‐IGIV respiratory syncytial virus

immune globulin, intravenous

71 Active

RSV‐MAb respiratory syncytial virus

monoclonal antibody

(palivizumab), intramuscular

93 Active

rubella rubella virus vaccine 6 Active

rubella/mumps rubella and mumps virus

vaccine

38 Active

Staphylococcus

bacterio lysate

Staphylococcus bacteriophage

lysate

76 Inactive

Td (adult) tetanus and diphtheria

toxoids, adsorbed for adult

use

9 Active

Td (adult)

preservative free

tetanus and diphtheria

toxoids, adsorbed,

preservative free, for adult

use

113 Active

Tdap tetanus toxoid, reduced

diphtheria toxoid, and

acellular pertussis vaccine,

adsorbed

115 Active

tetanus toxoid tetanus toxoid, adsorbed 35 Active

tetanus toxoid, NOS tetanus toxoid, NOS 112 Active

tick‐borne

encephalitis

tick‐borne encephalitis

vaccine

77 Inactive

TIG tetanus immune globulin 13 Active

TST, NOS tuberculin skin test; NOS 98 Inactive

TST‐OT tine test tuberculin skin test; old

tuberculin, multipuncture

95 Inactive
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A26

device

TST‐PPD intradermal tuberculin skin test; purified

protein derivative solution,

intradermal

96 Inactive

TST‐PPD tine test tuberculin skin test; purified

protein derivative,

multipuncture device

97 Inactive

tularemia vaccine tularemia vaccine 78 Inactive

typhoid, NOS typhoid vaccine, NOS 91 Inactive

typhoid, oral typhoid vaccine, live, oral 25 Active

typhoid, parenteral typhoid vaccine, parenteral,

other than acetone‐killed,

dried

41 Active

typhoid, parenteral,

AKD (U.S. military)

typhoid vaccine, parenteral,

acetone‐killed, dried (U.S.

military)

53 Active

typhoid, ViCPs typhoid Vi capsular

polysaccharide vaccine

101 Active

vaccinia (smallpox) vaccinia (smallpox) vaccine 75 Active

vaccinia (smallpox)

diluted

vaccinia (smallpox) vaccine,

diluted

105 Inactive

vaccinia immune

globulin

vaccinia immune globulin 79 Active

varicella varicella virus vaccine 21 Active

VEE, inactivated Venezuelan equine

encephalitis, inactivated

81 Active

VEE, live Venezuelan equine

encephalitis, live, attenuated

80 Active

VEE, NOS Venezuelan equine

encephalitis vaccine, NOS

92 Active

VZIG varicella zoster immune

globulin

36 Active

VZIG (IND) varicella zoster immune

globulin (Investigational New

Drug)

117 Inactive

yellow fever yellow fever vaccine 37 Active

zoster zoster vaccine, live 121 Active

no vaccine

administered

no vaccine administered 998 Inactive

RESERVED ‐ do not

use

RESERVED ‐ do not use 99 Inactive

unknown unknown vaccine or immune 999 Inactive
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A27

globulin

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.   

Note that this code differs from the 2.3.1 Guide, which used the 2 character codes.

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 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A28

HL7‐defined Table 0301 ‐ Universal ID type (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
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A29

HL7‐defined Table 0354 ‐ Message structure [only selected values listed] (use in MSH‐9,

third component)

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.

205 Duplicate key identifier The ID of the patient, order, etc. already exists. Used

in response to addition transactions (Admit, New

Order, etc.).
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A30

Status

code

Status text Description/Comment

206 Application record locked The transaction could not be performed at the

application storage level, e.g., database locked.

207 Application internal error A catchall for internal errors not explicitly covered

by other codes.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A31

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
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A32

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
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A33

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
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A34

VTA VERMONT

WAA WASHINGTON

WIA WISCONSIN

WVA WEST VIRGINIA

WYA WYOMING

User‐defined Table 0396 – Coding system [only selected values listed] See Version 2.5.1

Table 0396 for other values. (Use in CE data types to denote the coding system used for

coded values)

Value Description 

99zzz or L Local general code (where z is an alphanumeric character) 

ART WHO Adverse Reaction Terms

C4 CPT-4 

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
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A35

Value Description 

SNT SNOMED topology codes (anatomic sites)

UML Unified Medical Language

UPC Universal Product Code

UPIN UPIN 

W1 WHO record # drug codes (6 digit)

W2 WHO record # drug codes (8 digit)

W4 WHO record # code with ASTM extension

WC WHO ATC 

User‐defined Table 0441 ‐ Immunization registry status (use in PD1‐16) [HL7 assigned

table number 0441 in Version 2.4]

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.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A36

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.

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

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

NIP‐defined NIP003 ‐ Observation identifiers (use in OBX‐3)35

LOINC®

Code36

Description Corresponding

data type

(indicate in

OBX‐2)

Corresponding  observation

value EXAMPLE OR code table

to use (value in OBX‐5)

Vaccine Funding Source – Use in OBX‐3 to indicate that OBX‐5 will contain the funding

source for a given immunization.

                                                      

35 All VAERS-only items removed. 

36 This material contains content from LOINC® (http://loinc.org). The LOINC table 

and LOINC codes are copyright © 1995-2010, Regenstrief Institute, Inc. and the 

Logical Observation Identifiers Names and Codes (LOINC) Committee.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A37

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 “NOS” as needed.) 

38890-0 Component Vaccine Type (CE) HL70292 

(CVX codes – use the codes 

described as “NOS” as needed.) 

Contraindications, Precautions, Indications and Immunities

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

29768-9 Date Vaccine Information 

Statement Published 

(TS) 19900605 

29769-7 Date Vaccine Information 

Statement Presented 

(TS) 199307311615 

Forecasting and Evaluating Immunizations
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A38

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 

30982-3 

30981-5 – Earliest date to 

give 

30982-3 – Reason applied 

by forecast logic to project 

this vaccine 

(TS) 

(CE) or (ST) 

19980522 

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

The following value sets replace a number of NIP tables. These have been registered in

the CDC local value set, CDCPHINVS.  Where appropriate, existing codes are used.  For
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A39

example SNOMED codes are used for some contraindications.  Local codes (VXCxx) will

be replaced as new SNOMED codes are published.

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.

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:  

|PHC70^Private funds^CDCPHINVS|

|OTH^Other^NULLFL|
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A40

NIP‐defined NIP004 ‐ Contraindications, Precautions, and Immunities  

This table has been replaced by separate tables for contraindications, 

indications, reactions and immunities 

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 

VXC23

current fever with moderate‐

to‐severe illness

current fever with

moderate‐to‐severe

illness CDCPHINVS

16 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A41

Concept 

Code  

Concept Name Definition HL7 Table 

0396 Code 

V 2.3.1 Value 

NIP004 

VXC24

current acute illness,

moderate to severe (with or

without fever) (e.g., diarrhea,

otitis media, vomiting)

current acute illness,

moderate to severe

(with or without fever)

(e.g., diarrhea, otitis

media, vomiting) CDCPHINVS

21 

27624003 Chronic disease (disorder)

chronic illness (e.g.,

chronic gastrointestinal

disease) SCT

22 

VXC25

History of Arthus

hypersensitivity reaction to a

tetanus‐containing vaccine

administered < 10 yrs

previously

History of Arthus

hypersensitivity

reaction to a tetanus‐

containing vaccine

administered < 10 yrs

previously CDCPHINVS

VXC26

underlying unstable, evolving

neurologic disorders,

(including seizure disorders,

cerebral palsy, and

developmental delay)

underlying unstable,

evolving neurologic

disorders, (including

seizure disorders,

cerebral palsy, and

developmental delay) CDCPHINVS

37 

VXC27

immunodeficiency due to any

cause, including HIV

(hematologic and solid tumors,

congenital immunodeficiency,

long‐term immunosuppressive

therapy, including steroids)

immunodeficiency due

to any cause, including

HIV (hematologic and

solid tumors,

congenital

immunodeficiency,

long‐term

immunosuppressive

therapy, including

steroids) CDCPHINVS

36 

77386006

Patient currently pregnant

(finding)

pregnancy (in

recipient) SCT

39 

302215000

Thrombocytopenic disorder

(disorder)

thrombocytopenia

SCT

40 

161461006 History of ‐ purpura (situation)

thrombocytopenic

purpura (history) SCT

41 

Examples:

|VXC18^allergy to bakers yeast^CDCPHINVS|

|77386006^patient currently pregnant^SCT|
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A42

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)

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.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A43

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 (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
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A44

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

Concept 

Code  

Concept 

Name 

Definition HL7 

Table 

0396 

Code 

V 2.3.1 Value 

NIP004 

409498004 Anthrax

(disorder)

History of anthrax infection. SCT
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A45

Concept 

Code  

Concept 

Name 

Definition HL7 

Table 

0396 

Code 

V 2.3.1 Value 

NIP004 

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

398102009 Acute

poliomyelitis

(disorder)

History of polio infection. SCT 30 
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/31/2011

Appendix A - A46

Concept 

Code  

Concept 

Name 

Definition HL7 

Table 

0396 

Code 

V 2.3.1 Value 

NIP004 

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

Examples:

|38907003^Varicella infection^SCT|
 

Appendix B 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.0) 

Last Updated on 2/1/2010

 

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
Appendix B 1 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

Immunization History Definition

Table 12-Immunization History Definition 

An immunization history consists of the following components:

Data Element NVAC37

Core Data

Element38

HL7 Message Location

Client identifiers

ID39

Name

Mother’s maiden name

Optional

Required

Required

PID‐3

PID‐5

PID‐6

Client demographics

Race

Ethnicity

Gender

Birth date

Death date

Birth order

Multiple Birth Indicator

Birth State

Birth facility

Required

Required

Required

Required

N/A40

Required

N/A

Required

Optional

PID‐10

PID‐22

PID‐8

PID‐7

PID‐29

PID‐24

PID‐25

PID‐11

Client locators

address  

phone (and email)

Optional

Optional

PID‐11

PID‐13

Client IIS status (MOGE) Optional PD1‐16

Client eligibility for vaccine

funding (VFC)

Optional PV1‐20

Client primary language Optional PID‐15

Client privacy request

(protection of information)

N/A PD1‐12

Client desires on being

contacted for reminders

N/A PD1‐11

Next of kin name, address and

phone number

Optional NK1 Segment

History of vaccine preventable Optional OBX segment

                                                      

37 National Vaccine Advisory Committee 38 Required means that a system must be able to store if known. Optional means that a system 

should be able to store if known. 

39 ID is a list of all important identifiers like IIS id, medical record number, birth registration 

number and SSN. 

40 N/A indicates that it is not currently in the NVAC core data elements, 
Appendix B 2 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

An immunization history consists of the following components:

Data Element NVAC37

Core Data

Element38

HL7 Message Location

disease such as Varicella

Immunization records RXA segment

Vaccine Required RXA‐5

Vaccine lot Required RXA‐15

Vaccination date Required RXA‐4

Quantity N/A RXA‐6 and RXA‐7

Vaccine provider

Administering

Organization

Ordering

clinician

Clinic site of

administration

Optional

RXA‐10

ORC‐12

RXA‐11

Manufacturer Required RXA‐17

Vaccine information

sheet date

N/A OBX segment

Injection site Optional RXR‐2

Administration route N/A RXR‐1

Vaccine Expiration Date Optional RXA‐16

Funding source N/A OBX segment

Record source (historical

indicator)

Optional RXA‐9

Reactions to vaccination N/A OBX segment

Refusal of vaccination N/A RXA‐18 and RXA‐20

Client conditions that impact

forecasting and dose validation

N/A OBX Segment

Next dose forecast N/A OBX Segment

Validation of recorded dose

based on schedule

recommendations

N/A OBX Segment

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.

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.

Appendix B 3 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 
Appendix B 4 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

                                                      

a. Determine if message meets HL7 rules

b. Validate based on local business rules41

5. Seek matching client in receiver data base

a. No match is found42

i. Add the client to the receiver database.

ii. Send acknowledgement message43

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

ii. Protection indicator = Y

1. Do not integrate record into receiver data base

2. Send acknowledgement45

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 acknowledgement46

6. Send acknowledgment to sending system

7. Sending system accepts acknowledgement message.47

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

41 See Send Error in ACK for dealing with errors if either of these two tasks identifies problems. 42 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. 

43 See Send Acknowledgement with no error. 44 Locally, this may be known as the sharing indicator. In this case, the equivalent value is 

sharing = N. 

45 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. 46 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. 

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

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

produced a chapter of best practices on this process. This is available on the American

Immunization Registry Association web site (www.immregistries.org).

The following example messages represent straightforward immunization history

messages.  They do not illustrate dealing with specific use cases, such as messaging

reactions, client specific conditions or vaccine forecasts.  Clearly, these may be

components of a VXU, but will be addressed separately to simplify the messages.

It is important to reiterate here that conformant systems should be able to successfully

populate and process the VXU message segments and fields identified as Required or

Required but may be empty.  They should be able to populate and process conditional

items when the predicate conditions are met.  If segments or fields are optionally

repeating, they should be able to gracefully handle the repetitions.  Systems that do not

conform to these expectations risk missed data.   

Supported Message Segments

The following table lists the segments and their usage.

Segment Cardinality Usage48 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] RE

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]49 R Each RXA is the child of

                                                      

48 R means it is required. RE means it is required if known/available. X means not supported in 

this Guide. O means optional. 

49 Each ORC must have 1 RXA and each RXA belongs to exactly 1 ORC. 
Appendix B 6 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

on ORC

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

Figure 7-Segment Usage 

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.

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> 

ORC|RE||197023^DCS|||||||^Clerk^Myron|||||||DCS^Dabig Clinical 

System^StateIIS<CR> 
Appendix B 7 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

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 vaccine funding source and client eligibility

status:

Immunization messages must be able to convey the eligibility status of a recipient when

they received immunizations.  In addition, these messages must be able to include

information on the funding source for an immunization.  While these are related, they

are separate concepts.   

Eligibility status:

The PV1 segment shall be used to convey eligibility status, as it has in the past.  The PV1‐

20, Financial Class, is a repeating field of FC data type.  This data type is composed of

two components.  The first is financial class code (data type IS) and points to a user

defined table (0064).  The second component is Effective Date and in our case indicates

when the financial class was determined.  The format is displayed below.

|Financial class^Effective date|

A repetition is indicated by the repetition symbol, ~.  The repetition follows the ~.  If a

list of eligibility is sent, the repetitions should be unique on financial class and effective

date.  That is, two different financial classes may have the same effective date.  

Similarly, two different effective dates may have the same financial class.

Only the current eligibility needs to be sent in a message, but the history of eligibility

should be stored.  Receiving systems should be able to accept either current eligibility or

complete history of eligibility.
Appendix B 8 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

Eligibility status 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 and assessment dates.  In the past, some systems have only kept the

most current status.  This prevents accurate reporting.

Sending One Financial Class With Date: 

The following example shows the PV1 segment with one financial class and effective

date.

MSH... 

PID... 

PV1|1|R||||||||||||||||||V02^20090531<CR> 

Sending Two Financial Classes With Dates: 

The following example shows the PV1 segment with two different financial classes and

their effective dates.  The first financial class is from the standard VFC classes and the

second is a hypothetical financial class.  Both were evaluated on the same day.

MSH... 

PID... 

PV1|1|R||||||||||||||||||V02^20090531~IHS02^20090531<CR> 

If repetition is used and indicates 2 financial classes on the same 

date, they should not be mutually exclusive. (i.e. Medicaid and not 

eligible for VFC) 

Documentation of local usage will greatly facilitate 

interoperability. This documentation should include both local 

values in table 0064 and business rules for processing. Local codes 

should express information about the client at the time of a visit 

and not about payment source for the immunizations given that day. 

Funding Source:

The funding source of a vaccination indicates who paid for a given immunization.  Table

CDCPHINVS local values Immunization Funding Source (Value set OID

2.16.840.1.114222.4.11.3287) lists the categories. Local systems may support additional

values, but must document them.   

The following table lists the value set.

Value Label Definition 

PHC70 Private funds Immunization was 
Appendix B 9 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

funded by private 

funds, including 

insurance. 

VXC1

Federal funds Immunization was 

funded with public 

funds from the 

federal government. 

VXC2

State funds Immunization was 

funded with public 

funds from a state. 

PHC68

Military funds Immunization was 

paid for with military 

funds. 

VXC3

Tribal funds Immunization was 

paid for with tribal 

funds. 

OTH

Other Immunization was 

paid for by funding 

not listed above. 

UNK

Unspecified Funding source for 

immunization is not 

specified. 

The funding source may be linked to each immunization record, using an OBX segment.

(See note below for the supporting infrastructure on the system side.)

Note that the order of OBX segments is not specified.  They may appear in any order.  So

one immunization may have an OBX listing funding source, followed by an OBX

indicating an adverse reaction.  The order may be reversed and receiving system should

gracefully handle them in either case.

Observation sub‐id (OBX‐4) groups related observations.

The following example shows an immunization record with one funding source and a

second, historical record of an immunization without a funding source.  It does not show

eligibility, which would be in the PV1 segment.

MSH.... 

PID... 

ORC|RE|197027^DCS|1970237^DCS|||||||^Clerk^Myron||^Pediatric^MARY^^^

^^^^L^^^^^^^^^^^MD<CR> 

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> 
Appendix B 10 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

OBX|1|CE|30693-3^funding source for 

immunization^LN|1|PHC70^Privately 

funded^CDCPHINVS||||||F|||20090415<CR> 

ORC|RE|197023^DCS|197023^DCS|||||||^Clerk^Myron||^^^^^^^^^L|||||DCS^

Dabig Clinical System^StateIIS<CR> 

RXA|0|1|20090415132511|20090415132511|31^Hep B Peds 

NOS^CVX|999||||||||||| <CR> 

In the example above, we see that the first immunization in the message was funded by

Private funding.  The second immunization in the message does not have funding source

included, probably because it is not able to be determined, since it is a historic record of

an immunization.

Supporting infrastructure:

In order to support this level of detail, the funding source for each dose of vaccine given

must be recorded in the database.  There are a number of potential solutions, but one

logical one is to build on existing inventory management capabilities.  If each

immunization is pulled from a specific lot of vaccine and that lot has a funding source

associated, then the funding source may be determined.  This would require that the

inventory management system would need to separate vaccine lots with the same lot

number, but different funding.   

Example VXU #3 ‐ Include immunization history evaluation and forecast in

VXU

The LOINC codes and value sets are still in the process of development. The 

basic concepts should not change. 

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.
Appendix B 11 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

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.

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

                                                      

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 12 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

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

Reason code This can indicate

why a dose is not

valid or that the

30982‐3 Optional
Appendix B 13 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

Data

element

Use OBX‐3 Value Optionality for

meaningful evaluation

and forecast50.

recommendation

was changed

because of a special

circumstance.   

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.   

The basic structure for including evaluation in a message is:

RXA‐the immunization and vaccine

OBX‐vaccine group

OBX‐the schedule

OBX‐series used

OBX‐dose number in series (ordinal position)

OBX‐doses in series

OBX‐dose validity

OBX‐series status

The basic structure for evaluation of combination vaccine components is:

RXA‐the immunization and vaccine

OBX‐vaccine group 51

                                                      

51 All of the related observations are linked to the vaccine group using the OBX-4, observation 

sub-id. 
Appendix B 14 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

                                                      

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:

RXA‐vaccine, CVX‐NOS (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.

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.

52 All of the related observations are linked to the vaccine group using the OBX-4, observation 

sub-id. 
Appendix B 15 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

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

Combination vaccine:

RXA|0|1|20091010||94^MMRV^CVX|0.5|ML^^ISO+||||||||EZ342|20111001|MSD^^MVX<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 
Appendix B 16 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

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

RXR|C28161^IM^NCIT^IM^IM^HL70162|<CR> 

OBX|1|TS|30956-7^vaccine type^LN|1|17^HIB, NOS^CVX||||||F<CR> 

OBX|1|CE|59779-9^Immunization Schedule 

used^LN|1|VXC16^ACIP^CDCPHINVS||||||F|||20090415<CR> 

OBX|1|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.

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|1|N|59782-3^number of doses in series^LN|1|1||||||F|||20090415<CR> 

Reporting Next Dose Recommendation Dates:

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:

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
Appendix B 17 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

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.

OBX|1|TS|30956-7^vaccine type^LN|1|17^HIB, NOS^CVX||||||F<CR> 

OBX|1|CE|59779-9^Immunization Schedule 

used^LN|1|VXC16^ACIP^CDCPHINVS||||||F|||20090415<CR> 

OBX|1|DT|30980-7^Date vaccination 

due^LN|1|20090615||||||F|||20090415<CR> 

OBX|1|DT|59777-3^Latest date to give 

vaccine^LN|1|20100615||||||F|||20090415<CR> 

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.

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
Appendix B 18 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

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

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<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:
Appendix B 19 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

A contraindication is any physical condition, current medication or other factor that

indicates that a person should not receive an immunization that may be associated with

the contraindication.  This contraindication may be temporary or permanent.

LOINC: 30945-0

Examples:

OBX|1|CE|30945-0^Vaccination contraindication^LN|1|91930004^allergy 

to eggs^SCT||||||F|||20090415<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> 
Appendix B 20 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

                                                      

RXA|0|1|20090412|20090412|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> 

OBX|1|CE|31044-1^reaction^LN|1|VXC12^fever > 40.5 

C^CDCPHINVS||||||F|||20090415<CR> 

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. 
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 two pieces of information about each

event.   

• the date that the VIS was presented to the client/parent.   

• the publication date of the VIS that was presented.

These are carried in separate OBX segments associated with a vaccination event (RXA).  

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.

There is a change in how OBX‐3 uses LOINC codes. It no longer uses subcomponent

LOINCs to group information.  In the old Guide, 38890-0&29768-9 in OBX-3 indicated the 

vaccine group and VIS Publication Date. The first component is unacceptable in version 2.5.1. 

Example 1‐Single vaccine

RXA|0|1|20091010||03^MMR^CVX|0.5|ML^^ISO+||||||||EZ342|20111001|MSD^^MVX<CR> 

OBX|1|TS|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.

Appendix B 21 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 
Appendix B 22 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

Example 2‐Combination vaccine

RXA|0|1|20091010||94^MMRV^CVX|0.5|ML^^ISO+||||||||EZ342|20111001|MSD^^MVX<CR> 

OBX|1|TS|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|TS|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> 

This example shows that a person received an MMRV on 10/10/2007.  They received 2

VIS documents, one for MMR and one for Varicella.  The publication date for the MMR

was 10/10/2007 and the Varicella on 10/10/2009.  Note the use of OBX‐4 to group

related data together.

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.  
Appendix B 23 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

This document does not specify the order of the lot numbers.

For example, if we needed to include an immunization record where the vaccine was

Pentacel, we would put the lot number from the first component in sequence 15,

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

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:

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.
Appendix B 24 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

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.   

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> 
Appendix B 25 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

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.

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

Figure 8--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.

Appendix B 26 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 
Appendix B 27 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

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.

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

b. Validate based on local business rules54

                                                      

Appendix B 28 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

54 The process for responding is documented below. 
Appendix B 29 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

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 create s 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.

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 

                                                      

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 30 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

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 

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> 
Appendix B 31 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

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^HL70292|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.
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|Z343^request Immunization history^HL70471<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|Z343^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 32 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 
Appendix B 33 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

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

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 
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> 

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 

                                                      

Appendix B 35 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

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 36 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

~@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.  

In the case where the IIS identifier is returned by the MPI, the VXU message sent to the

IIS may contain the IIS ID  
Appendix B 37 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

A user may believe that a candidate does exist and may choose to refine the query

parameters and requery.

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> 

MSA|AR|<CR> 

This message indicates that the application rejected the message. 
Appendix B 38 

HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 

Last Updated on 1/25/2011

 

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|Z343^request Immunization history^HL70471<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