The EHR stays.
The product goes on top.
A counseling practice needed a mobile app for its therapists. The patient records lived in an EHR nobody was allowed to replace, and no patient data was allowed to leave it. So we built the product as a layer on top of the record system instead of a second system beside it.
0 clinical records
Stored in our database — referrals and clinicians only
60s sync cycle
Open referrals read from the record system every minute
5 / 10 / state
Referral escalation tiers by distance, then statewide
1 tap to assigned
From push notification to accepted case in the EHR
The problem
Referrals arrive one at a time, from a discharge planner at a nursing facility, an activities director at an assisted-living community, or an adult child worried about a parent. Behind each one is a real person at a real address who needs a therapist to drive to them.
A referral is only useful to a clinician who is close enough to get there, licensed in that state, and not already full. Matching those three conditions used to be office work: an intake coordinator sat with a list of therapists and a phone, and called around until someone said yes.
That is slow at the exact moment speed matters, and it favours whoever the coordinator happens to think of first. The therapists, meanwhile, had no way of seeing what work was available near them that day.
Why this could not be solved with a new system
The practice kept its clinical records in a practice-management and EHR system built for behavioral health. That is where a referral belongs.
Two things were off the table from the first conversation. Replacing the EHR was out, because no practice rips out its clinical record system to get a better app. Copying patient records into a second database was out too, because that doubles the number of places the data can leak from.
What we built
A service reads the practice's open referrals out of the EHR once a minute and turns each street address into a map point. It then offers the referral to the clinicians who can actually take it: first the ones within five miles, then within ten, then anyone in the state.
Clinicians get a push notification and accept in one tap. The platform writes that acceptance straight back into the EHR, so the clinical record stays the single source of truth and nobody re-types anything.
Around that sits a back office. The practice watches coverage state by state, messages clinicians in chosen states, publishes reference material and retires people from the rotation.
What our database holds: clinicians, zip codes, the referrals currently open, statistics and logs.
What it does not hold: a single clinical record.
How the two systems divide the work
One minute behind the record system
The hard part
One referral goes out to many phones at once, so two therapists can tap ACCEPT in the same second. Only one of them can have it, and the answer has to be right the first time, because whoever gets it is going to drive somewhere.
Most teams solve that with a lock in their own database. We could not, because our database is not the one that decides anything. Someone in the office can claim the same referral directly inside the EHR, and our app would never hear about it.
So the final check and the assignment both happen inside the EHR. The app asks whether the referral is still unclaimed, the EHR answers, and the EHR makes the assignment. One therapist gets a confirmation. The other gets a message saying another therapist took it, and the card disappears. A referral claimed in the office disappears from the app on the next sync.
Two therapists, one referral
Offered to every eligible phone, and still not double-booked
Privacy built into the flow
While a therapist is deciding, the card shows gender, age, language, residence type and distance. It does not show a name.
The name, address and phone number appear only after they accept.
This is not a permissions setting or a hidden field. The platform pulls the identifying details from the EHR at the moment of acceptance. Before that moment nobody had sent them to the phone, so there was nothing on the device to hide.
Anonymous until accepted
A name only after they accept
What the office got
A live coverage map
A US map with a pin for every active clinician, labelled with how many referrals that clinician will currently accept.
State-by-state gaps
A coverage panel where Nebraska (ref: 4, clin: 0) states a business problem in four characters.
A silent ban
The account keeps working normally from the clinician’s side but stops receiving offers, so the practice can retire someone from the rotation without a confrontation.
Who is actually working
A record of who is opening the app, and of what happened to every referral.
Messages by state
A message that goes to two states and not the other three.
Transferable
Three things worth copying
Confine the integration to one file
The whole EHR link runs through a single gateway: one vendor endpoint, called with a different command depending on what we need. When you cannot change the other system, every assumption you make about it should live in one file you can re-point the day the vendor changes something.
Make geography a real data type
Every clinician and every referral is stored as a real coordinate in a spatially indexed database. That is the only reason the platform can answer who is within five miles of an address fast enough to do it every sixty seconds. Zip-code lookup tables would have been either approximate or slow, and the tiered routing could not have existed.
Ship the business rules as settings
The escalation delay, the active radius tiers and the list of excluded accounts are all settings. When the practice decided referrals should go statewide immediately, that was a settings change rather than a development project.
Questions we get asked
Before you decide between a layer and a rewrite
Is a layer just a temporary fix until we replace the old system?
Sometimes, and that is a fine reason to build one. But this platform ran for five years and the EHR is still there. A layer can be permanent architecture, as long as the system underneath does its job well and only its interface is wrong.
What happens when the vendor changes their interface?
You re-point one file. That is the whole reason for keeping the integration inside a single gateway. It is also why we build a simulator mode that runs the platform against fabricated data, so the team can test without touching live patient records.
Does this mean less work than a rewrite?
Less risk, not always less work. The routing engine, the offer tiers, the contention handling and the privacy flow were all real engineering. What you avoid is migrating clinical data and retraining the office on a new record system, and that is where rewrites of this kind usually fail.
Can the client change the rules themselves?
In this case yes, for the parts that change often: radii, escalation timing and who is excluded. Decide early which rules become settings, because retrofitting that later is expensive.
Have a system you cannot replace?
Tell us what it is and what it will not let you do. We will tell you whether a layer is the right answer, and what building one would take.