How MediMic Safeguards Protected Health Information
This article explains the technical and administrative controls MediMic uses to comply with the HIPAA Security Rule (45 CFR Part 164). It is intended for healthcare organizations evaluating MediMic, privacy officers, and IT/security teams conducting vendor assessments.
Plain-English Summary
When a provider and patient speak through MediMic, audio is streamed in real time to our speech-to-text and translation vendor to produce a transcript — that vendor necessarily processes the actual words in order to transcribe and translate them. Once the transcript is produced, it is encrypted on the device before being sent for storage, stored on our servers as ciphertext, and decrypted only on participant devices. MediMic's own servers never hold the encryption keys and never store a readable copy of the transcript. Even in a hypothetical scenario where our database were stolen, the stored transcript records would be unreadable without a device-held key.
1. End-to-End Encryption of Transcript Content
How it works
Every session uses a unique 256-bit AES-GCM (Advanced Encryption Standard in Galois/Counter Mode) key. AES-256-GCM is authenticated encryption — it simultaneously encrypts the content and produces an authentication tag that detects any tampering, satisfying both the confidentiality and integrity requirements of HIPAA §164.312(e)(2)(ii) and §164.312(c)(1).
Key generation
The session key is generated by the host device using the operating system's cryptographically secure random number generator (System.Security.Cryptography.RandomNumberGenerator). No deterministic or predictable value — such as a session ID or timestamp — is used. The key material is 32 bytes (256 bits) of pure entropy.
Key storage
Session keys are stored exclusively in the device's secure hardware enclave:
| Platform | Key storage mechanism |
|---|---|
| iOS | iOS Keychain (hardware-backed on devices with Secure Enclave) |
| Android | Android Keystore System (hardware-backed on Android 6+ with TEE/StrongBox) |
Keys are never written to disk outside these protected stores, never included in device backups, and never transmitted to MediMic servers.
Key agreement for two-device sessions
In two-device mode (provider device + patient device), the session key is never transmitted. The two devices derive it independently using ephemeral Elliptic-Curve Diffie-Hellman.
- Each device generates an ephemeral ECDH key pair (NIST P-256) scoped to that session.
- The devices exchange SubjectPublicKeyInfo-encoded public keys over the session channel.
- Each side performs the ECDH agreement with its own private key and the peer's public key, producing an identical raw shared secret.
- That secret is passed through HKDF-SHA256 — salt
medimic-session-{sessionId}, infosession-encryption-key-v1— to derive the 256-bit AES-GCM session key. - The derived key is written to the device's Keychain/Keystore. Private keys never leave the device that generated them.
The invite URL format is:
https://api.medimic.ai/join?token=INVITE_TOKEN
token(query string): the invite code, used to authenticate the join. It is safe to server-log — it does not yield the session key.
Because only public keys traverse the network, an adversary with full visibility of the relay — including MediMic's own infrastructure — cannot compute the shared secret and therefore cannot decrypt session content.
Bootstrap key — a known limitation. Before the ECDH exchange completes, both devices seed a provisional key derived as
SHA-256(invite token). Because the invite token is presented to the server to authenticate the join, this provisional key is derivable by the server and does not carry the same guarantee as the ECDH-derived key. It exists only to bootstrap the handshake; the ECDH key replaces it for session content. Organizations conducting their own risk analysis should treat any pre-handshake material as server-visible.
Superseded design. Earlier releases transmitted the key in the invite URL fragment (
#secret=…), relying on browsers not sending fragments to servers. That mechanism has been replaced by the ECDH agreement above. The client retains parsing for fragment-style links solely for backward compatibility with invites issued before the change.
What the server stores
For every utterance, the server stores only:
ciphertext | nonce (12 bytes, random per message) | key fingerprint | algorithm = "AES-256-GCM"
The key fingerprint is a hash of the key's hash — it allows participants to verify they share the same key, but reveals nothing about the key itself. The ciphertext is meaningless without the key, which the server does not have.
For single-device (shared) sessions
No key exchange is required. The host device generates a key on first use, encrypts all utterances, and is the only device that ever holds the key. Transcripts stored on the server remain encrypted.
2. Transmission Security
All communication between devices and MediMic servers uses TLS 1.2 or higher (HTTPS). TLS provides an encrypted transport layer that protects data in transit from network interception. Combined with E2E encryption, there are two independent encryption layers for transcript content:
- TLS — protects the payload from network attackers (terminated at our edge)
- AES-256-GCM — protects PHI content from MediMic itself and any infrastructure-level compromise (end-to-end, server never decrypts)
3. Access Controls (§164.312(a)(1))
Provider authentication
Portal users (healthcare providers) authenticate via magic link email — a single-use, time-limited token sent to their registered email address. There are no passwords to compromise. Upon authentication, a short-lived JWT (JSON Web Token) is issued for API access.
For providers who choose "Remember me," a long-lived session token is stored in an HttpOnly, Secure, SameSite=Strict browser cookie — a configuration that prevents JavaScript from reading the token and blocks cross-site request attacks. A fresh short-lived access token is issued on each page load from this cookie.
Role-based access control
Providers are assigned roles within their organization (Owner, Admin, Member, Billing). API endpoints enforce these roles on every request.
Staff (MediMic internal) authentication
MediMic staff access the Admin Console via a passwordless one-time email code, scoped by granular role (super_admin, platform_ops, support, finance, read_only), and every staff action is recorded in an append-only audit log. Multi-factor authentication for staff accounts is planned but not yet implemented — see our Security Policy for current status.
Guest (patient) device identity
Patient devices that use MediMic without a portal account are issued a stable hardware-bound device identity:
- Android:
AndroidId— a value derived from the device's hardware, scoped to the app's signing certificate. The same value survives app uninstalls. - iOS: A UUID stored in the iOS Keychain — survives app reinstalls.
This prevents circumvention of the guest trial limit by reinstalling the app, and enables session history recovery after reinstall without storing PHI on the server.
4. Audit Controls (§164.312(b))
MediMic maintains two audit layers:
Application audit log — every API call that creates, reads, or modifies data produces a timestamped log entry including the actor identity, action type, and affected resource. Transcript content is never included in logs.
Admin audit log — every administrative action performed by MediMic staff (plan changes, user suspension, impersonation, feature flag changes, organization modifications) is written to an append-only AdminAuditLog table with the staff actor's identity and a before/after JSON snapshot. This log supports HIPAA's requirement for activity review (§164.308(a)(1)(ii)(D)).
5. PHI Minimization in the Admin Console
MediMic's internal Admin Console, used by staff, displays only session metadata:
- Session ID, status, timestamp, duration, mode
- Participant count
- Organization name (if applicable)
Transcript content is never displayed, accessible, or queryable from the Admin Console. A prominent policy banner is shown on every session-related screen. Accessing actual transcript content requires a separate, logged, scoped PHI-access grant — a process that would be documented and auditable.
6. Data Integrity
AES-GCM's authentication tag provides cryptographic integrity verification on every message. A message that has been tampered with in transit or in storage will fail authentication and be rejected by the receiving device. This satisfies §164.312(c)(1) (integrity controls) and §164.312(e)(2)(ii) (encryption and decryption).
7. Business Associate Agreement (BAA)
MediMic enters into a Business Associate Agreement with every covered entity (healthcare organization) that uses the platform. BAA execution is tracked per organization. The BAA defines MediMic's obligations as a Business Associate under 45 CFR §164.504(e), including:
- Permitted uses and disclosures of PHI
- Safeguarding obligations
- Breach notification procedures
- Subcontractor requirements
Contact your MediMic account representative to execute a BAA before deploying MediMic in a production clinical environment.
8. What Is Outside MediMic's Direct Control
HIPAA compliance is a shared responsibility. The following areas are the responsibility of the deploying organization and/or infrastructure provider:
Encryption at rest — database level
MediMic stores transcript content only as AES-256-GCM ciphertext. Organizational metadata (provider names, email addresses, organization names, timestamps) is stored in plaintext in the database. We strongly recommend enabling Transparent Data Encryption (TDE) on the SQL Server instance hosting MediMic to protect this metadata layer.
Infrastructure HIPAA compliance
The server infrastructure hosting MediMic (compute, database, storage, networking) must itself be hosted on a HIPAA-eligible infrastructure provider (e.g., Azure, AWS, or GCP with a signed BAA). MediMic's application-layer controls do not substitute for infrastructure-level compliance.
Data retention and deletion
Organizations are responsible for establishing and enforcing data retention policies consistent with applicable state and federal requirements. MediMic supports data deletion requests; please contact support for assistance with PHI deletion workflows.
Physical safeguards
Physical access controls for devices used to access MediMic (workstations, mobile devices) are the responsibility of the covered entity per §164.310.
Workforce training
HIPAA workforce training requirements (§164.308(a)(5)) are the responsibility of the covered entity.
9. Summary of HIPAA Technical Safeguards Coverage
| Safeguard | Requirement | MediMic Implementation |
|---|---|---|
| Access control | §164.312(a)(1) | Magic-link/one-time-code auth, JWT, role-based access, HttpOnly session cookies |
| Audit controls | §164.312(b) | Append-only 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 / one-time code (no shared passwords); MFA planned, not yet implemented |
| Transmission security | §164.312(e)(1) | TLS for all transport; AES-256-GCM end-to-end encryption for stored transcript content |
| PHI encryption | §164.312(e)(2)(ii) | AES-256-GCM, keys in device Keychain/Keystore, never on server |
Last reviewed: June 2026. For questions about MediMic's security posture or to request a copy of our Security Policy, contact [email protected].