Project Initiation Report HealthInsight HIE This report contains the documents delivered during the Assessment Phase for conducting the HIE project as well as a summary of next steps. Your project initiation will be conducted by HealthInsight. These documents will be reviewed along with next steps. Please return prior to the scheduled date established between you and your project manager. I. Assessment Phase 1. HIE Overview 2. Readiness Assessment- Inpatient 3. Readiness Assessment- Outpatient EMR 4. VPN agreement 5. Participant Agreement (Sent Separately) 6. Business Associates Agreement (Sent Separately) II. Project Initiation Summary 1. Introductions 2. Phase One Overview 3. Interrelated Project Overview 4. Review Project Plan A. Review Readiness Assessment 1. Discuss Orders 2. Discuss Referrals B. Review MPI Document C. Review Clinician Directory Document 5. Governance 1. Business Associates Agreement 2. Participant Agreement 6. Quality Improvement Achieving Results 1. Identify Change Management 2. Identify barriers HealthInsight Nevada 6830 West Oquendo Rd., Suite 102 Las Vegas, NV 89118 Phone: 702-385-9933 Fax: 702-385-4586
3. Identify champions, key stakeholders 4. Discuss workflow analysis 5. Human factors 6. Reports Growing Trend toward HIEs Health Information Exchange Overview The need for health information exchanges (HIEs) has never been greater than today as more health care leaders recognize that improved health care outcomes, safety, and efficiency is a priority. This has been reinforced by the passing of the HITECH in 2009 and the Health Reform Act of 2010. Legislation has only reinforced existing trends toward improved coordinated care, new models of care such as the Patient-centered Medical Home Model, payment reform initiatives, and Accountable Care Organizations. HIE is essential to all of these movements. Nationally, there are close to 250 reported HIEs in the country of which 73 were operational as of 2010. Many more are expected to be operational 2011 and beyond. What is an HIE? An HIE is the exchange of healthcare information electronically across organizations within a region, community or hospital system to improve the quality, value, and efficiency of patient-centric care. An HIE provides the capability to electronically move clinical information among disparate health care information systems while maintaining the meaning of the information being exchanged. HIEs enable physicians and clinicians to access all of the patient s relevant data at the point of care regardless of where the patient has been seen or where the physician is located. An important secondary benefit of the HIE is the reduction of redundant and costly HIT interfaces connecting to other organizations. In the future, HIEs have the potential for many other services enabling the use of data and tools for analysis to improve outcomes performance. HIEs Connect the Many Providers in a Common Region 2
3
Typical Participants in Community-based HIEs At its core, HIEs include the providers along the continuum of care who can join as stand-alone institutions or as a network. In addition, public health and other state agencies can connect. More HIEs are including a personal health record as an option for patients without other solutions. Some communities have plans to connect to the national network, NwHIN. Many other types of entities can and do participate, and increasingly, administrative data is provided by payers. HealthInsight HIE will start by connecting hospitals and physicians and expand to other data sources and data users. Governance and Sustainability of a Community-based HIE Typically, a community or regional HIE is governed by a multi-stakeholder body representing the participants in the HIE and, in some cases, other leading community organizations. While start-up funding may be through a grant or contribution, the stakeholders achieve sustainability through fees charges to participating organizations. Fees are determined based on the principles of benefits received and a common understanding of what is fair and reasonable. HealthInsight is currently working with stakeholders to establish its governance model and fee structure. Typical Services of an HIE 1. Secure clinical messaging the capability to move the data from among users across organizations. Typically, this includes lab and radiology results delivery, provider cross-referrals. 2. Inquiry the ability of an authorized clinician to look up clinical and administrative data from multiple sources through the HIE. This snapshot of patient data is often called the Continuity of Care Document (CCD), a virtual health record or a portal. It is an essential and life-saving tool used by EDs as well as others. 3. Web-based EHR Some HIEs are providing physicians with simple, Web-based EMRs at no cost or at a low cost to facilitate the movement of physicians from paper to electronic tools and to enable the entire provider community to take full advantage of the HIE. 4. eprescribing The ability of prescribers to electronically refill and prescribe medications, do medical reconciliations, and use decision support tools. 5. Public health connectivity Many HIEs use the clinical messaging function and direct data feeds to communicate with public health. 6. Direct data feeds through the HIE Most HIEs provide direct data feeds from data senders to the HIE and then route the data to other users for direct data feeds from the HIE. During the Initial Onboarding phase, HealthInsight will focus on secure clinical messaging. 4
Readiness Assessment Inpatient Setting Instructions Please complete this form and return to your implementation project manager. Project Information DATA PROVIDER: TARGETED START DATE: TARGETED COMPLETION DATE: Project Contacts Please provide contact details for all members of the project team (network engineer, interface specialist, analyst): Name Title/Role Phone Email Project Planning Questions No. Question Discussion and Decision (if your answer is yes to the question, please describe) Please list any current/future initiatives that may impact this project implementation. (eg, system upgrade, resource constraints, platform migration) Are there any external drivers or time constraints that the HIE/RHIO should be aware or consider when outlining the implementation schedule for this project? If so, please provide details (eg, grant deadlines, stakeholder expectations) 5
General Interface Information No. Question Discussion and Decision (if your answer is yes to the question, please describe) HL7 3 Please provide your facilities current HL7 version. (Note: The minimum HL7 requirement is 2.x.) 4 Do you currently produce outbound HL7 data feeds for ADT, Lab, Radiology, and Transcription? Facility Information 5 Facility Acronym (Please select a facility Acronym no greater than 6 characters in length) 6 Facility NPI 7 Facility OID 8 Have you allocated any additional OIDs/sub OIDs that we will not be able to utilize? 9 Facility transaction volumes per day: ADT LAB RAD Sample Messages TRN 10 Minimum requirement for initial mapping is 100 messages per feed. Will you be able to provide? 6
Data Feed: ADT ADT Clinical Application Vendor Version/Release No. Question Discussion and Decision (if your answer is yes to the question, please describe) Fictitious Patients 1. What is the fictitious naming convention for newborn females? 2. What is the fictitious naming convention for newborn males? 3. What is the fictitious naming convention for newborn unknowns? 4. What is the fictitious naming convention for multiple births? 5. What is the fictitious naming convention for unconscious trauma patients? (i.e. name, MRN convention, other demographic data?) 6. What is the fictitious naming convention for VIPs or patients with special circumstances? (eg drug screens for an employer where patient is not registered individually). 7. Are there requirements in your registration system that may not be provided by the patient and is then inserted as fictitious information on the patient registration? Patient Merges 8 What HL7 message event type is sent when merging a patient s MRN? 9 What HL7 message event type is sent when unmerging a patient s MRN? HIE Consent 7
10 Do you plan on collecting consent through your registration process? If yes, do you know the HL7 field(s) that you will send it in? Note: Axolotl currently does not support consent updates based on a standard ADT feed. Consent will need to be transmitted in a separate feed containing consent updates only. MRN Mapping 11 Please indicate from which Seg/field we should pull the MRN. 12 Additional ADT comments? Data Feed: Laboratory Lab Application Vendor: Version/Release: No. Question Discussion and Decision (if your answer is yes to the question, please describe) Do you have a separate Pathology application? Do you have a separate Microbiology application? Will all lab data come through a single feed through an outbound feed? Do you send a preliminary indicator in the HL7? Do you identify corrected results? 6. If Yes to either 4 or 5, please provide the specific field in which the Corrected or Prelim flags will be sent. 7. Do you currently LOINC code lab tests? Corrected: Prelim: 8. Additional Lab comments? 8
Data Feed: Radiology Radiology Application Vendor: Version/Release: No. Question Discussion and Decision (if your answer is yes to the question, please describe) Is the transcription part of the HL7 message in plain text format? (Note: Axolotl currently does not support RTF) Does Cardiology textual reports come through the radiology feed? Are you capable of embedding a URL to a PACS system in your HL7 message? Additional radiology comments? Data Feed: Transcription Transcription Application Vendor: Version/Release: No. Question Discussion and Decision (if your answer is yes to the question, please describe) Is the transcription part of the HL7 message in plain text format? (Note: Axolotl currently does not support RTF) Does Cardiology textual reports come through the transcription feed? What types transcribed reports can be sent, discharge summary, Op reports, H&P, Consults, etc.? Additional transcription comments? 9
Additional Questions No. Question Discussion and Decision (if your answer is yes to the question, please describe) 5 Do you have multiple physician address books? Data Feed Validation No. Question Discussion and Decision (if your answer is yes to the question, please describe) Is QA (validation testing) for data feeds typically performed by the IT/IS department or by staff within the ancillary departments? Do you currently have an existing test platform for all feeds? Additional QA comments? 10
Readiness Assessment Outpatient EMR Instructions Please complete this form and return to your implementation project manager. Customer/ HIE Information Site Name Primary Contact EMR Information EMR application name EMR software version Primary contact Primary contact phone Primary contact email Address/city/state/zip Primary technical contact (if different than above) Primary technical contact phone Primary technical contact email 11
Physician Office/Group Information Office name Address/city/state/zip Primary contact Primary contact phone Primary contact email Primary technical contact (if different from above) Primary technical contact phone Primary technical contact email 12
Technical Details Type of Interface Outbound to EMR What features are requested? Please check only the ones that apply: Lab Transcription Radiology Patient Memos (EMR-Lite specific form) Forwarded Messages (EMR-Lite specific form) Office Memos (EMR-Lite specific form) Referrals (EMR-Lite specific form) Others please list. Inbound to Elysium Patient Index/ADT Progress Notes Referrals Orders Others please list. Method of Communication: Inbound: (Select One) SFTP File Share w/vpn Socket Connection w/vpn Outbound: (Select One) SFTP File Share w/vpn Socket Connection w/vpn Outbound (to EMR) Data Types: ORU MDM Referrals Inbound (to Elysium) Data Types: ADT one time load ongoing ORU ORM MDM Referrals Outbound Specific Data Elements: EMR specific MRN (requires inbound ADT interface) EMR specific Physician ID Number Order/Encounter Specific information: (requires inbound Orders/ADT interface) 13
EMR Vendor Requirements Please define specific MSH header requirements Field Value MSH_3 MSH_4 MSH_5 MSH_6 MSH_12 Please define other requirements: Field Value 14
Please define any data filtering rules that may apply (i.e., only send when physician is listed as ordering physician, etc.): Please note any special cases to be taken into account (i.e., encounter matching, etc.): Task Responsible Party Target Date Determine projected target date Discuss referral patterns, possible filtering of data, message types to be exchanged, direction of information flow, establish timeline for implementation and resources needed Exchange data format specifications and sample files Determine data transport mechanisms Analyze data format specifications determine approach for revisions and discrepancies Establish and test data transport Create users in address book, Physician ID from the EMR is loaded in to the Elysium directory Configure outbound data feeds to EMR vendor specs Test sample files Complete go live configuration Go Live Outbound Data Feed Axolotl/Customer Axolotl/Customer Axolotl/EMR Vendor Axolotl/EMR Vendor Axolotl/EMR Vendor Axolotl/EMR Vendor Customer Axolotl Customer/EMR Vendor Axolotl All Week 1 Week 1 Week 2 Week 2 Week 3 Week 3 Week 4 Week 5 Week 5 Week 6 Week 6 15
VPN Agreement Axolotl VPN Contact Your VPN Contact Name: Name: Technical Services * Required Company: * Required Company: Axolotl Corp. Phone: * Required Phone: 1.408.920.0800 x280 Email: * Required Email: support@axolotl.com All VPN requests must be approved by an Axolotl Account or Project Manager Name of Axolotl Account/Project Manager = * Required Customer name = * Required RHIO/Governing body name = * Required (Example Laboratories of XXX ) (Example RHIO of YYY ) Axolotl VPN peer IPs = 208.37.137.4 and 8.8.32.11 (Both peers must be configured) Customer VPN peer IP = * Required TEMPORARY pre-shared key for use for initial configuration = F$iijexCC2Vvi@FQI4XqvgA! (The key will be changed before any network traffic is allowed to pass other than ICMP ping tests) Phase 1 Transform-set: Phase 2 Transform-set: DH Group 2 ESP 3DES SHA1 Lifetime 86400 seconds (24 hours) No PFS ESP 3DES SHA1 Lifetime 28800 seconds (8 hours) Axolotl interesting traffic endpoint IP address (es). Provided below is the initial host that is required for the VPN setup. Additional hosts will be provided later as they are specific per customer/data provider. IP Addresses Traffic/ports to Description (Axolotl Endpoints) allow 1) 209.119.87.254 ICMP VPN HEALTH MONITOR 2) xxx.yyy.xxx.yyy TBD Data Feed IP/PortsTo Be Determined 3) xxx.yyy.xxx.yyy TBD after form is filled out Customer interesting traffic endpoint IP addresses (es). Please provide host addresses below. No subnets please. If you are unable to provide public IPs for the hosts, we will require that you NAT to a 172.28.x.x 172.30.x.x address. To obtain the appropriate NAT IP s for your network, please email netops@axolotl.com and request NAT addresses for each server that does not have a PUBLIC IP. Failure to request a range of NAT IP s, or provide PUBLIC IP s for each endpoint may result in a delay processing this vpn request. IP Addresses (Your Endpoint Data Feeds/Servers) * Required If IP is not PUBLIC Email netops@axolotl.com to obtain 172.28.x.x 172.30.x.x NAT * Required Description / Remarks (Data Feed/Server) Operating System (Linux/Windows 200x, AS/400, Custom) 16
NOTES: A site-to-site VPN cannot be configured without all the required fields. If this is a VPN modification request, please ensure that all your existing endpoints are on the form and make a remark that indicates that these endpoints are either existing or new. This form contains all the information necessary to do the initial VPN configuration on the customer side. Subsequent data will be exchanged during a scheduled conference call to finalize all settings, perform testing and complete the process. These include both the production site and the DR site. Please see the attached diagram. If your current infrastructure technology does not allow for any of the requirements indicated here, we can provide a Cisco ASA5505CPE that will enable you to achieve interoperability. Please contact your Account Manager or Project Manager to proceed with this option. A client based, mutually authenticated SSL VPN using certificates is also an option. Please fill-out the Operating System column so we can assess if this is feasible in your environment. The current client based VPN is OS dependent. Additional Comments or requests: BASIC SITE-TO-SITE VPN CONFIGURATION For HIE Data Sources Version 1.0 Customer Side Production Data Center Node 1 IP address 1 Node 2 IP Address 2 Socket Server 1 Production NMS Node 3 IP Address 3 Customer VPN Appliance VPN Appliance Socket Server 2 Production VPN Appliance DR Data Center NOTES: The IP addresses of the nodes that are required to communicate through the tunnel should be translated (NAT) to either a public IP address or an Axolotl assigned private IP address. The VPN tunnels on the customer-end need to be configured so that the failover or the secondary tunnel will take-over when the primary tunnel fails and revert back when the primary tunnel becomes available. The VPN appliance need to comply with the encryption and fail-over standards set by Axolotl. This Customer Premise Equipment (CPE) can be provided by Axolotl. The IP address of the Socket servers and the Network Management Server (NMS), or the interesting traffic destination, will be the same on both data centers. The NMS should be allowed to ping (ICMP) to a defined IP address in the customer side for VPN up/down monitoring. When in production mode, the DR site will prevent the tunnel to be established to itself thereby preventing unwanted traffic to terminate to the inactive node. When a DR failover is initiated, Axolotl will make the changes to enable the VPN to be established on the DR site and prevent on the production site. This should allow for an automatic reroute of the traffic to the DR site socket servers. Socket Server 1 DR Socket Server 2 DR NMS 17