Serene Gao

Serene Gao

← All work

Designing Explainable AI Features for Clinical Guideline Review

Clinical review screen, faded, with two passages emphasized: an AI-surfaced finding in the guideline's impaired-oxygenation criteria and the matching sentence in the patient's History & Physical note, joined by a dashed line.

What to notice: each AI finding in the guideline links to the exact passage in the patient record it came from, so reviewers can check before deciding. Synthetic patient data.

I designed clinical guideline-review features powered by Synapse, MCG’s internal LLM engine. By bringing AI-surfaced findings and their source evidence into the workflow clinical reviewers already know, I made the features easier to verify and use.

12%–63%

Less time per case review

~50%

Shorter ramp-up time to full productivity

CONTEXT

Utilization-management teams review requests for care against clinical guidelines. Reviewers work across patient records, attachments, guideline requirements, and assessment tools to determine whether the available evidence supports a request.

Synapse’s LLM capabilities and the product features were being developed in parallel. Requirements evolved as the team learned what the model could reliably surface, while reviewers still needed a familiar interface and clear ways to verify findings. Because these decisions can affect patients' access to medical treatment, the design needed to support careful human review and make the origin of AI findings easily accessible.

MY ROLE

Lead Product Designer. I owned the design direction for the Synapse features, partnering with product, UX engineering, and development to translate evolving requirements into workflows and interaction patterns. I designed how AI findings and source evidence appear across the review experience and defined complex states and edge cases.

DECISION 1 OF 3

Organize complex findings in the current review workflow

Rather than isolate Synapse output in a separate view, I designed for findings and their supporting evidence to appear within the clinical guideline and clinical attachments. Reviewers could inspect potential data matches alongside the relevant requirement and source material, without leaving the workflow they already knew.

This decision built provenance into the existing review workflow: reviewers could trace a finding to its source evidence in context and understand why it had been surfaced before deciding whether it supported a guideline requirement.

Textual findings anchor to source in clinical attachments.

(All screens shown are adapted for this portfolio. Clinical criteria and data have been generalized or replaced with synthetic examples to protect company IP)

DECISION 2 OF 3

Distinguish AI findings from a reviewer’s decision

The guideline tree had to communicate several different things: evidence found by the model and its confidence or relevance 1, whether the evidence appeared to support an indication 2, and what the reviewer decided 3. Treating these as one “matched” state may be simpler to scan, but could confuse reviewers on the significance of their action.

The guideline tree had to communicate several different things: evidence found by the model and its confidence or relevance 1, whether the evidence appeared to support an indication 2, and what the reviewer decided 3. Treating these as one “matched” state may be simpler to scan, but could confuse reviewers on the significance of their action.

Tachycardia criterion expanded to show supporting evidence: vitals, progress, care and triage notes, and a 12-lead ECG table

1

2

3

Tachycardia criterion expanded to show supporting evidence: vitals, progress, care and triage notes, and a 12-lead ECG table

1

2

3

Tachycardia criterion expanded to show supporting evidence: vitals, progress, care and triage notes, and a 12-lead ECG table

1

2

3

I designed visual and interaction states that communicate the different meanings carried y machine-found evidence, and differentiate them from reviewer decisions. Reviewers assess the evidence and decide whether it met the guideline requirement, rather than having the interface present that conclusion for them. I tested the interaction model with users at a client conference, using their feedback to refine the visual cues.

Reviewer selecting the finding checks the criterion it supports, turning the definition's status badge to "met" and highlighting chevrons indicating that parent indication is also met.

DECISION 3 OF 3

Use prototypes to challenge a hard constraint

PM initially set a 5-second requirement for returning attachment findings. I was concerned that slower processing would force a “Resume reasoning” action, adding another decision to an already complex review. When discussion alone didn’t resolve the trade-off, I resorted to prototyping to make the costs visible.

I presented an asynchronous alternative: each attachment showed its OCR/LLM processing status, became expandable when processing finished, and displayed a completion toast. The side-by-side prototype allowed me to make a case for the more user-friendly approach and persuaded the product team to move beyond the rigid 5-second requirement.

As each attachment finishes processing, its findings appear under the matching guideline criteria, so reviewers can open documents and start working before the full review completes.

OUTCOME

The review experience I designed brought Synapse findings into the clinical workflow, connected them to source evidence, distinguished AI output from reviewer decisions, and kept attachment processing transparent. User feedback helped refine the visual cues, and prototyping helped the product team reconsider requirements. This interaction model is becoming a foundation for how the company delivers AI-assisted solutions.