A safe AI handover tool does one thing: it turns the handover a clinician already gives out loud into a structured SBAR note, shows which fields were not covered, and asks the clinician to review it and sign it before anything is stored. It transcribes, structures and retrieves. It never diagnoses, never recommends, never files a note on its own, and never sends identifiable speech to a general-purpose model. Everything below follows from that sentence: the evidence for why handover needs its own tool, the requirements, the lines a safe tool does not cross, and the questions to put to any vendor, including us.
Why handover, not the consultation
Every ambient scribe on the market documents a doctor-patient consultation and produces prose. Handover is a different event. It is clinician to clinician, it has a fixed structure, it is given out loud and written up later from memory at a desk, and whatever falls out between the bedside and the desk falls out silently.
The loss is measured. A prospective study of handovers among staff intensivists in a thirty-bed tertiary unit followed 352 patient encounters across 44 day-to-night handovers. The incoming clinicians correctly identified 454 of 857 diagnoses, which is 53%, and 123 of 304 goals of treatment, which is 40%, immediately after the handover. Gaps were widest for neurological diagnoses. The authors' conclusion was that diagnoses and goals are either not conveyed or not retained in roughly half the cases.
Structure helps, and that is also measured. A 2026 closed-loop quality-improvement study audited 92 handover events before and after introducing SBAR templates, education and feedback. Documentation of the escalation plan went from 0% to 97.7%, response to treatment from 2.1% to 79.5%, urgent issues from 4.2% to 100%, vital signs from 16.7% to 86.4%. It was a single-centre study with a small sample and no control group, and the authors say so. But the direction is not in doubt: when the structure is enforced, the record gets complete. The cost is that someone has to write it, which is the part that gets skipped at the end of a shift.
That is the gap a voice-to-SBAR tool fills: the structure of the template, without the typing.
What the evidence says about AI documentation in Arabic and English
The question a clinician asks first is whether the machine can be trusted with the language. There is now peer-reviewed evidence on that, for consultations. A prospective evaluation of a bilingual Arabic-English ambient scribe, published in March 2026, tested the system on 55 real consultations, 40 in Arabic and 15 in English, across outpatient, inpatient and primary care in one health cluster. Physician reviewers scored the Arabic notes 42.4 out of 45 on a modified PDQI-9 rubric, with the highest domain scores for internal consistency at 4.94 of 5, comprehensibility at 4.89 and absence of hallucination at 4.87. Of 22 physicians surveyed, 86.4% strongly agreed the summaries were comprehensive and 86.4% strongly agreed on the potential time saving. The dataset covered a wide range of Arabic dialects and non-native speech.
Read the limitations as carefully as the results. The study was single-arm with no comparator, the real-world stage was limited to family medicine, the evaluators came from the same health cluster, and no systematic safety audit was performed. So: note quality in Arabic is achievable, and the safety audit is the open question. A handover tool should be designed so the safety audit is built in, not bolted on. That is what the requirements below do.
The requirements
| It must | It must never | How you verify it |
|---|---|---|
| Fill a fixed schema: Situation, Background, Assessment, Recommendation, with named fields under each | Produce free prose that looks complete | Ask for the schema as a document. Feed a handover that omits the escalation plan and watch where it goes |
| Leave a field nobody covered visibly empty | Fill a gap fluently from context | Give it a handover with one field deliberately missing. A safe tool shows the blank |
| Require two human review gates, then a signature, before storing anything as a handover | Auto-file a draft | Try to leave the screen without signing. The draft should not become a record |
| Keep an audit trail: raw transcript, structured draft, every edit, the signature, with timestamps, in an append-only log the unit owns | Overwrite the draft in place | Ask to see the trail for a test note |
| Strip identifiers before any text reaches a language model, and document the model call as a data transfer | Send raw audio or identifiable text to a general API | Ask where the de-identification runs and what the model receives |
| Handle Arabic-English code-switching with a dedicated clean-up stage for clinical terms inside Arabic speech, tested on real patterns | Claim "supports Arabic" | Speak a mixed sentence with three English drug and device names. Read the output |
| Export the signed note where the unit already keeps records: Word, PDF, the messaging channel the unit uses | Lock the note inside the product | Export a test note |
| Transcribe, structure and retrieve only | Diagnose, suggest, recommend, or score risk | Ask whether any feature proposes clinical content. If yes, it is a different product with different regulation |
| Run only on simulated cases until in-country hosting and the de-identification layer are live | Pilot on real patients while compliance is open | Ask for the compliance page and its dated status per item |
The five checks
The table above is the long form of the standard every AI system we build runs inside.
- The model never decides. It transcribes, structures and retrieves; a person reviews and signs.
- Data is stripped before it leaves. De-identification before any model call; hosting where the unit's law expects it; the transfer documented.
- Output is validated against a schema. A fixed JSON contract, not prose; a field nobody covered stays empty.
- Every step leaves a trail. Raw input to signed note, append-only, owned by the unit.
- Both languages, including mixed. Code-switching handled explicitly and tested.
The four fears, and which requirement answers each
When we researched the buyers of our own product, four fears came up in the clinicians' own words, and each one now owns a requirement.
- "Something will be lost in the handoff and I will not know." The visible empty field. The tool's job is to show the gap, not hide it.
- "I will be blamed and cannot prove otherwise." The audit trail. The record protects the person who made it, because it shows what was said, what was edited, and who signed.
- "AI will make me worse at my job." The tool sells typing, never thinking. No diagnosis, no suggestion. We removed a differential-diagnosis feature from our own product to keep it a documentation tool.
- "It will mangle Arabic-English code-switching." The dedicated clean-up stage, stated specifically, because a vague claim reads as a lie to this audience.
Data residency and the law
Health data has the strictest expectations of any category. The working pattern is that the application, its logs and any vector store are hosted in the jurisdiction the unit's data-protection law expects, and the model call is documented as a transfer with a written risk assessment. Regulators' AI guidance adds two things every deployment should do regardless: disclose that the person is interacting with an AI system, and provide a human path. A security page that names each regulation and its honest status, including "not yet", is worth more to a quality director than a compliance badge.
What we built, and what we have not claimed
Critical Care Copilot is our own product and the reference implementation of the requirements above. A clinician speaks the shift handover; the pipeline transcribes and structures it through a language model behind a de-identification layer, annotates clinical entities with Apache cTAKES, validates the result against the SBAR JSON schema, and presents it for two rounds of review and a signature. The signed note exports to Word, PDF and the messaging channel the unit uses. Every step is logged.
Fifteen clinicians have tested it on simulated cases. That is the only proof line we use. Usage and outcome results are not yet available, paid acquisition is on hold until the compliance items that block it are closed, and none of that is hidden on the product's own site.
Ten questions for any vendor
- Show me the schema. Which fields exist under each SBAR heading?
- What happens to a field I did not mention?
- Can a draft become a record without my signature?
- Where does de-identification run, and what does the model receive?
- Where is the data hosted, and where is the transfer risk assessment?
- Speak a code-switched sentence. What comes out?
- Does any feature propose clinical content?
- Where is the audit trail, and who owns it?
- How does the signed note get into our existing record?
- What is the proof line, exactly, and what is not yet measured?
The first step
Voice to document is scoped after a workflow diagnosis, because every unit's handover has its own fields. Record one handover on a simulated case, send it through the contact page, and you get back a written map of the fields, the gaps and the safety checks, with a fixed price for the first step. If the answer is that your unit does not need a tool, the map says that too.
Sources
- Handovers among staff intensivists: a study of information loss and clinical accuracy, Critical Care Medicine, 2018. Prospective observational cohort; 352 encounters, 44 handovers.
- Improving the quality and completeness of clinical handover using the SBAR framework: a closed-loop quality improvement study, Cureus, 2026. 92 handover events, single centre.
- A bilingual Arabic-English ambient AI scribe for clinical documentation: prospective evaluation study, JMIR Medical Informatics, March 2026. 55 consultations, 22 physicians surveyed.
- Shift transition communication among nurses: a systematic review of ISBAR and SBAR-based structured handover tools, 2026.
- Enhancing ICU-to-ward handover documentation through a human factors approach, 2026.
