Will Kinsey

Selected Work · Applied AI · Healthcare operations

Medical equipment recall pipeline

Finding out about a recall is easy. Knowing which of a hospital’s devices are actually affected, who needs to act, and whether the work was really created is the hard part. I led the design, AI-assisted development, and operation of a system that closes that gap.

My role
Owner: design, AI-assisted development, operation
Status
Working system, run weekly with human review
Built with
Python, Playwright, FDA data, web search API, agent orchestration
Scope
Intake through validated work orders and communications

Replay: one recall, start to finish

A fictional recall and fictional assets, run through the real sequence of steps. Press Play, or click any step.

    Fictional manufacturer, device, serials, and locations. No real recall, customer, or inventory data is shown.

    Four outcomes, not two

    A yes-or-no match creates unnecessary work or misses real risk. Every candidate asset gets one of four decisions.

    MATCH

    Source and inventory evidence place the asset inside the affected scope. Work is created.

    CONFIRM_APPLICABILITY

    In scope, but a fact only visible in the field decides it. The work order starts with that exact check.

    NO_MATCH

    Known identifiers exclude the asset. No one gets sent to inspect equipment that is not affected.

    ESCALATE_REVIEW

    Missing or conflicting evidence, suspect identifiers, or duplicate risk. Held for a person instead of guessed.

    What it connects

    Sources

    • FDA recall data (openFDA and FDA device recall search)
    • Recall databases
    • Manufacturer and public-web notices, found through a search API with time and spend limits
    • Manager and manufacturer emails with attachments

    Pipeline

    • Python stages with defined inputs and outputs
    • Business rules in configuration: manufacturer aliases, product rules, facility and contact registries
    • Agent-assisted evidence review and exception handling
    • Run manifests, ledgers, and review queues for resumable state

    Systems and people

    • Maintenance management system: inventory exports, equipment lookup, and work order creation through browser automation
    • Report exports for independent validation
    • Email drafts for site managers and safety leaders
    • Weekly scheduled run with documented recovery

    Engineering choices

    • One process, many inputs. FDA and email notices converge after normalization instead of becoming separate systems.
    • Rules outside the prompts. Aliases, product decisions, facilities, and contacts live in maintained configuration.
    • Serials are not unique. A serial match also requires the right manufacturer and product.
    • Contained failures. One missing PDF or unknown manufacturer does not stop unrelated recalls; outages are retried with pacing and checkpoints.
    • No duplicate work orders. Single-writer checks, recall history, and saved creation evidence come before any retry.
    • Honest measurement. Reports separate scripted, agent-assisted, and operator-assisted work.

    Where I stay in the loop

    • Uncertain applicability. Field-only facts and conflicting evidence come to me, not to a guess.
    • First live record. One test work order is created and I inspect it before the rest of the batch runs.
    • Sending. The system drafts the messages; I attach the notice and send.
    • Open items. Anything waiting on an outside reply stays visibly open until it is resolved.

    What I did

    I own the workflow end to end: designing the stages and decision rules, building it with AI coding agents, operating it each week, and refining it as edge cases appear, from source intake through evidence-backed handoffs and communication tracking.