MediMic.Ai
Start Free
HIPAA Security Rule · 45 CFR Part 164

Built for HIPAA. Verified at every layer.

MediMic's encryption architecture ensures the content of every session stays private — even from us. Here is exactly how, in the detail your compliance team needs.

Execute your BAA Request security questionnaire
HIPAA Compliant AES-256 Encryption
End-to-end encryption

PHI is encrypted on the device, before it ever leaves the microphone.

Every session uses a unique 256-bit AES-GCM key generated on the host device. The key is stored only in the device's secure enclave and is never transmitted to MediMic. We store ciphertext — never the key.

1
Key generated on deviceCSPRNG · 256 bits of entropy
→
2
Key stored in secure enclaveiOS Keychain / Android Keystore
→
3
Content encrypted on deviceAES-256-GCM authenticated
→
4
Server stores ciphertext onlynonce · fingerprint · no key
→
5
Patient device decrypts locallykey shared via URL fragment

The URL-fragment trick (two-device mode)

The session key is shared exactly once, inside the part of the invite link after the #. URL fragments are processed only in the browser and are never sent to any server — they don't appear in access logs, CDN logs, or proxy logs.

https://portal.medimic.ai/join?token=INVITE#secret=BASE64_KEY

#secret never leaves the device · token is safe to log — useless without the key

Technical safeguards

HIPAA Security Rule, mapped to implementation.

Compliance officers: this table is built to be screenshotted into a vendor assessment.

SafeguardRequirementMediMic implementation
Access control§164.312(a)(1)Magic-link auth, JWT, RBAC, HttpOnly session cookies, hardware device identity
Audit controls§164.312(b)Immutable application + admin audit logs
Integrity§164.312(c)(1)AES-GCM authentication tag on every message
Person/entity authentication§164.312(d)Email magic link (no shared passwords), TOTP 2FA for staff
Transmission security§164.312(e)(1)TLS 1.2+ for all transport; AES-256-GCM E2E for PHI content
PHI encryption§164.312(e)(2)(ii)AES-256-GCM, keys in device Keychain/Keystore, never on server

Full detail in the Help Center: How MediMic safeguards PHI →

Infrastructure

Hosted on HIPAA-eligible infrastructure in the U.S.

  • Azure, United States (HIPAA-eligible regions)
  • AES-256 Transparent Data Encryption on all databases
  • TLS 1.3 in transit
  • Access logging on all infrastructure
  • No PHI in application logs
AES-256at rest (TDE)
TLS 1.3in transit
0 keyson server
6 yraudit retention
Two independent encryption layers protect every utterance
Business Associate Agreement

A signed BAA, without the legal back-and-forth.

MediMic enters into a BAA with every covered entity, defining our obligations under 45 CFR §164.504(e) — permitted uses, safeguarding, breach notification, and subcontractor requirements. On paid plans it's a click-through in your dashboard.

Execute your BAA in 2 clicks Download BAA summary (PDF)
Standard BAA45 CFR §164.504(e)
  • Included on every paid plan — no extra cost
  • Click-through acceptance in your dashboard
  • Covers breach notification & subcontractors
  • Enterprise: custom redlines on request
Security FAQ

Questions compliance teams ask.

No. Transcript content is encrypted with AES-256-GCM using a key that exists only on participant devices. Our servers store ciphertext and never hold the key. Even if our entire database were stolen, the content would be unreadable.
Keys live in the device's hardware-backed secure enclave (iOS Keychain / Android Keystore) and are not included in device backups. If a device is lost, the transcripts encrypted with keys held only on that device cannot be decrypted — by anyone, including MediMic. We recommend organizational device management policies per §164.310.
On HIPAA-eligible Azure infrastructure in the United States. Transcript content is stored only as ciphertext; metadata is protected with AES-256 Transparent Data Encryption at the database layer.
No. PHI content is never used to train models. Because session content is end-to-end encrypted and the key never reaches our servers, the content is not available to us for any secondary purpose.
Breach notification obligations and timelines are defined in the BAA we execute with your organization, consistent with the HIPAA Breach Notification Rule. Contact [email protected] for our full Security Policy.

Ready for a vendor assessment?

We provide a detailed security questionnaire response for procurement and compliance review.

Request security questionnaire For hospitals & health systems