Verdikt The domain.
Domain primer · ~2 minutes

PAPs, in plain terms

Patient Assistance Programs (PAPs) are grants that pay for medication when insurance won't. A pharmaceutical manufacturer funds the program, a pharmacy or hub service administers it, and eligible patients receive the drug at no cost. This page explains the roles, the paperwork, and where Verdikt fits, so the demo video makes sense even if you don't work in pharma.

The flow

Who pays whom, who receives what

Four parties, one loop. The manufacturer funds the program to broaden access to its own drug; a specialty pharmacy or hub administrator screens applicants; approved patients get the medication shipped to their door.

Sponsor

Manufacturer

Funds the program, sets the eligibility rules (income cap, indication, insurance status).

Point of care

Prescriber

Writes the prescription, signs the medical-necessity attestation, provides NPI/DEA.

Administrator

PAP hub / pharmacy

Screens applications against the rules, issues an outcome letter, ships the medication.

Beneficiary

Patient

Submits an enrollment packet (income, insurance denial, prescription) and receives the drug.

funds → prescribes → ships drug → ← receives meds

In the demo, the administrator is a fictional pharmacy called Alderwood Specialty Pharmacy. The patient is Devon Okafor; the medication is Cardiovita 40 mg.

The motive

Why manufacturers fund PAPs

A PAP is not pure charity. It's a legitimate access program that also protects the manufacturer's most important asset: a patient staying on their drug. Three reasons usually drive it: it keeps patients on therapy, fills the gap payers leave, and builds long-term prescriber trust.

Read the three reasons

Access & adherence

Uninsured or underinsured patients who can't afford a specialty drug walk away from therapy. A PAP keeps them on the prescribed regimen, which protects clinical outcomes and avoids losing the patient to discontinuation.

Fill the coverage gap

High-cost specialty drugs get denied by payers all the time. A PAP catches the cases the manufacturer wants covered anyway: correct indication, right patient, no commercial insurance path available.

Long-term relationship

Patients who start on a brand through a PAP often stay on it after they gain coverage. Prescribers who trust a manufacturer's safety net keep prescribing. The program pays back over years, not months.

The application

Four documents, one case file

A PAP application isn't a single form. It's a stack. Each document proves one thing the administrator has to verify before approving the grant.

Enrollment form
Applicant identity, contact, household size, income attestation, consent to share medical info. The intake anchor.
Income verification
Two recent pay stubs or the prior year's tax return. Proves household income is below the program's cap.
Insurance card
Confirms the applicant has no coverage, or that their coverage denied this specific drug. Sponsors don't want to displace commercial insurance.
Prescription
The prescriber's Rx pad script with NPI, dosage, and refills. Proves medical need for the exact drug the program covers.
The decision

Three outcomes an administrator can issue

Every submitted case ends in one of three states. Each one is a letter with different content and, importantly, different next-step instructions for the applicant.

Approve

Meets income, medical, and insurance criteria.

  • Approval letter + first ship date
  • Refill schedule
  • Benefits guide + re-attestation reminder

Deny

Fails at least one hard rule (usually income cap, commercial coverage, or wrong indication).

  • Denial letter citing the specific rule that failed
  • Appeals notice (60-day window)
  • Resubmission form if circumstances change

Missing information

Application isn't decidable as sent. A required document is absent or unreadable.

  • Missing-info letter with an itemized checklist
  • Instructions to submit only the delta
  • Case held open, no denial recorded
The reply

Why the outbound letter isn't just a letter

Because it's the record that leaves the building. Regulators, sponsors, and internal audit teams all reference the same PDF for years. The letter has to be reproducible from the audit log (same frozen template, same input, same render stack, same output) long after the AI models that helped produce it have changed versions.

And the reply is rarely a single letter. Depending on the outcome it may be an ordered document package: outcome letter → appeals notice → benefits guide → whatever blank forms the applicant needs next. The administrator declares the package composition in advance; it never changes at render time.

The full picture

From every channel to the patient's door

Verdikt is the AI + deterministic-render pipeline in the middle of a much larger operation. The intake channels on the left all normalize into one case; the pipeline (highlighted) reads, decides, and produces the byte-identical reply; downstream systems dispatch the physical order to fulfillment. In production, outbound goes via pharmacy OMS + carrier + case management; the demo mailbox also replies by email so the result is visible.

INBOUND NORMALIZE VERDIKT PIPELINE · AI in, deterministic out DOWNSTREAM FULFILLMENT Email applicant · plus attachments Fax prescriber office · fax-to-email Mail (scanned) physical intake · digitized Web portal patient / caregiver form EHR · REST/API provider system · JSON push Intake normalizer tenant resolve · dedupe one case per applicant Ingest → Triage → Decide → Deliver → Remember Ingest read stack → structured fields Triage classify + route → new/refill/appeal Decide rules + verdict → approve/deny/miss Deliver frozen template → byte-identical PDF Remember audit + sha256 → reproducible STOP AI ends here Case in. Verdict out. Same case, same reply, forever. FEEDER · DATA + CONFIG MDM patient · prescriber master identity Rules Library program eligibility versioned YAML Template Library frozen · sha256 human-approved Audit Log · S3 every stage · every artifact · retained Pharmacy OMS dispensing order on approve · SFTP/API Case Mgmt · CRM orchestrates dispatch, outreach, appeals Patient Portal signed letter · status delivered in-portal Carrier FedEx / UPS / USPS Patient medication delivered READ BY DECIDE EXTERNAL VERIFIERS · THIRD-PARTY APIS · ILLUSTRATIVE Identity bureau identity · income verification Address validation postal service · standardization APIs Benefits verification eligibility vendors · payer clearinghouses NPI Registry CMS · prescriber validation All channels normalize to the same case. Fax and mail turn into email attachments upstream. The green box is Verdikt — the AI-in / deterministic-out pipeline this repository ships. The whole pipeline hands off to Case Mgmt / CRM; CRM dispatches to Pharmacy OMS on approve and updates the Patient Portal on every outcome. Feeders (reference data + config) & External Verifiers (third-party lookups) are all read at the Decide stage. Outbound to the patient is via signed portal + carrier — never email.
Verdikt pipeline (this repository) Partner / channel system Feeder (data + config) Physical fulfillment
Where Verdikt fits

The five stages, mapped onto the domain

Verdikt is the pipeline that reads the case, decides against the program's rules, delivers a byte-identical reply package, and remembers the trail. Here's how each of the five stages maps onto the flow above, the same five stages the timeline pill in the demo video walks through.

Ingest
Reads the intake stack (enrollment form, pay stubs, insurance card, prescription) and turns each into structured fields. Uses MiniCPM-V on Nebius for multimodal extraction.
Triage
Nemotron Nano on Nebius classifies the case (new intake · refill · appeal · missing-info reply · not decidable — plus any program-specific case type the operator adds) and picks a route. Each row carries a decision needed? flag: when off, the pipeline skips the Decide stage entirely and dispatches straight to the target (refills to Pharmacy OMS, not-decidable to reject, etc.). Rule-based classifier is the safety net when the LLM call fails or returns low confidence.
Decide
Retrieves the program's eligibility rules (dense-vector search with Qwen3-Embedding on Nebius), then runs Nemotron Super to produce a structured verdict (approve / deny / missing info) with citations back to the specific rule that fired.
Deliver
Merges the verdict into a frozen human-approved template (Alderwood's ASP-201 for approvals). No AI runs at render time. The bytes come from templates a human already signed off.
Remember
Every stage is recorded in the audit trail (model, timing, outcome), and each render is stamped with the frozen template's sha256 and a render-stack fingerprint. Years later, a reviewer can trace exactly what produced the PDF that left the building.
Reference

Glossary

Terms that show up in the demo, the templates, and the code.

Show the glossary
PAP
Patient Assistance Program. Manufacturer-funded grant that covers the cost of a specific medication for eligible patients.
PBM
Pharmacy Benefit Manager. The middleman between an insurer and pharmacies for prescription drugs.
PA
Prior authorization. Insurer's approval that a specific drug is medically appropriate before dispensing.
Rx
Prescription. The prescriber's written order for a specific medication, dosage, and refill count.
NPI
National Provider Identifier. A 10-digit ID issued to every prescribing clinician in the United States.
DEA #
Drug Enforcement Administration registration number. Required on any prescription for a controlled substance.
Formulary
An insurer's list of covered drugs, usually tiered by copay level.
Copay
The patient's out-of-pocket share of a prescription cost, after insurance pays its portion.
Enrollment form
The intake application. In the demo it's Alderwood's ASP-100, a 2-page fillable PDF.
Outcome letter
The compliance-audited reply that documents the administrator's decision. In the demo it's ASP-201 (approval), ASP-202 (denial), or ASP-203 (missing info).
Doc package
An ordered set of documents the applicant receives for a given outcome, e.g. approval letter + benefits guide + next-refill reminder.
Preflight
Static analysis of an uploaded template before it can be labeled; checks for form fields, page count, and font embedding.
Placement
A named region on a template PDF (e.g., patient.dob) that the render pipeline fills at merge time.
Freeze
Marking a template version as immutable and production-ready. Frozen versions are the only ones that can render outbound letters.