A clinic can sign a BAA with an AI interpreter vendor and still create avoidable PHI risk the first week it goes live.
The compliance question sits inside a broader problem: language barriers in healthcare can block access even when the underlying process is technically compliant.
A shared tablet may stay signed in at the front desk. Staff may use one account for the whole site. A transcript may land in a download folder. A patient call may move through a service the security team never reviewed.
HIPAA readiness depends on the full path of electronic protected health information, or ePHI, through the clinic. The useful question is not simply whether the AI vendor says it is HIPAA compliant. It is how the clinic, the vendor, the devices, and the connected systems handle PHI together.
TLDR:
- A BAA is one part of HIPAA readiness. Clinics still need their own risk analysis, access rules, device safeguards, and security procedures.
- Trace the PHI path before go-live: device, network, AI service, cloud services, EHR connection, stored output, and logs.
- Decide what should remain after each encounter. Audio, transcripts, notes, and audit records do not need identical retention settings.
- Shared tablets, phone calls, and telehealth deserve their own workflow checks because PHI can move through different systems in each one.
- Test the backup path before staff need it. Interpreter access should still work during an outage, lost device, or account problem.
Start with the PHI path, not the contract
The current HIPAA Security Rule requires covered entities and business associates to use administrative, physical, and technical safeguards for ePHI. HHS also requires a risk analysis of potential risks and vulnerabilities to ePHI.
For an AI interpreter, that analysis becomes much easier when the clinic draws the data path.
Ask what happens when a medical assistant starts an interpreted visit on a tablet:
- Does the device capture audio locally?
- Does audio leave the device?
- Is a transcript created?
- Where is the transcript stored?
- Does any output move into the EHR?
- Which vendor or subcontractor systems touch the data?
- What logs remain after the encounter?
Once the clinic can answer those questions, the security review becomes concrete.
1. confirm the BAA and the service boundary
HHS states that a cloud service provider that creates, receives, maintains, or transmits ePHI for a covered entity is a business associate, even if the cloud provider only holds encrypted ePHI and does not have the encryption key. See HHS cloud guidance.
For an AI medical interpreter, the clinic should know which company signs the BAA and which other services touch PHI behind the scenes.
Useful contract questions include:
- Which services and product features are covered by the BAA?
- Do any subcontractors create, receive, maintain, or transmit PHI?
- What uses of PHI are permitted under the agreement?
- What happens to clinic data when the contract ends?
- How and when is the clinic told about a security incident?
Your separate HIPAA BAA guide for interpreter vendors covers the contract question in more depth.
2. decide what data should remain after the encounter
An interpreted conversation can create several types of data: live audio, temporary speech data, a transcript, a clinical note, translated patient material, and system logs.
Do not treat them as one data type.
A clinic may need the clinical note in the EHR while having no care reason to keep raw encounter audio. A security log may need to remain available even when temporary speech data is gone.
Before launch, write down the desired state for each output:
- whether it is stored
- where it is stored
- who can see it
- how long the vendor keeps it
- how deletion works
- whether clinic staff can export or download it
HHS cloud guidance tells covered entities to understand the cloud service they use and notes that service agreements can cover data return, security responsibility, and use, retention, and disclosure limits. See the HHS guidance.
3. give each staff member the right level of access
A clinic with ten staff members should not need one shared interpreter login.
The HIPAA Security Rule calls for access controls, authentication, and policies that limit ePHI access based on the user's role. It also calls for audit controls that record and review activity in systems containing ePHI. See the HHS Security Rule summary.
In practice, clinics should check whether the interpreter service supports:
- individual user accounts
- role-based permissions
- strong authentication
- rapid account removal when staff leave
- admin access separated from routine clinical access
- logs that connect activity to a specific user
A shared tablet can still be used by many staff members. The account and access design should still make individual activity traceable when the clinic needs that level of review.
4. treat the shared tablet as part of the PHI workflow
HHS permits mobile-device access to ePHI when appropriate administrative, physical, and technical safeguards are in place. Its mobile-device guidance makes clear that mobile use itself is not prohibited.
For a shared clinic tablet, the bigger questions are mundane and easy to miss:
- Does the device lock itself after inactivity?
- Can a patient reach another patient's session by pressing Back?
- Does the browser keep session data after sign-out?
- Can staff save transcripts or files to local storage?
- Can the clinic remotely lock or wipe a lost device?
- Does the device show PHI in notifications on the lock screen?
These checks often matter more to day-to-day clinic use than a long security questionnaire.
5. check phone and telehealth flows separately
A clinic may use the same interpreter service in the exam room, on an outbound patient call, and during a video visit. The PHI path can differ each time.
For a patient call, ask whether the interpreter service receives the patient's phone number, name, language, or chart context. For telehealth, identify whether PHI passes through the video service as well as the interpreter service.
If another vendor receives PHI on the clinic's behalf, the clinic should know where that vendor sits in its HIPAA relationship and security review.
Do not assume approval for one workflow automatically covers every connected feature.
6. verify logging before an incident happens
A clinic should be able to answer basic questions after an unusual event: Who opened the session? When? From which account? Was information exported? Did an admin change a setting?
HIPAA audit controls call for mechanisms that record and review activity in systems that contain or use ePHI.
Before go-live, ask the vendor to show the actual admin view. Screenshots in a security packet are less useful than seeing what clinic staff can retrieve after a test encounter.
7. put the AI interpreter into the clinic's risk analysis
HHS describes risk analysis as a required part of the Security Rule and provides a Security Risk Assessment tool for small and medium-sized healthcare practices. See HHS risk-analysis guidance.
The clinic does not need a separate risk analysis for every button in the interpreter app. It does need to include the new system, the data it handles, the devices staff use, and the connections to other systems.
A useful review asks:
- What ePHI does this workflow create, receive, maintain, or transmit?
- What could expose or alter that information?
- What controls reduce those risks?
- Who owns each control: the clinic, the vendor, or both?
- How will the clinic check that those controls still work later?
As of September 2026, HHS still lists its 2024 HIPAA Security Rule cybersecurity update as a proposed rule. The current Security Rule remains in effect, so clinics should distinguish current requirements from proposed future changes.
8. plan for downtime and security events
Language access cannot disappear because a tablet was lost or an account was locked.
The clinic should have a backup interpreter path and staff should know when to use it.
The security plan should also say who contacts the vendor after a suspected incident, who can disable accounts, who preserves relevant logs, and how the clinic's privacy or security lead becomes involved.
A one-page runbook is usually more useful during an incident than a policy staff have never seen.
Where Opalite fits
Opalite supports real-time AI medical interpretation across 150+ languages and dialects on phones, tablets, computers, phone workflows, and telehealth.
For clinic deployments, Opalite can work under a BAA and supports healthcare security review, user access controls, and EHR-connected workflows. The right setup still depends on how the clinic plans to use the service and which data flows it turns on.
A strong implementation starts by mapping those flows with the clinic before go-live, then testing the actual device and user workflows staff will use.
For vendor-level HIPAA due diligence, see Is Your AI Medical Interpreter HIPAA Compliant?.
Clinic go-live checklist
- BAA signed for the services that will handle PHI
- PHI data path documented
- Subcontractor data flow understood
- Retention and deletion settings reviewed
- Unique users and roles configured
- Shared devices tested for lock, sign-out, and local storage
- Phone and telehealth flows reviewed separately
- Admin and encounter logs tested
- AI interpreter added to the clinic's HIPAA risk analysis
- Backup language-access path tested
- Security incident contacts documented
Learn more about Opalite's AI medical interpreter and multilingual clinical workflows.