Hl7guide 02 2011

HL7Version2.5.
ImplementationGuide forImmunizationMessaging
Release1.2 02/15/2011
PageIntentionallyBlank
PublicationHistoryofPreviousVersions: ImplementationGuideforImmunizationDataTransactions usingVersion2.3.1ofthe HealthLevelSeven(HL7)StandardProtocol Version Date Version2.0 June1999 Version2.1 September2003 Version2.2 June2006
Revision history
Revision Date Author Release1.0 5/1/2010 RobSavage Release1.1 8/15/2010 RobSavage Release1.2 2/15/2011 RobSavage AlistofchangesmaybefoundattheendofImplementationGuide. ForinformationaboutHL7,contact: ForinformationaboutthisGuide,contact: RobSavage HealthLevelSeven 3300WashtenawAvenue,Suite227 rbsavage@cdc.gov AnnArbor,MI481044250 WarrenWilliams Phone:(734)6777777 wxw4@cdc.gov Fax:(734)6776622 EMail:hq@hl7.org ImmunizationInformationSystems Website:www.hl7.org SupportBranch,ImmunizationServices Division,NationalCenterfor ForinformationabouttheAmerican ImmunizationandRespiratoryDiseases, ImmunizationRegistryAssociation,visit CentersforDiseaseControland www.immregistries.org Prevention Phone:(404)6398245 Fax:(404)6398171 Website: www.cdc.gov/vaccines/programs/iis/default.htm
TableofContents
1. INTRODUCTION................................................................................................................1 INTENDED AUDIENCE .............................................................................................. 1 SCOPE.................................................................................................................... 2 ORGANIZATION AND FLOW ...................................................................................... 3 INTRODUCTION TO DIAGRAMS AND MODELS ............................................................ 5 ACTOR AND USE CASE DIAGRAMS AND TABLES ............................................ 5 SEQUENCE DIAGRAMS ................................................................................. 6 ACTIVITY DIAGRAMS .................................................................................... 7 2. ACTORS,GOALS,ANDMESSAGINGTRANSACTIONS..........................................................9 ACTORS AND GOALS .............................................................................................. 9 HIGH-LEVEL VIEW OF USE CASES ......................................................................... 12 USE CASE DESCRIPTIONS ..................................................................................... 14 USE CASE 1SEND IMMUNIZATION HISTORY ............................................. 14 USE CASE 2RECEIVE IMMUNIZATION HISTORY ........................................ 15 USE CASE 3REQUEST IMMUNIZATION HISTORY ....................................... 15 USE CASE 4RETURN IMMUNIZATION HISTORY ......................................... 17 USE CASE 4AFIND CANDIDATE CLIENTS ................................................. 17 USE CASE 5--ACCEPT REQUESTED HISTORY: ............................................. 20 USE CASE 6SEND DEMOGRAPHIC DATA ................................................. 21 USE CASE 7ACCEPT DEMOGRAPHIC DATA ............................................. 21 USE CASE 8--ACKNOWLEDGE RECEIPT ...................................................... 22 USE CASE 9REPORT ERROR .................................................................. 23 MESSAGING IN THE CONTEXT OF THE BUSINESS PROCESS .................................... 23 3. HL7MESSAGINGINFRASTRUCTURE................................................................................26 HL7 DEFINITIONS .................................................................................................. 26 BASIC MESSAGE CONSTRUCTION RULES .............................................................. 28 ENCODING RULES FOR SENDING................................................................ 28 ENCODING RULES FOR RECEIVING ............................................................. 29 IMPLICATIONS OF THE ENCODING RULES .................................................... 29 DETERMINING USAGE OF SEGMENTS, FIELDS AND COMPONENTS ............... 30 MESSAGE ATTRIBUTES COMMON TO ALL MESSAGES ............................................ 35 SEGMENT ATTRIBUTES COMMON TO ALL SEGMENTS ............................................. 36 4. HL7DATATYPES.............................................................................................................38 DATA TYPES FOR IIS USE ..................................................................................... 38 CE -- CODED ELEMENT (MOST USES) ......................................................... 39 CE -- CODED ELEMENT (TEXT ONLY IN RXA-9)........................................... 41 CQ -- COMPOSITE QUANTITY WITH UNITS .................................................. 41 CWE -- CODED WITH EXCEPTIONS ............................................................ 42 CX -- EXTENDED COMPOSITE ID WITH CHECK DIGIT .................................. 44 DT -- DATE ............................................................................................... 45 DTM -- DATE/TIME .................................................................................... 46 EI -- ENTITY IDENTIFIER ............................................................................. 46
ERL -- ERROR LOCATION .......................................................................... 47 FC -- FINANCIAL CLASS ............................................................................. 49 FN -- FAMILY NAME ................................................................................... 49 HD -- HIERARCHIC DESIGNATOR ................................................................ 50 ID -- CODED VALUES FOR HL7 TABLES ...................................................... 51 IS -- CODED VALUES FOR USER DEFINED TABLES ...................................... 52 LA2 -- LOCATION WITH ADDRESS VARIATION 2 ........................................... 52 MSG -- MESSAGE TYPE ............................................................................ 53 NM -- NUMERIC ......................................................................................... 54 PT -- PROCESSING TYPE ........................................................................... 54 SAD -- STREET ADDRESS .......................................................................... 55 SI -- SEQUENCE ID .................................................................................... 55 ST STRING ............................................................................................. 56 TS -- TIME STAMP ..................................................................................... 56 VID -- VERSION ID ..................................................................................... 56 XAD -- EXTENDED ADDRESS ..................................................................... 57 XCN - EXTENDED COMPOSITE ID NUMBER AND NAME FOR PERSONS ........ 59 EXTENDED PERSON NAME (XPN) .............................................................. 62 XTN - EXTENDED TELECOMMUNICATION NUMBER ...................................... 63 5. SEGMENTSANDMESSAGEDETAILS................................................................................66 BHSBATCH HEADER SEGMENT ......................................................................... 72 BHS FIELD DEFINITIONS............................................................................. 72 BTSBATCH TRAILER SEGMENT ......................................................................... 73 BTS FIELD DEFINITIONS ............................................................................. 73 ERRERROR SEGMENT ...................................................................................... 73 ERR FIELD DEFINITIONS: ........................................................................... 75 EVN - EVENT TYPE SEGMENT ............................................................................... 76 EVN FIELD DEFINITIONS............................................................................. 76 FHSFILE HEADER SEGMENT ............................................................................. 77 FHS FIELD DEFINITIONS ............................................................................. 77 FTSFILE TRAILER SEGMENT ............................................................................. 78 IN1INSURANCE SEGMENT (IN2, IN3) ................................................................. 78 MSAMESSAGE ACKNOWLEDGEMENT SEGMENT ................................................ 79 MSA FIELD DEFINITIONS ............................................................................ 79 MSHMESSAGE HEADER SEGMENT .................................................................... 80 MSH FIELD DEFINITIONS ............................................................................ 81 NK1NEXT OF KIN SEGMENT .............................................................................. 86 NK1 FIELD DEFINITIONS ............................................................................. 89 NTENOTE SEGMENT ......................................................................................... 90 NTE FIELD DEFINITIONS ............................................................................. 90 OBXOBSERVATION RESULT SEGMENT .............................................................. 90 OBX FIELD DEFINITIONS ............................................................................ 93 ORCORDER REQUEST SEGMENT ...................................................................... 95 ORC FIELD DEFINITIONS ............................................................................ 98 PD1PATIENT DEMOGRAPHIC SEGMENT ........................................................... 100 PD1 FIELD DEFINITIONS ........................................................................... 102 PIDPATIENT IDENTIFIER SEGMENT................................................................... 104 PID FIELD DEFINITIONS ............................................................................ 108 PV1PATIENT VISIT SEGMENT........................................................................... 111
PV1 FIELD DEFINITIONS ........................................................................... 114 QAKQUERY ACKNOWLEDGEMENT SEGMENT ................................................... 115 QAK FIELD DEFINITIONS .......................................................................... 115 QPD QUERY PARAMETER DEFINITION .............................................................. 116 QPD FIELD DEFINITIONS .......................................................................... 116 RCP RESPONSE CONTROL PARAMETER SEGMENT ........................................... 117 RCP FIELD DEFINITIONS .......................................................................... 118 RXA-- PHARMACY/TREATMENT ADMINISTRATION SEGMENT ................................ 119 RXA FIELD DEFINITIONS........................................................................... 122 RXR-- PHARMACY/TREATMENT ROUTE SEGMENT ............................................... 126 RXR FIELD DEFINITIONS .......................................................................... 126 6. MESSAGESFORTRANSMITTINGIMMUNIZATIONINFORMATION.................................128 INTRODUCTION.................................................................................................... 128 SEND IMMUNIZATION HISTORY--VXU ................................................................... 128 REQUESTING INFORMATION (IMMUNIZATION HISTORY) QBP .............................. 130 RESPOND TO REQUEST FOR INFORMATION RSP ................................................ 131 REQUESTING AN IMMUNIZATION HISTORY FROM ANOTHER SYSTEM VXQ ............. 132 THE USE OF VXQ IS NOT SUPPORTED FOR 2.5.1 IMMUNIZATION MESSAGING. ............................................................................................................... 132 ACKNOWLEDGING A MESSAGE--ACK .................................................................. 132 SENDING DEMOGRAPHIC INFORMATION VXU OR ADT ....................................... 133 SENDING MESSAGES IN A BATCH ........................................................................ 134 7. QUERYANDRESPONSEPROFILE(QBP/RSP)..................................................................136 REQUEST IMMUNIZATION HISTORY QUERY PROFILE Z34^CDCPHINVS ............ 136 RETURN A LIST OF CANDIDATES PROFILE -- Z31^CDCPHINVS .......................... 148 INTRODUCTION: ....................................................................................... 148 USE CASE: .............................................................................................. 149 STATIC DEFINITION .................................................................................. 150 SEGMENT LEVEL PROFILE ....................................................................... 152 FIELD LEVEL PROFILE .............................................................................. 152 DYNAMIC DEFINITION............................................................................... 153 ACKNOWLEDGEMENT RESPONSIBILITIES .................................................. 153 RETURN AN IMMUNIZATION HISTORY Z32^CDCPHINVS .................................. 154 INTRODUCTION: ....................................................................................... 154 USE CASE: .............................................................................................. 154 STATIC DEFINITION .................................................................................. 156 SEGMENT LEVEL PROFILE ....................................................................... 157 FIELD LEVEL PROFILE .............................................................................. 158 DYNAMIC DEFINITION............................................................................... 158 CHANGEHISTORYDETAILS...................................................................................................159 APPENDIXA: CODETABLES...................................................................................................1 APPENDIXBGUIDANCEONUSAGEANDEXAMPLEMESSAGES..............................................1 IMMUNIZATION HISTORY DEFINITION ........................................................................ 1 SEND IMMUNIZATION HISTORY (VXU) ...................................................................... 2
BUSINESS PROCESS ............................................................................................... 2 SUPPORTED MESSAGE SEGMENTS .......................................................................... 5 EXAMPLE VXU # 1-BASIC MESSAGE: ...................................................................... 6 EXAMPLE VXU #2 - INDICATE VACCINE FUNDING SOURCE AND CLIENT ELIGIBILITY STATUS: ................................................................................................................. 7 ELIGIBILITY STATUS: .................................................................................... 7 FUNDING SOURCE: ...................................................................................... 8 EXAMPLE VXU #3 - INCLUDE IMMUNIZATION HISTORY EVALUATION AND FORECAST IN VXU ..................................................................................................................... 10 INDICATING THE SCHEDULE THAT WAS USED: ............................................. 14 INDICATING VACCINE GROUP ASSOCIATED: ................................................ 15 REPORTING THE ORDINAL POSITION IN A SERIES: ...................................... 16 REPORTING THE NUMBER OF DOSES IN A SERIES: ...................................... 16 REPORTING NEXT DOSE RECOMMENDATION DATES: .................................. 16 REPORTING RECOMMENDATION REASONS: ................................................ 17 USING THE NTE SEGMENT ASSOCIATED WITH AN OBX TO PROVIDE MORE INFORMATION: ........................................................................................... 17 EXAMPLE VXU #4 - SEND CLIENT SPECIFIC CONDITIONS ........................................ 18 EVIDENCE OF IMMUNITY: ............................................................................ 18 CONTRAINDICATIONS TO IMMUNIZATION: .................................................... 18 FACTORS WHICH INDICATE THE NEED FOR AN IMMUNIZATION OR A CHANGED RECOMMENDATION: ................................................................................... 19 EXAMPLE VXU #5 SEND IMMUNIZATIONS ASSOCIATED WITH REACTIONS (ADVERSE EVENTS) ............................................................................................................... 19 EXAMPLE VXU #6 DELETE AN IMMUNIZATION RECORD ........................................ 20 VXU EXAMPLE #7--SEND INFORMATION ABOUT VACCINE INFORMATION STATEMENT (VIS) .................................................................................................................... 21 VXU EXAMPLE #8SEND INFORMATION ABOUT IMMUNIZATION REFUSAL ............. 22 VXU EXAMPLE #9SEND TWO LOT NUMBERS IN RXA ......................................... 22 VXU EXAMPLE #10RECORDING BIRTH INFORMATION......................................... 23 VXU EXAMPLE #11RECORDING AN INCOMPLETELY ADMINISTERED DOSE OR A NON-POTENT DOSE................................................................................................ 23 SEND ACKNOWLEDGEMENT ACK IN RESPONSE TO VXU ....................................... 24 SEND ACKNOWLEDGEMENT OF SUCCESS IN ACK ........................................ 24 SEND ERROR IN ACK ................................................................................ 24 SEND REQUEST FOR VACCINE HISTORY (QBP/RSP) ............................................. 25 PROCESS FOR REQUESTING IMMUNIZATION HISTORY.................................. 25 DESCRIPTION OF THE VXQ/VXX/VXR PROCESS FROM VERSION 2.3.1....... 26 USING QBP QUERY TO REPLICATE VXQ/VXX/VXR .................................... 27 RETURNING A LIST OF CANDIDATE CLIENTS IN RESPONSE TO QBP^Q11 QUERY ...................................................................................................... 30 RETURNING AN IMMUNIZATION HISTORY IN RESPONSE TO A REQUEST FOR IMMUNIZATION HISTORY QUERY ................................................................. 31 ACKNOWLEDGING A QUERY THAT FINDS NO CANDIDATE CLIENTS ................. 31 ACKNOWLEDGING A QUERY THAT FINDS MORE CANDIDATES THAN REQUESTED ................................................................................................................. 32 USING A TWO-STEP PROCESS TO REQUEST AN IMMUNIZATION HISTORY ....... 33 RETURNING A LIST OF CANDIDATE CLIENTS IN RESPONSE TO PDQ QUERY ... 36 RECEIVING SYSTEM DETERMINES THAT MESSAGE HAS ERRORS ................... 37 MALFORMED MESSAGE .............................................................................. 37 NO MATCH IS FOUND ................................................................................ 38
TableofFigures
Revision history..................................................................................................... 3 Figure 1-1 Simple Use Case Diagram ................................................................. 6 Figure 1-2-Simple Sequence Diagram .................................................................. 7 Figure 1-3 Simple Activity Diagram ....................................................................... 8 Table 2-1 Actors and Goals for Messaging ......................................................... 10 Figure 2-1 Use Case Diagram ............................................................................ 13 Figure 2-2 Finding a Client .................................................................................. 14 Figure 2-3-Use Cases 1 and 2: Send and Receive Immunization History .......... 15 Figure 2-4-Use Cases 3, 4 and 5: Request Immunization History, Respond to Request and Accept Requested History ...................................................... 17 Figure 2-5--Using PDQ to Resolve Identity Prior to Request for Immunization History ......................................................................................................... 18 Figure 2-6--Implicit Identity Resolution in Response to a Request for Immunization History When One High-confidence Match Is Found ............. 19 Figure 2-7--Implicit Identity Resolution in Response to a Request for Immunization History When Lower Confidence Candidates Are Found ...... 20 Figure 2-8--Send Demographic Data Via VXU or ADT ....................................... 22 Figure 2-9--VXU Process Model ......................................................................... 25 Table 3-1 Outcome of Encoding Rule Breaches ................................................. 29 Table 3-1--Usage Code Interpretations for Fields, Components and Subcomponents ................................................................................................. 31 Table 3-2--Usage Code Interpretation for Segments .......................................... 34 Table 3-3--Message Attributes ............................................................................ 35 Table 3-4--Segment Attributes ............................................................................ 36 Table 4-1-- Data Types ....................................................................................... 39 Table 4-2 Coded Element (CE) ........................................................................... 40 Table 4-3 Coded Element (CE) for Text Only RXA-9 ......................................... 41 Table 4-4 Composite Quantity with Units (CQ) .................................................. 42 Table 4-5 Coded with Exceptions (CWE) ........................................................... 43 Table 4-6 Extended Composite ID with Check Digit(CX) ................................... 44 Table 4-7 Date (DT) ........................................................................................... 45 Table 4-8 Date/Time (DTM) ............................................................................... 46 Table 4-9 Entity Identifier (EI) ............................................................................. 46 Table 4-10 Error Location (ERL) ........................................................................ 47 Table 4-11 Financial Class (FC) ......................................................................... 49 Table 4-12 Family Name.................................................................................... 50 Table 4-13 Hierachical Designator (HD) ............................................................. 50 Table 4-14 Coded Values for User Defined Tables (IS) ...................................... 52 Table 4-15 Location with Address Variation 2 ..................................................... 52 Table 4-16 Message Type (MSG) ....................................................................... 53 Table 4-17 Numeric (NM) ................................................................................... 54 Table 4-18 Processing Type (PT) ...................................................................... 55 Table 4-19 Street Address (SAD) ....................................................................... 55 Table 4-20 Sequence Id (SI) ............................................................................... 56
Table 4-21 Time Stamp (TS) .............................................................................. 56 Table 4-22 Version ID (VID) ................................................................................ 56 Table 4-23 Extended Address (XAD) .................................................................. 57 Table 4-24 Extended Composite ID Number and Name (XCN) .......................... 59 Table 4-25 Extended Person Name (XPN) ......................................................... 62 Table 4-26 XTN Extended Telecommunication Number (XTN) .......................... 63 Table 5-1 Message Segments ............................................................................ 66 Table 5-2 Batch Header Segment (BHS) ............................................................ 72 Table 5-3 Batch Trailer Segment (BTS) .............................................................. 73 Table 5-4 Error Segment (ERR).......................................................................... 74 Table 5-5 Event Segment (EVN)......................................................................... 76 Table 5-6 File Header Segment (FHS) ............................................................... 77 Table 5-7 File Trailer Segment (FTS) ................................................................. 78 Table 5-8 Message Acknowledgement Segment (MSA)..................................... 79 Table 5-9 Message Header Segment (MSH) ...................................................... 80 Table 5-10 Message Types ................................................................................ 83 Table 5-11-Next of Kin Segment (NK1) .............................................................. 87 Table 5-12 Note Segment (NTE) ........................................................................ 90 Table 5-13 Observation Segment (OBX) ............................................................ 91 Table 5-14 Common Order Segment (ORC) ...................................................... 96 Table 5-15-Patient Demographic Segment (PD1) ............................................ 101 Table 5-16-Patient Identifier Segment (PID) ..................................................... 105 Table 5-17-Patient Visit (PV1) .......................................................................... 112 Table 5-18-Query Acknowledgement Segment ................................................ 115 Table 5-19-Query Parameter Definition (QPD) ................................................. 116 Table 5-20-Response Control Parameter ......................................................... 118 Table 5-21 Pharmacy/Treatment Administration (RXA) .................................... 120 Table 5-22 Pharmacy/Treatment Route (RXR) ................................................. 126 Table 6-1-Supported Messages ........................................................................ 128 Table 6-2--VXU Segment Usage ...................................................................... 128 Figure 6-1-VXU Domain Diagram ..................................................................... 130 Table 6-3 QBP/RSP Query By Parameter/Segment Pattern Response ........ 131 Table 6-4-Segment Pattern Response (RSP) ................................................... 132 Table 6-5 Message Acknowledgement Segment (ACK) ................................... 132 Table 6-6-ADT A04 Message ........................................................................... 134 Table 7-1 Request Immunization History Query Profile .................................... 137 Table 7-2-Response Grammar to Different Outcomes...................................... 138 Table 7-3 Response Grammar RSP^K11 ......................................................... 140 Table 7-4 MSH Specification for Request Immunization History Query ............ 142 Table 7-5 QPD Input Parameter Specification .................................................. 143 Table 7-6 QPD Input Parameter Field Description and Commentary ............... 144 Table 7-7 RCP Response Control Parameter Field Description and Commentary ................................................................................................................... 147 Table 7-8 Query Response Possibilities ........................................................... 148 Figure 7-1--Return Candidate List..................................................................... 149 Table 7-9 Response Grammar RSP^K11 ......................................................... 150
Figure 7-2 Return Candidate List (RSP^K11) ................................................... 153 Figure 7-3 Return Immunization History Use Case ........................................... 155 Figure 7-4 Return Immunization History Response Grammar .......................... 156 Figure 7-5 Return Immunization History Sequence Diagram ............................ 158 Table 40--Release 1.1 Changes ....................................................................... 159 Table 41--Release 1.2 Changes ....................................................................... 159 Table 41-Immunization History Definition ............................................................. 1 Figure 6-VXU Business Process ........................................................................... 3 Figure 7-Segment Usage ...................................................................................... 6 Figure 8--VXQ/VXX/VXR processes ................................................................... 26 Figure 9--Request Immunization History ............................................................. 28
Chapter 1: Introduction
1. Introduction
ImmunizationInformationSystems(IIS)arecentralizedpopulationbasedrepositoriesof immunizationrelatedinformation.Theyreceiveandsharedataonindividual clients/patientswithanumberofothersystems,includingElectronicHealthRecord systems(EHRS).HealthLevelSeven(HL7)isanationallyrecognizedstandardfor electronicdataexchangebetweensystemshousinghealthcaredata.TheHL7standard isakeyfactorthatsupportsthistwowayexchangeofinformationbecauseitdefinesa syntaxorgrammarforformulatingthemessagesthatcarrythisinformation.Itfurther describesastandardvocabularythatisusedinthesemessages.Itdoesnotdependon specificsoftware,thatis,itisplatformindependent. ThisdocumentrepresentsthecollaborativeeffortoftheAmericanImmunization RegistryAssociation(AIRA)andtheCentersforDiseaseControlandPrevention(CDC)to improveintersystemcommunicationofimmunizationrecords.Thisimplementation guidewillreplacetheexistingImplementationGuideforImmunizationDataTransaction UsingVersion2.3.1oftheHL7StandardProtocol,andwillbebasedonHL7Version 2.5.1,aspublishedbytheHL7organization(www.hl7.org).Theexisting2.3.1Guidehas anumberofsuccessfulimplementationsthatexchangemessageswithotherIISand EHRS.Theexperienceoftheseimplementationshasidentifiedanumberofareasofthe existingGuidethatwouldbenefitfromanupdateoftheGuide. AsHL7hasdevelopedandpublishednewversionsofthestandard,ithassoughtto maximizetheabilityofimplementations,basedonnewerversionstobeabletoaccept messagesfromearlierversions.Basedonthis,weanticipatethatfaithful implementationsofthisGuidewillbeabletoacceptmostimmunizationmessages basedonthe2.3.1Guide.Notethatvariationsincurrent2.3.1interfacesincreasethe riskthatfaithful2.5.1implementationswillencounterproblemswith2.3.1messages. Thebenefitsfrommovingto2.5.1shouldencouragemigrationtothisstandard. ImplementationsthataresupportingVersion2.3.1messagesshouldcontinuetofollow thespecificationsof2.3.1messagesdescribedintheImplementationGuideVersion2.2, June2006.
IntendedAudience
ThisGuidehastwoaudiences.Thefirstisthesystemmanagersthatmustunderstand thisprocessatahighlevel.ThesecondisthetechnicalgroupfromIISandEHRSthat mustimplementtheseguidelines.Forthemwestriveforanunambiguousspecification forcreatingandinterpretingmessages.OurgoalisforthisGuidetobeabridgebetween thetwo.
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011
ItisimportanttonotethatHL7specifiestheinterfacebetween2systems.Itdoesnot specifyhowanygivensystemisimplementedtoaccomplishthegoalsofmessaging.
Scope
ThisGuideisintendedtofacilitatetheexchangeofimmunizationrecordsbetween differentsystems 1 .Thisincludes sendingandreceivingimmunizationhistoriesforindividuals sendingandreceivingdemographicinformationabouttheindividuals requestingimmunizationhistoriesforindividuals respondingtorequestsforimmunizationhistoriesbyreturningimmunization histories acknowledgingreceiptofimmunizationhistoriesandrequestsfor immunizationhistories reportingerrorsinthemessagingprocess sendingobservationsaboutanimmunizationevent(thismayinclude funding,reactions,forecastsandevaluations). TheGuideisnotintendedtospecifyotherissuessuchas businessrules,whicharenotimplicitinHL7,appliedwhencreatinga message businessrules,whicharenotimplicitinHL7,appliedwhenprocessinga receivedmessage thestandardtransportlayer searchprocessusedwhenrespondingtoaquery businessrulesusedtodeduplicateclientsorevents managementofvaccineinventory 2 maintenanceofMasterPersonIndex. Localimplementationsareresponsiblefortheimportantissuesdescribedabove.One waytoinsuresuccessistopublishalocalprofileorimplementationguidethatoutlines thelocalbusinessrulesandprocesses.TheseguidesmayfurtherconstrainthisGuide, butmaynotcontradictit.ThisGuidewillidentifysomeofthekeyissuesthatshouldbe addressedinlocalprofiles. TheGuideismeanttosupportandintegratewithstandardsharmonizationefforts. TheseeffortsincludetheHealthInformationStandardsPanel(HITSP),HITSPhas selectedanumberofitemswhichsupportinteroperabilitybetweenhealthsystems. Amongtheseisselectionofpreferredvocabulary.ThisGuidewilladoptthesestandard vocabulariesastheyapply.Anothereffort,whichpromotesstandardsharmonization,is
1 2
The exchange partners could be IIS, EHR-S. or other health data systems. Note that requesting an immunization history may require interaction with an MPI or other identity source. Those using these services should consult with profiles or implementation guides that support this. Integrating the Healthcare Enterprise (IHE) has profiles that support MPI maintenance and identity resolution. HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 2 1/31/2011
anorganizationcalledIntegratingtheHealthcareEnterprise(IHE) 3 .Theyproduce profiles,whichdefinehowtoaccomplishvariousgoalswithcommoncomponents. ThisGuidemakesthefollowingassumptions: Infrastructureisinplacetoallowaccurateandsecureinformationexchange betweeninformationsystems. 4 ProvidersaccessimmunizationinformationthrougheitheranEHRSor immunizationinformationsystem(IIS). Privacyandsecurityhasbeenimplementedatanappropriatelevel. Legalandgovernanceissuesregardingdataaccessauthorizations,data ownershipanddatauseareoutsidethescopeofthisdocument. Theimmunizationrecordanddemographicrecordforeachpatientcontains sufficientinformationforthesendingsystemtoconstructtheimmunizationand demographicmessageproperly. Externalbusinessrulesareassumedtobedocumentedlocally. Itisimportanttobeabletoacceptcompleteimmunizationhistoriesfromdifferent sourcesandhaveamethodforintegratingthem.Thisimpliesthatasystemshouldnot assumethatanyrecordsentisnew.Ifthesystemmakesthisassumptionandreceives acompletehistorythathasoverlappingimmunizationrecords,thereisariskfor duplicaterecords. ThereisbestpracticeguidanceonhandlingthisfromtheAmericanImmunization RegistryAssociation(AIRA)intheModelingImmunizationRegistryOperations Workgroup(MIROW)documentsavailabletheAIRAwebsite.(immregistries.org)
OrganizationandFlow
Thefirsttwochaptersaremeanttolayoutwhatcanbedoneandwhy.Thechapters thatfollowthemdescribeandspecifyhow.Theystartatthemostgranularleveland proceedtothemessagelevel.Severalappendicessupportimplementerswithvaluesets andexamplesofuse. Boxednotesareusedtocallattentiontoareaswheretherearechangesfromthe version2.3.1ImplementationGuideorareaswherereadersshouldpayspecial attention.
3
IHE is an industry-supported group, which creates implementable specifications, based on existing standards, to support accomplishment of selected use cases. 4 This infrastructure is not specified in this document, but is a critical element to successful messaging. Trading partners must select a methodology and should specify how it is used. HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011
Chapter1Introduction ThischapterdescribesthescopeoftheGuideandgivessupportingbackground.It includesadescriptionofthediagramsthatwillbeusedtoillustratebusinessprocesses andtransactions. Chapter2Actors,GoalsandMessagingTransactions Chapter2describesthebusinessmotivationsthatthisGuidewillsupport.Itwill describetheentities(actors)thatwillrelyonthemessages.Itwilllayoutthe transactionsthatwillsupportthegoalsoftheseactors(usecases).Finally,itwill describethebroadercontextthatthismessagingoccursin.Therearesupporting businessprocessesoutsideoftheactualmessagingthatarekeystosuccess. Chapter3Messaginginfrastructure Chapter3focusesontheunderlyingrulesandconceptsthatarethebasisforHL7 messaging.Itwillillustratethecomponentsofmessages,thegrammaticalrulesfor specifyingthecomponentsandsubcomponents. Chapter4_DatatypeDefinitions Thischapterwilldescribeandspecifyalldatatypesanticipatedforusebythemessages supportedbythisGuide.Wheretherearesubcomponentstoadatatype,itwillspecify anyrulesrelatedtouse.ThevaluesusedinmessagesarespecifiedinappendixA.Data typesarethebuildingblockforsegments,describedinthenextchapter. Chapter5MessageSegments Chapter5givesspecificationsformessagesegments.Segmentsareunitsofthemessage thatcarryspecifictypesofinformation.ForinstancePIDcarriespatientidentifying information.Thesegmentsincludedinthischapterarethosethatareneededbythe messagesspecifiedinChapter6. Chapter6MessageDetailsforImmunization Chapter6specifieshowtousethebuildingblocksofdatatypesandsegmentstomeet thebusinessneedstoconveyimmunizationrecords.Itwillincludespecificationfor requestinganimmunizationhistoryandacknowledgingmessagereceiptorerrors. Chapter7QueryProfileforRequestinganImmunizationHistory. HL7hasatemplateforspecifyingaquery.Thischapterusesthattemplatetogivethe specificationsforaqueryrequestinganImmunizationHistory.Itisbuiltontheprevious 4chapters.Twochildprofiles,whichsupportresponsetothequery,arealsofoundin thischapter. AppendixACodeTables ThisappendixlistsexpectedvaluesforallcodeddataelementsusedinthisGuide. HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 4
1/31/2011
AppendixBMessageexamples Thisappendixwillshowdetailedexamplesofhowtoimplementthemessagesspecified inthebodyoftheImplementationGuide.
IntroductiontoDiagramsandModels
Thisdocumentmakesuseofmodelsordiagramstoillustratethetransactionsandtheir components.TheseincludeUseCasemodel,SequenceDiagramandActivityDiagram. ThesearebasedontheUnifiedModelingLanguage(UML).Theillustrationsbeloware examplesonly.Detailedmodelswillbefoundintheappropriatesectionslaterinthe document. ActorandUseCaseDiagramsandTables Actorsareinformationsystemsorcomponentsofinformationsystemsthatproduce, manage,oractoncategoriesofinformationrequiredbyoperationalactivitiesinthe enterprise.Inourcontext,usecasesaretasksorgoalsthatactorsusetocommunicate therequiredinformationthroughstandardsbasedmessages.Thediagramsandtables ofactorsandtransactionsinsubsequentsectionsindicatewhichtransactionseachactor performs. Theusecasesshownonthediagramsareidentifiedbytheirname.Supportingtextwill definethegoalofausecase.Theactorsassociatedwitheachusecasewillbeincluded andshowtheirrelationship.Thediagrambelowshows2actorsthatusetheSend ImmunizationHistoryUseCase.InthisusecaseweseethatbothIISandEHRSusethe SendImmunizationHistoryusecase.ItdoesnotimplythattheIISsendsan immunizationhistorytoanEHRS.
Figure 1-1 Simple Use Case Diagram
SequenceDiagrams Thedescriptionsoftheusecasesthatfollowincludesequencediagramsthatillustrate howtheusecaseisaccomplishedasasequenceoftransactionsbetweenrelevant actors. Thesediagramsareintendedtoprovideanoverviewsothetransactionscanbeseenin thecontextoftheparticipatinginstitutionsworkflows.Thesediagramsarenot intendedtopresenttheonlypossiblescenario,justthoserequiredtoaccomplishthe goalsofcommunicatingbetweeninformationsystems. Insomecasesthesequenceoftransactionsmaybeflexible.Wherethisisthecasethere willgenerallybeanotepointingoutthepossibilityofvariations.Transactionsareshown asarrowsorientedaccordingtotheflowoftheprimaryinformationhandledbythe transaction.Inthediagrambelowweseethatonesystem(itcouldbeIISorEHRS) sendsanimmunizationrecordtoanothersystem.ThemessagesentisaVXU (UnsolicitedUpdateofImmunizationRecord).Thereceiverprocessesthemessageand sendsanacknowledgmentofthereceipt.Theprocessingisnotpartofthemessaging andmayvaryfromapplicationtoapplication.Theacknowledgementcouldbeassimple asIgotit,allisOKorThemessagehaserrorsandIcantacceptit
Figure 1-2-Simple Sequence Diagram
ActivityDiagrams Activitydiagramsareanotherwayofshowingwhatishappeningwithinsystemsand betweensystems.Theyaremostusefulforshowingthedecisionlogicused.The diagramincludesswimlanes,whichseparatethetasksofcooperatingsystems.The purposeofthefollowingdiagramistoillustratethecomponentsofanactivitydiagram, nottodesignasystem. Inthiscase,thesendingsystemsendsaVXU.Thereceivingsystemparsesthemessage anddecideswhattodowithit.Weassumethatparsingwassuccessfultosimplifythis diagram.Thereareanumberofdecisionsthataremadeandeachleadstoanactionor actions.Thediamondsrepresentdecisionpoints.Inthefirstdecisionpoint,thesystem branchesfollowsdifferentpaths,dependingontheresultsoftheclientsearch.Ifno matchesarefound,itfollowsitslocalprocessforintegratinganewrecordintothedata base.Ifalowerconfidencematchisfound(forinstance,morethanoneclientmatches theincomingrecord)itfollowslocalbusinessrulesforthesituation.Ifahighconfidence matchisfound,itfollowslocalbusinessrulesformergingtheincomingdataintoan existingclientrecord.Allactionsthenmovetoacknowledgetheresultsoftheactivity. Theactualactivityofarealsystemmaybeverydifferentfromthis.
Figure 1-3 Simple Activity Diagram
Notethatthefocusofthisguideisontheformatandgrammarofthemessages betweensystems.Theactivitiesshownwithinasystemareintendedtoputthemessage incontextandtohighlightthelocalresponsibilitiesforsuccessfulmessaging.
Chapter 2: Actors, Goals and Messaging Transactions
2. Actors, Goals, and Messaging Transactions

Thischapterwilldescribetheactors(entities)thatmaybeinvolvedinsendingor receivingimmunizationrelatedmessages.Itwilllistanddescribetheusecases(goals) thattheyhavethatcanbemetbythemessages.Itwillillustratethemessaginginterface incontext.Finally,itwillassociatespecificHL7messageswiththesegoals. Notethatthereareanumberofsupportingprocessesthatarenotincludedwithinthe messagingspecifications.Theyarevitaltosuccess,butdonotbelonginthis ImplementationGuide,butratherinlocalbusinessrulesdocumentation.
ActorsandGoals
Thereareanumberofprimaryactorsinvolvedindataexchange.Theseinclude ImmunizationInformationSystem(IIS) ElectronicHealthRecordSystems(EHRS)andothersystems 5 AnactorwithasupportingrolemaybeaMasterPersonIndex(MPI) 6 . Wewillfocusonthefirst2actorsbutwillillustratehowtheMPIactormaybe integrated.Theseactorscanbesuppliersofinformation/dataand consumers/requestersofdata.Wewillconsidertheinitiatorofamessaging conversationthesenderandthetargetofthisfirstmessagethereceiver.Obviously,a sendermayreceivemessages.Forinstance,asenderinitiatesarequestforan immunizationhistoryforaclient.Thereceiverrespondswithamessagethatisreceived bytheinitiatingsender.Forclarity,theinitiatorwillkeepthelabelofsender. Notethatwedonotassumethatthesenderorreceiverisaspecificdatasource(IISor EHR).OneIISmayqueryanotherIISoranEHRS.Similarly,anEHRSmaysendan immunizationhistorytoanotherEHRS. OtheractorshaveaninterestinthefunctionsofanIISandmessaging.Theseinclude: Clients/patients Users Policymakers Researchers PublicHealthagencies
5 6
The diagrams often show an IIS and an EHRs/other system. The other system may be an IIS. A Master Person Index is used by some health data systems to cross-reference a persons identifiers across these systems. If system A needs the persons id from system B, then it may retrieve it from the MPI. The PIX query asks for one systems personal identifier, based on another systems identifier. HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 9 1/31/2011
Clinicians Billingsystems
TheseactorswillnotbedirectlyaddressedinthisGuide.Theyinteractwiththeprimary actorstoaccomplishtheirneeds.
Table 2-1 Actors and Goals for Messaging
Actor Immunization InformationSystem (IIS)
Responsibility Provideaccesstoacomplete, consolidatedimmunization recordforeachpersoninits catchmentarea Supplyindividual immunizationrecordsto authorizedusersandsystems Supportaggregatereporting andanalysis Evaluateimmunizationhistory andmakerecommendations fornextdoses Storemedicalconditionsthat affectwhatvaccinesare recommended
ElectronicHealth Recordsystem(EHR S)
Houseapersonselectronic healthrecord Makeapersonsrecord availabletoauthorized persons
MessagingGoals Receiveimmunization historiesandupdates Receivedemographicupdates Receiverequestsforindividual records Receiveobservationsabouta person Sendobservationsabouta person Sendimmunizationrecordsto othersystems Senddemographicdata Requestimmunizationrecord Requestpersonid Acknowledgereceiptof message Reportprocessingerrorsfrom receiptofmessage Receiveimmunization historiesandupdates Receivedemographicupdates Receiverequestsforindividual 10
Actor
Responsibility Providedecisionsupportfor clinicaldecisions.
MasterPersonIndex orotheridentity broker.
Maintainalistofpatientsand identifiersforasetofpersons Supplyidentifiersforother systemsuse Beacentraldemographic supplierforparticipating systems Providecrossreferencefor identifiersforparticipating systems.
MessagingGoals records Sendimmunizationrecordsto IIS Senddemographicdata Receiveobservationsabouta person Sendobservationsabouta person RequestImmunizationrecord Requestpersonid Acknowledgereceiptof message Reportprocessingerrorsfrom receiptofmessage Requestevaluationonan immunizationhistoryand recommendationsfornext doseonagivenSchedule,such asACIP Sendidforanindividualfor useinarecordrequestor recordupdate Receiverequestforpersonid. Returncompletedemographic dataforanindividualfrom centraldemographicstore
ThetablelistsanumberofmessagingneedsthatrelatetoIISandtheirtradingpartners. TheseareallcandidatesforHL7messaging.Somearenotcurrentlyimplemented,but HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 11
1/31/2011
giveusthelandscapethatshouldbeconsidered.Notethatthemessagingfor maintainingofanMPIisoutofscopeforthisImplementationGuide. Anotherwaytoorganizethesetasksorgoalsistodecomposethegoalsoftheentities (actors)intothevariousrolestheymayplay.Theserolesinclude: Immunizationhistorysupplier Immunizationhistoryconsumer Demographicinformationsupplier Demographicinformationconsumer Identityresolutionbroker Eachoftheactorsabovemayhavethecapacityandinteresttosupportsome constellationoftheseroles.Thisapproachisusefulforsystemdesignand implementationandencouragesaservicesapproachtodevelopment.Sincethegoalof thischapteristoprovideanontechnicalviewtohelpsystemmanagersunderstand howmessagingcanmeettheirneeds,wewillfocusonthebusinessentitiesandtheir goals.
HighLevelViewofUseCases
Wecanmaptheseactorsandmessaginggoalstousecases.Thefollowingdiagrammaps themessaginggoalsofthevariousplayerstousecases.Theseusecaseswillbedefined below.Notethatsomeoftheseusecasesarelogicallyrelated.Forinstance,Request ImmunizationHistoryispairedwithReturnImmunizationHistory.SendImmunization HistoryneedsthereceivertoReceiveImmunizationHistory.Theseusecasesarenot intendedtobethebasisofasoftwaredesignprocess. Severalpathsmayaccomplishtherequestforimmunizationhistory.Systemswillreturn animmunizationhistorywhentheyareconfidentthatthepersonrequestedhasbeen identified.Onepathseparatesidentityresolutionfromtherequestforimmunization history.Anotherincludesimplicitidentityresolution.Fordetails,seeusecase3,4Aand 4below.
12
Chapter 2: Actors, Goals and Messaging Transactions Figure 2-1 Use Case Diagram
Thefollowingdiagramillustratesamoredetailedviewoftherequestimmunization historyandreturnimmunizationhistory.ItbreakstheFindCandidateClientsusecase out.Notethatasystemmayrequestidentityresolution(findclient)priortorequesting animmunizationhistory.Alternatively,asystemmayrequestanimmunizationhistory. Thiscantriggeranimplicitrequesttofindaclient.
13
Chapter 2: Actors, Goals and Messaging Transactions Figure 2-2 Finding a Client
ThefollowingliststheHL7MessagesshownbelowintheUseCases: ACKAcknowledgementmessage ADTAdmit,DischargeandTransfermessage QBPQuerybyparameter RSPRespondtoQBP VXUUnsolicitedvaccinehistory ThefollowingareprofiledqueriessupportedbyIHEforidentityresolution: PDQAspecifictypeofQBPthatfacilitatesidentifyresolutionbasedondemographic information PIXAspecifictypeofQBPthataccomplishesidcrossreference
UseCaseDescriptions
UseCase1SendImmunizationHistory Goal:Tosendanimmunizationhistoryforanindividualclientfromonesystemto another.InadditiontoEHRSandIIS,othersystemssuchasvitalrecordssystemsor billingsystemscouldusethismessagetosendimmunizationhistories.
HL7 version 2.5.1 Message Type: VXU
Precondition:Auserorotheractorrequeststhatthesendingsystemsendan immunizationhistory.
14
Figure 2-3-Use Cases 1 and 2: Send and Receive Immunization History
Thissequencediagramillustratesthemessageflow.Thesendersendsanimmunization record(UseCase1).Thereceiveracceptsthemessage(UseCase2)andprocessesit. Thereceivermaysendanacknowledgmentmessage.(SeeUseCase9)Thetransactions thatareofinterestareindicatedbyboldarrows. UseCase2ReceiveImmunizationHistory Goal:Toreceiveanunsolicitedimmunizationhistory.Itmaybeanupdateoranew record.Thisusecasedoesnothaveresponsibilityfortheprocessingofthemessage.The receivingsystemmayreviewandaccepttheimmunizationhistoryifitchooses,butthis outsidethescopeofthisusecase.

HL7 version 2.5.1 Message Type: VXU
Precondition:AVXUisreceivedbythereceivingsystem. UseCase3RequestImmunizationHistory Goal:Torequestanimmunizationhistoryfromanothersystem. Precondition:Auserorotheractorrequeststhatthesendingsystemsendarequestfor animmunizationhistoryusingdemographicinformationand/orotheridentifiers. TheoldVXQqueryincludedimplicitidentityresolution.Ifahighconfidencecandidate wasidentified,basedondemographicsandotheridentifiers,animmunizationhistory wasreturnedinaVXR.Iflowerconfidencecandidateswerefound,alistofcandidates wasreturnedforfurtherselectioninaVXX.TheselectionfromtheVXXinformedthere querywithanewVXQ.TheapproachoutlinedinthisGuideallowsthisprocesstobe followedusingdifferentmessages.
15
Anotherapproachthatiscommonintheinformaticsworldistoseparatetheidentity resolutionfromtherequestforcontent(immunizationhistoryinthiscase).Herethe requestersendsaqueryseekingacandidate,basedondemographicsandother identifiers.Therequesterselectsfromthecandidatesreturnedandthensendsthe requestforcontentbasedonthatselection.Theidentitymaybesoughtfromaseparate MasterPersonIndexorfromthecontentprovider.Oneindustrystandard,which supportsthisapproach,isthePDQqueryprofilebyIntegratingtheHealthcare Enterprise(IHE).TheapproachoutlinedinthisGuideallowsthisprocesstobefollowed. Athirdsituationoccurswhentherequesteralreadyknowsanidentifiermeaningfulto therespondingsystem.Thismayoccurwhenthesendingsystemhasalreadysenta recordforthepersonofinterestthatincludesthesendersidentifier.Alternatively,it mayoccuriftherequesterknowstheuniqueidentifierusedbytherespondingsystem. TheapproachoutlinedinthisGuideallowsthisprocesstobefollowed. Sinceidentityresolutionisrequiredeitherimplicitlyorexplicitly,ausecaseisdescribed forfindingaclient/candidate(UseCase4A).Thatusecasecontainsthealternateflows forthedifferentpaths. Notethatmoredetailedinformationabouttheflowofeventsandoptionsisavailablein AppendixB.
HL7 version 2.5.1 Message Type: QBP using Request Immunization History query profile.
16
Chapter 2: Actors, Goals and Messaging Transactions Figure 2-4-Use Cases 3, 4 and 5: Request Immunization History, Respond to Request and Accept Requested History
Notethatthesendingsystemprocessmayincludeconfirmingthattherecordreturned istheonebeingsought.Thisprocessisnotspecifiedhere. UseCase4ReturnImmunizationHistory Goal:Toreturnanimmunizationhistory.Itdoesnotincludetheprocessesusedtofind candidateclientsforreturn. Thereare4possibleresults: 1. Oneclientmatchesexactly 7 thecriteriasent 2. Oneormoreclientsmatchthecriteriasent(inexactmatch) 8 3. Noclientsmatchthecriteriasent 4. Therewereerrorsorotherproblems NotethatsystemsmustdealwiththesituationwhereaClienthasindicatedthathis/her recordsmustbeprotected.(Onlytheowningprovidermayview)Thisshouldbeclearly documented. SeeFigure6.
Standard Reference HL7 version 2.5.1 Message Type: RSP
Precondition:Areceivingsystemreceivesarequestforanimmunizationhistory.
HL7 version 2.5.1 Message Type: QBP using Request Immunization History query profile
UseCase4AFindCandidateClients Goal:Tofindoneormorecandidateclientsfromanothersystemandselectonetobe usedwhenrequestinganimmunizationhistory. Precondition: Therearetwopotentialpreconditions. 1. Auserorotheractorrequeststhatthesendingsystemsendarequestforoneor morecandidateclientsusingdemographicinformationand/orotheridentifiers. (ThisiswellspecifiedintheIHEPDQprofile) 2. Areceivingsystemreceivesarequestforimmunizationhistoryusingarequest forimmunizationhistoryquery.
7 8
The definition of exact is a local business rule and should be documented locally. If more than one client has a high-confidence match with the query parameters, this is an inexact match. HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011
17
Ifexactlyonehighconfidencematchisfoundthenanimmunizationhistoryisreturned. Ifthisquerydoesnotfindonehighconfidencecandidate,butratherfindsoneormore lowerconfidencecandidatesthenalistofcandidatesarereturned.Ifmorethanone highconfidentmatchisfound,thenthisistreatedasalowerconfidencematch. Notethatthediagramsbelowareintendedtoputthemessagesincontextanddonot accuratelyreflectthearchitecturethatwouldsupporttheactivities.

Request Identity Resolution Prior to Requesting an Immunization History
ThefollowingdiagramillustratestheprocessandmessageswhereasystemusesaPDQ querytorequestidentifiersanddemographicsforaclient.Theresultofthisprocessis thenusedtopopulateaRequestforImmunizationHistoryquery.Messageshavebolded arrows.Otherprocessesarenotbolded.Itshouldbenotedthattheimmunization historysuppliermayalsoactastheidsupplier,butthisisnotrequired.Thisparticular UseCasefocusesontheinteractionsbetweentherequesterandtheidsupplier.The othertransactionsillustratehowthisfitsintotherestoftheprocess.Weassumethat theidentifierusedintheQBP^Q11isuniquewithintheimmunizationhistorysupplier.
Figure 2-5--Using PDQ to Resolve Identity Prior to Request for Immunization History
Requesting an Immunization History Using Implicit Identity Resolution
18
Thefollowing2diagramsillustratehowasystem,whichusesaRequestfor ImmunizationHistory,reliesonimplicitidentityresolution. Thefirstdrawingillustratesthecasewhenonehighconfidencecandidateisfound.The outcomeofthefindclientprocessisacallforthesystemtosendtheimmunization historybacktotherequestingsystem.Messagesarebolded.
Figure 2-6--Implicit Identity Resolution in Response to a Request for Immunization History When One High-confidence Match Is Found
Whenthefindclientprocessfindslowerconfidencecandidates,thenthesystemreturns alistofcandidateclients.Theuserreviewstheseandselectstheoneofinterest.The selectionisusedtopopulateasecondRequestforImmunizationHistoryquery.The identityresolutionprocesspointstothecorrectclientandanimmunizationhistoryis returned.Theusermaychoosetorefinethesearchcriteriaandsubmitanewquery,if he/shebelievesthatamatchshouldhavebeenfound.
19
Figure 2-7--Implicit Identity Resolution in Response to a Request for Immunization History When Lower Confidence Candidates Are Found
HL7 version 2.5.1 Message Type: QBP using Request Immunization History query profile Or QBP using PDQ (IHE)
UseCase5Acceptrequestedhistory:
Scope:
Thegoalofthisusecaseistoacceptanimmunizationhistoryinresponsetoaqueryfor animmunizationhistoryfromanothersystem.
Standard Reference HL7 version 2.5 Message Type:RSP
Preconditions:Asendingsystemreceivesarequestedimmunizationhistory.
Sequence Diagram:
Seesequencediagramsforusecase3above.
20
UseCase6SendDemographicData Goal:Tosenddemographicdataaboutaperson.Itmaybeanupdateoranewrecord. Thisusecasedoesnothaveresponsibilityfortheprocessingofthemessage.The messagewillincludeanindicationoftheexpected/requestedacknowledgement.

Standard Reference HL7 version 2.5 Message Type:
ThestandardmessagesthatmaybeusedforcarryingdemographicdataareVXUand ADT. Precondition:Auserorotheractorrequeststhatthesendingsystemsenddemographic data.

Sequence Diagram:
SeeFigure7. UseCase7AcceptDemographicData Goal:Toacceptdemographicdataaboutaperson.Itmaybeanupdateoranewrecord. Thisusecasedoesnothaveresponsibilityfortheprocessingofthemessage.The messagewillincludeanindicationoftheexpected/requestedacknowledgement.

Standard Reference HL7 version 2.5 Message Type:
ThestandardmessagesthatmaybeusedforcarryingdemographicdataareVXU,ADT. Precondition:Thereceivingsystemreceivesdemographicdata.
Sequence Diagram:
SeeFigure7.
21
Figure 2-8--Send Demographic Data Via VXU or ADT
UseCase8AcknowledgeReceipt
Scope:
Thegoalofthisusecaseistoacknowledgereceiptofamessage.Thiscanbean immunizationhistory,requestforimmunizationhistory,demographicupdate, observationreportorrequestforpersonalid.Itmayindicatesuccessorfailure.Itmay includeerrormessages.Oneexampleoccurswhenaqueryiswellformed,butfindsno candidates.Inthiscasetheacknowledgementreportsthisfact.

Standard Reference HL7 version 2.5 Message Type:ACK, RSP
Precondition:Asystemhasprocessedamessageanddeterminedthesuccessofreceipt.
Sequence Diagram:
Seesequencediagramsforusecasesabove.
22
UseCase9ReportError
Scope:
Thegoalofthisusecaseistosenderrormessagesrelatedtomessages.
Standard Reference HL7 version 2.5 Message Type: ACK, RSP
Precondition:Asystemhasprocessedamessageandfounderrors.
Sequence Diagram:
Seesequencediagramsforusecasesabove.
MessagingintheContextoftheBusinessProcess
Whilethisdocumentfocusesontheformatandcontentofmessagesfromonesystem toanother,itisusefultounderstandwherethisfitsintothebiggerpictureof interoperablecommunication. ThefollowingdiagramillustratesthemostcommonmessageexchangeintheIIS context,theVXU(unsolicitedimmunizationrecord).Whenthesendingsystemwishesto sendaVXUtoareceivingsystem,itmustdoseveralstepsinpreparation: o Createmessage 9 o Assembledataonpersonofinterest o BuildtheVXUmessagewiththisdata o Sendthemessage o Connecttothereceivingsystem.Thepartnersmustagreeonhowthisis done. o Thesendingsystemnowsendsthemessageovertheconnectionandthe receivingsystemcatchesthemessage. Thereceiveraccomplishesthefollowingsteps: o Processthereceivedmessage o Determinethatthemessageisintheappropriateformat. o Parsethemessageintoaformatthatituses. o Evaluatethemessagecomponentstodeterminethatthesearecorrectly formattedandspecified. o Sendanacknowledgementtothesender,indicatingthemessagehasbeen successfullyprocessed.
Identifying which clients record to send is an important consideration, but outside the scope of this document. HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 23 1/31/2011
o Integratethereceivedrecordintotheexistingdatabase. 10 o Deduplicateonclienttobesurethateachclientonlyhasonerecord. o Deduplicatetheevents(immunizations,forinstance). o Insertorupdatedata. Obviously,theinteractionmaybemorecomplexthanthis 11 .Theconnectionmaybe rejectedorfail.Themessagemaybepoorlyformedormaynotcontainrequired information.Partofthemessagemaycontainerrors,buttheseerrorsarenotsufficient torejecttheentiremessage. Thebusinessrulesforboththesenderandthereceivershouldbeclearlyspecifiedso thateachsideunderstandshowthemessagewillbehandled. Whenillustratingtheprocessesinvolvedineachmessagebelow,wewillnotelaborate ontheprocessesthatoccuroutsidetheactualmessageexchange.
10 11
Local business rules determine how this occurs and should be documented clearly. See Appendix B for illustrations of the processing rules expected when handling HL7 messages. HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011
24
Figure 2-9--VXU Process Model

Note: It is vital that each implementation clearly document the business rules and special handling in a local Implementation Guide or Profile. Local implementers may place further constraints on the specifications found in this Guide. Optional fields or required fields that are allowed to be empty in this Guide may be made required. Repeating fields may be constrained to fewer repetitions.
AppendixBgivesdetailedexamplemessagesandhasillustrationofthebusiness processessurroundingothermessagetransactions.
25
Chapter 3: HL7 Messaging Infrastructure
3. HL7 Messaging Infrastructure

Thissectionwillcontainabasicdescriptionofthetermsanddefinitions,whichareused inthisdocumentinordertounderstandtheHealthLevel7standardasitappliesto immunizationinformationsystems.MoredetailmaybefoundintheHL72.5.1standard inChapters1,2and2A.
HL7definitions
Thetermsbelowareorganizedtomovefromthemessagetosubsequentlymore granularcomponents. Message:Amessageistheentireunitofdatatransferredbetweensystemsinasingle transmission.Itisaseriesofsegmentsinasequencedefinedbythemessage specifications.ThesespecificationsarebasedonconstraintstotheHL7specifications,as describedinanImplementationGuide. Example: Segment Description MSH| MessageHeader PID| PersonalIdentifiers ORC| OrderSegment RXA| Vaccineadministeredsegment ThetableaboveshowsanimmunizationhistoryforthepatientidentifiedinthePID.This personhasoneimmunizationorderedandrecorded. Segment:Asegmentisalogicalgroupingofdatafields.Segmentswithinadefined messagemayberequiredoroptional,mayoccuronlyonce,ormaybeallowedto repeat.EachsegmentisnamedandisidentifiedbyasegmentID,aunique3character code. Example:
PID|||12322^^Âssigning authority^MR^||Savage^Robert^^^^^L^|
ThisPIDsegmentincludesamedicalrecordnumberandapersonsname. Field:Afieldisastringofcharactersandisofaspecificdatatype.Eachfieldisidentified bythesegmentitisinanditspositionwithinthesegment;e.g.,PID5isthefifthfieldof thePIDsegment.Amaximumlengthofthefieldisstatedasnormativeinformation. Exceedingthelistedlengthshouldnotbeconsideredanerror.Afieldisboundedbythe |character.
26
Component:Acomponentisoneofalogicalgroupingofitemsthatcomprisethe contentsofacodedorcompositefield.Withinafieldhavingseveralcomponents,notall componentsarerequiredtobevalued. Example:RXA5administeredcodeiscomposedof6components.

Code 1^text 1^code set 1âlternate code 2âlt text 2âlt code set 2
Itemnumber:Eachfieldisassignedauniqueitemnumber.Fieldsthatareusedinmore thanonesegmentwillretaintheiruniqueitemnumberacrosssegments. Nullandemptyfields:Thenullvalueistransmittedastwodoublequotemarks().A nullvaluedfielddiffersfromanemptyfield.Anemptyfieldshouldnotoverwrite previouslyentereddatainthefield,whilethenullvaluemeansthatanypreviousvalue inthisfieldshouldbeoverwritten.

Value in Field || <empty field> || Meaning Nullify the value recorded in the receiving system data base. Make no changes to the record in the receiving data base. The sending system has no information on this field.
Nullfieldsshouldnotbesentinimmunizationmessages.Systemswhichwillsendnull fields()mustspecifytheiruseinlocalimplementationguides.Systemswhichwill acceptandprocessnullfields,asdescribedabove,mustspecifytheiruseinlocal implementationguides. Datatype:Adatatyperestrictsthecontentsandformatofthedatafield.Datatypesare givena2or3lettercode.Somedatatypesarecodedorcompositetypeswithseveral components.Theapplicabledatatypeislistedanddefinedineachfielddefinition. CodeSets/Systems:Mostdataelementswillhaveassociatedlistsofacceptablevalues intablessupportedbyastandardsorganizationsuchasHL7orCDC.Thesecodesetswill includedefinitionstosupportcommonusage. Delimiters:Delimitercharactersareusedtoseparatesegments,fieldsandcomponents inanHL7message.ThedelimitervaluesaregiveninMSH2andusedthroughoutthe message.Applicationsmustuseagreedupondelimiterstoparsethemessage.Messages usedinthisGuideshallusethefollowingdelimiters: <CR>=SegmentTerminator; |=FieldSeparator; ^=ComponentSeparator; &=SubComponentSeparator; ~=RepetitionSeparator;
27
\=EscapeCharacter. Messagesyntax:Eachmessageisdefinedinspecialnotationthatliststhesegment3 letteridentifiersintheordertheywillappearinthemessage.Braces,{},indicatethat oneormoreoftheenclosedgroupofsegmentsmayrepeat,andbrackets,[],indicate thattheenclosedgroupofsegmentsisoptional.Notethatsegmentsmaybenested withinthebracesandbrackets.Thiswillindicatethatthenestedsegmentsareunits withinasubgroupofsegments.TheirUsageisrelativetotheparentsegmentinthe group. Zsegments:Allmessagetypes,triggereventcodes,andsegmentIDcodesbeginning withZarereservedforlocallydefinedmessages.Nosuchcodeswillbedefinedwithin theHL7Standard.TheusersofthisGuidehaveagreedtoeliminateZsegmentsfrom theirimplementationsinordertoproduceastandardmethodthatwillbeused nationallytotransmitimmunizationdata.Thequeryprofiledinthisdocumentdoes haveanamecodewhichbeginswithZasspecifiedbyHL7.
BasicMessageConstructionRules
EncodingRulesforSending 1.Encodeeachsegmentintheorderspecifiedintheabstractmessageformat. 2.PlacetheSegmentIDfirstinthesegment. 3.Precedeeachdatafieldwiththefieldseparator. 4.Encodethedatafieldsintheorderanddatatypespecifiedinthesegmentdefinition table. 5.Endeachsegmentwiththesegmentterminator. 6.Components,subcomponents,orrepetitionsthatarenotvaluedattheendofafield neednotberepresentedbycomponentseparators.Thedatafieldsbelow,forexample, areequivalent: |^XXX&YYY&&^|isequalto|^XXX&YYY^| |ABC^DEF^^| isequalto|ABC^DEF| 7.Components,subcomponents,orrepetitionsthatarenotvalued,butprecede components,subcomponentsorrepetitionsthatarevaluedmustberepresentedby
28
appropriateseparators.Forexample,thefollowingCEdatatypeelementhasthefirst triplicateemptyandapopulatedsecondtriplicate:
|^^ÂBC^Text^Codesystem|
8.Ifafieldallowsrepetition(Cardinalitymaximum>1),thenthelengthofthefield appliestoEACHrepetition. EncodingRulesforReceiving 1.Ifadatasegmentthatisexpectedisnotincluded,treatitasifalldatafieldswithin werenotpresent. 2.Ifadatasegmentisincludedthatisnotexpected,ignoreit;thisisnotanerror. 3.Ifdatafieldsarefoundattheendofadatasegmentthatarenotexpected,ignore them;thisisnotanerror. ImplicationsoftheEncodingRules Thefollowingtableliststheexpectedoutcomeimpliedbytheencodingrulesabove.
Table 3-1 Outcome of Encoding Rule Breaches
Condition Requiredsegmentnot present. Segmentsnotincorrect order Segmentnotexpected Nonrepeatingsegmentis repeated Requiredsegmenthas requiredfieldsthatarenot presentorrejecteddueto errors Optionalsegmenthas requiredfieldthatisnot presentorrejecteddueto errors.
ImmediateOutcome Messagerejected. Outofsequencesegment ignored. Segmentisignored Repeatedsegmentis ignored.Firstsegmentis processednormally. Messageisrejected.
SecondaryOutcome Errormessagereturnedto sendingsystem. Ifthissegmentisrequired, thenmessagerejected. Informationintherepeated segmentislosttoreceiving system. Errormessagereturnedto sendingsystem.
Segmentisignored
Messageisnotrejected becauseofthiserror.Error messagereturned. 29
Condition Requiredfieldisnot present.
ImmediateOutcome Segmentis ignored/rejected.
Requiredfieldisrejected duetoerrors.
Segmentis ignored/rejected.
Incomingdatavalueisnot Incomingdataaretreated inthelistofexpected asempty. valuesforafieldthatis constrainedtoalistof values. Notethatallerrorsinprocessingamessageshouldbecommunicatedbacktothe sendingsystemunlesstheinitiatingsystemhasindicatedthatnoresponseisdesired.
SecondaryOutcome Ifsegmentisrequired,then messageisrejected.If segmentisnotrequired, theinformationinthe segmentislosttoreceiving system. Ifsegmentisrequired,then messageisrejected.If segmentisnotrequired, theinformationinthe segmentislosttoreceiving system.
DeterminingUsageofSegments,FieldsandComponents ManyfieldsandsegmentsinHL7areoptional.Thisguidetightensconstraintsonsome fieldstosupportfunctionalityrequiredfrommeaningfuluseofimmunizationdata.The followinglisttherulesappliedtothedecisionsusedtodetermineusageinthisGuide. 1.Anysegment,field,orcomponentthatisrequiredbyHL7standardisrequired. 2.AnyfieldorcomponentthatisarequiredNationalVaccineAdvisoryCommittee (NVAC)CoreDataelementisrequiredbutmaybeempty 12 . 3.AnysegmentthatcontainsarequiredNVACCoredataelementisrequiredbutmaybe empty. 4.Anysegment,field,orcomponentthatisretainedforbackwardcompatibilityin Version2.5.1shallbeunsupportedinthisGuide. 5.Anysegment,field,orcomponentthatisconditionalbutmaybeemptyinVersion 2.5.1shallbeconditionalorconditionalbutmaybeemptyinthisGuide,unlessthis conflictswith2or3above.
12
In some cases they may not be empty. Client name may never be empty or null, for instance. HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 30 1/31/2011
6.Allotherfieldswillbeleftoptional.
Table 3-1--Usage Code Interpretations for Fields, Components and Sub-components
UsageCode R
Interpretation Required
RE
Requiredbutmay beempty
Comment Aconformingsendingapplicationshallpopulateall Relementswitha nonemptyvalue. Conformingreceivingapplicationshallprocessor ignoretheinformationconveyedbyrequired elements. Aconformingreceivingapplicationmustnotraise anerrorduetothepresenceofa requiredelement,butmayraiseanerrordueto theabsenceofarequiredelement. Theelementmaybemissingfromthemessage, butmustbesentbythesendingapplicationif thereisrelevantdata. Aconformingsendingapplicationmustbecapable ofprovidingall"RE"elements.Ifthe conformingsendingapplicationknowsthe requiredvaluesfortheelement,thenitmustsend thatelement.Iftheconformingsending applicationdoesnotknowtherequiredvalues, thenthatelementwillbeomitted. Receivingapplicationswillbeexpectedtoprocess orignoredatacontainedintheelement,butmust beabletosuccessfullyprocessthemessageifthe elementisomitted(noerrormessageshouldbe generated becausetheelementismissing).
31
UsageCode C
Interpretation Conditional
Comment Thisusagehasanassociatedconditionpredicate. Thispredicateisanattributewithinthemessage. Ifthepredicateissatisfied: Aconformantsendingapplicationmustalways sendtheelement. Aconformantreceivingapplicationmustprocess orignoredataintheelement.Itmayraiseanerror iftheelementisnotpresent. IfthepredicateisNOTsatisfied: AconformantsendingapplicationmustNOTsend theelement. AconformantreceivingapplicationmustNOTraise anerroriftheconditionpredicateisfalseandthe elementisnotpresent,thoughitmayraisean erroriftheelementISpresent.
32
Comment Thisusagehasanassociatedconditionpredicate. Thispredicateisanattributewithinthemessage. Ifthepredicateissatisfied: Iftheconformingsendingapplicationknowsthe requiredvaluesfortheelement,thenthe applicationmustsendtheelement. Iftheconformingsendingapplicationdoesnot knowthevaluesrequiredforthiselement, thentheelementshallbeomitted.The conformingsendingapplicationmustbecapable ofknowingtheelement(whenthepredicateis true)forallCEelements. Iftheelementispresent,theconformantreceiving applicationshallprocessorignorethevaluesof thatelement.Iftheelementisnotpresent. Theconformantreceivingapplicationshallnot raiseanerrorduetothepresenceorabsenceof theelement. Ifthepredicateisnotsatisfied: Theconformantsendingapplicationshallnot populatetheelement. Theconformantreceivingapplicationmayraisean applicationerroriftheelementispresent. O Optional Thiselementmaybepresentifspecifiedinlocal profile.Localpartnersmaydevelopprofilesthat supportuseofthiselement.Intheabsenceofa profile,conformantsendingapplicationswillnot sendtheelement. Conformantreceivingapplicationswillignorethe elementifitissent,unlesslocalprofilespecifies otherwise.Conformantreceivingapplicationsmay notraiseanerrorifitreceivesanunexpected optionalelement. X NotSupported Theelementisnotsupported.Sending applicationsshouldnotsendthiselement. Receivingapplicationsshouldignorethiselement ifpresent.Areceivingapplicationmayraisean HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 33
1/31/2011
UsageCode CE
Interpretation Conditionalbut maybeempty
UsageCode
Interpretation
Comment errorifitreceivesanunsupportedelement.Any profilebasedonthisGuideshouldnotspecifyuse ofanelementthatisnotsupportedinthisGuide.
Elementsthatareoptionalorarenotsupportedforuseinimmunizationmessageswill benotedintheelementtable,butnotintheelementdefinitiontextthatfollow.
Table 3-2--Usage Code Interpretation for Segments
UsageCode R
Interpretation Required
RE
Requiredbutmay beempty
Optional
Comment Aconformingsendingapplicationshallincludeall Rsegments. Conformingreceivingapplicationshallprocessall requiredsegments. Aconformingreceivingapplicationmustprocess allrequiredsegments.Itshouldraiseanerrordue totheabsenceofarequired segment. Thesegmentmaybemissingfromthemessage, butmustbesentbythesendingapplicationif thereisrelevantdata. Aconformingsendingapplicationmustbecapable ofprovidingall"RE"segments.Ifthe conformingsendingapplicationhasdataforthe requiredsegment,thenitmustsendthat segment. Receivingapplicationswillbeexpectedtoprocess thedatacontainedinthesegment.Itmustbeable tosuccessfullyprocessthemessageifthesegment isomitted(noerrormessageshouldbegenerated becausethesegmentismissing). Thissegmentmaybepresentifspecifiedinlocal profile.Localpartnersmaydevelopprofilesthat supportuseofthissegment.Intheabsenceofa profile,conformingsendingapplicationswillnot sendtheelement.Conformantreceiving applicationswillignoretheelementifitissent, unlesslocalprofilespecifiesotherwise. 34
UsageCode X
Interpretation NotSupported
Comment Thesegmentisnotsupported.Sending applicationsshouldnotsendthiselement. Receivingapplicationsshouldignorethiselement ifpresent.AnyprofilebasedonthisGuideshould notspecifyuseofanelementthatisnot supportedinthisGuide.
MessageAttributesCommontoAllMessages
ThefollowingdescribehowmessagespecificationswillbeillustratedinthisGuide. ThesetermswillbeusedinthetablesspecifyingmessagesthroughoutthisGuide.
Table 3-3--Message Attributes
MessageAttributes Attribute Description Threecharactercodeforthesegmentandtheabstractsyntax (i.e.,thesquareandcurlybraces) [ XXX ] Optional { XXX } Repeating XXX Required(notinsideanybraces) [{ XXX }]OptionalandRepeating Segment
[ XXX ]
[YYY]
Name Usage
Cardinality
YYYisnestedwithinthesegmentblockstartingwithXXX.Itisan optionalsubsegmenttoXXX 13 .Thewholeblockisoptional. NotethatforSegmentGroupstherewillnotbeasegmentcode present,butthesquareandcurlybraceswillstillbepresent. NameoftheSegmentorSegmentgroupelement. Usageofthesegment.Indicatesifthesegmentisrequired, optional,ornotsupportedinamessage.SeetablewithUsage CodeInterpretationabove. Indicatoroftheminimumandmaximumnumberoftimesthe elementmayappear. [0..0] Elementneverpresent. [0..1] Elementmaybeomittedanditcanhaveatmost,one
13
YYY may only be included if XXX is present. XXX may be present without YYY. HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011
35
occurrence. [1..1] ElementmusthaveexactlyoneOccurrence. [0..n] Elementmaybeomittedormayrepeatuptontimes. [1..n] Elementmustappearatleastonce,andmayrepeatupto ntimes. [0..*]Elementmaybeomittedorrepeatforanunlimitednumber oftimes. [1..*]Elementmustappearatleastonce,andmayrepeat unlimitednumberoftimes. [m..n]Elementmustappearatleastmand,atmost,ntimes.
SegmentAttributesCommontoAllSegments
Theabbreviatedtermsandtheirdefinitions,asusedinthesegmenttableheadings,are asfollows:
Table 3-4--Segment Attributes
Abbreviation Description Seq Sequenceoftheelements(fields)astheyarenumberedinthesegment Recommendedmaximumlengthoftheelement.Lengthsareprovided onlyforprimitivedatatypes. Lengthsshouldbeconsideredrecommendations,notabsolutes.The Len receivermaytruncatefields,components,andsubcomponentslonger thantherecommendedlength.Thereceivershouldnotfailtoprocessa messagesimplybecausefields,components,orsubcomponentsaretoo long. DataType DatatypeusedforHL7element.Datatypespecificationscanbefoundin Chapter4. IndicateswhetherthefieldissupportedinthisGuide.Indicatesifthe field,component,orsubcomponentisrequired,optional,orconditional inthecorrespondingsegment,field,orcomponent.SeeUsageCode Interpretation,above. Note:Arequiredfieldinanoptionalsegmentdoesnotmeanthe Usage segmentmustbepresentinthemessage.Itmeansthatifthesegmentis present,therequiredfieldswithinthatsegmentmustbepopulated.The sameappliestorequiredcomponentsofoptionalfields.Ifthefieldis populated,thentherequiredcomponentmustbepopulated.Thesame appliestorequiredsubcomponentsofoptionalcomponents.Ifa componentispopulated,therequiredsubcomponentsofthat componentmustalsobepopulated.
36
Abbreviation Description Indicatoroftheminimumandmaximumnumberoftimestheelement mayappear. [0..0] Elementneverpresent. [0..1] Elementmaybeomittedandcanhaveatmost,oneoccurrence. [1..1] Elementmusthaveexactlyoneoccurrence. [0..n] Elementmaybeomittedormayrepeatuptontimes. Cardinality [1..n] Elementmustappearatleastonce,andmayrepeatupton times. [0..*] Elementmaybeomittedorrepeatforanunlimitednumberof times. [1..*] Elementmustappearatleastonce,andmayrepeatunlimited numberoftimes. [m..n] Elementmustappearatleastmand,atmost,ntimes. Item# UniqueitemidentifierinHL7 HL7Element HL7descriptoroftheelementinthesegment. Name Comment ListsanyconstraintsimposedandothercommentsinthisGuide
37
Chapter 4: HL7 Data Types
4. HL7 Data Types

Datatypesarethebuildingblocksthatarethefoundationofsuccessfulinteroperability.Each field,componentorsubcomponenthasadatatype.Conformingsystemsagreetoadheretothe datatypeassignedtoeachcomponent,assuringsmoothcommunication.Forexample,dates maybeformattedinmanyways,buttoassureinteroperability,theseneedtobeconstrained anddefined.HL7specifiesseveralformats,butthesearecompatiblewitheachother.They allowdatestobeasgranularasneeded.Theformatallowsforjustayear(YYYY)orformonth, day,year,hour,minute,second,etc. AppendixAcontainsthetablesofvaluesetsreferencedbythesedatatypes.
DataTypesforIISUse
Datatypesspecifytheformatandtypeofdataused.Adatatypemaybeassimpleasanumeric datatype,whichallowsanumber.Itmaybeamorecomplexcodedentrythatrequiresa specificsetofcodevaluesandthenameofthecodesystem.Datatypesmaycontain subcomponentsthatarespecifiedbydatatypes. Thefollowinglistofdatatypesonlyincludesthosethatareusedbyfieldsthatareanticipated forIISuse.DatatypesforfieldsthatarenotusedinthisGuidearenotincluded,eveniftheyare partofsegmentthatisused.
38
Chapter 4: HL7 Data Types Table 4-1-- Data Types Data type CE CQ CWE CX DT DTM EI ERL FC FN HD ID IS LA2 MSG NM PT SAD SI ST TS VID XAD XCN XPN XTN Data Type Name Coded element Composite Quantity with Units Coded with Exceptions Extended Composite Id with Check digit Date Date/Time Entity Identifier Error Location Financial Class Family Name Hierarchic Designator Coded Values for HL7 Tables Coded value for User-Defined Tables Location with address variation 2 Message Type Numeric Processing Type Street Address Sequence ID String Time Stamp Version Identifier Extended Address Extended Composite ID Number and Name for Persons Extended Person Name Extended telephone number
CECodedElement(mostuses) Definition:Thisdatatypetransmitscodesandthetextassociatedwiththecode. ThefollowingspecificationsapplytoallusesofCEdatatypeEXCEPTRXA9,Administration Notes.Thatfieldmayusethisspecificationorthespecificationthatfollowsthissection.
39
Chapter 4: HL7 Data Types Table 4-2 Coded Element (CE) SEQ 1 LEN 999 Data Type ST Usage RE Value Set Component Name Identifier Comments Identifying Code. Human readable text that is not further used. If Sequence 1 is populated, this should also be populated. If sequence 1 is populated, this field must be populated. Alternate Identifying coded. Human readable text that is not further used. If Sequence 4 is populated, this should also be populated. If sequence 4 is populated, this field must be populated.
2 3 4
999 20 999
ST ID ST
CE C RE
0396
Text Name of Coding Alternate Identifier
5 6
999 20
ST ID
CE C
0396
Alternate Text Name of Alternate
Note: Sequence 1,2, and 3 are one triplet that are treated as a unit. The other triplet is a separate unit. Either may be populated, but should mean the same thing if both are populated. The order of the contents is not specified. In the previous guide, the first triplet was reserved for CVX codes in RXA-5. This is no longer true, based on HL7 usage of CE data type.
Identifier (ST)
Definition: Sequence of characters (the code) that uniquely identifies the item being referenced. Different coding schemes will have different elements here.
Text (ST)
Definition: The descriptive or textual name of the identifier, e.g., DTaP. This is not used by the sending or receiving system, but rather facilitates human interpretation of the code.
Name of Coding System (ID)

Definition: Identifies the coding scheme being used in the identifier component. The combination of the identifier and name of coding system components will be a unique code for a data item. Each system has a unique identifier.
Alternate Identifier (ST)

Definition: An alternate sequence of characters (the code) that uniquely identifies the item being referenced. See usage note in section introduction.
Alternate Text (ST)

Definition: The descriptive or textual name of the alternate identifier, e.g., DTaP. This is not used by the sending or receiving system, but rather facilitates human interpretation of the code.
40
Name of Alternate Coding System (ID)

Definition: Identifies the coding scheme being used in the alternate identifier component.
Exampleusage: FromRXA5,AdministeredCode: |50^DTAPHIB^CVX^90721^DTAPHIB^C4| CECodedElement(textonlyinRXA9) Definition:Thisdatatypemaybeusedtotransmittextonlynotes. ThefollowingspecificationsapplytouseofCEdatatypeforRXA9,administrationnotesonly.

Table 4-3 Coded Element (CE) for Text Only RXA-9 SEQ 1 2 3 4 5 6 LEN 999 999 20 999 999 20 Data Type ST ST ID ST ST ID Usage X R X X X X Value Set Component Name Identifier Text Name of Coding Alternate Identifier Alternate Text Name of Alternate Human readable text that is not further processed. Comments

0396

HL7039 0396
Note: Sequence 1,2, and 3 are one triplet that are treated as a unit. The other triplet is a separate unit. Either may be populated, but should mean the same thing if both are populated. When transmitting text note only, only the first triplet shall be populated.
Text (ST)
Definition: Free text note regarding the immunization reported in this RXA.
CQCompositeQuantitywithUnits
Definition: This data type carries a quantity and attendant units. Its primary use in this Guide will be for indicating the maximum number of records to return in a query response.
41
Chapter 4: HL7 Data Types Table 4-4 Composite Quantity with Units (CQ)
SEQ 1 LEN 16 Data Type NM Usage R Value set COMPONENT NAME Quantity COMMENTS The value shall be a positive integer. 2 CE R 0126 Units The value shall be RD (records).
MaximumLength:500 Note: CQcannotbelegallyexpressedwhenembeddedwithinanotherdatatype.Itsuseis constrainedtoasegmentfield.

Examples:
|10^RD| 10 records
Quantity (NM)
Definition: This component specifies the numeric quantity or amount of an entity.
Units (CE)
Definition: This component species the units in which the quantity is expressed. Field-by-field, default units may be defined within the specifications. When the quantity is measured in the default units, the units need not be transmitted. If the quantity is recorded in units different from the default, the units must be transmitted.
CWECodedWithExceptions
Definition: Specifies a coded element and its associated detail. The CWE data type is used when 1) more than one table may be applicable or 2) the specified HL7 or externally defined table may be extended with local values or 3) when text is in place, the code may be omitted.
42
Chapter 4: HL7 Data Types Table 4-5 Coded with Exceptions (CWE)
Data SEQ LEN Type Usage Value Set Component Name Comments
999
ST
RE
Identifier
Identifying Code. Human readable text that is not further used. If Sequence 1 is populated, this should also be populated. If sequence 1 is populated, this field must be populated. Alternate Identifying code. Human readable text that is not further used. If Sequence 4 is populated, this should also be populated. If sequence 4 is populated, this field must be populated.
2 3 4
999 20 999
ST ID ST
CE CE RE
0396
Text Name of Coding Alternate Identifier
5 6 7 8 9
999 20 10 10 199
ST ID ST ST ST
CE CE O O O
0396
Alternate Text Name of Alternate Coding System Version Id Alternate Coding System Version Id Original Text
Note: Sequences 1,2 and 3 are one triplet that are treated as a unit. The other triplet is a separate unit. Either may be populated, but should mean the same things if both are populated. The order of the contents is not specified. In the previous guide, the first triplet was reserved for CVX codes in RXA-5. This is no longer true, based on HL7 usage of CE data type.
Identifier (ST)
Definition: Sequence of characters (the code) that uniquely identifies the item being referenced. Different coding schemes will have different elements here.
Text (ST)
Definition: The descriptive or textual name of the identifier, e.g., DTaP. This is not used by the sending or receiving system, but rather facilitates human interpretation of the code.
Name of Coding System (ID)

Definition: Identifies the coding scheme being used in the identifier component. The combination of the identifier and name of coding system components will be a unique code for a data item. Each system has a unique identifier.
Alternate Identifier (ST)

Definition: An alternate sequence of characters (the code) that uniquely identifies the item being referenced. See usage note in section introduction.
43
Alternate Text (ST)

Definition: The descriptive or textual name of the alternate identifier, e.g., DTaP. This is not used by the sending or receiving system, but rather facilitates human interpretation of the code.
Name of Alternate Coding System (ID)

Definition: Identifies the coding scheme being used in the alternate identifier component.
Exampleusage: FromRXR:|C28161ÎM^NCITÎMÎNTRAMUSCULAR^HL70162| CXExtendedCompositeIDWithCheckDigit

Table 4-6 Extended Composite ID with Check Digit(CX)
SEQ 1 2 3 LEN 15 1 3 Data Type ST ST ID Usage R O CE 0061 Value set COMPONENT NAME ID Number Check Digit Check Digit Scheme If sequence 2 is populated, then this sequence must be populated. 4 5 5 HD ID R R 0363 0203 Assigning Authority Identifier Type Code 6 7 8 9 8 8 HD DT DT CWE O O O O Assigning Facility Effective Date Expiration Date Assigning Jurisdiction 10 CWE O Assigning Agency or Department COMMENTS
Definition: This data type is used for specifying an identifier with its associated administrative detail.
Maximum Length: 1913
Note: The check digit and check digit scheme are empty if ID is alphanumeric.
Example:
|1234567^^^ME129^MR|
44
ID (ST)
Definition: The value of the identifier itself.
Check Digit (ST)

This component should be valued empty.
Check Digit Scheme (ID)

This component should be valued if Check digit is populate, otherwise it should be empty.
Assigning Authority (HD)

The assigning authority is a unique name of the system (or organization or agency or department) that creates the data. . Refer to User-defined Table 0363 Assigning authority for suggested values. This table shall be maintained by each IIS. The first component shall be used for this unique name. The second and third may be used if OIDs 14 are recorded.
Identifier Type Code (ID)

A code corresponding to the type of identifier. In some cases, this code may be used as a qualifier to the Assigning authority component. Refer to HL7 Table 0203 - Identifier type for suggested values.
DTDate
Definition: Specifies the century and year with optional precision to month and day. Table 4-7 Date (DT) SEQ 1 LEN 8
Data Type
Usage R
Value Set
Component Name Date
Comments
As of v 2.3, the number of digits populated specifies the precision using the format specification YYYY(MM[DD]). Thus: Examples:
|19880704| |199503| |2000|
Four digits are used to specify a precision of "year" Six are used to specify a precision of "month" Eight are used to specify a precision of "day."
14
OIDs are object identifiers. According to wikipeida: Health Level Seven (HL7), a standards-developing organization in the area of electronic health care data exchange, is an assigning authority at the 2.16.840.1.113883 (joint-iso-itu-t.country.us.organization.hl7) node. HL7 maintains its own OID registry, and as of January 1, 2008 it contained almost 3,000 nodes, most of them under the HL7 root. The Centers for Disease Control and Prevention has also adopted OIDs to manage the many complex values sets or "vocabularies" used in public health. The various OIDs are available in the Public Health Information Network (PHIN) Vocabulary Access and Distribution System (VADS).
45
DTMDate/Time
Table 4-8 Date/Time (DTM)
Data
SEQ
LEN 24
Type
Usage R
Value Set
Component Name Date/time
Comments
The number of characters populated (excluding the time zone specification) specifies the precision. Format: YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ]. Thus: Four digits are used to specify a precision of "year" Six are used to specify a precision of "month" Eight are used to specify a precision of "day." the first ten are used to specify a precision of "hour the first twelve are used to specify a precision of "minute the first fourteen are used to specify a precision of "second the first sixteen are used to specify a precision of "one tenth of a second the first nineteen are used to specify a precision of " one ten thousandths of a second
When the time zone is not included, it is presumed to be the time zone of the sender. Example: |199904| specifies April 1999.
EIEntityIdentifier
Definition: The entity identifier defines a given entity within a specified series of identifiers.
Table 4-9 Entity Identifier (EI)

SEQ 1 2 LEN 199 20 Data Type ST IS Usage RE C 0363 Value Set COMPONENT NAME Entity Identifier Namespace ID If Universal Id is not populated, then this field shall be populated. 3 199 ST CE Universal ID If Namespace ID is not populated, then this field shall be populated. When populated, it shall be an OID. 4 6 ID C 0301 Universal ID Type If Universal Id is populated, this field must also be populated. When populated, it shall be constrained to ISO. COMMENTS
Maximum Length: 427
46
Entity Identifier (ST)

The first component, <entity identifier>, is defined to be unique within the series of identifiers created by the <assigning authority>, defined by a hierarchic designator, represented by component 2.
Namespace ID (IS)
The assigning authority is a unique identifier of the system (or organization or agency or department) that creates the data. Refer to User-defined Table 0363 Assigning authority for suggested values.
Universal ID (ST)
This is a universal id associated with this entity. It must be linked to the Universal Id Type below. If populated, it shall be an OID.
Universal ID Type (ID)

This universal id type is drawn from HL7 Table 0301. If populated, it shall be ISO.
Example: FromMSH21profileidentifier: |Z34^CDCPHINVS| ERLErrorLocation

Table 4-10 Error Location (ERL)
SEQ 1
LEN 3
Data Type ST
Usage R
Value Set
COMPONENT NAME Segment ID
COMMENTS The 3-character name for the segment (i.e. PID)
2 3
2 2
NM NM
R RE
Segment Sequence Field Position This should not be populated if the error refers to the whole segment.
NM
RE
Field Repetition
This should be populated whenever Field Position is populated.
NM
RE
Component Number
Should be populated ONLY when a particular component cause the error.
47

6 2 NM RE Sub-Component Number Should be populated ONLY when a particular sub-component cause the error.
Definition: This data type identifies the segment and its constituent where an error has occurred.
Maximum Length: 18
Segment ID (ST)
Definition: Specifies the 3-letter name for the segment.
Segment Sequence (NM)

Definition: Identifies the segment occurrence within the message. That is, for the first instance of the segment in the message the number shall be 1.
Field Position (NM)

Definition: Identifies the number of the field within the segment. The first field is assigned a number of 1. Field number should not be specified when referring to the entire segment.
Field Repetition (NM)

Definition: Identifies the repetition number of the field. The first repetition is counted as 1. If a Field Position is specified, but Field Repetition is not, Field Repetition should be assumed to be 1. If Field Position is not specified, Field Repetition should not be specified.
48
Component Number (NM)

Definition: Identifies the number of the component within the field. The first component is assigned a number of 1. Component number should not be specified when referring to the entire field.
Sub-Component Number (NM)

Definition: Identifies the number of the sub-component within the component. The first subcomponent is assigned a number of 1. Sub-component number should not be specified when referring to the entire component.
Example: |RXA^1^5^1^3| FCFinancialClass Definition:Thisdatatypeidentifiesthefinancialclassapersonbelongsto.

Table 4-11 Financial Class (FC)
SEQ 1 2 LEN 20 Data Type IS TS Usage R RE Value Set 0064 COMPONENT NAME Financial Class Code Effective Date COMMENTS
Maximum Length: 47
Financial Class Code (IS)

This component contains the financial class assigned to a person. User-defined Table 0064 Financial class is used as the HL7 identifier for the user-defined table of values for this component.
Effective Date (TS)

This component contains the effective date/time of the persons assignment to the financial class specified in the first component. For instance, this is used to indicate when a persons financial class was determined.
ExamplefromPV1:|V01^20090101| FNFamilyName Definition:Thisdatatypecontainsapersonsfamilynameorsurname.
49
Chapter 4: HL7 Data Types Table 4-12 Family Name

SEQ 1 2 3 4 LEN 50 20 50 20 Data Type ST ST ST ST Usage R O O O Value Set COMPONENT NAME Surname Own Surname Prefix Own Surname Surname Prefix From Partner/Spouse 5 50 ST O Surname From Partner/Spouse COMMENTS
Surname (ST)
This is the person's last name.
ExamplefromPID:|Anyperson| HDHierarchicDesignator HITSP is recommending the use of OIDs in fields using this data type. Definition:HDidentifiesan(administrativeorsystemorapplicationorother)entitythathas responsibilityformanagingorassigningadefinedsetofinstanceidentifiers(suchasplaceror fillernumber,patientidentifiers,provideridentifiers,etc.).Thisentitycouldbeaparticular healthcareapplicationsuchasaregistrationsystemthatassignspatientidentifiers,a governmentalentitysuchasalicensingauthoritythatassignsprofessionalidentifiersordrivers licensenumbers,orafacilitywheresuchidentifiersareassigned.
Table 4-13 Hierachical Designator (HD)
SEQ 1 LEN 20 Data Type IS Usage CE Value Set 0300 0361 0362 0363 COMPONENT NAME Namespace ID COMMENTS This field is used for a locally defined name/id. It may be used as previous version 2.3.1 Implementation Guide specified. If the field or component is required, then this field shall be populated if components 2 and 3 are not populated. The value set used depends on usage.
50
SEQ 2
LEN 199
Data Type ST
Usage CE
Value Set
COMPONENT NAME Universal ID
COMMENTS This field shall be populated if component 3 is populated. This field must be populated if field 1 is empty. This field shall used OID if populated
ID
CE
0301
Universal ID Type
This field shall be populated if component 2 is populated. If populated the value is constrained to ISO
IS -- Namespace ID
User-defined Table 0300/0361/0362/0363 - Namespace ID is used as the HL7 identifier for the user-defined table of values for this component.
Note: When the HD is used in a given segment (either as a field or as a component of another data type) this table may be re-defined (given a different user-defined table number and name) by the technical committee responsible for that segment. Tables 0361-0363 are preferred for most instances. For instance for identifying the assigning authority, use 0363.
Universal ID (ST)
The HDs second component, <universal ID> (UID), is a string formatted according to the scheme defined by the third component, <universal ID type> (UID type). The UID is intended to be unique over time within the UID type. It is rigorously defined. Each UID must belong to one of the specifically enumerated schemes for constructing UIDs (defined by the UID type). The UID (second component) must follow the syntactic rules of the particular universal identifier scheme (defined by the third component). Note that these syntactic rules are not defined within HL7 but are defined by the rules of the particular universal identifier scheme (defined by the third component).
Universal ID Type (ID)

The third component governs the interpretation of the second component of the HD. If the third component is a known UID refer to HL7 Table 0301 - Universal ID type for valid values, then the second component is a universal ID of that type. Since the second component is constrained to OID, then the value of component 3 shall be ISO, when populated.
ExamplefromMSH: |CA12^^| IDCodedValuesforHL7Tables Definition:ThisdatatypeisusedforcodedvaluesfromanHL7table.

The value of such a field follows the formatting rules for an ST field except that it is drawn from a table of legal values. There shall be an HL7 table number associated with ID data types. An
51
Chapter 4: HL7 Data Types example of an ID field is PID 24 Multiple Birth Indicator. This data type should be used only for HL7 tables (see Appendix A).
ExamplefromPIDMultipleBirthIndicator: |Y| ISCodedValuesforUserDefinedTables Definition:ThisdatatypeisusedforcodesfromUserdefinedTables.

Table 4-14 Coded Values for User Defined Tables (IS)
SEQ Length Data Type Usage Value Sets COMPONENT NAME COMMENTS
20 (Max.)
Coded Value for User-Defined Tables
Maximum Length: 20
The value of such a field follows the formatting rules for a ST field except that it is drawn from a site-defined (or user-defined) table of legal values. There shall be an HL7 table number associated with IS data types. This data type should be used only for user-defined tables (see Section 2.5.3.6 - Table).
ExamplefromPIDSex: |F| LA2LocationwithAddressVariation2

Definition: Specifies a location and its address. Table 4-15 Location with Address Variation 2
SEQ 1 LEN 20 Data Type IS Usage O Value Sets 0302 COMPONENT NAME Point of Care COMMENTS This represents the location within a facility that the service was provided. This is not the clinic site where an event occurred. 2 3 4 20 20 IS IS HD O O RE 0303 0304 Room Bed Facility This represents the location that the service was provided. For example the clinic. 5 6 20 20 IS IS O O 0306 0305 Location Status Patient Location Type
52
SEQ 7 8 9 10 11 12 13 14 15 16
LEN 20 20 120 120 50 50 12 3 3 50
Data Type IS IS ST ST ST ST ST ID ID ST
Usage O O O O O O O O O O
Value Sets 0307 0308
COMPONENT NAME Building Floor Street Address Other Designation City State or Province Zip or Postal Code
COMMENTS
0399 0190
Country Address Type Other Geographic Designation
Maximum Length: 790
Note: Replaces the CM data type used in 4.14.5.13 RXD-13, 4.14.6.11 RXG-11 and 4.14.7.11 RXA-11 as of V 2.5.
MSGMessageType
Definition: This field contains the message type, trigger event, and the message structure ID for the message. Table 4-16 Message Type (MSG)
SEQ 1 2 3 LEN 3 3 7 Data Type ID ID ID R R R 0076 0003 0354 Message Code Trigger Event Message Structure Usage Value Set COMPONENT NAME COMMENTS
Maximum Length: 15.
Note: Replaces the CM data type used in 2.16.9.9 MSH-9 as of v 2.5.
Message Code (ID)

Definition: Specifies the message type code. Refer to HL7 Table Message Type in section 2.17.1 for valid values. This table contains values such as ACK, ADT, ORU etc. HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011
53
Chapter 4: HL7 Data Types See section 2.5.1- Messages for further discussion.
Trigger Event (ID)

Definition: Specifies the trigger event code. Refer to HL7 Table Event Type in section 2.17.2 for valid values. This table contains values like A01, V01, R01 etc.
Message Structure (ID)

Definition: Specifies the abstract message structure code. Refer to HL7 Table 0354.
ExamplefromMSH: |VXU^V04^VXU_V04| Thethirdcomponentwasnotrequiredinversion2.3.1.Itisnowrequired. NMNumeric

Definition: A number represented as a series of ASCII numeric characters consisting of an optional leading sign (+ or -), the digits and an optional decimal point. In the absence of a sign, the number is assumed to be positive. If there is no decimal point the number is assumed to be an integer.
Table 4-17 Numeric (NM)

SEQ LEN 16 Data Type Usage Value Set COMPONENT NAME Numeric COMMENTS
Maximum Length: 16
Examples:
|999| |-123.792|
Leading zeros, or trailing zeros after a decimal point, are not significant. For example, the following two values with different representations, 01.20 and 1.2," are identical. Except for the optional leading sign (+ or -) and the optional decimal point (.), no non-numeric ASCII characters are allowed. Thus, the value <12 should be encoded as a structured numeric (SN) (preferred) or as a string (ST) (allowed, but not preferred) data type.
PTProcessingType
Definition: This data type indicates whether to process a message as defined in HL7 Application (level 7) Processing rules.
54
Table 4-18 Processing Type (PT)

SEQ 1 2 LEN 1 1 Data Type ID ID Usage R X Value Set 0103 0207 COMPONENT NAME Processing ID Processing Mode Constrain to empty, which implies current processing. COMMENTS
Maximum Length: 3
Processing ID (ID)
A value that defines whether the message is part of a production, training, or debugging system. Refer to HL7 Table 0103 - Processing ID for valid values.
SADStreetAddress
Definition: This data type specifies an entity's street address and associated detail.
Table 4-19 Street Address (SAD)

SEQ 1 2 3 LEN 120 50 12 Data Type ST ST ST R O O Usage Value Set Street or Mailing Address Street Name Dwelling Number COMPONENT NAME COMMENTS
Maximum Length: 184
Note: Appears ONLY in the XAD data type
Street or Mailing Address (ST)

Definition: This component specifies the street or mailing address of a person or institution.
SISequenceId
Definition: A non-negative integer in the form of a NM field. The uses of this data type are defined in the chapters defining the segments and messages in which it appears.
55
Table 4-20 Sequence Id (SI)

SEQ LEN 4 Data Type Usage Value set COMPONENT NAME Sequence ID COMMENTS
Maximum Length: 4. This allows for a number between 0 and 9999 to be specified.
STString
Definition: String data is left justified with trailing blanks optional. Any displayable (printable) ACSII characters (hexadecimal values between 20 and 7E, inclusive, or ASCII decimal values between 32 and 126), except the defined escape characters and defined delimiter characters.
TSTimeStamp
Definition: Specifies a point in time.
Table 4-21 Time Stamp (TS)

SEQ 1 2 LEN 24 1 Data Type DTM ID Usage R X 0529 Value Set COMPONENT NAME Time Degree of Precision COMMENTS
Maximum Length: 26
Time (DTM)
Definition: The point in time.
VIDVersionId Definition:ThisspecifiestheHL7version.
Table 4-22 Version ID (VID)
SEQ LEN Data Type ID CE CE Usage Value Set COMPONENT NAME COMMENTS
1 2 3
R O O
0104 0399
Version ID Internationalization Code International Version ID
56

Maximum Length: 973
Version ID (ID)
Used to identify the HL7 version. Refer to HL7 Table 0104 Version ID in section 2.15.9.12 for valid values.
XADExtendedAddress
Definition: This data type specifies the address of a person, place or organization plus associated information.
Table 4-23 Extended Address (XAD)

SEQ 1 2 3 4 5 6 120 50 50 12 3 LEN Data Type SAD ST ST ST ST ID RE RE RE RE RE O 0399 Usage Value Sets Street Address Other Designation City State or Province Zip or Postal Code Country Empty defaults to USA 7 8 3 50 ID ST R O 0190 Address Type Other Geographic Designation 9 10 11 12 20 20 1 IS IS ID DR O O O X 0289 0288 0465 County/Parish Code Census Tract Address Representation Code Address Validity Range deprecated as of v 2.5 13 14 TS TS O O Effective Date Expiration Date COMPONENT NAME COMMENTS
Maximum Length: 631
Note: Replaces the AD data type as of v 2.3.
57
Chapter 4: HL7 Data Types Example of usage for US:

|1000 Hospital Lane^Ste. 123Ânn Arbor ^MI^99999^^B|
This would be formatted for postal purposes as

1000 Hospital Lane Ste. 123 Ann Arbor MI 99999
Street Address (SAD)

Definition:This is the street address.
Other Designation (ST)

Definition: Second line of address. In US usage, it qualifies address. Examples: Suite 555 or Fourth Floor. This can be used for dwelling number.
City (ST)
Definition: This component specifies the city, or district or place where the addressee is located depending upon the national convention for formatting addresses for postal usage.
State or Province (ST)

Definition: This component specifies the state or province where the addressee is located. State or province should be represented by the official postal service codes for that country.
Zip or Postal Code (ST)

Definition: This component specifies the zip or postal code where the addressee is located. Zip or postal codes should be represented by the official codes for that country. In the US, the zip code takes the form 99999[-9999], while the Canadian postal code takes the form A9A9A9, and the Australian Postcode takes the form 9999.
Country (ID)
Definition: This component specifies the country where the addressee is located. HL7 specifies that the 3-character (alphabetic) form of ISO 3166 be used for the country code. Refer to HL7 Table 0399 Country code in section 2.15.9.17 for valid values.
Address Type (ID)

Definition: This component specifies the kind or type of address. Refer to HL7 Table 0190 Address type for valid values.
County/Parish Code (IS)

A code that represents the county in which the specified address resides. User-defined Table 0289 - County/parish is used as the HL7 identifier for the user-defined table of values for this component. When this component is used to represent the county (or parish), component 8 <other geographic designation> should not duplicate it (i.e., the use of <other geographic designation> to represent the county is allowed only for the purpose of backward compatibility, and should be discouraged in this and future versions of HL7). Allowable values: codes defined by government.
58
Effective Date (TS)

Definition: The first date, if known, on which the address is valid and active.
Expiration Date (TS)

Definition: The last date, if known, on which the address is valid and active.
XCNExtendedCompositeIDNumberAndNameForPersons
Definition: This data type identifies a person using a unique id and name. The ID is associated with an entity such as an organization, which assigns the ID. Table 4-24 Extended Composite ID Number and Name (XCN)
SEQ 1 LEN 15 DT ST Usage C TBL# COMPONENT NAME ID Number COMMENTS If name fields below are not populated, then this field must be populated. 2 3 4 30 30 FN ST ST RE RE RE Family Name Given Name Second and Further Given Names or Initials Thereof 5 6 7 20 20 5 ST ST IS O O X 0360 Suffix (e.g., JR or III) Prefix (e.g., DR) Degree (e.g., MD) Use Professional suffix in sequence 21. 8 4 IS O 0297 Source Table Since we are requiring assigning authority, this field may be left empty. 9 HD C 0363 Assigning Authority If the id field is populated, then this field must be populated. 10 1 ID O 0200 Name Type Code If the name fields are populated and this is empty, then the type defaults to L, legal name. 11 1 ST O Identifier Check Digit
59
SEQ 12
LEN 3
DT ID
Usage C
TBL# 0061
COMPONENT NAME Check Digit Scheme
COMMENTS If check digit identifier is populated, then this field must indicate the check digit scheme.
13
ID
0203
Identifier Type Code
Constrain to values in the published HL7 table 0203 only.
14 15 1
HD ID
O O 0465
Assigning Facility Name Representation Code
16 17 18 19 20 21 22 23 1
CE DR ID TS TS ST CWE CWE
O X X O O O O O
0448
Name Context Name Validity Range
0444
Name Assembly Order Effective Date Expiration Date Professional Suffix Assigning Jurisdiction Assigning Agency or Department
Note: Replaces CN data type as of v 2.3.
This data type is used where there is a need to specify the ID number and name of a person.
ID number (ST)
This string refers to the coded ID assigned by the assigning authority.
Family Name (FN)

This component contains the persons surname.
Given Name (ST)

First name.
Second and Further Given Names or Initials Thereof (ST)

Multiple middle names may be included by separating them with spaces.
60
Suffix (ST)
Used to specify a name suffix (e.g., Jr. or III).
Prefix (ST)
Used to specify a name prefix (e.g., Dr.).
Source Table (IS)

User-defined Table 0297 CN ID source is used as the HL7 identifier for the user-defined table of values for this component. Used to delineate the first component.
Assigning Authority (HD)

The assigning authority is a unique identifier of the system (or organization or agency of department) that creates the data. User-defined Table 0363 Assigning authority is used as the HL7 identifier for the user-defined table of values for the first sub-component of the HD component, <namespace ID>. Note: When HD data type is used as a component of another data type, its components are demoted to subcomponents. This means that each component is separated by & rather than ^. For example: Name space id^some OIDÎSO becomes Name space id&some OID&ÎSO
Note: When the HD data type is used in a given segment as a component of a field of another data type, User-defined Table 0300 - Namespace ID (referenced by the first sub-component of the HD component) may be re-defined (given a different user-defined table number and name) by the technical committee responsible for that segment. By site agreement, implementers may continue to use User-defined Table 0300 Namespace ID for the first sub-component.
Name Type Code (ID)

A code that represents the type of name. Refer to HL7 Table 0200 - Name type for valid values. If the field is not populated then the value is assumed to be L.
Identifier Check Digit (ST)

The check digit in this data type is not an add-on produced by the message processor. It is the check digit that is part of the identifying number used in the sending application. If the sending application does not include a self-generated check digit in the identifying number, this component should be valued empty.
Check Digit Scheme (ID)

Definition: Contains the code identifying the check digit scheme employed. Refer to HL7 Table 0061 - Check digit scheme for valid values.
Identifier Type Code (IS)

A code corresponding to the type of identifier. In some cases, this code may be used as a qualifier to the <assigning authority> component. Refer to HL7 Table 0203 - Identifier type for suggested values. HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011
61
Professional Suffix (ST)

Definition: Used to specify an abbreviation, or a string of abbreviations denoting qualifications that support the persons profession, (e.g., licenses, certificates, degrees, affiliations with professional societies, etc.). The Professional Suffix normally follows the Family Name when the Person Name is used for display purposes. Please note that this component is an unformatted string and is used for display purposes only.
ExtendedPersonName(XPN)
Definition: This is used for representing a persons name. Table 4-25 Extended Person Name (XPN)
SEQ 1 2 3 30 30 LEN Data Type FN ST ST Usage R R RE Value Sets COMPONENT NAME Family Name Given Name Second and Further Given Names or Initials Thereof 4 5 6 20 20 6 ST ST IS O O X 0360 Suffix (e.g., JR or III) Prefix (e.g., DR) Degree (e.g., MD) Use Professional suffix in sequence 14 7 8 1 1 ID ID RE O 0200 0465 Name Type Code Name Representation Code 9 10 11 12 13 14 199 1 CE DR ID TS TS ST O X O O O O 0444 0448 Name Context Name Validity Range Name Assembly Order Effective Date Expiration Date Professional Suffix COMMENTS
Note: Replaces PN data type as of v 2.3.
62
Family Name (FN)

This is the persons surname or family name.
Given Name (ST)

First name.
Second and Further Given Names or Initials Thereof (ST)

Multiple middle names may be included by separating them with spaces.
Suffix (ST)
Used to specify a name suffix (e.g., Jr. or III).
Prefix (ST)
Used to specify a name prefix (e.g., Dr.).
Name Type Code (ID)

A code that represents the type of name. Refer to HL7 Table 0200 - Name type for valid values.
Note: The content of Legal Name is country specific. In the US the legal name is the same as the current married name.
Professional Suffix (ST)

This is the persons professional suffix. Replaces degree above.
XTNExtendedTelecommunicationNumber Definition:Thiscontainstheextendedtelephonenumber.
Table 4-26 XTN Extended Telecommunication Number (XTN)
SEQ 1 LEN 199 Data Type ST Usage X Value Set COMPONENT NAME Telephone Number COMMENTS Deprecated as of 2.3 2 3 ID R 0201 Telecommunication Use Code 3 8 ID RE 0202 Telecommunication Equipment Type 4 199 ST CE Email Address If the telecommunicati on type code is NET, then this field shall be populated. 5 3 NM O Country Code
63
SEQ 6
LEN 5
Data Type NM
Usage CE
Value Set
COMPONENT NAME Area/City Code
COMMENTS If the telecommunicati on type code is not NET, then this field shall be populated.
NM
CE
Local Number
If the telecommunicati on type code is not NET, then this field shall be populated.
8 9 10 11 12
5 199 4 6 199
NM ST ST ST ST
O O O O O
Extension Any Text Extension Prefix Speed Dial Code Unformatted Telephone number
Maximum Length: 850
Note: Components five through nine reiterate the basic function of the first component in a delimited form that allows the expression of both local and international telephone numbers. As of 2.3, the recommended form for the telephone number is to use the delimited form rather than the unstructured form supported by the first component . The old implementation guide (2.3.1) allowed the first component to be used for phone number. This is not supported by this Guide.
Note: Replaces TN data type as of v 2.3
Example: A primary residence number

^PRN^PH^^^734^6777777
Telecommunication Use Code (ID)

A code that represents a specific use of a telecommunication number. Refer to HL7 Table 0201 Telecommunication use code for valid values.
Telecommunication Equipment Type (ID)

A code that represents the type of telecommunication equipment. Refer to HL7 Table 0202 Telecommunication equipment type for valid values.
64
Email Address (ST)

The email address for the entity.
Area/city Code (NM)

The telephone area code for the entity.
Phone Number (NM)

The phone number for the entity.
Extension (NM)
The extension to the phone.
65
Chapter 5: Segments and Message Details
5. Segments and Message Details

Thischapterwillcontainspecificationsforeachsegmentused.Itwillindicatewhichfieldsaresupportedorrequiredanddescribe anyconstraintsonthesefields.Chapter6willthenaddresshowthesebuildingblocksareassembledintospecificmessagesthat meettheusecaseslistedinChapter2.
Table 5-1 Message Segments
Segment (Name/Role) BHS (BatchHeader Segment)
Definition TheBatchHeaderSegmentwraps agroupof1ormoremessages. Thesemaybeamixtureof acceptablemessagetypes.This segmentisnotrequiredforreal timemessaging.Thatis,astream ofmessagesmaybesentwithout aBHS.Asystemmaychooseto requireBHSforallgroupsof messages,butshouldspecifythis requirementinalocal implementationGuide. TheBTSsegmentdefinestheend ofabatch.Itisrequiredifthe messagehasamatchingBHS. Theerrorsegmentreports informationabouterrorsin processingthemessage.The segmentmayrepeat.Eacherror
MessageUsage Any
Usage Optional
Note Usedatthebeginningofanybatchof messages.
BTS (BatchTrailer Segment) ERR (Error Segment)
Any
ACK,RSP
Requiredif message startswith BHS. Abilityto createand processis requiredfor
Usedtomarktheendofanybatchof messages.Ifthebatchofmessages startswithaBHS,thenthissegmentis required. Usedtoreturninformationabout errors.
66
Segment (Name/Role)
Definition willhaveitsownERRsegment.
MessageUsage
Usage conformant systems. Requiredfor ADT message.
Note
EVN (Event Segment)
FHS (FileHeader Segment)
FTS (FileTrailer Segment)
TheEVNsegmentisusedto ADT communicatenecessarytrigger eventinformationtoreceiving applications.Valideventtypesfor allchaptersarecontainedinHL7 Table0003EventType Thefileheadersegmentmaybe Any usedtogrouponeormore batchesofmessages.Thisisa purelyoptionalsegment,evenif batchesaresent.Itsuseisnot anticipatedforuseinrealtime transactions.Anysystemthat anticipatesitsuseshouldspecify thisinalocalimplementation Guide. TheFTSsegmentdefinestheend Any ofafileofbatches.Itisonlyused whentheFHSsegmentisused.
Usedtoconveyeventtrigger information.
Optional
Usedtomarkthebeginningofafileof batches.
IN13 (Insurance Segment)
TheIN1IN3segmentscontain insurancepolicycoverage informationnecessarytoproduce
VXU
Requiredto terminatea fileof batches. (Matches FHS) Optional
Usedtomarktheendofafileof batches.IfafileofbatcheshasanFHS atthebeginning,thenthissegmentis required.
Thissegmentisnotanticipatedforuse inimmunizationmessages,butmaybe specifiedforlocaluse.
67
Segment (Name/Role)
Definition properlyproratedandpatient andinsurancebills. Thissegmentisincludedinthe queryresponse(RSP) and acknowledgment (ACK) messages.Itcontains informationusedtoidentifythe receiversacknowledgement responseto anidentifiedprior message. TheMSHsegmentdefinesthe intent,source,destination,and somespecificsofthesyntaxofa message.
MessageUsage
Usage
Note
MSA (Message
Acknowledgeme ntSegment)
RSP,ACK
Abilityto createand processis requiredfor conformant systems.
MSH (Message Segment Header)
All
NK1 (NextofKin Segment)
TheNK1segmentcontains informationaboutthepatients nextofkinorotherrelated parties.Anyassociatedparties maybeidentified.
VXU,ADT,RSP
NTE (Note Segment)
TheNTEsegmentisusedfor VXU,ADT,RSP sendingnotesandcomments.Itis usedinrelationtoOBXintheVXU andRSP.
Abilityto createand processis requiredfor conformant systems. Abilityto createand processis requiredfor conformant systems. Abilityto createand processis requiredfor conformant
Thisbeginseverymessageand includesinformationaboutthetypeof message,howtoprocessitandwhoit wascreatedby.
Usedtocarryinformationaboutthe nextofkinforaclient.
Usedtocarryanoterelatedtothe parentsegment.
68
Segment (Name/Role) OBX (Observation Result Segment)
Definition
MessageUsage
Usage systems. Abilityto createand processis requiredfor conformant systems.
Note
Theobservationresultsegment ADT,VXU,RSP hasmanyuses.Itcarries observationsabouttheobjectof itsparentsegment.Inthe VXU/RSPitisassociatedwiththe RXAorimmunizationrecord.The basicformatisaquestionandan answer. ORC TheCommonOrdersegment VXU,RSP (OrderRequest (ORC)isusedtotransmitfields Segment) thatarecommontoallorders(all typesofservicesthatare requested).Whilenotall immunizationsrecordedinan immunizationmessageareableto beassociatedwithanorder,each RXAmustbeassociatedwithone ORC,basedonHL72.5.1standard. PD1 Thepatientadditional VXU,RSP,ADT (Patient demographicsegmentcontains Demographic demographicinformationthatis Segment) likelytochangeaboutthepatient. Inimmunizationmessages,thisis informationabouttheneedto protecttheclientsinformation, howtheyshouldbepartof
Usedtoreportoneatomicpartofan observation.
Usedtogiveinformationabouta groupofoneormoreorders(typically RXA).
Usedtogiveinformationabouta patient.Aprimaryuseinimmunization messagesistogiveinformationabout privacyandwhethercontactis allowed.
69
Segment (Name/Role)
Definition
MessageUsage
Usage
Note
PID (Patient Identifier Segment)
PV1 (PatientVisit Segment)
remindereffortsandtheircurrent statusintheIIS. Thissegmentcontainspermanent VXU,ADT,RSP patientidentifyingand demographicinformationthat,for themostpart,isnotlikelyto change.Usedbyallapplications astheprimarymeansof communicatingpatient identificationinformation. frequently. Thissegmentcontains VXU,ADT,RSP informationrelatedtoaspecific visit.
Usedtocarryinformationaboutthe patient/client.
QAK (Query acknowledgem entsegment)
TheQAKsegmentcontains informationsentwithresponses toaquery.
RSP
QPD
Queryparameterdefinition
QBP,RSP
Abilityto createand processis requiredfor conformant systems. Abilityto createand processis requiredfor conformant systems. Abilityto createand processis
Usedtocarryinformationabouta givenvisit.Usedinimmunization messagestocarryinformationabout clienteligibilityforvariousfunding sources.
70
Segment (Name/Role)
Definition
MessageUsage
Usage requiredfor conformant systems. Abilityto createand processis requiredfor conformant systems. Abilityto createand processis requiredfor conformant systems. Abilityto createand processis requiredfor conformant systems.
Note
RCP
Responsecontrolparameter segment
QBP
RXA
Pharmacy/Treatment AdministrationSegment
VXU,RSP
RXR
Pharmacy/TreatmentRoute Segment
VXU,RSP
71
BHSBatchHeaderSegment
Table 5-2 Batch Header Segment (BHS) SEQ 1 2 3 4 5 6 7 8 9 10 11 12 40 20 80 20 20 LEN 1 3 Data Type ST ST HD HD HD HD TS ST ST ST ST ST Cardinality [1..1] [1..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] Value set ITEM # 00081 00082 00083 00084 00085 00086 00087 00088 00089 00090 00091 00092 ELEMENT NAME Batch Field Separator Batch Encoding Characters Batch Sending Application Batch Sending Facility Batch Receiving Application Batch Receiving Facility Batch Creation Date/Time Batch Security Batch Name/ID/Type Batch Comment Batch Control ID Reference Batch Control ID Usage R R O O O O O O O O O O Constraint The BHS.1 field shall be | The BHS.2 field shall be ^~\&
BHSfielddefinitions
BHS-1 Batch Field Separator (ST) 00081
Definition: This field contains the separator between the segment ID and the first real field, BHS-2-batch encoding characters. As such it serves as the separator and defines the character to be used as a separator for the rest of the message. The required value is |,(ASCII 124). Note that this field is different from other fields and immediately follows the Segment name code. BHS|
72
separator
BHS-2 Batch Encoding Characters (ST) 00082

Definition: This field contains the four characters in the following order: the component separator, repetition separator, escape characters, and subcomponent separator. The required values are ^~\& (ASCII 94, 126, 92, and 38, respectively).
BTSBatchTrailerSegment
Table 5-3 Batch Trailer Segment (BTS) SEQ 1 2 3 LEN 10 80 100 Data Type ST ST NM Cardinality [0..1] [0..1] [0..1] Value Set ITEM # 00093 00090 00095 ELEMENT NAME Batch Message Count Batch Comment Batch Totals Usage O O O Constraint
BTSfielddefinitions
BTS-1 - BTS-3 Not anticipated to be used for immunization messages.
Example:BTS||
ERRErrorSegment
NotethattheERR1fieldisnotsupportedinVersion2.5.1. Itmaycontinuetobeusedforversions2.4andearlierasspecifiedintheearlierImplementationGuide.ItistheONLYfieldthatwill beincludedinanERRsegmentiftheMSHindicatesthatthemessagewiththeerrorwasaversionpriorto2.5.
73
Table 5-4 Error Segment (ERR) SEQ 1 2 18 LEN Data Type ELD ERL Cardinality [0..0] [0..1] 15 Value Set ITEM # 00024 01812 ELEMENT NAME Error Code and Location Error Location Usage X RE Constraint Not supported for Version 2.5 and above. If an error involves the entire message (e.g. the message is not parseable.) then location has no meaning. In this case, the field is left empty.
3 4 5 6 7 8 80 2048 250 2
CWE ID CWE ST TX TX
[1..1] [1..1] [0..1] [0..1] [0..1] [0..1]
0357 0516 0533
01813 01814 01815 01816 01817 01818
HL7 Error Code Severity Application Error Code Application Error Parameter Diagnostic Information User Message
R R O O O O This field may contain free text that may be displayed to a user. It is not intended for any further processing.
9 10 11
20
IS CWE CWE
[0..1] [0..1] [0..1]
0517 0518 0519
01819 01820 01821
Inform Person Indicator Override Type Override Reason Code
O O O
This Guide does not support repeat of this field. It assumes that each error will be contained in one ERR segment. If the same error occurs more than once, there will be one ERR for each.
15
74
SEQ 12
LEN
Data Type XTN
Cardinality [0..1]
Value Set
ITEM # 01822
ELEMENT NAME Help Desk Contact Point
Usage O
Constraint
ERRfielddefinitions:
Note that ERR-1 is not supported for use in messages starting with version 2.5.
ERR-2 Error Location (ERL) 01812

Definition: Identifies the location in a message related to the identified error, warning or message. Each error will have an ERR, so no repeats are allowed on this field. This field may be left empty if location is not meaningful. For example, if is unparseable, an ERR to that effect may be returned.
ERR-3 HL7 Error Code (CWE) 01813

Definition: Identifies the HL7 (communications) error code. Refer to HL7 Table 0357 Message Error Condition Codes for valid values.
ERR-4 Severity (ID) 01814

Definition: Identifies the severity of an application error. Knowing if something is Error, Warning or Information is intrinsic to how an application handles the content. Refer to HL7 Table 0516 - Error severity for valid values. If ERR-3 has a value of "0", ERR-4 will have a value of "I".
ERR-5 Application Error Code (CWE) 01815

Definition: Application specific code identifying the specific error that occurred. Refer to User-Defined Table 0533 Application Error Code for suggested values. If the message associated with the code has parameters, it is recommended that the message be indicated in the format of the java .text.MessageFormat approach 16 . This style provides information on the parameter type to allow numbers, dates and times to be formatted appropriately for the language.
16
Details on MessageFormat can be found at http://java.sun.com/products/jdk/1.2/docs/api/java/text/MessageFormat.html.
75
ERR-6 Application Error Parameter (ST) 01816

Definition: Additional information to be used, together with the Application Error Code, to understand a particular error condition/warning/etc. This field can repeat to allow for up to 10 parameters.
ERR-8 User Message (TX) 01818

Definition: The text message to be displayed to the application user. This is not intended to be processed further by the receiving system.
ExamplewitherrorinPID: ERR||PID^1^5|101^Requiredfieldmissing^HL70357^^^|E|
EVNEventTypeSegment
. Table 5-5 Event Segment (EVN) SEQ 1 2 3 4 5 6 7 3 LEN 3 Data Type ID TS TS IS XCN TS HD Cardinality [0.. 1] [1..1] [0..1] [0..1] [0..*] [0..1] [0..1] 0062 0188 Value set 0003 ITEM# 00099 00100 00101 00102 00103 01278 01534 ELEMENT NAME Event Type Code Recorded Date/Time Date/Time Planned Event Event Reason Code Operator ID Event Occurred Event Facility Usage O R O O O O O Comment
EVNfielddefinitions
EVN-2 Recorded Date/Time (TS) 00100
Definition: Most systems will default to the system date/time when the transaction was entered, but they should also permit an override.
76
FHSFileHeaderSegment
Table 5-6 File Header Segment (FHS) SEQ 1 2 3 4 5 6 7 8 9 10 11 12 40 20 80 20 20 LEN 1 4 Data Type ST ST HD HD HD HD TS ST ST ST ST ST Cardinality [1..1] [1..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] Value Set ITEM # 00067 00068 00069 00070 00071 00072 00073 00074 00075 00076 00077 00078 ELEMENT NAME File Field Separator File Encoding Characters File Sending Application File Sending Facility File Receiving Application File Receiving Facility File Creation Date/Time File Security File Name/ID File Header Comment File Control ID Reference File Control ID Usage R R O O O O O O O O O O Comment The FSH.1 field shall be | The FSH.2 field shall be ^~\&
FHSfielddefinitions
FHS-1 File Field Separator (ST) 00067
Definition: This field has the same definition as the corresponding field in the MSH segment. The value shall be |.
77
Note that this field is different from other fields and follows the segment name code immediately. FHS|
FHS-2 File Encoding Characters (ST) 00068

Definition: This field has the same definition as the corresponding field in the MSH segment. The value shall be ^~\&
FTSFileTrailerSegment
Table 5-7 File Trailer Segment (FTS) SEQ 1 2 LEN 10 80 Data Type NM ST Cardinality [0..1] [0..1] Value set ITEM # 00079 00080 ELEMENT NAME File Batch Count File Trailer Comment Usage Comment
O O
IN1InsuranceSegment(IN2,IN3)
These segments are not anticipated for use in immunization messaging. They are not described or specified further in this Guide. Local implementations may document use for local purposes in local implementation Guide.
78
MSAMessageAcknowledgementSegment
Table 5-8 Message Acknowledgement Segment (MSA) SEQ 1 2 3 4 5 6 CE LEN 2 20 80 15 Data Type ID ST ST NM Cardinality [1..1] [1..1] [0..1] [0..1] [0..1] [0..0] 0357 Value Set 0008 ITEM # 00018 00010 00020 00021 00022 00023 ELEMENT NAME Acknowledgment Code Message Control ID Text Message Expected Sequence Number Delayed Acknowledgment Type Error Condition Usage R R O O O X Comment
MSAfielddefinitions
MSA-1 Acknowledgment Code (ID) 00018
Definition: This field contains an acknowledgment code, see message processing rules. Refer to HL7 Table 0008 - Acknowledgment code for valid values.
MSA-2 Message Control ID (ST) 00010

Definition: This field contains the message control ID of the message sent by the sending system. It allows the sending system to associate this response with the message for which it is intended. This field echoes the message control id sent in MSH-10 by the initiating system.
79
MSHMessageHeaderSegment
HL7 ATTRIBUTE TABLE - MSH - MESSAGE HEADER
Table 5-9 Message Header Segment (MSH) SEQ 1 2 3 4 5 6 7 LEN 1 4 Data Type ST ST HD HD HD HD TS Cardinality [1..1] [1..1] [0..1] [0..1] [0..1] [0..1] [1..1] 0361 0362 0361 0362 Value set ITEM # 00001 00002 00003 00004 00005 00006 00007 ELEMENT NAME Field Separator Encoding Characters Sending Application Sending Facility Receiving Application Receiving Facility Date/Time Of Message Usage R R RE RE RE RE R Constraint The MSH.1 field shall be | The MSH.2 field shall be ^~\& No constraint No constraint No constraint No constraint
Thedegreeofprecisionmustbeatleastto theminute,andthetimezonemustbe included (format YYYYMMDDHHMM[SS[.S[S[S[S]]]]]+/ZZZZ).
8 9 10 11 12 13 14
40 15 20 3 15 180
ST MSG ST PT VID NM ST
[0..1] [1..1] [1..1] [1..1] [1..1] [0..1] [0..1]
00008 00009 00010 00011 00012 00013 00014
Security Message Type Message Control ID Processing ID Version ID Sequence Number Continuation Pointer
O R R R R O O 2.1, 2.2, 2.3,2.3.1, 2.4,2.5.1
80
SEQ 15
LEN 2
Data Type ID
Cardinality [0..1]
Value set 0155
ITEM # 00015
ELEMENT NAME Accept Acknowledgement Type Application Acknowledgment Type Country Code Character Set Principal Language Of Message Alternate Character Set Handling Scheme Message Profile Identifier
Usage RE
Constraint
16
ID
[0..1]
0155
00016
RE
AL-always, NE-Never, ER-Error/reject only, SU successful completion only Use 3 character country code from ISO 3166. If is empty, assume USA blank defaults to ASCII printable blank blank
17 18 19 20
3 16
ID ID CE
[0..1] [0..1] [0..1] [0..1]
0399 0211
00017 00692 00693
O O O O
20
ID
0356
01317
21
EI
[0..*]
01598
This field will be required for use whenever a Profile is being used.
MSHfielddefinitions
MSH-1 Field Separator (ST) 00001
Definition:ThisfieldcontainstheseparatorbetweenthesegmentIDandthefirstrealfield,MSH2encodingcharacters.Assuchit servesastheseparatoranddefinesthecharactertobeusedasaseparatorfortherestofthemessage.Requiredvalueis|,(ASCII 124).
81
Example: MSH|
MSH-2 Encoding Characters (ST) 00002
Definition:Thisfieldcontainsthefourcharactersinthefollowingorder:thecomponentseparator,repetitionseparator,escape character,andsubcomponentseparator.Requiredvaluesare^~\&(ASCII94,126,92,and38,respectively).
MSH-3 Sending Application (HD) 00003
Definition:Thisfielduniquelyidentifiesthesendingapplication.InthecaseofanIIS,itwillbefoundinthelistofIISapplicationsin AppendixA,Userdefinedtable0361.Thisisnottheproduct,butratherthenameofthespecificinstance.Forinstance,theIISin Georgia(GRITS)isaninstancebasedontheWisconsinIIS(WIR).ThecodeforGRITSwouldbespecifictoGRITS.Additionallocally definedcodesmaybeaddedtoaccommodatelocalneeds.ThefirstcomponentshallbethenamespaceidfoundinUserdefined Table0361,includinglocaladditionstothistable.ThesecondandthirdcomponentsarereservedforuseofOIDs.

MSH-4 Sending Facility (HD) 00004
Definition:Thisfieldidentifiestheorganizationresponsiblefortheoperationsofthesendingapplication.Locallydefinedcodesmay beaddedtoaccommodatelocalneeds.ThefirstcomponentshallbethenamespaceidfoundinUserdefinedTable0362.The secondandthirdcomponentsarereservedforuseofOIDsorotheruniversalidentifiers.

MSH-5 Receiving Application (HD) 00005
Definition:Thisfielduniquelyidentifiesthereceivingapplication.InthecaseofanIIS,itwillbefoundinthelistofIISapplicationsin AppendixA,Userdefinedtable0361.Thisisnottheproduct,butratherthenameofthespecificinstance.Forinstance,theIISin Georgia(GRITS)isaninstancebasedontheWisconsinIIS(WIR).ThecodeforGRITSwouldbespecifictoGRITS.Additionallocally definedcodesmaybeaddedtoaccommodatelocalneeds.ThefirstcomponentshallbethenamespaceidfoundinUserdefined Table0300.ThesecondandthirdcomponentsarereservedforuseofOIDs. 82
MSH-6 Receiving Facility (HD) 00006
Definition:Thisfieldidentifiestheorganizationresponsiblefortheoperationsofthereceivingapplication.Locallydefinedcodesmay beaddedtoaccommodatelocalneeds.ThefirstcomponentshallbethenamespaceidfoundinUserdefinedTable0362.The secondandthirdcomponentsarereservedforuseofOIDs.

MSH-7 Date/Time Of Message (TS) 00007
Definition:Thisfieldcontainsthedate/timethatthesendingsystemcreatedthemessage.Thedegreeofprecisionmustbeatleast totheminute.Thetimezonemustbespecifiedandwillbeusedthroughoutthemessageasthedefaulttimezone. Note: Thisfieldwasmaderequiredinversion2.4.Messageswithversionspriorto2.4arenotrequiredtovaluethisfield.This usagesupportsbackwardcompatibility.

MSH-9 Message Type (MSG) 00009
Definition:Thisfieldcontainsthemessagetype,triggerevent,andthemessagestructureIDforthemessage.RefertoHL7Table 0076Messagetypeforvalidvaluesforthemessagetypecode.ThistablecontainsvaluessuchasACK,ADT,VXU,ORUetc.The followingtableliststhoseanticipatedtobeusedbyIIS.

Table 5-10 Message Types
Transaction Messagetype Unsolicitedupdateofimmunizationrecord VXU Unsolicitedupdateofdemographicdata ADT Querytoanothersystem QBP Responsetoquery RSP RefertoHL7Table0003Eventtypeforvalidvaluesforthetriggerevent.ThistablecontainsvalueslikeA01,O01,R01etc.
83
Messagestructurecomponentisrequired.
MSH-10 Message Control ID (ST) 00010
Definition:Thisfieldcontainstheidentifierassignedbythesendingapplication(MSH.3)thatuniquelyidentifiesamessageinstance. Thisidentifierisuniquewithinthescopeofthesendingfacility(MSH.4),sendingapplication(MSH.3),andtheYYYYMMDDportionof messagedate(MSH.7).ThereceivingsystemechoesthisIDbacktothesendingsystemintheMessageacknowledgmentsegment (MSA).Thecontentandformatofthedatasentinthisfieldistheresponsibilityofthesender.Thereceiverreturnsexactlywhatwas sentinresponsemessages.

MSH-11 Processing ID (PT) 00011
Definition:ThisfieldisusedtodecidewhethertoprocessthemessageasdefinedinHL7Application(level7)Processingrules. ReferenceTableHL70103inAppendixA.ThechoicesareProduction,DebuggingandTraining.Inmostcases,PorProductionshould beused.

MSH-12 Version ID (VID) 00012
Definition:ThisfieldcontainstheidentifieroftheversionoftheHL7messagingstandardusedinconstructing,interpreting,and validatingthemessage.Onlythefirstcomponentneedbepopulated. MessagesconformingtothespecificationsinthisGuideshallindicatethattheversionis2.5.1.Messagesindicatinganearlierversion shallfollowthespecificationsinthe2.3.1Guide.

MSH-15 Accept Acknowledgment Type (ID) 00015
Definition:Thisfieldidentifiestheconditionsunderwhichacceptacknowledgmentsarerequiredtobereturnedinresponsetothis message.Requiredforenhancedacknowledgmentmode.RefertoHL7Table0155Accept/applicationacknowledgmentconditions forvalidvalues.
84
Acceptacknowledgementindicatesifthemessagewassafelyreceivedornot.Itdoesnotindicatesuccessfulprocessing.Application acknowledgementindicatestheoutcomeofprocessing.
MSH-16 Application Acknowledgment Type (ID) 00016
Definition:Thisfieldcontainstheconditionsunderwhichapplicationacknowledgmentsarerequiredtobereturnedinresponseto thismessage. Requiredforenhancedacknowledgmentmode. Note: IfMSH15acceptacknowledgmenttypeandMSH16applicationacknowledgmenttypeareomitted(orarebothempty),the originalacknowledgmentmoderulesareused.Thismeansthat,unlessotherwisespecified,thereceivingapplicationwillsend acknowledgmentwhenithasprocessedthemessage.

MSH-17 Country Code (ID) 00017
Definition:Thisfieldcontainsthecountryoforiginforthemessage.ThevaluestobeusedarethoseofISO3166,.17.TheISO3166 tablehasthreeseparateformsofthecountrycode:HL7specifiesthatthe3character(alphabetic)formbeusedforthecountry code.Ifthisfieldisnotvalued,thenassumethatthecodeisUSA. RefertoHL7Table0399Countrycodeforthe3charactercodesasdefinedbyISO31661.

MSH-21 Message Profile Identifier (EI) 01598
Definition:Sitesmayusethisfieldtoassertadherenceto,orreference,amessageprofile.Messageprofilescontaindetailed explanationsofgrammar,syntax,andusageforaparticularmessageorsetofmessages.Chapter7describesthequeryprofilefor requestinganimmunizationhistory.Italsoincludeschildprofilesthatconstraintheresponsetothequery.

17
Available from ISO 1 Rue de Varembe, Case Postale 56, CH 1211, Geneve, Switzerland
85
Thisfieldwillberequiredwheneveraprofileisbeingusedtoconstrainthemessage.
NK1NextofKinSegment
TheNK1segmentcontainsinformationaboutthepatientsotherrelatedparties.Anyassociatedpartiesmaybeidentified.Utilizing NK11setID,multipleNK1segmentscanbesenttopatientaccounts.Thatis,eachsubsequentNK1incrementstheprevioussetID by1.Soif3NK1weresentinonemessage,thefirstwouldhaveasetidof1,thesecondwouldhave2andthethirdwouldhave3.
86
Table 5-11-Next of Kin Segment (NK1) SEQ 1 2 LEN 4 Data Type SI XPN Cardinality [1..1] [1..*] Value set ITEM# 00190 00191 ELEMENT NAME Set ID - NK1 Name Usage R R The first instance is the legal name and is required. The first instance shall be the primary address. The first instance shall be the primary phone number. Constraint
3 4
CE XAD
[1..1] [0..*]
0063
00192 00193
Relationship Address
R RE
XTN
[0..*]
00194
Phone Number
RE
6 7 8 9 10 11 12 13 14 15 16 17 2 1 8 8 60
XTN CE DT DT ST JCC CX XON CE IS TS IS
[0..*] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] 0223 0002 0001 0327/ 0328 0131
00195 00196 00197 00198 00199 00200 00201 00202 00119 00111 00110 00755
Business Phone Number Contact Role Start Date End Date Next of Kin / Associated Parties Job Title Next of Kin / Associated Parties Job Code/Class Next of Kin / Associated Parties Employee Number Organization Name - NK1 Marital Status Administrative Sex Date/Time of Birth Living Dependency
O O O O O O O O O O O O
87
SEQ 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39
LEN 2
Data Type IS CE CE
Cardinality [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1]
Value set 0009 0171 0296 0220 0215 0136 0231 0006 0212 0189 0222
ITEM# 00145 00129 00118 00742 00743 00744 00745 00120 00109 00739 00125 00747 00748 00749 00750 00751
ELEMENT NAME Ambulatory Status Citizenship Primary Language Living Arrangement Publicity Code Protection Indicator Student Indicator Religion Mothers Maiden Name Nationality Ethnic Group Contact Reason Contact Persons Name Contact Persons Telephone Number Contact Persons Address Next of Kin/Associated Partys Identifiers Job Status Race Handicap Contact Person Social Security Number Next of Kin Birth Place VIP Indicator
Usage O O O O O O O O O O O O O O O O O O O O O O
Constraint
2 1 2
IS CE ID IS CE XPN CE CE CE XPN XTN XAD CX
2 2 16
IS CE IS ST ST
0311 0005 0295
00752 00113 00753 00754 01905
IS
0099
00146
88
NK1fielddefinitions
NK1-1 Set ID - NK1 (SI) 00190
Definition: This field contains the number that identifies this transaction. For the first occurrence of the segment, the sequence number shall be one, for the second occurrence, the sequence number shall be two, etc.
NK1-2 Name (XPN) 00191

Definition: This field contains the name of the next of kin or associated party. Multiple names for the same person are allowed, but the legal name must be sent in the first sequence. Refer to HL7 Table 0200 - Name Type for valid values.
NK1-3 Relationship (CE) 00192

Definition: This field contains the actual personal relationship that the next of kin/associated party has to the patient. Refer to User-defined Table 0063 - Relationship for suggested values.
NK1-4 Address (XAD) 00193

Definition: This field contains the address of the next of kin/associated party. Multiple addresses are allowed for the same person. The mailing address must be sent in the first sequence. If the mailing address is not sent, then the repeat delimiter must be sent in the first sequence.
NK1-5 Phone Number (XTN) 00194

Definition: This field contains the telephone number of the next of kin/associated party. Multiple phone numbers are allowed for the same person. The primary telephone number must be sent in the first sequence. If the primary telephone number is not sent, then the repeat delimiter must be sent in the first sequence. Refer to HL7 Table 0201 - Telecommunication Use Code and HL7 Table 0202 Telecommunication Equipment Type for valid values.
NK1-6 Business Phone Number (XTN) 00195

Definition: This field contains the business telephone number of the next of kin/associated party. Multiple phone numbers are allowed for the same person. The primary business telephone number must be sent in the first sequence. If the primary telephone number is not sent, then the repeat delimiter must be sent in the first sequence. Refer to HL7 Table 0201 - Telecommunication Use Code and HL7 Table 0202 - Telecommunication Equipment Type for valid values.
89
NK1-15 Administrative Sex (IS) 00111

Definition: This is the sex of the next of kin.
NK1-16 Date/Time of Birth (TS) 00110

Definition: This is the data of birth of the next of kin.
NTENoteSegment
The NTE segment is used for sending notes and comments. It is used in relation to OBX in the VXU and RSP. It is also used in ADT in relation to various segments. Table 5-12 Note Segment (NTE) SEQ 1 2 3 4 LEN 4 8 Data Type SI ID FT CE Cardinality [0..1] [0..1] [1..1] [0..1] 0364 0105 Value Set ITEM # 00096 00097 00098 01318 ELEMENT NAME Set ID - NTE Source of Comment Comment Comment Type Usage O O R O Comment
NTEfielddefinitions
NTE-3 Comment (FT) 00098
Definition: This field contains the comment contained in the segment.
OBXObservationResultSegment
Theobservationresultsegmenthasmanyuses.Itcarriesobservationsabouttheobjectofitsparentsegment.IntheVXU/RSPitis associatedwiththeRXAorimmunizationrecord.Thebasicformatisaquestion(OBX3)andananswer(OBX5).
90
Table 5-13 Observation Segment (OBX) SEQ 1 2 3 LEN 4 2 Data Type SI ID CE Cardinality [1..1] [1..1] [1..1] 0125 Value Sets ITEM# 00569 00570 00571 ELEMENT NAME Set ID OBX Value Type Observation Identifier Usage R R R CE, NM, ST, DT, or TS This indicates what this observation refers to. It poses the question that is answered by OBX-5. Comment
4 5
20
ST varies 18
[0..1] [1..1]
00572 00573
Observation SubID Observation Value
RE R This is the observation value and answers the question posed by OBX-3 If the observation in OBX-5 requires an indication of the units, they are placed here.
CE
[0..1]
00574
Units
CE
7 8 9 10 11 12
60 5 5 2 1
ST IS NM ID ID TS
[0..1] [0..1] [0..1] [0..1] [1..1] [0..1] 0080 0085 0078
00575 00576 00577 00578 00579 00580
References Range Abnormal Flags Probability Nature of Abnormal Test Observation Result Status Effective Date of Reference Range Values
O O O O R O Constrain to F
18
The length of the observation field is variable, depending upon value type. See OBX-2 value type.
91
SEQ 13 14 15 16 17 18 19 20
LEN 20
Data Type ST TS CE XCN CE EI TS
Cardinality [0..1] [1..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1]
Value Sets
ITEM# 00581 00582 00583 00584 00936 01479 01480
ELEMENT NAME User Defined Access Checks Date/Time of the Observation Producer's Reference Responsible Observer Observation Method Equipment Instance Identifier Date/Time of the Analysis Reserved for harmonization with V2.6 Reserved for harmonization with V2.6 Reserved for harmonization with V2.6
Usage O R O O O O O O
Comment
21
[0..1]
22
[0..1]
23 24
XON XAD
[0..1] [0..1]
02283 02284
Performing Organization Name Performing Organization Address
O O
92
SEQ 25
LEN
Data Type XCN
Cardinality [0..1]
Value Sets
ITEM# 02285
ELEMENT NAME Performing Organization Medical Director
Usage O
Comment
OBXfielddefinitions
OBX-1 Set ID - OBX (SI) 00569
Definition: This field contains the sequence number. The first instance shall be set to 1 and each subsequent instance shall be the next number in sequence.
OBX-2 Value Type (ID) 00570

Definition: This field contains the format of the observation value in OBX. If the value is CE then the result must be a coded entry.
OBX-3 Observation Identifier (CE) 00571

Definition: This field contains a unique identifier for the observation. The format is that of the Coded Element (CE). Example: |309633^Vaccine purchased with^LN|. In most systems the identifier will point to a master observation table that will provide other attributes of the observation that may be used by the receiving system to process the observations it receives. This may be thought of as a question that the observation answers. In the example above, the question is how was this immunization paid for The answer in OBX-5 could be Public Funding.
The2.3.1ImplementationGuideusedsuffixesonthefirstsequenceinOBX3togrouprelatedobservations.Forinstance,reportingaVISpublicationdateand VISreceiptdateeachaddedasuffixofoneLOINCcodetoasecondLOINCcodewhenrecordingVISdatesforacomponentvaccine.(388900&297689^DATE VACCINEINFORMATIONSTATEMENTPUBLISHED^LN)Thisisnolongeracceptable.GroupingofrelatedobservationswillbeaccomplishedusingObservation subid(OBX4).
93
OBX-4 Observation Sub-ID (ST) 00572

Definition: This field is used to group related observations by setting the value to the same number. For example, recording VIS date and VIS receipt date for a combination vaccination requires 6 OBX segments. One OBX would indicate the vaccine group. It would have a pair of OBX indicating the VIS publication date and the VIS receipt date. These would have the same OBX-4 value to allow them to be linked. The second set of three would have another OBX-4 value common to each of them. This field may be used to link related components of an observation. Each component of the observation would share an Observation subid. For example: OBX|1|LN|ôbservation 1 part 1^^^^^|1| OBX|2|LN|^ observation 1 part 2^^^^^|1| OBX|3|DT|â different observation^^^^^|2|
Example: OBX|1|CE|388900^COMPONENTVACCINETYPE^LN|1|45^HEPB,NOS^CVX||||||F|<CR> OBX|2|TS|297689^DATEVACCINEINFORMATIONSTATEMENTPUBLISHED^LN|1|20010711||||||F|<CR> OBX|3|TS|297697^DATEVACCINEINFORMATIONSTATEMENT PRESENTED^LN|1|19901207||||||F|<CR> OBX|4|CE|388900^COMPONENTVACCINETYPE^LN|2|17^HIB,NOS^CVX||||||F|<CR> OBX|5|TS|297689^DATEVACCINEINFORMATIONSTATEMENT PUBLISHED^LN|2|19981216||||||F|<CR>
94
OBX|6|TS|297697^DATEVACCINEINFORMATIONSTATEMENT PRESENTED^LN|2|19901207||||||F|<CR>
OBX-5 Observation Value (varies) 00573

Definition: This field contains the value observed by the observation producer. OBX-2-value type contains the data type for this field according to which observation value is formatted. This field contains the value of OBX-3-observation identifier of the same segment. Depending upon the observation, the data type may be a number (e.g., dose number), a coded answer (e.g., a vaccine), or a date/time (the date/time that the VIS was given to the client/parent). An observation value is always represented as the data type specified in OBX-2-value type of the same segment. Whether numeric or short text, the answer shall be recorded in ASCII text. Coded values When an OBX segment contains values of CE data types, the observations are stored as a combination of codes and/or text.
OBX-6 Units (CE) 00574

Definition: This shall be the units for the value in OBX-5. The value shall be from the ISO+ list of units.
OBX-11 Observation Result Status (ID) 00579

Definition: This field contains the observation result status. The expected value is F or final.
OBX-14 Date/Time of the Observation (TS) 00582

Definition: Records the time of the observation. It is the physiologically relevant date-time or the closest approximation to that date-time of the observation.
ORCOrderRequestSegment
TheCommonOrdersegment(ORC)isusedtotransmitfieldsthatarecommontoallorders(alltypesofservicesthatarerequested). Whilenotallimmunizationsrecordedinanimmunizationmessageareabletobeassociatedwithanorder,eachRXAmustbe associatedwithoneORC,basedonHL72.5.1standard.
95
Table 5-14 Common Order Segment (ORC) SEQ 1 2 3 4 5 6 7 8 9 10 2 1 LEN 2 Data Type ID EI EI EI ID ID TQ EIP TS XCN Cardinality [1..1] [0..1] [1..1] [0..1] [0..1] [0..1] [0..0] [0..1] [0..1] [0..1] 0038 0121 Value Set 0119 ITEM# 00215 00216 00217 00218 00219 00220 00221 00222 00223 00224 ELEMENT NAME Order Control Placer Order Number Filler Order Number Placer Group Number Order Status Response Flag Quantity/Timing Parent Date/Time of Transaction Entered By Usage R RE R O O O X O O RE This is the person that entered this immunization record into the system. This shall be the provider ordering the immunization. It is expected to be empty if the immunization record is transcribed from a historical record. Comment use RE See Guidance below. See Guidance below.
11 12
XCN XCN
[0..1] [0..1]
00225 00226
Verified By Ordering Provider
O RE
13 14 15
PL XTN TS
[0..1] [0..1] [0..1]
00227 00228 00229
Enterer's Location Call Back Phone Number Order Effective Date/Time
O O O
96
SEQ 16 17
LEN
Data Type CE CE
Cardinality [0..1] [0..1]
Value Set
ITEM# 00230 00231
ELEMENT NAME Order Control Code Reason Entering Organization Entering Device Action By Advanced Beneficiary Notice Code Ordering Facility Name Ordering Facility Address Ordering Facility Phone Number Ordering Provider Address Order Status Modifier Advanced Beneficiary Notice Override Reason Filler's Expected Availability Date/Time Confidentiality Code Order Type Enterer Authorization Mode
Usage O O
Comment
This is the provider organization that entered this record/order.
18 19 20
CE XCN CE
[0..1] [0..1] [0..1] 0339
00232 00233 01310
O O O
21 22 23 24 25 26
XON XAD XTN XAD CWE CWE
[0..1] [0..1] [0..1] [0..1] [0..1] [0..1] 0552
01311 01312 01313 01314 01473 01641
O O O O O O
27 28 29 30
TS CWE CWE CNE
[0..1] [0..1] [0..1] [0..1] 0177 0482 0483
01642 00615 01643 01644
O O O O
97
SEQ 31
LEN
Data Type CWE
Cardinality [0..1]
Value Set
ITEM# 02286
ELEMENT NAME Parent Universal Service Identifier
Usage O
Comment
ORCfielddefinitions
ORC-1 Order Control (ID) 00215
Definition: Determines the function of the order segment. The value for VXU and RSP shall be RE.
PlacerOrderNumber(ORC2)andFillerOrderNumber(ORC3)areuniqueidentifiersfromthesystemwhereanorderwasplaced andwheretheorderwasfilled.Theywereoriginallydesignedformanaginglaborders.Thesefieldshaveausagestatusof ConditionalinVersion2.5.1.TheconditionforeachisthattheymustbepresentineithertheOBRorORCofamessage.Therehas beenconfusionaboutusageforthesefields.TheOrdersandObservationsworkgrouphasaddressedthisconfusion.Inthecontext thatORCwillbeusedinImmunizationmessagingeitherORC2orORC3mustbepopulated.Theymaybothbepopulated. Intheimmunizationcontext,itisnotcommontohaveonesystemplacingandonefillinganimmunizationorder.Insomecases neitherisknown.Theusecasethatthesehavesupportedistoallowasystemthatsentanimmunizationrecordtoanothersystem toidentifyanimmunizationthatneedstobechangedusingtheFillerOrderNumberithadsent. ThisGuidespecifiesthatPlacerOrderNumberisRE(required,butmaybeempty).TheFillerOrderNumberSHALLbetheunique immunizationidofthesendingsystem.
ORC-2 Placer Order Number (EI) 00216
The placer order number is used to uniquely identify this order among all orders sent by a provider organization. ORC-2 is a system identifier assigned by the placer software application. The Placer Order Number and the Filler Order Number are essentially foreign keys exchanged between applications for uniquely identifying orders and the associated results across applications.
98
In the case where the ordering provider organization is not known, the sending system may leave this field empty.
ORC-3 Filler Order Number (EI) 00217

The filler order number is used to uniquely identify this order among all orders sent by a provider organization that filled the order. This shall be the unique identifier of the sending system in a given transaction. In the case where system A sends the record to system B and system B then forwards to system C, system B will send its own unique identifier. Use of this foreign key will allow the initiating system to accurately identify the previously sent immunization record, facilitating update or deletion of that record. In the case where a historic immunization is being recorded (i.e. from an immunization card), the sending system SHALL assign an identifier as if it were an immunization administered by a provider associated with the provider organization owning the sending system. In the case where an RXA is conveying information about an immunization which was not given (e.g. refusal) the filler order number shall be 9999. Note that the receiving system will need to store this value in addition to its own internal id in order for this to be used.
ORC-10 Entered By (XCN) 00224

Definition: This identifies the individual that entered this particular order. It may be used in conjunction with an RXA to indicate who recorded a particular immunization.
ORC-12 Ordering Provider (XCN) 00226

Definition: This field contains the identity of the person who is responsible for creating the request (i.e., ordering physician). In the case where this segment is associated with a historic immunization record and the ordering provider is not known, then this field should not be populated.
ORC-17 Entering Organization (CE) 00231

Definition: This field identifies the organization that the enterer belonged to at the time he/she enters/maintains the order, such as medical group or department. The person who entered the request is defined in ORC-10 -entered by.
ORC-21 Ordering Facility Name (XON) 01311

Definition: This field contains the name of the facility placing the order. It is the organization sub-unit that ordered the immunization. (i.e. the clinic)
99
ORC-22 Ordering Facility Address (XAD) 01312

Definition: This field contains the address of the facility requesting the order.
ORC-23 Ordering Facility Phone Number (XTN) 01312

Definition: This field contains the phone number of the facility requesting the order.
ORC-24 Ordering Provider Address (XAD) 01314

Definition: This field contains the address of the care provider requesting the order.
ORC 28 Confidentiality Code (CWE) 00615

This field allows a system to indicate if special privacy rules apply to the RXA that is associated with this ORC. For instance, if a state had special rules about who may see records for HPV vaccinations, then this field could convey that. The recommended value to use in this case is R for restricted. If this field is populated, it indicates the active choice of the patient or responsible person. In other words, if the value indicates that the information must be protected, the person has stated that it must be protected. An empty field indicates that the client has not actively specified the way they want this data to be handled. Local implementation guides should describe the local usage of this field and value.
PD1PatientDemographicSegment
ThePatientDemographicSegmentcontainspatientdemographicinformationthatmaychangefromtimetotime.Therearethree primaryusesforinImmunizationMessages.Theseincludeindicatingwhetherthepersonwantshis/herdataprotected,whetherthe personwantstoreceiverecall/remindernoticesandthepersonscurrentstatusintheregistry.
100
Table 5-15-Patient Demographic Segment (PD1) SEQ 1 2 3 4 5 6 7 8 9 10 11 12 13 LEN 2 2 250 250 2 2 2 2 1 250 250 1 8 Data Type IS IS XON XCN IS IS IS IS ID CX CE ID DT Cardinality [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] 0215 0136 0231 0295 0315 0316 0136 Value Set 0223 0220 Item # 00755 00742 00756 00757 00745 00753 00759 00760 00761 00762 00743 00744 01566 ELEMENT NAME Living Dependency Living Arrangement Patient Primary Facility Patient Primary Care Provider Name & ID No. Student Indicator Handicap Living Will Code Organ Donor Code Separate Bill Duplicate Patient Publicity Code Protection Indicator Protection Indicator Effective Date Place of Worship Advance Directive Code Immunization Registry Status Immunization Registry Status Effective Date Publicity Code Effective Date Usage O O O O O O O O O O RE RE CE If protection indicator is valued, then this field should be valued. Comment
14 15 16 17
250 250 1 8
XON CE IS DT
[0..1] [0..1] [0..1] [0..1] 0435 0441
01567 01568 01569 01570
O O RE CE If the registry status field is filled, then this should be valued. If the publicity code field is filled then this field should be valued.
18
DT
[0..1]
01571
CE
101
SEQ 19 20 21
LEN 5 2 3
Data Type IS IS IS
Cardinality [0..1] [0..1] [0..1]
Value Set 0140 0141 0142
Item # 01572 00486 01573
ELEMENT NAME Military Branch Military Rank/Grade Military Status
Usage O O O
Comment
PD1fielddefinitions
PD1-3 Patient Primary Facility (XON) 00756
Definition: This field contains the name and identifier that specifies the primary care healthcare facility selected by the patient. Use may be specified locally.
PD1-4 Patient Primary Care Provider Name & ID No. (XCN) 00757
Definition: Identifier for primary care provider. Use may be specified locally.
PD1-11 Publicity Code (CE) 00743

Definition: This field contains a user-defined code indicating what level of publicity is allowed (e.g., No Publicity, Family Only) for the patient. In the context of immunization messages, this refers to how a person wishes to be contacted in a reminder or recall situation. Refer to User-defined Table 0215 - Publicity Code for suggested values.
PD1-12 Protection Indicator (ID) 00744

Definition: This field identifies whether a persons information may be shared with others 19 . Specific protection policies are a local consideration (opt in or opt out, for instance). This field conveys the current state in the sending system. The protection state must be actively determined by the clinician. If it is not actively determined, then the protection indicator shall be empty. There are 3 states:
Local policies determine how data are protected. In general, it indicates who may view the clients data. It may be as narrow as just the provider that entered the information.
19
102
Protection State Yes, protect the data. Client (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. Client (or guardian) has indicated that the information does not need to be protected. (Sharing is OK) No determination has been made regarding clients (or guardians) wishes regarding information sharing
Code Y N
PD1-12 is empty.
Notes on use of Y for Protection Indicator in 2.5.1 Guide vs. earlier Guides.
Note that the previous Implementation Guide stated that Y meant that a persons information could be shared. This was an incorrect interpretation of the use of this field. The meaning now aligns with the definition of HL7. That is, Y means data must be protected. Existing systems that use the old meaning will need to determine how they will send the correct value in a 2.5.1 message.
Note that the value sent in a message that is based on the 2.3.1 or 2.4 version of the HL7 standard shall continue to follow the old guidance. That is, Y means sharing is allowed and N means sharing is not allowed.
Note on Null and Empty in HL7

See notes on null and empty fields in Chapter 3.
PD1-13 Protection Indicator Effective Date (DT) 01566

Definition: This field indicates the effective date for PD1-12 - Protection Indicator.
103
PD1-16 Immunization Registry Status (IS) 01569

Definition: This field identifies the current status of the patient in relation to the sending provider organization.. Refer to User-defined Table 0441 - Immunization Registry Status for suggested values. This field captures whether the sending provider organization considers this an active patient. There are several classes of responsibility. The status may be different between the sending and receiving systems. For instance, a person may no longer be active with a provider organization, but may still be active in the public health jurisdiction, which has the Immunization Information System (IIS). In this case the provider organization would indicate that the person was inactive in their system using this field in a message from them. The IIS would indicate that person was active in a message from the IIS.
PD1-17 Immunization Registry Status Effective Date (DT) 01570

Definition: This field indicates the effective date for the registry status reported in PD1-16 - Immunization Registry Status.
PD1-18 Publicity Code Effective Date (DT) 01571

Definition: This is the effective date for PD1-11 - Publicity Code.
PIDPatientIdentifierSegment
ThePIDisusedbyallapplicationsastheprimarymeansofcommunicatingpatientidentificationinformation.Thissegmentcontains permanentpatientidentifyinganddemographicinformationthat,forthemostpart,isnotlikelytochangefrequently.
104
Table 5-16-Patient Identifier Segment (PID) SEQ 1 2 3 4 5 LEN 4 Data Type SI CX CX CX XPN Cardinality [0..1] [0..0] [1..*] [0..0] [1..*] Value Set ITEM# 00104 00105 00106 00107 00108 Element Name Set ID - PID Patient ID Patient Identifier List Alternate Patient ID 00106 Patient Name Usage RE X R X R the first repetition shall contain the legal name. Multiple given names or initials are separated by spaces. Required, must have month, day and year. M= male, F = female, U = not determined/unspecified/unk nown. Constraint
6 7 8 1
XPN TS IS
[0..1] [1..1] [0..1]
00109 00110 00111
Mothers Maiden Name Date/Time of Birth Administrative Sex
RE R RE
0001
9 XPN [0..0] 00112 Patient Alias X
This field should not be used. It was supported in earlier implementations.

The first triplet is to be used for the alpha code. The second triplet of the CE data type for race (alternate identifier, alternate text, and name of alternate coding
10
CE
[0..*]
0005
00113
Race
RE
105
SEQ
LEN
Data Type
Cardinality
Value Set
ITEM#
Element Name
Usage
Constraint system) should be used for governmentally assigned numeric codes (####-#).
11 12 13 4
XAD IS XTN
[0..*] [0..0] [0..*]
00114
Patient Address County Code Phone Number - Home
RE X RE
The first repetition should be the primary address. County belongs in address field. The first instance shall be the primary phone number. Only one item is allowed per repetition.
0289
00115 00116
14 15 16 17 18 19 20 21 22 16
XTN CE CE CE CX ST DLN CX CE
[0..1] [0..1] [0..1] [0..1] [0..1] [0..0] [0..0] [0..0] [0..1] 0189 0296
00117 00118 00119 00120 00121 00122 00123 00124 00125
Phone Number Business Primary Language Marital Status Religion Patient Account Number SSN Number - Patient Driver's License Number - Patient Mother's Identifier Ethnic Group
O O O O O X X X RE First triplet shall contain H,N,U if populated. Second triplet shall contain government issued code from table xxx, if populated. If both are populated, they must match logically. Use ISO 639.
0002 0006
106
SEQ 23 24
LEN 60 1
Data Type ST ID
Cardinality [0..1]
Value Set
ITEM# 00126
Element Name Birth Place Multiple Birth Indicator
Usage O
Constraint Use may be specified locally. The acceptable values are Y and N. If the status is undetermined, then field shall be empty. If Multiple Birth Indicator is populated with Y, then this field should contain the number indicating the persons birth order, with 1 for the first child born and 2 for the second.
[0..1]
0136
00127
RE
25
NM
[0..1]
00128
Birth Order
CE
26 27 28 29 30 1
CE CE CE TS ID
[0..1] [0..1] [0..1] [0..1] [0..1]
0171 0172 0212
00129 00130 00739 00740
Citizenship Veterans Military Status Nationality Patient Death Date and Time Patient Death Indicator
O O O RE CE If patient death date is populated, then this field should be populated.
0136
00741
31 32 33 34 35 36
1 20
ID IS TS HD CE CE
[0..1] [0..1] [0..1] [0..1] [0..1] [0..1]
0136 0445
01535 01536 01537 01538
Identity Unknown Indicator Identity Reliability Code Last Update Date/Time Last Update Facility Species Code Breed Code
O O O O O O May be locally specified. Use is locally specified.
0446 0447
01539 01540
107
SEQ 37 38 39
LEN 80
Data Type ST CE CWE
Cardinality [0..1] [0..1] [0..1]
Value Set
ITEM# 01541
Element Name Strain Production Class Code Tribal Citizenship
Usage O O O
Constraint
0429 0171
01542 01840
PIDfielddefinitions
PID-1 Set ID - PID (SI) 00104
Definition: This field contains the number that identifies this transaction. For the first occurrence of the segment, the sequence number shall be one, for the second occurrence, the sequence number shall be two, etc.
PID-3 Patient Identifier List (CX) 00106

Definition: This field contains the list of identifiers (one or more) used by the healthcare facility to uniquely identify a patient (e.g., medical record number, billing number, birth registry, national unique individual identifier, etc.).
PID-5 Patient Name (XPN) 00108

Definition: This field contains the names of the patient, The primary or legal name of the patient is reported first. Therefore, the name type code in this field should be L - Legal. Refer to HL7 Table 0200 - Name Type for valid values.
PID-6 Mother's Maiden Name (XPN) 00109

Definition: This field contains the family name under which the mother was born (i.e., before marriage). It is used to distinguish between patients with the same last name.
PID-7 Date/Time of Birth (TS) 00110

Definition: This field contains the patients date and time of birth.
108
PID-8 Administrative Sex (IS) 00111

Definition: This field contains the patients sex. Refer to User-defined Table 0001 - Administrative Sex for suggested values.
PID-9 Patient Alias (XPN) 00112

Not anticipated for use in immunization messages. This field was used in the 2.3.1 Implementation Guide. Alias names should be placed in the patient name field.
PID-10 Race (CE) 00113

Definition: This field refers to the patients race. Refer to User-defined Table 0005 - Race for suggested values. The second triplet of the CE data type for race (alternate identifier, alternate text, and name of alternate coding system) is reserved for governmentally assigned codes.
PID-11 Patient Address (XAD) 00114

Definition: This field contains the mailing address of the patient. Address type codes are defined by HL7 Table 0190 - Address Type. Multiple addresses for the same person may be sent in the following sequence: The primary mailing address must be sent first in the sequence (for backward compatibility); if the mailing address is not sent, then a repeat delimiter must be sent in the first sequence. This field is used for any type of address that is meaningfully associated with the client/patient. For instance Birth State is the state of the address of the birthing location, address type = BDL. A persons address may be sent in this field or in the NK1 segment with a relationship code indicating Self. Local implementations should clarify how these addresses will be handled.
PID-12 County Code (IS) 00115

Not anticipated for use in immunization messages. County code belongs in the Address field (PID-11).
PID-13 Phone Number - Home (XTN) 00116

Definition: This field contains the patients personal phone numbers. All personal phone numbers for the patient are sent in the following sequence. The first sequence is considered the primary number (for backward compatibility). If the primary number is not sent, then a repeat delimiter is sent in the first sequence. Each type of telecommunication shall be in its own repetition. For example, if a person has a phone number and an email address, they shall each have a repetition. Refer to HL7 Table 0201 - Telecommunication Use Code and HL7 Table 0202 - Telecommunication Equipment Type for valid values.
109
PID-14 Phone Number - Business (XTN) 00117

Definition: This field contains the patients business telephone numbers. All business numbers for the patient are sent in the following sequence. The first sequence is considered the patients primary business phone number (for backward compatibility). If the primary business phone number is not sent, then a repeat delimiter must be sent in the first sequence. Refer to HL7 Table 0201 Telecommunication Use Code and HL7 Table 0202 - Telecommunication Equipment Type for valid values.
PID-15 Primary Language (CE) 00118

Definition: This field contains the patients primary language. HL7 recommends using ISO table 639 as the suggested values in Userdefined Table 0296 - Primary Language.
PID-22 Ethnic Group (CE) 00125

Definition: This field further defines the patients ancestry. Refer to User-defined Table 0189 - Ethnic Group. The second triplet of the CE data type for ethnic group (alternate identifier, alternate text, and name of alternate coding system) is reserved for governmentally assigned codes.
PID-24 Multiple Birth Indicator (ID) 00127

Definition: This field indicates whether the patient was part of a multiple birth. Refer to HL7 Table 0136 - Yes/No Indicator for valid values. Y N the patient was part of a multiple birth the patient was a single birth multiple birth status is undetermined.
Empty field
PID-25 Birth Order (NM) 00128

Definition: When a patient was part of a multiple birth, a value (number) indicating the patients birth order is entered in this field. If PID-24 is populated, then this field should be populated.
PID-29 Patient Death Date and Time (TS) 00740

Definition: This field contains the date and time at which the patient death occurred.
PID-30 Patient Death Indicator (ID) 00741

Definition: This field indicates whether the patient is deceased. Refer to HL7 Table 0136 - Yes/no Indicator for valid values.
110
Y N
the patient is deceased the patient is not deceased
Empty status is undetermined
PID-33 Last Update Date/Time (TS) 01537

Definition: This field contains the last update date and time for the patients/persons identifying and demographic data, as defined in the PID segment.
PID-34 Last Update Facility (HD) 01538

Definition: This field identifies the facility of the last update to a patients/persons identifying and demographic data, as defined in the PID segment.
PV1PatientVisitSegment
The PV1 segment is used to convey visit specific information. The primary use in immunization messages is to carry information about the clients eligibility status.
111
Table 5-17-Patient Visit (PV1) SEQ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 2 2 2 6 2 2 3 2 LEN 4 1 Data Type SI IS PL IS CX PL XCN XCN XCN IS PL IS IS IS IS IS XCN IS CX FC Cardinality [0..1] [1..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [1..*] 0064 0087 0092 0023 0009 0099 0010 0018 0010 0010 0010 0069 0007 0004 Value Set ITEM# 00131 00132 00133 00134 00135 00136 00137 00138 00139 00140 00141 00142 00143 00144 00145 00146 00147 00148 00149 00150 ELEMENT NAME Set ID - PV1 Patient Class Assigned Patient Location Admission Type Pre-admit Number Prior Patient Location Attending Doctor Referring Doctor Consulting Doctor Hospital Service Temporary Location Preadmit Test Indicator Re-admission Indicator Admit Source Ambulatory Status VIP Indicator Admitting Doctor Patient Type Visit Number Financial Class Usage O R O O O O O O O O O O O O O O O O O R Constraint If populated, this should be 1. R
112
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
2 2 2 2 8 12 3 2 4 8 10 12 12 1 8 3
IS IS IS IS DT NM NM IS IS DT IS NM NM IS DT IS DLD CE
[0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1]
0032 0045 0046 0044
00151 00152 00153 00154 00155 00156 00157
Charge Price Indicator Courtesy Code Credit Rating Contract Code Contract Effective Date Contract Amount Contract Period Interest Code Transfer to Bad Debt Code Transfer to Bad Debt Date Bad Debt Agency Code Bad Debt Transfer Amount Bad Debt Recovery Amount Delete Account Indicator Delete Account Date Discharge Disposition Discharged to Location Diet Type
O O O O O O O O O O O O O O O O O O
0073 0110
00158 00159 00160
0021
00161 00162 00163
0111
00164 00165
0112 0113 0114
00166 00167 00168
113
39 40 41 42 43 44 45 46 47 48 49 50 51 52
2 1 2
IS IS IS PL PL TS TS
[0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1] [0..1]
0115 0116 0117
00169 00170 00171 00172 00173 00174 00175 00176 00177 00178 00179
Servicing Facility Bed Status Account Status Pending Location Prior Temporary Location Admit Date/Time Discharge Date/Time Current Patient Balance Total Charges Total Adjustments Total Payments Alternate Visit ID Visit Indicator Other Healthcare Provider
O O O O O O O O O O O O O O
12 12 12 12 1
NM NM NM NM CX IS XCN
0203 0326 0010
00180 01226 01274
PV1fielddefinitions
PV1-2 Patient Class (IS) 00132
Definition: This field is used by systems to categorize patients by site. It shall be constrained to R.
PV1-20 Financial Class (FC) 00150

Definition: This field contains the financial class(es) assigned to the patient. It reflects the current eligibility status. For children, this will include the eligibility status for the Vaccines for Children program (VFC). This field has 2 components: financial class and date. The date is the date that the status was assessed. Refer to User-defined Table 0064 - Financial Class for suggested values.
114
This field does not indicate how each immunization was paid for on this visit. That information may be carried in an OBX segment associated with each RXA segment.
QAKQueryAcknowledgementSegment
Table 5-18-Query Acknowledgement Segment SEQ 1 2 3 4 5 6 10 10 10 LEN 32 2 Data Type ST ID CE NM NM NM Cardinality [1..1] [0..1] [0..1] [0..1] [0..1] [0..1] 0208 0471 Value set ITEM# 00696 00708 01375 01434 01622 01623 ELEMENT NAME Query Tag Query Response Status Message Query Name Hit Count This payload Hits remaining Usage R O O O O O Comment
QAKfielddefinitions
QAK-1 Query Tag (ST) 00696
Definition: This field contains the value sent in QPD-2 (query tag) by the initiating system, and will be used to match response messages to the originating query. The responding system is required to echo it back as the first field in the query acknowledgement segment(QAK).
QAK-2 Query Response Status (ID) 00708

Definition: This field allows the responding system to return a precise response status. It is especially useful in the case where no data is found that matches the query parameters, but where there is also no error. It is defined with HL7 Table 0208 - Query Response Status.
115
QAK-3 Message Query Name (CE) 01375

Definition: This field contains the name of the query. This shall mirror the QPD-1 (Message Query Name) found in the query message that is being responded to.
QPDQueryParameterDefinition
The QPD segment defines the parameters of the query.
Table 5-19-Query Parameter Definition (QPD) SEQ 1 2 3-n 32 LEN Data Type CE ST varies Cardinality [1..1] Value Set 0471 ITEM# 01375 00696 01435 ELEMENT NAME Message Query Name Query Tag User Parameters (in successive fields) Usage R R R Generated by the initiating system. The specification of this sequence is found in the profile specific to the use case. Comment
QPDfielddefinitions
QPD-1 Message Query Name (CE) 01375
Definition: This field contains the name of the query. These names are assigned by the function-specific chapters of this specification. It is one to one with the conformance statement for this query name, and it is in fact an identifier for that conformance statement.
QPD-2 Query Tag (ST) 00696

Definition: This field must be valued by the initiating system to identify the query, and may be used to match response messages to the originating query. The responding system is required to echo it back as the first field in the query acknowledgement segment (QAK).
116
This field differs from MSA-2-Message control ID in that its value remains constant for each message (i.e. all continuation messages) associated with the query, whereas MSA-2-Message control ID may vary with each continuation message, since it is associated with each individual message, not the query as a whole.
QPD-3 User Parameters (Varies) 01435

Definition: These successive parameter fields hold the values that the Client passes to the Server. The client data is presented as a sequence of HL7 fields. Beginning at QPD-3-User parameters, the remaining fields of the QPD segment carry user parameter data. Each QPD user parameter field corresponds to one parameter defined in the Conformance Statement, where each name, type, optionality, and repetition of each parameter has been specified. While these parameters are understood to be usually and-ed together, the user must inspect the required Conformance Statement to properly understand each. Except in the QSC variant, the parameter names do not need to be stated in the query; they are understood to be positional based on the Conformance Statement. Each parameter field may be specified in the Conformance Statement to be of any single data type, including the complex QIP and QSC types. Parameter fields in the QPD segment appear in the same order as in the Conformance Statement.
RCPResponseControlParameterSegment
The RCP segment is used to restrict the amount of data that should be returned in response to query. It lists the segments to be returned.
117
Table 5-20-Response Control Parameter SEQ 1 LEN 1 Data Type ID Cardinality [0..1] Value set 0091 ITEM# 00027 ELEMENT NAME Query Priority Usage O Comments Constrain to empty or I. Immediate priority is expected. This field may contain a maximum number of records that may be returned. The first component contains the count and the second contains RD for records.
CQ
[0..1]
0126
00031
Quantity Limited Request
3 4 5 6 7 1
CE TS ID SRT ID
[0..1] [0..1] [0..1] [0..1] [0..*]
0394
01440 01441
Response Modality Execution and Delivery Time Modify Indicator Sort-by Field Segment group inclusion
O O O O O
0395
01443 01624 01594
RCPfielddefinitions
RCP-1 Query Priority (ID) 00027
Definition: This field contains the time frame in which the response is expected. Refer to HL7 Table 0091 - Query priority for valid values. Table values and subsequent fields specify time frames for response. Only I for immediate shall be used for this field.
RCP-2 Quantity Limited Request (CQ) 00031

Definition: This field contains the maximum length of the response that can be accepted by the requesting system. Valid entries are numerical values (in the first component) given in the units specified in the second component. Default is LI (lines). The expected type is records, so the second component is constrained to RD.
118
Note that this field is the maximum total records to return. The Version 2.5.1 standard indicates the maximum number to return in each batch. No batching of responses is permitted in this Guide.
RCP-3 Response Modality (CE) 01440

Definition: This field specifies the timing and grouping of the response message(s). Refer to HL7 Table 0394 Response modality for valid values.
RCP-7 Segment Group Inclusion (ID) 01594

Definition: Specifies those optional segment groups which are to be included in the response. Refer to HL7 Table 0391Segment group for values for Segment Group. This is a repeating field, to accommodate inclusion of multiple segment groups. The default for this field, not present, means that all relevant groups are included.
Note: Although the codes for segment groups are taken from HL7 Table 0391, the exact segment-level definition of a segment group (e.g. PIDG) is given only in the conformance statement of the query in which this segment group appears.
RXAPharmacy/TreatmentAdministrationSegment
TheRXAsegmentcarriespharmacyadministrationdata.ItisachildofanORCsegment,whicharepeatingsegmentintheRSPand VXUmessages.BecauseORCareallowedtorepeatanunlimitednumbersofvaccinationsmaybeincludedinamessage.EachRXA mustbeprecededbyanORC. 20 ThereisachangerequiringanORCconflictswiththepreviousimplementationGuide.Inthat,ORCisoptionalandinfactrarely includedinaVXU.
20
The HL7 Version 2.5.1 document clearly indicates that any RXA must be associated with an ORC. In the case of immunization, each immunization will have its own ORC.
119
Table 5-21 Pharmacy/Treatment Administration (RXA) SEQ 1 2 3 4 LEN 4 4 Data Type NM NM TS TS Cardinality [1..1] [1..1] [1..1] [0..1] Value Set ITEM # 00342 00344 00345 00346 ELEMENT NAME Give Sub-ID Counter Administration Sub-ID Counter Date/Time Start of Administration Date/Time End of Administration Administered Code Administered Amount Administered Units Usage R R R RE If populated, this should be the same as Start time (RXA-3) CVX code is strongly preferred. If administered amount is not recorded, use 999. If previous field is populated by any value except 999, it is required. The primary use of this field it to convey if this immunization record is based on a historical record or was given by the provider recording the immunization. All systems should be able to support this use. Other uses of this field are permitted, but need to be specified locally. Comment Constrain to 0 (zero) Constrain to 1
5 6 7 20
CE NM CE
[1..1] [1..1] [0..1]
0292
00347 00348 00349
R R CE
8 9
CE CE
[0..1] [0..*] NIP 0001
00350 00351
Administered Dosage Form Administration Notes
O RE
120
SEQ 10 11 12 13 14 15 16
LEN
Data Type XCN LA2
Cardinality [0..1] [0..1] [0..1] [0..1] [0..1] [0..*] [0..1]
Value Set
ITEM # 00352 00353 00354 01134 01135 01129 01130
ELEMENT NAME Administering Provider Administered-at Location Administered Per (Time Unit) Administered Strength Administered Strength Units Substance Lot Number Substance Expiration Date
Usage RE RE O O O RE CE
Comment This is the person who gave the administration.
20 20
ST NM CE
20
ST TS
If the lot number is populated, this field should be valued.
17 18
CE CE
[0..*] [0..*]
0227
01131 01136
Substance Manufacturer Name Substance/Treatment Refusal Reason Indication Completion Status
RE C If the Completion status is RE, then this shall be populated If this field is not populated, it is assumed to be CP or complete. If the Refusal reason is populated, this field shall be set to RE.
19 20 2
CE ID
[0..1] [0..1] 0322
01123 01223
O RE
21 22 23
2 5
ID TS NM
[0..1] [0..1] [0..1]
0323
01224 01225 01696
Action Code - RXA System Entry Date/Time Administered Drug Strength Volume
RE O O
121
SEQ 24 25 26
LEN
Data Type CWE CWE
Cardinality [0..1] [0..1] [0..1]
Value Set
ITEM # 01697 01698
ELEMENT NAME Administered Drug Strength Volume Units Administered Barcode Identifier Pharmacy Order Type
Usage O O O
Comment
ID
0480
01699
RXAfielddefinitions
RXA-1 Give Sub-ID Counter (NM) 00342
Definition: This field is used to match an RXA and RXG. Not a function under IIS. Constrain to 0 (zero).
RXA-2 Administration Sub-ID Counter (NM) 00344

Definition: This field is used to track multiple RXA under an ORC. Since each ORC has only one RXA in immunization messages, constrain to 1. This should not be used for indicating dose number, which belongs in an OBX. Note that the previous Implementation Guide suggested that this be used for indicating dose number. This use is no longer supported.
RXA-3 Date/Time Start of Administration (TS) 00345

Definition: The date this vaccination occurred. In the case of refusal or deferral, this is the date that the refusal or deferral was recorded.
RXA-4 Date/Time End of Administration (If Applies) (TS) 00346

Definition: In the context of immunization, this is equivalent to the Start date/time. If populated it should be = RXA-3. If empty, the date/time of RXA-3-Date/Time Start of Administration is assumed.
122
RXA-5 Administered Code (CE) 00347

Definition: This field identifies the medical substance administered. If the substance administered is a vaccine, CVX codes should be used in the first triplet to code this field (see HL7 Table 0292 - Codes for vaccines administered). The second set of three components could be used to represent the same vaccine using a different coding system, such as Current Procedural Terminology (CPT). CVX code is the strongly preferred code system.
RXA-6 Administered Amount (NM) 00348
Definition:Thisfieldrecordstheamountofpharmaceuticaladministered.Theunitsareexpressedinthenextfield,RXA7.Registries thatdonotcollecttheadministeredamountshouldrecordthevalue999inthisfield.
RXA-7 Administered units (CE) 00349
Definition: This field is conditional because it is required if the administered amount code does not imply units. This field must be in simple units that reflect the actual quantity of the substance administered. It does not include compound units. This field is not required if the previous field is populated with 999.
RXA-9 Administration Notes (CE) 00351

Definition: This field is used to indicate whether this immunization record is based on a historical record or was given by the reporting provider. It should contain the information source (see NIP-defined Table 0001 - Immunization Information Source). The first component shall contain the code, the second the free text and the third shall contain the name of the code system. (NIP001) Sending systems should be able to send this information. Receiving systems should be able to accept this information.
This field may be used for other notes if specified locally. The first repetition shall be the information source. If other notes are sent when information source is not populated, then the first repetition shall be empty. Other notes may include text only in component 2 of the repeat. Acceptance of text only is by local agreement only.
Information source is an NVAC core data element. It speaks to the reliability of the immunization record. IIS rely on this information.
123
RXA-10 Administering Provider (XCN) 00352

Definition: This field is intended to contain the name and provider ID of the person physically administering the pharmaceutical.
Note that previous Implementation Guide (2.3.1) overloaded this field by using local codes to indicate administering provider, ordering provider and recording provider. This is a misuse of this field and not supported in this Guide. The ordering and entering providers are indicated in the associated ORC segment.
RXA-11 Administered-at Location (LA2) 00353

Definition: The name and address of the facility that administered the immunization. Note that the components used are: Component 4: The facility name/identifier. Subcomponent 1:identifier 21 Subcomponent 2: Universal ID This shall be an OID, if populated. Note that this should not be a local code, but rather a universal id code. Subcomponent 3: Universal ID type (specify which universal id type) Note that if subcomponent 1 is populated, 2 and 3 should be empty. If subcomponent 2 is populated with an OID, subcomponent 3 must be populated with ISO. Component 9-15: Facility address. Components not specifically mentioned here are not expected in immunization messages.
RXA-15 Substance Lot Number (ST) 01129

Definition: This field contains the lot number of the medical substance administered. It may remain empty if the dose is from a historical record.
21
This value should uniquely identify a specific facility. Systems may choose to publish a table with local values.
124
Note: The lot number is the number printed on the label attached to the container holding the substance and on the packaging which houses the container. If two lot numbers are associated with a product that is a combination of different components, they may be included in this field. The first repetition should be the vaccine.
RXA-16 Substance Expiration Date (TS) 01130

Definition: This field contains the expiration date of the medical substance administered. It may remain empty if the dose is from a historical record.
Note: Vaccine expiration date does not always have a "day" component; therefore, such a date may be transmitted as YYYYMM.
RXA-17 Substance Manufacturer Name (CE) 01131

Definition: This field contains the manufacturer of the medical substance administered.
Note: For vaccines, code system MVX should be used to code this field.
RXA-18 Substance/Treatment Refusal Reason (CE) 01136

Definition: This field contains the reason the patient refused the medical substance/treatment. Any entry in the field indicates that the patient did not take the substance. If this field is populated RXA-20, Completion Status shall be populated with RE.
RXA-20 Completion Status (ID) 01223

This field indicates if the dose was successfully given. It must be populated with RE if RXA-18 is populated. If a dose was not completely administered or if the dose were not potent this field may be used to label the immunization.
RXA-21 Action Code RXA (ID) 01224

This field indicates the action expected by the sending system. It can facilitate update or deletion of immunization records. This field has a usage of RE. If it is left empty, then receiving systems should assume that the action code is A. ORC-3, Placer order number, may be used to link to a specific immunization if the system receiving the request has recorded this from the initial order. Local implementers should specify its use in a local implementation guide. The action code U ( Update system) is used to indicate to a subordinate receiver that a previously sent immunization should be changed. Most IIS have specific criteria for determining whether to add or update an immunization that does not rely directly on this field. For this
125
reason it is common practice to indicate action as Add even if this vaccination has been previously reported. It is important to not assume that Updates will be or need to be specifically indicated.
RXA-22 System Entry Date/Time (TS) 01225

This field records the date/time that this record was created in the originating system. Local implementations should specify its use.
RXRPharmacy/TreatmentRouteSegment
The Pharmacy/Treatment Route segment contains the alternative combination of route, site, administration device, and administration method that are prescribed as they apply to a particular order. Table 5-22 Pharmacy/Treatment Route (RXR) SEQ 1 2 3 4 5 6 LEN Data Type CE CWE CE CWE CE CWE Cardinality [1..1] [0..1] [0..1] [0..1] [0..1] [0..1] 0495 TBL# 0162 0163 0164 0165 ITEM # 00309 00310 00311 00312 01315 01670 ELEMENT NAME Route Administration Site Administration Device Administration Method Routing Instruction Administration Site Modifier Usage R RE O O O O Constraint
RXRfielddefinitions
RXR-1 Route (CE) 00309
Definition: This field is the route of administration. Refer to User-Defined Table 0162 - Route Of Administration for valid values.
This will change, based on HITSP. They specify use of FDA list. Systems should be prepared to accept either FDA or HL7 codes.
126
RXR-2 Administration Site (CWE) 00310

Definition: This field contains the site of the administration route.
RXR-3 Administration Device (CE) 00311

Not anticipated for IIS use.
RXR-4 Administration Method (CWE) 00312

RXR-5 Routing Instruction (CE) 01315

RXR-6 Administration Site Modifier (CWE) 01670

127
Chapter 6: Messages for Transmitting Immunization Information
6. Messages for Transmitting Immunization Information

Introduction
Thischapterdescribeseachofthemessagesusedtoaccomplishtheusecasesdescribed inpreviouschapters.ThesemessagesarebuiltfromthesegmentsdescribedinChapter 5,SegmentsandMessageDetails.TheSegmentsarebuiltusingtheDataTypesspecified inChapter4.Readersarereferredtothesechaptersforspecificsonthesecomponents. Issuesrelatedtosegmentsandfields,whicharemessagespecificwillbeaddressedin thischapter.
Table 6-1-Supported Messages
Message VXU QBP
RSP
ACK ADT
Purpose SendImmunization History Request Immunization HistoryandRequest PersonId RespondtoRequest forImmunization Recordand RespondtoRequest forPersonId SendMessage Acknowledgement SendPerson DemographicData
RelatedMessages ACK RSP
AssociatedProfiles Z34^CDC
QBP
Z31^CDC Z32^CDC
VXU,ADT,QBP ACK
SendImmunizationHistoryVXU
SystemsmaysendunsolicitedimmunizationrecordsusingaVXU.Thismaybearecord thatisnewtothereceivingsystemormaybeanupdatetoanexistingrecord.The followingtableliststhesegmentsthatarepartofaVXU.Someoftheoptionalsegments arenotanticipatedtobeused.SeeAppendixBfordetailedactivitydiagramsand examplemessagesthatillustratetheprocessingofthismessage.
Table 6-2--VXU Segment Usage
Segment MSH [{SFT}]
Cardinality [1..1] [0..*]
Usage R O
Comment EverymessagebeginswithanMSH. NotdescribedinthisGuide.Maybelocally specified. 128
Segment PID PD1 NK1 PV1
Cardinality [1..1] [0..1] [0..*] [0..1]
Usage R RE RE RE
PV2 GT1 Begin Insurance group IN1 IN2 IN3
[0..1] [0..*] [0..*]
O O O
Comment EveryVXUhasonePIDsegment. EveryPIDsegmentinVXUmayhaveoneorless PD1segment ThePIDsegmentinaVXUmayhavezeroormore NK1segments. ThePIDsegmentinaVXUmayhavezeroorone PV1segment.Subsequentmessagesregarding thesamepatient/clientmayhaveadifferentPV1 segment. NotdescribedinthisGuide.Maybelocally specified. NotdescribedinthisGuide.Maybelocally specified. Theinsurancegroupmayrepeat.
[0..1] [0..1] [0..1]
O O O
EndInsurancegroup BeginOrdergroup ORC [1..*] TQ1 TQ2 RXA RXR OBX NTE [0..1] [0..1] [1..1] [0..1] [0..*] [0..1]
RE O O R RE RE RE
EndOrderGroup Thefollowingdiagramillustratestherelationshipsofthesegments.Thecardinalityis displayedontheassociationlinks.Notethatinorderforasegmenttobepresentina

NotdescribedinthisGuide.Maybelocally specified. NotdescribedinthisGuide.Maybelocally specified. NotdescribedinthisGuide.Maybelocally specified. EachVXUmayhavezeroormoreOrdergroups TheordergroupinaVXUmayhaveoneormore ORCsegments. NotdescribedinthisGuide.Maybelocally specified. NotdescribedinthisGuide.Maybelocally specified. EachORCsegmentinaVXUmusthaveoneRXA segment.EveryRXArequiresanORCsegment. EveryRXAsegmentinaVXUmayhavezeroor oneRXRsegments. EveryRXAsegmentinaVXUmayhavezeroor moreOBXsegments. EveryOBXsegmentinaVXUmayhavezeroor oneNTEsegment.
129
message,itmustbeassociatedwithanyparentsegments.Forexample,theNTE segmentcanonlybeincludedinamessageasasubsegmenttoanOBX.Further,the OBXcanonlybepresentasachildofanRXA.Finally,asegmentthatisrequiredanda childofanothersegmentmustbepresentiftheparentispresent.Iftheparentisnot present,itisNOTpermitted.
Figure 6-1-VXU Domain Diagram
RequestingInformation(ImmunizationHistory)QBP
ThisdescriptionwillspecifytheuseofQBPformessaging,butisnotspecifictotheuse casesinthisGuide.FormalQueryandResponseProfilesforspecifyingthestructureto
130
supporttheusecaseswillfollowinChapter7.TheQBPqueryhasamatchingRSP response.(Seebelow)
QBP/RSP query by parameter/segment pattern response (events vary ) Table 6-3 QBP/RSP Query By Parameter/Segment Pattern Response Segment MSH Cardinality [1..1] Usage R Comment The MSH must include an identifier which indicates the Query Profile used. Not anticipated for use in immunization messages.
[{SFT}] QPD [ []
[0..1] [1..1] --- QBP begin [1..*]
O R R
The Query Profile will specify the list of fields and their components in the order that they will be expected for this query. The Query Profile will list the segments that are expected to be returned in response to this query. Not anticipated for use in immunization messages.
] RCP
--- QBP end Response Control Parameters R
[ DSC ]
Continuation Pointer
RespondtoRequestforInformationRSP
Thespecificationsbelowarenotspecifictotherequestforimmunizationhistory,but arethefoundationonwhichthosespecificationsarebased.TheQueryprofilefor requestinganimmunizationhistoryandtheassociatedResponsemaybefoundin Chapter7ofthisGuide. FormalProfilesbasedontheQueryProfileinChapter7willallowtherequestingsystem tobeinformediftheresponseisalistofcandidateclientsorasingleimmunization history.
131
Chapter 6: Messages for Transmitting Immunization Information Table 6-4-Segment Pattern Response (RSP) Segment MSH Cardinality [1..1] Usage R Comment The MSH will indicate which query is being responded to and what Query Profile it was based on. Not anticipated for use in immunization messages.
[{SFT}]
[0..1]
MSA [ ERR ] QAK QPD
[1..1] [0..1] [1..1] [1..1]
R O R R This segment echoes the Query Parameter Definition Segment sent in the requesting query. The specified segments and their contents as specified in the Segment Pattern from Query Profile, are returned here. May be empty if no records returned. Not anticipated for use in immunization messages.
--- SEGMENT_PATTERN begin [0..1] O
] [ DSC ]
--- SEGMENT_PATTERN end Continuation Pointer O
RequestingAnImmunizationHistoryfromAnotherSystemVXQ
TheuseofVXQisnotsupportedfor2.5.1immunizationmessaging. Version2.5.1implementationsareexpectedtosupportQBPstylequery.
AcknowledgingaMessageACK
TheACKreturnsanacknowledgementtothesendingsystem.Thismayindicateerrorsin processing.
Table 6-5 Message Acknowledgement Segment (ACK)
Segment MSH [{SFT}]
Cardinality (1..1) (0..1)
Usage R O
Comment
Not anticipated for use in immunization
132
Segment MSA [{ERR}]
Cardinality (1..1) (0..*)
Usage R RE
Comment
messages.
Includeifthereareerrors.
Note: For the general acknowledgment (ACK) message, the value of MSH-9-2-Trigger event is equal to the value of MSH-9-2-Trigger event in the message being acknowledged. The value of MSH-9-3-Message structure for the general acknowledgment message is always ACK.
SendingDemographicInformationVXUorADT
UseoftheADTmessageisrequiredforparticipationinthePIX/PDQprofilefor maintenanceoftheMasterPersonIndex.Inaddition,itmaybeusedtopopulateanIIS withdatafromsystemsthatdonotcontainimmunizationdataorthatcantproduce immunizationmessages. Inmostcases,atpresent,useoftheADTmessageisnotanticipatedforwidespreaduse outsideofthiscontext.SincethisImplementationGuidefocusesonmessaging immunizationinformation,thoseinterestedinuseoftheADTarereferredtoChapter3 oftheVersion2.5.1documentation.Inaddition,theIHEprofilesincludeclearguidelines onusinganADT.TheVXUmessagemaybeusedtoconveydemographicinformation withoutinclusionofimmunizationinformation,sinceORCareoptionalsegments. ADTmessagesshallnotbeusedfortransmittingimmunizationrecords.Theymaybe usedfortransmittingdemographicinformation. ThisGuidewillgivespecificationsfortheRegisterPatient(A04)message.Theonly differencesbetweenA04andA28aretheMessageType(MSH9)andtheadditionofa PDA(PatientDeathandAutopsy)segmentfortheA04variantoftheADT.TheGuidewill notprovidespecificationsforthefullsuiteofpatientmanagementactivities.Systems thatwillsupportthesemoreextensiveactivitiesshouldadoptanexistingprofileor developanimplementationguideorprofilespecifyingtheirlocaluse. IntegratingtheHealthcareEnterprise(IHE)haspublishedaprofilethatprovidessupport forthetransactionsthatsupportinteractionwithaMasterPersonIndex(MPI).Those planningextensiveuseofADTareurgedtoconsultthesedocuments. http://www.ihe.net/profiles/index.cfm http://www.ihe.net/Technical Framework/index.cfm 22
22
These links are current as of 5/1/2010. HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 1/31/2011
133
Chapter 6: Messages for Transmitting Immunization Information Table 6-6-ADT A04 Message
Segment MSH [{SFT}] EVN PID [PD1] [{ROL}] [{NK1}] PV1 [PV2] [{ROL}] [{DB1}] [{OBX}] [{AL1}] [{DG1}] [DRG] [{ PR1 [{ROL}] }] [{GT1}] [{ IN1 IN2 IN3 [{ROL}] }] [ACC] [UB1] [UB2] [PDA]
Cardinality [1..1] [0..*] [1..1] [1..1] [0..1] [0..*] [0..*] [1..1] [0..1] [0..*] [0..*] [0..*] [0..*] [0..*] [0..*] [0..1] [0..*] [0..*] [0..1] [0..1] [0..1] [0..*] [0..1] [0..1] [0..1] [0..1]
Usage R O R R RE O O R O O O O O O O O O O O O O O O O O O
Comment EverymessagebeginswithanMSH. EveryADThasoneEVNsegment. EveryADThasonePIDsegment. EveryPIDsegmentinADTmayhavezeroorone PD1segment ThePIDsegmentinaADTmayhavezeroormore NK1segments. ThePIDsegmentinanADTmusthaveonePV1 segment. ThePIDsegmentinanADTmayhavezeroormore OBXsegments.
SendingMessagesinaBatch
Systemsmaychoosetosendmessagesinbatches.Abatchbeginswithabatchheader statement(BHS)andendswithaBatchTrailerSegment.Batchesmayinturnbebatched intofilesofbatchesusingFileHeaderStatementandFileTrailerstatement.Ifasystemis 134
sendingasinglebatch,theFHS/FTSisnotnecessary.Astreamofmessagesmaybesent withoutuseofeitherBHSorFHS. Thegenericlayoutofabatchmessageisasfollows: BHS VXU VXU BTS Similarly,afileofbatchesislaidoutasfollows: FHS BHS VXU VXU BTS BHS VXU BTS FTS
135
Chapter 7:Query and Response Profile
7. Query and Response Profile (QBP/RSP)

RequestImmunizationHistoryQueryProfileZ34^CDCPHINVS
ThefollowingqueryprofilesupportsreplicationofthefunctionalityoftheVXQ/VXX/VXRqueryandresponses 23 .Implicitinthis profileisidentityresolutionasitwasinVXQ. SomesystemsmaywishtoseparatethisfunctionalityusingthePatientDemographicQuery(PDQ)profilefromIHE.Theresultsof theidentityresolutionaccomplishedwiththePDQcanbeusedwiththisqueryprofiletorequestanimmunizationhistory.Itis anticipatedthatonehighconfidencematchwillbetheresultsofthiseffortandthereturnresponsewillbeoneimmunization history.IHEalsohasaqueryprofiletosupportinteractionwithanMPI.ThePIXqueryrequestspatientidentifiercrossreference.It assumesthatthepertinentidentifiershavebeenregisteredusingADTmessages. IntegratingtheHealthcareEnterprise(IHE)haspublishedaprofilethatprovidessupportforthePDQquery.Inaddition,theyhave publishedasupplementalPediatricDemographicProfilethatoptimizesthePDQquerytosupportqueriesforchildrensidentifiers. http://www.ihe.net/profiles/index.cfm http://www.ihe.net/Technical Framework/index.cfm 24 SeeAppendixBformoredetailsontheprocesses. ThreeprofileswillbesupportedbyCDC.Oneprofilewillreflectthequeryasspecifiedbelow.Inadditiontwoprofileswillspecify constraintsontheresponsesreturnedinaresponsetothequery.Onewillspecifyasingleimmunizationhistoryreturned.The secondwillspecifyalistofcandidateclientsandtheiridentifiers.
23
This functionality entails a query that uses demographic and other identifying information to request an immunization history. If one or more lower confidence candidates are found a list of candidates is returned. If a single high-confidence match is found, an immunization history is returned. 24 These links are current as of 5/1/2010.
136
Request Immunization History Query Profile

Table 7-1 Request Immunization History Query Profile
Query Statement ID (Query ID=Z34): Type: Query Name: Query Trigger (= MSH-9): Query Mode: Response Trigger (= MSH-9): Query Characteristics: Z34 Query Request Immunization History QBP^Q11^QBP_Q11 Both RSP^K11^RSP_K11 The query parameters may include demographic and address data. No sorting is expected. This profile does not specify the logic used when searching for matching clients/patients. The query parameter contents may be used for simple query or as input for probabilistic search algorithms. The search methodology should be specified by local implementations. Purpose: Response Characteristics: The purpose is to request a complete immunization history for one client. In the case where no candidates are found, the response will indicate that no candidates were found. In the case where exactly one high-confidence candidate is found, an immunization history may be returned. In the case where one or more clients could match the criteria sent, a list of candidates may be returned to allow for refinement of the query. If the number of candidates exceeds the maximum number requested or allowed for return, the response will indicate too many matches and no records will be returned. In the case where receiving system cant process the query, the receiving system will indicate an error.
Based on Segment Pattern:
NA
137
Notethatwhenonepatientisfound,aReceivingsystemmaychoosetosendanimmunizationhistoryoralistofonepatient identifiersdependingonthelocalbusinessrules.Thisshouldbeclearlydocumentedinalocalprofile. Eachsystemwillneedtodeterminethebusinessrulesthatdealwithpatientswhowishtohavetheirrecordsprotected.Some systemsmaychoosetotreatthepersonasiftheyarenotinthesystem.Othersmaychoosetosendaresponseindicatingthatthe personexistsinthesystembutdoesnotallowsharing.Thisruleshouldbeclearlydocumentedinthelocalprofile. QueryGrammar QBP^Q11^QBP Q11 Query Grammar: QBP Message Usage Comment
MSH [{SFT}] Message Header Segment Software Segment R O Local profile may specify QPD RCP [ DSC ] Query Parameter Definition Response Control Parameter Continuation Pointer R R X Not supported
ResponseGrammar
Table 7-2-Response Grammar to Different Outcomes
OutcomeofQuery Nomatchfound
ResponseMessage Responseindicatesthatmessagewassuccessfullyprocessedandthatno clientsmatchedthecriteriathatweresentinthequery.
138
Responseincludesacompleteimmunizationhistoryasspecifiedbelow. SeeProfileReturnImmunizationHistory. 26 Atleastonelowerconfidencematch is ResponsereturnsonePIDwithassociatedPD1andNK1segmentsforeach found,but<=maximumnumberallowed. potentialmatch.Noimmunizationhistoryisreturned. SeeProfileReturnCandidateList. Morethanthemaximumnumberallowedis Responseindicatesthatthemessagewassuccessfullyprocessed,butthat found. toomanypotentialmatcheswerefound. Themaximumnumberallowedisthelowerofthemaximumnumber requestedandthemaximumnumberthatthereceivingsystemwillreturn. Messageisnotwellformedandhasfatal Responseindicatesthatthemessagewasnotsuccessfullyprocessedand errors. mayindicateerrors. Theresponsegrammarbelowwillaccommodateeachofthecasesabove.Ifonehighconfidencecandidateisfoundthenanentire immunizationhistorymaybereturned.Ifoneormorelowerconfidencecandidatesarefound,thenalistofpatientidentifiersmay bereturned. Theusageofsegmentswillbespecifiedintwoseparateprofiles.Thefirstprofilewilladdressthecasewhereoneormorelower confidencematchesarefound.Inthiscasealistofcandidateswillbereturned.Thesewillnothaveimmunizationhistories.(Similar toV2.3.1VXX)Theotherprofilewillhandlethecasewherethereceivingsystemfindsonehighconfidencematch.Inthiscaseone clientimmunizationrecordwillbereturned(similartoV2.3.1VXR).
Definition of match is left to local business rules. These rules should be documented in a local implementation guide. For example, a system may only return an immunization history when the match is exact, returning a list of 1 if one person for a lower probability match. 26 More than one high confidence match constitutes is considered a set of lower confidence matches.
25
Exactlyonehighconfidencematchfound 25
139
ResponseGrammarRSP^K11
Table 7-3 Response Grammar RSP^K11 Segment MSH MSA [ERR] QAK QPD [{ [{ PID [PD1] [{NK1}] }] [ [PV1] [IN1] [{ ORC RXA [RXR] [{ OBX [NTE] [1..1] [0..1] [0..*] [1..1] [0..1] R RE RE R RE [0..1] [0..1] [0..1] [0..*] [1..1] O RE RE RE R Cardinality [1..1] [1..1] [0..1] [1..1] [1..1] [0..1] [0..*] [1..1] [0..1] [0..*] HL7 Optionality 27 R R O R R O O R RE RE Query Parameter Definition Segment 28 --- Response begin 29 Beginpatientidentifier Comment

If errors exist, then this segment is populated.
EndPatientIdentifier Beginimmunizationhistory
BeginOrder Requiredifclienthasimmunizationrecords (RXA).ThereisoneORCforeachRXA BeginPharmacyAdministration
BeginObservation
27 28
Optionality is not the same as Usage, but rather the standard definitions of HL7. Matches the information in the requesting QBP message. 29 If a query errors out or if no matching persons are found the segments in the Response group will not be returned.
140
}] }] ] }]
Endobservation EndPharmacyAdministration EndOrder EndImmunizationHistory Responseend
141
MSH - MESSAGE HEADER SPECIFICATION

Table 7-4 MSH Specification for Request Immunization History Query SEQ 1 2 3 4 5 6 7 26 LEN 1 4 Data Type ST ST HD HD HD HD TS Cardinality [1..1] [1..1] [0..1] [0..1] [0..1] [0..1] [1..1] 0361 0362 0361 0362 Value set ITEM # 00001 00002 00003 00004 00005 00006 00007 ELEMENT NAME Field Separator Encoding Characters Sending Application Sending Facility Receiving Application Receiving Facility Date/Time Of Message Usage R R RE RE RE RE R Constraint The MSH.1 field shall be | The MSH.2 field shall be ^~\& No constraint No constraint No constraint No constraint The degree of precision must be at least to the second, and the time zone must be included (format YYYYMMDDHHMMSS[.S[S[ S[S]]]]+/-ZZZZ). QBP^Q11^QBP_Q11
8 9 10 11 12 13 14 15
40 15 20 3 15 180 2
ST MSG ST PT VID NM ST ID
[0..1] [1..1] [1..1] [1..1] [1..1] [0..1] [0..1] [0..1] 0155
00008 00009 00010 00011 00012 00013 00014 00015
Security Message Type Message Control ID Processing ID Version ID Sequence Number Continuation Pointer Accept Acknowledgment Type
O R R R R O O RE NE-Never 2.5.1
142
SEQ 16 17 18 19 20 21
LEN 2 3 16
Data Type ID ID ID CE
Cardinality [0..1] [0..1] [0..1] [0..1] [0..1] [1..1]
Value set 0155 0399 0211
ITEM # 00016 00017 00692 00693
ELEMENT NAME Application Acknowledgment Type Country Code Character Set Principal Language Of Message Alternate Character Set Handling Scheme Message Profile Identifier
Usage RE O O O O R
Constraint
AL-Always
blank blank blank blank Z34^ CDCPHINVS
20
ID EI
0356
01317 01598
QPDInputParameterSpecification
Table 7-5 QPD Input Parameter Specification
Field Seq (Query ID=Z34) 1 Name Key/ Search Sort LEN TYPE Opt Rep Match Op TBL Segment Field Name Service Identifier Code Element Name or Value Z34^Request Immunization History^HL70471 Y PID.3 PID.5 PID.6 PID.7 PID.8 PID-3: Patient Identifier List PID-5: Patient Name PID-6: Mothers maiden name PID-7: Patient date of birth PID-8: Patient sex
MessageQueryName
CE
2 3 4 5 6 7
QueryTag PatientList PatientName PatientMotherMaiden Name Patient Date of Birth Patient Sex
32
ST CX XPN XPN
R RE RE RE RE RE
26 1
TS IS
143
Field Seq (Query ID=Z34) 8 9 10 11 12 13
Name
Key/ Search
Sort
LEN
TYPE
Opt
Rep
Match Op
TBL
Segment Field Name PID.11 PID.13 PID-24 PID-25 PID-33 PID-34
Service Identifier Code
Element Name or Value PID-11: Patient Address PID-13: Patient home phone PID-24: Patient multiple birth indicator PID-25: Patient birth order PID-33: Patient last update date PID-34: Patient last update faciliity
Patient Address Patient home phone Patient multiple birth indicator Patient birth order Client last updated date Client last update facility 1 2
XAD XTN ID NM TS HD
RE RE RE RE RE RE
QPDInputParameterFieldDescriptionandCommentary
Table 7-6 QPD Input Parameter Field Description and Commentary
Input Parameter (Query ID=Z34) Comp. Name DT Description
144
Input Parameter (Query ID=Z34)
Comp. Name
DT
Description
MessageQueryName QueryTag PatientList
CE ST CX
Z34^Request Immunization History^HL70471 Unique to each query message instance. The combination of values for Patientlist.ID, patientlst.identifiercode and Patientlist.AssigningAuthority are intended to allow unique identification of a client, if the data are found in the responding system. If this field, PID.3.1, is not valued, PatientList is not considered when seeking matching clients. If this field, PID.3.4, is not valued, PatientList is not considered when seeking matching clients. If this field, PID.3.5, is not valued, PatientList is not considered when seeking matching clients. If this field, PID.5, is not valued, then the query will return an error, since this is a required field. If this field, PID.5.1, is not valued, then patient name is considered to contain no value. If this field, PID.5.2, is not valued, then patient name is considered to contain no value. Given name is required. If this field, PID.5.3, is not valued, then all values for this field are considered a match. If this field, PID.5.4, is not valued, then all values for this field are considered a match. If this field, PID.6, is not valued, Mothers maiden name is not considered when seeking matching clients. If this field, PID.6.1, is not valued, then mothers maiden name is considered to contain no value. If this field, PID.6.2, is not valued, then all values for this field are considered a match. If this field, PID.7, is not valued to an accuracy of at least day,
ID Assigning Authority IdentifierTypeCode PatientName Family Name Given Name Second or further names Suffix Mothers Maiden Name Family Name Given Name DateOfBirth
ST HD IS XPN FN ST ST ST XPN FN ST TS
145
Comp. Name
DT
Description
then this field is considered not valued. Sex Address Street Address City State ZIP Address Type Phone IS XAD SAD ST ST ST IS XTN If this field, PID.8, is not valued, then all values for this field are considered a match. If this field, PID.11, is not valued, then address will not be considered when seeking matching clients. If this field, PID.11.1, is not valued, then all values for this field are considered a match. If this field, PID.11.3, is not valued, then address is considered to contain no value. If this field, PID.11.4, is not valued, then address is considered to contain no value. If this field, PID.11.5, is not valued, then all values for this field are considered a match. If this field, PID.11.7 is not valued, then it shall default to L, legal address. This field will be considered the Home phone. If this field, PID.13, is not valued, then phone number is not considered when seeking matching clients. If this field, PID.13.6, is not valued, then all values for this field shall be considered matches. If this field, PID.13.7, is not valued, then address is considered to contain no value. If this field, PID.24, is not valued, then Multiple Birth Indicator is not considered when seeking matching clients. If this field, PID.25, is not valued, then birth order is not considered when seeking matching clients. If this field, PID.33, is not valued, then client last updated date is not considered when seeking matching clients. If this field, PID.34, is not valued, then client last updating facility
Area code Local number Multiple Birth Indicator Birth Order Client last updated date Client last update facility
NM NM ID NM TS TS
146
Comp. Name
DT
Description
is not considered when seeking matching clients.
AllofthefieldsusedforsearchinginthequeryparametersarelistedasRequiredbutmaybeempty(RE)intheGuide.However, localbusinessrulesmayconstrainthis.Forinstance,asystemmayrequirename,dateofbirthandpatientid.Alternatively,itmay requirethatatleastfourfieldsarepopulatedorsomeotherbusinessrule.Thismustbedocumentedinalocalimplementationguide orprofile. ThisGuidedoesnotspecifysearchlogic.Itspecifiesthestructureandcontentofthemessageusedtoquery.Itisincumbenton systemstopublicallydocumenttheirexpectationswithintheconstraintsofthisguide. RCPResponseControlParameterFieldDescriptionandCommentary

Table 7-7 RCP Response Control Parameter Field Description and Commentary
Field Seq (Query ID=Z34) 1 2 Name Component Name LEN DT Description
Query Priority Quantity Limited Request Quantity Units
1 10
ID CQ NM CWE
If this field is not valued then it shall default to I. The only value permitted is I. The maximum number of patients that may be returned. This value is set by the requester. The sender may send up to this number. This value shall be RD (records) Real time or Batch. Default is R. This field shall be empty.
3 7
Response Modality Segment group inclusion
60 256
CWE ID
147
ReturnaListofCandidatesProfileZ31^CDCPHINVS
HL7Version2.5.1MessageProfileforReturningaListofCandidatesinResponsetoaRequestImmunizationHistoryQuery Introduction: Akeytaskthatmustbeaccomplishedforimmunizationmessagingisrequestinganimmunizationhistoryfromanotherinformation system.Thereare4possibleoutcomestoarequestforimmunizationquery.
Table 7-8 Query Response Possibilities
Outcome Noclientsarefoundthatmatchthe requestedperson Exactlyonehighconfidencematchis found. Oneormorelowerconfidencepersons matchthecriteriasent.Matchingmore thanonehighconfidencecandidate constitutesalowerconfidencematch. Themessageisnotwellformedandcant beprocessed.
Action Sendacknowledgementindicatingno matchesfound. ReturnImmunizationhistory(SeeZ32 profile) Returnalistofcandidatesforfurther refinementofselection.
Returnerroracknowledgement
ThisprofileconstrainstheQBPQuery,RequestImmunizationHistoryQueryZ34,thatisspecifiedabove.Thegoalofthisprofileisto constraintheresponsespecifiedintheRequestImmunizationHistoryqueryprofiletoalistofpatientsandtheiridentifiers.Inall otheraspectsitconformscompletelywiththespecificationsdescribedinthatqueryprofile.
148
UseCase:
Figure 7-1--Return Candidate List
Name: ReturnCandidateList Actors: 1. ImmunizationHistoryRequesterisasystemthatrequestsanimmunizationhistoryforaspecificindividual.Inthisusecase, itreceivesthecandidatelistsent. 2. ImmunizationHistorySupplierreturnscandidatelisttoarequesterforinresponsetoarequestforimmunizationhistory. Preconditions: 1. TheHistorySupplierhasfoundrecordsforoneormorepersonswhomatchtheparametersinthequery. 2. TheHistorySupplierhascreatedtheresponsemessage. FlowofEvents: 1. TheHistorySuppliersendstheRSPresponsemessage. 2. TheHistoryRequesterreceivestheRSPresponsemessage.
149
PostConditions: 1. TheHistoryRequesterhasalistofcandidatesforreviewandselection. StaticDefinition ResponseGrammarRSP^K11ConstrainedbyThisProfile ThisprofileconstrainstheRequestforImmunizationQueryResponseGrammarbychangingthecardinalityoftheImmunization Historyblockto[0..0].Noneofthesegmentswithinthatblockwillbereturned. ResponseGrammarRSP^K11

Table 7-9 Response Grammar RSP^K11 Segment MSH MSA [ ERR] QAK QPD [{ [{ PID [PD1] [{NK1}] Cardinality [1..1] [1..1] [0..1] [1..1] [1..1] [1..1] [1..*] [1..1] [0..1] [0..*] HL7 Optionality R R O R R R R R RE RE Query Parameter Definition Segment 30 --- Response begin 31 Beginpatientidentifier Comment

30 31
Matches the information in the requesting QBP message. If a query errors out or if no matching persons are found the segments in the Response group will not be returned.
150
}] [ [0..0] X
EndPatientIdentifier Beginimmunizationhistory Allsegmentsbelowarenot returnedbecausethisgroupis notsupportedinthisresponse profile.Thecardinalityandusage foreachsegmentbelowisnot changed.
[PV1] [IN1] [{ ORC
[0..1] [0..1] [0..*] [1..1]
RE RE RE R
RXA [RXR] [{ OBX [{NTE}] }] }] ] }] [1..1] [0..1] [0..*] [1..1] [0..*] R RE RE R RE
BeginOrder Requiredifclienthas immunizationrecords(RXA). ThereisoneORCforeachRXA BeginPharmacyAdministration
BeginObservation

Endobservation EndPharmacyAdministration EndOrder EndImmunizationHistory Responseend
Thisprofileindicatesthatalistofpatientidentificationshallbereturned.ItshallbeidentifiedinMSH21byitsprofileidentifier.
151
SegmentLevelProfile Thisprofilemakesnochangestotheparentqueryprofile. FieldLevelProfile Thisprofilemakesnochangestotheparentqueryprofile,withtheexceptionoftheMSH21field,whichcontainstheprofile identifier,Z31^CDCPHINVS.
152
DynamicDefinition
Sequence Diagram
Figure 7-2 Return Candidate List (RSP^K11)
Thisdiagramillustratesthecontextofthemessage.ThemessagespecifiedinthisprofileisinBoldandlabeledReturnCandidate List(RSP^K11). AcknowledgementResponsibilities Applicationlevelacknowledgementisallowed,butnotrequired.
153
ReturnanImmunizationHistoryZ32^CDCPHINVS
HL7Version2.5.1MessageProfileforReturninganImmunizationHistory Introduction: Akeytaskthatmustbeaccomplishedforimmunizationmessagingisrequestinganimmunizationhistoryfromanotherinformation system.Onecomponentofthatprocessisreturninganimmunizationhistory.ThisprofileconstrainstheQBPQuery,Request ImmunizationHistoryQueryZ34,thatisspecifiedabove.Thatqueryprofilespecifiesthequeryforrequestinganimmunization historyandisintendedtosupport2typesofresponse.Oneresponsereturnsalistofcandidateclient/patientstobethebasisof furtherselection.Thatselectionisthenusedtorequeryforanimmunizationhistory.Thesecondisaresponsethatreturnsan immunizationhistory.Thissecondisthefocusofthismessageprofile.Thegoalofthisprofileistoconstraintheresponsespecifiedin theRequestImmunizationHistoryqueryprofiletoasingleimmunizationhistory.Inallotheraspectsitconformscompletelywiththe specificationsdescribedintheimplementationGuideforthisqueryprofile. UseCase: Name:
ReturnImmunizationHistory
154
Figure 7-3 Return Immunization History Use Case
Actors: 1. ImmunizationHistoryRequesterisasystemthatrequestsanimmunizationhistoryforaspecificindividual.Inthisusecase, itreceivestheimmunizationhistorysent. 2. ImmunizationHistorySupplierreturnsanimmunizationhistorytoarequesterforaspecificindividualinresponsetoa requestforimmunizationhistory. Preconditions: 1. TheHistorySupplierhasfoundtherecordsfortherequestedperson. 2. TheHistorySupplierhascreatedtheresponsemessage. FlowofEvents: 1. TheHistorySuppliersendstheRSPresponsemessage. 2. TheHistoryRequesterreceivestheRSPresponsemessage. PostConditions:
155
1. TheHistoryRequesterhastheimmunizationhistory. StaticDefinition ResponseGrammarRSP^K11ConstrainedbyThisProfile ThisprofileconstrainstheRequestforImmunizationQueryResponseGrammarbychangingthecardinalityoftheresponsetoone repetition. ResponseGrammarRSP^K11

Figure 7-4 Return Immunization History Response Grammar Segment MSH MSA [ERR] QAK QPD [ Cardinality [1..1] [1..1] [0..*] [1..1] [1..1] [0..1] Query Parameter Definition Segment 32 --- Response control parameter begin Note Changed Cardinality Beginpatientidentifier Comment

PID [PD1] [{NK1}]

32
(1..1) (0..1) (0..*) EndPatientIdentifier
Matches the information in the requesting QBP message.
156
[ PV1 ] [ IN1 ] [{ ORC (0..1) (0..*) [1..1] (0..1)
Beginpatientvisit
BeginInsurance EndInsurance BeginOrder Requiredifclienthas immunizationrecords(RXA). ThereisoneORCforeachRXA BeginPharmacyAdministration
RXA [RXR] [{ OBX [{NTE}] }] }] ] --(1..1) (0..1) (0..*) (1..1) (0..*)
BeginObservation

Endobservation EndPharmacyAdministration EndOrder Responsecontrolparameterend
Thisprofileindicatesthatonlyonerepetitionofanentireimmunizationhistoryshallbereturned.ItshallbeidentifiedinMSH21by itsprofileidentifier,Z32^CDCPHINVS. SegmentLevelProfile Thisprofilemakesnochangestotheparentqueryprofile.
157
FieldLevelProfile Thisprofilemakesnochangestotheparentqueryprofile,withtheexceptionoftheMSH21profileidentifier,Z32^CDCPHINVS. DynamicDefinition

Sequence Diagram
Figure 7-5 Return Immunization History Sequence Diagram
Thisdiagramillustratesthecontextofthemessage.ThemessagespecifiedinthisprofileisinBoldandlabeledReturnImmunization History(RSP^K11).
Acknowledgement Responsibilities
Applicationlevelacknowledgementisallowed,butnotrequired. 158
Change History
Change History Details

Table 10--Release 1.1 Changes
Location Page100 Page46 Page124 AppendixA1 AppendixA2andA3 AppendixA33 AppendixA2 AppendixA30 AppendixA30 AppendixA36 Location AppendixA18 AppendixAmultiple Chapter6,page129 Chapter5,p72 Chapter5,p72and throughoutGuide Chapter7,p140 Chapter7,page156 Chapter7,page157 Chapter4,page61 AppendixB,throughout AppendixB15
Change PD14PrimaryProvider.CorrecteddatatypetoXCN. CorrectedusagedefinitionsforEIEntityIdentifierdata type. ClarifieddefaultactionifRXA21ActionCodeisnot populated. AddedcopyrightnoteonLOINCcodes.Addedreference toSNOMED.AddedreferencetoPHINVADS RemovedlinkstodeadwebpagesonRaceandEthnicity. AddedNCITtocodes CorrectedValuesetOIDforrace. CorrectedcodeforAllergytoproteinofrodentorigin. RemovedduplicaterowVXC28 CorrectedLOINCcodeforcontraindication
Table 111--Release 1.2 Changes
Change Addedexampleofresponsetoquerythatfoundtoo manycandidates. Correcteduseofprofileidentifiersintheresponses. ChangedHL70396toCDCPHIVS. CorrectedcardinalityofGT1andInsurancesegment group. CorrectedspellingofBHS Changednulltoemptyindatatypes,fieldsand segments.Insomecasesdeletedcontentsofcell Correctedcardinality RemovedextraneousRCProwintable. IncludeprofileidinthetextexplainingZ32^CDCPHINVS IllustrateduseofHDdatatypeinXCN CorrectedQuerynametoZ34^Request Immunization
History^CDCPHINVS
CorrectedLOINCinexamplemessage.Itwassetto Reaction,butshouldbe597799,scheduleused. Chapter5,page105 CorrectedcardinalityofPID1 Chapter5,variouspages CorrectedcardinalityoffieldswithusageofX(not supported)from[0..1]to[0..0] Chapter5,page108 CorrecteddatatypeofPID39TribalcitizenshipfromCE toCWE HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) 159
1/31/2011
Change History
Chapter5,page101 Chapter5,page91 Chapter4,page50 Chapter5,page823 Chapter5,page96 AppendixA,Table0363
CorrecteddatatypesforallPD1fields. CorrectedusageofOBX1 AddedreferencetoUserdefinedtables03610363 Clarifiedusageoftables0361and0362 CorrectedORC3usage Addedtablewithvalueset
160
APPENDIX A: Code Tables

Author Date RobSavage 5/1/2010 RobSavage 8/15/2010 RobSavage 2/15/2011 NOTE:WhereonlyselectedvaluesarelistedforHL7tables,pleaserefertotheHL7 Standardforcompletelistings.Inthisappendix,valuesareselectedfromstandard codesetswhereavailable.TheValueSetsaremaintainedinthePHINVADSforusein PublicHealth.ThemainpurposeofPHINVADSistodistributevocabularysubsets neededinPublicHealth.Thelatestversionofvaluesetsreferencedinthis ImplementationGuidecanbeobtainedfromPHINVADSat[http://phinvads.cdc.gov]. Searchusingkeywordimmunization. ThismaterialcontainscontentfromLOINC(http://loinc.org).TheLOINCtableand LOINCcodesarecopyright19952010,RegenstriefInstitute,Inc.andtheLogical ObservationIdentifiersNamesandCodes(LOINC)Committee. ThismaterialcontainscontentfromSNOMEDCT.SNOMEDCT(Systematized NomenclatureofMedicineClinicalTerms)isacomprehensiveclinicalterminology, originallycreatedbytheCollegeofAmericanPathologists(CAP)and,asofApril2007, owned,maintained,anddistributedbytheInternationalHealthTerminology StandardsDevelopmentOrganization(IHTSDO),anonforprofitassociationin Denmark.TheCAPcontinuestosupportSNOMEDCToperationsundercontracttothe IHTSDOandprovidesSNOMEDrelatedproductsandservicesasalicenseeofthe terminology. UserdefinedTable0001Sex[valuessuggestedbyHL7](useinPID8,NK115) Thiscodereflectstheselfreportedgender. ValuesetOID: 2.16.840.1.113883.1.11.1 Definition Value Description F M U
Appendix A - A1 HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) Last Updated on 1/31/2011
RevisionHistory Revision Release1 Release1.1 Release1.2
Female Male Unknown/undifferentiat ed
Personreportsthatsheisfemale. Personreportsthatheismale. NoassertionIsmadeaboutthegenderofthe person.
HL7definedTable0003Eventtype[onlyselectedvalueslisted](useinMSH9,second component) Thiscodeindicatesthetriggerevent.RefertoChapter3,Version2.5.1forfurther informationonHL7eventtriggers. Value Description A28 A08 A04 Q11 K11 V04 ADT/ACKAddpersoninformation ADT/ACKUpdatepersoninformation ADT/ACKRegisterapatient QBPQuerybyparameterrequestinganRSPsegmentpatternresponse(Query forvaccinationrecord) RSPSegmentpatternresponseinresponsetoQBP^Q11(Responseto vaccinationquery) VXUUnsolicitedvaccinationrecordupdate
UserdefinedTable0004Patientclass[valuessuggestedbyHL7](useinPV12) Thiscodecategorizesthepatientinthecurrentevent. TheonlyvaluesupportedisRforrecurringpatient.ForacurrentlistofHL7values pleasereferencetheHL7version2.5.1documents. UserdefinedTable0005Race[ThesevaluesareconsistentwiththeOMBNoticeof revisedcategoriesforcollectionofraceandethnicitydatathecombinedformat.](use inPID10,NK135) Thiscoderepresentstheclientsselfreportedrace. ValuesetOID: 2.16.840.1.114222.4.11.836 USracecodes Description
10025 20289 20768 20545 21063 21311 <emptyfield>
AmericanIndianorAlaskaNative Asian NativeHawaiianorOtherPacificIslander BlackorAfricanAmerican White OtherRace Unknown/undetermined
Thefollowingtableisincludedforreference.TheNIPoriginalracecodesarestill acceptedforbackwardscompatibility.ThenumericcodeUSracecodesshouldbeused.
USracecodes
Description AmericanIndianor AlaskaNative Asian NativeHawaiianor OtherPacificIslander BlackorAfrican American White OtherRace Unknown
NIP original race codes
Description
10025 20289 20768 20545 21063 21311
I A A B W O U
AmericanIndian orAlaskaNative AsianorPacific Islander AsianorPacific Islander BlackorAfrican American White Other Unknown
HL7definedTable0008Acknowledgmentcode(useinMSA1) Thiscodeindicatesthetypeofacknowledgementexpected. Value Description AA AE AR CA CE CR Originalmode:ApplicationAccept Enhancedmode:Applicationacknowledgment:Accept Originalmode:ApplicationError Enhancedmode:Applicationacknowledgment:Error Originalmode:ApplicationReject Enhancedmode:Applicationacknowledgment:Reject Enhancedmode:Acceptacknowledgment:CommitAccept Enhancedmode:Acceptacknowledgment:CommitError Enhancedmode:Acceptacknowledgment:CommitReject
UserdefinedTable0010PhysicianID(useinallXCNdatatypes;includingPV1 7,8,9,17,RXA10) [locallydefined]Eachregistryshouldestablishasystemofcodingitsreporting physicians.TheNationalProviderIdentifier(NPI)adoptedfortheHIPAAlegislationmay beusedforthispurpose. HL7definedTable0061Checkdigitscheme(useinallCXdatatypes;includingPID 2,3,4,18,21) Value Description

M10 M11 ISO NPI
Mod10algorithm Mod11algorithm ISO7064:1983 CheckdigitalgorithmintheUSNationalProviderIdentifier
UserdefinedTable0063Relationship[asdefinedinHL7sVersion2.4](useinNK13, IN117) Value Description BRO Brother CGV Caregiver FCH Fosterchild FTH Father GRD Guardian GRP Grandparent MTH Mother OTH Other PAR Parent SCH Stepchild SEL Self SIB Sibling SIS Sister SPO Spouse UserdefinedTable0064Financialclass[NIPsuggestedvalues](useinPV120) Financialclassreferencesaclientseligibilitystatusatapointintime.Thevaluesinthis tablerelatetoeligibilityfortheVaccineforChildren(VFC)program.Local implementationsmaydefineanddocumentlocalcodes. NotethatfundingsourceforaspecificimmunizationisdifferentfromFinancialClass. ThesearedocumentedinCDClocalcodestable,CDCPHINVS(ValuesetOID 2.16.840.1.114222.4.11.3287). Code Lable Definition V01 Not VFC eligible Client does not qualify for VFC because they do not have one of the statuses below. This category does not include the underinsured (see V08). V02 VFC eligibleClient is currently on Medicaid or Medicaid Medicaid/Medicaid managed care. Managed Care V03 VFC eligibleClient does not have insurance coverage for Uninsured vaccinations.
V04
V05
V06
V07
V08
VFC eligibleAmerican Indian/Alaskan Native VFC eligibleFederally Qualified Health Center Patient (under-insured) VFC eligible- State specific eligibility (e.g. S-CHIP plan) VFC eligibilityLocal-specific eligibility Not VFC eligibleUnder-insured
Client is a member of a federally recognized tribe.
Client has insurance that partially covers vaccines received on visit and so is eligible for VFC coverage at a Federally Qualified Health Center. The client must be receiving the immunizations at the FQHC. Client is eligible for VFC, based on State-specific rules, such as S-CHIP. Client is eligible for VFC, based on local-specific rules. Client has insurance that partially covers vaccines received on visit. The immunizations were not administered at a Federally Qualified Health Center (FQHC)
HL7definedTable0076Messagetype[onlyselectedvalueslisted](useinMSH9,first component)
Value Description Usage in this guide
ACK ADT QBP RSP VXU
Generalacknowledgment ADTmessage QuerybyParameter ResponsetoQuerybyparameter Unsolicitedvaccinationrecordupdate
Supported Supported Supported Supported Supported
HL7definedTable0078Abnormalflags(useinOBX8) Fieldsusingthiscodesetareexpectedtobeempty.ForacurrentlistofHL7values pleasereferencetheHL7version2.5.1documents. HL7definedTable0085Observationresultstatuscodesinterpretation(useinOBX 11) FieldsusingthiscodesetareexpectedtobeFforFinal.ForacurrentlistofHL7values pleasereferencetheHL7version2.5.1documents. HL7definedTable0091Querypriority FieldsusingthiscodesetareexpectedtobeIorempty,whichindicatesImmediate processingisexpected.ForacurrentlistofHL7valuespleasereferencetheHL7version 2.5.1documents.
HL7definedTable0102Delayedacknowledgmenttype(useinMSA5) Fieldsusingthiscodesetareexpectedtobeempty.ForacurrentlistofHL7values pleasereferencetheHL7version2.5.1documents. HL7definedTable0103ProcessingID(useinMSH11) Value Description D P T Debugging Production Training
HL7definedTable0104VersionID(useinMSH12) Value Description 2.1 2.2 2.3 2.3.1 2.4 2.5.1 Release2.1 Release2.2 Release2.3 March1997 Release2.3.1May1999 Release2.4October2000 Release2.5.1April2007
HL7definedTable0105Sourceofcomment(useinNTE2) Fieldsusingthiscodesetareexpectedtobeempty.ForacurrentlistofHL7values pleasereferencetheHL7version2.5.1documents. HL7definedTable0119OrderControlCodes(useinORC1)

Value Description Usage
OK RE
Orderaccepted&OK Observationstofollow
Notsupported Supported
HL7definedTable0126Quantitylimitedrequest(useinRCP2) FieldsusingthiscodesetareexpectedtobesettoRDforrecords.Foracurrentlistof HL7valuespleasereferencetheHL7version2.5.1documents. HL7definedTable0136Yes/Noindicator(useinPID24,30;PD112) Value Description Y N

Yes No
Infieldsthatmaybeempty,suchasPD112novalueshouldbeenteredifthevalueis notYorN.InHL7meansremovethepreviousvalue.Ifthefieldisempty,thenit meansdonothingtoexistingvalues. Note on Null and Empty in HL7

Note that in the previous Implementation Guide, the undetermined state was signified by (HL7 null). This has a specific meaning in HL7. It means change the state in the receiving system to null. The empty field means that the existing state should remain unchanged in the receiving system.
Value in Field
|| <empty field> ||
Meaning
Nullify the value recorded in the receiving system data base.
Make no changes to the record in the receiving data base. The sending system has no information on this field.
HL7definedTable0155Accept/Applicationacknowledgmentconditions(useinMSH 15and16) Value Description AL NE ER SU Always Never Error/Rejectconditionsonly Successfulcompletiononly
HL7definedTable0162Routeofadministration[onlyselectedvalueslisted](usein RXR1) NotethatHITSPhasspecifiedtheuseoftheFDArouteofadministration.Thefollowing tablemapsthesetotheHL7table0162values. FDA HL70162 Description Definition NCI Thesaurus (NCIT) ID Intradermal withinorintroducedbetweenthe C38238 layersoftheskin IM Intramuscular withinorintothesubstanceofa C28161 muscle NS Nasal Givenbynose C38284
C38276 C38288 C38676 C38299 C38305
IN IV PO OTH SC TD
Intranasal Intravenous Oral
{Donotusethisoldercode} administeredintoavein administeredbymouth
Other/Miscellaneous Percutaneous made,done,oreffectedthroughthe skin. Subcutaneous Undertheskinorbetweenskinand muscles. Transdermal describessomething,especiallya drug,thatisintroducedintothe bodythroughtheskin
Example |C28161Întramuscular^NCIT| |SC^Subcutaneous^HL70162|
HL7definedTable0163Administrativesite[onlyselectedvalueslisted](useinRXR2) HITSPhasrecommendedtheuseofSNOMEDcodes.Atthispointnotallofthese conceptshaveprecoordinatedSNOMEDcodes.Thepostcoordinatedarelongerthan thenominallengthofthefirstcomponentoftheCEdatatype.Therefore,thisguidewill continuetosupporttheHL70163codes. SNOMED HL70163 Description LT LA LD LG LVL LLFA RA RT RVL RG RD RLFA LeftThigh LeftUpperArm LeftDeltoid LeftGluteousMedius LeftVastusLateralis LeftLowerForearm RightUpperArm RightThigh RightVastusLateralis RightGluteousMedius RightDeltoid RightLowerForearm
UserdefinedTable0189EthnicGroup[ThesevaluesareconsistentwiththeOMB NoticeofrevisedcategoriesforcollectionofraceandethnicitydataandwithHL7s Version2.4](useinPID22,NK128) Description HL7Version2.4 US ethnicity codes ethnicitycodes 21352 21865 H N U HispanicorLatino notHispanicorLatino Unknown
HL7definedTable0190Addresstype(useinallXADdatatypes;includingPID11) Value Description C P M B O H Currentortemporary Permanent Mailing Firm/Business Office Home
N F L BDL BR RH BA
Birth(nee) Countryoforigin Legaladdress Birthdeliverylocation[useforbirthfacility] Residenceatbirth[useforresidenceatbirth] Registryhome Badaddress
RecordingofBirthStateusestheBDL,birthdeliverylocationcode.
HL7definedTable0200Nametype(useinallXCN,XPNdatatypes;includingPID5,6, 9) Value Description Definition A Aliasname Thisisanicknameorotherassumedname. L Legalname Thisapersonsofficialname.Itistheprimaryname recordedintheIIS. D Displayname Thisisthepreferrednamedisplayedonauser interface. M Maidenname Thisisawomansnamebeforemarriage. C Adoptedname Thisisthenameofapersonafteradoption. B Nameatbirth Thisisnamerecordedatbirth(priortoadoption). P Nameofpartner/spouse Thisisthenameofthepartnerorspouse. U Unspecified Thisisanameofunspecifiedtype. HL7definedTable0201Telecommunicationusecode(useinallXTNdatatypes; includingPID13,14) Value Description PRN ORN WPN VHN ASN EMR NET BPN Primaryresidencenumber Otherresidencenumber Worknumber Vacationhomenumber Answeringservicenumber Emergencynumber Network(email)address Beepernumber
HL7definedTable0202Telecommunicationequipmenttype(useinallXTNdata types;includingPID13,14)
Value PH FX MD CP BP Internet X.400 TDD TTY Description Telephone Fax Modem Cellular phone Beeper Internet address: Use only if telecommunication use code is NET X.400 email address: Use only if telecommunication use code is NET Telecommunications Device for the Deaf Teletypewriter
UserdefinedTable0203Identifiertype[valuessuggestedbyHL7;withNIPsuggested additions](useinallCX,XCNtypecodes;includingPID2,3,4,18,21andRXA10)
HL7 Table 0203 - Identifier type
Value AN ANON Description Account number Anonymous identifier Comment An identifier that is unique to an account. An identifier for a living subject whose real identity is protected or suppressed Justification: For public health reporting purposes, anonymous identifiers are occasionally used for protecting patient identity in reporting certain results. For instance, a state health department may choose to use a scheme for generating an anonymous identifier for reporting a patient that has had a positive human immunodeficiency virus antibody test. Anonymous identifiers can be used in PID 3 by replacing the medical record number or other non-anonymous identifier. The assigning authority for an anonymous identifier would be the state/local health department. Class: Financial A more precise definition of an account number: sometimes two distinct account numbers must be transmitted in the same message, one as the creditor, the other as the debtor. Class: Financial A more precise definition of an account number: sometimes two distinct account numbers must be transmitted in the same message, one as the creditor, the other as the debtor. Class: Financial Temporary version of an Account Number. Use Case: An ancillary system that does not normally assign account numbers is the first time to register a patient. This ancillary system will generate a temporary account number that will only be used until an official account number is assigned. An identifier that is unique to an advanced practice registered nurse within the jurisdiction of a certifying board Class: Financial Class: Financial An identifier that is unique to a persons bank card. Replaces AM, DI, DS, MS, and VS beginning in v 2.5. Class: Financial Use Case: needed especially for transmitting information about invoices. An identifier that is unique to a dentist within the jurisdiction of the licensing board
ANC
Account number Creditor
AND
Account number debitor
ANT
Temporary Account Number
APRN BA BC
Advanced Practice Registered Nurse number Bank Account Number Bank Card Number
BR CC
Birth registry number Cost Center number
CY DDS
County number Dentist license number
Value DEA
Description Drug Enforcement Administration registration number
DFN
Drug Furnishing or prescriptive authority Number
Comment An identifier for an individual or organization relative to controlled substance regulation and transactions. Use case: This is a registration number that identifies an individual or organization relative to controlled substance regulation and transactions. A DEA number has a very precise and widely accepted meaning within the United States. Surprisingly, the US Drug Enforcement Administration does not solely assign DEA numbers in the United States. Hospitals have the authority to issue DEA numbers to their medical residents. These DEA numbers are based upon the hospitals DEA number, but the authority rests with the hospital on the assignment to the residents. Thus, DEA as an Identifier Type is necessary in addition to DEA as an Assigning Authority. An identifier issued to a health care provider authorizing the person to write drug orders Use Case: A nurse practitioner has authorization to furnish or prescribe pharmaceutical substances; this identifier is in component 1.
DL DN DPM DO DR EI EN FI GI GL GN HC JHN
Drivers license number Doctor number Podiatrist license number Osteopathic License number Donor Registration Number Employee number Employer number Facility ID Guarantor internal identifier General ledger number Guarantor external identifier Health Card Number Jurisdictional health number (Canada)
An identifier that is unique to a podiatrist within the jurisdiction of the licensing board. An identifier that is unique to an osteopath within the jurisdiction of a licensing board. A number that uniquely identifies an employee to an employer.
Class: Financial Class: Financial Class: Financial Class: Insurance 2 uses: a) UK jurisdictional CHI number; b) Canadian provincial health card number: A number assigned to a member of an indigenous or aboriginal group outside of Canada.
IND LI LN LR MA MB
Indigenous/Aboriginal Labor and industries number License number Local Registry ID Patient Medicaid number Member Number
MC MCD MCN MCR
Patient's Medicare number Practitioner Medicaid number Microchip Number Practitioner Medicare number
Class: Insurance An identifier for the insured of an insurance policy (this insured always has a subscriber), usually assigned by the insurance carrier. Use Case: Person is covered by an insurance policy. This person may or may not be the subscriber of the policy. Class: Insurance Class: Insurance Class: Insurance
Value MD
Description Medical License number
MI
Military ID number
MR MRT
Medical record number Temporary Medical Record Number
NE
National employer identifier
Comment An identifier that is unique to a medical doctor within the jurisdiction of a licensing board. Use Case: These license numbers are sometimes used as identifiers. In some states, the same authority issues all three identifiers, e.g., medical, osteopathic, and physician assistant licenses all issued by one state medical board. For this case, the CX data type requires distinct identifier types to accurately interpret component 1. Additionally, the distinction among these license types is critical in most health care settings (this is not to convey full licensing information, which requires a segment to support all related attributes). A number assigned to an individual who has had military duty, but is not currently on active duty. The number is assigned by the DOD or Veterans Affairs (VA). An identifier that is unique to a patient within a set of medical records, not necessarily unique within an application. Temporary version of a Medical Record Number Use Case: An ancillary system that does not normally assign medical record numbers is the first time to register a patient. This ancillary system will generate a temporary medical record number that will only be used until an official medical record number is assigned. In the US, the Assigning Authority for this value is typically CMS, but it may be used by all providers and insurance companies in HIPAA related transactions. Class: Insurance Used for the UK NHS national identifier. In the US, the Assigning Authority for this value is typically CMS, but it may be used by all providers and insurance companies in HIPAA related transactions. Class: Insurance In the US, the Assigning Authority for this value is typically CMS, but it may be used by all providers and insurance companies in HIPAA related transactions. Class: Insurance In Germany a national identifier for an insurance company. It is printed on the insurance card (health card). It is not to be confused with the health card number itself. Class: Insurance Use case: a subdivision issues the card with their identifier, but the main division is going to pay the invoices.
NH
National Health Plan Identifier
NI
National unique individual identifier
NII
National Insurance Organization Identifier
NIIP
National Insurance Payor Identifier (Payor) National Person Identifier where the xxx is the ISO table 3166 3-character (alphabetic) country code Nurse practitioner number National provider identifier
NNxxx NP NPI
An identifier that is unique to a nurse practitioner within the jurisdiction of a certifying board. Class: Insurance In the US, the Assigning Authority for this value is typically CMS, but it may be used by all providers and insurance companies in HIPAA related transactions.
Value OD PA PCN PE PEN PI PN PNT PPN
Description Optometrist license number Physician Assistant number Penitentiary/correctional institution Number Living Subject Enterprise Number Pension Number Patient internal identifier Person number Temporary Living Subject Number Passport number
Comment A number that is unique to an individual optometrist within the jurisdiction of the licensing board. An identifier that is unique to a physician assistant within the jurisdiction of a licensing board A number assigned to individual who is incarcerated. An identifier that is unique to a living subject within an enterprise (as identified by the Assigning Authority). A number that is unique to a patient within an Assigning Authority. A number that is unique to a living subject within an Assigning Authority. Temporary version of a Lining Subject Number. A unique number assigned to the document affirming that a person is a citizen of the country. In the US this number is issued only by the State Department. A number that is unique to an individual provider, a provider group or an organization within an Assigning Authority. Use case: This allows PRN to represent either an individual (a nurse) or a group/organization (orthopedic surgery team).
PRC PRN
Permanent Resident Card Number Provider number
PT QA RI
Patient external identifier QA number Resource identifier
RPH RN RR RRI SL SN
Pharmacist license number Registered Nurse Number Railroad Retirement number Regional registry ID State license Subscriber Number
A generalized resource identifier. Use Case: An identifier type is needed to accommodate what are commonly known as resources. The resources can include human (e.g. a respiratory therapist), non-human (e.g., a companion animal), inanimate object (e.g., an exam room), organization (e.g., diabetic education class) or any other physical or logical entity. An identifier that is unique to a pharmacist within the jurisdiction of the licensing board. An identifier that is unique to a registered nurse within the jurisdiction of the licensing board.
Class: Insurance An identifier for a subscr ber of an insurance policy which is unique for, and usually assigned by, the insurance carrier. Use Case: A person is the subscriber of an insurance policy. The persons family may be plan members, but are not the subscriber.
SR SS TAX U UPIN VN
State registry ID Social Security number Tax ID number Unspecified identifier Medicare/CMS (formerly HCFA)s Universal Physician Identification numbers Visit number
Class: Insurance
Value WC WCN XX
Description WIC identifier Workers Comp Number Organization identifier
Comment
UserdefinedTable0204Organizationalnametype[valuessuggestedbyHL7](usein allXONdatatypes) Value Description L D Legalname Displayname
HL7definedTable0207Processingmode(useinMSH11) Fieldsusingthiscodesetareexpectedtobeempty.ForacurrentlistofHL7values pleasereferencetheHL7version2.5.1documents. UserdefinedTable0208Queryresponsestatus[valuessuggestedbyHL7](usein QAK2) Value Description OK NF AE AR TM Datafound,noerrors(thisisthedefault) Nodatafound,noerrors Applicationerror Applicationreject Toomanycandidatesfound
HL7definedTable0211Alternatecharactersets(useinMSH18) Fieldsusingthiscodesetareexpectedtobeempty.ForacurrentlistofHL7values pleasereferencetheHL7version2.5.1documents.
UserdefinedTable0215Publicitycode[valuessuggestedbyNIP](useinPD111) Value Description 01 02 03 04 05 06 07 08 09 10 11 12 Noreminder/recall Reminder/recallanymethod Reminder/recallnocalls Reminderonlyanymethod Reminderonlynocalls Recallonlyanymethod Recallonlynocalls Reminder/recalltoprovider Remindertoprovider Onlyremindertoprovider,norecall Recalltoprovider Onlyrecalltoprovider,noreminder
UserdefinedTable0220Livingarrangement Fieldsusingthiscodesetareexpectedtobeempty.ForacurrentlistofHL7values pleasereferencetheHL7version2.5.1documents. HL7definedTable0227Manufacturersofvaccines(code=MVX)(useinRXA17)The tablebelowrepresentstheFebruary2010versionoftheMVXcodeset.TheCDCs NationalCenterforImmunizationandRespiratoryDiseases(NCIRD)maintainstheHL7 externalcodesetMVX. http://www2a.cdc.gov/nip/IIS/IISStandards/vaccines.asp?rpt=mvx 33

NOTE:TheMVXtablereflectsnamechangesandchangesincorporatestatus.Wheretherehavebeencompany mergers/acquisitions,theaffectedoldcodeshavebeenlabeledinactive.Theinactivemanufacturercodesare retainedtoallowmanufacturertobeidentifiedforhistoricimmunizationrecords.Theyshouldnotbeusedfor currentimmunizations.Inactivecodesshouldnotbecrosswalkedtothecodeforthecurrentmanufacturer.
(alphabetizedbymanufacturername)
MVXCODE AB ACA AD AKR ALP AR

33
ManufacturerName AbbottLaboratories Acambis,Inc AdamsLaboratories, Inc. Akorn,Inc AlphaTherapeutic Corporation Armour
Active Notes TRUE includesRossProductsDivision FALSE acquiredbysanofiinsept2008 TRUE TRUE
TRUE FALSE
This link is current as of 2/15/2011.
AVB AVI BA
AventisBehring L.L.C. Aviron BaxterHealthcare Corporation
FALSE FALSE acquiredbymedimmune FALSE includesHylandImmuno,Immuno InternationalAG,andNorthAmerican Vaccine,Inc./acquiredsomeassets TRUE fromalphatherapeutics bayerbiologicalsnowownedby FALSE talecris FALSE includesSwissSerumandVaccine TRUE InstituteBerne formerlyMichiganBiologicProducts TRUE Institute NewownerofNABIHBasof December2007,DoesNOTreplace NABIBiopharmaceuticalsinthiscode TRUE list. TRUE FALSE FALSE FALSE FALSE TRUE TRUE acquiredbyMerieux CSLBiotherapiesrenamedtoCSL Behring
BAH BAY BP BPC MIP
BaxterHealthcare Corporation BayerCorporation BernaProducts BernaProducts Corporation BioportCorporation Biotest Pharmaceuticals Corporation Cangene Corporation CelltechMedeva Pharmaceuticals CenteonL.L.C. ChironCorporation Connaught CSLBiotherapies,Inc DynPortVaccine Company,LLC EvansMedical Limited GeoVaxLabs,Inc. GlaxoSmithKline GreerLaboratories, Inc. Immuno InternationalAG ImmunoU.S.,Inc. IntercellBiomedical KoreaGreenCross Corporation Lederle Massachusetts
BTP CNJ CMP CEN CHI CON CSL DVC EVN GEO SKB GRE IAG IUS INT KGC LED MBL
FALSE TRUE includesSmithKlineBeechamand TRUE GlaxoWellcome TRUE
FALSE TRUE TRUE TRUE FALSE TRUE formerlyMassachusettsPublicHealth
MA
MED MSD IM MIL NAB NYB NAV
NOV NVX OTC ORT OTH PD PFR PWJ PRX
PMC SCL SOL SI TAL
BiologicLaboratories BiologicLaboratories Massachusetts PublicHealth BiologicLaboratories FALSE acquisitionsofU.S.Biosciencein1999 andAvironin2002,aswellasthe integrationwithCambridgeAntibody Technologyandthestrategic alignmentwithournewparent MedImmune,Inc. TRUE company,AstraZeneca,in2007. Merck&Co.,Inc. TRUE Merieux FALSE Miles FALSE formerlyNorthAmericanBiologicals, NABI TRUE Inc. NewYorkBlood Center TRUE NorthAmerican Vaccine,Inc. FALSE includesChiron,PowderJect Pharmaceuticals,CelltechMedeva Novartis Pharmaceutical VaccinesandEvansLimited,Ciba Corporation TRUE GeigyLimitedandSandozLimited Novavax,Inc. TRUE OrganonTeknika Coporation TRUE Orthoclinical aJ&Jcompany(formerlyOrtho Diagnostics TRUE DiagnosticSystems,Inc.) Othermanufacturer TRUE Parkedale nowebsiteandnonewsarticles Pharmaceuticals FALSE (formerlyParkeDavis) Pfizer TRUE PowderJect Pharmaceuticals FALSE PraxisBiologics FALSE (formerlyAventisPasteur,Pasteur MerieuxConnaught;includes ConnaughtLaboratoriesandPasteur sanofipasteur TRUE Merieux) Sclavo,Inc. TRUE Solvay Pharmaceuticals TRUE SwissSerumand VaccineInst. FALSE Talecris Biotherapeutics TRUE includesBayerBiologicals
JPN
USA UNK VXG WA
TheResearch Foundationfor MicrobialDiseases ofOsakaUniversity (BIKEN) UnitedStatesArmy MedicalResearch andMaterial Command Unknown manufacturer VaxGen WyethAyerst
TRUE
TRUE
WAL ZLB
WyethAyerst ZLBBehring
TRUE TRUE FALSE includesWyethLederleVaccinesand Pediatrics,WyethLaboratories, LederleLaboratories,andPraxis Biologics,acquiredbyPfizer FALSE 10/15/2009 includesAventisBehringandArmour FALSE PharmaceuticalCompany,ChildofCSL
UserdefinedTable0288Censustract(useinallXAD;includingPID11) Fieldsusingthiscodesetareexpectedtobeempty.ForacurrentlistofHL7values pleasereferencetheHL7version2.5.1documents. UserdefinedTable0289County/parish(useinallXAD;includingPID11) AcompletelistofFIPS64countycodesisavailableat <www.itl.nist.gov/div897/pubs/fip64.htm>.AccordingtotheFIPSguidance,the2letter statecode(availableat<www.itl.nist.gov/div897/pubs/fip52.htm>)plusthenumeric countycodeshouldbeused(e.g.,AZ001representsApacheCounty,ArizonaandAL001 representsAutaugaCounty,Alabama).
HL7definedTable0292CodesforVaccinesadministered(code=CVX)(useinRXA5) ThetablebelowrepresentstheFebruary2010versionoftheCVXcodeset.Newcodes areaddedasneeded;therefore,seethemostcurrentversionofthiscodesetatthe websiteWebsite:http://www2a.cdc.gov/nip/IIS/IISStandards/vaccines.asp?rpt=cvx 34 TheCDCsNationalCenterforImmunizationandRespiratoryDiseases(NCIRD)maintains theHL7externalcodesetCVX.
CVXVaccinesAdministered
VaccineName adenovirus,NOS adenovirus,type7 LongName adenovirusvaccine,NOS adenovirusvaccine,type7, live,oral adenovirus,type4 adenovirusvaccine,type4, 54 live,oral anthrax anthraxvaccine 24 BCG BacillusCalmetteGuerin 19 vaccine botulinumantitoxin botulinumantitoxin 27 cholera choleravaccine 26 CMVIG cytomegalovirusimmune 29 globulin,intravenous denguefever denguefevervaccine 56 diphtheriaantitoxin diphtheriaantitoxin 12 DT(pediatric) diphtheriaandtetanus 28 toxoids,adsorbedforpediatric use DTaP diphtheria,tetanustoxoids 20 andacellularpertussisvaccine DTaP,5pertussis diphtheria,tetanustoxoids 106 antigens andacellularpertussis vaccine,5pertussisantigens DTaP,NOS diphtheria,tetanustoxoids 107 andacellularpertussis vaccine,NOS DTaPHepBIPV DTaPhepatitisBand 110 poliovirusvaccine DTaPHib DTaPHaemophilusinfluenzae 50 typebconjugatevaccine DTaPHibIPV diphtheria,tetanustoxoids 120
34
CVXcode Current Status 82 Inactive 55 Inactive Inactive Active Active Inactive Inactive Active Inactive Inactive Active
Active Active
Inactive
Active Active Active
Link is current as of 5/1/2010.
andacellularpertussis vaccine,Haemophilus influenzaetypebconjugate, andpoliovirusvaccine, inactivated(DTaPHibIPV) DTaPIPV Diphtheria,tetanustoxoids 130 andacellularpertussis vaccine,andpoliovirus vaccine,inactivated DTP diphtheria,tetanustoxoids 1 andpertussisvaccine DTPHib DTPHaemophilusinfluenzae 22 typebconjugatevaccine DTPHibHepB DTPHaemophilusinfluenzae 102 typebconjugateandhepatitis bvaccine hantavirus hantavirusvaccine 57 HBIG hepatitisBimmuneglobulin 30 HepA,adult hepatitisAvaccine,adult 52 dosage HepA,NOS hepatitisAvaccine,NOS 85 HepA,ped/adol hepatitisAvaccine, 83 pediatric/adolescentdosage, 2doseschedule HepA,ped/adol,3 hepatitisAvaccine, 84 dose pediatric/adolescentdosage, 3doseschedule HepA,pediatric, hepatitisAvaccine,pediatric 31 NOS dosage,NOS HepAHepB hepatitisAandhepatitisB 104 vaccine HepB,adolescentor hepatitisBvaccine,pediatric 8 pediatric orpediatric/adolescent dosage HepB, hepatitisBvaccine, 42 adolescent/highrisk adolescent/highriskinfant infant dosage HepB,adult hepatitisBvaccine,adult 43 dosage HepB,dialysis hepatitisBvaccine,dialysis 44 patientdosage HepB,NOS hepatitisBvaccine,NOS 45
Active
Inactive Inactive Inactive
Inactive Active Active Inactive Active
Inactive
Inactive Active Active
Inactive
Active Active Inactive
HepC HepE herpessimplex2
hepatitisCvaccine hepatitisEvaccine herpessimplexvirus,type2 vaccine Hib(HbOC) Haemophilusinfluenzaetype bvaccine,HbOCconjugate Hib(PRPD) Haemophilusinfluenzaetype bvaccine,PRPDconjugate Hib(PRPOMP) Haemophilusinfluenzaetype bvaccine,PRPOMPconjugate Hib(PRPT) Haemophilusinfluenzaetype bvaccine,PRPTconjugate Hib,NOS Haemophilusinfluenzaetype bvaccine,conjugateNOS HibHepB Haemophilusinfluenzaetype bconjugateandHepatitisB vaccine HIV humanimmunodeficiency virusvaccine HPV,bivalent humanpapillomavirus vaccine,bivalent HPV,quadrivalent humanpapillomavirus vaccine,quadrivalent IG immuneglobulin, intramuscular IG,NOS immuneglobulin,NOS IGIV immuneglobulin,intravenous influenza,H5N1 influenzavirusvaccine,H5N1, 1203 A/Vietnam/1203/2004 (nationalstockpile) influenza,live, influenzavirusvaccine,live, intranasal attenuated,forintranasaluse influenza,NOS influenzavirusvaccine,NOS8 Influenza,seasonal, JapaneseEncephalitisvaccine highdose forintramuscular administration influenza,split(incl. influenzavirusvaccine,split purifiedsurface virus(incl.purifiedsurface antigen) antigen) influenza,whole influenzavirusvaccine,whole virus IPV poliovirusvaccine,inactivated
58 59 60 47 46 49 48 17 51
Inactive Inactive Inactive Inactive Inactive Active Active Inactive Active
61 118 62 86 14 87 123
Inactive Active Active Active Active Active Inactive
111 88 134
Active Active Active
15
Active
16 10
Inactive Active
Japanese encephalitis Juninvirus leishmaniasis leprosy Lymedisease M/R
JapaneseEncephalitisVaccine 39 SC Juninvirusvaccine 63 leishmaniasisvaccine 64 leprosyvaccine 65 Lymediseasevaccine 66 measlesandrubellavirus 4 vaccine malaria malariavaccine 67 measles measlesvirusvaccine 5 melanoma melanomavaccine 68 meningococcalC meningococcalCconjugate 103 conjugate vaccine meningococcal meningococcalpolysaccharide 114 MCVP4 (groupsA,C,YandW135) diphtheriatoxoidconjugate vaccine(MCV4) meningococcal meningococcalpolysaccharide 32 MPSV4 vaccine(MPSV4) meningococcal,NOS meningococcalvaccine,NOS 108 MMR measles,mumpsandrubella 3 virusvaccine MMRV measles,mumps,rubella,and 94 varicellavirusvaccine mumps mumpsvirusvaccine 7 OPV poliovirusvaccine,live,oral 2 parainfluenza3 parainfluenza3virusvaccine 69 pertussis pertussisvaccine 11 plague plaguevaccine 23 Pneumococcal pneumococcalconjugate 133 conjugatePCV13 vaccine,13valent pneumococcal pneumococcalconjugate 100 conjugatePCV7 vaccine,7valent pneumococcal pneumococcalpolysaccharide 33 polysaccharide vaccine PPV23 pneumococcal,NOS pneumococcalvaccine,NOS 109 polio,NOS poliovirusvaccine,NOS 89 Qfever Qfevervaccine 70 rabies,intradermal rabiesvaccine,forintradermal 40 injection injection rabies, rabiesvaccine,for 18
Active Inactive Inactive Inactive Inactive Active Active Active Inactive Active Active
Active Active Active Active Active Inactive Inactive Inactive Active Active Active Active
Active Active Inactive Active Active
intramuscular injection rabies,NOS rheumaticfever RiftValleyfever RIG rotavirus, monovalent rotavirus,NOS rotavirus, pentavalent rotavirus, tetravalent RSVIGIV
intramuscularinjection Inactive Inactive Inactive Active Active Active Active Inactive Active Active
rabiesvaccine,NOS 90 rheumaticfevervaccine 72 RiftValleyfevervaccine 73 rabiesimmuneglobulin 34 rotavirus,live,monovalent 119 vaccine rotavirusvaccine,NOS 122 rotavirus,live,pentavalent 116 vaccine rotavirus,live,tetravalent 74 vaccine respiratorysyncytialvirus 71 immuneglobulin,intravenous RSVMAb respiratorysyncytialvirus 93 monoclonalantibody (palivizumab),intramuscular rubella rubellavirusvaccine 6 rubella/mumps rubellaandmumpsvirus 38 vaccine Staphylococcus Staphylococcusbacteriophage 76 bacteriolysate lysate Td(adult) tetanusanddiphtheria 9 toxoids,adsorbedforadult use Td(adult) tetanusanddiphtheria 113 preservativefree toxoids,adsorbed, preservativefree,foradult use Tdap tetanustoxoid,reduced 115 diphtheriatoxoid,and acellularpertussisvaccine, adsorbed tetanustoxoid tetanustoxoid,adsorbed 35 tetanustoxoid,NOS tetanustoxoid,NOS 112 tickborne tickborneencephalitis 77 encephalitis vaccine TIG tetanusimmuneglobulin 13 TST,NOS tuberculinskintest;NOS 98 TSTOTtinetest tuberculinskintest;old 95 tuberculin,multipuncture
Active Active Inactive Active
Active
Active
Active Active Inactive Active Inactive Inactive
device TSTPPDintradermal tuberculinskintest;purified proteinderivativesolution, intradermal TSTPPDtinetest tuberculinskintest;purified proteinderivative, multipuncturedevice tularemiavaccine tularemiavaccine typhoid,NOS typhoidvaccine,NOS typhoid,oral typhoidvaccine,live,oral typhoid,parenteral typhoidvaccine,parenteral, otherthanacetonekilled, dried typhoid,parenteral, typhoidvaccine,parenteral, AKD(U.S.military) acetonekilled,dried(U.S. military) typhoid,ViCPs typhoidVicapsular polysaccharidevaccine vaccinia(smallpox) vaccinia(smallpox)vaccine vaccinia(smallpox) vaccinia(smallpox)vaccine, diluted diluted vacciniaimmune vacciniaimmuneglobulin globulin varicella varicellavirusvaccine VEE,inactivated Venezuelanequine encephalitis,inactivated VEE,live Venezuelanequine encephalitis,live,attenuated VEE,NOS Venezuelanequine encephalitisvaccine,NOS VZIG varicellazosterimmune globulin VZIG(IND) varicellazosterimmune globulin(InvestigationalNew Drug) yellowfever yellowfevervaccine zoster zostervaccine,live novaccine novaccineadministered administered RESERVEDdonot RESERVEDdonotuse use unknown unknownvaccineorimmune
96
Inactive
97
Inactive
78 91 25 41
Inactive Inactive Active Active
53
Active
101 75 105 79 21 81 80 92 36 117
Active Active Inactive Active Active Active Active Active Active Inactive
37 121 998 99 999
Active Active Inactive Inactive Inactive
globulin UserdefinedTable0296Language ISO639shallbeusedforLanguage.ItisavailablefromPHINVADSat: http://phinvads.cdc.gov/vads/ViewValueSet.action?id=43D34BBC-617F-DD11B38D-00188B398520# ThecodeusedfromHL70396tableisISO6392. Examplecodesarefoundinthetablebelow. Notethatthiscodediffersfromthe2.3.1Guide,whichusedthe2charactercodes. Value Description ara arm cat chi dan eng fre ger hat heb hin hmn jpn kor rus som spa vie Arabic Armenian Catalan;Valencian Chinese Danish English French German Haitian;HaitianCreole Hebrew Hindi Hmong Japanese Korean Russian Somali Spanish;Castilian Vietnamese
UserdefinedTable0297CNIDsource(useinallXCNdatatypes)[locallydefined] UserdefinedTable0300NamespaceID(useinallEI,HDdatatypes) [locallydefined] Seetables03610363forApplicationIdentifier,FacilityIdentifier,andAssigning Authority.Thesetablesaremorespecificthan0300andarepreferred.

HL7definedTable0301UniversalIDtype(useinallHDdatatypes) Value Description DNS GUID HCD HL7 ISO L,M,N Random AnInternetdottednameeitherinASCIIorasintegers. SameasUUID. TheCENHealthcareCodingSchemeDesignator.(IdentifiersusedinDICOM followthisassignmentscheme.) ReservedforfutureHL7registrationschemes. AnInternationalStandardsOrganizationObjectIdentifier. Thesearereservedforlocallydefinedcodingschemes. Usuallyabase64encodedstringofrandombits.Theuniquenessdependsonthe lengthofthebits.MailsystemsoftengenerateASCIIstringuniquenames, fromacombinationofrandombitsandsystemnames.Obviously,such identifierswillnotbeconstrainedtothebase64characterset. TheDCEUniversalUniqueIdentifier. AnX.400MHSformatidentifier. AnX.500directoryname.
UUID x400 x500
HL7definedTable0322Completionstatus(useinRXA20) Value Description CP RE NA PA Complete Refused NotAdministered PartiallyAdministered
HL7definedTable0323Actioncode(useinRXA21) Value Description A D U Add Delete Update
HL7definedTable0354Messagestructure[onlyselectedvalueslisted](useinMSH9, thirdcomponent) Value Events ACK QBP_Q11 RSP_K11 VXU_V04 ACK QBP RSP VXU
HL7definedTable0356Alternatecharactersethandlingscheme(useinMSH20) Fieldsusingthiscodesetareexpectedtobeempty.ForacurrentlistofHL7values pleasereferencetheHL7version2.5.1documents. HL7definedTable0357Messageerrorstatuscodes(useinERR3) Status Statustext Description/Comment code Success 0 Messageaccepted Success.Optional,astheAAconveysthis.Usedfor systemsthatmustalwaysreturnastatuscode. Themessagesegmentswerenotintheproperorder orrequiredsegmentsaremissing. Arequiredfieldismissingfromthesegment. Thefieldcontaineddataofthewrongdatatype, e.g.,anNMfieldcontainedlettersofthealphabet. AfieldofdatatypeIDorISwascomparedagainst thecorrespondingtable,andnomatchwasfound. TheMessagetypeisnotsupported. TheEventCodeisnotsupported. TheProcessingIDisnotsupported. TheVersionIDisnotsupported. TheIDofthepatient,order,etc.wasnotfound. Usedfortransactionsotherthanadditions,e.g., transferofanonexistentpatient. TheIDofthepatient,order,etc.alreadyexists.Used inresponsetoadditiontransactions(Admit,New Order,etc.).
Errorstatuscodes 100 Segmentsequenceerror 101 102 103 Requiredfieldmissing Datatypeerror Tablevaluenotfound
Rejectionstatuscodes 200 Unsupportedmessage type 201 Unsupportedeventcode 202 Unsupportedprocessing ID 203 UnsupportedversionID 204 Unknownkeyidentifier
205
Duplicatekeyidentifier
Status code 206 207
Statustext Applicationrecordlocked Applicationinternalerror
Description/Comment Thetransactioncouldnotbeperformedatthe applicationstoragelevel,e.g.,databaselocked. Acatchallforinternalerrorsnotexplicitlycovered byothercodes.
UserdefinedTable0360DegreeSelectedvaluessuggestedbyHL7.;(useinallXPN datatypes,includingPID5,6,9) Value Description PN AA AS BA BN BS BSN CER CANP CMA CNP CNM CNA CRN CNS CPNP DIP PHD MD DO EMT EMTP FPNP HS JD LPN MA MBA MPH MS MSN MDA MT NG NP PharmD PA AdvancedPracticeNurse AssociateofArts AssociateofScience BachelorofArts BachelorofNursing BachelorofScience BachelorofScienceinNursing Certificate CertifiedAdultNursePractitioner CertifiedMedicalAssistant CertifiedNursePractitioner CertifiedNurseMidwife CertifiedNursesAssistant CertifiedRegisteredNurse CertifiedNurseSpecialist CertifiedPediatricNursePractitioner Diploma DoctorofPhilosophy DoctorofMedicine DoctorofOsteopathy EmergencyMedicalTechnician EmergencyMedicalTechnicianParamedic FamilyPracticeNursePractitioner HighSchoolGraduate JurisDoctor LicensedPracticalNurse MasterofArts MasterofBusinessAdministration MasterofPublicHealth MasterofScience MasterofScienceNursing MedicalAssistant MedicalTechnician NonGraduate NursePractitioner DoctorofPharmacy PhysicianAssistant
Value PHN RMA RN RPH SEC TS
Description PublicHealthNurse RegisteredMedicalAssistant RegisteredNurse RegisteredPharmacist SecretarialCertificate TradeSchoolGraduate
UserdefinedTable0361Application Nosuggestedvaluesdefined. UserdefinedTable0362Facility Nosuggestedvaluesdefined. UserdefinedTable0363AssigningAuthority Localimplementationswillneedtoaddcodestothistabletoidentifylocalassigning authorities.Thevaluesinthistableareintendedtobeusedbystateandregional immunizationprograms. Code AKA ALA ARA ASA AZA BAA CAA CHA COA CTA DCA DEA FLA FMA GAA GUA HIA IAA Grantee ALASKA ALABAMA ARKANSAS AMERICANSAMOA ARIZONA NEWYORKCITY CALIFORNIA CHICAGO COLORADO CONNECTICUT DISTRICTOF COLUMBIA DELAWARE FLORIDA FEDSTATESMICRO GEORGIA GUAM HAWAII IOWA
IDA ILA INA KSA KYA LAA MAA MDA MEA MHA MIA MNA MOA MPA MSA MTA NCA NDA NEA NHA NJA NMA NVA NYA OHA OKA ORA PAA PHA PRA RIA RPA SCA SDA TBA THA TNA TXA UTA VAA VIA VTA
IDAHO ILLINOIS INDIANA KANSAS KENTUCKY LOUISIANA MASSACHUSETTS MARYLAND MAINE REPMARSISLANDS MICHIGAN MINNESOTA MISSOURI NO.MARIANAISLAND MISSISSIPPI MONTANA NORTHCAROLINA NORTHDAKOTA NEBRASKA NEWHAMPSHIRE NEWJERSEY NEWMEXICO NEVADA NEWYORKSTATE OHIO OKLAHOMA OREGON PENNSYLVANIA PHILADELPHIA PUERTORICO RHODEISLAND REPUBLICPALAU SOUTHCAROLINA SOUTHDAKOTA SANANTONIO HOUSTON TENNESSEE TEXAS UTAH VIRGINIA VIRGINISLANDS VERMONT
VTA WAA WIA WVA WYA
VERMONT WASHINGTON WISCONSIN WESTVIRGINIA WYOMING
UserdefinedTable0396Codingsystem[onlyselectedvalueslisted]SeeVersion2.5.1 Table0396forothervalues.(UseinCEdatatypestodenotethecodingsystemusedfor codedvalues)

Value 99zzz or L ART C4 C5 CDCA CDCM CDCPHINVS CDS CPTM CST CVX E E5 E6 E7 ENZC HB HCPCS HHC HL7nnnn HPC I10 I10P I9 I9C ISOnnnn LB LN MCD MCR MEDR MVX NDC NCIT NPI SNM SCT SCT2 SNM3 Description Local general code (where z is an alphanumeric character) WHO Adverse Reaction Terms CPT-4 CPT-5 CDC Analyte Codes CDC Methods/Instruments Codes PHIN VS (CDC Local Coding System) CDC Surveillance CPT Modifier Code COSTART CDC Vaccine Codes EUCLIDES Euclides quantity codes Euclides Lab method codes Euclides Lab equipment codes Enzyme Codes HIBCC HCFA Common Procedure Coding System Home Health Care HL7 Defined Codes where nnnn is the HL7 table number HCFA Procedure Codes (HCPCS) ICD-10 ICD-10 Procedure Codes ICD9 ICD-9CM ISO Defined Codes where nnnn is the ISO table number Local billing code Logical Observation Identifier Names and Codes (LOINC) Medicaid Medicare Medical Dictionary for Drug Regulatory Affairs (MEDDRA) CDC Vaccine Manufacturer Codes National drug codes NCI Thesaurus National Provider Identifier Systemized Nomenclature of Medicine (SNOMED) SNOMED Clinical Terminology
SNOMED Clinical Terms alphanumeric codes
SNOMED International
Value SNT UML UPC UPIN W1 W2 W4 WC
Description SNOMED topology codes (anatomic sites) Unified Medical Language Universal Product Code UPIN WHO record # drug codes (6 digit) WHO record # drug codes (8 digit) WHO record # code with ASTM extension WHO ATC
UserdefinedTable0441Immunizationregistrystatus(useinPD116)[HL7assigned tablenumber0441inVersion2.4] Value Description A I L M P U Active InactiveUnspecified InactiveLosttofollowup(cannotcontact) InactiveMovedorgoneelsewhere(transferred) InactivePermanentlyinactive(donotreactivateoraddnewentriestothis record) Unknown
ThecodeO(Other)hasbeenremoved,donotuse UserdefinedTable0471QueryName Value Description Z34 RequestImmunizationHistory
HL7Table0516ErrorSeverity(useinERR4) Value Description W Warning
Information
Error
Comment Transactionsuccessful,but theremaybeissues.These mayincludenonfatal errorswithpotentialfor lossofdata. Transactionsuccessful,but includesreturned information. Transactionwasnot successful.
UserdefinedTable0533ApplicationErrorCode Therearenosuggestedvaluesforthiscode.Localimplementationsneedtocreatea tableoflocalapplicationerrorcodes. NIPdefinedNIP001Immunizationinformationsource(useinRXA9) Value Description

00 01 02 03 04 05 06 07 08 New immunization record Historical information - source unspecified Historical information - from other provider Historical information - from parents written record Historical information - from parents recall Historical information - from other registry Historical information - from birth certificate Historical information - from school record Historical information - from public agency
NIPdefinedNIP002Substancerefusalreason(useinRXA18) Value Description 00 01 02 03 Parentaldecision Religiousexemption Other(mustaddtextcomponentoftheCEfieldwithdescription) Patientdecision
NIPdefinedNIP003Observationidentifiers(useinOBX3) 35 LOINC Description Corresponding Correspondingobservation 36 Code datatype valueEXAMPLEORcodetable (indicatein touse(valueinOBX5) OBX2) VaccineFundingSourceUseinOBX3toindicatethatOBX5willcontainthefunding sourceforagivenimmunization.
All VAERS-only items removed. This material contains content from LOINC (http://loinc.org). The LOINC table and LOINC codes are copyright 1995-2010, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee. Appendix A - A36
36
35
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) Last Updated on 1/31/2011
30963-3
Vaccine funding source
(CE)
ValueSetOID 2.16.840.1.114222.4.11.3287
ValueSetCode:: PHVS_ImmunizationFundingSource_IIS
VaccineTypeIdentifier
30956-7 Vaccine Type (Vaccine group or family) Component Vaccine Type (CE) HL70292 (CVX codes use the codes described as NOS as needed.) HL70292 (CVX codes use the codes described as NOS as needed.) 19970522
38890-0
(CE)
Contraindications,Precautions,IndicationsandImmunities
30946-8 Vaccination contraindication/precaution effective date Vaccination temporary contraindication/precaution expiration date Vaccination contraindication/precaution (DT)
30944-3
(DT)
19990523
30945-0
(CE)
ValueSetOID 2.16.840.1.114222.4.11.3288
ValueSetCode:: PHVS_VaccinationContraindication_IIS
31044-1
Reaction
(CE)
ValueSetOID 2.16.840.1.114222.4.11.3289
ValueSetCode:: PHVS_VaccinationReaction_IIS
59784-9
Disease with presumed immunity
(CE)
Value Set OID 2.16.840.1.114222.4.11.3293

Value Set Code:: PHVS_EvidenceOfImmunity_IIS
59785-6
Indications to immunize
(CE)
ValueSetOID 2.16.840.1.114222.4.11.3290
ValueSetCode:: PHVS_VaccinationSpecialIndications_IIS
VaccineInformationStatement(VIS)Dates
29768-9 29769-7 Date Vaccine Information Statement Published Date Vaccine Information Statement Presented (TS) (TS) 19900605 199307311615
ForecastingandEvaluatingImmunizations
30973-2 30979-9
30973-2 -- Dose number in series Vaccines due next
(NM) (CE)
2 HL70292 (CVX)
30980-7 30981-5 30982-3
30980-7 Date vaccine due 30981-5 Earliest date to give 30982-3 Reason applied by forecast logic to project this vaccine Immunization Schedule used
(TS) (TS) (CE) or (ST)
19980526 19980522 Codes for forecast logic reason locally defined. ValueSetOID
2.16.840.1.114222.4.11.3291 ValueSetCode:: PHVS_ImmunizationScheduleIdentifier_IIS
59779-9
CE
59780-7 59782-3 59781-5 59783-1
Immunization Series name Number of doses in primary series Dose validity Status in immunization series
CE NM ID CE
Locally Defined 2 Y, N or empty Locally defined value set
SmallpoxTakeRead:Thesecodesallowinformationaboutevaluationofasmallpox vaccination,calledthetakeresponse.
46249-9 46250-7 VACCINATION TAKERESPONSE TYPE VACCINATION TAKERESPONSE DATE (ST) (TS) Major Take, Equivocal, Not Available 20091221
LOINCcodesarecopyright19952009,RegenstriefInstituteandtheLogical ObservationIdentifierNamesandCodes(LOINC)Committee.Allrightsreserved. ThefollowingNIPtablesarenotincludedinthisGuide.TheysupportVAERS reporting,whichnotwithinthescopeofthisGuide. NIP005EventConsequences NIP007VaccinatedatLocation NIP008VaccinepurchasedwithFunds NIP009Adverseeventpreviouslyreported NIP010Reporttype ThefollowingvaluesetsreplaceanumberofNIPtables.Thesehavebeenregisteredin theCDClocalvalueset,CDCPHINVS.Whereappropriate,existingcodesareused.For
exampleSNOMEDcodesareusedforsomecontraindications.Localcodes(VXCxx)will bereplacedasnewSNOMEDcodesarepublished. ValueSetNameImmunizationFundingSource(UsedinOBX5) ValueSetOID2.16.840.1.114222.4.11.3287

ValueSetCode::PHVS_ImmunizationFundingSource_IIS Valuesetdefinition:Indicatesfundingsourceforanimmunization. CodeSetOID: NULLFL:2.16.840.1.113883.5.1008 CDCPHINVS:2.16.840.1.114222.4.5.274
Localimplementsmayexpandthislist. Concept Concept Definition Code Name

Private funds PHC70 Federal funds VXC1 VXC2 PHC68 VXC3 OTH UNK State funds Military funds Tribal funds Other Unspecified Immunization was funded by private funds, including insurance. Immunization was funded with public funds from the federal government. Immunization was funded with public funds from a state. Immunization was paid for with military funds. Immunization was paid for with tribal funds. Immunization was paid for by funding not listed above. Funding source for immunization is not specified.
HL7 Table 0396 Code
V 2.3.1 Value NIP008

PVF
CDCPHINVS
CDCPHINVS CDCPHINVS CDCPHINVS CDCPHINVS NULLFL NULLFL OTH MLF
Examples: |PHC70^Privatefunds^CDCPHINVS| |OTHÔther^NULLFL|
NIPdefinedNIP004Contraindications,Precautions,andImmunities This table has been replaced by separate tables for contraindications, indications, reactions and immunities ValueSetNameVaccinationContraindications(UsedinOBX5) ValueSetOID2.16.840.1.114222.4.11.3288
ValueSetCode::PHVS_VaccinationContraindication_IIS Valuesetdefinition:indicatesacontraindicationtovaccination. CodeSetOID: SNOMED:2.16.840.1.113883.6.96 CDCPHINVS:2.16.840.1.114222.4.5.274
Concept Code
VXC30 VXC17 VXC18 91930004 294847001 294468006 294466005 VXC19
Concept Name
allergy(anaphylactic)to proteinsofrodentorneural origin allergy(anaphylactic)to2 phenoxyethanol allergytobakersyeast (anaphylactic) Allergytoeggs(disorder) Gelatinallergy(disorder) Neomycinallergy(disorder) Streptomycinallergy(disorder) allergytothimerosal (anaphylactic) allergytopreviousdoseofthis vaccineortoanyofitsunlisted vaccinecomponents (anaphylactic)
Definition
allergy(anaphylactic) toproteinsofrodentor neuralorigin allergy(anaphylactic) to2phenoxyethanol allergytobakersyeast (anaphylactic) allergytoeggingestion (anaphylactic) allergytogelatin (anaphylactic) allergytoneomycin (anaphylactic) allergytostreptomycin (anaphylactic) allergytothimerosal (anaphylactic) allergytoprevious doseofthisvaccineor toanyofitsunlisted vaccinecomponents (anaphylactic) allergy(anaphylactic) toalum allergy(anaphylactic) tolatex allergy(anaphylactic) topolymycinB Previoushistoryof intussusception encephalopathywithin 7daysofpreviousdose ofDTPorDTaP currentfeverwith moderatetosevere illness
HL7 Table 0396 Code
CDCPHINVS CDCPHINVS CDCPHINVS SCT SCT SCT SCT CDCPHINVS
03 04 05 06 07 08 09
VXC20 402306009 300916003 294530006 VXC21 Allergytoaluminum(disorder) Latexallergy(disorder) PolymyxinBallergy(disorder) Previoushistoryof intussusception encephalopathywithin7days ofpreviousdoseofDTPor DTaP currentfeverwithmoderate tosevereillness
CDCPHINVS SCT SCT SCT CDCPHINVS
15
CDCPHINVS
VXC22
16
CDCPHINVS
VXC23
Concept Code
Concept Name
currentacuteillness, moderatetosevere(withor withoutfever)(e.g.,diarrhea, otitismedia,vomiting)
Definition
currentacuteillness, moderatetosevere (withorwithoutfever) (e.g.,diarrhea,otitis media,vomiting) chronicillness(e.g., chronicgastrointestinal disease) HistoryofArthus hypersensitivity reactiontoatetanus containingvaccine administered<10yrs previously underlyingunstable, evolvingneurologic disorders,(including seizuredisorders, cerebralpalsy,and developmentaldelay) immunodeficiencydue toanycause,including HIV(hematologicand solidtumors, congenital immunodeficiency, longterm immunosuppressive therapy,including steroids) pregnancy(in recipient) thrombocytopenia thrombocytopenic purpura(history)
HL7 Table 0396 Code
V 2.3.1 Value NIP004 21
VXC24
CDCPHINVS
22
SCT
27624003
Chronicdisease(disorder) HistoryofArthus hypersensitivityreactiontoa tetanuscontainingvaccine administered<10yrs previously underlyingunstable,evolving neurologicdisorders, (includingseizuredisorders, cerebralpalsy,and developmentaldelay)
VXC25
CDCPHINVS
37
VXC26 immunodeficiencyduetoany cause,includingHIV (hematologicandsolidtumors, congenitalimmunodeficiency, longtermimmunosuppressive therapy,includingsteroids)
CDCPHINVS
36
VXC27 77386006 302215000 161461006 Patientcurrentlypregnant (finding) Thrombocytopenicdisorder (disorder) Historyofpurpura(situation)
CDCPHINVS SCT SCT SCT
39 40 41
Examples: |VXC18âllergytobakersyeast^CDCPHINVS| |77386006^patientcurrentlypregnant^SCT|

ValueSetNameVaccinationReactionIIS(UsedinOBX5) ValueSetOID2.16.840.1.114222.4.11.3289
ValueSetCode::PHVS_VaccinationReaction_IIS Valuesetdefinition:indicatesareactionoradverseeventassociateintimewithanimmunization. CodeSetOID: SNOMED:2.16.840.1.113883.6.96 CDCPHINVS:2.16.840.1.114222.4.5.274
Concept Code
Concept Name
Definition
Anaphylaxis Encephalopathy
HL7 Table 0396 Code

SCT SCT
39579001 Anaphylaxis(disorder) Disorderofbrain 81308009 (disorder)
VXC9 VXC10 VXC11 VXC12 VXC13 VXC14 VXC15
persistent,inconsolablecrying lasting>3hourswithin48 hoursofdose collapseorshocklikestate within48hoursofdose convulsions(fits,seizures) within72hoursofdose feverof>40.5C(105F)within 48hoursofdose GuillainBarresyndrome(GBS) within6weeksofdose Rashwithin14daysofdose Intussusceptionwithin30days ofdose
persistent,inconsolable cryinglasting>3hours within48hoursofdose collapseorshocklike statewithin48hoursof dose convulsions(fits, seizures)within72 hoursofdose feverof>40.5C(105F) within48hoursofdose GuillainBarre syndrome(GBS)within 6weeksofdose Rashwithin14daysof dose Intussusceptionwithin 30daysofdose
CDCPHINVS
CDCPHINVS
CDCPHINVS CDCPHINVS
CDCPHINVS CDCPHINVS CDCPHINVS
Examples: |39579001ânaphylaxis^SCT| |VXC14^Rashwithin14days^CDCPHINVS| ValueSetNameVaccinationSpecialIndicationsIIS(UsedinOBX5) ValueSetOID2.16.840.1.114222.4.11.3290

ValueSetCode::PHVS_VaccinationSpecialIndications_IIS Valuesetdefinition:Describesafactorabouttheclientwhichmayimpactforecastingofnextdoseofvaccine needed.
CodeSetOID: CDCPHINVS:2.16.840.1.114222.4.5.274
Concept Code
Concept Name
Definition
Rabiesexposure withinprevious10 days. Memberofspecial group
HL7 Table 0396 Code
V 2.3.1 Value
Rabiesexposurewithin VXC7 previous10days. VXC8 Memberofspecialgroup
CDCPHINVS CDCPHINVS
Example: |VXC7^Rabiesexposure^CDCPHINVS| ValueSetNameImmunizationProfileIdentifiersIIS(UsedinMSH21) ValueSetOID2.16.840.1.114222.4.11.3291

ValueSetCode::PHVS_ImmunizationProfileIdentifier_IIS Valuesetdefinition:Identifiestheprofileusedbythemessage. CodeSetOID: CDCPHINVS:2.16.840.1.114222.4.5.274
Concept Code
Z31
Concept Name
Definition
ReturnCandidate Clients Return Immunization History
RequestImmunization History
HL7 Table 0396 Code

CDCPHINVS
V 2.3.1 Value
ReturnCandidateClients ReturnImmunization History

RequestImmunizationHistory
Z32
CDCPHINVS CDCPHINVS
Z34
Example: |Z34^CDCPHINVS|

ValueSetNameImmunizationScheduleIdentifiersIIS(UsedinOBX5) ValueSetOID2.16.840.1.114222.4.11.3292
ValueSetCode::PHVS_ImmunizationScheduleIdentifier_IIS Valuesetdefinition:Identifiesthescheduleusedforimmunizationevaluationandforecast. CodeSetOID: CDCPHINVS:2.16.840.1.114222.4.5.274
Concept Code
VXC16
Concept Name
ACIPSchedule
Definition
HL7 Table 0396 Code
V 2.3.1 Value
Thisindicatesthat CDCPHINVS thecurrentACIP Scheduleof recommendations wereusedto forecastnextdoses due.
Example: |VXC16ÂCIPSchedule^CDCPHINVS| LocalImplementationsmayaddlocalcodesforlocalschedules.Inordertodothis, thelocalimplementationguideshouldpublishthecodeinalocaltable.Thecode systemidentifier(CDCPHINVSuseaboveisanexample)needstobeincludedinalocal copyofTable0396.Seefirstrowforexample.Thelocalschedulecodeshouldbe recordedasfollows: |yourLocalcode^yourschedulenamehere^99xxx| The99xxxisthelocalcodetableidentifier.Xxxarealphacharacters. ValueSetNameEvidenceofImmunityIIS(UsedinOBX5) ValueSetOID2.16.840.1.114222.4.11.3293
ValueSetCode::PHVS_EvidenceOfImmunity_IIS Valuesetdefinition:Evidenceofimmunityindicatesthatapersonhasplausibleevidence
thattheyhavealreadydevelopedimmunitytoaparticulardisease.Thedefinitionof plausibleevidenceisalocaldecision,butbestpracticewouldsuggestthatserological evidenceofimmunityisthestrongestindicatorofimmunity.

CodeSetOID: SNOMED:2.16.840.1.113883.6.96
Concept Code
Concept Name
Definition
HL7 Table 0396 Code

SCT
409498004 Anthrax
Historyofanthraxinfection.
(disorder)
Concept Code
Concept Name
Definition
HL7 Table 0396 Code

SCT SCT SCT SCT SCT
V 2.3.1 Value NIP004 24 32 29
397428000 Diphtheria (disorder) 76902006 Tetanus (disorder) 27836007 Pertussis (disorder) 40468003 Viralhepatitis, typeA(disorder) 66071002 TypeBviral hepatitis (disorder) 91428005 Haemophilus influenzae infection (disorder) 240532009 Human papillomavirus infection (disorder) 6142004 Influenza (disorder) 52947006 Japanese encephalitisvirus disease (disorder) 14189004 Measles (disorder) 36989005 Mumps (disorder) 36653000 Rubella (disorder) 23511006 Meningococcal infectious disease (disorder) 16814004 Pneumococcal infectious disease (disorder) 398102009 Acute poliomyelitis (disorder)
Historyofdiphteriainfection. Historyoftetanusinfection. Historyofpertussisinfection. HistoryofHepatitisAinfection. HistoryofHepatitisBinfection.
26 25
HistoryofHIBinfection.
SCT
HistoryofHPVinfection.
SCT
Historyofinfluenzainfection. HistoryofJapaneseencephalitis infection.
SCT SCT
Historyofmeaslesinfection. Historyofmumpsinfection. Historyofrubellainfection. Historyofmeningococcalinfection.
SCT SCT SCT SCT
27 28 31
Historyofpneumococcalinfection.
SCT
Historyofpolioinfection.
SCT
30
Concept Code
Concept Name
Definition
HL7 Table 0396 Code

SCT SCT
14168008 Rabies(disorder) 18624000 Diseasedueto Rotavirus (disorder) 4834000 Typhoidfever (disorder) 111852003 Vaccinia (disorder) 38907003 Varicella (disorder) 16541001 Yellowfever (disorder)
Historyofrabiesinfection. Historyofrotavirusinfection.
Historyoftyphoidinfection. Historyofvacciniainfection. HistoryofVaricellainfection. Historyofyellowfeverinfection.
SCT SCT SCT SCT
Examples: |38907003^Varicellainfection^SCT|
Appendix B Guidance on Usage and Example Messages

Author RobSavage RobSavage RevisionHistory Revision Release1 Release1.1 Date 5/1/2010 2/15/2011
Appendix B HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.0) Last Updated on 2/1/2010
ImmunizationHistoryDefinition
Table 12-Immunization History Definition
Animmunizationhistoryconsistsofthefollowingcomponents: DataElement NVAC 37 HL7MessageLocation CoreData Element 38 Clientidentifiers 39 ID Optional PID3 Name Required PID5 Mothersmaidenname Required PID6 Clientdemographics Race Required PID10 Ethnicity Required PID22 Gender Required PID8 Birthdate Required PID7 Deathdate N/A 40 PID29 Birthorder Required PID24 MultipleBirthIndicator N/A PID25 BirthState PID11 Required Birthfacility Optional Clientlocators address Optional PID11 phone(andemail) Optional PID13 ClientIISstatus(MOGE) Optional PD116 Clienteligibilityforvaccine Optional PV120 funding(VFC) Clientprimarylanguage Optional PID15 Clientprivacyrequest N/A PD112 (protectionofinformation) Clientdesiresonbeing N/A PD111 contactedforreminders Nextofkinname,addressand Optional NK1Segment phonenumber Historyofvaccinepreventable Optional OBXsegment
37 38
National Vaccine Advisory Committee Required means that a system must be able to store if known. Optional means that a system should be able to store if known. 39 ID is a list of all important identifiers like IIS id, medical record number, birth registration number and SSN. 40 N/A indicates that it is not currently in the NVAC core data elements,
Appendix B 1 HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) Last Updated on 1/25/2011
Animmunizationhistoryconsistsofthefollowingcomponents: DataElement NVAC 37 HL7MessageLocation CoreData Element 38 diseasesuchasVaricella Immunizationrecords RXAsegment Vaccine Required RXA5 Vaccinelot Required RXA15 Vaccinationdate Required RXA4 Quantity N/A RXA6andRXA7 Vaccineprovider Optional Administering RXA10 Organization Ordering ORC12 clinician Clinicsiteof RXA11 administration Manufacturer Required RXA17 Vaccineinformation N/A OBXsegment sheetdate Injectionsite Optional RXR2 Administrationroute N/A RXR1 VaccineExpirationDate Optional RXA16 Fundingsource N/A OBXsegment Recordsource(historical Optional RXA9 indicator) Reactionstovaccination N/A OBXsegment Refusalofvaccination N/A RXA18andRXA20 Clientconditionsthatimpact N/A OBXSegment forecastinganddosevalidation Nextdoseforecast N/A OBXSegment Validationofrecordeddose N/A OBXSegment basedonschedule recommendations
SendImmunizationHistory(VXU) BusinessProcess
Thefollowingactivitydiagramillustratestheprocessofsendingandreceivingan immunizationhistory.Itismeanttobeillustrativeandnotprescriptive.Withthe
exceptionoftheHL7messagestructureprocessingandthereturnofan acknowledgement,theactivitiesarebasedonlocalbusinessrules.Theserulesmustbe documentedforsmoothinteroperability.HL7onlyaddressesthemessages,VXUand ACK.
Figure 6-VXU Business Process
1. TheprocessforsendingaVXU(Immunizationhistory)beginswiththesending systembuildingtheVXUmessage. 2. ThesendingsystemconnectstothereceivingsystemandsendstheVXU. 3. Thereceivingsystemacceptsthemessage. 4. Thereceivingsystemparsesthemessageandvalidates.

a. DetermineifmessagemeetsHL7rules b. Validatebasedonlocalbusinessrules 41 5. Seekmatchingclientinreceiverdatabase a. Nomatchisfound 42 i. Addtheclienttothereceiverdatabase. ii. Sendacknowledgementmessage 43 b. Exactlyonematchfound i. Determineifclientinreceiverdatabasehasindicatedthathis/her dataistobeprotected(protectionindicator=Y) 44 ii. Protectionindicator=Y 1. Donotintegraterecordintoreceiverdatabase 2. Sendacknowledgement 45 iii. Protectionindicator=N 1. Basedonlocalbusinessrules,integrateincomingrecord intoreceiverdatabase. 2. Sendacknowledgement c. Morethanonematchfound i. Sendacknowledgement 46 6. Sendacknowledgmenttosendingsystem 7. Sendingsystemacceptsacknowledgementmessage. 47 Notethatsendingsystemmayindicatethatitdoesnotacceptacknowledgement messages.Inthiscase,noacknowledgementisreturned.Thisisnotrecommended. Itisexpectedthataclientsimmunizationhistoryisthecompletehistoryknowntothe sendingsystem,andnotjustupdatesonnewinformationinthesendingsystem.While somesystemsmaysendupdatesonly,thereceivingsystemshouldmakeno assumptionsaboutthis.Thishasimportantimplicationsforprocessingthoseincoming records.Atthesametime,thesendingsystemmaynotknowofallimmunizations,so receivingsystemmusthaveaprocessforintegratingthereceiveddataintoanexisting record.TheModelingImmunizationRegistryOperationsWorkgroup(MIROW)has
See Send Error in ACK for dealing with errors if either of these two tasks identifies problems. Local business rules determine what happens next, but we assume that it is a simple insert of the client record. The receiving system may require review and confirmation prior to insertion. Other systems may choose to require human review before adding to data base. 43 See Send Acknowledgement with no error. 44 Locally, this may be known as the sharing indicator. In this case, the equivalent value is sharing = N. 45 Local business rules may vary. In general, the acknowledgement may reject the client record, but not indicate the existence of the client record in the receiver system. 46 Local business rules will determine how the multiple matches are to be handled. The record could be put into a pending state, rejected outright, loaded in as a new record for clean up later. 47 The sending system response to an acknowledgement message (ACK) is locally determined. Good practice would be to have a way to use the ACK to alert user to outcome and to allow trouble-shooting of problem messages.
42
41
producedachapterofbestpracticesonthisprocess.ThisisavailableontheAmerican ImmunizationRegistryAssociationwebsite(www.immregistries.org). Thefollowingexamplemessagesrepresentstraightforwardimmunizationhistory messages.Theydonotillustratedealingwithspecificusecases,suchasmessaging reactions,clientspecificconditionsorvaccineforecasts.Clearly,thesemaybe componentsofaVXU,butwillbeaddressedseparatelytosimplifythemessages. Itisimportanttoreiterateherethatconformantsystemsshouldbeabletosuccessfully populateandprocesstheVXUmessagesegmentsandfieldsidentifiedasRequiredor Requiredbutmaybeempty.Theyshouldbeabletopopulateandprocessconditional itemswhenthepredicateconditionsaremet.Ifsegmentsorfieldsareoptionally repeating,theyshouldbeabletogracefullyhandletherepetitions.Systemsthatdonot conformtotheseexpectationsriskmisseddata.
SupportedMessageSegments
Thefollowingtableliststhesegmentsandtheirusage. Segment Cardinality Usage 48 Notes MSH [1..1] R Everymessagebegins withanMSH PID [1..1] R EveryVXUrequires onePID PD1 [0..1] RE NK1 [0..*] RE NK1mayrepeatand mayincludetheclient witharelationshipof self. PV1 [0..1] RE IN1 [0..1] O IN13arenotspecified inthisguide. IN2 [0..1] O IN3 [0..1] O AllofthefollowingsegmentsarepartoftheORDERgroup.A VXUdoesnotrequireanORCgroup,allowingupdateof patient/clientrelateddataintheabsenceofupdatedRXA data.EachRXAdoesrequireanORC. ORC [0..*] RE RXA [1..1] 49 R EachRXAisthechildof
R means it is required. RE means it is required if known/available. X means not supported in this Guide. O means optional. 49 Each ORC must have 1 RXA and each RXA belongs to exactly 1 ORC.
48
RXR OBX
[0..1] [0..*]
RE RE
NTE
[0..1]
RE
onORC EachRXRisthechildof oneRXA EachOBXisthechild ofoneRXA.EachRXA mayhavemorethan oneOBXsegment. EachNTEisthechildof oneOBX
Figure 7-Segment Usage
ExampleVXU#1Basicmessage:
Storyboard: JohnnyNewPatient(male),born4/14/09hashad1doseofHepBon4/15/09, accordingtherecordbroughtinbyMom(SallyPatient).Theyliveat123AnyStreet, Somewhere,Wisconsin54000.NurseStickeratDalittleClinic(DCS_DC),administersthe followingshotson5/31/09: DTAPHepBIPV(Pediarix)lot#xy3939IM HIB(ActHIB)lot#33k2aIM TheywereallorderedbyDrMaryPediatricwhobelongstoDabigClinicalSystem(DCS). Momacknowledgedthathisdatamaybesharedwithotherproviders.Johnnyiseligible forMedicaid.HismedicalrecordnumberinDabigClinicalSystemis432155.Myron ClerkenteredtheinformationintotheEHRs(MYEHR). TheinformationwassentfromDabigClinicalSystemtotheStateIIS Notethatwewillindicatetheendofeachsegmentwitha<CR>.Segmentsmaywrap aroundinthisdocument.Wewillinsertablanklinebetweeneachsegmentfor increasedreadability.
MSH|^~\&|MYEHR|DCS|||20090531145259||VXU^V04^VXU_V04|3533469|P|2.5.1 ||||AL <CR> PID|1||432155^^^DCS^MR||Patient^Johnny^New^^^^L||20090414150308|M||| 123 Any St^^Somewhere^WI^54000^^L<CR> PD1||||||||||||N|20090531<CR> NK1|1|Patient^Sally|MTH^mother^HL70063|123 Any St^^Somewhere^WI^54000^^L<CR> PV1|1|R||||||||||||||||||V02^20090531<CR> ORC|RE||197023^DCS|||||||^Clerk^Myron|||||||DCS^Dabig Clinical System^StateIIS<CR>
RXA|0|1|20090415132511|20090415132511|31^Hep B Peds NOS^CVX|999|||01^historical record^NIP0001|||||||| <CR> ORC|RE||197027^DCS|||||||^Clerk^Myron||^Pediatric^MARY^^^^^^^L^^^^^^ ^^^^^MD<CR> RXA|0|1|20090531132511|20090531132511|48^HIB PRP-T^CVX|999|||00^new immunization record^NIP0001|^Sticker^Nurse|^^^DCS_DC||||33k2a||PMC^sanofi^MVX<CR> RXR|C28161ÎM^NCITÎMÎM^HL70162|<CR> ORC|RE||197028^DCS|||||||^Clerk^Myron||^Pediatric^MARY^^^^^^^L^^^^^^ ^^^^^MD<CR> RXA|0|1|20090531132511|20090531132511|110^DTAP-Hep BIPV^CVX|999|||00^new immunization record^NIP0001|^Sticker^Nurse|^^^DCS_DC||||xy3939||SKB^GSK^MVX<CR> RXR|IMÎM^HL70162^C28161ÎM^NCIT|<CR>
ExampleVXU#2Indicatevaccinefundingsourceandclienteligibility status:
Immunizationmessagesmustbeabletoconveytheeligibilitystatusofarecipientwhen theyreceivedimmunizations.Inaddition,thesemessagesmustbeabletoinclude informationonthefundingsourceforanimmunization.Whilethesearerelated,they areseparateconcepts. Eligibilitystatus: ThePV1segmentshallbeusedtoconveyeligibilitystatus,asithasinthepast.ThePV1 20,FinancialClass,isarepeatingfieldofFCdatatype.Thisdatatypeiscomposedof twocomponents.Thefirstisfinancialclasscode(datatypeIS)andpointstoauser definedtable(0064).ThesecondcomponentisEffectiveDateandinourcaseindicates whenthefinancialclasswasdetermined.Theformatisdisplayedbelow. |FinancialclassÊffectivedate| Arepetitionisindicatedbytherepetitionsymbol,~.Therepetitionfollowsthe~.Ifa listofeligibilityissent,therepetitionsshouldbeuniqueonfinancialclassandeffective date.Thatis,twodifferentfinancialclassesmayhavethesameeffectivedate. Similarly,twodifferenteffectivedatesmayhavethesamefinancialclass. Onlythecurrenteligibilityneedstobesentinamessage,butthehistoryofeligibility shouldbestored.Receivingsystemsshouldbeabletoaccepteithercurrenteligibilityor completehistoryofeligibility.
EligibilitystatusisakeydataelementforcreatingtheVaccinesforChildren(VFC)report onvaccineusage.Supportforthisreportrequiresthatsystemsstoreahistoryof eligibilitystatusesandassessmentdates.Inthepast,somesystemshaveonlykeptthe mostcurrentstatus.Thispreventsaccuratereporting.

Sending One Financial Class With Date:
ThefollowingexampleshowsthePV1segmentwithonefinancialclassandeffective date.
MSH
PID
PV1|1|R||||||||||||||||||V02^20090531<CR>
Sending Two Financial Classes With Dates:
ThefollowingexampleshowsthePV1segmentwithtwodifferentfinancialclassesand theireffectivedates.ThefirstfinancialclassisfromthestandardVFCclassesandthe secondisahypotheticalfinancialclass.Bothwereevaluatedonthesameday.

MSH PID
PV1|1|R||||||||||||||||||V02^20090531~IHS02^20090531<CR> If repetition is used and indicates 2 financial classes on the same date, they should not be mutually exclusive. (i.e. Medicaid and not eligible for VFC) Documentation of local usage will greatly facilitate interoperability. This documentation should include both local values in table 0064 and business rules for processing. Local codes should express information about the client at the time of a visit and not about payment source for the immunizations given that day.
FundingSource: Thefundingsourceofavaccinationindicateswhopaidforagivenimmunization.Table CDCPHINVSlocalvaluesImmunizationFundingSource(ValuesetOID 2.16.840.1.114222.4.11.3287)liststhecategories.Localsystemsmaysupportadditional values,butmustdocumentthem. Thefollowingtableliststhevalueset.

Value
PHC70
Label Private funds
Definition Immunization was
Federal funds
VXC1
State funds Military funds Tribal funds Other Unspecified
VXC2
PHC68
VXC3
OTH
UNK
funded by private funds, including insurance. Immunization was funded with public funds from the federal government. Immunization was funded with public funds from a state. Immunization was paid for with military funds. Immunization was paid for with tribal funds. Immunization was paid for by funding not listed above. Funding source for immunization is not specified.
Thefundingsourcemaybelinkedtoeachimmunizationrecord,usinganOBXsegment. (Seenotebelowforthesupportinginfrastructureonthesystemside.) NotethattheorderofOBXsegmentsisnotspecified.Theymayappearinanyorder.So oneimmunizationmayhaveanOBXlistingfundingsource,followedbyanOBX indicatinganadversereaction.Theordermaybereversedandreceivingsystemshould gracefullyhandlethemineithercase. Observationsubid(OBX4)groupsrelatedobservations. Thefollowingexampleshowsanimmunizationrecordwithonefundingsourceanda second,historicalrecordofanimmunizationwithoutafundingsource.Itdoesnotshow eligibility,whichwouldbeinthePV1segment.
MSH. PID ORC|RE|197027^DCS|1970237^DCS|||||||^Clerk^Myron||^Pediatric^MARY^^^ ^^^^L^^^^^^^^^^^MD<CR> RXA|0|1|20090531132511|20090531132511|48^HIB PRPT^CVX|999||||^Sticker^Nurse|^^^DCS_DC||||33k2a||PMC^sanofi^MVX<CR> RXR| C28161ÎM^NCITÎMÎM^HL70396<CR>
OBX|1|CE|30693-3^funding source for immunization^LN|1|PHC70^Privately funded^CDCPHINVS||||||F|||20090415<CR> ORC|RE|197023^DCS|197023^DCS|||||||^Clerk^Myron||^^^^^^^^^L|||||DCS^ Dabig Clinical System^StateIIS<CR> RXA|0|1|20090415132511|20090415132511|31^Hep B Peds NOS^CVX|999||||||||||| <CR>
Intheexampleabove,weseethatthefirstimmunizationinthemessagewasfundedby Privatefunding.Thesecondimmunizationinthemessagedoesnothavefundingsource included,probablybecauseitisnotabletobedetermined,sinceitisahistoricrecordof animmunization. Supportinginfrastructure: Inordertosupportthislevelofdetail,thefundingsourceforeachdoseofvaccinegiven mustberecordedinthedatabase.Thereareanumberofpotentialsolutions,butone logicaloneistobuildonexistinginventorymanagementcapabilities.Ifeach immunizationispulledfromaspecificlotofvaccineandthatlothasafundingsource associated,thenthefundingsourcemaybedetermined.Thiswouldrequirethatthe inventorymanagementsystemwouldneedtoseparatevaccinelotswiththesamelot number,butdifferentfunding.
ExampleVXU#3Includeimmunizationhistoryevaluationandforecastin VXU
The LOINC codes and value sets are still in the process of development. The basic concepts should not change. Evaluatinganimmunizationhistory,basedontherecommendationsoftheACIP scheduleorotherscheduleisanimportantfunctionprovidedbymanyIIS.Basedonthis evaluationandotherfactors,recommendationsmaybemadefornextdosesdue.Some oftheirtradingpartnerswouldliketoreceivetheoutcomeofthisevaluation.The previousimplementationguideincludedamethodforaccomplishingthisusingOBX segments.Thisdocumentillustrateshowthisisdoneandexpandsonthetypesof informationthatmaybemessaged. Thisdocumentdoesnotdescribenorspecifythefunctionalityoraccuracyofthe forecastingservice.Thefocusisonlyonthecontentofthemessages.Implementations shouldpublishdocumentationonlocalspecifics. Thisdocumentisnotmeanttosupportacalltoaforecastingandevaluationservice.It ismeanttosupportexistingapplicationsthatmessagevaccineforecastsandevaluation asapartofacompleteimmunizationhistory.
This does not mean that every message must have one of the required OBX. It just means that this concept needs to be known to put the evaluation and forecast in context.
Whenaclinicianevaluatesapersonsimmunizationhistoryandmakes recommendations,she/hemustuseastandard(schedule).Traditionally,clinicianshave evaluatedbasedonvaccinegroupsorfamilies.Theschedulehasoneormoresetsof immunizationeventsthatcanbesatisfiedtoindicateprotectionagainstthediseasesof thevaccinegroupofinterest.Theseconstituteaseries. Thefollowingtablelaysouttheinformationneededtoconveyanevaluationand forecast. Data Use OBX3Value Optionalityfor element meaningfulevaluation andforecast 50 . Schedule Identifiesthe 597799 Required standardsused. ACIPisthe prototypical example. Vaccine Identifieswhich Singlevaccinetypeuse Required group/family diseasesare 309567 expectedtobe preventedby Combinationvaccine completionof use388900 series. Seriesname Nameofthespecific 597807 Optional setofdosesand recommendations thatwereusedto evaluatethisdose andmake recommendations. Ordinal Indicateswhich 309732 Required positionin doseinaseriesthis primary givenimmunization series fulfills. DoseValidity Indicatesifthisdose 597815 Optional wasgiven appropriatelyfor thisseriesinthis schedule.
50
Data element Numberof dosesin primary Series
Use
OBX3Value
SeriesStatus
Nextdose forecast
Indicateshowmany 597823 appropriatelygiven dosesarerequired tomeetthegoalsof thisseries. Notethatinthe casewherethere aredosesthatmay beskipped,dueto theageofthe client/patient,the numbershallreflect theadjusted numberofdoses. Thisindicatesthe 597831 statusoftheclients progresstoward meetingthegoalsof theseriesselected. Thiscouldbe complete,overdue, inprogress,etc. Earliestdatedose 309815 shouldbegiven. Datenextdose recommended Latestdatenext doseshouldbe given Datedoseis overdue 309807
Optionalityfor meaningfulevaluation andforecast 50 . Optional
optional
Requiredforforecast
597773
597781
Reasoncode
Thiscanindicate whyadoseisnot validorthatthe
309823
Optional
Data element
Use
OBX3Value
Optionalityfor meaningfulevaluation andforecast 50 .
recommendation waschanged becauseofaspecial circumstance. Itisimportanttonotethatevaluationrelatestodosesreceived,butrecommendations relatetodosesnotyetgiven.Eachwillbeaddressedseparately.Evaluationwillbe associatedwithanimmunizationreceived.Recommendationswillbeassociatedwith futureevents.ThatistheywillbeassociatedwithanRXAthatindicatesthatnodose wasgiven.Theywillnotbeassociatedwithexistingimmunizationrecords(RXA).This meansthatifapersonhasreceivedonehepBdose(valid).Theevaluationwillbe associatedwiththefirstRXAindicatingthatshe/hereceivedthedose.TheOBX followingthiswillindicatetheevaluation.Therecommendationsforthenextdosedue willbeassociatedwithasecondRXA. Thereareotherfactorsrelatingtoforecasting,suchasexemptionandprevious immunity.Thesearedealtwithintheclientspecificconditionsimpactingforecasting. Whenagivendoseisevaluatedagainstaschedule,wecanmakeanumberof observationsaboutit.EachdoseofvaccinerecordedistransmittedinanRXAsegment. EachRXAsegmentmayhaveoneormoreOBX,observationsegments.Eachdistinct pieceofinformationisfoundinitsownOBXsegmentandfollowsitsassociatedRXA. Thebasicstructureforincludingevaluationinamessageis: RXAtheimmunizationandvaccine OBXvaccinegroup OBXtheschedule OBXseriesused OBXdosenumberinseries(ordinalposition) OBXdosesinseries OBXdosevalidity OBXseriesstatus Thebasicstructureforevaluationofcombinationvaccinecomponentsis: RXAtheimmunizationandvaccine OBXvaccinegroup 51
51
All of the related observations are linked to the vaccine group using the OBX-4, observation sub-id.
OBXtheschedule OBXseriesused OBXdosenumberinseries(ordinalposition) OBXdosesinseries OBXdosevalidity OBXvaccinegroup 52 OBXtheschedule OBXseriesused OBXdosenumberinseries(ordinalposition) OBXdosesinseries OBXdosevalidity OBXseriesstatus Thebasicstructurefortherecommendationinthemessageis: RXAvaccine,CVXNOS(nodosegiven) OBXtheschedule OBXtheseriesused OBXdosenumberintheseries OBXnumberofdosesintheseries OBXearliestnextdosedue OBXrecommendednextdosedue OBXoverduenextdosedue OBXseriesstatus ThisdocumentwillfirstillustratehowtobuildeachOBXtosupportreportingthekey information.Thenextsectionwillshowhowtoputthesepiecestogethertocreate evaluationandrecommendationsinVXU.Notethatthesameapproachmaybeusedin anRSPthatreturnsanimmunizationhistory. IndicatingtheSchedulethatwasused: Evaluationisonlymeaningfulinthecontextofadefinedschedule.Scheduleisa requiredelementinamessagethatiscarryingevaluationorrecommendation information. TheonlyschedulesupportedbyCDCistheACIPschedule.Somesystemsmaychooseto developotherschedulesthatmeetlocalneeds.WeassumethatACIPistheschedule usedinourexamples.
52
All of the related observations are linked to the vaccine group using the OBX-4, observation sub-id.
TherearenodifferencesbetweenrecommendationandevaluationintheOBX indicatingthescheduleused. ThefollowingexampleshowsthattheACIPschedulewasusedtoevaluatethis immunization.

ORC|RE||197027^DCS|||||||^Clerk^Myron||^Pediatric^MARY^^^^^^^L^^^^^^ ^^^^^MD<CR> RXA|0|1|20090412|20090412|48^HIB PRP-T^CVX|999|||00^new immunization record^NIP0001|^Sticker^Nurse|^^^DCS_DC||||33k2a||PMC^sanofi^MVX<CR> RXR|C28161ÎM^NCITÎMÎM^HL70162|<CR>
OBX|1|CE|59779-9^Schedule used^LN|1|VXC16ÂCIP^CDCPHINVS||||||F|||20090415<CR>
IndicatingVaccineGroupassociated: Evaluationisconsideredbyvaccinegroup.Someimmunizationsarecomposedofone vaccinegroupwhileothersarecombinationsofseveralvaccinegroups.Thefirstismore straightforwardwhenconstructingamessage.ThevaccinegroupisindicatedinanOBX. AllfollowingOBXrelatetothatvaccinegroup,usingtheOBX4Observationsubid. SingleVaccinegroupVaccine:

RXA|0|1|20091010||03^MMR^CVX|0.5|ML^ÎSO+||||||||EZ342|20111001|MSD^^MVX<CR> OBX|1|TS|30956-7^vaccine type^LN|1|03^MMR^CVX||||||F<CR>
Inthecasewhereacombinationvaccineisgiven,eachvaccinegroupisidentifiedand hassegmentsdescribingitsevaluation.Thiscaserequiresthattheinformationabout eachvaccinegroupbehandledseparately.Eachvaccinegroupisassociatedwitha groupofOBX,usingtheOBX4observationsubid. Combinationvaccine:

RXA|0|1|20091010||94^MMRV^CVX|0.5|ML^ÎSO+||||||||EZ342|20111001|MSD^^MVX<CR> OBX|1|TS|38890-0^Component Vaccine Type^LN|1|21^Varicella^CVX||||||F<CR> stuff about this vaccine group OBX|4|TS|38890-0^Component Vaccine Type^LN N|2|03^MMR^CVX||||||F<CR> stuff about this vaccine group
ReportingTheOrdinalPositionInASeries: Evaluation: ReportingtheordinalpositioninaselectedseriesmaybereportedinanOBXsegment. Theordinalpositionisthedosenumberbeingsatisfiedbyagivenimmunization.(dose #1ina3doseseries)Thenextsectionillustrateshowtoreporttheexpectednumberof dosesintheseries.(3intheexampleabove)Itwouldbeemptyforaboosterdoseand fordoseswhicharenotvalid.

ORC|RE||197027^DCS|||||||^Clerk^Myron||^Pediatric^MARY^^^^^^^L^^^^^^^^^^ ^MD<CR> RXA|0|1|20090412|20090412|48^HIB PRP-T^CVX|999|||00^new immunization record^NIP0001|^Sticker^Nurse|^^^DCS_DC||||33k2a||PMC^sanofi^MVX<CR> RXR|C28161ÎM^NCITÎMÎM^HL70162|<CR> OBX|1|TS|30956-7^vaccine type^LN|1|17^HIB, NOS^CVX||||||F<CR> OBX|1|CE|59779-9Îmmunization Schedule used^LN|1|VXC16ÂCIP^CDCPHINVS||||||F|||20090415<CR> OBX|1|N|30973-2^dose number in series^LN|1|1||||||F|||20090415<CR>
Recommendation: Thereisadifferentcodetobeusedforindicatingthenumberofthenextdosedue. NotethatthepreferredLOINCcodesarenotvaccinegroupspecific.Theuseofold vaccinespecificLOINCshouldnotoccur.Forexample,30936-9 DTaP/DTP dose count in combination vaccine shouldnotbeused. ReportingtheNumberofDosesinaSeries: Therearenodifferencesbetweenrecommendationsandevaluations.Thisnumeric fieldindicatesthenumberofdosesrequiredtomeetthegoalsoftheprimaryseriesfor thisvaccinegroup.Itwouldbeemptyforaboosterdose.
OBX|1|N|59782-3^number of doses in series^LN|1|1||||||F|||20090415<CR>
ReportingNextDoseRecommendationDates: Forecastingnextdosedueisanimportantfunctionthatcanbereportedinamessage. Thereareanumberofkeydatesthatcanbecommunicated: Datetype Definition Theearliestacceptabledatebasedonthe Thisistheearliestdatethataperson scheduleused shouldreceivethenextdoseforthe vaccinegroup.Itdoesnotincludeany graceperiod.Forexampletheearliest
dataapersonshouldreceiveaDTAPis age42days. Therecommendeddate Thisisthedatethatapersonshould ideallyreceivethenextdoseforthe vaccinegroup. Theoverduedate(thedatethepersonis Thisisthedatethatthepersonis consideredlateforgettingthevaccine) consideredlateforgettingthenextdose forthevaccinegroup.Itisalocally definedvalue. Thelatestdatethatadoseshouldbegiven Thisisthelastpossibledatethataperson (e.g.forHIBitiscurrently5yearsold) shouldreceivethenextdoseforthe vaccinegroup.Generally,thisisrelated toageofrecipient.Forexamplethe oldestapersonshouldreceiveadoseof HIBis5yearsold. Notalldatesmayberelevantandsomaybeomitted.
OBX|1|TS|30956-7^vaccine type^LN|1|17^HIB, NOS^CVX||||||F<CR> OBX|1|CE|59779-9Îmmunization Schedule used^LN|1|VXC16ÂCIP^CDCPHINVS||||||F|||20090415<CR> OBX|1|DT|30980-7^Date vaccination due^LN|1|20090615||||||F|||20090415<CR>
OBX|1|DT|59777-3^Latest date to give vaccine^LN|1|20100615||||||F|||20090415<CR>
ReportingRecommendationReasons: Sometimesadosemaybreakaspecificruleintheschedule.Alternativelyconditions maytriggerspecialrules,suchastheneedforacceleratingtherecommendationsto catchupwiththepreferredschedule.Thismaybereportedfromthesystemina message.Thelistofvaluesislocallydetermined.Theseshouldbedocumentedlocally. LocalCodesdrivetheanswers. UsingTheNTESegmentAssociatedWithAnOBXToProvideMoreInformation: EachOBXmayhaveanassociatedNTEsegment.Thismaybeusedforsendingnotesor commentsthatthereceivingsystemmaychoosetodisplaytoauser.Anyuseofthisis localandrequireslocaldocumentation. IssuesThatAreOutsideOfMessagingButImpactTheValueSentInAMessage 1. Therearesomeserieswheredosesmaybeskipped.Forinstanceapersonwho getssignificantlybehindonsomeHIBseriesmayskipadoseandcomplete
early.Localprofilesshouldspecifyhowthesedoseswillbehandledand messaged. 2. Somevaccineshaveanumberedprimaryseriesandarefollowedbyintermittent boosterdoses.Thesedonotincreasethenumberofdosesintheprimaryseries. 3. Personswhohavebeenpreviouslyinfectedmaynotneedfurtherdosesof vaccine.ThiscanbemessagedinanOBXreportingclientimmunity.
ExampleVXU#4Sendclientspecificconditions
Evaluationofimmunizationhistoryandforecastingnextdosedueareimportantservices providedbymanyIIS.Thereareanumberoffactorsthatcanimpacttheseevaluations andforecasts.Ingeneralterms,somefactorscontraindicatenextdoses,whileothers recommendnextdoses.ThesefactorsmaybemessagedinOBXsegmentsassociated withanRXA. Evidenceofimmunity: Infectionwiththediseasesthatarethetargetofimmunizationsleadstolongterm immunity.Furtherimmunizationagainstthediseaseisnotlikelytoprovidebenefit. Definition: Evidenceofimmunityindicatesthatapersonhasplausibleevidencethattheyhave alreadydevelopedimmunitytoaparticulardisease.Thedefinitionofplausibleevidence isalocaldecision,butbestpracticewouldsuggestthatserologicalevidenceofimmunity isthestrongestindicatorofimmunity. TheexamplebelowshowsthatnodoseofHepBvaccinewasgivenbecausetheperson hadevidenceofpreviousinfectionwithHepB.
ORC|RE||197027^DCS|||||||^Clerk^Myron| <CR>
RXA|0|1|20090412|20090412|998^No vaccine administered^CVX|999<CR> OBX|1|CE|59784-9^Disease with presumed immunity ^LN|1|66071002^HISTORY OF HEP B INFECTION^SCT||||||F<CR>
Contraindicationstoimmunization: Thereareanumberofcontraindicationstoimmunization.Thesemaybetemporaryor permanent.Oneisahistoryofreactionstopreviousimmunization.Thatisdealtwith above.Othersincludeallergiestocomponentsofvaccines,physicalconditions,current medicationandcurrentillnesses. Definition:

Acontraindicationisanyphysicalcondition,currentmedicationorotherfactorthat indicatesthatapersonshouldnotreceiveanimmunizationthatmaybeassociatedwith thecontraindication.Thiscontraindicationmaybetemporaryorpermanent. LOINC: 30945-0 Examples:

OBX|1|CE|30945-0^Vaccination contraindication^LN|1|91930004âllergy to eggs^SCT||||||F|||20090415<CR> OBX|1|CE|30945-0^Vaccination contraindication^LN|1|VXC19âllergy to thimerasol(anaphylactic)^CDCPHINVS||||||F|||20090415<CR>
Factorswhichindicatetheneedforanimmunizationorachangedrecommendation: Severalfactorscandrivetheneedforaspecificimmunizationorachangeinthenormal scheduleforimmunization.Thesemaybeanexposuretoaninfection,suchasrabies. Otherriskfactorsmayincludemembershipinariskgroup. Definition: Ariskfactorissomecharacteristicofanindividual,whichmayleadtoa recommendationforaspecificvaccine.

OBX|1|CE|59785-6^Special Indication for vaccination^LN|1|VXC7êxposure to rabies^CDCPHINVS||||||F|||20090415<CR>
ExampleVXU#5Sendimmunizationsassociatedwithreactions(adverse events)
Somepeopleexperienceadverseeventsafterreceiptofanimmunization.Inmany cases,ImmunizationInformationSystems(IIS)recordtheseinconjunctionwitha specificimmunizationevent.Occasionally,theexactimmunizationeventinformationis unknown.(e.g.anaphylaxisoccurredafterapreviousdose,yearsinthepast.) Definition: Anadversereactionisanegativephysicalconditionthatoccursshortlyafteroneor moreimmunizationshavebeenreceived. LOINCcode: 31044-1
Value Set is Vaccination Reaction in CDCPHINVS
ORC|RE||197027^DCS|||||||^Clerk^Myron||^Pediatric^MARY^^^^^^^L^^^^^^ ^^^^^MD<CR>
RXA|0|1|20090412|20090412|48^HIB PRP-T^CVX|999|||00^new immunization record^NIP0001|^Sticker^Nurse|^^^DCS_DC||||33k2a||PMC^sanofi^MVX<CR> RXR|C28161ÎM^NCITÎMÎM^HL70162|<CR>
OBX|1|CE|31044-1^reaction^LN|1|VXC12^fever > 40.5 C^CDCPHINVS||||||F|||20090415<CR>
OBX|1|CE|31044-1^reaction^LN|1|81308009êncephalopathy, disorder of brain^SCT||||||F|||20090415<CR>
ThisexampledescribesadoseofHIBgivenon4/12/2009.On4/15/2009,theclient experiencedafever>40.5Candencephalopathy.
ExampleVXU#6DeleteanImmunizationRecord
Thereareoccasionswhenasystemthathassentanimmunizationrecordtoanother systemwishestodeletetherecordontheothersystem.Thereareseveralapproaches thatmaybetaken.Theapproachselecteddependsontherulesandcapabilitiesofboth systems. Oneapproachusesasnapshotapproach.Eachtimeanimmunizationhistoryissent,it replacestheentireimmunizationhistoryonthereceivingside. AnotherapproachistousetheRXA21,ActionCodetorequestdeletionofaspecific record.Somesystemswillmatchtherequestwithanexistingimmunizationrecord basedonvaccine,vaccinationdateandotherfactorsimplicitintherecordandthe request.TheymayalsousetheORC3,FillerOrderNumber,touniquelydeletethe recordofinterest. ThefollowingdiagramillustrateshowtheORC3maybeusedtoidentifyan immunizationrecordfordeletion 53 .Notethatthesendingsystemincludesthesending systemuniqueidintheORC3firstcomponent.Thesecondcomponentistheassigning authority,inthiscaseasystemthatislabeledMYIIS.Inorderforalaterdeleterequest tobesuccessful,thereceivingsystemmuststorethosevalues.Asubsequentrequestto deleteanimmunizationrecordincludesthesendingsystemidandassigningauthority. Thereceivingsystemsearchesforanimmunizationrecordwiththesamesending systemidandassigningauthority.Inthiscaseweshowthattherecordmatchismade andtherecordisdeletedfromthereceivingsystem.
53
The other approaches will not be further illustrated here.

VXUExample#7SendInformationAboutVaccineInformationStatement (VIS)
TheVaccineInformationStatement(VIS)isadocumentthatexplainsthereasonsfora vaccineandthepotentialrisksfromreceivingthevaccine.IIStrackthefactthataVIS wassharedwiththeclientorparent.Therearetwopiecesofinformationabouteach event. thedatethattheVISwaspresentedtotheclient/parent. thepublicationdateoftheVISthatwaspresented. ThesearecarriedinseparateOBXsegmentsassociatedwithavaccinationevent(RXA). Foravaccinethatisacombinationofvaccines,thereareoftenseparateVISforeach vaccine.Thismaybehandledbysending2setsofOBX,oneforeachvaccine. ThereisachangeinhowOBX3usesLOINCcodes.Itnolongerusessubcomponent LOINCstogroupinformation.IntheoldGuide,38890-0&29768-9 in OBX-3 indicated the
vaccine group and VIS Publication Date. The first component is unacceptable in version 2.5.1.
Example1Singlevaccine
RXA|0|1|20091010||03^MMR^CVX|0.5|ML^ÎSO+||||||||EZ342|20111001|MSD^^MVX<CR> OBX|1|TS|30956-7^vaccine type^LN|1|03^MMR^CVX||||||F<CR> OBX|2|TS|29768-9^VIS Publication Date^LN|1|20080110||||||F<CR> OBX|3|TS|29769-7^VIS Presentation Date^LN|1|20091010||||||F<CR>
InthisexamplethepersonreceivedadoseofMMRon10/10/2009.TheyreceivedaVIS sheetonthesameday.Thedocumenthadapublicationdateof1/10/2008.
Example2Combinationvaccine
RXA|0|1|20091010||94^MMRV^CVX|0.5|ML^ÎSO+||||||||EZ342|20111001|MSD^^MVX<CR> OBX|1|TS|38890-0^Component Vaccine Type^LN|1|21^Varicella^CVX||||||F<CR> OBX|2|TS|29768-9^VIS Publication Date^LN|1|20091010||||||F<CR> OBX|3|TS|29769-9^VIS Presentation Date^LN|1|20101010||||||F<CR> OBX|4|TS|38890-0^Component Vaccine Type^LN N|2|03^MMR^CVX||||||F<CR> OBX|5|TS|29768-9^VIS Publication Date^LN|2|20071010||||||F<CR OBX|6|TS|29768-9^VIS Presentation Date^LN|2|20101010||||||F<CR>
ThisexampleshowsthatapersonreceivedanMMRVon10/10/2007.Theyreceived2 VISdocuments,oneforMMRandoneforVaricella.ThepublicationdatefortheMMR was10/10/2007andtheVaricellaon10/10/2009.NotetheuseofOBX4togroup relateddatatogether.
VXUExample#8SendInformationAboutImmunizationRefusal
Clientsortheirparentsmaychoosenottobeimmunizedagainstaparticulardiseaseor diseases.Itisimportanttosharethisinformationwhensendingimmunizationhistories usingHL7.Thereareseveralcomponentstomessagingarefusal.Therefusalreasonis indicatedinRXA18.TheCompletionStatusinRXA20indicatesthatthevaccinewas notgiven.Theamountgivenshouldbe0.Thefollowingexampleillustrateshowto accomplishthis.
ORC|RE||197027^DCS|||||||^Clerk^Myron <CR>
RXA|0|1|20091010||107^DTAP-NOS^CVX|999||||||||||||00^Parental refusal^NIP002||RE<CR>
Thisexampleshowsthaton10/10/2009thisclientsparentrefusedtohavethechild receiveaDTAPimmunization.NotethattheORCisstillrequired.FillerOrderNumberis stillrequired,butmeaningless. NotethatRXA2isNOTusedtoindicatedosenumber,asithadinthepastGuide.Itis constrainedtohaveavalueof1.
VXUExample#9SendTwoLotNumbersinRXA
Thereareoccasionswhentwovaccinesarecombinedatthetimeofadministration. TheRXAsegmentshouldbeusedtocapturethisinformation,specificallytheRXA15 field.Thisfieldallowsrepetition.EachseparateLotnumbercanbeplacedherewitha~ separatingthetwolotnumbers.Eachcomponentbelongstooneormorevaccine groupsorfamilies.
Thisdocumentdoesnotspecifytheorderofthelotnumbers. Forexample,ifweneededtoincludeanimmunizationrecordwherethevaccinewas Pentacel,wewouldputthelotnumberfromthefirstcomponentinsequence15, followedbya~andthenthesecondlotnumber.ThespecificRXAfieldishighlighted belowinyellow. Example:

RXA|0|1|20080907|20080907|120^DTAP-IPV-HIB^CVX^^^ |.5|ML^ÎSO+||00^NEW IMMUNIZATION RECORD^NIP001|1234567890^SMITH^SALLY^S|| |||1234ad~455sd||PMC^Sanofi^MVX|||CP |<CR>
VXUExample#10RecordingBirthInformation
Birthinformationcanbeapowerfultoolinidentityresolution.Componentsofbirth informationarelistedintheNVACcoredataelements.Theinformationthatcanbe carriedinanHL7messageincludes: Field HL7messageComponent Example Birthdate PID7 19500512 Birth PID3(asoneidentifierin 12345^^âssigning Registration list) authority^BR Number Birthorder PID24 2 MultipleBirth PID25 Y Indicator BirthState PID11(asoneaddressin ^^^WI^^^BDL list,useaddresstypeBDL) Birthfacility PID23 ChildrensHospital NotethatBirthFacilityisnotusedforBirthState.
VXUExample#11Recordinganincompletelyadministereddoseora nonpotentdose.
Thereareoccasionswhenadoseisnotcompletelyadministered.Forexampleachild mayjumpawayduringinjectionandanunknownquantitywasadministered.Inthis case,thedoseneedstoberecordedtosupportaccurateinventorymanagementandto allowforrecalloftheclientifthereisarecallofthevaccine.Thisisaccomplishedusing theCompletionstatusinRXA20.TheRXAiscompletedasusual,butthecompletion statusissettoPA.Ifmoredetailsareofinterest,thenthisinformationmaybeplacedin anNTEsegmentunderanOBXsegment.Ifthereasonisanonpotentdose,thenthis informationmaybeincludedinanOBX.
RXA|0|1|20091010||03^MMR^CVX|0.5|ML^ÎSO+||||||||A23E1||MSD^^MVX|||PA<CR>
SendAcknowledgementACKInResponseToVXU
Sendinganacknowledgementcanaccomplishoneofanumberoftasks.Itcanindicate thatthemessagethatwassentwassuccessfullyreceivedandprocessed.Itcanalso indicatethatthemessagehaderrors.Whenamessageissent,itcanindicatewhenan acknowledgementisexpected.Thechoicesmayincludealways,onlyonerrorornever. TheabilitytoacceptACKmessagesallowssendingsystemmanagerstotroubleshoot communications.Itallowsthemtoidentifysystematicproblemswithmessagecreation. BeingabletosendACKallowsreceivingsystemmanagerstoinformsendingsystem managersaboutthenatureoferrorsreceived. SendacknowledgementofsuccessinACK Somesystemsmaywishtoreceiveanacknowledgmentmessage,regardlessofwhether thereceivingsystemhadproblemswiththemessage.Inthatcase,thereisarelatively straightforwardresponse.
MSH|^~|&|DCS|MYIIS|MYIIS||20090604||ACK^V04ÂCK|9299381|P|2.5.1|||ER<CR> MSA|AA|9299381<CR>
Intheexampleabove,thesystemwiththecodeDCSissendinganacknowledgementto thesystemwiththecodeMYIISonJune4,2009.Themessageindicatesthattherewere noerrorsinprocessing.DCSonlywantsanacknowledgementifMYIISencountersan errorinprocessingtheacknowledgement. SendErrorinACK Whenthereareerrors,thesecaneitherbefatalornonfatal.Fatalerrorsindicatethat themessagethatwassentwasnotabletobeprocessed.Nonfatalmeansthatthe messagethatwassenthadsometypeoferror,whichdidnotpreventthemessagefrom beingprocessed.Somedatamayhavebeenlostasaresultoftheerror.Inaddition,the errormayhavebeenintheprocessingoftheHL7orviolationofalocalbusinessrule.
Acknowledging A Fatal HL7 Processing Error:
ThereareanumberofproblemsthatmaycauseafatalerrorwhenprocessinganHL7 messagethatarebasedonHL7rules.Theseincludemissingrequiredsegments.Ifa requiredfieldismissing,thenthesegmentistreatedasmissing.Ifthisisarequired segment,thentheerrorbecomesfatal.

MSH|^~|&|DCS|MYIIS|MYIIS||20090604||ACK^V04ÂCK|9299381|P|2.5.1|||ER<CR> MSA|AR|9299381<CR> ERR||PID^5|101^required field missing^HL70357|E<CR> Appendix B 24 HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) Last Updated on 1/25/2011
ERR||PID|100^required segment missing^HL70357|E<CR>
Intheexamplemessageabove,weseethatthePID5(patientname)fieldwasmissing. SincethisisarequiredfieldinaPID,thePIDisignoredandthereforeismissing. Notethatlocalviolationoflocalbusinessrulesmaybyreturnedinanacknowledgement message.Thoserulesarebestrepresentedincodesthatarereferencedinalocaltable. ThesemayberecordedintheERRsegment.Alocalbusinessrulemayleadtorejection ofpartsorallofamessage.Forinstance,alocalbusinessrulemaystatethatthesystem requiresafirstnameforeveryperson.Ifnofirstnameisincludedinthemessage,then thesystemrejectsthefieldforname(PID5).Sincethisisarequiredfieldinarequired message,theentiremessageisrejected.TherewouldbeathirdERRsegmentindicating thatalocallyrequiredcomponentwasmissing.(Noexampleisgiven,asthereisno localtableoferrorsinthisappendix.
Acknowledging A Non-Fatal HL7 Processing Error:
Anonfatalerrormayoccurforanumberofreasons.Oneexamplewouldoccurwhena nonrequiredcomponentorfieldismalformed.Forinstance,LastUpdateDateisnota requiredfield.IfthemessageindicatedthatthelastupdateoccurredonFebruary31, 2009,thenthatfieldwouldbeignored.Sincethefieldisnotrequired,thesegment wouldnotberejected. Localbusinessrulesshouldspecifywhatwilloccurforeachtypeoferror.Inthecase above,thefieldcouldbeignore,itcouldbeacceptedandflaggedforfurtherfollowup, theentiremessagecouldberejectedorthebaddatacouldbestoredinthedatabase as.

MSH|^~|&|DCS|MYIIS|MYIIS||20090604||ACK^V04ÂCK|9299381|P|2.5.1|||ER MSA|AE|9299381 ERR||PID^33|207âpplication internal error^HL70357|I
TheexampleaboveindicatesthatanerroroccurredinPID33(lastupdateddate).Itdid notcausethemessagetoberejected.
SendRequestforVaccineHistory(QBP/RSP)
ProcessforrequestingImmunizationHistory Requestinganimmunizationhistoryisakeyfunctionsupportedbymessaging.As describedabove,acompleteimmunizationhistoryincludesalltheinformationneeded forevaluatingwhatimmunizationshavebeenreceivedandwhatonesareneedednext. ThisqueryisdefinedinaQueryProfileinChapter7oftheImplementationGuide.The requestingsystemsendsarequestwithsomecombinationofdemographicand
identifierinformation.ThisImplementationGuidereplicatesthefunctionalityofthe VXQ/VXX/VXRqueryandresponses. DescriptionoftheVXQ/VXX/VXRProcessFromVersion2.3.1 ThefollowingdescribestheprocessthatwasusedwhenrespondingtoaVXQandis includedtogivebackground.AsdescribedintheusecasesinChapter2ofthisGuide, requestinganimmunizationhistoryrequirestherespondingsystemtofindamatching client.TheoldVXQqueryrequiredimplicitidentityresolution.Thatis,theresponding systemusedlocallydefinedmethodstofindapersonandifexactlyonehighconfidence matchwasfound,returnedanimmunizationhistory.Iflowerconfidencematcheswere found,itreturnedalistofclientswiththeiridentifiers(PID,NK1)forreviewbyaperson ontherequestingsystem.Ifoneofthecandidateswasselectedandreturnedina secondVXQ,thentheonehighconfidencematchisreturned.Thefollowingdiagram illustratestheflow.(Themessagesbetweensystemsareboldedarrows.)
Figure 8--VXQ/VXX/VXR processes
Thereceivingsystemapplieslocallydefinedsearchlogic.Thereare4possibleoutcomes ifthemessageissuccessfullyprocessed: 1. Thesearchfindsexactlyonehighconfidencecandidateclienttoreturn. a. Immunizationhistoryisreturned.

b. Ifsendingsystemusermaychoosetoaccepttheimmunizationhistory, thesendingsystemfollowslocalprotocolsforincorporatingthenew record. 2. Thesearchfindsoneormorecandidateclients. a. SendingsystemuserselectstheoneofinterestandresendstheVXQwith themorecompleteinformation. 3. Thesearchfindsnocandidatestoreturn. a. Anacknowledgementisreturnedtothesendingsystem. 4. Themessageismalformedandnoqueryisprocessed. a. Anacknowledgementisreturnedtothesendingsystem. Step2isthestepwheretheimplicitidentityresolutionoccurs. ThenewerQBPstylequeryallowsidentityresolutiontobeseparatedfromrequestfor content.Thisisaccomplishedusingatwostepapproach.ItmirrorstheflowoftheVXQ whenlowerconfidencecandidatesarefoundandreturned.Oneindustrystandardfor accomplishingthistwostepapproachisthePatientDemographicQuery(profilebyIHE). ThisGuideallowseitherexactreplicationoftheVXQ/VXX/VXRapproachoratwostep approach.Thetwostepprocessaccomplishesthesamegoalastheoldprocess,but separatestherequestforimmunizationhistoryandtherequestforidentityresolution. Thetwostepapproachtakestheresultsoftheselectionfromtheidentityresolution andrequeststheimmunizationhistoryfortheselectedperson.Notethatthistwostep approachalsofacilitatesinteractionwithaMasterPatientindex(MPI). ThisGuideandAppendixdoesNOTprescribethesearchmethods,sotheseshouldbe describedinalocalprofileorimplementationguide. Inaddition,thisguidedoesnotdefinethemeaningofexactmatches.Thisneedstobe specifiedlocally. UsingQBPquerytoreplicateVXQ/VXX/VXR Thediagramforthenewqueryisverysimilartothepreviousdiagram.Theonlyreal differencesarethemessagesused.InplaceoftheVXQ,aRequestImmunizationHistory query(QBP^Q11^QBP_Q11)issent.IthasanMSH21,profileidofZ34^CDCPHINVS.In placeofaVXX,aReturnCandidateListresponseisreturned(profileidof Z31^CDCPHINVS).InplaceofaVXR,aReturnImmunizationHistoryresponseis returned(profileidofZ32^CDCPHINVS).

Figure 9--Request Immunization History
1. TheprocessforsendingaqueryrequestinganImmunizationhistorybeginswith thesendingsystembuildingthemessage. 2. Thesendingsystemconnectstothereceivingsystemandsendsthequery message. 3. Thereceivingsystemacceptsthemessage. 4. Thereceivingsystemparsesthemessageandvalidates. a. DetermineifmessagemeetsHL7rules b. Validatebasedonlocalbusinessrules 54

54
The process for responding is documented below.
5. Seekmatchingclientinreceiverdatabase 55 a. Nomatchisfound b. Exactlyonematchisfound. c. Oneormoreinexactmatchesandlessthanmaximumplus1allowed 56 matchesfound. d. Morethanthemaximumallowedmatchesfound. e. Oneormoreclientsarefound,buttheydonotwanttheirrecordsshared. 6. Thereceivingsystemresponds(seebelow). Whenaclientisdoesnotwanthis/herdatasharedandisfound,localbusinessrules needtobeapplied.Forinstance,someapplicationsmaybehaveasiftheclientrecord doesnotexistinthesystem.Thatis,itwouldrespondwithanorecordsfound message.Theexceptiontothiswouldbeiftherequestingproviderweretheonewho settheprotectionindicator.Inthiscase,thepersonmaybeacandidatethatis returned.Anotherresponsemightbetosendlimitedinformationnotifyingthe requestingsystemthatthepersonexists,butwantshis/herrecordsprotected. Thesendingsystemmustdealwiththereturnedmessages.Whileitisoutsidethescope ofthisimplementationguide,therearesomelogicalactions.Theseactionsshouldbe documentedlocally.Thefollowingindicatesomeofthepossibilities.Thelistisneither prescriptivenorcomplete. Onecandidateimmunizationhistoryisreturned. o Userreviewsandaccepts o Userreviewsandrejects o Requestingsystemacceptsandmarksforreview. Alistofcandidatesarereturned o Userreviewsandselectsone NewQBPissent usingtheidentifyinginformationfromtheRSP list o Userreviewsandrejectsall Usercreate sanewquerywithmoreordifferentinformation o Requestingsystemacceptsandstoresthelistforlaterreview. ThefollowingisanexamplequeryusingtheQBP^Q11queryprofilespecifiedinthe ImplementationGuide.
MSH|^~\&|||||||QBP^Q11^QBP_Q11|793543|P|2.5.1|||||||||Z34^CDCPHINVS <CR> QPD| Z34^Request Immunization History^CDCPHINVS |37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050512|M|10 East Main
Each case will be detailed below. Note that this is an area that should clearly be documented by each system in a local profile or implementation guide. 56 This maximum may be set by the sending system and may be determined by the receiving system. The maximum will be the smaller of the two.
55
St^^Myfaircity^GA^^^L<CR> RCP|I|5^RD^HL70126|R^real-time^HL70394<CR>
ThisqueryisbeingsentfromasystemwithanamespaceidentifierofMYEHR.Itis requestinganimmunizationhistoryforapersonnamedBobbieQChild.Hismothers maidennamewasSuzyQue.Hewasborn5/12/2005andlivesat10EastMainSt, Myfaircity,Georgia.HismedicalrecordnumberwithMYEHRis12345.Themostrecords thattherequestingsystemwantsreturnediflowerconfidencecandidatesarereturned is5.Processingisexpectedtobeimmediate. LocalimplementationswillspecifywhichfieldsarerequiredintheQPD.Allfieldshavea usageofRE(required,butmaybeempty).Thismeansthatsendingsystemsmay populateanyorallofthesefields.Receivingsystemsmustacceptvaluesinanyofthese fields,butmayspecifywhicharerequiredandwhichwillbeignored. ReturningalistofcandidateclientsinresponsetoQBP^Q11query WhenasystemreceivesaQBP^Q11RequestforImmunizationHistoryquery,itmayfind oneormore,lowerconfidencecandidates.InthiscaseitreturnsanRSPthatcontainsa listofthesecandidates.ItincludesallpertinentinformationinPID,NK1andPD1 segments.Ifthenumberofcandidatesisgreaterthanthemaximumnumberrequested bythequeryingsystemorgreaterthanthemaximumnumbertherespondingsystem allowstobereturned,thenanerroracknowledgmentwillbesent.(Seebelow) NotethatPID1,SetId,isrequiredwhenreturningalistofPID. ThefollowingexampleRSPmessageillustratesthecasewhen2candidateshavebeen foundbytherespondingsystem.Allknowninformationforeachcandidatethatcanbe includedinPID,NK1andPD1segmentsisreturned.Weassumethatthemedicalrecord numbersentinthequeryisnotknowntotherespondingsystem.Ifitwere,itisunlikely thattherespondingsystemwouldfindlowerconfidencecandidates. Theactuallogicusedtofindthecandidatesisnotspecifiedbythisdocument.Itmaybe assimpleasexactstringanddatematchingorascomplexasaprobabilisticsearch algorithm.
MSH|^~\&|SOME_SYSTEM|A_Clinic|MYIIS|MyStateIIS|20091105||RSP^K11^RSP_K11|37374859|P|2.5.1|||||||||Z31^CDC PHINVS<CR> MSA|AA|793543<CR> QAK|37374859|AA<CR> QPD| Z34^Request Immunization History^CDCPHINVS |37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050512|M|10 East Main St^^Myfaircity^GA^^^L<CR PID|1||99445566^^^MYStateIIS^SR||Child^Robert^^^^^L||20050512|M<CR> NK1||Child^Susan|MTH^Mother^HL70063|^^Myfaircity^GA<CR> Appendix B 30 HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.2) Last Updated on 1/25/2011
PID|2||123456^^^MYStateIIS^SR||Child^Robert^^^^^L||20050512|M<CR>
This response includes 2 candidates that must be reviewed by the person requesting records. If they select a specific client and repeat the Request Immunization History query with the refined information, they should receive a response that includes the complete immunization history from the IIS. Note the use of PID-1, set id. ReturninganimmunizationhistoryinresponsetoaRequestforImmunizationHistory query WhentheRequestImmunizationHistoryqueryfindsonehighconfidencematch,the matchingclientsimmunizationhistoryisreturnedintheresponse.Thefollowing examplemessageshowsasimpleresponse.Notethatthisquerycouldhavebeena secondaryquerythatoccurredafterpreliminaryidentityresolutionoraprimaryquery withsufficientdemographicdatatopermitmatching.
MSH||MYIIS|MyStateIIS||MYEHR|20091130||RSP^K11^RSP_K11|7731029|P|2.5.1|||||||||Z32^CDCPHINVS<CR> MSA|AA|793543<CR> QAK|37374859|OK| Z34^Request Immunization History^CDCPHINVS <CR> QPD| Z34^Request Immunization History^CDCPHINVS |37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050512|M|10 East Main St^^Myfaircity^GA^^^L<CR PID|1||123456^^^MYEHR^MR||Child^Robert^Quenton^^^^L|Que^Suzy^^^^^M|||||10 East Main St^^Myfaircity^GA<CR> PD1||||||||||||N|20091130<CR> NK1|1|Child^Suzy^^^^^L|MTH^Mother^HL70063<CR> PV1||R||||||||||||||||||V03^20091130<CR> ORC|RE||142324567^YOUR_EHR|||||||^Shotgiver^Fred||Ôrderwriter^Sally^^^^^^^^^^^^^^^^^^MD<CR> RXA|0|1|20050725||03^MMR^HL70292|0.5|ML^ÎSO+||^New Immunization Record^NIP001<CR> RXR|SC^^HL70162<CR>
NotethattheresponsereturnedthemedicalrecordnumberfromtheMYEHRsystem.It couldalsohavereturnedtheIISid.Thisisapolicydecisionsetlocally. AcknowledgingaQuerythatfindsnocandidateclients Awellformedquerymayfindnomatchingcandidates.Thisisnotanerror,butshould beacknowledgedinaresponsemessage.Thefollowingexamplemessageshowshow thismaybedone.NotethattheRequestImmunizationHistoryresponsegrammar indicatesthatMSH,MSA,QAKandQPDarerequiredsegments.
QAK2indicatesthatnodatawerefoundthatmatchedthequeryparameters.
MSA|AE|793543<CR> QAK|37374859|NF|Z343^request Immunization history^HL70471<CR> QPD| Z34^Request Immunization History^CDCPHINVS |37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050512|M|10 East Main St^^Myfaircity^GA^^^L<CR>
MSH||MYIIS|MyStateIIS||MYEHR|20091130||RSP^K11^RSP_K11|7731029|P|2.5.1|||||||||Z34^Request Immunization History^CDCPHINVS<CR>
Acknowledgingaquerythatfindsmorecandidatesthanrequested Thesendingsystemsetsanupperlimitonthenumberofcandidatesitwillacceptin responsetoaqueryinRCP2.Itexpectsthatarespondingsystemwillsendnomore candidatesthatthisnumber.Inaddition,therespondingsystemmayhaveanupper limitonthenumberofcandidatesthatitwillreturn.Thisnumbermaybelowerthanthe requestingsystem.Itwilltrumptherequestingsystemupperlimit.Ineithercase,ifthe respondingsystemfindsmorecandidatesthantheupperlimit,thenitrespondswith andacknowledgementindicatingthattoomanycandidateswerefound.QAK2 indicatesthatthereweretoomanycandidatesfoundthatmatchedthequery parameters.
MSH||MYIIS|MyStateIIS||MYEHR|20091130||RSP^K11^RSP_K11|7731029|P|2.5.1|||||||||Z34^Request Immunization History^CDCPHINVS <CR> MSA|AE|793543<CR> QAK|37374859|TF|Z343^request Immunization history^CDCPHINVS<CR> QPD| Z34^Request Immunization History^CDCPHINVS |37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050512|M|10 East Main St^^Myfaircity^GA^^^L<CR>
UsingaTwostepprocesstorequestanimmunizationhistory TheIHEprofiledefines2queriesforobtaininganIDofinterest.Onequeryrequestsan idbasedonthedemographicinformationincludedinthequery(PDQ,usingthe PediatricDemographicprofile).Whenamatchisfound,itreturnstherelevantidand demographicinformation.Theotherqueryseeksanidforapersonfromoneregistered providerbasedontheidfromanotherregisteredprovider(PIX). TheuseoftheIHEPatientIdentificationCrossReferencing(PIX)and PatientDemographicQuery(PDQ)transactionsisanalternativeapproach whichseparatesretrieval/updateofapatientidentifierand retrieval/updateofimmunizationdataintotwomessagingtransactions. APatientDemographicSuppliermaybeaMasterPersonIndexorothersourceof patientdemographicandidentificationinformation.WhilewewillfocusonanMPI below,anyPatientDemographicSuppliermaybesubstituted. AMasterPersonIndexisadatabasethatcontainsdemographicandlocating informationofregisteredpersonsandassociateseachpersonwiththeidentifiersforthe personfromeachoftheparticipatingsystems.Thisallowsonesystemtorequestthe identifierforapersonthatwasassignedbyanothersystem.Thisidmaybeusedto requestdatafromthatsecondsystemandassuresapositivematch. SystemsthatparticipateinanMPIshouldregistereachpersontheyareinterestedin withtheMPI.AnexcellentprofileformaintainingandinteractingwithanMPIhasbeen publishedbythegroup,IntegratingtheHealthcareEnterprise(IHE).Thatprofilewillnot bereplicatedhere.However,theprocessforrequestingpersonalidentifieroutlined belowisbasedonthatprofile. AddingapatientrecordtoanMPIisdonebyaPIXtransactionusinganADT message.ThismethodmaybeusedbyanEHRorbyanIIS,orboth,toadda patientidentifiertoanMPI.ThePIXprofile,describedintheIHETechnicalFramework VolumeI,includesspecifictransactionsthatdescribethesegmentsandfieldstobe used.TheseADTbasedtransactionsaredescribedintheIHETechnicalFramework VolumeII.ThestandardtransactionusedbyPIXisITI8,whichusesanHL7V2.3.1ADT. ThePediatricDemographicsOption,describedatthiswritinginasupplementtoPIX andPDQ,ispreferredforinteractionswithMPIsmanagingIISdata.Theuseofthe PediatricDemographicsOptionaddsITI30,whichusesanHL7V2.5ADT. OnceapersonhasbeenregisteredwiththeMPI,aPIXQuerymaybeusedtoretrieve thecrossreferencedIISidentifier(ifany).
ThefollowingdiagramillustratestheuseofthePIXquerytogetapreregisteredpatient identifier.Thisrequiresthatthecrossreferencedidentifiersareregisteredusingthe ADTmessage.
Notethatthisinteractionissimplified.Theinitiatingsystemsendsarequestfora patientidentifier.TherequestincludesoneidentifierinaPID3.Theidentitysupplier looksforamatchingidentifierofinterestandreturnsitalongwiththepatientname (PID5).Thisinformationisincludedintherequestimmunizationhistoryquery (QBP^Q11).Assumingthattheidentifierusedistheoneintheimmunizationhistory supplier,thereshouldbeaonetoonematch. IftheEHRwishestoretrievetheIISidwithoutpreviouslyregisteringthepatientwith theMPI,orifitwishestoquerytheMPIbydemographicsforsomeotherreason,itmay useaPatientDemographicsQuerytodoso. ThefollowingdiagramillustratestheuseofPDQtoobtainanidandhowthiswouldbe usedtorequestanimmunizationrecord.TherecordseekerusesaPatientDemographic Query(PDQ)toaMasterPersonIndex(MPI),requestingtheidentifiersforthepersonof interest.TheMPIfindsthepersonofinterestandreturnsthedemographicinformation andidentifiers.Therecordseekersystemusesthisinformationtocreatearequestfor immunizationhistory,whichitsendstotherecordsource.Therecordsourceusesthis informationtofindtheimmunizationhistoryforthepersonofinterest.
Notethatthisinteractionissimplified.Theclientofinterestwouldbeselectedandthat clientsinformationwouldpopulatethequeryrequestinganimmunizationhistory.To beassuredofsuccess,therecordsourcesystemwouldneedtohaveregisteredthe personintheMPI.Inthatwaythepersonidintherecordsourcewouldbeavailablein theMPI. ThediagramsillustratingthePIXQueryandPatientDemographicsQuery(PDQ) approachessharesimilarflowtotheoriginalVXQmessage.PIXQueryfollowedbya RequestImmunizationHistoryusingtheretrievedidentifierissimilartoaVXQ/VXR. PDQfollowedbyanRequestImmunizationHistoryreplicatesaVXQ/VXXand VXQ/VXR. 57 Thefollowingillustratesoneoftheabovedescribedmessages,thePatient DemographicsQuery.Forexamplesofothermessages,IHEdocumentationshouldbe consulted.
MSH|^~\&| MYIIS|MyStateIIS|SOME_SYSTEM|A_Clinic |20091105||QBP^Q22^ ||P|2.5.1||||||||| <CR> QPD|ÎHE PDQ Query^ |37374859|@PID.3.1^123456~@PID.3.4^MYEHR~@PID.3.5^MR~@PID.5.1.1^Child~@PID.5.2^Bobbie~@PID.5.3^Q
57
It is possible that even with the two-step process, an exact match may not be found for the record of interest. This is especially true if the source of identity resolution is not exactly in synch with the source of the immunization history. Local rules should dictate the response to this situation.
~@PID.6.1.1^Que~@PID.6.2^Suzy ~@PID.7^20050512~@PID.8^M~@PID.11.1.1^10 East Main St^~@PID.11.3^Myfaircity~@PID.11.4^GA <CR> RCP|I|5^RD^HL70126|R^real-time^HL70394<CR>
NotethattheintentoftheQuantityLimitedRequestdiffersfromitsuseintheRequest ImmunizationHistoryquery.Hereitmeanssendmebatchesof5recordsuntilyouhave sentthemall.IntheRequestImmunizationHistoryqueryitmeansreturnalistofupto fiveclients,butifyoufindmore,thensendmeanerrorindicatingtoomanyrecords found. ReturningalistofcandidateclientsinresponsetoPDQquery TheresponsetoaPDQqueryisverysimilartothatofaRequestforImmunization Historyquerywhichfindslowerconfidencematches.Themostsignificantdifferences include: NoNK1isreturned. MPIs implementing the Pediatric Demographics Option use Mother's Maiden name in the PID segment to provide equivalent value in patient record matching. Ifmorethanthemaximumrecordsarefoundtheyarereturnedinbatchesofup tothemaximumrecordsspecifiedinthequery PotentialuseofDSCsegmenttosupportreturnofbatchesofrecords Thefollowingexampleshowsareturnsimilartotheresponsemessagereturnedbythe requestforimmunizationhistoryquery(above).Notethatinbothcases,theresponse messagereturnsallinformationthatitknowsabouteachclientinthesegments requiredforeachresponse.
MSH|^~\&|SOME_SYSTEM|A_Clinic|MYIIS|MyStateIIS|20091105||RSP^K22^ |37374859|P|2.5.1||||||||| <CR> MSA|AA|793543<CR> QAK|37374859|AA<CR> QPD|ÎHE PDQ Query^ |37374859|@PID.3^123456^^^MYEHR^MR~@PID.5^Child^Bobbie^Q^^^^L~PID.6^Que^Suzy^^^^^M~@PID.7^20050512 @PID.8^M~@PID.11^10 East Main St^^Myfaircity^GA^^^L~@PID.18^<CR> PID|1||99445566^^^MYStateIIS^SR||Child^Robert^^^^^L||20050512|M<CR> PID|2||123456^^^MYStateIIS^SR||Child^Robert^^^^^L||20050512|M<CR>
UsingPIXinpreparationforreportinganImmunizationRecordtoanIIS InthecasewhereanIISparticipatesinanMPI,theEHRmayuseaPIXQuerytoretrieve theIISidentifierfromtheMPIpriortosendinganimmunizationrecordtotheIIS. InthecasewheretheIISidentifierisreturnedbytheMPI,theVXUmessagesenttothe IISmaycontaintheIISID

Ausermaybelievethatacandidatedoesexistandmaychoosetorefinethequery parametersandrequery. Receivingsystemdeterminesthatmessagehaserrors HL7MessageRuleErrors TherearetwoclassesoferrorrelatedtoHL7messagerules.Thefirstiswhenamessage iswellformed,butthequeryhaserrorsincontentorformat.Thesecondoccurswhen themessageismalformedandcannotbeparsedbytherecipient. Thefollowingexamplesillustratehoweachisreported. MalformedQuery: InitiatingQuery:
QPD|Z34^Request Immunization History^CDCPHINVS||123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050512|M|10 East Main St^^Myfaircity^GA^^^L<CR>
MSH|^~\&|||||||QBP^Q11^QBP_Q11|793543|P|2.5.1|||||||||Z34^CDCPHINVS. <CR>
MSH|^~\&|MYIIS|MyStateIIS||MYEHR|20091130||RSP^K11^RSP_K11|7731029|P|2.5.1||||||||| Z34^Request Immunization History^CDCPHINVS <CR> MSA|AE|7731029<CR> ERR||QPD^1^2|101^required field missing^HL70357|E<CR> QAK||AE|Z34^request Immunization history^CDCPHINVS<CR> QPD| Z34^Request Immunization History^CDCPHINVS ||123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050512|M|10 East Main St^^Myfaircity^GA^^^L<CR>
NotethatonlytheMSHandQPDsegmentswillbedisplayedabove.TheQPDdoesnot havedatainarequiredfield,theQueryTagfield(QPD2).
NotethatQAK1Querytagisemptyinthiscase,becauseitwasmissingintheinitiating query. Malformedmessage Whenamalformedmessageisreceived,theresponseisanACKwithARintheMSA1 (AcknowledgementCode)

MSH|^~\&|MYIIS|MyStateIIS||MYEHR|20091130||ACK||P <CR> MSA|AR|<CR>
This message indicates that the application rejected the message.

ReceivingSystemBusinessRuleErrors FatalError: Datesentinarequiredfieldisnotlegitimate(February30,2009) Nonfatalerror: NoMatchIsFound Ifnomatchisfound,thenthereceivingsystemsendsaresponsethatindicatesthatthe messagewasacceptedandfoundnodata.Notethatthismightoccurifoneclientwas found,butdoesnotwanthis/herdatasharedwithadifferentprovider.

MSH|^~\&|MYIIS|MyStateIIS||MYEHR|20091130||RSP^K11^RSP_K11|7731029|P|2.5.1|||||||||| MSA|AA|7731029<CR> QAK|37374859|NF|Z343^request Immunization history^HL70471<CR>
QPD|Z34^Request Immunization History^HL70471|37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050512|M|10 East Main St^^Myfaircity^GA^^^L<CR

Hl7guide 02 2011

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Hl7guide 02 2011

Enviado por

Direitos autorais:

Formatos disponíveis

HL7Version2.5.

AppendixBMessageexamples Thisappendixwillshowdetailedexamplesofhowtoimplementthemessagesspecified inthebodyoftheImplementationGuide.

Figure 1-1 Simple Use Case Diagram

Figure 1-2-Simple Sequence Diagram

Figure 1-3 Simple Activity Diagram

Notethatthefocusofthisguideisontheformatandgrammarofthemessages betweensystems.Theactivitiesshownwithinasystemareintendedtoputthemessage incontextandtohighlightthelocalresponsibilitiesforsuccessfulmessaging.

Chapter 2: Actors, Goals and Messaging Transactions

2. Actors, Goals, and Messaging Transactions

Chapter 2: Actors, Goals and Messaging Transactions

Actor Immunization InformationSystem (IIS)

Houseapersonselectronic healthrecord Makeapersonsrecord availabletoauthorized persons

Chapter 2: Actors, Goals and Messaging Transactions

Responsibility Providedecisionsupportfor clinicaldecisions.

MasterPersonIndex orotheridentity broker.

Chapter 2: Actors, Goals and Messaging Transactions

Chapter 2: Actors, Goals and Messaging Transactions

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

Chapter 2: Actors, Goals and Messaging Transactions

Chapter 2: Actors, Goals and Messaging Transactions

Requesting an Immunization History Using Implicit Identity Resolution

Chapter 2: Actors, Goals and Messaging Transactions

Chapter 2: Actors, Goals and Messaging Transactions

Chapter 2: Actors, Goals and Messaging Transactions

UseCase6SendDemographicData Goal:Tosenddemographicdataaboutaperson.Itmaybeanupdateoranewrecord. Thisusecasedoesnothaveresponsibilityfortheprocessingofthemessage.The messagewillincludeanindicationoftheexpected/requestedacknowledgement.

ThestandardmessagesthatmaybeusedforcarryingdemographicdataareVXUand ADT. Precondition:Auserorotheractorrequeststhatthesendingsystemsenddemographic data.

SeeFigure7. UseCase7AcceptDemographicData Goal:Toacceptdemographicdataaboutaperson.Itmaybeanupdateoranewrecord. Thisusecasedoesnothaveresponsibilityfortheprocessingofthemessage.The messagewillincludeanindicationoftheexpected/requestedacknowledgement.

Chapter 2: Actors, Goals and Messaging Transactions

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

Chapter 2: Actors, Goals and Messaging Transactions

Chapter 2: Actors, Goals and Messaging Transactions

Chapter 2: Actors, Goals and Messaging Transactions

Figure 2-9--VXU Process Model

Chapter 3: HL7 Messaging Infrastructure

3. HL7 Messaging Infrastructure

Chapter 3: HL7 Messaging Infrastructure

Component:Acomponentisoneofalogicalgroupingofitemsthatcomprisethe contentsofacodedorcompositefield.Withinafieldhavingseveralcomponents,notall componentsarerequiredtobevalued. Example:RXA5administeredcodeiscomposedof6components.

Chapter 3: HL7 Messaging Infrastructure

Chapter 3: HL7 Messaging Infrastructure

ImmediateOutcome Messagerejected. Outofsequencesegment ignored. Segmentisignored Repeatedsegmentis ignored.Firstsegmentis processednormally. Messageisrejected.

Messageisnotrejected becauseofthiserror.Error messagereturned. 29

Chapter 3: HL7 Messaging Infrastructure

Condition Requiredfieldisnot present.

ImmediateOutcome Segmentis ignored/rejected.

Incomingdatavalueisnot Incomingdataaretreated inthelistofexpected asempty. valuesforafieldthatis constrainedtoalistof values. Notethatallerrorsinprocessingamessageshouldbecommunicatedbacktothe sendingsystemunlesstheinitiatingsystemhasindicatedthatnoresponseisdesired.

Chapter 3: HL7 Messaging Infrastructure

Chapter 3: HL7 Messaging Infrastructure

Chapter 3: HL7 Messaging Infrastructure

Interpretation Conditionalbut maybeempty

Chapter 3: HL7 Messaging Infrastructure

Comment errorifitreceivesanunsupportedelement.Any profilebasedonthisGuideshouldnotspecifyuse ofanelementthatisnotsupportedinthisGuide.

Chapter 3: HL7 Messaging Infrastructure

Comment Thesegmentisnotsupported.Sending applicationsshouldnotsendthiselement. Receivingapplicationsshouldignorethiselement ifpresent.AnyprofilebasedonthisGuideshould notspecifyuseofanelementthatisnot supportedinthisGuide.

Chapter 3: HL7 Messaging Infrastructure

Chapter 3: HL7 Messaging Infrastructure

Chapter 4: HL7 Data Types

4. HL7 Data Types

CECodedElement(mostuses) Definition:Thisdatatypetransmitscodesandthetextassociatedwiththecode. ThefollowingspecificationsapplytoallusesofCEdatatypeEXCEPTRXA9,Administration Notes.Thatfieldmayusethisspecificationorthespecificationthatfollowsthissection.

Text Name of Coding Alternate Identifier

Alternate Text Name of Alternate

Name of Coding System (ID)

Alternate Identifier (ST)

Alternate Text (ST)