Subrata Behera Nancy Casazza Martin Coyne Cornelius Jemison
Subrata Behera, Nancy Casazza, Martin Coyne, Cornelius Jemison, Abby Zimmerman Northwestern University Med Inf 403 -DL
v Provides a platform through which data can be shared across various disparate healthcare systems for day to day operations v Helps to achieve a higher standard of patient care by utilizing the EMR so to maintain patient continuity of care across multiple providers v Provides participating systems with a reduction in costs associated with duplicate testing and the locating of missing patient information
v Consumer’s fear of security problems and providers fear of liability v Reluctance of providers to share information v Insufficient leadership at the federal, state and local levels v Relatively high costs v 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. v For this particular project we will be using the example of Healthbridge which serves the states of Ohio, Kentucky and Indiana. v 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. v
v Sharing of clinical data across various EMR applications v Sharing of ED discharge summaries with outpatient physician offices/clinics v Sharing of lab and radiology results performed at independent companies such as Labcorp v Provides a physician portal that enables physicians to view patient results, even if the office does not contain an EMR
v When sharing clinical data across healthcare systems each healthcare system: generates its own set of ID’s v these numbers are not shared or stored in other systems v v Individual IDs produce issues with patient validation resulting in: v manual intervention to correct HL 7 messages v this manual intervention leads to erroneous data
v Create an Enterprise Master Patient Index (EMPI) which is maintained by the HIE v Create algorithms which will assign weights to each individual demographic criterion (this will be utilized in the patient matching logic) v Results are returned only if they are above a certain threshold
v 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 v This solution would be open source, having the ability to be utilized by existing vendor products with little modification
v All information requests will pass through the HIE v The HIE will query the EMPI with demographic information present in the HL 7 message v The attributes of Patient MRN, Name (F, L, M), Date of Birth, gender, SSN will be utilized for each query v Each attribute will have an associated weight attached to them
v The EMPI will respond to the query with the sum of weights for all the attributes v The query will then provide zero to many results v 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 v Single Identifier Developer Contractor v Hospital participants v Payor participants v Ancillary service participants v Monthly meetings during first 6 months v Quarterly meetings after implementation for first year
ITEM COST Project Manager (0. 50 FTE) Programmer/Designer (0. 50 FTE) Implementation Manager (1. 0 FTE) $55, 000 $50, 000 $40, 000 Trainer (1. 0 FTE) Manual Documentation Assistant (0. 25 FTE) Implementation: Travel, Hosting Admin support (0. 25 FTE) $30, 500 $15, 000 $6, 250 $12, 500 TOTAL: $195, 750
v v v v 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
v Objective v Average response time v Accuracy retrieval v. Subjective( v. Impact scale 1 -5) on workflow v. Ease of use v. User satisfaction
v Development v Distribution v Formal v Small of training manual lectures explaining training manual group “hands-on” training sessions
v Request Application Development Domain from Google App Engine Cloud Services. v Design JAVA Database Objects (JDO) Objects that will persist in Google App Engine Cloud Services based on business case provided by business process owners. v 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.
HTTP: //MED-404 -HIE. APPSPOT. COM/R/PERSON
HTTP: //MED-404 -HIE. APPSPOT. COM
v Tested utilizing common JAVA source library sets like JUNIT v Any system errors received on the application side will be managed by the community support systems v Internal errors will be managed by the medical providers IT systems v 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
v HTTPS, Providers will only be able to access the URL v Standard ID and authentication controls will be utilized v Data will only be stored on system servers v In event of a patient emergency will utilize break-glass to elevate privileges http: //www. ihe. net/Technical_Framework/upload/IHE_ITI_Whitepaper_Security_and_Privacy_2007_07_18. pdf
v. Elimination v. Labor of test duplication (ROI) (patient, employees) (ROI) v. Improved Patient Satisfaction v. Improved Provider Satisfaction v. Improved Quality of Care
Do we need to add a demonstration of the site at the end?
- Slides: 26