How MediMic Safeguards Protected Health Information
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, every word is encrypted on the device before it leaves the microphone, transmitted as ciphertext, stored on our servers as ciphertext, and decrypted only on the participant devices. MediMic servers never hold the encryption keys. Even in a hypothetical scenario where our entire database were stolen, the transcript content would be unreadable.
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 sharing for two-device sessions
In two-device mode (provider device + patient device), the session key is shared exactly once via an invite URL fragment. URL fragments — the portion of a URL after the # symbol — are a well-established browser security primitive: they are processed exclusively on the client and are never transmitted to the web server in any HTTP request. They do not appear in server access logs, CDN logs, or proxy logs.
The invite URL format is:
https://portal.medimic.ai/join?token=INVITE_TOKEN#secret=BASE64_KEY
token(query string): a single-use invite code. This is safe to server-log — it has no value without the key.secret(fragment only): the 256-bit session key in base64. This never reaches any server.
The joining device stores the received key in its own Keychain/Keystore before the session begins.
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 password + TOTP two-factor authentication. Staff roles are granular (super_admin, platform_ops, support, finance, read_only) and every staff action is recorded in an immutable audit log.
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 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 |
Last reviewed: June 2026. For questions about MediMic's security posture or to request a copy of our Security Policy, contact [email protected].