Washington State Immunization Information System. HL7 Interface Project Guide

Transcription

1 Washington State Immunization Information System HL7 Interface Project Guide Version 1.4 August 31, 2014 DOH August 2014 If you have a disability and need this document in a different format, please call (TDD/TTY )

2 Table of Contents I. Introduction II. III. IV. Getting Started HL7 Messaging Notes Special Requirements for Washington State V. Meaningful Use VI. Document Change History Appendices: Appendix A HL7 Precertification Checklist Appendix B HL7 Project Phases & Timeline Appendix C Required Fields (Segments & Components) Appendix D Quick Tips for a Successful Interface 2

3 I. Introduction Tools to Build Your HL7 Message Welcome to the Washington State Immunization Information System s (IIS) HL7 Interface Project. Our staff is ready and available to work with Washington State health care providers enrolled in the IIS, and their Electronic Health Record (EHR) vendors or in-house IT staff. The registry s goal is to build an HL7 bidirectional real-time interface exchanging all possible vaccination data elements. If that is not possible up front, an interface must initially meet basic requirements and plan to work toward a more complete interface in the future. The IIS does focus on Meaningful Use (MU) requirements and strongly encourages all data elements required for MU certification to be included in an interface. Washington s IIS software is an IWeb software application developed and supported by Scientific Technologies Corporation or STC ( The HL7 interface supports the CDC standard immunization messages as described in the CDC HL7 Implementation Guide for Immunization Messages. The interface currently supports HL7 version 2.3.1and HL7 version A number of ambiguities existed in 2.3.1, and these have been clarified in Those improvements are in place in IWeb. The IIS will continue to support HL7 version and does not require an interface to be upgraded to at this time, unless a provider plans to attest for Meaningful Use Stage 2. Please note that the IIS does not have the resources to build or develop your HL7 message format. A number of tools are available to help you in this development. If you have not already received them, our staff can provide these tools to support your work: CDC HL7 Specification Available online: PHIN Message Framework (parsing tool) - STC HL7 Specification Available via attachment from the IIS. The current version is STC HL7 Local Implementation Guide Available via attachment from the IIS. STC Secure Transport Specification Available via attachment HL7 Precertification Checklist See Appendix A of this document HL7 Project Phases and Timeline See Appendix B of this document Required and Recommended Data Segment Table See Appendix C of this document Quick Tips for a Successful Interface See Appendix D of this document 3

4 Please Note: The IIS expects to receive HL7 messages formatted according to the CDC specifications. All available segment components are expected in the messages, even if the components are empty or null. Regard all components as required for inclusion in the message, even if you do not intend to send data in the component. Those components that must contain data are listed in Appendix C as Required. If a provider opts to send a strongly recommended data item, that item must be sent correctly and becomes required data, subject to the data quality threshold. Please keep in mind that EHRs and HL7 interfaces represent a rapidly changing environment. There will be updates and changes to the IIS interface requirements as the Centers for Medicaid and Medicare (CMS) criteria for Meaningful Use (MU) move forward, as the Centers for Disease Control and Prevention (CDC) make changes to their HL7 specifications and as requirements specific to the federal entitlement, Vaccines for Children (VFC) Program, occur. IIS staff is available to support your work and answer any questions related to HL7 interface projects. The IIS had a lengthy waiting list for interface project work. If the IIS has completed one interface with a provider and the provider changes EHRs, the provider will go on the waiting list for a new HL7 project. The IIS is not able to immediately offer interface work to a provider based on an EHR change. The IIS will work to reduce the wait time. If a provider is unable to continuously monitor an interface once it has been moved to Production and the interface is not performing, the WA State Department of Health reserves the right to terminate the interface. We look forward to working with you. The Washington State Immunization Information System HL7 Interface Team Contact information: Washington State Immunization Information System formerly Child Profile Immunization Registry th Avenue, Suite 900 Seattle, WA Phone: 800/ iishelpdesk@kingcounty.gov 4

5 II. Getting Started The first step in the HL7 Project process is to contact the IIS, confirm the Washington State health care provider is enrolled in the IIS, and schedule a conference call. Please refer to Appendix A and review the HL7 Precertification Checklist. This is not a certification for Meaningful Use (MU). This is an initial discovery meeting to discuss and clarify the process for setting up or enhancing an HL7 interface with the IIS. You will see a number of important points on the checklist, and the conference call is a time to respond to questions on the checklist, bring up additional questions or concerns with the proposed interface, review the proposed timeline for the project (See Appendix B), and clarify whether the project is ready to move forward or if the project requires additional preparation before moving to establish connectivity and begin the message testing process. Important issues to review may include but not be limited to: Provider/vendor ability to meet the IIS s required message segments Planned transport method, including any security concerns Specific functionality and ability of the interface to complete specific actions such as decrementing inventory Clarification regarding the interface the provider has purchased from the vendor, and the implications (cost to provider) of enhancing the interface in the future or changing EHRs Criteria an interface must meet before the interface is approved by the IIS to move from the IIS s Development environment to the live Production system Note: It is key that the provider s IT staff and clinical staff be involved in the entire interface process and be aware of exactly what data is included in the interface and what data is not included in the interface. IIS staff work diligently to avoid surprises when an interface goes live and to deliver an interface that provides satisfaction for both IT and clinical staff. Moving an interface to the IIS s Production system is not the end of the process. An immunization IIS interface requires ongoing, often daily, monitoring and response by the provider. Throughout the Getting Started phase, interface roles will be determined, and it is helpful to have both the IT staff and clinical staff involvement to ensure all needs are met. These roles and responsibilities will also continue through the interface testing process and continue post go live for on-going monitoring and effective inventory management. 5

6 III. HL7 Messaging Notes The IIS s software: Accepts the following patient update messages: VXU Responds to immunization record query messages: VXQ, QBP/RSP. Queries external registries by sending immunization record query messages: VXQ. Sends batch updates to external registries: VXU. The following is a list of the segments required for the IIS interface. Additional information can be found in the HL7 Precertification Checklist (Appendix A) and Required Data Elements (Appendix C). A sample message follows that includes the segments listed in the table below. Different vendors will customize items such as the MSH header. The IIS does not recommend copying and pasting from the example. Rather, use the example as a template to develop your own messages. Segment Notes MSH PID NK1-3 ORC PD1-3 PV1-20 Header, including critical information about the medical organization (MSH-11 is always P) Basic patient identifying information Next of kin: only GRD = Guardian, MTH = Mother, FTH = Father, and PAR = Parent are recognized and accepted values. A null value defaults to GRD. Other codes are ignored and data submitted does not populate the IIS record. Common order segment. Accepted but optional. Name and ID for the clinic location, which populates the demographic screen in the IIS Literally financial class, includes the VFC information to populate the demographic record in the IIS. Links to required annual clinic report to WA State on VFC status of patients seen in a calendar year. Now required in an interface. 6

7 Segment Notes RXA RXR OBX Vaccine information, including administration date, vaccine code, lot number, manufacturer code, new (00) or historical (01) notes, action codes (add & delete). Anatomical site and route of administration Documents public or private vaccine supply source, VIS presentation and version dates, Contraindications. OBX for VFC status is required for all age patients. Sample Messages One source for sample VXU messages is the NIST Immunization Messaging, HL7 V2 Validation Tool, Meaningful Use 2014 Certification Testing - NIST offers seven test scenarios which you can load and review. Please note the examples below are from the NIST web site, but additional Washington State required segments have been added to meet the state s needs. Child Immunization Record - VXU MSH ^~\& Test EHR Application X68 NIST Test Iz Reg VXU^V04^VXU_V04 NIST- IZ P AL ER PID 1 D ^^^NIST MPI^MR Snow^Madelynn^Ainsley^^^^L Lam^Morgan F ^Native Hawaiian or Other Pacific Islander^HL Prescott Street Ave^^Warwick^MA^02452^USA^L ^PRN^PH^^^657^ ^non Hispanic or Latino^CDCREC PD1 CLINIC WEST^^CLWE 02^Reminder/Recall - any method^hl70215 A NK1 1 Lam^Morgan^^^^^L MTH^Mother^HL Prescott Street Ave^^Warwick^MA^02452^USA^L ^PRN^PH^^^657^ PV1 R V10^ ORC RE IZ ^NDA I-23432^Burden^Donna^A^^^^^NIST-AA ^RADON^NICHOLAS^^^^^^NIST-AA-1^L RXA ^Influenza, seasonal, injectable, preservative free^cvx 0.5 ml^milliliter [SI Volume Units]^UCUM 00^New immunization record^nip ^Lemon^Mike^A^^^^^NIST-AA- 1 ^^^X68 Z0860BB CSL^CSL Behring^MVX CP A RXR IM^Intramuscular^HL70162 LA^Left Arm^HL70163 OBX 1 CE ^Vaccine funding program eligibility category^ln 1 V05^VFC eligible - Federally Qualified Health Center Patient (under-insured)^hl70064 F VXC40^Eligibility captured at the immunization level^cdcphinvs OBX 2 CE ^vaccine type^ln 2 88^Influenza, unspecified formulation^cvx F OBX 3 TS ^Date vaccine information statement published^ln F OBX 4 TS ^Date vaccine information statement presented^ln F 7

8 Chicken Pox History Record VXU MSH ^~\& Test EHR Application X68 NIST Test Iz Reg VXU^V04^VXU_V04 NIST- IZ P AL ER PID 1 MR-11891^^^NIST MPI^MR Wolfe^Aron^^^^^L M ORC RE 9999^CDC RXA ^No vaccine administered^cvx 999 NA OBX 1 CE ^Disease with presumed immunity^ln ^Varicella infection^sct F Adult Immunization Record VXU MSH ^~\& Test EHR Application X68 NIST Test Iz Reg VXU^V04^VXU_V04 NIST- IZ P AL ER PID 1 MR-76732^^^NIST MPI^MR~ ^^^MAA^SS Vally^Nitika^^^^^L F ^~^NET^^nvally@fastmail.com PD1 CLINIC WEST^^CLWE PV1 R V01 ORC RE IZ ^NDA 57422^RADON^NICHOLAS^^^^^^NDA^L RXA ^Hep A^CVX 1 ml^milliliter [SI Volume Units]^UCUM 00^New immunization record^nip001 ^^^F28 I90FV MSD^Merck and Co^MVX CP A RXR IM^Intramuscular^HL70162 RD^Right Arm^HL70163 OBX 1 CE ^Vaccine funding program eligibility category^ln 1 V01^Not VFC eligible^hl70064 F VXC40^Eligibility captured at the immunization level^cdcphinvs OBX 2 TS ^Date vaccine information statement published^ln F OBX 3 CE ^vaccine type^ln 2 85^Hepatitis A^CVX F OBX 4 TS ^Date vaccine information statement presented^ln F Acknowledgement (ACK) Message The IIS sets your HL7 account to Always Acknowledge every message received. An ACK message will be sent to your account. If clinic staff contact the IIS and state that HL7 messages were sent to the IIS but they didn t transfer, IIS staff refer the caller to their IT staff and ask if an ACK was received. Query Response The IIS will continue to accept VXQ (Vaccination Query) messages in HL interfaces. If a provider is submitting HL , a QBP/RSP query message is expected. A query of the IIS would result in one of three possible responses: Query Acknowledgement No Match (QCK) Query Acknowledgment Possible Match (VXX) returns maximum number requested and/or allowed. No immunization history returned. Query Acknowledgement Exact Match (VXR) Immunization history returned. 8

9 QBP/RSP Consult the CDC s Version HL Implementation Guide for Immunization Messaging details on the Query By Parameter - The response differs from the QCK, VXX, and VXR. Outcome of Query No match found Exactly one high confidence match found At least one lower confidence match is found, but <= maximum number allowed. Response Message Response indicates that message was successfully processed and that no clients matched the criteria that were sent in the query. Response includes a complete immunization history as specified in CDC s Profile, Return Immunization History. Response returns one PID with associated PD1 and NK1 segments for each potential match. No immunization history is returned. See CDC s Profile Return Candidate List. More than the maximum number allowed is found. Response indicates that the message was successfully processed, but that too many potential matches were found. The maximum number allowed is the lower of the maximum number requested and the maximum number that the receiving system will return. Message is not well formed and has fatal errors. Response indicates that the message was not successfully processed and may indicate errors. Sending an HL7 Message HL7 message files may be uploaded manually to the IIS or automatically via HTTPS. Applications that can generate a file or use TCP/IP but can t connect via HTTPS may install the 9

10 HL7 Bridge on their local server to submit data directly to IIS. The HL7 Bridge is provided free of charge and is installed on the provider s server. If the file is automated, files should be sent nightly when the IIS application is not generally in use. If the file requires manual upload on a regular basis, a staff member will need to generate a file from their application and upload it directly to the IIS server. A daily upload is recommended. At least two people in an office should be trained to do this task so that there is no interruption of data flow to the IIS. Request: When the sending application sends the IIS an HL7 message via an HTTPS POST command, it must have the following fields: USERID - Assigned by the IIS administrator. PASSWORD - Assigned by the IIS administrator. MESSAGEDATA - The HL7 message(s). HL7 messages may be submitted one at a time (one for every HTTPS request) or together as a batch. Batched messages do not require special separators or wrappers. Response: The IIS always returns responses in HL7 format (ACK). Responses are returned based on how the account is configured in the IIS. The response configurations available are Always, Never, On Error (only for those messages that are not accepted) or Determined by Message (Incoming request message indicates in the MSH segment whether to always, never or only on error). The HL7 response can indicate any one of the following: Authentication error - username and password are incorrect or account does not have permission to accept HL7 Message parsing error incoming messages do not conform to HL7 standards Message content error incoming message is missing or includes incorrect information Message processing exception incoming message has an unexpected problem Message accepted - data has been accepted and has been sent to deduplication Response to query registry responds to query with query results The IIS has a document that lists common errors reported in the HL7 Import Log. The list is available upon request from the IIS. IV. Requirements Specific to Washington State Washington State has a number of programs or circumstances that necessitate special messaging for a successful IIS interface. Vaccine Ordering/Receiving/Online Reporting Washington State is rolling out online vaccine management at the provider level for providers enrolled in the Washington State Childhood Vaccine Program who receive state- 10

11 supplied vaccine. To successfully implement online vaccine ordering, online vaccine receiving, and online vaccine usage reporting, it is now important to include specific vaccine information in HL7 messages. Vaccines for Children or VFC status is required Facility names in messages must be consistent with the facility name identified on the annual Provider Agreement completed to receive state-supplied vaccine. Current CVX/CPT coding is critical no codes set inactive by CDC or codes for unspecified vaccines are acceptable - The IIS strongly recommends that the provider subscribes to the updates available on this page from CDC. Lot number and vaccine manufacturer, utilizing the CDC MVX codes, is critical - The MVX code in a provider s IIS inventory must exactly match the MVX code in an incoming message. The vendor and provider must monitor changes to the vaccine supply, including the introduction of new vaccines and vaccine coding changes. CVX coding submitted must match the vaccine products administered at the provider s office. Current coding must be in place in HL7 messaging before the interface moves to the IIS s Production system. To help providers keep up to date on vaccine products, the IIS maintains a number of Best Choices guides on the IIS Training page - Best Choices for Pediatric/Adolescent & State-Supplied Vaccines Best Choices for Adult and Travel Vaccines Best Choices for Influenza (Flu) Vaccines Complete List of Vaccine Names and CPT/CVX Codes Universal Status for State-Supplied Vaccines Washington is a universal state, meaning that all patients under 19 years of age are eligible to receive all state-supplied vaccines, even if they are covered by private insurance that covers vaccine. While private insurance coverage is not a standard CDC VFC eligible category according to federal guidelines, it is an eligibility category in WA State. In addition, a VFC status of ineligible is required for all patients 19 years of age and older. To submit VFC status via HL7 messaging, a code of eligible or ineligible must be submitted for all patients, as shown in the table below. 11

12 VFC Code V01 V02 V03 V04 V05 VFC Status Not VFC eligible, applies to patients over 19 only and must be sent via OBX for all patients in this category. VFC eligible - Medicaid/Medicaid Managed Care VFC eligible - Uninsured VFC eligible American Indian/Alaskan Native VFC eligible Federally Qualified Health Center Patient/Underinsured V10 VFC eligible - Private/Commercial insurance, under 19 Race and Ethnic Groups CDC strongly recommends that immunization information systems (IIS) collect Race and Ethnicity data on all patient records. If possible, Race and Ethnicity data should be submitted in HL7 data. (See Appendix C). Only the current CDC values in HL7 version are acceptable. Deprecated (outdated) values will not be accepted. If you are unable to submit current values, leave the appropriate segments empty. US Race Codes Description American Indian or Alaska Native Asian Native Hawaiian or Other Pacific Islander Black or African-American White Other Race (should be avoided or very limited use; make a specific race selection when possible) <empty field> Unknown/undetermined (Avoid unless EHR defaults to Other) 12

13 US Ethnicity Codes Description Hispanic or Latino Not Hispanic or Latino <empty field> Unknown (Avoid) Privacy of Data The IIS no longer accepts or stores social security numbers. Additional privacy & security changes may occur in the future and will be communicated as those changes occur. Unverified Vaccine Data The IIS does not accept any patient or parent reported vaccine information without documentation or medical evidence to support the administration of vaccine. This is consistent with ACIP advice and the Centers for Disease Control advice. No partial vaccine dates should be accepted or defaulted to a specific date or added to the IIS. If your organization does enter patient or parent reported vaccine information, the IIS will not accept historical data in the interface. The CDC recommendation is clear for pediatric/adolescent and adult vaccines. and for adults - V. Meaningful Use (MU) This information will help providers determine if they are eligible for an interface with the Washington State Immunization Information System (IIS). General information on Meaningful Use: More information on Meaningful Use Rules and Eligibility for Incentives is online at: The Official Web Site for the Medicare and Medicaid Electronic Health Records (EHR) Incentive Programs [ Washington State's Medicaid EHR Incentive Program [ 13

14 Health care providers who give immunizations: If you want to meet the public health requirement for Meaningful Use through the exchange of immunization records with the IIS, you must: Be eligible for Meaningful Use (an Eligible Professional or Eligible Hospital per CMS guidelines [ Use EHR technology certified for the Medicare and Medicaid EHR Incentive Programs. See a list of certified EHR systems [ Give vaccines and include CVX coding for vaccines in data exchange. If you meet these requirements, review the CMS document on immunization registries ission.pdf]. Get more Meaningful Use information and support from the Washington-Idaho Regional Extension Center [ Meaningful Use Stage 1 Meaningful Use Stage 1 is a self-directed process. Visit the Washington State Department of Health s web site - acilities/datareportingandretrieval/electronichealthrecordsmeaningfuluse/immunizationi nformationsystem for more information. To participate in Meaningful Use Stage 1 with the IIS, a Washington healthcare provider must be enrolled in the IIS. There are no exceptions. Once the provider is enrolled, follow the directions on the Meaningful Use web site to initiate the Meaningful Use Stage 1 testing process. Meaningful Use Stage 2 The CMS regulations for Meaningful Use Stage 2 are different than for Stage A provider must register and indicate the provider s intent to attest for Meaningful Use Stage 2. Registration is online ndfacilities/datareportingandretrieval/electronichealthrecordsmeaningfuluse/immuni zationinformationsystem. Complete the online registration form, and the IIS will acknowledge your registration and provide additional information. a. Eligible hospitals must complete all three public health criteria, IIS, electronic laboratory reporting, and syndromic surveillance. b. Eligible providers may select one of the three public health criteria. 2. In Stage 2, a provider must submit data continuously for one quarter of a calendar year. The quarter for submission was identified in the provider s registration. The IIS will confirm completion of the submission, and the provider will complete a Provider Submission Detail Report in the IIS as evidence of that submission. 14

15 Health care providers who do NOT give immunizations: The Washington State Immunization Information System only works with health care providers who give vaccines. Immunization registries represent only one of three public health Meaningful Use criteria. The other two criteria are syndromic surveillance and electronic laboratory reporting. For more information on these two options, go to the Washington State Department of Health website [ or contact Dr. Bryant Karras, Washington State Department of Health Meaningful Use Coordinator, or go to the Washington State Medicaid Office website [ If none of the public health options apply to your office, you may be eligible for exclusion from the public health requirement. See the websites above for more information. VI. Document Change History Version Issue Date Modified By Comments/Reason /01/2011 Sherry Riddick First Version released /15/2011 Sherry Riddick Formatting of document changed. Appendices A, B, C, D incorporated into main document. Appendix C modified Vaccinator (RXA 10) added to list of Vaccination Fields as Recommended. Had been inadvertently omitted in Version /15/2012 Margo Harris Updated supported NK codes. Revised Appendix A and C with minor changes /15/2012 Margo Harris Edited for IIS name change, updated CDC HL7 Specification link /16/2013, 8/31/2014 Margo Harris Major revision of guide, updating WA State requirements, including Meaningful Use Stage 2. Replaced Appendix D. Updated information for HL and QBP/RSP query. Additional minor edits 8/31 15

16 APPENDIX A Washington State Immunization Information System HL7 Interface Project Guide HL7 Precertification Checklist This checklist provides an outline of basic steps followed to help assure a successful interface. This is not a stand-alone document, and is intended to be used as a helpful tool in conjunction with the Washington State HL7 Interface Project Guide and other HL7 tools referenced in the introduction of this document. The Washington State HL7 Guide clarifies the specific requirements for Washington State. Please refer to the CDC and STC guides for message construction support and other HL7 details. A provider s HL7 data must meet all the criteria listed below, verified by IIS staff in the IIS Test environment at a quality threshold of 95% or higher, before the provider s interface is approved to move to the IIS Production environment. 1. To initiate the precertification process, the provider/vendor must schedule a conference call with IIS staff. Key issues to consider: a) HL7 data transport strategy - The IIS supports https post and a transport bridge. See the Washington HL7 Interface Project Guide for more details. b) The IIS system is a lifetime IIS. Immunization information for patients of all ages, including travel vaccines, RSV, PPD/Quantiferon Tests are accepted. c) The vaccine supply in use at the provider office, publicly supplied and privately purchased vaccines. Best Choices Guides are referenced in the Introduction of this document. d) Vaccines entered as administered, i.e. combination vaccines, new vaccine choices e) Update requirements in WA to manage vaccine inventory in the IIS, including lot number, manufacturer, site, and route of vaccination, action codes for Add/Delete? Clarify the scope of the project. f) Unverified vaccines are unacceptable for submission to the IIS. The IIS does not accept patient or parent reported vaccines without documentation or medical evidence. If necessary, the IIS may require a provider to filter historical vaccines out of the interface. g) Questions/issues you would like to raise at the start of the call? 2. All required data fields are successfully reaching the IIS and populating accurately, including Facility ID and Gender, at a threshold of 95% or higher. (See Appendix C for more details on required fields.) a) Basic Required Fields: The set of data items for the interface must include: i. Demographic Section: Medical Record Number/Patient ID (must be unique, PID-3) Patient Name, Last (PID-5 ) Patient Name, First (PID-5) Patient Date of Birth (PID-7) Guardian/Guarantor First Name, Last Name (NKI Segment only GRD, MTH, FTH, PAR or null accepted) Gender (PID-8) Full Address (PID- 11) street address concatenated to one line only Patient Name Suffix (PID-5)

17 Race (PID-10) Ethnicity (PID-22) Phone Number (PID-13) (consider Reminder/Recall, phone or auto-dialer) Facility Name (PD1-3.1) and Facility ID (PD1-3.3) VFC Status (PV1-20) ii. Vaccine Section Vaccination Administration Date (RXA-3) Vaccine Code (CVX, CPT, or both) and Name (RXA-5) CVX/CPT coding must match vaccine products administered in provider s office Administration Notes New (coded 00 ) vs. Historical (coded 01 ) (RXA-9) (identify patient-reported, unverified vaccine history as unacceptable to enter or to default a complete date) Facility Name (RXA-11.4) and Facility ID (RXA-11.1) Vaccine lot number (RXA-15) Manufacturer name with MVX code (RXA-17) Dose size (volume) (RXA-6) Dose measurement (ml) (RXA-7) Route of administration (RXR-1) Anatomical site of administration (RXR-2) Vaccine publicly or privately supplied (must be submitted in an OBX message using a VFC code) a) Additional Strongly Recommended Fields: i. Demographic Section: Patient Middle Name/Initial (PID-5) address (PID-13) (consider Reminder/Recall) ii. Vaccine Section: (if not currently capable, plan for future submission) Vaccinator (administering provider) (RXA-10) Vaccine Information Statement (VIS) publication date and given/presentation date (OBX messages) History of Chickenpox (OBX message) ,000 HL7 messages are sent to the IIS a) The IIS needs to receive between HL7 messages (excluding influenza messages, which are reviewed but not included in this total) during the testing process. Initial messages are useful as you finalize your HL7 message format. The majority of the messages submitted MUST represent the final message format. b) The range of vaccines to be sent across the age span must be included. It is helpful if they represent typical messaging at the provider s office on a daily or weekly basis. c) Connecting the provider s production or live system to the IIS s test environment (i.e. to see volume, data entry errors, etc) is critical. d) Test messages continue until all vaccine and demographic data issues have been resolved, the proportion of vaccines sent to the IIS is appropriate for the practice, and all vaccines administered are represented in the provider s data. 17

18 4. The provider s clinical staff/vendor s technical staff and IIS staff review the data populating the Development server and agree that it is acceptable. a) What items is the provider/vendor looking for in the patient record? Are the vaccines displaying appropriately? (Requires a user account on the Development web site, not the login for the HL7 Account). (i) Vaccination Breakdown Report: - Individual patient records and vaccine detail screen. (ii) Patient Detail Report: - Look at several records to see data fields - (NOTE: Look at Facility level for each report) (iii)vaccination Data Quality Detail Report: - Identifies any quality issues/questions about data received - Identifies patient messages received, but not yet populating IIS records (iv) Washington State Vaccine Administered Report - Review alphabetical list of vaccines and age appropriateness b) Clinical staff at the provider office have had an opportunity to review immunization data as it is populating the Development application, including inventory management if that is a feature of this interface. 5. Once success for each of the check list items is completed, the provider s account will be changed to the IIS Production system. Data submitted to the IIS Test system will NOT be moved to Production. The IIS DOES NOT go live with an immunization interface in the IIS Production system the same day the Electronic Health Record (EHR) goes live. a) The Production URL will be provided. b) A new Login and password will be provided for the HL7 account. c) Access will be provided for one or more staff to monitor the HL7 Import log. 6. In Production ongoing: Provider staff monitor data on a regular, ongoing basis: a) Monitor HL7 error logs & acknowledgement messages, troubleshoot as needed, resolve any error messages. b) Clinical staff review & monitor accuracy of patient records in the immunization IIS, report any issues to the provider s IT staff and IIS staff. 18

19 APPENDIX B Washington State Immunization Information System HL7 Interface Project Guide HL7 Interface Phases with Suggested Timeline While each HL7 interface will move at its unique pace, the work progresses in three phases. A suggested timeline is outlined below. PHASE 1 Activities Time Range Comments 1. Initial contact 2. Conference call 3. HL7 Account Set up 4. Connectivity verified 5. Message building activity 6. Message format completion PHASE 2 NA Required, scheduled as IIS staff are available, linked to waiting list Within 5 business days of #2 or as requested Within 5 business days of #2 or as requested Within 5-10 days from #4 Within 30 days from #5 Activities Time Range Comments 1. First authentic test data submitted 2. Follow-up conference call days from Phase 1, #2 The IIS may share HL7 specifications document, HL7 checklist & timeline. Review HL7 checklist, HL7 Phases & Timeline, Q & A, demo on request. Set up user accounts in Development. HTTPS post or transport bridge provided. User accounts in Development required for clinical and IT staff representatives. (Meaningful Use may be demonstrated here, if MU criteria are met.) Test messages are useful and reviewed during this time, but they are not authentic until the message format is completed. Phase 2 begins when authentic data that matches the intended HL7 message format is submitted. This can be test data but production data is needed before going live days from Initial authentic data review, including demo 19

20 Phase 1, #2 of HL7 Import Log and suggested reports. Train clinical staff in data quality report review as needed. 3. Data Review & Demonstration PHASE days from Phase 2, #2 Should be final review prior to move to Production Activities Time Range Comments 1. Provide HL7 Production account login and password 2. Move to Production day review of data, issues. Within 1 2 weeks of Phase 2, #3 Within 1 2 weeks of Phase 2, # days from interface go live Data on Development is NOT moved to Production. Confirm IT and clinical contacts, confirm monitoring role. Depending on the organization s readiness to move forward, the stated time range will vary. Note: The IIS does NOT move the immunization interface to Production the same day a medical organization goes live on an Electronic Health Record (EHR). Authentic data = data submitted in Phase 2 that is in the final HL7 message format designed for this interface. If possible, this data represents a connection from the provider s live electronic health record (EHR) to the IIS s Development or Test application. 20

21 APPENDIX C Washington State Immunization Information System HL7 Interface Project Guide Required Fields (Segments & Components) DATA FIELD REQUIRED, RECOMMENDED, ACCEPTED, IGNORED HL7 SEGMENT COMMENTS PATIENT FIELDS Patient ID (Medical Record Number) Required PID-3 First Name Required PID-5 Last Name Required PID-5 Middle Name Recommended PID-5 Suffix Required in a suffix field PID-5 Suffix may only be submitted in a suffix field, not appended to last name Date of Birth Required PID-7 Gender Required PID-8 Social Security Number No longer accepted or stored Not Accepted Please do not submit. Alias First Name Recommended PID-9 Alias Last Name Recommended PID-9 Birth File Number Accepted PID-3 Birth Multiple Recommended PID-24 Birth Order Recommended PID-25 Race Required PID-10 Use current standard code set per CDC Implementation Guide page A-2 Regard as Required but may be Empty (RE) Ethnicity Required PID-22 See Comments for Race above. 21

22 DATA FIELD REQUIRED, RECOMMENDED, ACCEPTED, IGNORED HL7 SEGMENT COMMENTS Facility Name Required PD1-3.1 Facility ID Required PD1-3.3 Eligible VFC (at demographic level) Required PV1-20 Address Street & City Address State Required Required PID-11 PID-11 Entire street address should be concatenated into one line. The address must include: street, city, state, zip code. Address Zip Required PID-11 Phone Required PID-13 Recommended PID-13 VACCINATION FIELDS Vaccine Name Required RXA-5 Vaccine Code CVX Required (for MU) RXA-5 CVX vaccine codes are required for Meaningful Use. Both CVX and CPT codes can be submitted Vaccine Code CPT Required if no CVX code RXA-5 CPT vaccine codes can be accepted if CVX codes cannot be provided, but do not meet Meaningful Use requirements Vaccination Administration Date Required RXA-3 Vaccinator (administering provider) Recommended RXA-10 Vaccine Lot Number Required Administered vaccines Vaccine Manufacturer Name Required Administered vaccines RXA-15 RXA-17 Vaccine Manufacturer Code (only current MVX accepted) Required Administered vaccines RXA-17 22

23 DATA FIELD REQUIRED, RECOMMENDED, ACCEPTED, IGNORED HL7 SEGMENT COMMENTS Vaccine expiration date Accepted RXA-16 Vaccine Eligible VFC Code Required OBX Including V10 for patients with private insurance Administration Notes: Historical vs Administered (new) Action Code (add & delete supported/update not supported) Required RXA-9 Historical coded 01, New coded 00 Recommended RXA-21 A = Add U = Update D = Delete Administered Amount (i.e, dose size, numeric volume) Required RXA-6 Route of administration Required RXR-1 Anatomical site of administration Required RXR-2 VIS Presentation Date Recommended OBX VIS Publication Date Recommended OBX Facility ID Required RXA-11.1 Facility Name Required RXA-11.4 Facility Address Accepted RXA-11 GUARDIAN FIELDS First Name Required NK1-2 Only required for <19 yo Last Name Required NK1-2 Only required for <19 yo Phone Recommended NK1-5 Relationship Required to be coded as GRD, MTH, FTH, PAR, or null. If null, defaults to GRD. But NK1-3 23

24 DATA FIELD REQUIRED, RECOMMENDED, ACCEPTED, IGNORED HL7 SEGMENT COMMENTS if populated with any other value, the guardian name info will be ignored. Social Security Number No longer accepted or stored Not accepted 24

25 APPENDIX D Washington State Immunization Information System HL7 Interface Project Guide Quick Tips for a Successful Interface Message Segment MSH-11 PID-3 PD1-11 PV1-20 IIS Recommendation The processing ID is always P even if messages are being submitted to the Development server. The IIS does not have other requirements or provide other IDs for the MSH. The identifier code is assumed to be MR. Publicity code identifies Reminder Recall method. If submitted, the correct value is 02^Reminder/Recall any method. Required for all patients. A valid code for WA state must be submitted for patients under 19 to complete the annual WA State VFC Profile. V00 is not accepted and should not be submitted. OBX VFC Status is the code for eligibility category, ^vaccine fund pgm elig cat^ln - This is the correct code for indicating VFC status indicates a funding program, which is not the correct code. OBX History of Chicken Pox OBX 1 CE ^Disease with presumed immunity^ln ^Varicella immune (finding)^sct F QPB/RSP Query required for HL RXA-5 Administered Code RXA-10 - Vaccinator CVX, CPT, or both are expected Correct submission would include: RXA10.1 ID RXA10.2 Last name RXA10.3 First name RXA10.4 Middle name/initial (optional) RXA Credential 25