Skip to content
Husain Bootwala
06In discovery

Pharmacovigilance Productivity AI

Modelling a regulated industry's working day before committing to a product

The adverse-event case lifecycle as five columns: intake and triage by an intake associate, case processing by a drug safety associate, quality control, medical review by a physician, and regulatory submission. Two dashed arrows run backwards: a rework loop from QC to processing, and a loop from the archive back to intake when new information reopens a closed case. A highlighted band explains that Day 0 is company awareness, that a fatal unlisted case is due in seven calendar days and other serious unlisted cases in fifteen, and that late seriousness upgrades recalculate the clock from the original date.
Diagram · The life of a case: five pairs of hands, two rework loops, and a submission clock
Channel
06
Period
2026 —
Domain
Software
Role
Sole researcher: domain modelling, process flowcharts, opportunity scoring, competitive teardown

Stack

  • Domain research
  • Process modelling
  • Regulatory analysis
  • Opportunity scoring
  • Agentic research pipelines
Role process models
11

One per role, from intake through submission

AI opportunities scored
72

Each anchored to a specific step in a flowchart

Product direction chosen
None

The decision is not ready to be made yet

Why this project is here unfinished

This project has no product, no code and no launch date, and it is the one I would most like to be asked about.

Anyone can generate a working application now. The scarce skill is knowing which application is worth generating. In a regulated industry, getting that wrong costs more than a wasted sprint; it creates a compliance exposure.

So this repository holds the part of the work that usually gets skipped.

The trap

Pharmacovigilance is the discipline of detecting and assessing adverse effects of medicines. Safety teams process individual case safety reports under legally binding submission deadlines, the volume is high, and the deadlines do not move.

The obvious AI product, then, is automated case processing. It is also close to the worst thing to build. Case assessment is where regulators require demonstrable human judgement, and a vendor promising to remove it is selling something a compliance officer cannot sign off. A product built that way would be unbuyable however well it worked.

What I did instead

I modelled the day first. Eleven roles, from intake through medical review to regulatory submission, each with its own process model, plus a master model of the whole case lifecycle on one page.

Then every opportunity had to be anchored to a step. Seventy-two candidate AI interventions, each scored, and each required to point at a specific box on a specific flowchart. Anything that cannot be located in someone’s working day is a feature idea rather than an opportunity.

Vendor numbers are kept apart from observed fact. Incumbents publish efficiency figures; those are recorded as claims, in a dated file, until something independent supports them.

Where it stands

The direction is still undecided, and I am comfortable with that. The models come from published literature and vendor material, and desk research has a ceiling: they need correcting by people who do this work every day. Practitioner interviews are the next step, and the MVP folder stays locked until they have happened.

Picking a direction now would have felt like progress. It would also have been the most expensive mistake on the table.

Media

A two-column diagram. The left column lists the steps a case processor performs: read every source document, enter the fields, code in MedDRA and WHODrug, complete seriousness and expectedness, write the narrative, draft the follow-up query, self-QC. The right column pairs each step with the registered AI opportunity that attaches to it, by identifier. The narrative row is the exception: it is highlighted, and its right-hand cell says drafting can be assisted but the step stays owned by a human.
Diagram · A case processor's day, with every AI opportunity anchored to a step

How this was built

The spec sheet above lists the stack. This section covers how the work was run, which a screenshot cannot show you.

Where AI did the work

  • Ran research as a pipeline with a fixed output contract: every finding lands in a register with a score and a link back to the step in the process model it attaches to. An opportunity that cannot be pointed at a box on a diagram is not admitted.
  • Used separate passes for building the domain model and for challenging it, because an agent that researches and validates in the same breath will confirm whatever it already wrote.

The discipline around it

  • Observed fact and vendor claim are stored separately, with a dated validation file tracking which is which. Every efficiency percentage a software vendor publishes is treated as marketing until independently checked.
  • Point-in-time research is dated and never edited in place; evergreen domain understanding is updated in place. Mixing the two is how a knowledge base rots without anyone noticing.
  • The repository states in writing that nothing in it is a commitment. Without that line, a well-written research document starts getting treated as a decision.

What stayed human

  • The product direction is marked undecided in writing, and the MVP folder stays locked until that changes. AI can enumerate and score options; it cannot be allowed to pick, because the choice is where the judgement sits.
  • Desk research has a stated ceiling. These models are built from published literature and vendor material and are marked as unvalidated until real practitioners correct them.

Process artifacts in the repo

AI_OPPORTUNITY_REGISTER.md
72 candidates, scored, each anchored to a process step
VALIDATION-2026-07.md
Dated ledger of what is verified versus what is vendor claim
DECISION_LOG.md
Open questions, with "undecided" recorded as a state in its own right