Mira
Español

Call us directly

801-341-9304

Security & Compliance

Security and compliance, in one place.

Mira™'s security posture, BAA chain, HIPAA + 42 CFR 418.58 controls, integration patterns, audit trails — consolidated for IT and compliance teams.

01 — HIPAA + BAA chain

PHI never leaves the BAA chain.

HIPAA requires a Business Associate Agreement with every entity that creates, receives, maintains, or transmits PHI on behalf of a covered entity. Mira™ has executed BAAs with each AI provider in its stack — Anthropic, and OpenAI-compatible providers where used — before any PHI-adjacent data was processed through those providers. PHI does not flow to a provider that is not covered by an executed agreement. This is not a policy statement; it is enforced at the infrastructure level.

Per-provider BAA status — executed, pending review, or expired — is visible to administrators in the Mira™ admin panel without requiring a support request or a call with our team. Copies of executed agreements are available to customers under a mutual NDA. Prospective customers conducting vendor due diligence can request the current BAA inventory during the security review process.

The BAA chain extends to every layer of the stack where patient data could be present: compute, storage, AI inference, email delivery, and logging infrastructure. The Mira™ security questionnaire (available below) maps each third-party vendor to its BAA status and the data categories it handles.

For the full compliance module including PHI audit trails and breach notification workflows, see the Compliance module.

02 — 42 CFR 418.58 QAPI

All six QAPI elements tracked. Quarterly export ready for the survey binder.

42 CFR 418.58 requires hospice programs to maintain a Quality Assessment and Performance Improvement program that addresses six specific elements. A narrative description is not sufficient — surveyors review discrete documentation evidence for each element. Mira™ tracks all six:

  1. 1
    Organizational structure: Program charter and team composition recorded in Mira™; governing body sign-off events are logged with date and responsible party.
  2. 2
    Process: Clinical workflow documentation from the Mira™ clinical module feeds directly into the process element; no separate data entry required.
  3. 3
    Patient outcomes: Outcomes data is drawn from the patient record already in the system — discharge disposition, symptom burden, and goal attainment — with no manual compilation.
  4. 4
    Performance indicators: Configurable indicators tracked over rolling 90-day windows with threshold alerts; compliance teams set the targets, Mira™ tracks the actuals.
  5. 5
    Performance improvement projects: PI projects have defined start dates, goals, measurement criteria, and closure status; open projects are surfaced in the QAPI dashboard with time-to-resolution tracking.
  6. 6
    Governing body oversight: Meeting records and governing body sign-off events are stored and retrievable; the quarterly export includes a governing body summary section formatted for surveyor review.

The quarterly export compiles all six elements into a structured report formatted for the survey binder. The same data is available for CMS Conditions of Participation self-assessment. The export is generated on demand — no manual compilation, no spreadsheet assembly.

Full QAPI deep-dive including screenshot walk-through: Compliance module.

03 — SOC2 status

SOC2 Type II audit in progress. Target completion 2026 Q4.

Mira™'s SOC2 Type II audit is currently in progress. The Type II report is targeted for completion in 2026 Q4. The Type II audit covers the five Trust Service Criteria relevant to a healthcare SaaS platform: Security, Availability, Confidentiality, Processing Integrity, and Privacy. The audit is conducted by an accredited CPA firm under AICPA attestation standards — Mira™ does not self-certify SOC2 compliance.

A pre-audit security questionnaire is available on request. The questionnaire covers access controls, encryption at rest and in transit, incident response procedures, vendor management, change management, and the BAA chain. Procurement teams and security review boards may request it at any time without a signed NDA; the full control documentation requires a mutual NDA.

SOC2 Type II audit in progress — target 2026 Q4. Auditor name not yet public.
04 — Identity + SSO

SAML 2.0, OIDC, Azure AD, Okta, Google Workspace. Per-tenant identity provider config.

Mira™ supports SAML 2.0 and OIDC for enterprise SSO. The staff authentication path runs through MSAL B2C backed by Azure Active Directory; organizations may federate their own Azure AD, Okta, or Google Workspace tenant to that path without Mira™ involvement in the identity provider configuration. Each organization configures its own identity provider — Mira™ does not share identity configuration across tenants.

SAML 2.0
OIDC
MSAL B2C
Azure Active Directory
Okta
Google Workspace

Conditional Access policies, MFA enforcement, and session lifetime controls are delegated to the organization's identity provider — Mira™ does not override them. For organizations without an existing enterprise IdP, MSAL B2C with email + MFA is the default path.

Full integration catalog including EMR connectors and webhook config: Integrations module.

05 — Integration security

HMAC-SHA256 signed webhooks. OAuth 2.0 + PKCE for EMR. Scoped per integration.

Outbound webhooks from Mira™ are signed with HMAC-SHA256 and carry an X-Mira-Timestamp header. Receiving systems must verify the signature and reject any request where the timestamp falls outside a 300-second replay window. This prevents both payload tampering and replay attacks without requiring mutual TLS on the receiving endpoint.

EMR connections use OAuth 2.0 with PKCE. No long-lived credentials are stored on the Mira™ side; access tokens are short-lived and scoped to the minimum permissions required for the integration. Each integration carries a defined OAuth scope list — a billing integration does not carry clinical read scopes. Scope lists are visible to administrators in the integration configuration panel.

  • Webhooks signed HMAC-SHA256 with X-Mira-Timestamp; 300-second replay window enforced
  • EMR connections via OAuth 2.0 + PKCE; no long-lived credentials stored
  • Per-integration OAuth scope list; billing integrations do not carry clinical scopes
  • Scope lists visible to administrators in the integration config panel without a support request

Full integration catalog and connector documentation: Developers.

06 — Data residency

US-only by default. PHI does not leave US infrastructure without explicit consent.

All Mira™ production workloads run in AWS us-east-1 (primary) and us-west-2 (disaster recovery). No customer PHI is processed or stored outside these two regions under the default configuration. Mira™ does not currently operate on Azure or GCP; there is no silent cross-cloud data transfer in the default stack.

Multi-region configurations — including regions outside the United States — are available on Enterprise plans for organizations with specific residency requirements (cross-border care networks, international affiliates). Any configuration that would cause PHI to leave US infrastructure requires an explicit, BAA-extended consent addendum signed by the customer's compliance officer and Mira™'s data protection team before the configuration is enabled.

Default configuration

AWS us-east-1 (primary) + us-west-2 (DR). No other regions active.

Enterprise / multi-region

Available with explicit BAA-extended consent. Contact security team to discuss.

07 — PHI access audit trail

Every chart access logged. Queryable by user, patient, or date range.

Every access to a patient record by any authenticated user is logged: user identity (name and system ID), patient record accessed, action taken, timestamp (UTC), and originating IP address. This covers chart views, documentation entries, record exports, and administrative overrides — not only third-party disclosures as required under 45 CFR 164.528.

The audit log is immutable. Records cannot be modified or deleted through the application interface. Compliance officers query the log through the admin panel — filter by patient, by user, by date range, or by any combination. Exports are available in CSV format for surveyor requests, breach investigations, or legal discovery. The surveyor-ready export formats the log for direct inclusion in the survey binder.

  • Every chart access logged — not only disclosures — with user, timestamp, IP, and action
  • Immutable records: no modification or deletion through the application interface
  • Queryable by patient, user, date range, IP, or any combination; CSV export available
  • Surveyor-ready export format; no manual reformatting for the survey binder

Full audit trail documentation including query screenshots: Compliance module — audit trail.

08 — AI governance

BAA-gated. Default off per org. Audit-logged. Fail-closed.

Mira™ ships 7 AI features across clinical, billing, compliance, and family workflows. Every one of them operates under the same four governance rules:

BAA-gated

Every AI provider in the Mira™ stack has a signed Business Associate Agreement in place before any PHI-adjacent data is processed. PHI does not flow to any AI provider without an executed BAA. Provider BAA status is visible to admins in the dashboard.

Default off per org

Every organization starts with all AI features disabled at the infrastructure level — not just toggled off in the UI. An administrator must affirmatively enable each feature for their organization. The default-off state means a new organization cannot accidentally process PHI through an AI provider before the compliance team has reviewed the feature.

Audit-logged

Every AI call is logged with the feature invoked, prompt length, latency, org ID, patient ID (where applicable), and the opt-in status at the time of the call. The prompt body and model response are never stored in the audit log — only the metadata needed for compliance verification.

Fail-closed

If an AI provider is unavailable, the clinical or billing workflow continues without interruption using the non-AI path. No data is queued for retry against the AI provider. The feature degrades gracefully — the patient record, the claim, or the report is produced without the AI enhancement rather than blocking the workflow.

The admin dashboard shows the opt-in status of each AI feature per organization alongside the BAA status of each provider. Compliance teams can audit AI feature adoption across the organization without requiring a support ticket.

Full 7-feature AI catalog with clinical and billing use cases: AI module.

Security questionnaire

Pre-filled security questionnaire available.

Mira™'s pre-filled security questionnaire covers access controls, encryption at rest and in transit, incident response, vendor management (including the full BAA inventory), change management, and data residency. Formatted for standard procurement review processes.

Download our pre-filled security questionnaire (PDF) →

If the download isn't yet available, email security@usemirahealth.com and we'll send the latest version within one business day.

Ready to complete your security review?

We support NDA-gated reviews of BAA agreements, SOC2 controls, integration architecture, and the AI governance framework. Bring your security team or your external auditor — 30 minutes, no slides.