Skip to content
← Back to case studies
Healthcare Payor · Prior Authorization

Prior authorization, automated

Reference architecture for the F500 healthcare payor archetype — what a Vihaya prior-authorization pilot would look like. Production-shaped architecture; designed to deploy into the payor’s environment in a 12-week design-partner pilot. No paid pilot has completed yet.

Reference
Solution architecture in repo · pilots open
DPDP-aligned
Audit, citations, escalation by design
12 weeks
Pilot SOW to shadow run

The problem

Prior authorisation is the most expensive form of paperwork in healthcare. Large payors run utilisation-management operations of substantial scale — Indian health insurers and TPAs review large volumes of cases per month against thousands of policy clauses and clinical guidelines. Every decision needs an audit trail dense enough for a regulator. The work is rules-heavy, document-grounded, and high-stakes — exactly the shape LLM-driven decisioning is good at, if you can show your work.

Honest framing: Vihaya is pre-revenue with no paying customers. Patent drafts are in agent handover, not yet filed with USPTO. The architecture below is shipped in the repo with full unit-test coverage; the first paid pilots are the next milestone. Any industry-impact figures cited elsewhere describe other vendors’ deployed customer outcomes, not Vihaya’s.

The solution

A single agentic decisioning service. One POST, one immutable decision, one audit chain, and a queue of low-confidence cases routed to a human reviewer.

What it does, end-to-end

Behaviour, not architecture. The underlying engineering substrate is proprietary; what follows is what the customer’s reviewers, compliance team, and regulators experience.

  1. 1
    Receive

    PA request arrives via the payor’s existing intake channel; every action from this point is recorded in an append-only audit log mapped to SOC 2 control families.

  2. 2
    Ground

    The agent retrieves the relevant policy clauses, clinical guidelines, and any prior decisions for the same subject — so the eventual answer is anchored in the customer’s own source-of-truth, not the model’s general knowledge.

  3. 3
    Reason

    The agent applies the policy criteria to the case, produces a structured decision (approve / partial / deny / escalate), and attaches a model-reported confidence score and citations to the exact source passages it used.

  4. 4
    Decide

    Above the configured confidence floor the decision is recorded immutably and returned. Below the floor the case is force-routed to the customer’s existing human reviewer with the agent’s recommendation, rationale, and citations attached.

  5. 5
    Audit

    Every step of the chain — receipt, retrieval, model call, outcome, escalation, reviewer disposition — is linkable back to the underlying source. The audit chain is reconstructable from cold storage years later for IRDAI, RBI, or regulatory inspection.

Why this shape

  • One service, one shape. POST /api/pa/decide. The payor’s intake doesn’t change — only what happens after the request lands.
  • Confidence floor is a safety primitive, not a UI flag. Below threshold → escalation, regardless of model verdict. Tunable per drug class.
  • Citations are not optional. The decision row stores citation chunk IDs. Reviewers see the exact policy text the agent grounded on.
  • The audit trail is the product. Every step is one row in an append-only compliance log mapped to controls. Decisions are reconstructable from cold storage.

What ships in 12 weeks

  • ›Service deployed to your dev/staging environment with your UM corpus indexed
  • ›Inbound adapter for your intake (X12 278 / FHIR / portal API / file drop)
  • ›Outbound adapter back into your case-management / PA portal
  • ›Golden eval set scoped jointly with your medical director and signed off before shadow run
  • ›Confidence threshold locked to your medical director’s risk tolerance
  • ›OpenTelemetry traces exported to your observability stack
  • ›Runbook, threat model, retraining playbook

What a PA decision looks like to the reviewer

Every prior-auth case produces one immutable decision record. The reviewer console shows the outcome, the agent’s rationale, a confidence score, and citation links to the exact policy passages the agent grounded on — so the reviewer can verify the reasoning in seconds, not minutes. Behind the record sits an append-only audit envelope that captures the actor, action, and resource for every state change.

Schemas, control mappings, and the engine internals that produce this output are shared with design-partner customers under NDA. The Platform overview covers the capability shape; depth comes after the discovery call.

Honest caveats

  • Vihaya is pre-revenue and pre-SOC 2 Type II. The architecture is production-shaped; the audit firm is on the roadmap.
  • Any reference policies used during a demo are illustrative, not clinical. Real engagements load the payor’s own UM corpus behind the customer’s firewall.
  • No headline ROI figure is published here on purpose. Any impact estimate depends on the payor’s actual PA volume, per-case ops cost, automation rate, and reviewer-hour savings. The math applied to your specific book is part of the diligence step.
Next step

Want to be the first paid pilot?

12-week design-partner pilot. Your corpus, your environment, your eval set, your medical director’s threshold. Materially better economics in exchange for being the lighthouse.

Talk to us about a design-partner pilot