<strong>Illustrative example.</strong> This engagement is fictional and exists to show format and tone. Replace it with a real case study, with written client permission, or relabel this section before publishing.
Headline: Duplicate patient records cut by 88% At a glance: Independent healthcare group, 9 sites · Service Cloud + Data Cloud + FHIR integration · 22 weeks
The problem
Referrals arrived by fax, email, portal and phone into four systems that had grown up per site. The same patient could exist five times with different spellings, and the coordination team spent much of each morning working out whether two referrals were one person.
Patients felt this directly. When someone called to ask where their referral had got to, the person answering often could not tell them, because status lived in whichever site’s system had received it. Complaints about communication were the group’s largest complaint category.
An earlier attempt at consolidation had stalled because it began as a data project — a lot of ingestion, no decision it changed.
What we found
- 34,000 patient records across four systems, resolving to an estimated 19,700 people.
- Referral status expressed differently at each site; no shared definition of “accepted”.
- Consent captured at intake but not visible to outreach, creating real compliance exposure.
- Coordination staff averaged 3.4 system switches per enquiry.
- No audit log of record access at two of the four sites.
Boundary first — Clinical truth stays in the EHR. Salesforce coordinates: referral intake, triage, status, communication, consent. Written into an integration contract before any build. Identity resolution — Data Cloud ingesting all four sources, with a resolution ruleset tuned against a labelled set of 1,200 known-duplicate and known-distinct pairs. Referral workflow — One intake model, one status vocabulary agreed across sites, skills-and-capacity routing. Consent — A single consent state on the resolved profile, enforced at the point of outreach. Access and audit — Field-level security, restricted profiles, full access logging.
01 · Weeks 1–4 — Decision definition and profiling. We named the decision first: “can the person answering the phone tell a patient where their referral is, in under 30 seconds?” Every subsequent scope decision was tested against it. 02 · Weeks 5–9 — Status vocabulary. Cross-site workshops to agree eleven shared statuses. Slow, political, and the reason the rest worked. 03 · Weeks 10–15 — Ingestion and resolution. Data Cloud streams, mapping, resolution ruleset, match-rate testing against the labelled set. 04 · Weeks 16–18 — Service Cloud build. Intake, routing, console, consent enforcement, FHIR integration for demographics and appointment data. 05 · Weeks 19–20 — Parallel run. Both processes live; discrepancies reconciled daily. 06 · Weeks 21–22 — Cutover and hypercare.
Results (six months post-launch)
| Metric | Before | After |
|---|---|---|
| Estimated duplicate rate | 42% | 5% |
| Match rate (labelled test set) | — | 96.4% (false-match 0.3%) |
| Time to answer “where is my referral?” | 4–6 min, often unresolved | 22 sec median |
| System switches per enquiry | 3.4 | 1.1 |
| Communication-related complaints | baseline 100 | 39 |
What we’d do differently
We should have started the status-vocabulary workshops in week one rather than week five. Nothing technical was blocked by them, but the sequencing meant two weeks of build assumed definitions that later changed.
Start here
Tell us what your CRM is getting wrong
Thirty minutes with a consultant, not a salesperson. You’ll leave the call with at least one thing you can fix yourself — whether or not you hire us.
Prefer email? hello@zeptglobal.com · Typical reply time: one business day