Subrata Behera, Nancy Casazza, Martin Coyne, Cornelius Jemison, Abby Zimmerman Northwestern University Med Inf 403-DL

 Provides a platform through which data can be shared across various disparate healthcare systems for day to day operations  Helps to achieve a higher standard of patient care by utilizing the EMR so to maintain patient continuity of care across multiple providers  Provides participating systems with a reduction in costs associated with duplicate testing and the locating of missing patient information

 Consumer’s fear of security problems and providers fear of liability  Reluctance of providers to share information  Insufficient leadership at the federal, state and local levels  Relatively high costs  Lack of sustainable business model, particularly in the current economic environment

 There are many HIE’s in US which allow the sharing of clinical data across a geographic location.  For this particular project we will be using the example of Healthbridge which serves the states of Ohio, Kentucky and Indiana.  Founded in 1997, Healthbridge is a non-profit organization and its provides connectivity for more than 28 hospitals, 5500 physicians, 17 health departments, 700 physician offices, Nursing Homes, Labs, and radiology centers.

 Sharing of clinical data across various EMR applications  Sharing of ED discharge summaries with outpatient physician offices/clinics  Sharing of lab and radiology results performed at independent companies such as Labcorp  Provides a physician portal that enables physicians to view patient results, even if the office does not contain an EMR

 When sharing clinical data across healthcare systems each healthcare system:  generates its own set of ID’s  these numbers are not shared or stored in other systems  Individual IDs produce issues with patient validation resulting in:  manual intervention to correct HL7 messages  this manual intervention leads to erroneous data

 Create an Enterprise Master Patient Index (EMPI) which is maintained by the HIE  Create algorithms which will assign weights to each individual demographic criterion (this will be utilized in the patient matching logic)  Results are returned only if they are above a certain threshold

 Analyzed various EMPI systems currently on the market and the drawback to the various systems are that they are vendor specific, thus lead to difficulty with interoperability  This solution would be open source, having the ability to be utilized by existing vendor products with little modification

 All information requests will pass through the HIE  The HIE will query the EMPI with demographic information present in the HL7 message  The attributes of Patient MRN, Name (F, L, M), Date of Birth, gender, SSN will be utilized for each query  Each attribute will have an associated weight attached to them

 The EMPI will respond to the query with the sum of weights for all the attributes  The query will then provide zero to many results  If the query does not return a possible match then a new entry may be created in the EMPI and the new ID will be relayed onto the application

Representatives of HIE stakeholders  Single Identifier Developer Contractor  Hospital participants  Payor participants  Ancillary service participants  Monthly meetings during first 6 months  Quarterly meetings after implementation for first year

TOTAL:$195,750 ITEM Project Manager (0.50 FTE) Programmer/Designer (0.50 FTE) Implementation Manager (1.0 FTE) Trainer (1.0 FTE) Manual Documentation Assistant (0.25 FTE) Implementation: Travel, Hosting Admin support (0.25 FTE) COST $55,000 $50,000 $40,000 $30,500 $15,000 $6,250 $12,500

 Presentation of design/specifications to Steering Committee  Implementation Plan development  Presentation of Plan to Steering Committee  Formal introductory lecture to general stakeholders  Pilot implementation 2 sites  Review of implementation to Steering Committee  Implementation 4 more sites  Review of implementation experience Summary report and request for “going live” from stakeholders

 Objective  Average response time  Accuracy retrieval  Subjective( scale 1-5)  Impact on workflow  Ease of use  User satisfaction

 Development of training manual  Distribution of training manual  Formal lectures explaining training manual  Small group “hands-on” training sessions

 Request Application Development Domain from Google App Engine Cloud Services.  Design JAVA Database Objects (JDO) Objects that will persist in Google App Engine Cloud Services based on business case provided by business process owners.  Utilize RESTLET, an open source framework for RESTFUL based webs services, and Design REST based web services that integrate with JDO objects for the patients and providers.

 Tested utilizing common JAVA source library sets like JUNIT  Any system errors received on the application side will be managed by the community support systems  Internal errors will be managed by the medical providers IT systems  Providing users with a web page to test sent data and also the ability to test system responses when there are problems with web services

 HTTPS, Providers will only be able to access the URL  Standard ID and authentication controls will be utilized  Data will only be stored on system servers  In event of a patient emergency will utilize break-glass to elevate privileges

 Elimination of test duplication (ROI)  Labor (patient, employees) (ROI)  Improved Patient Satisfaction  Improved Provider Satisfaction  Improved Quality of Care

 Do we need to add a demonstration of the site at the end?