Q&A: Designing for Patient-Specific Queries
Building a holistic information retrieval system for clinicians.
Scaling the product
Suki's reputation was built on ambient documentation: listen to a visit, write the note. As the world moved toward ChatGPT and Gemini, conversational chat-window interfaces became the default expectation for an AI assistant. The pressure on the team was to become more of a full-stack assistant ourselves, with our own information retrieval and Q&A system.
"Build our own chat window"
This was a vague brief in a crowded space. It was important to understand what our users wanted to query, and what our edge would actually be. We looked at two things in parallel.
What's out there?
| Category | Knows the patient? | Knows the medicine? | What it can't answer |
|---|---|---|---|
|
DAX, Ambience,
Abridge, Heidi Ambient scribes
|
Partial
Encounter context and note-level EHR data only. No question-answering against the chart.
|
No
No access to guidelines, literature, or drug databases.
|
Anything outside the live encounter including historical trends, drug safety against this patient's profile, evidence-based recommendations.
|
|
UpToDate,
OpenEvidence Clinical knowledge
|
No
Completely patient-blind. No EHR access, no individual context of any kind.
|
Yes
Deep, cited, evidence-based answers from curated editorial content and peer-reviewed literature.
|
Anything specific to the patient in front of them, including their history, their labs, their current medications, how their profile changes the answer.
|
|
ChatGPT, Gemini,
Perplexity General chat
|
No
No EHR access. No patient context of any kind.
|
Partial
Broad but unverified. No clinical trust model, no HIPAA compliance.
|
Anything requiring clinical trust, patient specificity, or cited evidence.
|
Clinical questions
A set of real clinician questions, surfaced through shadowing and interaction-data review.
"Given her age, comorbidities, and medications, what's the recommended treatment approach?"
"Has this patient ever been diagnosed with atrial fibrillation?"
"Is this medication safe for her given her kidney function?"
"What's her A1c trend been over the last year?"
"Does she meet criteria for starting a statin?"
"What is the most likely cause of her worsening shortness of breath?"
"What does UpToDate recommend for managing diabetes in a patient with CKD and cardiovascular disease?"
"What evidence supports treatment option A versus B for someone like this patient?"
"What changed since the last visit?"
"Is she taking any medications that increase fall risk?"
"What care gaps should I address during today's visit?"
Combined Reasoning
A physician doesn't think "let me check the patient's eGFR" and then separately "let me check if this medication is safe at that level." They think the combined question: is this medication safe for this patient?
A system that answers questions requiring both patient-specific data and general medical knowledge together.
Suki's existing EHR integrations already gave us live access to a patient's problems, medications, labs, vitals, and visit history, data. Combining that with general medical knowledge, in one surface, was something no competitor was doing.
Where and when Q&A shows up
First principles
To ensure consistency and clarity, I first established the system's expected behaviours and the foundational design principles that would guide its evolution.
Exploring layout directions
Before committing to a panel structure, I explored four layout directions for how a Q&A response could sit relative to the clinician's primary task on the existing product.
Side-by-side won out, for a few reasons:
Response categories
To understand the required response formats, I built a taxonomy of question types. Any question and response could be a combination of these distinct types. The surface itself would be dynamic, expanding, shrinking, or minimising based on context, importance, and screen size.
| Type | Example | Response format |
|---|---|---|
| Binary (Y/N) | "Does this patient have an active POLST on file?" | Text: Yes/no + context |
| Individual | "Who is this patient's nephrologist?" | Text: Short, specific answer |
| Cumulative | "Show me the patient's current medication list." | List, visual, or trend graphs |
| Computed | "What is the patient's average blood pressure?" | Interactive calculator, calculated answer |
| Time-specific | "What was the patient's last A1c, and when?" | Date-anchored answer |
| Trend | "Graph the patient's hemoglobin over the last year." | Charts and interactive visualisations |
| External | "Show me management recommendations for peripheral artery disease." | Longform answer, cited paragraphs (General Medical Knowledge) |
The badge
Suki is a voice-first product. While the 'Blue Dot' was central to its identity, clinicians rarely understood its purpose, and voice wasn't practical in shared charting spaces or patient rooms. We evolved the 'Blue Dot' from a voice trigger into a functional entry point for Q&A and broader assistant workflows.
This mirrored where the broader industry was heading too: combined chat-and-voice interfaces were becoming the norm. The text alone told a clinician what the system could do. Typing and voice both worked, and a clinician could switch mid-task.
Getting to yes
I built a Q&A vision demo grounded in day-to-day clinical workflows. It showcased realistic questions across different points in the clinician journey, multiple input modalities, and both patient-specific and general medical knowledge, while demonstrating how responses could adapt to different information needs.
Secured leadership approval for the unified direction: one Q&A surface, combining patient data and general medical knowledge, with a shared interface.
Pre-charting
Before a visit, clinicians need a rapid understanding of the patient's history. The experience begins with AI-generated summaries and suggested follow-up questions, allowing them to drill into abnormal labs, vitals, medications and prior visits. Optimised for heavy patient loads, the focus is on minimal clicks, low latency and quick retrieval over chart navigation.
Longitudinal review
Many clinical questions are about trends rather than single values. I explored longitudinal views of labs, vitals and medications, presenting changes over time through clear visualisations. This helps clinicians quickly identify meaningful patterns during the limited time available before entering the patient room.
Post-visit reasoning
After the visit, clinicians shift from information retrieval to clinical reasoning while completing documentation. Integrated alongside the note editor, Q&A combines patient-specific context with general medical knowledge to answer questions about guidelines, drug interactions and care decisions. With the patient no longer present, voice also becomes a more practical input modality.
Contract constraints meant Patient Data Q&A and General Medical Knowledge Q&A had to be built as separate tracks, on different timelines, with different vendor dependencies (UpToDate for General Medical Knowledge, our own EHR integrations for patient data).
Design separately to generalise across both.
Follow-up questions
Clinicians didn't start out knowing what Suki could answer, so suggestions in the empty state taught them what to ask. Suggested questions are based on prior questions, the patient's data and the clinician's specialty context. After a response, a good follow-up made it easy to keep rabbit-holing, one tap deeper into a patient's history or a clinical question, without retyping.
Sources, citations, and trust
Every answer carried a collapsible "Sources" section. "Powered by UpToDate" surfaced directly in the response, a clinical reference physicians already trust. Trust itself came from the sources backing an answer, linked citations and a visible explanation of how the answer was derived.
Graph responses
Trend and cumulative questions, the two categories from the taxonomy that needed visual responses, were represented with graphs or tables, depending on the use case.
Managing perceived latency
A response that takes too long to appear, or appears all at once with no warning, breaks the sense that Suki is keeping pace with the clinician.
Suggested and follow-up questions were built with cached answers so they'd feel near-instant when tapped. Loader states told the user what was happening while answers loaded, building confidence in the retrieval process.
Mobile
The Q&A surface adapts to mobile as a full-screen experience – clinicians on the go or at point of care could access the same functionality from their phone.
What this opens up
A few directions came out of this work as designed concepts, ready to build on, rather than open questions.
Early outcomes
The first month of usage validated two distinct jobs-to-be-done.
- 52% retrieved a single, most recent patient value – labs, medications, vitals, imaging
- 28% summarised a previous visit or clinical note
- 5% asked for clinical reasoning or recommendations – intentionally out of scope for the initial release, but the clearest signal of future demand
The Ask function is great. Accurate answers and so much easier than digging through the chart... essentially a more advanced form of the Find function.
- ~45% medication dosing, contraindications and drug interactions, most commonly during pre-charting. Given early users were primarily in primary care, clinicians typically entered visits with a treatment plan in mind and used Q&A as a quick reference to validate details.
- ~30% clinical guidelines and screening recommendations, often immediately before or after patient visits. This highlighted the importance of mobile and point-of-care access, where clinicians were less likely to be using Suki on the web.
- ~15% diagnostic criteria and disease management questions
- ~10% medical calculations