mdvin
Sign in
Prior Authorization + Value-Based Care · one platform

Care shouldn't have to wait for paperwork.

Somewhere in your organization right now, a patient is waiting on an authorization that has sat in a queue for nine days. A nurse is on hold with a payer. A coordinator is three PDFs deep looking for the right criteria. We built mdvin to put prior authorization and value-based care on the same system, so a request carries its own clinical evidence, every decision runs against a real deadline, and a care gap closes when the care actually happens.

Open the live demo Read the manual

Demo environment — all data is synthetic; no PHI. Full credentials published below.

The problem

Utilization review was supposed to protect care. Somewhere along the way, it started delaying it.

Ask anyone who works a prior authorization queue and you will hear the same thing. The staff are not the bottleneck. The work is spread across phone calls, fax machines, and a dozen browser tabs that do not talk to each other.

The waiting

Treatment plans sit while requests move through intake queues and callbacks. Patients reschedule once, then again. Some of them give up on care their own physician ordered. An urgent case needs a deadline that somebody is accountable to.

The losses

A denial that could have been avoided turns into rework, and rework turns into an appeal. When that appeal is overturned, the original decision cost both sides money and weeks for nothing. Staff hours go into resubmission, revenue lands late, and the working relationship between the payer and the practice gets a little worse each round.

The research grind

Does this plan require authorization for this procedure? Under which policy, which version of it, and what documentation will satisfy the reviewer? Experienced staff spend a large part of every week answering those questions by hand, across payer portals and PDF manuals that change without warning.

It doesn't have to work this way.

mdvin answers the coverage question before the order goes out and carries the clinical evidence along with the request. Every decision is held to the regulatory deadline that applies to it, and a denial requires a licensed physician's signature. When the care is delivered, the record closes on the evidence that comes back. Your staff spend their time on patients instead of paperwork.

Why now

CMS-0057-F SLAs are live

72-hour expedited / 7-calendar-day standard decisions and specific denial reasons apply to impacted payers since Jan 1, 2026 — and the CRD/DTR/PAS-pattern Prior Authorization APIs arrive Jan 1, 2027.

States are regulating AI in UM

California SB 1120 requires a licensed physician with relevant clinical expertise to make medical-necessity determinations — AI cannot autonomously deny — and the NAIC AI model bulletin has been adopted in roughly 25 states.

HEDIS is going digital

NCQA's digital measurement direction makes versioned measure packages, value-set versioning, and reproducible evidence-backed gap closure an engineering requirement — not a reporting afterthought.

Modules

Two modules on one engine

Both modules share the same patient record, workflow engine, policy packages and audit trail, so an authorization becomes one step inside the care journey rather than a separate system your staff has to reconcile.

Prior Authorization

Utilization management for payer review teams and provider intake

End-to-end electronic PA with server-enforced guardrails at every transition.

  • The policy resolver matches payer, line of business, state and service code to a versioned criteria package. Cases already in flight keep the version they started under.
  • Criterion outcomes have five states with evidence attached to each one, so an unknown is never recorded as a no.
  • AI review appears as a clearly labeled recommendation with links to the evidence behind it, and it has no ability to decide the case.
  • Decision clocks start at submission, with 72-hour expedited and 7-day standard defaults that you configure by payer type.
  • An adverse determination requires a physician credential together with a specific reason code and explanation. The server rejects anything less.
  • Duplicate submissions are refused at the API rather than cleaned up afterward.

Value-Based Care

Population workflow for ACOs and risk-bearing providers

Care gap work your team can actually run, from identifying the gap through to a documented closure.

  • A risk-tiered registry in which every risk factor cites the source record and the date it came from.
  • Care gaps are tied to a measure package and value-set version, so a closure can be reproduced later for audit.
  • A My Work queue that ranks a care manager's day and explains why each patient is on the list.
  • Interventions move through a defined set of states, with every transition checked before it is allowed.
  • Scheduling is held while a linked authorization is still pending.
  • A gap closes on clinical evidence. An approved authorization on its own never closes one.

The cross-module golden path

How it works

This is the sequence that separate systems cannot run end to end. It begins with an open quality gap and finishes with a documented closure, and every step is checked on the server and written to the same audit trail.

1

Care gap opens

Measure engine flags an overdue diabetic retinal exam.

2

Requirement check

Policy resolver: this service, this coverage — PA required.

3

PA with inherited context

The gap's evidence is attached already, so nothing gets re-keyed.

4

Human-signed decision

An RN can pend or approve. Only a physician can deny, and only with a specific reason.

5

Scheduling unlocked

The intervention can book only once the PA is decided.

6

Evidence returns

Imaging result lands against the encounter.

7

Gap auto-closes

Closure is evaluated against the clinical evidence that came back.

Every transition is validated against an explicit state table. An illegal move returns a 409, and the demo is open if you would like to try to break it.

Platform

Built like infrastructure

Six properties run through both modules. The interface only displays what the server has already decided, and every rule below is enforced in the API and visible in the audit trail.

Workflow state machines

Every authorization and intervention transition is validated against an explicit table before it is applied. Illegal transitions return a 409, and no request handler changes state on its own.

Versioned policy & criteria packages

Criteria and policy live as effective-dated, versioned packages, resolved by payer, line of business, state and service. A case in flight keeps the snapshot it started with.

Hash-chained audit trail

Every action on clinical data writes an append-only event with a correlation ID, and /ops/audit-verify recomputes the hash chain on demand so integrity can be checked rather than assumed.

Governed AI

AI output is stored as an advisory record with no ability to change the state of a case, so a manipulated prompt cannot deny care. The model and its version are logged with every recommendation.

Role + credential-gated decisions

Role and tenant checks run on every query, on the server. The deny path also requires a physician credential, which puts the statutory rule in the code path itself.

SLA clock engine

The decision deadline is calculated at submission from configurable timeframes, with 72-hour expedited and 7-day standard defaults, and queues are ranked by that clock.

Demo access

See it for yourself

The full product is running on synthetic data. There is no signup and no sales call in the way. Pick a persona below, sign in, and push on the guardrails.

1

Open the app

Go to mdvin.com/app — It runs in the browser with nothing to install.

2

Pick a persona

Copy any sign-in from the table below. Each role sees a different slice of the platform.

3

Follow a first action

Each row suggests a starting point, and there are three guided flows below.

Demo credentials — all five personas

Shared demo environment · synthetic data only
Role Sign-in Password What this role demonstrates
Care Manager jane@demo.aco CareManager!2026x
My Work queue, starting interventions, patient engagement, launching PAs from a care gap.
VBC Manager alex@demo.aco VbcManager!2026xx
Dashboard aggregates and population-level views across gaps, PAs, and interventions.
UM NurseRN nurse@demo.payer UmNurse!2026xxxx
PA review queue with AI advisory; pend or approve. Then attempt a denial; the server will refuse it, because an RN cannot make an adverse determination.
Medical DirectorMD · Ophthalmology md@demo.payer MedDirector!2026
Adverse determinations — the deny path demands this credential plus a specific denial reason.
Medical Director 2 md2@demo.payer MedDirector2!26x
Independent appeal reviews — the original denier cannot decide an appeal; this second physician can.
Auditor audit@demo.aco Auditor!2026xxxx
Read-only decision traces — who did what, under which policy version, with which evidence.
Platform Admin (backend) admin@demo.aco PlatformAdmin!26
The dynamic backend — sign in at mdvin.com/app → Administration: rename the product live, add / remove / rename fields on every entity. Changes apply across the platform instantly.

The Golden Path

~10 min

Sign in as jane@demo.aco. Open My Work and start the intervention for the diabetic retinal exam gap. When you launch the authorization, the gap's evidence goes with it, and scheduling stays locked until the decision comes back.

Care gap → PA → decision → schedule → evidence → closed.
Step-by-step in the manual

The PA Review Path

~5 min

Sign in as nurse@demo.payer. Open the review queue and read the AI advisory alongside the criteria evaluation before you pend or approve. Then switch to md@demo.payer to see the adverse path, which requires a credential and a specific reason.

AI recommends and a credentialed physician decides.
Step-by-step in the manual

The Deny Guard

~2 min

Sign in as the RN and try to deny an authorization. The server returns a 403, because the physician-credential rule lives in the API rather than the interface. Check the audit trail afterward and you will find the refused attempt recorded there as well.

The guardrails sit in the API, where they belong.
Step-by-step in the manual
Security & compliance

Every decision leaves a record you can defend

The platform is designed against the HIPAA Security Rule as proposed in the 2025 NPRM, with SOC 2-aligned control design and OWASP ASVS practices. Controls are enforced on the server, and every action on clinical data is written to an append-only, hash-chained trail whose integrity is verifiable on demand.

Read the full security documentation
Argon2id password hashing Short-lived JWT sessions RBAC + tenant isolation Credential-gated adverse decisions Hash-chained append-only audit Login throttling + lockout No-PHI structured logging Strict headers + CSP
FAQ

Common questions

Short answers here; the manual and security documentation carry the depth.

What data does the demo environment contain?
Only synthetic data. Every patient, member ID, coverage, care gap, policy package, and document in this environment is fictional and generated for demonstration. No PHI is stored or processed here, and the deployment runs with a synthetic-only flag. The controls are built as though the data were real, which is what makes the demo worth testing.
How does the demo reset? Will my changes persist?
This is a shared environment that is periodically re-seeded to a known baseline, so anything you create — interventions, PA decisions, notes — may be cleared without notice. Treat it as a sandbox. Push on the guardrails, try to break the state machines, submit duplicates. The audit trail will record all of it until the next reset.
How would this integrate with our EHR, clearinghouse, and payer systems?
The platform is API-first (typed contracts, OpenAPI) with a canonical domain model in the middle and adapters at the edges — channel is configuration. Provider-side flows are designed to align with the Da Vinci CRD / DTR / PAS FHIR patterns that CMS-0057-F and HTI-4 standardize on, and X12 transaction sets (270/271/278) are modeled as alternate channel adapters rather than a parallel product. PA records carry channel provenance, which the CMS PA-metrics reporting requires.
How is the AI governed?
The governance is structural rather than a policy statement. AI output is stored as advisory records that cannot transition a case — the deny transition requires a credentialed human actor with a physician credential, which is the operative requirement of California SB 1120 and the direction of the NAIC AI model bulletin adopted across roughly 25 states. Every advisory logs its model and version, recommendations are visually distinct from deterministic rule results, and the whole trace is designed to be reproducible: inputs, criteria version, outcomes, actor, and timestamps.

The same rules cover the two places you will actually touch it. The documentation readiness check is deterministic: it matches your record against the plan's criteria and cites what it found, so it never asserts a clinical fact, and anything it cannot evidence is reported unknown rather than unmet. The Ask mdvin assistant runs as the person asking, filtered to their tenant and gated on their own permissions, and every answer names the records behind it. Language-model phrasing is off by default; when it is on it receives the finished conclusion rather than the record, and any number it produces that was not in its input causes the phrasing to be discarded. See the six rules for the full statement.
Do you license clinical criteria like InterQual or MCG?
No — and that is deliberate. Criteria, policies, SLAs and measures live in the platform as versioned data packages rather than code. Customers load the criteria content they license (or author their own medical policy), with effective dating, four-eye approval, and prospective application; in-flight cases keep the version they started under. The demo environment ships with synthetic criteria packages for illustration only.
How do we evaluate this for a pilot?
Start with the demo: run the three guided flows above, then hand the manual to your UM and quality leads and the security documentation to your security review. Pilots run on a dedicated tenant with your configuration — payer types, timeframes, criteria packages, and roles. To arrange one, contact BvLogic Solutions LLC through the channel where you received this demo.