Concept study · Pfizer Medical Affairs
AI-assisted medical inquiry response, designed around verification rather than drafting
What this is
Where AI should act, where human judgment must remain, and how the interface makes that line visible.
I chose medical inquiry response as a representative workflow, not as the subject. It exposes the problem Medical Affairs will meet again and again: where AI should act, where human judgment must remain, and how the system makes that boundary visible. The same architecture carries over to content review, insight capture, literature triage and evidence synthesis.
| Decision | What it assumes | If the assumption is wrong |
|---|---|---|
| Design for verification, not drafting speed | Verification is the constraint, not queueing between steps | The evidence work becomes secondary to scheduling and capacity, and this design solves the wrong problem well |
| Evidence state is asserted from retrieval, never by the model | An approved source set exists to assert against, and is kept current | Most claims come back unsupported and the draft reads as worse than today's copy-and-adapt; content architecture comes first |
| Exception-based review, with verified claims collapsed | Reviewers will trust the collapsed set | They expand everything, review time doesn't fall, and the unit of trust has to change |
| Safety is a separate plane, not a branch | An inquiry can be routine and reportable at the same time | Nothing. This one holds even if the rest of the design is wrong |
The problem
The bottleneck is verification, not drafting.
A physician asks a clinical question the label does not answer: a drug interaction, a dosing edge case, use in a population the trials underrepresented. Medical Information owns the answer, and the answer is not correspondence. It is an auditable communication, grounded in approved sources and logged with who drafted and who approved it.
Today the work is mostly retrieval and re-verification. A specialist hunts for a prior approved response and adapts it, then a medical reviewer re-checks every citation by hand. Drafting is the fast part. A fluent AI draft with plausible citations does not save that reviewer time. It can cost time, because now they must check work whose provenance they cannot see.
So the assistant's job is not to write well. It is to arrive pre-verified: every clinical claim bound to the approved passage behind it, and every claim without one visibly marked as unsupported. The center of the interface is not a text editor with an AI button. It is a provenance view.
A draft that is 80% complete with honest gaps beats one that is 100% complete and uniformly unverifiable.
How I'd run discovery
Two working sessions, with the people who can veto the design as well as the people who use it: specialists, medical reviewers, compliance, safety, the content owner, and architecture.
Walk a live inquiry end to end. Mark where people lose time and, separately, where they feel exposed. Those are different maps, and the gap between them matters.
Sort a real sample by how routine each question is and how much risk the answer carries. AI drafting earns its keep in the routine, low-risk quadrant, and should mostly get out of the way in the novel, high-risk one.
What I'd be listening for: private workarounds. They need a control response, and they are also the clearest evidence of where the sanctioned path is too slow. Treating them only as a violation throws away the second half.
The future-state workflow
Not “add an assistant to step four.” A different operating model.
Governance moves upstream, and review turns from re-reading everything into handling exceptions.
| Step | Who acts | What it depends on |
|---|---|---|
| Classify | AI | Questions arrive in one place, and compliance has agreed what counts as risky |
| Governed retrieval | System | One approved set of documents, always the current version, and a rule for which source wins |
| Claim-grounded draft | AI | Every sentence points at the passage it came from, and gaps are labeled rather than filled |
| Specialist judgment | Human | You can see the source behind a sentence without going to look for it |
| Exception-based review | Human | The draft sits next to its sources, with the problems first |
| Release and audit | System | A record nobody can alter: sources, edits, who approved |
| Feedback loop | System and human | Rejections and overrides are captured for governed evaluation, then released as retrieval changes under change control |
The governance did not disappear. It moved from the end of the process, where it was a bottleneck, to the middle, where the system enforces it continuously.
The behavior model
The contract the interface has to express, written before any screens.
It is also the artifact compliance can actually review.
- Classify an incoming inquiry by topic, urgency, and risk
- Retrieve matching prior approved responses and source documents
- Draft a response using only retrieved sources the governance model permits for this workflow
- Bind every clinical claim to the passage supporting it
- Flag its own unsupported sentences
- Send anything to an external party
- Assert an externally consequential claim without a governed evidence basis appropriate to that workflow
- Use a superseded document version when a current one exists
- Infer beyond the source to close a gap
- Silently drop a part of the question it cannot answer
- Any mention of an adverse event or product complaint, routed to safety immediately, on its own clock, regardless of what else happens to the inquiry
- Off-label questions, human-authored, always
- Inquiries from media, legal, or regulators, out of this workflow entirely
- Any question where retrieval returns nothing adequate
Safety is a separate control plane, not a branch. An inquiry can be both a routine dosing question and a reportable event; both paths run, on their own clocks. Designing it as safety-or-normal is the mistake that produces missed reports.
Where sign-off sits. The specialist owns the content and approves the draft. The medical reviewer owns the release. Neither can be automated away, and the interface never implies otherwise: no “approve all,” no default-checked states, no progress bar that makes stopping feel like failure.
Why not just use the general assistant we already have
The question is fair. A tenant-scoped general assistant already clears the security bar.
The data stays inside the tenant, access is logged, and nobody is pasting inquiries into a consumer tool. What it still cannot do is show a reviewer where any given sentence came from. So the verification work it was meant to save lands back on the reviewer, now against an unfamiliar draft. That is the trade this design refuses.
What a general assistant leaves out is exactly the part that makes an answer releasable: claim-level provenance, an approved source set kept current, mandatory adverse-event routing, an audit trail bound to the response rather than to the conversation, and one quality bar instead of twelve. Model capability is not the differentiator. Turning it into a governed workflow is, and that is design work done with architecture and engineering rather than downstream of them.
The interface
Four concept screens, each making one judgment cheaper.
Built as a clickable prototype in two rounds: a neutral pass to settle structure, then one in Pfizer's published identity, tuned for dense reading. Drafting is shown above; triage and review follow, and the pattern page appears with the library below. Open the prototype to click through all four.
How I'd test and measure it
Not whether people like the assistant, but whether they make the right judgment with it, and whether it fails safely.
Participants. Medical Information specialists, medical reviewers, and a safety representative, including two people who have said the tool is a bad idea.
Before real users, a synthetic round. A concept has no access to Pfizer specialists, so I'd build personas from published Medical Information practice and run the same seven tasks against them first. That is a screen on the protocol, not a source of findings: it catches tasks that are ambiguous or unfalsifiable before they cost a real participant an hour.
- Choose which inquiry in the queue to handle first
- Decide whether a draft is sufficiently supported to edit rather than rewrite
- Find the source behind a specific claim
- Reject a source that doesn't say what the draft implies
- Resolve an unsupported statement
- Decide whether an inquiry requires escalation
- Approve or send back at review
Planted failures. At least three tasks contain a seeded AI error: a claim bound to a passage that doesn't support it, a superseded document version, and an inquiry with a buried adverse-event mention. Whether people catch these is the test.
Three rounds of five to six participants, revising the behavior model between rounds, not only the screens. Some findings mean the assistant was given a job it shouldn't have.
What I'd measure
Instrumented before building, because a baseline you didn't capture is one you can't claim later.
| Type | Measure | Baseline to capture first |
|---|---|---|
| Cycle time | Median turnaround, inquiry to sent | Current median by inquiry type |
| Effort | Reviewer minutes per inquiry | Timed observation, not self-report |
| Quality | Rework rate at review | Share of drafts sent back today |
| Trust | “I'd send this with only minor edits,” five-point, every draft | From the first prototype onward |
| Adoption | Share of eligible inquiries run through the workflow | Zero, by definition |
| Guardrail | Missed escalations; AI claims accepted without sufficient evidence | Current miss rate, if it is measured at all |
Trust leads; adoption follows. A low trust score is a design defect, not a training problem.
The counter-metric. Any workflow that speeds up review creates pressure to rubber-stamp. I'd watch for review time falling faster than rework rate. That pattern means people stopped reading, and it is the failure mode this design could plausibly cause.
From one workflow to a pattern library
The difference between shipping a tool and establishing a standard.
Medical inquiry response is one instance. The components it needs are not specific to it: evidence grounding, claim-to-source binding, uncertainty marking, exception review, escalation routing, a human approval gate, version awareness and an audit record. Built as one-offs, an organization ends up with six AI tools that behave differently and are each trusted separately.
| Workflow | AI role | Human judgment | Dominant pattern |
|---|---|---|---|
| Medical inquiry response | Retrieve and draft | Verify and release | Provenance and escalation |
| Content and promotional review | Detect and compare | Interpret and approve | Diff and exception review |
| Field insight capture | Structure and cluster | Interpret significance | Traceability and synthesis |
| Literature triage | Classify and summarize | Relevance judgment | Evidence ranking and uncertainty |
| Evidence synthesis | Assemble and cross-reference | Scientific interpretation | Grounding and version awareness |
Designed once and governed centrally, these become a pattern library other designers build against, instead of every workflow earning trust from zero. The fourth screen is that library's first entry.
On visual craft. The reviewer's attention is the scarce resource, so hierarchy does the work: four type levels in Noto Sans, reading text at 15px on a 680px measure, and color reserved for meaning. Safety renders as a dark system band because it must borrow nothing from the evidence language. Product names, versions and passages are placeholders.
The decisions I'd force
Most of what stalls this work isn't design. It's questions nobody owns, which each team then answers differently and quietly. I'd bring each to one working session with a recommendation attached.
- What evidence is sufficient, and in what order of precedence?A governance decision, not one a designer should quietly encode. Someone also has to say what happens when approved sources conflict.
- What false-positive escalation rate is acceptable?Over-flagging is the quiet killer of these systems. Nobody wants to name a number, and the design cannot be tuned until someone does.
- Where does ownership sit when the AI and the human disagree?If a specialist overrides a flag and is wrong, whose defect is it? The answer determines how much the interface should resist an override.
I'd push hardest on the first two. Both are cheap to decide in week two and expensive to change in month six.
What I don't know yet
I'd rather show where the reasoning runs out than paper over it.
-
Is verification really the constraint?
Or is it queueing, with inquiries sitting untouched between steps? That is the one I'd want answered first.
-
Is the library actually structured and current?
Or is it a decade of documents with inconsistent metadata? Retrieval quality is a content problem before it is a model problem.
-
Who will refuse to use it, and what would change their mind?
Designing for the skeptic produces a better tool than designing for the enthusiast.
The first design decision isn't where to put AI. It's which part of the workflow deserves to change. If verification is the constraint, design for evidence and exception-based review. If queueing is, redesign routing and capacity. If retrieval quality is, fix the knowledge architecture before anyone opens Figma.
Concept work. Not affiliated with, commissioned by or endorsed by Pfizer.