2care.ai

Dev

What an AI Escalation Should Contain

An escalation is a payload, not a button. See what 2care puts in a handover, how fast it routes, and why it sends no assessment.

Bala Guhanesh
DevEngineering

Summarize with

Key takeaways

  • An escalation is a payload, not a button. 2care attaches the transcript, resolved identity, trigger and call state, so the clinician never restarts from zero.
  • 2care resolves urgency on every call. Routine resolves on the line, an emergency reaches a human in about 3 seconds, a clinical question in about 4.
  • The trigger is recorded on every handover, so a practice can read a month of escalations and tune the threshold instead of trusting it.
  • 2care attaches no assessment, no severity score and no summary, because producing a clinical judgement is exactly what the agent is built not to do.
  • A handover carrying a transcript and a patient identity is PHI in motion, so it makes 2care a business associate under a signed BAA.
What an AI Escalation Should Contain

An escalation is a payload, not a button. The question that decides whether it was worth anything is what arrives with the call. If a clinician picks up and has to ask the patient to start again, the handover moved the call without moving any of the information in it.

We build the part of 2care that decides what travels with a handover, and the thing we would most want a practice to interrogate is not how fast an escalation happens. It is what is in it. Speed is easy to demonstrate and easy to compare. Contents are neither, which is why they get less attention and matter more.

  1. 0:00The call turns clinical
  2. 0:02The agent stops responding to the content
  3. 0:04Transcript, identity and trigger are assembled
  4. 0:09Routing picks the destination from the practice's own rules
  5. 0:18A named person picks up with the context already on screen

Those are design targets, not measured averages. The ordering is the point: the payload is assembled before the destination is chosen, not after.

The default in most phone systems is a transfer that carries nothing. The call arrives at a clinician as a ringing line.

The immediate cost is repetition. The patient has just described something, often with difficulty, and now has to do it again. That is unpleasant, and worse, it is lossy: second tellings are shorter, more composed, and frequently drop the detail that made the first one alarming.

There is a second cost that is less obvious. The clinician receiving a bare transfer has no idea why the call was escalated. They cannot tell whether the system passed it on because of something specific or because it did not understand, so they reconstruct not only the clinical content but the reason it reached them, from a patient who does not know either.

The patient learns something too, and it is the wrong thing: that describing a symptom to the first person got them nowhere. The second telling is then guarded as well as shorter, which is the opposite of what a clinician needs from a caller who was alarmed a minute ago.

The four things worth carrying

The transcript. What was actually said, in the caller's words, not a summary. A summary is an interpretation, and an interpretation of a symptom description is exactly the thing that should not be produced by a system not permitted to form clinical views.

The resolved identity. Which patient this is, matched against the practice record before the handover rather than confirmed afterwards. Without it the clinician starts by taking a name and searching.

The trigger. The specific phrase or condition that caused the escalation. This is the field most often missing and the one that makes the rest reviewable.

The state of the call. What had already been arranged before it turned: the appointment being booked, the request being made. If the caller was rescheduling a follow-up when they mentioned the symptom, that half-finished booking travels too, so the clinician sees what the call was for and nobody has to reconstruct it. Otherwise the administrative half of the call is lost and the patient rings back about it.

Why the trigger field matters most

Recording what caused the escalation turns a promise into something a practice can audit.

A vendor can assert that its agent escalates appropriately. With the trigger recorded on every handover, a practice does not have to take that on trust: it can read a month of escalations and see what set them off. A trigger firing constantly on ordinary calls is a threshold set too broadly. A category of call that never escalates and probably should is visible by its absence. This is also what makes the boundary improvable, because most practices set their first thresholds badly, in both directions, and without the trigger recorded there is no way to find out which way.

FieldBare transferMessage-taking service2care escalation
What the patient saidNo, they repeat itAn operator's paraphraseFull transcript
Which patientNoName, usuallyResolved against the record
Why it escalatedNoSometimesThe specific trigger
What was already arrangedNoRarelyCarried with the handover

The middle column deserves fairness. A good answering-service operator writes a useful note, and a note written by a person who heard the call carries something a transcript does not: an impression of how the caller sounded. What it lacks is fidelity, because it is a paraphrase, and reviewability, because the operator's judgement about what to pass on is recorded nowhere.

How fast, and where it goes

2care resolves urgency as one of the four things it understands on every call, and the Escalation Engine routes on it against triggers the practice configures. The routing runs to three lanes with their own targets.

A routine call is resolved on the line, in zero seconds of anyone else's time. An emergency, a described red flag like chest pain or stroke signs, goes straight to a human in about 3 seconds. A call that turns on clinical judgement goes to a nurse or provider queue in about 4 seconds, with the transcript and resolved identity attached.

The lanes are not single destinations. Each carries a fallback: if the first named recipient does not answer within a set number of rings, the call moves to the next link in the chain, and the last link is a person who is always reachable rather than a voicemail box. A routing chain that quietly ends in voicemail is the most common gap we find in a setup, and it stays invisible until the one night it matters.

Contents are half the problem. Destination is the other half, and it belongs to the practice rather than the vendor. A payload assembled perfectly and delivered to a voicemail box has achieved nothing, and that is a more common failure than it sounds, because the routing destination is configured once during setup by whoever was available and rarely revisited. Four questions settle it before anything is switched on: who receives an escalation in hours, who receives one at three in the morning, what happens if they do not answer, and how long the fallback takes.

What 2care attaches, and what it refuses to

Every escalation carries the transcript, the patient identity resolved against the practice record, the trigger, and the state of the call so far. Routing destinations and out-of-hours rules are the practice's, not 2care's, and every escalation logs what triggered it so the threshold stays auditable and tunable rather than trusted.

What 2care does not attach is an assessment. There is no severity score, no prioritisation, and no summary of what the system thinks is happening. That is a deliberate absence: producing a judgement about clinical content is the thing the agent is built not to do, and attaching one to a handover would smuggle it back in through a side door. See the clinical boundary for where that line sits.

The clinician receives what the patient said and decides. That division is the whole design, and it is why the routing lives in triage and routing rather than in a model's opinion of the call.

Why the payload is a compliance artefact too

An escalation carrying a transcript and a resolved patient identity is protected health information moving between systems, and the contractual position follows from that.

Under HHS guidance a vendor is a business associate rather than a conduit when it creates, receives or maintains protected health information rather than merely transmitting it transiently. Assembling a transcript, matching it to a record and storing the trigger is all three.

2care signs a business associate agreement, encrypts that content with AES-256 at rest and TLS 1.2 or better in transit, and covers EU and UK deployments under GDPR and Indian ones under DPDP. The practical question for a practice is not whether an agreement exists but what it covers, set out on the compliance page.

4

fields in a complete handover: transcript, identity, trigger, call state

3

seconds to a human on an emergency

4

seconds to a nurse queue on a clinical question

0

fields a bare ring transfer carries

Where richer escalations change nothing

Three situations, and the first is common enough to check first.

A practice with no clear destination. The payload arrives somewhere nobody is watching, and the contents are irrelevant. Fixing where escalations land is the prerequisite and it costs nothing.

A practice already drowning in escalations. That is a threshold problem, not a contents problem, and more context on each of two hundred handovers a week does not make two hundred sustainable.

A receiving clinician who cannot open the practice system, for example on a personal mobile out of hours. The resolved identity is less useful than it looks, and it is worth checking what the receiving end can actually read before assuming the payload is usable.

Frequently asked questions

Is the transcript summarised before it reaches a clinician?

No. The clinician gets what was said. A summary is an interpretation, and interpreting a symptom description is outside what the agent is permitted to do, so the raw transcript travels instead of a paraphrase of it.

What if the patient said something before the escalation triggered?

The whole call travels, not the fragment after the trigger. The administrative first half is frequently where the useful context is, and dropping it is how a patient ends up ringing back to redo the booking they had half finished.

Can we review escalations afterwards?

Yes, and it is the main reason the trigger is recorded. A monthly read of what caused escalations is the practical way to tell whether the threshold is set correctly, and to move it in either direction with evidence.

Who decides where an escalation goes?

The practice. Destinations, out-of-hours routes and fallbacks are configured per practice, because a dialysis unit and a paediatric list need different answers, and 2care does not overwrite that judgement with a default.

Does the escalation payload fall under HIPAA?

Yes. A transcript matched to a patient record is protected health information being created and maintained, which makes 2care a business associate. A signed agreement is in place, and it covers the storage and handling of that content.

Ask what arrives at two in the morning

Ask whoever currently receives your out-of-hours escalations what they actually get. Not what the process document says: what appears on their phone at two in the morning.

Then ask how often they have had to ring the patient back to ask what the call was about. That number is the cost of an empty payload, and it is usually higher than anyone at the practice expects.

See how the lanes are set for nights and weekends in after-hours cover, or hear a handover assembled on a live call when you book a demo.

See it answer your practice's calls.

30 minutes, on your own call flows. No commitment.

Book Demo

More stories

All posts

Get every new post by email

Notes from the front desk, sent as they publish - every Tuesday and Friday. No filler.

I agree to receive the 2Care AI newsletter. Unsubscribe anytime.