Development of a Single Patient Database/EMPI for a Hie

1
Development of a Single Patient Database/EMPI for
a Hie

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

2
What is an hie?

• 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

3
Barriers to hie

• Consumers 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

4
Background

• There are many HIEs 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.

5
Current functions of Healthbridge hie

• 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

6
Identified Problems

• When sharing clinical data across healthcare
  systems each healthcare system
• generates its own set of IDs
• 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

7
Proposed solution

• 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

8
Why this solution?

• 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

9
Proposed Workflow

• 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

10
Proposed Workflow cont.

• 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

11
Steering Committee development

• 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

12
Development Budget for first 6 months

• 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

• TOTAL

• 195,750

13
IMPLEMENTATION (first 6 months)

• 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

14
IMPLEMENTATION QUESTIONNAIRE

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

15
Training

• Development of training manual
• Distribution of training manual
• Formal lectures explaining training manual
• Small group hands-on training sessions

16
Application methodology

• 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.

17
ERD for EMPI database Model
18
Person RESTFUL Web service - http//med-404-hie.ap
pspot.com/r/person
19
Infrastructure model
20
HIE Website http//med-404-hie.appspot.com
21
testing

• 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

22
Security need assist

• 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
• http//www.ihe.net/Technical_Framework/upload/IHE_
  ITI_Whitepaper_Security_and_Privacy_2007_07_18.pdf
  

23
BUSINESS CASE

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

24
(No Transcript)
25
Need assist

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

26
(No Transcript)