Security
MedFlow is built for regulated healthcare integrations. Patient data is encrypted in transit and at rest, access is tenant-scoped and least-privilege, and every sensitive operation is audited and traceable to the API key that performed it.
MedFlow secures the platform as described below. Your organization remains responsible for its own BAAs, workforce training, and how you handle PHI in your own systems.
Compliance
Section titled “Compliance”- SOC 2: MedFlow has completed a SOC 2 Type 1 examination, and a Type 2 examination is underway with the report expected later in 2026.
- HIPAA: MedFlow operates as a business associate under a signed BAA, and signs a BAA with every subprocessor that handles PHI.
- Control framework: MedFlow designs its controls against the NIST SP 800-53 Moderate control families. This is an internal reference, not a certification claim.
Request current reports through the contact form.
Encryption
Section titled “Encryption”Data is protected in transit and at rest, and secrets are kept out of the artifacts the engine generates.
- At rest: all tenant data lives only in the production environment, encrypted with AES-256.
- In transit: every connection uses TLS 1.2 or higher, encrypted and authenticated with AES-128-GCM over an ECDHE-RSA key exchange, with HSTS enforced. Qualys SSL Labs rates the configuration “A”.
- Secrets: API key secrets are stored hashed and resolved at runtime in least-privilege contexts, never embedded in generated automation artifacts (see Architecture).
Data residency and retention
Section titled “Data residency and retention”- Residency: tenant data is stored in the United States and does not leave it, except when a call you initiate requires it, such as an outbound request to your own endpoint.
- Backups: MedFlow takes multiple backups per day and retains them for 7 days.
- Audit log retention: audit events are retained securely for at least 7 years.
- Deletion: you can request export and deletion of tenant data through the contact form, subject to legal and contractual retention obligations.
Access control
Section titled “Access control”Access is scoped tightly and defended in depth.
| Control | Behavior |
|---|---|
| Tenant isolation | Every key is bound to a single tenant and workspace, and requests never cross tenant boundaries in either storage or execution. |
| API key secret | Shown once at creation, and stored only as a hash. |
| Scopes | Optional least-privilege scopes on each key (see Authentication). |
| Rate limits and quotas | Per-key and per-tenant ceilings (see Rate limits and quotas). |
| IP allowlist | Optional per-key allowlist of source networks. |
Identity and authentication
Section titled “Identity and authentication”Authentication runs through Auth0, so MedFlow never stores a password of its own.
- Single sign-on: MedFlow supports SSO through Auth0, including OIDC, OAuth 2.0, and SAML 2.0.
- Passwords: MedFlow never stores passwords. Auth0 handles authentication and password hashing.
- MFA: multi-factor authentication is required for everyone with logical access, and on every third-party service that touches the environment.
- Account verification: users without SSO confirm their account through an emailed verification link.
Infrastructure
Section titled “Infrastructure”MedFlow runs on Google Cloud, using its HIPAA-covered services.
- Network: firewall rules, threat detection, and network segmentation are managed with cloud-native tooling, and virtual machine clusters are patched on a routine schedule.
- Payments: MedFlow does not store card data. Payments are processed by Stripe, which is PCI compliant.
Monitoring and logging
Section titled “Monitoring and logging”MedFlow captures logs, events, and metrics through its own logging service alongside Google Cloud logging. Every action in the system is logged, and reads of sensitive information are flagged as auditable events that can be reconstructed later.
Audit events
Section titled “Audit events”MedFlow records an audit event for:
- Creating, updating, or deleting diagrams, triggers, and queries
- Creating, starting, canceling, pausing, or resuming runs
- Executing search (PHI-bearing reads)
Each event includes at least:
| Field | Purpose |
|---|---|
timestamp | When the action occurred (UTC) |
requestId | Matches X-Request-Id on the HTTP call |
keyId | Stable id of the API key |
keyName | Human label of the key |
tenantId / workspaceId | Tenancy context |
method / path | HTTP method and path |
action | Normalized action (for example run.create, diagram.create) |
resourceType / resourceId | Target resource when applicable |
result | Success or failure |
clientIp / userAgent | Caller metadata |
By default, audit logs capture identifiers and metadata rather than secrets or raw PHI payloads.
Tracing a call
Section titled “Tracing a call”- Capture
X-Request-Idfrom the response, or send your own on the request. - Note the
keyIdand key name that MedFlow issued alongside the API key. - Send the timestamp window, path, and
requestIdthrough the contact form so we can investigate.
PHI handling
Section titled “PHI handling”- MedFlow stores only the clinical data needed to find cohorts and run pathways, scoped to the tenant that owns it.
- Audit logs record identifiers and metadata, not raw clinical payloads or secrets.
- In your own systems, log resource ids rather than full clinical payloads, never log API key secrets, and keep staging keys to staging data so production keys never run in a non-production environment.
Vulnerability management
Section titled “Vulnerability management”An independent third party performs penetration tests periodically, and HostedScan scans for vulnerabilities continuously. To report a suspected vulnerability, email security@medflow.care. Please do not test against production tenants or other tenants’ data.
Incident and status
Section titled “Incident and status”- Report security and confidentiality incidents to security@medflow.care, and we handle them under our established incident policy.
- Service disruptions and maintenance windows are posted on the status page, which you can subscribe to.
Resilience and change management
Section titled “Resilience and change management”- Disaster recovery and business continuity: plans are documented and exercised routinely to protect uptime and availability.
- Change management: releases follow a formal software development lifecycle and Semantic Versioning. See the Release notes for release history.
- Risk management: we run risk assessments monthly.
Personnel
Section titled “Personnel”- Access follows least privilege, with regular reviews and prompt removal when it is no longer needed.
- Privileged access goes through Google Cloud Shell secured with Cloud IAM.
- Personnel devices are inventoried and secured with antivirus, device controls, and patching.
- Everyone undergoes background checks, signs a confidentiality agreement, and completes annual Security Awareness and HIPAA training.
Subprocessors
Section titled “Subprocessors”MedFlow reviews vendors for security and compliance and signs a BAA with any that handle PHI.
| Vendor | Activity | Location |
|---|---|---|
| Google Cloud | Cloud infrastructure | United States |
| Amazon Web Services | Cloud infrastructure | United States |
| Stripe | Payment processing | United States |
| Auth0 | Authentication | United States |
| Kno2 | Healthcare messaging | United States |
| Faxage | Cloud fax | United States |