AgelessRx

The vendor evaluation

Working prototypes of two vendors, compared head to head on capture, embedding, failure handling, admin handoff and resuming an abandoned session. I brought engineering's recommendation to product, who made the call.

Value before the finish line

The first release ran the vendor's records check silently at checkout and approved patients on the details they had already submitted. Intake didn't change and no one was rejected, but most patients stopped needing a manual review right away. The ID and selfie step followed in a second release.

The back-end

The verification model and migration, a vendor service behind an interface, and a signed webhook endpoint that rejects replayed and oversized requests. The checkout trigger logs vendor errors instead of throwing them, so it can never block a patient's checkout.

The admin review

The screen customer service uses when automation can't decide: the vendor's decline reasons, zoomable ID and selfie images, and a resubmission flow that messages the patient.

Reconciliation

The vendor confirms an ID is genuine, not that it matches what the patient typed. I designed and built the check that compares name, date of birth and address against what the ID reads, flags any disagreement on Admin Review, holds approval until a mismatched name or date of birth is settled, and settles them in one click. Customer service can filter the queue to find them.

Recommended one vendor, then changed my mind on the merits

My first recommendation was Vouched: easier to build with, richer data back. Working through the tradeoffs with the team, Persona fit the skip-and-return flow far better — it can resume an abandoned session and takes a date of birth in the first check — and a reputational concern I'd been weighing didn't outweigh that. We chose on fit, and product made the call.

Departing from the spec when it stranded patients

The spec said requesting a resubmission should set the vendor's status to "resubmission required." I built it, then found a patient's way back in only appeared for a different status, so they could be parked with no path forward. I replaced it by inferring resubmission from the verification's own history.

Hold approval, never rejection

Pharmacies need a patient's legal name and real date of birth, so a mismatch on either holds the order until it's settled. An address doesn't, because the one on an ID is often out of date. Rejection stays open, so a suspect order can be declined without editing the patient's record first. Each fix is its own audited record with the before and after values, and keeping the patient's value requires a reason.

Mapping the catalog

An admin page where staff map each product to its DrugBank entries, with search, filters, and a confirmation step that treats removing a mapping differently from saving one.

Matching at intake

A typeahead in the medications step, so patients pick their own match and the ID is captured at the source. Free text is still allowed for anything DrugBank doesn't know.

Checking automatically

The data model and API for interaction records, and background jobs that check every matched medication against the ordered product and record what DrugBank finds, including "no known interaction."

Clinical review

Severity-tinted alerts at order review for admins and doctors, with DrugBank's guidance. Clinicians can override a severity only with a written justification, validated on the back-end against the original. Moderate and Major interactions still need a clinician; Minor and None no longer hold approval.

A write-once baseline

The record of what DrugBank originally said can't be rewritten, so an override can't quietly change history. The migration added nullable columns so existing rows couldn't fabricate a baseline that was never there.

A field that quietly rewrote medication names

An enrichment step replaced a patient's pick of "Acetaminophen" with a branded child product, which is wrong for an adult platform. I removed it: the name is now exactly what the provider chose.

Direction isn't ownership

In DrugBank, which drug is the "subject" of an interaction depends on the mechanism, not on which drug is ours. Ibuprofen is the subject in a liver-damage interaction with metformin. Cards were wrongly showing "no match"; I fixed it by identifying our drug by exclusion.