Case Study
AI Scribe -Reducing the documentation burden for healthcare providers
AI Scribe is an AI-assisted clinical documentation solution designed to reduce the manual effort required from providers during patient encounters.
It captures the provider-patient conversation, converts it into a transcript, extracts relevant clinical information, and generates a structured clinical note for the provider to review and finalize.
Project Details
-
My Role: Product Designer
-
Scope: End-to-end - initial ideation, competitor research, wireframing, design iteration, stakeholder reviews, and final shipped solution
-
Team: Business Analyst, Product Owner, Clinical Representative (Practicing Physician), VP of Product, AI Engineers, Solution Architects
-
Domain: Healthcare EHR - Ambient Clinical Documentation
-
Timeline: 2026
-
Status: High-priority flagship initiative, shipped mid-2026
-
Platform: Web and mobile
The Problem
Providers spend a significant part of every patient encounter, as well as additional time afterward, documenting what happened instead of focusing on the patient.
The goal wasn't simply to add AI to the EHR. The challenge was to reduce the time and cognitive effort required for documentation without asking providers to learn an entirely new way of working.
This was especially important because many of our users are experienced providers, often 45 - 60+ years old, who already have established documentation habits. A solution that introduced another complex workflow could create an additional adoption barrier instead of reducing the existing burden.
Understanding the Existing Workflow
I started by understanding the existing Provider Note workflow, the providers who use it, and the broader clinical documentation landscape.
The existing workflow required providers to manage the patient consultation while capturing, organizing, reviewing, and finalizing clinical information.
The provider is required to listen to the patient, understand the clinical situation, capture relevant information, organize it into the appropriate sections, and review the documentation before completing the encounter.
What Made the Problem Difficult
The documentation problem had several connected challenges.
This created several areas of friction:
-
Manual documentation - Providers spend time entering and organizing clinical information themselves.
-
Divided attention - Documentation competes with the provider's attention during the consultation.
-
Repetitive work - The same documentation activities are repeated across patient encounters.
-
Complex clinical information - Information needs to be captured in the appropriate sections of the clinical note.
-
Existing habits - Providers are already familiar with their current workflow, making significant behavioral changes difficult.
.png)
.png)
.png)
Research
The AI Scribe category was not empty water to step into it's a fast-maturing, well-funded market. Established players include Microsoft's DAX Copilot (used by over 600 healthcare organizations, documenting over a million consultations a month), Abridge (over $300M raised, deployed across 200+ health systems), and others including Suki, Nabla, and DeepScribe, each already carving out specific strengths voice-first interaction, EHR-agnostic flexibility, specialty-specific templates. This wasn't a race to be first; it was a need to build something genuinely well-suited to CureMD's own provider base and existing clinical data, entering a category where the baseline expectations were already high.
The team studied around five direct competitors in depth their recording flows, transcription approaches, note generation, clinical information extraction, and coding suggestions through product demonstrations, released materials, and hands-on review. Indirect competitors (general voice-to-text and summarization tools) were reviewed too, to understand where structured, clinically-useful output was genuinely hard to get right versus where it was becoming commoditized.
One important strategic decision came out of this research: rather than licensing a third-party ambient scribe solution, the direction was to build the capability internally, so the feature could draw directly on CureMD's existing clinical and product data rather than treating documentation as a bolt-on feature.
Rather than treating this as a simple UI refresh, the approach focused on building an adaptive intake framework bridging patient accessibility with clinical utility.
Approach & Strategy

Discarded Direction
The first concept explored wasn't an ambient AI Scribe at all it was an AI chatbot. The idea was that a conversational interface would feel natural: a provider could simply ask the AI questions and get answers, the way people were already getting used to interacting with AI elsewhere. Multiple chatbot concepts were explored and refined.
But working through the details surfaced the real flaw: a chatbot still required the provider to actively interact with a system typing or talking to AI instead of removing that interaction from their day.
The team stepped back and asked more fundamental questions: What's the actual problem here? Where are providers actually losing time? And how do we let them focus on the patient instead of the computer?
That reframing was the turning point.
The goal was never “introduce an AI interface.” It was “remove documentation work from the provider's day entirely, wherever possible.”
That's what led to the ambient AI Scribe approach: instead of asking providers to talk to AI, let AI listen to the provider-patient conversation itself and turn that directly into a structured note.


The Key Insight
AI should reduce the provider's documentation workload not become another task they have to learn, trust blindly, or manage.
But working through the details surfaced the real flaw: a chatbot still required the provider to actively interact with a system typing or talking to AI instead of removing that interaction from their day.
The provider needed to remain in control of the clinical documentation by reviewing, correcting, and approving what AI produced rather than simply accepting it.
This shaped the overall experience into a single, clear workflow:
Requirement Gathering & Clinical Workflow Understanding
The project started with a broad goal: reduce the documentation burden on providers while keeping the existing clinical workflow familiar.
I worked with the Business Analyst, Product Owner, and clinical representative to understand the Provider Note workflow, the documentation requirements, and how clinical information moves through the EHR.
Through these discussions and workflow walkthroughs, we identified several requirements that would shape the AI Scribe experience:
-
Manual documentation - AI should reduce manual documentation rather than introduce another task.
-
Natural conversation - Providers should be able to continue their consultation normally while AI captures the encounter.
-
Clinical structure - Unstructured conversation needs to be converted into relevant clinical sections such as HPI, ROS, Physical Exam, Assessment, and Plan.
-
Provider control - AI-generated content must remain reviewable and editable before being added to the clinical record.
-
Existing workflow integration: - AI Scribe should work within the Provider Note rather than require providers to adopt a separate documentation workflow.
-
Trust & accuracy - The experience should make it easy for providers to identify, review, and correct information generated by AI.
AI Scribe User Flow

Design Decisions
01. Embedded in the Existing Workflow
Rather than introducing AI Scribe as a separate application, it was integrated directly into the Provider Note through the Assistive Panel.
Providers could continue documenting manually when preferred, or use AI Scribe when it added value. This made adoption optional and familiar, reducing the need to learn or switch to a completely new workflow.

02. A Recording Experience Built Around Clinical Encounters
The recording experience was designed around how providers actually work during a patient encounter.
A persistent recording widget remains active even when the provider navigates to another part of the system for example, when stepping away to examine the patient. This allows the conversation to continue being captured without interrupting the provider's workflow.
To avoid unnecessarily capturing long periods of silence, the system detects when no voice is present for 30 seconds, displays a “No voice detected” message for 10 seconds, and then automatically pauses the recording.
The experience also supports up to three recordings per note, with each recording supporting up to 60 minutes. This allows providers to capture different parts of an encounter, such as an initial consultation, a follow-up discussion, or information captured later.
Design goal: Keep recording in the background so the provider can focus on the patient, not the recording controls.

03. Surfacing Uncertainty Instead of Hiding It
AI-generated clinical information can contain uncertainty, and hiding that uncertainty inside a long note can make review difficult.
A persistent recording widget remains active even when the provider navigates to another part of the system for example, when stepping away to examine the patient. This allows the conversation to continue being captured without interrupting the provider's workflow.
To make potential issues easier to identify, we introduced a color-coded system:
-
Blue - Information correctly matched by AI
-
Yellow - Information already present in the patient's existing record
-
Red - Information that is uncertain or requires provider attention
Rather than making providers search through the entire note, uncertain items are collected in a dedicated “Need Correction” area for quick review.
We also explicitly label topics that were not mentioned during the encounter as “Not Discussed” instead of leaving them blank. This helps distinguish missing information from information that was intentionally not captured.
Design goal: Make AI uncertainty visible and actionable, so providers can quickly review what needs their attention.

04. A Clear Boundary Between AI-Generated and Provider-Entered Information
Providers can correct or remove AI-detected information directly within the generated note, but they cannot add entirely new clinical information into an AI-generated section.
If something was missed, the provider can either create another recording for AI to process or add the information manually elsewhere in the Provider Note.
This creates a clear and traceable distinction between AI-generated content and provider-entered information an important consideration when working with clinical documentation.

Collaboration
The project started with the Business Analyst bringing the initial problem and asking for exploration of different directions.
From there, I worked closely with the Product Owner and a clinical representative (practicing physician) through frequent review cycles. We presented design progress, discussed open questions, validated the workflow, and continuously incorporated feedback as the product evolved.
As the solution progressed, the VP of Product, AI Engineers, and Solution Architects joined the discussions to align the design with technical feasibility and product goals, especially given the project's high priority and tight timeline.
Outcomes
Internally, the most rigorously validated result is specific and defensible: testing with clinical staff across more than 50 real test attempts showed 98% accuracy in capturing spoken content and correctly mapping it into the appropriate note sections.
Broader claims about overall adoption and provider satisfaction were positive, but were based on internal team impressions rather than a formal study, so this case study does not present them as measured outcomes.
AI Scribe shipped as a flagship initiative in mid-2026, with the same core experience available across web and mobile.
Key Outcome
-
Manual documentation - in capturing spoken content and mapping it to the correct note sections
-
50+ test attempts - validated with clinical staff
-
Web + Mobile - same core AI Scribe experience across platforms
-
Flagship Initiative - shipped mid-2026