Designing Pre-Surgical Care for Patients Who Can't Type, Can't Speak, or Can't Show Up

02 The Problem

Before surgery, anesthesiologists need specific information: allergies, current medications, pre-existing conditions, reactions to prior anesthesia. The standard process was a phone call. But that process excluded the patients who needed the most careful assessment.

Patients who couldn't speak couldn't complete the call. Patients with cognitive impairments couldn't process rapid-fire clinical questions. Patients with motor impairments could talk but couldn't type - making digital forms useless. Patients who didn't speak English fluently couldn't navigate either channel. Elderly, homebound, or assisted care patients couldn't show up for in-person pre-op visits.

The gap was clear: patients who most needed careful pre-surgical assessment were least able to participate in it. Clinical teams compensated at point of arrival - more time in pre-op, more questions under pressure, more decisions with incomplete information.

04 The Approach

Core insight: patients aren't a monolith. A single communication path would always exclude someone. The solution was two parallel paths that converged to the same clinical output.

Path 1: Text-Based Questionnaire - for patients who could read and interact with a screen but couldn't speak or preferred async. Send a link, complete on their own time, at their own pace, on their own device. No scheduling required.

Path 2: Video Consultation - for patients who could speak but couldn't type or read well. Scheduled video call with a clinical team member. Walk through questions verbally, observe non-verbal cues, capture information in real time.

Both paths produced the same clinical output: a completed pre-surgical assessment that met documentation standards and was billable to insurance. Patient capability determined the path, not the system's convenience.

05 Designing the Questionnaire

Plain language without clinical ambiguity. "Have you ever had a bad reaction to anesthesia?" captures the same information as clinical terminology but doesn't require medical literacy to answer. Every question went through clinical review and plain-language translation.

Pacing for patients under stress. Short sections, clear progress indicators, ability to pause and return. Pre-surgical patients are anxious. The questionnaire had to respect that state, not add to it.

Large, forgiving interaction patterns. Touch targets designed for impaired motor control. High contrast throughout. No sliders, no drag-and-drop, no small checkboxes. Every interaction was a large, tappable surface area that didn't punish imprecise input.

06 Designing the Video Consultation

Zero-learning-curve entry. Receive link, tap, in the call. No app download, no account creation, no permissions dialogs. Every barrier removed between the patient and the clinician.

Minimal on-screen controls for the patient: clinician's face, end call, mute. That's it. Nothing else on screen to confuse, distract, or require explanation.

Clinician side designed for speed. Patient video, assessment questions, documentation fields, and patient record all visible simultaneously. The asymmetry was intentional - the patient sees simplicity, the clinician sees everything they need to work efficiently.

07 The Billing Integration

Every completed assessment had to produce a documented encounter meeting insurance billing standards. This wasn't an afterthought - it was a core design constraint that shaped the entire encounter structure.

Encounter documentation was structured to meet billing codes. Video consultations were logged with clinical detail sufficient for reimbursement. Questionnaire completions were matched to the same documentation standard as in-person assessments. The platform didn't just improve communication - it created a new billable service line.

09 What Didn't Work

Not everything landed the first time. Some of the hardest lessons came from designs that were technically sound but practically wrong.

First questionnaire designs were too long. I tried to capture everything in the initial version. Clinicians helped me prioritize - cut the nice-to-haves, keep the questions that directly impacted anesthesia decisions. Shorter questionnaire, higher completion rate.

Video call reliability was outside my control but inside my responsibility. Network quality, device compatibility, browser support - all variables I couldn't control but patients would blame the product for. I designed graceful degradation, auto-reconnect flows, and fallback to text when video failed.

Caregiver-mediated interactions were underestimated. Many patients had a family member or aide completing the assessment on their behalf. Consent flow, question framing, and identity verification all needed adjustment post-deployment to handle this pattern properly.

10 What I Learned

Accessibility isn't a checklist - it's the product. The entire product existed because standard interfaces excluded people who needed care most. WCAG compliance was necessary but insufficient. Real accessibility meant designing for patients with Parkinson's trying to tap a button, for dementia patients whose caregiver was answering on their behalf, for stroke recovery patients who could speak but not read. The accessibility was the value proposition.

The business model is a design constraint. Insurance billing requirements shaped design decisions as much as user needs did. The encounter structure, the documentation format, the timing of data capture - all of it had to satisfy billing codes or the product had no revenue model. Understanding that constraint early meant designing with it, not against it.

Designing for impairment means designing for reality. Design for the worst-case version of every user, not the best-case. If the interface works for a patient with tremors, impaired vision, and limited English - it works for everyone. That framing changed every design decision from "what's the ideal interaction" to "what's the most forgiving interaction."