Variant-aware PA decisions,
grounded in FDA labels.
Send an anonymised tuple of variant, drug, tumor type, prior therapies, and payer. Get back a decision (likely covered, requires PA, not on policy, or insufficient data) with the source excerpt and citation URL. No patient identifiers in the request. No PHI in the LLM path.
Foundation: FDA labels + CMS LCDs + openFDA, with citation back to the source excerpt. Bring your own guideline content (NCCN, OncoKB, institutional formulary) through the external_levels hook to layer guideline-aligned criteria on top of the FDA baseline.
How it reaches a decision
Three layers, in order. Each one returns a citation back to its source.
- 1
FDA label cross-check
Looks up the proposed drug on openFDA and verifies the variant + tumor pair against the indications_and_usage section. If aligned, decision is likely_covered with the relevant SPL excerpt and a DailyMed citation URL.
- 2
Payer-policy match
If the FDA-label path doesn't apply, queries pa_policies for the named payer. Today: CMS LCDs (free public API, 958 documents indexed) and Cigna oncology policies. Returns a policy_section + source_excerpt + citation_url when a policy mentions the tuple.
- 3
External-level hook for guideline content
Layer your existing NCCN, OncoKB, or institutional formulary content on top. The engine surfaces the matched level under external_levels on the decision response so guideline-aligned criteria appear next to the FDA baseline. Schema-only on the UNMIRI side; your license, your content.
Payer coverage today (honest matrix)
Policies are reproducible from public sources where the payer's terms allow. Payers whose terms-of-use explicitly prohibit automated retrieval are not included.
| Payer | Status | Source |
|---|---|---|
| CMS LCDs (MolDX, Palmetto, Noridian, ...) | Live | api.coverage.cms.gov · 958 indexed |
| Cigna oncology policies | In progress | static.cigna.com (robots-allowed PDF index) |
| CMS NCDs | Planned | api.coverage.cms.gov (per-NCD endpoint) |
| UnitedHealthcare | By data-licensing only | UHC ToS prohibits automated retrieval |
| Aetna | By data-licensing only | Aetna ToS prohibits automated retrieval |
| Kaiser Permanente | Not pursued | Closed HMO; low commercial PA volume |
The honest answer on UHC, Aetna, and Kaiser: their public-policy pages forbid automated retrieval in their Terms of Use. We don't scrape them. If you already license their policies through MCG, Carelon, Zelis, or MMIT, the ingest pipeline is generic enough to consume that data without re-engineering.
The API
POST /v4/pa/decide
Anonymised variant + drug + tumor + payer in. Decision + citation out.
POST /v4/pa/decide
{
"variants": [{"gene":"EGFR","hgvs_short":"L858R"}],
"drug_name": "osimertinib",
"drug_rxnorm_cui": "1721560",
"tumor_type": "non-small cell lung cancer",
"payer_code": "cms",
"line_of_therapy": 1
}POST /v4/pa/decide/sample
Developer-tier-safe sample IDs. No external network. Three pre-loaded scenarios.
POST /v4/pa/decide/sample
{ "sample_id": "egfr-l858r-osimertinib-cms" }GET /v4/pa/policies
List the ingested policies. Filter by payer_code.
POST /v4/pa/policies/ingest/cms-ncd
Admin-tier. Refresh CMS LCDs from the public Coverage API.
Wire-level details: /api-explorer. PHI policy: request payload is {variant, drug, tumor, payer, prior_therapies}. No patient identifiers. Decisions are audited per call.
Who this is for
RCM vendors, specialty oncology practices, and payer-side automation startups that need a variant-aware PA layer.
Drop-in PA reasoning layer behind your claims-scrub pipeline. Per-call billing aligns with your claim volume.
Pre-emptive PA decisioning at the order moment. Cite back to the policy section the payer will use.
Variant-aware criteria matching that incumbents (CoverMyMeds, Cohere, etc.) don't ship. White-label or co-brand.
Guideline content. UNMIRI's decision engine returns a citation-grounded answer against FDA labels + CMS LCDs out of the box. If your organization already licenses NCCN, OncoKB, or an institutional formulary, plug it in through the external_levels field on the response; the engine will surface the licensed level alongside the FDA-aligned decision so both views appear side by side.
Frequently asked questions
Which payers does the engine cover today?
CMS LCDs across all MAC jurisdictions (MolDX, Palmetto, Noridian, etc.) are production-ready today, refreshed monthly from api.coverage.cms.gov. Cigna oncology policies are in active rollout (clean URL pattern, monthly bulletin). For UHC, Aetna, and Kaiser, we read your existing aggregator feed (MCG, Carelon, Zelis, MMIT) rather than re-deriving the policies ourselves — the ingester is generic enough to consume any structured feed.
Do you support NCCN-aligned criteria?
Yes — through the customer-bring-your-own hook on every decision response. Your NCCN compendium license stays with you; the engine surfaces the matched NCCN level under external_levels alongside the FDA-label baseline. Same pattern works for OncoKB, ASCO Guidelines, or institutional formularies.
What does 'FDA-label-aligned' mean for the decision?
Every likely-covered decision cites a specific section of the drug's FDA label (typically indications_and_usage) where the variant + tumor combination is named, with a link back to the SPL on DailyMed. The engine is conservative: it returns likely_covered only when the FDA label explicitly supports the indication, requires_pa when a payer policy applies but isn't aligned, and insufficient_data when the request is missing the variant tuple or drug identifier.
How is the decision cited back to source?
Every response includes policy_section (which document section applied), source_excerpt (the 200-character window around the matched text), and citation_url (the public link to the policy or FDA label). You can show this to a reviewer; nothing is generated without a citable source.
Can we plug in our own MCG, Carelon, Zelis, or MMIT data?
Yes. The pa_policies table is schema-driven, not source-locked. Provide your aggregator's policy export (CSV, JSON, or a vended API) and we add a per-payer ingester that pre-populates the engine with your licensed content. No scraping required.
Do you sign a BAA?
Yes, on the partner tier. The decision request payload is intentionally anonymized — variant, drug, tumor type, payer, prior therapies — none of which carry patient identifiers. The PHI control plane stays in our AWS account under the AWS BAA.
What's the per-call latency?
Decision API p95 is under 600ms warm. The FDA-label lookup hits openFDA's cached responses; the payer-policy match is a Postgres ILIKE against the pre-indexed policy_text. No LLM in the critical path.
What does the partner tier add over the developer sandbox?
Developer sandbox is free, three pre-loaded sample tuples, no authentication. Partner tier adds: arbitrary variant + drug + payer tuples on /v4/pa/decide, per-call audit log retention for 7 years, configurable payer-policy ingestion for your aggregator, signed BAA, monthly invoice with per-call detail, and a named compliance contact.