CASE STUDY · HEALTHCARE AI & CLINICAL WORKFLOW AUTOMATION
Connecting three EHR systems into one patient view.
- 12 minutesChart lookup down from 12 minutes to 2 minutes
- 20%Duplicate patient records down 20%
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised multi-site clinic group. Name withheld under confidentiality.
A mapping layer and patient-matching rules feeding a single patient summary.
- 1Three EHRs with different formats, and staff re-keying data between them.
- 2The group had grown by acquiring clinics, and each came with its own EHR.
- 3A patient who visited two sites had two or three partial records.
- 4Staff looked up charts in each system in turn and sometimes typed key details from one into another.
- 5Names, dates of birth and identifiers were stored in different formats.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01Our first matching rules treated family members who shared an address, a phone number and similar names as the same person
In particular, parents and children with the same name were wrongly proposed for merging. We caught it in the review sessions, before any merge was applied. We changed the rules so that a date of birth mismatch blocks an automatic match, added a clear display for "possible match, needs review" and added test cases for families.
- PROBLEM 02We changed the rules so that a date of birth mismatch blocks an automatic match, added a clear display for "possible match, needs review" and added test cases for families
- PROBLEM 03A second hurdle was data quality
One of the three EHRs stored dates of birth in a free-text field, and some entries held typing errors or only a year. Matching on that field gave poor results. We added a cleaning step that standardises dates where the meaning is clear and flags the rest as "unverified", so they count for less in matching.
- PROBLEM 04We also gave the front desk a simple way to correct the source record, so the problem shrinks over time instead of being hidden by the mapping layer
03 · THE PROCESS
How we ran it.
We worked in stages so that clinical staff never relied on something unproven.
- 01Discovery
we listed the data each system held, the interfaces it offered and the fields staff used most.
- 02Mapping
we agreed a common patient summary with clinicians and defined how each field in each system maps to it.
- 03Matching
we built and tuned the rules that decide whether two records belong to the same person, reviewing borderline cases with the front-desk team.
- 04Pilot and rollout
one site first, read-only, then the other sites once the summary had been checked against real charts.
We held a weekly session with front-desk staff and a clinical lead, who reviewed the matches the system was unsure about.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Staff open one summary instead of searching three systems.
- NOW 02
A named person reviews the uncertain matches each week, so duplicates are caught early and not left to build up.
- NOW 03
When the group adds a new clinic, the mapping layer gives them a defined way to bring its system in, not another round of manual re-keying.
- 12 minutes
Chart lookup down from 12 minutes to 2 minutes
- 20%
Duplicate patient records down 20%
05 · WHAT WE BUILT
How it works.
- Each EHR is connected through its own adapter that reads data using the interface it supports, including standard HL7 and FHIR messages where available.
- A mapping layer converts each system's formats into one common model, including dates, names, codes and units.
- Matching uses deterministic rules on strong identifiers first.Weaker matches are scored and sent to a person to confirm. The system never merges two records on a weak match alone.
- The patient summary is read-only and shows the source system for every item, so staff can trace it back.
- Access is by role and every view is logged.
- Monitoring and controls
- Handover
- We trained the front-desk leads on the review queue, documented each field mapping and left a runbook for adding a new site or a new field. The group's integration engineer made the first mapping change under our supervision.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- Three EHRs with different formats, and staff re-keying data between them.
- What did Brandsmashers build?
- A mapping layer and patient-matching rules feeding a single patient summary.
- How was the work run?
- We worked in stages so that clinical staff never relied on something unproven.
- What were the results?
- Chart lookup down from 12 minutes to 2 minutes; duplicate patient records down 20%.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
