Indianapolis Emergency Medical Service and the Indiana Network for Patient Care: Evaluating the Patient Match Algorithm

Abstract

In 2009, Indianapolis launched an electronic medical record system within their ambulances1 and started to exchange patient data with the Indiana Network for Patient Care (INPC) This unique system allows EMS personnel to get important information prior to the patient’s arrival to the hospital. In this descriptive study, we found EMS personnel requested patient data on 14% of all transports, with a “success” match rate of 46%, and a match “failure” rate of 17%. The three major factors for causing match “failure” were ZIP code 55%, Patient Name 22%, and Birth date 12%. We conclude that the ZIP code matching process needs to be improved by applying a limitation of 5 digits in ZIP code instead of using ZIP+4 code. Non-ZIP code identifiers may be a better choice due to inaccuracies and changes of the ZIP code in a patient’s record.

Introduction

Emergency medical services (EMS) play a critical role in the nation’s emergency and trauma care systems. Annually, hundreds of thousands of EMS personnel provide more than 16 million medical transports. It is during these encounters where EMS personnel initiate care to patients and attempt to collect relevant information from the patient: such as chief complaint, past medical history, and current medications.

In circumstances where the patient is unable to provide relevant details: either obtunded from drugs or alcohol; or due to altered level of consciousness from infection, metabolic reasons, or trauma. Access to pre-existing medical information relating to medications, allergies, prior visits and hospitalizations, and diagnoses is even more critical when “time is of the essence” and may improve patient care.

Since 2009, authorized EMS personnel of Indianapolis Emergency Medical Service (I-EMS) have been requesting patient data from the Indiana Network for Patient Care (INPC)^{1, 2, 3}. This is the first regional health information exchange in the country to connect pre-existing health information to EMS providers. Our prior work³ illustrated the quantitative and perceived benefits of access to medical records in the pre-hospital setting.

EMS personnel initiate the patient identification (PI) process by submitting patient demographics into their electronic medical record (EMR). The system responds with message that indicates whether a patient match was made in the INPC system and if a clinical abstract is forthcoming. When an INPC patient lookup request results in a successful match in the INPC system, a patient abstract PDF document is returned asynchronously to the EMS system. The medical information provided in the INPC EMS abstract allows pre-hospital personnel to collect a more detailed medical history and allows for more informed treatment decisions. ⁴

As the system matured, we learned of situations where the EMS personnel would enter patient demographic data, yet no clinical abstract was returned. However, upon arrival to the hospital, the patient was registered into the emergency department (ED), ED personnel did indeed have access to the clinical abstract, where the EMS personnel did not. These reports prompted us to investigate this further and to analyze our matching algorithm in more detail.

The existing patient-matching algorithm based upon our real world experience of matching patients across disparate hospital systems. While our standard algorithm leverages the requesting institution name and patient medical record number along with other identifiers to match patients, I-EMS does not maintain a patient registry and therefore medical record numbers are not available. The purpose of this study was to evaluate the reasons why EMS personnel were unable to find a patient from the INPC database, yet the patient does truly exist in the INPC.

Methods

The Indiana University Institutional Review Board (IRB) approved this study. As a brief review from our previous work³, authorized EMS personnel may request patient information from the INPC through a modified look up screen (figure1). The lookup feature uses 1) Patient name (First and Last), 2) Date of Birth (DOB), 3) Gender, 4) Patient’s home ZIP code, and 5) Social security number (SSN). The EMS personnel are messaged as to the results of the lookup request. Possible responses include: 1) Patient match, 2) Too many patients match submitted information, and 3) No patients match submitted data.

Figure 1.

Mobile Data Terminal with ePCR & ePCR INPC query page ⁵

This analysis required three sets of clinical data: 1) I-EMS patients transported log, 2) I-EMS request for patient data log, and 3) the INPC registration log for Wishard hospital. I-EMS patients transported log data resides as a web-based reporting service. It contains the EMS data that is collected through the Siren ePCR system. The I-EMS log contains a list of all patients transported during the one-year study period from July 1st, 2010 through June 30th, 2011. The I-EMS request for patient data resides within Regenstrief Institute and contains information of the request packet sent from the tablet. It records: 1) EMS personnel demographics: EMT’s name, unit number, and service; 2) Patient demographic data: patient’s name, date of birth, ZIP (Zone Improvement Plan) code – U.S. Postal code, and social security number, and 3) Result of request for information: success or fail, if failed, the reason for failure. The INPC registration log contains all of the patient’s demographic information as they were registered at Wishard hospital. This information is used to match the patient across the INPC. We used this data set as the “gold standard” to determine what the EMS personnel should have provided when requesting patient information.

The PI algorithm works as follows: 1) It first does a SSN lookup, and if only one patient found then indicate a match. 2) If no SSN provided, or not a unique match, we then use the patient’s name ^{6, 7}, DOB, and gender (if provided). If there is no match, then no match is returned. If there is more than one patient matching these criteria then ZIP code is used to narrow the search. 3) The ZIP code match tries to match on what was entered. If this fails, then tries to match on the first five digits.

We first narrowed the I-EMS patients transported log to only those patients transported to Wishard hospital. Utilizing PERL, we loaded this file into a Postgres database. For each EMS response, there is a unique number assigned to that transport, known as the incident number. The I-EMS patients transported log and the I-EMS request for patient data log both contain the incident number. Utilizing the incident number as the primary key, we combined the first two data sets. This created a single data table with both the transporting agency information as well as the information provided in the request to the INPC for patient data. We then used a simple SQL query to pull the records from the database that resulted in a No Match response. These records were then manually compared to the INPC registration log to determine the cause of the failure.

Results

Of the 21,215 EMS transports to Wishard hospital during the one-year study period, there were 3,021 (14%) requests for INPC data.

Regarding the 3,021 requests for INPC data: 1) we excluded 1,105 (37%) which were “Not Authorized” to retrieve the data. EMS personnel must be authorized by I-EMS in order to view INPC data. Therefore, there was no attempt to match the submitted data. 2) there were 1,398 (46%) requests which resulted in a unique match, 3) seven (0.2%) resulted in “unknown” error, leaving 511 (17%) which resulted in no match.

Regarding the 511 “no match” patients: we determined which identifiers results in the highest number of errors. There were 275 (53.8%) due to zip code, 106 (20.7%) due to an error regarding the patient’s name, 59 (11.5%) with incorrect DOB, 49 (9.6%) unknown, and 22 (4.3%) had errors related to SSN.

Of the 49 “unknown” errors – we found the information transmitted by I-EMS to equal the information sent from the hospital system. One possibility is there was a technical issue for the non-match. Another possibility could be they may be a new patient the INPC. Further analysis would be required to learn if they were truly a “new patient”.

Discussion

In this descriptive study, we found EMS personnel requested patient data on 14% of all transports, with a “success” match rate of 46%, and a match “failure” rate of 17%. The three major factors for causing match “failure” were ZIP code (55%), Patient Name (22%), and Birth Date (12%).

The highest percentage (54%) of the errors was due to the patient’s ZIP code. Looking at the data in more depth, there were 244 (88.7%) records that matched only the first three digits, 15 (5.5%) records matched only the first two digits, 9 records that matched only the first digit, and 7 records having a totally different ZIP code. Our PI algorithm first utilizes all of ZIP code data (up to ZIP+4), and found ZIP code mismatch occurs within the first five digits in 97% cases.

One explanation for these findings is the dynamic nature of a patient’s ZIP code. A patient’s home ZIP code may change, or can be confused with the ZIP code information at the scene of an incident. We also found at least three situations with no match in ZIP code and determined these locations were homeless shelters and nursing homes within Indianapolis. Suggesting the patient’s home address and current residence may differ.

Regarding the patient’s name errors, we found seven records to have switched the first and last names as part of the medical record. It would be possible to provide more sophisticated logic to account for these and other common errors. Further detailed analysis will help to inform us other algorithms that could provide a more robust match.

INPC and I-EMS are the first organizations using a state wide health information exchange within the nation³. While there are a few studies regarding EMR in EMS, this research focuses upon expanding the existing hospital based EMR system into their ambulances as a departmental implementation.^{8, 9}

Limitations

This study was descriptive in nature and only contained data from one institution. It is possible that data from other institutions may yield different results. However, the results contained within this institution are informative and likely to aid other institutions as well. Second, we assume the true “unique patient” matches are a proper match. While not a primary focus of this study, we anticipate completing this part of the analysis within the next few months.

Conclusion

Over the past two years, the overall utilization rate remains stable: 16% in 2010 and 14% 2012. We believe in order to increase the utilization of the valuable data contained within the INPC, we need to measure the rates of our PI algorithm. Our study demonstrates that the ZIP code matching process needs to be improved by applying a limitation of 5 digits in ZIP code instead of using ZIP+4 code. Non-ZIP code identifiers may be a better choice due to inaccuracies and changes of the ZIP code in a patient’s record.

Figure 2.

Patient Identification Process between I-EMS & INPC

Figure 3.

Patient Identification Process Algorithm

Figure 4.

Analysis of Current Usage

Figure 5.

Analysis of No result

Figure 6.

ZIP code mismatch in digit