Live demo environment — all data is synthetic · no PHI Security details
Apex MediSuite
Sign in
Prior Authorization + Value-Based Care · one platform

Care shouldn't have to wait for paperwork.

Right now, somewhere in your organization, a patient is waiting on an authorization that has been sitting in a fax queue for nine days. A nurse is on hold with a payer. A coordinator is digging through the wrong PDF for the right criteria. Apex MediSuite was built to end that: prior authorization and value-based care on one system, where requests carry their own clinical context, decisions run on real clocks, and closed care gaps prove themselves with evidence.

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. The problem isn't the people. It's that the work runs on phone calls, faxes, and fifteen browser tabs.

The waiting

Treatment plans stall while requests crawl through intake queues and callbacks. Patients reschedule, then reschedule again. Some quietly give up on care their physician already ordered. Urgent cases deserve a clock, not a hope.

The losses

Avoidable denials become rework. Rework becomes appeals. Appeals that overturn were never worth denying, and every cycle costs staff hours, delays revenue, and erodes the trust between payers and providers that the whole system runs on.

The research grind

Which plan requires authorization for this procedure? Under which policy, which version, with what documentation? Your best people spend their days answering that question from scratch, across dozens of payer portals and PDF manuals that change without notice.

It doesn't have to work this way.

Apex MediSuite answers the coverage question before the order is placed, moves the request with its clinical evidence already attached, runs every decision on a regulatory clock, and puts a licensed physician's name on every adverse determination. When the care happens, the record closes itself. Your team gets their days back, and your patients get their care on time.

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. One orchestration engine.

A shared patient record, one workflow engine, versioned policy packages, and a single audit spine — so an authorization is a step inside the care journey, never a separate silo.

Prior Authorization

Utilization management for payer review teams and provider intake

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

  • Policy resolver: payer × line of business × state × service code resolves to a versioned criteria package — in-flight cases keep their snapshot.
  • Five-state criterion outcomes with linked evidence — unknown is never collapsed into false.
  • AI advisory review: visually distinct recommendations with evidence links; structurally unable to decide.
  • SLA clocks from submission: 72-hour expedited / 7-day standard defaults, configurable per payer type.
  • Adverse determinations require a physician credential plus a specific reason code and text — the server rejects anything less.
  • Idempotent intake: duplicate submissions are blocked at the API, not deduped after the fact.

Value-Based Care

Population workflow for ACOs and risk-bearing providers

Care-gap work that executes — not a dashboard describing last quarter.

  • Risk-tiered registry with provenance-carrying risk factors — every flag cites its source and date.
  • Care gaps versioned to measure package and value set for digital-HEDIS-style reproducibility.
  • My Work queue: ranked, reasoned tasks for care managers — why this patient, why today.
  • Interventions as state machines — guard-checked transitions, duplicate creation blocked.
  • Scheduling gated on authorization state: no booking a service against a pending PA.
  • Evidence-only closure: a PA approval never closes a gap — only clinical evidence does.

The cross-module golden path

How it works

This is the flow siloed tools can't run: one event choreography from an open quality gap to an evidenced closure, with every hop guard-checked on the server and written to the same hash-chained 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

Gap evidence pre-attached; no re-keying, no lost context.

4

Human-signed decision

RN pends or approves; only an MD can deny — 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 evaluated on clinical evidence — never on the approval.

Every transition is validated against an explicit state table. Illegal moves return 409 — in the demo, you can try to break it.

Platform

Built like infrastructure, not another portal

Six properties run through every module. The UI is a projection — every rule below is enforced server-side and observable in the audit trail.

Workflow state machines

No status strings. Every PA and intervention transition is validated against an explicit table; illegal transitions are 409s, and no handler mutates state directly.

Versioned policy & criteria packages

Rules are data: effective-dated, versioned packages resolved per payer, line of business, state, and service. In-flight cases keep the snapshot they started with.

Hash-chained audit trail

Append-only events with correlation IDs on every PHI-class action. /ops/audit-verify recomputes the chain on demand — integrity is monitored, not assumed.

Governed AI

Advisory rows physically cannot transition state — a compromised prompt cannot deny care. Model and version are logged on every recommendation.

Role + credential-gated decisions

RBAC and tenant ABAC on every query, server-side only. The deny path additionally demands a physician credential — statutory control expressed as code.

SLA clock engine

Decision-due computed at submission from configurable timeframes — 72-hour expedited and 7-day standard defaults — with queues ranked by the clock.

Demo access

See it for yourself

The full product is running right now on synthetic data. No signup, no sales call: pick a persona, sign in, and push on the guardrails.

1

Open the app

Go to mdvin.com/app — it runs in your browser, 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 where to start — or take one of the three guided flows underneath.

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, start the intervention for the diabetic retinal exam gap, and launch the PA — the gap's evidence rides along automatically. Scheduling stays locked until the decision lands.

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, read the AI advisory and the five-state criteria evaluation, then pend or approve. Switch to md@demo.payer for the adverse path — credential plus specific reason required.

AI recommends. A credentialed human decides. Always.
Step-by-step in the manual

The Deny Guard

~2 min

Sign in as the RN and try to deny a PA. The server refuses with a 403 — adverse determinations require a physician credential, and that rule lives in the API, not the interface. Then check the audit trail: the refused attempt is logged too.

Our guards are server-side. The UI is just a projection.
Step-by-step in the manual
Security & compliance

Every decision leaves a record we would be comfortable defending.

Designed to the HIPAA Security Rule as proposed in the 2025 NPRM, with SOC 2-aligned control design and OWASP ASVS-level practices — every control enforced server-side, and every PHI-class action written to an append-only, hash-chained audit 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, however, are built as if the data were real — that is the point of the demo.
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?
By construction, not by policy text. AI outputs land as advisory rows that structurally 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.
Do you license clinical criteria like InterQual or MCG?
No — and that is deliberate. Criteria, policies, SLAs, and measures are versioned data packages in the platform, not 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.