Half the consultation never reached the transcript: where the audio died

Start with duration, because a short file and a complete-but-poor file are unrelated problems. Pull recorded seconds for the encounter and compare it against the booked slot. A 4-minute file against a 15-minute appointment means capture stopped and you are looking for where. A 14-minute file against the same appointment means capture ran and something else — distance, overlap, a drape over the phone — cost you the content. Teams that skip this comparison spend a week on microphone settings for a problem that was an upload queue.

Once you know which, the shape of the gap names the cause. There are 4, and each leaves a different signature in the file and in the client logs. None of this is about which microphone to buy — a separate question answered in whether the microphone in the room actually matters.

Read the shape of the gap before you read the logs

The 4th row is the one people misread as the 1st. Both end the audio, but a lock-screen truncation is silent in the logs while an interruption is loud in them — the system tells the app it is losing the input. If the app does not act on that message, capture ends and the clinician has no idea until review.

The clean cut: the operating system reclaimed the microphone

A consultation app that records while the clinician does anything else on the phone is asking the platform for a privilege, not for a permission, and both mobile platforms grant it narrowly. On Android, continuing to capture from the background requires a foreground service declared with the microphone service type — `android:foregroundServiceType="microphone"` in the manifest, the FOREGROUND_SERVICE_MICROPHONE permission, and the RECORD_AUDIO runtime permission granted by the user. Android's own documentation is explicit that RECORD_AUDIO is subject to while-in-use restrictions: the app cannot create a microphone foreground service while it is already in the background, and cannot start one from a boot receiver. In practice that means the service has to exist before the clinician switches away, not after.

On iOS the shape is similar and the vocabulary differs: an app records in the background only if it has declared that it does, and the system will interrupt the audio session for higher-priority audio — an incoming call being the obvious one. Confirm the current rules in Apple's developer documentation rather than a settings guide, because the background-mode requirements have moved more than once. What matters for diagnosis is that both platforms end capture without asking, and an app that treats the microphone as something it holds until it decides otherwise will lose consultations.

The hole in the middle: a chunk that never made it up

Most consultation capture streams in chunks — often 15 to 30 seconds each — so transcription can start before the visit ends. That turns 1 large upload into 30 or 60 small ones, and a clinic corridor with 1 bar of signal will fail some of them. The failure is invisible only if nobody counts: each chunk carries a sequence number, and a transcript with a hole in it is a sequence with a missing index. If your pipeline cannot answer whether all 42 chunks arrived for an encounter, it cannot tell a quiet minute from a lost one.

• Write to durable local storage first, then upload. A chunk that exists only in memory is gone when the app is killed, and the app will be killed.
• Retry with backoff for hours, not seconds. A clinic that loses signal in the basement recovers it on the ground floor, and the file is worth keeping until it does.
• Reconcile server-side by sequence, not by byte count. Assemble the encounter only when the expected indices are present, and mark it incomplete when they are not.
• Show the clinician upload state, not a spinner. 'All 42 segments received' is actionable at the end of a list; a tick that means the app tried is not.
• Never generate a note from a knowingly incomplete transcript without marking it as such.

Sizing makes the case, because the numbers are small enough that holding unsent audio is cheap. At 16 kHz, 16-bit mono, raw audio runs at about 32 kB per second — roughly 29 MB for a 15-minute consultation, or about 2.7 MB compressed for speech at 24 kbps. A day's list of 30 consultations held locally until delivery is confirmed sits well under 100 MB. There is no engineering reason to discard a chunk because its first upload failed.

A transcript with a hole in it looks exactly like a consultation where nobody spoke. The system cannot tell the difference, and neither can the model reading it — only the sequence numbers can.

Present but unintelligible: the examination happens away from the phone

This one has full duration and empty content, which is why duration is the first check. Sound pressure falls by about 6 dB each time distance from the source doubles, so a clinician talking 3 metres away behind a curtain arrives at a fraction of the level of the same clinician at the desk. Add a drape, a running tap, a couch that puts the patient's head below the phone, and the examination minutes come back as fragments — thin exactly where the objective findings were spoken.

The dangerous downstream effect is not the missing examination. It is what a template does with an examination section it was given nothing for: a section that expects to be full tends to get filled, and a generated normal is worse than a blank. That mechanism, and its structural fix, is normals appearing in the review of systems that nobody asked about — read it alongside this page.

Which of the 3 fixes to build first

1. Fix background capture first if any incident shows a clean cut. It is the cheapest change, it affects every clinician, and until it is done the other diagnoses are contaminated by truncations you cannot attribute.
2. Fix the upload queue second. Durable local write, sequence reconciliation, and an incomplete-encounter state that the note generator refuses to run against silently. This is ordinary pipeline work and it is where AI agents and automation engagements usually start on a scribe stack.
3. Fix the room last, because it is per-room and needs a person to walk in. Move the phone off the desk, add a second capture point for the examination area, or accept that examination findings are dictated rather than overheard.
4. Then instrument, so the next incident takes 10 minutes instead of a week: recorded seconds, expected seconds, chunk count expected and received, lifecycle events, and interruption events, all on the encounter record.

Two constraints shape all of this. You can only diagnose an incident while the raw audio still exists, and the retention rule is usually written by someone who has never had to debug one — settle it deliberately, which is the argument in who keeps the recordings when the pilot ends. And re-recording a consultation is rarely an option, so the consent script and the failure path must agree in advance about what happens when capture fails, which belongs with what to settle before the first consultation is recorded.

Catching a truncated recording before the clinician goes home

Most of these failures surface at review, so the discovery window is the signing window. A draft generated from 4 minutes of a 15-minute visit can still be repaired from memory on the day, and cannot be repaired at all on Friday. That makes same-day signing a capture-quality control as much as a compliance one, which is why draining the unsigned-note queue the same day belongs in the same project as the upload fix.

Where audio never leaves the clinic — an on-premise or private deployment — the upload path is a local network rather than a mobile one, which changes the failure profile without removing it; the trade-offs are set out in private LLM deployment. The rest of the capture-to-signature chain sits in ambient documentation and the clinical note, inside our healthcare and MedTech work.

• audio capture
• ambient documentation
• mobile capture
• upload reliability