Dev
Patient matching without creating duplicate charts
The failure mode nobody demos: an agent that books correctly and leaves you two records for the same person.
An agent that books flawlessly and creates a second chart for an existing patient has not saved you any work. It has moved the work to whoever reconciles records, and that person is usually more expensive than the receptionist.
Duplicate creation is the quiet failure mode of automated scheduling, and it happens because matching is genuinely hard. People give different phone numbers than the one on file. They shorten their names. They give a partner's mobile. They moved house two years ago and never told anyone. A naive exact match on name plus date of birth will miss a meaningful proportion of returning patients, and every miss becomes a new record.
The rule we apply is that creation is a last resort, not a default. The agent searches the source system on the identifiers it has, and where the match is confident it uses the existing record - existing MRN, existing history, existing everything. Where the match is ambiguous rather than absent, it does not guess: it collects enough to disambiguate on the call, because the patient is right there and can simply be asked. Only a genuine no-match creates anything.
This matters more in some systems than others. In Epic the chart is the organising object and a duplicate propagates outward into every department that touches it. In smaller practice management systems the blast radius is narrower but the cleanup is still manual. Either way the defensible default is the same: match first, ask second, create last.
The platform covers the architecture at a higher level, integrations lists what we connect to, and trust and compliance has the data handling detail your security review will ask for.
How it connects
Real time
Written while the patient is still on the line. Every write logged and reversible.
