Compliance status coming soon.
Compliance status will be published when it can be backed by concrete evidence across engineering controls, operational policies, vendor agreements, and legal review.
Until the status page is published, the product direction is tracked through compliance checklists, RBAC rules, audit foundations, and launch-gate criteria. This is a placeholder, not a self-declaration.
Product guidance, not legal advice. This page is intentionally a placeholder. No control is claimed as implemented, verified, or compliant on this page. Specific readiness signals are only shared in a procurement or security review context.
Why status is not just a badge.
A “HIPAA compliant” badge is a marketing artifact. It collapses code, deployment configuration, vendor contracts, training records, and operational drills into one green checkmark. That collapse is the problem.
The MediFlow status page will instead separate the layers that actually determine readiness: engineering implementation, verification evidence, vendor and legal agreements, operational procedures, and risk review. Each layer has its own owner, its own artifact type, and its own definition of done.
Until those layers can be shown with concrete evidence, the responsible thing to publish is this placeholder. The page is honest about what is missing rather than performative about what is not yet true.
Status model preview.
These are the labels the future status page will use. They describe what each label means — they are not assigned to any specific control here.
- Planned
- Defined in requirements but not implemented.
- In progress
- Implementation or evidence collection underway.
- Implemented
- Code exists but may still need operational or legal validation.
- Verified
- Tested or evidenced in a specific environment.
- Blocked
- Waiting on a decision, provider agreement, or missing dependency.
- Not applicable
- Outside the current product scope.
No control is mapped to any of these labels on this page. Assignments only appear when a row can be backed by an artifact, a test output, a signed agreement, or a named owner.
What will be tracked.
The categories below are the scope of the future status page. They are not status claims. They describe what will be tracked, not where any of it currently sits.
Access control
Server-side role enforcement, organization isolation, scoped membership, and the rules a UI cannot bypass.
Audit logging
Append-only event capture, actor and target identifiers, timestamps, and PHI-safe metadata.
PHI handling
Where protected health information is written, who can read it, how it is gated, and how it is redacted from logs.
AI safety
Feature flags, prompt minimization, output review, and the gates between AI features and patient data.
Document security
Storage isolation, quota enforcement, signed and time-limited download links, and read-only workspace behavior.
GDPR workflows
Right-to-export and right-to-erasure workflows, with verification artifacts for each.
Vendor agreements
BAA status with the hosting tier and any AI providers, DPAs, subprocessor inventory, and data-residency posture.
Operational policies
Security officer assignment, incident response, breach notification, access review, workforce training, and retention.
Evidence artifacts
Test outputs, audit export samples, deletion proofs, deployment checklists, and the change log for each release.
Contact before publication.
If you are evaluating MediFlow for a clinic, a pilot, a procurement review, or a security assessment, do not wait for the public status page. Email us. We will share current readiness information, provider agreement status, and implementation evidence in the context of your review.
The published status page will follow only when those answers can be repeated in writing, backed by artifacts, and held to the same evidence discipline used internally.
Continue the evidence trail.
These pages already document the direction this status page will eventually report against.