Splicing a CRM and an EHR without double booking

Two systems disagree about the same person. The EHR has a consult on Tuesday at 10:30. The CRM still says the opportunity is open and unbooked. Or the CRM says booked and the EHR has nothing, because the agent took a call while typing. Neither system is wrong. Each one recorded exactly what it was told, and it was told different things at different times by a person with four tabs open.

Double booking is the same failure seen from the other side. The agent searches the EHR, does not find the patient under a slightly different spelling, and creates a second record. Now the clinic has two profiles for one person, one with the appointment and one with the payment history.

Both problems have the same root. The write to the EHR and the update to the CRM were two separate actions, taken by a person, in an order the person chose. Fix the order and the count, and the problems go away.

Step one: resolve identity before anything writes

The EHR is the identity authority. Before a booking can happen, DialSplice asks the system of record whether this contact already exists, with a match score, and whether they exist at more than one location. The agent sees the answer in the record header: “EHR record found · Northgate · Riverside”.

If the match is clean, the booking writes to the existing profile. If there is no match, a new profile is created, once, from the booking. If the match is ambiguous, it is held for a person. The workspace does not guess, and it does not let the agent guess either. An ambiguous identity is a reconciliation item, not a coin flip.

This is also where scope applies. A contact seen at two locations shows both histories only to roles scoped to both. The agent at Northgate does not create a duplicate at Riverside because they could not see the Riverside record; the system saw it and either surfaced it under scope or held it.

Step two: the write is one event

When the agent clicks Book, the booking is a single external effect, journaled once before it is sent. If the EHR confirms, the ledger row completes. If the EHR returns something ambiguous, such as a timeout or a partial response, the effect enters reconciliation. It is never blindly retried, because a blind retry is how a system that timed out on a successful create ends up creating twice.

Idempotency is the technical name for “this can be retried safely, because the second attempt will be recognised as the first”. Reconciliation is what happens when the system cannot yet tell whether the first attempt landed. The manager desk shows these as “Reconciliation holds”, with a count and a button to release them once a person has looked.

Step three: the CRM is updated from the same event

Here is the part that ends the disagreement. The CRM update is not a second action the agent takes. It is a consequence of the same booking event that wrote to the EHR. One event, two destinations, one source of truth about whether it happened.

On the CRM side that means the opportunity moves stage, the booking confirmation lands on the contact timeline, and the disposition “Booked” is written to the record. The agent did none of that by hand. They set one disposition, and the policy did the rest.

The repeat-lead rule sits alongside this. A returning contact updates the open opportunity; a new opportunity is created only after the previous one closed or was abandoned. So the CRM does not fill with duplicate leads for the same person any more than the EHR fills with duplicate profiles.

What each system keeps

None of this moves the appointment out of the EHR or the lead out of the CRM. With the connectors supported today, Zenoti still owns the appointment, the patient record, and the payment. HighLevel still owns the lead, the opportunity, and the complete customer-interaction record. DialSplice holds the work item, the scope, the timestamps, the disposition, and the event hash. It reads identity from your systems under your scopes; it does not copy identity into its own store.

That split is what keeps a compliance review short. The ledger can show that a booking happened, when, by whom, at which location, and that the CRM was updated from the same event. It cannot show clinical notes, because it never had them. Notes written back to the patient record are outcome notes, never transcripts.

Reading it back

Once the booking is an event, show rate becomes a fact rather than a report. Kept, cancelled, and no-show outcomes are read back from the EHR and tied to the call that produced the booking. In the illustrative analytics fixture, that is a funnel of 412 attempts, 156 connected, 42 scheduled, 34 showed, with the note “read back from your system of record”. The number is the EHR’s number, connected to the ledger’s row.

The same applies to payments. Taking a deposit or updating the card on file happens from the workspace, through the system of record, and lands in the ledger like every other action. The agent never opens a second screen to do it, and the EHR remains the place where the money is recorded.

What to ask your vendor

• Which system is the identity authority, and does a booking check it before the write?
• What happens to an ambiguous patient match: held, guessed, or duplicated?
• Is the CRM updated from the booking event, or by the agent as a second step?
• What does the system do when the EHR times out mid-write: retry, or reconcile?
• Which system holds clinical notes, and can the middleware ever read them?