Last Reviewed February 2016
 

 

 

 

Implementation Guide for Immunization Data Transactions 

using Version 2.3.1 of the Health Level Seven (HL7) 

Standard Protocol 

Implementation Guide Version 2.2 

June 2006 

Centers for Disease Control and Prevention 

National Center for Immunization and Respiratory Diseases 

Immunization Services Division 

Immunization Information Systems Support Branch 

DEPARTMENT OF HEALTH AND HUMAN SERVICES 

SAFER ∙ HEALTHIER ∙ PEOPLETM 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Version 2.2 June 2006 Notes 

This document replaces previous National Immunization Program (NIP) Guidelines for Immunization Data 

Transactions versions dated September 2002 and earlier. This version 2.2 (referenced herein as the 

Guide) incorporates changes to the 2002 Guide. The revised, added, or deleted material is indicated by 

vertical lines in the margin, and is summarized in the table below the contact information following this 

section. Additionally, Appendix 5 provides additional narrative and shows the new material and previous 

version's material 

Any needed additions or revisions to the Guide have been coordinated with the American Immunization 

Registry Association (AIRA). Previous changes were coordinated with the Committee on Immunization 

Registry Standards for Electronic Transactions (CIRSET), whose functions have now been merged with 

AIRA. Members have indicated their intention to implement the Guide as written and to resist adding Z 

segments or otherwise changing the implementation to one that is not consistent with this document. 

To claim conformance with this Guide, registries must support the four immunization data transaction 

messages described on page 3: the VXQ (Query for Vaccination Record), the VXR (Response to 

Vaccination Query Returning the Vaccination Record), the VXX (Response to Vaccination Query 

Returning Multiple PID Matches), and the VXU (Unsolicited Vaccination Record Update). As necessary, 

registries should support the use of ACK and QCK messages described in the Guide. For registries that 

are developing HL7-based electronic VAERS reporting, the ORU message definition supplied in the 

Guide is the standard for compliance. Supporting all four VX* message types is also a recommended 

requirement for registry certification. 

Registries are encouraged to implement HL7 communication with providers and data sources other than 

registries. In these cases, the four VX* messages mentioned above may alone prove insufficient. ADT 

messages are discussed in this document and are available for communication with providers and other 

non-registry data sources. However, even with non-registry data sources, the VX* messages are 

preferred when possible and appropriate. 

A conformant registry must also follow the HL7 protocol as described in the standard and further defined 

in this Guide. Registries should include segments and fields required by HL7 exactly as defined by the 

standard and described in this Guide. For example, the third field in the Patient Identification Segment 

(PID-3) is required by HL7 to contain the list of patient identifiers, identified by type code. It can retain an 

unlimited number of identifiers. Registries should not restrict the utility of this field in their implementation 

by arbitrarily limiting the supported identifiers to their own registry identifier. Other functions described 

herein, such as reporting vaccine adverse events using HL7, are provided as information to registries. If 

these functions are implemented, however, registries should follow the guidelines as written. 

The HL7 2.3.1 standard version is the standard for registries and for registry certification. XML versions 

of the HL7 versions 2.3, 2.4 and 2.5 exist and are used by registries. These cannot, however, be 

considered a substitute for the standard version embodied in this document. Any registry using an XML 

approach has the responsibility to be able to communicate with other registries or providers using the HL7 

standard version. In order to be certified, any registry using an XML approach must be able to receive, 

process, and respond using the standard HL7 2.3.1 message test sets. 

This Guide is intended for use by immunization registries that want to participate in a strictly-defined 

record exchange agreement that limits the amount of optionality normally expected when using the HL7 

standard. The Guide describes the most frequently used segments in their entirety, while giving a 

minimum description of segments containing only a few useful fields for registries. The Guide fully 

describes the fields within the segments used frequently by immunization registries, while the others are 

omitted in this document. With this limited scope, this Guide can in no way serve as a substitute for a 

thorough study of the entire set of HL7 specifications for electronic data interchange in health care 

environments. For more complete information about HL7, visit the website at www.hl7.org 
 

 

 

 

 

 

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.http://www.immregistries.org 

For information about this Guide, contact: 

Ron Van Duyne 

404-639-8962 

rvanduyne@cdc.gov 

Warren Williams 

404-639-8867 

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/nip/registry 

This Implementation Guide is in the public domain and may be used and reprinted without permission; 

citation as to source, however, is appreciated. copies may be downloaded from the National Center for 

Immunization and Respiratory Diseases website 

http://www.cdc.gov/nip/registry/st_terr/tech/tech.htm#stds. 

Summary of Revised, Added, or Deleted Material (from Version 2.1, September 2002) 

(Note: See Appendix 5 for narrative about updates listed below) 

Page(s) 

Deleted 

Page(s) 

Inserted 

Page# Section Number - Summary of Change in Material/Topic 

Follows title 

page Version 2.2 Notes 

Follows 

Notes Contact Information update 

3 Immunization Data Transaction Messages: clarification 

16 

7.2.1 Unsolicited Transmission of an Observation (ORU) Example VAERS ORU 

Message: VAERS Item 2 new LOINC for sibling replacing separate LOINCs for 

brother and sister 

52 3.3.3 - PV1 Segment clarification re: VFC or Mediciad Eligibility 

75.1-75.2 75.1 7.3.2.4 - OBX Observation sub-ID for Combination vaccines with possible 

separate VISs for individual vaccine components (page 75.2 continues old text) 

80 3.2 Patient Administration Message Definitions & Use of Optional 

Admission/Discharge/Transfer (ADT) Messages: clarification 

A1-12 to 

A1-17 

HL7-defined Tables 0227 & 0292 - Current MVX & CVX code tables replace older 

versions 

A1-24 to 

A1-27 

NIP defined Table NIP003 - Observation Identifiers: Dose Number for 

Combination Vaccines & Vaccine Component (of a combination vaccine) 

clarification & observation examples furnished 

A1-26 to 

A1-27 

NIP defined Table NIP003 - Observation Identifiers: Examples furnished for 

Vaccines Due Next & VAERS ORU Message; new LOINC for sibling replacing 

separate LOINCs for brother and sister for VAERS ORU Message 

A5-1 to 

A5-2 Added narrative about updates 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

TABLE OF CONTENTS 

HL7 DEFINITIONS........................................................................................................................................ 1
 

BASIC MESSAGE CONSTRUCTION RULES............................................................................................. 2
 

IMMUNIZATION DATA TRANSACTION MESSAGES................................................................................ 3
 

VXQ Example #1 (Query with many identifiers)................................................................ 5
 

VXQ Example #2 (Query with only a name identifier)....................................................... 5
 

4.14.2	 RESPONSE TO VACCINATION QUERY RETURNING MULTIPLE PID MATCHES (VXX).......................6
 

VXX Example (Response with many matches)................................................................. 6
 

4.14.3	 RESPONSE TO VACCINATION QUERY RETURNING THE VACCINATION RECORD (VXR) ...................7
 

VXR Example #1 (Response to VXQ Example #1)........................................................... 7
 

VXR Example #2 Returning Vaccines Due Next Data from the Registry Algorithm ......... 9
 

4.14.4	 UNSOLICITED VACCINATION RECORD UPDATE (VXU) .................................................................11
 

VXU Example #1 (Message with only required fields valued) ........................................11
 

VXU Example #2 (Unsolicited update showing use of optional segments) ....................11
 

7.2.1	 UNSOLICITED TRANSMISSION OF AN OBSERVATION (ORU) ..........................................................13
 

Example VAERS ORU Message.....................................................................................15
 

2.13	 ACKNOWLEDGMENT MESSAGES (WITH ERRORS OR FINDING NO MATCH TO QUERY PARAMETERS)18 

General Acknowledgment Example #1 (ACK with error) ................................................18
 

Query General Acknowledgment Example #2 (QCK with no matching records found)..18
 

SEGMENTS 19 

2.24 MESSAGE CONTROL SEGMENTS ...........................................................................................20
 

2.24.1	 MESSAGE HEADER (MSH) SEGMENT.............................................................................................20
 

2.24.2	 MESSAGE ACKNOWLEDGMENT (MSA) SEGMENT..........................................................................25
 

2.24.3	 ERROR (ERR) SEGMENT ................................................................................................................27
 

2.24.22	 QUERY ACKNOWLEDGMENT (QAK) SEGMENT..............................................................................28
 

2.24.4	 QUERY DEFINITION (QRD) SEGMENT............................................................................................29
 

2.24.5	 QUERY FILTER (QRF) SEGMENT....................................................................................................32
 

2.23.3 HL7 BATCH PROTOCOL............................................................................................................35
 

2.24.11	 FILE HEADER (FHS) SEGMENT ......................................................................................................35
 

2.24.12	 FILE TRAILER (FTS) SEGMENT ......................................................................................................36
 

2.24.13	 BATCH HEADER (BHS) SEGMENT..................................................................................................37
 

2.24.14	 BATCH TRAILER (BTS) SEGMENT..................................................................................................38
 

3.3 PATIENT ADMINISTRATION MESSAGE SEGMENTS .............................................................39
 

3.3.2	 PATIENT IDENTIFICATION (PID) SEGMENT ....................................................................................39
 

3.3.9	 PATIENT ADDITIONAL DEMOGRAPHIC (PD1) SEGMENT ................................................................47
 

3.3.3	 PATIENT VISIT (PV1) SEGMENT THE PV1 SEGMENT IS USED TO SEND VISIT-SPECIFIC
 

INFORMATION. ...............................................................................................................................51
 

3.3.5	 NEXT OF KIN (NK1)/ASSOCIATED PARTIES SEGMENT...................................................................54
 

6.4 FINANCIAL MANAGEMENT MESSAGE SEGMENTS ..............................................................58
 

6.4.6	 INSURANCE (IN1) SEGMENT ..........................................................................................................58
 

6.4.7	 INSURANCE ADDITIONAL INFORMATION (IN2) SEGMENT ..............................................................58
 

6.4.8	 INSURANCE ADDITIONAL INFORMATION, CERTIFICATION (IN3) SEGMENT....................................58
 

4.8 PHARMACY/TREATMENT ORDERS.........................................................................................59
 

4.3.1	 COMMON ORDER (ORC) SEGMENT ...............................................................................................59
 

4.8.3	 PHARMACY/TREATMENT ROUTE (RXR) SEGMENT........................................................................62
 

4.8.14	 PHARMACY/TREATMENT ADMINISTRATION (RXA) SEGMENT ......................................................63
 

7.3 OBSERVATION REPORTING SEGMENTS ...............................................................................70
 

7.3.2	 OBSERVATION/RESULT (OBX) SEGMENT ......................................................................................73
 
 

 

 

 

 

 

 

 

 

 

 

 

 

2.24.15 NOTES AND COMMENTS (NTE) SEGMENT.............................................................................79
 

3.2.28	 ADMISSION/DISCHARGE/TRANSFER AND ACKNOWLEDGMENT (ADT/ACK) - ADD PERSON
 

INFORMATION (EVENT A28)...........................................................................................................81
 

3.2.29	 ADMISSION/DISCHARGE/TRANSFER AND ACKNOWLEDGMENT (ADT/ACK) -DELETE PERSON
 

INFORMATION (EVENT A29)...........................................................................................................81
 

3.2.30	 ADMISSION/DISCHARGE/TRANSFER AND ACKNOWLEDGMENT (ADT/ACK) -MERGE PERSON
 

INFORMATION (EVENT A30)...........................................................................................................82
 

3.2.31	 ADMISSION/DISCHARGE/TRANSFER AND ACKNOWLEDGMENT (ADT/ACK) -UPDATE PERSON
 

INFORMATION (EVENT A31)...........................................................................................................82
 

3.3.1	 EVENT TYPE (EVN) SEGMENT.......................................................................................................82
 

3.3.8 MERGE PATIENT INFORMATION (MRG) SEGMENT ........................................................................84
 

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

APPENDIX 3: RECOMMENDED CORE DATA SET FOR IMMUNIZATION REGISTRIES.................... 1
 

APPENDIX 4: VACCINE ADVERSE EVENT REPORTING SYSTEM (VAERS) .................................... 1
 

APPENDIX 5: NARRATIVE REVIEW OF REVISED, ADDED, OR DELETED MATERIAL SHOWING
 

NEW AND PREVIOUS VERSIONS WITH SPECIFIC CHANGES MADE (UNLESS OTHERWISE
 

NOTED) 1
 

REVISED, ADDED OR DELETED TEXT (VERSION 2.2, JUNE 2006) PAGE 3 ....................................... 1
 

IMMUNIZATION DATA TRANSACTION MESSAGES................................................................................ 1
 

IMMUNIZATION DATA TRANSACTION MESSAGES................................................................................ 1
 

REVISED, ADDED OR DELETED TEXT (VERSION 2.2, JUNE 2006) PAGE 75.1 .................................. 2
 

REVISED, ADDED OR DELETED TEXT (VERSION 2.2, JUNE 2006) PAGE 80 ..................................... 3
 

3.2 PATIENT ADMINISTRATION MESSAGE DEFINITIONS............................................................. 4
 

ii 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

HL7 Definitions 

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

is a series of segments in a defined sequence, with a message type and a trigger event. 

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. 

Field: A field is a string of characters. 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. Optional data fields may be omitted. 

Whether a field is required, optional, or conditional in a segment is specified in the segment attribute 

tables. The designations are: R=Required, O=Optional, C=Conditional on the trigger event or on some 

other field(s). The field definition should define any conditionality for the field: X=Not used with this trigger 

event, B=Left in for backward compatibility with previous versions of HL7. A maximum length of the field 

is stated as normative information. Exceeding the listed length should not be considered an error. 

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. 

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. 

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. Appendix 2 provides a complete listing of data 

types used in this document and their definitions. 

Delimiters: The delimiter values are given in MSH-2 and used throughout the message. Applications 

must use agreed upon delimiters to parse the message. The recommended delimiters for immunization 

messages are <CR> = Segment Terminator; | = Field Separator; ^ = Component Separator; & = SubComponent Separator; ~ = Repetition Separator; and \ = 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. 

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. 

1 
 

 

 

Basic Message Construction Rules 

Encoding Rules for Sending
 

- Encode each segment in the order specified in the abstract message format.
 

- Place the Segment ID first in the segment.
 

- Precede each data field with the field separator. 

- Encode the data fields in the order and data type specified in the segment definition table. 

- End each segment with the segment terminator. 

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

Encoding Rules for Receiving 

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

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

- If data fields are found at the end of a data segment that are not expected, ignore them; this is not an 

error. 

2 
 

 

 

 

 

 

 

 

IMMUNIZATION DATA TRANSACTION MESSAGES 

Information systems that maintain immunization records need to be able to transmit patient-specific 

immunization histories electronically to other systems to allow healthcare providers to have access to 

these records at the time health care is given. Electronic tracking of immunization records also allows 

providers to track their own progress in reaching age-appropriate immunization coverage levels easily 

and efficiently. 

The data transmissions between registries will occur as the result of four activities: (1) a query from one 

system for a patient's vaccination record that is held in another system (VXQ); (2) a response to a query 

containing multiple patient "matches" to the query, but not returning vaccination records (VXX); (3) a 

response to a query containing the vaccination record (VXR); and (4) an unsolicited update to a 

vaccination record (VXU). 

Trigger event V01 will initiate the Query for Vaccination Record (VXQ) message. Two responses are 

possible: (1) event type V02--Response to Vaccination Query Returning Multiple PID Matches (VXX), or 

(2) event type V03--Response to Query Returning Vaccination Record (VXR). Trigger event type V04 will 

initiate the Unsolicited Update to Vaccination Record (VXU) message. Addition of new patients can be 

accomplished by using either VXU (V04) or ADT. The interaction model at the end of this section 

graphically depicts this process. 

Version 2.3.1 of the HL7 Standard gives the following explanation in Section 2.2.4, Queries. “In all cases, 

the HL7 Standard consists of a simple exchange of messages between a pair of applications: the 

unsolicited update and its acknowledgment, or the query and its response. The underlying operational 

model is that of a client and a server. An application interfaces with another application using an event 

code that identifies the transaction. The other application responds with a message that includes data or 

an error indication. The initiating application may receive a reject status from the other application or from 

lower level software indicating that its message was not received correctly.” 

For standard immunization exchanges, the VXQ message (event V01) querying for a patient’s

immunization record and its two standard responses, VXX (event V02) reporting multiple matches to the 

query parameters, or VXR (event V03) reporting the specifically requested patient immunization history, 

are defined in Sections 4.12 through 4.14 of the HL7 Standard. In the event that a query was not 

received correctly, the response would be an ACK (see Sections 2.13, 2.13.1, and 2.18.1 of the Guide). 

In the event that a query was received and processed correctly, but no matching records were found, the 

response would be a QCK (see Sections 2.13, 2.13.1, and 2.18.1 of the Guide). In the case of an 

unsolicited update to a record, a VXU (event V04) message would be sent. The response to the VXU is 

an ACK, or Acknowledgment Message (see Sections 2.13, 2.13.1, and 2.18.1 of the Guide). 

Each message is defined in special notation called the message syntax that lists the allowed segments by 

their three-letter identifiers in the order they will appear in the message. Braces, {}, indicate that the 

enclosed segment(s) may repeat one or more times, and brackets, [ ], indicate that the enclosed 

segment(s) is optional. The syntax and an example of each of the defined messages follow. In HL7 

transmissions, messages are transmitted as a single string of ASCII characters. The segment is 

terminated with the carriage return symbol, the ASCII Hex0D. In the examples in this document, the 

three-letter segment identifiers are bolded, each segment begins on a new line, and carriage return 

segment endings are shown as <CR> to allow human reading. In a message transmission, an HL7 

parser “reads” the characters that are transmitted, using the delimiters to divide fields and components. 

The notation of message and event type in MSH-9 informs the parser which segments will follow, which 

segments are required, and which can repeat. Similarly, each segment begins with its three-letter 

identifier, alerting the parser to which fields will follow, which fields are required, and which can repeat. 

Each segment is defined in the standard, with each field defined. Required fields and allowed field or 

component repetitions are so noted. For the purposes of this document, the optional segments (PD1, 

PV1, PV2, IN1, IN2, IN3, RXR, OBX, and NTE) and optional fields within the messages are defined only if 

needed for immunization registries or if required by HL7. 

3 
 

VXQ (Query for Vaccination) )Record) 

 

 

 

 

 

 

 

 

 

 

 

Private Provider–

Application “A”

Possible responses: 

Private Provider–

Application “A”

Private Provider –

Application “A”

Possible Response: 

Private Provider –

Application “A”

Private Provider –

Application “A”

Possible Response: 

Private Provider –

Application “A”

VXQ (Query for Vaccination Record) 

[Uses components in QRF-5 to match record] 

1. VXR (Response to Vaccination Query
 

Returning the Vaccination Record)
 

2. VXX (Response to Vaccination Query 

Returning Multiple PID Matches)
 

[Indicates several possible matches – No 

medical data returned]
 

3. ACK (General Acknowledgment)
 

[Receiving registry was able to receive the 

message. Can indicate errors]
 

4. QCK (Query General Acknowledgment - no 

matching records)
 

[Receiving registry was not able to match 

patient]
 

VXU (Unsolicited Vaccination Record Update) 

[Represents a regular report to a registry that a shot 

has been given – no information requested] 

ACK (General Acknowledgment) 

[Receiving registry was able to receive the 

message. Can indicate errors] 

ORU (Unsolicited Transmission of an Observation) 

[Represents a widely used message that can report 

various information to a registry—commonly used for 

electronic laboratory reports. Can be used for 

VAERS reports.] 

ACK (General Acknowledgment) 

[Receiving registry was able to receive the 

message. Can indicate errors] 

Immunization Registry 

– Application “B”

Immunization Registry 

– Application “B”

Immunization Registry 

– Application “B”

Immunization Registry 

– Application “B”

Immunization Registry 

– Application “B”

Immunization Registry 

– Application “B”

The following graphic depicts these dataexchanges: 

4 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4.14.1 Query for Vaccination Record (VXQ) 

Definition: When a health care provider participating in an immunization registry needs to obtain 

a complete patient vaccination record, he will send a query (using a V01 trigger event) to the 

immunization registry for the definitive (last updated) immunization record. 

The query will follow this format: 

VXQ Vaccination Query HL7 Chapter 

MSH Message Header Segment 2 

QRD Query Definition Segment 2 

[QRF] Query Filter Segment 2 

VXQ Example #1 (Query with many identifiers) 

MSH|^~\&||GA0000||MA0000|199705221605||VXQ^V01|19970522GA40|T|2.3.1|||NE|AL|<CR> 

QRD|199705221605|R|I|19970522GA05|||25^RD|^KENNEDY^JOHN^FITZGERALD^JR|VXI^VACCINE 

INFORMATION^HL70048|^SIIS|<CR> 

QRF|MA0000||||256946789~19900607~MA~MA99999999~88888888~KENNEDY^JACQUELINE^ 

LEE~BOUVIER~898666725~KENNEDY^JOHN^FITZGERALD~822546618|<CR> 

In this query, the Georgia state registry (GA0000) is sending a request to the Massachusetts state 

registry (MA0000) for the immunization record of John Fitzgerald Kennedy, Jr., who was born on June 7, 

1990. The request is being sent on May 22, 1997, at 4:05 p.m. All known patient identifiers are included 

in the sample query for use in matching records. These identifiers are defined by their position in the 

QRF segment. The responding system is expected to return all query items in its response. If the 

requestor knew only the patient’s Social Security number and birth date, this is how the QRF-5 would 

appear: 

|256946789~19900607| 

If in addition to the Social Security number and birth date, the patient’s birth state and mother’s current 

and maiden name were known, this is how the QRF-5 would appear: 

|256946789~19900607~MA~~~KENNEDY^JACQUELINE^LEE~BOUVIER| 

Note: Responses when some information has been found in the receiving system are outlined below. If 

there are processing errors or no data are found to match the query, the response message would be a 

general acknowledgment message with errors noted or explanatory information provided. A full 

discussion of error responses follows below. 

VXQ Example #2 (Query with only a name identifier) 

MSH|^~\&||GA0000||MA0000|199705221605||VXQ^V01|19970522GA40|T|2.3.1|||NE|AL|<CR> 

QRD|199705221605|R|I|19970522GA05|||25^RD|^KENNEDY^JOHN|VXI^VACCINE 

INFORMATION^HL70048|^SIIS|<CR> 

This query shows a request for the immunization record using only the patient’s name. A limited number

of identifiers may result in the receiving registry’s matching multiple records. 

5 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4.14.2 Response to Vaccination Query Returning Multiple PID Matches (VXX) 

Definition: In response to a query for the definitive patient vaccination record, the system holding 

the record will return it to the system originating the query. If the query results in multiple "matches;” i.e., 

more than one patient record matches the identifiers in the query so that there is no unique identification, 

the response to the query (a V02 trigger event) will follow this format: 

VXX Vaccination Response HL7 Chapter 

MSH Message Header Segment 2 

MSA Message Acknowledgment Segment 2 

QRD Query Definition Segment 2 

[QRF] Query Filter Segment 2 

{ PID Patient Identification Segment 3 

[ {NK1} ] Next of Kin Segment 3 

} 

VXX Example (Response with many matches) 

MSH|^~\&||MAVACREC||GAVACREC|199705221610||VXX^V02|19970522MA53|T|2.3.1|||NE|AL|<CR> 

MSA|AA|19970522GA40|<CR> 

QRD|199705221605|R|I|19950522GA05|||25^RD|^KENNEDY^JOHN|VXI^VACCINE 

INFORMATION^HL70048|^SIIS|<CR> 

PID|1||||KENNEDY^JOHN|<CR> 

NK1|1|KENNEDY^JANET^MARIE|MTH^MOTHER^HL70063||||||||||||||||||||||||||||||265909900^^^^SS|<CR> 

PID|2||||KENNEDY^JOHN|<CR> 

NK1|1|KENNEDY^JACQUELINE|MTH^MOTHER^HL70063||||||||||||||||||||||||||||||898666725^^^^SS|<CR> 

NK1|2|KENNEDY^JOHN^FITZGERALD|FTH^FATHER^HL70063||||||||||||||||||||||||||||||822546618^^^^SS|<CR> 

PID|3||||KENNEDY^JOHN|<CR> 

NK1|1|KENNEDY^JACKIE^ANN|MTH^MOTHER^HL70063||||||||||||||||||||||||||||||288763102^^^^SS|<CR> 

PID|4||||KENNEDY^JOHN|<CR> 

NK1|1|KENNEDY^J^CILENE|MTH^MOTHER^HL70063||||||||||||||||||||||||||||||190966725^^^^SS|<CR> 

NK1|2|KENNEDY^JACK|FTH^FATHER^HL70063||||||||||||||||||||||||||||||786118768^^^^SS|<CR> 

In this VXX example, each Patient Identification Segment (PID) returns, along with its associated Next of 

Kin/Associated Parties Segment(s) (NK1). In this message, the query contained only the patient name of 

John Kennedy. The responding system, Massachusetts state registry, found four patient matches to the 

query, as reflected in the PID segments. Their associated NK1 segments provide information about the 

patient's associated parties that will allow the querying system, Georgia state registry, to send a more 

precise query. 

Note: To protect confidentiality some registries will not allow this function to return values in any field that 

was not valued in the query. Each registry will implement its own policies in this regard. We recommend 

that registries consult the guidelines for privacy, confidentiality, and security of data on the NIP website at 

<www.cdc.gov/nip/registry>. 

6 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4.14.3 Response to Vaccination Query Returning the Vaccination Record (VXR) 

Definition: When the patient has been uniquely identified (there is only one "match" to the query), 

the response to the query (a V03 trigger event) will follow this format: 

VXR Vaccination Response HL7 Chapter 

MSH Message Header Segment 2 

MSA Message Acknowledgment Segment 2 

QRD Query Definition Segment 2 

[QRF] Query Filter Segment 2 

PID Patient Identification Segment 3 

[PD1] Additional Demographics 3 

[ {NK1} ] Next of Kin/Associated Parties 3 

[PV1 Patient Visit 3 

[PV2] ] Patient Visit Additional Information 3 

[ {IN1 Insurance 6 

[IN2] Insurance Additional Information 6 

[IN3] Insurance Additional Information-Cert. 6 

} ] 

[ { [ORC] Common Order Segment 4 

RXA Pharmacy Administration 4 

[ RXR] Pharmacy Route 4 

[ { OBX Observation/Result 7 

[ {NTE} ] Notes (Regarding Immunization) 2 

} ] 

} ] 

VXR Example #1 (Response to VXQ Example #1) 

The example below reflects a vaccination record response from an immunization registry to a query from an
 

immunization registry in one state to another state registry, but is typical of a response from an immunization
 

registry to one of its participating private health care providers. The example demonstrates the use of optional
 

segments in the message to provide more detail about the patient. Having made an exact match, this response 

provides the immunization history and other information. For example, the OBX segments document the 

Vaccine Information Statement (VIS) date, specify dose number for each component in a combination vaccine, 

record an adverse event, and document the reaction to a PPD test.
 

MSH|^~\&||MA0000||GA0000|199705221610||VXR^V03^V03|19970522MA53|T|2.3.1|||NE|AL|<CR>
 

MSA|AA|19970522GA40|<CR>
 

QRD|199705221605|R|I|19970522GA05|||25^RD|^KENNEDY^JOHN^FITZGERALD^JR|VXI^VACCINE
 

INFORMATION^HL70048|^SIIS|<CR>
 

QRF|MA0000||||256946789~19900607~MA~MA99999999~88888888~KENNEDY^JACQUELINE^
 

LEE~BOUVIER~898666725~KENNEDY^JOHN^FITZGERALD~822546618|<CR>
 

PID|||1234^^^^SR^~1234-12^^^^LR^~3872^^^^MR~221345671^^^^SS^~430078856^^^^MA^
 

||KENNEDY^JOHN^FITZGERALD^JR^^^L|BOUVIER^^^^^^M|19900607|M|KENNEDY^BABY BOY^^^^^^ 

B|2106-3^WHITE^HL70005|123 MAIN ST^APT 3B^LEXINGTON^MA^00210^^M^MSA
 

CODE^MA034~345 ELM ST^^BOSTON^MA^00314^^BDL~^^^^^^BR^^MA002||(617)555-1212^PRN
 

^PH^^^617^5551212^^||EN^ENGLISH^HL70296^^^|||||||N^NOT HISPANIC OR LATINO^HL70189^2186-

5^NOT HISPANIC OR LATINO^CDCRE1|CHILDREN’S HOSPITAL|<CR>
 

PD1|||CHILDREN’S CLINIC^L^1234^^^^FI^LEXINGTON HOSPITAL&5678&XX|12345^WELBY^
 

MARCUS^^^DR^MD^^^L^^^DN|||||||03^REMINDER/RECALL - NO CALLS^HL70215|Y|19900607 

|||A|19900607|19900607|<CR>
 

NK1|1|KENNEDY^JACQUELINE^LEE|MTH^MOTHER^HL70063||||||||||||||||||||||||||||||898666725^^^^SS|<CR>
 

NK1|2|KENNEDY^JOHN^FITZGERALD|FTH^FATHER^HL70063||||||||||||||||||||||||||||||822546618^^^^SS|<CR>
 

PV1||R||||||||||||||||||V02^19900607~H02^19900607|<CR>
 

RXA|0|1|19900607|19900607|08^HEPB-PEDIATRIC/ADOLESCENT^CVX^90744^HEPB-PEDATRIC 

/ADOLESCENT^C4|.5|ML^^ISO+||03^HISTORICAL INFORMATION - FROM PARENT’S WRITTEN
 

7 
 

 

 

RECORD^NIP0001|^JONES^LISA|^^^CHILDREN’S

HOSPITAL||5|MCG^^ISO+|MRK12345|199206|MSD ^MERCK^MVX|<CR> 

RXA|0|0|19901207|19901207|20^DTAP^CVX|.5|ML^^ISO+|||1234567891^O’BRIAN^ROBERT^A^^DR^

MD|^^^CHILD HEALTHCARE CLINIC^^^^^101 MAIN STREET^^BOSTON^MA||||W22532806|19901230| 

PMC^PASTEUR MERIEUX CONNAUGHT^MVX|00^PARENTAL DECISION^NIP002||RE|<CR> 

OBX|1|TS|29768-9^DATE VACCINE INFORMATION STATEMENT PUBLISHED^LN||19900605||||||F|<CR> 

OBX|2|TS|29769-7^DATE VACCINE INFORMATION STATEMENT PRESENTED^LN||19901207||||||F|<CR> 

RXA|0|1|19910907|19910907|50^DTAP-HIB^CVX^90721^DTAP-HIB^C4|.5|ML^^ISO+||00^NEW 

IMMUNIZATION RECORD^NIP001|1234567890^SMITH^SALLY^S^^^^^^^^^VEI~ 

1234567891^O’BRIAN^ROBERT^A^^DR^MD^^^^^^OEI|^^^CHILD HEALTHCARE CLINIC^^^^^101 

MAIN STREET^^BOSTON^MA||||W46932777|199208|PMC^PASTEUR MERIEUX CONNAUGHT
 

^MVX|||CP|A|19910907120030|<CR>
 

RXR|IM^INTRAMUSCULAR^HL70162|LA^LEFT ARM^HL70163|<CR>
 

OBX|1|NM|30936-9^DTAP/DTP DOSE COUNT IN COMBINATION VACCINE^LN||4||||||F|<CR>
 

OBX|2|NM|30938-5^HAEMOPHILUS INFLUENZAE TYPE B (HIB) DOSE COUNT IN COMBINATION 

VACCINE^LN||4||||||F|<CR>
 

RXA|0|1|19910907|19910907|03^MMR^CVX|.5|ML^^ISO+|||1234567890^SMITH^SALLY^S^^^^^^^^^VEI
 

~1234567891^O’BRIAN^ROBERT^A^^DR^MD^^^^^^OEI|^^^CHILD HEALTHCARE CLINIC^^^^^101 

MAIN STREET^^BOSTON^MA||||W2348796456|19920731|MSD^MERCK^MVX|<CR>
 

RXR|SC^SUBCUTANEOUS^HL70162|LA^LEFT ARM^HL70163|<CR>
 

RXA|0|5|19950520|19950520|20^DTAP^CVX|.5|ML^^ISO+|||1234567891^O’BRIAN^ROBERT^A^^DR^M
 

D|^^^CHILD HEALTHCARE CLINIC^^^^^101 MAIN STREET^^BOSTON^MA||||W22532806|19950705|
 

PMC^PASTEUR MERIEUX CONNAUGHT ^MVX|<CR>
 

RXR|IM^INTRAMUSCULAR^HL70162|LA^LEFT ARM^HL70163|<CR>
 

RXA|0|2|19950520|19950520|03^MMR^CVX|.5|ML^^ISO+|||1234567891^O’BRIAN^ROBERT^A^^DR^M
 

D|^^^CHILD HEALTHCARE CLINIC^^^^^101 MAIN STREET^^BOSTON^MA||||W2341234567|19950630|
 

MSD^ MERCK^MVX|<CR>
 

RXR|SC^SUBCUTANEOUS^HL70162|LA^LEFT ARM^HL70163|<CR>
 

OBX||FT|30948-4^VACCINATION ADVERSE EVENT AND TREATMENT, IF 

ANY^LN||ANAPHYLAXIS||||||F|<CR>
 

NTE|||PATIENT DEVELOPED HIGH FEVER APPROX 3 HRS AFTER VACCINE INJECTION|<CR>
 

NTE|||VAERS FORM SUBMITTED BY PROVIDER|<CR>
 

RXA|0|1|19960415|19960415|96^TST-PPD INTRADERMAL^CVX|5|TU|<CR>
 

OBX||NM|1648-5^TUBERCULOSIS REACTION WHEAL 3D POST 5 TU ID^LN||1|MM||N|||F|||19960418|<CR>
 

8 
 

 

 

 

 

 

VXR Example #2 Returning Vaccines Due Next Data from the Registry Algorithm 

MSH|^~\&||GA0000||CHILD HEALTHCARE CLINIC|199007221606||VXR^V03^V03|1990072253| 

T|2.3.1|||NE|AL|<CR> 

MSA|AA|19900722GA40|<CR> 

QRD|199007221605|R|I|19900722GA05|||25^RD|^KENNEDY^JOHN^FITZGERALD^JR|VXI^VACCINE 

INFORMATION^HL70048|^SIIS|<CR> 

QRF|MA0000||||256946789~19900607~MA~MA99999999~88888888~KENNEDY^JACQUELINE^LEE~B 

OUVIER~898666725~KENNEDY^JOHN^FITZGERALD~822546618|<CR> 

PID|||1234^^^^SR^~1234-12^^^^LR^~3872^^^^MR~221345671^^^^SS^~430078856^^^^MA^ 

||KENNEDY^JOHN^FITZGERALD^JR^^^L|BOUVIER^^^^^^M|19900607|M|KENNEDY^BABY 

BOY^^^^^^B|2106-3^WHITE^HL70005|123 MAIN ST^APT^3B^LEXINGTON^MA^00210^^M^MSA 

CODE^MA034~345 ELM ST^^BOSTON^MA^00314^^BDL^^^^^^BR^^MA002||(617)555-

1212^PRN^PH^^^617^5551212^^||EN^ENGLISH^HL70296^^^|||||||N^NOT OF HISPANIC ORIGIN^ 

HL70189|CHILDREN’S HOSPITAL|<CR>

NK1|1|KENNEDY^JACQUELINE^LEE|32^MOTHER^HL70063||||||||||||||||||||||||||||||898666725^^^^SS|<CR> 

RXA|0|0|19900722|19900722|998^No Vaccine Administered^CVX|999|<CR> 

OBX|1|CE|30979-9^Vaccine due next^LN|1|20^DTAP^CVXI|||||F|<CR> 

OBX|2|TS|30979-9&30980-7^Date vaccine due^LN|1|19900807I|||||F|<CR> 

OBX|3|NM|30979-9&30973-2^Vaccine due next dose number^LN|1|01|||||FI<CR> 

OBX|4|TS|30979-9&30981-5^Earliest date to give^LN|1|19900803I|||||F|<CR> 

OBX|5|CE|30979-9&30982-3^Reason applied by forecast logic to project this vaccine^LN|1|^ACIP 

schedule||||||F|<CR> 

OBX|6|CE|30979-9^Vaccines due next, Vaccine type^LN|2|08^Hep B, pediatric^CVX|||||||F|<CR> 

OBX|7|TS|30979-9&30980-7^Date vaccine due^LN|2|19900722||||||F|<CR> 

OBX|8|NM|30979-9&30973-2^Vaccine due next dose number^LN|2|1||||||F|<CR> 

OBX|9|TS|30979-9&30981-5^Earliest date to give^LN|2|19900722||||||F|<CR> 

OBX|10|CE|30979-9&30982-3^Reason applied by forecast logic to project this vaccine^LN|2|^ACIP 

schedule||||||F|<CR> 

This example shows the response to a query from the Child Healthcare Clinic to the Georgia 

Immunization Registry for the record of a one-month-old child. The child’s birth information came from

Vital Statistics, but the registry has no record of any vaccines having been given. This response gives no 

vaccine administration data in the required RXA segment, but is able to return a forecast of next vaccines 

due in the associated OBX segments. The example shows the use of a “placeholder” RXA, but in a 

typical exchange, the immunization registry will be returning a history of vaccines in repeating RXA 

segments, then adding the next vaccines due after the last RXA. The list of vaccines due next is not 

dependant on any one vaccine, but rather the history as a whole, so there should be no misinterpretation 

of the message in the case where the OBX list showing next vaccines due follows an RXA reporting a 

real vaccine. The LOINC® descriptions for the OBX-3 fields are so specific that they offer further 

insurance against misinterpretation. If a user chooses to insert a “place-holder” RXA after the vaccine 

history and before the next vaccines due list, it should be acceptable to the receiver. 

9 
 

[This page was intentionally left blank.] 

10
 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4.14.4 Unsolicited Vaccination Record Update (VXU) 

Definition: When a provider using one system wishes to update the patient's vaccination record 

being held in another system, he will transmit an unsolicited update of the record (a V04 trigger event). 

An unsolicited update will follow this format: 

VXU Unsolicited Vaccination Update HL7 Chapter 

MSH Message Header Segment 2 

PID Patient Identification Segment 3 

[PD1] Additional Demographics 3 

[{NK1} ] Next of Kin/Associated Parties 3 

[PV1 Patient Visit 3 

[PV2] ] Patient Visit Additional Information 3 

[ {IN1 Insurance 6 

[IN2] Insurance Additional Information6 

[IN3] Insurance Additional Information-Cert. 6 

} ] 

[ { [ORC] Common Order Segment 4 

RXA Pharmacy Administration 4 

[RXR] Pharmacy Route 4 

[ { OBX Observation/Result 7 

[ {NTE} ] Notes (Regarding Immunization) 2 

} ] 

} ] 

VXU Example #1 (Message with only required fields valued) 

The example below of an unsolicited update of a vaccination record demonstrates a message with only
 

the minimum number of fields valued. This message provides all the NIP-required core data elements
 

(see Appendix 3 for the complete core data set) as well as the fields required by HL7 to form a correct 

message. In the body of this Implementation Guide these required items are represented in
 

boldface type. Some software vendors have expressed an interest in attaching a “patch” to an existing
 

system, possibly a billing system that does not otherwise use HL7, that would automatically generate this
 

message from data in an existing application. 

MSH|^~\&|||||||VXU^V04|19970522MA53|P|2.3.1|<CR>
 

PID|||221345671^^^^SS||KENNEDY^JOHN^FITZGERALD^JR|BOUVIER^^^^^^M|19900607|M|||~^^^^MA
 

^^^BDL|<CR>
 

NK1|1|KENNEDY^JACQUELINE^LEE|MTH^MOTHER^HL70063|<CR>
 

RXA|0|1|19900607|19900607|08^HEPB-PEDIATRIC/ADOLESCENT^CVX|.5|ML^^ISO+||||||||
 

MRK12345||MSD^MERCK^MVX|<CR>
 

VXU Example #2 (Unsolicited update showing use of optional segments)
 

The example below of an unsolicited update of a vaccination record demonstrates the use of this 

message to update an entire immunization record and to use some of the optional segments in the 

message to provide additional information. For example, the PD1 segment records the medical home 

and states whether reminder/recall notices should be sent for this patient. The PV1 segment reports that 

the patient is a recurring patient who is VFC eligible and is a Medicaid patient. The effective date of his 

VFC and Medicaid status is June 7, 1990. 

MSH|^~\&||MA0000||GA0000|19970901||VXU^V04|19970522MA53|T|2.3.1|||NE|AL|<CR> 

PID|||1234^^^^SR^~1234-12^^^^LR^~3872^^^^MR~221345671^^^^SS^~430078856^^^^MA^ 

||KENNEDY^JOHN^FITZGERALD^JR^^^L|BOUVIER^^^^^^M|19900607|M|KENNEDY^BABY BOY^^^^^^ 

B| 2106-3^WHITE^HL70005|123 MAIN ST^APT 3B^LEXINGTON^MA^00210^^M^MSA 

CODE^MA034~345 ELM ST^^BOSTON^MA^00314^^BDL~^^^^^^BR^^MA002||(617)555-1212^PRN^ 

PH^^^617^5551212^^||EN^ENGLISH^HL70296^^^|||||||N^NOT HISPANIC OR LATINO^HL70189^2186

5^NOT HISPANIC OR LATINO^CDCRE1|CHILDREN’S HOSPITAL|<CR>

-

11 
 

 

PD1|||CHILDREN’S CLINIC ^L^1234^^^^FI^LEXINGTON HOSPITAL&5678&XX|12345^WELBY^ 

MARCUS^^^DR^MD^^^L^^^DN|||||||03^REMINDER/RECALL - NO CALLS^HL70215|Y|19900607 

|||A|19900607|19900607|<CR> 

NK1|1|KENNEDY^JACQUELINE^LEE|MTH^MOTHER^HL70063||||||||||||||||||||||||||||||898666725^^^^SS|<CR> 

NK1|2|KENNEDY^JOHN^FITZGERALD|FTH^FATHER^HL70063||||||||||||||||||||||||||||||822546618^^^^SS|<CR> 

PV1||R|||||||||||||||A|||V02^19900607~H02^19900607|<CR> 

RXA|0|1|19900607|19900607|08^HEPB-PEDIATRIC/ADOLESCENT^CVX^90744^HEPBPEDATRIC/ADOLESCENT^C4|.5|ML^^ISO+||03^HISTORICAL INFORMATION - FROM PARENT’S

WRITTEN RECORD^NIP0001|^JONES^LISA|^^^CHILDREN’S HOSPITAL||5|MCG^^ISO+|MRK12345|

199206|MSD^MERCK^MVX|<CR> 

RXA|0|4|19910907|19910907|50^DTAP-HIB^CVX^90721^DTAP-HIB^C4|.5|ML^^ISO+||00^NEW 

IMMUNIZATION RECORD^NIP0001|1234567890^SMITH^SALLY^S^^^^^^^^^VEI~1234567891 

^O’BRIAN^ROBERT^A^^DR^MD^^^^^^OEI|^^^CHILD HEALTHCARE CLINIC^^^^^101 MAIN STREET^^

BOSTON^MA||||W46932777|199208|PMC^PASTEUR MERIEUX CONNAUGHT^MVX|||CP|A|
 

19910907120030|<CR>
 

RXR|IM^INTRAMUSCULAR^HL70162|LA^LEFT ARM^HL70163|<CR>
 

RXA|0|1|19910907|19910907|03^MMR^CVX|.5|ML^^ISO+|||1234567890^SMITH^SALLY^S^^^^^^^^^VEI
 

~1234567891^O’BRIAN^ROBERT^A^^DR^MD^^^^^^OEI|^^^CHILD HEALTHCARE CLINIC^^^^^101 

MAIN STREET^^BOSTON^MA||||W2348796456|19920731|MSD^MERCK^MVX|<CR>
 

RXR|SC^SUBCUTANEOUS^HL70162|LA^LEFT ARM^HL70163|<CR>
 

RXA|0|5|19950520|19950520|20^DTAP^CVX|.5|ML^^ISO+|||1234567891^O’BRIAN^ROBERT^A^^DR|^^
 

^CHILD HEALTHCARE CLINIC^^^^^101 MAIN STREET^^BOSTON^MA||||W22532806|19950705|PMC^
 

PASTEUR MERIEUX CONNAUGHT^MVX|<CR>
 

RXR|IM^INTRAMUSCULAR^HL70162|LA^LEFT ARM^HL70163|<CR>
 

RXA|0|2|19950520|19950520|03^MMR^CVX|.5|ML^^ISO+|||1234567891^O’BRIAN^ROBERT^A^^DR|^^^
 

CHILD HEALTHCARE CLINIC^^^^^101 MAIN STREET^^BOSTON^MA||||W2341234567|19950630|
 

MSD^MERCK^MVX|<CR>
 

RXR|SC^SUBCUTANEOUS^HL70162|LA^LEFT ARM^HL70163|<CR>
 

12 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

7.2.1 Unsolicited Transmission of an Observation (ORU) 

The ORU is a very versatile HL7 message. Using this message, one can construct almost any 

clinical report as a three-level hierarchy, with the patient information (PID segment) at the upper level, an 

order record (OBR segment) at the next level, and one or more observation records (OBX segment) at 

the third level. 

ORU^R01 Observational Results (Unsolicited) Chapter 

MSH Message Header 2 

{ 

[ 

PID Patient Identification 3 

[PD1] Additional Demographics 3 

[ {NK1} ] Next of Kin/Associated Parties 3 

[ {NTE} ] Notes and Comments 2 

[PV1 Patient Visit 3 

[PV2]] Patient Visit - Additional Info 3 

] 

{ 

[ORC] Order common 4 

OBR Observations Report ID 7 

{ [NTE] } Notes and comments 2 

{ 

[OBX] Observation/Result 7 

{ [NTE] } Notes and comments 2 

} 

{ [CTI] } Clinical Trial Identification 7 

} 

} 

[DSC] Continuation Pointer 2 

The HL7 ORU message can transmit a report of an adverse event possibly caused by a vaccine. The 

message is tightly coded and defined to provide unambiguous reporting that can be processed 

electronically. Each item on the VAERS-1 (FDA) form can be reported in one of the fields in this 

message. The standard ORU message allows for the optional use of PD1, PV1, PV2, CTI, and DSC 

segments, but these segments will not be used in the VAERS ORU message. For this reason, the limited 

discussion of some of these segments in this implementation guide in connection with other messages 

does not reference the VAERS message. The segments that are highlighted in the syntax above are 

those needed by the VAERS message. 

Background on the Vaccine Adverse Event Reporting System (VAERS) 

VAERS is a passive surveillance system, a repository for voluntarily submitted reports. An active 

surveillance system, in contrast, would follow all individuals in a defined population to determine their 

responses to vaccination. To encourage reporting of any possibly vaccine-induced adverse event, the 

criteria for reporting to VAERS are unrestrictive; the system accepts and includes any report submitted, 

no matter how tenuous the possible connection with vaccination might seem. The virtually universal 

exposure of the population to vaccines makes it vitally important to understand even the very rare 

complications of vaccination. Therefore, it is essential to continue to collect information on vaccinerelated adverse events, even after the vaccines have been approved for general use. For this reason, the 

Federal Government has established a surveillance system to monitor adverse events that occur 

following vaccination. The National Childhood Vaccine Injury Act of 1986 mandated that all health care 

providers report certain adverse events that occur following vaccination. Adverse events are defined for 

VAERS reporting as health effects that occur after immunization that may be related to the vaccine. 

Adverse event data are continually monitored in order to detect previously unknown adverse events or 

increases in known adverse events. Several investigations of VAERS data have uncovered previously 

unrecognized problems that may occur rarely in vaccine recipients. 

13 
 

 

 

 

 

 

 

 

 

 

 

 

 

Immunization registries have the potential to provide a mechanism for the more efficient and 

comprehensive reporting of adverse events associated with vaccines. Physicians increasingly are 

establishing electronic connections with local and state registries using the standard HL7 protocol. HL7 

messages to report immunizations and to access the repository of immunization histories in the registry 

have been specified in other parts of this Guide. Immunization registries and vendors of physicians’

electronic information systems should be able to extend the common immunization record exchange 

functions of registries to allow physicians to submit VAERS reports about their patients with a minimum of 

staff time and duplication of data entry. This Guide contains the specifications for electronic transmission 

of VAERS reports to immunization registries and to the VAERS processing contractor using a standard 

HL7 message, the ORU. The VAERS ORU specifications are incorporated throughout the document. 

For example, the PID segment is used in both VAERS and immunization messages, but its definition is 

provided in only one place. 

The optionality of items in the VAERS ORU message is governed by requirements of the HL7 syntax for 

an ORU message and by the VAERS reporting rules. The directions on the back of the VAERS form are 

for the submitter to complete the form to the best of their abilities. It states further that “Items 3, 4, 7, 8,

10, 11, and 13 are considered essential and should be completed whenever possible.” 

A separate implementation guide for only the VAERS message is available at 

<www.cdc.gov/nip/registry/hl7vaers.pdf>. This guide describes the ORU message, defines each data 

field in the message, and provides an example of a complete message using the VAERS-1 (FDA) form. 

The guide includes tables of codes that are especially relevant to this message. Future versions of 

VAERS reports may change from the VAERS-1 (FDA) form. Developers are advised to confirm the 

current reporting version and format before implementation, but the VAERS-1 (FDA) form will continue to 

be supported for the near future. 

The following VAERS ORU message example places the message in a grid that allows users to easily 

see the item number of the VAERS-1 (FDA) form being addressed, the example segment with the item 

question expressed as a LOINC® code, and the identification of the table needed to provide the answer to 

the question (if coded). The code tables needed to provide data in the OBX-5 and descriptions of 

required data types are provided in appendices 1 and 2. A copy of the VAERS-1 (FDA) form is provided 

as Appendix 4. 

14 
 

 

 

Example VAERS ORU Message 

VAERS 

Item 

Number EXAMPLE SEGMENTS THAT ANSWER THE VAERS QUESTIONS 

Code Tables To 

Be Used 

Unnumbered Questions in Top Third of Page and Questions 1- 5 

MSH|^~\&||GA0000||VAERS PROCESSOR|20010316||ORU^R01| 

20010422GA03|T|2.3.1|||NE|AL|<CR> 

PID|||1234^^^^SR~1234-12^^^^LR~00725^^^^MR||Doe^John^Fitzgerald^JR^^^L 

||20001007|M||2106-3^White^HL70005|123 Peachtree St^APT 

3B^Atlanta^GA^30210^^M^^GA067||(678)555-1212^PRN|<CR> 

NK1|1|Jones^Jane^Lee^^^RN|VAB^Vaccine administered by 

(Name)^HL70063|<CR> 

NK1|2|Jones^Jane^Lee^^^RN|FVP^Form completed by (Name)-Vaccine 

provider^HL70063|101 Main Street^^Atlanta^GA^38765^^O^^GA121||(404)554-

9097^WPN|<CR> 

ORC|RE|||||||||||1234567^Welby^Marcus^J^Jr^Dr.^MD^L|||||||||Peachtree Clinic|101 

Main Street^^Atlanta^GA^38765^^O^^GA121|(404)554-9097^WPN|101 Main 

Street^^Atlanta^GA^38765^^O^^GA121|<CR> 

OBR|1|||^CDC VAERS-1 (FDA) Report|||20010316|<CR> 

OBX|1|NM|21612-7^Reported Patient Age^LN||05|mo^month^ANSI|||||F|<CR> 

HL7 User-defined 

table 0063 

NA 

Table NIP003 

HL7 Figure 7-11, 

ANSI unit codes 

6 OBX|2|TS|30947-6^Date form completed^LN||20010316||||||F|<CR> Table NIP003 

7 OBX|3|FT|30948-4^Vaccination adverse events and treatment, if any^LN|1|fever of 

106F, with vomiting, seizures, persistent crying lasting over 3 hours, loss of 

appetite||||||F|<CR> 

Table NIP003 

8 OBX|4|CE|30949-2^Vaccination adverse event outcome^LN|1|E^required 

emergency room/doctor visit^NIP005||||||F|<CR> 

OBX|5|CE|30949-2^Vaccination adverse event outcome^LN|1|H^required 

hospitalization^NIP005||||||F|<CR> 

OBX|6|NM|30950-0^Number of days hospitalized due to vaccination adverse 

event^LN|1|02|d^day^ANSI|||||F|<CR> 

Table NIP003 

Table NIP005 

Note: Patient 

death and date 

information is 

derived from PID29-30. 

9 OBX|7|CE|30951-8^Patient recovered^LN||Y^Yes^ HL70136||||||F|<CR> Table NIP003 

HL7 Table 0136 

10 OBX|8|TS|30952-6^Date of vaccination^LN||20010216||||||F|<CR> Table NIP003 

11 OBX|9|TS|30953-4^Adverse event onset date and 

time^LN||200102180900||||||F|<CR> 

Table NIP003 

12 OBX|10|FT|30954-2^Relevant diagnostic tests/lab data^LN||Electrolytes, CBC, 

Blood culture||||||F|<CR> 

Table NIP003 

NA 

13 OBR|2|||30955-9^All vaccines given on date listed in #10^LN|<CR> 

OBX|1|CE|30955-9&30956-7^Vaccine type^LN|1|08^HepB-Adolescent/pediatric 

^CVX||||||F|<CR> 

OBX|2|CE|30955-9&30957-5^Manufacturer^LN|1|MSD^Merck^MVX||||||F|<CR> 

OBX|3|ST|30955-9&30959-1^Lot number^LN|1|MRK12345||||||F|<CR> 

OBX|4|CE|30955-9&30958-3^ Route^LN|1|IM^Intramuscular ^HL70162||||||F|<CR> 

OBX|5|CE|30955-9&31034-2^Site^LN|1|LA^Left arm^ HL70163||||||F|<CR> 

OBX|6|NM|30955-9&30960-9^Number of previous doses^LN|1|01||||||F|<CR> 

OBX|7|CE|30955-9&30956-7^Vaccine type^LN|2|50^DTaP-Hib^CVX||||||F|<CR> 

OBX|8|CE|30955-9&30957-5^ Manufacturer^LN|2|WAL^WyethAyerst^MVX||||||F|<CR> 

OBX|9|ST|30955-9&30959-1^Lot number^LN|2|W46932777||||||F|<CR> 

OBX|10|CE|30955-9&30958-3^ Route^LN|2|IM^Intramuscular^HL70162||||||F|<CR> 

Table NIP003 

The OBR-4 

LOINC® code 

30955-9 is 

repeated in each 

subcomponent of 

this item and joined 

with a second 

LOINC® code by 

an “&.”

HL7 Table 0227 

HL7 Table 0292 

NA 

HL7 Table 0162 

15 
 

 

 

 

 

OBX|11|CE|30955-9&31034-2^Site^LN|2|LA^Left arm^HL70163||||||F|<CR> 

OBX|12|NM|30955-9&30960-9^Number of previous doses^LN|2|01||||||F|<CR> 

HL7 Table 0163 

NA 

14 OBR|3|||30961-7^Any other vaccinations within 4 weeks prior to the date listed in 

#10^LN|<CR> 

OBX|1|CE|30961-7&30956-7^Vaccine type^LN|1|10^IPV^CVX||||||F|<CR> 

OBX|2|CE|30961-7&30957-5^Manufacturer^LN|1|PMC^Aventis Pasteur^MVX||||||F| 

<CR> 

OBX|3|ST|30961-7&30959-1^Lot number^LN|1|PMC123456||||||F|<CR> 

OBX|4|CE|30961-7&30958-3^Route^LN|1|SC^Subcutaneaous^HL70162||||||F|<CR> 

OBX|5|CE|30961-7&31034-2^Site^LN|1|LA^Left arm^HL70163||||||F|<CR> 

OBX|6|NM|30961-7&30960-9^Number of previous doses^LN|1|01||||||F|<CR> 

OBX|7|TS|30961-7&31035-9^date given^LN|1|20001216||||||F|<CR> 

Table NIP003 

The OBR-4 

LOINC® code 

30961-7 is 

repeated in each 

subcomponent of 

this item and 

joined with a 

second LOINC® 

code by an “&.”

HL7 Table 0227 

HL7 Table 0292 

NA 

HL7 Table 0162 

HL7 Table 0163 

NA 

NA 

15 OBX|8|CE|30962-5^Vaccinated at^LN||PVT^Private doctor’s office/hospital

^NIP007||||||F|<CR> 

Table NIP003 

Table NIP007 

16 OBX|9|CE|30963-3^Vaccine purchased with^LN||PBF^Public funds^NIP008 

||||||F|<CR> 

Table NIP003 

Table NIP008 

17 OBX|10|FT|30964-1^Other medications^LN||None||||||F|<CR> Table NIP003 

NA 

18 OBX|11|FT|30965-8^Illness at time of vaccination (specify)^LN||None||||||F|<CR> Table NIP003 

NA 

19 OBX|12|FT|30966-6^Pre-existing physician diagnosed allergies, birth defects, 

medical conditions^LN||Past conditions convulsions||||||F|<CR> 

Table NIP003 

NA 

20 OBX|13|CE|30967-4^Was adverse event reported 

previously^LN||N^no^NIP009||||||F|<CR> 

Table NIP003 

Table NIP009 

21 OBR|4||30968-2^Adverse event following prior vaccination in patient^LN|<CR> 

OBX|1|FT|30968-2&30971-6^Adverse event^LN||None||||||F|<CR> 

OBR|5||35286-4^Adverse event following prior vaccination in sibling^LN|1|<CR> 

OBX|1|FT|35286-4&30971-6^Adverse event^LN||vomiting, fever, otitis media||||||F| 

<CR> 

OBX|2|NM|35286-4&30972-4^Onset age^LN||04|mo^month^ANSI|||||F|<CR> 

OBX|3|CE|35286-4&30956-7^Vaccine Type ^LN||10^IPV^CVX||||||F|<CR> 

OBX|4|NM|35286-4&30973-2^Dose number in series^LN||02||||||F|<CR> 

OBR|6|||35286-4^Adverse event following prior vaccination in sibling^LN|2|<CR> 

OBX|1|FT|35286-4&30971-6^Adverse event^LN||None||||||F|<CR> 

Table NIP003 

The OBR-4 

LOINC® code 

30968-2 is 

repeated in each 

subcomponent of 

this item and 

joined with a 

second LOINC® 

code by an “&.”

NA 

Table NIP003 

NA 

NA 

HL7 table 0292 

NA 

Table NIP003 

NA 

NA 

22 OBR|7||^For children 5 and under|<CR> 

16 
 

 

 

 

OBX|1|NM|8339-4^Body weight at birth^LN||82|oz^ounces^ANSI|||||F|<CR> Table NIP003 

HL7 Figure 7-11, 

ANSI unit codes 

23 OBX|2|NM|30974-0^Number of brothers and sisters^LN||2||||||F|<CR> Table NIP003 

24 OBR|8|||^Only for reports submitted by manufacturer/immunization project|<CR> 

OBX|1|ST|30975-7^Mfr./Imm. Proj. report no.^LN||12345678||||||F|<CR> 

Table NIP003 

25 OBX|2|TS|30976-5^Date received by manufacturer/immunization project^LN|| 

12345678||||||F|<CR> 

Table NIP003 

26 OBX|3|CE|30977-3^15 day report^LN||N^No^HL70136||||||F|<CR> Table NIP003 

HL7 Table 0136 

27 OBX|4|CE|30978-1^Report type^LN||IN^Initial^NIP010||||||F|<CR> Table NIP010 

This example shows an HL7 message being sent on March 31, 2001, from the Georgia Immunization 

Registry to the VAERS processor. The message contains a VAERS report for patient John Fitzgerald 

Doe, Jr., white male, who resides at 123 Peachtree St., Atlanta, GA 30210. His date of birth was October 

7, 2000. Additional identifying information given in the message is: telephone number, 678-555-1212; 

State registry number 1234; local registry number 1234-12; medical record number 00725. Jane Lee 

Jones administered the vaccine and also completed the VAERS form. Her mailing address and work 

telephone number are provided. Dr. Marcus J. Welby, Jr., MD, of the Peachtree Clinic, 101 Main Street, 

Atlanta, GA 38765, ordered the vaccine, and his telephone number is provided. 

The VAERS form was completed on March 16, 2001, and reported fever of 106, with seizures, persistent 

crying lasting over 3 hours, and loss of appetite. This event required an emergency room visit and a 2-

day hospitalization. The patient recovered. The patient was vaccinated on February 16, 2001, at the 

reported age of 5 months, with Hep B and DTaP-Hib. The onset of the adverse event was February 18, 

2001, at 9:00 am. 

17 
 

 

 

 

 

 

 

 

 

 

 

 

2.13	 Acknowledgment Messages (With errors or finding no match to query parameters) 

Definition: The general default acknowledgment message returning error conditions has the 

following syntax. 

2.13.1 ACK General Acknowledgment HL7 Chapter 

MSH Message Header 2 

MSA Message Acknowledgment 2 

[ ERR ] Error 2 

Definition: The query general default acknowledgment message returning error conditions or 

explaining why the requested data are not being returned has the following syntax. 

2.18.1 QCK Query General Acknowledgment HL7 Chapter 

MSH Message Header 2 

MSA Message Acknowledgment 2 

[ ERR ] Error 2 

[ QAK ] Query Acknowledgment Segment 2 

General Acknowledgment Example #1 (ACK with error) 

Acknowledgment Example #1 shows an unsolicited update being rejected by Massachusetts Vaccine 

Records because a required field was empty. The error was located in the PID segment, where the 

patient identifier list (PID-3) was missing. 

MSH|^~\&||MA0000||GA0000|199705221305||ACK^|19970522GA40|T|2.3.1|<CR> 

MSA|AE|19970522GA40|NO PATIENT IDENTIFIER LIST|<CR> 

ERR|PID^^3^ID|<CR> 

Query General Acknowledgment Example #2 (QCK with no matching records found) 

Acknowledgment Example #2 illustrates a response after Massachusetts Vaccine Records processed the
 

query message, but found no match to the query parameters in its records. 

MSH|^~\&||MA0000||GA0000|199705221730||QCK^|19970522MA75|T|2.3.1|<CR>
 

MSA|0|19970522GA40|<CR>
 

ERR|0^MESSAGE ACCEPTED^HL70357|<CR>
 

QAK|19970522GA05|NF|<CR>
 

18 
 

 

 

 

 

SEGMENTS 

Each message is composed of a series of segments. Each segment is identified by its unique three-letter 

code. The segments used in the immunization messages are defined below. The segments are listed in 

the most logical order for immunization messages and do not strictly adhere to the order in which they are 

presented in the HL7 Standard. However, for ease of reference, the number preceding each segment 

and field name indicates its reference place in the HL7 Standard, Version 2.3.1. Because the segments 

here are re-ordered, these reference numbers are not always in sequential order. 

The following format is used in this document for listing and defining message segments and fields. First, 

the message segment’s use is defined, and a segment attribute table listing all fields defined in the

segment is shown. In the segment attribute table, the following attributes are given for each field: 

sequence number within the segment, length of field, data type, whether required (R), optional (O), 

conditional (C), or for backwards compatibility (B), whether repeating (Y), the applicable table number for 

values, the field item number, and the field name. 

Following the table, an example of the segment is provided, and selected fields are listed and defined. 

For each defined field, the HL7 segment code and reference number are listed, followed by the field 

name. Items in parentheses after the field name show respectively data type and length of field, whether 

the field is required or optional, and lists “repeating” if the field is allowed to repeat. The HL7 item number

follows the parenthesis and is given for reference convenience. As part of the definitions, usage notes for 

immunization registries are provided, a description of the data type is given in small font, and a statement 

about how the field is valued in the example is given. Fields that we do not anticipate immunization 

registries using are not defined. Users interested in learning more about fields not discussed in this 

document should refer to the full text of the HL7 Standard. 

19 
 

 

 

 

SEGMENT DEFINITIONS 

2.24 MESSAGE CONTROL SEGMENTS 

These segments are necessary to support the functionality described in the Control/Query 

chapter of the HL7 Standard. 

2.24.1 Message Header (MSH) Segment 

Used to define the intent, source, destination, and some specifics of the syntax of a message. 

MSH Attributes 

SEQ LEN DT R/O RP# TBL# ITEM# ELEMENT NAME 

1 1 ST R 00001 Field separator 

2 4 ST R 00002 Encoding characters 

3 180 HD O 00003 Sending application 

4 180 HD O 00004 Sending facility 

5 180 HD O 00005 Receiving application 

6 180 HD O 00006 Receiving facility 

7 26 TS O 00007 Date/Time of message 

8 40 ST O 00008 Security 

9 7 CM R 0076 00009 Message type 

0003 

10 20 ST R 00010 Message control ID 

11 3 PT R 00011 Processing ID 

12 60 VID R 0104 00012 Version ID 

13 15 NM O 00013 Sequence number 

14 180 ST O 00014 Continuation pointer 

15 2 ID O 0155 00015 Accept acknowledgment type 

16 2 ID O 0155 00016 Application acknowledgment type 

17 2 ID O 00017 Country code 

18 10 ID O Y 0211 00692 Character set 

19 60 CE O 00693 Principal language of message 

20 20 ID O 0356 01317 Alternate character set handling scheme 

Example:
 

MSH|^~\&||GA0000||VAERS PROCESSOR|20010331605||ORU^R01|20010422GA03|T|2.3.1|||NE|
 

AL|<CR>
 

This example MSH segment shows a Version 2.3.1 ORU message being sent from the Georgia 

immunization registry to the VAERS processor on March 31, 2001, at 4:05 pm. The message control ID
 

indicates that this is the third HL7 message of the day from this registry.
 

2.24.1.0 MSH field definitions 

MSH 2.24.1.1 Field separator (ST-1, Required) 00001 

Definition: The character to be used as the field separator for the rest of the message. 

The recommended value is |, as shown in our examples. 

MSH 2.24.1.2 Encoding characters (ST-4, Required) 00002 

Definition: Four characters in the following order: the component separator, repetition separator, 

escape character, and subcomponent separator. 

The recommended values are ^~\&, as shown in our examples. 

20 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

MSH 2.24.1.3 Sending application (HD-180, Optional) 00003 

Definition: Uniquely identifies the sending application among all other applications within the 

network enterprise. The network enterprise consists of all the applications that participate in the 

exchange of HL7 messages within the enterprise. Immunization programs may use this field to identify 

the software name and version. We do not define it further in this document. 

Data type HD: Components: <namespace ID (IS)>^ <universal ID (ST)>^<universal ID type (ID)>
 

Components are defined as follows:
 

(1)	 Namespace ID (IS). Refer to User-defined Table 0300 - Namespace ID for suggested values. 

(2)	 Universal ID (ST). The UID is a string formatted according to the scheme defined by the third component, UID type. 

The UID is intended to be unique over time within the UID type. It is rigorously defined by the scheme constructing it. 

The UID must follow the syntactic rules of the particular scheme defined in the third component. 

(3)	 Universal ID type (ID). Governs the interpretation of the second component of the HD. If it is a known UID, refer to 

HL7 Table 0301 - Universal ID type for valid values. 

In our examples, we have not valued this field. 

MSH 2.24.1.4 Sending facility (HD-180, Optional) 00004 

Definition: This field contains the address of the sending facility. Site-defined. Immunization 

programs may use this field to identify which state immunization registry is sending the query. The 

address consists of the two-letter postal code plus digits. The digits of the state central registry will be all 

0's; e.g., GA0000. Facilities and registries within the state will be assigned numeric codes by the state; 

e.g., GA0322. 

Data type HD: Components: <namespace ID (IS)>^ <universal ID (ST)>^<universal ID type (ID)>
 

Components are defined as follows:
 

(1)	 Namespace ID (IS). Refer to User-defined Table 0300 - Namespace ID for suggested values. 

(2)	 Universal ID (ST). The UID is a string formatted according to the scheme defined by the third component, UID type. 

The UID is intended to be unique over time within the UID type. It is rigorously defined by the scheme constructing it. 

The UID must follow the syntactic rules of the particular scheme defined in the third component. 

(3)	 Universal ID type (ID). Governs the interpretation of the second component of the HD. If it is a known UID, refer to 

HL7 Table 0301 - Universal ID type for valid values. 

In our query examples, we show the Georgia state registry as the sending facility. 

MSH 2.24.1.5 Receiving application (HD-180, Optional) 00005 

Definition: Uniquely identifies the receiving application among all other applications within the 

network enterprise. The network enterprise consists of all the applications that participate in the 

exchange of HL7 messages within the enterprise. Immunization programs may use this field to identify 

the software name and version. We do not define it further in this document. 

Data type HD: Components: <namespace ID (IS)>^ <universal ID (ST)>^<universal ID type (ID)>
 

Components are defined as follows:
 

(1)	 Namespace ID (IS). Refer to User-defined Table 0300 - Namespace ID for suggested values. 

(2)	 Universal ID (ST). The UID is a string formatted according to the scheme defined by the third component, UID type. 

The UID is intended to be unique over time within the UID type. It is rigorously defined by the scheme constructing it. 

The UID must follow the syntactic rules of the particular scheme defined in the third component. 

(3)	 Universal ID type (ID). Governs the interpretation of the second component of the HD. If it is a known UID, refer to 

HL7 Table 0301 - Universal ID type for valid values. 

In our examples, we have not valued this field. 

MSH 2.24.1.6 Receiving facility (HD-180, Optional) 00006 

Definition: This field identifies the receiving application among multiple identical applications 

running on behalf of different organizations. Site-defined. Immunization programs may use this field to 

identify which state immunization registry is to receive the query. The address consists of the two-letter 

postal code plus digits. The digits of the state central registry will be all 0's; e.g., MA0000. Facilities and 

registries within the state will be assigned numeric codes by the state; e.g., MA0322. 

Data type HD: Components: <namespace ID (IS)>^ <universal ID (ST)>^<universal ID type (ID)>
 

Components are defined as follows:
 

21 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

(1)	 Namespace ID (IS). Refer to User-defined Table 0300 - Namespace ID for suggested values. 

(2)	 Universal ID (ST). The UID is a string formatted according to the scheme defined by the third component, UID type. 

The UID is intended to be unique over time within the UID type. It is rigorously defined by the scheme constructing it. 

The UID must follow the syntactic rules of the particular scheme defined in the third component. 

(3)	 Universal ID type (ID). Governs the interpretation of the second component of the HD. If it is a known UID, refer to 

HL7 Table 0301 - Universal ID type for valid values. 

In our query examples, we show Massachusetts state registry as the receiving system. 

MSH 2.24.1.7 Date/time of message (TS-26, Optional) 00007 

Definition: Date/time the sending system created the message. 

Time stamp (TS) data type must be in the format:
 

YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]^<degree of precision>
 

Note: The optional degree of precision component is retained for backward compatibility only. Immunization registries will not value 

this component. 

The user values the field only as far as needed. When a system has only a partial date, e.g., month and 

year, but not day, the missing values may be interpreted as zeros. The time zone is assumed to be that 

of the sender. In the query examples, a message is being sent on May 22, 1995, at 4:05 p.m. 

MSH 2.24.1.8 Security (ST-40, Optional) 00008 

Definition: This field may be used to implement security features, but its use is not further 

specified by HL7. 

In our examples, we have not valued this field. 

MSH 2.24.1.9 Message type (CM-7, Required) 00009 

Definition: The receiving system uses this field to know the data segments to recognize and, 

possibly, the application to which to route this message. The second component is not required on 

acknowledgment messages. The third component is not required for immunization registries, since in the 

VXQ, VXR, VXX, and VXU messages, the message structure is the same designation as the trigger event 

type shown in component two. 

The specific components of fields using the CM data type are defined within the field descriptions.
 

The components for this field are: <message type (ID)>^<trigger event (ID)>^<message structure (ID)>
 

Refer to HL7 Table 0076 - Message type, HL7 Table 0003 - Event type, and HL7 Table 0354 - Message structure for values.
 

In the VXR example, the third component is valued for illustration although we do not anticipate 

immunization registries using this component. 

The unsolicited transmission of a vaccination record update message would appears as: |VXU^V04|. 

The unsolicited transmission of an observation message, such as a VAERS report, would appear as: 

|ORU^R01|. 

MSH 2.24.1.10 Message control ID (ST-20, Required) 00010 

Definition: Number or other identifier that uniquely identifies the message. The receiving system 

echoes this ID back to the sending system in the message acknowledgment segment (MSA). Each 

immunization registry will design its own method for assigning control IDs. 

VXQ Example #1 shows a potential identification method consisting of date (YYYYMMDD)+state 2-letter 

code+sequential number indicating the number of queries from the Georgia registry for this date. In the 

example, this is the 40th HL7 message to be sent from the Georgia registry on May 22, 1997. 

MSH 2.24.1.11 Processing ID (PT-3, Required) 00011 

Definition: Used to indicate how to process the message as defined in HL7 processing rules. 

PT data type components: <processing ID (ID)>^<processing mode (ID)> 

22 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

(1) 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. 

(2) Processing mode (ID). A value that defines whether the message is part of an archival process or an initial load. 

Refer to HL7 Table 0207-Processing mode for valid values. The default (blank) means current processing. 

In our VXU #1 example, the use is production. In the other examples, the use is training. The second 

component is not specified, indicating current processing as the default. 

MSH 2.24.1.12 Version ID (VID-60, Required) 00012 

Definition: Matched by the receiving system to its own HL7 version to be sure the message will 

be interpreted correctly. 

VID data type components: <version ID (ID)>^<internationalization code (CE)>^<international version ID (CE)> 

(1) Version ID (ID). Used to identify the HL7 version. Refer to HL7 Table 0104 - Version ID for valid values 

(2) Internationalization code (CE). Used to identify the international affiliate country code. ISO 3166 provides a list of 

country codes that may be used (see User-defined Table 0212 - Nationality). 

(3) International version ID (CE). Used when the international affiliate has more than a single local version associated 

with a single U.S. version. 

In our examples, the version is 2.3.1. 

MSH 2.24.1.13 Sequence number (NM-15, Optional) 00013 

Definition: Non-null value in this field implies that the sequence number protocol is in use. This 

numeric field is incremented by one for each subsequent value. 

In our examples, we have not valued this field. 

MSH 2.24.1.14 Continuation pointer (ST-180, Optional) 00014 

Definition: Used to define continuations in application-specific ways. 

In our examples, we have not valued this field. 

MSH 2.24.1.15 Accept acknowledgment type (ID-2, Optional) 00015 

Definition: Identifies the conditions under which accept acknowledgments are required to be 

returned in response to this message. HL7 Table 0155 - Accept/Application acknowledgment conditions 

gives valid values. Required for enhanced acknowledgment mode. (Note: If MSH-15 and MSH-16 are 

omitted or null, the original acknowledgment mode rules are used.) 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

This field is required if the enhanced acknowledgement mode is used, when the sending system wants a 

guarantee that the underlying communications system has delivered the message. The enhanced 

acknowledgement mode distinguishes both accept and application acknowledgments, as well the 

conditions under which each is required. With a positive accept acknowledgment, the receiving system 

commits the message to safe storage in a manner that releases the sending system from the need to 

resend the message. After the message has been processed by the receiving system, an application 

acknowledgment may be used to return the resultant status to the sending system. Immunization 

registries will usually use the original acknowledgement mode and will value this field as NE. 

MSH 2.24.1.16 Application acknowledgment type (ID-2, Optional) 00016 

Definition: Identifies the conditions under which application acknowledgments are required to be returned 

in response to this message. Required for enhanced acknowledgment mode. See HL7 Table 0155 -

Accept/Application acknowledgment conditions for values. 

23 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

In our examples, we have specified that the application acknowledgement is always required. 

This mode specifies that the message be acknowledged at the application level. The reasoning is that it 

is not sufficient to know that the underlying communications system guaranteed delivery of the message. 

It is also necessary to know that the receiving application processed the data successfully at a logical 

application level. In our examples, we have specified that the accept acknowledgment (MSH-15) is never 

required, but the application acknowledgment (MSH-16) is always required. 

MSH 2.24.1.17 Country code (ID-2, Optional) 00017 

Definition: Defines the country of origin for the message. It is used primarily to specify default 

elements, such as currency denominations. ISO 3166 provides a list of country codes that may be used 

(see User-defined Table 0212 - Nationality). 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

In our examples, we have not specified a country. When left blank, we assume this field to be the USA. 

MSH 2.24.1.18 Character set (ID-10, Optional, Repeating) 00692 

Definition: Contains the character set for the entire message. Refer to HL7 Table 0211 -

Alternate character sets for valid values of alternate character sets. The default set (if the field is left 

blank) is the printable 7-bit ASCII character set. 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

In our examples, we have not valued this field. 

MSH 2.24.1.19 Principal language of message (CE-60, Optional) 00693 

Definition: Contains the principal language of the message. HL7 recommends ISO 639 codes. 

See User-defined Table 0296 - Language. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1)	 Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2)	 Text (ST). Name or description of the item in question. 

(3)	 Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

In our examples, we have not valued this field. 

MSH 2.24.1.20 Alternate character set handling (ID-20, Optional) 01317 

Definition: When alternative character sets are used as specified in the second or later 

components of MSH-18 - Character Sets, any special handling scheme needed can be specified in this 

component according to HL7 Table 0356 - Alternative character set handling scheme. 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

In our examples, we have not valued this field. 

24 
 

 

 

 

 

 

 

2.24.2 Message Acknowledgment (MSA) Segment 

Used to send information while acknowledging another message. 

MSA Attributes 

SEQ LEN DT R/O RP/# TBL# ITEM# ELEMENT NAME 

1 2 ID R 0008 00018 Acknowledgment code 

2 20 ST R 00010 Message control ID 

3 80 ST O 00020 Text message 

4 15 NM O 00021 Expected sequence number 

5 1 ID B 0102 00022 Delayed acknowledgment type 

6 100 CE O 00023 Error condition 

Example: 

MSA|AA|19970522GA40|<CR> 

In this example MSA segment, the receiving system is replying to the sending system with an application 

accept acknowledgement indicating that the message was processed successfully and echoing the 

sender’s message control ID--19970522GA40. 

2.24.2.0 MSA field definitions 

MSA 2.24.2.1 Acknowledgment code (ID-2, Required) 00018 

Definition: Valid codes are given in HL7 Table 0008 - Acknowledgment code to indicate accept, 

reject, error, etc. 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

In our VXX and VXR examples, the code is AA = Application Accept. Our Acknowledgment Message #1 

example shows AE = Application Error. 

MSA 2.24.2.2 Message control ID (ST-20, Required) 00010 

Definition: Message control ID of the message sent by the sending system. It allows the sending 

system to associate this response with the message for which it is intended. 

In our VXX example, the message control ID of 19970522GA40 sent from the Georgia state registry in 

the query is echoed. This should be the same ID that was sent by the sending system in MSH-10. 

MSA 2.24.2.3 Text message (ST-80, Optional) 00020
 

Definition: Optional text field that further describes an error condition. This text may be printed in 

error logs or presented to an end user. 

In our Acknowledgment message with error example, we have valued this field to show that the sending 

system failed to value a required field. The text reads, “No patient identifier list.”

MSA 2.24.2.4 Expected sequence number (NM-15, Optional) 00021 

Definition: Optional numeric field used in the sequence number protocol. 

In our examples, we have not valued this field. 

MSA 2.24.2.5 Delayed acknowledgment type (ID-1, Backwards Compatibility) 00022 

25 
 

 

 

 

 

 

 

 

 

 

 

 

Definition: Valid codes given in HL7 Table 0102 - Delayed acknowledgment type. Used only as 

described in the HL7 Standard Section 2.5.2. Otherwise this field is not used. 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

In our examples, we have not valued this field. 

MSA 2.24.2.6 Error condition (CE-100, Optional) 00023 

Definition: CE data type field allows the acknowledging system to use HL7 Table 0357- Message 

error status codes to further specify AR (application reject) or AE (application error) type 

acknowledgments. This field allows a coded replacement for MSA-3-text message. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1) Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2) Text (ST). Name or description of the item in question. 

(3) Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

In our examples, we have not valued this field. Immunization registries may wish to develop codes to 

represent various types of errors from their participants. 

26 
 

 

 

 

 

 

 

 

 

2.24.3	 Error (ERR) Segment 

Used to add error comments to acknowledgment messages. If the message was rejected for 

functional reasons, this segment will locate the error and describe it using locally established codes. 

ERR Attributes 

SEQ LEN DT R/O RP/# TBL# ITEM# ELEMENT NAME 

1 80 CM R Y 0357 00024 Error code and location 

Example: 

ERR|PID^^3^ID|<CR> 

This error segment shows that an error was located in the third field of the PID segment, where the 

patient identifier list (PID-3) was missing. 

2.24.3.0 ERR field definitions 

ERR 2.24.3.1 Error code and location (CM-80, Required, Repeating) (00024) 

Definition: Identifies an erroneous segment in the message received. The second component is 

an index if more than one segment of a specific type repeats. For systems that do not use the HL7 

Encoding Rules, the data item number may be used for the third component. The fourth component 

(which references HL7 Table 0357 - Message error status codes) is restricted from having any 

subcomponents, since it is a CE data type and the subcomponent separator is now the CE's component 

separator. 

The specific components of fields using the CM data type are defined within the field descriptions.
 

The components for this field are: <segment ID (ST)>^<sequence (NM)>^<field position (NM)>^<code identifying error (CE)>
 

In our Acknowledgment Message example with error, we show an error in the PID segment, field 3. 

27 
 

 

 

 

 

 

 

 

 

 

 

 

 

2.24.22 Query Acknowledgment (QAK) Segment 

Used to send information with responses to a query. 

QAK Attributes 

SEQ LEN DT R/O RP/# TBL# ITEM# ELEMENT NAME 

1 32 ST C 00696 Query tag 

2 2 ID O 0208 00708 Query response status 

Example: 

QAK|19970522GA05|NF|<CR> 

This example query acknowledgement segment shows that the query with the query tag 19970522GA05 

was processed, but no matches to the query parameters were found. 

2.24.22.0 QAK field definitions 

QAK 2.24.22.1 Query tag (ST-32, Conditional) 00696 

Definition: This field may be valued by the initiating system to identify the query and may be used 

to match response messages to the originating query. If it is valued, the responding system is required to 

echo it back as the first field in the QAK. This field differs from MSA-2-message control ID in that its value 

remains constant for each message associated with the query (i.e., all continuation messages), whereas 

MSA-2-message control ID may vary with each continuation message, since it is associated with each 

individual message, not the query as a whole. 

In our Acknowledgment Example #2 (with no records found), we show the Massachusetts registry 

reflecting the Query ID (QRD-4) sent in the query from the Georgia registry. 

QAK 2.24.22.2 Query response status (ID-2, Optional) 00708 

Definition: This field allows the responding system to return a precise response status. It is 

especially useful in the case where no data is found that matches the query parameters, but where there 

is also no error. It is defined with HL7 Table 0208 - Query response status. 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

In our Acknowledgment Example #2 (with no records found), we show the Massachusetts registry 

advising the Georgia registry that it processed the query, but found no matches to the query parameters. 

Note that some registries plan to use this acknowledgment when they do not have consent to exchange 

the record. (See discussion at PD1-12.) 

28 
 

 

 

 

 

 

 

 

 

 

 

2.24.4	 Query Definition (QRD) Segment 

Used to define a query. 

QRD Attributes 

SEQ LEN DT R/O RP/# TBL# ITEM# ELEMENT NAME 

1 26 TS R 00025 Query date/time 

2 1 ID R 0106 00026 Query format code 

3 1 ID R 0091 00027 Query priority 

4 10 ST R 00028 Query ID 

5 1 ID O 0107 00029 Deferred response type 

6 26 TS O 00030 Deferred response date/time 

7 10 CQ R 0126 00031 Quantity limited request 

8 60 XCN R Y 00032 Who subject filter 

9 60 CE R Y 0048 00033 What subject filter 

10 60 CE R Y 00034 What department data code 

11 20 CM O Y 00035 What data code value qualifier 

12 1 ID O 0108 00036 Query results level 

Example:
 

QRD|199705221605|R|I|19970522GA05|||25^RD|^KENNEDY^JOHN|VXI^VACCINE INFORMATION
 

^HL70048|^SIIS|<CR>
 

This example QRD segment shows that a query with ID 19970522GA05 for vaccine information for John
 

Kennedy was generated on May 22, 1997, at 4:05 p.m. The example limits the response to 25 records. 

The sending system expects a record-oriented response to be sent immediately from the State 

Immunization Information System (SIIS).
 

2.24.4.0 QRD field definitions 

QRD 2.24.4.1	 Query date/time (TS-26, Required) 00025 

Definition: Date the query was generated by the application program. 

Time stamp (TS) data type must be in the format:
 

YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]^<degree of precision>
 

Note: The optional degree of precision component is retained for backward compatibility only. Immunization registries will not value 

this component. 

In both query examples, the query was generated on May 22, 1997, at 4:05 p.m. 

QRD 2.24.4.2 Query format code (ID-1, Required) 00026 

Definition: Valid format codes are given in HL7 Table 0106 - Query/response format code. 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

In both query examples, we use the record-oriented format (R). 

QRD 2.24.4.3 Query priority (ID-1, Required) 00027 

Definition: Time frame in which the response is expected. Table values and subsequent fields 

specify time frames for response. HL7 Table 0091 - Query priority gives valid codes. 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

In both query examples, we expect an immediate response (I). 

29 
 

 

VXQ Example #1 follows the same formula as in MSH-10. While MSH-10 demonstrates the 40th

message of the day, the QRD-4 field reveals that this is the 5th query of the day from the Georgia system. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

QRD 2.24.4.4 Query ID (ST-10, Required) 00028 

Definition: Unique identifier for the query. Assigned by the querying application. Returned intact 

by the responding application. 

QRD 2.24.4.5 Deferred response type (ID-1, Optional) 00029 

Definition: Valid entries are from HL7 Table 0107 - Deferred response type, to indicate before or 

later than the date/time specified. 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

In our examples, we have not specified a date/time of response, because we expect an immediate 

response (see 2.24.4.3 above). 

QRD 2.24.4.6 Deferred response date/time (TS-26, Optional) 00030 

Definition: Date/time before or after which to send a deferred response. If not present, the 

response can be sent when it is available. 

Time stamp (TS) data type must be in the format: 

YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]^<degree of precision> 

Note: The optional degree of precision component is retained for backward compatibility only. Immunization registries will not value 

this component. 

In our examples, we have not specified a response date/time. 

QRD 2.24.4.7 Quantity limited request (CQ-10, Required) 00031 

Definition: Maximum length of the response that can be accepted by the requesting system. 

Valid responses are numerical values given in units specified in the second component. HL7 Table 0126 

- Quantity limited request gives valid entries, with codes for characters, lines, pages, records, or locally 

defined. The default value is lines. 

CQ data type components: <quantity (NM)>^<units (CE)> 

Our query examples specify a maximum length of 25 records. 

QRD 2.24.4.8 Who subject filter (XCN-60, Required, Repeating) 00032 

Definition: Identifies the subject of the query or who the inquiry is about. The field is allowed to 

repeat. 

XCN data type components: <ID number (ST)>^<family name (ST)>&<last name prefix (ST)>^<given name 

(ST)>^<middle initial or name (ST)>^<suffix (e.g., Jr. or III) (ST)>^<prefix (e.g., Dr.) (ST)>^<degree (e.g., MD) 

(IS)>^<source table (IS)>^<assigning authority (HD)>^<name type code (ID)>^<identifier check digit (ST)>^<code 

identifying the check digit scheme employed (ID)>^<identifier type code (IS)>^<assigning facility ID (HD)>^<name 

representation code (ID)> 

Subcomponents of assigning authority: <namespace ID (IS)>&<universal ID (ST)> & <universal ID type (ID)> 

Subcomponents of assigning facility: <namespace ID (IS)>&<universal ID (ST)> & <universal ID type (ID)> 

In our VXQ example #1, we are sending a query for the record of John Fitzgerald Kennedy, Jr. Our VXQ 

example #2 demonstrates giving only the name of John Kennedy as the subject of the query. 

30 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

QRD 2.24.4.9 What subject filter (CE-60, Required, Repeating) 00033 

Definition: Describes the kind of information required to satisfy the request. Valid codes are 

given in HL7 Table 0048 - What subject filter and may be extended locally during implementation. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1) Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2) Text (ST). Name or description of the item in question. 

(3) Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

In our query examples, we specify Vaccine Information (VXI). 

QRD 2.24.4.10 What department data code (CE-60, Required, Repeating) 00034 

Definition: Can include drug code, item number, etc., consistent with the subject in 2.24.4.9. Can 

contain multiple occurrences separated by repetition delimiters. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1)	 Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2)	 Text (ST). Name or description of the item in question. 

(3)	 Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

In our VXQ #1, VXQ #2, VXX, and VXR examples, we have specified State Immunization Information 

Systems (SIIS) in this field. 

QRD 2.24.4.11 What data code value qualifier (CM-20, Optional, Repeating) 00035 

Definition: Further refines the inquiry by data code qualifiers by providing a window or range to 

further refine the inquiry. This field contains components giving start and stop code values. 

The specific components of fields using the CM data type are defined within the field descriptions. 

The components for this field are: <first data code value (ST)>^<last data code value (ST)> 

In our examples, we have not valued this field. 

QRD 2.24.4.12 Query results level (ID-1, Optional) 00036 

Definition: Used to control level of detail in results. HL7 Table 0108 - Query results level gives 

valid values. 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

In our examples, we have not valued this field. 

31 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2.24.5 Query Filter (QRF) Segment 

Used with the QRD segment to further refine the content of a query. 

QRF Attributes 

SEQ LEN DT R/O RP/# TBL# ITEM# ELEMENT NAME 

1 20 ST R Y 00037 Where subject filter 

2 26 TS O 00038 When data start date/time 

3 26 TS O 00039 When data end date/time 

4 60 ST O Y 00040 What user qualifier 

5 60 ST O Y 00041 Other query subject filter 

6 12 ID O Y 0156 00042 Which date/time qualifier 

7 12 ID O Y 0157 00043 Which date/time status qualifier 

8 12 ID O Y 0158 00044 Date/time selection qualifier 

9 60 TQ O 00694 When quantity/timing qualifier 

Example: 

QRF|MA0000||||256946789~19900607~MA~MA99999999~88888888~KENNEDY^JACQUELINE^ 

LEE~BOUVIER~898666725~KENNEDY^JOHN^FITZGERALD~822546618|<CR> 

This query filter segment from our VXQ #1 example shows a query for the record of John Fitzgerald 

Kennedy, Jr. The patient's Social Security number is 256-94-6789; his birth date is June 7, 1990; his birth 

state is MA; his birth registration number is MA99999999; his Medicaid number is 88888888; his mother 

is Jacqueline Lee Kennedy, whose maiden name is Bouvier; his mother's Social Security number is 

898666725; his father is John Fitzgerald Kennedy; and his father's Social Security number is 822546618. 

2.24.5.0 QRF field definitions 

Usage notes: QRF-6 through 9, optional fields, have not been valued in our examples and are 

not defined here. 

QRF 2.24.5.1 Where subject filter (ST-20, Required, Repeating) 00037 

Definition: Identifies the department, system, or subsystem to which the query pertains. This 

field may repeat. 

In our VXQ example #1, the query pertains to the Massachusetts immunization registry. 

QRF 2.24.5.2 When data start date/time (TS-26, Optional) 00038 

Definition: Data representing dates and times the same as or after this value should be included. 

Time stamp (TS) data type must be in the format:
 

YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]^<degree of precision>
 

Note: The optional degree of precision component is retained for backward compatibility only. Immunization registries will not value 

this component. 

In our VXQ example #1, we have not specified a date for record inclusion, because we want the entire 

vaccine record. 

QRF 2.24.5.3 When data end date/time (TS-26, Optional) 00039 

Definition: Data representing dates and times the same as or before this value should be 

included. 

Time stamp (TS) data type must be in the format:
 

YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]^<degree of precision>
 

32 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Note: The optional degree of precision component is retained for backward compatibility only. Immunization registries will not value 

this component. 

In our VXQ example #1, we have not specified an end date for record inclusion, because we want the 

entire vaccine record. 

QRF 2.24.5.4 What user qualifier (ST-60, Optional, Repeating) 00040 

Definition: An identifier to further define characteristics of the data of interest. The field is 

allowed to repeat. 

In our query examples, we have not valued this field. 

QRF 2.24.5.5 Other query subject filter (ST-60, Optional, Repeating) 00041 

Definition: A filter defined locally for use between two systems. This filter uses codes and field 

definitions which have specific meaning only to the applications and/or sites involved. The field is allowed 

to repeat. If one of the fields has no value, it is left empty in the repeating field. The requestor may send 

values for all the components that are known or may limit the items according to a search formula. 

For vaccination data, QRF-5 should be structured as shown in the table below to transmit up to ten 

separate search “keys.” These search keys are used to identify one patient's immunization record and 

include a wide variety of possible identifiers. The format of each possible search key is given below. 

These keys are transmitted as strings separated by repeat delimiters. The position of the components 

within QRF-5 is significant, as the position of an occurrence in this field defines the characteristic. Data 

items will be given in this order: <patient Social Security number>~<patient birth date>~<patient birth 

state>~<patient birth registration number>~<patient Medicaid number>~<mother's name>~<mother's 

maiden name>~<mother's Social Security number>~<father's name>~<father's Social Security number>. 

If one of the fields has no value, it is left empty in the repeating field, with a repeat delimiter holding its 

place. 

Posi 

-tion 

Component Data 

Type 

Description/Examples 

1 Patient Social Security Number~ ST In U.S., use SSN without hyphens between 3rd 

and 4th digits and 5th and 6th digits, e.g., 

123456789. In other countries, universal patient 

ID such as National Health Service number may 

be used. 

2 Patient Birth Date~ DT July 4, 1976 = 19760704 

3 Patient Birth State~ ID In U.S., use 2-letter postal code, e.g., IN, NY, CA. 

In other countries, locally applicable postal table 

may be used. 

4 Patient Birth Registration Number~ ST State birth certificate number 

5 Patient Medicaid Number~ ST When relevant 

6 Mother’s Name Last^First^Middle~ PN <family name>^<given name>^<middle name or 

initial>^<suffix>^<prefix>^<degree>. E.g., 

Smith^Mary^Elizabeth 

7 Mother’s Maiden Name~ ST Family name of mother before marriage. E.g., 

Jones 

8 Mother’s Social Security Number~ ST In U.S., use SSN without hyphens between 3rd 

and 4th digits and 5th and 6th digits, e.g., 

33 
 

 

 

 

 

 

123456789. In other countries, universal patient 

ID such as National Health Service number may 

be used. 

9 Father’s Name Last^First^Middle~ PN <family name>^<given name>^<middle name or 

initial>^<suffix>^<prefix>^<degree>. 

E.g.,Smith^Thomas^A^Jr 

10 Father’s Social Security Number ST In U.S., use SSN without hyphens between 3rd 

and 4th digits and 5th and 6th digits, e.g., 

123456789. In other countries, universal patient 

ID such as National Health Service number may 

be used. 

34 
 

 

 

 

 

 

 

 

 

 

2.23.3 HL7 BATCH PROTOCOL 

Use of the File/Batch Header (BHS) and Trailer (BTS) Segments 

A batch of HL7 messages may be sent online using a common file transfer protocol or offline via tape or 

diskette. If needed, a group of batches may be sent using the file header and trailer segments. The FHS 

and FTS are optional and need not be sent if the transaction is one batch of records. Both the batch 

header segment (BHS) and the file header segment (FHS) have fields that provide unique ID’s for these 

segments. The file/batch syntax follows. 

[FHS] (file header segment) 

{ [BHS] (batch header segment) 

{[MSH (zero or more HL7 messages)

 .... 

....

 ....

 ]} 

[BTS] (batch trailer segment) 

} 

[FTS] (file trailer segment) 

Batch Protocol Example 

BHS|^~\&||IHS0032||MA0000|199505221605||VAXBAX950522G||11254|<CR>
 

MSH|...(1)VXU...
 

MSH|...(2)VXU...
 

MSH|...(3)VXU...
 

BTS|3<CR>
 

This example demonstrates three HL7 VXU messages being sent from the Indian Health Service Clinic
 

0032 to the Massachusetts Immunization Registry on May 22, 1995, at 4:05 p.m. If a group of batches
 

were sent, an FHS would be added at the beginning of the message and an FTS at the end. 

2.24.11 File Header (FHS) Segment 

Used to head a file (group of batches). 

FHS Attributes 

SEQ LEN DT R/O RP# TBL# ITEM# ELEMENT NAME 

1 1 ST R 00067 File field separator 

2 4 ST R 00068 File encoding characters 

3 15 ST O 00069 File sending application 

4 20 ST O 00070 File sending facility 

5 15 ST O 00071 File receiving application 

6 20 ST O 00072 File receiving facility 

7 26 TS O 00073 File creation date/time 

8 40 ST O 00074 File security 

9 20 ST O 00075 File name/ID/type 

10 80 ST O 00076 File comment 

11 20 ST O 00077 File control ID 

12 20 ST O 00078 Reference file control ID 

35 
 

 

 

 

 

 

 

 

 

2.24.11.0 FHS field definitions 

Usage notes: FHS fields 1-8 have the same definitions as the corresponding fields in the MSH 

segment and are not repeated here. We did not use the FHS segment in our examples, but provide the 

field definitions below for reference. 

FHS 2.24.11.9 File name/ID/type (ST-20, Optional) 00075 

Definition: This field can be used by the application processing the batch. It can have extra 

components if needed. 

FHS 2.24.11.10 File header comment (ST-80, Optional) 00076 

Definition: This is a free text comment field that is not further defined in the HL7 protocol. 

FHS 2.24.11.11 File control ID (ST-20, Optional) 00077 

Definition: This field is used to uniquely identify a particular file. It can be echoed back in FHS12-reference file control ID. 

FHS 2.24.11.12 Reference file control ID (ST-20, Optional) 00078 

Definition: This field contains the value of FHS-11-file control ID when this file was originally 

transmitted. This field is not valued if this file is being sent for the first time. 

2.24.12 File Trailer (FTS) Segment 

Used to define the end of a file. 

FTS Attributes
 

SEQ LEN DT R/O RP# TBL# ITEM# ELEMENT NAME 

1 10 NM O 00079 File batch count 

2 80 ST O 00080 File trailer comment 

2.24.12.0 FTS field definitions 

Usage notes: We did not use the FTS segment in our examples, but provide the field definitions 

below for reference. 

FTS 2.24.12.1 File batch count (NM-10, Optional) 00079 

Definition: This field contains the number of batches contained in the file. 

FTS 2.24.12.2 File trailer comment (ST-80, Optional) 00080 

Definition: The use of this free text field is not further defined in the HL7 protocol. 

36 
 

 

 

 

 

 

 

 

 

 

 

2.24.13 Batch Header (BHS) Segment 

Used to define the start of a batch. 

BHS Attributes 

SEQ LEN DT R/O RP# TBL# ITEM# ELEMENT NAME 

1 1 ST R 00081 Batch field separator 

2 3 ST R 00082 Batch encoding characters 

3 15 ST O 00083 Batch sending application 

4 20 ST O 00084 Batch sending facility 

5 15 ST O 00085 Batch receiving application 

6 20 ST O 00086 Batch receiving facility 

7 26 TS O 00087 Batch creation date/time 

8 40 ST O 00088 Batch security 

9 20 ST O 00089 Batch name/ID/type 

10 80 ST O 00090 Batch comment 

11 20 ST O 00091 Batch control ID 

12 20 ST O 00092 Reference batch control ID 

Example: 

BHS|^~\&||IHS0032||MA0000|199505221605||VAXBAX950522G||11254|<CR> 

This batch header example demonstrates how the header would appear when being sent from the Indian 

Health Service Clinic 0032 to the Massachusetts Immunization Registry on May 22, 1995, at 4:05 p.m. 

The batch has the name of Vaxbax950522G and a control ID of 11254. 

2.24.13.0	 BHS field definitions 

Usage notes: BHS fields 1-8 have the same definitions as the corresponding fields in the MSH 

segment and are not repeated here. We did not use the BHS segment in our examples, but provide the 

field definitions below for reference. 

BHS 2.24.13.9 Batch name/ID/type (ST-20, Optional) 00089 

Definition: This field can be used by the application processing the batch. It can have extra 

components if needed. 

BHS 2.24.13.10 Batch comment (ST-80, Optional) 00090 

Definition: This field is a comment field that is not further defined in the HL7 protocol. 

BHS 2.24.13.11 Batch control ID (ST-20, Optional) 00091 

Definition: This field is used to uniquely identify a particular batch. It can be echoed back in BHS12-reference batch control ID if an answering batch is needed. 

BHS 2.24.13.12 Batch reference batch control ID (ST-20, Optional) 00092 

Definition: This field contains the value of BHS-11-batch control ID when this batch was originally 

transmitted. This field is not valued if this batch is being sent for the first time. 

37 
 

 

 

 

 

 

 

 

 

2.24.14 Batch Trailer (BTS) Segment 

Used to define the end of a batch. 

BTS Attributes 

SEQ LEN DT R/O RP# TBL# ITEM# ELEMENT NAME 

1 10 ST O 00093 Batch message count 

2 80 ST O 00094 Batch comment 

3 100 NM O Y 00095 Batch totals 

Example: 

BTS|3|<CR> 

This example batch trailer gives the batch message count as 3. 

2.24.14.0 BTS field definitions 

Usage notes: We did not use the BTS segment in our examples, but provide the field definitions 

below for reference. 

BHS 2.24.14.1 Batch message count (ST-10, Optional) 00093 

Definition: This field contains the count of the individual messages contained within the batch. 

BHS 2.24.14.2 Batch comment (ST-80, Optional) 00094 

Definition: This field is a comment field that is not further defined in the HL7 protocol. 

BHS 2.24.14.3 Batch totals (NM-100, Optional, Repeating) 00095 

Definition: This field may carry, as separate repeating components, as many types of totals as 

needed for the batch. Each component is an NM data type. This field may be defined as a CM data type 

for backwards compatibility with HL7 2.2 and 2.1. Users of the field in later HL7 2.x versions should use 

the NM data type and define it as “repeating” as illustrated below. 

Components: <total 1 (NM)>~<total 2 (NM)>~.... 

38 
 

 

 

 

 

3.3 PATIENT ADMINISTRATION MESSAGE SEGMENTS 

3.3.2 Patient Identification (PID) Segment 

Used by all applications as the primary means of communicating patient identification information. 

This segment contains permanent patient identifying and demographic information that, for the most part, 

is not likely to change frequently. 

PID Attributes 

SEQ LEN DT R/O RP/# TBL# ITEM# ELEMENT NAME 

1 4 SI O 00104 Set ID - PID 

2 20 CX B 00105 Patient ID 

3 20 CX R Y 00106 Patient identifier list 

4 20 CX B Y 00107 Alternate patient ID - PID 

5 48 XPN R Y 00108 Patient name 

6 48 XPN O Y 00109 Mother’s maiden name 

7 26 TS O 00110 Date/time of birth 

8 1 IS O 0001 00111 Sex 

9 48 XPN O Y 00112 Patient alias 

10 80 CE O Y 0005 00113 Race 

11 106 XAD O Y 00114 Patient address 

12 4 IS B 0289 00115 County code 

13 40 XTN O Y 00116 Phone number - home 

14 40 XTN O Y 00117 Phone number - business 

15 60 CE O 0296 00118 Primary language 

16 80 CE O 0002 00119 Marital status 

17 80 CE O 0006 00120 Religion 

18 20 CX O 00121 Patient account number 

19 16 ST B 00122 SSN number - patient 

20 25 DLN O 00123 Driver’s license number - patient 

21 20 CX O Y 00124 Mother’s identifier

22 80 CE O Y 0189 00125 Ethnic group 

23 60 ST O 00126 Birth place 

24 1 ID O 0136 00127 Multiple birth indicator 

25 2 NM O 00128 Birth order 

26 80 CE O Y 0171 00129 Citizenship 

27 60 CE O 0172 00130 Veterans military status 

28 80 CE O 0212 00739 Nationality 

29 26 TS O 00740 Patient death date and time 

30 1 ID O 0136 00741 Patient death indicator 

Example: 

PID|||1234^^^^SR~1234-12^^^^LR~00725^^^^MR^||Doe^John^Fitzgerald^JR^^^L||20001007|M||2106-

3^White^HL70005|123 Peachtree ST^APT 3B^Atlanta^GA^30210^^M^^GA067||(678)555-1212^PRN| 

<CR> 

This example identifies the patient as John Fitzgerald Doe, Jr., white male, who resides at 123 Peachtree 

St., Atlanta, GA 30210. His date of birth was October 7, 2000. Additional identifying information given in 

the message is: telephone number, 678-555-1212; State registry number 1234; local registry number 

1234-12; medical record number 00725. 

3.3.2.0 PID field definitions 

Usage notes: There are several PID fields that we do not anticipate that immunization registries 

will need to use, so we do not provide definitions for them here. These are PID-2,4,12,16-20,26-28. 

Several of these fields refer to types of patient identifiers. 

39 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

With Version 2.3.1, HL7 recommends using PID-3-patient identifier list for all patient identifiers. 

NIP encourages immunization registries to conform to the HL7 Version 2.3.1 recommendation by 

repeating PID-3 to report these identifiers along with the appropriate identifier type code (User-defined 

Table 0203 - Identifier type). Previous versions of these guidelines based on HL7 Version 2.3 

recommended that immunization registries use PID-4 - Alternate patient ID to record the patient’s birth 

certificate or birth registration number assigned by the state at birth. In addition, it was formerly 

recommended that the patient’s Social Security number be recorded in PID-19 - SSN – patient. The HL7 

recommendation as stated above supercedes those recommendations. 

PID 3.3.2.1 Set ID - PID (SI-4, Optional) 00104 

Definition: The Set ID field numbers the repetitions of the segment. For the first occurrence of the 

segment, the sequence number shall be one, for the second occurrence, the sequence number shall be 

two, etc. 

SI data type is a non-negative integer in the form of an NM field. The uses of this data type are defined in the chapters 

defining the segments and messages in which it is used. 

The VXX example shows the use of this field to number the four PID segments. 

For vaccine adverse event reporting, it is strongly recommended that information for only one patient be 

sent per message, in other words one PID per MSH. Thus PID-1 may be left blank or appear as: |1| 

PID 3.3.2.3 Patient identifier list (CX-20, Required, Repeating) 00106 

Definition: This field contains the list of identifiers (one or more) used by immunization registries 

and their participants to uniquely identify a patient ( e.g., medical record number, billing number, birth 

registry, national unique individual identifier, etc.) 

CX data type components: <ID (ST)>^<check digit (ST)>^<code identifying the check digit scheme employed
 

(ID)>^<assigning authority (HD)>^<identifier type code (IS)>^<assigning facility (HD)>
 

Components are defined as follows: 

(1)	 ID number (ST). 

(2)	 Check digit (ST). Defined as in the CK data type except as a ST. The check digit used 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 

null. 

(3)	 Code identifying check digit scheme employed (ID). Refer to HL7 Table 0061 - Check digit scheme for valid values. (4)	 Assigning authority (HD). 

Subcomponents of (4): <application identifier 1 (ID)> & <application identifier 2 (ID)> & <application identifier 3 (ID)> 

& <application identifier 4 (ID)> & <application identifier 5 (ID)> & <application identifier 6 (ID)> 

(5)	 Identifier type code (IS). A code corresponding to the type of identifier. This code may be used as a qualifier to the “Assigning 

authority” component. Refer to User-defined Table 0203 - Identifier type for suggested values. 

(6)	 Assigning facility (HD). The place or location identifier where the identifier was first assigned to the patient-part of the history 

of the identifier. 

Subcomponents of (6): <namespace ID (IS)>&<universal ID (ST)>&<universal ID type (ID)> 

HL7 recommends that this field be used to record all patient identifiers. For that reason, the type code 

should always be used to identify what type of identifier is being listed. Values for the type code are 

found in User-defined Table 0203 - Identifier type. Immunization registries should retain all identifiers and 

type codes they receive for a patient to aid in matching records of patients seen by multiple providers. 

In our VXR example, we have listed a state registry ID, a local registry ID, the provider’s medical record 

number, the patient’s Social Security number, and the patient’s Medicaid number. Other identifiers, such 

as WIC client number, birth certificate number, etc. may also be listed in this field. 

PID 3.3.2.5 Patient name (XPN-48, Required, Repeating) 00108 

Definition: The current, assumed legal name of the patient should be sent in this field. The name 

type code in this field should always be “L” for “Legal.” All other names for the patient should be sent in 

PID-9-patient alias. Repetition of this field is allowed only for representing the same name in different 

40 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

character sets, a situation that will rarely arise. Therefore, for practical purposes this field should 

be considered not repeating. 

XPN data type components: <family name (ST)>&<last name prefix (ST)>^<given name (ST)>^<middle initial or name 

(ST)>^<suffix (e.g., JR or III) (ST)>^<prefix (e.g., DR) (ST)>^<degree (e.g., MD) (IS)>^<name type code 

(ID)>^<name representation code (ID)> 

For valid values, refer to User-defined Table 0360 - Degree for the degree component, to HL7 Table 0200 - Name type for 

the name type code, and to HL7 Table 4000 - Name/address representation for the name representation code. 

In our VXU #1, VXU #2, and VXR examples, the patient is John Fitzgerald Kennedy, Jr., and the name 

type code is “L” for “Legal.” In all of our example fields that use the XPN data type, we do not value the

last component because all of our messages use an alphabetic name representation. 

PID 3.3.2.6 Mother's maiden name (XPN-48, Optional) 00109 

Definition: This field contains the family name under which the mother was born (i.e., before 

marriage). It is used to distinguish between patients with the same last name. The name type code 

should be valued “M” for “Maiden Name.” If a system needs additional information about the mother, the

NK1 segment should be used. 

XPN data type components: <family name (ST)>&<last name prefix (ST)>^<given name (ST)>^<middle initial or name 

(ST)>^<suffix (e.g., JR or III) (ST)>^<prefix (e.g., DR) (ST)>^<degree (e.g., MD) (IS)>^<name type code 

(ID)>^<name representation code (ID)> 

For valid values, refer to User-defined Table 0360 - Degree for the degree component, to HL7 Table 0200 - Name type for 

the name type code, and to HL7 Table 4000 - Name/address representation for the name representation code. 

In our VXU #1, VXU #2, and VXR examples, the mother's maiden name is Bouvier, and the name type 

code is “M.”

PID 3.3.2.7 Date of birth (TS-26, Optional) 00110 

Definition: This field contains the patient's date and (if applicable) time of birth. If not present, the 

HHMM portion will default to 0000. 

Time stamp (TS) data type must be in the format:
 

YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]^<degree of precision>
 

Note: The optional degree of precision component is retained for backward compatibility only. Immunization registries will not value 

this component. 

In our examples that value this field, the patient's date of birth is June 7, 1990. 

PID 3.3.2.8 Sex (IS-1, Optional) 00111 

Definition: This field contains the patient's sex. Refer to User-defined Table 0001 - Sex for valid 

values. 

The IS data type follows the formatting rules for an ST field except that it is drawn from a site-defined (or user-defined) 

table of legal values. 

In our examples that value this field, the patient's sex is male. 

PID 3.3.2.9 Patient alias (XPN-48, Optional, Repeating) 00112 

Definition: This field contains names by which the patient has been known at some time. 

XPN data type components: <family name (ST)>&<last name prefix (ST)>^<given name (ST)>^<middle initial or name 

(ST)>^<suffix (e.g., JR or III) (ST)>^<prefix (e.g., DR) (ST)>^<degree (e.g., MD) (IS)>^<name type code 

(ID)>^<name representation code (ID)> 

41 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

For valid values, refer to User-defined Table 0360 - Degree for the degree component, to HL7 Table 0200 - Name type for 

the name type code, and to HL7 Table 4000 - Name/address representation for the name representation code. 

In our VXU #2 and VXR examples, we have used this field to indicate a different birth name, Baby Boy 

Kennedy. The name type code is valued “B.”

PID 3.3.2.10 Race (CE-80, Optional, Repeating) 00113 

Definition: This field identifies the patient’s race. Refer to User-defined Table 0005 - Race for 

suggested values. This field is allowed to repeat, so several races may be reported for one patient. 

HL7’s Version 2.3.1 did not suggest values for this table, so Version 2.0 of our Implementation Guide 

provided a table based on commonly used categories for data on race at that time, stating that “values

compliant with the OMB directive will be added when available.” 

The U.S. Office of Management and Budget (OMB) published a notice of revised standards for the 

classification of Federal data on race and ethnicity in the Federal Register on October 30, 1997 

(hereinafter referenced as the OMB Notice). It directed the Bureau of the Census and other Federal 

programs to adopt the standards as soon as possible for data collections. The OMB Notice did not 

assign codes, but did establish categories of race and ethnicity with some differences from the previous 

standard. It established five minimum categories for data on race and two categories for data on 

ethnicity, but encouraged collection of greater detail. It also established two acceptable methods of 

reporting—one maintaining race and ethnicity as separate categories and one that combined both of 

these (called the combined format). It stated that more detailed collections should be organized in a way 

that allowed aggregation into these minimum categories for data on race and ethnicity. 

In response to OMB’s revised standard, representatives from several Federal agencies, including CDC, 

developed a code set that met the terms of the OMB Notice. HL7 also responded to this new need by 

recommending values for its User-defined Table 0005 – Race that were consistent with the OMB Notice 

and that adopted the codes for the minimum categories that were developed by the Federal agencies. 

The entire hierarchical list of numeric race and ethnicity categories is available at 

http://www.cdc.gov/od/hissb/docs/Race-EthnicityCodeSet.pdf. 

CIRSET members voted to change the recommendation in this Guide for race coding to these newer 

codes to be consistent with Federal data collections, such as Census data, as well as Version 2.4 and 

later HL7 implementations. The first triplet of this data type should use codes found in User-defined 

Table 0005 – Race. The HL7 standard states that the second triplet of the CE data type for race 

(alternate identifier, alternate text, and name of alternate coding system) is reserved for governmentallyassigned codes. If codes from the more detailed hierarchy described above are needed, for example to 

denote specific American Indian tribal affiliations, they may be drawn from the code set at the URL given 

above and represented in the second triplet of the CE data type in this field, with the code set name 

CDCRE1 in the 6th position of the second triplet. For example, if an immunization registry needed to 

represent the race of an American Indian patient who was a member of the Cherokee tribe, this field 

could be valued as: |1002-5^American Indian or Alaska Native^HL70005^1088-4^Cherokee^CDCRE1| 

The differences between the NIP-assigned race codes in the original Guide and the numeric race codes 

from HL7 Version 2.4’s User-defined Table 0005 – Race are in the categories of Asian and Pacific 

Islander. Immunization registries that collect race data will transition to the newer HL7 codes in the first 

triplet of the race field’s CE data type as quickly as possible. Immunization registries that have 

implemented messaging based on the original User-defined Table 0005 – Race may continue to provide 

this information in its original form during the transition by repeating the field and valuing the first triplet of 

the CE data in the repeated field with the original codes. Because the two affected categories will not 

map directly to the old categories, registries may map historical data collected before the availability of 

the revised OMB categories in these two categories to a code value of “U,” representing “Unknown.”

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

42 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

(1) Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2) Text (ST). Name or description of the item in question. 

(3) Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

In our VXU #2 and VXR examples, the patient’s race is “white “

PID 3.3.2.11 Patient address (XAD-106, Optional, Repeating) 00114 

Definition: This field lists the mailing address of the patient. Multiple addresses for the same 

person may be sent in the following sequence: the primary mailing address must be sent first in the 

sequence; if the mailing address is not sent, then a repeat delimiter must be sent in the first sequence. If 

there is only one repetition of this field and an address type is not given, it is assumed to be the primary 

mailing address. 

XAD data type components: <street address (ST)>^ <other designation (ST)>^<city (ST)>^<state or province (ST)>^<zip 

or postal code (ST)>^<country (ID)>^<address type (ID)>^<other geographic designation (ST)>^<county/parish 

code (IS)>^<census tract (IS)>^<address representation code (ID)> 

For valid values in these components, refer to User-defined Table 0212 - Nationality for country codes, HL7 Table 0190 -

Address type for address type codes, User-defined Table 0289 - County/parish for county/parish codes, User-defined Table 

0288 - Census Tract for census tract codes, and HL7 Table 4000 - Name/address representation for address representation 

codes. 

We recommend the USPS format for recording street address, other designation, city, state, and zip or 

postal code (available at <www.usps.gov>). When sending multiple addresses, the appropriate type code 

must be indicated. The address order is by local convention, however, we recommend that immunization 

registries send in the following order: 1) primary (current) mailing address (required to be first); 2) place 

of birth (indicate facility address and county ; name of birth facility is recorded in PID-23-Birth 

place); and 3) residence at birth (registries may choose to indicate county and state alone). Note that 

county is a specific component of this data type and should not be duplicated in the “other geographic

designation” component. Items to include here might be metropolitan statistical area (MSA) codes 

(available at <www.census.gov>) or school district number, for example. 

In our VXU #2 and VXR examples, we have listed the current mailing address, birth facility address, and 

residence county at birth. The birth facility address is recorded here, but the birth facility name is 

recorded in PID-23. 

PID 3.3.2.13 Phone number - home (XTN-40, Optional, Repeating) 00116 

Definition: The patient’s personal phone numbers. All personal phone numbers for the patient are 

sent in this sequence. The first sequence is considered the primary number. If the primary number is not 

sent, then a repeat delimiter is sent in the first sequence. 

XTN data type format and components: [NNN] [(999)]999-9999[X99999][B99999][C any text]^<telecommunication use 

code (ID)>^<telecommunication equipment type (ID)>^<email address (ST)>^<country code (NM)>^<area/city code 

(NM)>^<phone number (NM)>^<extension (NM)>^<any text (ST)> 

Refer to HL7 Table 0201 - Telecommunication use code and HL7 Table 0202 - Telecommunication equipment type for valid values. 

In our VXU #2 and VXR examples, we have listed the primary home phone number for the patient. 

PID 3.3.2.14 Phone number - business (XTN-40, Optional, Repeating) 00117 

Definition: Patient's business phone number. Repetitions are permitted, with the first one being 

the primary number. If the primary number is not sent, then a repeat delimiter is sent in the first 

sequence. 

XTN data type format and components: [NNN] [(999)]999-9999[X99999][B99999][C any text]^<telecommunication use 

code (ID)>^<telecommunication equipment type (ID)>^<email address (ST)>^<country code (NM)>^<area/city code 

(NM)>^<phone number (NM)>^<extension (NM)>^<any text (ST)> 

43 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Refer to HL7 Table 0201 - Telecommunication use code and HL7 Table 0202 - Telecommunication equipment type for 

valid values. 

In our examples, we have not valued this field. 

PID 3.3.2.15 Primary language (CE-60, Optional) 00118
 

Definition: Patient's primary language. Refer to User-defined Table 0296 - Language (ISO 639) 

for suggested values. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1) Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2) Text (ST). Name or description of the item in question. 

(3) Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

In our VXU #2 and VXR examples, the patient’s primary language is English. 

PID 3.3.2.21 Mother's identifier (CX-20, Optional, Repeating) 00124 

Definition: This field is used as a link field for newborns, for example. Typically a patient ID or 

account number may be used. This field can contain multiple identifiers for the same mother. 

Immunization registries will typically carry the majority of information about the mother in the NK1 

segment. 

CX data type components: <ID (ST)>^<check digit (ST)>^<code identifying the check digit scheme employed 

(ID)>^<assigning authority (HD)>^<identifier type code (IS)>^<assigning facility (HD)> 

Components are defined as follows: 

(1)	 ID number (ST) 

(2)	 Check digit (ST) (The check digit used 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 null.) 

(3)	 Code identifying check digit scheme employed (ID) Refer to HL7 Table 0061 - Check digit scheme for valid values. (4)	 Assigning authority (HD) 

Subcomponents of (4):	 <application identifier 1 (ID)> & <application identifier 2 (ID)> & <application 

identifier 3 (ID)> & <application identifier 4 (ID)> & <application identifier 5 (ID)> & <application 

identifier 6 (ID)> 

(5)	 Identifier type code (IS) 

A code corresponding to the type of identifier. This code may be used as a qualifier to the “Assigning authority” 

component. Refer to User-defined Table 0203 - Identifier type for suggested values. 

(6)	 Assigning facility (HD) 

Definition: The place or location identifier where the identifier was first assigned to the patient-part of the history of 

the identifier. 

Subcomponents of (6): <namespace ID (IS)>&<universal ID (ST)>&<universal ID type (ID)> 

In our examples, we have not valued this field. However, immunization registries may value this field with 

any number of identifiers for the patient’s mother using type codes as described in PID-3 above and 

shown in User-defined Table 0203 - Identifier type. 

PID 3.3.2.22 Ethnic group (CE-80, Optional, Repeating) 00125 

Definition: This field further defines patient ancestry. Suggested values are listed in User-defined 

Table 0189 - Ethnic group. This field is allowed to repeat, so several ethnic groups may be reported for 

one patient. HL7’s Version 2.3.1 did not suggest values for this table, so Version 2.0 of our Guide 

provided temporary codes, stating that these were to be used in the second triplet (of the CE data type) 

until OMB-compliant codes were available. According to HL7’s Version 2.4, “the second triplet of the CE

data type for Ethnic group (alternate identifier, alternate text, and name of alternate coding system) is 

44 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

reserved for governmentally assigned codes.” In the US, a current use is to report ethnicity following US 

federal standards for Hispanic origin. 

In the User-defined Table 0189 – Ethnic group, this Guide provides the ethnicity codes that were added to 

HL7’s Version 2.4, along with the relevant numeric ethnicity codes to be used in the second triplet from 

the hierarchical list of numeric race and ethnicity categories that is available at 

http://www.cdc.gov/od/hissb/docs/Race-EthnicityCodeSet.pdf. The code set from which these codes are 

drawn may be referenced as CDCRE1. (See discussion of these codes at PID-10.) Immunization 

registries that have already implemented the older codes for collections of ethnic data should transition to 

the HL7 codes provided in User-defined Table 0189 – Ethnic group in the first triplet of the CE data type 

and should include the numeric ethnic group codes in the second triplet. Because the affected categories 

will map directly to the old categories, registries should be able to map historical data collected before 

HL7’s Version 2.4 to the newer method with a minimum of effort. 

All new registry implementers of the HL7 messages that collect ethnic group data should use the HL7 

codes provided in User-defined Table 0189 – Ethnic group in the first triplet of the CE data type and the 

numeric ethnic group codes in the second triplet. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1) Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2) Text (ST). Name or description of the item in question. 

(3) Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

In our VXU #2 and VXR examples, the patient’s ethnic ancestry is “not Hispanic or Latino,” and we have 

shown the use of both the HL7 ethnic code and the governmentally-assigned code to which it maps. 

PID 3.3.2.23 Birth place (ST-60, Optional) 00126 

Definition: This field gives the location of the patient’s birth. Immunization registries may use this

field for the name of the facility where the patient was born. This information may be used in conjunction 

with PID-11-Patient address with address type as “location of birthing facility.”

In our VXU #2 and VXR examples, we have specified “Children’s Hospital” as the birth facility. The birth 

facility address is given in one repetition of PID-11 with the code BDL. 

PID 3.3.2.24 Multiple birth indicator (ID-1, Optional) 00127 

Definition: This field indicates whether the patient was part of a multiple birth. Refer to HL7 Table 

0136 - Yes/No indicator for valid values. 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

In our examples, we have not valued this field.
 

PID 3.3.2.25 Birth order (NM-2, Optional) 00128
 

Definition: If the patient was part of a multiple birth, a number indicating the patient's birth order 

is entered in this field. This field should only be used if PID-24-Multiple birth indicator is valued as “yes.”

In our examples, we have not valued this field. 

PID 3.3.2.29 Patient death date and time (TS-26, Optional) 00740 

45 
 

 

 

 

 

 

 

 

 

Definition: This field contains the date and time at which the patient death occurred. This field should only 

be valued if PID-30 is valued “yes.”

Time stamp (TS) data type must be in the format:
 

YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]^<degree of precision>
 

Note: The optional degree of precision component is retained for backward compatibility only. Immunization registries will not value 

this component. 

In our examples, we have not valued this field. 

PID 3.3.2.30 Patient death indicator (ID-1, Optional) 00741 

Definition: This field indicates whether or not the patient is deceased. Refer to HL7 Table 0136 -

Yes/No indicator for valid values. 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

In our examples, we have not valued this field. 

46 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3.3.9	 Patient Additional Demographic (PD1) Segment 

The patient additional demographic segment contains demographic information that is likely to 

change about the patient. 

PD1 Attributes 

SEQ LEN DT R/O RP/# TBL# ITEM# ELEMENT NAME 

1 2 IS O Y 0223 00755 Living dependency 

2 2 IS O 0220 00742 Living arrangement 

3 90 XON O Y 00756 Patient primary facility 

4 90 XCN O Y 00757 Patient primary care provider name & 

ID number 

5 2 IS O 0231 00745 Student indicator 

6 2 IS O 0295 00753 Handicap 

7 2 IS O 0315 00759 Living will 

8 2 IS O 0316 00760 Organ donor 

9 1 ID O 0136 00761 Separate bill 

10 20 CX O Y 00762 Duplicate patient 

11 80 CE O 0215 00763 Publicity code 

12 1 ID O 0136 00744 Protection indicator 

13 8 DT O 01566 Protection Indicator effective date 

14 250 XON O Y 01567 Place of worship 

15 250 CE O Y 01568 Advance directive code 

16 1 IS O 0441 01569 Immunization registry status 

17 8 DT O 01570 Immunization registry status effective 

date 

18 8 DT O 01571 Publicity code effective date 

Example:
 

PD1|||CHILDREN’S CLINIC^L^1234^^^^FI^LEXINGTON HOSPITAL&5678&XX|12345^WELBY^
 

MARCUS^^^DR^MD^^^L^^^DN|||||||03^REMINDER/RECALL-NO CALLS^HL70215|Y|19900607
 

|||A|19900607|19900607|<CR>
 

In this PD1 example, the legal name of the patient’s medical home, the primary facility, is Children’s

Clinic, which has a facility ID number of 1234. The authority that assigned this facility ID number is 

Lexington Hospital, which has 5678 as its organization identifier. Dr. Marcus Welby (his legal name), with 

doctor number 12345, is the patient’s primary care physician. The patient may be sent both reminder and 

recall notices by mail, but no calls are acceptable. The patient has consented to share records and is 

active in the registry as of June 7, 1990. 

3.3.9.0 PD1 field definitions 

Usage notes: We do not anticipate that immunization registries will use several PD1 fields (PD1-

1, 2, 5-10, 14-15; therefore, we do not provide definitions for them here. PD1-13, 16, 17 and 18 were 

requested for immunization registries and added to HL7's Version 2.4. Immunization registries may use 

the fields as described in this document in their Version 2.3.1 implementations, and the fields will be 

consistent with future versions of the standard. 

PD1 3.3.9.3 Patient primary facility (XON-90, Optional, Repeating) 00756 

Definition: This field contains the name and identifier that specifies the primary care facility for the 

patient. Multiple names and identifiers are allowed for the same facility. The legal name of the facility 

must be sent in the first sequence. If the legal name of the facility is not sent, then the repeat delimiter 

must be sent in the first sequence. Immunization registries may use this field to indicate a patient’s

medical home. Hierarchical organizational structures may be reflected here. 

XON data type components: <organization name (ST)>^ <organization name type code (IS)>^<ID number (NM)>^<check 

digit (NM)>^<code identifying the check digit scheme employed (ID)>^<assigning authority (HD)>^<identifier type 

code (IS)>^<assigning facility ID (HD)>^<name representation code (ID)> 

47 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Subcomponents of assigning authority: <namespace ID (IS)>&<universal ID (ST)>&<universal ID type (ID)> 

Subcomponents of assigning facility: <namespace ID (IS)>&<universal ID (ST)>&<universal ID type (ID)> 

Refer to User-defined Table 0204 - Organizational Name Type for the second component, to HL7 Table 0061 - Check Digit Scheme for the fifth 

component, to User-defined Table 0203 - Identifier Type for the seventh component, and to HL7 Table 4000 - Name/address representation for 

the last component. 

In our VXU #2 and VXR #1 examples, we have listed a medical home facility and its assigning authority 

organization. 

PD1 3.3.9.4 Patient primary care provider name & ID no. (XCN-90, Optional, Repeating) 00757 

Definition: This field contains the provider name and ID of the identified primary care provider. 

This information is usually selected by the patient at the time of enrollment in an HMO. This field is 

allowed to repeat and can provide multiple names for the same person. The legal name must be sent in 

the first sequence. If the legal name is not sent, then the repeat delimiter must be sent in the first 

sequence. Immunization registries may use this field to indicate a patient’s primary care provider or 

medical home provider. 

Components of the XCN data type: <ID number (ST)>^<family name (ST)>&<last name prefix (ST)>^<given name 

(ST)>^<middle initial or name (ST)>^<suffix (e.g., Jr. or III) (ST)>^<prefix (e.g., Dr.) (ST)>^<degree (e.g., MD) 

(IS)>^<source table (IS)>^<assigning authority (HD)>^<name type code (ID)>^<identifier check digit (ST)>^<code 

identifying the check digit scheme employed (ID)>^<identifier type code (IS)>^<assigning facility ID (HD)>^<name 

representation code (ID)> 

Subcomponents of assigning authority: <namespace ID (IS)>&<universal ID (ST)> & <universal ID type (ID)> 

Subcomponents of assigning facility: <namespace ID (IS)>&<universal ID (ST)> & <universal ID type (ID)> 

In our VXU #2 and VXR examples, we have listed Dr. Marcus Welby as the primary care physician. 

PD1 3.3.9.10 Duplicate patient (CX-20, Optional, Repeating) 00762 

Definition: This field indicates that a patient is the same as, or a duplicate of, another patient 

found on the sending system. The intent is to be informational only-no action is required by the receiver. 

Include the patient identifier if the sender knows an identifier for the patient. The assigning authority and 

identifier type code are strongly recommended for all CX data types. Refer to User-defined Table 0203 -

Identifier type for suggested values for the identifier type code. 

CX data type components: <ID (ST)>^<check digit (ST)>^<code identifying the check digit scheme employed 

(ID)>^<assigning authority (HD)>^<identifier type code (IS)>^<assigning facility (HD)> 

Components are defined as follows: 

(1)	 ID number (ST) 

(2)	 Check digit (ST) (The check digit used 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 null.) 

(3)	 Code identifying check digit scheme employed (ID) Refer to HL7 Table 0061 - Check digit scheme for valid values. (4)	 Assigning authority (HD) 

Subcomponents of (4):	 <application identifier 1 (ID)> & <application identifier 2 (ID)> & <application 

identifier 3 (ID)> & <application identifier 4 (ID)> & <application identifier 5 (ID)> & <application 

identifier 6 (ID)> 

(5)	 Identifier type code (IS) 

A code corresponding to the type of identifier. This code may be used as a qualifier to the “Assigning authority” 

component. Refer to User-defined Table 0203 - Identifier type for suggested values. 

(6)	 Assigning facility (HD) 

Definition: The place or location identifier where the identifier was first assigned to the patient-part of the history of 

the identifier. 

Subcomponents of (6): <namespace ID (IS)>&<universal ID (ST)>&<universal ID type (ID)> 

In our examples, we have not valued this field. 

PD1 3.3.9.11 Publicity code (CE-80, Optional) 00743 

48 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Definition: This field contains a user-defined code indicating what level of publicity is allowed 

(e.g., no publicity, family only) for the patient. This field will be used by immunization registries to indicate 

whether reminder/recall notices may be sent to a patient. Refer to User-defined Table 0215 – Publicity 

code for valid values. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1)	 Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2)	 Text (ST). Name or description of the item in question. 

(3)	 Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

In our VXU #2 and VXR examples, the patient may be sent both reminder and recall notices by mail. 

PD1 3.3.9.12 Protection indicator (ID-1, Optional) 00744 

Definition: This field identifies whether access to information about this person should be kept 

from users who do not have adequate authority for the patient. Refer to HL7 Table 0136 - Yes/No 

indicator for valid values. 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

This field will be used by immunization registries to indicate whether or not consent has been given (or 

assumed) for record sharing. It can have 3 values with the following meanings: 1) null, designated by “”

(see section 2.6 of HL7 Version 2.3.1 for discussion of null value). Null will indicate that patient/guardian 

has not yet been asked to give consent to share or has not responded; 2) Y - sharing is allowed (patient 

has given consent or consent is implied); 3) N - sharing is not allowed (patient has refused consent). 

For registries with required consent (e.g., California), the suggested default value for this field is null (““) to

indicate that consent has not yet been requested or received. For registries with implied consent (e.g., 

Georgia), the suggested default value is "Y" to allow sharing unless the patient specifically refuses 

consent. 

When a registry receives a request for a record for which record sharing is not permitted (value is N), that 

application should return a QAK query acknowledgment with the query response status field valued as 

"NF,” meaning "no data found, no errors.” No other information should be provided. When PD1-12 is 

valued as "N,” that record should never be shared outside the scope outlined by the consent agreement. 

In the mistaken case that a sending application sends or updates a record for which PD1-12 is "N,” the

receiving application should not process the message. A QAK segment should be returned to the 

sending application indicating "AE” for "application error" in the query response status field. MSA-3, Text 

message, should be valued to indicate that PD1-12 was “N” so the record was not processed and should 

not be re-sent. 

In our VXU #2 and VXR examples, the patient has consented to sharing, so the value indicated is “Y.”

PD1 3.3.9.13 Protection indicator effective date (DT-8, Optional) 01566 

Note: This field was added to HL7's Version 2.4 at NIP’s request, but may be used by registries in Version 2.3.1 messages.

Definition: Effective date for protection indicator reported in PD1-12. 

DT data type format: YYYY[MM[DD]] 

PD1 3.3.9.16 Immunization registry status (IS-1, Optional) 01569
 Note: This field was added to HL7's Version 2.4 at NIP’s request, but may be used by registries in Version 2.3.1 messages.
 

49 
 

 

 

 

 

 

 

 

 

 

 

 

Definition: This field identifies the registry status of the patient. Examples include active, inactive, lost to 

follow-up, moved or gone elsewhere (MOGE). Refer to User-defined Table 0441-Immunization registry 

status for suggested values. Note that Table 0441, now a part of HL7’s Version 2.4, is consistent with the 

former Table NIP006 - Patient registry status except that the code for Inactive has been changed by HL7 

to “I” for consistency with other HL7 codes. A deceased patient should be recorded in PID-30, with date 

and time of death recorded in PID-29. 

The IS data type follows the formatting rules for an ST field except that it is drawn from a site-defined (or userdefined) table of legal values. 

In our VXR example, the registry status of the patient is active. 

PD1 3.3.9.17 Immunization registry status effective date (DT-8, Optional) 01570 

Note: This field was added to HL7's Version 2.4 at NIP’s request, but may be used by registries in Version 2.3.1 messages.

Definition: Effective date for registry status reported in PD1-16. A deceased patient should be 

recorded in PID-30, with date and time of death recorded in PID-29. 

DT data type format: YYYY[MM[DD]] 

In our VXR example, the birth date of June 7, 1990, is the effective date of active status shown in PD1-

16. 

PD1 3.3.9.18 Publicity code effective date (DT-8, Optional) 01571 

Note: This field was added to HL7's Version 2.4 at NIP’s request, but may be used by registries in Version 2.3.1 messages.

Definition: Effective date for publicity code reported in PD1-11. 

DT data type format: YYYY[MM[DD]] 

50 
 

3.3.3 Patient Visit (PV1) Segment
 

The PV1 segment is used to send visit-specific information.
 

PV1 Attributes 

SEQ LEN DT R/O RP/# TBL# ITEM# ELEMENT NAME 

1 4 SI O 00131 Set ID - PV1 

2 1 IS R 0004 00132 Patient class 

3 80 PL O 00133 Assigned patient location 

4 2 IS O 0007 00134 Admission type 

5 20 CX O 00135 Preadmit number 

6 80 PL O 00136 Prior patient location 

7 60 XCN O Y 0010 00137 Attending doctor 

8 60 XCN O Y 0010 00138 Referring doctor 

9 60 XCN O Y 0010 00139 Consulting doctor 

10 3 IS O 0069 00140 Hospital service 

11 80 PL O 00141 Temporary location 

12 2 IS O 0087 00142 Preadmit test indicator 

13 2 IS O 0092 00143 Re-admission indicator 

14 3 IS O 0023 00144 Admit source 

15 2 IS O Y 0009 00145 Ambulatory status 

16 2 IS O 0099 00146 VIP indicator 

17 60 XCN O Y 0010 00147 Admitting doctor 

18 2 IS O 0018 00148 Patient type 

19 20 CX O 00149 Visit number 

20 50 FC O Y 0064 00150 Financial class 

21 2 IS O 0032 00151 Charge price indicator 

22 2 IS O 0045 00152 Courtesy code 

23 2 IS O 0046 00153 Credit rating 

24 2 IS O Y 0044 00154 Contract code 

25 8 DT O Y 00155 Contract effective date 

26 12 NM O Y 00156 Contract amount 

27 3 NM O Y 00157 Contract period 

28 2 IS O 0073 00158 Interest code 

29 1 IS O 0110 00159 Transfer to bad debt code 

30 8 DT O 00160 Transfer to bad debt date 

31 10 IS O 0021 00161 Bad debt agency code 

32 12 NM O 00162 Bad debt transfer amount 

33 12 NM O 00163 Bad debt recovery amount 

34 1 IS O 0111 00164 Delete account indicator 

35 8 DT O 00165 Delete account date 

36 3 IS O 0112 00166 Discharge disposition 

37 25 CM O 0113 00167 Discharged to location 

38 80 CE O 0114 00168 Diet type 

39 2 IS O 0115 00169 Servicing facility 

40 1 IS B 0116 00170 Bed status 

41 2 IS O 0117 00171 Account status 

42 80 PL O 00172 Pending location 

43 80 PL O 00173 Prior temporary location 

44 26 TS O 00174 Admit date/time 

45 26 TS O 00175 Discharge date/time 

46 12 NM O 00176 Current patient balance 

47 12 NM O 00177 Total charges 

48 12 NM O 00178 Total adjustments 

49 12 NM O 00179 Total payments 

50 20 CX O 0203 00180 Alternate visit ID 

51 1 IS O 0326 01226 Visit indicator 

52 60 XCN O Y 0010 01274 Other healthcare provider 

51 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Example: 

PV1||R||||||||||||||||||V02^19900607~H02^19900607|<CR> 

This PV1 segment shows that the patient is a recurring patient who is VFC eligible and is a Medicaid 

patient. The effective date of his VFC and Medicaid status is June 7, 1990. 

Since a single VFC effective date is being submitted, this status should only be applied to the 

immunizations given on June 7, 1990. The eligibility status for the other immunization dates is unknown. 

Every effort should be made to associate an effective date with a corresponding immunization date. For 

instance, since the only status submitted in the sample PV1 segment has a date of June 7, 1990, no 

information about the eligibility status of the other incoming immunizations should be inferred from this 

message. It is also possible that a VFC status and date may be sent that was not related to an 

immunization event: the status may not be applicable to any immunizations in the message. 

3.3.3.0 PV1 field definitions 

Usage notes: We do not anticipate that immunization registries will need to use several PV1 

fields (PV1 3-19,21-52); therefore, we do not provide definitions for them here. 

PV1 3.3.3.1 Set ID - PV1 (SI-4, Optional) 00131 

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

of the segment, the sequence number shall be one, for the second occurrence, the sequence number 

shall be two, etc. 

SI data type is a non-negative integer in the form of an NM field. The uses of this data type are defined in the chapters 

defining the segments and messages in which it is used. 

In our examples, we have not valued this field. 

PV1 3.3.3.2 Patient class (IS-1, Required) 00132 

Definition: This field is used by systems to categorize patients by site. It does not have a 

consistent industry-wide definition. We recommend that immunization registries record all patients as 

recurring. Refer to User-defined Table 0004 - Patient class for suggested values. 

The IS data type follows the formatting rules for an ST field except that it is drawn from a site-defined (or user-defined) 

table of legal values. 

In our VXU #2 and VXR examples, this is a recurring patient. 

PV1 3.3.3.20 Financial class (FC-50, Optional, Repeating) 00150 

Definition: This field contains the financial class(es) assigned to the patient for the purpose of 

identifying sources of reimbursement. Immunization registries may use this field to indicate several items: 

1) eligibility for the Vaccines For Children (VFC) program; 2) eligibility for state or local reimbursement 

programs; and 3) type of insurance plan (e.g., Medicaid, HMO, selfpay, etc.). Refer to User-defined Table 

0064 - Financial class for suggested values. 

FC data type components: <financial class (IS)>^<effective date (TS)> 

(1) Financial class (IS). The financial class assigned to a person. Refer to User defined Table 0064 - Financial class for 

suggested values. 

(2) Effective date (TS). The effective date/time of the person’s assignment to the financial class specified in the first 

component. 

In our VXU #2 and VXR examples, the patient is VFC-eligible because he is a Medicaid patient. 

52 
 

 

 

3.3.4 Patient Visit - Additional Information (PV2) Segment 

The PV2 segment is a continuation of the PV1 segment visit-specific information. 

PV2 Attributes 

SEQ LEN DT R/O RP/# TBL# ITEM# ELEMENT NAME 

1 80 PL C 00181 Prior pending location 

2 60 CE O 0129 00182 Accommodation code 

3 60 CE O 00183 Admit reason 

4 60 CE O 00184 Transfer reason 

5 25 ST O Y 00185 Patient valuables 

6 25 ST O 00186 Patient valuables location 

7 2 IS O 0130 00187 Visit user code 

8 26 TS O 00188 Expected admit date/time 

9 26 TS O 00189 Expected discharge date/time 

10 3 NM O 00711 Estimated length of inpatient stay 

11 3 NM O 00712 Actual length of inpatient stay 

12 50 ST O 00713 Visit description 

13 90 XCN O Y 00714 Referral source code 

14 8 DT O 00715 Previous service date 

15 1 ID O 0136 00716 Employment illness related indicator 

16 1 IS O 0213 00717 Purge status code 

17 8 DT O 00718 Purge status date 

18 2 IS O 0214 00719 Special program code 

19 1 ID O 0136 00720 Retention indicator 

20 1 NM O 00721 Expected number of insurance plans 

21 1 IS O Y 0215 00722 Visit publicity code 

22 1 ID O 0136 00723 Visit protection indicator 

23 90 XON O Y 00724 Clinic organization name 

24 2 IS O 0216 00725 Patient status code 

25 1 IS O 0217 00726 Visit priority code 

26 8 DT O 00727 Previous treatment date 

27 2 IS O 0112 00728 Expected discharge disposition 

28 8 DT O 00729 Signature on file date 

29 8 DT O 00730 First similar illness date 

30 80 CE O 0218 00731 Patient charge adjustment code 

31 2 IS O 0219 00732 Recurring service code 

32 1 ID O 0136 00733 Billing media code 

33 26 TS O 00734 Expected surgery date & time 

34 1 ID O 0136 00735 Military partnership code 

35 1 ID O 0136 00736 Military non-availability code 

36 1 ID O 0136 00737 Newborn baby indicator 

37 1 ID O 0136 00738 Baby detained indicator 

3.3.4.0 PV2 field definitions 

Usage notes: We do not anticipate that immunization registries will need to use any of the fields 

in the PV2 message segment; therefore, we do not define any of these fields further. 

53 
 

 

 

 

3.3.5	 Next of Kin (NK1)/Associated Parties Segment 

Contains information about the patient's next of kin and other associated or related parties. This 

segment is allowed to repeat, providing information about multiple related parties. 

NK1 Attributes 

SEQ LEN DT R/O RP/# TBL# ITEM# ELEMENT NAME 

1 4 SI R 00190 Set ID - NK1 

2 48 XPN O Y 00191 Name 

3 60 CE O 0063 00192 Relationship 

4 106 XAD O Y 00193 Address 

5 40 XTN O Y 00194 Phone number 

6 40 XTN O Y 00195 Business phone number 

7 60 CE O 0131 00196 Contact role 

8 8 DT O 00197 Start date 

9 8 DT O 00198 End date 

10 60 ST O 00199 Next of kin/AP job title 

11 20 JCC O 0327/ 00200 Next of kin/AP job code/class 

0328 

12 20 CX O 00201 Next of kin/AP employee number 

13 90 XON O Y 00202 Organization name - NK1 

14 80 CE O 0002 00119 Marital status 

15 1 IS O 0001 00111 Sex 

16 26 TS O 00110 Date/time of birth 

17 2 IS O Y 0223 00755 Living dependency 

18 2 IS O Y 0009 00145 Ambulatory status 

19 80 CE O Y 0171 00129 Citizenship 

20 60 CE O 0296 00118 Primary language 

21 2 IS O 0220 00742 Living arrangement 

22 80 CE O 0215 00743 Publicity code 

23 1 ID O 0136 00744 Protection indicator 

24 2 IS O 0231 00745 Student indicator 

25 80 CE O 0006 00120 Religion 

26 48 XPN O Y 00746 Mother’s maiden name

27 80 CE O 0212 00739 Nationality 

28 80 CE O Y 0189 00125 Ethnic group 

29 80 CE O Y 0222 00747 Contact reason 

30 48 XPN O Y 00748 Contact person’s name

31 40 XTN O Y 00749 Contact person’s telephone number

32 106 XAD O Y 00750 Contact person’s address

33 32 CX O Y 00751 Next of kin/AP’s identifiers

34 2 IS O 0311 00752 Job status 

35 80 CE O Y 0005 00113 Race 

36 2 IS O 0295 00753 Handicap 

37 16 ST O 00754 Contact person social security # 

Example: These example segments provide the Social Security numbers of the patient’s parents:
 

NK1|1|KENNEDY^JACQUELINE^LEE|MTH^MOTHER^HL70063||||||||||||||||||||||||||||||898666725^^^^SS|<CR>
 

NK1|2|KENNEDY^JOHN^FITZGERALD|FTH^FATHER^HL70063||||||||||||||||||||||||||||||822546618^^^^SS|<CR>
 

These example segments provide contact information for Nurse Jane Lee Jones, who administered the
 

vaccine to the patient and completed the VAERS-1 form:
 

NK1|1|Jones^Jane^Lee^^RN|VAB^Vaccine administered by (Name)^HL70063|<CR>
 

NK1|2|Jones^Jane^Lee^^RN|FVP^Form completed by (Name)-Vaccine provider^HL70063|101 Main 

Street^^Atlanta^GA^38765^^O^^GA121||(404)554-9097^^WPN|<CR>
 

54 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3.3.5.0 NK1 field definitions 

Usage notes: We do not anticipate immunization registries using several NK1 fields (NK1 7-

15,17-20, 22-28, 30-31, 34-37); therefore, we do not provide definitions for them here. The NK1 segment 

should be used to send the mother’s full name (a core data element). NK1-2 - Name may be repeated to 

also send the mother’s maiden name. If the mother’s maiden name is sent in the NK1, it should also be 

mapped to PID-6 – Mother’s maiden name. 

NK1 3.3.5.1 Set ID - NK1 (SI-4, Required) 00190 

Definition: The Set ID field numbers the repetitions of the segment within its association with the 

PID. For the first occurrence of the segment, the sequence number shall be one, for the second 

occurrence, the sequence number shall be two, etc. 

SI data type is a non-negative integer in the form of an NM field. The uses of this data type are defined in the chapters 

defining the segments and messages in which it is used. 

In our VXX, VXU #2 and VXR examples, 1 indicates that this segment is the first set of next of kin data, in 

this case the mother's information, and 2 indicates that this is the second next of kin data, the father's. 

NK1 3.3.5.2 Name (XPN-48, Optional, Repeating) 00191 

Definition: This field gives the name of the next of kin or associated party. Multiple names for the 

same person are allowed, but the legal name must be sent in the first sequence. If the legal name is not 

sent, then the repeat delimiter must be sent in the first sequence. 

XPN data type components: <family name (ST)>&<last name prefix (ST)>^<given name (ST)>^<middle initial or name 

(ST)>^<suffix (e.g., JR or III) (ST)>^<prefix (e.g., DR) (ST)>^<degree (e.g., MD) (IS)>^<name type code 

(ID)>^<name representation code (ID)> 

For valid values, refer to User-defined Table 0360 - Degree for the degree component, to HL7 Table 0200 - Name type for 

the name type code, and to HL7 Table 4000 - Name/address representation for the name representation code. 

In our VXU #1, VXU #2, and VXR examples, we have shown the mother as Jacqueline Lee Kennedy. In 

our VXU #2 and VXR examples, we have also shown the father as John Fitzgerald Kennedy. 

In our VAERS ORU example, the vaccine administrator is Jane Lee Jones, who also completed the 

VAERS-1 form. 

NK1 3.3.5.3 Relationship (CE-60, Optional) 00192 

Definition: This field defines the personal relationship of the next of kin. User-defined Table 0063 

-Relationship gives suggested values as defined in HL7 Standard Version 2.4. It is recommended that 

the original table in Version 2.0 of the Guide, which was based on X12N standard relationship codes, be 

replaced with the new HL7 table from Version 2.4 in order to keep the codes consistent with the newer 

HL7 implementations. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1)	 Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2)	 Text (ST). Name or description of the item in question. 

(3)	 Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

In our vaccine record examples, we have used this field to code the relationships of the mother and father 

to the patient. This segment can be used to record information about any person with a relation to the 

patient. It is not limited to relatives, but the relationship to the patient should be coded. 

55 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

NK1 3.3.5.4 Address (XAD-106, Optional, Repeating) 00193 

Definition: This field lists the mailing address of the next of kin/associated party. Multiple 

addresses for the same person may be sent in the following sequence: the primary mailing address must 

be sent first in the sequence; if the mailing address is not sent, then a repeat delimiter must be sent in the 

first sequence. If there is only one repetition of this field and an address type is not given, it is assumed 

to be the primary mailing address. 

XAD data type components: <street address (ST)>^ <other designation (ST)>^<city (ST)>^<state or province (ST)>^<zip 

or postal code (ST)>^<country (ID)>^<address type (ID)>^<other geographic designation (ST)>^<county/parish 

code (IS)>^<census tract (IS)>^<address representation code (ID)> 

For valid values in these components, refer to User-defined Table 0212 - Nationality for country codes, HL7 Table 0190 -

Address type for address type codes, User-defined Table 0289 - County/parish for county/parish codes, User-defined Table 

0288 - Census Tract for census tract codes, and HL7 Table 4000 - Name/address representation for address representation 

codes. 

We recommend using the USPS format for recording street address, other designation, city, state, and 

zip or postal code (available at <www.usps.gov>). When sending multiple addresses, the appropriate 

type code must be indicated. 

In our examples, we have not valued this field. 

NK1 3.3.5.5 Phone number (XTN-40, Optional, Repeating) 00194 

Definition: The next of kin/associated party’s personal phone numbers. All personal phone 

numbers for the next of kin/associated party are sent in this sequence. The first sequence is considered 

the primary number. If the primary number is not sent, then a repeat delimiter is sent in the first 

sequence. 

XTN data type format and components: [NNN] [(999)]999-9999[X99999][B99999][C any text]^<telecommunication use 

code (ID)>^<telecommunication equipment type (ID)>^<email address (ST)>^<country code (NM)>^<area/city code 

(NM)>^<phone number (NM)>^<extension (NM)>^<any text (ST)> 

Refer to HL7 Table 0201 - Telecommunication use code and HL7 Table 0202 - Telecommunication equipment type for valid values. 

In our examples, we have not valued this field. 

NK1 3.3.5.6 Business phone number (XTN-40, Optional, Repeating) 00195 

Definition: Next of kin/associated party’s business phone numbers. The first sequence is the 

primary number. If the primary number is not sent, then a repeat delimiter is sent in the first sequence. 

XTN data type format and components: [NNN] [(999)]999-9999[X99999][B99999][C any text]^<telecommunication use 

code (ID)>^<telecommunication equipment type (ID)>^<email address (ST)>^<country code (NM)>^<area/city code 

(NM)>^<phone number (NM)>^<extension (NM)>^<any text (ST)> 

Refer to HL7 Table 0201 - Telecommunication use code and HL7 Table 0202 - Telecommunication equipment type for valid values. 

In our NK1 example on the preceding page, we have listed (404)554-9097 as the value for this field. 

NK1 3.3.5.16 Date/time of birth (TS-26, Optional) 00110 

Definition: This field contains the next of kin/associated party's date of birth. 

Time stamp (TS) data type must be in the format:
 

YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]^<degree of precision>
 

Note: The optional degree of precision component is retained for backward compatibility only. Immunization registries will not value 

this component. 

In our examples, we have not valued this field. 

56 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

NK1 3.3.5.21 Living arrangement (IS-2, Optional) 00742 

Definition: This field identifies the situation that the associated party lives in at his or her 

residential address. Refer to User-defined Table 0220 - Living arrangement for suggested values. 

Immunization registries may use this field to record whether this associated party lives with the patient. 

The IS data type follows the formatting rules for an ST field except that it is drawn from a site-defined (or user-defined) 

table of legal values. 

In our examples, we have not valued this field. 

NK1 3.3.5.29 Contact reason (CE-80, Optional, Repeating) 00747 

Definition: This field identifies the role the next of kin/associated party plays with respect to the 

patient. Immunization registries may use this field to indicate the next of kin/associated party who is 

designated to receive reminder/recall notices, if applicable. This field may also be used to indicate the 

next of kin/associated party who is responsible for the patient’s care. Refer to User-defined Table 0222 -

Contact reason for suggested values. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1)	 Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2)	 Text (ST). Name or description of the item in question. 

(3)	 Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

In our examples, we have not valued this field. 

NK1 3.3.5.33 Next of kin/associated party’s identifiers (CX-32, Optional, Repeating) 00751 

Definition: This field contains identifiers for the next of kin/associated party. Examples include 

Social Security number, driver’s license number, Medicaid number, WIC client number, etc. This field, not 

NK1-37 - Contact Person Social Security #, should be used to record all identifiers, including SSN. 

CX data type components: <ID (ST)>^<check digit (ST)>^<code identifying the check digit scheme employed
 

(ID)>^<assigning authority (HD)>^<identifier type code (IS)>^<assigning facility (HD)>
 

Components are defined as follows: 

(1)	 ID number (ST) 

(2)	 Check digit (ST) (The check digit used 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 null.) 

(3)	 Code identifying check digit scheme employed (ID) Refer to HL7 Table 0061 - Check digit scheme for valid values. (4)	 Assigning authority (HD) 

Subcomponents of (4):	 <application identifier 1 (ID)> & <application identifier 2 (ID)> & <application 

identifier 3 (ID)> & <application identifier 4 (ID)> & <application identifier 5 (ID)> & <application 

identifier 6 (ID)> 

(5)	 Identifier type code (IS) 

A code corresponding to the type of identifier. This code may be used as a qualifier to the “Assigning authority” 

component. Refer to User-defined Table 0203 - Identifier type for suggested values. 

(6)	 Assigning facility (HD) 

Definition: The place or location identifier where the identifier was first assigned to the patient-part of the history of 

the identifier. 

Subcomponents of (6): <namespace ID (IS)>&<universal ID (ST)>&<universal ID type (ID)> 

In our VXU #2 and VXR examples, we show 898-66-6725 (expressed without hyphens) as the mother's 

SSN and 822-54-6618 as the father's. 

57 
 

 

 

 

 

 

 

6.4 FINANCIAL MANAGEMENT MESSAGE SEGMENTS 

Note: The Financial Management Message Segments listed below are optional segments in the 

message syntax for VXR and VXU. We do not anticipate immunization registries using these segments 

and do not provide field definitions or examples here. 

6.4.6 Insurance (IN1) Segment 

The IN1 segment contains insurance policy coverage information necessary to produce properly 

pro-rated patient and insurance bills. 

6.4.7 Insurance Additional Information (IN2) Segment 

The IN2 segment contains additional insurance policy coverage and benefit information 

necessary for proper billing and reimbursement. Fields used by this segment are defined by CMS 

(formerly HCFA) or other regulatory agencies. 

6.4.8 Insurance Additional Information, Certification (IN3) Segment 

The IN3 segment contains additional insurance information for certifying the need for patient care. 

Fields used by this segment are defined by CMS (formerly HCFA) or other regulatory agencies. 

58 
 

 

 

 

 

 

 

 

 

 

 

4.8 PHARMACY/TREATMENT ORDERS 

4.3.1 Common Order (ORC) Segment 

Used to transmit fields that are common to all orders (all types of services that are requested). 

ORC Attributes 

SEQ LEN DT R/O RP/# TBL# ITEM# ELEMENT NAME 

1 2 ID R 0119 00215 Order control 

2 22 EI C 00216 Placer order number 

3 22 EI C 00217 Filler order number 

4 22 EI O 00218 Placer group number 

5 2 ID O 0038 00219 Order status 

6 1 ID O 0121 00220 Response flag 

7 200 TQ O 00221 Quantity/timing 

8 200 CM O 00222 Parent 

9 26 TS O 00223 Date/time of transaction 

10 120 XCN O 00224 Entered by 

11 120 XCN O 00225 Verified by 

12 120 XCN O 00226 Ordering provider 

13 80 PL O 00227 Enterer’s location

14 40 XTN O Y/2 00228 Call back phone number 

15 26 TS O 00229 Order effective date/time 

16 200 CE O 00230 Order control code reason 

17 60 CE O 00231 Entering organization 

18 60 CE O 00232 Entering device 

19 120 XCN O 00233 Action by 

20 40 CE O 0339 01310 Advanced beneficiary notice code 

21 60 XON O Y 01311 Ordering facility name 

22 106 XAD O Y 01312 Ordering facility address 

23 48 XTN O Y 01313 Ordering facility phone number 

24 106 XAD O Y 01314 Ordering provider address 

Example:
 

ORC|RE|||||||||||1234567^Welby^Marcus^J^Jr^Dr.^MD^L|||||||||Peachtree Clinic|101 Main Street^^Atlanta^
 

GA^38765^^O^^GA121|(404)554-9097^WPN|101 Main Street^^Atlanta^GA^38765^^O^^GA121|<CR>
 

4.3.1.0 ORC field definitions 

Usage notes: This is an optional segment in the message syntax for VXR and VXU. We do not 

anticipate immunization registries using this segment for vaccine record reporting, but it is needed in the 

ORU VAERS message to state the name and address of the provider filing the report in fields ORC 21-

24. If the segment is used, the following string indicates a minimum response: 

ORC|OK|<placer order number>|<filler order number>|<CR> 

ORC 4.3.1.1 Order Control (ID-2, Required) 00215 

Definition: Determines the function of the order segment. Refer to HL7 Table 0119 – Order 

control codes and their meaning for valid entries. 

ID coded value for HL7 –defined tables: 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. Examples of ID fields include MSH-12-Version ID and PD1-12-Protection indicator. 

For VAERS reporting, the code for this field is RE, indicating that observations will follow. 

ORC 4.3.1.12 Ordering provider (XCN-120, Optional, Repeating) 00226 

59 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Definition: This field contains the identity of the person who is responsible for creating the 

request (i.e., ordering physician). ORC-12-ordering provider should have the same value as OBR-16-

ordering provider. 

XCN data type components: <ID number (ST)> ^ <family name (ST)> & <last name prefix (ST)> ^ <given name (ST)> ^ 

<middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) 

(ST)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code(ID)> ^ <identifier check digit (ST)> 

^ <code identifying the check digit scheme employed (ID )> ^ <identifier type code (IS)> ^ <assigning facility 

(HD)> ^ <name representation code (ID)> 

Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID) 

Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID) 

Note: Refer to XCN definition in Appendix 2 for valid code values. 

In the VAERS ORU example, the physician responsible for ordering the vaccinations is identified as Dr. 

Marcus J. Welby, Jr., whose identification number is 1234567. 

ORC 4.3.1.21 Ordering facility name (XON-60, Optional, Repeating) 01311 

Definition: This field contains the name of the facility placing the order. 

XON data type components: <organization name (ST)>^ <organization name type code (IS)>^<ID number 

(NM)>^<check digit (NM)>^<code identifying the check digit scheme employed (ID)>^<assigning authority 

(HD)>^<identifier type code (IS)>^<assigning facility ID (HD)>^<name representation code (ID)> 

Subcomponents of assigning authority: <namespace ID (IS)>&<universal ID (ST)>&<universal ID type (ID)> 

Subcomponents of assigning facility: <namespace ID (IS)>&<universal ID (ST)>&<universal ID type (ID)> 

Refer to User-defined Table 0204 - Organizational Name Type for the second component, to HL7 Table 0061 - Check 

Digit Scheme for the fifth component, to User-defined Table 0203 - Identifier Type for the seventh component, and to 

HL7 Table 4000 - Name/address representation for the last component. 

In our VAERS ORU example, we have listed Peachtree Clinic as the facility where the vaccination was 

ordered and administered. 

ORC 4.3.1.22 Ordering facility address (XAD-106, Optional, Repeating) 01312 

Definition: This field contains the address of the facility placing the order. The state (Item #1) 

and County (Item # 2) on the VAERS-1 (FDA) form where the vaccine was administered should be drawn 

from this field. 

XAD data type components: <street address (ST)>^ <other designation (ST)>^<city (ST)>^<state or province 

(ST)>^<zip or postal code (ST)>^<country (ID)>^<address type (ID)>^<other geographic designation 

(ST)>^<county/parish code (IS)>^<census tract (IS)>^<address representation code (ID)> 

For valid values in these components, refer to User-defined Table 0212 - Nationality for country codes, HL7 Table 

0190 - Address type for address type codes, User-defined Table 0289 - County/parish for county/parish codes, Userdefined Table 0288 - Census Tract for census tract codes, and HL7 Table 4000 - Name/address representation for 

address representation codes. 

In our VAERS ORU example, we have listed the address for the facility where the vaccines were 

administered as 101 Main Street, Atlanta, GA 38765. 

ORC 4.3.2.23 Ordering facility phone number (XTN-48, Optional, Repeating) 01313 

Definition: This field contains the telephone number of the facility placing the order. 

XTN data type format and components: [NNN] [(999)]999-9999[X99999][B99999][C any 

text]^<telecommunication use code (ID)>^<telecommunication equipment type (ID)>^<email address 

(ST)>^<country code (NM)>^<area/city code (NM)>^<phone number (NM)>^<extension (NM)>^<any text 

(ST)> 

Refer to HL7 Table 0201 - Telecommunication use code and HL7 Table 0202 – Telecommunication 

equipment type for valid values. 

In our VAERS ORU example, we have listed the work phone number for Peachtree Clinic. 

ORC 4.3.1.24 Ordering provider address (XAD-106, Optional, Repeating) 01314 

60 
 

 

 

 

 

 

 

 

Definition: This field contains the address of the care provider requesting the order. 

XAD data type components: <street address (ST)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or 

province (ST)> ^ <zip or postal code(ST)> ^ <country (ID)> ^ < address type (ID)> ^ <other geographic 

designation (ST)> ^ <county/parish code (IS)> ^ <census tract (IS)> ^ <address representation code (ID)> 

For valid values in these components, refer to User-defined Table 0212 - Nationality for country codes, HL7 Table 0190 -

Address type for address type codes, User-defined Table 0289 - County/parish for county/parish codes, User-defined 

Table 0288 - Census Tract for census tract codes, and HL7 Table 4000 - Name/address representation for address 

representation codes. 

In our VAERS ORU example, we have shown the address for the provider to be the same as that of the 

facility. 

61 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4.8.3 Pharmacy/Treatment Route (RXR) Segment 

The Pharmacy/Treatment Route Segment contains the alternative combination of route, site, 

administration device, and administration method that are prescribed. For immunization registries, the 

actual route and site used should be recorded. 

RXR Attributes 

SEQ LEN DT R/O RP/# TBL# ITEM# ELEMENT NAME 

1 60 CE R 0162 00309 Route 

2 60 CE O 0163 00310 Site 

3 60 CE O 0164 00311 Administration Device 

4 60 CE O 0165 00312 Administration Method 

5 60 CE O 01315 Routing Instruction 

Example:
 

RXR|IM^INTRAMUSCULAR^HL70162|LA^LEFT ARM^HL70163|<CR>
 

This RXR segment shows that a vaccine was administered intramuscularly in the left arm.
 

4.8.3.0 RXR field definitions 

Usage notes: We do not anticipate immunization registries using several RXR fields (RXR-3-5); 

therefore, we do not provide definitions for them here. 

RXR 4.8.3.1 Route (CE-60, Required) 00309 

Definition: This field is the route of administration (e.g., intramuscular, oral, etc.). Refer to HL7 

Table 0162 - Route of administration for valid values. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1)	 Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2)	 Text (ST). Name or description of the item in question. 

(3)	 Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

In our VXU #2 and VXR examples, DTaP-Hib and DTaP vaccines were administered intramuscularly, and 

MMR was administered subcutaneously. 

RXR 4.8.3.2 Site (CE-60, Optional) 00310 

Definition: This field contains the site of the administration route (e.g., left arm, right leg). Refer to 

HL7 Table 0163 - Administrative site for valid values. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1)	 Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2)	 Text (ST). Name or description of the item in question. 

(3)	 Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

In our examples, all of the vaccines for which route is indicated were given in the left arm. 

62 
 

 

 

 

 

 

 

4.8.14	 Pharmacy/Treatment Administration (RXA) Segment 

The RXA segment carries pharmacy administration data. It is a repeating segment in the VXR 

and VXU messages and can record unlimited numbers of vaccinations. 

RXA Attributes 

SEQ LEN DT R/O RP/# TBL# ITEM# ELEMENT NAME 

1 4 NM R 00342 Give sub-ID counter 

2 4 NM R 00344 Administration sub-ID counter 

3 26 TS R 00345 Date/time start of administration 

4 26 TS R 00346 Date/time end of administration 

5 100 CE R 0292 00347 Administered code 

6 20 NM R 00348 Administered amount 

7 60 CE C 00349 Administered units 

8 60 CE O 00350 Administered dosage form 

9 200 CE O Y 00351 Administration notes 

10 200 XCN O Y 00352 Administering provider 

11 200 CM C 00353 Administered-at location 

12 20 ST C 00354 Administered per (time unit) 

13 20 NM O 01134 Administered strength 

14 60 CE O 01135 Administered strength units 

15 20 ST O Y 01129 Substance lot number 

16 26 TS O Y 01130 Substance expiration date 

17 60 CE O Y 0227 01131 Substance manufacturer name 

18 200 CE O Y 01136 Substance refusal reason 

19 200 CE O Y 01123 Indication 

20 2 ID O 0322 01223 Completion status 

21 2 ID O 0323 01224 Action code-RXA 

22 26 TS O 01225 System entry date/time 

Example: 

RXA|0|1|19900607|19900607|08^HEPB-PEDIATRIC/ADOLESCENT^CVX|.5|ML^^ISO+|||||||| 

MRK12345||MSD^MERCK^MVX|<CR> 

This RXA segment shows that the first dose of a Hepatitis B vaccine, manufactured by Merck & Co., Inc., 

was administered on June 7, 1990. The dosage of the vaccine was .5mL, and the lot number was 

MRK12345. 

4.8.14.0 RXA field definitions 

RXA 4.8.14.1 Give sub-ID counter (NM-4, Required) 00342 

Definition: Use this field if matching this RXA segment to a corresponding RXG segment. If not 

matching, this field's value is zero. For immunization registries, this field’s value should always be zero.

In our examples, the value is 0. 

RXA 4.8.14.2 Administration sub-ID counter (NM-4, Required) 00344 

Definition: Starts with one the first time this medication is administered for this order and 

increases by increments of one with each additional administration of medication. This field can be used 

to record dose number for a particular vaccine series and product, if applicable. When the vaccine 

product administered is part of only one vaccine series (e.g., DTaP, MMR, etc.), a single digit number 

representing the series dose number should be entered. When a combination vaccine covering more 

than one series is administered, use the OBX segment to record dose numbers of various components as 

demonstrated at Section 7.3 of this document. If a vaccine is offered to the patient and refused, the 

number 0 should be recorded for the dose number in RXA-2 (see RXA-18 for recording refusal reason). 

63 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Since RXA-2 is a required field in HL7, registries who choose not to record dose number should 

enter “999" in this field. 

In our VXU #1, VXU #2, and VXR #1 examples, we show the first dose of Hepatitis B vaccine. In our 

VXU #2 and VXR #1 examples, we also show the fourth dose of DTaP and Hib vaccines (given in the first 

dose of a combination DTaP-Hib vaccine), the fifth dose of DTaP, and the first and second doses of 

MMR. Our VXR example also illustrates the administration of a tuberculosis test and the report of its 

result. 

RXA 4.8.14.3 Date/time start of administration (TS-26, Required) 00345 

Definition: This field records when the administration is started. We use this field to show the 

vaccination date. 

Time stamp (TS) data type must be in the format: 

YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]^<degree of precision> 

Note: The optional degree of precision component is retained for backward compatibility only. Immunization registries will not value 

this component. 

In our VXR #1 example, we show Hepatitis B given on June 7, 1990; DTaP’s on December 7, 1990, and 

May 20, 1995; DTaP-Hib on September 7, 1991; and MMR’s given on September 7, 1991, and May 20, 

1995. 

RXA 4.8.14.4 Date/time end of administration (if applies) (TS-26, Required) 00346 

Definition: Where administration continues over some time, the end date/time may be recorded. 

For typical vaccines, the end of administration is the same as the start of administration given in RXA-3 

date/time start of administration, so the RXA-3 date is repeated in RXA-4. 

Time stamp (TS) data type must be in the format: 

YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]^<degree of precision> 

Note: The optional degree of precision component is retained for backward compatibility only. Immunization registries will not value 

this component. 

In our examples, the values for end of administration are the same as for start of administration. 

RXA 4.8.14.5 Administered code (CE-100, Required) 00347 

Definition: This field identifies the medical substance administered. If the substance administered 

is a vaccine, CVX codes should be used in the first triplet to code this field (see HL7 Table 0292 - Codes 

for vaccines administered). The second set of three components could be used to represent the same 

vaccine using a different coding system, such as Current Procedural Terminology (CPT). The most up-todate version of the CVX code set and a mapping between the CVX and CPT codes are available on the 

CDC/NIP website at <http://www.cdc.gov/nip/registry/cpt.htm>. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1) Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2) Text (ST). Name or description of the item in question. 

(3) Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

In our VXU #1, VXU #2, and VXR #1 examples, we show administration of Hepatitis B vaccine. In our 

VXU #2 and VXR examples, we also show administration of MMR, DTaP-Hib, and DTaP vaccines. The 

first triplet of the CE data type gives the CVX vaccine codes as defined in HL7 Table 0292 - Codes for 

64 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

vaccines administered. The second triplet gives the CPT codes for the same vaccine. The VXR #1 

example also shows administration of a tuberculosis test. 

RXA 4.8.14.6 Administered amount (NM-20, Required) 00348 

Definition: This field records the amount of pharmaceutical administered. The units are 

expressed in the next field, RXA-7. Registries that do not collect the administered amount should record 

the value “999” in this field. 

In our examples, the amount of each vaccine administered was .5 mL. 

RXA 4.8.14.7 Administered units (CE-60, Conditional) 00349 

Definition: This field is conditional because it is required if the administered amount code does not 

imply units. Must be in simple units that reflect the actual quantity of the substance administered. It does 

not include compound units. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1)	 Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2)	 Text (ST). Name or description of the item in question. 

(3)	 Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

In our examples, we show ML to designate milliliter and ISO+ as the coding system. If no coding system 

is listed, ISO+ is the default system. 

RXA 4.8.14.8 Administered dosage form (CE-60, Optional) 00350 

Definition: The dosage form indicates the manner in which the medication is aggregated for 

dispensing, e.g., tablets, capsules, suppositories. In some cases, this information is implied by the 

dispense/give code in RXA-5. Use this field when the administered code does not specify the dosage 

form. Generally, immunization registries will not need to use this field. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined in Appendix 2, 2.8.3. 

In our examples, we have not valued this field. 

RXA 4.8.14.9 Administration notes (CE-200, Optional, Repeating) 00351 

Definition: Free text notes from the provider administering the medication. If coded, requires a 

user-defined table. If free text, place a null in the first component and the text in the second, e.g., |^this is 

a free text administration note|. Immunization registries may use this field to record information that is not 

found elsewhere in the message; e.g., indicate the source of information for this immunization record or, 

more generically, whether the immunization being reported has just been administered (new) or came 

from other records (historical). Refer to NIP-defined Table 0001 - Immunization Information Source for 

these codes. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

65 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CE data type components are defined as follows: 

(1)	 Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2)	 Text (ST). Name or description of the item in question. 

(3)	 Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

In our VXU #2 and VXR #1 examples, the Hepatitis B vaccine came from a parent’s immunization history;

the DTaP-Hib was new; and the information sources for the remaining immunizations (MMR and DTaP) 

are not stated. 

RXA 4.8.14.10 Administering provider (XCN-200, Optional, Repeating) 00352 

Definition: This field is intended to contain the name and provider ID of the person physically 

administering the pharmaceutical. This person (the “vaccinator”) should be listed first. In addition, 

immunization registries may desire to record the provider who ordered the immunization (the “orderer”)

and/or the person who recorded the immunization into the registry (the “recorder”). These persons may

also be listed. In order to distinguish between these persons, the following identifier type codes should be 

used: VEI - for vaccinator employee number; OEI - for orderer employee number (Note: The person 

identified by this code should be the same person listed in ORC-12, Orderer, for those systems that use 

the ORC segment); and REI - for recorder employee number. 

Components of the XCN data type: <ID number (ST)>^<family name (ST)>&<last name prefix (ST)>^<given name 

(ST)>^<middle initial or name (ST)>^<suffix (e.g., Jr. or III) (ST)>^<prefix (e.g., Dr.) (ST)>^<degree (e.g., MD) 

(IS)>^<source table (IS)>^<assigning authority (HD)>^<name type code (ID)>^<identifier check digit (ST)>^<code 

identifying the check digit scheme employed (ID)>^<identifier type code (IS)>^<assigning facility ID (HD)>^<name 

representation code (ID)> 

Subcomponents of assigning authority: <namespace ID (IS)>&<universal ID (ST)> & <universal ID type (ID)> 

Subcomponents of assigning facility: <namespace ID (IS)>&<universal ID (ST)> & <universal ID type (ID)> 

In our VXU #2 and VXR examples, the new vaccines were administered by Nurse Sally S. Smith, with ID 

number 1234567890 and ID type VEI. Dr. Robert A. O'Brian, ID number 1234567891, ordered the 

vaccinations and was listed with an OEI ID type. The historical vaccination was administered by Lisa 

Jones, with no ID number listed. 

RXA 4.8.14.11 Administered at location (CM-200, Conditional) 00353 

Definition: Name and address of facility where medical substance was administered. 

The specific components of fields using the CM data type are defined within the field descriptions. 

The components for this field are: <point of care (IS)>^< room (IS)>^<bed (IS)>^< facility (HD)>^<location status (IS)>^<patient 

location type (IS)>^<building (IS)>^<floor (IS)>^<street address (ST)>^< other designation (ST)>^<city (ST)>^<state or 

province (ST)>^<zip or postal code (ST)>^<country (ID)>^<address type (ID)>^<other geographic designation (ST)> 

Subcomponents of facility (HD): <namespace ID (IS)>&<universal ID (ST)>&< universal ID type (ID)> 

In our VXU #2 and VXR examples, we used Child Healthcare Clinic at 101 Main Street, Boston, MA as 

the facility location for the new vaccinations. The historical vaccination was administered at Children’s

Hospital, with no further address. 

RXA 4.8.14.12 Administer per (time unit) (ST-20, Conditional) 00354 

Definition: This field records the rate at which this medication was administered. Except for 

intravenous administrations, this field is not likely to be used by immunization registries. 

In our examples, we have not valued this field. 

RXA 4.8.14.13 Administered strength (NM-20, Optional) 01134 

66 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Definition: Use when RXA-5-administered code does not imply the strength. This is the numeric part of 

the strength, used in combination with RXA-14 Administered Strength Unit. 

In our VXU #2 and VXR #1 examples, we used this field only for Hepatitis B vaccine, where we indicated 

.5 mcg for the pediatric/adolescent formulation. 

RXA 4.8.14.14 Administered strength unit (CE-60, Optional) 01135 

Definition: Use when RXA-5-administered code does not specify the strength. This is the unit of 

the strength, used in combination with RXA-13-administered strength. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1)	 Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2)	 Text (ST). Name or description of the item in question. 

(3)	 Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

Note: These units can be a compound quantity; i.e., the units may express a quantity per unit of time. For 

example, micrograms per hour (ug/hr) is an acceptable value. 

In our VXU #2 and VXR #1 examples, we used MCG for micrograms and ISO+ for the coding system for 

the Hepatitis B vaccine only. 

RXA 4.8.14.15 Substance lot number (ST-20, Optional, Repeating) 01129 

Definition: This field records the lot number of the medical substance administered. 

Note: The lot number is defined as the number printed on the label attached to the container 

holding the substance and on the packaging that houses the container. If the substance is a vaccine and 

a diluent is required, a lot number may appear on the vial containing the diluent; however, any such 

identifier associated with a diluent is not the identifier of interest. The substance lot number should be 

reported, not that of the diluent. 

In our examples, the lot numbers (e.g., W2341234567 for second dose MMR) are listed for each of the 

newly administered vaccines. 

RXA 4.8.14.16 Substance expiration date (TS-26, Optional, Repeating) 01130 

Definition: This field identifies the expiration date of the medical substance administered. 

Time stamp (TS) data type must be in the format:
 

YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]^<degree of precision>
 

Note: The optional degree of precision component is retained for backward compatibility only. Immunization registries will not value 

this component. 

Note: Vaccine expiration date does not always have a "day" component. Such a date may be 

transmitted as YYYYMM. 

In our VXU #2 and VXR #1 examples, the expiration date (e.g., June 30, 1995 for the second dose MMR) 

is listed for each of the newly administered vaccines. 

67 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

RXA 4.8.14.17 Substance manufacturer (CE-60, Optional, Repeating) 01131 

Definition: This field records the manufacturer of the medical substance administered. For 

purposes of transmission of immunization data in immunization registries, the MVX codes from the HL7 

Table 0227 - Manufacturers of vaccines should be used. 

The manufacturer names and codes have changed over the years, and users are referred to the current 

codes that are located at www.cdc.gov/nip/registry/mvx.pdf. However, please note that the manufacturer 

names given in the second component of the CE data type in our examples continue to reflect the correct 

name and code at the time the vaccines in the example messages were administered. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1) Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2) Text (ST). Name or description of the item in question. 

(3) Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

RXA 4.8.14.18 Substance refusal reason (CE-200, Optional, Repeating) 01136 

Definition: When applicable, this field records the reason the patient refused the medical 

substance. Any entry in the field indicates that the patient did not take the substance. The vaccine that 

was offered should be recorded in RXA-5, with the number 0 recorded for the dose number in RXA-2. 

See discussion at RXA 4.8.14.20 below. Do not record contraindications and immunities in this field. 

They should be recorded in OBX segments. See discussion at 7.3 -- Observation Reporting Segments. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1)	 Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2)	 Text (ST). Name or description of the item in question. 

(3)	 Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

If the vaccination is refused by the patient or guardian, this field will record the vaccine refusal reason. 

See NIP-defined Table 002 - Substance refusal reason for valid values. 

In our VXR #1 example, we show the DTaP vaccine being refused by parental decision. 

RXA 4.8.14.19 Indication (CE-200, Optional) 01123 

Definition: This field contains the identifier of the condition or problem for which the 

drug/treatment was prescribed. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1)	 Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2)	 Text (ST). Name or description of the item in question. 

(3)	 Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

68 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

In our examples, we have not valued this field. 

RXA 4.8.14.20 Completion status (ID-2, Optional) 01223 

Definition: This field indicates the status of the treatment administration event. Refer to HL7 

Table 0322 - Completion status for valid values. If the substance is refused, RXA-18 - Substance refusal 

reason should be valued as well. The vaccine that was offered should be recorded in RXA-5, with the 

number 0 recorded for the dose number in RXA-2. If the substance is not administered because it was 

contraindicated, an OBX segment may be provided to record the specific contraindication. 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

In our VXR #1 example, we show “RE” to indicate that the DTaP was offered and was refused. The

DTaP-Hib vaccine administration is shown as “CP” for complete.

RXA 4.8.14.21 Action code (ID-2, Optional) 01224 

Definition: Status of record. This field provides a method of correcting vaccination information 

previously transmitted with incorrect patient identifying information. Refer to HL7 Table 0323 - Action 

code for valid values. 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

In our VXU #2 and VXR #1 examples, we showed the use of this field in the DTaP-Hib vaccine 

administration as “A” for add.

RXA 4.8.14.22 System entry date/time (TS-26, Optional) 01225 

Definition: This field records the date/time the administration information was entered into the 

source system. This field is used to detect instances where treatment administration information is 

inadvertently entered multiple times by providing a unique identification field. Under usual circumstances, 

this field would be provided automatically by the computer system rather than being entered by a person. 

Time stamp (TS) data type must be in the format:
 

YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]^<degree of precision>
 

Note: The optional degree of precision component is retained for backward compatibility only. Immunization registries will not value 

this component. 

In our VXR #1 and VXU #2 examples, we showed the use of this field in the DTaP-Hib vaccine 

administration as the computer-generated time of September 7, 1991 at 12:00:30. 

69 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

7.3	 OBSERVATION REPORTING SEGMENTS 

Use of OBX Segments 

OBX segments have great flexibility to report information. When properly coded, OBX segments report a 

large amount of information in a small amount of space. OBX segments within the ORU message are 

widely used to report laboratory and other clinical information. For immunization registries, these 

segments can be configured within the VXR and VXU messages to code adverse events, allergies related 

to vaccines, and many other kinds of data. For information that is commonly reported among registries, 

nationally standardized code sets such as Logical Observation Identifier, Names and Codes (LOINC®) 

are preferred over local user-defined code sets to facilitate a common vocabulary among registries. Code 

sets in this document that HL7 allows to be user-defined will be agreed upon by participants in the 

development of this document so that registries can efficiently exchange information. Registries are 

discouraged from establishing their own code sets, and instead are asked to coordinate their data needs 

through NIP so that all users will have a common vocabulary. NIP will maintain the latest version of these 

tables on its web site at <www.cdc.gov/nip/registry>. 

The optional, repeating OBX segment in the VXR and VXU messages provides information about a single 

vaccine event. It includes a field that identifies what kind of observation will be recorded in this segment 

(e.g., contraindication-can be used to indicate what condition the patient had that contraindicated receipt 

of the vaccine when RXA-18 indicates that the vaccine was not given and the RXA dose number is 

valued as zero). The optional Notes and Comments (NTE) segment is allowed to repeat and may be 

inserted after any of the OBX segments. The note segment applies to the information in the segment that 

immediately precedes it, i.e., the observation reported in the preceding OBX segment. The NTE segment 

can carry any text relevant to the vaccine event or the observation and can give its source. The NTE 

segment is not further defined by HL7. 

HL7 does not require the use of a particular coding system to identify either the observation or the result. 

In the past, users tended to invent their own unique code systems for identifying tests and other clinical 

observations because standard codes were not available. Such local code systems suffice for 

transmitting information within single institutions, but present high barriers to aggregating data from many 

sources for research or for public health record systems. Standard code systems such as LOINC® and 

others included in User-defined Table 0396 now exist for many of these purposes, and we strongly 

encourage their use in immunization registry reporting. Standard codes can be sent as the only code, or 

they can be sent along with the local historic code as the second code system represented in the field (a 

CE data type allows for two coded representations of the same concept within a single field). When two 

different codes for the same information are sent this way in OBX segments, immunization registries 

should send the nationally standardized code in the first triplet of the CE data type. 

For immunization registries, several categories of information have been identified that may be reported 

using the OBX segment in immunization messages. LOINC® codes for values in OBX-3 are provided in 

NIP-defined Table NIP003 - Observation identifiers. NIP has defined other tables in this document (see 

NIP-defined Tables NIP001, NIP002, NIP004, and NIP005) that reflect concepts particularly relevant to 

immunization registry reporting where no standardized code set has been identified. The data type for 

the results shown in OBX-5 will be designated in OBX-2. Suggested data types for these results are 

provided in NIP-defined Table NIP003 - Observation Identifiers. Code tables for use in OBX-5 are also 

provided in NIP-defined Table NIP003 - Observation Identifiers. 

Examples of the following uses of OBX are given in the VXR examples: 

1.	 Dose number for component antigens in combination vaccines when individual component dose 

numbers are different from the dose number of the combination vaccine 

2.	 Contraindications, Precautions, and Immunities 

3.	 Vaccine Adverse Event Reporting (VAERS) 

4.	 Date Vaccine Information Statement (VIS) Published 

5.	 Date Vaccine Information Statement (VIS) Presented 

6.	 Vaccines Due Next 

70 
 

 

 

7.3.1 Observation Request (OBR) Segment 

The Observation Request (OBR) segment is used within an Unsolicited Transmission of an Observation 

(ORU) message to define the attributes of a particular request for diagnostic services or clinical 

observations, and the attributes themselves follow the OBR in repeating OBX segments. The OBX 

segment is described in Section 7.3.2 below. 

In the VAERS ORU message, the first OBR identifies the message as a report using the VAERS-1 form. 

The subsequent OBR’s describe particular parts of the report for which detailed information is provided in

the associated OBX segments. As defined by the ORU syntax, there can be many OBX’s per OBR, and 

there can be many OBR’s per PID. 

OBR Attributes 

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME 

1 4 SI O 00237 Set ID – OBR 

2 22 EI C 00216 Placer Order Number 

3 22 EI C 00217 Filler Order Number + 

4 200 CE R 00238 Universal Service ID 

5 2 ID X 00239 Priority 

6 26 TS X 00240 Requested Date/Time 

7 26 TS C 00241 Observation Date/Time # 

8 26 TS O 00242 Observation End Date/Time # 

9 20 CQ O 00243 Collection Volume * 

10 60 XCN O Y 00244 Collector Identifier * 

11 1 ID O 0065 00245 Specimen Action Code * 

12 60 CE O 00246 Danger Code 

13 300 ST O 00247 Relevant Clinical Info. 

14 26 TS C 00248 Specimen Received Date/Time * 

15 300 CM O 0070 00249 Specimen Source * 

16 80 XCN O Y 00226 Ordering Provider 

17 40 XTN O Y/2 00250 Order Callback Phone Number 

18 60 ST O 00251 Placer Field 1 

19 60 ST O 00252 Placer Field 2 

20 60 ST O 00253 Filler Field 1 + 

21 60 ST O 00254 Filler Field 2 + 

22 26 TS C 00255 Results Rpt/Status Chng-Date/Time + 

23 40 CM O 00256 Charge to Practice + 

24 10 ID O 0074 00257 Diagnostic Serv Sect ID 

25 1 ID C 0123 00258 Result Status + 

26 400 CM O 00259 Parent Result + 

27 200 TQ O Y 00221 Quantity/Timing 

28 150 XCN O Y/5 00260 Result Copies To 

29 200 CM O 00261 Parent * 

30 20 ID O 0124 00262 Transportation Mode 

31 300 CE O Y 00263 Reason for Study 

32 200 CM O 00264 Principal Result Interpreter + 

33 200 CM O Y 00265 Assistant Result Interpreter + 

34 200 CM O Y 00266 Technician + 

35 200 CM O Y 00267 Transcriptionist + 

36 26 TS O 00268 Scheduled Date/Time + 

37 4 NM O 01028 Number of Sample Containers * 

38 60 CE O Y 01029 Transport Logistics of Collected 

Sample * 

39 200 CE O Y 01030 Collector's Comment * 

40 60 CE O 01031 Transport Arrangement Responsibility 

41 30 ID O 0224 01032 Transport Arranged 

42 1 ID O 0225 01033 Escort Required 

71 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

SEQ 

43 

44 

45 

LEN 

200 

80 

80 

DT 

CE 

CE 

CE 

OPT 

O 

O 

O 

RP/# 

Y 

Y 

TBL# 

0088 

0340 

ITEM # 

01034 

00393 

01316 

ELEMENT NAME 

Planned Patient Transport Comment 

Procedure Code 

Procedure Code Modifier 

Example: 

OBR|6|||30970-8^Adverse event following prior vaccination in sister^LN|<CR>
 

This example OBR segment identifies this section of the VAERS report as containing information about 

an adverse event following prior vaccination of the patient’s sister. 

7.3.1.0 OBR field definitions 

Usage Notes: We do not anticipate that several OBR fields (OBR-2-3, 5-6, 8-45) will be used for 

adverse event reporting purposes; therefore, we do not provide definitions for them here. 

OBR 7.3.1.1 Set ID (SI-4, Optional) 00237 

Definition: This field identifies the sequence number of one of multiple OBR’s under one PID. For

the first order transmitted, the sequence number shall be 1; for the second order, it shall be 2; and so on. 

For example, the second OBR under a single PID would appear as |2|. 

For VAERS reporting, OBR segments serve to name sections of the report. The set ID number for each 

OBR increases by one from the previous OBR-1. The example above indicates that this is the sixth OBR 

of the message. 

OBR 7.3.1.4 Universal service ID (CE-200, Required) 00238 

Definition: This field is the identifier code for the requested observation/test/battery. 

For vaccine adverse event reporting purposes, this field is used to identify the item on the VAERS-1 

(FDA) form for which information will follow in the OBX segments. Most OBR-4’s have an assigned

LOINC® code to specify the question on the VAERS form being addressed. Refer to NIP Table 003 –

Observation identifiers for VAERS reporting for valid entries. 

The CE data type transmits codes and the text associated with the code. This type has six components 

arranged in two groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1) Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2) Text (ST). Name or description of the item in question. 

(3) Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item.
 

(4-6) Three components analogous to 1-3 for the alternate or local coding system.
 

In our ORU example, we use the first OBR to identify this message as a VAERS-1 (FDA) report. 

Subsequent OBR’s name specific items to be reported in the associated OBX’s. 

OBR 7.3.1.7 Observation date/time (TS-26, Conditional) 00241 

Definition: This field is the clinically relevant date/time of the observation. When the OBR is 

transmitted as part of a report message, the field must be valued. 

For VAERS ORU reporting, this field should be valued in the first OBR of the message with the date the 

VAERS form was completed. 

72 
 

 

*  For vaccine adverse event reporting, LOINC codes are strongly recommended for OBX-3. 

 

 

 

 

 

 

 

 

 

7.3.2 Observation/Result (OBX) Segment 

Used to transmit an observation or observation fragment. It represents the smallest indivisible 

unit of a report. Its principal mission is to carry information about observations in report messages. The 

OBR, ORC, and OBX segments work together to provide a flexible structure for including detailed coded 

information. OBR gives general information about the details that will follow, ORC gives information on all 

services that are requested, while the OBX segment gives the specific, individual tests performed or 

report items (OBX-3) and the specific results for each test or answer for each report item (OBX-5). 

Vaccine adverse event reporting uses OBX-3 to state the subject of the information and OBX-5 to provide 

the specific related data. 

OBX Attributes 

SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME 

1 4 SI O 00569 Set ID-OBX 

2 3 ID C 0125 00570 Value type 

3 80 CE R 00571 Observation identifier* 

4 20 ST C 00572 Observation sub-ID 

5 655361 ** C Y2 00573 Observation value 

6 60 CE O 00574 Units 

7 60 ST O 00575 Reference ranges 

8 5 ID O Y/5 0078 00576 Abnormal flags 

9 5 NM O 00577 Probability 

10 2 ID O Y 0080 00578 Nature of abnormal test 

11 1 ID R 0085 00579 Observ result status 

12 26 TS O 00580 Date last obs normal values 

13 20 ST O 00581 User defined access checks 

14 26 TS O 00582 Date/time of the observation 

15 60 CE O 00583 Producer’s ID

16 80 XCN O Y 00584 Responsible observer 

17 60 CE O Y 00936 Observation method 

** The data type for OBX-5 can vary and is determined by OBX-2. 

1 The length of the observation value field is variable, depending upon value type. See OBX-2-value type.
 

2 May repeat for multipart, single answer results with appropriate data types, e.g., CE, TX, and FT data types.
 

Example: 

OBX|1|NM|30936-9^DTAP/DTP DOSE COUNT IN COMBINATION VACCINE^LN||4||||||F|<CR>
 

OBX|2|NM|30938-5^HAEMOPHILUS INFLUENZAE TYPE B (HIB) DOSE COUNT IN COMBINATION 

VACCINE^LN||4||||||F|<CR>
 

In these OBX segments, we report that this was the fourth dose of the DTAP/DTP component in the 

combination DTaP-Hib administered and the fourth dose of Hib as well. 

7.3.2.0 OBX field definitions 

Usage notes: There are two OBX fields that we do not anticipate that immunization registries will 

need to use, so we do not provide definitions for them here. These are OBX-12-13. 

OBX 7.3.2.1 Set ID - observation simple (SI-4, Optional) 00569 

Definition: This field contains the sequence number. Since OBX is a repeating segment in 

immunization messages, the number in this field will increase by one for each OBX used for a single 

RXA. 

SI data type is a non-negative integer in the form of an NM field. The uses of this data type are defined in the chapters 

defining the segments and messages in which it is used. 

In our VXR #1 example, for the DTaP-Hib vaccine, we show the first and second sequence number for 

the two OBX segments. 

73 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

In the VAERS example, the first OBX-1 after an OBR has the value of |1|. Each subsequent OBX-1 

increases its number by one. 

OBX 7.3.2.2 Value type (ID-3, Conditional) 00570 

Definition: This field contains the data type which defines the format of the observation value in 

OBX-5. A full explanation of possible data types is given below so that users will have complete 

information. However, for immunization registries, this field will usually be CE, NM, ST, DT, or TS. 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

Data types in OBX-2. This field must be a standard HL7-defined data type. It must be valued if OBX-11-

Observ result status is not valued with an X, meaning no results can be obtained for this observation. If 

the value is CE then the result must be a coded entry. When the value type is TX or FT then the results 

are bulk text. 

Although NM is a valid type, observations which are usually reported as numbers will sometimes have the 

string (ST) data type because non-numeric characters are often reported as part of the result, e.g., >300 

to indicate the result was off-scale for the instrument. In the example, ">300", ">" is a symbol and the 

digits are considered a numeric value. However, this usage of the ST type should be discouraged since 

the SN (structured numeric) data type now accommodates such reporting and, in addition, permits the 

receiving system to interpret the magnitude. All HL7 data types are valid, except CM, CQ, SI, and ID. 

This is because, for a CM definition to have meaning, the specifics about the CM must be included in the 

field definition. OBX-5-observation value is a general field definition that is influenced by the data type 

OBX-3, so CMs are undefined in this context. CQ is invalid because units for OBX-5-observation value 

are always specified explicitly in an OBX segment with OBX-6 units. SI is invalid because it only applies 

to HL7 message segments, and ID because it requires a constant field definition. We allow the FT data 

type in the OBX segment but its use is discouraged. Formatted text usually implies a meaningful 

structure e.g., a list of three independent diagnoses reported on different lines. But ideally, the structure 

in three independent diagnostic statements would be reported as three separate OBX segments. TX 

should not be used except to send large amounts of text. In the TX data type, the repeat delimiter can 

only be used to identify paragraph breaks. Use ST to send short, and possibly encodable, text strings. 

In our VXR and VAERS examples, each OBX occurrence of this field is valued appropriately to represent 

the data type of the expected value in OBX-5. 

OBX 7.3.2.3 Observation identifier (CE-80, Required) 00571 

Definition: This field contains a unique identifier for the observation, or the thing being reported. 

The format is that of the Coded Element (CE). Example: 

OBX|9|CE|30963-3^Vaccine purchased with^LN||PBF^Public funds^NIP008||||||F|<CR>... 

...in which 30963-3 is a LOINC code (with the name of this system coded in the third component as LN) 

for the subject of the observation, in this case “vaccine purchased with.” 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1)	 Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2)	 Text (ST). Name or description of the item in question. 

(3)	 Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

In our VXR #1 example, we have valued this field to show what observation will be reported in OBX-5. 

For example, following the RXA segment showing the administration of a DTaP vaccine, OBX-3 and 5 

show the VIS publication date and the date the VIS was presented to the patient. Following the RXA 

segment showing the administration of a DTaP-Hib combination vaccine, OBX-3 and 5 indicate the 

individual dose numbers of each vaccine component. Following the RXA segment showing the 

74 
 

 

 

 

 

 

 

administration of the second MMR, the OBX-3 and 5 show the report of an adverse event. For the results 

of the tuberculosis test, we use an OBX segment to show a measurement of the reaction. 

For reporting of adverse events, OBX-3 is valued with the LOINC® code that represents the subject of the 

information being given in OBX-5. Refer to NIP Table 003 – Observation identifiers for VAERS reporting 

for valid coded entries for VAERS reports. In both VAERS reports and vaccine due next reporting, we use 

the combining rule described in Section 7.1.2 of HL7’s Version 2.3.1 to combine a general code with a 

more specific one to arrange information in a hierarchy. An example is shown below at OBX 7.3.2.4. 

OBX 7.3.2.4 Observation sub-ID (ST-20, Conditional) 00572 

Definition: This field is used to distinguish between multiple OBX segments with the same 

observation ID. For example, a chest X-ray report might include three separate diagnostic impressions. 

The standard requires three OBX segments, one for each impression. By putting a 1 in the Sub-ID of the 

first of these OBX segments, 2 in the second, and 3 in the third, we can uniquely identify each OBX 

segment for editing or replacement. The sub-identifier can be further extended by adding decimals (e.g., 

2.1, 2.2). 

The use of the sub ID to distinguish repeating OBXs for the same observation ID uses the sub ID to group 

related subdivisions of information within the overall observation category. Its use must be carefully 

structured to avoid introducing ambiguities. 

In our VXR #2 example, we have valued this field as “1” in the first set of 5 OBX segments and as “2” in 

the second set. 

OBX|1|CE|30979-9^Vaccine due next^LN|1|20^DTAP^CVXI|||||F|<CR> 

OBX|2|TS|30979-9&30980-7^Date vaccine due^LN|1|19900807I|||||F|<CR> 

OBX|3|NM|30979-9&30973-2^Vaccine due next dose number^LN|1|01|||||FI<CR> 

OBX|4|TS|30979-9&30981-5^Earliest date to give^LN|1|19900803I|||||F|<CR> 

OBX|5|CE|30979-9&30982-3^Reason applied by forecast logic to project this vaccine^LN|1|^ACIP 

schedule||||||F|<CR> 

OBX|6|CE|30979-9^Vaccines due next, Vaccine type^LN|2|08^Hep B, pediatric^CVX|||||||F|<CR> 

OBX|7|TS|30979-9&30980-7^Date vaccine due^LN|2|19900722||||||F|<CR> 

OBX|8|NM|30979-9&30973-2^Vaccine due next dose number^LN|2|1||||||F|<CR> 

OBX|9|TS|30979-9&30981-5^Earliest date to give^LN|2|19900722||||||F|<CR> 

OBX|10|CE|30979-9&30982-3^Reason applied by forecast logic to project this vaccine^LN|2|^ACIP 

schedule||||||F|<CR> 

(continues on next page) 

75 
 

 

 

 

 

 

 

 

 

 

 

75.1 

Some information about combination vaccines (vaccines that contain multiple component antigens) can
 

be specific to an individual vaccine component. For example, there can be separate VIS statements for 

each vaccine component. In the example below the combination vaccine has two component vaccines. 

The RXA segment describes the entire combination vaccine and does not have a value in the
 

Observation sub-ID. Following the RXA, the first set of 5 OBX segments describes one vaccine
 

component so all have the value “1” in the Observation sub-ID. The next set of 5 OBX segments
 

describes another vaccine component so all have the value “2” in the Observation sub-ID.
 

RXA|0|1|19901207|19901207|51^HepB-HIB^CVX|.5|ML^^ISO+|||1234567891^O'BRIAN
 

^ROBERT^A^^DR^MD|^^^CHILD HEALTHCARE CLINIC^^^^^101 MAIN
 

STREET^^BOSTON^MA||||W22532806|19901230|MSD^MERCK^MVX||||<CR>
 

OBX|1|CE|38890-0^COMPONENT VACCINE TYPE^LN|1|45^HEP B, NOS^CVX||||||F|<CR>
 

OBX|2|TS|38890-0&29768-9^DATE VACCINE INFORMATION STATEMENT
 

PUBLISHED^LN|1|20010711||||||F|<CR>
 

OBX|3|TS|38890-0&29769-7^DATE VACCINE INFORMATION STATEMENT
 

PRESENTED^LN|1|19901207||||||F|<CR>
 

OBX|4|ST|38890-0&30973-2^Dose number in series^LN|1|3||||||F|<CR>
 

OBX|5|ST|38890-0&30959-1^LOT^LN|1|MY85542||||||F|<CR>
 

OBX|6|CE|38890-0^COMPONENT VACCINE TYPE^LN|2|17^HIB,NOS^CVX||||||F|<CR>
 

OBX|7|TS|38890-0&29768-9^DATE VACCINE INFORMATION STATEMENT
 

PUBLISHED^LN|2|19981216||||||F|<CR>
 

OBX|8|TS|38890-0&29769-7^DATE VACCINE INFORMATION STATEMENT
 

PRESENTED^LN|2|19901207||||||F|<CR>
 

OBX|9|ST|38890-0&30973-2^Dose number in series^LN|2|1||||||F|<CR>
 

OBX|10|ST|38890-0&30959-1^LOT^LN|2|WP95441||||||F|<CR>
 

The following is a simplified example that illustrates specifically how “Dose number in series” should be 

portrayed for a combination vaccine using the Observation sub-ID to group the OBX segments for each 

component vaccine type. Note the use of LOINC® codes 38890-0&30973-2 for every component vaccine 

dose number in series. This is preferred over the previous method for portraying “dose count in 

combination vaccine” which used a different LOINC® code for each component vaccine and which lacked 

a code for the dose count for the Polio vaccine component of a combination vaccine. 

RXA|0|1|19901207|19901207|110^DTAP/Polio/Hep B^CVX|.5|ML^^ISO+|||1234567891^O'BRIAN 

^ROBERT^A^^DR^MD|^^^CHILD HEALTHCARE CLINIC^^^^^101 MAIN 

STREET^^BOSTON^MA||||AC21A016AA|19901230|SKB^SKB^MVX||||<CR> 

OBX|1|CE|38890-0^COMPONENT VACCINE TYPE^LN|1|107^DTAP, NOS^CVX||||||F|<CR> 

OBX|2|ST|38890-0&30973-2^Dose number in series^LN|1|2||||||F|<CR> 

OBX|3|CE|38890-0^COMPONENT VACCINE TYPE^LN|2|89^Polio, NOS^CVX||||||F|<CR> 

OBX|4|ST|38890-0&30973-2^Dose number in series^LN|2|2||||||F|<CR> 

OBX|5|CE|38890-0^COMPONENT VACCINE TYPE^LN|3|45^HEP B, NOS^CVX||||||F|<CR> 

OBX|6|ST|38890-0&30973-2^Dose number in series^LN|3|3||||||F|<CR> 

(continues on next page) 
 

 

75.2 

 

 

 

 

 

OBX 7.3.2.5 Observation value (User-assigned, Conditional, Repeating) 00573 

Definition: This field contains the value observed. OBX-2-value type contains the data type for 

this field according to how the observation value is formatted. It is not a required field because some 

systems will report only normalcy/abnormalcy (OBX-8), especially in product experience reporting. This 

field contains the value of, or amount reported, or response to OBX-3-observation identifier of the same 

segment. Depending upon the observation, the data type may be a number (e.g., a respiratory rate), a 

coded answer (e.g., a pathology impression recorded as a SNOMED code), or a date/time (the 

date/time that a unit of blood is sent to the ward). An observation value is always represented as the data 

type specified in OBX-2-value type of the same segment. 

This example is from the list of OBX’s in section 7.3.2.4 above, where OBX-2 indicates that a numeric 

data type (NM) will be used in OBX-5 to provide the value of the subject named in OBX-3. In this 

example, the vaccine due next dose number is “1.” 

OBX|8|NM|30979-9&30973-2^Vaccine due next dose number^LN|2|1||||||F|<CR> 

In our VXR #1 example, we give several demonstrations of use of this field: 1) to show that the VIS 

publication date for DTaP was June 5, 1990; 2) that the VIS was presented to the patient on December 7, 

1990; and 3) that this is the fourth dose of DTaP and the fourth dose of Hib in the combination vaccine. 

For the second MMR, this field shows anaphylaxis as the adverse event. For the results of the 

tuberculosis test, we show a measurement of 1 mm. 

(continues on next page) 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

For VAERS reporting, the same rules apply--the OBX-5 provides the specific data in response to the topic 

specified in the OBX-3. The data must be formatted according to the data type named in OBX-2. 

OBX 7.3.2.6 Units (CE-60, Optional) 00574 

Definition: This field contains the units for the observation value in OBX-5. The default value is 

ISO+abbreviation, as defined. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1)	 Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2)	 Text (ST). Name or description of the item in question. 

(3)	 Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

In our VXR #1 example, we show the units to be millimeters. 

OBX 7.3.2.7 References range (ST-60, Optional) 00575 

Definition: When the observation quantifies the amount of a toxic substance, then the upper limit 

of the range identifies the toxic limit. If the observation quantifies a drug, the lower limits identify the lower 

therapeutic bounds and the upper limits represent the upper therapeutic bounds above which toxic side
 

effects are common.
 

If numeric, the values of this field may report several values in one of the following three formats:
 

a) lower limit-upper limit (when both lower and upper limits are defined, e.g., for potassium 3.5 - 4.5)
 

b) > lower limit (if no upper limit, e.g., >10) 

c) < upper limit (if no lower limit, e.g., <15) 

If alphabetical, the normal value may be reported in this location. 

In our examples, we have not valued this field. 

OBX 7.3.2.8 Abnormal flags (ID-5, Optional, Repeating) 00576 

Definition: This field contains a table lookup indicating the normalcy status of the result. Refer to 

HL7 Table 0078 - Abnormal flags for valid entries. 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

In our VXR #1 example, we show the reaction to the tuberculosis test to be normal. 

OBX 7.3.2.9 Probability (NM-5, Optional) 00577 

Definition: This field contains the probability of a result being true for results with categorical 

values. It mainly applies to discrete coded results. It is a decimal number represented as an ASCII string
 

that must be between 0 and 1, inclusive. 

In our examples, we have not valued this field.
 

OBX 7.3.2.10 Nature of abnormal test (ID-2, Optional, Repeating) 00578
 

Definition: This field contains the nature of the abnormal test. 

76 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

In our examples, we have not valued this field. 

OBX 7.3.2.11 Observation result status (ID-1, Required) 00579 

Definition: This field contains the observation result status. Refer to HL7 Table 0085 -

Observation result status codes interpretation for valid values. This field reflects the current completion 

status of the results for data contained in the OBX-5-observation value field. It is a required field. 

Previous versions of HL7 stated this implicitly by defining a default value of “F.”

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

In our VXR #1 example, we have valued all OBX-11 fields as F for final. 

OBX 7.3.2.14 Date-time of the observation (TS-26, Optional) 00582 

Definition: Records the time of the observation. It is the physiologically relevant date-time or the 

closest approximation to that date-time of the observation. 

Time stamp (TS) data type must be in the format:
 

YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]^<degree of precision>
 

Note: The optional degree of precision component is retained for backward compatibility only. Immunization registries will not value 

this component. 

In our VXR #1 example of results of the tuberculosis test, we show the date of observation as April 18, 

1990. 

OBX 7.3.2.15 Producer’s ID (CE-60, Optional) 00583 

Definition: Contains a unique identifier of the responsible producing service. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1)	 Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2)	 Text (ST). Name or description of the item in question. 

(3)	 Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

In our examples, we have not valued this field. 

OBX 7.3.2.16 Responsible observer (XCN-80, Optional, Repeating) 00584 

Definition: This field contains the identifier of the individual directly responsible for the observation 

(the person who either performed or verified it). 

Components of the XCN data type: <ID number (ST)>^<family name (ST)>&<last name prefix (ST)>^<given name 

(ST)>^<middle initial or name (ST)>^<suffix (e.g., Jr. or III) (ST)>^<prefix (e.g., Dr.) (ST)>^<degree (e.g., MD) 

(IS)>^<source table (IS)>^<assigning authority (HD)>^<name type code (ID)>^<identifier check digit (ST)>^<code 

identifying the check digit scheme employed (ID)>^<identifier type code (IS)>^<assigning facility ID (HD)>^<name 

representation code (ID)> 

Subcomponents of assigning authority: <namespace ID (IS)>&<universal ID (ST)> & <universal ID type (ID)> 

Subcomponents of assigning facility: <namespace ID (IS)>&<universal ID (ST)> & <universal ID type (ID)> 

In our examples, we have not valued this field. 

77 
 

 

 

 

 

 

 

 

 

 

 

 

 

OBX 7.3.2.17 Observation method (CE-60, Optional, Repeating) 00936 

Definition: Used to transmit the method or procedure by which an observation was obtained. 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined as follows: 

(1)	 Identifier (ST). The code that uniquely identifies the item being referenced by the <text>. Different coding schemes 

will have different elements here. 

(2)	 Text (ST). Name or description of the item in question. 

(3)	 Name of coding system (ST). Identifies the coding system used. The combination of the identifier and the name of 

the coding system components will be a unique code for a data item. 

(4-6) Three components analogous to 1-3 for the alternate or local coding system. 

In our examples, we have not valued this field. 

78 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2.24.15 Notes and Comments (NTE) Segment 

The NTE segment is defined as a common format for sending notes and comments. 

NTE Attributes 

SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME 

1 4 SI O 00096 Set ID-NTE 

2 8 ID O 0105 00097 Source of comment 

3 64k FT O Y 00098 Comment 

4 60 CE O 01318 Comment type 

Example:
 

NTE|||PATIENT DEVELOPED HIGH FEVER APPROX 3 HRS AFTER VACCINE INJECTION|<CR>
 

In this NTE segment, we show a comment about the patient’s reaction to the vaccination. 

2.24.15.0 NTE field definitions 

NTE 2.24.15.1	 Set ID - NTE (SI-4, Optional) 00096 

Definition: This field may be used when multiple NTE segments are included in a message. 

SI data type is a non-negative integer in the form of an NM field. The uses of this data type are defined in the chapters 

defining the segments and messages in which it is used. 

In our examples, we have not valued this field. 

NTE 2.24.15.2 Source of comment (ID-8, Optional) 00097 

Definition: This field is used to identify source of comment. HL7 Table 0105 - Source of Comment 

is used, but may be extended locally during implementation. 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

In our examples, we have not valued this field. 

NTE 2.24.15.3 Comment (FT-64k, Optional, Repeating) 00098 

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

Note: The FT data type without embedded formatting commands is compatible with the previous TX data type. 

In our VXR example, this comment field shows that the VAERS form was submitted by the provider. 

NTE 2.24.15.4 Comment type (CE-60, Optional) 01318 

Definition: This field identifies the type of comment text. Allowable values are user-defined, but 

may include the following: PI - Patient Instruction, HS - Historical Record Comment. A separate NTE 

segment can be used for each type of comment (e.g., instructions on one NTE and remarks on another 

NTE). 

The CE data type transmits codes and the text associated with the code. This type has six components arranged in two 

groups as follows: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate coding system (ST)> 

CE data type components are defined in Appendix 2, 2.8.3. 

In our examples, we have not valued this field. 

79 
 

 

 

 

 

 

 

 

3.2 PATIENT ADMINISTRATION MESSAGE DEFINITIONS 

Use of the Optional Admission/Discharge, Transfer (ADT) Segments 

The HL7 standard defines many specialized ADT messages for administrative events dealing with 

patients; e.g., admit, discharge, transfer, merge record. The VXU message can be used for adding a 

person or additional information about the person, so ADT messages are not necessary for registries to 

communicate with each other. However, intercommunicating private providers and immunization 

registries may decide to use the ADT message when there is no immunization information, especially 

when the communicating partner already has implemented the ADT but not the VXU. The challenge for 

registries becomes to identify which ADT messages to use. There are 51 different ADT messages 

distinguished from each other by 51 different trigger event codes. 

At this writing, the set of ADT messages most likely to be needed by registries is not yet fully bounded. 

Registries are accepting the messages sent by their communicating partners. Registries may receive 

extra messages that they are not interested in, in which case it will need to handle them appropriately. 

2.3.1 ADT messages currently identified and accepted by registries include (by event code): 

A01 (admit/visit notification)
 

A04 (register a patient)
 

A05 (pre-admit a patient)
 

A08 (update patient information)
 

A18 (merge patient information)
 

A28 (add person information)
 

A31 (update person information)
 

A47 (change patient identifier list)
 

As registry experience with ADT grows, this section of this document will be further refined.
 

80 
ADT^A29 ADT Message HL7 Chapter
 

MSH Message Header 2
 

EVN Event Type 3
 

PID Patient Identification 3
 

[PD1] Additional Demographics 3
 

 PV1 Patient Visit 3
 

[ PV2 ] Patient Visit - Additional Info. 3
 

[ { DB1 } ] Disability Information 3
 

[ { OBX } ] Observation/Result 7
 

 

ADT^A28 ADT Message HL7 Chapter
 

MSH Message Header 2
 

EVN Event Type 3
 

PID Patient Identification 3
 

[ PD1] Additional Demographics 3
 

[ { NK1 } ] Next of Kin /Associated Parties 3
 

PV1 Patient Visit 3
 

[ PV2 ] Patient Visit - Additional Info. 3
 

[ { DB1 } ] Disability Information 3
 

[ { OBX } ] Observation/Result 7
 

[ { AL1 } ] Allergy Information 3
 

[ { DG1 } ] Diagnosis Information 6
 

[ DRG ] Diagnosis Related Group 6
 

[ { PR1 Procedures 6

 [{ROL}] Role 12
 

} ] 

[ { GT1 } ] Guarantor 6
 

[ 

 { IN1 Insurance 6
 

 [ IN2 ] Insurance Additional Info. 6
 

 [ {IN3} ] Insurance Add’l Info - Cert. 6
 

} 

]
 

[ ACC ] Accident Information 6
 

[ UB1 ] Universal Bill Information 6
 

[ UB2 ] Universal Bill 92 Information 6
 

ACK General Acknowledgment HL7 Chapter
 

MSH Message Header 2
 

MSA Message Acknowledgment 2
 

[ERR ] Error 2
 

 

 

 

 

 

 

 

 

 

3.2.28 Admission/Discharge/Transfer and Acknowledgment (ADT/ACK) - add person information 

(event A28) 

Definition: The A28 event can be used to send everything that is known about a person. An A28 

(add person information) or A31 (update person information) can also be used for back loading MPI 

information for the person, or for back loading all person and historical information from one system to 

another. 

3.2.29 Admission/Discharge/Transfer and Acknowledgment (ADT/ACK) -delete person 

information (event A29) 

Definition: An A29 event can be used to delete all demographic information related to a given 

person. This event “undoes” an A28 (add person information) event. The information from the A28 event 

is deleted. This event is used, for example, when information was added in error, or when another record 

already exists for the person, or when one wants to purge the person from the database. When this 

event occurs, all visit and account level data for this person is also purged. 

81 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3.2.30 Admission/Discharge/Transfer and Acknowledgment (ADT/ACK) -merge person 

information (event A30) 

Definition: An A30 event can be used to merge person information in an MPI. An A30 (merge 

person information) is intended for merging person records without merging patient identifiers. 

ADT^A30 ADT Message HL7 Chapter 

MSH Message Header 2 

EVN Event Type 3 

PID Patient Identification 3 

[PD1] Additional Demographics 3 

MRG Merge Information 3 

3.2.31 Admission/Discharge/Transfer and Acknowledgment (ADT/ACK) -update person 

information (event A31) 

Definition: An A31 event can be used to update person information in an MPI. An A31 (update 

person information) or A28 (add person information) can also be used for back loading MPI information 

for the person, or for back loading all person and historical information from one system to another. 

The syntax for this message is identical to the ADT^A28 and is not repeated here. 

3.3.1 Event Type (EVN) Segment 

Used to communicate necessary trigger event information to receiving applications. 

EVN Attributes 

SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME 

1 3 ID B 0003 00099 Event type code 

2 26 TS R 00100 Recorded date/time 

3 26 TS O 00101 Date/time planned event 

4 3 IS O 0062 00102 Event reason code 

5 60 XCN O Y 0188 00103 Operator ID 

6 26 TS O 01278 Event occurred 

3.3.1.0 EVN field definitions 

Usage notes: We did not use the EVN segment in our examples, but do provide field definitions 

here for reference. 

EVN 3.3.1.1 Event type code (ID-3, Backwards Compatibility) 0 0099 

Definition: This field has been retained for backward compatibility only. Immunization registries 

will use the second component (trigger event) of MSH-9 to transmit event type code. 

The value of an ID data type follows the formatting rules for an ST data type except that it is drawn from a table of HL7 legal values. 

EVN 3.3.1.2 Recorded date/time (TS-26, Required) 00100 

Definition: Most systems will default to the system date/time when the transaction is entered, but 

they may permit an override. 

Time stamp (TS) data type must be in the format: 

YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]^<degree of precision> 

Note: The optional degree of precision component is retained for backward compatibility only. Immunization registries will not value 

this component. 

EVN 3.3.1.3 Date/time planned event (TS-26, Optional) 00101 

82 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Definition: The date/time the event is planned. 

Time stamp (TS) data type must be in the format:
 

YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]^<degree of precision>
 

Note: The optional degree of precision component is retained for backward compatibility only. Immunization registries will not value 

this component. 

EVN 3.3.1.4 Event reason code (IS-3, Optional) 00102 

Definition: The reason for this event . Refer to User-defined Table 0062 - Event reason for 

suggested values. 

The IS data type follows the formatting rules for an ST field except that it is drawn from a site-defined (or user-defined) 

table of legal values. 

EVN 3.3.1.5 Operator ID (XCN-60, Optional, Repeating) 00103 

Definition: The individual responsible for triggering the event. Refer to User-defined Table 0188 –

Operator ID for suggested values. Each immunization registry will maintain its own reference table for 

these values. 

Components of the XCN data type: <ID number (ST)>^<family name (ST)>&<last name prefix (ST)>^<given name 

(ST)>^<middle initial or name (ST)>^<suffix (e.g., Jr. or III) (ST)>^<prefix (e.g., Dr.) (ST)>^<degree (e.g., MD) 

(IS)>^<source table (IS)>^<assigning authority (HD)>^<name type code (ID)>^<identifier check digit (ST)>^<code 

identifying the check digit scheme employed (ID)>^<identifier type code (IS)>^<assigning facility ID (HD)>^<name 

representation code (ID)> 

Subcomponents of assigning authority: <namespace ID (IS)>&<universal ID (ST)> & <universal ID type (ID)> 

Subcomponents of assigning facility: <namespace ID (IS)>&<universal ID (ST)> & <universal ID type (ID)> 

EVN 3.3.1.6 Event occurred (TS-26, Optional) 01278 

Definition: The date/time that the event actually occurred. 

Time stamp (TS) data type must be in the format:
 

YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]^<degree of precision>
 

Note: The optional degree of precision component is retained for backward compatibility only. Immunization registries will not value 

this component. 

83 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3.3.8 Merge Patient Information (MRG) Segment 

The MRG segment provides receiving applications with information necessary to initiate the 

merging of patient data as well as groups of records. 

MRG Attributes 

SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME 

1 20 CX R Y 00211 Prior patient identifier list 

2 20 CX O Y 00212 Prior alternate patient ID 

3 20 CX O 00213 Prior patient account number 

4 20 CX O 00214 Prior patient ID 

5 20 CX O 01279 Prior visit number 

6 20 CX O 01280 Prior alternate visit ID 

7 48 XPN O Y 01281 Prior patient name 

3.3.8.0 MRG field definitions 

Usage notes: The assigning authority, the fourth component of the patient identifiers, is an HD 

data type that is uniquely associated with the assigning authority that originally assigned the number. A 

group of intercommunicating institutions, such as immunization registries, may establish a list of assigning 

authorities to serve as a master dictionary list. The assigning authority must be unique across 

applications at a given site. This field is required in HL7 implementations that have more than a single 

Patient Administration application assigning such numbers. 

We did not use the MRG segment in our examples, but do provide field definitions here for reference. 

MRG 3.3.8.1 Prior patient identifier list (CX-20, Required, Repeating) 00211 

Definition: This field contains the internal prior patient identifier. This field contains a list of 

potential “old” numbers to match. Only one old number can be merged with one new number in a 

transaction. 

CX data type components: <ID (ST)>^<check digit (ST)>^<code identifying the check digit scheme employed
 

(ID)>^<assigning authority (HD)>^<identifier type code (IS)>^<assigning facility (HD)>
 

Components are defined as follows: 

(1)	 ID number (ST) 

(2)	 Check digit (ST) (The check digit used 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 null.) 

(3)	 Code identifying check digit scheme employed (ID) Refer to HL7 Table 0061 - Check digit scheme for valid values. (4)	 Assigning authority (HD) 

Subcomponents of (4):	 <application identifier 1 (ID)> & <application identifier 2 (ID)> & <application 

identifier 3 (ID)> & <application identifier 4 (ID)> & <application identifier 5 (ID)> & <application 

identifier 6 (ID)> 

(5)	 Identifier type code (IS) 

A code corresponding to the type of identifier. This code may be used as a qualifier to the “Assigning authority” 

component. Refer to User-defined Table 0203 - Identifier type for suggested values. 

(6)	 Assigning facility (HD) 

Definition: The place or location identifier where the identifier was first assigned to the patient-part of the history of 

the identifier. 

Subcomponents of (6): <namespace ID (IS)>&<universal ID (ST)>&<universal ID type (ID)> 

MRG 3.3.8.2 Prior alternate patient ID (CX-20, Optional, Repeating) 00212 

Definition: This field contains the prior alternate patient identifier. 

MRG 3.3.8.3 Prior patient account number (CX-20, Optional) 00213 

Definition: This field contains the prior patient account number. 

MRG 3.3.8.4 Prior patient ID (CX-20, Optional) 00214 

84 
 

 

 

 

 

 

 

 

 

 

 

Definition: This field contains the prior patient identifier. 

MRG 3.3.8.5 Prior visit number (CX-20, Optional) 01279 

Definition: This field contains the internal prior visit number. 

MRG 3.3.8.6 Prior alternate visit number (CX-20, Optional) 01280 

Definition: This field contains the prior alternate visit number. 

MRG 3.3.8.7 Prior patient name (XPN-48, Optional, Repeating) 01281 

Definition: This field contains the prior name of the patient. This field is not used to change a 

patient name. 

XPN data type components: <family name (ST)>&<last name prefix (ST)>^<given name (ST)>^<middle initial or name 

(ST)>^<suffix (e.g., JR or III) (ST)>^<prefix (e.g., DR) (ST)>^<degree (e.g., MD) (IS)>^<name type code 

(ID)>^<name representation code (ID)> 

For valid values, refer to User-defined Table 0360 - Degree for the degree component, to HL7 Table 0200 - Name type for 

the name type code, and to HL7 Table 4000 - Name/address representation for the name representation code. 

85 
 

[This page was intentionally left blank.] 
 

 

 

 

 

 

 

 

APPENDIX 1: Code Tables 

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

that are assigned by NIP are italicized. 

User-defined Table 0001 - Sex [values suggested by HL7] (use in PID-8, NK1-15) 

Value Description 

F Female 

M Male 

O Other 

U Unknown 

HL7-defined Table 0003 - Event type [only selected values listed] (use in MSH-9, second component) 

Value Description 

A28 ADT/ACK - Add person information 

A29 ADT/ACK - Delete person information 

A30 ADT/ACK - Merge person information 

A31 ADT/ACK - Update person information 

V01 VXQ - Query for vaccination record 

V02 VXX - Response to vaccination query returning multiple PID matches 

V03 VXR - Vaccination record response 

V04 VXU - Unsolicited vaccination record update 

R01 ORU – Observation results (Unsolicited) 

User-defined Table 0004 - Patient class [values suggested by HL7] (use in PV1-2) 

Value Description 

E Emergency 

I Inpatient 

O Outpatient 

P Preadmit 

R Recurring Patient 

B Obstetrics 

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) 

US race codes 

(included in HL7 Version 2.4) 

(entire hierarchical set of codes at 

http://www.cdc.gov/od/hissb/docs/Race 

-EthnicityCodeSet.pdf) 

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 

2135-2 Hispanic or Latino H Hispanic 

2186-5 not Hispanic or Latino N 

2131-1 Other Race O Other 

Unknown U Unknown 

A1 - 1 
 

 

 

 

 

 

 

 

 

 

 

HL7-defined Table 0008 - Acknowledgment code (use in MSA-1) 

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 0048 - What subject filter [only selected values listed] (use in QRD-9) 

Value Description 

VXI Vaccine Information 

HL7-defined Table 0061 - Check digit scheme (use in all CX data types; including PID-2,3,4,18,21) 

Value Description 

M10 Mod 10 algorithm 

M11 Mod 11 algorithm 

ISO ISO 7064: 1983 

NPI Check digit algorithm in the US National Provider Identifier 

User-defined Table 0062 - Event reason [values suggested by HL7; with NIP-suggested additions] (use 

in EVN-4) 

Value Description 

01 Patient request 

02 Physician order 

03 Census management 

04 Add person data to immunization registry 

05 Delete person data from immunization registry 

06 Update person data in immunization registry 

07 Merge person data in immunization registry 

User-defined Table 0063 - Relationship [as defined in HL7’s Version 2.4] (use in NK1-3, IN1-17, IN2-

62) 

Value Description 

ASC Associate 

BRO Brother 

CGV Care giver 

CHD Child 

DEP Handicapped dependent 

DOM Life partner 

EMC Emergency contact 

EME Employee 

EMR Employer 

EXF Extended family 

FCH Foster child 

FND Friend 

FTH Father 

A1 - 2 
 

Value Description 

GCH Grandchild 

GRD Guardian 

GRP Grandparent 

MGR Manager 

MTH Mother 

NCH Natural child 

NON None 

OAD Other adult 

OTH Other 

OWN Owner 

PAR Parent 

SCH Stepchild 

SEL Self 

SIB Sibling 

SIS Sister 

SPO Spouse 

TRA Trainer 

UNK Unknown 

WRD Ward of court 

Codes for VAERS reporting only 

VAB Vaccine administered by (Name) 

FVP Form completed by (Name)--Vaccine provider 

FPP Form completed by (Name)--Patient/Parent 

FMN Form completed by (Name)—Manufacturer 

FOT Form completed by (Name)—Other 

User-defined Table 0064 - Financial class [NIP suggested values] (use in PV1-20) 

Value Description 

VFC eligibility codes 

V00 VFC eligibility not determined/unknown 

V01 Not VFC eligible 

V02 VFC eligible - Medicaid/Medicaid Managed Care 

V03 VFC eligible – Uninsured 

V04 VFC eligible – American Indian/Alaskan Native 

V05 VFC eligible – Federally Qualified Health Center Patient (under-insured) 

V06 VFC eligible - State-specific eligibility (e.g., S-CHIP plan) 

V07 VFC eligible - Local-specific eligibility 

S-CHIP eligibility codes 

CH00 S-CHIP coverage-not VFC eligible 

CH01 S-CHIP coverage-separate from Medicaid-not VFC eligible 

CH02 S-CHIP coverage-combination of Medicaid and separate-not VFC eligible 

A1 - 3 
 

 

 

 

 

 

Health plan type codes 

H01 Self pay 

H02 Medicaid (may be called by state-specific name, e.g., Medi-Cal) 

H03 Third party or private insurance 

Insured status 

IS00 Some or all vaccine costs covered 

IS01 Underinsured (no vaccine costs covered and not FQC/RHC) 

State program codes - state specific; use state 2-letter abbreviation plus a number for the value; see 

example below 

e.g., NY01 e.g., IHAP eligible 

HL7-defined Table 0076 - Message type [only selected values listed] (use in MSH-9, first component) 

Value Description 

ACK General acknowledgment 

ADR ADT response 

ADT ADT message 

QCK Query general acknowledgment 

VXQ Query for vaccination record 

VXX Vaccination query response with multiple PID matches 

VXR Vaccination query record response 

VXU Unsolicited vaccination record update 

ORU Unsolicited observation results 

HL7-defined Table 0078 - Abnormal flags [only selected values listed] (use in OBX-8) 

Value Description 

L Below low normal 

H Above high normal 

LL Below lower panic limits 

HH Above upper panic limits 

N Normal (applies to non-numeric results) 

A Abnormal (applies to non-numeric results) 

AA Very abnormal (applies to non-numeric units, analogous to panic limits for numeric units) 

HL7-defined Table 0085 - Observation result status codes interpretation (use in OBX-11) 

Value Description 

C Record coming over is a correction and thus replaces a final result 

D Deletes the OBX record 

F Final results; Can only be changed with a corrected result 

I Specimen in lab; results pending 

N Not asked; used to affirmatively document that the observation identified in the OBX was 

not sought when the universal service ID in OBR-4 implies that it would be sought 

O Order detail description only (no result) 

P Preliminary results 

R Results entered - not verified 

S Partial results 

X Results cannot be obtained for this observation 

U Results status change to Final without retransmitting results already sent as 

‘preliminary.’ e.g., radiology changes status from preliminary to final

W Post original as wrong; e.g., transmitted for wrong patient 

A1 - 4 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

HL7-defined Table 0091 - Query priority (use in QRD-3) 

Value Description 

D Deferred 

I Immediate 

HL7-defined Table 0102 - Delayed acknowledgment type (use in MSA-5) 

Value Description 

D Message received, stored for later processing 

F Acknowledgment after processing 

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.0 Release 2.0 September 1988 

2.0D Demo 2.0 October 1988 

2.1 Release 2.1 March 1990 

2.2 Release 2.2 December 1994 

2.3 Release 2.3 March 1997 

2.3.1 Release 2.3.1 May 1999 

2.4 Release 2.4 October 2000 

HL7-defined Table 0105 - Source of comment (use in NTE-2) 

Value Description 

L Ancillary (filler) department is source of comment 

P Orderer (placer) is source of comment 

O Other system is source of comment 

HL7-defined Table 0106 - Query/Response format code (use in QRD-2) 

Value Description 

D Response is in display format 

R Response is in record-oriented format 

T Response is in tabular format 

HL7-defined Table 0107 - Deferred response type (use in QRD-5) 

Value Description 

B Before the date/time specified 

L Later than the date/time specified 

A1 - 5 
 

 

 

 

 

 

 

HL7-defined Table 0108 - Query results level (use in QRD-12) 

Value Description 

O Order plus order status 

R Results without bulk text 

S Status only 

T Full results 

HL7-defined Table 0119 – Order Control Codes (use in ORC-1) 

Value Description 

OK Order accepted & OK 

RE Observations to follow 

HL7-defined Table 0126 - Quantity limited request (use in QRD-7) 

Value Description 

CH Characters 

LI Lines 

PG Pages 

RD Records 

ZO Locally defined 

HL7-defined Table 0136 - Yes/No indicator (use in PID-24,30; PD1-12) 

Value Description 

Y Yes 

N No 

“”<null> Not obtained (when used by immunization registries as defined in PD1-12) 

U Unknown 

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) 

Value Description 

ID Intradermal 

IM Intramuscular 

IN Intranasal 

IV Intravenous 

PO Oral 

OTH Other/Miscellaneous 

SC Subcutaneous 

TD Transdermal 

A1 - 6 
 

 

 

 

 

HL7-defined Table 0163 - Administrative site [only selected values listed] (use in RXR-2) 

Value Description 

LT Left Thigh 

LA Left Arm 

LD Left Deltoid 

LG Left Gluteous Medius 

LVL Left Vastus Lateralis 

LLFA Left Lower Forearm 

RA Right Arm 

RT Right Thigh 

RVL Right Vastus Lateralis 

RG Right Gluteous Medius 

RD Right Deltoid 

RLFA Right Lower Forearm 

User-defined Table 0188 - Operator ID (use in EVN-5) [locally-defined] 

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 

NIP’s original

temporary values 

(obsolete) 

Description 

2135-2 H H Hispanic or Latino 

2186-5 N NH 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 

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 

A1 - 7 
 

 

 

 

 

HL7-defined Table 0200 - Name type (use in all XCN, XPN data types; including PID-5, 6, 9) 

Value Description 

A Alias name 

L Legal name 

D Display name 

M Maiden name 

C Adopted name 

B Name at birth 

P Name of partner/spouse 

U Unspecified 

HL7-defined Table 0201 - Telecommunication use code (use in all XTN data types; including PID13,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 

A1 - 8 
 

 

 

 

 

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) 

Value Description 

AM American Express 

AN Account Number 

ANON Anonymous Identifier 

BR Birth Registry Number 

DI Diner’s Club Card

DL Driver’s License Number

DN Doctor Number 

DS Discover Card 

EI Employee Number 

EN Employer Number 

FI Facility Identifier 

GI Guarantor Internal Identifier 

GN Guarantor External Identifier 

LN License Number 

LR Local Registry ID 

MS MasterCard 

MA Medicaid Number 

MC Medicare Number 

MR Medical Record Number 

NE National Employer Identifier 

NH National Health Plan Identifier 

NI National Unique Individual Identifier 

NPI National Provider Identifier 

PI Patient Internal Identifier 

PN Person Number 

PRN Provider Number 

PT Patient External Identifier 

RRI Regional Registry ID 

RR Railroad Retirement Number 

SL State License 

SR State Registry ID 

SS Social Security Number 

U Unspecified 

UPIN Medicare/CMS's Universal Physician ID Numbers 

VS VISA 

VN Visit Number 

WC WIC Identifier 

XX Organization Identifier 

VEI Vaccinator Employee Number 

OEI Orderer Employee Number 

REI Recorder Employee Number 

A1 - 9 
 

 

 

 

 

 

 

User-defined Table 0204 - Organizational name type [values suggested by HL7] (use in all XON data 

types) 

Value Description 

A Alias name 

L Legal name 

D Display name 

SL Stock exchange listing name 

HL7-defined Table 0207 - Processing mode (use in MSH-11) 

Value Description 

A Archive 

R Restore from archive 

I Initial load 

T Current processing, transmitted at intervals (scheduled or on demand) 

<blank> Not present (the default, meaning current processing) 

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 

HL7-defined Table 0211 - Alternate character sets [only selected values listed] (use in MSH-18) 

Value Description 

ASCII The printable 7-bit ASCII character set (This is the default if this field is omitted) 

User-defined Table 0212 - Nationality [ISO 3166 is suggested by HL7; this table shows selected values 

only. Note that the table reflects only 3-letter codes. Two-letter and numeric codes are also available.] 

Full ISO 3166 country codes set is available at: ftp://ftp.ripe.net/iso3166-countrycodes.txt. Note: CDC 

has permission to disseminate certain ISO 3166 codes as a Federal agency that does not require 

applications to interchange data internationally and that are not involved in national defense programs or 

with the mission of the U.S. Department of State. (use in PID-28; also use for country code in all XAD 

data types) 

Value Description 

CAN Canada 

MEX Mexico 

USA United States 

UMI United States Minor Outlying Islands 

A1 - 10 
 

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 [values suggested by HL7; with NIP-suggested 

additions] (use in NK1-21) 

Value Description 

A Alone 

F Family 

I Institution 

R Relative 

U Unknown 

S Spouse only 

W With patient 

N Not with patient 

User-defined Table 0222 - Contact reason [values suggested by NIP] (use in NK1-29) 

Value Description 

RR NK1 is reminder/recall contact for immunization registry 

PC NK1 is responsible for patient care 

A1 - 11 
 

 

 

 

 

 

 

 

 

 

HL7-defined Table 0227 - Manufacturers of vaccines (code = MVX) (use in RXA-17) The table below 

represents the July 2006 version of the MVX code set. The CDC’s National Center for Immunization and 

Respiratory Diseases (NCIRD) maintains the HL7 external code set MVX. The implementation of the HL7 

standard for immunization data exchange is described in Chapter 4 of the HL7 standard. The codes in 

HL7 Version 2.3 table 0227 represent the initial content of the external MVX code set. This document 

represents the most up-to-date version of the MVX code set. See Website for further updates. 

http://www.cdc.gov/nip/registry/st_terr/tech/stds/hl7-cvx.htm 

(alphabetized by manufacturer name) 

Code Vaccine Manufacturer/Distributor 

AB Abbott Laboratories (includes Ross Products Division) 

AD Adams Laboratories, Inc. 

ALP Alpha Therapeutic Corporation 

AR Armour [Inactive – use AVB] 

AVB Aventis Behring L.L.C. (formerly Centeon L.L.C.; includes Armour Pharmaceutical Company) 

[Inactive – use ZLB] 

AVI Aviron 

BA Baxter Healthcare Corporation [Inactive – use BAH] 

BAH Baxter Healthcare Corporation (includes Hyland Immuno, Immuno International AG, and North 

American Vaccine, Inc.) 

BAY Bayer Corporation (includes Miles, Inc., and Cutter Laboratories) 

BP Berna Products [Inactive – use BPC] 

BPC Berna Products Corporation (includes Swiss Serum and Vaccine Institute Berne) 

MIP Bioport Corporation (formerly Michigan Biologic Products Institute) 

CNJ Cangene Corporation 

CMP Celltech Medeva Pharmaceuticals [Inactive – use NOV] 

CEN Centeon L.L.C. [Inactive – use AVB] 

CHI Chiron Corporation [Inactive – use NOV] Includes PowderJect Pharmaceuticals, Celltech 

Medeva Vaccines and Evans Medical Limited 

CON Connaught [Inactive – use PMC] 

DVC DynPort Vaccine Company, LLC 

EVN Evans Medical Limited [Inactive – use NOV] 

GEO GeoVax Labs, Inc. 

SKB GlaxoSmithKline (formerly SmithKline Beecham; includes SmithKline Beecham and Glaxo 

Wellcome) 

GRE Greer Laboratories, Inc. 

IAG Immuno International AG [Inactive – use BAH] 

IUS Immuno-U.S., Inc. 

KGC Korea Green Cross Corporation 

LED Lederle [Inactive – use WAL] 

MBL Massachusetts Biologic Laboratories (formerly Massachusetts Public Health Biologic 

Laboratories) 

MA Massachusetts Public Health Biologic Laboratories [Inactive – use MBL] 

MED MedImmune, Inc. 

MSD Merck & Co., Inc. 

IM Merieux [Inactive – use PMC] 

MIL Miles [Inactive – use BAY] 

NAB NABI (formerly North American Biologicals, Inc.) 

NYB New York Blood Center 

NAV North American Vaccine, Inc. [Inactive – use BAH] 

NOV Novartis Pharmaceutical Corporation (includes Chiron, PowderJect Pharmaceuticals, Celltech 

Medeva Vaccines and Evans Limited, Ciba-Geigy Limited and Sandoz Limited) 

NVX Novavax, Inc. 

OTC Organon Teknika Coporation 

ORT Ortho-clinical Diagnostics (formerly Ortho Diagnostic Systems, Inc.) 

PD Parkedale Pharmaceuticals (formerly Parke-Davis) 

PWJ PowderJect Pharmaceuticals (includes Celltech Medeva Vaccines and Evans Medical Limited) 

A1 - 12 
 

 

 

 

 

 

 

[Inactive – use NOV] 

PRX Praxis Biologics [Inactive – use WAL] 

JPN The Research Foundation for Microbial Diseases of Osaka University (BIKEN) 

PMC sanofi pasteur (formerly Aventis Pasteur, Pasteur Merieux Connaught; includes Connaught 

Laboratories and Pasteur Merieux) 

SCL Sclavo, Inc. 

SOL Solvay Pharmaceuticals 

SI Swiss Serum and Vaccine Inst. [Inactive – use BPC] 

TAL Talecris Biotherapeutics (includes Bayer Biologicals) 

USA United States Army Medical Research and Material Command 

VXG VaxGen 

WA Wyeth-Ayerst [Inactive – use WAL] 

WAL Wyeth-Ayerst (includes Wyeth-Lederle Vaccines and Pediatrics, Wyeth Laboratories, Lederle 

Laboratories, and Praxis Biologics) 

ZLB ZLB Behring (includes Aventis Behring and Armour Pharmaceutical Company) 

OTH Other manufacturer 

UNK Unknown manufacturer 

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. Where mergers/acquisitions have left the 

original company(ies) substantially intact, the original code remains so that Immunization Information Systems (IIS) 

and other users may not need to modify historical immunization records or internal tables for manufacturer names. 

User-defined Table 0288 - Census tract (use in all XAD; including PID-11)
 

For information about identifying census tracts, see <www.census.gov/geo/www/tractez.html>.
 

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

A1 - 13 
 

 

 

 

 

 

 

 

HL7-defined Table 0292 - Codes for Vaccines administered (code=CVX) (use in RXA-5) 

NOTE: parenteral unless otherwise specified. The table below represents the June 2006 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://www.cdc.gov/nip/registry/st_terr/tech/stds/hl7-cvx.htm 

The CDC’s National Center for Immunization and Respiratory Diseases (NCIRD) maintains the HL7 

external code set CVX. The implementation of the HL7 standard for immunization data exchange is 

described in Chapter 4of the HL7 standard. The codes in HL7 Version 2.3 table 0292, represented the 

initial content of the external CVX code set. Since vaccines have to be added to this table more quickly 

than new versions of HL7 are released, this document represents the most up-to-date version of the CVX 

code set. Items have been added. Others have been added for planning purposes, pending FDA 

approval. 

CVX – Vaccines Administered 

Code Short Description Full Vaccine Name 

54 adenovirus, type 4 adenovirus vaccine, type 4, live, oral 

55 adenovirus, type 7 adenovirus vaccine, type 7, live, oral 

82 adenovirus, NOS1 adenovirus vaccine, NOS 

24 anthrax anthrax vaccine 

19 BCG Bacillus Calmette-Guerin vaccine 

27 botulinum antitoxin botulinum antitoxin 

26 cholera cholera vaccine 

29 CMVIG cytomegalovirus immune globulin, intravenous 

56 dengue fever dengue fever vaccine 

12 diphtheria antitoxin diphtheria antitoxin 

28 DT (pediatric) diphtheria and tetanus toxoids, adsorbed for 

pediatric use 

20 DTaP diphtheria, tetanus toxoids and acellular 

pertussis vaccine 

106 DTaP, 5 pertussis antigens6 diphtheria, tetanus toxoids and acellular 

pertussis vaccine, 5 pertussis antigens 

107 DTaP, NOS diphtheria, tetanus toxoids and acellular 

pertussis vaccine, NOS 

110 DTaP-Hep B-IPV DTaP-hepatitis B and poliovirus vaccine 

50 DTaP-Hib DTaP-Haemophilus influenzae type b 

conjugate vaccine 

120 DTaP-Hib-IPV diphtheria, tetanus toxoids and acellular 

pertussis vaccine, Haemophilus influenzae 

type b conjugate, and poliovirus vaccine 

(DTaP-Hib-IPV) 

01 DTP diphtheria, tetanus toxoids and pertussis 

vaccine 

22 DTP-Hib DTP-Haemophilus influenzae type b conjugate 

vaccine 

102 DTP-Hib-Hep B DTP-Haemophilus influenzae type b conjugate 

and hepatitis b vaccine 

57 hantavirus hantavirus vaccine 

52 Hep A, adult hepatitis A vaccine, adult dosage 

83 Hep A, ped/adol, 2 dose hepatitis A vaccine, pediatric/adolescent 

dosage, 2 dose schedule 

84 Hep A, ped/adol, 3 dose hepatitis A vaccine, pediatric/adolescent 

dosage, 3 dose schedule 

31 Hep A, pediatric, NOS hepatitis A vaccine, pediatric dosage, NOS 

85 Hep A, NOS hepatitis A vaccine, NOS 

104 Hep A-Hep B hepatitis A and hepatitis B vaccine 

30 HBIG hepatitis B immune globulin 

08 Hep B, adolescent or pediatric hepatitis B vaccine, pediatric or 

pediatric/adolescent dosage 

42 Hep B, adolescent/high risk hepatitis B, adolescent/high risk infant dosage 

A1 - 14 
 

infant2 

43 Hep B, adult4 hepatitis B vaccine, adult dosage 

44 Hep B, dialysis hepatitis B vaccine, dialysis patient dosage 

45 Hep B, NOS hepatitis B vaccine, NOS 

58 Hep C hepatitis C vaccine 

59 Hep E hepatitis E vaccine 

60 herpes simplex 2 herpes simplex virus, type 2 vaccine 

46 Hib (PRP-D) Haemophilus influenzae type b vaccine, PRP-D 

conjugate 

47 Hib (HbOC) Haemophilus influenzae type b vaccine, HbOC 

conjugate 

48 Hib (PRP-T) Haemophilus influenzae type b vaccine, PRP-T 

conjugate 

49 Hib (PRP-OMP) Haemophilus influenzae type b vaccine, PRPOMP conjugate 

17 Hib, NOS Haemophilus influenzae type b vaccine, 

conjugate NOS 

51 Hib-Hep B Haemophilus influenzae type b conjugate and 

Hepatitis B vaccine 

61 HIV human immunodeficiency virus vaccine 

118 HPV, bivalent human papilloma virus vaccine, bivalent 

62 HPV, quadrivalent human papilloma virus vaccine, quadrivalent 

86 IG immune globulin, intramuscular 

87 IGIV immune globulin, intravenous 

14 IG, NOS immune globulin, NOS 

111 influenza, live, intranasal influenza virus vaccine, live, attenuated, for 

intranasal use 

15 influenza, split (incl. purified 

surface antigen) 

influenza virus vaccine, split virus (incl. purified 

surface antigen) 

16 influenza, whole influenza virus vaccine, whole virus 

88 influenza, NOS influenza virus vaccine, NOS 

10 IPV poliovirus vaccine, inactivated 

02 OPV poliovirus vaccine, live, oral 

89 polio, NOS poliovirus vaccine, NOS 

39 Japanese encephalitis Japanese encephalitis vaccine 

63 Junin virus Junin virus vaccine 

64 leishmaniasis leishmaniasis vaccine 

65 Leprosy leprosy vaccine 

66 Lyme disease Lyme disease vaccine 

03 MMR measles, mumps and rubella virus vaccine 

04 M/R measles and rubella virus vaccine 

94 MMRV measles, mumps, rubella, and varicella virus 

vaccine 

67 malaria malaria vaccine 

05 measles measles virus vaccine 

68 melanoma melanoma vaccine 

32 meningococcal meningococcal polysaccharide vaccine 

(MPSV4) 

103 meningococcal C conjugate meningococcal C conjugate vaccine 

114 meningococcal 

A,C,Y,W-135 diphtheria 

conjugate 

meningococcal polysaccharide (groups A, C, Y 

and W-135) diphtheria toxoid conjugate 

vaccine (MCV4) 

108 meningococcal, NOS meningococcal vaccine, NOS 

07 mumps mumps virus vaccine 

69 parainfluenza-3 parainfluenza-3 virus vaccine 

11 pertussis pertussis vaccine 

23 plague plague vaccine 

33 pneumococcal pneumococcal polysaccharide vaccine 

100 pneumococcal conjugate pneumococcal conjugate vaccine, polyvalent 

A1 - 15 
 

 

109 pneumococcal, NOS pneumococcal vaccine, NOS 

70 Q fever Q fever vaccine 

18 rabies, intramuscular injection rabies vaccine, for intramuscular injection 

40 rabies, intradermal injection rabies vaccine, for intradermal injection 

90 rabies, NOS rabies vaccine, NOS 

72 rheumatic fever rheumatic fever vaccine 

73 Rift Valley fever Rift Valley fever vaccine 

34 RIG rabies immune globulin 

119 rotavirus, monovalent rotavirus, live, monovalent vaccine 

122 rotavirus, NOS1 rotavirus vaccine, NOS 

116 rotavirus, pentavalent rotavirus, live, pentavalent vaccine 

74 rotavirus, tetravalent rotavirus, live, tetravalent vaccine 

71 RSV-IGIV respiratory syncytial virus immune globulin, 

intravenous 

93 RSV-MAb respiratory syncytial virus monoclonal antibody 

(palivizumab), intramuscular 

06 rubella rubella virus vaccine 

38 rubella/mumps rubella and mumps virus vaccine 

76 Staphylococcus bacterio lysate Staphylococcus bacteriophage lysate 

113 Td (adult) tetanus and diphtheria toxoids, adsorbed, 

preservative free, for adult use 

09 Td (adult) tetanus and diphtheria toxoids, adsorbed for 

adult use 

115 Tdap tetanus toxoid, reduced diphtheria toxoid, and 

acellular pertussis vaccine, adsorbed 

35 tetanus toxoid tetanus toxoid, adsorbed 

112 tetanus toxoid, NOS tetanus toxoid, NOS 

77 tick-borne encephalitis tick-borne encephalitis vaccine 

13 TIG tetanus immune globulin 

95 TST-OT tine test tuberculin skin test, old tuberculin, 

multipuncture device 

96 TST-PPD intradermal tuberculin skin test, purified protein derivative, 

intradermal 

97 TST-PPD tine test tuberculin skin test, purified protein derivative, 

multipuncture device 

98 TST, NOS tuberculin skin test, NOS 

78 tularemia vaccine tularemia vaccine 

91 typhoid, NOS typhoid vaccine, NOS 

25 typhoid, oral typhoid vaccine, live, oral 

41 typhoid, parenteral typhoid vaccine, parenteral, other than 

acetone-killed, dried 

53 typhoid, parenteral, AKD (U.S. 

military) 

typhoid vaccine, parenteral, acetone-killed, 

dried (U.S. military) 

101 typhoid, ViCPs typhoid Vi capsular polysaccharide vaccine 

75 vaccinia (smallpox) vaccinia (smallpox) vaccine 

105 vaccinia (smallpox) diluted vaccinia (smallpox) vaccine, diluted 

79 vaccinia immune globulin vaccinia immune globulin 

21 varicella varicella virus vaccine 

81 VEE, inactivated Venezuelan equine encephalitis, inactivated 

80 VEE, live Venezuelan equine encephalitis, live, 

attenuated 

92 VEE, NOS Venezuelan equine encephalitis vaccine, NOS 

36 VZIG varicella zoster immune globulin 

117 VZIG (IND) varicella zoster immune globulin 

(Investigational New Drug) 

37 yellow fever yellow fever vaccine 

121 zoster zoster vaccine, live 

998 no vaccine administered5 no vaccine administered 

999 unknown unknown vaccine or immune globulin 

A1 - 16 
 

 

 

 

 

 

 

 

 

99 RESERVED – do not use3 RESERVED – do not use 

Usage Notes: 

1.	 NOS=not otherwise specified; avoid using NOS codes except to record historical records that 

lack the indicated specificity. 

2.	 As of August 27, 1998, Merck ceased distribution of their adolescent/high risk infant hepatitis B 

vaccine dosage. Code 42 should only be used to record historical records. For current 

administration of hepatitis B vaccine, pediatric/adolescent dosage, use code 08. 

3.	 Code 99 will not be used in this table to avoid confusion with code 999. 

4.	 As of September 1999, a 2-dose hepatitis B schedule for adolescents (11-15 year olds) was FDA 

approved for Merck’s Recombivax HB® adult formulation. Use code 43 for both the 2-dose and 

the 3-dose schedules. 

5.	 Code 998 was added for use in VXR and VXU HL7 messages where the OBX segment is nested 

with the RXA segment, but the message does not contain information about a vaccine 

administration. An example of this use is to report the vaccines due next for a patient when no 

vaccine administration is being reported. 

6.	 As of May 2002, the FDA approved Aventis Pasteur’s DTaP Daptacel for use in the U.S. Aventis 

Pasteur also manufactures the DTaP vaccine Tripedia. Daptacel contains 5 pertussis antigens, 

while Tripedia contains 2 pertussis antigens. To distinguish between the two Aventis Pasteur 

DTaP vaccines, dose 106 was added to represent Daptacel. Use code 106 for Daptacel and 

code 20 for Tripedia and other DTaP vaccines 

User-defined Table 0296 - Language [ISO 639 suggested by HL7; selected 2-letter values listed from 

ISO 639:1988; The full set of ISO 639 Language Codes is available for purchase from <www.ansi.org>. 

Where ISO 2-letter codes are not available, 3-letter codes are given from the Ethnologue, available at 

<www.sil.org/ethnologue/>.] (use in PID-15) 

Value Description 

ASE American Sign Language 

Ar Arabic 

Hy Armenian 

Bn Bengali 

Km Cambodian (Khmer) 

CJD Chamorro 

YUH Chinese, Cantonese 

Zh Chinese, Mandarin 

Hr Croatian 

Cs Czech 

Nl Dutch 

En English 

Fa Farsi (Persian) 

Fr French 

De German 

el Greek 

hi Hindi 

BLU Hmong 

hu Hungarian 

ILO Ilocano 

id Indonesian 

it Italian 

ja Japanese 

ko Korean 

lo Laotian 

pl Polish 

pt Portuguese 

ro Romanian 

ru Russian 

sm Samoan 

sr Serbian 

A1 - 17 
 

 

 

 

 

 

Value Description 

sk Slovak 

so Somali 

es Spanish 

tl Tagalog 

th Thai 

to Tongan 

uk Ukranian 

ur Urdu 

vi Vietnamese 

yi Yiddish 

OTH Other (must add text component of the CE field with description) 

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]
 

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 

A1 - 18 
 

 

 

 

 

 

HL7-defined Table 0354 - Message structure [only selected values listed] (use in MSH-9, third 

component) 

Value Events 

ADT A01 A01, A04, A05, A08, A13, A14, A28, A31 

ADT A02 A02, A21, A22, A23, A25, A26, A27, A29, A32, A33 

ADT A30 A30, A34, A35, A36, A46, A47, A48, A49 

VXQ V01 V01 

VXR V03 V03 

VXU V04 V04 

VXX V02 V02 

ORU R01 R01 

HL7-defined Table 0356 - Alternate character set handling scheme (use in MSH-20) 

Value Description 

ISO 2022-1994 This standard is titled “Information Technology - Character Code Structure and 

Extension Technique.” This standard specifies an escape sequence from basic

one byte character set to specified other character set, and vice versa. The 

escape sequence explicitly specifies what alternate character set is to be 

evoked...This value is allowed only for HL7 v. 2.3.1. 

2.3 The character set switching mode specified in HL7 2.3, sections 2.8.28.6.1 and 

2.9.2. Note that the escape sequences used in this mode are “HL7 escape 

sequences” as defined in HL7 2.3, sec. 2.9, and do not use the ASCII “esc”

character, as defined in ISO 2022-1994. 

<null> This is the default, indicating that there is no character set switching occurring in 

this message. 

A1 - 19 
 

 

 

 

 

HL7-defined Table 0357 - Message error status codes (use in ERR-1) 

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 nonexistent patient. 

205 Duplicate key identifier The ID of the patient, order, etc. already exists. Used in 

response to addition transactions (Admit, New Order, 

etc.). 

206 Application record locked The transaction could not be performed at the application 

storage level, e.g., database locked. 

207 Application internal error A catchall for internal errors not explicitly covered by other 

codes. 

A1 - 20 
 

 

 

User-defined Table 0360 - Degree [selected values suggested by HL7; with NIP-suggested additions—

these will be included in HL7 Version 2.5] (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 

PHN Public Health Nurse 

RMA Registered Medical Assistant 

RN Registered Nurse 

RPH Registered Pharmacist 

SEC Secretarial Certificate 

TS Trade School Graduate 

A1 - 21 
 

 

 

 

 

 

User-defined Table 0396 – Coding system [only selected values listed] [From HL7 Standard, Version 

2.4] (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 

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 

NPI National Provider Identifier 

SNM Systemized Nomenclature of Medicine (SNOMED) 

SNM3 SNOMED International 

SNT SNOMED topology codes (anatomic sites) 

UML Unified Medical Language 

UPC Universal Product Code 

UPIN UPIN 

W1 WHO record # drug codes (6 digit) 

W2 WHO record # drug codes (8 digit) 

W4 WHO record # code with ASTM extension 

WC WHO ATC 

A1 - 22 
 

 

 

 

User-defined Table 0441 - Immunization registry status (Similar to previous Table NIP006 – Patient 

registry status) (use in PD1-16) [HL7 assigned table number 0441 in Version 2.4] 

Value Description 

A Active 

I Inactive 

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) 

O Other 

U Unknown 

HL7-defined Table 4000 - Name/address representation (use in all XPN, XAD data types) (PID-5, 6, 9, 

11) 

Value Description 

I Ideographic (e.g., Kanji) 

A Alphabetic (e.g., Default or some single-byte) 

P Phonetic (e.g., ASCII, Katakana, Hirigana, etc.) 

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 

A1 - 23 
 

 

 

 

 

 

 

NIP-defined NIP003 - Observation identifiers (use in OBX-3) 

LOINC® 

Code 

Description Corresponding 

data type 

(indicate in 

OBX-2) 

Corresponding 

observation value 

EXAMPLE OR code table 

to use (value in OBX-5) 

Dose Number for Combination Vaccines - Use in OBX-3 to indicate that OBX-5 value will be the dose 

number for a component of a combination vaccine. Used when dose numbers are different for the 

component antigens. The use of these codes is discouraged. Note that there is no code for “Polio 

dose count in combination vaccine”. It is preferred that LOINC® codes 38890-0&30973-2, which do not 

have that limitation, be used instead; see the section of this table for “Vaccine Component (of a 

combination vaccine)“.

30936-9 DTaP/DTP dose count in combination 

vaccine 

(NM) 4 

30937-7 Hepatitis B dose count in combination 

vaccine 

(NM) 3 

30938-5 Haemophilus influenzae B dose count in 

combination vaccine 

(NM) 2 

30939-3 Measles dose count in combination 

vaccine 

(NM) 2 

30940-1 MMR dose count in combination vaccine (NM) 2 

30941-9 Mumps dose count in combination vaccine (NM) 2 

30942-7 Rubella dose count in combination 

vaccine 

(NM) 2 

30943-5 Varicella dose count in combination 

vaccine 

(NM) 2 

Contraindications, Precautions, 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) NIP-defined Table NIP004 

31044-1 Reaction (CE) Locally defined 

Vaccine Information Statement (VIS) Dates 

29768-9 Date Vaccine Information Statement 

Published 

(TS) 19900605 

29769-7 Date Vaccine Information Statement 

Presented 

(TS) 199307311615 

Vaccine Component (of a combination vaccine) 

38890-0 Component Vaccine Type 

[38890-0 is the top level of this item 

description. Sub-components of this field 

are represented by a combination of this 

LOINC® code and a subcomponent 

LOINC® code, joined by an “&.”]

(CE) HL70292 

(CVX codes – use the 

codes described as 

“NOS” as needed.)

29768-9 38890-0&29768-9 – Date Vaccine 

Information Statement Published 

(TS) 19900605 

30973-2 38890-0&30973-2 -- Dose number in 

series 

(NM) 2 

30959-1 38890-0&30959-1 – Lot 

[This can be used for a combination 

vaccine that comes in a package 

containing separate vials that must be 

mixed prior to administration. The 

package has a lot # which should appear 

in the RXA segment. The component vial 

within the package may have its own lot # 

which is different.] 

(ST) Y706QB110 

A1 - 24 
 

 

 

 

 

 

 

 

 

 

LOINC® 

Code 

Description Corresponding 

data type 

(indicate in 

OBX-2) 

Corresponding 

observation value 

EXAMPLE OR code table 

to use (value in OBX-5) 

Vaccines 

Due Next 

30979-9 Vaccines due next 

[30979-9 is the top level of this item 

description. Sub-components of this field 

are represented by a combination of this 

LOINC® code and a subcomponent 

LOINC® code, joined by an “&.”]

(CE) HL70292 (CVX) 

30980-7 30979-9&30980-7 – Date vaccine due (TS) 19980526 

30973-2 30979-9&30973-2 -- Vaccine due next 

dose number 

(NM) 1 

30981-5 30979-9&30981-5 – Earliest date to give (TS) 19980522 

30982-3 30979-9&30982-3 – Reason applied by 

forecast logic to project this vaccine 

(CE) or (ST) Codes for forecast logic 

reason locally defined. 

Vaccine Adverse Event Reporting System (VAERS) - For additional information about VAERS, 

including a copy of the VAERS Form, see <www.cdc.gov/nip/vaers.htm> or 

<www.fda.gov/cber/vaers/vaers.htm>. (In this document, also see 7.2.1 (pages 13-17) Unsolicited 

Transmission of an Observation (ORU), Example VAERS ORU Message) 

30947-6 Date form completed (VAERS Form Item 

#6) 

(TS) 20010316 

30948-4 Vaccination adverse event(s)(symptoms, 

signs, time course) and treatment, if any 

(VAERS Form Item #7) 

(FT) Fever of 106F, with 

vomiting, seizures, etc. 

30949-2 Vaccination adverse event outcome 

(VAERS Form Item #8) 

(CE) NIP-defined Table NIP005 

30950-0 Number of days hospitalized due to 

vaccination adverse event (VAERS Form 

Item #8) 

(NM) 02 

30951-8 Patient recovered (VAERS Form Item #9) (CE) HL7 table HL70136 

30952-6 Date and time of vaccination (VAERS 

Form Item #10) 

(TS) 20010216 

30953-4 Vaccination adverse event onset date and 

time (VAERS Form Item #11) 

(TS) 20011021080900 

30954-2 Relevant diagnostic tests/laboratory data 

(VAERS Form Item #12) 

(FT) Electrolytes, CBC, 

Blood Culture 

30955-9 All vaccines given on date listed in no. 10 

(VAERS Form Item #13) 

[30955-9 represents the VAERS form item 

description. Sub-components of this field 

are represented by a combination of this 

LOINC® code and a subcomponent 

LOINC® code, joined by an “&.”]

see 7.2.1 (pages 13-17) 

Unsolicited Transmission 

of an Observation (ORU), 

See Example VAERS 

ORU Message, and items 

below 

30956-7 a) 30955-9&30956-7 Vaccine type (CE) HL7 table HL70292 (CVX) 

30957-5 b) 30955-9&30957-5 Vaccine 

manufacturer 

(CE) HL7 table HL70227 

(MVX) 

30959-1 c) 30955-9&30959-1 Lot (ST) A119PZY06022000 

30958-3 d) 30955-9&30958-3 Vaccine route (CE) HL7 table HL70162 

31034-2 e) 30955-9&31034-2 Vaccine site (CE) HL7 table HL70163 

30960-9 f) 30955-9&30960-9 Number of previous 

doses 

(NM) 01 

30961-7 Any other vaccinations within 4 weeks 

prior to the date listed in no.10 

See below 

A1 - 25 
 

 

 

 

 

LOINC® 

Code 

Description Corresponding 

data type 

(indicate in 

OBX-2) 

Corresponding 

observation value 

EXAMPLE OR code table 

to use (value in OBX-5) 

[30961-7 represents the VAERS form item 

description. Sub-components of this field 

are represented by a combination of this 

LOINC® code and a subcomponent 

LOINC® code, joined by an “&.”]

30956-7 a) 30961-7&30956-7 Vaccine type (CE) HL7 table HL70292 (CVX) 

30957-5 b) 30961-7&30957-5 Vaccine 

manufacturer 

(CE) HL7 table HL70227(MVX) 

30959-1 c) 30961-7&30959-1 Lot number (ST) KJM903XS8902Z 

30958-3 d) 30961-7&30958-3 Vaccine route (CE) HL7 table HL70162 

31034-2 e) 30961-7&31034-2 Vaccine site (CE) HL7 table HL70163 

30960-9 f) 30961-7&30960-9 Number of previous 

doses 

(NM) 01 

31035-9 g) 30961-7&31035-9 Date given (TS) 20010216 

30962-5 Vaccinated at (VAERS Form Item #15) (CE) NIP table NIP007 

30963-3 Vaccine purchased with (VAERS Form 

Item #16) 

(CE) NIP table NIP008 

30964-1 Other medications (patient was receiving 

at time of vaccination) (VAERS Form Item 

#17) 

(FT) None 

30965-8 Illness present at time of vaccination 

(VAERS Form Item #18) 

(FT) None 

30966-6 Pre-existing physician-diagnosed 

allergies, birth defects, medical conditions 

(VAERS Form Item #19) 

(FT) Past conditions 

convulsions 

30967-4 Adverse event reported previously 

(VAERS Form Item #20) 

(CE) NIP table NIP009 

30968-2 Adverse event following prior vaccination 

in patient (VAERS Form Item #21) 

[30968-2 represents the VAERS form item 

description. Sub-components of this field 

are represented by a combination of this 

LOINC® code and a subcomponent 

LOINC® code, joined by an “&.”]

see below 

30971-6 a) 30968-2&30971-6 -- Adverse event (FT) None 

30972-4 b) 30968-2&30972-4 -- Onset age (NM) 05 

30956-7 c) 30968-2&30956-7 -- Vaccine type (CE) HL7 table HL70292 (CVX) 

30973-2 d) 30968-2&30973-2 -- Dose number in 

series 

(NM) 02 

35286-4 Adverse event following prior vaccination 

in sibling #1 (VAERS Form Item #21) 

[35286-4 represents the VAERS form item 

description. Sub-components of this field 

are represented by a combination of this 

LOINC® code and a subcomponent 

LOINC® code, joined by an “&.”]

See below 

30971-6 a) 35286-4&30971-6 -- Adverse event (FT) Vomiting, fever, otitis 

media 

30972-4 b) 35286-4&30972-4 -- Onset age (NM) 04 (mo) 

30956-7 c) 35286-4&30956-7 -- Vaccine type (CE) HL7 table HL70292 

(CVX)) 

A1 - 26 
 

 

 

 

 

 

 

 

LOINC® 

Code 

Description Corresponding 

data type 

(indicate in 

OBX-2) 

Corresponding 

observation value 

EXAMPLE OR code table 

to use (value in OBX-5) 

30973-2 d) 35286-4&30973-2 -- Dose number in 

series 

(NM) 02 

35286-4 Adverse event following prior vaccination 

in sibling #2 (VAERS Form Item #21) 

[35286-4 represents the VAERS form item 

description. Sub-components of this field 

are represented by a combination of this 

LOINC® code and a subcomponent 

LOINC® code, joined by an “&.”]

See below 

(Note: No Adverse 

Event took place in this 

instance for sibling #2: 

therefore the None, and 

N/A/ notes below apply.) 

30971-6 a) 35286-4&30971-6 -- Adverse event (FT) None 

30972-4 b) 35286-4&30972-4 -- Onset age (NM) N/A (no Adverse Event) 

30956-7 c) 35286-4&30956-7 -- Vaccine type (CE) N/A (no Adverse Event) 

(HL7 table HL70292 

(CVX)) 

30973-2 d) 35286-4&30973-2 -- Dose number in 

series 

(NM) N/A (no Adverse Event) 

8339-4 Birth weight at birth(VAERS Form Item 

#22) 

(NM) 82 (oz) (HL7 Figure 7-11, 

ANSI+unit codes) 

30974-0 Number of brothers and sisters (VAERS 

Form Item #23) 

(NM) 2 

30975-7 Manufacturer/immunization project report 

No. (VAERS Form Item #24) 

(ST) 12345678 (only for 

reports submitted by mfr 

or immunization projectapplies to this item and 

also three items belowt) 

30976-5 Date received by 

manufacturer/immunization project 

(VAERS Form Item #25) 

(TS) 20010320 

30977-3 15 day report (VAERS Form Item #26) N (No) (HL7 table 

HL70136) 

30978-1 Report type (VAERS Form Item #27) I (Initial) (NIP table 

NIP010) 

LOINC® codes are copyright 1995-2002, Regenstrief Institute and the Logical Observation Identifier 

Names and Codes (LOINC®) Committee. All rights reserved. 

A1 - 27 
 

 

 

 

 

 

 

NIP-defined NIP004 - Contraindications, Precautions, and Immunities [Descriptions and explanations 

are summarized from Appendix A of the January 2002 Epidemiology and Prevention of VaccinePreventable Diseases. For more detail, see the appropriate ACIP recommendations at 

www.cdc.gov/nip/publications/ACIP-list.htm. This list also includes suggested codes by immunization 

registry representatives.] (use in OBX-5 when OBX-3 is valued as LOINC® code 30945-0, Vaccination 

contraindication/precaution) 

Value Description Explanation 

01 recipient condition - unspecified 

02 household condition - unspecified 

03 allergy to baker’s yeast (anaphylactic) contraindicates Hep B 

04 allergy to egg ingestion (anaphylactic) 

05 allergy to gelatin (anaphylactic) extreme caution for MMR & 

varicella 

06 allergy to neomycin (anaphylactic) contraindicates IPV, MMR & 

varicella 

07 allergy to streptomycin (anaphylactic) contraindicates IPV 

08 allergy to thimerosal (anaphylactic) 

09 allergy to previous dose of this vaccine or to any 

of its unlisted vaccine components (anaphylactic) 

contraindicates that vaccine 

10 anaphylactic (life-threatening) reaction to previous 

dose of this vaccine or any of its components 

contraindicates that vaccine 

11 collapse or shock like state within 48 hours of 

previous dose of DTP/DTaP 

precaution for DTP/DTaP 

12 convulsions (fits, seizures) within 72 hours of 

previous dose of DTP/DTaP 

precaution for DTP/DTaP 

13 persistent, inconsolable crying lasting ≥3 hours 

within 48 hours of previous dose of DTP/DTaP 

precaution for DTP/DTaP 

14 current diarrhea, moderate to severe contraindicates vaccination 

temporarily (until illness resolves) 

15 encephalopathy within 7 days of previous dose of 

DTP or DTaP 

contraindicates DTP/DTaP 

permanently 

16 current fever with moderate-to-severe illness contraindicates vaccination 

temporarily (until illness resolves) 

17 fever of ≥40.5°C (105°F) within 48 hours of 

previous dose of DTP/DTaP 

precaution for DTP/DTaP 

18 Guillain-Barré syndrome (GBS) within 6 weeks of 

previous dose of DTP/DTaP 

precaution for DTP/DTaP 

19 [inactiveuse 36 HIV infection (in household contact) contraindicates OPV 

20 [inactiveuse 36 HIV infection (in recipient) contraindicates OPV & VZV 

21 current acute illness, moderate to severe (with or 

without fever) (e.g., diarrhea, otitis media, 

vomiting) 

contraindicates vaccination 

temporarily (until illness resolves) 

22 chronic illness (e.g., chronic gastrointestinal 

disease) 

decide to vaccinate on an 

individual basis 

23 recent or simultaneous administration of an 

antibody-containing blood product (immune 

globulin) 

precaution for MMR & varicella 

24 immunity: diphtheria 

25 immunity: Haemophilus influenzae type B (Hib) 

26 immunity: hepatitis B 

27 immunity: measles 

28 immunity: mumps 

29 immunity: pertussis 

30 immunity: poliovirus 

31 immunity: rubella 

32 immunity: tetanus 

A1 - 28 
 

 

Value Description Explanation 

33 immunity: varicella (chicken pox) 

34 [inactiveuse 36 immunodeficiency (family history) contraindicates OPV & VZV 

unless immune status of recipient 

and other children in the family is 

documented 

35 [inactiveuse 36 immunodeficiency (household contact) contraindicates OPV 

36 immunodeficiency due to any cause, including 

HIV (hematologic and solid tumors, congenital 

immunodeficiency, long-term immunosuppressive 

therapy, including steroids) 

contraindicates OPV, MMR & 

varicella 

37 underlying unstable, evolving neurologic 

disorders, (including seizure disorders, cerebral 

palsy, and developmental delay) 

precaution for DTP/DTaP 

38 otitis media (ear infection) moderate to severe 

(with or without fever) 

contraindicates vaccination 

temporarily (until illness resolves) 

39 pregnancy (in recipient) contraindicates MMR & varicella 

40 thrombocytopenia precaution for MMR 

41 thrombocytopenic purpura (history) precaution for MMR 

42 other contraindication/precaution/immunity not 

listed (must add text component of the CE field 

with description) 

43 unknown (valid only for historical immunizations) 

A1 - 29 
 

 

 

 

 

 

 

 

 

 

 

 

NIP-defined NIP005 - Event consequence [adapted from HL7-defined Table 0240] (use in OBX-5 when 

OBX-3 is valued as 30949-2 - Vaccination adverse event outcome) 

Value Description 

D Patient died 

L Life threatening illness 

E Required emergency room/doctor visit 

H Required hospitalization (indicate # of days in another OBX segment) 

P Resulted in prolongation of hospitalization 

J Resulted in permanent disability 

O None of the above 

NIP-defined NIP006 – Patient registry status 

This table is now inactive. Use User-defined Table 0441 – Immunization registry status. 

NIP-defined NIP007 - Vaccinated at location. (use in OBX-5 when OBX-3 is valued as 30962-5 -

Vaccinated at) (VAERS item #15) 

Value Description 

PVT Private doctor’s office/hospital 

PUB Public Health Clinic/Hospital 

MIL Military clinic/Hospital 

WRK Workplace 

OTH Other 

UNK Unknown 

NIP-defined NIP008 - Vaccine purchased with (use in OBX-5 when OBX-3 is valued as 30963-3-

Vaccine purchased with) (VAERS item #16) 

Value Description 

PVF Private funds 

PBF Public funds 

MLF Military funds 

OTH Other 

NIP-defined NIP009 – Reported adverse event previously (use in OBX-5 when OBX-3 is valued as 

30967-4 - Reported adverse event previously) (VAERS item #20) 

Value Description 

N No 

D To doctor 

H To health department 

M To manufacturer 

NIP-defined NIP010 - Report type recommended values. (use in OBX-5 when OBX-3 is valued as 

30978-1 - Report type) (VAERS Item #27) 

Value Description 

I Initial 

F Follow-up 

A1 - 30 
(1)

(2)

(3)

2.8.

2.8.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

APPENDIX 2: Data Types used in this Implementation Guide 

HL7 

Ref# Data Type Description Notes 

2.8.3 CE - coded 

element with 

formatted 

values 

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

allow all six components of a CE data type to be valued, the suggested 

length of a field of this data type is at least 60. 

Components: 

<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^ 

<alternate identifier (ST)>^<alternate text (ST)> ^<name of alternate 

coding system (ST)> 

Components are defined as follows: 

(1) Identifier (ST). The code that uniquely identifies the item being 

referenced by the <text>. Different coding schemes will have different 

elements here. 

(2) Text (ST). Name or description of the item in question. 

(3) Name of coding system (ST). Identifies the coding 

system used. The combination of the identifier and the name 

of the coding system components will be a unique code for a 

data item. 

(4-6) Three components analogous to 1-3 for the alternate or 

local coding system. 

For HL7-defined tables, the third 

component, name of coding 

system, is constructed by 

appending the table number to the 

string “HL7.” For example, the 

HL7 table number 0163 would be 

designated in the “name of 

coding system” component as 

“HL70163.” 

The second set of codes must 

carry the same meaning as the 

first set. For example, for 

immunization data, a first set 

using CVX codes followed by a 

second set using CPT codes may 

be used to record the 

administration of a single 

vaccine. 

The presence of two sets of 

equivalent codes in this data type 

is semantically different from a 

repetition of a CE-type field. 

With repetition, several distinct 

codes (with distinct meanings) 

may be transmitted. 

2.8.5 CK - composite 

ID with check 

digit 

Components: <ID number (NM)>^<check digit (NM)>^<code 

identifying the check digit scheme employed (ID)>^<assigning authority 

(HD)> 

Components are defined as follows: 

(1) ID number (NM). 

(2) Check digit (NM). This 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 null. 

(3) Code identifying the check digit scheme employed (ID). Check 

digit scheme codes are defined in HL7 Table 0061 - Check digit scheme. 

Note: Mod 10 and Mod 11 check digit algorithms are defined in the 

HL7 Standard Section 2.8.5.3. 

This data type is used for certain 

fields that commonly contain 

check digits, e.g., PID-3-Patient 

identifier list. If a user is not 

using check digits for a CK field, 

the second and third components 

are not valued. 

2.8.6 CM -

composite 

A field that is a combination of other meaningful data fields. Each 

portion is called a component. The specific components of CM fields are 

defined within the field descriptions. 

The CM data type is maintained 

strictly for backward 

compatibility and may not be 

used for the definition of new 

fields. 

2.8.9 CP - composite 

price 

Components: <price (MO)>^<price type (ID)>^<from value (NM)>^<to 

value (NM)>^<range units (CE)>^<range type (ID)> 

See HL7 Standard for component 

definitions. 

2.8.10 CQ - composite 

quantity with 

units 

Components: <quantity (NM)>^<units (CE)> Future use of this data type will 

be avoided because the same 

information can be sent as a CE 

data type. 

2.8.12 CX - extended 

composite ID 

with check 

digit 

Components: <ID (ST)>^<check digit (ST)>^<code identifying the 

check digit scheme employed (ID)>^<assigning authority 

(HD)>^<identifier type code (IS)>^<assigning facility (HD)> 

Components are defined as follows: 

(1) ID (ST). 

(2) Check digit (ST). Defined as in the CK data type except as a ST. 

The check digit used 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 

Refer to User-defined Table 0203 

- Identifier type for suggested 

values for component 5. 

A2 - 1 
(3)

4.

5.

6.

(1)

(2)

(1)

(2)

(3)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

HL7 

Ref# Data Type Description Notes 

component should be valued null. 

(3) Code identifying the check digit scheme employed (ID). 

(4) Assigning authority (HD). 

Subcomponents of (4): 

<application identifier 1 (ID)> & <application identifier 2 (ID)> & 

<application identifier 3 (ID)> & <application identifier 4 (ID)> & 

<application identifier 5 (ID)> & <application identifier 6 (ID)> 

(5) Identifier type code (IS). A code corresponding to the type of 

identifier. This code may be used as a qualifier to the “Assigning 

authority” component. Refer to User-defined Table 0203 - Identifier 

type for suggested values. 

(6) Assigning facility (HD). The place or location identifier where the 

identifier was first assigned to the patient-part of the history of the 

identifier. 

Subcomponents of (6): 

<namespace ID (IS)>&<universal ID (ST)>&<universal ID type (ID)> 

2.8.13 DLN – driver’s 

license number 

Components: <license number (ST)>^<issuing state, province, country 

(IS)>^<expiration date (DT)> 

This data type gives the driver’s 

license information. See HL7 

Standard for component 

definitions and tables to use. 

2.8.15 DT - date Format: YYYY[MM[DD]] The precision of a date may be 

expressed by limiting the number 

of digits used with the format 

specification YYYY[MM[DD]]. 

2.8.17 EI - entity 

identifier 

Components: <entity identifier (ST)>^<namespace ID (IS)>^<universal 

ID (ST)>^<universal ID type (ID)> 

Components are defined as follows: 

(1) Entity identifier (ST). This component is usually defined to be 

unique within the series of identifiers created by the assigning 

authority, defined by a hierarchic designator, represented by 

components (2) through (4). (These are as defined here at 2.8.20, 

“HD - hierarchic designator.”) 

The entity identifier defines a 

given entity within a specified 

series of identifiers. 

2.8.18 FC - financial 

class 

Components: <financial class (IS)>^<effective date (TS)> 

Components are defined as follows: 

(1) Financial class (IS). The financial class assigned to a person. 

Refer to User-defined Table 0064 - Financial class for suggested values. 

(2) Effective date (TS). The effective date/time of the person’s 

assignment to the financial class specified in the first component. 

Used in immunization registries 

to classify VFC eligibility. 

2.8.19 FT - formatted 

text data 

This data type is derived from the string data type by allowing the 

addition of embedded formatting instructions. These instructions are 

limited to those that are intrinsic and independent of the circumstances 

under which the field is being used. The FT field is of arbitrary length 

(up to 64K) and may contain formatting commands enclosed in escape 

characters. 

2.8.20 HD - hierarchic 

designator 

A unique name that identifies the system which was the source of the 

data. The HD is designed to be used either as a local version of a sitedefined application identifier or a publicly-assigned UID. Syntactically, 

the HD is a group of two application identifiers: one defined by the first 

component, and one defined by the second and third components. 

Components: <namespace ID (IS)>^ <universal ID (ST)>^<universal ID 

type (ID)> 

Components are defined as follows: 

(1) Namespace ID (IS). Refer to User-defined Table 0300 -

Namespace ID for suggested values. 

(2) Universal ID (ST). The UID is a string formatted according to the 

scheme defined by the third component, UID type. The UID is intended 

to be unique over time within the UID type. It is rigorously defined by 

the scheme constructing it. The UID must follow the syntactic rules of 

the particular scheme defined in the third component. 

(3) Universal ID type (ID). Governs the interpretation of the second 

Used in fields that formerly used 

the IS data type. When only the 

first HD component is valued, it 

looks like a simple IS data type. 

Designed to be an application 

identifier, either as a local version 

of a site-defined application 

identifier or a publicly-assigned 

universal ID (UID). The HD is a 

group of two application 

identifiers: one defined by the 

first component, and one defined 

by the second and third 

components. 

If the first component is present, 

A2 - 2 
(1)

(2)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

HL7 

Ref# Data Type Description Notes 

component of the HD. If it is a known UID, refer to HL7 Table 0301 -

Universal ID type for valid values. 

the second and third components 

are optional. The second and third 

components must either both be 

valued (both non-null), or both be 

not valued (both null). 

2.8.21 ID - coded 

value for HL7-

defined tables 

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. Examples of ID 

fields include MSH-12-Version ID and PD1-12-Protection indicator. 

This data type should be used 

only for HL7 tables. The reverse 

is not true, since in some 

circumstances, it is more 

appropriate to use the CE data 

type for HL7 tables. 

2.8.22 IS - coded 

value for userdefined tables 

The value of such a field follows the formatting rules for an ST field 

except that it is drawn from a site-defined (or user-defined) table of legal 

values. An example of an IS field is PID-8-Sex. 

This data type should be used 

only for user-defined tables. The 

reverse is not true, since in some 

circumstances, it is more 

appropriate to use the CE data 

type for user-defined tables. 

2.8.23 JCC - job 

code/class 

Format: <job code (IS)>^<job class (IS)> See HL7 Standard for component 

definitions and tables to use. 

2.8.25 MO - money Components: <quantity (NM)>^<denomination (ID)> See HL7 Standard for component 

definitions and tables to use. 

2.8.26 NM - numeric 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. 

Leading zeros, or trailing zeros after a decimal point, are not significant. 

2.8.28 PL - person 

location 

Components: <point of care (IS)>^<room (IS)>^<bed (IS)>^<facility 

(HD)>^<location status (IS)>^<person location type (IS)>^<building 

(IS)>^<floor (IS)>^<location description (ST)> 

Used to specify a patient location 

within a healthcare institution. 

See HL7 Standard for component 

definitions and tables to use. 

2.8.30 PN - person 

name 

Components: <family name (ST)>&<last name prefix (ST)>^<given 

name (ST)>^<middle initial or name (ST)>^<suffix (e.g., Jr. or III) 

(ST)>^<prefix (e.g., Dr.) (ST)>^<degree (e.g., MD) (IS)> 

Components are defined as follows: 

(1) Family name (ST) & Last name prefix (ST). Surname/last name. 

Last name prefix is for use with Germanic languages (e.g., van in 

Ludwig van Beethoven). 

(2) Given name (ST). 

(3) Middle initial or name (ST). 

(4) Suffix (ST). Used to specify a name suffix (e.g., Jr. or III). 

(5) Prefix (ST). Used to specify a name prefix (e.g., Dr.). 

(6) Degree (IS). Used to specify an educational degree (e.g., MD). 

See User-defined Table 0360 - Degree for values. 

Note: To “translate” the last name 

prefix and the family name, 

prepend the last name prefix to 

the family name component. If 

the last name prefix is not null, 

the last name prefix should not 

also be present as part of the 

family name component. 

2.8.31 PT - processing 

type 

Components: <processing ID (ID)>^<processing mode (ID)> 

Components are defined as follows: 

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. 

Processing mode (ID). A value that defines whether the message is part 

of an archival process or an initial load. Refer to HL7 Table 0207 -

Processing mode for valid values. The default (blank) means current 

processing. 

2.8.38 SI - sequence 

ID 

A non-negative integer in the form of an NM field. The uses of this data type are 

defined in the chapters defining 

the segments and messages in 

which it is used. 

2.8.40 ST - string data Any printable ASCII characters except the defined delimiter characters. 

To include any HL7 delimiter character (except the segment terminator) 

within a string data field, use the appropriate HL7 escape sequence. 

String data is left justified with trailing blanks optional. 

The ST data type is intended for 

short strings (less than 200 

characters). For longer strings, 

the TX or FT data types should 

A2 - 3 
(1)

(2)

(3)

(9)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

HL7 

Ref# Data Type Description Notes 

be used. 

2.8.43 TQ - timing 

quantity 

Components: <quantity (CQ)>^<interval (CM)>^<duration (ST)>^<start 

date/time (TS)>^<end date/time (TS)>^<priority (ST)>^<condition 

(ST)>^<text (TX)>^<conjunction (ST)>^<order sequencing 

(CM)>^<performance duration (CE)>^<total occurrences (NM)> 

Describes when a service should 

be performed and how frequently. 

Complete description is in HL7 

Standard Section 4.4. 

2.8.44 TS - time 

stamp 

Contains the exact time of an event, including the date and time. 

Format: YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]^ 

<degree of precision> 

The date portion of a time stamp follows the rules of a date field (DT) 

and the time portion follows the rules of a time field (TM). HL7 

recommends, but does not require, that all systems routinely send the 

time zone offset. 

The optional degree of precision 

component is retained only for 

backwards compatibility. 

Immunization registries will not 

value this component. Instead, 

the precision of the data may be 

indicated by limiting the number 

of digits valued. 

2.8.45 TX - text data String data meant for user display (on a terminal or printer). Not 

necessarily left justified. Leading spaces may contribute to clarity of the 

presentation to the user. 

2.8.47 VID - version 

identifier 

Components: <version ID (ID)>^<internationalization code 

(CE)>^<international version ID (CE)> 

Components are defined as follows: 

Version ID (ID). Used to identify the HL7 version. Refer to HL7 Table 

0104 - Version ID for valid values. 

Internationalization code (CE). Used to identify the international 

affiliate country code. ISO 3166 provides a list of country codes that 

may be used (see User-defined Table 0212 - Nationality). 

International version ID (CE). Used when the international affiliate has 

more than a single local version associated with a single U.S. version. 

2.8.48 XAD -

extended 

address 

Components: <street address (ST)>^ <other designation (ST)>^<city 

(ST)>^<state or province (ST)>^<zip or postal code (ST)>^<country 

(ID)>^<address type (ID)>^<other geographic designation 

(ST)>^<county/parish code (IS)>^<census tract (IS)>^<address 

representation code (ID)> 

Components are defined as follows: 

(1) Street address (ST). The street or mailing address of a person or 

institution. 

(2) Other designation (ST). Second line of address (e.g., Suite 555, or 

Fourth Floor). 

(3) City (ST). 

(4) State or province (ST). State or province should be represented by 

the official postal service codes for that country. 

(5) Zip or postal code (ST). Zip or postal codes should be represented 

by the official codes for that country. In the U.S., the zip code 

takes the form 99999[-9999], while the Canadian postal codes take 

the form A9A-9A9. 

(6) Country (ID). Defines the country of the address. ISO 3166 

provides a list of country codes that may be used (see User-defined 

Table 0212 - Nationality). 

(7) Address type (ID). Type is optional and defined by HL7 Table 

0190 - Address type. 

(7) Other geographic designation (ST). Other geographic designation 

includes county, bioregion, SMSA, etc. 

(9) County/Parish Code (IS). This component should not duplicate 

component 8. Refer to User-defined Table 0289 - County/Parish for 

values. 

(10) Census Tract (IS). Refer to User-defined Table 0288 - Census tract 

for values. 

(11) Address representation code (ID). See HL7 Table 4000 -

Name/address representation. 

HL7 Table 0190 - Address type 

allows user to designate the type 

of address (e.g., mailing, 

residence at birth, birth delivery 

location). When this field is 

allowed to repeat, several 

addresses can be recorded in the 

field, with each type noted. 

2.8.49 XCN -

extended 

Components: <ID number (ST)>^<family name (ST)>&<last name 

prefix (ST)>^<given name (ST)>^<middle initial or name (ST)>^<suffix 

See PN (1-6) for component 

definitions (2-7). 

A2 - 4 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

HL7 

Ref# Data Type Description Notes 

composite ID 

number and 

name for 

persons 

(e.g., Jr. or III) (ST)>^<prefix (e.g., Dr.) (ST)>^<degree (e.g., MD) 

(IS)>^<source table (IS)>^<assigning authority (HD)>^<name type code 

(ID)>^<identifier check digit (ST)>^<code identifying the check digit 

scheme employed (ID)>^<identifier type code (IS)>^<assigning facility 

ID (HD)>^<name representation code (ID)> 

Components are defined as follows: 

(1) ID number. This string refers to the coded ID according to a userdefined table. If the first component is present, either the source 

table or the assigning authority must be valued. 

(2-7) These components are defined as in the PN data type(1-6). 

(8) Source table (IS). Refer to user-defined table 0297 - CN ID source 

for suggested values. Used to delineate the first component. 

(9) Assigning authority (HD). 

Subcomponents of (9): <namespace ID (IS)>&<universal ID (ST)> 

& <universal ID type (ID)> 

(10) Name type code (ID). Refer to User-defined Table 0200 - Name 

type for valid values. 

(11) Identifier check digit (ST). 

(12) Code identifying the check digit scheme employed (ID). 

(13) Identifier type code (IS). Refer to user-defined table 0203 -

Identifier type for valid values. 

(14) Assigning facility (HD). 

Subcomponents of (14): <namespace ID (IS)>&<universal ID 

(ST)> & <universal ID type (ID)> 

(15) Name representation code (ID). See HL7 Table 4000 -

Name/address representation for valid values. 

2.8.50 XON -

extended 

composite 

name and 

identification 

number for 

organizations 

Components: <organization name (ST)>^<organization name type code 

(IS)>^<ID number (NM)>^<check digit (NM)>^<code identifying the 

check digit scheme employed (ID)>^<assigning authority 

(HD)>^<identifier type code (IS)>^<assigning facility ID (HD)>^<name 

representation code (ID)> 

Components are defined as follows: 

(1) Organization name (ST). The name of the specified organization. 

(2) Organization name type code (IS). Refer to User-defined Table 

0204 - Organizational name type. 

(3-5) Defined as in CK (1-3). 

(6) Assigning authority (HD). 

Subcomponents of (9): <namespace ID (IS)>&<universal ID (ST)> 

& <universal ID type (ID)> 

(7) Identifier type code (IS). Refer to user-defined table 0203 -

Identifier type for valid values. 

(8) Assigning facility (HD). 

Subcomponents of (8): <namespace ID (IS)>&<universal ID (ST)> 

& <universal ID type (ID)> 

(9) Name representation code (ID). See HL7 Table 4000 -

Name/address representation for valid values. 

See CK (1-3) for XON 

components (3-5). 

2.8.51 XPN -

extended 

person name 

Components: <family name (ST)>&<last name prefix (ST)>^<given 

name (ST)>^<middle initial or name (ST)>^<suffix (e.g., Jr. or III) 

(ST)>^<prefix (e.g., Dr.) (ST)>^<degree (e.g., MD) (IS)>^<name type 

code (ID)>^<name representation code (ID)> 

Components are defined as follows: 

(1-6) These components are defined as in the PN data type. 

(7) Name type code (ID). Refer to HL7-defined Table 0200 - Name 

type for valid values. 

(8) Name representation code (ID). Refer to HL7-defined Table 4000 -

Name/address representation for valid values. 

2.8.52 XTN -

extended 

telecommunica 

tion number 

Format and Components: [NNN] [(999)]999-9999[X99999][B99999][C 

any text]^<telecommunication use code (ID)>^<telecommunication 

equipment type (ID)>^<email address (ST)>^<country code 

(NM)>^<area/city code (NM)>^<phone number (NM)>^<extension 

(NM)>^<any text (ST)> 

Note: To interoperate with CEN’s 

Telecommunication data attribute 

group, HL7 allows use of the 

second component for email 

addresses. When used for an 

A2 - 5 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

HL7 

Ref# Data Type Description Notes 

For codes, refer to HL7-defined Table 0201 - Telecommunication use 

code and HL7-defined Table 0202 - Telecommunication equipment type. 

Internet address, the first 

component will be null; the 

second component will have the 

code NET, and the type of 

Internet address is specified with 

Internet or X.400 in the third 

component. When used for an 

Internet address, the first 

component of the XTN data type 

will be null. If the @-sign is 

being used as a subcomponent 

delimiter, the HL7 subcomponent 

escape sequence may be used 

(See Section 2.9 of the HL7 

Standard). 

A2 - 6 
 

 

 

 

 

 

 

 

 

 

APPENDIX 3: Recommended Core Data Set for Immunization Registries 

This core data set was prepared in 1995 by the National Immunization Program (NIP) in consultation with 

the Immunization Grantee Working Group. It was reviewed by the National Vaccine Advisory Committee 

(NVAC), and recommendations of NVAC were incorporated. Contributions were also made by public 

health representatives and private providers. 

The core data elements fall into two categories: required and optional. In addition, two functions for future 

consideration are presented here. Required core data elements are listed in bold print. These elements 

represent fundamental attributes necessary for identifying individuals and for describing immunization 

events. Required elements are critical to the record exchange process. Optional core data elements are 

less important for record exchange. Some optional items (e.g., address) may be useful only at the local 

level. 

The purpose of the core data set is to facilitate record exchange between immunization registries. It is 

imperative that, at a minimum, each registry include in its database schema a method to receive and 

store all of the required core data elements, even if the registry does not routinely collect the information. 

Thus, if a registry receives a record from one system and subsequently transfers it to another, no required 

core data elements will be lost in the process. It is strongly recommended that immunization registries 

also collect data on all of the required core data elements for their own patients. 

Listing of Core Data Set
 

(Required data elements are listed in bold print.)
 

Patient/System/State Identifiers 

(Until a unique personal identifier can be established on a national basis, multiple means of identification 

must be used.) 

Patient name: first, middle, last 

Patient alias name: first, middle, last
 

(former names for management of adoptions and name changes)
 

Patient address, phone number, birthing facility
 

(these variables should be locally defined)
 

Patient Social Security number (SSN) 

Patient birth date 

Patient sex 

Patient race 

Patient primary language 

Patient birth order 

Patient birth registration number 

Patient birth State/country 

Patient Medicaid number 

Mother's name: first, middle, last, maiden 

Mother's SSN 

Father's name: first, middle, last 

Father's SSN 

A3 - 1 
 

 

 

 

 

 

 

 

 

 

 

 

 

Immunization Event Identifiers 

Vaccine type 

(Use HL7-defined Table 0292 - Vaccines Administered (code=CVX) found in Appendix 1. 

Note that up-to-date versions of this table will be maintained on the NIP website at 

<www.cdc.gov/nip/registry>.) 

Vaccine Manufacturer 

(Use HL7-defined Table 0227 - Manufacturers of vaccines (code=MVX) found in Appendix 1. 

Note that up-to-date versions of this table will be maintained on the NIP website at 

<www.cdc.gov/nip/registry>.) 

Vaccine dose number 

NOTE: With a fully operating system, this variable is not needed. However, in the real world, 

and particularly during the initial startup phase, many systems will be gathering partial 

histories; therefore, to evaluate histories properly, dose number becomes very important. 

The ultimate goal would be to remove this variable from the core data set, within the first 2 to 

3 years of system operation. 

Vaccine expiration date 

Vaccine injection site 

Vaccination date 

Vaccine lot number 

Vaccine provider 

These Items Were Designated by NVAC as Functions for Future Consideration 

Vaccine adverse events monitoring 

[Such events must be linkable to the existing national adverse events surveillance system, 

with immunization information systems having ability to electronically report, without 

redundant keying of information to the Vaccine Adverse Events Reporting System (VAERS).] 

Vaccine preventable disease reporting 

[Such disease events must be linkable to existing local, state and national disease reporting 

systems, with the immunization information systems having ability to electronically report, 

without redundant keying of information to the appropriate disease reporting systems.] 

A3 - 2 
 

APPENDIX 4: VACCINE ADVERSE EVENT REPORTING SYSTEM (VAERS) 

A4 - 1 
 

A4 - 2 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

APPENDIX 5: NARRATIVE REVIEW OF REVISED, ADDED, OR DELETED MATERIAL SHOWING NEW
 

AND PREVIOUS VERSIONS WITH SPECIFIC CHANGES MADE (unless otherwise noted)
 

Revised, Added or Deleted Text (version 2.2, June 2006) Page 3 

(Bold Italics indicate added material.) 

Summary - Message type abbreviations are added. The reference to ADT messages is deleted (see 

Previous Text below.)
 

IMMUNIZATION DATA TRANSACTION MESSAGES 

Information systems that maintain immunization records need to be able to transmit patient-specific 

immunization histories electronically to other systems to allow healthcare providers to have access to these 

records at the time health care is given. Electronic tracking of immunization records also allows providers to 

track their own progress in reaching age-appropriate immunization coverage levels easily and efficiently. 

The data transmissions between registries will occur as the result of four activities: (1) a query from one 

system for a patient's vaccination record that is held in another system (VXQ); (2) a response to a query 

containing multiple patient "matches" to the query, but not returning vaccination records (VXX); (3) a 

response to a query containing the vaccination record (VXR); and (4) an unsolicited update to a vaccination 

record (VXU). 

Trigger event V01 will initiate the Query for Vaccination Record (VXQ) message. Two responses are 

possible: (1) event type V02--Response to Vaccination Query Returning Multiple PID Matches (VXX), or (2) 

event type V03--Response to Query Returning Vaccination Record (VXR). Trigger event type V04 will initiate 

the Unsolicited Update to Vaccination Record (VXU) message. Addition of new patients can be 

accomplished by using either VXU (V04) or ADT. The interaction model at the end of this section graphically 

depicts this process. 

=============================================================================== 

Previous Text (version 2.1, September 2002) Page 3 

(Strike-through indicates material deleted from newer version above) 

IMMUNIZATION DATA TRANSACTION MESSAGES 

Information systems that maintain immunization records need to be able to transmit patient-specific 

immunization histories electronically to other systems to allow healthcare providers to have access to these 

records at the time health care is given. Electronic tracking of immunization records also allows providers to 

track their own progress in reaching age-appropriate immunization coverage levels easily and efficiently. 

The data transmissions will occur as the result of four activities: (1) a query from one system for a patient's 

vaccination record that is held in another system; (2) a response to a query containing multiple patient 

"matches" to the query, but not returning vaccination records; (3) a response to a query containing the 

vaccination record; and (4) an unsolicited update to a vaccination record. Some registries will use 

Admission/Discharge/Transfer (ADT) transactions to add or update patient information. Registries will need 

to determine how they will add new patients or update patient information when no immunization activity is 

involved. ADT messages can provide these functions and are described in this document. 

Trigger event V01 will initiate the Query for Vaccination Record (VXQ) message. Two responses are 

possible: (1) event type V02--Response to Vaccination Query Returning Multiple PID Matches (VXX), or (2) 

event type V03--Response to Query Returning Vaccination Record (VXR). Trigger event type V04 will 

initiate the Unsolicited Update to Vaccination Record (VXU) message. Addition of new patients can be 

accomplished by using either VXU (V04) or ADT (A28). The interaction model at the end of this section 

graphically depicts this process. 

============================================================================== 

============================================================================== 

A5-1 
 

 

 

 

 

 

 

 

 

 

 

Revised, Added or Deleted Text (version 2.2, June 2006) Page 52 

(Bold Italics indicate added material.) 

Summary 

Emphasizes effective date matching an immunization date. 

Example: 

PV1||R||||||||||||||||||V02^19900607~H02^19900607|<CR> 

This PV1 segment shows that the patient is a recurring patient who is VFC eligible and is a Medicaid patient. 

The effective date of his VFC and Medicaid status is June 7, 1990. 

Since a single VFC effective date is being submitted, this status should only be applied to the immunizations 

given on June 7, 1990. The eligibility status for the other immunization dates is unknown. 

Every effort should be made to associate an effective date with a corresponding immunization date. 

For instance, since the only status submitted in the sample PV1 segment has a date of June 7, 1990, 

no information about the eligibility status of the other incoming immunizations should be inferred 

from this message. It is also possible that a VFC status and date may be sent that was not related to 

an immunization event: the status may not be applicable to any immunizations in the message. 

======================================================================= 

Previous Text (version 2.1, September 2002) Page 52 

Example: 

PV1||R||||||||||||||||||V02^19900607~H02^19900607|<CR> 

This PV1 segment shows that the patient is a recurring patient who is VFC eligible and is a Medicaid patient. 

The effective date of his VFC and Medicaid status is June 7, 1990. 

=======================================================================
 

=======================================================================
 

Revised, Added or Deleted Text (version 2.2, June 2006) Page 75.1
 

(All material on this page is added: thus, no extra bolding and italics are used.)
 

Summary 

(For combination vaccine Vaccine Information Statements (VIS), the first example demonstrates use of the 

Observation sub-ID to indicate separate VIS for each component antigen. The second example 

demonstrates use of the Observation sub-ID with the 'Dose Number in Series' for a combination vaccine, and 

contrasts this with previous use of separate LOINC codes for dose count.) 

) 

======================================================================== 

Some information about combination vaccines (vaccines that contain multiple component antigens) can be 

specific to an individual vaccine component. For example, there can be separate VIS statements for each 

vaccine component. In the example below the combination vaccine has two component vaccines. The RXA 

segment describes the entire combination vaccine and does not have a value in the Observation sub-ID. 

Following the RXA, the first set of 5 OBX segments describes one vaccine component so all have the value 

“1” in the Observation sub-ID. The next set of 5 OBX segments describes another vaccine component so all 

have the value “2” in the Observation sub-ID. 

RXA|0|1|19901207|19901207|51^HepB-HIB^CVX|.5|ML^^ISO+|||1234567891^O'BRIAN
 

^ROBERT^A^^DR^MD|^^^CHILD HEALTHCARE CLINIC^^^^^101 MAIN
 

STREET^^BOSTON^MA||||W22532806|19901230|MSD^MERCK^MVX||||<CR>
 

OBX|1|CE|38890-0^COMPONENT VACCINE TYPE^LN|1|45^HEP B, NOS^CVX||||||F|<CR>
 

OBX|2|TS|38890-0&29768-9^DATE VACCINE INFORMATION STATEMENT
 

PUBLISHED^LN|1|20010711||||||F|<CR>
 

OBX|3|TS|38890-0&29769-7^DATE VACCINE INFORMATION STATEMENT
 

PRESENTED^LN|1|19901207||||||F|<CR>
 

OBX|4|ST|38890-0&30973-2^Dose number in series^LN|1|3||||||F|<CR>
 

OBX|5|ST|38890-0&30959-1^LOT^LN|1|MY85542||||||F|<CR>
 

A5-2 
 

 

 

 

 

 

 

 

 

OBX|6|CE|38890-0^COMPONENT VACCINE TYPE^LN|2|17^HIB,NOS^CVX||||||F|<CR>
 

OBX|7|TS|38890-0&29768-9^DATE VACCINE INFORMATION STATEMENT
 

PUBLISHED^LN|2|19981216||||||F|<CR>
 

OBX|8|TS|38890-0&29769-7^DATE VACCINE INFORMATION STATEMENT
 

PRESENTED^LN|2|19901207||||||F|<CR>
 

OBX|9|ST|38890-0&30973-2^Dose number in series^LN|2|1||||||F|<CR>
 

OBX|10|ST|38890-0&30959-1^LOT^LN|2|WP95441||||||F|<CR>
 

The following is a simplified example that illustrates specifically how “Dose number in series” should be 

portrayed for a combination vaccine using the Observation sub-ID to group the OBX segments for each 

component vaccine type. Note the use of LOINC® codes 38890-0&30973-2 for every component vaccine 

dose number in series. This is preferred over the previous method for portraying “dose count in combination

vaccine” which used a different LOINC® code for each component vaccine and which lacked a code for the 

dose count for the Polio vaccine component of a combination vaccine. 

RXA|0|1|19901207|19901207|110^DTAP/Polio/Hep B^CVX|.5|ML^^ISO+|||1234567891^O'BRIAN 

^ROBERT^A^^DR^MD|^^^CHILD HEALTHCARE CLINIC^^^^^101 MAIN 

STREET^^BOSTON^MA||||AC21A016AA|19901230|SKB^SKB^MVX||||<CR> 

OBX|1|CE|38890-0^COMPONENT VACCINE TYPE^LN|1|107^DTAP, NOS^CVX||||||F|<CR> 

OBX|2|ST|38890-0&30973-2^Dose number in series^LN|1|2||||||F|<CR> 

OBX|3|CE|38890-0^COMPONENT VACCINE TYPE^LN|2|89^Polio, NOS^CVX||||||F|<CR> 

OBX|4|ST|38890-0&30973-2^Dose number in series^LN|2|2||||||F|<CR> 

OBX|5|CE|38890-0^COMPONENT VACCINE TYPE^LN|3|45^HEP B, NOS^CVX||||||F|<CR> 

OBX|6|ST|38890-0&30973-2^Dose number in series^LN|3|3||||||F|<CR> 

(continues on next page) 

======================================================================== 

======================================================================== 

Revised, Added or Deleted Text (version 2.2, June 2006) Page 80 

(Bold Italics indicate added material.) 

3.2 PATIENT ADMINISTRATION MESSAGE DEFINITIONS 

Use of the Optional Admission/Discharge, Transfer (ADT) Segments 

The HL7 standard defines many specialized ADT messages for administrative events dealing with patients; 

e.g., admit, discharge, transfer, merge record. The VXU message can be used for adding a person or 

additional information about the person, so ADT messages are not necessary for registries to 

communicate with each other. However, intercommunicating private providers and immunization 

registries may decide to use the ADT message when there is no immunization information, especially 

when the communicating partner already has implemented the ADT but not the VXU. The challenge 

for registries becomes to identify which ADT messages to use. There are 51 different ADT messages 

distinguished from each other by 51 different trigger event codes. 

At this writing, the set of ADT messages most likely to be needed by registries is not yet fully 

bounded. Registries are accepting the messages sent by their communicating partners. Registries 

may receive extra messages that they are not interested in, in which case it will need to handle them 

appropriately. 

2.3.1 ADT messages currently identified and accepted by registries include (by event code):
 

A01 (admit/visit notification)
 

A04 (register a patient)
 

A05 (pre-admit a patient)
 

A08 (update patient information)
 

A18 (merge patient information)
 

A28 (add person information)
 

A31 (update person information)
 

A47 (change patient identifier list)
 

As registry experience with ADT grows, this section of this document will be further refined.
 

=============================================================================== 

A5-3 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Previous Text (version 2.1, September 2002) Page 80 

(Strike-through indicates material deleted from newer version above) 

3.2 PATIENT ADMINISTRATION MESSAGE DEFINITIONS 

Use of the Optional Admission/Discharge, Transfer (ADT) Segments 

Note: The HL7 standard defines many specialized ADT messages for administrative events dealing with patients; e.g., 

admit, discharge, transfer, merge record. The ADT messages are distinguished from each other by the trigger event 

code. Some ADT messages are for use with admitted patients only. These include event code A01 (admit/visit 

notification), A08 (update patient information), A18 (merge patient information), and A23 (delete a patient record). We 

will not define those in this document, because their utility to immunization registries is limited. Even though the 

segments and fields are identical, the A28, A29, and A31 events are not duplicate messages, because they are not 

intended to be used for notification of admitted patient events. 

The VXU message can be used for adding a person or additional information about the person, so ADT messages are 

not necessary for registries to communicate with each other. However, intercommunicating private providers and 

immunization registries may decide to use the ADT/A28 message to add or update person data from a different data 

system to a registry or vice versa. The data would be kept in both places. The purpose of the ADT A28, A29, A30, and 

A31 messages is to allow sites with multiple systems and respective master patient databases to communicate activity 

related to a person regardless of whether that person is currently a patient on each system. Each system has an interest 

in the database activity of the others in order to maintain data integrity across an institution. Though they are defined 

within the ADT message set, these messages differ in that they are not patient-specific. To a certain registry, the person 

may be a person of interest, a potential future patient, a parent or guardian, or a potential guarantor. For example, these 

events can be used to maintain an MPI (master patient index), a cancer or immunization registry, members of a 

managed care plan, an HIV database, etc. Visit information may be included but is not required. These events are 

primarily for demographic data, but optional historical non-demographic data may be sent as well. 

The A28 event can be used to send all known demographics about a person. An A28 (add person information) or A31 

(update person information) can also be used for back loading MPI information for the person, or for back loading all 

personal and historical information from one system to another. In addition to adding (A28) a person to a database, the 

delete (A29), update (A31), and merge (A30) messages work in a similar manner to maintain concurrent person 

information. It is left up to site-specific negotiations to decide how much data must be transmitted or re-transmitted when 

a person becomes a patient. For immunization registries, only items listed in the CDC core data set should be required 

for entry to a registry. These items can be found at <www.cdc.gov/nip/registry>. 

Note that all segments are optional except the MSH, EVN, and PID. The segments that are useful for immunization 

registries have been defined above, except for the EVN and MRG segments, which are described below. The syntax for 

the ADT^A28 and ADT^A31 are identical. These messages are distinguished by the second component of MSH-9-

Message type, a CM data type formatted as <message type (ID)>^<trigger event (ID)>^<message structure (ID)>. 

=============================================================================== 

=============================================================================== 

Revised, Added or Deleted Text (version 2.2, June 2006) 

Other material revised, added, or deleted in this version is detailed in the corresponding Appendix and 

appropriate Table. Therefore, it is not repeated here. 

A1-12 to 

A1-17 HL7-defined Tables 0227 & 0292 - Current MVX & CVX code tables replace older versions 

A1-24 to 

A1-27 

NIP defined Table NIP003 - Observation Identifiers: Dose Number for Combination Vaccines & 

Vaccine Component (of a combination vaccine) clarification & observation examples furnished 

A1-26 to A1-27 

NIP defined Table NIP003 - Observation Identifiers: Examples furnished for Vaccines Due Next & 

VAERS ORU Message; new LOINC for sibling replacing separate LOINCs for brother and sister for 

VAERS ORU Message 

A5-4 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

C 

INDEX 

A 

Acknowledgment Messages .......................................................................................................................18
 

Admission/Discharge/Transfer and Acknowledgment (ADT/ACK) .............................................................81
 

Add person information..................................................................................................................81
 

Delete person information..............................................................................................................81
 

Merge person information ..............................................................................................................82
 

Update person information.............................................................................................................82
 

Adverse events ...........................................................................................................3, 13, 14, 15, 70, 75, 2
 

Allergy ........................................................................................................................................... 70, A1 - 22
 

B 

Basic Message Construction Rules .............................................................................................................. 2
 

Batch Header (BHS) Segment....................................................................................................................37
 

BHS Attributes................................................................................................................................37
 

BHS field definitions .......................................................................................................................37
 

Batch Trailer (BTS) Segment......................................................................................................................38
 

BTS Attributes ................................................................................................................................38
 

BTS field definitions .......................................................................................................................38
 

Code Tables.......................................................................................................................................... A1 - 1
 

Abnormal flags ......................................................................................................................... A1 - 4
 

Accept/Application acknowledgment conditions ...................................................................... A1 - 6
 

Acknowledgment code............................................................................................................. A1 - 2
 

Action code ............................................................................................................................ A1 - 15
 

Address type ............................................................................................................................ A1 - 7
 

Administrative site .................................................................................................................... A1 - 6
 

Alternate character set handling scheme............................................................................... A1 - 16
 

Alternate character sets ........................................................................................................... A1 - 9
 

Census tract ........................................................................................................................... A1 - 11
 

Check digit scheme.................................................................................................................. A1 - 2
 

CN ID source.......................................................................................................................... A1 - 15
 

Codes for vaccines administered (code = CVX) .................................................................... A1 - 11
 

Coding System....................................................................................................................... A1 - 17
 

Completion status .................................................................................................................. A1 - 15
 

Contact reason....................................................................................................................... A1 - 10
 

Contraindications, Precautions, and Immunities.................................................................... A1 - 22
 

County/parish ......................................................................................................................... A1 - 11
 

Deferred response type............................................................................................................ A1 - 5
 

Degree.................................................................................................................................... A1 - 17
 

Delayed acknowledgment type ................................................................................................ A1 - 4
 

Ethnic Group ............................................................................................................................ A1 - 7
 

Event consequence................................................................................................................ A1 - 24
 

Event reason ............................................................................................................................ A1 - 2
 

Event type ................................................................................................................................ A1 - 1
 

Financial class.......................................................................................................................... A1 - 3
 

Identifier type............................................................................................................................ A1 - 8
 

Immunization information source ........................................................................................... A1 - 19
 

Immunization registry status .................................................................................................. A1 - 18
 

Language ............................................................................................................................... A1 - 14
 

Living arrangement ................................................................................................................ A1 - 10
 

Manufacturers of vaccines (code = MVX).............................................................................. A1 - 10
 

Message error status codes................................................................................................... A1 - 16
 

Message structure.................................................................................................................. A1 - 15
 

Message type........................................................................................................................... A1 - 4
 

Index - 1 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Name type................................................................................................................................ A1 - 7
 

Name/address representation................................................................................................ A1 - 19
 

Namespace ID ....................................................................................................................... A1 - 15
 

Nationality ................................................................................................................................ A1 - 9
 

Observation identifiers ........................................................................................................... A1 - 19
 

Observation result status codes interpretation ........................................................................ A1 - 4
 

Operator ID .............................................................................................................................. A1 - 6
 

Order Control Codes ................................................................................................................ A1 - 5
 

Organizational name type ........................................................................................................ A1 - 9
 

Patient class............................................................................................................................. A1 - 1
 

Physician ID ............................................................................................................................. A1 - 2
 

Processing ID........................................................................................................................... A1 - 5
 

Processing mode ..................................................................................................................... A1 - 9
 

Publicity code ........................................................................................................................... A1 - 9
 

Quantity limited request ........................................................................................................... A1 - 5
 

Query priority............................................................................................................................. A1 -4
 

Query response status .............................................................................................................. A1- 9
 

Query results level ................................................................................................................... A1 - 5
 

Query/Response format code .................................................................................................. A1 - 5
 

Race.......................................................................................................................................... A1 -1
 

Relationship ............................................................................................................................. A1 - 2
 

Report type............................................................................................................................. A1 - 24
 

Reported adverse event previously ....................................................................................... A1 - 24
 

Route of administration ............................................................................................................ A1 - 6
 

Sex ........................................................................................................................................... A1 - 1
 

Source of comment .................................................................................................................. A1 - 5
 

Substance refusal reason ...................................................................................................... A1 - 19
 

Telecommunication equipment type ........................................................................................ A1 - 7
 

Telecommunication use code .................................................................................................. A1 - 7
 

Universal ID type.................................................................................................................... A1 - 15
 

Vaccinated at location ............................................................................................................ A1 - 24
 

Vaccine purchased with ......................................................................................................... A1 - 24
 

Version ID ................................................................................................................................ A1 - 5
 

What subject filter..................................................................................................................... A1 - 2
 

Yes/No indicator....................................................................................................................... A1 - 6
 

Combination vaccines .................................................................................................................................70
 

Common Order (ORC) Segment ................................................................................................................59
 

ORC Attributes ...............................................................................................................................59
 

ORC field definitions ......................................................................................................................59
 

Order control ..................................................................................................................................59
 

Ordering facility address ................................................................................................................60
 

Ordering facility name ....................................................................................................................60
 

Ordering facility phone number......................................................................................................60
 

Ordering provider ...........................................................................................................................59
 

Ordering provider address .............................................................................................................60
 

Confidentiality ................................................................................................................................................ 6
 

Consent .................................................................................................................................................28, 49
 

Contraindication ...........................................................................................69, 70, A1 - 19, A1 - 22, A1 - 23
 

Core data..................................................................................................................11, 55, 80, A3 - 1, A3 - 2
 

CPT codes................................................................................................................................. 64, 65, A2 - 1
 

Current Procedural Terminology (CPT) ......................................................................................................64
 

CVX codes ...................................................................................................................................... 64, A2 - 1
 

D 

Data Types ............................................................................................................................................ A2 - 1
 

Coded Element with Formatted Vaules (CE)........................................................................... A2 - 1
 

Coded Value for HL7 - Defined Tables (ID)............................................................................. A2 - 3
 

Coded Value for User - Defined Tables (IS) ............................................................................ A2 - 3
 

Composite (CM) ....................................................................................................................... A2 - 1
 

Index - 2 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Composite ID with Check Digit (CK) ........................................................................................ A2 - 1
 

Composite Price (CP) .............................................................................................................. A2 - 1
 

Composite Quantity with Units (CQ) ........................................................................................ A2 - 1
 

Date (DT) ................................................................................................................................. A2 - 2
 

Driver's License Number (DLN) ............................................................................................... A2 - 2
 

Entity Identifier (EI)................................................................................................................... A2 - 2
 

Extended Address (XAD)......................................................................................................... A2 - 4
 

Extended Composite ID Number and Name for Persons (XCN) ............................................. A2 - 4
 

Extended Composite ID with Check digits (CX) ...................................................................... A2 - 1
 

Extended Composite Name and Identification Number for Organizations (XON) ................... A2 - 5
 

Extended Person Name (XPN) ................................................................................................ A2 - 5
 

Extended Telecommunication Number (XTN) ......................................................................... A2 - 5
 

Financial Class (FC)................................................................................................................. A2 - 2
 

Formatted Text Data (FT) ........................................................................................................ A2 - 2
 

Hierarchic Designator (HD)...................................................................................................... A2 - 2
 

Job/Code/Class (JCC) ............................................................................................................. A2 - 3
 

Money (MO) ............................................................................................................................. A2 - 3
 

Numeric (NM)........................................................................................................................... A2 - 3
 

Person Location (PL) ............................................................................................................... A2 - 3
 

Person Name (PN)................................................................................................................... A2 - 3
 

Processing Type (PT) .............................................................................................................. A2 - 3
 

Sequence ID (SI)...................................................................................................................... A2 - 3
 

String Data (ST) ....................................................................................................................... A2 - 3
 

Text Data (TX).......................................................................................................................... A2 - 4
 

Time Stamp (TS)...................................................................................................................... A2 - 4
 

Timing Quantity (TQ)................................................................................................................ A2 - 4
 

Version Identifier (VID)............................................................................................................. A2 - 4
 

Delimiters ...................................................................................................................................................... 1
 

Dose Number for Combination Vaccines............................................................................................ A1 - 19
 

E 

Encoding Rules for Receiving....................................................................................................................... 2
 

Encoding Rules for Sending.......................................................................................................................... 2
 

Error (ERR) Segment..................................................................................................................................27
 

ERR Attributes ...............................................................................................................................27
 

ERR field definitions.......................................................................................................................27
 

Error code and location ..................................................................................................................27
 

Event Type (EVN) Segment........................................................................................................................82
 

Date/time planned event ................................................................................................................82
 

Event occurred ...............................................................................................................................83
 

Event reason code .........................................................................................................................83
 

Event type code .............................................................................................................................82
 

EVN Attributes................................................................................................................................82
 

EVN field definitions .......................................................................................................................82
 

Operator ID ....................................................................................................................................83
 

Recorded date/time........................................................................................................................82
 

F 

File Header (FHS) Segment........................................................................................................................35
 

FHS Attributes................................................................................................................................35
 

FHS field definitions .......................................................................................................................36
 

File Trailer (FTS) Segment..........................................................................................................................36
 

FTS Attributes ................................................................................................................................36
 

FTS field definitions........................................................................................................................36
 

Financial Management Message Segments...............................................................................................58
 

Index - 3 
 

 

G 

General Acknowledgment (ACK) ................................................................................................................18
 

H 

HL7 Batch Protocol .....................................................................................................................................35
 

File/Batch Header (BHS) and Trailer (BTS) Segments .................................................................35
 

HL7 Definitions
 

Component....................................................................................................................................... 1
 

Data type.......................................................................................................................................... 1
 

Delimiters ......................................................................................................................................... 1
 

Field.................................................................................................................................................. 1
 

Item number..................................................................................................................................... 1
 

Message syntax ............................................................................................................................... 1
 

Null and empty fields........................................................................................................................ 1
 

Segment........................................................................................................................................... 1
 

Z segments ...................................................................................................................................... 1
 

I
 

Immunization Data Transaction Messages................................................................................................... 3
 

Insurance (IN1) Segment............................................................................................................................58
 

Insurance Additional Information (IN2) Segment........................................................................................58
 

Insurance Additional Information, Certification (IN3) Segment...................................................................58
 

L 

LOINC®........................................................................ 15, 16, 70, 72, 75, A1 - 19, A1 - 20, A1 - 21, A1 - 22
 

M 

Merge Patient Information (MRG) Segment ...............................................................................................84
 

MRG Attributes...............................................................................................................................84
 

MRG field definitions ......................................................................................................................84
 

Prior alternate patient ID ................................................................................................................84
 

Prior alternate visit number ............................................................................................................85
 

Prior patient account number.........................................................................................................84
 

Prior patient ID ...............................................................................................................................84
 

Prior patient identifier list................................................................................................................84
 

Prior patient name..........................................................................................................................85
 

Prior visit number ...........................................................................................................................85
 

Message........................................................................................................................................................ 1
 

Message Acknowledgment (MSA) Segment ..............................................................................................25
 

Error condition................................................................................................................................26
 

Message control ID ........................................................................................................................25
 

MSA Attributes ...............................................................................................................................25
 

MSA Field definitions .....................................................................................................................25
 

Message Control Segments........................................................................................................................20
 

Message Header (MSH) Segment..............................................................................................................20
 

Message control ID ........................................................................................................................22
 

Message type.................................................................................................................................22
 

MSH Attributes ...............................................................................................................................20
 

MSH field definitions ......................................................................................................................20
 

Version ID ......................................................................................................................................23
 

N 

Next of Kin (NK1)/Associated Parties Segment..........................................................................................54
 

Address ..........................................................................................................................................56
 

Business phone number ................................................................................................................56
 

Contact reason...............................................................................................................................57
 

Date/time of birth............................................................................................................................56
 

Index - 4 
 

 

 

Name..............................................................................................................................................55
 

Next of kin/associated party's identifiers........................................................................................57
 

NK1 Attributes ................................................................................................................................54
 

NK1 field definitions .......................................................................................................................55
 

Phone number................................................................................................................................56
 

Relationship ...................................................................................................................................55
 

Set ID - NK1 ...................................................................................................................................55
 

Notes and Comments (NTE) Segment .......................................................................................................79
 

Comment........................................................................................................................................79
 

Comment type................................................................................................................................79
 

NTE Attributes................................................................................................................................79
 

NTE field definitions .......................................................................................................................79
 

Set ID - NTE...................................................................................................................................79
 

Source of comment ........................................................................................................................79
 

Null ................................................................................................................................................................ 1
 

O 

Observation identifiers 

Contraindications, Precautions, and Immunities.................................................................... A1 - 19 

Observation Reporting Segments...............................................................................................................70
 

Observation Request (OBR) Segment........................................................................................................71
 

Observation Request Segment (OBR)
 

OBR Attributes ...............................................................................................................................71
 

OBR field definitions.......................................................................................................................72
 

Observation date/time....................................................................................................................72
 

Set ID .............................................................................................................................................72
 

Universal service ID .......................................................................................................................72
 

Observation/Result (OBX) Segment ...........................................................................................................73
 

Date-time of the observation..........................................................................................................77
 

Observation identifier .....................................................................................................................74
 

Observation result status ...............................................................................................................77
 

Observation sub-ID ........................................................................................................................75
 

Observation value ..........................................................................................................................75
 

OBX Attributes ...............................................................................................................................73
 

OBX field definitions.......................................................................................................................73
 

Set ID - observation simple............................................................................................................73
 

Units ...............................................................................................................................................76
 

Value type ......................................................................................................................................74
 

OBX segments ............................................................................................................................................70
 

P 

Patient Additional Demographic (PD1) Segment........................................................................................47
 

Duplicate patient ............................................................................................................................48
 

Immunization registry status ..........................................................................................................49
 

Immunization registry status effective date....................................................................................50
 

Patient primary care provider name & ID no..................................................................................48
 

Patient primary facility....................................................................................................................47
 

PD1 Attributes ................................................................................................................................47
 

PD1 field definitions .......................................................................................................................47
 

Protection indicator ........................................................................................................................49
 

Protection indicator effective date..................................................................................................49
 

Publicity code .................................................................................................................................48
 

Publicity code effective date ..........................................................................................................50
 

Patient Administration Message Definitions................................................................................................80
 

Optional Admission/Discharge, Transfer (ADT) Segments ...........................................................80
 

Patient Administration Message Segments ................................................................................................39
 

Patient Identification (PID) Segment...........................................................................................................39
 

Birth order ......................................................................................................................................45
 

Birth place ......................................................................................................................................45
 

Index - 5 
 

Date of birth....................................................................................................................................41
 

Ethnic group ...................................................................................................................................44
 

Mother's identifier ...........................................................................................................................44
 

Mother's maiden name...................................................................................................................41
 

Multiple birth indicator ....................................................................................................................45
 

Patient address ..............................................................................................................................43
 

Patient alias....................................................................................................................................41
 

Patient death date and time ...........................................................................................................45
 

Patient death indicator ...................................................................................................................46
 

Patient identifier list ........................................................................................................................40
 

Patient name ..................................................................................................................................40
 

Phone number - business ..............................................................................................................43
 

Phone number - home ...................................................................................................................43
 

PID Attributes .................................................................................................................................39
 

PID field definitions ........................................................................................................................39
 

Primary language ...........................................................................................................................44
 

Race...............................................................................................................................................42
 

Set ID - PID ....................................................................................................................................40
 

Sex .................................................................................................................................................41
 

Patient Visit - Additional Information (PV2) Segment .................................................................................53
 

PV2 Attributes ................................................................................................................................53
 

PV2 field definitions........................................................................................................................53
 

Patient Visit (PV1) Segment........................................................................................................................51
 

Financial class................................................................................................................................52
 

Patient class...................................................................................................................................52
 

PV1 Attributes ................................................................................................................................51
 

PV1 field definitions........................................................................................................................52
 

Set ID - PV1 ...................................................................................................................................52
 

Pharmacy/Treatment Administration (RXA) Segment ................................................................................63
 

Action code ....................................................................................................................................69
 

Administered amount .....................................................................................................................65
 

Administered at location.................................................................................................................66
 

Administered code .........................................................................................................................64
 

Administering provider ...................................................................................................................66
 

Administration notes.......................................................................................................................65
 

Administration sub ID counter........................................................................................................63
 

Completion status ..........................................................................................................................69
 

Date/time start of administration ....................................................................................................64
 

RXA Attributes................................................................................................................................63
 

RXA field definitions .......................................................................................................................63
 

Substance expiration date .............................................................................................................67
 

Substance lot number ....................................................................................................................67
 

Substance manufacturer................................................................................................................68
 

Substance refusal reason ..............................................................................................................68
 

Pharmacy/Treatment Route (RXR) Segment .............................................................................................62
 

Route..............................................................................................................................................62
 

RXR Attributes ...............................................................................................................................62
 

RXR field definitions.......................................................................................................................62
 

Site .................................................................................................................................................62
 

Privacy........................................................................................................................................................... 6
 

Q 

Query Acknowledgment (QAK) Segment ...................................................................................................28

QAK Attributes ...............................................................................................................................28

QAK field definition.........................................................................................................................28

Query tag .......................................................................................................................................28

Query Definition (QRD) Segment ...............................................................................................................29

ORD Attributes ...............................................................................................................................29

ORD field definitions ......................................................................................................................29

Index - 6 
 

V 

Query date/time..............................................................................................................................29

Query ID.........................................................................................................................................30

What subject filter...........................................................................................................................31

Who subject filter............................................................................................................................30

Query Filter (QRF) Segment .......................................................................................................................32
 

Other query subject filter ................................................................................................................33
 

QRF Attributes ...............................................................................................................................32
 

QRF field definitions.......................................................................................................................32
 

What user qualifier .........................................................................................................................33
 

Query General Acknowledgment (QCK).....................................................................................................18

Query for Vaccination Record (VXQ)............................................................................................................ 5
 

R

Response to Vaccination Query Returning Multiple PID Matches (VXX)..................................................... 6
 

Response to Vaccination Query Returning the Vaccination Record (VXR) ................................................. 7
 

S 

Security .................................................................................................................................6, 22, 35, 37, 54
 

Segments ....................................................................................................................................................19
 

Segment Definitions .......................................................................................................................20
 

U 

Unsolicited Transmission of an Observation (ORU) ...................................................................................13
 

Unsolicited Vaccination Record Update (VXU)...........................................................................................11
 

Vaccine Adverse Event Reporting System (VAERS) ............................................................... 13, 20, A1 - 1
 

Vaccine Information Statement (VIS)..........................................................................................................70
 

Vaccines Due Next......................................................................................................................................70
 

VAERS ........................................................................................................................ 13, 20, 70, 71, A1 - 19
 

Z 

Z segments.................................................................................................................................................... 1
 

Index - 7