…
Demo environment — all data is synthetic; no PHI is stored or processed.
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

Apex MediSuite is a prior-authorization and value-based-care orchestration platform for a domain where a wrong decision is a legal event. So the platform treats security and decision governance as the same 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, however, are built as if the data were real: the same guards, the same audit chain, 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 live in the workflow engine, not in policy prose. Illegal transitions are HTTP 409s, not training slides.

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

Apex MediSuite is designed to align with the frameworks below. We state our position precisely: where a control is enforced in code today, we say so; where alignment is 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 Apex MediSuite 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. Built toward the NPRM, not the legacy floor: 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 — 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 regardless of what any 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 state this plainly rather than implying 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 — no composition theater
  • Login throttling (10/min) and lockout (5 failures → 15 minutes) with a generic 401 — no user enumeration
  • 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 — wired before any non-demo exposure
  • RBAC permission matrix plus tenant ABAC applied to every query, server-side only — the UI holds zero authorization logic
  • 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) — generic denials are impossible to record
  • Criterion outcomes are five-state end-to-end (met / not met / unknown / not applicable / needs human review) — unknown is never collapsed to false
  • 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 — integrity is monitored, not 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 — 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 restore actually tested, not just 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 made one thing clear: when a determination is challenged, the algorithm, its inputs, and its audit trail become discoverable. Apex MediSuite is built for that day. 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 algorithm did it" is a sentence this system cannot produce, and "here is precisely what happened" is one it 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 — not as they read today.
Inspectable now Sign in with the Auditor demo role and open any decided case — this trace is a real screen, not a diagram. All demo data is synthetic.
AI governance

Four 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. Apex MediSuite's answer is structural, not procedural: the rules below are properties of the system's architecture.

Grounded

Advisories are generated only from the tenant's own policy packages and the case record in front of the reviewer — 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 — the registry needed for the AI-use audits state regulators 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.

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 is in the API, not the UI.

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 if 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 — ever, 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 the product
  • 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 is the other half: the controls a production, PHI-bearing deployment requires that the demo environment deliberately defers — each tracked, each part of the production-customer 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 side's list works without the other; we write both down.
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 — no attestation is asserted.
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; WORM makes 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 Apex MediSuite or this demo environment, we want to hear about it. Report privately — 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 the environment holds synthetic data only — there is no PHI to find. We do not operate a paid bug-bounty program at this time and make no reward commitments; we do commit to taking every credible report seriously and crediting researchers who wish to be named.