About this checklist
AI interpretation moves some of the most sensitive content in healthcare: the live clinical conversation itself. A product in this category should be evaluated as clinical software that processes protected health information, not as a consumer translation app that happens to be used in a clinic.
This checklist is written for the security, compliance, and procurement teams doing that evaluation. The questions are vendor-neutral: they apply to any AI interpretation product, including Efatha.
Start with the data: in motion and at rest
Conversation audio and transcripts are the core asset. Before anything else, establish where they travel, where they rest, and how they are protected in both states.
- Confirm transport encryption of TLS 1.2 or higher for all conversation data in transit.
- Ask how transcripts are encrypted at rest (AES-256 is a reasonable expectation) and whether sensitive fields are encrypted above the database layer.
- Ask exactly what is stored: audio, transcripts, translations, metadata. A vendor that stores less has less to protect.
- Ask whether conversation data is used to train models, and whether the vendor has zero-retention arrangements with its AI model providers.
The device in the room
In-room interpretation runs on the phones and tablets clinicians already carry, often shared and sometimes lost. The device is the most exposed part of the system, so what the app leaves on it matters more than any other single control.
- Patient conversations should never be stored on the device.
- Device credentials should be short-lived and narrowly scoped, with no long-lived service keys sitting in local storage.
- Ask what an attacker with a lost or stolen device could actually access, and for how long.
- Ask how the app behaves on shared devices: session expiry, sign-out, and account switching.
Access, identity, and accountability
Transcripts of clinical conversations deserve the same access discipline as the chart. The question is not just who can sign in, but who can see which encounter, and whether anyone can answer that after the fact.
- Role-based access control scoped by both role and facility, so access follows responsibility.
- Sign-in through trusted identity providers, with multi-factor authentication available for your organization.
- Audit visibility: who accessed which session or transcript, and when.
- Separation between administrative roles and clinical roles.
Deletion and the data lifecycle
Retention is a decision, not a default. A trustworthy vendor can tell you precisely what happens to a discarded session, a deleted account, and everything in between.
- Discarded sessions and entire accounts should be permanently deletable, not soft-hidden.
- Ask how retention periods are configured and who controls them.
- Ask for the subprocessor list: every service the conversation data touches, including AI model providers.
- Ask how deletion propagates to backups and subprocessors.
The paperwork that matters
There is no such thing as a government HIPAA certification: HHS does not certify products. Treat any "HIPAA certified" claim as a reason to look closer. What a vendor can legitimately offer is careful language, such as "designed to support HIPAA-compliant workflows," backed by documents specific enough for your compliance review.
- A Business Associate Agreement, available before PHI flows.
- A current subprocessor list and notice process for changes.
- Breach notification commitments with defined timelines.
- Security documentation concrete enough to answer this checklist in writing.
Language access is also a compliance surface
Language access is not only a quality goal; it is an obligation under requirements such as Title VI of the Civil Rights Act and Section 1557 of the Affordable Care Act. Interpretation technology can support an organization's language-access program, but no tool guarantees compliance on its own. The program, its policies, and its documentation remain the organization's responsibility.
How to use this checklist
Ask every vendor, including Efatha, for specifics in writing rather than assurances. A serious product in this category should be able to answer each item concretely: what is encrypted and how, what lives on the device, who can access what, what gets deleted and when, and which documents back it all up.
Security review is ultimately about the combination of product, configuration, and your own policies. The checklist gets you to the right questions; your organization's evaluation gets you to the right answer.