CCI study materials
CCI study resources

Week One of a Reference Lab Interface

CCI · Put your knowledge to work in context.

All case studies

Week One of a Reference Lab Interface

A regional hospital went live six days ago with a new reference laboratory interface carrying about 1,400 results per day (HL7 v2.5.1 ORU^R01). Four problems have surfaced. First, creatinine from one send-out analyzer arrives in micromoles per liter while the EHR expects milligrams per deciliter, so a value of 707 was filed for a patient whose true creatinine was 8.0 mg/dL. Second, 14% of send-out tests have no LOINC code and map to the vendor's default "miscellaneous lab" code. Third, the abnormal flag field from one lab uses "HH" and "LL" where the EHR expects "H" and "L", so an elevated potassium did not trigger the critical-value workflow. Fourth, registration created 41 duplicate MRNs in six days when patients with existing records came in for outpatient draws, because the EMPI match threshold was set to require an exact last name and a full Social Security number, and this population often has none. The interface engine team of two is also supporting a radiology go-live next month.

1. Triage the four issues for action in the next 24-48 hours and justify the order you choose.

Read the worked answer

Rank by harm per day times invisibility. Silently wrong data outranks visibly missing data, and both outrank a classification gap.

1. Unit conversion (immediate, today). Every creatinine from that analyzer is wrong by a factor of about 88 and looks plausible on the screen. A clinician may act on 707 as if it were severe renal failure, or dismiss 0.9 when the true value is 80. Actions: suspend auto-verification from that analyzer so results hold for manual review; correct the unit mapping in the interface engine using UCUM codes; then retrospectively identify every result received since go-live, correct the filed values, and notify the ordering clinicians with a plain statement of which values were affected. Involve risk management and the laboratory medical director, and document the correction in the record.

2. Abnormal flag mismatch (immediate). A potassium that should have fired the critical-value workflow did not, which means an unknown number of critical results were delivered without escalation. Actions: map HH to H and LL to L in the engine; query all results from that lab since go-live for values exceeding critical limits regardless of flag, then contact the responsible clinicians for each. Do not simply reprocess the messages without a human check.

3. Duplicate MRNs (within 48 hours). Stop creating more before fixing the 41. Loosen the match criteria to a weighted, probabilistic set that does not require a Social Security number, and require a documented search and supervisor override before creating a new record. Do not bulk-merge until each candidate pair is reviewed; an incorrect merge attaches one patient's results to another patient's chart.

4. Missing LOINC codes (this week). Lowest immediate harm because the result is still visible, but it blocks trending, decision support, and reporting. Assign an owner and a date. Do not let it consume the team's attention while items 1 and 2 are open.

Also. Notify the laboratory medical director, risk management, and the CMIO the same day, and open a single incident record that captures all four problems so patterns are visible later.

2. What governance and technical controls would keep these mapping problems from recurring, given a two-person interface team?

Read the worked answer

The pattern is the problem. Three of the four issues are terminology or translation failures, not coding bugs: units, flags, and code systems. That points to an absent mapping and validation process rather than an unlucky build.

Controls

  • A controlled mapping repository with a named owner for each domain: units, LOINC, abnormal flags, reference ranges, and specimen codes. Version every change and record who approved it and why.
  • Fail loudly on missing units. Reject or hold messages that lack a UCUM-coded unit in the observation value field rather than defaulting to the EHR's expected unit. A held message is far cheaper than a converted one.
  • Mandatory LOINC mapping in the contract and onboarding. Each send-out test must arrive with a LOINC code; unmapped codes route to a review queue with a defined turnaround, and the queue is worked weekly, not when someone notices.
  • A standard acceptance test for every new analyzer or lab connection, run before go-live and after any change: contrived patients covering all flag variants, critical values, corrected results, cancellations, units, and a known abnormal panel. Sign-off by the laboratory and informatics, not by the vendor alone.
  • A production reconciliation report produced daily for the first 30 days and weekly thereafter: message counts by type, held or rejected messages, unmapped codes, unit mismatches, and flag values not in the expected vocabulary. Review it in a standing 15-minute huddle.
  • Change control with regression testing so a future analyzer configuration change cannot silently alter flags or units.

Given two people supporting a radiology go-live Be explicit about capacity. Escalate to the CMIO and CIO with a written statement that the current team cannot both remediate this interface and certify radiology, and ask for a decision on sequencing or temporary staffing. Also propose that certification criteria for any future interface include the reconciliation report running clean for 14 consecutive days; that converts a verbal standard into a gate the team can defend under pressure.

3. How would you handle the patient identity problem, and what monitoring would show that the EMPI change is safe?

Read the worked answer

Recognize that identity is the highest-consequence risk on the list. A duplicated record fragments the chart and hides history; an incorrect merge puts one patient's results in another's record and is far harder to detect and undo. Any change to the match threshold must be evaluated on both errors, not just the duplicate rate.

Immediate handling

  • Stop the bleeding: require a documented search by name and date of birth before any new record creation, with supervisor override and a reason code for creating anyway.
  • Review the 41 candidate pairs individually before merging. Verify with a second identifier such as date of birth plus address or phone. Merge with full audit trail so orders, results, and documents are relinked, not orphaned.
  • If an enterprise master patient index or health information exchange query is available, use it at registration rather than as an afterthought.

Redesign the match Move from the current all-or-nothing rule to a weighted, probabilistic match across name, date of birth, sex, address, and phone, with a review band for partial matches. The Social Security number requirement should be removed, not merely relaxed, because its absence in this population guarantees failures while adding little discriminating power.

Monitoring that distinguishes success from over-correction

  • Duplicate record creation rate per 1,000 registrations, tracked weekly with a target.
  • False-merge rate, which is the balancing measure: sample 20 merges per week and verify identity by chart review. Any wrong merge is a reportable safety event.
  • Override counts and reasons for new-record creation.
  • Downstream indicators: results filed to a record with no prior history, orders placed on a newly created record for a patient with a known history, and patient complaints about missing records.
  • A monthly reconciliation of duplicate pairs found by an external audit, to check that the internal process is not simply not looking.

Report the pair together. Presenting duplicate rate alone will drive the team to over-merge, which is the worse failure. The governance message should be that both charts must be right, and that loosening a threshold requires a corresponding increase in review capacity.