…
Trust Center

Security & Compliance

Every control described on this page is enforced in code — in the state machine, the permission layer, and the audit spine — and can be independently inspected against the running system. Nothing here is a policy PDF promise.

Last reviewed: Aug 13, 2026 Security baseline v0.1 Controls-as-code Synthetic data only
Posture

Security-first by architecture, not by afterthought

mdvin is a prior-authorization and value-based-care orchestration platform for a domain where a wrong decision is a legal event. The platform therefore treats security and decision governance as one discipline: statutory constraints are compiled into the workflow state machine, every privileged action requires an authenticated, credentialed actor, and every state change lands in an append-only, hash-chained audit trail.

The hosted environment you can sign into today is a live demo environment running entirely on synthetic data — no PHI is stored or processed. The controls are built as though the data were real, with the same guards, the same audit chain and the same server-side refusals. You can verify that yourself — the audit integrity endpoint (/ops/audit-verify) recomputes the hash chain on demand, and the Auditor demo role gives read-only access to full decision traces (credentials in the manual).

Controls as code

Guards run inside the workflow engine itself. An illegal transition returns an HTTP 409 from the API.

Inspectable, not asserted

Hash-chained audit trail with a public self-check endpoint; correlation IDs tie every UI action to server events.

Humans decide

No AI or automation path can issue an adverse determination. The deny transition demands a physician credential.

Synthetic by design

Every patient, payer, and policy in the demo is fictional. A deployment flag pins the environment to synthetic-only mode.

Regulatory alignment

Built against the 2026 regulatory reality

mdvin is designed to align with the frameworks below. Where a control is enforced in code today we say so, and where alignment is still a design target or a roadmap item we say that instead. We do not claim certifications or attestations we do not hold.

Framework What it demands Where mdvin stands Status
HIPAA Security Rule
incl. Jan 2025 NPRM direction (final rule expected ~2027)		 The proposed rewrite removes the required-vs-addressable distinction and points to mandatory MFA, encryption in transit and at rest, asset inventory and network mapping, prescriptive risk analysis, and vulnerability-scanning cadence. The build targets the NPRM rather than the current minimum: MFA slot (TOTP) on every account with an enforcement flag; TLS-only transport with HSTS; Argon2id password storage; documented deployment checklist covering asset inventory and least-privilege database users. Field-level encryption at rest with managed keys is a tracked roadmap item. Designed to align
CMS-0057-F
Interoperability & Prior Authorization Final Rule		 Since Jan 1, 2026: 72-hour expedited / 7-calendar-day standard decision timeframes, specific denial reasons (no generic denials), and annual public PA metrics. From Jan 1, 2027: Prior Authorization, Patient Access, Provider Access, and Payer-to-Payer APIs. SLA clocks are computed server-side at submission (72h/7d, configurable per payer type, since scope is never hard-coded). The deny transition returns HTTP 422 without a reason code plus reason text. PA records carry channel provenance for metrics capture. API alignment path follows the Da Vinci CRD / DTR / PAS pattern (FHIR facade on the roadmap). Enforced in code
CA SB 1120
"Physicians Make Decisions Act" + NAIC AI Model Bulletin (~25 states adopted)		 AI may not autonomously deny, delay, or modify care on medical-necessity grounds; a licensed physician with relevant clinical expertise must make the determination; plans must disclose and audit AI use. The NAIC bulletin adds a written AI-systems program with model validation and vendor oversight. Enforced server-side in the state machine: the deny transition requires the pa.decide permission and a physician credential (MD:*) — an RN attempting a denial is refused by the server whatever the client sends. AI output is written as advisory rows that structurally cannot touch case state, and every advisory is logged with model and version for audit. Enforced in code
42 CFR Part 2
Substance-use-disorder records		 Heightened confidentiality and consent handling for SUD treatment records, requiring segmentation from the general record. Segmentation hooks are a tracked design item on the production path; the current demo carries no SUD data (all records synthetic). We would rather say so than imply coverage we have not built. Planned
SOC 2 (CC-series)
Trust Services Criteria		 Independent attestation over security, availability, and related common criteria — the entry ticket for US enterprise procurement. SOC 2-aligned controls: access control with least privilege, change-tracked configuration, structured logging, backup and restore testing, incident-handling runbooks on the deployment checklist. Formal Type II attestation is on the roadmap and would accompany any production engagement; we do not claim it today. Aligned controls

Wording note: "designed to align" means the control objectives shaped the architecture and the relevant mechanics exist in code; it does not assert regulatory compliance status or a third-party attestation, neither of which apply to a demo environment holding no PHI.

Technical controls

The controls matrix, honestly stated

Six domains, every item below verifiable against the running system or the deployment configuration. Items we have deliberately deferred are listed later in shared responsibility & roadmap — not silently omitted here.

Identity & access

  • Passwords hashed with Argon2id (memory-hard), minimum length 12 characters
  • Login throttling (10/min) and lockout (5 failures → 15 minutes) with a generic 401 response, so accounts cannot be enumerated
  • JWT access tokens capped at 15 minutes; refresh tokens with an 8-hour absolute ceiling; jti present for revocation
  • TOTP MFA slot on every user record with an enforcement flag — to be switched on before any non-demo exposure
  • RBAC permission matrix plus tenant ABAC applied to every query, on the server; the interface holds no authorization logic at all
  • Cross-tenant access returns 404 with no existence leak; negative tests pin this behavior

Decision governance

  • Adverse determinations are credential-gated: deny requires a physician credential; the server refuses all others
  • Denial without a specific reason code + reason text is rejected (422) — there is no way to record a generic denial
  • Criterion outcomes are five-state end-to-end (met / not met / unknown / not applicable / needs human review) — an unknown is never recorded as a no
  • Clinical policy packages are versioned and effective-dated; in-flight cases keep their policy snapshot
  • AI is advisory-only by construction, with model + version logged on every advisory row

Auditability

  • Append-only, hash-chained audit trail — each event carries the hash of its predecessor
  • Every PHI-class read, write, and decision logged with actor, tenant, and timestamp
  • Correlation IDs on every request, surfaced in the UI, joining user action to server-side events
  • /ops/audit-verify recomputes the entire chain on demand, so integrity is checked rather than assumed
  • Dedicated read-only Auditor role scoped to decision traces

Transport & headers

  • TLS 1.2+ only at the edge; HTTP redirected to HTTPS; HSTS outside development
  • Content Security Policy of default-src 'none' on API responses
  • X-Content-Type-Options: nosniff and DENY framing on every response
  • Cache-Control: no-store — so clinical data is never cached downstream
  • No-referrer policy; no third-party scripts inside the application shell

Application security

  • All persistence through SQLAlchemy parameterization — no string-built SQL anywhere
  • Pydantic validation on every request body; typed contracts via OpenAPI
  • Global rate limit (120/min per client) plus the stricter login throttle
  • Generic error contract: no stack traces, no internal identifiers, no object-existence leakage across tenants
  • Secrets are environment-only; production boot refuses to start on a default JWT secret

Operations

  • systemd hardening: NoNewPrivileges, ProtectSystem, dedicated non-privileged service user
  • Per-application directory jail — the service sees only its own tree
  • Least-privilege database account for the application role
  • Nightly database backups in rotation, with restores tested rather than only scheduled
  • Dependency and secrets scanning on the deployment checklist before every release
The decision trace

Every determination is reproducible — by design

Recent litigation over algorithmic utilization management has established that when a determination is challenged, the algorithm, its inputs and its audit trail all become discoverable. mdvin is built with that day in mind. Every prior-authorization decision stores the policy package version it was evaluated against, the five-state outcome of each criterion, any AI advisory with its model version, the reviewer's identity and credential, and timestamps for every transition — all bound into the hash-chained audit trail. A historical decision can be replayed exactly as it happened. The answer to a challenge is therefore a complete record of what happened rather than an assurance that the software behaved, which is one always can.

Why this shape matters

Audit-ready Reviewer credentials, timeliness against the regulatory clock, criteria-version traces, and denial-reason logs are exactly the artifacts payer audits and accreditation reviews ask for.
Discovery-ready If a determination is ever litigated, the full evidentiary chain — inputs, rule version, advisory content, human signatory — already exists in one tamper-evident record.
Reproducible Because in-flight cases pin their policy snapshot, a decision replays against the rules as they stood at the time.
Inspectable now Sign in with the Auditor demo role and open any decided case — this trace is a real screen in the application. All demo data is synthetic.
AI governance

Seven rules the AI cannot break

AI in utilization management is now constrained by state statute — California's SB 1120 requires that a licensed physician with relevant clinical expertise, not an algorithm, makes medical-necessity determinations, and the NAIC model bulletin (adopted in roughly 25 states) requires a governed, auditable AI program. Our answer to that is architectural. The seven rules below are properties of how the system is built, and they cover every surface that could influence care: the review advisory, the documentation readiness check, the Ask mdvin assistant, and — added 2026 — the risk-scoring engine and the next-best-action engine. Those last two are deterministic rule engines, not models. We say so plainly because the distinction cuts both ways: it is what makes every score explainable, and it means nothing here should be described as a prediction.

Grounded

Advisories are generated only from the tenant's own policy packages and the case record in front of the reviewer — and never from open-ended generation.

Evidence-linked

Every recommendation cites the criterion and the evidence item it rests on, rendered visually distinct from deterministic rule results.

Logged with model version

Each advisory row records model and version in the audit trail — which gives the registry that state AI-use audits now expect.

Structurally incapable of adverse action

Advisory rows have no write path to case state. A compromised prompt cannot deny care, because no code path connects AI output to the deny transition.

Bound by the caller's own permissions

The assistant runs as the person asking, not as the system. Every query filters to their tenant and every question is checked against their own permissions, so it refuses exactly where the API refuses and names the permission that is missing. It cannot become a side channel around access control.

Phrasing never becomes fact

Language-model phrasing is off by default. When enabled it receives the finished conclusion and its facts, never the record, and it is refused outright unless the deployment is marked synthetic-only. Every number in its output must already appear in its input, or the rephrasing is discarded and the computed sentence kept. Answers a model touched are labelled, and the audit row records which.

A named model must have actually run

Any score that influences care displays the engine and version that produced it, and that name must refer to something that ran. Where no engine has scored a member, the screen says so in those words rather than showing a version string. Scores are written to a history table, so "which engine, which version, on what inputs, when" has an answer for any past decision, and the version is bumped whenever a weight changes so an old score still means what it meant. A displayed model version is a disclosure claim, and an unsupported one is the kind of detail that surfaces in discovery rather than in a demo.

Try it live: sign in as the UM Nurse demo user, attempt a denial and the server will refuse it, then repeat as the Medical Director with a specific reason. The guard sits in the API itself.

Data handling

What we hold, what we log, what we never touch

The demo environment operates under a strict synthetic-data policy: every patient, member ID, coverage, and clinical value is fictional and generated for demonstration. There is no PHI in the system, and the handling rules below are enforced as though there were.

Synthetic data policy

  • All records seeded from a fictional dataset; patient rows carry an explicit synthetic flag
  • A deployment-level synthetic-only flag pins the environment's scope
  • No integrations to real payers, providers, EHRs, or clearinghouses from the demo
  • No real member, patient or provider data in any form

What we log

  • Structured JSON application logs: request path, status code, latency, correlation ID
  • Audit events: actor, tenant, action, timestamp, chained hash
  • AI advisories: model, version, evidence references
  • No request or response bodies in logs
  • No PHI-class fields in logs — a hard rule, not a filter

Retention & resets

  • Audit events are append-only and retained for the life of the environment — they are part of the record itself
  • Demo working data may be reseeded periodically; resets restore the published synthetic dataset
  • Nightly backups in rotation with restore testing; backups contain synthetic data only
  • Demo accounts and their activity may be cleared on reset without notice
Shared responsibility & roadmap

What's deferred, said out loud

A trust page that lists only finished work is a marketing page. This section covers the other half: the controls a production, PHI-bearing deployment requires and this demo environment deliberately defers. Each one is tracked and belongs to the production path.

Shared-responsibility model: the platform enforces workflow guards, authorization, audit integrity, and transport security. A production customer engagement adds the contractual and environmental layer: Business Associate Agreements across the chain, identity federation with the customer's IdP, network placement and the attestation program below. Neither list works without the other, which is why both are written down here.
Production gate
BAA chain + SOC 2 / HITRUST attestations
Required before any real PHI enters. SOC 2 Type II first, HITRUST as the payer-grade credential. Today we claim aligned controls only, and assert no attestation.
Production gate
Field-level encryption with managed keys
Identifier-level encryption at rest under KMS-managed keys, aligning with the HIPAA NPRM's universal-encryption direction. Transport encryption and hashed credentials are in place today.
Production gate
SIEM shipping, anomaly alerting, WORM audit tier
Off-box log shipping with alerting, and a write-once storage tier for the audit chain. The chain is tamper-evident today, and write-once storage would make it tamper-proof at the storage layer.
Production gate
Penetration testing & DAST cadence
Scheduled third-party penetration tests and dynamic scanning, per the NPRM's direction on testing cadence. Static analysis, dependency and secrets scanning are already on the release checklist.
Tracked
JWT revocation cache + refresh rotation
Tokens already carry a revocation identifier (jti) and expire in 15 minutes; a backing revocation list and refresh-token rotation complete the story.
Tracked
42 CFR Part 2 segmentation hooks
Data-classification and consent segmentation for SUD records, ahead of any tenant that handles them.
Tracked
FHIR facade — Da Vinci CRD / DTR / PAS
The CMS-0057-F API pattern (payer APIs due Jan 1, 2027) as a conformance surface over the same decision spine; the internal model already carries the provenance those APIs require.
Responsible disclosure

Found something? Tell us.

We welcome good-faith security research

If you believe you have found a vulnerability in mdvin or this demo environment, we want to hear about it. Report it privately and include the URL, steps to reproduce and the correlation ID from the response header if you have one. We will acknowledge receipt, investigate, and keep you informed through remediation.

security@bvlogic.example (placeholder address for the demo environment)

Please avoid testing that degrades the service for other demo users, and remember that the environment holds synthetic data only, so there is no PHI to find. We do not run a paid bug-bounty program at this time and make no reward commitments. We do commit to taking every credible report seriously and to crediting researchers who would like to be named.