Why your AI scribe should not run on your phone

Ask any clinician who has used an AI scribe for more than a month and they have a story. The session where the phone rang. The one where a text notification paused the recording and nobody noticed. The group that ran long and the battery did not. The app that got backgrounded when they checked the schedule and quietly stopped listening.

The outcome is always the same. Not a worse note. No note. And a clinician writing from memory after hours, which is the exact problem the scribe was bought to solve.

What actually goes wrong

Every phone-based scribe runs inside the phone's rules, and the phone was not built to be a clinical recorder.

• Interruptions. An incoming call takes the microphone. On iOS the recording app does not get it back automatically. Some scribes recover, some do not, and the clinician cannot tell which until the note comes back short.
• Backgrounding. Switch to the calendar, the EMR, or a text, and the operating system may suspend the recording app to save battery. The scribe "ran" the whole session. It captured the first eleven minutes.
• Battery. Recording plus a screen plus a cell radio is the fastest way to drain a phone. Back-to-back sessions on a shared device is where this bites.
• Storage and updates. A full phone or a pending OS update can stop a recording from saving at all.
• The phone in the room. A phone on the table is a phone. Clients react to it. Clinicians glance at it. Neither is the therapeutic frame anyone wants.

None of this is a software bug in any particular scribe. It is what phones are.

What it costs

Take a conservative number: one lost session per clinician per month. At fifteen minutes to reconstruct a note from memory, that is three hours a year per clinician, which sounds small until you add the quality problem. A note written from memory three hours after a session is a weaker note, a less defensible note in an audit, and a note that a payer reviewer can tell was reconstructed. For a facility with twenty clinicians, the compliance exposure is the real cost, not the time.

The fix is hardware, not a better app

A dedicated recorder holds the session on the device. Not on the phone, not in a cloud. If the phone rings, the recorder does not care. If the app is backgrounded, the recorder does not care. If the battery dies, the recorder has its own. When the session ends and the device is back in range, the recording syncs and the note is generated. An interruption delays an upload. It never loses the encounter.

This is why NavixScribe now pairs with Plaud recorders. The recorder connects through Plaud's device SDK inside the NavixScribe app, so there is no Plaud app and no Plaud cloud in the path. The recording goes from the device to NavixScribe and nowhere else, then through the same pipeline that writes every other Navix note: SOAP, DAP, BIRP, GIRP, SIRP, group sessions split per client, and form-fill on custom assessments.

What to ask your scribe vendor

If you are evaluating scribes, or already on one, these five questions separate the tools built for a treatment center from the tools built for a demo.

1. What happens to the recording if my phone rings mid-session?
2. What happens if I switch to another app during the session?
3. Where does the audio live between the end of the session and the finished note?
4. Which third parties touch the audio, and do you have a BAA with each?
5. Can I record on a dedicated device instead of a phone?

If the answer to the last one is no, you are buying the phone's failure modes along with the scribe. The Plaud + NavixScribe page has the full picture on how we answer all five.

• #AI & Automation
• #NavixScribe
• #Documentation