mdvin is a clinical orchestration platform for US healthcare. It runs prior authorization and value-based care on the same engine, which is the part that matters: in most organisations these are two systems that do not speak, so the authorization a care gap requires is raised by re-keying the member's details into a different screen, and nobody can tell afterwards whether the authorization led to the care.
Live at mdvin.com.
What it is today. A working platform with a full demo environment running on synthetic data. It is built to production standards and models the controls a real deployment needs, but it does not hold protected health information and carries no compliance certification. Where that line sits is set out below, because a healthcare buyer's first question is what is real.
Why the two modules belong on one engine#
A care gap and an authorization are the same story told twice. A member is overdue a retinal exam; the plan requires prior authorization for it; the authorization is approved; the exam happens; the gap closes. Four systems usually own those four steps, and the seams between them are where the work is lost.
On one engine the sequence is a single thread: the gap identifies the member, the requirement check says whether an authorization is needed, the authorization is launched with the clinical context already attached, scheduling stays blocked while it is pending, and the completed service closes the gap. Every step carries the identifiers of the ones before it, so the question did this authorization actually result in care has an answer rather than an opinion.
What it refuses to do, and why that is the feature#
Healthcare software fails buyers by claiming more than it does. These are constraints enforced in the code rather than promised in a brochure:
- AI never issues an adverse determination. The copilot produces an advisory recommendation with its evidence attached; a credentialed physician makes the decision, and a denial requires a specific reason. The advisory record physically cannot change the state of a request. That is CA SB 1120 and the NAIC model bulletin implemented as a state machine rather than as a policy statement.
- An approved authorization never closes a care gap. Only clinical evidence does. Approval means the plan will pay for the service; it does not mean the member received it, and a platform that conflates the two reports care that did not happen.
- A member who is not eligible for a measure is not "compliant". Denominator, numerator and exclusions are separate answers. Folding "excluded" into "met" is the commonest way a quality rate gets inflated.
- Numbers that cannot be computed honestly are returned as unavailable, with the reason. Avoidable ED utilisation needs a licensed classification set the platform does not hold, so it says so rather than printing a plausible figure. The same rule governs projections: it projects a rate of change, and refuses when the series is too short or too noisy to carry a line.
What it does#
Prior authorization. Provider intake with eligibility and requirement checking, payer-side utilisation review with the CMS-0057-F clocks running — 72 hours expedited, seven days standard — specific denial reasons, appeals with independence enforced between the original decision-maker and the reviewer, and a decision trace that reconstructs what was known when.
Value-based care. Risk stratification that shows the factors behind each tier, quality measures computed from a coded clinical record rather than authored by hand, care-gap identification and closure, member outreach, transitions of care, and contract performance: PMPM against benchmark, shared savings, and the quality gate that decides whether any of it is earned.
The management layer above both. Contract health in a single view, the specific gaps that close the distance to a quality gate, cost by category against benchmark, and the ability to turn a population finding into prioritised work for a named care manager — then measure whether that work moved anything.
Standards, because interoperability is not optional here. FHIR R4 with US Core, the Da Vinci CRD / DTR / PAS pattern for electronic prior authorization, X12 270/271 and 278, and coded terminology throughout. Clinical criteria are versioned data packages rather than logic buried in code, so a decision made last quarter can be reproduced against the rules that applied then.
The state of it, stated plainly#
The platform runs a full demonstration end to end, on synthetic data, with published credentials. What that means precisely:
- Real: the workflow engine and its guards, the clinical data store, risk and quality computation, the contract and financial engine, the append-only audit trail, role-based access control, the FHIR and X12 surfaces, and the reporting built on all of it.
- Simulated, and labelled as such on screen: the voice channel, and inbound feeds from systems of record. The governance around them — consent, quiet hours, audit — is real. The channel is not.
- Not claimed: SOC 2, HITRUST or HIPAA certification, production PHI handling, or a customer reference. Moving to real member data is a defined list of work rather than a switch, and that list is given to the people evaluating the platform instead of being discovered by them later.
Where it fits at BvLogic#
mdvin is the healthcare entry in the portfolio, and the one where the compliance surface rather than the model is the hard part. The discipline it forces — every number traceable to the record that produced it, every automated suggestion separable from every human decision — is the discipline the rest of our work is held to. It is simply easier to see here, because in healthcare the cost of getting it wrong is legible.