HI499 Unit 5 Root Cause Analysis Example

Found in the Exam Room, Made at Launch: A Unit 5 Root Cause Analysis Tracing Self-Scheduling Duplicates to One Matching Setting

[Student Name]

Purdue University Global

HI499: Bachelor's Capstone in Health Information Management

Unit 5 Root Cause Analysis

[Instructor Name]

[Date]

Callowfield Health, the sampled pairs and every figure are composite; the sources cited are real.

Where the Problem Surfaces and Where It Is Made

The data review showed that 61 percent of the tool's duplicates are found by staff at a patient's next visit, after a median of 19 days. That is where the problem surfaces. It is not where the problem is made. A front desk worker who notices a missing history is catching an error that happened at home, on the booking screen, weeks earlier. This analysis is about production: what happens inside the self-scheduling tool between the moment a patient enters a name and the moment a record exists.

Method

I drew a random sample of 120 confirmed pairs from the past twelve months in which the newer record had been created by the tool. For each pair, a data integrity specialist and I compared the two records field by field and recorded every difference. The application analyst then pulled the matching engine's log entry for the newer record, which shows the score the engine gave the best existing candidate and the action the tool took. I also mapped the tool's matching step with the analyst, and walked one composite case back through five links of why. Candidate causes were gathered from the two specialists, two front desk supervisors, the analyst and the patient access director before any evidence was examined, so the field of causes was not shaped by what I expected to find.

The Field of Candidate Causes

Candidate causes were grouped under five headings and then marked against the evidence:

1. People: patients mistyping details (partly supported); patients unaware they already have a record (supported, but expected and not controllable); staff error (unsupported, since no staff member touches these records at creation).

2. Process: no review step between a possible match and record creation (supported).

3. Technology: the tool's handling of uncertain matches (supported); the engine's scoring weights (partly supported).

4. Data: addresses entered in many formats (supported); surnames that changed (supported); phone numbers and email addresses that changed (supported).

5. Policy: no written rule on what the tool should do with uncertain matches (supported).

What Differed Between Paired Records

Ranking the 120 pairs by the field that differed most often between the two records gives this order, where each pair is counted once by its main difference:

1. Name variants, such as a nickname, a former surname or a hyphenated surname entered one way: 46 pairs.

2. A new phone number or email address: 29 pairs.

3. A changed or differently formatted address: 21 pairs.

4. A mistyped birth date: 14 pairs.

5. Other differences: 10 pairs.

Names and contact details account for 75 of the 120. These are ordinary differences between two honest entries for the same person, the kind that published research identifies as the main source of matching failure (Just et al., 2016). Only the 14 birth date errors look like careless typing, and even several of those were a patient entering the booking date in the birth date field.

What the Engine Saw

The decisive figure came from the engine's log. In 97 of the 120 pairs, the engine had scored the existing record in its uncertain band: high enough to flag it as a likely match, too low to accept automatically. In 18 pairs the score was below the band, so the engine treated the two as different people. In 5 the score was above the band; these turned out to be pairs where the tool had failed to attach the booking to the existing record for a technical reason now fixed. In four of every five sampled pairs, the matching engine found the patient's existing record and the tool then built a new one anyway. The process map shows why. When a registration clerk's screen meets an uncertain match, the system stops and shows the clerk the candidate. When the self-scheduling tool meets one, there is no clerk. At launch, the configuration offered two choices for that branch: hold the booking for staff review, or create a new record so the booking could go through. The second was chosen, according to the analyst, so patients would not see a delay or an error and abandon the booking. No one recorded the decision as a risk, and no written policy governed it.

One Why-Chain

A composite patient arrives at a dermatology clinic and mentions a penicillin allergy at intake, yet her chart lists none. Why? She is on a new record created eleven days earlier. Why was a new record created? She booked online using her married surname, while her original record carried her maiden name. Why did the tool not use her original record? The engine scored it in the uncertain band, matching her birth date and phone but not her surname. Why did an uncertain match create a record? The tool was configured at launch to create a record whenever a match was uncertain. Why was it configured that way? Booking completion was the only goal set for the launch, and the cost of duplicates was not considered.

Causes Considered and Rejected

Patient carelessness was rejected as a root cause. Most differences were legitimate changes in name or contact details, and patients cannot be expected to know how a record was keyed years ago. Registration staff were rejected because no staff member is involved in creating these records. The engine's scoring weights were judged a contributing factor, since a better address comparison might move some pairs out of the uncertain band, but not the root cause: even a perfect scorer will produce uncertain cases, and the question is what happens to them. Critics of root cause analysis in health care warn that investigations often stop at the easiest person to blame or produce weak fixes such as reminders (Peerally et al., 2017), and the field has long questioned how well such analyses lead to lasting change (Wu et al., 2008). This analysis tried to avoid both by asking what system decision made the error possible.

Root Cause and Contributing Factors

Root cause: the self-scheduling tool sends possible matches in the uncertain band to automatic record creation instead of human review, a setting chosen at launch to protect booking completion, with no policy or risk review behind it. Contributing factors: addresses accepted in any format, which pushes some true matches into the uncertain band; no prompt for a former surname; and no measure of duplicates among the launch goals.

What This Means for the Fix

A fix that only reminds patients to type carefully would address 14 of 120 pairs at most. A fix that routes uncertain matches to a staff queue would address up to 97, and standardizing addresses would reduce how many pairs fall into that band. Matching reviews describe exactly this combination of better data entry and human review of uncertain scores (Riplinger et al., 2020). Before any change is recommended, Unit 6 will test each option against privacy, breach, record and state rules.

References

Just, B. H., Marc, D., Munns, M., & Sandefer, R. (2016). Why patient matching is a challenge: Research on master patient index (MPI) data discrepancies in key identifying fields. Perspectives in Health Information Management, 13(Spring), 1e.

Peerally, M. F., Carr, S., Waring, J., & Dixon-Woods, M. (2017). The problem with root cause analysis. BMJ Quality & Safety, 26(5), 417-422. https://doi.org/10.1136/bmjqs-2016-005511

Riplinger, L., Piera-Jiménez, J., & Dooling, J. P. (2020). Patient identification techniques: Approaches, implications, and findings. Yearbook of Medical Informatics, 29(1), 81-86. https://doi.org/10.1055/s-0040-1701984

Wu, A. W., Lipshutz, A. K. M., & Pronovost, P. J. (2008). Effectiveness and efficiency of root cause analysis in medicine. JAMA, 299(6), 685-687. https://doi.org/10.1001/jama.299.6.685