Healthcare cloud selection guide: how do you choose a cloud for PHI workloads?
AWS, Microsoft Azure and Google Cloud all offer a business associate agreement, so the BAA alone does not decide the choice. What decides it is whether the specific services your workload needs are covered, which managed healthcare data services exist, where data can live and be recovered, what your team already runs and how hard it is to leave.
How do you compare clouds for a PHI workload?
Quick answer
A healthcare cloud selection should test each workload against the provider's own documents: which services the BAA covers, which managed FHIR, DICOM and HL7 v2 services exist, where PHI can be stored and recovered, and how data leaves. Agnotic Technologies runs this check per workload and tests the shortlist in a proof of concept.
| Criterion | Managed health data services | General cloud services |
|---|---|---|
| BAA coverage | Confirm each managed FHIR, DICOM or HL7 v2 service is named in the provider's current HIPAA documentation | Confirm every compute, storage, queue, logging and backup service in the design is covered |
| Healthcare data formats | Check the FHIR version, supported profiles and operations, DICOMweb support and HL7 v2 ingestion | You choose and run the FHIR server, archive or engine, and own its upgrades |
| Identity in use | Does the service work with the identity provider and SMART on FHIR scopes you plan to use? | Same question for your services; reuse the directory the organization already runs |
| Region and residency | Is the managed service offered and covered in each region where PHI must stay? | General services exist in more regions; confirm coverage for each one |
| Backup and recovery | What backup, export and cross-region options does the service offer, and can you test a restore? | You design backups, replication and restore tests yourself |
| AI inside the BAA boundary | Is the model or AI service you plan to use covered, in your region? | If you self-host models, are the instance types you need available in that region? |
| Team skills | Less to operate; learn each service's quotas and limits | More to operate; the team must patch, scale and monitor it |
| Exit and portability | Test a bulk export of FHIR resources, DICOM instances and stored messages | Data is in formats you control; test a restore on another platform anyway |
What they are
What is Managed health data services
Managed healthcare data services are provider-run FHIR, DICOM and HL7 v2 stores and APIs. The provider operates the servers, scaling and patching, and you configure them. They shorten the build but tie part of the design to that provider's service limits and features.
What is General cloud services
General cloud services are compute, containers, databases, queues and storage on which you run your own FHIR server, DICOM archive or interface engine. Every provider offers them, so the design moves more easily between clouds, but your team runs more of the stack.
Key differences
Does a signed BAA cover every service?
Read each provider's own scope statement. AWS publishes a list of HIPAA eligible services that may create, receive, process, maintain or transmit ePHI, and notes that customers still must configure them consistent with HIPAA. Microsoft offers its HIPAA BAA through the Microsoft Product Terms for in-scope Azure services. Google states that its Cloud BAA covers its entire infrastructure, in all regions, together with a list of supported products. In each case, a service outside the scope cannot carry PHI.
How do you check BAA scope per workload?
Start from the architecture diagram, not the product brochure. List every service a request touches: load balancer, compute, database, object storage, queue, logging, monitoring, backup, analytics, AI and support tooling. Match each one against the provider's current HIPAA documentation, record the date you checked, and repeat the check when the design or the list changes. Provider lists are updated often.
How do an EHR, an RPM pipeline and an analytics platform weigh the criteria?
A cloud EHR weighs identity, managed FHIR support, backup and recovery, and region coverage most, because clinicians depend on it all day. A remote monitoring pipeline weighs device ingestion, queues, alerting and HL7 v2 or FHIR delivery to the EHR. An analytics platform weighs warehouse and AI services inside the BAA, de-identification and data export. Run the criteria table once per workload; the answers can differ inside one company.
What do residency and recovery require?
The HIPAA Security Rule requires a contingency plan with a data backup plan, a disaster recovery plan and an emergency mode operation plan for systems that hold ePHI (45 CFR 164.308(a)(7)). In the cloud that means knowing which regions can hold the data, where backups go, whether a second region is covered for every service you fail over to, and how long a restore takes in practice.
Does the identity platform you already run matter?
Often more than any feature. A health system that runs one directory for staff, or a product team that already operates on one cloud, carries skills, policies and security tooling with it. Changing platforms adds work that has nothing to do with the healthcare workload. Count that work honestly in the comparison.
How do you keep a way out?
Prefer standard formats at the boundaries: FHIR R4 resources, DICOM instances, HL7 v2 message archives and open database formats. Before you commit, export a real data set from the managed service and load it somewhere else. For FHIR stores specifically, our FHIR data stores comparison covers portability in more depth.
When to use each
When to use Managed healthcare data services
- You need a FHIR API or DICOMweb endpoint quickly and do not want to run the server.
- Your team is small and would rather configure services than operate them.
- The managed service is covered by the BAA in the region your data must stay in.
- You accept some provider-specific features in return for less operations work.
When to use General services you configure
- You already run a FHIR server, PACS or interface engine and want to keep it.
- You need the same architecture on more than one cloud or on premises.
- A managed service is not offered or not covered in a region you need.
- Your team has the skills to patch, scale and monitor the healthcare components.
What should a healthcare cloud proof of concept test?
1. BAA scope on the real diagram. Every service in the proof of concept is on the provider's current HIPAA documentation for the region used.
2. A representative data load. Load de-identified or synthetic data at realistic volume into the FHIR, DICOM or HL7 v2 service you would use.
3. Your identity flow. Sign in with your identity provider and exercise the scopes or roles your app will need.
4. A FHIR or DICOM round trip. Write, search and read the resources or studies your product actually uses, including paging and error responses.
5. Backup and restore. Restore a backup into a clean environment and time it.
6. Region failover. Fail one component over to a second region and confirm every service there is covered.
7. Logging and audit. Confirm access to data is logged where your security team can search it.
8. Export and exit. Bulk export the data set and load it into another platform.
9. Operations load. Record what your team had to configure, patch or monitor, because that work continues after launch.