Subratabeheraportfolio.weebly.com



Creating a single patient database for all patient MRN’s for a HIE

Subrata Behera, Nancy Casazza, Martin Coyne, Cornelius Jemison, Abby Zimmerman

Northwestern University

Overview

With the advent of the latest innovations in the field of computing there were major breakthroughs in the development of online medical records. Medical records which used to be in the paper form where digitized and stored online for easier retrieval and better sharing across the entities within the same hospital system. Then users were faced with a challenge of sharing the clinical data with various entities within a geographical location. Thus came the concept of HIE (Health Information Exchange). An HIE can be defined as the transfer of the healthcare information electronically across organizations within a geographical location.

HIE provides the platform through which data can be shared across various disparate healthcare system which are using various information system products for their day to day operations. The primary goal of the HIE is maintain the meaning of clinical data that is being transferred over. HIE are being used more and more to share data across entities that have agreed to share data for meaningful use. HIE can be used as a tool by the public health authorities to monitor the health of the population.

HIE systems helps in achieving higher standards of patient care by the use of the electronic medical record as patients continuity of care can be maintained by multiple providers. The secondary healthcare provider benefit from HIE with the reduction in cost associated with the duplicate tests, time involved in missing patient information, manual man hours spent on getting the patients results from other providers through fax, scans, paper copies etc.

Organizations are now coming together to provide health information exchange efforts at the local and regional level. These organizations are being supported financially by the Office of the National Coordinator for Health Information Technology. These grants were legislated into the HITECH components of the American Reinvestment and Recovery Act in 2009 (U.S. Department of Health & Human Services, 2011). The newer organizations are coming together to form RHIO (Regional Health Information Organization) which are geographically defined entities which have mutual agreement and contractual obligations to arrange for the meaningful sharing of health information using the defined HIE standards (Overhage, Evans, & Marchibroda, 2005).

Advantages of an HIE

•• Easier sharing of clinical data

•• Reduction in cost as duplicate tests will be avoided by physicians.

•• Better access to clinical data both for the end users and the patients.

Barriers to HIE

Despite its potential, and despite hundreds of millions of dollars in government and private funding, a nationwide HIE is not on the horizon. One of the biggest problems is the lack of standardization. There are no universal standards for data and data exchange, although organizations in the United States are working on developing such standards. In addition, there is no standardization for the software and hardware purchased and used by providers and health care organizations. Other barriers include:

•• Consumers’ fear of security problems and providers’ fear of liability

•• The reluctance of providers to share information

•• Insufficient leadership at the federal, state and local levels

•• Relatively high costs

•• Lack of a sustainable business model, particularly in the current economic environment

Background

Health information exchanges (HIE) are an integral part of the meaningful use requirements under ARRP. HIE are used to move electronically generated clinical data across various disparate systems while maintaining the meaning of the information and use of the information that is being exchanged. The goal of HIE is to facilitate access to and retrieval of clinical data, so to provide safer, more timely, efficient, effective, equitable, patient-centered care.

HIE systems assist clinicians in meeting the high standards for patient care. These standards are met through electronic participation in a patient's continuity of care, along with additional care providers. Secondary healthcare provider benefits include reduced expenses associated with: duplicate tests, time involved in recovering missing patient information, paper, ink and associated office machinery, manual printing, scanning and faxing of documents, the physical mailing of entire patient charts, and manual phone communication to verify delivery of traditional communications, referrals and test results (Noam H. Arzt, 2011).

There are many HIE’s across the US which allow the sharing of the clinical data across a certain geographic location. These HIEs are often referred to as Regional Health Information Organizations (RHIOs). Their purpose is to develop and manage a set of contractual conventions and terms, arrange for the means of electronic exchange of information, and develop and maintain HIE standards (Overhage, 2005). HIEs and RHIOs continue to struggle to achieve self-sustainability and the vast majority remains tied to Federal, State, or Independent grant funding in order to remain operational. There are some exceptions to this, such as the Indiana HIE (http:/​/​​, April 25, 2011).

Founded in 1997, Healthbridge is a non-profit community-based organization and one of the largest HIE organizations in the United States (HealthBridge, 2011). Healthbridge provides connectivity for more than 28 hospitals, 5500 physician users, 17 local health departments,  700 physician offices and clinics, as well as nursing homes, independent labs, and radiology centers which serve the states of Ohio, Kentucky and Indiana.

Currently the HIE performs the following functions:

- Sharing of clinical data across various EMR applications based on the patient’s PCP

- Sharing of ED discharge summaries to patients PCP

- Sharing of lab and radiology tests done at the national sites (e.g., Labcorp, Quest)

- Also provides a physician portal where the physicians can become a member to view the diagnostic results of their patients even if they don’t have any EMR installed in their offices.

Sharing of the clinical data across the various healthcare systems is based on various patient identifiers that are sent across the system through the use HL7 messaging. The most common identifiers that are used for validating results against a patient record are as follows:

o Patient (Medical Record Number) MRN

o Patient Name (F Name, L Name, M Name)

o Date of Birth

o Sex

o SSN

The above identifiers holds good when we a use a single EMR as the MRN’s are auto generated within the system and the data sharing is happening within the hospital system. The issue arises when we start sharing clinical data across healthcare systems. Each healthcare system generates its own set of ID’s and these numbers are not shared or stored in other systems which results in issues with patient validation and hence requires manual intervention to correct the HL7 messages. Manual correction of the HL7 messages increases the chance of data being entered erroneously which defeats the purpose of seamless data flow and an automated process. Additionally, a few of the national labs (e.g., Labcorp, Quest) use specimen numbers to uniquely identify a result that comes across the system and is being shared.

Proposed Solution

The proposed solution to fix the issue as mentioned above will involve the following:

- Creation of a Master Patient Index (MPI) which is maintained by the HIE

- Creation of algorithms which will assign weights to each individual demographic criterion, which will be used in the patient matching logic

- Other Technical considerations

Workflow

- The result that is being sent from the initiating system will pass through the HIE.

- The HIE will query the MPI with the demographic information that is present in the HL7 message. The following demographic information will be used by the query. Each attribute below will have a weight associated with them:

o Patient MRN

o Patient Name (F Name, L Name, M Name)

o Date of Birth

o Sex

o SSN

- The MPI responds to the query with the sum of weights for all the attributes along with the list of possible matches. The greater the information passed along in the query, the better the search result. If the sum of the weights crosses a particular threshold then only the MRN is associated with the clinical message and will forward to the receiving system. The results will then be able to file successfully in the receiving system.

- If the search doesn’t return any possible matches or returns results that are below the threshold then a new entry may be created in the MPI and the new ID for the patient will be relayed onto the application, both sending and receiving, so the information is up-to-date in all the systems.

Assumptions

- Initial patient load will not happen in the MPI with the information collected from across the region so as to arrive at a comprehensive list.

Why Our Solution

We did an analysis of the various EMPI systems in the market. Initiate is the leader in MPI systems in the market. There are also a bunch of vendor specific MPI systems that are being used currently for MPI management within an application (for e.g. Identity from Epic). The drawback of such kind of systems is that they are vendor specific and hence are not interoperable. Initiate is one of the MPI systems that is truly interoperable and hence can be used with existing products make s it truly a market leader.

The solution that we are recommending would be open source and can be used by the existing vendors with little modification. The MPI system will result in resolving the issue of patient ID mismatch which is a critical functionality in a HIE network. The project will help reduce the manual work effort utilized daily towards fixing the errors that are generated due to the patient ID mismatch and the also the potential patient safety concerns. Healthbridge does certainly have a MPI system in place but it has not been working as intended and hence the adoption of the same has been limited to only a few hospitals. Currently there are only a few hospitals in the Cincinnati region that use Healthbridge’s MPI system.

The proposed solution that we are developing has a weight based approach in finding a possible match from the MPI system. Each identifier that the query is using for finding a patient from the database has a weight assigned to them. The results are returned only if they are above a certain threshold. If the threshold are met then only the list of the patients are returned. The patient having the highest threshold is picked up and used in population the patient unique identifier and then passed onto the downstream applications. The threshold limits helps in allowing only the closest match and not any match. The threshold limit is defined by each individual hospitals depending on the confidence on their own patient database and the cleanup effort that must have taken before the patient data is loaded into the MPI database maintained by the HIE.

Since the product that is being developed can be customized and be used by the other HIEs around the country thus helping a making HIE a reality and much more efficient.

Implementation Overview

The Implementation of the project will be done is a staggered fashion with each hospital going live with two beta sites. After review of this experience, more beta sites will be implemented. At 6 months, the results will be presented to a steering committee for review and future decision.

Steering Committee

A steering committee will be formed with representatives of the key stakeholders in the HIE. These stakeholders are: hospital members, payors, medical group and ancillary services. The committee will meet monthly for the first six months, then quarterly for the next six months. The committee will elect its own officers. The Enterprise IT contractor will report monthly to this committee in regard to progress and process in the program development and implementation. This committee will have final authority in regard to the scope of the contract with the contractor.

Budget for first 6 months

Personnel Expenses ($)

Project Manager (0.50 FTE) 55,000

Programmer/designer (0.50 FTE) 50,000

Implementation Manager (1.0 FTE) 40,000

Trainer (1.0 FTE) 30,000

Documentation Assistant (0.25 FTE) 15,000

Admin support (0.25 FTE) 12,500

Travel, hosting 6, 250

TOTAL $195,750

Implementation

Design and Specifications will be formally presented to the Steering Committee at the onset of the first six months. The implementation plan will be presented for approval to the Steering Committee by Week 2 of Month 1. On Week 4 of Month 1, a formal presentation will be made to a larger group of stakeholders including IT representatives of the stakeholders. This implementation plan will identify 2 pilot sites (a hospital and an outpatient medical group). By end of Month 3, the user survey and expert opinions about the pilot sites implementation will be presented to the Steering Committee. Pending approval of this Committee, an extended Pilot Study in 4 sites will be implemented in Month 4. At the end of Month 6, expert opinions and user survey will be reported to the Steering Committee. After this review, the Steering Committee will have the responsibility to recommend a full implementation or improvement remedies.

Implementation testing and training

Objective criteria will be reported. These include average response time for processing the ID and accuracy of retrieval of the ID.

Subjective opinions from a review of a questionnaire with a scale of 1-5. These questions will include: impact on workflow, ease of use, and user satisfaction. Independent experts drawn from the stakeholder IT staff and users will participate in this survey.

A training manual will be developed which will be distributed to all departments that will use the ID retrieval system. A series of formal lectures will initiate the training cycle. These lectures will be followed up with “hands-on” training in small groups. A Help Desk will be available throughout the implementation for the subsequent 6 months after implementation.

Business Case

Return on Investment

Biggest return is expected from a reduction in duplication of tests resulting from confusion over the patient’s multiple IDs in the system. According Peter Orzag, former director, Congressional Budget Office, $700 billion annually is spent on unnecessary medical tests. Assuming a service area of 3 million people for this HIE, there could be as much as $7 billion in unnecessary tests performed (Costs of Care, 2009). Assuming even 1% reduction in unnecessary tests by making obtaining performed tests easier, the return of actual expenditure of $200,000 for the 6 month period could be easily surpassed within the first year. In addition, indirect costs such as the cost of training incurred by the stakeholder entities in the HIE could easily be captured within the first year

Satisfaction

Both provider and customer satisfaction will be enhanced by easier access to already performed studies and by the reduction of clipboard duplication, i.e., registering the patient repeatedly at different points of entry.

Improved Quality of Care

Reduction in duplication of testing will further decrease the cost of complications resulting from this reduction.

Training

Training will provided the training onsite at each of the facilities going live. During the course of the training the end users will be provided the following:

- Instruction Manual detailing the steps that are required to work with the product.

- Hands on experience on the product in the playground environment.

- Tips and Tricks so as to make the working with the product easier.

Software/Hardware Infrastructure

Cloud Services

Within in the last five years more companies are looking to expand the services that they offer through service oriented architecture or what’s commonly known as web services. As these services are offered, those companies are choosing infrastructures that are hosted in the cloud or outsourcing the infrastructure portions of enterprise systems to other infrastructure vendors. Our HIE for our community is hosted in Google’s Application Engine infrastructure, where Google is responsible for the care of our infrastructure.

Technical Approach

The HIE was developed using Google’s Application Engine JAVA API, and Google’s database system. The web services portion of the application was developed using an open source library called RESTUL which provides restful based web services in XML and the HL7 patient document formats.

The following methodology will be used to develop this application.

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.

• A RESTFUL service for patients

o Search

o Creation

• A RESTFUL service for providers

o Search

o Creation

• Design two simple web page that uses JAVA Servlets on Google App Engine Cloud Services

o Basic JAVA Script lookup for Search

▪ If patient isn’t in HIE during search, automatically added them to Google’s App Engine Cloud Services.

o Basic Hl7 input document lookup that operates similarly like JAVA Script search.

▪ If patient isn’t in HIE during search, automatically added them to Google’s App Engine Cloud Services.

HIE Website –

Database Model

Infrastructure Model

Business Process

The HIE software provides basic system integration to identify patients within the Cleveland community through a restful based web services and a system lookup via a web browser. Hospital and medical providers can use both utilities to look up patient’s unique identifiers for a community to link each EMR records for any patient. If the patient isn’t within the HIE, a record with a unique identifier is created.

Quality Assurance

Unit Testing

This application was tested using common JAVA open source library sets like JUNIT to test system responses from the Google’s servers. The application successfully passed those test. We provide both XML based web services with custom XSD schemas. Also, we’ve provided w

Integration Testing

Through testing will be responsible for the integration with hospital systems. Any system errors received on the application side of the testing will be handled by the community support systems, and internal errors will be handled by the medical providers IT systems. Users should be aware that we provide both a web page to test the data sent and to test the system responses when there are problems with the web services.

Below is a sample of a simplistic test plan that we’ve given to users:

HIE Test Plan

Website

Test 1 – Search for an Existing Applicant

1. Grab an existing patient from the web service:

2. Go to the HIE website and enter the patient’s SSN into the search form and hit submit.

a.

3. Did the patient’s record return?

a. If no, then enter what happened?

Test 2 - Create an application

1. Enter a test candidate into the website that doesn’t exist in the HIE.

a.

2. Did the patient’s record return?

a. If no, then enter what happened?

3. Did the patient have a new HIE ID?

a. If no, then enter what happened?

Web Service

Test 1 – Search for an Existing Applicant

1. Grab an existing patient from the web service:

2. Go to the HIE website and HTTP POST the patient’s record into the search web service.

a.

b.

3. Did the patient’s record return?

a. If no, then enter what happened?

Test 2 - Create an application

1. Create a patient and HTTP POST the patient’s record into the search web service.

a.

b.

2. Did the patient’s record return?

a. If no, then enter what happened?

3. Did the patient have a new HIE ID?

a. If no, then enter what happened?

For errors outside of the normal web services usage, a team of developers from coordinating hospitals would be assigned to look at the issue.

References

Costs of Care. (2009). All doctors should understand how the decisions they make impact what patients pay. Retrieved May 29, 2011, from http:/​/​ Web site: http:/​/​​about-costs-of-care/​opportunity

HealthBridge. (2011). HealthBridge Profile. Retrieved April 25, 2011, from http:/​/​ Web site: http:/​/​​index.php?option=com_content&task=view&id=5&Itemid=6

Noam H. Arzt. (2011). HIMSS Health Information Exchange (HIE). Retrieved April 23, 2011, from http:/​/​ Web site: http:/​/​​ASP/​topics_rhio.asp

Overhage, J. (2005). Communities' Readiness for Health Information Exchange: The National Landscape in 2004. JAMIA, 12, 107-112. doi:10.1197/​jamia.M1680

U.S. Department of Health, & Human Services. (2011, March 16). State Health Information Exchange Cooperative Agreement Program [Article]. Retrieved June 1, 2011, from http:/​/​healthit. Web site: http:/​/​healthit.​portal/​server.pt?open=512&objID=1488&parentname=CommunityPage&parentid=58&mode=2&in_hi_userid=11113&cached=true

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download