· web viewpage 136hl7 version 2.5.1 ig: laboratory results interface, dstu r2 – us realm....

HL7 Version 2.8.2 Implementation Guide: Immunization Messaging, Release 1.0 - US Realm

2018/11/02

© Health Level Seven International. All rights reserved. Document generated with NIST IGAMT.

Table of Contents1 INTRODUCTION.......................................................................................................................6

1.1 PURPOSE 61.2 AUDIENCE 71.3 SCOPE 8

1.3.1 IN SCOPE 81.3.2 OUT OF SCOPE8

1.4 KEY TECHNICAL DECISIONS 81.4.1 USE OF VOCABULARY STANDARDS 81.4.2 CONVENTIONS 91.4.3 KEYWORDS 91.4.4 MESSAGE ACKNOWLEDGEMENT 101.4.5 USAGE CONFORMANCE TESTING RECOMMENDATIONS 111.4.6 OTHER DECISIONS 13

2 USE CASES........................................................................................................................ 142.1 ACTORS 142.2 GENERAL ASSUMPTIONS 15

2.2.1 ASSUMPTIONS 152.2.2 PRE-CONDITIONS 162.2.3 POST-CONDITIONS 162.2.4 ERRORS AND ACKNOWLEDGEMENTS 162.2.5 OBSERVATIONS18

2.3 USE CASE 1-SEND IMMUNIZATION EVENT 242.3.1 CONTEXT 242.3.2 USER STORY 252.3.3 INTERACTION DEFINITION 252.3.4 DYNAMIC DEFINTION 262.3.5 SCENARIOS 272.3.6 MESSAGING CAPABILITIES 282.3.7 SAMPLE MESSAGES 37

2.4 USE CASE 2-SEND DEMOGRAPHICS DATA ONLY 442.4.1 CONTEXT 442.4.2 USER STORY 442.4.3 INTERACTION DEFINITION 442.4.4 DYNAMIC DEFINTION 452.4.5 SCENARIOS 462.4.6 MESSAGING CAPABILITIES 472.4.7 SAMPLE MESSAGES 48

2.5 USE CASE 3-REQUEST HISTORY WITH FORECAST 492.5.1 CONTEXT 492.5.2 USER STORY 512.5.3 INTERACTION DEFINITION 512.5.4 DYNAMIC DEFINTION 522.5.5 SCENARIOS 542.5.6 MESSAGING CAPABILITIES 592.5.7 SAMPLE MESSAGES 62

3 MESSAGE INFRASTRUCTURE....................................................................................................683.1 CONFORMANCE PROFILES 68

3.1.1 VXU^V04^VXU_V04 - IZ22R1.0 - SEND AN UNSOLICITED IMMUNIZATION EVENT 693.1.2 ACK^VARIESÂCK - IZ23R1.0 - RESPOND WITH A GENERAL ACKNOWLEDGEMENT 963.1.3 ADTÂ31ÂDT_A05 - IZ24R1.0 - SEND DEMOGRAPHICS ONLY 1013.1.4 QBP^Q11^QBP_Q11 - IZ54R1.0 - REQUEST AN IMMUNIZATION HISTORY WITH FORECAST 1183.1.5 RSP^K11^RSP_K11 - IZ52R1.0 - RESPOND WITH AN IMMUNIZATION HISTORY WITH FORECAST 1243.1.6 RSP^K11^RSP_K11 - Z31R1.0 - RESPOND WITH A LIST OF CANDIDATES 1553.1.7 RSP^K11^RSP_K11 - IZ33R1.0 - RESPOND WITH A NO PERSON FOUND MESSAGE 164

3.2 DATATYPES 170


3.2.1 CQ_IZ01 - COMPOSITE QUANTITY WITH UNITS 1713.2.2 CWE_IZ01 - CODED WITH EXCEPTIONS 1713.2.3 CWE_IZ02 - CODED WITH EXCEPTIONS 1723.2.4 CX_IZ01 - EXTENDED COMPOSITE ID WITH CHECK DIGIT 1733.2.5 DT_IZ01 - DATE 1743.2.6 DTM_IZ01 - DATE/TIME 1743.2.7 DTM_IZ02 - DATE/TIME 1753.2.8 DTM_IZ03 - DATE/TIME 1753.2.9 EI_IZ01 - ENTITY IDENTIFIER 1763.2.10 EI_IZ02 - ENTITY IDENTIFIER 1773.2.11 ERL_IZ01 - ERROR LOCATION 1773.2.12 FN_IZ01 - FAMILY NAME 1783.2.13 HD_IZ01 - HIERARCHIC DESIGNATOR 1783.2.14 ID_IZ01 - CODED VALUE FOR HL7 DEFINED TABLES 1793.2.15 IS_IZ01 - CODED VALUE FOR USER-DEFINED TABLES 1793.2.16 MSG_IZ01 - MESSAGE TYPE 1793.2.17 NM_IZ01 - NUMERIC 1803.2.18 OG_IZ01 - OBSERVATION GROUPER 1803.2.19 PL_IZ01 - PERSON LOCATION 1803.2.20 PT_IZ01 - PROCESSING TYPE 1813.2.21 SAD_IZ01 - STREET ADDRESS 1813.2.22 SI_IZ01 - SEQUENCE ID 1813.2.23 SNM_IZ01 - STRING OF TELEPHONE NUMBER DIGITS 1813.2.24 ST_IZ01 - STRING DATA 1823.2.25 TX_IZ01 - TEXT DATA 1823.2.26 VID_IZ01 - VERSION IDENTIFIER 1823.2.27 XAD_IZ01 - EXTENDED ADDRESS 1823.2.28 XCN_IZ01 - EXTENDED COMPOSITE ID NUMBER AND NAME FOR PERSONS 1833.2.29 XON_IZ01 - EXTENDED COMPOSITE NAME AND IDENTIFICATION NUMBER FOR ORGANIZATIONS 1853.2.30 XPN_IZ01 - EXTENDED PERSON NAME 1853.2.31 XPN_IZ02 - EXTENDED PERSON NAME 1863.2.32 XTN_IZ01 - EXTENDED TELECOMMUNICATION NUMBER 187

3.3 VALUE SETS 1883.3.1 0001_01 - ADMINISTRATIVE SEX 1893.3.2 0003_01 - EVENT TYPE 1903.3.3 0004_01 - PATIENT CLASS 1903.3.4 0008_01 - ACKNOWLEDGMENT CODE 1903.3.5 0063_01 - RELATIONSHIP 1913.3.6 0064_01 - PATIENT ELIGIBILITY 1923.3.7 0072_01 - INSURANCE PLAN ID 1923.3.8 0076_01 - MESSAGE TYPE 1933.3.9 0086_01 - PLAN ID 1933.3.10 0103_01 - PROCESSING ID 1933.3.11 0125_01 - VALUE TYPE 1943.3.12 0126_01 - QUANTITY LIMITED REQUEST 1943.3.13 0136_01 - YES/NO INDICATOR 1943.3.14 0163_01 - BODY SITE 1953.3.15 0190_01 - ADDRESS TYPE 1953.3.16 0200_01 - NAME TYPE (PATIENT NAME) 1963.3.17 0200_02 - NAME TYPE (PROVIDER NAME) 1973.3.18 0201_01 - TELECOMMUNICATION USE CODE 1983.3.19 0202_01 - TELECOMMUNICATION EQUIPMENT TYPE 1983.3.20 0203_01 - IDENTIFIER TYPE (PATIENT) 1993.3.21 0203_02 - IDENTIFIER TYPE (ORGANIZATION) 2003.3.22 0203_03 - IDENTIFIER TYPE (PROVIDER) 2003.3.23 0206_01 - SEGMENT ACTION CODE 2013.3.24 0208_01 - QUERY RESPONSE STATUS 201


3.3.25 0215_01 - PUBLICITY CODE 2023.3.26 0322_01 - COMPLETION STATUS 2023.3.27 0354_01 - MESSAGE STRUCTURE 2023.3.28 0357_01 - MESSAGE ERROR CONDITION CODES 2033.3.29 0361_01 - APPLICATION 2043.3.30 0362_01 - FACILITY 2043.3.31 0363_01 - ASSIGNING AUTHORITY 2043.3.32 0396_01 - CODING SYSTEM 2043.3.33 0399_01 - COUNTRY CODE 2053.3.34 0441_01 - IMMUNIZATION REGISTRY STATUS 2053.3.35 0516_01 - ERROR SEVERITY 2063.3.36 0532_01 - EXPANDED YES/NO INDICATOR 2063.3.37 0533_01 - APPLICATION ERROR CODE 2073.3.38 CDCREC_01 - RACE 2123.3.39 CDCREC_02 - ETHNICITY 2123.3.40 CVX_01 - VACCINES ADMINISTERED (CVX) 2133.3.41 CVX_02 - VIS VACCINE TYPES (CVX) 2193.3.42 CVX_03 - EVALUATION AND FORECAST TYPES (CVX) 2213.3.43 MVX_01 - MANUFACTURER 2223.3.44 NCIT_01 - ROUTE OF ADMINISTRATION 2253.3.45 NIP001_01 - IMMUNIZATION INFORMATION SOURCE 2253.3.46 NIP002_01 - SUBSTANCE REFUSAL REASON 2263.3.47 NIP003_01 - OBSERVATION IDENTIFIER LIST FOR PATIENT OBSERVATIONS 2273.3.48 NIP003_02 - OBSERVATION IDENTIFIER LIST FOR THE IZ22 PROFILE 2283.3.49 NIP003_03 - OBSERVATION IDENTIFIER LIST FOR THE IZ52 PROFILE 2283.3.50 PATIENTCONDITION - GENERAL CONDITIONS FOR A PATIENT 2293.3.51 PHVS_EVALUATIONSTATUSREASON_IIS - REASON FOR THE ASSIGNED DOSE VALIDITY 2303.3.52 PHVS_HISTORYOFDISEASE_IIS - HISTORY OF DISEASE 2313.3.53 PHVS_IMMUNIZATIONFUNDINGSOURCE_IIS - IMMUNIZATION FUNDING SOURCE 2323.3.54 PHVS_IMMUNIZATIONPROFILEID_IIS - IMMUNIZATION PROFILE IDENTIFIERS 2323.3.55 PHVS_IMMUNIZATIONSCHEDULEIDENTIFIER_IIS - IMMUNIZATION SCHEDULE IDENTIFIERS 2333.3.56 PHVS_SERIESSTATUS_IIS - STATUS OF A PATIENT WITHIN AN IMMUNIZATION SERIES 2333.3.57 PHVS_SEROLOGICALEVIDENCEOFIMMUNITY_IIS - SEROLOGICAL EVIDENCE OF IMMUNITY 2343.3.58 PHVS_VACCINATIONCONTRAINDICATION_IIS - VACCINE CONTRAINDICATIONS 2343.3.59 PHVS_VACCINATIONREACTION_IIS - VACCINATION REACTION 2363.3.60 PHVS_VACCINATIONSPECIALINDICATIONS_IIS - VACCINATION SPECIAL INDICATIONS 2363.3.61 PHVS_VISBARCODES_IIS - VIS FULLY-ENCODED TEXT STRING 2373.3.62 PHVS_VISVACCINES_IIS - VIS VACCINES 2403.3.63 UCUM_01 - UNITS 2423.3.64 USPS_STATE - 2 CHARACTER STATE CODES AS PER THE USPS 242


Table of TablesTABLE 2-1 MESSAGING GOALS AND RESPONSIBILITIES FOR IIS AND EHR-S..........................................................14TABLE 2-2 SEVERITY VALUES AND EXPECTATIONS..............................................................................................17TABLE 2-3 IMMUNIZATION MESSAGE CONTEXTS..................................................................................................18TABLE 2-4 OBSERVATION CONTEXT AND GROUPS...............................................................................................19TABLE 2-5 SAMPLE ELIGIBILITY OUTCOMES.........................................................................................................33TABLE 2-6 RESPONSE TO DIFFERENT OUTCOMES...............................................................................................50TABLE 2-7 SUMMARY OF ACKNOWLEDGEMENT CODE BY ERROR CONDITION........................................................56TABLE 2-8 SUMMARY OF PROFILE AND QUERY RESPONSE STATUS BY QUERY OUTCOME.....................................56TABLE 2-9 FORECAST DATE TYPES....................................................................................................................61

Table of FiguresFIGURE 2-1 SEND IMMUNIZATION EVENT SEQUENCE DIAGRAM............................................................................26FIGURE 2-2 SEND VXU ACTIVITY DIAGRAM.........................................................................................................27FIGURE 2-3 DELETING AN IMMUNIZATION RECORD SEQUENCE DIAGRAM..............................................................30FIGURE 2-4 ELIGIBILITY STATUS DETERMINATION................................................................................................33FIGURE 2-5 SEND DEMOGRAPHIC DATA ONLY SEQUENCE DIAGRAM....................................................................45FIGURE 2-6 SEND DEMOGRAPHICS ONLY MESSAGE ACTIVITY DIAGRAM...............................................................46FIGURE 2-7 REQUEST EVALUATED HISTORY AND FORECAST SEQUENCE DIAGRAM (SINGLE MATCH FOUND)..........52FIGURE 2-8 REQUEST HISTORY WITH FORECAST ACTIVITY DIAGRAM....................................................................53FIGURE 2-9 PROCESS QUERY ACTIVITY DIAGRAM...............................................................................................54


1 INTRODUCTION

The reduction of vaccine-preventable diseases is a major goal of clinical care providers and the Public Health community. The exchange of data between systems that operate at the point of clinical care, including Electronic Health Record systems (EHR-S) and systems which consolidate immunization data is critical to achieving this goal. Immunization information systems (IIS) are defined by the Centers for Disease Control and Prevention (CDC) as confidential, population-based, computerized databases that record all immunization doses administered by participating providers to persons residing within a given geopolitical area. IIS receive and share data on individuals with a number of other systems, including EHR-S and other IIS. This implementation guide documents the electronic data exchange requirements for a number of use cases within the immunization workspace in the US Realm.

Health Level Seven (HL7) is an internationally recognized standard for electronic data exchange between systems housing health care data. The HL7 standard is a key factor that supports the two-way exchange of information because it defines a syntax or grammar for formulating the messages that carry this information. It further describes a standard vocabulary that is used in these messages. It does not depend on specific software, that is, it is platform independent.

Note that the individual who is the recipient of an immunization or who is the subject of an immunization history query can be known by many labels. This includes "client", a term typically used by public health organizations, and "patient", a term common among EHR systems and provider organizations. For the sake of consistency, this document will use the term "patient" when referring to this individual.

1.1 Purpose This document represents the collaborative effort of the immunization community to improve inter-system communication of immunization related data. It is based on HL7 version 2.8.2 (v2.8.2), as published by the HL7 organization (www.hl7.org). The content of this document is largely based on Release 1.5 of the Implementation Guide for Immunization Messaging published by the American Immunization Registry Association (AIRA) and CDC. Release 1.5 is the latest in a series of implementation guides, the first of which was balloted through HL7 as a "for comment" document. Changes have been made to account for the move from version 2.5.1 to version 2.8.2, and to apply lessons learned from the implementation of Release 1.5 but otherwise much of the content of this document is directly based on the Release 1.5 workflows and specifications.

This document outlines how to generate and populate HL7 v2.8.2 messages used to fulfill the data exchange use cases described within. It defines message profiles which are used as the basis for building and consuming individual messages exchanged by interoperable systems. Message profiles are combined to define exchanges which will support the major use cases. All profiles will rely on common data type definitions and value sets. The content of the messages represents the communal idea of a superset of the information required by most systems to fulfill immunization use cases. The data required is a mix of patient demographic data, immunization event clinical information, and technical data necessary to process the HL7 message. This document aims to standardize the content and format of the HL7 messages to promote interoperability and reduce the burden of data sharing. We encourage all systems implementing these standards to adhere to them to the fullest extent possible.

It is important to recognize that while compliance with these specifications guarantees a conformant HL7 message it does not imply all issues of interoperability (e.g., permission to change data, view a record, etc.) are addressed; nor does non-compliance of a given message indicate a complete lack of useful data. If a message is found to not adhere to its stated profile, that simply means the message is not conformant to the profile.


Whether or not that is grounds for rejection of the message is a business decision that each receiving system will need to make. If the message still contains the information necessary to meet local business needs, the message need not be rejected for conformance issues alone. There may be many reasons why a sending system may not have sufficient data to send a fully conformant message, including the need to message legacy data before standards were widely adopted or data originating from systems not claiming conformance with standards. As long as key data elements such as vaccine type, administration date and a link to a patient are available, it is permissible to send the message and let the receiving system determine if it is willing to accept a non-conformant message. The sending system may still populate MSH-21 with the profile ID they are intending to meet even if the message itself is not conformant with the profile. The goal of this document is to increase the quantity and quality of messages being exchanged by trading partners, leading to more consistent and better populated messages, as well as a smooth and swift interface development process. To that end, lack of conformance to this document should not be the sole reason to withhold or reject data that could have otherwise been accepted and used.

Additionally, it is important for the system receiving a message to respond to the sending system with any errors that require resolution and/or resubmission of the data in the message. These error notifications play a key role in ensuring that complete data is exchanged between systems, and that the integrations are optimized to a state requiring a minimum of manual intervention. While many systems will share common error conditions, ultimately defining the specific errors which prevent exchanged data from being fully and accurately processed will be a function of the local processes and policies of the system consuming receiving the message.

As systems are updated to conform to the standards specified by this document, they will operationally need to continue to support current production data feeds. This will likely include accepting messages that are not yet conformant to the current standards, with the expectation that these submitters will eventually adopt the latest standards. Continuing to accept and process previous messages formats, even as systems add support for this standard, will minimize interruption in interoperability as systems work to upgrade from one release to another.

Note that the focus of this document is on the format and grammar of the messages exchanged between systems. Any activities shown within a system are intended to put the message in context and to highlight the local responsibilities for successful messaging. The functional requirements for interacting applications should be defined separately. This document attempts to reflect the common application functionality found in the immunization community.

This document has received input from the National Institute of Standards and Technology (NIST) to improve the capacity to test conformance with this specification.

1.2 Audience This document is intended for analysts and developers from systems who wish to exchange immunization data. Such systems include but are not limited to IIS and EHR-S. For all readers, this document strives for an unambiguous specification for creating and interpreting messages. Readers of this document should be familiar with the basic premises of the HL7 version 2.

It is important to note that HL7 specifies the exchange between two systems. It does not specify how any given system is implemented to accomplish the goals of messaging.

1.3 Scope This document has been created to facilitate the exchange of immunization data between different systems. While this document is intended to be applicable across a large range of systems and jurisdictions, local policies and requirements may necessitate additional constraints. One way to ensure success in such a scenario is to publish local technical documentation or profiles that accommodate the local variants and clearly


define the local business rules and processes. This documentation may further constrain this Implementation Guide but may not contradict it. It is recommended that local documentation be published in the format of a "delta" document which only highlights areas where the local requirements diverge from this Implementation Guide.

1.3.1 IN SCOPE

The following items are in scope for this document: Sending immunization events for a patient, including sending demographics and observations about

the patient and/or immunization event (this may include patient eligibility for a funding program, reactions, immunity, etc.)

Sending demographic updates for a patient Acknowledging receipt of demographics only and immunization event messages Requesting an immunization history for a patient including an evaluation of the history and a future

forecast Responding to a request for an immunization history including an evaluation of the history and a

future forecast Reporting errors in the messaging process

1.3.2 OUT OF SCOPE

The following items are out of scope for this document: Business rules, which are not implicit in HL7, applied when creating a message, including defining

events which trigger the creation of the message Business rules, which are not implicit in HL7, applied when processing a received message A standard transport layer (although the use of standard transport methods is highly recommended) Search processes used when responding to a query Business rules used to deduplicate patients or events Technical processes of inventory management Legal and governance issues regarding data access authorizations, data ownership and data use Maintenance of Master Person Index (MPI) using messages defined by Chapter 3 of the base

standard.

1.4 Key Technical Decisions This section contains a basic description of the terms and definitions, which are used in this document to understand the HL7 standard as it applies to the exchange of immunization related data. More detail may be found in the HL7 v2.8.2 standard in Chapters 1, 2 ,2A, 2B and 2C.

1.4.1 USE OF VOCABULARY STANDARDS

This document identifies specific vocabulary standards for the exchange of immunization information such as LOINC and SNOMED. Standard vocabularies support automated decision support for patient healthcare, as well as for public health surveillance of populations. Terminology is updated periodically and it is best practice to use the most current version of the coding system when allowed by the value set. In particular, support for the most recent iterations of the NDC (vaccine), CVX (vaccine), MVX (manufacturer) and VIS (vaccine information statement) codes sets is required.

1.4.2 CONVENTIONS

This document adheres to the following conventions:


This document is constructed assuming the implementer has access to v2.8.2 of the HL7 standard. Although some information from the standard is included in this document, much information from the standard has not been repeated here.

Data types have been described separately from the fields that use the data types. Because requirements for the data type often diverge from the base standard, "data type flavors" have been defined. Each flavor is constrained to suit a particular use. For some data types, multiple flavors are defined as the requirements for the data type varies by location in the message.

Limited conformance information is provided for optional message elements. Implementers who want to use optional message elements should refer to the base HL7 v2.8.2 standard to determine how these optional message elements should be used.

This document uses "X" as a conformance usage indicator very sparingly. Where the underlying standard indicates the segment/field/component is present as withdrawn ("W") an "X" will be used. For all other fields/components, "O" is used to enable trading partners to explore additional capabilities. Note that without a clearly agreed upon implementation profile between trading partners, a sender does not have to send any elements marked as an "O", nor does a receiver have to process any elements marked as an "O".

Because all exchanges involve an initiating message and a response message, interacting systems both send and receive messages during a single exchange. This document will use the terms "initiating system" or "initiator" to describe the system that begins the exchange by constructing and transmitting the initial message. This document will use the terms "responding system" or "responder" to describe the system that is the ultimate recipient the initial message and who constructs and transmits a response message.

Note that this document does not assume that the initiator or responder is a specific data source (IIS or EHR-S). One IIS may query another IIS or an EHR-S. Similarly, an EHR-S may send an immunization events to another EHR-S.

1.4.3 KEYWORDS

The following keywords in this document are to be interpreted as follows:

"MUST", or the terms "REQUIRED" or "SHALL", means that the definition is an absolute requirement of the specification.

"MUST NOT", or the phrase "SHALL NOT", means that the definition is an absolute prohibition of the specification.

"SHOULD", or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

"SHOULD NOT", or the phrase "NOT RECOMMENDED", means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

"MAY", or the adjective "OPTIONAL", means that an item is truly optional. One software supplier may choose to include the item to enable certain capabilities while another software supplier may omit the same item. In either case, the trading partner cannot be expected to either provide it (sender) or process it (receiver) without clear and voluntary agreement between the partners.


An application that does not support a particular segment/field/component marked as optional MUST be prepared to interoperate with another application which does support the optional segment/field/component, though perhaps with reduced functionality. In the same vein, an application which supports a particular segment/field/component marked as optional MUST be prepared to interoperate with another application which does not support the optional segment/field/component.

1.4.4 MESSAGE ACKNOWLEDGEMENT

The use of application level acknowledgements is required by this Implementation Guide. The use of accept (communication) level acknowledgements is not supported. This is consistent with the Original Mode pattern of acknowledgements as described in the base standard.

The conversation between an initiating system and a responding system consists of a message (VXU, ADT, QBP) and an application level response (ACK, RSP). Responding systems are expected to process the message and send a response. The system receiving the response does not acknowledge the response. For example, the system receiving a VXU is expected to return an ACK. The system receiving that ACK should not respond back to that ACK.

All response messages shall be returned synchronously. That is, the receiving process gives the response immediately or in a short period during which the originating process will wait for the response. The originating process will not send a new message until a response has been received. A system may initiate multiple simultaneous processes if allowed, but each process must wait for a response to a given message before sending the next one. For query interactions, this behavior is controlled by the constrained value of "I" in the Query Priority (RCP-1) field. See Chapter 5 of the HL7 v2.8.2 base standard for more details.

Receipt and processing of ACK messages has a number of significant benefits: Notification of errors and rejected data alerts the initiating system that the message has errors and

may require correction Alerting the initiating system that the data did not get into the responding system

Previous immunization messaging implementation guides have constrained values of ER for Accept Acknowledgement Type (MSH-15) and AL for Application Acknowledgement Type (MSH-16) for the initiating message profiles while supporting the Original Mode of acknowledgment. Per the HL7 base definition of Original Mode, the constrained values should be NE and AL respectively for MSH-15 and MSH-16.

Some messages pass through intermediary systems like a Health Information Exchange (HIE). It is important that the intermediary system pass the response message back to the initiating system to allow that system to be aware of and deal with messaging errors.

1.4.5 USAGE CONFORMANCE TESTING RECOMMENDATIONS

The following text is from the HL7 v2.8.2 Conformance chapter (Chapter 2B) Please refer to the base standard documentation for a full explanation of conformance concepts. Usage is described here as it introduces the revised approach to conditional element handling.

Note that local implementations may constrain the requirements of this Implementation Guide. See Chapter 2B for additional guidance on how to further constrain this document for local use.

---------- start citation---------Usage


Message content is governed by the cardinality specification associated (explicitly or implicitly) with each element of an HL7 message. Usage rules govern the expected behavior of the sending application and receiving application with respect to the element. The usage codes expand/clarify the optionality codes defined in the HL7 standard. Usage codes are employed in a message profile to constrain the use of elements defined in the standard. The usage code definitions are given from a sender and receiver perspective and specify implementation and operational requirements.

The standard allows broad flexibility for the message structures that HL7 applications must be able to receive without failing. But while the standard allows that messages may be missing data elements or may contain extra data elements, it should not be inferred from this requirement that such messages are conformant. In fact, the usage codes specified in a message profile place strict conformance requirements on the behavior of the application.Definition of Conditional Usage

The conditional usage is defined as follows:

C(a/b) - "a" and "b" in the expression are placeholders for usage codes representing the true("a") predicate outcome and the false ("b") predicate outcome of the condition. The condition is expressed by a conditional predicate associated with the element ("See section 2.B.7.9,"Condition predicate")."a" and "b" shall be one of "R", "RE","O" and/or "X". The values of "a" and "b" can be the same.

The example C(R/RE) is interpreted as follows. If the condition predicate associated with the element is true then the usage for the element is R-Required. If the condition predicate associated with the element is false then the usage for the element is RE-Required but may be empty.

There are cases where it is appropriate to value "a" and "b" the same. For example, the base standard defines the usage of an element as "C" and the condition predicate is dependent on the presence or non-presence of another element. The profile may constrain the element that the condition is dependent on to X; in such a case the condition should always evaluate to false. Therefore, the condition is profiled to C(X/X) since the desired effect is for the element to be not supported. Note it is not appropriate (in this case) to profile the element to X since this breaks the rules of allowable usage profiling (see table HL7 Optionality and Conformance Usage).Usage Rules for a Sending ApplicationOptionality/Usage Indicator

Description Implementation Requirement Operational Requirement

RRequired The application shall implement "R"

elements.The application shall populate "R" elements with a non-empty value.

RERequired but may be empty

The application shall implement "RE" elements.

The application shall populate "RE" elements with a non-empty value if there is relevant data. The term "relevant" has a confounding interpretation in this definition

C(a/b)Conditional An element with a conditional usage code has an associated condition

predicate (See section 2.B.7.9, "Condition predicate") that determines the requirements (usage code) of the element. If the condition predicate associated with the element is true, follow the rules for a which shall be one of "R", "RE", "O" or X": If the condition predicate associated with the element is false, follow the


Optionality/Usage Indicator


rules for b which shall be one of "R", "RE", "O" or X".a and b can be valued the same.

XNot supported

The application (or as configured) shall not implement "X" elements.

The application shall not populate "X" elements.

OOptional None. The usage indicator for this

element has not yet been defined. For an implementation profile all optional elements must be profiled to R, RE, C(a/b) or X.

Not Applicable.

Usage Rules for a Receiving ApplicationOptionality/Usage Indicator


RRequired The application shall

implement "R" elements.The receiving application shall process (save/print/archive/etc.) the information conveyed by a required element. A receiving application shall raise an exception due to the absence of a required element. A receiving application shall not raise an error due to the presence of a required element.

RERequired but may be empty

The application shall implement "RE" elements.

The receiving application shall process (save/print/archive/etc.) the information conveyed by a required but may be empty element. The receiving application shall process the message if the element is omitted (that is, an exception shall not be raised because the element is missing).

C(a/b)Conditional An element with a conditional usage code has an associated condition

predicate (See section 2.B.7.9, "Condition predicate") that determines the requirements (usage code) of the element.If the condition predicate associated with the element is true, follow the rules for a which shall be one of "R", "RE", "O" or X":If the condition predicate associated with the element is false, follow the rules for b which shall be one of "R", "RE", "O" or X".a and b can be valued the same.

XNot supported

The application (or as configured) shall not implement "X" elements.

None, if the element is not sent. If the element is sent the receiving application may process the message, shall ignore the element, and may raise an exception. The receiving application shall not process (save/print/archive/etc.) the information conveyed by a not-supported element.

OOptional None. The usage indicator

for this element has not yet been defined. For an

None.


Optionality/Usage Indicator


implementation profile all optional elements must be profiled to R, RE, C(a/b), or X.

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

1.4.6 OTHER DECISIONS

Delete Indicator: The delete indicator ("") should not be sent in any field, component or subcomponent of an immunization message.

Z segments: All message types, trigger event codes, and segment ID codes beginning with Z are reserved for locally defined messages. No such codes are defined within the HL7 Standard. Implementers who claim conformance to this IG, or issue conformance statements about their implementation SHALL NOT locally define and implement Z messages or include Z-segments in the standardized messages defined in this IG. Even though the profile identifiers used by this document (IZ22r1.0, IZ23r1.0, etc.) include a Z they are not locally defined and they are not Z-segments.

Truncation: While permitted for some data elements in the base standard, truncation of data in any immunization message is undesirable. This document excludes the use of the truncation delimiter as described in the base standard. Systems should not truncate data when constructing a message.


2 USE CASES This document defines a number of constrainable profiles that are combined to produce message exchanges that fulfill specific use cases. These use cases are defined below and set the overall context for data exchanges described by this document. They are not comprehensive of all immunization workflows and possible exchanges,

2.1 Actors This section will describe the actors (entities) that may be involved in sending or receiving immunization-related messages. There are a number of primary actors involved in data exchange. These include:

Immunization Information System (IIS) Electronic Health Record Systems (EHR-S) operating at the point of clinical care Other systems interested in contributing or leveraging immunization data (e.g. pharmacy systems) Master Person Index (MPI) in a supporting role Health Information Exchange (HIE) in a supporting role Intermediary systems who act as a pass-through for messages between the initiating system and

the ultimate intended recipient

These actors can be suppliers of data or requesters/consumers of data. This document will focus on the first 2 actors. Note that this document does not assume that the initiator or responder is either actor (IIS or EHR-S).

Other actors have an interest in the exchange of immunization data. These include Patients Policy makers Researchers Public Health agencies Clinicians Billing systems

These actors will not be directly addressed in this document as they interact through the primary actors to accomplish their needs.

The table below lists a number of messaging needs that relate to IIS and EHR-S. These are all candidates for immunization related use cases, although some are not currently implemented or are out of scope for this document.

TABLE 2-1 MESSAGING GOALS AND RESPONSIBILITIES FOR IIS AND EHR-SActor Responsibility Messaging GoalsImmunization Information System (IIS)

Provide access to a complete, consolidated immunization record for each person in its catchment area

Supply individual immunization records to authorized users and systems

Support aggregate reporting and analysis

Evaluate immunization history and make recommendations for next doses

Receive immunization events and updates

Receive demographic updates Receive requests for immunization

records Receive observations about a patient Send observations about a patient Send immunization records to other

systems Send evaluated immunization

histories and forecasts of next doses


Actor Responsibility Messaging Goals Store medical conditions that affect

vaccines recommendations Support inventory management Protect privacy of immunization data Return errors to initiating system Participate in an integrated and/or

interoperable group of application systems that use a Master Patient/Person (MPI) Index to link patient records

due for a specific patient Send requests for immunization

records Acknowledge receipt of message Report processing errors from receipt

of message

Electronic Health Record system (EHR-S)

House a patient's electronic health record including data on immunizations administered

Make a patient's record available to authorized persons

Provide clinical decision support to clinicians

Support inventory management Protect privacy of immunization data Correct system errors received from

IIS Provide the option to reconcile the

immunization history received from IIS with the history present in the EHR and evaluate recommendations for the next dose(s) after reconciliation is complete

Send immunization event and updates Send demographic updates Send observations about a person Request patient's immunization

history, including an evaluation of the history and future forecast

Receive evaluated immunization history and recommendations for next dose

2.2 General Assumptions

2.2.1 ASSUMPTIONS

The following assumptions are made regarding each use case: Infrastructure is in place to allow accurate and secure information exchange between systems Providers access immunization information through either an EHR-S, immunization information

system (IIS) or other application Privacy and security has been implemented at an appropriate level Legal and governance issues regarding data access authorizations, data ownership and data use

are outside the scope of this document The immunization record and demographic record for each patient contains sufficient information for

the initiating system to construct the message properly External business rules are documented locally

2.2.2 PRE-CONDITIONS

The following pre-conditions apply to each use case: The patient exists in the initiating system (except for the Demographics Only use case where the

creation of a new patient might trigger such a message) A user of the system takes an action that initiates the exchange This can include:

o An update to patient demographics


o Documentation of an immunization (either a new administration or a reported historical administration)

o Activating a trigger to query an external system for a patient's immunization history

2.2.3 POST-CONDITIONS

The following post-conditions apply to each use case: The responding system processes and, as necessary, stores and displays data from the message The responding system generates a response message appropriate for the initiating message profile The initiating system consumes and, as necessary, stores and displays data from the response

message for technical or clinical use

2.2.4 ERRORS AND ACKNOWLEDGEMENTS

Sending an acknowledgement can accomplish one of a number of goals. It can indicate that the message that was sent was successfully received and processed. It can also indicate that the processing of the message resulted in errors. A response message can take the form of either an ACK message or, in the case of a query exchange, an RSP message. The following description of error messaging applies to both types of response messages.

The ability to generate acknowledgement messages allows the responding system to notify the initiating system about the nature of any errors encountered during processing of the initial message. This is a prerequisite to troubleshooting errors in the initiating system. It allows the initiating system to identify systemic problems with message creation or data mapping. The process can also keep senders informed that some or all of the data they sent did not make into the target system.

It is vital that when messages are passed on by an intermediary, like a Health Information Exchange (HIE), that the acknowledgement message is passed back to the initiating system.

The word "error" can have different meanings depending on the context of its use. The following usages are common:

It could mean the general concept of an error as in something unexpected, unwanted, or wrong. It could refer to the Error (ERR) segment It could refer to a specific codified error returned in an ERR segment (ERR-3 or ERR-5) It could refer to the Severity (ERR-4) of Error (E) It could refer to the Acknowledgement Code of Application Error (AE).

This document attempts to be as specific as possible when using the term "error" to properly associate it to one of the possible meanings above. In the case that the term isn't clarified, the first meaning above (the general concept of an error as in something unexpected, unwanted, or wrong) should be assumed. The remainder of this section will use error in the sense of the first meaning.

An error may be serious enough as to warrant the rejection of an entire message or it may be trivial such as the receipt of an unexpected field of data. Interoperability errors may be caused by a variety of issues including:

A violation of an HL7 standard A violation of local processing rules A failure in the transport layer between the 2 systems A failure by the system sending the message to be authenticated by the system receiving the

message

The first 2 types of errors (violations of the HL7 Standard, this Implementation Guide, or a violation of local


processing rules) are addressed by this document. The third and fourth types of errors (failures in the transport layer and authentication errors between the sender and receiver) are not specifically messaging errors and would likely be identified as part of a transport layer.

The error is defined by an error code and by an error severity both of which are returned as part of the acknowledgement message. The error type (transmitted as a coded value in ERR-3 or ERR-5) should clearly identify the nature of the error. Three severity levels (transmitted as a coded value in ERR-4) are required by this document:

Informational (I) - the processing of the message was successful but additional information is returned

Warning (W) - the processing of the message was at least partially successful but issues were identified, potentially resulting in the loss of data. These data quality issues should be researched and resolved over the course of time.

Error (E) - the processing of the message was not successful in whole or in part, and important data was rejected

A fourth error severity level of Fatal (F) is permitted, when agreed upon by trading partners, to indicate when a message is not processed due to an application or a network failure condition.

Not all responding systems will agree upon the severity of a given error. Data that are critical for one system may be optional for another. As such, this document leaves the determination of error severity to each system. However, expectations regarding the definition of each severity should be consistent across systems. The severity should consistently inform the initiating system as to a course of action to take relative to the error.

TABLE 2-2 SEVERITY VALUES AND EXPECTATIONSSeverity Must Correct? Must Resubmit?Informational No NoWarning Yes NoError Yes Yes

Based on the table above, upon receiving an informational error, there is no expectation that the initiating system will update any system configuration, content, build or mapping, nor does it need to resubmit the message that generated the acknowledgement message. Upon receiving a warning error, the initiating system is expected to correct some issue in the system but resubmission of the original message is not required. Finally, upon receiving an error, the initiating system is expected to correct some configuration, content, build or mapping error in their system and resubmit the original message with errors addressed. Note that based solely on the content of the acknowledgement message containing the severity of error, it may not be possible to definitively tell what parts, if any, of a message were consumed by the responding system. Before correcting the error and resubmitting a message, an agent of the initiating system must investigate the error thoroughly. Note that the source of the error may reside in the responding system, so conversation between trading partners is crucial to the troubleshooting process.

Note that while the ACK message allows multiple errors to be returned to the initiating system, the v2.8.2 definition of the RSP message allows only a single error to be returned. This limitation of RSP message type will be corrected in the base v2.9 standard, but for now, it is left to the discretion of the responding system which error to return if multiple errors arise in the course of processing a single message. The recommendation of this document is to return the most severe error found.


2.2.5 OBSERVATIONS

A variety of observations can be exchanged using OBX segments in the messages described by this document. OBX segments can be used in a variety of contexts with different message types. The term Order Segment Group refers to set of one ORC segment, one RXA segment and associated RXR and OBX segments, if any, as defined by the message definitions.

TABLE 2-3 IMMUNIZATION MESSAGE CONTEXTS

Context Description Message Types

Person Observations

Observations related to the patient as a whole rather than an immunization event. These observations may be part of the PERSON_OBSERVATION segment group in a VXU or RSP message or an OBX segment following the PID segment in an ADT message.

ADT, VXU, RSP

Immunization Event Order Segment Group

Observations related to a given immunization event as reported by a submitter. VXU

Immunization Event (Contraindicated) Order Segment Group

Observations related to a contraindicated vaccine which is not given. VXU, RSP

Immunization Event (Refused) Order Segment Group

Observations related to a vaccine refused by the patient or guardian. VXU, RSP

Immunization Event (Evaluated) Order Segment Group

Observations about an immunization event evaluated against a standard set of guidelines. The evaluated order segment group can also include all observations relevant to the original Immunization Event order segment group.

RSP

Forecast Order Segment Group Observations related to recommended future doses RSP

However, not all observations are appropriate for every context. The table below outlines the core observations used by this document and indicates the appropriate context for each observation. Some observations may be used in multiple contexts, although the meaning in each context may be slightly different.

As well, a set of related values may be exchanged using multiple OBX segments. For example, a recommendation includes both a vaccine type (LOINC 30956-7) and a recommended date (LOINC 30980-7). Because a forecast may contain multiple recommended vaccines, it is critical to be able to link the vaccine type to the appropriate recommended date. This is accomplished using the sub-ID in OBX-4. All related OBX segments must contain the same value in OBX-4. The Group column in the table below indicates which observations comprise a group of related codes which must share a common sub-ID. Observations in the "Individual" group have no related observations and should always be messaged with a unique sub-ID.

TABLE 2-4 OBSERVATION CONTEXT AND GROUPS

Description LOINC Code Group Context Comments

Condition 75323-6 Condition Person Observation

This value represents a fact known about the patient. This observation may appear multiple times per patient.

Date of condition onset 85585-8 Condition Person Observation This value represents the effective date of the patient



condition. Only a single effective date may be associated with any given patient condition.

Date of condition abatement 88878-4 Condition Person Observation

This value represents the abatement date of the patient condition. Only a single abatement date may be associated with any given patient condition.

Disease with serological evidence of immunity 75505-8 Individual Person Observation

This value represents a history of the disease by serological evidence. This observation may appear multiple times per patient.

Disease with presumed immunity 59784-9 Individual Person Observation

This value represents a disease where a clinician has determined that the patient has a history of the disease. This observation may appear multiple times per patient.

Vaccine funding program eligibility category 64994-7 Eligibility

Immunization Event; Immunization Event (Evaluated)

This value represents the funding program that should pay for a given immunization. It is determined based on characteristics of the patient and the type of vaccine administered. This observation may appear only once per order segment group.

Vaccine funding source

30963-3 EligibilityImmunization Event; Immunization Event (Evaluated)

This value represents the funding source (public or private) of the vaccine administered. This observation may appear only once per order segment group.

Document type 69764-9 VIS


This value represents the document type (VIS Fully-encoded text string) of the VIS provided. This observation may appear multiple times per order segment group when a vaccine contains multiple vaccine types.

Date vaccine information statement presented

29769-7 VIS Immunization Event; Immunization Event (Evaluated)

This value represents the date the document was presented to the patient/responsible person. This observation may appear multiple times per order segment group when a vaccine contains multiple vaccine types but only a



single presented date may be associated with a given document type.

VIS vaccine type 30956-7 VISImmunization Event; Immunization Event (Evaluated)

When not using the document type (GDTI), the vaccine type observation plus the version date observation can be used to specify the VIS given to the patient. Note that this same LOINC code is used as part of the transmission of evaluation and forecasting data.

VIS version date 29768-9 VIS


This value represents the date the VIS document presented to the patient was published. This observation type is only used with the VIS vaccine type observation when the document type (GDTI) is not used.

Indication for immunization 59785-6 Indication


This value represents a factor which can drive the need for a specific immunization or a change in the normal schedule for immunization. This observation may appear multiple times per order segment group.

Date of vaccination indication effective

88877-6 IndicationImmunization Event; Immunization Event (Evaluated)

This value represents the effective date of the indication. Only a single effective date may be associated with an indication observation.

Date of vaccination temporary indication expiration

88879-2 IndicationImmunization Event; Immunization Event (Evaluated)

This value represents the expiration date of the indication. Only a single expiration date may be associated with an indication observation.

Immunization reaction

31044-1 Individual

Immunization Event; Person Observation

This value represents a reaction a patient experienced after an immunization. This observation may appear multiple times per segment group or patient.

Annotation comment 48767-8 Individual Immunization Event; Immunization Event (Refused); Immunization Event (Contraindicated); Immunization Event

This value represents a comment regarding the vaccination. This observation may appear multiple times per order segment group. Comments should be clinically relevant and discrete data which



(Evaluated)can be sent elsewhere in the message should not be sent as a comment.

Vaccination contraindication/precaution

30945-0 Contraindication

Immunization Event (Contraindicated)

This value represents a physical condition, current medication or other factor that indicates that a person should not receive an immunization. This observation may appear multiple times per order segment group.

Date vaccination contraindication/precaution effective

30946-8

Contraindication


This value represents the effective date of the contraindication. Only a single effective date may be associated with a contraindication observation.

Date of vaccination temporary contraindication/precaution expiration

30944-3

Contraindication


This value represents the expiration date of the contraindication. Only a single expiration date may be associated with a contraindication observation.

Vaccine Type 30956-7 Evaluation Immunization Event (Evaluated); Forecast

This value represents the vaccine administered or recommended. This observation may appear multiple times per order segment group. When an Immunization Event is evaluated against different antigens, each group of observations must have a unique sub-ID. As well, when multiple vaccine types are forecast, each vaccine type mush have a unique sub-ID. Note that this same LOINC code is used as part of the transmission of VIS data.

Dose validity 59781-5 Evaluation

Immunization Event (Evaluated)

This value represents whether or not the dose being evaluated is valid for the series or not. This observation may appear multiple times per order segment group but only once per Vaccine Type.

Reason applied by forecast logic to project this vaccine

30982-3 Evaluation; Forecast

Immunization Event (Evaluated); Forecast

This value may be used to represent why a dose is given its evaluation status (validity) when part of an evaluation order segment group. This is typically



used when a dose is determined to be invalid. This value may also be used to represent why a dose is being forecast when part of a forecast order segment group. This is typically used when a dose is being forecast for a reason beyond typical age-based recommendations.

Immunization series name 59780-7

Evaluation; Forecast


This value represents the name of the series the dose applies to. Values are defined locally. This observation may appear multiple times per order segment group but only once per Vaccine Type.

Immunization schedule used 59779-9 Evaluation;

ForecastImmunization Event (Evaluated); Forecast

This value represents the schedule used during an evaluation or forecast process. This observation may appear multiple times per order segment group but only once per Vaccine Type.

Number of doses in primary immunization series

59782-3



This value represents the total number of doses in the series. This observation may appear multiple times per order segment group but only once per Vaccine Type.

Dose number in series 30973-2



This value represents position in the antigen series that the dose occupies This observation may appear multiple times per order segment group but only once per Vaccine Type.

Status in the immunization series 59783-1 Forecast Forecast

This value represents the status of the series the dose belongs to. This observation may appear multiple times per forecast order segment group but only once per recommended Vaccine Type.

Earliest date 30981-5 Forecast Forecast

This value represents the earliest possible date the next dose could be given. This observation may appear multiple times per forecast order segment group but only once per recommended Vaccine Type.



Recommended due date 30980-7 Forecast Forecast

This value represents the date the next dose is due. This observation may appear multiple times per forecast order segment group but only once per recommended Vaccine Type.

Overdue date 59778-1 Forecast Forecast

This value represents the date when the next dose is considered overdue. This observation may appear multiple times per forecast order segment group but only once per recommended Vaccine Type.

Latest date 59777-3 Forecast Forecast

This value represents the latest possible date the next dose could be given. This observation may appear multiple times per forecast order segment group but only once per recommended Vaccine Type.

2.3 Use Case 1-Send Immunization Event

2.3.1 CONTEXT

Goal: To send data about one or more immunization events for an individual patient from one system to another and to receive an acknowledgement message back in return.

An immunization event may be the administration of a vaccine or immune globulin. The initiating system may be an Electronic Health Record system (EHR-S), an Immunization Information System (IIS) or another type of health information system. This use case includes new administrations, updates of existing administrations, deletion of existing administrations and documentation of immunization refusals or contraindications. It also includes the messaging of patient and administration level observations.

Trigger Event: A user, actor or process completes an add, update or delete of relevant information about one or more immunization events for a patient in the initiating system.

Note that placing an order or entering a future immunization into the initiating system should not trigger the generation of a VXU message as not all placed orders result in an administration. The trigger should be the documentation of the immunization event itself (including if the administration is refused or determined to be contraindicated). Limiting the triggering event to the documentation of the event itself improves data quality, reduces overhead and results in a more accurate patient history.

Initial Message Profile: IZ22r1.0 (VXU)

Responding System Outcome: The responding system processes the IZ22r1.0 message and returns an acknowledgement message, including errors if any.


Response Message Profile: IZ23r1.0 (ACK)

Initiating System Outcome: The initiating system processes the IZ23r1.0 acknowledgement message. Relevant content from the IZ23r1.0 message, such as error related data, is stored or displayed to end users.

Processing Mode: The goal of the Send Immunization Event use case is to send up-to-date information about an immunization event(s) and the patient receiving the administration(s). A conformant message may contain a view of the entire patient vaccination history as known by the system originating the VXU^V04 message, but it is not required to do so and usually will not do so. In other words, a given IZ22r1.0 conformant message is likely to contain only a subset of all immunization events on the patient record, typically only those that have been added, updated or deleted as part of the event leading to the triggering of the IZ22r1.0 message. The responding system is responsible for applying business rules to integrate the data received but should not assume that the message being processed represents the entire patient immunization history. The data within any single order segment group should represent the complete set of data about the immunization event as known by the system originating the message. The demographics data within the message should represent the complete set of demographics data about the patient as known by the system originating the message.

2.3.2 USER STORY

A typical user story for the Send Immunization Event use case is as follows. A patient presents to a clinic for an encounter. A clinic staff member collects basic patient demographic information including name, date of birth and administrative sex. A clinic provider reviews the patient's immunization history and determines that the patient previously received one or more doses that are not yet currently documented electronically. The staff member also determines that the patient needs additional immunizations to meet standard recommendations. A clinician prepares and administers the doses to the patient and then enters the data into the EHR for both the reported and administered doses and transmits it to the IIS.

2.3.3 INTERACTION DEFINITION

This sequence diagram illustrates the message flow for the Send Immunization Event use case. The initiating system sends one or more immunization events in a VXU message. The trigger may be a new record, an update or delete of an existing record or some other event. The responding system accepts the message and processes it. The responding system sends an acknowledgment in an ACK message, including any relevant error information.

It is important to note that the messages may pass through intermediaries, such as a Health Information Exchange (HIE). The message comes from the initiating system and the acknowledgement MUST be returned to that initiating system regardless of the number of nodes (or "hops") in between the two systems.


FIGURE 2-1 SEND IMMUNIZATION EVENT SEQUENCE DIAGRAM

2.3.4 DYNAMIC DEFINTION

This activity diagram illustrates the expected flow of events. An event triggers the initiating system to create and send a VXU message. The responding system accepts the VXU. If the message is of an unsupported message type, has an unsupported event code, has an unsupported processing ID, has an unsupported version ID or is unable to be processed for reasons unrelated to format or content, then the responding system returns an ACK with the acknowledgement code of "AR". Otherwise, the responding system continues to process the message. It parses the message and processes it according to the specifications of this profile and applies local business rules. If there are no errors or warnings, the acknowledgment code is set to "AA". If there are errors, the acknowledgement code is set to "AE". If the errors are fatal, then the message may be rejected, otherwise the data are integrated into the responding system. The acknowledgement code is returned to the initiating system in an ACK message.


FIGURE 2-2 SEND VXU ACTIVITY DIAGRAM

2.3.5 SCENARIOS

2.3.5.1 SENDING SUCCESS ACKNOWLEDGEMENTS

The initiating system should expect to receive an acknowledgment message, even when the responding system has successfully processed the message. Similarly, the responding system must be prepared to send an acknowledgement even when it has successfully processed the message. The purpose of this success acknowledgement is to inform the initiating system that the data were received and processed.


The responding system will respond with an Acknowledgement Code (MSA-1) of AA.

While not recommended, in this scenario, an optional ERR segment may be sent with an Error Code and a Severity (ERR-4) of I. Such a segment would indicate that the responding system wishes to inform the originating system of additional non-error information, such as a confirmation of the number of immunization events processed.

2.3.5.2 SENDING MESSAGE REJECTION ACKNOWLEDGEMENTS

A responding system will reject the message and respond with an Acknowledgement Code (MSA-1) of AR only under one of the following conditions:

Unsupported Message Type Unsupported Event Code Unsupported Processing ID Unsupported Version ID Unable to process for reasons unrelated to format or content

2.3.5.3 SENDING MESSAGE PROCESSING ERROR/WARNING ACKNOWLEDGEMENTS

A responding system will respond with an Acknowledgement Code (MSA-1) of AE upon encountering one or more errors with a severity of Error or Warning.

A responding system may reject some or all of a message based on HL7 rules, including the following conditions:

Empty or missing Required segment(s) not in a segment group Empty or missing Required segment group(s) Empty or missing Required segment(s) in a segment group Empty or missing Required field(s) in a Required segment

There may be additional rules that a receiving system enforces beyond those defined by HL7 definitions. For example, a local business rule may be that the date of birth shall be on or before the date of administration. Violation of this rule would generate an error.

Note that an Acknowledgement Code of AE may be returned even if some of the data in the message are accepted and incorporated into the responding system. For example, a message containing multiple immunization events may be processed in such a way that one event generates an error and is partially or wholly rejected while the remaining events are accepted.

2.3.6 MESSAGING CAPABILITIES

The specific content of the VXU^V04 message will vary with the user workflow and patient context. The following sections will specify how to send the following types of data:

Add a dose - An immunization event is added when a provider documents the administration of a new dose of vaccine or when he/she documents a historical immunization.

Update a dose - An immunization event is updated when information about a previously added dose is changed, regardless of whether or not it was reported as a new administration or a historical administration.

Delete a dose - An immunization event is deleted when a previously added dose is removed from the patient's record in the initiating system.


Send Patient Protection Indicator - A patient may choose not to share their immunization data with others.

Send Patient Conditions - Some observations relate to the patient as a whole rather than to an individual immunization event.

Send Patient Eligibility Status - Federal regulations specify that patient eligibility status be assessed for each administration event.

Send Vaccine Funding Source - The funding source indicates if the vaccine administered was purchased with private or public funds.

Send Vaccine Information Statement (VIS) - The VIS is a document provided to the patient that explains the reasons for a vaccine and the potential risks from receiving the vaccine.

Send Administration Refusals - An immunization may be refused by a patient. Send Partial Administrations - There are occasions when a dose is not completely administered or

deemed ineffective (e.g., cold-chain break, manufacturer recall, etc). Send Adverse Reactions - A patient may experience an adverse event after the receipt of a vaccine. Send Evidence of Immunity - Infection with the disease(s) that is the target of immunizations leads to

long-term immunity. Further immunization against the disease is not likely to provide benefit. Send Contraindications - A contraindication is any physical condition, current medication or other

factor that indicates that a person should not receive an immunization. Send Special Indications - Patient specific factors can drive the need for a specific immunization or a

change in the normal schedule for immunization. Send Comments - Free text comments may be made regarding the administration. The comment

should not be used to transmit any data, such as contraindications or immunities, that can be sent discretely as described in this document.

2.3.6.1 SENDING ADDS

When an administration is first documented in the initiating system, an "add" message is generated. The administration being documented in the initiating system can either be a "new administration" (one where the content of the report is based on information from the person who administered the vaccine) or a "historical administration" (one performed elsewhere and where the content of the report is not based on information from the person who administered the vaccine). See documentation on Information Source codes messaged in RXA-9 for distinguishing between these administration types. In both cases, a unique ID for each administration is messaged using the Filler Order Number (ORC-3). The next section contains a more thorough description of the use of ORC-3.

2.3.6.2 SENDING UPDATES OR DELETIONS

There are occasions when a system that has sent an immunization record to another system wishes to update or delete the record on the other system. Each system may have rules about the submitter's right to update or delete records.

The Action Code (RXA-21) is used to indicate the need for an update to or deletion of a specific record. The following diagram illustrates how the Filler Order Number in ORC-3 may be used to identify an immunization record for update or deletion. Note that the initiating system includes the system's unique ID for the immunization record in the first component of ORC-3. The second component is the namespace (assigning authority) of the ID. In this case, the namespace is a system that is labeled MyEHR. In order for a later message to be successful, the receiving system should be able to associate the initiating system's ID and namespace with the vaccination event record. A subsequent request to update or delete an immunization record includes the same ID and namespace used by the initiating system. The responding system searches for an immunization record with the same identifier and updates/deletes the found record.


FIGURE 2-3 DELETING AN IMMUNIZATION RECORD SEQUENCE DIAGRAM

2.3.6.3 SENDING PATIENT PROTECTION INDICATOR

The protection indicator identifies whether a person's information may be shared with others. The indicator conveys the current patient state in the system constructing the message. Local laws, regulations and IIS policy may significantly impact the collection and exchange of patient protection indicators including, but not limited to:

Method of collecting protection indicator (electronic versus paper) Who data is collected for (adults versus minors) Whether individuals opt in or opt out of data sharing Filtering of data for protected individuals

More information on consent can be found in the AIRA Confidentiality and Privacy Considerations document in the AIRA document repository.

Some jurisdictions require that submitters not transmit events for patients who have not consented to share their data. In this case, no HL7 message is constructed by the submitter's system. The remaining discussion of the protection indicator in this use case assumes that the submitter is allowed to generate and transmit an HL7 message.

The protection state must be explicitly captured in the system documenting the immunization. If it is not actively determined, then the protection indicator shall be empty.

There are 3 states: Yes, protect the data. Patient (or guardian) has indicated that the information shall be protected. (Do

not share data) No, it is not necessary to protect data from other clinicians. Patient (or guardian) has indicated that

the information does not need to be protected. (Sharing is OK)


No determination has been made regarding patient's (or guardian's) wishes regarding information sharing.

If PD1-12 is not populated the receiving system is expected to select a default value based on local policy and requirements.

The protection indicator and associated effective date are messaged in the Protection Indicator (PD1-12) field and the Protection Indicator Effective Date (PD1-13) field.

2.3.6.4 SENDING PATIENT CONDITIONS

Some observations are relevant to the patient as a whole and not to any single immunization event. Typically, these condition observations consist of information known about the patient which may be an indication or a contraindication for certain antigens (see subsequent sections for more information on how to message indications and contraindications). For example, a patient may be pregnant (a fact known about the patient) which is an indication for pertussis vaccination but a contraindication for MMR vaccine. Each condition may be associated with an onset date and/or an abatement date.

Because conditions are relevant to the patient as a whole, they are transmitted using the Person Observation segment group. A condition is messaged in a Person Observation OBX segment using the LOINC code 75323-6 and the PatientCondition value set. The date of condition onset is messaged using the LOINC code 85585-8 and the condition abatement date is messaged using the LOINC code 88878-4.

The nature of the triggering action and scope of patient conditions that are valid to be exchanged are beyond the scope of the document and should be agreed upon locally by trading partners.

2.3.6.5 SENDING EVIDENCE OF IMMUNITY

Evidence of immunity indicates that a person has plausible evidence that they have already developed immunity to a particular disease. Long-term immunity in the patient may result from infection with the disease(s) that is a vaccine target. If Evidence of Immunity is confirmed, further immunization against the disease is not likely to provide benefit. The strongest evidence of immunity is when serological evidence indicates immunity. An alternative evidence of immunity is when a clinician has determined that the patient has a history of the disease.

Evidence of Immunity is messaged in the Person Observation segment group using an OBX segment containing the LOINC codes 59784-9 (Disease with Presumed Immunity) and 75505-8 (Serological Evidence of Immunity) and the PHVS_HistoryOfDiseaseAsEvidenceOfImmunity_IIS and PHVS_SerologicalEvidenceOfImmunity_IIS value sets respectively.

Evidence of Immunity is not relevant to all vaccine preventable diseases, in part because often a vaccine may protect against multiple variants of the organism and immunity to one variant may not provide full immunity to other variants.

2.3.6.6 SENDING PATIENT ELIGIBILITY STATUS

Immunization event messages may convey the patient eligibility status. That is, for each new dose administered, the patient's eligibility should be recorded and transmitted. Eligibility refers to what funding program should pay for the vaccine. This is distinctly different from the funding source, which refers to what funding program actually paid for the vaccine. The next section further discusses how to send funding source.


Federal regulations specify that the Patient Eligibility status be assessed for each immunization event. It is a key data element for creating the Vaccines for Children (VFC) report on vaccine usage. Support for this report requires that systems capture and exchange eligibility statuses specifically at the dose administered level. When recorded at the dose level, patient eligibility is dependent on two requirements:

The patient must meet the criteria for the program The vaccine administered must be included in the program

In the past, eligibility was recorded for each visit where a patient received an immunization. Guidance from the Modeling Immunization Registry Operations Workgroup (MIROW) has clarified that the eligibility status of the patient should be recorded for each vaccine dose administered. In contrast to previous versions of this implementation guide, this document no longer describes support for sending patient eligibility determined at the visit level.

As described in the MIROW document, a variety of factors play a role in determination of Patient Eligibility Status: VFC and grantee policies, age, private insurance coverage, type of provider, and type of vaccine to be administered. For instance, a person under the age of 19 years who was an Alaska Native receiving an MMR would have an eligibility status code of V04. Note that when an event could meet more than one eligibility, selection is based on priority.


FIGURE 2-4 ELIGIBILITY STATUS DETERMINATION

The following table is an illustration of the expected outcomes for eligibility determination:

TABLE 2-5 SAMPLE ELIGIBILITY OUTCOMESDetermined Patient Eligibility Vaccine Type Eligibility Eligibility OutcomeMedicaid Vaccine type is eligible for VFC (e.g. DTaP) Patient is VFC eligible (V02)

American Indian/Alaska Native Vaccine type is not eligible for VFC (e.g. Yellow fever)

Patient is not VFC eligible (V01)

Too old (Age 21 years) Any Patient is not VFC eligible (V01)

Eligible for state or local vaccine program and not eligible for VFC Vaccine is eligible for state or local program. State or local eligibility (V25)


Local funding programs may necessitate the use of locally defined eligibility codes to message jurisdictional specific concepts.

Patient eligibility is messaged in an OBX segment using the LOINC code 64994-7 and the 0064_01 value set.

Patient eligibility status should not be transmitted for immunizations that represent a historical record of an immunization.

In previous releases of the immunization messaging implementation guide, the PV1 segment was used to carry information about the patient's eligibility status. This is now transmitted at the immunization event (dose administered) level through the use of the OBX segment. Use of the PV1 segment for the purpose of reporting patient eligibility for a funding program at the visit level is not supported in this document.

2.3.6.7 SENDING VACCINE FUNDING SOURCE

The funding source indicates whether a dose of vaccine came from publicly or privately funded inventory. Identification of the actual funding source for a given immunization is necessary to support inventory management and vaccine use accountability. Every immunization that is a new administration has one funding source.

Funding source codes from the PHVS_ImmunizationFundingSource_IIS value set usually reflects physical storage at the provider site and indicate the inventory stock for either a two-stock storage model (Public or Private) or three-stock storage model (Public VFC, Public non-VFC, Private) from which each vaccine dose was taken. For publicly purchased vaccine, an IIS will use either the VXC50 code (i.e., public) or the combination of the VXC51 (i.e., Public VFC) and VXC52 (i.e., Public non-VFC) codes to record the inventory stock for publicly purchased vaccine. All funding source values should be mutually exclusive. Local funding programs may necessitate the use of additional locally defined funding source codes in order to support vaccinations funded through locally allocated funds rather than federally allocated funds.

The funding source is messaged in an OBX segment using the LOINC code 30963-3 and the value set PHVS_ImmunizationFundingSource_IIS.

2.3.6.8 SENDING VACCINE INFORMATION STATEMENTS (VIS)

The Vaccine Information Statement (VIS) is a document presented to patients or the legal guardians that explains the reasons for a vaccine and the potential risks from receiving the vaccine.

VIS documentation is required for all patients, but only for specific vaccines. The requirements for sending VIS information within an order segment group is detailed elsewhere in the document and the list of vaccines requiring VIS data is documented in the PHVS_VISVaccines_IIS value set.

Historically, two methods have existed to transmit VIS document(s) information in an HL7 message. The first involves the use of 2D VIS barcode data strings, "VIS Fully-encoded text string". The second involves the identification of the vaccine type or group along with the VIS publication date. The use of the VIS Fully-encoded text string is highly recommended when messaging VIS information. The alternative of using the vaccine type, publication date and presentation date LOINC codes is problematic and fails in several use cases including when sending manufacturer specific VIS information or when sending the Multiple Vaccines VIS document because an appropriate CVX code to use for the vaccine type is not always available.


Several pieces of information are messaged about each VIS presented to the individual. Fully Encoded String Method:

o The VIS document type (LOINC code 69764-9) from the PHVS_VISBarcodes_IIS value seto The date that the VIS was presented to the patient/guardian (LOINC code 29769-7)

Document Type Methodo The vaccine type of the VIS (LOINC code 30956-7)o The date that the VIS was published (LOINC code 29768-9)o The date that the VIS was presented to the patient/guardian (LOINC code 29769-7)

For any given administration, the message will use one method or the other but not both. That is, for a given administration, the two methods are mutually exclusive.

The 13 digit Global Document Type Identifier (GDTI) is used to identify a document type while the 24 digit VIS Fully-encoded text string begins with "253" and includes the GDTI as well as the publication date. The VIS Fully-encoded text string represents a particular version of the VIS document and the publication date may be inferred from the VIS Fully-encoded text string. It is the VIS Fully-encoded text string and not the GDTI that should be sent in OBX-5. The GDTI, Fully-encoded text string, and Edition Date are available in the VIS Lookup Table (http://www.cdc.gov/vaccines/programs/iis/code-sets/vis-barcode-lookup-table.html).

The VIS related observations are transmitted in separate OBX segments associated with an immunization event (RXA segment). Key elements of the OBX include:

Observation Identifier (OBX-3) which contains the LOINC code Observation Value (OBX-5) which contains the dose specific value (document type, vaccine type or

date (published and/or presented)) Sub-ID (OBX-4) which links the related OBX segments

When RXA-5 indicates that a combination vaccine was administered, the OBX segments for the VIS related observations will be repeated for each component of the vaccine. For example, If RXA-5 indicates that Pentacel (DTaP-Hib-IPV) was administered and the patient/guardian was presented with three individual VIS (for DTaP, Hib and Polio), then a total of 6 OBX segments will be included in the message when using the fully encoded string method. For each of the three vaccine components, a document type OBX segment and a presentation date OBX segment will be included where three unique OBX-4 values will be used to group the segments in into 3 groups of 2 OBX segments each. See the sample message in section 2.3.7.1 for an example. Note that it is also valid for the provider to present a single multiple vaccine VIS to the patient/guardian. If that occurs, the message should only include a single document type OBX segment (containing the identifier for the multiple vaccine VIS) and a single presentation date OBX segment. Note that the content of the message must match the documents actually provided to the patient/guardian.

2.3.6.9 SENDING ADMINISTRATION REFUSALS

Patients or their parents may choose not to be immunized against a particular disease or diseases. There are several components to messaging a refusal. A value of "RE" in the Completion Status in RXA-20 indicates that the vaccine was not given. The refusal reason is indicated in RXA-18. RXA-5 will indicate the vaccine that was refused. The amount given (RXA-6) shall be "999". Note that the ORC segment is still required. Filler Order Number (ORC-3) is still required and shall be "9999".

2.3.6.10 SENDING PARTIAL ADMINISTRATIONS

There are occasions when a dose is not completely effective. For example, a child may jump away during injection and an unknown quantity was administered or a dose of vaccine may be considered sub-potent due to


a cold-chain break or manufacturing issue. In this case, the dose needs to be recorded to support accurate inventory management and to allow for notification of the patient if there is a recall of the vaccine. This is accomplished using a Completion Status of "PA" in RXA-20. The remainder of the RXA segment is populated as usual. If more details are of interest, then by local agreement additional information may be sent as a comment or using locally defined observations identifiers.

2.3.6.11 SENDING ADVERSE REACTIONS

An adverse reaction is a negative health consequence experienced by the patient related in time to administration of vaccine(s). "In time" means that it happens in some reasonable time after the immunization event. It might not be attributable to a specific vaccine dose administered, especially in cases when the patient receives several shots in one visit.

An adverse reaction is messaged in an OBX segment using the LOINC code 31044-1 and the value set PHVS_VaccinationReaction_IIS.

2.3.6.12 SENDING CONTRAINDICATIONS

A contraindication is a condition in a patient that greatly increases the chance of a serious adverse reaction and renders a vaccination inadvisable for a patient. A contraindication may be temporary or permanent.

There are a number of contraindications to immunization. One is a history of an adverse reaction to a previous immunization. Others include allergies to components of vaccines, physical conditions, current medication being taken and current illnesses or medical conditions. Each contraindication may be associated with an onset date and/or an expiration date.

A contraindication is messaged in an OBX segment using the LOINC code 30945-0 and the PHVS_VaccinationContraindication_IIS value set. The effective date of the contraindication is messaged using the LOINC code 30946-8 and the date of contraindication expiration is messaged using the LOINC code 30944-3. RXA-5 in the same order segment group shall indicate the contraindicated vaccine and RXA-20 shall be NA, indicating that a dose was not administered.

2.3.6.13 SENDING SPECIAL INDICATIONS

An indication is a relevant observation about a patient that signals the need for additional protection beyond the vaccination recommendations for standard age-based series.

Several factors can drive the need for a specific immunization or a change in the normal schedule for immunization. These may be an exposure to an infection, such as rabies. Other risk factors may include membership in a risk group. Each indication may be associated with an onset date and/or an expiration date.

A special indication is messaged in an OBX segment using the LOINC code 59785-6 and the PHVS_VaccinationSpecialIndications_IIS value set. The effective date of the vaccination indication is messaged using the LOINC code 88877-6 and the date of vaccination indication expiration is messaged using the LOINC code 88879-2.

2.3.6.14 SENDING COMMENTS

A free text comment may be recorded in association with an administration event. Transmitted comments should be clinically relevant to the administration.

A comment is messaged in an OBX segment using the LOINC code 48767-8.


2.3.7 SAMPLE MESSAGES

The sample messages contained in this section of the document are for illustration purposes and should not form the basis of system design. Readers should not infer any requirements solely from these messages. For example, the order that observations are given in OBX segments and the order in which events appear in the messages are not intended to indicate requirements for message construction.

2.3.7.1 ADD, PROTECTION, ELIGIBILITY, FUNDING SOURCE, VIS, COMMENT

This scenario includes sending patient eligibility status, vaccine funding source and VIS documentation as well as historical and new administration records.

A two-month old male infant, Darren Franklin Wilson, is brought to the West Clinic for a well-child visit by his mother Tamara Violet Wilson (nee Scott) and his father Robert Wilson. A clinic staff member collects basic patient demographic information including name, date of birth and administrative sex. A clinic provider, Vivian Jordan reviews the patient's vaccination history and determines that the child previously received Hepatitis B vaccine 1 day after birth and 1 month after birth. The provider also determines that the patient needs DTaP, Hib, IPV, Rotavirus and Pneumococcal vaccinations. Because of the patient's status of Native American, he qualifies for all Vaccine For Children (VFC) supplied vaccines with the status of VFC eligible - American Indian/Alaska Native. The parents are given 5 Vaccine Information Sheets (VIS) to review. After reading them, they agree that the child should receive all the vaccinations recommended. They also agree that the data should be shared once it is incorporated into the local IIS. Appropriate doses of DTaP/Hib/IPV (Pentacel), Rotavirus (RotaTeq) and Pneumococcal (Prevnar13) are selected from the clinic's stock of publicly funded vaccines. A clinician, Spencer Hill, prepares and administers the doses to the patient and then enters the data into the EHR and transmits it to the IIS.

MSH|^~\&||wcEHR||IIS|20160720123514-0500||VXU^V04^VXU_V04|4850|P|2.8.2|||NE|AL|||||IZ22r1.0^CDCPHINVS|wcEHR|IISPID|1||998756^^^wcEHR^MR||Wilson^Darren^Franklin^^^^L|Scott^^^^^^M|20160517|M^Male^HL70001||1002-5Âmerican Indian or Alaska Native^CDCREC|99 Wellington Street^^Carson City^NV^89701ÛSA^P||^PRN^PH^^^775^5558458|||||||||2186-5^Not Hispanic or Latino^CDCREC||N|1|||||NPD1|||||||||||07^Recall only - no calls^HL70215|N|20160720|||AÂctive^HL70441|20160517|20160720NK1|1|Wilson^Tamara^Violet^^^^L|MTH^Mother^HL70063|99 Wellington Street^^Carson City^NV^89701ÛSA^P|^PRN^PH^^^775^5558458NK1|2|Wilson^Robert^^^^^L|FTH^Father^HL70063|99 Wellington Street^^Carson City^NV^89701ÛSA^P|^PRN^PH^^^775^5558458ORC|RE|3598^wcEHR|94560^wcEHR|||||||9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN||724^Jordan^Vivian^Sarah^^^^^wcEHR^L^^^MD|||||wcEHR^West Clinic^HL70362RXA|0|1|20160720|20160720|49281-0560-05^Pentacel^NDC^120^DTaP-Hib-IPV^CVX|0.5|mL^mLÛCUM||00^New Record^NIP001|9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN|||||170167|20170118|PMC^Sanofi Pasteur^MVX|||CP|A||||||^^^wcEHRRXR|C28161Întramuscular^NCIT|RT^Right Thigh^HL70163OBX|1|CWE|30963-3^Vaccine Funding Source^LN|1|VXC50^Public^CDCPHINVS||||||F|||20160720OBX|2|CWE|64994-7^Vaccine Funding Program Eligibility^LN|2|V04^VFC Eligible - American Indian/Alaska Native^HL70064||||||F|||20160720OBX|3|CWE|69764-9^Document Type^LN|3|253088698300003511070517^Diphtheria/Tetanus/Pertussis (DTaP) VIS^cdcgs1vis||||||F|||20160720OBX|4|DT|29769-7^Date Vis Presented^LN|3|20160720||||||F|||20160720OBX|5|CWE|69764-9^Document Type^LN|4|253088698300006611150402^Haemophilus Influenzae type b VIS^cdcgs1vis||||||F|||20160720OBX|6|DT|29769-7^Date Vis Presented^LN|4|20160720||||||F|||20160720OBX|7|CWE|69764-9^Document Type^LN|5|253088698300017211160720^Polio Vaccine VIS^cdcgs1vis||||||F|||20160720OBX|8|DT|29769-7^Date Vis Presented^LN|5|20160720||||||F|||20160720OBX|9|TX|48767-8Ânnotation Comment^LN|6|Vaccine was reconstituted 15 minutes in advance of administration.||||||F|||20160720ORC|RE|4820^wcEHR|72363^wcEHR|||||||9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN||724^Jordan^Vivian^Sarah^^^^^wcEHR^L^^^MD|||||wcEHR^West Clinic^HL70362RXA|0|1|20160720|20160720|00006-4047-01^RotaTeq^NDC^116^rotavirus, pentavalent^CVX|0.5|mL^mLÛCUM||00^New Record^NIP001|9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN|||||73048|20161207|MSD^Merck and Co., Inc.^MVX|||CP|A||||||^^^wcEHRRXR|C38288Ôral^NCITOBX|1|CWE|30963-3^Vaccine Funding Source^LN|1|VXC50^Public^CDCPHINVS||||||F|||20160720OBX|2|CWE|64994-7^Vaccine Funding Program Eligibility^LN|2|V04^VFC Eligible - American Indian/Alaska Native^HL70064||||||


F|||20160720OBX|3|CWE|69764-9^Document Type^LN|3|253088698300019611150415^Rotavirus VIS^cdcgs1vis||||||F|||20160720OBX|4|DT|29769-7^Date Vis Presented^LN|3|20160720||||||F|||20160720ORC|RE|7021^wcEHR|82006^wcEHR|||||||9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN||724^Jordan^Vivian^Sarah^^^^^wcEHR^L^^^MD|||||wcEHR^West Clinic^HL70362RXA|0|1|20160720|20160720|00005-1971-01^Prevnar 13^NDC^133^Pneumococcal conjugate PCV 13^CVX|0.5|mL^mLÛCUM||00^New Record^NIP001|9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN|||||802701|20161123|PFR^Pfizer, Inc^MVX|||CP|A||||||^^^wcEHRRXR|C28161Întramuscular^NCIT|LT^Left Thigh^HL70163OBX|1|CWE|30963-3^Vaccine Funding Source^LN|1|VXC50^Public^CDCPHINVS||||||F|||20160720OBX|2|CWE|64994-7^Vaccine Funding Program Eligibility^LN|2|V04^VFC Eligible - American Indian/Alaska Native^HL70064||||||F|||20160720OBX|3|CWE|69764-9^Document Type^LN|3|253088698300015811151105^PCV13 Vaccine VIS^cdcgs1vis||||||F|||20160720OBX|4|DT|29769-7^Date Vis Presented^LN|3|20160720||||||F|||20160720ORC|RE|6183^wcEHR|96117^wcEHR|||||||9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN|||||||wcEHR^West Clinic^HL70362RXA|0|1|20160518|20160518|45^Hep B, unspecified formulation^CVX|999|||01^Historical Administration^NIP001|||||||||||CP|A||||||^^^wcEHRORC|RE|6939^wcEHR|40389^wcEHR|||||||9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN|||||||wcEHR^West Clinic^HL70362RXA|0|1|20160617|20160617|45^Hep B, unspecified formulation^CVX|999|||01^Historical Administration^NIP001|||||||||||CP|A||||||^^^wcEHR

2.3.7.2 UPDATE

After documenting vaccinations for Darren Wilson (see previous sample message) the clinician, Spencer Hill recognizes that an error was made during data entry for the Pneumococcal vaccine. The Lot Number was entered incorrectly. He updates the data in the EHR and transmits it to the IIS.

MSH|^~\&||wcEHR||IIS|20160720141214-0500||VXU^V04^VXU_V04|4866|P|2.8.2|||NE|AL|||||IZ22r1.0^CDCPHINVS|wcEHR|IISPID|1||998756^^^wcEHR^MR||Wilson^Darren^Franklin^^^^L|Scott^^^^^^M|20160517|M^Male^HL70001||1002-5Âmerican Indian or Alaska Native^CDCREC|99 Wellington Street^^Carson City^NV^89701ÛSA^P||^PRN^PH^^^775^5558458|||||||||2186-5^Not Hispanic or Latino^CDCREC||N|1|||||NPD1|||||||||||07^Recall only - no calls^HL70215|N|20160720|||AÂctive^HL70441|20160512|20160720NK1|1|Wilson^Tamara^Violet^^^^L|MTH^Mother^HL70063|99 Wellington Street^^Carson City^NV^89701ÛSA^P|^PRN^PH^^^775^5558458NK1|2|Wilson^Robert^^^^^L|FTH^Father^HL70063|99 Wellington Street^^Carson City^NV^89701ÛSA^P|^PRN^PH^^^775^5558458ORC|RE|7021^wcEHR|82006^wcEHR|||||||9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN||724^Jordan^Vivian^Sarah^^^^^wcEHR^L^^^MD|||||wcEHR^West Clinic^HL70362RXA|0|1|20160720|20160720|00005-1971-01^Prevnar 13^NDC^133^Pneumococcal conjugate PCV 13^CVX|0.5|mL^mLÛCUM||00^New Record^NIP001|9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN|||||807201|20161123|PFR^Pfizer, Inc^MVX|||CP|U||||||^^^wcEHRRXR|C28161Întramuscular^NCIT|LT^Left Thigh^HL70163OBX|1|CWE|30963-3^Vaccine Funding Source^LN|1|VXC50^Public^CDCPHINVS||||||F|||20160720OBX|2|CWE|64994-7^Vaccine Funding Program Eligibility^LN|2|V04^VFC Eligible - American Indian/Alaska Native^HL70064||||||F|||20160720OBX|3|CWE|69764-9^Document Type^LN|3|253088698300015811151105^PCV13 Vaccine VIS^cdcgs1vis||||||F|||20160720OBX|4|DT|29769-7^Date Vis Presented^LN|3|20150720||||||F|||20160720

2.3.7.3 DELETE

An adult female, Emily Smith, visits the West Clinic for a well woman visit. A clinic staff member collects basic patient demographic information including name, date of birth and administrative sex. A clinic provider, Vivian Jordan reviews the patient's vaccination history and determines she is in need of a tetanus booster and a dose of pertussis. Because of the patient's age she does not qualify for Vaccine For Children (VFC) supplied. Emily is given the appropriate Vaccine Information Sheet (VIS) to review. After reading it, she agrees to receive the recommended vaccination. She also agrees that the data should be shared once it is incorporated into the local IIS. An appropriate dose of Tdap is selected from the clinic's stock of privately funded vaccines. A clinician, Spencer Hill prepares and administers the doses to the patient and then enters the data into the EHR and transmits it to the IIS.


After administering the dose of Tdap, the clinician realizes that the vaccination was documented on the incorrect patient chart. He deletes the vaccination from the patient's chart and transmits the change to the IIS. He subsequently enters the data into the correct patient's chart and transmits it to the IIS (the message that shows the entry into the correct patient's chart is not shown below).

Initial message:MSH|^~\&||wcEHR||IIS|20160720130626-0500||VXU^V04^VXU_V04|90336|P|2.8.2|||NE|AL|||||IZ22r1.0^CDCPHINVS|wcEHR|IISPID|1||376122^^^wcEHR^MR||SmithÊmily^^^^^L||19790118|F^Female^HL70001||2106-3^White^CDCREC|324 Meadowood Court^^Carson City^NV^89701ÛSA^P||^PRN^PH^^^775^5556023~^PRNÎnternet^[email protected]|||||||||2186-5^Not Hispanic or Latino^CDCREC||N|1|||||NPD1|||||||||||02^Reminder/recall - any method^HL70215|N|20160720|||AÂctive^HL70441|19790118|20160720ORC|RE|8097^wcEHR|36380^wcEHR|||||||9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN||724^Jordan^Vivian^Sarah^^^^^wcEHR^L^^^MD|||||wcEHR^West Clinic^HL70362RXA|0|1|20160720|20160720|49281-0400-58Âdacel^NDC^115^Tdap^CVX|0.5|mL^mLÛCUM||00^New Record^NIP001|9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN|||||511875|20170803|PMC^Sanofi Pasteur^MVX|||CP|A||||||^^^wcEHRRXR|C28161Întramuscular^NCIT|RD^Right Deltoid^HL70163OBX|1|CWE|30963-3^Vaccine Funding Source^LN|1|PHC70^Private^CDCPHINVS||||||F|||20160720OBX|2|CWE|64994-7^Vaccine Funding Program Eligibility^LN|2|V01^Not VFC Eligible^HL70064||||||F|||20160720OBX|3|CWE|69764-9^Document Type^LN|3|253088698300027111150224^Tetanus/Diphtheria/Pertussis (Tdap) VIS^cdcgs1vis||||||F|||20160720OBX|4|DT|29769-7^Date Vis Presented^LN|3|20160720||||||F|||20160720

Deletion message:MSH|^~\&||wcEHR||IIS|20160720152726-0500||VXU^V04^VXU_V04|90512|P|2.8.2|||NE|AL|||||IZ22r1.0^CDCPHINVS|wcEHR|IISPID|1||376122^^^wcEHR^MR||SmithÊmily^^^^^L||19790118|F||2106-3^White^CDCREC|324 Meadowood Court^^Carson City^NV^89701ÛSA^P||^PRN^PH^^^775^5556023~^PRNÎnternet^[email protected]|||||||||2186-5^Not Hispanic or Latino^CDCREC||N|1|||||NPD1|||||||||||02^Reminder/recall - any method^HL70215|N|20160720|||AÂctive^HL70441|19790118|20160720ORC|RE|8097^wcEHR|36380^wcEHR|||||||9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN||724^Jordan^Vivian^Sarah^^^^^wcEHR^L^^^MD|||||wcEHR^West Clinic^HL70362RXA|0|1|20160720|20160720|49281-0400-58Âdacel^NDC^115^Tdap^CVX|0.5|mL^mLÛCUM||00^New Record^NIP001|9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN|||||511875|20170803|PMC^Sanofi Pasteur^MVX|||CP|D||||||^^^wcEHRRXR|C28161Întramuscular^NCIT|RD^Right Deltoid^HL70163OBX|1|CWE|30963-3^Vaccine Funding Source^LN|1|PHC70^Private^CDCPHINVS||||||F|||20160720OBX|2|CWE|64994-7^Vaccine Funding Program Eligibility^LN|2|V01^Not VFC Eligible^HL70064||||||F|||20160720OBX|3|CWE|69764-9^Document Type^LN|3|253088698300027111150224^Tetanus/Diphtheria/Pertussis (Tdap) VIS^cdcgs1vis||||||F|||20160720OBX|4|DT|29769-7^Date Vis Presented^LN|3|20160720||||||F|||20160720

2.3.7.4 REFUSAL

This scenario includes both accepted and refused vaccinations.

A 1 year old male, Owen Kevin Lark, is brought to the West Clinic for a well-child visit. He is accompanied by his father James Terrence Lark. A clinic staff member collects basic patient demographic information including name, date of birth and administrative sex. A clinic provider, Vivian Jordan reviews the patient's vaccination history and determines that the child requires Hib, Hep A, MMR and Varicella vaccinations. The child is covered by insurance and does not qualify for Vaccine For Children (VFC) supplied vaccines. The father is given the appropriate Vaccine Information Sheets (VIS) to review. After reading them, the father agrees that the child should receive the Hib, Hep A and MMR vaccines but refuses the Varicella vaccine. He also agrees that the data should be shared once it is incorporated into the local IIS. Appropriate doses of Hib, Hep A and MMR are selected from the clinic's stock of privately funded vaccines. A clinician, Spencer Hill prepares and administers the doses to the patient and then enters the data into the EHR and transmits it to the IIS.

MSH|^~\&||wcEHR||IIS|20160720132654-0500||VXU^V04^VXU_V04|48480|P|2.8.2|||NE|AL|||||IZ22r1.0^CDCPHINVS|wcEHR|IISPID|1||17782^^^wcEHR^MR||LarkÔwen^Kevin^^^^L||20150711|M^Male^HL70001||2106-3^White^CDCREC|111 44th


Ave^^Carson City^NV^89701ÛSA^P||^PRN^PH^^^775^5552971|||||||||2186-5^Not Hispanic or Latino^CDCREC||N|1|||||NPD1|||||||||||02^Reminder/recall - any method^HL70215|N|20150720|||AÂctive^HL70441|20150711|20160720NK1|1|Lark^James^Terrence^^^^L|FTH^Father^HL70063|111 44th Ave^^Carson City^NV^89701ÛSA^P|^PRN^PH^^^775^5552971ORC|RE|4428^wcEHR|8357^wcEHR|||||||9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN||724^Jordan^Vivian^Sarah^^^^^wcEHR^L^^^MD|||||wcEHR^West Clinic^HL70362RXA|0|1|20160720|20160720|49281-0547-58Âcthib^NDC^48^Hib (PRP-T)^CVX|0.5|mL^mLÛCUM||00^New Record^NIP001|9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN|||||88097|20170104|PMC^Sanofi Pasteur^MVX|||CP|A||||||^^^wcEHRRXR|C28161Întramuscular^NCIT|RT^Right Thigh^HL70163OBX|1|CWE|30963-3^Vaccine Funding Source^LN|1|PHC70^Private^CDCPHINVS||||||F|||20160720OBX|2|CWE|64994-7^Vaccine Funding Program Eligibility^LN|2|V01^Not VFC Eligible^HL70064||||||F|||20160720OBX|3|CWE|69764-9^Document Type^LN|3|253088698300006611150402^Haemophilus Influenzae type b VIS^cdcgs1vis||||||F|||20150620OBX|4|DT|29769-7^Date Vis Presented^LN|3|20160720||||||F|||20160720ORC|RE|2455^wcEHR|37487^wcEHR|||||||9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN||724^Jordan^Vivian^Sarah^^^^^wcEHR^L^^^MD|||||wcEHR^West Clinic^HL70362RXA|0|1|20160720|20160720|00006-4095-01^Vaqta^NDC^83^Hep A, ped/adol, 2 dose^CVX|0.5|mL^mLÛCUM||00^New Record^NIP001|9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN|||||131036|20161228|MSD^Merck and Co., Inc.^MVX|||CP|A||||||^^^wcEHRRXR|C28161Întramuscular^NCIT|RT^Right Thigh^HL70163OBX|1|CWE|30963-3^Vaccine Funding Source^LN|1|PHC70^Private^CDCPHINVS||||||F|||20160720OBX|2|CWE|64994-7^Vaccine Funding Program Eligibility^LN|2|V01^Not VFC Eligible^HL70064||||||F|||20160720OBX|3|CWE|69764-9^Document Type^LN|3|253088698300004211160720^Hepatitis A Vaccine VIS^cdcgs1vis||||||F|||20160720OBX|4|DT|29769-7^Date Vis Presented^LN|3|20160720||||||F|||20160720ORC|RE|7598^wcEHR|76819^wcEHR|||||||9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN||724^Jordan^Vivian^Sarah^^^^^wcEHR^L^^^MD|||||wcEHR^West Clinic^HL70362RXA|0|1|20160720|20160720|00006-4681-01^MMR^NDC^03^MMR^CVX|0.5|mL^mLÛCUM||00^New Record^NIP001|9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN|||||775088|20170201|MSD^Merck and Co., Inc.^MVX|||CP|A||||||^^^wcEHRRXR|C28161Întramuscular^NCIT|LT^Left Thigh^HL70163OBX|1|CWE|30963-3^Vaccine Funding Source^LN|1|PHC70^Private^CDCPHINVS||||||F|||20160720OBX|2|CWE|64994-7^Vaccine Funding Program Eligibility^LN|2|V01^Not VFC Eligible^HL70064||||||F|||20160720OBX|3|CWE|69764-9^Document Type^LN|3|253088698300012711120420^Measles/Mumps/Rubella VIS^cdcgs1vis||||||F|||20160720OBX|4|DT|29769-7^Date Vis Presented^LN|3|20150720||||||F|||20160720ORC|RE||9999^wcEHR|||||||9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN|||||||wcEHR^West Clinic^HL70362RXA|0|1|20160720|20160720|21^Varicella^CVX|999||||||||||||00^Parental decision^NIP002||RE|A||||||^^^wcEHR

2.3.7.5 PARTIAL ADMINISTRATION

This scenario also includes a decision not to share immunization data in the IIS.

An 18 month old male, Manuel Jose Vasquez, is brought to the West Clinic for a well-child visit by his mother Sofia Maria Vasquez. A clinic staff member collects basic patient demographic information including name, date of birth and administrative sex. A clinic provider, Vivian Jordan reviews the patient's vaccination history and determines that the child requires a Hep A vaccination. The child is covered by insurance and does not qualify for Vaccine For Children (VFC) supplied vaccines. The mother is given the Vaccine Information Sheet (VIS) to review. After reading it, the mother agrees that the child should receive the Hep A vaccine. However, she decides that the data should not be shared once it is incorporated into the local IIS. An appropriate dose of Hep A is selected from the clinic's stock of privately funded vaccines. A clinician, Spencer Hill prepares and administers the dose to the patient, however the patient moves unexpectedly during the administration and only a portion of the dose is actually administered. The clinician enters the data into the EHR as a partial administration and transmits it to the IIS.

MSH|^~\&||wcEHR||IIS|20160720133836-0500||VXU^V04^VXU_V04|32752|P|2.8.2|||NE|AL|||||IZ22r1.0^CDCPHINVS|wcEHR|IISPID|1||8009^^^wcEHR^MR||Vasquez^Manuel^Jose^^^^L||20150113|M^Male^HL70001||2106-3^White^CDCREC|42 Lincoln Way^^Carson City^NV^89701ÛSA^P||^PRN^PH^^^775^5555299|||||||||2135-2^Hispanic or Latino^CDCREC||N|1|||||NPD1|||||||||||04^Reminder only - any method^HL70215|Y|20150720|||AÂctive^HL70441|20150113|20150720NK1|1|Vasquez^Sofia^Maria^^^^L|MTH^Mother^HL70063|42 Lincoln Way^^Carson City^NV^89701ÛSA^P|^PRN^PH^^^775^5555299ORC|RE|9087^wcEHR|12149^wcEHR|||||||9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN||724^Jordan^Vivian^Sarah^^^^^wcEHR^L^^^MD|||||wcEHR^West Clinic^HL70362RXA|0|1|20160720|20160720|00006-4095-01^Vaqta^NDC^83^Hep A, ped/adol, 2 dose^CVX|0.5|mL^mLÛCUM||00^New


Record^NIP001|9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN|||||343288|20151005|MSD^Merck and Co., Inc.^MVX|||PA|A||||||^^^wcEHRRXR|C28161Întramuscular^NCIT|LT^Left Thigh^HL70163OBX|1|CWE|30963-3^Vaccine Funding Source^LN|1|PHC70^Private^CDCPHINVS||||||F|||20150720OBX|2|CWE|64994-7^Vaccine Funding Program Eligibility^LN|2|V01^Not VFC Eligible^HL70064||||||F|||20160720OBX|3|CWE|69764-9^Document Type^LN|3|253088698300004211160720^Hepatitis A Vaccine VIS^cdcgs1vis||||||F|||20160720OBX|4|DT|29769-7^Date Vis Presented^LN|3|20160720||||||F|||20160720

2.3.7.6 PATIENT CONDITION

A 28 year old female, Hazel Jackson goes to the West Clinic for a checkup. A clinic staff member collects basic patient demographic information including name, date of birth and administrative sex. Hazel indicates that she is a smoker. She also reports that she recently received her yearly influenza vaccine A clinician, Spencer Hill enters the data into the EHR and transmits it to the IIS.

MSH|^~\&||wcEHR||IIS|20161120142514-0500||VXU^V04^VXU_V04|4850|P|2.8.2|||NE|AL|||||IZ22r1.0^CDCPHINVS|wcEHR|IISPID|1||14445^^^wcEHR^MR||Jackson^Hazel^^^^^L|Willis^^^^^^M|19900312|F^Female^HL70001||2131-1Ôther race^CDCREC|2501 Duval Street^Âustin^TX^78704ÛSA^P||^PRN^PH^^^512^5559812|||||||||2186-5^Not Hispanic or Latino^CDCREC||N|1|||||NPD1|||||||||||07^Recall only - no calls^HL70215|N|20161120|||AÂctive^HL70441|20160517|20161120OBX|1|CWE|75323-6^Condition^LN|1|77176002^Smoker [finding]^SCT||||||F|||20161120OBX|2|DT|85585-8^Date ofCondition Onset^LN|1|20140522||||||F|||20161120ORC|RE||63434^wcEHR|||||||9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRNRXA|0|1|20161103|20161103|88înfluenza, unspecified formulation^CVX |999|||01^Historical Administration^NIP001|||||||||||CP|A||||||^^^wcEHR

2.3.7.7 SPECIAL INDICATION

A 27 year old female, Jackie Helena McGillis goes to the West Clinic for a checkup. A clinic staff member collects basic patient demographic information including name, date of birth and administrative sex. A clinic provider, Vivian Jordan reviews the patient's medical and vaccination history and determines that Jackie requires a pneumococcal (polysaccharide) vaccination because she is a smoker. Because of the patient's age she does not qualify for Vaccine For Children (VFC) supplied. Jackie is given the Vaccine Information Sheet (VIS) to review. After reading it, she agrees that she should receive the pneumococcal vaccine. She also agrees that the data should be shared once it is incorporated into the local IIS. An appropriate dose of Pneumovax 23 is selected from the clinic's stock of privately funded vaccines. A clinician, Spencer Hill prepares and administers the doses to the patient and then enters the data into the EHR, including an indication of smoking and transmits it to the IIS

MSH|^~\&||wcEHR||IIS|20160720142514-0500||VXU^V04^VXU_V04|4850|P|2.8.2|||NE|AL|||||IZ22r1.0^CDCPHINVS|wcEHR|IISPID|1||8845^^^wcEHR^MR||McGillis^Jackie^Helena^^^^L|Mitchell^^^^^^M|19890207|F^Female^HL70001||2131-1Ôther race^CDCREC|101 South Congress Ave^Âustin^TX^78704ÛSA^P||^PRN^PH^^^512^5550090|||||||||2186-5^Not Hispanic or Latino^CDCREC||N|1|||||NPD1|||||||||||07^Recall only - no calls^HL70215|N|20160720|||AÂctive^HL70441|20160517|20160720ORC|RE|89001^wcEHR|11213^wcEHR|||||||9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN||724^Jordan^Vivian^Sarah^^^^^wcEHR^L^^^MD|||||wcEHR^West Clinic^HL70362RXA|0|1|20160720|20160720|00006-4943-01^Pneumovax 23^NDC |0.5|mL^mLÛCUM||00^New Record^NIP001|9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN|||||56345|20170126|MSD^Merck and Co., Inc^MVX|||CP|A||||||^^^wcEHRRXR|C28161Întramuscular^NCIT|RD^Right Deltoid^HL70163OBX|1|CWE|30963-3^Vaccine Funding Source^LN|1|PHC70^Private^CDCPHINVS||||||F|||20160720OBX|2|CWE|64994-7^Vaccine Funding Program Eligibility^LN|2|V01^Not VFC Eligible^HL70064||||||F|||20160720OBX|3|CWE|69764-9^Document Type^LN|3|253088698300016511150424^Pneumococccal Polysaccharide VIS^cdcgs1vis||||||F|||20160720OBX|4|DT|29769-7^Date Vis Presented^LN|3|20160720||||||F|||20160720OBX|5|CWE|59785-6Îndication for Immunization^LN|4|77176002^Smoker [finding]^SCT||||||F|||20160720


2.3.7.8 ADVERSE REACTION

After the administration of Pneumovax 23 to a 27 year old female, Jackie Helena McGillis, during checkup (see previous sample message), an adverse reaction is noted. A clinic staff member documents the adverse reaction in the EHR and transmits it to the IIS as an update to the original vaccination event.

MSH|^~\&||wcEHR||IIS|20160721091801-0500||VXU^V04^VXU_V04|4922|P|2.8.2|||NE|AL|||||IZ22r1.0^CDCPHINVS|wcEHR|IISPID|1||8845^^^wcEHR^MR||McGillis^Jackie^Helena^^^^L|Mitchell^^^^^^M|19890207|F^Female^HL70001||2131-1Ôther race^CDCREC|101 South Congress Ave^Âustin^TX^78704ÛSA^P||^PRN^PH^^^512^5550090|||||||||2186-5^Not Hispanic or Latino^CDCREC||N|1|||||NPD1|||||||||||07^Recall only - no calls^HL70215|N|20160720|||AÂctive^HL70441|20160517|20160720ORC|RE|89001^wcEHR|11213^wcEHR|||||||9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN||724^Jordan^Vivian^Sarah^^^^^wcEHR^L^^^MD|||||wcEHR^West Clinic^HL70362RXA|0|1|20160720|20160720|00006-4943-01^Pneumovax 23^NDC |0.5|mL^mLÛCUM||00^New Record^NIP001|9914^Hill^Spencer^Tyler^^^^^wcEHR^L^^^PRN|||||56345|20170126|MSD^Merck and Co., Inc^MVX|||CP|U||||||^^^wcEHRRXR|C28161Întramuscular^NCIT|RD^Right Deltoid^HL70163OBX|1|CWE|30963-3^Vaccine Funding Source^LN|1|PHC70^Private^CDCPHINVS||||||F|||20160720OBX|2|CWE|64994-7^Vaccine Funding Program Eligibility^LN|2|V01^Not VFC Eligible^HL70064||||||F|||20160720OBX|3|CWE|69764-9^Document Type^LN|3|253088698300016511150424^Pneumococccal Polysaccharide VIS^cdcgs1vis||||||F|||20160720OBX|4|DT|29769-7^Date Vis Presented^LN|3|20160720||||||F|||20160720OBX|5|CWE|59785-6Îndication for Immunization^LN|4|77176002^Smoker [finding]^SCT||||||F|||20160720OBX|6|CWE|31044-1Îmmunization reaction^LN|5|VXC14^Rash within 14 days of dose^CDCPHINVS||||||F|||20160721

2.3.7.9 SUCCESS ACKNOWLEDGMENT

An EHR-S records a new administration and generates a VXU message and sends it to the IIS. The IIS returns a positive acknowledgement message indicating that no errors were found during the course of processing the message.

Initial message MSH segment:MSH|^~\&||wcEHR||IIS|20160721121329-0500||VXU^V04^VXU_V04|86150|P|2.8.2|||NE|AL|||||IZ22r1.0^CDCPHINVS|wcEHR|IIS

ACK message:MSH|^~\&||IIS||wcEHR|20160721121406-0500||ACK^V04ÂCK|31210|P|2.8.2|||NE|NE|||||IZ23r1.0^CDCPHINVS|IIS|wcEHRMSA|AA|86150

Note that MSH-10 from the initial message is echoed back in MSA-2 of the acknowledgement message and that MSH-10 of the acknowledgement message is a unique value.

2.3.7.10 MESSAGE REJECTION ACKNOWLEDGEMENT

An EHR records a new administration and generates a VXU message and sends it to the IIS. Due to a configuration error, the wrong HL7 version is sent in MSH-12. The IIS is unable to process the message due to the incorrect HL7 version and rejects the message.

MSH|^~\&||IIS||wcEHR|20150721121047-0500||ACK^V04ÂCK|67112|P|2.8.2|||NE|NE|||||IZ23r1.0^CDCPHINVS|IIS|wcEHRMSA|AR|39077ERR||MSH^1^12^1^1|203Ûnsupported Version ID^HL70357|E||||Version ID not recognized - message rejected


2.3.7.11 MESSAGE PROCESSING ERROR ACKNOWLEDGEMENT

An EHR records a new administration and generates a VXU message and sends it to the IIS. Due to a mapping error in a CVX table, the IIS is unable to recognize the CVX code sent in RXA-5. The IIS is unable to identify the appropriate vaccine, which is a required element, and cannot process the message.

MSH|^~\&||IIS||wcEHR|20160721121047-0500||ACK^V04ÂCK|67112|P|2.8.2|||NE|NE|||||IZ23r1.0^CDCPHINVS|IIS|wcEHRMSA|AE|39077ERR||RXA^1^5^1^1|207Âpplication error^HL70357|E|5^Table value not found^HL70533|||Vaccine code not recognized - message rejected

2.3.7.12 MESSAGE PROCESSING WARNING ACKNOWLEDGEMENT

An EHR records a new administration and generates a VXU message and sends it to the IIS. The EHR populates PID-2 which is an unsupported field. The IIS is able to process the message but sends back a warning that PID-2 was not used.

MSH|^~\&||IIS||wcEHR|20160721131116-0500||ACK^V04ÂCK|32851|P|2.8.2|||NE|NE|||||IZ23r1.0^CDCPHINVS|IIS|wcEHRMSA|AE|76112ERR||PID^1^2|207Âpplication error^HL70357|W||||PID-2 is not supported - data ignored

2.4 Use Case 2-Send Demographics Data Only

2.4.1 CONTEXT

Goal: The goal of this use case is to send only demographic data about a patient. It may be an update or a new record. Only an ADT message may be used to fulfill this use case. A VXU message without an order segment group may not be used for this purpose, although demographic updates may be sent as part of a VXU message adding, deleting or updating an immunization event.

Trigger Event: A user in the initiating system adds or updates one or more elements of the patient's demographics data. The nature of the triggering action and set of patients that are valid to be exchanged are beyond the scope of the document and should be agreed upon locally by trading partners. The triggering criteria will be included in future functional requirements guidance documents.

Initial Message Profiles: IZ24r1.0 (ADT)

Responding System Outcome: The responding system processes the IZ24r1.0 message per local business rules and returns a response message, including errors if any.

Response Message Profile: IZ23r1.0 (ACK)

Initiating System Outcome: The initiating system processes the IZ23r1.0 acknowledgement message. Relevant content from the IZ23r1.0 message, such as error related data, is stored or displayed to end users.

Processing Mode: The goal of the Send Demographics Data Only use case is to send up-to-date demographics information about a patient. The data within the message should represent the complete set of demographics data about the patient as known by the system originating the message.


2.4.2 USER STORY

A typical user story for the Send Demographics Data Only use case is as follows. A patient calls the clinic to report an address change. A staff person locates the patient's record in the appropriate application and updates the address. An action by the staff person triggers an update message to the IIS.


This sequence diagram illustrates the message flow for the Send Demographics Data Only use case. The initiating system sends an ADT message. The trigger may be a new record or an update of an existing record. The responding system accepts the message and processes it. The responding system sends an acknowledgment in an ACK message, including any relevant error information.

It is important to note that the messages may pass through intermediaries, such as a Health Information Exchange (HIE). The message comes from the initiating system and the acknowledgement MUST be returned to that initiating system.

FIGURE 2-5 SEND DEMOGRAPHIC DATA ONLY SEQUENCE DIAGRAM


This activity diagram illustrates the expected flow of events. Some event triggers the initiating system to create and send a demographics only message. The responding system accepts the message. If the message is of an unsupported message type, has an unsupported event code, has an unsupported processing ID, has an unsupported version ID or is unable to be processed for reasons unrelated to format or content, then the responding system returns an ACK with the acknowledgement code of "AR". Otherwise, the responding system continues to process the message. It parses the message and processes per the specifications of this profile


and applies local business rules. If there are no errors, the acknowledgment code is set to "AA". If there are errors, the acknowledgement code is set to "AE". If the errors are fatal, then the message is rejected, otherwise the data are integrated into the responding system. The acknowledgement code is returned to the initiating system in an ACK message.


FIGURE 2-6 SEND DEMOGRAPHICS ONLY MESSAGE ACTIVITY DIAGRAM

2.4.5 SCENARIOS

2.4.5.1 RETURNING SUCCESS ACKNOWLEDGEMENTS

The initiating system should expect to receive an acknowledgment message, even when the responding system has successfully processed the message. Similarly, the responding system must be prepared to send an acknowledgement even when it has successfully processed the message. The purpose of this success acknowledgement is to inform the originating system that the data were received and processed.


The responding system will respond with an Acknowledgement Code (MSA-1) of AA.

While not recommended, in this scenario, an optional ERR segment may be sent with an Error Code and a Severity (ERR-4) of I. Such a segment would indicate that the responding system wishes to inform the originating system of additional non-error information.

2.4.5.2 RETURNING MESSAGE REJECTION ACKNOWLEDGEMENTS

A responding system will reject the message and respond with an Acknowledgement Code (MSA-1) of AR only under one of the following conditions:

Unsupported Message Type Unsupported Event Code Unsupported Processing ID Unsupported Version ID Unable to process for reasons unrelated to format or content

2.4.5.3 RETURNING MESSAGE PROCESSING ERROR/WARNING ACKNOWLEDGEMENTS

A responding system will respond with an Acknowledgement Code (MSA-1) of AE upon encountering one or more errors with a severity of Error or Warning.

A responding system may reject some or all of a message based on HL7 rules, including the following conditions:

Empty or missing Required segment(s) not in a segment group Empty or missing Required segment(s) group Empty or missing Required segment(s) in a segment group Empty or missing Required field(s) in a Required segment

There may be additional rules that a receiving system enforces beyond those defined by HL7 definitions. For example, a local business rule may be that the patient address be within the jurisdiction of the IIS. Violation of this rule would generate an error.


2.4.6.1 SENDING NEW PATIENT DATA

When a new patient is first documented in the initiating system, a new patient message may be generated. Trading partners must agree when a new demographics only message will be used.

2.4.6.2 SENDING UPDATED PATIENT DATA

When one or more elements of a patient's demographics data are updated in the initiating system, a patient update message may be generated. Trading partners must agree when a demographics only update message will be used. Note that the format and content of the update message are the same as for a "new patient" demographics only message.


The sample messages contained in this section of the document are for illustration purposes and should not form the basis of system design. Readers should not infer any requirements solely from these messages.


2.4.7.1 PATIENT DEMOGRAPHICS

Note that there is no difference in message content or structure when transmitting a new patient versus updating an existing patient.

An 8 year old female, Janet Danielle Malone, is brought to the East Clinic for a well-child visit by her mother Sarah Kimberly Malone (nee Andrews) and her father Christopher Malone. A clinic staff member confirms and updates basic patient demographic information including name, date of birth, administrative sex and address. A clinic provider reviews the patient's vaccination history and determines that the child's immunization history is up to date and no vaccines are required at this visit. The updated demographics data are transmitted to the IIS.

MSH|^~\&||ecEHR||IIS|20160705101514-0500||ADTÂ31ÂDT_A05|99076|P|2.8.2|||NE|AL|||||IZ24r1.0^CDCPHINVS|ecEHR|IISEVN||20160705101514PID|1||54098^^êcEHR^MR||Malone^Janet^Danielle^^^^L|Andrews^^^^^^M|20080701|F^Female^HL70001||2054-5^Black or African-American^CDCREC|324 Nortel Drive^^Mooresville^NC^28115ÛSA^P||^PRN^PH^^^704^5550024|||||||||2186-5^Not Hispanic or Latino^CDCREC||N|1|||||NPD1|||||||||||07^Recall only - no calls^HL70215|N|20160705|||AÂctive^HL70441|20080701|20160705NK1|1|Malone^Sarah^Kimberly^^^^L|MTH^Mother^HL70063|324 Nortelrive^^Mooresville^NC^28115ÛSA^P|^PRN^PH^^^704^5550024~^PRS^CP^^^704^5555033NK1|2|Malone^Christopher^^^^^L|FTH^Father^HL70063|324 Nortel Drive^^Mooresville^NC^28115ÛSA^P|^PRN^PH^^^704^5550024PV1||N

2.4.7.2 SUCCESS ACKNOWLEDGMENT

An EHR records a patient demographics update and generates an ADT message and sends it to the IIS. The IIS returns a positive acknowledgement message indicating that no errors were found during the course of processing the message.

Initial message MSH segment:MSH|^~\&||ecEHR||IIS|20160721121329-0500||ADTÂ31ÂDT_A05|86150|P|2.8.2|||NE|AL|||||IZ24r1.0^CDCPHINVS|ecEHR|IIS

ACK message:MSH|^~\&||IIS||ecEHR|20160721121342-0500||ACKÂ31ÂCK|31210|P|2.8.2|||NE|NE|||||IZ23r1.0^CDCPHINVS|IIS|ecEHRMSA|AA|86150

Note that MSH-10 from the initial message is echoed back in MSA-2 of the acknowledgement message and that MSH-10 of the acknowledgement message is a unique value.

2.4.7.3 MESSAGE REJECTION ACKNOWLEDGEMENT

An EHR records a patient demographics update and generates an ADT message and sends it to the IIS. Due to a configuration error, the wrong HL7 version is sent in MSH-12. The IIS is unable to process the message due to the incorrect HL7 version and rejects the message.

MSH|^~\&||IIS||ecEHR|20160721121047-0500||ACKÂ31ÂCK|67112|P|2.8.2|||NE|NE|||||IZ23r1.0^CDCPHINVS|IIS|ecEHRMSA|AR|39077ERR||MSH^1^12^1^1|203Ûnsupported Version ID^HL70357|E||||Version ID not recognized - message rejected



An EHR records a patient demographics update and generates an ADT message and sends it to the IIS. Due to a mapping error, the IIS is unable to recognize the patient's administrative sex transmitted in PID-8. The IIS is unable to identify the appropriate sex, which is a required element, and cannot process the message.

MSH|^~\&||IIS||ecEHR|20160721121047-0500||ACKÂ31ÂCK|67112|P|2.8.2|||NE|NE|||||IZ23r1.0^CDCPHINVS|IIS|ecEHRMSA|AE|39077ERR||PID^1^8^1^1|207Âpplication error^HL70357|E|5^Table value not found^HL70533|||Administrative Sex not recognized - message rejected

2.4.7.5 MESSAGE PROCESSING WARNING ACKNOWLEDGEMENT

An EHR records a patient demographics update and generates an ADT message and sends it to the IIS. The EHR populates PID-2 which is an unsupported field. The IIS is able to process the message but sends back a warning that PID-2 was not used.

MSH|^~\&||IIS||ecEHR|20160721131116-0500||ACKÂ31ÂCK|32851|P|2.8.2|||NE|NE|||||IZ23r1.0^CDCPHINVS|IIS|ecEHRMSA|AE|76112ERR||PID^1^2|207Âpplication error^HL70357|W||||PID-2 is not supported - data ignored

2.5 Use Case 3-Request History with Forecast

2.5.1 CONTEXT

Goal: The goal of this query is to provide the patient's complete consolidated immunization history along with clinical decision support including evaluation of the immunization history along with a forecast of future doses due.

Trigger Event: The initiating system requests an immunization history with forecast using demographic information and/or other identifiers. The request may be initiated by end user activity (e.g. clicking a button) or by an automated process (e.g. automatically at patient arrival).

Initial Message Profiles: IZ54r1.0 (QBP)

Responding System Outcome: The responding system processes the message and returns a response message, including an error if appropriate. Multiple outcomes are possible including:

1 One patient matches the criteria sent2 One or more patients match the criteria sent (inexact match)3 No patients match the criteria sent4 A match is found but the patient has requested that their data not be shared5 There was an error in the structure or content of the query or other problems that prevented the

identification of a matching patient

Response Message Profile: IZ52r1.0 (RSP), IZ31r1.0 (RSP), IZ33r1.0 (RSP), IZ23r1.0 (ACK)

Initiating System Outcome: The initiating system processes the response message, consuming patient data when returned. Typically, the content is presented to the person who requested the evaluated history and forecast.


Processing Mode: The goal of an IZ52r1.0 message is to return a complete and evaluated history with forecast in response to a query request. It is intended to be displayed back to the requesting provider to inform clinical care. The evaluated history portion of the message contains all immunizations for the patient known to the responding system. Some or all of these will be evaluated against a set of rules, such as those developed by the Advisory Committee on Immunization Practices (ACIP). This message is intended to return all the details expected of a complete immunization history along with the evaluation. The data within any single order group (set of one ORC segment, one RXA segment and associated RXR and OBX segments, if any) should represent the complete set of data as known by the system originating the response message.

TABLE 2-6 RESPONSE TO DIFFERENT OUTCOMESOutcome of Query Response Message

No match foundProfile IZ33r1.0 - Response indicates that message was successfully processed and that no patients matched the criteria that were sent in the query.

Exactly one high confidence match found Profile IZ52r1.0 - Response includes a complete immunization history with evaluation and forecast.

At least one lower confidence match is found, but <= maximum number allowed (More than one high confidence match is considered a set of lower confidence matches)

Profile IZ31r1.0 - If state law allows, the Response returns one PID with associated NK1 segments for each potential match. No immunization history is returned. Alternatively, the IZ33r1.0 profile may be used to indicate that no matching patient was found.

Exactly one protected patient is found

Profile IZ33r1.0 - If state law allows, the Response returns a message where QAK-2 = PD. No immunization history is returned. Alternatively, the IZ33r1.0 profile may be used to indicate that no matching patient was found.

More than the maximum number of matches allowed are found

Profile IZ33r1.0 - Response indicates that the message was successfully processed, but that too many potential matches were found. The maximum number allowed is the lower of the maximum number requested and the maximum number that the responding system will return.

Message is not well formed and has fatal errors Profile IZ33r1.0 - Response indicates that the message was not successfully processed and will indicate the error.

Message was rejected because one of the following occurred:

Unsupported message type Unsupported event code Unsupported processing ID Unsupported version ID Unable to process for reasons

unrelated for format or content

Profile IZ23r1.0 - Acknowledgement indicates that the message was not successfully processed and will indicate the errors.

Note that the system responding must deal with the situation where a patient has indicated that his/her records must be protected. System behavior should be clearly documented.

2.5.2 USER STORY

A typical user story for the Request History with Forecast use case is as follows. A child is brought to the clinic for an annual visit. A staff person locates the child's medical record in the EHR-S. The staff person triggers a


request to the IIS for a history with forecast for the child. The IIS performs a search based on the patient demographic data sent in the query request and finds one high-confidence match. The IIS generates a complete and evaluated history with forecast for the patient and returns this to the EHR-S. The EHR-S displays the history and forecast.


The following sequence diagram shows the message flows involved for one possible outcome for this use case. The initiating system creates a query and sends it. The responding system sends a response. The figure below assumes that a single high threshold patient match is found by the responding system, but other possible outcomes, including matching to 0 patients or multiple patients follow a similar sequence, the difference being the profile of the message returned.

FIGURE 2-7 REQUEST EVALUATED HISTORY AND FORECAST SEQUENCE DIAGRAM (SINGLE MATCH FOUND)


The following activity diagrams show the flow of activities associated with this use case. An event triggers the initiating system to create and send a history with forecast query message. The responding system accepts the message. If the message is of an unsupported message type, has an unsupported event code, has an unsupported processing ID, has an unsupported version ID or is unable to be processed for reasons unrelated to format or content, then the responding system returns an ACK with the acknowledgement code of "AR". Otherwise, the responding system continues to process the message. It parses the message and processes per the specifications of this profile and applies local business rules. If there are no errors, the acknowledgment code is set to "AA". If there are errors, the acknowledgement code is set to "AE". If the errors are fatal, then the


message is rejected, otherwise the data are used to identify a matching patient in the responding system. Depending on the outcome of that search, one of several possible profiles is used to construct the RSP message. The acknowledgement code is returned to the initiating system in the response message.

FIGURE 2-8 REQUEST HISTORY WITH FORECAST ACTIVITY DIAGRAM


FIGURE 2-9 PROCESS QUERY ACTIVITY DIAGRAM

Note that if local laws, regulations or policy prevent the return of any indication of multiple matching patients, returning a QAK-2 value of NF is also an acceptable QAK-2 value for the ">1 found" outcome.

2.5.5 SCENARIOS

Local implementations will specify which fields are used in patient matching. The responding system must accept values in any of these fields but may determine which are used for patient matching and which will be ignored.

2.5.5.1 QUERY PROCESSING OUTCOME

Responding to a QBP query message is complex, as multiple outcomes are possible ranging from the outright rejection of the message to a successful search resulting in one or more matching records. The message profile, (MSH-21) Acknowledgment Code (MSA-1), the Query Response Status (QAK-2) and the Error Severity (ERR-4) are all dependent upon the outcome of processing the query message and must be in agreement and appropriate for the outcomes of the processing of the initial message.

An RSP^K11 message may contain only a single ERR segment. When multiple errors are encountered when processing a single message, it is left to the responding system to select the most salient error to return in the response message.


Three basic outcomes are possible from query message processing: Message is rejected

o Occurs when any of the following conditions are met The message is of an unsupported message type (MSH-9) The message has an unsupported event code (MSH-9) The message has an unsupported processing ID (MSH-11) The message has an unsupported version ID (MSH-12) The message is unable to be processed for reasons unrelated to format or content

o IZ23 (ACK) profile is the appropriate response profileo MSA-1 must be AR and an ERR segment must be presento ERR-4 must be E indicating that the originating system should investigate/correct the issue

and resubmit the messageo The IZ23 (ACK) profile message does not include a QAK segment

An error is encountered which prevents successful execution of the queryo Occurs when the query fails for a reason other than the conditions outlined aboveo The IZ33 profile is the appropriate response profileo MSA-1 must be AEo QAK-2 must be AE

QAK-2 may not be AR as that indicates failure due to one of the five conditions described above which requires the use of the IZ23 profile

QAK-2 may not be OK, PD, TM or NF as those indicate a successful query outcomeo ERR-4 must be E indicating that the originating system should investigate/correct the issue

and resubmit the message Query is successfully processed

o Occurs when the query is successfully processed, regardless of the number of matching patients found (i.e., finding 0 or more than 1 matching patients is considered a "successful" query if the search executes and completes)

o The IZ31, IZ33 or IZ52 profiles may be used depending on the outcome of the search. Regardless of which profile is used for the response message, the same guidance applies

o MSA-1 will be AA if no errors are encountered (i.e., the message does not contain an ERR segment)

o MSA-1 may also be AA if an ERR segment where ERR-4 is equal to I is includedo MSA-1 will be AE if one or more errors are encountered but none are severe enough to

prevent the successful completion of the search (regardless of the outcome of the search) The message must contain an ERR segment with ERR-4 equal to W ERR-4 may not be E as that indicates a severe enough error that the originating

system must resubmit the query messageo QAK-2 should always reflect the outcome of the query and is independent of the

Acknowledgement Code in MSA-1 QAK-2 may not be AR as that indicates failure due to one of the five conditions

described above which requires the use of the IZ23 profile QAK-2 may not be AE as that indicates a severe enough error to prevent the search

from successfully executing (see previous scenario)

The Acknowledgment Code (MSA-1) and Query Response Status (QAK-2) are independent of each other as they represent the outcome of technical processing the message and results of the query search respectively. However, the values that are appropriate to use in these fields are constrained by the outcome of the processing of the message and the execution of the search query. The tables below summarize the appropriate


values by outcome. Keep in mind that in an RSP response message, only a single ERR segment is allowed due to constraints on the message structure imposed by the v2.8.2 base HL7 standard.

TABLE 2-7 SUMMARY OF ACKNOWLEDGEMENT CODE BY ERROR CONDITIONOutcome of Processing RSP ValuesRejection error encountered for MSH-9, -11 or -12, or reason unrelated for format or content MSA-1 = AR; ERR-4 = E

Fatal error encountered MSA-1 = AE; ERR-4 = EWarning error encountered MSA-1 = AE; ERR-4 = WInformational error encountered MSA-1 = AA; ERR-4 = INo error encountered MSA-1 = AA; No ERR segment

TABLE 2-8 SUMMARY OF PROFILE AND QUERY RESPONSE STATUS BY QUERY OUTCOMEOutcome of Query RSP ValuesMessage rejection error IZ23 (no QAK segment)Message processing error IZ33 (QAK-2 = AE)No match found IZ33 (QAK-2 = NF)One match found (data sharing is allowed) IZ52 (QAK-2 = OK)One match found (data sharing is not allowed) IZ33 (QAK-2 = PD) or IZ33 (QAK-2 = NF)Multiple matches found (but less than the maximum allowed) IZ31 (QAK-2 = OK) or IZ33 (QAK-2 = NF)More than the maximum number of allowed matches found IZ33 (QAK-2 = NF or TM)

2.5.5.2 REQUESTING A HISTORY WITH FORECAST

A user or system initiates a compete and evaluated history with forecast query to an IIS using the IZ54 history with forecast profile. The triggering event may be a manual action (e.g. clicking a button) or an automated system task. This scenario is a prerequisite for the remaining scenarios.

2.5.5.3 RETURNING A SINGLE HIGH THRESHOLD MATCH

A user or system initiates a complete and evaluated history with forecast query using the IZ54 history with forecast profile.

The responding system consumes the query message A single high threshold matching patient is found, the responding system returns a message using

the IZ52 profile including patient demographics, immunization history and forecast. Key message characteristics are:o MSA-1 = AA or AE if only a warning (non-significant error) is returnedo QAK-2 = OK

The initiating system consumes the response message and makes the patient immunization history and forecast available for end users.

2.5.5.4 RETURNING A PROTECTED PATIENT

When a patient who does not want his/her data shared is found, local business rules need to be applied. System behavior will be dictated by local laws, regulations and IIS policy. For instance, some applications may behave as if the record does not exist in the system. That is, it would respond with a no records found message. Another response might be to send limited information notifying the requesting system that the person exists but wants his/her records protected. In the latter case, the following scenario is used


A user or system initiates a complete and evaluated history with forecast query using the IZ54 history with forecast profile

The responding system consumes the query message A single high threshold matching patient is found, the responding system returns a message using

the IZ33 profile including patient demographics and an error segment indicating a match was found in the IIS but no immunization history or forecast is returned since Data Sharing for the record is set to No. Key message characteristics are:o MSA-1 = AAo ERR-4 = Io ERR-8 is populated with a text string noting that a protected patient was foundo QAK-2 = PD

The initiating system consumes the response message and indicates to end users that a protected match was found

2.5.5.5 RETURNING NO MATCHING PATIENTS


The responding system consumes the query message No high threshold matching patients are found, the responding system returns a message using the

IZ33 profile indicating that no patients were found using the criteria in the query. Key message characteristics are:o MSA-1 = AA or AE if only a warning (non-significant error) is returnedo QAK-2 = NF

The initiating system consumes the response message and indicates that no matching patients were found.

2.5.5.6 RETURNING MORE THAN THE MAXIMUM NUMBER PATIENTS FOUND

If local laws, regulations and IIS policy don't strictly prohibit indicating that more than the maximum number of matching patients were found, the following scenario applies:


The responding system consumes the query message Multiple high threshold matching patients are found and that number exceeds the maximum number

allowed by either system, the responding system returns a message using the IZ33 profile indicating that too many candidate patients were found using the criteria in the query. Key message characteristics are:o MSA-1 = AA or AE if only a warning (non-significant error) is returnedo QAK-2 = TM

The initiating system consumes the response message and indicates to end users that too many matching patients were found.

2.5.5.7 RETURNING MULTIPLE MATCHING PATIENTS

If local laws, regulations and IIS policy don't strictly prohibit returning multiple high threshold matching patients, the following scenario applies


The responding system consumes the query message


Multiple high threshold matching patients are found, the responding system returns a message using the IZ31 profile indicating that multiple matching patients were found using the criteria in the query. Only patient demographics are returned. Key message characteristics are:o MSA-1 = AA or AE if only a warning (non-significant error) is returnedo QAK-2 = OK

The initiating system consumes the response message and indicates that multiple matching patients were found. The patient demographics may be used to refine the search criteria and trigger a new query.

2.5.5.8 RETURNING MESSAGE PROCESSING ERROR ACKNOWLEDGEMENT


The responding system attempts to consume the query message One or more fatal errors are encountered, the responding system returns a message using the IZ33

profile indicating that the message was not successfully processed. Key message characteristics are:o MSA-1 = AEo QAK-2 = AE

The initiating system consumes the response message and indicates that processing of the message failed.

2.5.5.9 RETURNING MESSAGE REJECTION ACKNOWLEDGEMENTS


The responding system attempts to consume the query message One or more of the following errors are encountered, the responding system returns a message

using the IZ23 profile indicating that the message was not successfully processed.o Unsupported Message Typeo Unsupported Event Codeo Unsupported Processing IDo Unsupported Version IDo Unable to process for reasons unrelated to format or content

The initiating system consumes the response message and indicates that processing of the message failed.


The specific content of the RSP^K11 message will vary with the patient context and history. The Messaging Capabilities section below will specify how to send particular data for the following types of data:

Evaluation - comparison of the already administered doses in a patient's immunization history against a schedule of recommended immunizations

Forecast - recommendations for future doses based on a schedule of recommended immunizations

2.5.6.1 EVENT DETAILS

While this use case revolves around the ability to return an evaluation of the patient immunization history along with a personalized forecast of future doses, the content of the evaluated history and forecast message may also contain data submitted as part of use case 1. Thus, the RSP message may include:

A Person Observation group containing observations such as conditions and evidence of immunity


Special indications Refused doses Contraindicated doses Partial administrations

Refer back to use case 1 for a description of how this data is transmitted in a message.

2.5.6.2 EVALUATION

Evaluating an immunization history, based on the recommendations of the ACIP schedule or other schedule is an important function provided by many IIS. Based on this evaluation and other factors, recommendations may be made for next doses due. Some of their trading partners would like to receive the outcome of this evaluation.

This document does not describe nor specify the functionality of the evaluation service. The focus is only on the content of the messages. Implementations should document the local specifics of the evaluation process.

After receiving a query requesting a complete and evaluated history with forecast for a specific person, if a single high threshold matching patient is found, the responding system evaluates the immunizations administered to that patient against a schedule (e.g. ACIP). The results of the evaluation are returned in the response message.

It is important to remember that the evaluation process is a retrospective analysis of doses already received by the patient. The evaluation of a given dose will be associated with an RXA segment documenting the dose. OBX segments will follow the RXA segment indicating the outcome of the evaluation. Each distinct piece of information is found in its own OBX segment.

In some cases, there may be multiple series (paths to immunity) for a single disease of interest against which a dose can be evaluated. In this case, it is up to the evaluation engine to select the best series to return in the response message.

In other cases, the administered dose may be of a combination vaccine in which case the response message should contain an evaluation against multiple vaccine groups, each targeting a different disease of interest relevant to the vaccine. Note that all of the observations for an evaluation against a given vaccine group are linked using the observation Sub-ID (OBX-4). This is particularly important for combination vaccines where a single dose is evaluated against multiple vaccine groups and the evaluation results for each vaccine groups must be identifiable through the use of unique Sub-IDs for each vaccine group.

2.5.6.3 FORECAST

Unlike evaluations which relate to already administered doses, a forecast relates the prospective analysis of future needs or suggested actions. This can include recommending future doses and/or indicating that vaccination is not needed (e.g., an immunity or contraindication negates the need for additional doses, the patient has aged out of a series, a patient has completed a series).

This document does not describe nor specify the functionality or accuracy of the forecasting service. The focus of this document is only on the content of the messages. Implementations should document the local specifics on the forecasting process.

After receiving a query requesting a complete and evaluated history with forecast for a specific person, if a single high threshold matching patient is found, the responding system evaluates the immunizations


administered to that patient against a schedule (e.g. ACIP) and then further forecasts the next recommended action(s). The results of the forecast process are returned in the response message.

The results of the forecast process are returned in OBX segments associated with an RXA segment that indicates that no dose was given. Repeating sets of OBX segments are then used to convey the relevant data about one or more forecasted vaccine groups.

2.5.6.4 VACCINE TYPE

The Vaccine Type observation is used as part of both an evaluation and a forecast. For an evaluation, the vaccine type observation indicates the vaccine group (disease or collection of diseases) against which a dose was evaluated. For a forecast, the vaccine type observation indicates the vaccine group (or possibly specific vaccine) that the forecast relates to. In both contexts, the vaccine type is sent as an OBX segment and subsequent OBX segments are linked to that vaccine type using the Observation Sub-ID (OBX-4). There are no differences between evaluation and forecast in the OBX indicating the vaccine type.

For evaluations, it is important to remember that some products are composed of one vaccine type while others are combinations of several vaccine types. For example, CVX code 104 is mapped to a vaccine containing both Hep A and Hep B. Single vaccine type products are more straightforward when constructing a message. In contrast, multiple vaccine type products require multiple sets of observations, one for each vaccine type.

A vaccine type is messaged in an OBX segment using the LOINC code 30956-7.

2.5.6.5 SCHEDULE

Evaluations and forecasts are only meaningful in the context of a defined schedule. The only schedule supported by CDC is the ACIP schedule. Some systems may choose to develop other schedules that meet local needs.

There are no differences between evaluation and forecast in the OBX indicating the schedule used.

A schedule is messaged in an OBX segment using the LOINC code 59779-9.

2.5.6.6 DOSE NUMBER

The ordinal position in a selected series may be reported in an OBX segment. The ordinal position is the dose number being satisfied by a given immunization (e.g. dose #1 in a 3 dose series).

An ordinal position is messaged in an OBX segment using the LOINC code 30973-2. The total number of doses in a series is messaged in an OBX segment using the LOINC code 59782-3.

2.5.6.7 DOSE VALIDITY

As part of an evaluation, the dose validity indicates if the dose was given appropriately for the series in the schedule. Note that for combination vaccines, it may be possible that a given dose is valid for one series but invalid for another series.

A dose validity is messaged in an OBX segment using the LOINC code 59781-5.

2.5.6.8 SERIES STATUS

The series status code indicates the overall status of the series for the patient.


A series status is messaged in an OBX segment using the LOINC code 59783-1.

2.5.6.9 REASON

For an evaluation, the reason code can indicate why a dose is not valid. The reason code may also be used as part of a forecast to indicate a deviation from the standard age-based recommendations because of a special circumstance, such as the need for a less common vaccine due to the patient's particular circumstances (e.g. vaccination with a pertussis containing vaccine is important for pregnant women).

The technical usage of this code is the same for both evaluation and forecast even if the meaning of the "reason" is different.

A reason is messaged in an OBX segment using the LOINC code 30982-3.

2.5.6.10 DATES

A forecast can include a number of key dates that can be communicated.

TABLE 2-9 FORECAST DATE TYPES

Date Type Definition LOINC Code

The earliest acceptable date based on the schedule used

This is the earliest date that a person could receive the next valid dose for the vaccine group. It does not include any grace period. For example, the earliest date a person could receive the first dose of DTaP is age 42 days.

30981-5

The recommended date This is the date that a person should ideally receive the next dose for the vaccine group.

30980-7

The overdue date (the date the person is considered late for getting the vaccine)

This is the date that the person is considered late for getting the next dose for the vaccine group.

59778-1

The latest date that a dose should be given

This is the last possible date that a person could receive the next dose for the vaccine group. Generally, this is related to the age of the recipient. For example, the latest an individual should receive a dose of rotavirus vaccine is 8 months old.

59777-3


The sample messages contained in this section of the document are for illustration purposes and should not form the basis of system design. Readers should not infer any requirements solely from these messages. For example, the order that observations are given in OBX segments and the order in which events appear in the messages are not intended to indicate requirements for message construction.

2.5.7.1 SINGLE HIGH THRESHOLD MATCH

A family including a child, Peter Hugh Frye, has selected a new provider. Upon Peter's first visit to the new provider for his 2 month check up, the provider requests a complete and evaluated immunization history with forecast from the local IIS using demographics and IDs from the EHR system. The IIS finds a single high threshold matching patient and returns the history with forecast.

When sending multiple recommendations in a single query response message, the recommendations are sent


using a single ORC/RXA pair followed by multiple sets of related OBX segments (grouped via the Sub-ID in OBX-4) for each recommendation.

Query Message:MSH|^~\&||wcEHR||IIS|20160729152209.180-0500||QBP^Q11^QBP_Q11|970012|P|2.8.2|||NE|AL|||||IZ54r1.0^CDCPHINVS|wcEHR|IISQPD|IZ54^Request History with Forecast^CDCPHINVS|2208|534522^^^wcEHR^MR|Frye^Peter^Hugh^^^^L|Meyers^^^^^^M|20160526|M^Male^HL70001|122 Avenue A^Âustin^TX^78751ÛSA^P|^PRN^PH^^^512^5559908|N|1RCP|I|10^RD&Record&HL70126

Response Message:MSH|^~\&||IIS||wcEHR|20160729152212.180-0500||RSP^K11^RSP_K11|3695|P|2.8.2|||NE|NE|||||IZ52r1.0^CDCPHINVS|IIS|wcEHRMSA|AA|970012QAK|2208|OK|IZ54^Request History with Forecast^CDCPHINVSQPD|IZ54^Request History with Forecast^CDCPHINVS|2208|534522^^^wcEHR^MR|Frye^Peter^Hugh^^^^L|Meyers^^^^^^M|20160526|M^Male^HL70001|122 Avenue A^Âustin^TX^78751ÛSA^P|^PRN^PH^^^512^5559908|N|1PID|1||2239^^ÎIS^SR||Frye^Peter^Hugh^^^^L|Meyers^^^^^^M|20160526|M^Male^HL70001||2106-3^White^CDCREC|122 Avenue A^Âustin^TX^78751ÛSA^P||^PRN^PH^^^512^5559908|||||||||2186-5^Not Hispanic or Latino^CDCREC||N|1|||||NORC|RE|778^ghEHR|334665^ghEHR|||||||228^Brown^JanelleÔlivia^^^^^ghEHR^L^^^PRN||714^WarnerÂaron^Thomas^^^^^ghEHR^L^^^PRN|||||ghEHR^General Hospital^HL70362RXA|0|1|20160526|20160526|08^Hep B, adolescent or pediatric^CVX|0.5|mL^mLÛCUM||01^Historical Administration^NIP001|228^Brown^JanelleÔlivia^^^^^ghEHR^L^^^PRN|^^^ghEHR||||9901233|20161011|SKB^GlaxoSmithKline^MVX|||CP|||||||^^^ghEHRRXR|C28161Întramuscular^NCIT|RT^Right Thigh^HL70163OBX|1|CWE|30956-7^vaccine type^LN|1|45^Hep B NOS^CVX||||||F|||20160729OBX|2|ID|59781-5^dose validity^LN|1|Y||||||F|||20160729OBX|3|CWE|59779-9Îmmunization Schedule used^LN|1|VXC16ÂCIP^CDCPHINVS||||||F|||20160729ORC|RE|54322êcEHR|111234êcEHR|||||||9914^Hill^Spencer^Tyler^^^^êcEHR^L^^^PRN||724^Jordan^Vivian^Sarah^^^^êcEHR^L^^^MD|||||ecEHRÊast Clinic^HL70362RXA|0|1|20160627|20160627|08^Hep B, adolescent or pediatric^CVX|0.5|mL^mLÛCUM||01^Historical Administration^NIP001|9914^Hill^Spencer^Tyler^^^^êcEHR^L^^^PRN|^^êcEHR||||11901|20161115|SKB^GlaxoSmithKline^MVX|||CP|||||||^^êcEHRRXR|C28161Întramuscular^NCIT|RT^Right Thigh^HL70163OBX|1|CWE|30956-7^vaccine type^LN|1|45^Hep B NOS^CVX||||||F|||20160729OBX|2|ID|59781-5^dose validity^LN|1|Y||||||F|||20160729OBX|3|CWE|59779-9Îmmunization Schedule used^LN|1|VXC16ÂCIP^CDCPHINVS||||||F|||20160729ORC|RE||9999ÎISRXA|0|1|20160729|20160729|998^no vaccine admin^CVX|999||||||||||||||NAOBX|1|CWE|30956-7^vaccine type^LN|1|107^DTaP^CVX||||||F|||20160729OBX|2|CWE|59779-9Îmmunization Schedule used^LN|1|VXC16ÂCIP^CDCPHINVS||||||F|||20160729OBX|3|DT|30980-7^Date vaccination due^LN|1|20160726||||||F|||20160729OBX|4|DT|30981-5Êarliest Date to give^LN|1|20160707||||||F|||20160729OBX|5|CWE|30956-7^vaccine type^LN|2|10ÎPV^CVX||||||F|||20160729OBX|6|CWE|59779-9Îmmunization Schedule used^LN|2|VXC16ÂCIP^CDCPHINVS||||||F|||20160729OBX|7|DT|30980-7^Date vaccination due^LN|2|20160726||||||F|||20160729OBX|8|DT|30981-5Êarliest Date to give^LN|2|20160707||||||F|||20160729OBX|9|CWE|30956-7^vaccine type^LN|3|17^Hib^CVX||||||F|||20160729OBX|10|CWE|59779-9Îmmunization Schedule used^LN|3|VXC16ÂCIP^CDCPHINVS||||||F|||20160729OBX|11|DT|30980-7^Date vaccination due^LN|3|20160726||||||F|||20160729OBX|12|DT|30981-5Êarliest Date to give^LN|3|20160707||||||F|||20160729OBX|13|CWE|30956-7^vaccine type^LN|4|109^Pneumococcal^CVX||||||F|||20160729OBX|14|CWE|59779-9Îmmunization Schedule used^LN|4|VXC16ÂCIP^CDCPHINVS||||||F|||20160729OBX|15|DT|30980-7^Date vaccination due^LN|4|20160726||||||F|||20160729OBX|16|DT|30981-5Êarliest Date to give^LN|4|20160707||||||F|||20160729OBX|17|CWE|30956-7^vaccine type^LN|5|122^Rotavirus^CVX||||||F|||20160729OBX|18|CWE|59779-9Îmmunization Schedule used^LN|5|VXC16ÂCIP^CDCPHINVS||||||F|||20160729OBX|19|DT|30980-7^Date vaccination due^LN|5|20160726||||||F|||20160729OBX|20|DT|30981-5Êarliest Date to give^LN|5|20160707||||||F|||20160729


2.5.7.2 SINGLE HIGH THRESHOLD MATCH WITH AN INVALID DOSE

A child, Kenneth Yee, is brought to his provider for a check up. The provider requests a complete and evaluated immunization history with forecast from the local IIS using demographics and IDs from the EHR system. The IIS finds a single high threshold matching patient and returns the evaluated history and forecast. One dose in the child's history is found to be invalid because it was given too soon after the previous dose. A response message is returned including the invalid dose.

Query Message:MSH|^~\&||wcEHR||IIS|20161019152209.180-0500||QBP^Q11^QBP_Q11|34095|P|2.8.2|||NE|AL|||||IZ54r1.0^CDCPHINVS|wcEHR|IISQPD|IZ54^Request History with Forecast^CDCPHINVS|1299|800912^^^wcEHR^MR|Yee^Kenneth^^^^^L|Zhang^^^^^^M|20160830|M^Male^HL70001|5301 Red River St^Âustin^TX^78751ÛSA^P|^PRN^PH^^^512^5550011|N|1RCP|I|10^RD&Record&HL70126

Response Message:MSH|^~\&||IIS||wcEHR|20161019152212.180-0500||RSP^K11^RSP_K11|3695|P|2.8.2|||NE|NE|||||IZ52r1.0^CDCPHINVS|IIS|wcEHRMSA|AA|34095QAK|1299|OK|IZ54^Request History with Forecast^CDCPHINVSQPD|IZ54^Request History with Forecast^CDCPHINVS|1299|800912^^^wcEHR^MR|Yee^Kenneth^^^^^L|Zhang^^^^^^M|20160830|M^Male^HL70001|5301 Red River St^Âustin^TX^78751ÛSA^P|^PRN^PH^^^512^5550011|N|1PID|1||667099^^ÎIS^SR||Yee^Kenneth^^^^^L|Zhang^^^^^^M|20160830|M^Male^HL70001||2028-9Âsian^CDCREC|5301 Red River St^Âustin^TX^78751ÛSA^P||^PRN^PH^^^512^5550011|||||||||2186-5^Not Hispanic or Latino^CDCREC||N|1|||||NORC|RE|122^ghEHR|78099^ghEHR|||||||228^Brown^JanelleÔlivia^^^^^ghEHR^L^^^PRN||714^WarnerÂaron^Thomas^^^^^ghEHR^L^^^PRN|||||ghEHR^General Hospital^HL70362RXA|0|1|20160830|20160830|08^Hep B, adolescent or pediatric^CVX|0.5|mL^mLÛCUM||01^Historical Administration^NIP001|228^Brown^JanelleÔlivia^^^^^ghEHR^L^^^PRN|^^^ghEHR||||89732|20161221|SKB^GlaxoSmithKline^MVX|||CP|||||||^^^ghEHRRXR|C28161Întramuscular^NCIT|RT^Right Thigh^HL70163OBX|1|CWE|30956-7^vaccine type^LN|1|45^Hep B NOS^CVX||||||F|||20161019OBX|2|CWE|59779-9Îmmunization Schedule used^LN|1|VXC16ÂCIP^CDCPHINVS||||||F|||20161019OBX|3|ID|59781-5^dose validity^LN|1|Y||||||F|||20161019ORC|RE|6543êcEHR|1553êcEHR|||||||9914^Hill^Spencer^Tyler^^^^êcEHR^L^^^PRN||724^Jordan^Vivian^Sarah^^^^êcEHR^L^^^MD|||||ecEHRÊast Clinic^HL70362RXA|0|1|20160923|20160923|08^Hep B, adolescent or pediatric^CVX|0.5|mL^mLÛCUM||01^Historical Administration^NIP001|9914^Hill^Spencer^Tyler^^^^êcEHR^L^^^PRN|^^êcEHR||||177812|20161128|SKB^GlaxoSmithKline^MVX|||CP|||||||^^êcEHRRXR|C28161Întramuscular^NCIT|RT^Right Thigh^HL70163OBX|1|CWE|30956-7^vaccine type^LN|1|45^Hep B NOS^CVX||||||F|||20161019OBX|2|CWE|59779-9Îmmunization Schedule used^LN|1|VXC16ÂCIP^CDCPHINVS||||||F|||20161019OBX|3|ID|59781-5^dose validity^LN|1|N||||||F|||20161019OBX|4|ST|30982-3^Reason applied ^LN|1|Too Young||||||F|||20151031ORC|RE||9999ÎISRXA|0|1|20160729|20160729|998^no vaccine admin^CVX|999||||||||||||||NAOBX|1|CWE|30956-7^vaccine type^LN|1|45^Hep B NOS^CVX||||||F|||20161019OBX|2|CWE|59779-9Îmmunization Schedule used^LN|1|VXC16ÂCIP^CDCPHINVS||||||F|||20161019OBX|3|DT|30980-7^Date vaccination due^LN|1|20161023||||||F|||20161019OBX|4|DT|30981-5Êarliest Date to give^LN|1|20161021||||||F|||20161019

2.5.7.3 PROTECTED PATIENT

A family including a child, Peter Hugh Frye, has selected a new provider. Upon Peter's first visit to the new provider for his 2 month check up, the provider requests a complete and evaluated immunization history with forecast from the local IIS using demographics and IDs from the EHR system. The IIS finds a matching patient, but the patient data is marked as protected. For the IIS, local laws, regulations and IIS policy don't strictly prohibit sending some indication that a patient even exists in the IIS, so a message indicating a protected patient was found is returned.

Query Message:


MSH|^~\&||wcEHR||IIS|20160729152209.180-0500||QBP^Q11^QBP_Q11|970012|P|2.8.2|||NE|AL|||||IZ54r1.0^CDCPHINVS|wcEHR|IISQPD|IZ54^Request History with Forecast^CDCPHINVS|2208|534522^^^wcEHR^MR|Frye^Peter^Hugh^^^^L|Meyers^^^^^^M|20160526|M^Male^HL70001|122 Avenue A^Âustin^TX^78751ÛSA^P|^PRN^PH^^^512^5559908|N|1RCP|I|10^RD&Record&HL70126

Response Message:MSH|^~\&||IIS||wcEHR|20160729152212.180-0500||RSP^K11^RSP_K11|3695|P|2.8.2|||NE|NE|||||IZ33r1.0^CDCPHINVS|IIS|wcEHRMSA|AA|970012ERR|||207Âpplication Internal Error^HL70357|I||||A match was found in the IIS but no value is returned since Data Sharing for the record is set to NoQAK|2208|PD|IZ54^Request History with Forecast^CDCPHINVSQPD|IZ54^Request History with Forecast^CDCPHINVS|2208|534522^^^wcEHR^MR|Frye^Peter^Hugh^^^^L|Meyers^^^^^^M|20160526|M^Male^HL70001|122 Avenue A^Âustin^TX^78751ÛSA^P|^PRN^PH^^^512^5559908|N|1

2.5.7.4 NO MATCHING PATIENTS

A family including a child, Peter Hugh Frye, has selected a new provider. Upon Peter's first visit to the new provider for his 2 month check up, the provider requests a complete and evaluated immunization history with forecast from the local IIS using demographics and IDs from the EHR system. The IIS finds no matching patients and returns a response indicating no patients were found.


Response Message:MSH|^~\&||IIS||wcEHR|20160729152212.180-0500||RSP^K11^RSP_K11|3695|P|2.8.2|||NE|NE|||||IZ33r1.0^CDCPHINVS|IIS|wcEHRMSA|AA|970012QAK|2208|NF|IZ54^Request History with Forecast^CDCPHINVSQPD|IZ54^Request History with Forecast^CDCPHINVS|2208|534522^^^wcEHR^MR|Frye^Peter^Hugh^^^^L|Meyers^^^^^^M|20160526|M^Male^HL70001|122 Avenue A^Âustin^TX^78751ÛSA^P|^PRN^PH^^^512^5559908|N|1

2.5.7.5 MULTIPLE MATCHING PATIENTS

A family including a child, April Fiona MacDonald, has selected a new provider. Upon April's first visit to the new provider, the provider requests a complete and evaluated immunization history with forecast from the local IIS using demographics and IDs from the EHR system. The IIS finds multiple high threshold matching patients and returns patient demographics for the matching records. No immunization data are returned. When the response includes more than 1 candidate, it may be reviewed by the person requesting records. If they select a specific patient and repeat the query with the refined information, they should receive a response that includes the complete immunization history from the responding system.

Query Message:MSH|^~\&||wcEHR||IIS|20160727131307-0500||QBP^Q11^QBP_Q11|35869|P|2.8.2|||NE|AL|||||IZ54r1.0^CDCPHINVS|wcEHR|IISQPD|IZ54^Request History with Forecast^CDCPHINVS|16|17782^^^wcEHR^MR|MacDonaldÂpril^Fiona^^^^L|Cochrane^^^^^^M|20160523|F^Female^HL70001|990 Big Lake Drive^^St Cloud^MN^14201ÛSA^P|


^PRN^PH^^^320^5550067|N|1RCP|I|5^RD&Record&HL70126

Response Message:MSH|^~\&||IIS||wcEHR|20150727131308-0500||RSP^K11^RSP_K11|3695|P|2.8.2|||NE|NE|||||IZ31r1.0^CDCPHINVS|IIS|wcEHRMSA|AA|35869QAK|16|OK|IZ54^Request History with Forecast^CDCPHINVSQPD|IZ54^Request History with Forecast^CDCPHINVS|16|17782^^^wcEHR^MR|MacDonaldÂpril^Fiona^^^^L|Cochrane^^^^^^M|20160523|F^Female^HL70001|990 Big Lake Drive^^St Cloud^MN^14201ÛSA^P|^PRN^PH^^^320^5550067|N|1PID|1||63463^^ÎIS^SR||McDonaldÂpril^Fiona^^^^L|Cochrane^^^^^^M|20160523|F^Female^HL70001NK1|1|Cochrane^Susan^^^^^L|MTH^Mother^HL70063PID|2||33452^^ÎIS^SR||MacDonaldÂpril^Fiona^^^^L||20160523|F^Female^HL70001

2.5.7.6 MORE THAN THE MAXIMUM NUMBER OF PATIENTS FOUND

A family including a child, April Fiona MacDonald, has selected a new provider. Upon April's first visit to the new provider, the provider requests a complete and evaluated immunization history with forecast from the local IIS using demographics and IDs from the EHR system. The IIS finds more high threshold matching patients then are allowed and returns a response that no patients were found.

Query Message:MSH|^~\&||wcEHR||IIS|20160727131307-0500||QBP^Q11^QBP_Q11|35869|P|2.8.2|||NE|AL|||||IZ54r1.0^CDCPHINVS|wcEHR|IISQPD|IZ54^Request History with Forecast^CDCPHINVS|16|17782^^^wcEHR^MR|MacDonaldÂpril^Fiona^^^^L|Cochrane^^^^^^M|20160523|F^Female^HL70001|990 Big Lake Drive^^St Cloud^MN^14201ÛSA^P|^PRN^PH^^^320^5550067|N|1RCP|I|10^RD&Record&HL70126

Response Message:MSH|^~\&||IIS||wcEHR|20150727131308-0500||RSP^K11^RSP_K11|3695|P|2.8.2|||NE|NE|||||IZ33r1.0^CDCPHINVS|IIS|wcEHRMSA|AA|35869QAK|16|TM|IZ54^Request History with Forecast^CDCPHINVSQPD|IZ54^Request History with Forecast^CDCPHINVS|16|17782^^^wcEHR^MR|MacDonaldÂpril^Fiona^^^^L|Cochrane^^^^^^M|20160523|F^Female^HL70001|990 Big Lake Drive^^St Cloud^MN^14201ÛSA^P|^PRN^PH^^^320^5550067|N|1


A family including a child, Peter Hugh Frye, has selected a new provider. Upon Peter's first visit to the new provider for his 2 month check up, the provider requests a complete and evaluated immunization history with forecast from the local IIS using demographics and IDs from the EHR system. The IIS determines that the message contains a fatal error and is unable to process the request. A response message is returned indicating the nature of the error.

Query Message:MSH|^~\&||wcEHR||IIS|20160729152209.180-0500||QBP^Q11^QBP_Q11|970012|P|2.8.2|||NE|AL|||||IZ54r1.0^CDCPHINVS|wcEHR|IISQPD|IZ54^Request History with Forecast^CDCPHINVS||534522^^^wcEHR^MR|Frye^Peter^Hugh^^^^L|Meyers^^^^^^M|20160526|M^Male^HL70001|122 Avenue A^Âustin^TX^78751ÛSA^P|^PRN^PH^^^512^5559908|N|1RCP|I|1^RD&Record&HL70126

Response Message:


MSH|^~\&||IIS||wcEHR|20160729152212.180-0500||RSP^K11^RSP_K11|3695|P|2.8.2|||NE|NE|||||IZ33r1.0^CDCPHINVS|IIS|wcEHRMSA|AE|970012ERR||QPD^1^2|101^required field missing^HL70357|EQAK||AE|IZ54^Request History with Forecast^CDCPHINVSQPD|IZ54^Request History with Forecast^CDCPHINVS||534522^^^wcEHR^MR|Frye^Peter^Hugh^^^^L|Meyers^^^^^^M|20160526|M^Male^HL70001|122 Avenue A^Âustin^TX^78751ÛSA^P|^PRN^PH^^^512^5559908|N|1

Note that in the example above the QAK-1 Query tag is empty because it was missing in the initiating query (which is the source of the error).

2.5.7.8 MESSGE REJECTION ACKNOWLEDGEMENT

A family including a child, Peter Hugh Frye, has selected a new provider. Upon Peter's first visit to the new provider for his 2 month check up, the provider requests a complete and evaluated immunization history with forecast from the local IIS using demographics and IDs from the EHR system. The IIS determines that the message contains a fatal error in MSH-12 and is unable to process the request. A response message is returned indicating the nature of the error.


Response Message:MSH|^~\&||IIS||wcEHR|20160729152212.180-0500||ACK^Q11ÂCK|3695|P|2.8.2|||NE|NE|||||IZ23r1.0^CDCPHINVS|IIS|wcEHRMSA|AR|970012ERR||MSH^1^12|203Ûnsupported version ID^HL70357|E


3 MESSAGE INFRASTRUCTURE 3.1 Conformance Profiles

Conformance profiles are sets of constraints on a message, identified by a code in the message header (MSH-21). By including the profile ID in MSH-21 of a message, the sending system is asserting that the message conforms to both the base messaging standard as well as the additional constraints defined by the profile that make the message perform as required for a specific use case or purpose, as documented in an Implementation Guide.

This document uses a Message Profile Identifier (MSH-21) composed of 3 pieces: The base profile identifier which is consistent between releases of the implementation guide A constant delimiter (the lower-case letter "r") A version identifier which corresponds to the release number of the implementation guide

For example, in the previous implementation guide published by AIRA, the profile ID "Z22" was used to indicate the requirements for a VXU message for submitting vaccination event data. To avoid confusion with Z-segments and to harmonize with conformance statement identifiers, an additional “I” will be added to each profile ID starting with this document. The cognate profile in this document is "IZ22r1.0" indicating the version of the base IZ22 profile described in Release 1.0 (this document) of the HL7 implementation guide. By concatenating the base ID with a version ID, it will be possible to examine the value of MSH-21 in a given message and unambiguously identify the set of requirements relevant for the message.

In the message definition tables in this section, the "Segment" column indicates the HL7 standard segment identifier used in the message. The "Flavor" column indicates when this document constrains the base segment for the purposes of meeting use case requirements. All segment flavors unique to this guide include the "_IZ" suffix and are detailed in the sections following the message definition. In some cases, more than one flavor of a single segment is required to meet the different requirements of multiple use cases. When this happens, an additional numeric suffix is appended onto the name of the flavor.

Note that in some cases a segment is given a usage of R (Required) when is part of an optional segment group. For example, in the IZ22r1.0 profile, the PATIENT_VISIT segment group has a usage of O (Optional) but within that segment group, the PV1 segment has a Usage of R. What this means is that a sending system is not required to include the PATIENT_VISIT group in a message, but if it does, then a PV1 segment must be included. In this scenario, even though the segment has a usage of R, the document may not define a unique segment flavor and if implemented, the segment should conform at a minimum to base HL7 standard requirements for that segment.

Similarly, base data types are constrained in the document through the creation of "data type flavors". Each data type flavor is also suffixed with "_IZ" and an additional numeric suffix. As with segments, when multiple flavors of a given data type are required to satisfy the requirements of different portions of the message, multiple data types flavors are defined. The specifics of each flavor are defined later in this document.

The messages described in this document contain groups of segments organized as logical units called segment groups. One such segment group is the Order Segment Group that contains required ORC and RXA segments as well as required but may be empty RXR and OBX segments (note that the OBX segment is itself part of the Observation Segment Group). Five basic flavors of Order Segment Groups are found in


immunization messages. The following sections of this document will outline the use of these Order Segment Group flavors in the various message profiles.

Immunization Event - this segment group includes observations about the event itself Immunization Event (Contraindicated) - this segment group includes data about a potential dose

which was NOT given due to a patient contraindication, this segment group documents a specific decision to not administer a dose

Immunization Event (Refused) - this segment group includes data about a vaccine that was refused by the patient or the patient's guardian

Immunization Event with Evaluation - this segment group includes observations about the event itself as well as additional observations derived from an evaluation of the event against a set of immunization recommendations

Forecast -this segment group includes observations pertaining to recommended future doses derived from a comparison of the patient history with a set of immunization recommendations

3.1.1 VXU^V04^VXU_V04 - IZ22R1.0 - SEND AN UNSOLICITED IMMUNIZATION EVENT

The IZ22r1.0- Send an Unsolicited Immunization Event profile is a constrainable profile that supports the messaging of immunization events for a patient. This may be an event that is new or it may be an update or delete to an existing event.

The goal of this interaction is to transfer immunization information from one health information system to another. The initiating system is typically an Electronic Health Record system (EHR-S) but may be an Immunization Information System (IIS) or another type of health information system.

The IZ22r1.0 profile has a partner profile for acknowledging processing of the message, IZ23r1.0 - Respond with a General Acknowledgment.

A conformant IZ22r1.0 message includes one or more Order Segment Groups (repeating sets of ORC, RXA, RXR and OBX segments) containing data about specific doses administered to the patient, contraindicated doses and/or refused doses. Any combination of action codes may be sent in a single VXU message. That is, a single message may contain order segment groups for any combination of adds, deletes or updates. Note that when sending multiple order segment groups, either in a single message or in multiple messages, the order in which the information is sent should reflect the order in which changes were made in the application. For example, if an immunization event record is created and then deleted, the "add" data should precede the "delete" data. This document makes no recommendations regarding the order of OBXs within a given Order Segment Group in this profile, but keep in mind that related OBX segments, such as those related to VIS information, must be linked via the sub-ID in OBX-4.

Within an Immunization Event Order Segment Group, RXA-5 shall indicate the vaccine administered and RXA-20 shall be PA or CP indicating an administered dose. The following OBX segment types are relevant:

Patient eligibility status (required for new administrations) - LOINC code 64994-7 Vaccine funding source (required for new administrations) - LOINC code 30963-3 Vaccine Information Statements (VIS) (required for new administrations) - LOINC codes 69764-9

and 29769-7 or LOINC codes 30956-7, 29768-9 and 29769-7 Adverse reactions where the reaction can be directly attributable to a specific immunization event -

LOINC code 31044-1 Indication (why the dose was administered) - LOINC code 59785-6 Indication effective date - LOINC code 88877-6 Indication expiration date - LOINC code 88879-2 Free text comment - LOINC code 48767-8


Within an Immunization Event (Refused) Order Segment Group, RXA-5 shall indicate the refused vaccine, RXA-20 shall be RE and RXA-18 shall contain a coded refusal reason. The following OBX segment type is relevant:

Free text comment - LOINC code 48767-8

Within an Immunization Event (Contraindicated) Order Segment Group, RXA-5 shall indicate the contraindicated vaccine and RXA-20 shall be NA, indicating that a dose was not administered. The following OBX segment types are relevant:

Contraindication (why a dose was not administered) - LOINC code 30945-0 Contraindication effective date - LOINC code 30946-8 Contraindication expiration date - LOINC code 30944-3 Free text comment - LOINC code 48767-8

The message may also contain one or more Person Observation Segment Groups, each containing a patient level observation. Patient level observations should not be included as part of an Order Segment Group. Within a Person Observation Segment Group, the following OBX segment types are relevant:

Adverse reactions where the reaction cannot be directly attributable to a specific immunization event - LOINC code 31044-1

Serological evidence of immunity - LOINC code 75505-8 Presumed evidence of immunity - LOINC code 59784-9 Condition - LOINC code 75323-6 Date of condition onset - LOINC code 85585-8 Date of condition abatement - LOINC code 88878-4

See the co-constraints table associated with the OBX segment definitions more details on how to message these concepts.

Conformance Profile Definition Segment Flavor Element name Usage CardinalityMSH MSH_IZ Message Header R [1..1]SFT SFT Software Segment O [0..*]UAC UAC User Authentication Credential Segment O [0..1]PID PID_IZ Patient Identification R [1..1]PD1 PD1_IZ_01 Patient Additional Demographic RE [0..1]NK1 NK1_IZ Next of Kin / Associated Parties RE [0..*]ARV ARV Access Restriction O [0..*][ BEGIN PATIENT_VISIT GROUP O [0..1]PV1 PV1 Patient Visit R [1..1]PV2 PV2 Patient Visit - Additional Information O [0..1]ARV ARV Access Restriction O [0..*]] END PATIENT_VISIT GROUPGT1 GT1 Guarantor O [0..*][ BEGIN INSURANCE GROUP O [0..1]IN1 IN1_IZ Insurance R [1..1]IN2 IN2 Insurance Additional Information O [0..1]


Segment Flavor Element name Usage CardinalityIN3 IN3 Insurance Additional Information, Certification O [0..1]] END INSURANCE GROUP[ BEGIN PERSON_OBSERVATION GROUP RE [0..*]OBX OBX_IZ_01 Observation/Result R [1..1]PRT PRT Participation Information O [0..*]NTE NTE Notes and Comments O [0..*]] END PERSON_OBSERVATION GROUP[ BEGIN ORDER GROUP R [1..*]ORC ORC_IZ_01 Common Order R [1..1]PRT PRT Participation Information O [0..*][ BEGIN TIMING GROUP O [0..1]TQ1 TQ1 Timing/Quantity R [1..1]TQ2 TQ2 Timing/Quantity Relationship O [0..*]] END TIMING GROUPRXA RXA_IZ_01 Pharmacy/Treatment Administration R [1..1]RXR RXR_IZ Pharmacy/Treatment Route RE [0..1][ BEGIN OBSERVATION GROUP RE [0..*]OBX OBX_IZ_02 Observation/Result R [1..1]PRT PRT Participation Information O [0..*]NTE NTE Notes and Comments O [0..1]] END OBSERVATION GROUP] END ORDER GROUP

Conformance Statements Message:ID Description

IZ-45 IF RXA-20 (Completion Status) contains one of the values in the list (NA, RE) THEN ORC-3.1 (Identifier) in the same Order Segment Group SHALL contain the value "9999".

IZ-155

If RXA-20 (Completion Status) contains one of the values in the list (CP, PA) AND If RXA-9.1 (Administration Notes) contains the value "00" THEN exactly one occurrence of OBX-3.1 (Identifier) in the same Order Segment Group SHALL contain the contain the value “30963-3” (Funding Source) drawn from the code system “LN”.

IZ-205IF OBX-3.1 (Identifier) contains the value "59785-6" (Indication for Immunization) THEN the value of RXA-20 (Completion Status) in the same Order Segment Group SHALL contain one of values in the list (CP, PA).

IZ-206IF OBX-3.1 (Identifier) contains the value "30945-0" (Vaccination contraindication/precaution) THEN the value of RXA-20 (Completion Status) in the same Order Segment Group SHALL contain the value "NA".

IZ-23

If RXA-20 (Completion Status) contains one of the values in the list (CP, PA) AND If RXA-9.1 (Administration Notes) contains the value "00" THEN exactly one occurrence of OBX-3.1 (Identifier) in the same Order Segment Group SHALL contain the contain the value "64994-7" (Vaccine funding program eligibility category) drawn from the code system “LN”.

IZ-24 IF RXA-20 (Completion Status) contains one of the values in the list (CP, PA) AND if RXA-9.1


ID Description(Administration Notes) contains the value "00" AND if RXA-5 (Administered Code) is valued with a code equivalent to a CVX code from the PHVS_VISVaccines_IIS value set THEN for each vaccine information statement that was presented the message SHALL include in the same Order Segment Group either a pair of OBX segments where OBX-3.1 (Identifier) contains the values "69764-9" (bar coded document type) and "29769-7" (presentation /delivery date) OR a triplet of OBX segments with OBX-3.1 (Identifier) contains the values "30956-7" (vaccine type), "29768-9" (document publication date) and "29769-7" (presentation /delivery date). All VIS related observations for the same document SHALL contain the same value in OBX-4 (Observation Sub-ID). When multiple documents are transmitted in a given Order Segment Group, each set of VIS related observations SHALL contain a unique value in OBX-4 (Observation Sub-ID).

3.1.1.1 SEGMENT DEFINITIONS

3.1.1.1.1 MSH_IZ - MESSAGE HEADER

Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Field Separator ST_IZ01 R [1..1]2 Encoding Characters ST_IZ01 R [1..1]3 Sending Application HD_IZ01 RE [0..1] 0361_014 Sending Facility HD_IZ01 RE [0..1] 0362_015 Receiving Application HD_IZ01 RE [0..1] 0361_016 Receiving Facility HD_IZ01 RE [0..1] 0362_017 Date/Time of Message DTM_IZ01 R [1..1]8 Security ST O [0..1]9 Message Type MSG_IZ01 R [1..1]10 Message Control ID ST_IZ01 R [1..1]11 Processing ID PT_IZ01 R [1..1]12 Version ID VID_IZ01 R [1..1]13 Sequence Number NM O [0..1]14 Continuation Pointer ST O [0..1]

15 Accept Acknowledgment Type ID_IZ01 R [1..1] 0155

16 Application Acknowledgment Type ID_IZ01 R [1..1] 0155

17 Country Code ID O [0..1]18 Character Set ID O [0..1]

19 Principal Language Of Message CWE O [0..1]

20 Alternate Character Set Handling Scheme ID O [0..1]

21 Message Profile Identifier EI_IZ02 R [1..*] PHVS_ImmunizationProfileID_IIS

22 Sending Responsible Organization XON_IZ01 RE [0..1]


Seq Element name Data type Usage Cardinality Value Set

23 Receiving Responsible Organization XON_IZ01 RE [0..1]

24 Sending Network Address HD O [0..1]25 Receiving Network Address HD O [0..1]

Conformance StatementsID DescriptionIZ-12 MSH-1 (Field Separator) SHALL contain the value “|”.IZ-13 MSH-2 (Encoding Characters) SHALL contain the value “^~\&”.IZ-75 MSH-9.1 (Message Code) SHALL contain the value "VXU" drawn from the code system "HL70076".IZ-76 MSH-9.2 (Trigger Event) SHALL contain the value "V04" drawn from the code system "HL70003".

IZ-77 MSH-9.3 (Message Structure) SHALL contain the value "VXU_V04" drawn from the code system "HL70354".

IZ-74 MSH-12.1 (Version ID) SHALL contain the value "2.8.2".

IZ-53 MSH-15 (Accept Acknowledgment Type) SHALL contain the value "NE" drawn from the code system "HL70155".

IZ-58 MSH-16 (Application Acknowledgment Type) SHALL contain the value "AL" drawn from the code system "HL70155".

IZ-78In exactly one occurrence of MSH-21 (Message Profile Identifier), MSH-21.1 (Entity Identifier) SHALL contain the value "IZ22r1.0" AND MSH-21.2 (Namespace ID) SHALL contain the value "CDCPHINVS".

MSH-3: Sending Application (HD_IZ01)

This field uniquely identifies the application sending the message. The value is locally defined and often assigned by the IIS.

MSH-4: Sending Facility (HD_IZ01)

This field identifies the organization responsible for the operations of the sending application. Locally defined codes accommodate local needs. The first component shall be the name space ID found in User-defined Table 0362. The second and third components are reserved for use of OIDs.

Depending on the architecture of the integration, MSH-4 may or may not be the same organization that is responsible for the content of the message. For example, if an EHR communicates with an IIS via a Health Information Exchange (HIE), the value in MSH-4 may change (depending on local policy) from representing the EHR to representing the HIE as the message moves between systems. This value may represent the same organization as sent in MSH-22 but does not have to.

MSH-5: Receiving Application (HD_IZ01)


MSH-6: Receiving Facility (HD_IZ01)


This field identifies the organization responsible for the operations of the receiving application. Locally defined codes will accommodate local needs.

Depending on the architecture of the integration, MSH-6 may or may not be the same organization that is the ultimate recipient of the message. For example, if an EHR communicates with an IIS via a Health Information Exchange (HIE), the value in MSH-6 may change (depending on local policy) from representing the HIE to representing the IIS as the message moves between systems. This value may represent the same organization as sent in MSH-23 but does not have to.

MSH-10: Message Control ID (ST_IZ01)

This field contains the identifier assigned by the sending system that uniquely identifies a message instance. This identifier is unique within the scope of the sending system and the YYYYMMDD portion of message date (MSH-7). When generating a response message, the receiving system echoes this ID back to the sending system in the Message Acknowledgment segment (MSA). The content and format of the data sent in this field are the responsibility of the sender.

Some messages pass through intermediary systems like a Health Information Exchange (HIE) or integration engine. It is important that the intermediary system not alter MSH-10 so that the original MSH-10 can be used to populate MSA-2 in the response message.

MSH-21: Message Profile Identifier (EI_IZ02)

This field is used to indicate the message profile that the sender is claiming conformance to. For example, the identifier of "IZ22r1.0^CDCPHINVS" indicates that the sender is claiming the message instance adheres to the requirements for the IZ22 profile as stated in this document Additional occurrences of the element may be sent, for example, to claim conformance to a local (e.g., state) profile that further constrains the IZ22 profile.

MSH-22: Sending Responsible Organization (XON_IZ01)

This field contains the business organization that originated and is accountable for the content of the message.

Currently, MSH provides fields to transmit both sending/receiving applications and facilities (MSH-3 through MSH-6). However, these levels of organization do not necessarily relate to or imply a legal entity such as a business organization. As such, multiple legal entities (organizations) may share a service bureau, with the same application and facility identifiers. Another level of detail is required to delineate the various organizations using the same service bureau.

Therefore, the Sending Responsible Organization field provides a complete picture from the application level to the overall business level. The Business Organization represents the legal entity responsible for the contents of the message.

MSH-23: Receiving Responsible Organization (XON_IZ01)

This field contains the business organization that is the intended receiver of the message and is accountable for acting on the data conveyed by the transaction.

This field has the same justification as the Sending Responsible Organization except in the role of the


Receiving Responsible Organization. The receiving organization has the responsibility to act on the information in the message.

3.1.1.1.2 PID_IZ - PATIENT IDENTIFICATION

Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Set ID - PID SI_IZ01 R [1..1]2 Patient ID - X3 Patient Identifier List CX_IZ01 R [1..*]4 Alternate Patient ID - PID - X5 Patient Name XPN_IZ01 R [1..*]6 Mother's Maiden Name XPN_IZ02 RE [0..1]7 Date/Time of Birth DTM_IZ02 R [1..1]8 Administrative Sex CWE_IZ01 R [1..1] 0001_019 Patient Alias - X10 Race CWE_IZ01 RE [0..*] CDCREC_0111 Patient Address XAD_IZ01 RE [0..*]12 County Code - X13 Phone Number - Home XTN_IZ01 RE [0..*]14 Phone Number - Business XTN O [0..*]15 Primary Language CWE O [0..1]16 Marital Status CWE O [0..1]17 Religion CWE O [0..1]18 Patient Account Number CX O [0..1]19 SSN Number - Patient - X20 Driver's License Number - Patient - X21 Mother's Identifier CX O [0..*]22 Ethnic Group CWE_IZ01 RE [0..1] CDCREC_0223 Birth Place ST O [0..1]24 Multiple Birth Indicator ID_IZ01 RE [0..1] 0136_0125 Birth Order NM_IZ01 C(RE/O) [0..1]26 Citizenship CWE O [0..1]27 Veterans Military Status CWE O [0..1]28 Nationality - X29 Patient Death Date and Time DTM_IZ02 C(RE/X) [0..1]30 Patient Death Indicator ID_IZ01 RE [0..1] 0136_0131 Identity Unknown Indicator ID O [0..1]32 Identity Reliability Code CWE O [0..1]33 Last Update Date/Time DTM O [0..1]34 Last Update Facility HD O [0..1]


Seq Element name Data type Usage Cardinality Value Set35 Taxonomic Classification Code CWE O [0..1]36 Breed Code - X37 Strain ST O [0..1]38 Production Class Code CWE O [0..1]39 Tribal Citizenship CWE O [0..1]40 Patient Telecommunication Information XTN O [0..1]

Conformance StatementsID DescriptionIZ-46 PID-1 (Set ID - PID) SHALL contain the value "1".

Conditional PredicatesLocation Usage DescriptionPID-25 C(RE/O) If PID-24 (Multiple Birth Indicator) contains the value “Y”.PID-29 C(RE/X) If PID-30 (Patient Death Indicator) contains the value “Y”.

PID-6: Mother's Maiden Name (XPN_IZ02)

The family name under which the mother was born (i.e., before marriage) is used to distinguish between patients with similar demographics.

PID-7: Date/Time of Birth (DTM_IZ02)

This field contains the patient's date and time of birth. Only the date is required.

Date of Birth is generally considered to be independent of the time zone. If a time is available, the interacting systems should not convert the patient's accepted date of birth to a local equivalent.

PID-13: Phone Number - Home (XTN_IZ01)

This field contains the patient's phone number(s) and/or email address(es). Each type of telecommunication shall be in its own occurrence. For example, if a person has a phone number and an email address, they shall each have an occurrence.

PID-15: Primary Language (CWE)

If exchanging this optional field, ISO 639 shall be used for Language. It is available from PHIN-VADS at:

http://phinvads.cdc.gov/vads/ViewValueSet.action?id=43D34BBC-617F-DD11-B38D-00188B398520#

The coding system used is ISO6392 from the HL70396 table.

PID-24: Multiple Birth Indicator (ID_IZ01)

This field indicates whether the patient was part of a multiple birth.


Y - the patient was part of a multiple birthN - the patient was a single birthEmpty - multiple birth status is undetermined.

PID-25: Birth Order (NM_IZ01)

When a patient was part of a multiple birth, this field contains a number indicating the person's birth order, with 1 for the first child born and 2 for the second, etc.

PID-29: Patient Death Date and Time (DTM_IZ02)

This field contains the date and time at which the patient death occurred.

Date of Death is generally considered to be independent of the time zone. If a time is available, the sending and receiving systems should not convert the patient's accepted date of death to a local equivalent.

PID-30: Patient Death Indicator (ID_IZ01)

This field indicates whether the patient is deceased.

Y - the patient is deceasedN - the patient is not deceasedEmpty - death status is undetermined

PID-40: Patient Telecommunication Information (XTN)

This optional field replaces PID-13 - Phone Number - Home and PID-14 - Phone Number - Business with the intention that the components of the XTN data type be used to identify phone usage (Telecommunication use code) and type of equipment (telecommunication equipment type). This field may be considered for use by trading partners and will be used by future releases of this document.

3.1.1.1.3 PD1_IZ_01 - PATIENT ADDITIONAL DEMOGRAPHIC

There are three primary uses for PD1 in immunization messages. These include indicating whether the person wants his/her data protected, whether the person wants to receive recall/reminder notices and the person's current status in the system generating the message.

Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Living Dependency CWE O [0..1]2 Living Arrangement CWE O [0..1]3 Patient Primary Facility XON O [0..1]4 Patient Primary Care Provider Name & ID No. - X5 Student Indicator CWE O [0..1]6 Handicap CWE O [0..1]7 Living Will Code CWE O [0..1]


Seq Element name Data type Usage Cardinality Value Set8 Organ Donor Code CWE O [0..1]9 Separate Bill ID O [0..1]10 Duplicate Patient CX O [0..1]11 Publicity Code CWE_IZ01 RE [0..1] 0215_0112 Protection Indicator ID_IZ01 RE [0..1] 0136_0113 Protection Indicator Effective Date DT_IZ01 C(RE/X) [0..1]14 Place of Worship XON O [0..1]15 Advance Directive Code CWE O [0..1]16 Immunization Registry Status CWE_IZ01 RE [0..1] 0441_0117 Immunization Registry Status Effective Date DT_IZ01 C(RE/X) [0..1]18 Publicity Code Effective Date DT_IZ01 C(RE/X) [0..1]19 Military Branch CWE O [0..1]20 Military Rank/Grade CWE O [0..1]21 Military Status CWE O [0..1]22 Advance Directive Last Verified Date DT O [0..1]

Conditional PredicatesLocation Usage DescriptionPD1-13 C(RE/X) If PD1-12 (Protection Indicator) is valued.PD1-17 C(RE/X) If PD1-16 (Immunization Registry Status) is valued.PD1-18 C(RE/X) If PD1-11 (Publicity Code) is valued.

PD1-3: Patient Primary Facility (XON)

This optional field contains the name and identifier that specifies the "primary care" healthcare facility selected by the patient at the time of enrollment in an HMO Insurance Plan. It is not the Primary Care Practitioner or Medical Home. The meaning of this field should not be expanded to include the concept of medical home.

PD1-11: Publicity Code (CWE_IZ01)

This field contains a user-defined code indicating what level of publicity is allowed for the patient. In the context of immunization messages, this refers to how a person wishes to be contacted in a reminder or recall situation

PD1-12: Protection Indicator (ID_IZ01)

This field identifies whether a person's information may be shared with others (local policies determine how data are protected). The protection state must be explicitly captured in the system documenting the immunization. If it is not actively determined, then the protection indicator shall be empty.

There are 3 states:Protection State CodeYes, protect the data. Patient (or guardian) has indicated that the information shall be protected. (Do not share data) Y


Protection State CodeNo, it is not necessary to protect data from other clinicians. Patient (or guardian) has indicated that the information does not need to be protected. (Sharing is OK) N

No determination has been made regarding patient's (or guardian's) wishes regarding information sharing PD1-12 is empty

Notes on use of Y for Protection Indicator in starting in version 2.5.1

Note that Implementation Guides based on HL7 versions less than 2.5 stated that Y meant that a person's information could be shared. This was an incorrect interpretation of the use of this field. The meaning now aligns with the base definition of HL7, that is, Y means data must be protected. Existing systems that use the old meaning will need to determine how they will send the correct value in messages based on version 2.5.1 or beyond.

Note that the requirements in this document do not affect the value sent in a message that is based on the 2.3.1 or 2.4 version of the HL7 standard (which may continue to follow the old guidance - that is, Y means sharing is allowed and N means sharing is not allowed). A system receiving a message containing a PD1 segment must process the protection indicator in a way consistent with the HL7 version the message is based on.

PD1-16: Immunization Registry Status (CWE_IZ01)

This field identifies the current status of the patient in relation to the sending organization. The term "sending organization" refers to the organization that is accountable for the content of the message. This may be an EHR for a VXU^V04 message or an IIS for an RSP^K11 message. PD1-16 should reflect the status of the patient relative to the system creating the message.

The patient status may be different between the sending and receiving systems. For instance, a person may no longer be active with a provider organization but may still be active in the public health jurisdiction, which operates the Immunization Information System (IIS). In this case the provider organization would indicate that the person was inactive in their system using this field in a message from them. The IIS would indicate that person was active in a message from the IIS.

This document does not intend to define the use of this field to infer "ownership" of the patient by a particular submitter organization. Receiving systems should develop and document the local business rules used to accurately maintain patient ownership.

For additional information on this topic, see the MIROW guide on Patient Active/Inactive Status available at http://repository.immregistries.org/resources/search/PAIS.

3.1.1.1.4 NK1_IZ - NEXT OF KIN / ASSOCIATED PARTIES

Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Set ID - NK1 SI_IZ01 R [1..1]2 Name XPN_IZ01 R [1..*]3 Relationship CWE_IZ01 R [1..1] 0063_014 Address XAD_IZ01 RE [0..*]


Seq Element name Data type Usage Cardinality Value Set5 Phone Number XTN_IZ01 RE [0..*]6 Business Phone Number XTN O [0..1]7 Contact Role CWE O [0..1]8 Start Date DT O [0..1]9 End Date DT O [0..1]10 Next of Kin / Associated Parties Job Title ST O [0..1]

11 Next of Kin / Associated Parties Job Code/Class JCC O [0..1]

12 Next of Kin / Associated Parties Employee Number CX O [0..1]

13 Organization Name - NK1 XON O [0..1]14 Marital Status CWE O [0..1]15 Administrative Sex CWE O [0..1]16 Date/Time of Birth DTM O [0..1]17 Living Dependency CWE O [0..1]18 Ambulatory Status CWE O [0..1]19 Citizenship CWE O [0..1]20 Primary Language CWE O [0..1]21 Living Arrangement CWE O [0..1]22 Publicity Code CWE O [0..1]23 Protection Indicator ID O [0..1]24 Student Indicator CWE O [0..1]25 Religion CWE O [0..1]26 Mother's Maiden Name XPN O [0..1]27 Nationality CWE O [0..1]28 Ethnic Group CWE O [0..1]29 Contact Reason CWE O [0..1]30 Contact Person's Name XPN O [0..1]31 Contact Person's Telephone Number XTN O [0..1]32 Contact Person's Address XAD O [0..1]33 Next of Kin/Associated Party's Identifiers CX O [0..1]34 Job Status CWE O [0..1]35 Race CWE O [0..1]36 Handicap CWE O [0..1]37 Contact Person Social Security Number ST O [0..1]38 Next of Kin Birth Place ST O [0..1]39 VIP Indicator CWE O [0..1]40 Next of Kin Telecommunication Information XTN O [0..1]



41 Contact Person's Telecommunication Information XTN O [0..1]

Conformance StatementsID DescriptionIZ-70 NK1-1 (Set ID - NK1) SHALL be valued sequentially starting with the value "1".

3.1.1.1.5 IN1_IZ - INSURANCE

Local implementations may document the use of the IN1 segment for local purposes in local implementation guides. When this happens, they should conform to the specifications that follow. They have been constrained, based on current usage. Local implementations that require IN1 should base requirements on this guide. Specifications for IN1 are included because several IIS require this segment and this specification is intended to assure that implementations are consistent across systems.

Note that only the current insurance data should be sent. Historical insurance information should not be sent.

Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Set ID - IN1 SI_IZ01 R [1..1]2 Health Plan ID CWE_IZ01 R [1..1] 0072_013 Insurance Company ID CX_IZ01 R [1..1]4 Insurance Company Name XON O [0..1]5 Insurance Company Address XAD O [0..1]6 Insurance Co Contact Person XPN O [0..1]7 Insurance Co Phone Number XTN O [0..1]8 Group Number ST O [0..1]9 Group Name XON O [0..1]10 Insured's Group Emp ID CX O [0..1]11 Insured's Group Emp Name XON O [0..1]12 Plan Effective Date DT O [0..1]13 Plan Expiration Date DT O [0..1]14 Authorization Information AUI O [0..1]15 Plan Type CWE_IZ01 R [1..1] 0086_0116 Name Of Insured XPN O [0..1]17 Insured's Relationship To Patient CWE O [0..1]18 Insured's Date Of Birth DTM O [0..1]19 Insured's Address XAD O [0..1]20 Assignment Of Benefits CWE O [0..1]21 Coordination Of Benefits CWE O [0..1]22 Coord Of Ben. Priority ST O [0..1]


Seq Element name Data type Usage Cardinality Value Set23 Notice Of Admission Flag ID O [0..1]24 Notice Of Admission Date DT O [0..1]25 Report Of Eligibility Flag ID O [0..1]26 Report Of Eligibility Date DT O [0..1]27 Release Information Code CWE O [0..1]28 Pre-Admit Cert (PAC) ST O [0..1]29 Verification Date/Time DTM_IZ02 RE [0..1]30 Verification By XCN O [0..1]31 Type Of Agreement Code CWE O [0..1]32 Billing Status CWE O [0..1]33 Lifetime Reserve Days NM O [0..1]34 Delay Before L.R. Day NM O [0..1]35 Company Plan Code CWE O [0..1]36 Policy Number ST O [0..1]37 Policy Deductible CP O [0..1]38 Policy Limit - Amount - X39 Policy Limit - Days NM O [0..1]40 Room Rate - Semi-Private - X41 Room Rate - Private - X42 Insured's Employment Status CWE O [0..1]43 Insured's Administrative Sex CWE O [0..1]44 Insured's Employer's Address XAD O [0..1]45 Verification Status ST O [0..1]46 Prior Insurance Plan ID CWE O [0..1]47 Coverage Type CWE O [0..1]48 Handicap CWE O [0..1]49 Insured's ID Number CX O [0..1]50 Signature Code CWE O [0..1]51 Signature Code Date DT O [0..1]52 Insured's Birth Place ST O [0..1]53 VIP Indicator CWE O [0..1]54 External Health Plan Identifiers CX O [0..1]55 Insurance Action Code ID O [0..1]

Conformance StatementsID DescriptionIZ-69 IN1-1 (Set ID - IN1) SHALL contain the value "1".


3.1.1.1.6 OBX_IZ_01 - OBSERVATION/RESULT

The observation result segment has many uses. It carries observations about the object of its parent segment. In this case, it is associated with the PID segment to convey observations about the patient. The basic format is a question (OBX-3) and an answer (OBX-5).

The Co-Constraints table at the end of this section specifies how to populate an OBX segment based on the observation being messaged. To use the table, find the row containing the LOINC code being messaged in OBX-3. Then use the remaining columns to determine how to populate the remainder of the segment. The data type for OBX-2 is indicated along with valid value sets for various observations (when appropriate for the date type). When populating the segment, the value in OBX-2 must correspond to a value found in HL7 table 0125 but the format of the data in OBX-5 should correspond to a data type flavor described in "OBX-2 (Flavor)". For example, when sending a coded observation value, OBX-2 should be the value "CWE" but OBX-5 should be formatted according to the requirements of the CWE_IZ01 data type flavor.

Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Set ID - OBX SI_IZ01 R [1..1]2 Value Type ID_IZ01 R [1..1] 0125_013 Observation Identifier CWE_IZ01 R [1..1] NIP003_014 Observation Sub-ID OG_IZ01 R [1..1]5 Observation Value VARIES R [1..1]6 Units CWE_IZ01 C(R/O) [0..1]7 References Range ST O [0..1]8 Interpretation Codes CWE O [0..1]9 Probability NM O [0..1]10 Nature of Abnormal Test ID O [0..1]11 Observation Result Status ID_IZ01 R [1..1] 008512 Effective Date of Reference Range DTM O [0..1]13 User Defined Access Checks ST O [0..1]14 Date/Time of the Observation DTM_IZ02 RE [0..1]15 Producer's ID CWE O [0..1]16 Responsible Observer XCN O [0..1]17 Observation Method CWE O [0..1]18 Equipment Instance Identifier EI O [0..1]19 Date/Time of the Analysis DTM O [0..1]20 Observation Site - X21 Observation Instance Identifier - X22 Mood Code - X23 Performing Organization Name XON O [0..1]24 Performing Organization Address XAD O [0..1]25 Performing Organization Medical Director XCN O [0..1]26 Patient Results Release Category ID O [0..1]


Seq Element name Data type Usage Cardinality Value Set27 Root Cause CWE O [0..1]28 Local Process Control CWE O [0..1]29 Observation Type ID O [0..1]30 Observation Sub-Type ID O [0..1]

Conformance StatementsID DescriptionIZ-20 OBX-1 (Set ID - OBX) SHALL be valued sequentially starting with the value "1".IZ-150 OBX-4.1 (Original Sub-Identifier) SHALL contain a positive integer.

OBX_IZ_01-11 OBX-11 (Observation Result Status) SHALL contain the value "F" drawn from the code system "HL70085".

Conditional PredicatesLocation Usage DescriptionOBX-6 C(R/O) If OBX-2 (Value Type) contains the value “NM”.

Co-Constraints IF (OBX-3) Column Value

59784-9

THENOBX-2(Value) CWEOBX-2(Flavor) CWE_IZ01OBX-5(Value Set) PHVS_HistoryOfDisease_IISDescription Disease with presumed immunity

75505-8

THENOBX-2(Value) CWEOBX-2(Flavor) CWE_IZ01OBX-5(Value Set) PHVS_SerologicalEvidenceOfImmunity_IISDescription Disease with serological evidence of immunity

31044-1

THENOBX-2(Value) CWEOBX-2(Flavor) CWE_IZ01OBX-5(Value Set) PHVS_VaccinationReaction_IISDescription Immunization reaction

75323-6

THENOBX-2(Value) CWEOBX-2(Flavor) CWE_IZ01OBX-5(Value Set) PatientConditionDescription Condition

85585-8

THENOBX-2(Value) DTOBX-2(Flavor) DT_IZ01Description Date of condition onset


IF (OBX-3) Column Value

88878-4

THENOBX-2(Value) DTOBX-2(Flavor) DT_IZ01Description Date of condition abatement

OBX-1: Set ID - OBX (SI_IZ01)

This field contains the sequence number. The first instance in the shall be set to 1 and each subsequent instance in the Person Observation segment group shall be the next number in sequence.

OBX-3: Observation Identifier (CWE_IZ01)

This field contains the identifier for the observation.

This may be thought of as a question that the observation in OBX-5 answers.

LOINC shall be the standard coding system for this field if an appropriate LOINC code exists. If a local coding system is in use, a local code may also be sent to help with identification of coding issues. When no valid LOINC exists, the local code may be the only code sent. When populating this field with values, this guide does not give preference to the triplet in which the standard (LOINC) code should appear.

OBX-4: Observation Sub-ID (OG_IZ01)

This field is used to group related observations by setting the value to the same number. For example, when recording patient conditions multiple groups of OBX segments may be needed. One OBX would indicate the patient condition. It may have an associated OBX indicating the the onset date of the condition. These 2 segments would have the same OBX-4 value to allow them to be linked. The second set of related OBX segments for the next condition would have another OBX-4 value common to each of them.

The observation Sub-ID must be unique for each related set of observations within a given Segment Group. Sub-IDs may be re-used between Segment Groups in the message.

OBX-5: Observation Value (VARIES)

This field contains the value of the observation being reported. OBX-2 (Value Type) defines the data type for this field. OBX -3 (Observation Identifier) defines the concept being reported in this field.

OBX-6: Units (CWE_IZ01)

This shall be the units for the value in OBX-5. If there is not a unit of measure available while the Condition Predicated is true, then the value "NA" may be used in OBX-6.1 and "HL70353" in OBX-6.3.

3.1.1.1.7 ORC_IZ_01 - COMMON ORDER

The Common Order segment (ORC) is used to transmit fields that are common to all orders (all types of services that are requested). While not all immunizations transmitted in an immunization message are able to be associated with an order, each RXA must be associated with one ORC, per the HL7 base standard.


Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Order Control ID_IZ01 R [1..1] 01192 Placer Order Number EI_IZ01 RE [0..1]3 Filler Order Number EI_IZ01 R [1..1]4 Placer Group Number EIP O [0..1]5 Order Status ID O [0..1]6 Response Flag ID O [0..1]7 Quantity/Timing - X8 Parent Order EIP O [0..1]9 Date/Time of Transaction DTM O [0..1]10 Entered By XCN_IZ01 RE [0..1]11 Verified By XCN O [0..1]12 Ordering Provider XCN_IZ01 C(RE/O) [0..1]13 Enterer's Location PL O [0..1]14 Call Back Phone Number XTN O [0..1]15 Order Effective Date/Time DTM O [0..1]16 Order Control Code Reason CWE O [0..1]17 Entering Organization CWE_IZ01 RE [0..1] 0362_0118 Entering Device CWE O [0..1]19 Action By XCN O [0..1]20 Advanced Beneficiary Notice Code CWE O [0..1]21 Ordering Facility Name XON O [0..1]22 Ordering Facility Address XAD O [0..1]23 Ordering Facility Phone Number XTN O [0..1]24 Ordering Provider Address XAD O [0..1]25 Order Status Modifier CWE O [0..1]26 Advanced Beneficiary Notice Override Reason CWE O [0..1]27 Filler's Expected Availability Date/Time DTM O [0..1]28 Confidentiality Code CWE O [0..1]29 Order Type CWE O [0..1]30 Enterer Authorization Mode CNE O [0..1]31 Parent Universal Service Identifier CWE O [0..1]32 Advanced Beneficiary Notice Date DT O [0..1]33 Alternate Placer Order Number CX O [0..1]34 Order Workflow Profile CWE O [0..1]

Conformance Statements


ID DescriptionORC_IZ_01-1 ORC-1 (Order Control) SHALL contain the value "RE" drawn from the code system "HL70119".

Conditional PredicatesLocation Usage Description

ORC-12 C(RE/O) If RXA-9.1 (Identifier) contains the value "00" AND RXA-20 (Completion Status) is one of the values in the list (CP, PA).

ORC-2: Placer Order Number (EI_IZ01)

The placer order number is used to uniquely identify this administration among all administrations sent by a provider organization. In the case where the ordering provider organization is not known, this field may be left empty.

ORC-3: Filler Order Number (EI_IZ01)

The filler order number is used to uniquely identify this administration among all administrations sent by a provider organization that filled the order. Use of this foreign key will allow the system receiving the message to accurately identify the previously sent immunization record, facilitating update or deletion of that record.

In the case where a historic immunization is being recorded (e.g. from an immunization card), the system reporting the administration SHALL assign an identifier as if it were an immunization administered by a provider associated with the provider organization owning the system.

Note that the receiving system will need to store this value in addition to its own internal ID in order for this to be used.

ORC-10: Entered By (XCN_IZ01)

This identifies the individual that entered this particular order.

ORC-17: Entering Organization (CWE_IZ01)

The person who entered the request is defined in ORC-10 (entered by).

3.1.1.1.8 RXA_IZ_01 - PHARMACY/TREATMENT ADMINISTRATION

The RXA segment carries pharmacy administration data. It is paired with the ORC segment within the Order Segment Group. Each RXA must be preceded by an ORC.

Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Give Sub-ID Counter NM_IZ01 R [1..1]2 Administration Sub-ID Counter NM_IZ01 R [1..1]3 Date/Time Start of Administration DTM_IZ02 R [1..1]4 Date/Time End of Administration DTM_IZ02 R [1..1]5 Administered Code CWE_IZ01 R [1..1] CVX_01


Seq Element name Data type Usage Cardinality Value Set6 Administered Amount NM_IZ01 R [1..1]7 Administered Units CWE_IZ01 C(R/X) [0..1] UCUM_018 Administered Dosage Form CWE O [0..1]9 Administration Notes CWE_IZ01 C(R/O) [0..1] NIP001_0110 Administering Provider XCN_IZ01 C(RE/O) [0..1]11 Administered-at Location - X12 Administered Per (Time Unit) ST O [0..1]13 Administered Strength NM O [0..1]14 Administered Strength Units CWE O [0..1]15 Substance Lot Number ST_IZ01 C(R/O) [0..*]16 Substance Expiration Date DTM_IZ03 C(RE/O) [0..1]17 Substance Manufacturer Name CWE_IZ01 C(R/O) [0..1] MVX_0118 Substance/Treatment Refusal Reason CWE_IZ01 C(R/X) [0..*] NIP002_0119 Indication CWE O [0..1]20 Completion Status ID_IZ01 RE [0..1] 0322_0121 Action Code - RXA ID_IZ01 C(R/X) [0..1] 0206_0122 System Entry Date/Time DTM O [0..1]23 Administered Drug Strength Volume NM O [0..1]24 Administered Drug Strength Volume Units CWE O [0..1]25 Administered Barcode Identifier CWE O [0..1]26 Pharmacy Order Type ID O [0..1]27 Administer-at PL_IZ01 C(RE/O) [0..1]28 Administered-at Address XAD O [0..1]29 Administered Tag Identifier EI O [0..1]

Conformance StatementsID DescriptionRXA_IZ_01-1 RXA-1 (Give Sub-ID Counter) SHALL contain the value "0".RXA_IZ_01-2 RXA-2 (Administration Sub-ID Counter) SHALL contain the value "1".

IZ-30 RXA-4 (Date/Time End of Administration) SHALL be identical to the value of RXA-3 (Date/Time Start of Administration).

IZ-49 IF RXA-5.1 (Identifier) contains the value "998" THEN RXA-6 (Administered Amount) SHALL contain the value "999".

IZ-207 IF RXA-20 (Completion Status) contains the value "RE" THEN RXA-5.1 (Identifier) SHALL NOT contain the value "998".

IZ-48 IF RXA-20 (Completion Status) contains the value "RE" THEN RXA-6 (Administered Amount) SHALL contain the value "999".

IZ-32 IF RXA-18 (Substance/Treatment Refusal Reason) is valued THEN RXA-20 (Completion Status) SHALL contain the value "RE".

Conditional Predicates


Location Usage DescriptionRXA-7 C(R/X) If RXA-6 (Administered Amount) does not contain the value “999”.RXA-9 C(R/O) If RXA-20 (Completion Status) is one of the values in the list (CP, PA).

RXA-10 C(RE/O) If RXA-9.1 (Identifier) contains the value “00” AND RXA-20 (Completion Status) is one of the values in the list (CP, PA).

RXA-15 C(R/O) If RXA-9.1 (Identifier) contains the value “00” AND RXA-20 (Completion Status) is one of the values in the list (CP, PA).


RXA-17 C(R/O) If RXA-9.1 (Identifier) contains the value “00” AND RXA-20 (Completion Status) is one of the values in the list (CP, PA).

RXA-18 C(R/X) If RXA-20 (Completion Status) contains the value “RE”.RXA-21 C(R/X) If RXA-5.1 (Identifier) does not contain the value “998”.


RXA-1: Give Sub-ID Counter (NM_IZ01)

This field is used to match an RXA and RXG, which is not applicable to the processing of immunization data, however the field is required to match the base standard requirements.

Note that in the Conformance Statement, "0" is zero.

RXA-2: Administration Sub-ID Counter (NM_IZ01)

This field is used to track multiple RXA segments under an ORC. Since each ORC has only one RXA in immunization messages, this field is constrained to 1. This should not be used for indicating dose number, which is messaged via the OBX segment.

RXA-3: Date/Time Start of Administration (DTM_IZ02)

The date this vaccination occurred. In the case of a contraindication, refusal or deferral, this is the date the action occurred.

RXA-4: Date/Time End of Administration (DTM_IZ02)

This field is specified as required in the HL7 base standard. An immunization is given at a point in time, and in the context of immunization, the End date/time is equivalent to the Start date/time. For this reason, this document has required this field to be equal to RXA-3.

RXA-5: Administered Code (CWE_IZ01)

This field identifies the medical substance administered. If the substance administered is a vaccine, CVX and NDC codes are typically used for historical and new administrations respectively. The second set of three components may be used to represent the same vaccine using a different coding system.

RXA-6: Administered Amount (NM_IZ01)


This field records the amount of vaccine administered. The units are expressed in the next field, RXA-7. When the administered amount is unknown, this field should be populated with the value "999".

RXA-9: Administration Notes (CWE_IZ01)

This field is used to indicate whether this immunization record is based on a historical record or is being reported by the administering provider.

RXA-10: Administering Provider (XCN_IZ01)

This is the person who gave the administration. It is not the ordering clinician.

RXA-11: Administered-at Location (-)

RXA-11 has been deprecated in the v2.8 base standard and has been replaced by RXA-27.

RXA-16: Substance Expiration Date (DTM_IZ03)

A vaccine expiration date does not always have a "day" component; therefore, such a date may be transmitted as YYYYMM.

RXA-18: Substance/Treatment Refusal Reason (CWE_IZ01)

This field contains the reason the patient refused the medical substance/treatment. Any entry in the field indicates that the patient did not take the substance.

RXA-20: Completion Status (ID_IZ01)

The system generating the RXA should typically be able to determine the appropriate value for RXA-20, however most IIS will assume a default value of CP (Complete) when RXA-20 is empty.

RXA-21: Action Code - RXA (ID_IZ01)

This field indicates the action taken by the system constructing the message. It can facilitate update or deletion of immunization records.

When processing Update or Delete messages, ORC-3, Placer order number, may be used to link to a specific immunization if the system receiving the message has recorded this from the initial order. Local implementers should specify its use in a local implementation guide.

The action code U (Update) is used to indicate to a receiver that a previously sent immunization should be changed. Most IIS have specific criteria for determining whether to add or update an immunization that do not rely directly on this field.

When sending a Delete message, the VXU^V04 message should be constructed such that all data in the message, including segments in the Order Group, are the same as the most recent message for the administration, except for the Action Code (RXA-21) which should be D. Importantly, the filler ID in ORC-3


should be the same between messages as this ID may be crucial to identifying the correct administration to remove. Once the inaccurate data have been deleted, additional independent messages (adds, refusals, etc) can be sent to accurately populate the receiving system.

RXA-27: Administer-at (PL_IZ01)

This field specifies the location where the vaccine was administered. RXA-27 replaces RXA-11 from previous versions of the immunization messaging implementation guide.

3.1.1.1.9 RXR_IZ - PHARMACY/TREATMENT ROUTE

Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Route CWE_IZ01 R [1..1] NCIT_012 Administration Site CWE_IZ01 RE [0..1] 0163_013 Administration Device CWE O [0..1]4 Administration Method CWE O [0..1]5 Routing Instruction CWE O [0..1]6 Administration Site Modifier CWE O [0..1]

3.1.1.1.10OBX_IZ_02 - OBSERVATION/RESULT

The observation result segment has many uses. It carries observations about the object of its parent segment. In this case, it is associated with the RXA segment. The basic format is a question (OBX-3) and an answer (OBX-5).

The Co-Constraints table at the end of this section specifies how to populate an OBX segment based on the observation being messaged. To use the table, find the row containing the LOINC code being messaged in OBX-3. Then use the remaining columns to determine how to populate the remainder of the segment. The data type for OBX-2 is indicated along with valid value sets for various observations (when appropriate for the date type). When populating the segment, the value in OBX-2 must correspond to a value found in HL7 table 0125 but the format of the data in OBX-5 should correspond to a data type flavor described in "OBX-2 (Flavor)". For example, when sending a coded observation value, OBX-2 should be the value "CWE" but OBX-5 should be formatted according to the requirements of the CWE_IZ01 data type flavor.

Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Set ID - OBX SI_IZ01 R [1..1]2 Value Type ID_IZ01 R [1..1] 0125_013 Observation Identifier CWE_IZ01 R [1..1] NIP003_024 Observation Sub-ID OG_IZ01 R [1..1]5 Observation Value VARIES R [1..1]6 Units CWE_IZ01 C(R/O) [0..1]7 References Range ST O [0..1]8 Interpretation Codes CWE O [0..1]9 Probability NM O [0..1]


Seq Element name Data type Usage Cardinality Value Set10 Nature of Abnormal Test ID O [0..1]11 Observation Result Status ID_IZ01 R [1..1] 008512 Effective Date of Reference Range DTM O [0..1]13 User Defined Access Checks ST O [0..1]14 Date/Time of the Observation DTM_IZ02 RE [0..1]15 Producer's ID CWE O [0..1]16 Responsible Observer XCN O [0..1]17 Observation Method CWE O [0..1]18 Equipment Instance Identifier EI O [0..1]19 Date/Time of the Analysis DTM O [0..1]20 Observation Site - X21 Observation Instance Identifier - X22 Mood Code - X23 Performing Organization Name XON O [0..1]24 Performing Organization Address XAD O [0..1]

25 Performing Organization Medical Director XCN O [0..1]

26 Patient Results Release Category ID O [0..1]27 Root Cause CWE O [0..1]28 Local Process Control CWE O [0..1]29 Observation Type ID O [0..1]30 Observation Sub-Type ID O [0..1]



Conditional PredicatesLocation Usage DescriptionOBX-6 C(R/O) If OBX-2 (Value Type) contains the value "NM".

Co-Constraints IF (OBX-3) Column Value64994-7 THEN

OBX-2(Value) CWEOBX-2(Flavor) CWE_IZ01OBX-5(Value Set) 0064_01


IF (OBX-3) Column ValueDescription Vaccine funding program eligibility category

30963-3

THENOBX-2(Value) CWEOBX-2(Flavor) CWE_IZ01OBX-5(Value Set) PHVS_ImmunizationFundingSource_IISDescription Vaccine funding source

69764-9

THENOBX-2(Value) CWEOBX-2(Flavor) CWE_IZ01OBX-5(Value Set) PHVS_VISBarcodes_IISDescription Document type

29769-7

THENOBX-2(Value) DTOBX-2(Flavor) DT_IZ01Description Date vaccine information statement presented

29768-9

THENOBX-2(Value) DTOBX-2(Flavor) DT_IZ01Description Date vaccine information statement published

30956-7

THENOBX-2(Value) CWEOBX-2(Flavor) CWE_IZ01OBX-5(Value Set) CVX_02Description Type [Identifier] Vaccine

31044-1


59785-6

THENOBX-2(Value) CWEOBX-2(Flavor) CWE_IZ01OBX-5(Value Set) PHVS_VaccinationSpecialIndications_IISDescription Indication for immunization

88877-6

THENOBX-2(Value) DTOBX-2(Flavor) DT_IZ01Description Date of vaccination indication effective

88879-2

THENOBX-2(Value) DTOBX-2(Flavor) DT_IZ01Description Date of vaccination temporary indication expiration



30945-0

THENOBX-2(Value) CWEOBX-2(Flavor) CWE_IZ01OBX-5(Value Set) PHVS_VaccinationContraindication_IISDescription Vaccination contraindication/precaution

30946-8

THENOBX-2(Value) DTOBX-2(Flavor) DT_IZ01Description Date.vaccination contraindication/precaution effective

30944-3

THENOBX-2(Value) DTOBX-2(Flavor) DT_IZ01Description Date of vaccination temporary contraindication/precaution expiration

48767-8 THENOBX-2(Value) TXOBX-2(Flavor) TX_IZ01Description Annotation comment


This field contains the sequence number. The first instance shall be set to 1 and each subsequent instance shall be the next number in sequence. Numbering might not be restarted within a message. That is, if a message had 3 segment groups containing OBX segments and each had 3 OBX, the last OBX in the message would have value of 9 for this field. Alternatively, the Set ID is also allowed to restart for each segment group. That is, if a message had 3 order segment groups and each had 3 OBX segments, all three groups would contain OBX segments with Set IDs of 1, 2 and 3. Either approach, restarting or not restarting per set of OBX segments, is allowed.






This field is used to group related observations by setting the value to the same number. For example, recording VIS fully-encoded text string and VIS presentation date for a combination vaccination requires multiple groups of OBX segments. One OBX would indicate the document type and version using the fully-encoded text string. It would have an associated OBX indicating the VIS presentation date. These 2 segments


would have the same OBX-4 value to allow them to be linked. The second set of related OBX segments for the next vaccine component would have another OBX-4 value common to each of them.

The observation Sub-ID must be unique for each related set of observations within a given order Segment Group. Sub-IDs may be re-used between order Segment Groups in the message.





3.1.2 ACK^VARIES^ACK - IZ23R1.0 - RESPOND WITH A GENERAL ACKNOWLEDGEMENT

The IZ23r1.0 - Respond with a General Acknowledgment profile is a constrainable profile that supports the acknowledgement of receipt and processing of a partner message (VXU or QBP). Errors found during processing may be indicated. The system generating the ACK is typically an Immunization Information System (IIS), but may be an Electronic Health Record system (EHR-S) or another type of health information system which has received a message from a trading partner.

The IZ23r1.0 profile is the response to the IZ22r1.0 - Send an Unsolicited Immunization Event and IZ24r1.0 - Send Demographics Only profiles. It is also one possible response to the IZ54r1.0 - Request an Immunization History with Forecast query.

Conformance Profile Definition Segment Flavor Element name Usage CardinalityMSH MSH_IZ Message Header R [1..1]SFT SFT Software Segment O [0..*]UAC UAC User Authentication Credential Segment O [0..1]MSA MSA_IZ Message Acknowledgment R [1..1]ERR ERR_IZ Error RE [0..*]


IZ-152 IF MSA-1 (Acknowledgement Code) contains the value “AA” THEN ERR-4 (Error Severity) in no occurrences of the ERR Segment SHALL contain one of values in the list (W, E).

IZ-153 IF MSA-1 (Acknowledgment Code) contains the value “AE” THEN ERR-4 (Severity) in at least one occurrence of the ERR Segment SHALL contain one of values in the list (W, E).

IZ-154 IF MSA-1 (Acknowledgment Code) contains the value “AR” THEN ERR-4 (Severity) in at least one occurrence of the ERR Segment SHALL contain the value “E”.

An ERR segment is only included if an error or warning is encountered during processing the message.




Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Field Separator ST_IZ01 R [1..1]2 Encoding Characters ST_IZ01 R [1..1]3 Sending Application HD_IZ01 RE [0..1] 0361_014 Sending Facility HD_IZ01 RE [0..1] 0362_015 Receiving Application HD_IZ01 RE [0..1] 0361_016 Receiving Facility HD_IZ01 RE [0..1] 0362_017 Date/Time of Message DTM_IZ01 R [1..1]8 Security ST O [0..1]9 Message Type MSG_IZ01 R [1..1]10 Message Control ID ST_IZ01 R [1..1]11 Processing ID PT_IZ01 R [1..1]12 Version ID VID_IZ01 R [1..1]13 Sequence Number NM O [0..1]14 Continuation Pointer ST O [0..1]15 Accept Acknowledgment Type ID_IZ01 R [1..1] 0155


17 Country Code ID O [0..1]18 Character Set ID O [0..1]19 Principal Language Of Message CWE O [0..1]






Conformance StatementsID DescriptionIZ-12 MSH-1 (Field Separator) SHALL contain the value “|”.IZ-13 MSH-2 (Encoding Characters) SHALL contain the value “^~\&”.IZ-90 MSH-9.1 (Message Code) SHALL contain the value "ACK" drawn from the code system "HL70076".

IZ-91 MSH-9.2 (Trigger Event) SHALL be from the list of values drawn from the code system "HL70003": V04, A31, Q11.


ID DescriptionIZ-92 MSH-9.3 (Message Structure) SHALL contain the value "ACK" drawn from the code system "HL70354".IZ-74 MSH-12.1 (Version ID) SHALL contain the value "2.8.2".


IZ-52 MSH-16 (Application Acknowledgment Type) SHALL contain the value "NE" drawn from the code system "HL70155".

IZ-93 In exactly one occurrence of MSH-21 (Message Profile Identifier), MSH-21.1 (Entity Identifier) SHALL contain the value "IZ23r1.0" AND MSH-21.2 (Namespace ID) SHALL contain the value "CDCPHINVS".












This field contains the identifier assigned by the sending system that uniquely identifies a message instance. This identifier is unique within the scope of the sending system and the YYYYMMDD portion of message date (MSH-7). When generating a response message, the receiving system echoes this ID back to the sending


system in the Message Acknowledgment segment (MSA). The content and format of the data sent in this field are the responsibility of the sender.










This field has the same justification as the Sending Responsible Organization except in the role of the Receiving Responsible Organization. The receiving organization has the responsibility to act on the information in the message.

3.1.2.1.2 MSA_IZ - MESSAGE ACKNOWLEDGMENT

Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Acknowledgment Code ID_IZ01 R [1..1] 0008_012 Message Control ID ST_IZ01 R [1..1]3 Text Message - X4 Expected Sequence Number NM O [0..*]5 Delayed Acknowledgment Type - X6 Error Condition - X7 Message Waiting Number NM O [0..*]


Seq Element name Data type Usage Cardinality Value Set8 Message Waiting Priority ID O [0..*]

MSA-2: Message Control ID (ST_IZ01)

This field contains the message control ID (MSH-10) of the message sent by the initiating system.

3.1.2.1.3 ERR_IZ - ERROR

Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Error Code and Location - X2 Error Location ERL_IZ01 RE [0..1]3 HL7 Error Code CWE_IZ01 R [1..1] 0357_014 Severity ID_IZ01 R [1..1] 0516_015 Application Error Code CWE_IZ01 RE [0..1] 0533_016 Application Error Parameter ST O [0..10]7 Diagnostic Information TX O [0..*]8 User Message TX_IZ01 RE [0..1]9 Inform Person Indicator CWE O [0..*]10 Override Type CWE O [0..*]11 Override Reason Code CWE O [0..*]12 Help Desk Contact Point XTN O [0..*]

ERR-2: Error Location (ERL_IZ01)

An ERR segment may only describe a single error condition, so repeats are not allowed on this field. This field may be left empty if location is not meaningful. For example, if an error involves the entire message (e.g. the message is not parse-able), then location has no meaning. In this case, ERR-2 is left empty.

ERR-4: Severity (ID_IZ01)

Identifies the severity of an application error. The Severity code indicates if the system sending the ACK or RSP is reporting an error that caused significant error loss.

3.1.3 ADT^A31^ADT_A05 - IZ24R1.0 - SEND DEMOGRAPHICS ONLY

The IZ24r1.0 - Send Demographics Only profile is a constrainable profile that supports the messaging of patient demographics data without any associated immunization event data. This may be used to add a new patient or to update an existing patient.

The goal of this interaction is to transfer patient demographic information from one health information system to another. The initiating system is typically an Electronic Health Record system (EHR-S) but may be an Immunization Information System (IIS) or another type of health information system.

The IZ24r1.0 profile has a partner profile for acknowledging processing of the message, IZ23r1.0 - Respond with a General Acknowledgment.


The message may also contain one or more OBX segments, each containing a patient level observation. The following OBX segment types are relevant:


Serological evidence of immunity - LOINC code 75505-8 Presumed evidence of immunity - LOINC code 59784-9 Condition - LOINC code 75323-6 Date of condition onset - LOINC code 85585-8 Date of condition abatement - LOINC code 88878-4

Conformance Profile Definition Segment Flavor Element name Usage CardinalityMSH MSH_IZ Message Header R [1..1]SFT SFT Software Segment O [0..*]UAC UAC User Authentication Credential Segment O [0..1]EVN EVN_IZ Event Type R [1..1]PID PID_IZ Patient Identification R [1..1]PD1 PD1_IZ_01 Patient Additional Demographic RE [0..1]ARV ARV Access Restriction O [0..*]ROL ROL Role O [0..*]NK1 NK1_IZ Next of Kin / Associated Parties RE [0..*]PV1 PV1_IZ Patient Visit R [1..1]PV2 PV2 Patient Visit - Additional Information O [0..1]ARV ARV Access Restriction O [0..*]ROL ROL Role O [0..*]DB1 DB1 Disability O [0..*]OBX OBX_IZ_01 Observation/Result RE [0..*]AL1 AL1 Patient Allergy Information O [0..*]DG1 DG1 Diagnosis O [0..*]DRG DRG Diagnosis Related Group O [0..1][ BEGIN PROCEDURE GROUP O [0..*]PR1 PR1 Procedures R [1..1]ROL ROL Role O [0..*]] END PROCEDURE GROUPGT1 GT1 Guarantor O [0..*][ BEGIN INSURANCE GROUP O [0..1]IN1 IN1_IZ Insurance R [1..1]IN2 IN2 Insurance Additional Information O [0..1]

IN3 IN3 Insurance Additional Information, Certification O [0..1]

ROL ROL Role O [0..*]AUT AUT Authorization Information O [0..*]RF1 RF1 Referral Information O [0..*]


Segment Flavor Element name Usage Cardinality] END INSURANCE GROUPACC ACC Accident O [0..1]UB1 UB1 UB82 O [0..1]UB2 UB2 Uniform Billing Data O [0..1]













Conformance StatementsID DescriptionIZ-12 MSH-1 (Field Separator) SHALL contain the value “|”.IZ-13 MSH-2 (Encoding Characters) SHALL contain the value “^~\&”.IZ-176 MSH-9.1 (Message Code) SHALL contain the value "ADT" drawn from the code system "HL70076".IZ-177 MSH-9.2 (Trigger Event) SHALL contain the value "A31" drawn from the code system "HL70003".

IZ-178 MSH-9.3 (Message Structure) SHALL contain the value "ADT_A05" drawn from the code system "HL70354".














Depending on the architecture of the integration, MSH-6 may or may not be the same organization that is the ultimate recipient of the message. For example, if an EHR communicates with an IIS via a Health Information


Exchange (HIE), the value in MSH-6 may change (depending on local policy) from representing the HIE to representing the IIS as the message moves between systems. This value may represent the same organization as sent in MSH-23 but does not have to.














3.1.3.1.2 EVN_IZ - EVENT TYPE

The EVN segment is used to communicate necessary trigger event information to receiving applications. The inclusion of this segment is required by the HL7 base standard definition of the ADT^A31 message but it is not expected to play a significant role in the exchange of immunization data.

Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Event Type Code - X2 Recorded Date/Time DTM_IZ02 R [1..1]3 Date/Time Planned Event DTM O [0..*]4 Event Reason Code CWE O [0..*]5 Operator ID XCN O [0..*]6 Event Occurred DTM O [0..*]7 Event Facility HD O [0..*]


Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Set ID - PID SI_IZ01 R [1..1]2 Patient ID - X3 Patient Identifier List CX_IZ01 R [1..*]4 Alternate Patient ID - PID - X5 Patient Name XPN_IZ01 R [1..*]6 Mother's Maiden Name XPN_IZ02 RE [0..1]7 Date/Time of Birth DTM_IZ02 R [1..1]8 Administrative Sex CWE_IZ01 R [1..1] 0001_019 Patient Alias - X10 Race CWE_IZ01 RE [0..*] CDCREC_0111 Patient Address XAD_IZ01 RE [0..*]12 County Code - X13 Phone Number - Home XTN_IZ01 RE [0..*]14 Phone Number - Business XTN O [0..*]15 Primary Language CWE O [0..1]16 Marital Status CWE O [0..1]17 Religion CWE O [0..1]18 Patient Account Number CX O [0..1]19 SSN Number - Patient - X20 Driver's License Number - Patient - X21 Mother's Identifier CX O [0..*]22 Ethnic Group CWE_IZ01 RE [0..1] CDCREC_02


Seq Element name Data type Usage Cardinality Value Set23 Birth Place ST O [0..1]24 Multiple Birth Indicator ID_IZ01 RE [0..1] 0136_0125 Birth Order NM_IZ01 C(RE/O) [0..1]26 Citizenship CWE O [0..1]27 Veterans Military Status CWE O [0..1]28 Nationality - X29 Patient Death Date and Time DTM_IZ02 C(RE/X) [0..1]30 Patient Death Indicator ID_IZ01 RE [0..1] 0136_0131 Identity Unknown Indicator ID O [0..1]32 Identity Reliability Code CWE O [0..1]33 Last Update Date/Time DTM O [0..1]34 Last Update Facility HD O [0..1]35 Taxonomic Classification Code CWE O [0..1]36 Breed Code - X37 Strain ST O [0..1]38 Production Class Code CWE O [0..1]39 Tribal Citizenship CWE O [0..1]

40 Patient Telecommunication Information XTN O [0..1]

Conformance StatementsID DescriptionIZ-46 PID-1 (Set ID - PID) SHALL contain the value "1".











Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Living Dependency CWE O [0..1]2 Living Arrangement CWE O [0..1]3 Patient Primary Facility XON O [0..1]4 Patient Primary Care Provider Name & ID No. - X5 Student Indicator CWE O [0..1]6 Handicap CWE O [0..1]7 Living Will Code CWE O [0..1]8 Organ Donor Code CWE O [0..1]9 Separate Bill ID O [0..1]10 Duplicate Patient CX O [0..1]11 Publicity Code CWE_IZ01 RE [0..1] 0215_0112 Protection Indicator ID_IZ01 RE [0..1] 0136_0113 Protection Indicator Effective Date DT_IZ01 C(RE/X) [0..1]14 Place of Worship XON O [0..1]15 Advance Directive Code CWE O [0..1]16 Immunization Registry Status CWE_IZ01 RE [0..1] 0441_0117 Immunization Registry Status Effective Date DT_IZ01 C(RE/X) [0..1]18 Publicity Code Effective Date DT_IZ01 C(RE/X) [0..1]19 Military Branch CWE O [0..1]20 Military Rank/Grade CWE O [0..1]21 Military Status CWE O [0..1]22 Advance Directive Last Verified Date DT O [0..1]

Conditional PredicatesLocation Usage DescriptionPD1-13 C(RE/X) If PD1-12 (Protection Indicator) is valued.PD1-17 C(RE/X) If PD1-16 (Immunization Registry Status) is valued.PD1-18 C(RE/X) If PD1-11 (Publicity Code) is valued.






PD1-12: Protection Indicator (ID_IZ01)

This field identifies whether a person's information may be shared with others (local policies determine how data are protected). The protection state must be explicitly captured in the system documenting the immunization. If it is not actively determined, then the protection indicator shall be empty.

There are 3 states:Protection State CodeYes, protect the data. Patient (or guardian) has indicated that the information shall be protected. (Do not share data) Y

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

No determination has been made regarding patient's (or guardian's) wishes regarding information sharing PD1-12 is empty

Notes on use of Y for Protection Indicator in starting in version 2.5.1

Note that Implementation Guides based on HL7 versions less than 2.5 stated that Y meant that a person's information could be shared. This was an incorrect interpretation of the use of this field. The meaning now aligns with the base definition of HL7, that is, Y means data must be protected. Existing systems that use the old meaning will need to determine how they will send the correct value in messages based on version 2.5.1 or beyond.

Note that the requirements in this document do not affect the value sent in a message that is based on the 2.3.1 or 2.4 version of the HL7 standard (which may continue to follow the old guidance - that is, Y means sharing is allowed and N means sharing is not allowed). A system receiving a message containing a PD1 segment must process the protection indicator in a way consistent with the HL7 version the message is based on.


This field identifies the current status of the patient in relation to the sending organization. The term "sending organization" refers to the organization that is accountable for the content of the message. This may be an EHR for a VXU^V04 message or an IIS for an RSP^K11 message. PD1-16 should reflect the status of the patient relative to the system creating the message.






Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Set ID - NK1 SI_IZ01 R [1..1]2 Name XPN_IZ01 R [1..*]3 Relationship CWE_IZ01 R [1..1] 0063_014 Address XAD_IZ01 RE [0..*]5 Phone Number XTN_IZ01 RE [0..*]6 Business Phone Number XTN O [0..1]7 Contact Role CWE O [0..1]8 Start Date DT O [0..1]9 End Date DT O [0..1]10 Next of Kin / Associated Parties Job Title ST O [0..1]11 Next of Kin / Associated Parties Job Code/Class JCC O [0..1]


13 Organization Name - NK1 XON O [0..1]14 Marital Status CWE O [0..1]15 Administrative Sex CWE O [0..1]16 Date/Time of Birth DTM O [0..1]17 Living Dependency CWE O [0..1]18 Ambulatory Status CWE O [0..1]19 Citizenship CWE O [0..1]20 Primary Language CWE O [0..1]21 Living Arrangement CWE O [0..1]22 Publicity Code CWE O [0..1]23 Protection Indicator ID O [0..1]24 Student Indicator CWE O [0..1]25 Religion CWE O [0..1]26 Mother's Maiden Name XPN O [0..1]27 Nationality CWE O [0..1]28 Ethnic Group CWE O [0..1]29 Contact Reason CWE O [0..1]


Seq Element name Data type Usage Cardinality Value Set30 Contact Person's Name XPN O [0..1]31 Contact Person's Telephone Number XTN O [0..1]32 Contact Person's Address XAD O [0..1]33 Next of Kin/Associated Party's Identifiers CX O [0..1]34 Job Status CWE O [0..1]35 Race CWE O [0..1]36 Handicap CWE O [0..1]37 Contact Person Social Security Number ST O [0..1]38 Next of Kin Birth Place ST O [0..1]39 VIP Indicator CWE O [0..1]40 Next of Kin Telecommunication Information XTN O [0..1]



3.1.3.1.6 PV1_IZ - PATIENT VISIT

Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Set ID - PV1 SI O [0..*]2 Patient Class CWE_IZ01 R [1..1] 0004_013 Assigned Patient Location PL O [0..*]4 Admission Type CWE O [0..*]5 Preadmit Number CX O [0..*]6 Prior Patient Location PL O [0..*]7 Attending Doctor XCN O [0..*]8 Referring Doctor XCN O [0..*]9 Consulting Doctor - X10 Hospital Service CWE O [0..*]11 Temporary Location PL O [0..*]12 Preadmit Test Indicator CWE O [0..*]13 Re-admission Indicator CWE O [0..*]14 Admit Source CWE O [0..*]15 Ambulatory Status CWE O [0..*]16 VIP Indicator CWE O [0..*]17 Admitting Doctor XCN O [0..*]


Seq Element name Data type Usage Cardinality Value Set18 Patient Type CWE O [0..*]19 Visit Number CX O [0..*]20 Financial Class FC O [0..*]21 Charge Price Indicator CWE O [0..*]22 Courtesy Code CWE O [0..*]23 Credit Rating CWE O [0..*]24 Contract Code CWE O [0..*]25 Contract Effective Date DT O [0..*]26 Contract Amount NM O [0..*]27 Contract Period NM O [0..*]28 Interest Code CWE O [0..*]29 Transfer to Bad Debt Code CWE O [0..*]30 Transfer to Bad Debt Date DT O [0..*]31 Bad Debt Agency Code CWE O [0..*]32 Bad Debt Transfer Amount NM O [0..*]33 Bad Debt Recovery Amount NM O [0..*]34 Delete Account Indicator CWE O [0..*]35 Delete Account Date DT O [0..*]36 Discharge Disposition CWE O [0..*]37 Discharged to Location DLD O [0..*]38 Diet Type CWE O [0..*]39 Servicing Facility CWE O [0..*]40 Bed Status - X41 Account Status CWE O [0..*]42 Pending Location PL O [0..*]43 Prior Temporary Location PL O [0..*]44 Admit Date/Time DTM O [0..*]45 Discharge Date/Time DTM O [0..*]46 Current Patient Balance NM O [0..*]47 Total Charges NM O [0..*]48 Total Adjustments NM O [0..*]49 Total Payments NM O [0..*]50 Alternate Visit ID CX O [0..*]51 Visit Indicator CWE O [0..*]52 Other Healthcare Provider - X53 Service Episode Description ST O [0..*]54 Service Episode Identifier CX O [0..*]


3.1.3.1.7 OBX_IZ_01 - OBSERVATION/RESULT


The Co-Constraints table at the end of this section specifies how to populate an OBX segment based on the observation being messaged. To use the table, find the row containing the LOINC code being messaged in OBX-3. Then use the remaining columns to determine how to populate the remainder of the segment. The data type for OBX-2 is indicated along with valid value sets for various observations (when appropriate for the date type). When populating the segment, the value in OBX-2 must correspond to a value found in HL7 table 0125 but the format of the data in OBX-5 should correspond to a data type flavor described in "OBX-2 (Flavor)" . For example, when sending a coded observation value, OBX-2 should be the value "CWE" but OBX-5 should be formatted according to the requirements of the CWE_IZ01 data type flavor.

Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Set ID - OBX SI_IZ01 R [1..1]2 Value Type ID_IZ01 R [1..1] 0125_013 Observation Identifier CWE_IZ01 R [1..1] NIP003_014 Observation Sub-ID OG_IZ01 R [1..1]5 Observation Value VARIES R [1..1]6 Units CWE_IZ01 C(R/O) [0..1]7 References Range ST O [0..1]8 Interpretation Codes CWE O [0..1]9 Probability NM O [0..1]10 Nature of Abnormal Test ID O [0..1]11 Observation Result Status ID_IZ01 R [1..1] 008512 Effective Date of Reference Range DTM O [0..1]13 User Defined Access Checks ST O [0..1]14 Date/Time of the Observation DTM_IZ02 RE [0..1]15 Producer's ID CWE O [0..1]16 Responsible Observer XCN O [0..1]17 Observation Method CWE O [0..1]18 Equipment Instance Identifier EI O [0..1]19 Date/Time of the Analysis DTM O [0..1]20 Observation Site - X21 Observation Instance Identifier - X22 Mood Code - X23 Performing Organization Name XON O [0..1]24 Performing Organization Address XAD O [0..1]



25 Performing Organization Medical Director XCN O [0..1]

26 Patient Results Release Category ID O [0..1]27 Root Cause CWE O [0..1]28 Local Process Control CWE O [0..1]29 Observation Type ID O [0..1]30 Observation Sub-Type ID O [0..1]





59784-9

THENOBX-2(Value) CWEOBX-2(Flavor) CWE_IZ01OBX-5(Value Set) PHVS_HistoryOfDisease_IISDescription Disease with presumed immunity

75505-8


31044-1


75323-6


85585-8 THEN


IF (OBX-3) Column ValueOBX-2(Value) DTOBX-2(Flavor) DT_IZ01Description Date of condition onset

88878-4









This field is used to group related observations by setting the value to the same number. For example, when recording patient conditions multiple groups of OBX segments may be needed. One OBX would indicate the patient condition. It may have an associated OBX indicating the onset date of the condition. These 2 segments would have the same OBX-4 value to allow them to be linked. The second set of related OBX segments for the next condition would have another OBX-4 value common to each of them.










Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Set ID - IN1 SI_IZ01 R [1..1]2 Health Plan ID CWE_IZ01 R [1..1] 0072_013 Insurance Company ID CX_IZ01 R [1..1]4 Insurance Company Name XON O [0..1]5 Insurance Company Address XAD O [0..1]6 Insurance Co Contact Person XPN O [0..1]7 Insurance Co Phone Number XTN O [0..1]8 Group Number ST O [0..1]9 Group Name XON O [0..1]10 Insured's Group Emp ID CX O [0..1]11 Insured's Group Emp Name XON O [0..1]12 Plan Effective Date DT O [0..1]13 Plan Expiration Date DT O [0..1]14 Authorization Information AUI O [0..1]15 Plan Type CWE_IZ01 R [1..1] 0086_0116 Name Of Insured XPN O [0..1]17 Insured's Relationship To Patient CWE O [0..1]18 Insured's Date Of Birth DTM O [0..1]19 Insured's Address XAD O [0..1]20 Assignment Of Benefits CWE O [0..1]21 Coordination Of Benefits CWE O [0..1]22 Coord Of Ben. Priority ST O [0..1]23 Notice Of Admission Flag ID O [0..1]24 Notice Of Admission Date DT O [0..1]25 Report Of Eligibility Flag ID O [0..1]26 Report Of Eligibility Date DT O [0..1]27 Release Information Code CWE O [0..1]28 Pre-Admit Cert (PAC) ST O [0..1]29 Verification Date/Time DTM_IZ02 RE [0..1]


Seq Element name Data type Usage Cardinality Value Set30 Verification By XCN O [0..1]31 Type Of Agreement Code CWE O [0..1]32 Billing Status CWE O [0..1]33 Lifetime Reserve Days NM O [0..1]34 Delay Before L.R. Day NM O [0..1]35 Company Plan Code CWE O [0..1]36 Policy Number ST O [0..1]37 Policy Deductible CP O [0..1]38 Policy Limit - Amount - X39 Policy Limit - Days NM O [0..1]40 Room Rate - Semi-Private - X41 Room Rate - Private - X42 Insured's Employment Status CWE O [0..1]43 Insured's Administrative Sex CWE O [0..1]44 Insured's Employer's Address XAD O [0..1]45 Verification Status ST O [0..1]46 Prior Insurance Plan ID CWE O [0..1]47 Coverage Type CWE O [0..1]48 Handicap CWE O [0..1]49 Insured's ID Number CX O [0..1]50 Signature Code CWE O [0..1]51 Signature Code Date DT O [0..1]52 Insured's Birth Place ST O [0..1]53 VIP Indicator CWE O [0..1]54 External Health Plan Identifiers CX O [0..1]55 Insurance Action Code ID O [0..1]

Conformance StatementsID DescriptionIZ-69 IN1-1 (Set ID - IN1) SHALL contain the value "1"..

3.1.4 QBP^Q11^QBP_Q11 - IZ54R1.0 - REQUEST AN IMMUNIZATION HISTORY WITH FORECAST

The IZ54r1.0 - Request an Immunization History with Forecast profile is a constrainable profile that supports the request of a complete and evaluated immunization history with forecast for a patient.

The goal of this query is to transfer a patient's consolidated and evaluated immunization history along with an immunization forecast from one information system to another. The history content of the response will be very similar to a VXU message.


A complete immunization history consists of: Demographic information about the patient The history of immunization administered with validation by a clinical decision support engine Forecast of what the patient is due to receive next and the dates when due Potentially, a list of refused immunizations, contraindicated immunizations and/or completed series Potentially, a list of any patient conditions that impact immunizations (e.g. allergies, history of

vaccine preventable disease)

This document does not specify the methodology used by the responding system to search for a person. It specifies the structure and content of the message used to query. It is incumbent on systems to publicly document their expectations and behaviors within the constraints of this guide.

The IZ54r1.0 profile has a set of partner profiles that return the requested history with forecast, a list of candidate patients, an acknowledgement that no matches were found or an acknowledgement that the query failed to execute.

Conformance Profile Definition Segment Flavor Element name Usage CardinalityMSH MSH_IZ Message Header R [1..1]SFT SFT Software Segment O [0..*]UAC UAC User Authentication Credential Segment O [0..1]QPD QPD_IZ Query Parameter Definition R [1..1]RCP RCP_IZ Response Control Parameter R [1..1]DSC DSC Continuation Pointer X



Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Field Separator ST_IZ01 R [1..1]2 Encoding Characters ST_IZ01 R [1..1]3 Sending Application HD_IZ01 RE [0..1] 0361_014 Sending Facility HD_IZ01 RE [0..1] 0362_015 Receiving Application HD_IZ01 RE [0..1] 0361_016 Receiving Facility HD_IZ01 RE [0..1] 0362_017 Date/Time of Message DTM_IZ01 R [1..1]8 Security ST O [0..1]9 Message Type MSG_IZ01 R [1..1]10 Message Control ID ST_IZ01 R [1..1]11 Processing ID PT_IZ01 R [1..1]12 Version ID VID_IZ01 R [1..1]


Seq Element name Data type Usage Cardinality Value Set13 Sequence Number NM O [0..1]14 Continuation Pointer ST O [0..1]15 Accept Acknowledgment Type ID_IZ01 R [1..1] 0155









Conformance StatementsID DescriptionIZ-12 MSH-1 (Field Separator) SHALL contain the value “|”.IZ-13 MSH-2 (Encoding Characters) SHALL contain the value “^~\&”.IZ-81 MSH-9.1 (Message Code) SHALL contain the value "QBP" drawn from the code system "HL70076".IZ-82 MSH-9.2 (Trigger Event) SHALL contain the value "Q11" drawn from the code system "HL70003".

IZ-83 MSH-9.3 (Message Structure) SHALL contain the value "QBP_Q11" drawn from the code system "HL70354".








This field identifies the organization responsible for the operations of the sending application. Locally defined


codes accommodate local needs. The first component shall be the name space ID found in User-defined Table 0362. The second and third components are reserved for use of OIDs.














Currently, MSH provides fields to transmit both sending/receiving applications and facilities (MSH-3 through


MSH-6). However, these levels of organization do not necessarily relate to or imply a legal entity such as a business organization. As such, multiple legal entities (organizations) may share a service bureau, with the same application and facility identifiers. Another level of detail is required to delineate the various organizations using the same service bureau.





3.1.4.1.2 QPD_IZ - QUERY PARAMETER DEFINITION

When part of an RSP^K11 message, the content of the QPD segment should match the content in the QBP^Q11 message which initiated the exchange. Any relevant patient demographic data content from the responding system is contained within the PID segment, not the QPD segment.

Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Message Query Name CWE_IZ01 R [1..1]2 Query Tag ST_IZ01 R [1..1]3 Patient List CX_IZ01 RE [0..*]4 Patient Name XPN_IZ01 R [1..*]5 Mother's Maiden Name XPN_IZ02 RE [0..1]6 Date/Time of Birth DTM_IZ02 R [1..1]7 Administrative Sex CWE_IZ01 RE [0..1] 0001_018 Patient Address XAD_IZ01 RE [0..*]9 Phone Number - Home XTN_IZ01 RE [0..*]10 Multiple Birth Indicator ID_IZ01 RE [0..1] 0136_0111 Birth Order NM_IZ01 RE [0..1]12 Last Update Date/Time DTM O [0..1]13 Last Update Facility HD O [0..1]

Conformance StatementsID DescriptionIZ-208 QPD-1.1 (Identifier) SHALL contain the value "IZ54".IZ-209 QPD-1.3 (Name of Coding System) SHALL contain the value "CDCPHINVS".

QPD-3: Patient List (CX_IZ01)


Equivalent to PID-3 (Patient Identifier List).

The combination of values for QPD-3.1 (Patient ID), QPD-3.4 (Assigning Authority) and QPD-3.5 (Identifier Type Code) are intended to allow unique identification of a patient, if the data are found in the responding system.

QPD-4: Patient Name (XPN_IZ01)

Equivalent to PID-5 (Patient Name)

QPD-5: Mother's Maiden Name (XPN_IZ02)

Equivalent to PID-6 (Mother's Maiden Name)

QPD-6: Date/Time of Birth (DTM_IZ02)

Equivalent to PID-7 (Date/Time of Birth)

Date of Birth is generally considered to be independent of the time zone. If a time is available, the sending and receiving systems should not convert the patient's accepted date of birth to a local equivalent.

QPD-7: Administrative Sex (CWE_IZ01)

Equivalent to PID-8 (Administrative Sex)

QPD-8: Patient Address (XAD_IZ01)

Equivalent to PID-11 (Patient Address)

QPD-9: Phone Number - Home (XTN_IZ01)

Equivalent to PID-13 (Phone Number - Home)

QPD-10: Multiple Birth Indicator (ID_IZ01)

Equivalent to PID-24 (Multiple Birth Indicator)

QPD-11: Birth Order (NM_IZ01)

Equivalent to PID-25 (Birth Order)

QPD-12: Last Update Date/Time (DTM)

This optional field is equivalent to PID-33 (Last Update Date/Time)

QPD-13: Last Update Facility (HD)


This optional field is equivalent to PID-34 (Last Update Facility)

3.1.4.1.3 RCP_IZ - RESPONSE CONTROL PARAMETER

The RCP segment is used to restrict the number of patient records that should be returned in response to a query.

Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Query Priority ID_IZ01 R [1..1] 00912 Quantity Limited Request CQ_IZ01 R [1..1]3 Response Modality CNE O [0..1]4 Execution and Delivery Time - X5 Modify Indicator ID O [0..1]6 Sort-by Field SRT O [0..1]7 Segment group inclusion ID O [0..1]

Conformance StatementsID DescriptionRCP_IZ-1 RCP-1 (Query Priority) SHALL contain the value "I" drawn from the code system "HL70091".IZ-184 RCP-2.2.1 (Identifier) SHALL contain the value "RD" drawn from the code system "HL70126".

RCP-2: Quantity Limited Request (CQ_IZ01)

This field contains the maximum number of patient records that should be returned in the response message. There is no maximum number of immunization records for the patient in the response message.

When multiple patients are to be returned in the response message, all patients must be included in a single response message. The use of the continuation (DSC) segment to split the response across multiple messages is not permitted by this document. The maximum number of patients allowed is the lower of the maximum number requested and the maximum number that the responding system will return.

3.1.5 RSP^K11^RSP_K11 - IZ52R1.0 - RESPOND WITH AN IMMUNIZATION HISTORY WITH FORECAST

The IZ52r1.0 - Respond with an Immunization History with Forecast profile is a constrainable profile that supports the return of a complete and evaluated immunization history of an individual with a forecast for the patient.

The goal of this query is to transfer a patient's consolidated and evaluated immunization history along with an immunization forecast from one information system to another. The content of the response will be very similar to a VXU message.

A complete immunization history consists of: Demographic information about the patient, The history of immunization administered with validation by a clinical decision support engine Forecast of what the patient is due to receive next and the dates when due


Potentially, a list of refused immunizations, contraindicated immunizations and/or completed series Potentially, a list of any patient conditions that impact immunizations (i.e. allergies, contraindications,

history of vaccine preventable disease)

The IZ52 profile is a possible response to the IZ54 - Request an Immunization History with Forecast query.

A conformant IZ52r1.0 message may include multiple Order Segment Groups. The message will contain zero or more Immunization Event with Evaluation Order Segment Groups containing data about specific doses administered to the patient. These Order Segment Groups may contain observations about the event as documented by the originator of the record as well as additional evaluation data. The message will also contain one Order Segment group containing patient forecast information. This Forecast Order Segment Group may contain multiple "sets" of related OBX segments with each set detailing a recommendation for a single future administration or series, these sets of OBX segments are linked via an identical sub-ID in OBX-4 (each forecasted administration must have a unique sub-ID). Finally, if the system generating the IZ52r1.0 message is capable of capturing refused vaccines, the message may contain zero or more Immunization Event (Refused) Order Segment Groups containing data. If the system generating the IZ52r1.0 message is capable of capturing contraindicated vaccines, the message may contain zero or more Immunization Event (Contraindicated) Order Segment Groups. Alternatively, the contraindication may also be returned as a patient level observation. Except where noted below, this document makes no recommendations regarding the order of OBXs within a given Order Segment Group, but keep in mind that related OBX segments, such as those related to a vaccine group evaluation or forecast, must be linked via the sub-ID in OBX-4.

Within an Immunization Event (Evaluated) Order Segment Group, RXA-5 shall indicate the vaccine administered and RXA-20 shall be PA or CP indicating an administered dose. The following OBX segment types are relevant:

Information about the immunization event:o Patient eligibility status - LOINC code 64994-7o Vaccine funding source - LOINC code 30963-3o Vaccine Information Statements (VIS) - LOINC codes 69764-9 and 29769-7 or LOINC codes

30956-7, 29768-9 and 29769-7o Adverse reactions where the reaction can be directly attributable to a specific immunization

event - LOINC code 31044-1o Indication (why the dose was administered) - LOINC code 59785-6o Indication effective date - LOINC code 88877-6o Indication expiration date - LOINC code 88879-2o Free text comment - LOINC code 48767-8

Information about the evaluation of the immunization event (note that for combination vaccines, multiple related sets of evaluation OBX segments may be present, one for each target disease):o Vaccine type (required and must be the first OBX segment among the related group of OBX

segments for an evaluation) - LOINC code 30956-7o Dose validity (required and must be the second OBX segment among the related group of

OBX segments for an evaluation) - LOINC code 59781-5o Reason for validity - LOINC code 30982-3o Series Name - LOINC code 59780-7o Total number of doses in the series - LOINC code 59782-3o Dose number of the evaluated event - LOINC code 30973-2o Schedule used - LOINC code 59779-9

Within a Forecast Order Segment Group, RXA-5.1 shall be the CVX code 998 and RXA-20 shall be NA. The


following OBX segment types are relevant per forecasted series/dose (keep in mind that the single Forecast Order Segment Group may contain multiple related sets of OBX segments when forecasting multiple doses or series):

Vaccine type (required and must be the first OBX segment among the related group of OBX segments for a forecast) - LOINC code 30956-7

Earliest date (required for future doses) - LOINC code 30981-5 Recommended due date (required for future doses) - LOINC code 30980-7 Overdue date - LOINC code 59778-1 Latest date - LOINC code 59777-3 Reason for recommendation - LOINC code 30982-3 Series Name - LOINC code 59780-7 Total number of doses in the series - LOINC code 59782-3 Dose number of the evaluated event - LOINC code 30973-2 Status in the immunization series (including completed and contraindicated series) - LOINC code

59783-1 Schedule used - LOINC code 59779-9

Within an Immunization Event (Refused) Order Segment Group, RXA-5 shall indicate the vaccine refused, RXA-20 shall be RE and RXA-18 shall contain a coded refusal reason. The following OBX segment type is relevant:

Free text comment - LOINC code 48767-8

Within an Immunization Event (Contraindicated) Order Segment Group, RXA-5 shall indicate the contraindicated vaccine and RXA-20 shall be NA, indicating that a dose was not administered. The following OBX segment types are relevant:

Contraindication (why a dose was not administered) - LOINC code 30945-0 Contraindication effective date - LOINC code 30946-8 Contraindication expiration date - LOINC code 30944-3 Free text comment - LOINC code 48767-8

The message may also contain one or more Person Observation Segment Groups, each containing a patient level observation. Patient level observations should not be included as part of an Order Segment Group. Within a Person Observation Segment Group, the following OBX segment types are relevant:


Serological evidence of immunity - LOINC code 75505-8 Presumed evidence of immunity - LOINC code 59784-9 Condition - LOINC code 75323-6 Date of condition onset - LOINC code 85585-8 Condition abatement date - LOINC code 88878-4

See the co-constraints table associated with the OBX segment definitions more details on how to message these concepts.

Conformance Profile Definition Segment Flavor Element name Usage CardinalityMSH MSH_IZ Message Header R [1..1]SFT SFT Software Segment O [0..*]UAC UAC User Authentication Credential Segment O [0..1]


Segment Flavor Element name Usage CardinalityMSA MSA_IZ Message Acknowledgment R [1..1]ERR ERR_IZ Error RE [0..1]QAK QAK_IZ Query Acknowledgment R [1..1]QPD QPD_IZ Query Parameter Definition R [1..1]PID PID_IZ Patient Identification R [1..1]PD1 PD1_IZ_02 Patient Additional Demographic RE [0..1]NK1 NK1_IZ Next of Kin / Associated Parties RE [0..*]PV1 PV1 Patient Visit O [0..1]IN1 IN1_IZ Insurance O [0..1][ BEGIN PERSON_OBSERVATION GROUP RE [0..*]OBX OBX_IZ_01 Observation/Result R [1..1]PRT PRT Participation Information O [0..*]NTE NTE Notes and Comments O [0..*]] END PERSON_OBSERVATION GROUP[ BEGIN COMPLETE_HISTORY GROUP R [1..*]ORC ORC_IZ_02 Common Order R [1..1]RXA RXA_IZ_02 Pharmacy/Treatment Administration R [1..1]RXR RXR_IZ Pharmacy/Treatment Route RE [0..1][ BEGIN Observation GROUP RE [0..*]OBX OBX_IZ_03 Observation/Result R [1..1]NTE NTE Notes and Comments O [0..1]] END Observation GROUP] END COMPLETE_HISTORY GROUPDSC DSC Continuation Pointer X






Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Field Separator ST_IZ01 R [1..1]2 Encoding Characters ST_IZ01 R [1..1]3 Sending Application HD_IZ01 RE [0..1] 0361_014 Sending Facility HD_IZ01 RE [0..1] 0362_01


Seq Element name Data type Usage Cardinality Value Set5 Receiving Application HD_IZ01 RE [0..1] 0361_016 Receiving Facility HD_IZ01 RE [0..1] 0362_017 Date/Time of Message DTM_IZ01 R [1..1]8 Security ST O [0..1]9 Message Type MSG_IZ01 R [1..1]10 Message Control ID ST_IZ01 R [1..1]11 Processing ID PT_IZ01 R [1..1]12 Version ID VID_IZ01 R [1..1]13 Sequence Number NM O [0..1]14 Continuation Pointer ST O [0..1]

15 Accept Acknowledgment Type ID_IZ01 R [1..1] 0155









Conformance StatementsID DescriptionIZ-12 MSH-1 (Field Separator) SHALL contain the value “|”.IZ-13 MSH-2 (Encoding Characters) SHALL contain the value “^~\&”.IZ-95 MSH-9.1 (Message Code) SHALL contain the value "RSP" drawn from the code system "HL70076".IZ-96 MSH-9.2 (Trigger Event) SHALL contain the value "K11" drawn from the code system "HL70003".

IZ-97 MSH-9.3 (Message Trigger) SHALL contain the value "RSP_K11" drawn from the code system "HL70354".




IZ-144 In exactly one occurrence of MSH-21 (Message Profile Identifier), MSH-21.1 (Entity Identifier) SHALL


ID Descriptioncontain the value "IZ52r1.0" AND MSH-21.2 (Namespace ID) SHALL contain the value "CDCPHINVS".

























Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Acknowledgment Code ID_IZ01 R [1..1] 0008_012 Message Control ID ST_IZ01 R [1..1]3 Text Message - X4 Expected Sequence Number NM O [0..*]5 Delayed Acknowledgment Type - X6 Error Condition - X7 Message Waiting Number NM O [0..*]8 Message Waiting Priority ID O [0..*]






Conformance Statements ID DescriptionIZ-210 ERR-4 (Severity) SHALL NOT contain the value "E".





3.1.5.1.4 QAK_IZ - QUERY ACKNOWLEDGMENT

Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Query Tag ST_IZ01 R [1..1]2 Query Response Status ID_IZ01 R [1..1] 0208_013 Message Query Name CWE_IZ01 R [1..1]4 Hit Count Total NM O [0..*]5 This payload NM O [0..*]6 Hits remaining NM O [0..*]



ID DescriptionIZ-212 QAK-2 (Query Response Status) SHALL contain the value "OK".IZ-214 QAK-3.1 (Identifier) SHALL contain the value "IZ54".IZ-215 QAK-3.3 (Name of Coding System) SHALL contain the value "CDCPHINVS".

QAK-1: Query Tag (ST_IZ01)

This field contains the value sent in QPD-2 (Query Tag) by the initiating system and will be used by the initiating system to match response messages to the originating query. The responding system is required to echo it back as the first field in the query acknowledgement segment (QAK).

QAK-2: Query Response Status (ID_IZ01)

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.

QAK-3: Message Query Name (CWE_IZ01)

This field contains the name of the query. This shall mirror the QPD-1 (Message Query Name) found in the query message that is being responded to.






ID DescriptionIZ-208 QPD-1.1 (Identifier) SHALL contain the value "IZ54".IZ-209 QPD-1.3 (Name of Coding System) SHALL contain the value "CDCPHINVS".

When the QPD segment is part of a query response message (RSP), the content of the segment shall mirror the data sent as part of the query message (QBP).


Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Set ID - PID SI_IZ01 R [1..1]2 Patient ID - X3 Patient Identifier List CX_IZ01 R [1..*]4 Alternate Patient ID - PID - X5 Patient Name XPN_IZ01 R [1..*]6 Mother's Maiden Name XPN_IZ02 RE [0..1]7 Date/Time of Birth DTM_IZ02 R [1..1]8 Administrative Sex CWE_IZ01 R [1..1] 0001_019 Patient Alias - X10 Race CWE_IZ01 RE [0..*] CDCREC_0111 Patient Address XAD_IZ01 RE [0..*]12 County Code - X13 Phone Number - Home XTN_IZ01 RE [0..*]14 Phone Number - Business XTN O [0..*]15 Primary Language CWE O [0..1]16 Marital Status CWE O [0..1]17 Religion CWE O [0..1]18 Patient Account Number CX O [0..1]19 SSN Number - Patient - X20 Driver's License Number - Patient - X21 Mother's Identifier CX O [0..*]22 Ethnic Group CWE_IZ01 RE [0..1] CDCREC_0223 Birth Place ST O [0..1]24 Multiple Birth Indicator ID_IZ01 RE [0..1] 0136_0125 Birth Order NM_IZ01 C(RE/O) [0..1]26 Citizenship CWE O [0..1]27 Veterans Military Status CWE O [0..1]28 Nationality - X29 Patient Death Date and Time DTM_IZ02 C(RE/X) [0..1]30 Patient Death Indicator ID_IZ01 RE [0..1] 0136_01


Seq Element name Data type Usage Cardinality Value Set31 Identity Unknown Indicator ID O [0..1]32 Identity Reliability Code CWE O [0..1]33 Last Update Date/Time DTM O [0..1]34 Last Update Facility HD O [0..1]35 Taxonomic Classification Code CWE O [0..1]36 Breed Code - X37 Strain ST O [0..1]38 Production Class Code CWE O [0..1]39 Tribal Citizenship CWE O [0..1]40 Patient Telecommunication Information XTN O [0..1]

Conformance Statements ID DescriptionIZ-46 PID-1 (Set ID - PID) SHALL contain the value "1".





























Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Living Dependency CWE O [0..1]2 Living Arrangement CWE O [0..1]3 Patient Primary Facility XON O [0..1]



4 Patient Primary Care Provider Name & ID No. - X

5 Student Indicator CWE O [0..1]6 Handicap CWE O [0..1]7 Living Will Code CWE O [0..1]8 Organ Donor Code CWE O [0..1]9 Separate Bill ID O [0..1]10 Duplicate Patient CX O [0..1]11 Publicity Code CWE_IZ01 RE [0..1] 0215_0112 Protection Indicator ID O [0..1]13 Protection Indicator Effective Date DT O [0..1]14 Place of Worship XON O [0..1]15 Advance Directive Code CWE O [0..1]16 Immunization Registry Status CWE_IZ01 RE [0..1] 0441_0117 Immunization Registry Status Effective Date DT_IZ01 C(RE/X) [0..1]18 Publicity Code Effective Date DT_IZ01 C(RE/X) [0..1]19 Military Branch CWE O [0..1]20 Military Rank/Grade CWE O [0..1]21 Military Status CWE O [0..1]22 Advance Directive Last Verified Date DT O [0..1]

Conditional PredicatesLocation Usage DescriptionPD1-17 C(RE/X) If PD1-16 (Immunization Registry Status) is valued.PD1-18 C(RE/X) If PD1-11 (Publicity Code) is valued.






This field identifies the current status of the patient in relation to the sending organization. The term "sending organization" refers to the organization that is accountable for the content of the message. This may be an EHR


for a VXU^V04 message or an IIS for an RSP^K11 message. PD1-16 should reflect the status of the patient relative to the system creating the message.





Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Set ID - NK1 SI_IZ01 R [1..1]2 Name XPN_IZ01 R [1..*]3 Relationship CWE_IZ01 R [1..1] 0063_014 Address XAD_IZ01 RE [0..*]5 Phone Number XTN_IZ01 RE [0..*]6 Business Phone Number XTN O [0..1]7 Contact Role CWE O [0..1]8 Start Date DT O [0..1]9 End Date DT O [0..1]10 Next of Kin / Associated Parties Job Title ST O [0..1]

11 Next of Kin / Associated Parties Job Code/Class JCC O [0..1]


13 Organization Name - NK1 XON O [0..1]14 Marital Status CWE O [0..1]15 Administrative Sex CWE O [0..1]16 Date/Time of Birth DTM O [0..1]17 Living Dependency CWE O [0..1]18 Ambulatory Status CWE O [0..1]19 Citizenship CWE O [0..1]20 Primary Language CWE O [0..1]21 Living Arrangement CWE O [0..1]22 Publicity Code CWE O [0..1]


Seq Element name Data type Usage Cardinality Value Set23 Protection Indicator ID O [0..1]24 Student Indicator CWE O [0..1]25 Religion CWE O [0..1]26 Mother's Maiden Name XPN O [0..1]27 Nationality CWE O [0..1]28 Ethnic Group CWE O [0..1]29 Contact Reason CWE O [0..1]30 Contact Person's Name XPN O [0..1]31 Contact Person's Telephone Number XTN O [0..1]32 Contact Person's Address XAD O [0..1]33 Next of Kin/Associated Party's Identifiers CX O [0..1]34 Job Status CWE O [0..1]35 Race CWE O [0..1]36 Handicap CWE O [0..1]37 Contact Person Social Security Number ST O [0..1]38 Next of Kin Birth Place ST O [0..1]39 VIP Indicator CWE O [0..1]40 Next of Kin Telecommunication Information XTN O [0..1]






Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Set ID - IN1 SI_IZ01 R [1..1]2 Health Plan ID CWE_IZ01 R [1..1] 0072_013 Insurance Company ID CX_IZ01 R [1..1]4 Insurance Company Name XON O [0..1]


Seq Element name Data type Usage Cardinality Value Set5 Insurance Company Address XAD O [0..1]6 Insurance Co Contact Person XPN O [0..1]7 Insurance Co Phone Number XTN O [0..1]8 Group Number ST O [0..1]9 Group Name XON O [0..1]10 Insured's Group Emp ID CX O [0..1]11 Insured's Group Emp Name XON O [0..1]12 Plan Effective Date DT O [0..1]13 Plan Expiration Date DT O [0..1]14 Authorization Information AUI O [0..1]15 Plan Type CWE_IZ01 R [1..1] 0086_0116 Name Of Insured XPN O [0..1]17 Insured's Relationship To Patient CWE O [0..1]18 Insured's Date Of Birth DTM O [0..1]19 Insured's Address XAD O [0..1]20 Assignment Of Benefits CWE O [0..1]21 Coordination Of Benefits CWE O [0..1]22 Coord Of Ben. Priority ST O [0..1]23 Notice Of Admission Flag ID O [0..1]24 Notice Of Admission Date DT O [0..1]25 Report Of Eligibility Flag ID O [0..1]26 Report Of Eligibility Date DT O [0..1]27 Release Information Code CWE O [0..1]28 Pre-Admit Cert (PAC) ST O [0..1]29 Verification Date/Time DTM_IZ02 RE [0..1]30 Verification By XCN O [0..1]31 Type Of Agreement Code CWE O [0..1]32 Billing Status CWE O [0..1]33 Lifetime Reserve Days NM O [0..1]34 Delay Before L.R. Day NM O [0..1]35 Company Plan Code CWE O [0..1]36 Policy Number ST O [0..1]37 Policy Deductible CP O [0..1]38 Policy Limit - Amount - X39 Policy Limit - Days NM O [0..1]40 Room Rate - Semi-Private - X41 Room Rate - Private - X


Seq Element name Data type Usage Cardinality Value Set42 Insured's Employment Status CWE O [0..1]43 Insured's Administrative Sex CWE O [0..1]44 Insured's Employer's Address XAD O [0..1]45 Verification Status ST O [0..1]46 Prior Insurance Plan ID CWE O [0..1]47 Coverage Type CWE O [0..1]48 Handicap CWE O [0..1]49 Insured's ID Number CX O [0..1]50 Signature Code CWE O [0..1]51 Signature Code Date DT O [0..1]52 Insured's Birth Place ST O [0..1]53 VIP Indicator CWE O [0..1]54 External Health Plan Identifiers CX O [0..1]55 Insurance Action Code ID O [0..1]

Conformance StatementsID DescriptionIZ-69 IN1-1 (Set ID - IN1) SHALL contain the value "1".




Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Set ID - OBX SI_IZ01 R [1..1]2 Value Type ID_IZ01 R [1..1] 0125_013 Observation Identifier CWE_IZ01 R [1..1] NIP003_014 Observation Sub-ID OG_IZ01 R [1..1]5 Observation Value VARIES R [1..1]6 Units CWE_IZ01 C(R/O) [0..1]


Seq Element name Data type Usage Cardinality Value Set7 References Range ST O [0..1]8 Interpretation Codes CWE O [0..1]9 Probability NM O [0..1]10 Nature of Abnormal Test ID O [0..1]11 Observation Result Status ID_IZ01 R [1..1] 008512 Effective Date of Reference Range DTM O [0..1]13 User Defined Access Checks ST O [0..1]14 Date/Time of the Observation DTM_IZ02 RE [0..1]15 Producer's ID CWE O [0..1]16 Responsible Observer XCN O [0..1]17 Observation Method CWE O [0..1]18 Equipment Instance Identifier EI O [0..1]19 Date/Time of the Analysis DTM O [0..1]20 Observation Site - X21 Observation Instance Identifier - X22 Mood Code - X23 Performing Organization Name XON O [0..1]24 Performing Organization Address XAD O [0..1]25 Performing Organization Medical Director XCN O [0..1]26 Patient Results Release Category ID O [0..1]27 Root Cause CWE O [0..1]28 Local Process Control CWE O [0..1]29 Observation Type ID O [0..1]30 Observation Sub-Type ID O [0..1]




Co-Constraints IF (OBX-3) Column Value59784-9 THEN


IF (OBX-3) Column ValueOBX-2(Value) CWEOBX-2(Flavor) CWE_IZ01OBX-5(Value Set) PHVS_HistoryOfDisease_IISDescription Disease with presumed immunity

75505-8


31044-1


75323-6


85585-8

THENOBX-2(Value) DTOBX-2(Flavor) DT_IZ01Description Date of condition onset

88878-4










This field is used to group related observations by setting the value to the same number. For example, when recording patient conditions multiple groups of OBX segments may be needed. One OBX would indicate the patient condition. It may have an associated OBX indicating the the onset date of the condition. These 2 segments would have the same OBX-4 value to allow them to be linked. The second set of related OBX segments for the next condition would have another OBX-4 value common to each of them.






3.1.5.1.11 ORC_IZ_02 - COMMON ORDER

The Common Order segment (ORC) is used to transmit fields that are common to all orders (all types of services that are requested). While not all immunizations transmitted in an immunization message are able to be associated with an order, each RXA must be associated with one ORC, per the HL7 base standard.

Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Order Control ID_IZ01 R [1..1] 01192 Placer Order Number EI_IZ01 RE [0..1]3 Filler Order Number EI_IZ01 R [1..1]4 Placer Group Number EIP O [0..1]5 Order Status ID O [0..1]6 Response Flag ID O [0..1]7 Quantity/Timing - X8 Parent Order EIP O [0..1]9 Date/Time of Transaction DTM O [0..1]10 Entered By XCN_IZ01 RE [0..1]11 Verified By XCN O [0..1]12 Ordering Provider XCN_IZ01 C(RE/O) [0..1]13 Enterer's Location PL O [0..1]14 Call Back Phone Number XTN O [0..1]15 Order Effective Date/Time DTM O [0..1]



16 Order Control Code Reason CWE O [0..1]

17 Entering Organization CWE_IZ01 RE [0..1] 0362_0118 Entering Device CWE O [0..1]19 Action By XCN O [0..1]

20 Advanced Beneficiary Notice Code CWE O [0..1]

21 Ordering Facility Name XON O [0..1]22 Ordering Facility Address XAD O [0..1]

23 Ordering Facility Phone Number XTN O [0..1]

24 Ordering Provider Address XAD O [0..1]25 Order Status Modifier CWE O [0..1]

26 Advanced Beneficiary Notice Override Reason CWE O [0..1]

27 Filler's Expected Availability Date/Time DTM O [0..1]

28 Confidentiality Code CWE O [0..1]29 Order Type CWE O [0..1]30 Enterer Authorization Mode CNE O [0..1]

31 Parent Universal Service Identifier CWE O [0..1]

32 Advanced Beneficiary Notice Date DT O [0..1]

33 Alternate Placer Order Number CX O [0..1]

34 Order Workflow Profile CWE O [0..1]

Conformance StatementsID DescriptionORC_IZ_02-1 ORC-1 (Order Control) SHALL contain the value "RE" drawn from the code system "HL70119".

Conditional PredicatesLocation Usage Description

ORC-12 C(RE/O) If RXA-9.1 (Identifier) contains the value "00" AND RXA-20 (Completion Status) is one of the values in the list (CP, PA).

ORC-2: Placer Order Number (EI_IZ01)

The placer order number is used to uniquely identify this administration among all administrations sent by a provider organization. In the case where the ordering provider organization is not known, this field may be left empty.


ORC-3: Filler Order Number (EI_IZ01)

When an immunization history is returned, the Filler ID should be the IIS identifier associated with the administered dose. The IIS may be aware of other IDs used by VXU submitting organizations, but the RSP should contain the IIS identifier. Having a stable identifier for a given dose that is used across RSP messages is important for systems receiving the RSP so that they can reconcile doses across query responses.

ORC-10: Entered By (XCN_IZ01)

This identifies the individual that entered this particular order.

ORC-17: Entering Organization (CWE_IZ01)

The person who entered the request is defined in ORC-10 (entered by).

3.1.5.1.12RXA_IZ_02 - PHARMACY/TREATMENT ADMINISTRATION

The RXA segment carries pharmacy administration data. It is paired with the ORC segment within the Order Segment Group. Each RXA must be preceded by an ORC.

Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Give Sub-ID Counter NM_IZ01 R [1..1]2 Administration Sub-ID Counter NM_IZ01 R [1..1]3 Date/Time Start of Administration DTM_IZ02 R [1..1]4 Date/Time End of Administration DTM_IZ02 R [1..1]5 Administered Code CWE_IZ01 R [1..1] CVX_016 Administered Amount NM_IZ01 R [1..1]7 Administered Units CWE_IZ01 C(R/X) [0..1] UCUM_018 Administered Dosage Form CWE O [0..1]9 Administration Notes CWE_IZ01 C(R/O) [0..1] NIP001_0110 Administering Provider XCN_IZ01 C(RE/O) [0..1]11 Administered-at Location - X12 Administered Per (Time Unit) ST O [0..1]13 Administered Strength NM O [0..1]14 Administered Strength Units CWE O [0..1]15 Substance Lot Number ST_IZ01 C(R/O) [0..*]16 Substance Expiration Date DTM_IZ03 C(RE/O) [0..1]17 Substance Manufacturer Name CWE_IZ01 C(R/O) [0..1] MVX_01

18 Substance/Treatment Refusal Reason CWE_IZ01 C(R/X) [0..*] NIP002_01

19 Indication CWE O [0..1]20 Completion Status ID_IZ01 RE [0..1] 0322_01


Seq Element name Data type Usage Cardinality Value Set21 Action Code - RXA ID O [0..1]22 System Entry Date/Time DTM O [0..1]23 Administered Drug Strength Volume NM O [0..1]

24 Administered Drug Strength Volume Units CWE O [0..1]

25 Administered Barcode Identifier CWE O [0..1]26 Pharmacy Order Type ID O [0..1]27 Administer-at PL_IZ01 C(RE/O) [0..1]28 Administered-at Address XAD O [0..1]29 Administered Tag Identifier EI O [0..1]

Conformance StatementsID DescriptionRXA_IZ_02-1 RXA-1 (Give Sub-ID Counter) SHALL contain the value "0".RXA_IZ_02-2 RXA-2 (Administration Sub-ID Counter) SHALL contain the value "1".

IZ-30 RXA-4 (Date/Time End of Administration) SHALL be identical to the value of RXA-3 (Date/Time Start of Administration).

IZ-49 IF RXA-5.1 (Identifier) contains the value "998" THEN RXA-6 (Administered Amount) SHALL contain the value "999".

IZ-207 IF RXA-20 (Completion Status) contains the value "RE" THEN RXA-5.1 (Identifier) SHALL NOT contain the value "998".

IZ-48 IF RXA-20 (Completion Status) contains the value "RE" THEN RXA-6 (Administered Amount) SHALL contain the value "999".

IZ-32 IF RXA-18 (Substance/Treatment Refusal Reason) is valued THEN RXA-20 (Completion Status) SHALL contain the value "RE".

Conditional PredicatesLocation Usage DescriptionRXA-7 C(R/X) If RXA-6 (Administered Amount) does not contain the value “999”.RXA-9 C(R/O) If RXA-20 (Completion Status) is one of the values in the list (CP, PA).

RXA-10 C(RE/O) If RXA-9.1 (Identifier) contains the value “00” AND if RXA-20 (Completion Status) is one of the values in the list (CP, PA).

RXA-15 C(R/O) If RXA-9.1 (Identifier) contains the value “00” AND if RXA-20 (Completion Status) is one of the values in the list (CP, PA).


RXA-17 C(R/O) If RXA-9.1 (Identifier) contains the value “00” AND if RXA-20 (Completion Status) is one of the values in the list (CP, PA).

RXA-18 C(R/X) If RXA-20 (Completion Status) contains the value “RE”.


RXA-1: Give Sub-ID Counter (NM_IZ01)


This field is used to match an RXA and RXG, which is not applicable to the processing of immunization data, however the field is required to match the base standard requirements.

Note that in the Conformance Statement, "0" is zero.

RXA-2: Administration Sub-ID Counter (NM_IZ01)

This field is used to track multiple RXA segments under an ORC. Since each ORC has only one RXA in immunization messages, this field is constrained to 1. This should not be used for indicating dose number, which is messaged via the OBX segment.

RXA-3: Date/Time Start of Administration (DTM_IZ02)

The date this vaccination occurred. In the case of a contraindication, refusal or deferral, this is the date the action occurred. In the case of a forecast dose, this is the date the forecast was made.

RXA-4: Date/Time End of Administration (DTM_IZ02)

This field is specified as required in the HL7 standard. An immunization is given at a point in time, and in the context of immunization, the End date/time is equivalent to the Start date/time. For this reason, this document has required this to be equal to RXA-3.

RXA-5: Administered Code (CWE_IZ01)

When returning data in a query response message, the use of CVX codes is preferred. There is no expectation to message the vaccine via an NDC.

RXA-6: Administered Amount (NM_IZ01)

This field records the amount of pharmaceutical administered. The units are expressed in the next field, RXA-7. When the administered amount is unknown, this field should be populated with the value "999".

RXA-9: Administration Notes (CWE_IZ01)

This field is used to indicate whether this immunization record is based on a historical record or is being reported by the administering provider.

RXA-10: Administering Provider (XCN_IZ01)

This is the person who gave the administration. It is not the ordering clinician.

RXA-11: Administered-at Location (-)

RXA-11 has been deprecated in the v2.8 base standard and has been replaced by RXA-27.

RXA-16: Substance Expiration Date (DTM_IZ03)


A vaccine expiration date does not always have a "day" component; therefore, such a date may be transmitted as YYYYMM.

RXA-17: Substance Manufacturer Name (CWE_IZ01)

This field contains the manufacturer of the medical substance administered.

RXA-18: Substance/Treatment Refusal Reason (CWE_IZ01)

This field contains the reason the patient refused the medical substance/treatment. Any entry in the field indicates that the patient did not take the substance.

RXA-27: Administer-at (PL_IZ01)

This field specifies the location where the vaccine was administered. RXA-27 replaces RXA-11 from previous versions of the immunization messaging implementation guide.

3.1.5.1.13RXR_IZ - PHARMACY/TREATMENT ROUTE

Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Route CWE_IZ01 R [1..1] NCIT_012 Administration Site CWE_IZ01 RE [0..1] 0163_013 Administration Device CWE O [0..1]4 Administration Method CWE O [0..1]5 Routing Instruction CWE O [0..1]6 Administration Site Modifier CWE O [0..1]


The observation result segment has many uses. It carries observations about the object of its parent segment. In this case, it is associated with the RXA segment. The basic format is a question (OBX-3) and an answer (OBX-5).


Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Set ID - OBX SI_IZ01 R [1..1]2 Value Type ID_IZ01 R [1..1] 0125_01


Seq Element name Data type Usage Cardinality Value Set3 Observation Identifier CWE_IZ01 R [1..1] NIP003_034 Observation Sub-ID OG_IZ01 R [1..1]5 Observation Value VARIES R [1..1]6 Units CWE_IZ01 C(R/O) [0..1]7 References Range ST O [0..1]8 Interpretation Codes CWE O [0..1]9 Probability NM O [0..1]10 Nature of Abnormal Test ID O [0..1]11 Observation Result Status ID_IZ01 R [1..1] 008512 Effective Date of Reference Range DTM O [0..1]13 User Defined Access Checks ST O [0..1]14 Date/Time of the Observation DTM_IZ02 RE [0..1]15 Producer's ID CWE O [0..1]16 Responsible Observer XCN O [0..1]17 Observation Method CWE O [0..1]18 Equipment Instance Identifier EI O [0..1]19 Date/Time of the Analysis DTM O [0..1]20 Observation Site - X21 Observation Instance Identifier - X22 Mood Code - X23 Performing Organization Name XON O [0..1]24 Performing Organization Address XAD O [0..1]25 Performing Organization Medical Director XCN O [0..1]26 Patient Results Release Category ID O [0..1]27 Root Cause CWE O [0..1]28 Local Process Control CWE O [0..1]29 Observation Type ID O [0..1]30 Observation Sub-Type ID O [0..1]






64994-7

THENOBX-2(Value) CWEOBX-2(Flavor) CWE_IZ01OBX-5(Value Set) 0064_01Description Vaccine funding program eligibility category

30963-3

THENOBX-2(Value) CWEOBX-2(Flavor) CWE_IZ01OBX-5(Value Set) PHVS_ImmunizationFundingSource_IISDescription Vaccine funding source

69764-9

THENOBX-2(Value) CWEOBX-2(Flavor) CWE_IZ01OBX-5(Value Set) PHVS_VISBarcodes_IISDescription Document type

29769-7

THENOBX-2(Value) DTOBX-2(Flavor) DT_IZ01Description Date vaccine information statement presented

29768-9

THENOBX-2(Value) DTOBX-2(Flavor) DT_IZ01Description Date vaccine information statement published

31044-1


59785-6

THENOBX-2(Value) CWEOBX-2(Flavor) CWE_IZ01OBX-5(Value Set) PHVS_VaccinationSpecialIndications_IISDescription Indication for immunization

88877-6

THENOBX-2(Value) DTOBX-2(Flavor) DT_IZ01Description Date of vaccination indication effective

88879-2 THENOBX-2(Value) DTOBX-2(Flavor) DT_IZ01


IF (OBX-3) Column ValueDescription Date of vaccination temporary indication expiration

30945-0

THENOBX-2(Value) CWEOBX-2(Flavor) CWE_IZ01OBX-5(Value Set) PHVS_VaccinationContraindication_IISDescription Vaccination contraindication/precaution

30946-8

THENOBX-2(Value) DTOBX-2(Flavor) DT_IZ01Description Date.vaccination contraindication/precaution effective

30944-3

THENOBX-2(Value) DTOBX-2(Flavor) DT_IZ01Description Date of vaccination temporary contraindication/precaution expiration

48767-8

THENOBX-2(Value) TXOBX-2(Flavor) TX_IZ01Description Annotation comment

30956-7

THENOBX-2(Value) CWEOBX-2(Flavor) CWE_IZ01OBX-5(Value Set) CVX_02, CVX_03Description Type [Identifier] Vaccine

Comment The CVX_02 value set should be used when transmitting VIS information in the RSP message.

59783-1

THENOBX-2(Value) CWEOBX-2(Flavor) CWE_IZ01OBX-5(Value Set) PHVS_SeriesStatus_IISDescription Status in immunization series

59781-5

THENOBX-2(Value) IDOBX-2(Flavor) ID_IZ01OBX-5(Value Set) 0532_01Description Dose validity

30982-3

THENOBX-2(Value) CWEOBX-2(Flavor) CWE_IZ01OBX-5(Value Set) PHVS_EvaluationStatusReason_IIS, PHVS_VaccinationSpecialIndications_IISDescription Reason applied by forecast logic to project this vaccine.

Comment A "reason" may be given for both the dose validity (evaluation) and the forecast. ST is also a valid value type (OBX-2)



59779-9

THENOBX-2(Value) CWEOBX-2(Flavor) CWE_IZ01OBX-5(Value Set) PHVS_ImmunizationScheduleIdentifier_IISDescription Immunization schedule used

59780-7

THENOBX-2(Value) CWEOBX-2(Flavor) CWE_IZ02Description Immunization series name

30973-2

THENOBX-2(Value) STOBX-2(Flavor) ST_IZ01Description Dose number in series

59782-3

THENOBX-2(Value) NMOBX-2(Flavor) NM_IZ01Description Number of doses in primary immunization series

30980-7

THENOBX-2(Value) DTOBX-2(Flavor) DT_IZ01Description Date vaccine due

30981-5

THENOBX-2(Value) DTOBX-2(Flavor) DT_IZ01Description Earliest date to give

59777-3 THENOBX-2(Value) DTOBX-2(Flavor) DT_IZ01Description Latest date to give immunization

59778-1

THENOBX-2(Value) DTOBX-2(Flavor) DT_IZ01Description Date when overdue for immunization


This field contains the sequence number. The first instance shall be set to 1 and each subsequent instance shall be the next number in sequence. Numbering might not be restarted within a message. That is, if a message had 3 segment groups containing OBX segments and each had 3 OBX, the last OBX in the message would have value of 9 for this field. Alternatively, the Set ID is also allowed to restart for each segment group. That is, if a message had 3 order segment groups and each had 3 OBX segments, all three groups would contain OBX segments with Set IDs of 1, 2 and 3. Either approach, restarting or not restarting per set of OBX segments, is allowed.







This field is used to group related observations by setting the value to the same number. For example, when an immunization event is evaluated against multiple antigens because a combination vaccine was administered, the results of the evaluation are messaged using multiple related OBX segments (Vaccine Type, Dose Validity, Reason for Validity, etc). All of the segments for a given antigen would have the same OBX-4 value to allow them to be linked. The second set of related OBX segments for the next antigen would have another OBX-4 value common to each of them. Similarly, if multiple vaccines are recommended in a forecast, the OBX segments related to a single recommended vaccine (Vaccine Type, Earliest Date, Recommended Date, etc) will share a common OBX-4 value while OBX segments for a different vaccine will share a different OBX-4 value.

The observation Sub-ID must be unique for each related set of observations within a given order Segment Group. Sub-IDs may be re-used between order Segment Groups in the message.




This shall be the units for the value in OBX-5.

If there is not a unit of measure available while the Condition Predicated is true, then the value "NA" may be used in OBX-6.1 and "HL70353" in OBX-6.3.

3.1.6 RSP^K11^RSP_K11 - Z31R1.0 - RESPOND WITH A LIST OF CANDIDATES

The Z31r1.0 - Respond with a List of Candidates profile is a constrainable profile that supports the return of a list of candidate patients of interest.

The goal of this response is to return a complete list of candidate patents in response to a request for a patient's record. This will support re-query by the initiator based on the selection of a patient from the list.

The Z31r1.0 profile is a possible response to the IZ54r1.0 - Request an Immunization History with Forecast query.


Conformance Profile Definition Segment Flavor Element name Usage CardinalityMSH MSH_IZ Message Header R [1..1]SFT SFT Software Segment O [0..*]UAC UAC User Authentication Credential Segment O [0..1]MSA MSA_IZ Message Acknowledgment R [1..1]ERR ERR_IZ Error RE [0..1]QAK QAK_IZ Query Acknowledgment R [1..1]QPD QPD_IZ Query Parameter Definition R [1..1][ BEGIN Patient_Identifier_List GROUP R [1..*]PID PID_IZ Patient Identification R [1..1]PD1 PD1 Patient Additional Demographic O [0..1]NK1 NK1 Next of Kin / Associated Parties O [0..*]] END Patient_Identifier_List GROUPDSC DSC Continuation Pointer X






Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Field Separator ST_IZ01 R [1..1]2 Encoding Characters ST_IZ01 R [1..1]3 Sending Application HD_IZ01 RE [0..1] 0361_014 Sending Facility HD_IZ01 RE [0..1] 0362_015 Receiving Application HD_IZ01 RE [0..1] 0361_016 Receiving Facility HD_IZ01 RE [0..1] 0362_017 Date/Time of Message DTM_IZ01 R [1..1]8 Security ST O [0..1]9 Message Type MSG_IZ01 R [1..1]10 Message Control ID ST_IZ01 R [1..1]11 Processing ID PT_IZ01 R [1..1]12 Version ID VID_IZ01 R [1..1]


Seq Element name Data type Usage Cardinality Value Set13 Sequence Number NM O [0..1]14 Continuation Pointer ST O [0..1]15 Accept Acknowledgment Type ID_IZ01 R [1..1] 0155














IZ-107In exactly one occurrence of MSH-21 (Message Profile Identifier), MSH-21.1 (Entity Identifier) SHALL contain the value "Z31r1.0" AND MSH-21.2 (Namespace ID) SHALL contain the value "CDCPHINVS".




This field identifies the organization responsible for the operations of the sending application. Locally defined


codes accommodate local needs. The first component shall be the name space ID found in User-defined Table 0362. The second and third components are reserved for use of OIDs.














Currently, MSH provides fields to transmit both sending/receiving applications and facilities (MSH-3 through


MSH-6). However, these levels of organization do not necessarily relate to or imply a legal entity such as a business organization. As such, multiple legal entities (organizations) may share a service bureau, with the same application and facility identifiers. Another level of detail is required to delineate the various organizations using the same service bureau.










Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Error Code and Location - X2 Error Location ERL_IZ01 RE [0..1]3 HL7 Error Code CWE_IZ01 R [1..1] 0357_014 Severity ID_IZ01 R [1..1] 0516_015 Application Error Code CWE_IZ01 RE [0..1] 0533_01

6 Application Error Parameter ST O [0..10]

7 Diagnostic Information TX O [0..*]


Seq Element name Data type Usage Cardinality Value Set8 User Message TX_IZ01 RE [0..1]9 Inform Person Indicator CWE O [0..*]10 Override Type CWE O [0..*]11 Override Reason Code CWE O [0..*]12 Help Desk Contact Point XTN O [0..*]

Conformance Statements Message:ID DescriptionIZ-210 ERR-4 (Severity) SHALL NOT contain the value "E".







Conformance StatementsID DescriptionIZ-212 QAK-2 (Query Response Status) SHALL contain the value "OK".IZ-214 QAK-3.1 (Identifier) SHALL contain the value "IZ54".IZ-215 QAK-3.3 (Name of Coding System) SHALL contain the value "CDCPHINVS".














Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Set ID - PID SI_IZ01 R [1..1]


Seq Element name Data type Usage Cardinality Value Set2 Patient ID - X3 Patient Identifier List CX_IZ01 R [1..*]4 Alternate Patient ID - PID - X5 Patient Name XPN_IZ01 R [1..*]6 Mother's Maiden Name XPN_IZ02 RE [0..1]7 Date/Time of Birth DTM_IZ02 R [1..1]8 Administrative Sex CWE_IZ01 R [1..1] 0001_019 Patient Alias - X10 Race CWE_IZ01 RE [0..*] CDCREC_0111 Patient Address XAD_IZ01 RE [0..*]12 County Code - X13 Phone Number - Home XTN_IZ01 RE [0..*]14 Phone Number - Business XTN O [0..*]15 Primary Language CWE O [0..1]16 Marital Status CWE O [0..1]17 Religion CWE O [0..1]18 Patient Account Number CX O [0..1]19 SSN Number - Patient - X20 Driver's License Number - Patient - X21 Mother's Identifier CX O [0..*]22 Ethnic Group CWE_IZ01 RE [0..1] CDCREC_0223 Birth Place ST O [0..1]24 Multiple Birth Indicator ID_IZ01 RE [0..1] 0136_0125 Birth Order NM_IZ01 C(RE/O) [0..1]26 Citizenship CWE O [0..1]27 Veterans Military Status CWE O [0..1]28 Nationality - X29 Patient Death Date and Time DTM_IZ02 C(RE/X) [0..1]30 Patient Death Indicator ID_IZ01 RE [0..1] 0136_0131 Identity Unknown Indicator ID O [0..1]32 Identity Reliability Code CWE O [0..1]33 Last Update Date/Time DTM O [0..1]34 Last Update Facility HD O [0..1]35 Taxonomic Classification Code CWE O [0..1]36 Breed Code - X37 Strain ST O [0..1]38 Production Class Code CWE O [0..1]39 Tribal Citizenship CWE O [0..1]


Seq Element name Data type Usage Cardinality Value Set40 Patient Telecommunication Information XTN O [0..1]

Conformance StatementsID DescriptionIZ-72 PID-1 (Patient Identifier List) SHALL be valued sequentially starting with the value “1”.



























3.1.7 RSP^K11^RSP_K11 - IZ33R1.0 - RESPOND WITH A NO PERSON FOUND MESSAGE

The IZ33r1.0 - Respond with a No Person Found Message profile is a constrainable profile that supports return of an acknowledgement indicating no patients were found.

The goal of this response is to indicate that either the message could be parsed, but there was an error processing the message, that no candidates were found or that more than the allowed number of patients to be returned were found. No demographic or immunization history will be returned.

The IZ33r1.0 profile is a possible response to the IZ54r1.0 - Request an Immunization History with Forecast query.

Conformance Profile Definition Segment Flavor Element name Usage CardinalityMSH MSH_IZ Message Header R [1..1]SFT SFT Software Segment O [0..*]

UAC UAC User Authentication Credential Segment O [0..1]

MSA MSA_IZ Message Acknowledgment R [1..1]ERR ERR_IZ Error RE [0..1]QAK QAK_IZ Query Acknowledgment R [1..1]QPD QPD_IZ Query Parameter Definition R [1..1]


Segment Flavor Element name Usage CardinalityDSC DSC Continuation Pointer X













23 Receiving Responsible XON_IZ01 RE [0..1]


Seq Element name Data type Usage Cardinality Value SetOrganization






























This field has the same justification as the Sending Responsible Organization except in the role of the


Receiving Responsible Organization. The receiving organization has the responsibility to act on the information in the message.














Conformance StatementsID DescriptionIZ-214 QAK-3.1 (Identifier) SHALL contain the value "IZ54".IZ-215 QAK-3.3 (Name of Coding System) SHALL contain the value "CDCPHINVS".









Segment DefinitionSeq Element name Data type Usage Cardinality Value Set1 Message Query Name CWE_IZ01 R [1..1]2 Query Tag ST_IZ01 R [1..1]3 Patient List CX_IZ01 RE [0..*]


Seq Element name Data type Usage Cardinality Value Set4 Patient Name XPN_IZ01 R [1..*]5 Mother's Maiden Name XPN_IZ02 RE [0..1]6 Date/Time of Birth DTM_IZ02 R [1..1]7 Administrative Sex CWE_IZ01 RE [0..1] 0001_018 Patient Address XAD_IZ01 RE [0..*]9 Phone Number - Home XTN_IZ01 RE [0..*]10 Multiple Birth Indicator ID_IZ01 RE [0..1] 0136_0111 Birth Order NM_IZ01 RE [0..1]12 Last Update Date/Time DTM O [0..1]13 Last Update Facility HD O [0..1]



3.2 Datatypes

Data types are critical building blocks that help form the foundation of successful interoperability. Each field, component and subcomponent has a data type. Conforming systems agree to adhere to the data type assigned to each element, assuring smooth communication. For example, date/times may be formatted in many ways, but to assure interoperability, these need to be constrained and defined, allowing dates and times to be as granular as needed to fulfill a use case.

Data types specify the format and type of data used. A data type may be as simple as a numeric data type, which allows a number. It may be a more complex coded entry that requires a specific set of code values and the name of the code system. Data types may contain elements that are specified by additional data types.

The following list of data types only includes those that are used by elements that are used in this guide (elements that have a usage of Required (R), Required But May be Empty (RE) or Conditional (C)). Data types that are used only for optional elements are not included, even if they are part of a segment that is used. Refer to the HL7 base standard for additional information about data types used by optional message elements.

Because there may be different requirements for message elements using the same base data type, this document uses different "flavors" of some data types. For example, one flavor of DTM requires granularity down to only the month to accommodate vaccines with an expiration date which does not include a day of the month. In contrast, another flavor of DTM requires granularity down to the second for use in MSH-7.

See section 2.5.5 of the v2.8.2 base standard for a discussion of Normative (2.5.5.0) and Conformance (2.5.5.3) Lengths.


3.2.1 CQ_IZ01 - COMPOSITE QUANTITY WITH UNITS

This data type carries a quantity and attendant units.

Quantity and Units required.

Data Type DefinitionSeq Element name Data type Usage Value Set1 Quantity NM_IZ01 R2 Units CWE_IZ01 R 0126_01

3.2.2 CWE_IZ01 - CODED WITH EXCEPTIONS

Specifies a coded element and its associated detail.

Identifier (first triplet) required, Alternate Identifier (second triplet) optional.

Data Type DefinitionSeq Element name Data type Usage Value Set1 Identifier ST_IZ01 R2 Text ST_IZ01 RE3 Name of Coding System ID_IZ01 R 0396_014 Alternate Identifier ST O5 Alternate Text ST O6 Name of Alternate Coding System ID O7 Coding System Version ID ST O8 Alternate Coding System Version ID ST O9 Original Text ST O10 Second Alternate Identifier ST O11 Second Alternate Text ST O12 Name of Second Alternate Coding System ID O13 Second Alternate Coding System Version ID ST O14 Coding System OID ST O15 Value Set OID ST O16 Value Set Version ID DTM O17 Alternate Coding System OID ST O18 Alternate Value Set OID ST O19 Alternate Value Set Version ID DTM O20 Second Alternate Coding System OID ST O21 Second Alternate Value Set OID ST O22 Second Alternate Value Set Version ID DTM O


Note: If valued, the alternate identifier (CWE.4) should be the closest match for the identifier found in CWE.1, that is, they should be synonyms.

The Name of Coding System (CWE.3/CWE.6) in the message should reference the Coding System, not the Value Set. Given the distinctions between value sets and coding system, often there is confusion as to the value to send in the message in the CWE data type. For coded data types, the coding system in the third component is drawn from table HL70396. Changes to Table 0396 occur frequently. The most recent version of this table is available at http://www.hl7.org/special/committees/vocab/table_0396/index.cfm which contains a list of possible values.

Example:

RXA-5 (vaccine): 49281-0560-05^Pentacel^NDC

With optional alternate ID: 49281-0560-05^Pentacel^NDC^120^DTaP-Hib-IPV^CVX

Note that if an optional alternate ID is included in a message, the order of coding systems in the element should not be relevant and is not specified by this document for any use case.

Component Definitions

CWE.2 : Text The descriptive or textual name of the identifier (e.g., DTaP) is not typically used by the sending or receiving system, but rather facilitates human interpretation of the code.

3.2.3 CWE_IZ02 - CODED WITH EXCEPTIONS

Specifies the original text while also allowing a coded value.

Original Text required. Coded identifiers optional.

Data Type DefinitionSeq Element name Data type Usage Value Set1 Identifier ST O2 Text ST O3 Name of Coding System ID O4 Alternate Identifier ST O5 Alternate Text ST O6 Name of Alternate Coding System ID O7 Coding System Version ID ST O8 Alternate Coding System Version ID ST O9 Original Text ST R10 Second Alternate Identifier ST O11 Second Alternate Text ST O12 Name of Second Alternate Coding System ID O


Seq Element name Data type Usage Value Set13 Second Alternate Coding System Version ID ST O14 Coding System OID ST O15 Value Set OID ST O16 Value Set Version ID DTM O17 Alternate Coding System OID ST O18 Alternate Value Set OID ST O19 Alternate Value Set Version ID DTM O20 Second Alternate Coding System OID ST O21 Second Alternate Value Set OID ST O22 Second Alternate Value Set Version ID DTM O

Example:

LOINC 59780-7 (Immunization series): ^^^^^^^^IPV 4-dose

3.2.4 CX_IZ01 - EXTENDED COMPOSITE ID WITH CHECK DIGIT

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

ID, Assigning Authority and Identifier Type Code required.

Data Type DefinitionSeq Element name Data type Usage Value Set1 ID Number ST_IZ01 R2 Identifier Check Digit ST O3 Check Digit Scheme ID O4 Assigning Authority HD_IZ01 R 0363_015 Identifier Type Code ID_IZ01 R 0203_016 Assigning Facility HD O7 Effective Date DT O8 Expiration Date DT O9 Assigning Jurisdiction CWE O10 Assigning Agency or Department CWE O11 Security Check ST O12 Security Check Scheme ID O

The combination of the Assigning Authority (CX.4) and Identifier Type Code (CX.5) should uniquely identify the pool of IDs from which the ID Number (CX.1) is selected.

Example:

Patient Identifier: 1234567^^^MyEHR^MR



CX.4 : Assigning Authority The assigning authority is an identifier of the system (or organization or agency or department) that creates the identifier in CX.1. The first component should be used for a unique namespace. The second and third components may be used for OIDs.

3.2.5 DT_IZ01 - DATE

Specifies the date.

Year, month and day required.Component Name UsageYYYY RMM RDD R

Data Type DefinitionSeq Element name Data type Usage Value Set1 DT

Example:

20180716

3.2.6 DTM_IZ01 - DATE/TIME

Specifies a point in time using a 24-hour clock notation.

Year, month, day, hour minute, second and Time Zone are required.

Data Type Definition # Value Usage Predicate1 YYYY R2 MM R3 DD R4 HH R5 MM R6 SS R7 s O8 s C(O/X) If s(1/10 second) is valued.9 s C(O/X) If s(1/100 second) is valued.10 s C(O/X) If s(1/1000 second) is valued.11 ZZZZ R




Year, month and day required, Time Zone optional.

Data Type Definition # Value Usage Predicate1 YYYY R2 MM R3 DD R4 HH O5 MM C(O/X) If HH (Hour) is valued.6 SS C(O/X) If MM (Minute) is valued.7 s C(O/X) If SS (Second) is valued.8 s C(O/X) If s (1/10 second) is valued.9 s C(O/X) If s (1/100 second) is valued.10 s C(O/X) If s (1/1000 second) is valued.11 ZZZZ O



Year and month are required.

Data Type Definition # Value Usage Predicate1 YYYY R2 MM R3 DD O4 HH C(O/X) If DD (Day) is valued.5 MM C(O/X) If HH (Hour) is valued.6 SS C(O/X) If MM (Minute) is valued.7 s C(O/X) If SS (Second) is valued.8 s C(O/X) If s (1/10 second) is valued.9 s C(O/X) If s (1/100 second) is valued.10 s C(O/X) If s (1/1000 second) is valued.11 ZZZZ O

3.2.9 EI_IZ01 - ENTITY IDENTIFIER

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

Namespace ID required, ability to support an OID required.


Data Type DefinitionSeq Element name Data type Usage Value Set1 Entity Identifier ST_IZ01 R2 Namespace ID IS_IZ01 R 0363_013 Universal ID ST_IZ01 RE4 Universal ID Type ID_IZ01 C(R/X) 0301

Conformance StatementsID DescriptionIZ-3 EI.3 (Universal ID) SHALL be valued with an ISO-compliant OID.EI_IZ01.4 EI.4 (Universal ID Type) SHALL contain the value "ISO" drawn from the code system "HL70301".

Conditional PredicatesLocation Usage DescriptionEI.4 C(R/X) If EI.3 (Universal ID) is valued.

The Entity Identifier (EI.1) is defined to be unique within the series of identifiers defined by the Namespace (EI.2) or the Universal ID/ID Type (EI.3 and EI.4).

Note that EI.2, EI.3 and EI.4 combined, function like the HD data type.

Example:

ORC-3 Filler Order Number: 242091^MyEHR


EI.3 : Universal ID If populated, the Universal ID shall be an OID.

3.2.10 EI_IZ02 - ENTITY IDENTIFIER

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

Namespace ID required.

Data Type DefinitionSeq Element name Data type Usage Value Set1 Entity Identifier ST_IZ01 R2 Namespace ID IS_IZ01 R 0363_013 Universal ID ST O4 Universal ID Type ID O

The Entity Identifier (EI.1) is defined to be unique within the pool of IDs defined by the Namespace (EI.2).


Example:

MSH-21 profile identifier: IZ54r1.0^CDCPHINVS

3.2.11 ERL_IZ01 - ERROR LOCATION

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

Data Type DefinitionSeq Element name Data type Usage Value Set1 Segment ID ST_IZ01 R2 Segment Sequence NM_IZ01 R3 Field Position NM_IZ01 C(R/RE)4 Field Repetition NM_IZ01 RE5 Component Number NM_IZ01 C(R/RE)6 Sub-Component Number NM_IZ01 RE

Conditional PredicatesLocation Usage DescriptionERL.3 C(R/RE) If ERL.5 (Component Number) is valued.ERL.5 C(R/RE) If ERL.6 (Sub-Component Number) is valued.

Example:

Error in the first occurrence of the fifth field of the first RXA segment: RXA^1^5^1


ERL.2 : Segment Sequence Identifies the segment occurrence within the message. That is, for the first instance of the segment in the message the number shall be 1 and for the second 2. It is not the sequence within a segment group. For example, if a message had 3 order groups and each order group had 3 OBX segments, the Sequence number of the last OBX in the message would be 9.

ERL.4 : Field Repetition Identifies the occurrence number of the field. The first occurrence is counted as 1. If a Field Position is specified, but Field Repetition is not, Field Repetition should be assumed to be 1.

3.2.12 FN_IZ01 - FAMILY NAME

This data type allows full specification of the surname of a person.

Surname required.

Data Type Definition


Seq Element name Data type Usage Value Set1 Surname ST_IZ01 R2 Own Surname Prefix ST O3 Own Surname ST O4 Surname Prefix from Partner/Spouse ST O5 Surname from Partner/Spouse ST O

3.2.13 HD_IZ01 - HIERARCHIC DESIGNATOR

The basic definition of the HD is that it identifies an entity (administrative or system or application or other) that has responsibility for managing or assigning a defined set of instance identifiers (such as patient identifiers, provider identifiers, etc.). This entity could be a particular health care application such as a registration system that assigns patient identifiers, a governmental entity such as a licensing authority that assigns professional identifiers or drivers' license numbers, or a facility where such identifiers are assigned.

Namespace ID required.

Data Type DefinitionSeq Element name Data type Usage Value Set1 Namespace ID IS_IZ01 R2 Universal ID ST_IZ01 RE3 Universal ID Type ID_IZ01 C(R/X) 0301

Conformance StatementsID DescriptionIZ-5 HD.2 (Universal ID) SHALL be valued with an ISO-compliant OID.

HD_IZ01.3 HD.3 (Universal ID Type) SHALL contain the value "ISO" drawn from the code system "HL70301".

Conditional PredicatesLocation Usage DescriptionHD.3 C(R/X) If HD.2 (Universal ID) is valued.

Example:

EHRAPP^2.16.840.1.113883.3.72.5.40.1^ISO


HD.2 : Universal ID If populated, the Universal ID shall be an OID.

3.2.14 ID_IZ01 - CODED VALUE FOR HL7 DEFINED TABLES

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


The value of such a field follows the formatting rules for an ST field except that it is drawn from a table of legal values.

3.2.15 IS_IZ01 - CODED VALUE FOR USER-DEFINED TABLES

This data type is used for coded values from a user-defined table.

The value of such a field follows the formatting rules for a ST field except that it is drawn from a site-defined (or user-defined) table of legal values.

3.2.16 MSG_IZ01 - MESSAGE TYPE

This data type contains the message type, trigger event, and the message structure ID for the message.

All components required.

Data Type DefinitionSeq Element name Data type Usage Value Set1 Message Code ID_IZ01 R 0076_012 Trigger Event ID_IZ01 R 0003_013 Message Structure ID_IZ01 R 0354_01

Example:

For the IZ22r1.0 profile: VXU^V04^VXU_V04

3.2.17 NM_IZ01 - 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. For example, the following two values with different representations, "01.20" and "1.2," are identical. Except for the optional leading sign (+ or -) and the optional decimal point (.), no non-numeric ASCII characters are allowed. Thus, the value <12 should be encoded as a structured numeric (SN) (preferred) or as a string (ST) (allowed, but not preferred) data type.

3.2.18 OG_IZ01 - OBSERVATION GROUPER

The data type is used to define the relationship of the observation/result segments (OBX) within a message.

Original Sub-Identifier required.

Data Type DefinitionSeq Element name Data type Usage Value Set1 Original Sub-Identifier ST_IZ01 R2 Group NM O3 Sequence NM O


Seq Element name Data type Usage Value Set4 Identifier ST O

3.2.19 PL_IZ01 - PERSON LOCATION

This data type is used to specify a patient location within a healthcare institution.

Facility required.

Data Type DefinitionSeq Element name Data type Usage Value Set1 Point of Care HD O2 Room HD O3 Bed HD O4 Facility HD_IZ01 R 0362_015 Location Status IS O6 Person Location Type IS O7 Building HD O8 Floor HD O9 Location Description ST O10 Comprehensive Location Identifier EI O11 Assigning Authority for Location HD O


PL.4 : Facility This is the location where the service was provided, for example a clinic. This may be a clinic that is a part of a larger provider organization or a provider organization. It is the location that is responsible for the inventory used for this immunization. If it provides Vaccine for Children funded vaccines, then it has a VFC PIN assigned.

3.2.20 PT_IZ01 - PROCESSING TYPE

This data type indicates whether to process a message as defined in HL7 Application (level 7) Processing rules.

Processing ID required.

Data Type DefinitionSeq Element name Data type Usage Value Set1 Processing ID ID_IZ01 R 0103_012 Processing Mode ID O

3.2.21 SAD_IZ01 - STREET ADDRESS

Appears only in the XAD data type.


Street or Mailing Address required.

Data Type DefinitionSeq Element name Data type Usage Value Set1 Street or Mailing Address ST_IZ01 R2 Street Name ST O3 Dwelling Number ST O

3.2.22 SI_IZ01 - SEQUENCE ID

A non-negative integer in the form of a NM field. The uses of this data type are defined in the chapters defining the segments and messages in which it appears.

3.2.23 SNM_IZ01 - STRING OF TELEPHONE NUMBER DIGITS

A string whose characters are limited to "+" and/or the decimal digits 0 through 9. As a string, leading zeros are always considered significant.

Used in the XTN data type.

3.2.24 ST_IZ01 - STRING DATA

String data is left justified (i.e., no leading blank space) with trailing blanks optional. Any displayable (printable) ACSII characters (hexadecimal values between 20 and 7E, inclusive, or ASCII decimal values between 32 and 126), except the defined escape characters and defined delimiter characters.

The ST data type is normally used for short text strings. No leading blanks (space characters) are permitted. Trailing blanks are permitted. In this document, the only allowed escape sequences are those allowed in HL7 v2.8.2, Chapter 2, Section 2.7.5 - Special Character. These are the escape sequences for the message delimiters.

3.2.25 TX_IZ01 - TEXT DATA

String data meant for user display. Such data would not necessarily be left justified since leading spaces may contribute greatly to the clarity of the presentation to the user. Leading spaces should be included. Trailing spaces should be removed.

In this document, the only allowed escape sequences are those allowed in HL7 v2.8.2, Chapter 2, Section 2.7.4 - Special Characters. These are the escape sequences for the message delimiters (i.e., |^&~\ ).

3.2.26 VID_IZ01 - VERSION IDENTIFIER

This data type specifies the HL7 version.

Version ID required.

Data Type DefinitionSeq Element name Data type Usage Value Set1 Version ID ID_IZ01 R


Seq Element name Data type Usage Value Set2 Internationalization Code CWE O3 International Version ID CWE O

3.2.27 XAD_IZ01 - EXTENDED ADDRESS

This data type specifies the address of a person, place or organization plus associated information.

Data Type DefinitionSeq Element name Data type Usage Value Set1 Street Address SAD_IZ01 RE2 Other Designation ST_IZ01 RE3 City ST_IZ01 RE4 State or Province ST_IZ01 RE USPS_State5 Zip or Postal Code ST_IZ01 RE6 Country ID_IZ01 RE 0399_017 Address Type ID_IZ01 R 0190_018 Other Geographic Designation ST O9 County/Parish Code CWE O10 Census Tract CWE O11 Address Representation Code ID O12 Address Validity Range - X13 Effective Date DTM O14 Expiration Date DTM O15 Expiration Reason CWE O16 Temporary Indicator ID O17 Bad Address Indicator ID O18 Address Usage ID O19 Addressee ST O20 Comment ST O21 Preference Order NM O22 Protection Code CWE O23 Address Identifier EI OExample:

Usage for US: 1000 Hospital Lane^Ste. 123^Ann Arbor ^MI^99999^^P|

This would be formatted for postal purposes as:

1000 Hospital Lane

Ste. 123


Ann Arbor MI 99999

3.2.28 XCN_IZ01 - EXTENDED COMPOSITE ID NUMBER AND NAME FOR PERSONS

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

Name or ID required.

Data Type DefinitionSeq Element name Data type Usage Value Set1 Person Identifier ST_IZ01 C(R/RE)2 Family Name FN_IZ01 RE3 Given Name ST_IZ01 RE

4 Second and Further Given Names or Initials Thereof ST_IZ01 RE

5 Suffix (e.g., JR or III) ST O6 Prefix (e.g., DR) ST O7 Degree (e.g., MD) - X8 Source Table CWE O9 Assigning Authority HD_IZ01 C(R/X)10 Name Type Code ID_IZ01 RE 0200_0211 Identifier Check Digit ST O12 Check Digit Scheme ID O13 Identifier Type Code ID_IZ01 C(R/X) 0203_0314 Assigning Facility HD O15 Name Representation Code ID O16 Name Context CWE O17 Name Validity Range - X18 Name Assembly Order - X19 Effective Date DTM O20 Expiration Date DTM O21 Professional Suffix ST O22 Assigning Jurisdiction CWE O23 Assigning Agency or Department CWE O24 Security Check ST O25 Security Check Scheme ID O

Conditional PredicatesLocation Usage DescriptionXCN.1 C(R/RE) If XCN.2.1 (Surname) is not valued AND if XCN.3 (Given Name) is not valued.XCN.9 C(R/X) If XCN.1 (Person Identifier) is valued.


Location Usage DescriptionXCN.13 C(R/X) If XCN.1 (Person Identifier) is valued.

Note: The ID Number component combined with the Assigning Authority (XCN.9) and ID type (XCN.13) must uniquely identify the associated person.

Example:

7824^Jackson^Lily^Suzanne^^^^^MyEHR^L^^^PRN


XCN.4 : Second and Further Given Names or Initials Thereof Multiple middle names may be included by separating them with spaces.

3.2.29 XON_IZ01 - EXTENDED COMPOSITE NAME AND IDENTIFICATION NUMBER FOR ORGANIZATIONS

This data type identifies an organization using a unique ID and/or name.

Name or ID required.

Data Type DefinitionSeq Element name Data type Usage Value Set1 Organization Name ST_IZ01 RE2 Organization Name Type Code CWE O3 ID Number - X4 Identifier Check Digit - X5 Check Digit Scheme - X6 Assigning Authority HD_IZ01 C(R/X)7 Identifier Type Code ID_IZ01 C(R/X) 0203_028 Assigning Facility HD O9 Name Representation Code ID O10 Organization Identifier ST_IZ01 C(R/RE)

Conditional PredicatesLocation Usage DescriptionXON.6 C(R/X) If XON.10 (Organization Identifier) is valued.XON.7 C(R/X) If XON.10 (Organization Identifier) is valued.XON.10 C(R/RE) If XON.1 (Organization Name) is not valued.

The combination of the Assigning Authority (XON.6) and the Identifier Type Code (XON.7) define a unique ID pool.


3.2.30 XPN_IZ01 - EXTENDED PERSON NAME

This is used for representing a person's name.

Family Name, Given Name and Name Type Code required.

Data Type DefinitionSeq Element name Data type Usage Value Set1 Family Name FN_IZ01 R2 Given Name ST_IZ01 R

3 Second and Further Given Names or Initials Thereof ST_IZ01 RE

4 Suffix (e.g., JR or III) ST O5 Prefix (e.g., DR) ST O6 Degree (e.g., MD) - X7 Name Type Code ID_IZ01 R 0200_018 Name Representation Code ID O9 Name Context CWE O10 Name Validity Range - X11 Name Assembly Order ID O12 Effective Date DTM O13 Expiration Date DTM O14 Professional Suffix ST O15 Called By ST O

Example:

Richardson^Russell^Clint^^^^L


XPN.3 : Second and Further Given Names or Initials Thereof Multiple middle names may be included by separating them with spaces.

XPN.7 : Name Type Code A code that represents the type of name

Note: The content of Legal Name is country specific. In the US the legal name is the same as the current married name.

3.2.31 XPN_IZ02 - EXTENDED PERSON NAME

This is used for representing a mother's maiden name.

Only Family Name and Name Type Code required.


Data Type DefinitionSeq Element name Data type Usage Value Set1 Family Name FN_IZ01 R2 Given Name ST O

3 Second and Further Given Names or Initials Thereof ST O

4 Suffix (e.g., JR or III) ST O5 Prefix (e.g., DR) ST O6 Degree (e.g., MD) - X7 Name Type Code ID_IZ01 R 02008 Name Representation Code ID O9 Name Context CWE O10 Name Validity Range - X11 Name Assembly Order ID O12 Effective Date DTM O13 Expiration Date DTM O14 Professional Suffix ST O15 Called By ST O

Conformance StatementsID DescriptionXPN_IZ02.7 XPN.7 (Name Type Code) SHALL contain the value "M" drawn from the code system "HL70200".


XPN.1 : Family Name This is the person's surname or family name.

Usage note:For use when communicating a mother's maiden name.

3.2.32 XTN_IZ01 - EXTENDED TELECOMMUNICATION NUMBER

This contains the extended telecommunication data. Includes phone number and email address.

Data Type DefinitionSeq Element name Data type Usage Value Set1 Telephone Number - X2 Telecommunication Use Code ID_IZ01 R 0201_013 Telecommunication Equipment Type ID_IZ01 R 0202_014 Communication Address ST_IZ01 C(R/X)5 Country Code SNM O


Seq Element name Data type Usage Value Set6 Area/City Code SNM_IZ01 C(RE/X)7 Local Number SNM_IZ01 C(R/X)8 Extension SNM O9 Any Text ST O10 Extension Prefix ST O11 Speed Dial Code ST O12 Unformatted Telephone number ST O13 Effective Start Date DTM O14 Expiration Date DTM O15 Expiration Reason CWE O16 Protection Code CWE O17 Shared Telecommunication Identifier EI O18 Preference Order NM O

Conditional PredicatesLocation Usage DescriptionXTN.4 C(R/X) If XTN.3 (Telecommunication Equipment Type) contains the value “Internet”.XTN.6 C(RE/X) If XTN.3 (Telecommunication Equipment Type) does not contain the value “Internet”.XTN.7 C(R/X) If XTN.3 (Telecommunication Equipment Type) does not contain the value “Internet”.

Note: Each telecommunication use code (ie. Phone number, email address, etc) must be in its own occurrence

Example:

Home telephone number: ^PRN^PH^^^734^5559907Work telephone number: ^WPN^PH^^^734^5556319Home email address: ^PRNÎnternet^[email protected] email address: ^WPNÎnternet^[email protected] mobile phone number: ^PRS^CP^^^734^5553750

All personal telecommunication codes in a single field: ^PRS^CP^^^734^5553750~^PRN^PH^^^734^5559907~^PRNÎnternet^[email protected]

3.3 Value Sets Interoperability discussions often reference both "coding systems" (AKA Code Sets) and "value sets" in relation to coded message elements (including the CWE, CX, IS, ID and XCN data types). While related, these terms are distinct. A coding system is an extensive, and in some cases extendable, list of values available for use in a message. A single coding system may be relevant to a number of different parts of a single message. For example, HL7 table 0203 contains a list of Identifier Types. This table is called out as part of the CX data type (used in PID-3 and QPD-3) as well as the XCN data type (used in ORC-12 and RXA-10). A coding system tends to be a very broad list and not all values are appropriate to use in a given message element. For example, HL7 table 0203 contains the ID types of MR (Medical Record Number) and NPI (National Provider Identifier) which are appropriate for use in PID-3 and ORC-12 respectively. In contrast, a value set is a more refined list of values, taken from one or more coding systems, applied at a more granular level of the message


and which contains only values appropriate for that location in the message. For example, separate value sets based on HL7 table 0203 may be created for use in patient and provider related fields. The patient related value set may contain the MR value (along with other relevant patient related values) while the provider value set may contain the NPI value (along with other provider relevant values). In some cases, a value set may fully have the same content as the underlying coding system. A single value set may include codes from multiple coding systems.

Note that for complex coded data types (such as CWE), the Name of Coding System (CWE.3/CWE.6) in the message should reference the coding system, not the value set.

Value sets have several attributes which impact the implementation of profiles and transactions.

Extensibility indicates if a value set can be extended by local trading partner agreement. Open extensibility indicates that trading partners have the latitude to include additional values to meet local needs. If a code exists in the value set for the concept that is being conveyed, then the implementer must use the code specified (i.e., a local code cannot be used as a substitute). Closed extensibility indicates that the value set cannot be extended while adhering to the profile, even by local agreement. Note that even if the value set is closed, the document authors may choose to extend or modify the value set in future versions of the specification.

Stability indicates how the value set is bound to an underlying coding system. A stability of static indicates that the value set is fixed both in terms of attributes and values. If a value set needs to be modified, it must be done through the publication of a new value set and specification. A stability of dynamic indicates that the value set can evolve as the underlying coding systems change independent of the publication of the specification. For example, the CVX coding system identifies vaccines and new CVX codes are added periodically. The vaccine value set based on CVX has a stability of dynamic meaning that as new codes are added, conformant systems are expected to support them even though the new codes are not published explicitly in the specification.

Content Definition indicates how values are specified in the value set. Extensional value sets contain an enumerated list of codes. Intensional value sets are defined by rules that, when executed, define the set of values in the value set.

Vocabulary (Value) Usage is similar to the Usage assigned to fields, components and sub-component in profile and data type definitions. Vocabulary usage is used to define which values must (or must not) be supported by a conformant system.

Required (R) - a code must be supported by a conformant systemExcluded (E) - a code must not be used by a conformant systemPermitted (P) - by local agreement, and depending upon local need, the code may or may not be supported by trading partners

For an open value set, all values not explicitly listed in the value set have a Usage of Permitted. For a closed value set, all values not explicitly listed in the value set have a Usage of Excluded.

3.3.1 0001_01 - ADMINISTRATIVE SEX

Metadata OID: 2.16.840.1.114222.4.11.927


Attributes Stability Extensibility Content DefinitionStatic Open Extensional

CodesValue Code System Usage DescriptionA HL70001 P AmbiguousF HL70001 R FemaleM HL70001 R MaleN HL70001 P Not applicableO HL70001 P OtherU HL70001 R Unknown

3.3.2 0003_01 - EVENT TYPE

Metadata OID: 2.16.840.1.114222.4.11.3362

Attributes Stability Extensibility Content DefinitionStatic Closed Extensional

CodesValue Code System Usage DescriptionA31 HL70003 P ADT - Update Person InformationK11 HL70003 R RSP - Segment pattern response in response to QBP^Q11

Q11 HL70003 R QBP - Query by parameter requesting an RSP segment pattern response

V04 HL70003 R VXU - Unsolicited vaccination record update

3.3.3 0004_01 - PATIENT CLASS


CodesValue Code System Usage DescriptionN HL0004 R Not Applicable

3.3.4 0008_01 - ACKNOWLEDGMENT CODE

Metadata OID: 2.16.840.1.114222.4.11.958

Attributes


Stability Extensibility Content DefinitionStatic Closed Extensional

CodesValue Code System Usage DescriptionAA HL70008 R Application AcceptAE HL70008 R Application ErrorAR HL70008 R Application RejectCA HL70008 E Enhanced mode Accept acknowledgment: Commit AcceptCE HL70008 E Enhanced mode Accept acknowledgment: Commit ErrorCR HL70008 E Enhanced mode Accept acknowledgment: Commit Reject

3.3.5 0063_01 - RELATIONSHIP

Metadata OID: 2.16.840.1.114222.4.11.813


CodesValue Code System Usage DescriptionASC HL70063 P AssociateBRO HL70063 P BrotherCGV HL70063 P Care giverCHD HL70063 P ChildDEP HL70063 P Handicapped dependentDOM HL70063 P Life partnerEMC HL70063 P Emergency contactEME HL70063 E EmployeeEMR HL70063 E EmployerEXF HL70063 P Extended familyFCH HL70063 P Foster childFND HL70063 P FriendFTH HL70063 R FatherGCH HL70063 P GrandchildGRD HL70063 R GuardianGRP HL70063 P GrandparentMGR HL70063 E ManagerMTH HL70063 R MotherNCH HL70063 P Natural childNON HL70063 E NoneOAD HL70063 P Other adult


Value Code System Usage DescriptionOTH HL70063 P OtherOWN HL70063 E OwnerPAR HL70063 R ParentSCH HL70063 P StepchildSEL HL70063 P SelfSIB HL70063 P SiblingSIS HL70063 P SisterSPO HL70063 P SpouseTRA HL70063 P TrainerUNK HL70063 P UnknownWRD HL70063 P Ward of court

3.3.6 0064_01 - PATIENT ELIGIBILITY

Metadata OID: 2.16.840.1.114222.4.11.3366


CodesValue Code System Usage Description CommentV01 HL70064 R Not VFC eligible

V02 HL70064 R VFC eligible - Medicaid/Medicaid Managed Care

V03 HL70064 R VFC eligible - Uninsured

V04 HL70064 R VFC eligible - American Indian/Alaska native

V05 HL70064 R VFC eligible - underinsured at FQHC/RHC/deputized provider

V22 HL70064 R CHIP https://www.healthcare.gov/medicaid-chip/childrens-health-insurance-program/

V23 HL70064 R 317 https://www.cdc.gov/vaccines/imz-managers/guides-pubs/qa-317-funds.html

V24 HL70064 R MedicareV25 HL70064 R State program eligibility

3.3.7 0072_01 - INSURANCE PLAN ID



CodesValue Code System Usage Description... HL70072 No suggested values

3.3.8 0076_01 - MESSAGE TYPE

Metadata OID: 2.16.840.1.114222.4.11.3364


CodesValue Code System Usage DescriptionACK HL70076 R General acknowledgment messageADT HL70076 P Update Person InformationQBP HL70076 R Query by parameterRSP HL70076 R Segment pattern responseVXU HL70076 R Unsolicited vaccination record update

3.3.9 0086_01 - PLAN ID



3.3.10 0103_01 - PROCESSING ID

Metadata OID: 2.16.840.1.114222.4.11.1028


CodesValue Code System Usage DescriptionD HL70103 P DebuggingP HL70103 R ProductionT HL70103 P Training


3.3.11 0125_01 - VALUE TYPE

Metadata OID: 2.16.840.1.114222.4.11.3392


CodesValue Code System Usage DescriptionCNE HL70125 P Coded with no exceptionsCWE HL70125 R Coded with exceptionsCX HL70125 P Extended composite ID with check digitDT HL70125 R DateDTM HL70125 P Date/timeED HL70125 P Encapsulated dataEI HL70125 P Entity identifierFT HL70125 P Formatted textHD HL70125 P Hierarchic designatorID HL70125 R Coded value for HL7 defined tablesIS HL70125 P Coded value for user-defined tablesNM HL70125 R NumericRP HL70125 P Reference pointerSN HL70125 P Structured numericST HL70125 R String dataTX HL70125 P Text

3.3.12 0126_01 - QUANTITY LIMITED REQUEST

Metadata OID: 2.16.840.1.114222.4.11.3383


CodesValue Code System Usage DescriptionRD HL70126 R Records

3.3.13 0136_01 - YES/NO INDICATOR

Metadata OID: 2.16.840.1.114222.4.11.819



CodesValue Code System Usage DescriptionN HL70136 R NoY HL70136 R Yes

3.3.14 0163_01 - BODY SITE

Metadata OID: 2.16.840.1.114222.4.11.3370


CodesValue Code System Usage DescriptionBN HL70163 R Bilateral NaresLA HL70163 R Left ArmLD HL70163 R Left DeltoidLG HL70163 R Left Gluteous MediusLLFA HL70163 R Left Lower ForearmLT HL70163 R Left ThighLVL HL70163 R Left Vastus LateralisRA HL70163 R Right ArmRD HL70163 R Right DeltoidRG HL70163 R Right Gluteous MediusRLFA HL70163 R Right Lower ForearmRT HL70163 R Right ThighRVL HL70163 R Right Vastus Lateralis

3.3.15 0190_01 - ADDRESS TYPE

Metadata OID: 2.16.840.1.114222.4.11.801


CodesValue Code System Usage DescriptionB HL70190 P Firm/Business


Value Code System Usage DescriptionBA HL70190 P Bad addressBDL HL70190 P Birth delivery location (address where birth occurred)BI HL70190 P Billing AddressBR HL70190 P Residence at birth (home address at time of birth)C HL70190 P Current Or TemporaryF HL70190 P Country Of OriginH HL70190 P HomeL HL70190 P Legal AddressM HL70190 R MailingN HL70190 P Birth (nee) (birth address, not otherwise specified)O HL70190 P Office/BusinessP HL70190 R Permanent

RH HL70190 P

Registry home. Refers to the information system, typically managed by a public health agency, that stores patient information such as immunization histories or cancer data, regardless of where the patient obtains services.

S HL70190 P Service LocationSH HL70190 P Shipping AddressTM HL70190 P Tube AddressV HL70190 P Vacation

3.3.16 0200_01 - NAME TYPE (PATIENT NAME)

Metadata OID: 2.16.840.1.114222.4.11.3371


CodesValue Code System Usage DescriptionA HL70200 P AssignedB HL70200 P Birth nameBAD HL70200 P Bad NameC HL70200 P Adopted NameD HL70200 P Customary NameF HL70200 P Fathers NameI HL70200 P Licensing NameK HL70200 P Business nameL HL70200 P Official Registry NameM HL70200 P Maiden NameMSK HL70200 P Masked


Value Code System Usage DescriptionN HL70200 P NicknameNAV HL70200 P Temporarily UnavailableNB HL70200 P Newborn NameNOUSE HL70200 P No Longer To Be UsedP HL70200 P Name of Partner/SpouseR HL70200 P Registered NameREL HL70200 P ReligiousS HL70200 P PseudonymT HL70200 P Indigenous/TribalTEMP HL70200 P Temporary NameU HL70200 P Unknown

3.3.17 0200_02 - NAME TYPE (PROVIDER NAME)

Metadata OID: 2.16.840.1.114222.4.11.3371


CodesValue Code System Usage DescriptionA HL70200 P AssignedB HL70200 E Birth nameBAD HL70200 E Bad NameC HL70200 P Adopted NameD HL70200 P Customary NameF HL70200 E Fathers NameI HL70200 P Licensing NameK HL70200 P Business nameL HL70200 R Official Registry NameM HL70200 E Maiden NameMSK HL70200 E MaskedN HL70200 E NicknameNAV HL70200 E Temporarily UnavailableNB HL70200 E Newborn NameNOUSE HL70200 E No Longer To Be UsedP HL70200 E Name of Partner/SpouseR HL70200 P Registered NameREL HL70200 E ReligiousS HL70200 E PseudonymT HL70200 P Indigenous/Tribal


Value Code System Usage DescriptionTEMP HL70200 E Temporary NameU HL70200 E Unknown

3.3.18 0201_01 - TELECOMMUNICATION USE CODE

Metadata OID: 2.16.840.1.114222.4.11.818


CodesValue Code System Usage DescriptionASN HL70201 P Answering Service NumberBPN HL70201 P Beeper NumberEMR HL70201 P Emergency NumberNET HL70201 P Network (email) AddressORN HL70201 P Other Residence NumberPRN HL70201 R Primary Residence NumberPRS HL70201 R PersonalVHN HL70201 P Vacation Home NumberWPN HL70201 R Work Number

BPN and NET are retained for backwards compatibility only as of HL7 version 2.6.

3.3.19 0202_01 - TELECOMMUNICATION EQUIPMENT TYPE

Metadata OID: 2.16.840.1.114222.4.11.817


CodesValue Code System Usage DescriptionBP HL70202 P BeeperCP HL70202 R Cellular or Mobile PhoneFX HL70202 P FaxInternet HL70202 R Internet AddressMD HL70202 P ModemPH HL70202 R TelephoneSAT HL70202 P Satellite PhoneTDD HL70202 P Telecommunications Device for the Deaf


Value Code System Usage DescriptionTTY HL70202 P TeletypewriterX.400 HL70202 P X.400 email address

3.3.20 0203_01 - IDENTIFIER TYPE (PATIENT)

Metadata OID: 2.16.840.1.114222.4.11.3372


CodesValue Code System Usage DescriptionANON HL70203 P Anonymous identifierANT HL70203 P Temporary Account NumberBCT HL70203 P Birth CertificateBR HL70203 P Birth registry numberDL HL70203 P Driver's license numberHC HL70203 P Health Card NumberIND HL70203 P Indigenous/AboriginalLR HL70203 P Local Registry IDMA HL70203 P Patient Medicaid numberMC HL70203 P Patient's Medicare numberMI HL70203 P Military ID numberMR HL70203 R Medical record numberMRT HL70203 P Temporary Medical Record NumberNI HL70203 P National unique individual identifierPI HL70203 P Patient internal identifierPN HL70203 P Person numberPT HL70203 P Patient external identifierRRI HL70203 P Regional registry IDSR HL70203 P State registry IDSS HL70203 P Social Security number

3.3.21 0203_02 - IDENTIFIER TYPE (ORGANIZATION)

Metadata OID: 2.16.840.1.114222.4.11.3372



CodesValue Code System Usage DescriptionFI HL70203 P Facility IDLR HL70203 P Local Registry IDRRI HL70203 P Regional registry IDSR HL70203 P State registry IDXX HL70203 R Organization identifier

3.3.22 0203_03 - IDENTIFIER TYPE (PROVIDER)

Metadata OID: 2.16.840.1.114222.4.11.3372


CodesValue Code System Usage DescriptionAMA HL70203 P American Medical Association NumberAPRN HL70203 P Advanced Practice Registered Nurse numberDN HL70203 P Doctor numberEI HL70203 P Employee numberESN HL70203 P Staff Enterprise NumberLANR HL70203 P Lifelong physician numberLN HL70203 P License numberMCD HL70203 P Practitioner Medicaid numberMCR HL70203 P Practitioner Medicare numberMD HL70203 P Medical License numberNP HL70203 P Nurse practitioner numberNPI HL70203 P National provider identifierPA HL70203 P Physician Assistant numberPPIN HL70203 P Medicare/CMS Performing Provider Identification NumberPRN HL70203 R Provider numberRN HL70203 P Registered Nurse NumberRRI HL70203 P Regional registry IDSL HL70203 P State license

UPIN HL70203 P Medicare/CMS (formerly HCFA)'s Universal Physician Identification numbers

3.3.23 0206_01 - SEGMENT ACTION CODE

Metadata OID: 2.16.840.1.114222.4.11.7827



CodesValue Code System Usage DescriptionA HL70206 R Add/InsertD HL70206 R DeleteU HL70206 R UpdateX HL70206 P No Change

3.3.24 0208_01 - QUERY RESPONSE STATUS

Metadata OID: 2.16.840.1.114222.4.11.3374


CodesValue Code System Usage DescriptionAE HL70208 R Application errorNF HL70208 R No data found, no errorsOK HL70208 R Data found, no errors (this is the default)PD HL70208 R Protected dataTM HL70208 R Too much data found

3.3.25 0215_01 - PUBLICITY CODE

Metadata OID: 2.16.840.1.114222.4.11.3384


CodesValue Code System Usage Description01 HL70215 R No reminder/recall02 HL70215 R Reminder/recall - any method03 HL70215 R Reminder/recall - no calls04 HL70215 R Reminder only - any method05 HL70215 R Reminder only - no calls06 HL70215 R Recall only - any method


Value Code System Usage Description07 HL70215 R Recall only - no calls08 HL70215 R Reminder/recall - to provider09 HL70215 R Reminder to provider10 HL70215 R Only reminder to provider, no recall11 HL70215 R Recall to provider12 HL70215 R Only recall to provider, no reminder

3.3.26 0322_01 - COMPLETION STATUS

Metadata OID: 2.16.840.1.114222.4.11.821


CodesValue Code System Usage DescriptionCP HL70322 R CompleteNA HL70322 R Not AdministeredPA HL70322 R Partially AdministeredRE HL70322 R Refused

3.3.27 0354_01 - MESSAGE STRUCTURE

Metadata OID: 2.16.840.1.114222.4.11.3376 Version 2


CodesValue Code System Usage DescriptionACK HL70354 R VariesADT_A05 HL70354 P A31QBP_Q11 HL70354 R Q11RSP_K11 HL70354 R K11VXU_V04 HL70354 R V04

3.3.28 0357_01 - MESSAGE ERROR CONDITION CODES

Metadata OID: 2.16.840.1.114222.4.11.974

Attributes


Stability Extensibility Content DefinitionStatic Open Extensional

CodesValue Code System Usage Description0 HL70357 P Message accepted100 HL70357 R Segment sequence error101 HL70357 P Required field missing102 HL70357 P Data type error103 HL70357 P Table value not found104 HL70357 P Value too long200 HL70357 R Unsupported message type201 HL70357 R Unsupported event code202 HL70357 R Unsupported processing id203 HL70357 R Unsupported version id204 HL70357 P Unknown key identifier205 HL70357 P Duplicate key identifier206 HL70357 P Application record locked207 HL70357 R Application internal error

Error code 207 indicates that an application generated error exists. ERR-5 and ERR-8 will contain additional information on the nature of the error. This error is unrelated to the message structure but indicates that the system may not use the data.

3.3.29 0361_01 - APPLICATION



3.3.30 0362_01 - FACILITY




3.3.31 0363_01 - ASSIGNING AUTHORITY

Attributes Stability Extensibility Content DefinitionDynamic Open Extensional


3.3.32 0396_01 - CODING SYSTEM

Metadata OID: 2.16.840.1.114222.4.11.3338


CodesValue Code System Usage Description99zzz HL70396 P Local general code where z is an alphanumeric charactercdcgs1vis HL70396 R VIS Bar Codes (IIS)CDCPHINVS HL70396 R CDC PHIN Vocabulary Coding SystemCDCREC HL70396 R Race & Ethnicity - CDCCVX HL70396 R CDC Vaccine CodesHL7nnnn HL70396 P HL7 Defined Codes where nnnn is the HL7 table numberL HL70396 P Local general codeLN HL70396 R Logical Observation Identifier Names and Codes (LOINC)MVX HL70396 R CDC Vaccine Manufacturer CodesNDC HL70396 R National drug codesNIP001 HL70396 R Source of Information (Immunization)NIP002 HL70396 R Substance refusal reasonSCT HL70396 P SNOMED Clinical TermsUCUM HL70396 R UCUM code set for units of measure (from Regenstrief)USPS HL70396 P United States Postal Service

The most current list of HL7 validated coding systems is available at https://www.hl7.org/Special/committees/vocab/table_0396/index.cfm.

3.3.33 0399_01 - COUNTRY CODE



CodesValue Code System Usage DescriptionUSA HL70399 R United States

3.3.34 0441_01 - IMMUNIZATION REGISTRY STATUS

Metadata OID: 2.16.840.1.114222.4.11.3377


CodesValue Code System Usage DescriptionA HL70441 R ActiveI HL70441 R InactiveL HL70441 P Inactive - Lost to follow-up (cancel contract)M HL70441 P Inactive - Moved or gone elsewhere (cancel contract)O HL70441 P Other

P HL70441 P Inactive - Permanently inactive (Do not reactivate or add new entries to the record)

U HL70441 P Unknown

3.3.35 0516_01 - ERROR SEVERITY

Metadata OID: 2.16.840.1.114222.4.11.993


CodesValue Code System Usage Description CommentE HL70516 R Error

F HL70516 P Fatal Error Message not processed due to application or network failure condition

I HL70516 R InformationW HL70516 R Warning

3.3.36 0532_01 - EXPANDED YES/NO INDICATOR

More granular statuses than those provided in this value set (eg. extraneous) may be assigned by a clinical decision support engine but mapped to Y or N (as appropriate) for the purposes of exchanging data. It is beyond the scope of this document to map more granular statuses to either a valid or not valid status.


Metadata OID: 2.16.840.1.114222.4.11.820


CodesValue Code System Usage Description Comment

N HL70532 R NoNot Valid - N should be used when the system generating the RSP message does not count the dose towards completion of a series for the patient

NI HL70532 R No InformationA clinical decision support engine may not evaluate all vaccine groups. For example, rabies or yellow fever may not be common enough to evaluate

Y HL70532 R YesValid - Y should be used when the system generating the RSP message counts the dose towards completion of a series for the patient

3.3.37 0533_01 - APPLICATION ERROR CODE

The use of standarized application level error codes will ensure that vendors and organizations operating across jurisdictional lines will receive consistent error content from trading partners, opening the door to more automated routing and handling of error conditions.

Systems that generate ERR segment containing ACK and RSP messages (i.e. IIS) should incorporate standard error codes into ERR-5 and not create their own local codes when the relevant error scenario is encountered. However, systems are not expected to be able identify all listed error scenarios. In other words, an IIS will not be expected to perform all of the checks and validations required to identify every error scenario, however, if local business logic identifies an error scenario for which a standard error code is defined, the IIS should use the standard error code in ERR-5 in place of a locally defined code.

Systems that receive ERR segments in ACK and/or RSP messages (i.e. IIS submitters such as EHRs and pharmacies) should gracefully accept any error code in ERR-5. Note that "gracefully" handling an unexpected error code may simply consist of populating a generic work queue for manual error investigation and resolution. Similarly, if ERR-5 is not populated with an error code, the receiving system should be prepared to accept the message.

Before taking more advanced error resolution actions based on the ERR-5 error code, the owners of a system must be confident that the trading partner generating error contain messages is adhering to the use of the standard error codes. If the trading partner is redefining any nationally defined error codes, inappropriate action may be taken, potentially resulting in negative data quality and patient care consequences.




1 HL70533 P Illogical date error Not recommended for use. Use a more granular application error instead.

2 HL70533 P Invalid date Date is not valid or lacks required precision.

3 HL70533 P Illogical value error Not recommended for use. Use a more granular application error instead.

4 HL70533 P Invalid value The value is not valid. This applies for fields that are not associated with a table of values.

5 HL70533 P Table value not found The value is not found in the associated table.

6 HL70533 P Required observation missing

A required observation, such as VFC eligibility status, is missing.

7 HL70533 P Required Data MissingThis error should be applied at the application level and may be used when data is sent but could not be interpreted.

2000 HL70533 P Conflicting Start and End Date of Administration

Indicates that the dates in RXA-3 and RXA-4 are not identical.

2001 HL70533 P Conflicting Administration Date and Expiration Date

Indicates a conflict between the administration date in RXA-3 and the expiration date in RXA-16. In other words it indicates that an expired vaccine was administered.

2002 HL70533 P Conflicting Date of Birth and Date of Death

Indicates that the date of birth messaged in PID-7 is after the date of death messaged in PID-29.

2003 HL70533 P Conflicting Codes in a Field

Indicates that if an ID and an alternate ID are messaged in the same field, that the receiving system has mapped those two codes to different, non-homologous concepts.

2004 HL70533 P Conflicting Query Identifiers Indicates that the profile in MSH-21 does not match the query in QPD-1.

2005 HL70533 P Conflicting Facilities Indicates that the facilities in MSH-4, MSH-11, ORC-17 and/or RXA-11 do not match

2006 HL70533 P Conflicting Patient IDsUsed when multiple IDs are messaged in PID-3 to indicate that the individual IDs are associated with different patient records in the IIS.

2007 HL70533 PConflicting Patient Status and Patient Death Information

Indicates a conflict between PID-29 and PID-30 or between PD1-16 and either PID field. In other words, one element indicates the patient is deceased and another element indicates the patient is not deceased.

2008 HL70533 P Conflicting Completion Status and Refusal Reason

Indicates that either a refusal reason was messaged in RXA-18 when the completion status in RXA-20 was not RE or a valid refusal reason was not messaged when the completion status was RE.

2009 HL70533 P Conflicting Lot Number and Indicates that the lot number messaged in RXA-


Value Code System Usage Description Comment

Funding Source

15 conflicts with the funding source messaged in an OBX segment. In other words, the lot number is associated with a funding source (public, private, etc) but a different funding source is reported in an OBX segment.

2010 HL70533 P Conflicting vaccine ID and Manufacturer

Indicates that the manufacturer messaged in RXA-17 is not valid for the vaccine identifier messaged in RXA-5.

2011 HL70533 P Conflicting Vaccine and Lot Number

Indicates that the lot number messaged in RXA-15 is not valid for the vaccine messaged in RXA-5.

2012 HL70533 P Conflicting Eligibility Information

Indicates that the eligibility code in an OBX segment conflicts with other data in the message (age, race, etc)

2013 HL70533 P Conflicting Funding Source Data

Indicates that the funding source code in an OBX segment conflicts with other data in the message (eligibility, age etc)

2014 HL70533 P Conflicting Vaccine and Amount Data

Indicates that the administration amount is inconsistent with the vaccine administered

2015 HL70533 P Conflicting Dose Status and Eligibility

Indicates that patient eligibility data should not be sent for historical doses

2016 HL70533 P Conflicting Vaccine and Route Data

Indicates that the administration route is inconsistent with the vaccine administered

2017 HL70533 P Conflicting Vaccine and Site Data

Indicates that the administration site is inconsistent with the vaccine administered

2100 HL70533 P Future DateIndicates that any date field is in the future. Specific errors for date transmitted in an OBX are also provided.

2101 HL70533 P Future Contraindication Effective Date

Indicates that a contraindication effective date messaged in OBX-5 is in the future

2102 HL70533 P Future VIS Given Date Indicates that a VIS given date messaged in OBX-5 is in the future

2103 HL70533 P Future VIS Publication Date Indicates that a VIS publication date messaged in OBX-5 is in the future

2104 HL70533 P Historical Dose Given on Submission Date

Indicates that a historical dose is being reported for the current date.

2200 HL70533 P Invalid Coding System Indicates that an unknown coding system was received in a coded field

2201 HL70533 P Invalid Name (Baby)Indicates that a patient name was received that indicates that a temporary baby name was messaged.

2202 HL70533 P Invalid Address

Indicates individual components of the address are valid, but overall, the address is invalid (conflict between elements, non-existent address, etc)

2203 HL70533 P Invalid Telecommunication Indicates individual components of the phone



Numbernumber or email are valid, but overall, the number or email address is invalid (conflict between elements, non-existent number etc)

2204 HL70533 P Vaccination Date Too Long Ago

Indicates that the administration being reported occurred too far in the past.

2205 HL70533 P Unknown Profile ID Indicates that an unrecognized or unsupported profile identifier is being used.

2206 HL70533 P Invalid Comment

Indicates that an invalid comment was received. Comments should be clinically relevant and should not include data that can be sent discretely elsewhere in the message.

2207 HL70533 P Invalid Value SetIndicates that for a particular observation ID (OBX-3), an invalid value set was used in OBX-5

2208 HL70533 P Invalid Assigning Authority Indicates that an invalid assigning authority was received

2209 HL70533 P Invalid ID Type Indicates tthat an invalid ID type was received

2210 HL70533 P Invalid Observation Method Indicates that the observation method for patient eligibility is invalid

2300 HL70533 P No Matching Dose Found Indicates that no matching doses were found using the data in the message.

2301 HL70533 P No Matching Provider Found Indicates that no matching providers were found using the data in the message.

2302 HL70533 P Multiple Matching Doses Found

Indicates that multiple matching doses were found using the data in the message.

2303 HL70533 P Multiple Matching Patients Found

Indicates that multiple matching patients were found using the data in the message.

2304 HL70533 P Multiple Matching Providers Found

Indicates that multiple matching providers were found using the data in the message.

2305 HL70533 P Patient Out of Jurisdiction Indicates that the patient found is is not in the jurisdiction.

2306 HL70533 P Patient Too Old Indicates that the patient found is too old.

2307 HL70533 P Lot Not Found Indicates that the lot number messaged in RXA-15 couldn't be linked to a lot.

2308 HL70533 P Action Code MismatchIndicates that an add message was received for existing dose or update message was received for a new dose.

2309 HL70533 PNo matching patient found, new patient record was created

Indicates that no matching patient was found using the data in the message but that the receiving system created a new patient record.

2310 HL70533 P No matching patient found, establish patient record first

Indicates that no matching patient was found using the data in the message. Action must be taken to establish a patient record before immunization data can be submitted (e.g., the patient must consent to be in the registry).

2400 HL70533 P Eligibility in PV1 Indicates that eligibility data was messaged in


Value Code System Usage Description Commentthe PV1 segment rather than in an OBX segment.

2401 HL70533 P Unsupported Field PopulatedIndicates that data was sent in an unsupported field. While OK to raise an error, this probably should not prevent processing of the message.

2500 HL70533 P Missing Eligibility Information Indicates that the patient eligibility status was not messaged.

2501 HL70533 P Missing Funding Source Information

Indicates that the funding source of the vaccine administered was not messaged.

2502 HL70533 PMissing Parent/Guardian/Responsible Person

Indicates that the patient parent/guardian/responsible person was not messaged.

2503 HL70533 P Missing VIS Barcode Indicates that the barcoded ID of the VIS was not messaged.

2504 HL70533 P Missing VIS Given Date Indicates that the VIS given date was not messaged.

2505 HL70533 P Missing VIS Information Indicates that the ID of the VIS was not messaged.

2506 HL70533 P Missing VIS Publication Date Indicates that the VIS publication date was not messaged.

2600 HL70533 P Data truncated Indicates that during the process of the message data was truncated.

2601 HL70533 P Inventory Management Error Indicates an application level error when executing inventory management functionality.

2602 HL70533 P Interface Cannot Delete Record

Indicates that the record indicated by the message cannot be deleted via an HL7 message, typically due to a an issue of local policy (eg. lack of authorization).

2603 HL70533 P Interface Cannot Update Record

Indicates that the record indicated by the message cannot be updated via an HL7 message, typically due to a an issue of local policy (eg. lack of authorization).

2700 HL70533 P Protected Patient Found Indicates that the patient found has requested protection of their data.

2701 HL70533 P Potentially Protected Patient Found

Indicates that the patient found has an unknown status regarding the protection of their data.

2800 HL70533 P System Doesn't Support Receipt of Deletion Evenss

Indicates that the system receiving the message does not support the ability to electronically delete vaccination events.

2801 HL70533 P System Doesn't Support Receipt of Refusal Events

Indicates that the system receiving the message does not support the receipt or storage of vaccine refusal information.

2802 HL70533 PSystem Doesn't Support Receipt of Contraindication Events

Indicates that the system receiving the message does not support the receipt or storage of vaccine contraindication information.

2803 HL70533 P System Doesn't Support Indicates that the system receiving the



Receipt of Partial Administration Events

message does not support the receipt or storage of vaccine partial administration information.

2804 HL70533 P

System Doesn't Support Receipt of Immunity Data

Indicates that the system receiving the message does not support the receipt or storage of patient immunity (history of disease or serological evidence of disease) information.

2805HL70533 P System Doesn't Support

Receipt of Adverse Event Data

Indicates that the system receiving the message does not support the receipt or storage of patient adverse event information.

2806 HL70533 P Unsupported Vaccine Code Received

Indicates that a valid, but unsupported vaccine code was received. For example, RXA-5 contained a valid code for an Immune Globulin, but the receiving system does not support the submission of IG administrations.

3.3.38 CDCREC_01 - RACE

Metadata OID: 2.16.840.1.114222.4.11.836


CodesValue Code System Usage Description1002-5 CDCREC R American Indian or Alaska Native2028-9 CDCREC R Asian2054-5 CDCREC R Black or African American2076-8 CDCREC R Native Hawaiian or Other Pacific Islander2106-3 CDCREC R White2131-1 CDCREC R Other Race

3.3.39 CDCREC_02 - ETHNICITY

Metadata OID: 2.16.840.1.114222.4.11.837


CodesValue Code System Usage Description2135-2 CDCREC R Hispanic or Latino


Value Code System Usage Description2186-5 CDCREC R Not Hispanic or Latino

3.3.40 CVX_01 - VACCINES ADMINISTERED (CVX)

This set of CVX codes is intended to include all codes necessary for documenting new and historical doses administered of vaccines and other products such as immune globulins. The CDC maintained code set is available at https://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=cvx. Additional comments on some CVX codes are available at that site.

Conformant systems are expected to support new CVX codes as they added, thus the value set has been given a stability of Dynamic.


CodesValue Code System Usage Description Comment01 CVX R DTP02 CVX R OPV03 CVX R MMR04 CVX R M/R05 CVX R measles06 CVX R rubella07 CVX R mumps08 CVX R Hep B, adolescent or pediatric09 CVX R Td (adult), adsorbed10 CVX R IPV11 CVX R pertussis12 CVX R diphtheria antitoxin13 CVX R TIG14 CVX R IG, unspecified formulation15 CVX R influenza, split (incl. purified surface antigen)16 CVX R influenza, whole17 CVX R Hib, unspecified formulation18 CVX R rabies, intramuscular injection19 CVX R BCG20 CVX R DTaP21 CVX R varicella22 CVX R DTP-Hib23 CVX R plague


Value Code System Usage Description Comment24 CVX R anthrax25 CVX R typhoid, oral26 CVX R cholera, unspecified formulation27 CVX P botulinum antitoxin28 CVX R DT (pediatric)29 CVX R CMVIG30 CVX R HBIG31 CVX R Hep A, pediatric, unspecified formulation32 CVX R meningococcal MPSV433 CVX R pneumococcal polysaccharide PPV2334 CVX R RIG35 CVX P tetanus toxoid, adsorbed36 CVX R VZIG37 CVX R yellow fever38 CVX R rubella/mumps39 CVX R Japanese encephalitis SC40 CVX R rabies, intradermal injection41 CVX R typhoid, parenteral42 CVX R Hep B, adolescent/high risk infant43 CVX R Hep B, adult44 CVX R Hep B, dialysis45 CVX R Hep B, unspecified formulation46 CVX R Hib (PRP-D)47 CVX R Hib (HbOC)48 CVX R Hib (PRP-T)49 CVX R Hib (PRP-OMP)50 CVX R DTaP-Hib51 CVX R Hib-Hep B52 CVX R Hep A, adult53 CVX R typhoid, parenteral, AKD (U.S. military)54 CVX R adenovirus, type 455 CVX R adenovirus, type 756 CVX P dengue fever Never Active57 CVX P hantavirus Never Active58 CVX P Hep C Never Active59 CVX P Hep E Never Active60 CVX P herpes simplex 2 Never Active61 CVX P HIV Never Active


Value Code System Usage Description Comment62 CVX R HPV, quadrivalent63 CVX P Junin virus Never Active64 CVX P leishmaniasis Never Active65 CVX P leprosy Never Active66 CVX R Lyme disease67 CVX P malaria Never Active68 CVX P melanoma Never Active69 CVX R parainfluenza-370 CVX P Q fever Never Active71 CVX R RSV-IGIV72 CVX P rheumatic fever Never Active73 CVX P Rift Valley fever Never Active74 CVX R rotavirus, tetravalent75 CVX R vaccinia (smallpox)76 CVX R Staphylococcus bacterio lysate77 CVX R tick-borne encephalitis78 CVX R tularemia vaccine79 CVX P vaccinia immune globulin80 CVX R VEE, live81 CVX R VEE, inactivated82 CVX R adenovirus, unspecified formulation83 CVX R Hep A, ped/adol, 2 dose84 CVX R Hep A, ped/adol, 3 dose85 CVX R Hep A, unspecified formulation86 CVX R IG87 CVX R IGIV88 CVX R influenza, unspecified formulation89 CVX R polio, unspecified formulation90 CVX R rabies, unspecified formulation91 CVX R typhoid, unspecified formulation92 CVX R VEE, unspecified formulation93 CVX P RSV-MAb94 CVX R MMRV95 CVX E TST-OT tine test TB Skin test is not vaccine.96 CVX E TST-PPD intradermal TB Skin test is not vaccine.97 CVX E TST-PPD tine test TB Skin test is not vaccine.98 CVX E TST, unspecified formulation TB Skin test is not vaccine.99 CVX P RESERVED - do not use Code 99 will not be used in

this table to avoid confusion


Value Code System Usage Description Commentwith code 999.

100 CVX R pneumococcal conjugate PCV 7101 CVX R typhoid, ViCPs102 CVX R DTP-Hib-Hep B103 CVX R meningococcal C conjugate104 CVX R Hep A-Hep B105 CVX R vaccinia (smallpox) diluted106 CVX R DTaP, 5 pertussis antigens107 CVX R DTaP, unspecified formulation

108 CVX R meningococcal ACWY, unspecified formulation

109 CVX R pneumococcal, unspecified formulation110 CVX R DTaP-Hep B-IPV111 CVX R influenza, live, intranasal112 CVX R tetanus toxoid, unspecified formulation113 CVX R Td (adult) preservative free114 CVX R meningococcal MCV4P115 CVX R Tdap116 CVX R rotavirus, pentavalent117 CVX R VZIG (IND)118 CVX R HPV, bivalent119 CVX R rotavirus, monovalent120 CVX R DTaP-Hib-IPV121 CVX R zoster live122 CVX R rotavirus, unspecified formulation123 CVX R influenza, H5N1-1203125 CVX R Novel Influenza-H1N1-09, nasal126 CVX R Novel influenza-H1N1-09, preservative-free127 CVX R Novel influenza-H1N1-09128 CVX R Novel Influenza-H1N1-09, all formulations

129 CVX R Japanese Encephalitis, unspecified formulation

130 CVX R DTaP-IPV131 CVX R typhus, historical132 CVX R DTaP-IPV-HIB-HEP B, historical133 CVX R Pneumococcal conjugate PCV 13134 CVX R Japanese Encephalitis IM135 CVX R Influenza, high dose seasonal


Value Code System Usage Description Comment136 CVX R Meningococcal MCV4O137 CVX R HPV, unspecified formulation138 CVX R Td (adult)139 CVX R Td(adult) unspecified formulation

140 CVX R Influenza, seasonal, injectable, preservative free

141 CVX R Influenza, seasonal, injectable142 CVX R tetanus toxoid, not adsorbed143 CVX R Adenovirus types 4 and 7

144 CVX R influenza, seasonal, intradermal, preservative free

145 CVX P RSV-MAb (new)146 CVX R DTaP,IPV,Hib,HepB

147 CVX R meningococcal MCV4, unspecified formulation

148 CVX R Meningococcal C/Y-HIB PRP149 CVX R influenza, live, intranasal, quadrivalent

150 CVX R influenza, injectable, quadrivalent, preservative free

151 CVX R influenza nasal, unspecified formulation

152 CVX R Pneumococcal Conjugate, unspecified formulation

153 CVX R Influenza, injectable, MDCK, preservative free154 CVX R Hep A, IG

155 CVX R influenza, recombinant, injectable, preservative free

156 CVX R Rho(D)-IG157 CVX R Rho(D) -IG IM158 CVX R influenza, injectable, quadrivalent159 CVX P Rho(D) - Unspecified formulation

160 CVX R Influenza A monovalent (H5N1), ADJUVANTED-2013

161 CVX R Influenza, injectable,quadrivalent, preservative free, pediatric

162 CVX R meningococcal B, recombinant163 CVX R meningococcal B, OMV164 CVX R meningococcal B, unspecified165 CVX R HPV9

166 CVX R influenza, intradermal, quadrivalent, preservative free


Value Code System Usage Description Comment167 CVX R meningococcal, unknown serogroups168 CVX R influenza, trivalent, adjuvanted169 CVX R Hep A, live attenuated170 CVX R DTAP/IPV/HIB - non-US

171 CVX R Influenza, injectable, MDCK, preservative free, quadrivalent

172 CVX R cholera, WC-rBS173 CVX R cholera, BivWC174 CVX R cholera, live attenuated175 CVX R Rabies - IM Diploid cell culture176 CVX R Rabies - IM fibroblast culture177 CVX R PCV10178 CVX R OPV bivalent179 CVX R OPV, monovalent, unspecified180 CVX R tetanus immune globulin181 CVX R anthrax immune globulin182 CVX R OPV, Unspecified183 CVX R Yellow fever vaccine - alt184 CVX R Yellow fever, unspecified formulation

185 CVX R influenza, recombinant, quadrivalent,injectable, preservative free

186 CVX R Influenza, injectable, MDCK, quadrivalent, preservative

187 CVX R zoster recombinant188 CVX R zoster, unspecified formulation189 CVX R Hep B, CpG adjuvanted801 CVX P AS03 Adjuvant

998 CVX R no vaccine administered

Code 998 was added for use in VXU HL7 messages where the OBX segment is nested with the RXA segment, but the message does not contain information about a vaccine administration. An example of this use is to report the vaccines due next for a patient when no vaccine administration is being reported.

999 CVX P unknown This CVX code has little utility and should rarely be used.


3.3.41 CVX_02 - VIS VACCINE TYPES (CVX)

This set of CVX codes represent the Vaccine Information Statements (VIS) as documented at https://www.cdc.gov/vaccines/programs/iis/code-sets/vis-url-table.html. Where an unspecified formulation CVX code is available, it has been used here.

The recommended method for transmitting VIS data is to use the fully encoded bar code ID rather than the CVX based vaccine type, but if the vaccine type (along with the publication date) is used, this is the appropriate set of CVX codes to use.

Note that a CVX code does not exist for the Multi Pediatric Vaccines VIS ( http://www.cdc.gov/vaccines/hcp/vis/vis-statements/multi.html).

Conformant systems are expected to support new CVX codes and VIS as they added, thus the value set has been given a stability of Dynamic.


Codes


03 CVX R MMR https://www.cdc.gov/vaccines/hcp/vis/vis-statements/mmr.html10 CVX R IPV https://www.cdc.gov/vaccines/hcp/vis/vis-statements/ipv.html

17 CVX R Hib, unspecified formulation https://www.cdc.gov/vaccines/hcp/vis/vis-statements/hib.html

21 CVX R varicella https://www.cdc.gov/vaccines/hcp/vis/vis-statements/varicella.html24 CVX R anthrax https://www.cdc.gov/vaccines/hcp/vis/vis-statements/anthrax.html

33 CVX Rpneumococcal polysaccharide PPV23

https://www.cdc.gov/vaccines/hcp/vis/vis-statements/ppv.html

45 CVX RHep B, unspecified formulation

https://www.cdc.gov/vaccines/hcp/vis/vis-statements/hep-b.html

82 CVX Radenovirus, unspecified formulation

https://www.cdc.gov/vaccines/hcp/vis/vis-statements/adenovirus.html

85 CVX RHep A, unspecified formulation

https://www.cdc.gov/vaccines/hcp/vis/vis-statements/hep-a.html

88 CVX Rinfluenza, unspecified formulation

https://www.cdc.gov/vaccines/hcp/vis/vis-statements/flu.html

90 CVX Rrabies, unspecified formulation

https://www.cdc.gov/vaccines/hcp/vis/vis-statements/rabies.html

91 CVX R typhoid, https://www.cdc.gov/vaccines/hcp/vis/vis-statements/typhoid.html



unspecified formulation

94 CVX R MMRV https://www.cdc.gov/vaccines/hcp/vis/vis-statements/mmrv.html

107 CVX RDTaP, unspecified formulation

https://www.cdc.gov/vaccines/hcp/vis/vis-statements/dtap.html

108 CVX R

meningococcal ACWY, unspecified formulation

https://www.cdc.gov/vaccines/hcp/vis/vis-statements/mening.html

115 CVX R Tdap https://www.cdc.gov/vaccines/hcp/vis/vis-statements/tdap.html

121 CVX R zoster vaccine, live (ZVL) https://www.cdc.gov/vaccines/hcp/vis/vis-statements/shingles.html

122 CVX Rrotavirus, unspecified formulation

https://www.cdc.gov/vaccines/hcp/vis/vis-statements/rotavirus.html

129 CVX R

Japanese Encephalitis, unspecified formulation

https://www.cdc.gov/vaccines/hcp/vis/vis-statements/je-ixiaro.html

137 CVX R HPV, unspecified formulation https://www.cdc.gov/vaccines/hcp/vis/vis-statements/hpv.html

139 CVX RTd(adult) unspecified formulation

https://www.cdc.gov/vaccines/hcp/vis/vis-statements/td.html

151 CVX Rinfluenza nasal, unspecified formulation

https://www.cdc.gov/vaccines/hcp/vis/vis-statements/flulive.html

152 CVX R

Pneumococcal Conjugate, unspecified formulation

https://www.cdc.gov/vaccines/hcp/vis/vis-statements/pcv13.html

164 CVX R meningococcal B, unspecified

https://www.cdc.gov/vaccines/hcp/vis/vis-statements/mening-serogroup.html

174 CVX R cholera, live attenuated https://www.cdc.gov/vaccines/hcp/vis/vis-statements/cholera.html

184 CVX RYellow fever, unspecified formulation

https://www.cdc.gov/vaccines/hcp/vis/vis-statements/yf.html

187 CVX Rzoster recombinant (RZV)

https://www.cdc.gov/vaccines/hcp/vis/vis-statements/shingles-recombinant.html

3.3.42 CVX_03 - EVALUATION AND FORECAST TYPES (CVX)

This set of CVX codes represent the antigens which may be evaluated or forecasted.


Conformant systems are expected to support new CVX codes and vaccine types as they added, thus the value set has been given a stability of Dynamic.


CodesValue Code System Usage Description03 CVX R MMR10 CVX R IPV17 CVX R Hib, unspecified formulation21 CVX R varicella24 CVX P anthrax26 CVX P cholera, unspecified formulation33 CVX R pneumococcal polysaccharide PPV2345 CVX R Hep B, unspecified formulation82 CVX P adenovirus, unspecified formulation85 CVX R Hep A, unspecified formulation88 CVX R influenza, unspecified formulation90 CVX P rabies, unspecified formulation91 CVX P typhoid, unspecified formulation94 CVX R MMRV107 CVX R DTaP, unspecified formulation108 CVX R meningococcal ACWY, unspecified formulation109 CVX R pneumococcal, unspecified formulation115 CVX R Tdap122 CVX R rotavirus, unspecified formulation129 CVX P Japanese Encephalitis, unspecified formulation137 CVX R HPV, unspecified formulation139 CVX R Td(adult) unspecified formulation152 CVX R Pneumococcal Conjugate, unspecified formulation164 CVX R meningococcal B, unspecified184 CVX P Yellow fever, unspecified formulation188 CVX R zoster, unspecified formulation

3.3.43 MVX_01 - MANUFACTURER

Metadata OID: 2.16.840.1.114222.4.11.826



CodesValue Code System Usage Description CommentAB MVX R Abbott Laboratories includes Ross Products Division, SolvayACA MVX R Acambis, Inc acquired by Sanofi in Sept 2008AD MVX R Adams Laboratories, Inc.AKR MVX R Akorn, IncALP MVX R Alpha Therapeutic CorporationAR MVX R Armour part of CSLAVB MVX R Aventis Behring L.L.C. part of CSLAVI MVX R Aviron acquired by MedimmuneBA MVX R Baxter Healthcare Corporation

BAH MVX R Baxter Healthcare Corporation

includes Hyland Immuno, Immuno International AG,and North American Vaccine, Inc./acquired some assets from alpha therapeutics

BAY MVX R Bayer Corporation Bayer Biologicals now owned by TalecrisBP MVX R Berna Products

BPC MVX R Berna Products Corporation includes Swiss Serum and Vaccine Institute Berne

BRR MVX R Barr Laboratories Subsidiary of Teva Pharmaceuticals

BTP MVX R Biotest Pharmaceuticals Corporation

New owner of NABI HB as of December 2007, Does NOT replace NABI Biopharmaceuticals in this code list.

CEN MVX R Centeon L.L.C.CHI MVX R Chiron Corporation Part of Novartis

CMP MVX R Celltech Medeva Pharmaceuticals Part of Novartis

CNJ MVX R Cangene Corporation Purchased by Emergent BiosolutionsCON MVX R Connaught acquired by MerieuxCRU MVX R Crucell acquired Berna, now a J & J companyCSL MVX R bioCSL CSL Biotherapies renamed to bioCSLDVC MVX R DynPort Vaccine Company, LLCEVN MVX R Evans Medical Limited Part of NovartisGEO MVX R GeoVax Labs, Inc.GRE MVX R Greer Laboratories, Inc.GRF MVX R GrifolsIAG MVX R Immuno International AG Part of BaxterIDB MVX R ID BiomedicalIM MVX R Merieux Part of SanofiINT MVX R Intercell Biomedical subsidiary of ValnevaIUS MVX R Immuno-U.S., Inc.JNJ MVX R Johnson and Johnson acquired CRUCELL which acquired


Value Code System Usage Description CommentBerna

JPN MVX RThe Research Foundation for Microbial Diseases of Osaka University (BIKEN)

KED MVX R Kedrion Biopharma acquired Rho(D) from OrthoKGC MVX R Korea Green Cross Corporation

LED MVX R Lederle became a part of WAL, now owned by Pfizer

MA MVX R Massachusetts Public Health Biologic Laboratories

MBL MVX R Massachusetts Biologic Laboratories

formerly Massachusetts Public Health Biologic Laboratories

MCM MVX R MCM Vaccine Company Partnership between Merck and Sanofi Pasteur

MED MVX R MedImmune, Inc.

acquisitions of U.S. Bioscience in 1999 and Aviron in 2002, as well as the integration with Cambridge Antibody Technology and the strategic alignment with our new parent company, AstraZeneca, in 2007.

MIL MVX R Miles

MIP MVX R Emergent BioDefense Operations Lansing

A unit of Emergent BioSolutions, Bioport renamed. Formerly Michigan Biologic Products Institute

MSD MVX R Merck and Co., Inc.NAB MVX R NABI formerly North American Biologicals, Inc.NAV MVX R North American Vaccine, Inc. part of Baxter

NOV MVX R Novartis Pharmaceutical Corporation

Novartis has sold its flu vaccines to Seqirus and other vaccines to GlaxoSmithKline. While Novartis vaccines may still be in circulation, its status is set to not active.

NVX MVX R Novavax, Inc.NYB MVX R New York Blood Center

ORT MVX R Ortho-clinical Diagnostics a J & J company (formerly Ortho Diagnostic Systems, Inc.)

OTC MVX R Organon Teknika CorporationOTH MVX R Other manufacturerPAX MVX R PaxVax

PD MVX R Parkedale Pharmaceuticals no website and no news articles (formerly Parke-Davis)

PFR MVX R Pfizer, Incincludes Wyeth-Lederle Vaccines and Pediatrics, Wyeth Laboratories, Lederle Laboratories, and Praxis Biologics,



PMC MVX R Sanofi Pasteur

formerly Aventis Pasteur, Pasteur Merieux Connaught; includes Connaught Laboratories and Pasteur Merieux. Acquired ACAMBIS.

PRX MVX R Praxis Biologics became a part of WAL, now owned by Pfizer

PSC MVX R Protein SciencesPWJ MVX R PowderJect Pharmaceuticals See NovartisSCL MVX R Sclavo, Inc.

SEQ MVX R SeqirusSeqirus acquired the flu vaccines from Novartis. It also includes the CSL vaccines.

SI MVX R Swiss Serum and Vaccine Inst. Part of Berna

SKB MVX R GlaxoSmithKline includes SmithKline Beecham and Glaxo Wellcome

SOL MVX R Solvay Pharmaceuticals Part of AbbottTAL MVX R Talecris Biotherapeutics includes Bayer BiologicalsUNK MVX R Unknown manufacturer

USA MVX RUnited States Army Medical Research and Material Command

VAL MVX R Valneva Distributes through Intercell in the US

VXG MVX R VaxGen acquired by Emergent Biodefense Operations Lansing, Inc

WA MVX R Wyeth-Ayerst became WAL, now owned by PfizerWAL MVX R Wyeth acquired by Pfizer 10/15/2009ZLB MVX R ZLB Behring acquired by CSL

3.3.44 NCIT_01 - ROUTE OF ADMINISTRATION

Metadata OID: 2.16.840.1.114222.4.11.3369


CodesValue Code System Usage DescriptionC28161 NCIT R IntramuscularC38238 NCIT R IntradermalC38276 NCIT P IntravenousC38284 NCIT R NasalC38288 NCIT R Oral


Value Code System Usage DescriptionC38299 NCIT P SubcutaneousC38305 NCIT P TransdermalC38676 NCIT P Percutaneous

3.3.45 NIP001_01 - IMMUNIZATION INFORMATION SOURCE

Metadata OID: 2.16.840.1.113883.3.88.12.80.39



00 NIP001 R New immunization record

The dose was administered by the organization that is reporting this dose. Includes add messages for newly administered doses as well as update and delete messages for doses previously documented as new administrations by the sending system.

01 NIP001 R Historical information - source unspecified

The record of a vaccine dose from a reliable historical source, such as an immunization card.

02 NIP001 P Historical information - from other provider

The record of a vaccine dose from another health care provider’s historical records.

03 NIP001 PHistorical information - from parent's or patient's written record

The record of a vaccine dose from written records maintained by the parent/guardian or patient.

04 NIP001 P Historical information - from parent's or patient's recall

The record of a vaccine dose from the recall of the patient/guardian or patient. The reliability of this record is considered low.

05 NIP001 P Historical information - from other registry

The record of a vaccine dose from another Immunization Information System (IIS).

06 NIP001 P Historical information - from birth certificate

The record of a vaccine dose from a birth record.

07 NIP001 P Historical information - from school record

The record of a vaccine dose from a written school record.

08 NIP001 P Historical information - from public agency

The record of a vaccine dose from a written public health agency record.

3.3.46 NIP002_01 - SUBSTANCE REFUSAL REASON

Metadata OID: 2.16.840.1.113883.3.2074.1.1.4



CodesValue Code System Usage Description00 NIP002 R Parental decision01 NIP002 R Religious exemption02 NIP002 R Other03 NIP002 R Patient decision

3.3.47 NIP003_01 - OBSERVATION IDENTIFIER LIST FOR PATIENT OBSERVATIONS


CodesValue Code System Usage Description29769-7 LN E Date Vaccine Information Statement Presented30944-3 LN E Date of vaccination temporary contraindication/precaution expiration30945-0 LN E Vaccination contraindication/precaution30946-8 LN E Date vaccination contraindication/precaution effective30956-7 LN E Type [Identifier] Vaccine (Vaccine group or family)30963-3 LN E Vaccine funding source30973-2 LN E Dose number in series30979-9 LN E Vaccines due next30980-7 LN E Date vaccine due30981-5 LN E Earliest date to give30982-3 LN E Reason applied by forecast logic to project this vaccine31044-1 LN P Immunization reaction38890-0 LN E Vaccine component type [Identifier]48767-8 LN E Annotation comment59777-3 LN E Latest date next dose may be given59778-1 LN E Date when overdue for immunization59779-9 LN E Immunization schedule used59780-7 LN E Immunization series name59781-5 LN E Dose validity59782-3 LN E Number of doses in primary immunization series59783-1 LN E Status in immunization series59784-9 LN P Disease with presumed immunity59785-6 LN E Indication for immunization64994-7 LN E Vaccine funding program eligibility category69764-9 LN E Document type


Value Code System Usage Description75323-6 LN P Condition75505-8 LN P Disease with serological evidence of immunity85585-8 LN P Date of condition onset88877-6 LN E Date of vaccination indication effective88878-4 LN P Date of condition abatement88879-2 LN E Date of vaccination indication expiration

3.3.48 NIP003_02 - OBSERVATION IDENTIFIER LIST FOR THE IZ22 PROFILE


CodesValue Code System Usage Description29769-7 LN R Date Vaccine Information Statement Presented30944-3 LN P Date of vaccination temporary contraindication/precaution expiration30945-0 LN P Vaccination contraindication/precaution30946-8 LN P Date vaccination contraindication/precaution effective30956-7 LN P Type [Identifier] Vaccine (Vaccine group or family)30963-3 LN R Vaccine funding source30979-9 LN E Vaccines due next30980-7 LN E Date vaccine due30981-5 LN E Earliest date to give30982-3 LN E Reason applied by forecast logic to project this vaccine31044-1 LN P Immunization reaction38890-0 LN E Vaccine component type [Identifier]48767-8 LN P Annotation comment59777-3 LN E Latest date next dose may be given59778-1 LN E Date when overdue for immunization59781-5 LN E Dose validity59783-1 LN E Status in immunization series59784-9 LN E Disease with presumed immunity59785-6 LN P Indication for immunization64994-7 LN R Vaccine funding program eligibility category69764-9 LN R Document type75323-6 LN E Condition75505-8 LN E Disease with serological evidence of immunity85585-8 LN E Date of condition onset88877-6 LN P Date vaccination indication effective88878-4 LN E Date of condition abatement88879-2 LN P Date of vaccination indication expiration


3.3.49 NIP003_03 - OBSERVATION IDENTIFIER LIST FOR THE IZ52 PROFILE


CodesValue Code System Usage Description29769-7 LN P Date Vaccine Information Statement Presented30944-3 LN P Date of vaccination temporary contraindication/precaution expiration30945-0 LN P Vaccination contraindication/precaution30946-8 LN P Date vaccination contraindication/precaution effective30956-7 LN R Type [Identifier] Vaccine (Vaccine group or family)30963-3 LN P Vaccine funding source30973-2 LN P Dose number in series30979-9 LN E Vaccines due next30980-7 LN R Date vaccine due30981-5 LN R Earliest date to give30982-3 LN R Reason applied by forecast logic to project this vaccine31044-1 LN P Immunization reaction38890-0 LN E Vaccine component type [Identifier]48767-8 LN P Annotation comment59777-3 LN P Latest date next dose may be given59778-1 LN P Date when overdue for immunization59779-9 LN P Immunization schedule used59780-7 LN P Immunization series name59781-5 LN R Dose validity59782-3 LN P Number of doses in primary immunization series59783-1 LN R Status in immunization series59784-9 LN E Disease with presumed immunity59785-6 LN P Indication for immunization64994-7 LN P Vaccine funding program eligibility category69764-9 LN P Document type75323-6 LN E Condition75505-8 LN E Disease with serological evidence of immunity85585-8 LN E Date of condition onset88877-6 LN P Date of vaccination indication effective88878-4 LN E Date of condition abatement88879-2 LN P Date of vaccination indication expiration

3.3.50 PATIENTCONDITION - GENERAL CONDITIONS FOR A PATIENT

Patient conditions are things known about the patient which may impact forecasting of future doses. Conditions may relate to medical conditions, medications being taken, allergies, environmental conditions, occupation, behavioral choices and a variety of other concepts. In the context of a specific recommendation, a condition


may be an indication or a contraindication. Furthermore, the same condition may be an indication for one vaccine but a contraindication for another. For example, the condition of "patient currently pregnant" is an indication for pertussis containing vaccine but a contraindication for the MMR vaccine. Currently, there is no authoritative list of patient conditions that IIS accept, store and use. The values provided in this value set exist as examples of the sort of conditions that trading partners may agree to exchange.


CodesValue Code System Usage Description77176002 SNOMED P Smoker77386006 SNOMED P Patient currently pregnant223366009 SNOMED P Healthcare professional294468006 SNOMED P Neomycin allergy328383001 SNOMED P Chronic Liver Disease370388006 SNOMED P Patient Immunocompromised

3.3.51 PHVS_EVALUATIONSTATUSREASON_IIS - REASON FOR THE ASSIGNED DOSE VALIDITY




VXC31 CDCPHINVS P Invalid Interval Vaccine Dose Administered was administered too soon following a previous dose

VXC32 CDCPHINVS P Invalid Product Vaccine Dose Administered was not an acceptable vaccine type (e.g. product)

VXC33 CDCPHINVS P Expired Vaccine Vaccine Dose Administered was administered after the Lot Number Expiration Date

VXC34 CDCPHINVS P Sub-potent VaccineVaccine Dose Administered was deemed to be ineffective or sub-potent. (e.g. recalled, cold-chain break, partially administered).

VXC35 CDCPHINVS P Too Young Vaccine Dose Administered was administered at too young of an age.

VXC36 CDCPHINVS P Too Old Vaccine Dose Administered was administered at too old of an age

VXC37 CDCPHINVS P Vaccine Conflict Vaccine Dose Administered was administered too close to another vaccine (e.g. live virus conflict)

VXC38 CDCPHINVS P Invalid Amount Vaccine Dose Administered amount was less than the recommended amount


3.3.52 PHVS_HISTORYOFDISEASE_IIS - HISTORY OF DISEASE

Note that a history of a disease for a patient does not typically indicate that the patient is fully protected. Whether or not a patient is "immune" depends on the rules and recommendations a system has implemented. Having a history of a disease may not change the schedule of future doses for the patient. The history of disease is simply meant to be an observation about the patient's medical history, how this observation affects the evaluation of the patient history and forecast will be determined by the clinical decision support rules in place.

Metadata OID: 2.16.840.1.114222.4.11.7244



4740000 SCT R Herpes zoster (disorder) History of herpes zoster infection.

4834000 SCT P Typhoid fever (disorder) History of typhoid infection.6142004 SCT P Influenza (disorder) History of influenza infection.14168008 SCT P Rabies (disorder) History of rabies infection.14189004 SCT P Measles (disorder) History of measles infection.

16541001 SCT P Yellow fever (disorder) History of yellow fever infection.

16814004 SCT P Pneumococcal infectious disease (disorder)

History of pneumococcal infection.

18624000 SCT P Disease due to Rotavirus (disorder) History of rotavirus infection.

23511006 SCT P Meningococcal infectious disease (disorder)

History of meningococcal infection.

27836007 SCT P Pertussis (disorder) History of pertussis infection.36653000 SCT P Rubella (disorder) History of rubella infection.36989005 SCT P Mumps (disorder) History of mumps infection.38907003 SCT R Varicella (disorder) History of Varicella infection.40468003 SCT P Viral hepatitis, type A (disorder) History of Hepatitis A infection.50711007 SCT P Viral hepatitis type C (disorder) History of Hepatitis C infection.

52947006 SCT P Japanese encephalitis virus disease (disorder)

History of Japanese encephalitis infection.

63650001 SCT P Cholera (disorder) History of cholera infection.66071002 SCT P Type B viral hepatitis (disorder) History of Hepatitis B infection.76902006 SCT P Tetanus (disorder) History of tetanus infection.

91428005 SCT P Haemophilus influenzae infection (disorder) History of Hib infection.


Value Code System Usage Description Comment111852003 SCT P Vaccinia (disorder) History of vaccinia infection.

240532009 SCT P Human papilloma virus infection (disorder) History of HPV infection.

397428000 SCT P Diphtheria (disorder) History of diphtheria infection.398102009 SCT P Acute poliomyelitis (disorder) History of polio infection.409498004 SCT P Anthrax (disorder) History of anthrax infection.

Support for any code representing a history of disease evidence of immunity which negates the need for future vaccinations should be supported by conformant systems. At the time of publication of this document the recommendations of the Advisory Committee on Immunization Practices (ACIP) only specify a history of varicella or herpes zoster as sufficient to negate the need for future doses in the varicella series. For this reason, these two codes have a Usage of R while other values have a Usage of P. In the future, updated recommendations may alter the content of this value set.

3.3.53 PHVS_IMMUNIZATIONFUNDINGSOURCE_IIS - IMMUNIZATION FUNDING SOURCE

Metadata OID: 2.16.840.1.114222.4.11.3287


CodesValue Code System Usage Description CommentPHC70 CDCPHINVS R Private Vaccine stock used was privately fundedVXC50 CDCPHINVS R Public Vaccine stock used was publicly funded

VXC51 CDCPHINVS R Public VFC Vaccine stock used was publicly funded by the VFC program

VXC52 CDCPHINVS R Public non-VFC Vaccine stock used was publicly funded by a non-VFC program

3.3.54 PHVS_IMMUNIZATIONPROFILEID_IIS - IMMUNIZATION PROFILE IDENTIFIERS



CodesValue Code System Usage DescriptionIZ22r1.0 CDCPHINVS R Send Unsolicited Immunization UpdateIZ23r1.0 CDCPHINVS R Return an AcknowledgementIZ31r1.0 CDCPHINVS R Return a List of Candidates


Value Code System Usage DescriptionIZ33r1.0 CDCPHINVS R Return an Acknowledgement with no Person RecordsIZ52r1.0 CDCPHINVS R Return Immunization History with ForecastIZ54r1.0 CDCPHINVS R Request Immunization History with Forecast

3.3.55 PHVS_IMMUNIZATIONSCHEDULEIDENTIFIER_IIS - IMMUNIZATION SCHEDULE IDENTIFIERS




VXC16 CDCPHINVS P ACIP Schedule This indicates that the current ACIP Schedule of recommendations were used to forecast next doses due.

3.3.56 PHVS_SERIESSTATUS_IIS - STATUS OF A PATIENT WITHIN AN IMMUNIZATION SERIES



CodesValue Code System Usage Description CommentLA4695-8 LN R Not Recommended Patient is not recommended for additional doses.

LA27183-5 LN R Immune Patient has demonstrated immunity and is unlikely to gain further benefit from additional doses.

LA4216-3 LN R ContraindicatedPatient should not complete the series because of a condition which may increase the possibility of an adverse reaction.

LA13421-5 LN R Complete All required does have been received to meet the requirements for a particular vaccine group

LA13422-3 LN R On Schedule Patient Is not overdue for a given dose in the series. Includes a person too young to start the series

LA13423-1 LN R Overdue Patient is late getting the next dose in the series

LA13424-9 LN R Too Old Patient cannot complete the series because the latest age for receiving dose has passed

3.3.57 PHVS_SEROLOGICALEVIDENCEOFIMMUNITY_IIS - SEROLOGICAL EVIDENCE OF IMMUNITY

Metadata OID: 2.16.840.1.114222.4.11.7245



CodesValue Code System Usage Description Comment271511000 SCT R Hepatitis B (finding) Serology confirmed hepatitis B278968001 SCT R Rubella (finding) Serology confirmed rubella278971009 SCT R Hepatitis A (finding) Serology confirmed hepatitis A371111005 SCT R Measles (finding) Serology confirmed measles371112003 SCT R Mumps (finding) Serology confirmed mumps371113008 SCT R Varicella (finding) Serology confirmed varicella

Support for any code representing a serological evidence of immunity which negates the need for future vaccinations should be supported by conformant systems. The current set of values listed represent the recommendations of the Advisory Committee on Immunization Practices (ACIP) as of the time of publication of this document. In the future, updated recommendations may alter the content of this value set.

3.3.58 PHVS_VACCINATIONCONTRAINDICATION_IIS - VACCINE CONTRAINDICATIONS

Contraindications are things known about the patient which may prevent the forecasting of future doses typically recommended based the patient age, gender and indications. Contraindications may relate to medical conditions, medications being taken, allergies and a variety of other concepts. For example, the condition of "patient currently pregnant" is a contraindication for MMR vaccine. Currently, there is no authoritative list of contraindications that IIS or other clinical decision support systems accept, store and use. The values provided in this value set exist as examples of the sort of contraindications that trading partners may agree to exchange.

MetadataOID: 2.16.840.1.114222.4.11.3288


CodesValue Code System Usage Description Comment161461006 SCT P History of - purpura (situation) thrombocytopenic purpura

(history)

27624003 SCT P Chronic disease (disorder) chronic illness (e.g., chronic gastrointestinal disease)

294466005 SCT P Streptomycin allergy (disorder) allergy to streptomycin

(anaphylactic)294468006 SCT P Neomycin allergy (disorder) allergy to neomycin

(anaphylactic)294530006 SCT P Polymyxin B allergy (disorder) allergy (anaphylactic) to

polymycin B


Value Code System Usage Description Comment294847001 SCT P Gelatin allergy (disorder) allergy to gelatin (anaphylactic)

300916003 SCT P Latex allergy (disorder) allergy (anaphylactic) to latex

302215000 SCT P Thrombocytopenic disorder (disorder) thrombocytopenia

402306009 SCT P Allergy to aluminum (disorder) allergy (anaphylactic) to alum

77386006 SCT P Patient currently pregnant (finding) pregnancy (in recipient)

91930004 SCT P Allergy to eggs (disorder) Allergy to egg ingestion (anaphylactic)

VXC17 CDCPHINVS P Allergy (anaphylactic) to 2-phenoxyethanol

VXC18 CDCPHINVS P Allergy to baker's yeast (anaphylactic)

VXC19 CDCPHINVS P Allergy to thimerosal (anaphylactic) allergy to thimerosal (anaphylactic)

VXC20 CDCPHINVS PAllergy to previous dose of this vaccine or to any of its unlisted vaccine components (anaphylactic)

allergy to previous dose of this vaccine or to any of its unlisted vaccine components (anaphylactic)

VXC21 CDCPHINVS P Previous history of intussusception

VXC22 CDCPHINVS P Encephalopathy within 7 days of previous dose of DTP or DTaP

VXC23 CDCPHINVS P Current fever with moderate-to-severe illness

VXC24 CDCPHINVS PCurrent acute illness, moderate to severe (with or without fever) (e.g., diarrhea, otitis media, vomiting)

VXC25 CDCPHINVS PHistory of Arthus hypersensitivity reaction to a tetanus-containing vaccine administered < 10 yrs previously

VXC26 CDCPHINVS PUnderlying unstable, evolving neurologic disorders, (including seizure disorders, cerebral palsy, and developmental delay)

VXC27 CDCPHINVS P

Immunodeficiency due to any cause, including HIV (hematologic and solid tumors, congenital immunodeficiency, long-term immunosuppressive therapy, including steroids)

VXC30 CDCPHINVS P Allergy (anaphylactic) to proteins of rodent or neural origin

3.3.59 PHVS_VACCINATIONREACTION_IIS - VACCINATION REACTION

Metadata OID: 2.16.840.1.114222.4.11.3289



CodesValue Code System Usage Description

VXC9 CDCPHINVS P Persistent, inconsolable crying lasting > 3 hours within 48 hours of dose

VXC10 CDCPHINVS P Collapse or shock-like state within 48 hours of doseVXC11 CDCPHINVS P Convulsions (fits, seizures) within 72 hours of doseVXC12 CDCPHINVS P Fever of >40.5C (105F) within 48 hours of doseVXC13 CDCPHINVS P Guillain-Barre syndrome (GBS) within 6 weeks of doseVXC14 CDCPHINVS P Rash within 14 days of doseVXC15 CDCPHINVS P Intussusception within 30 days of dose39579001 SCT P Anaphylaxis (disorder)81308009 SCT P Disorder of brain (disorder)

3.3.60 PHVS_VACCINATIONSPECIALINDICATIONS_IIS - VACCINATION SPECIAL INDICATIONS

Special indications are things known about the patient which may result in the forecasting of future doses beyond the standard age based recommendations. Indications may relate to medical conditions, medications being taken, allergies, environmental conditions, occupation, behavioral choices and a variety of other concepts. For example, the condition of "patient currently pregnant" is an indication for pertussis containing vaccine. Currently, there is no authoritative list of indications that IIS or other clinical decision support systems accept, store and use. The values provided in this value set exist as examples of the sort of indications that trading partners may agree to exchange.

Metadata OID: 2.16.840.1.114222.4.11.3290


CodesValue Code System Usage DescriptionVXC7 CDCPHINVS P Rabies exposure within previous 10 days.VXC8 CDCPHINVS P Member of special group

3.3.61 PHVS_VISBARCODES_IIS - VIS FULLY-ENCODED TEXT STRING

Support for the most current VIS barcodes is required. As new VIS are published, conformant systems must support the updated fully encoded barcode strings.

Metadata OID: 2.16.840.1.114222.4.11.6041



Codes


253088698300001111110714 cdcgs1vis P Adenovirus VIS Edition Date: 7/14/2011253088698300001111140611 cdcgs1vis R Adenovirus VIS Edition Date: 6/11/2014253088698300002811180321 cdcgs1vis R Anthrax Vaccine VIS Edition Date: 3/21/2018253088698300002811100310 cdcgs1vis P Anthrax VIS Edition Date: 3/10/2010

253088698300003511070517 cdcgs1vis R Diphtheria/Tetanus/Pertussis (DTaP) VIS Edition Date: 5/17/2007

253088698300004211160720 cdcgs1vis R Hepatitis A Vaccine VIS Edition Date: 7/20/2016

253088698300004211111025 cdcgs1vis P Hepatitis A VIS Edition Date: 10/25/2011

253088698300005911160720 cdcgs1vis R Hepatitis B Vaccine VIS Edition Date: 7/20/2016253088698300005911120202 cdcgs1vis P Hepatitis B VIS Edition Date: 2/2/2012

253088698300006611981216 cdcgs1vis P Haemophilus Influenzae type b VIS

Edition Date: 12/16/1998

253088698300006611140204 cdcgs1vis P Haemophilus Influenzae type b VIS ( Edition Date: 2/4/2014

253088698300006611150402 cdcgs1vis R Haemophilus Influenzae type b VIS Edition Date: 4/2/2015

253088698300007311110503 cdcgs1vis R Human papillomavirus Vaccine (Cervarix) VIS Edition Date: 5/3/2011

253088698300008011120222 cdcgs1vis P Human papillomavirus Vaccine (Gardasil) VIS Edition Date: 2/22/2012

253088698300008011130517 cdcgs1vis R Human papillomavirus Vaccine (Gardasil) VIS Edition Date: 5/17/2013

253088698300009711120702 cdcgs1vis P Influenza Vaccine - Live, Intranasal VIS Edition Date: 7/2/2012



253088698300009711150807 cdcgs1vis R Influenza Vaccine - Live, Intranasal VIS Edition Date: 8/7/2015

253088698300010311120702 cdcgs1vis P Influenza Vaccine - Inactivated VIS Edition Date: 7/2/2012



253088698300010311150807 cdcgs1vis R Influenza Vaccine - Inactivated Edition Date: 8/7/2015



VIS253088698300011011111207 cdcgs1vis P Japanese Encephalitis VIS Edition Date: 12/7/2011253088698300011011140124 cdcgs1vis R Japanese Encephalitis VIS Edition Date: 1/24/2014253088698300012711180212 cdcgs1vis R MMR Vaccine VIS Edition Date: 2/12/2018253088698300012711120420 cdcgs1vis P Measles/Mumps/Rubella VIS Edition Date: 4/20/2012253088698300013411180212 cdcgs1vis R MMRV Vaccine VIS Edition Date: 2/12/2018

253088698300013411100521 cdcgs1vis P Measles/Mumps/Rubella/Varicella VIS Edition Date: 5/21/2010

253088698300014111160331 cdcgs1vis R Meningococcal ACWY Vaccines VIS Edition Date: 3/31/2016

253088698300014111111014 cdcgs1vis P Meningococcal VIS Edition Date: 10/14/2011

253088698300015811151105 cdcgs1vis R PCV13 Vaccine VIS Edition Date: 11/5/2015

253088698300015811100416 cdcgs1vis P Pneumococcal Conjugate (PCV13) VIS Edition Date: 4/16/2010

253088698300015811130227 cdcgs1vis P Pneumococcal Conjugate (PCV13) VIS Edition Date: 2/27/2013

253088698300016511091006 cdcgs1vis P Pneumococcal Polysaccharide VIS Edition Date: 10/6/2009

253088698300016511150424 cdcgs1vis R Pneumococcal Polysaccharide VIS Edition Date: 4/24/2015

253088698300017211160720 cdcgs1vis R Polio Vaccine VIS Edition Date: 7/20/2016253088698300017211111108 cdcgs1vis P Polio VIS Edition Date: 11/8/2011253088698300018911091006 cdcgs1vis R Rabies VIS Edition Date: 10/6/2009253088698300019611180223 cdcgs1vis R Rotavirus Vaccine VIS Edition Date: 2/23/2018253088698300019611101206 cdcgs1vis P Rotavirus VIS Edition Date: 12/6/2010253088698300019611130826 cdcgs1vis P Rotavirus VIS Edition Date: 8/26/2013253088698300019611150415 cdcgs1vis P Rotavirus VIS Edition Date: 4/15/2015253088698300020211180212 cdcgs1vis R Live Zoster Vaccine VIS Edition Date: 2/12/2018253088698300020211091006 cdcgs1vis R Shingles VIS Edition Date: 10/6/2009

253088698300022611120124 cdcgs1vis P Tetanus/Diphtheria/Pertussis (Tdap/Td) VIS Edition Date: 1/24/2012

253088698300023311120529 cdcgs1vis R Typhoid VIS Edition Date: 5/29/2012253088698300024011180212 cdcgs1vis R Varicella Vaccine VIS Edition Date: 2/12/2018253088698300024011080313 cdcgs1vis P Varicella (Chickenpox) VIS Edition Date: 3/13/2008253088698300025711110330 cdcgs1vis R Yellow Fever VIS Edition Date: 3/30/2011253088698300026411151105 cdcgs1vis R Multi Pediatric Vaccines VIS Edition Date: 11/5/2015

253088698300026411121116 cdcgs1vis P Multiple Vaccines VIS Edition Date: 11/16/2012

253088698300026411141022 cdcgs1vis P Multiple Vaccines VIS Edition Date: 10/22/2014

253088698300027111130509 cdcgs1vis P Tetanus/Diphtheria/Pertussis (Tdap) VIS Edition Date: 5/9/2013



253088698300027111150224 cdcgs1vis R Tetanus/Diphtheria/Pertussis (Tdap) VIS Edition Date: 2/24/2015

253088698300028811170411 cdcgs1vis R Tetanus/Diphtheria (Td) Vaccine VIS Edition Date: 4/11/2017

253088698300028811140204 cdcgs1vis P Tetanus/Diphtheria (Td) VIS Edition Date: 2/4/2014253088698300028811150224 cdcgs1vis P Tetanus/Diphtheria (Td) VIS Edition Date: 2/24/2015253088698300029511161202 cdcgs1vis R HPV Vaccine VIS Edition Date: 12/2/2016253088698300029511160331 cdcgs1vis P HPV Vaccine (Gardasil-9) VIS Edition Date: 3/31/2016

253088698300029511150415 cdcgs1vis P Human papillomavirus Vaccine, 9-valent (Gardasil 9) VIS Edition Date: 4/15/2015

253088698300030111150814 cdcgs1vis P Meningococcal B VIS Edition Date: 8/14/2015

253088698300030111160809 cdcgs1vis R Serogroup B Meningococcal Vaccine VIS Edition Date: 8/9/2016

253088698300031811170706 cdcgs1vis R Cholera Vaccine VIS Edition Date: 7/6/2017

3.3.62 PHVS_VISVACCINES_IIS - VIS VACCINES

Metadata OID: 2.16.840.1.114222.4.11.6040


CodesValue Code System Usage Description3 CVX R MMR8 CVX R Hep B, adolescent or pediatric9 CVX R Td (adult), adsorbed10 CVX R IPV18 CVX R rabies, intramuscular injection20 CVX R DTaP21 CVX R varicella24 CVX R anthrax25 CVX R typhoid, oral32 CVX R meningococcal MPSV433 CVX R pneumococcal polysaccharide PPV2335 CVX R tetanus toxoid, adsorbed37 CVX R yellow fever41 CVX R typhoid, parenteral42 CVX R Hep B, adolescent/high risk infant43 CVX R Hep B, adult44 CVX R Hep B, dialysis


Value Code System Usage Description48 CVX R Hib (PRP-T)49 CVX R Hib (PRP-OMP)51 CVX R Hib-Hep B52 CVX R Hep A, adult62 CVX R HPV, quadrivalent83 CVX R Hep A, ped/adol, 2 dose94 CVX R MMRV101 CVX R typhoid, ViCPs104 CVX R Hep A-Hep B106 CVX R DTaP, 5 pertussis antigens110 CVX R DTaP-Hep B-IPV111 CVX R influenza, live, intranasal113 CVX R Td (adult) preservative free114 CVX R meningococcal MCV4P115 CVX R Tdap116 CVX R rotavirus, pentavalent118 CVX R HPV, bivalent119 CVX R rotavirus, monovalent120 CVX R DTaP-Hib-IPV121 CVX R zoster130 CVX R DTaP-IPV133 CVX R Pneumococcal conjugate PCV 13134 CVX R Japanese Encephalitis IM135 CVX R Influenza, high dose seasonal136 CVX R Meningococcal MCV4O138 CVX R Td (adult)140 CVX R Influenza, seasonal, injectable, preservative free141 CVX R Influenza, seasonal, injectable142 CVX R tetanus toxoid, not adsorbed143 CVX R Adenovirus types 4 and 7144 CVX R influenza, seasonal, intradermal, preservative free146 CVX R DTaP,IPV,Hib,HepB148 CVX R Meningococcal C/Y-HIB PRP149 CVX R influenza, live, intranasal, quadrivalent150 CVX R influenza, injectable, quadrivalent, preservative free153 CVX R Influenza, injectable, MDCK, preservative free155 CVX R influenza, recombinant, injectable, preservative free158 CVX R influenza, injectable, quadrivalent161 CVX R Influenza, injectable, quadrivalent, preservative free, pediatric162 CVX R meningococcal B, recombinant163 CVX R meningococcal B vaccine, fully recombinant165 CVX R Human Papillomavirus 9-valent vaccine


Value Code System Usage Description166 CVX R influenza, intradermal, quadrivalent, preservative free168 CVX R influenza, trivalent, adjuvanted171 CVX R Influenza, injectable, MDCK, preservative free, quadrivalent174 CVX R cholera, live attenuated175 CVX R Rabies - IM Diploid cell culture176 CVX R Rabies - IM fibroblast culture183 CVX R Yellow fever vaccine - alt185 CVX R influenza, recombinant, quadrivalent,injectable, preservative free186 CVX R Influenza, injectable, MDCK, quadrivalent, preservative187 CVX R zoster recombinant

3.3.63 UCUM_01 - UNITS


CodesValue Code System Usage DescriptionNA HL70353 P Not ApplicablemL UCUM R milliliter

3.3.64 USPS_STATE - 2 CHARACTER STATE CODES AS PER THE USPS


CodesValue Code System Usage DescriptionAL USPS R AlabamaAK USPS R AlaskaAZ USPS R ArizonaAR USPS R ArkansasCA USPS R CaliforniaCO USPS R ColoradoCT USPS R ConnecticutDE USPS R DelawareDC USPS R District of ColumbiaFL USPS R FloridaGA USPS R GeorgiaHI USPS R HawaiiID USPS R IdahoIL USPS R Illinois


Value Code System Usage DescriptionIN USPS R IndianaIA USPS R IowaKS USPS R KansasKY USPS R KentuckyLA USPS R LouisianaME USPS R MaineMD USPS R MarylandMA USPS R MassachusettsMI USPS R MichiganMN USPS R MinnesotaMS USPS R MississippiMO USPS R MissouriMT USPS R MontanaNE USPS R NebraskaNV USPS R NevadaNH USPS R New HampshireNJ USPS R New JerseyNM USPS R New MexicoNY USPS R New YorkNC USPS R North CarolinaND USPS R North DakotaOH USPS R OhioOK USPS R OklahomaOR USPS R OregonPA USPS R PennsylvaniaPR USPS R Puerto RicoRI USPS R Rhode IslandSC USPS R South CarolinaSD USPS R South DakotaTN USPS R TennesseeTX USPS R TexasUT USPS R UtahVT USPS R VermontVA USPS R VirginiaVI USPS R Virgin IslandsWA USPS R WashingtonWV USPS R West VirginiaWI USPS R WisconsinWY USPS R Wyoming


· web viewpage 136hl7 version 2.5.1 ig: laboratory results interface, dstu r2 – us realm....

Documents