HIPAA and AI: How Mira™ Handles Protected Health Information

When we built Mira™‘s AI features, we made a decision early: treat every potential PHI exposure as a hard engineering constraint, not a policy document commitment. The difference between those two approaches is measurable in breach incident reports.

This post is the technical and compliance answer to the question your IT director, compliance officer, or legal team will ask before signing off on an AI-enabled billing platform: exactly what happens to protected health information when your AI features run?

Why Mira™‘s Approach Is Different

Most healthcare AI products start with a language model and then figure out the compliance requirements afterward. We started with the compliance requirements and then built the AI layer within those constraints.

The core architecture has four properties:

BAA-gated. No AI feature that touches patient data runs against any external AI provider unless a Business Associate Agreement is in place between Mira™ and that provider. This is not an option you configure — it is a hard gate in the system. If a BAA is not present for a given provider, requests to that provider fail closed. We do not fall back to an unbounded API call.

Per-organization opt-in, default off. Every AI feature is disabled for every new Mira™ organization account by default. An organization’s administrator must explicitly enable each feature through the Mira™ admin settings panel. There is no scenario in which a feature that touches patient data activates without an administrator making a deliberate choice.

Audit-logged, length-only. Every AI feature call is logged in Mira™‘s immutable audit trail. The log entry records: the feature that ran, the timestamp, the organization ID, the user ID, and the prompt length in characters. The log does not record the prompt content. This design means your compliance team has a complete record of AI usage patterns without the log itself becoming a PHI exposure surface.

Fail-closed. If an AI provider is unreachable or returns an error, the feature fails with an error message to the user. It does not retry with a less-constrained provider, degrade to unlogged logging, or silently skip the audit record. The safe state for any unexpected condition is off.

What We Send — and What We Don’t

The most important compliance question is: what data leaves Mira™ and goes to an external AI provider?

The answer depends on the feature and which providers are configured for your organization. Here is the general principle: Mira™ sends the minimum data required to generate a useful response, preprocessed to remove anything not necessary for the query.

For the IDG brief generator, that means structured clinical summary data — diagnosis codes, current care plan elements, recent vital trend summaries — not full free-text clinical notes. For the denial prediction feature, that means the claim data and relevant billing history — no patient demographics beyond what is encoded in the claim itself.

For features that do process free-text clinical documentation (the admission documentation assistant and the visit note summarizer), that text is sent to the AI provider. This is by design — summarizing a clinical note requires reading the clinical note. This is also why those features are BAA-gated and require explicit organization opt-in. You are making a deliberate, audited, administrator-authorized decision to send that data to an external processor operating under a BAA.

What we never send, under any configuration: direct patient identifiers (name, SSN, MRN) beyond what is standard in a properly de-identified clinical data structure. The preprocessing layer strips identifiers before any prompt is assembled.

The Seven AI Features and Their Providers

Mira™‘s first release ships with seven AI features. Here is how each maps to the BAA and opt-in requirements:

Feature	Data category	BAA required	Admin opt-in required
IDG Brief Generator	Structured clinical summary	Yes	Yes
Admission Documentation Assistant	Free-text clinical notes	Yes	Yes
Denial Prediction	Claim data, billing history	Yes	Yes
AI-Assisted Appeal Drafting	Denial details, claim context	Yes	Yes
Billing Code Suggestions	Diagnosis codes, procedure context	Yes	Yes
Visit Note Summarizer	Free-text clinical notes	Yes	Yes
Bilingual Family Chatbot	Patient record (documented elements only)	Yes	Yes

All seven require a BAA. All seven require administrator opt-in. None activate automatically.

The specific AI providers available for each feature are documented in your Mira™ admin settings panel under AI Configuration. Mira™ supports Anthropic and OpenAI-compatible endpoints as external providers, plus a null (no-op) provider that lets your team test AI feature flows in staging environments without sending any data externally.

The Admin Opt-In Walkthrough

Enabling an AI feature in Mira™ takes a deliberate administrator action. Here is the sequence:

1. Log in as an organization administrator at usemirahealth.com/admin.
2. Navigate to Settings → AI Features.
3. Each of the seven features appears with its current status (disabled by default) and a description of the data it processes.
4. To enable a feature, click the toggle. A confirmation dialog displays the data category, the BAA requirement, and the audit logging behavior. Click Confirm to enable.
5. The change is recorded in the organization audit log with the administrator’s user ID and timestamp.

Features can be disabled at any time using the same toggle. Disabling a feature is immediate — in-flight requests complete, but no new requests are processed.

Satisfying Due Diligence

If your organization requires a formal review before enabling AI features, Mira™ can provide:

• The current Business Associate Agreement templates for each configured AI provider
• The data flow diagrams for each AI feature
• A sample audit log export demonstrating the length-only logging format
• The security architecture documentation covering encryption at rest and in transit

Request these through your Mira™ account manager or via usemirahealth.com/contact.

The goal of this architecture is not to make compliance review disappear — it is to make the answers to every compliance question specific, verifiable, and documented. If your legal team or compliance officer has questions that this post does not address, we want those questions.

---

Further reading: Privacy policy · Platform overview · Contact for due diligence requests