Healthcare Cloud Data Residency: HIPAA Plus State Law Matrix

When healthcare organisations move workloads to the cloud, HIPAA is the compliance framework that gets the most attention. Business Associate Agreements are negotiated, encryption standards are specified, and access logging is configured. What is less consistently addressed is the layer of state law obligations that sit on top of HIPAA — and in several states, exceed it in meaningful ways.

The federal preemption provision of HIPAA (45 CFR 160.203) does not preempt state laws that are more protective of patient privacy. Several states have enacted health data privacy laws that impose data residency requirements, breach notification timelines shorter than HIPAA's 60-day standard, and patient access rights that go beyond HIPAA's requirements. A cloud architecture that is HIPAA-compliant but state-law-non-compliant creates liability that a BAA does not cover.

HIPAA as the Federal Floor: What It Does and Does Not Require

HIPAA's Security Rule (45 CFR Part 164) establishes administrative, physical, and technical safeguards for electronic protected health information. The technical safeguards require access controls, audit controls, integrity controls, and transmission security — but do not specify particular technologies or geographic constraints. HIPAA does not require data to remain within the United States. It does not specify encryption algorithms beyond requiring appropriate encryption. It does not restrict which cloud regions PHI can be stored in.

What HIPAA does require is a BAA with every cloud service provider that handles PHI as a Business Associate. The BAA must specify permitted uses and disclosures, require the BA to implement appropriate safeguards, and establish breach notification obligations. AWS, Azure, and GCP all offer BAA-eligible service scopes — but not every service within each platform is covered under the BAA. Understanding which services are in scope is the first architectural constraint.

California: CMIA and CCPA Health Data Provisions

California's Confidentiality of Medical Information Act (CMIA) applies to providers, health plans, and healthcare service plans operating in California. It imposes obligations on medical information that go beyond HIPAA in several areas: breach notification must be made in the most expedient time possible and without unreasonable delay rather than within 60 days, and individuals have a right to inspect and copy their records within five business days of request compared to HIPAA's 30 days.

The California Consumer Privacy Act and its amendment, the CPRA, carve out medical information regulated under CMIA — but that carve-out has limits. Health data collected by entities that are not HIPAA covered entities may still fall under CPRA. Digital health apps, wellness platforms, and employer health programmes that do not qualify as covered entities must evaluate CPRA obligations independently of HIPAA.

Cloud architecture for California-based healthcare organisations must account for CMIA's breach notification timing, CMIA's civil liability provisions (which allow patients to sue directly for damages), and CPRA obligations for any non-HIPAA-regulated health data in scope.

Texas and New York: Health Data Obligations Beyond HIPAA

Texas Health and Safety Code Chapter 181 applies to covered entities defined more broadly than HIPAA, including entities that are not HIPAA covered entities but that handle protected health information in Texas. It requires breach notification within 60 days (aligned with HIPAA) but adds a requirement to notify the Texas Attorney General for breaches affecting more than 500 Texas residents. It also establishes a private right of action for negligent disclosure of PHI.

New York's SHIELD Act requires any person or business owning or licensing computerised data that includes private information of New York residents to implement reasonable data security. The SHIELD Act breach notification requirements — notification in the most expedient time possible and to the New York Attorney General for breaches over 500 residents — apply to healthcare organisations with New York patient populations.

Building the Multi-State Compliance Matrix

A cloud architecture serving a multi-state healthcare organisation must implement a state-residency-aware compliance layer. This means tagging PHI records with the patient's state of residence or the state where care was delivered, routing breach notification obligations to the correct state authority, and enforcing state-specific access timelines through the patient portal API.

A cloud architecture that routes data through international regions must verify whether any state laws governing that patient population restrict international data transfers. This is particularly relevant for organisations with significant patient populations in states that have enacted comprehensive privacy legislation since 2022.

The Cloud Provider BAA Scope Problem

AWS, Azure, and GCP each publish lists of services covered under their HIPAA BAAs. These lists do not include every service available on the platform. Healthcare organisations that build architectures using services outside the BAA-eligible scope — even inadvertently, through serverless compute functions, managed ML services, or logging infrastructure — create HIPAA violations regardless of the primary data store's compliance status.

Architecture review must include an explicit BAA scope check for every cloud service in the data path, not just the primary storage and compute layer. Logging services, secret management, message queuing, and container orchestration components all handle or interact with PHI in many architectures and must each be on the BAA-eligible service list for the primary cloud provider.

The Algorithm Approach: Compliance-First Cloud Architecture

The Algorithm builds healthcare cloud architectures with compliance constraints encoded as infrastructure requirements from the design phase, not applied as remediation after build. We maintain a current state-by-state health data law matrix and incorporate its requirements into cloud design documents, IaC configurations, and security control frameworks. For multi-state organisations, we design the patient residency tagging layer as a foundational data model component — ensuring breach notification, access rights, and processing restrictions can be enforced per-patient as the architecture scales.