Who is responsible for user accounts in your practice's cloud software?

For cloud software that handles patient information, such as online scheduling, patient intake forms or a telehealth platform, the vendor is responsible for securing its service. Your practice decides who gets a login and removes it when they leave. Where exactly the line falls depends on the service and the contract. HHS’s guidance on cloud computing says to sign a business associate agreement (BAA) with the vendor and to confirm in writing how each side meets the Security Rule.

When your cloud vendor is a business associate

HHS’s Guidance on HIPAA & Cloud Computing says that a cloud vendor that creates, receives, keeps or sends electronic patient information on your behalf is a business associate. That is true even if the vendor stores only encrypted data and has no key to read it. You and the vendor must sign a BAA, and using the service for patient data without one violates the HIPAA Rules.

This reaches beyond the EHR. HHS’s business associate examples include an AI chatbot on a patient portal that books appointments. Another is an app developer that, under contract with a practice, provides a health app to its patients and handles their information for the practice. For telehealth, HHS’s telehealth site says covered providers must use vendors that comply with HIPAA and will sign a BAA. A scheduling or intake tool that keeps patients’ names and symptoms on your behalf falls under the same rule.

How HHS describes the split

The clearest statement of the split is in HHS’s discussion of vendors that hold only encrypted data they can’t read. Where only the customer controls who can view the data, HHS says, access controls such as authentication and unique user IDs may be the customer’s job. Others, such as encryption, may be the vendor’s. Which side does what depends on each party’s risk management plan and on the BAA. HHS then says the vendor and the customer should each confirm in writing, in the BAA or other documents, how they will meet the Security Rule.

HHS also says what happens when one side doesn’t do its part. If the contract says the customer will set up certain security features and the customer doesn’t, OCR (HHS’s enforcement office) treats that as relevant in an investigation. A vendor isn’t responsible for failures caused only by the customer.

A scheduling or intake service that can read the data it holds doesn’t fit that example exactly. The principle still helps: decide which side handles each control, and write it down.

Adding and removing users is your practice’s job

When someone at your practice adds users in a tool’s admin settings, they are carrying out your own Security Rule duties. Each user needs a unique name or number so the system can track who did what (45 CFR 164.312(a)(2)(i), “Required”). Your access authorization and modification procedures (164.308(a)(4)(ii)(B) and (C)) decide who gets which rights. Your termination procedures (164.308(a)(3)(ii)(C)) cover removing access when someone leaves. Those last three are “Addressable”: you put them in place if reasonable, or document why not and use an equivalent measure (164.306(d)(3)).

The vendor can’t know who has left your practice unless you tell it. HHS’s 405(d) guide for small healthcare organizations says to remove a departing employee’s or contractor’s access immediately. It calls this especially important for cloud systems, where access depends on a login rather than on being at a particular computer.

A shared login hides people from the vendor’s record. If the front desk uses one scheduling login, the vendor’s log shows that login and not the person. For shared EHR logins in particular, see Can staff share an EHR login?.

What the agreement should cover

The BAA has required content. Under 45 CFR 164.314(a)(2)(i), the vendor must comply with the Security Rule, bind its subcontractors to it, and report security incidents to you. Under 164.504(e)(2)(ii)(J), it returns or destroys patient data at the end of the contract where feasible. HHS adds that the BAA can set the detail, frequency and format of incident reports.

HHS notes that a service level agreement (SLA) often sits beside the BAA. It lists topics an SLA can address:

• system availability and reliability
• backup and data recovery
• how your data comes back to you when you stop using the service
• who is responsible for which security tasks
• limits on how the vendor uses, keeps and discloses data

The SLA should match the BAA, and neither should stop you from reaching your own data. HIPAA doesn’t require the vendor to hand over security documents or allow audits. HHS says you may still ask for them in the BAA or SLA, based on your own risk analysis.

Questions to ask before you sign

These questions cover the account side of the split. The 405(d) guide’s steps for choosing an IT managed service provider include a written request for information that asks about the vendor’s security program. The same approach works for a cloud vendor.

If the vendor offers only a standard click-through agreement, compare its terms and documents against these questions before you rely on it.