CAPEI — Simplifying complex pharmacovigilance data intake

01Context

Pharmacovigilance (PV) is the science of monitoring the safety of medicines after they reach the market. When a patient experiences an adverse event, the details must be captured as a structured "case" — accurately, completely, and under strict regulatory timelines. CAPEI is Vitrana's cognitive automation platform that helps drug-safety teams process these cases at scale.

I joined the CAPEI team as a software engineer and transitioned into a UX Engineer role, eventually driving the end-to-end design of 'Captivant', the platform's Case Intake module — the front door through which every adverse-event case enters the system.

02The problem

Case intake was a cumbersome, multi-step manual process. Users had to move dense clinical information — patient details, suspect drugs, adverse events, reporter information, source documents — into the system across long, undifferentiated forms.

• High cognitive load: everything was presented at once, with little guidance on sequence or completeness.
• Error-prone entry: critical fields were easy to miss, and mistakes surfaced late — sometimes only at validation or review.
• Regulatory stakes: in PV, a data-entry error isn't a typo; it can affect the safety signal on a real medicine.

03Process

Learning the domain with SMEs

Pharmacovigilance has a steep vocabulary. I worked closely with subject-matter experts to understand how cases actually flow — what arrives in a source document, what must be coded, what regulators require. This collaboration continued throughout the project and kept the design honest to the domain.

Journey mapping the intake flow

I mapped the end-to-end intake journey to expose where effort, waiting, and error risk concentrated. The map made one thing obvious: the existing UI's structure mirrored the database, not the user's mental model of "telling the story of a case."

From lo-fi to hi-fi in Figma

I explored structures in low-fidelity wireframes first — a stepper flow versus a single accordion page versus a hybrid — and pressure-tested them with SMEs. The winning direction broke intake into a guided, step-by-step sequence organized around the case narrative, with progress always visible and validation surfaced inline at each step rather than at the end. I then built high-fidelity, interactive Figma prototypes for stakeholder review.

Weekly iteration under regulatory constraints

We reviewed with stakeholders weekly. Regulatory requirements were non-negotiable design constraints — certain fields, codings, and audit behaviors had to exist exactly as specified — so iteration focused on sequencing, defaults, grouping, and language: the things that reduce load without touching compliance.

Building it — in Angular

Because I also worked on the front-end, I implemented much of the design myself in Angular. The design-to-code loop was short: when a pattern proved awkward to build or slow to render, the design adapted the same week. Alongside this I built a Figma component library so the intake patterns — steppers, field groups, validation states — stayed consistent across CAPEI.

04Related craft work on CAPEI

• Ran heuristic evaluations of a legacy application in the suite and resolved 50+ usability issues.
• Established the team's shared Figma component library, giving design and engineering one source of truth.

05Outcome

The guided intake experience became a selling point of CAPEI — the thing the team could demo to show that a regulated, high-stakes workflow doesn't have to feel punishing.

06What I took from it

Complex domains reward designers who do the unglamorous work: learning the vocabulary, mapping the real journey, and respecting constraints instead of fighting them. And owning the build taught me that the best design reviews happen in code — where every decision finally has to survive contact with reality.