In January 2025 HHS published a proposed overhaul of the HIPAA Security Rule, the first major update in many years1. Healthcare organisations have been watching it since. As of this writing it still isn't final, and commentators report the expected timing has slipped, with regulatory agenda targets moving into 202734.
My view as an architect working on health data: stop waiting for the final text. Most of the proposal describes controls a healthcare AI platform should have anyway. Confirm the legal detail with counsel; build the engineering now.
What the proposal would change
Based on HHS's own summary and the proposed rule, the headline changes include12:
| Area | Proposed change | What it means for an AI platform |
|---|---|---|
| Encryption | Required for ePHI at rest and in transit, with limited exceptions, instead of "addressable" | Every store holding ePHI is encrypted, including vector indexes, caches and logs |
| Multi-factor authentication | Required for access to systems with ePHI, with limited exceptions | MFA on consoles, notebooks, data tools and admin APIs, not just the main app |
| Asset inventory and network map | Written, maintained inventory of technology assets and data flows | You must know every place ePHI travels, including model providers |
| Testing and recovery | Regular vulnerability scanning, penetration testing and restoration expectations | Recovery is tested, not assumed |
Treat the specifics as proposed. The final rule could change, be scaled back or be withdrawn4.
The AI-specific blind spots
Traditional HIPAA programmes were built around EHRs and databases. AI systems add places for ePHI to hide that inventories often miss:
- Embeddings and vector indexes built from clinical notes. They are derived from ePHI and should be protected like it.
- Prompt and response logs, which can contain full patient details if content capture is switched on. My LLM observability post covers capturing metadata without content.
- Evaluation datasets copied from production to test quality, often into less controlled environments.
- External model providers, which need appropriate agreements and a clear record of what data reaches them.
- Agent tool calls that move data between systems, which should be scoped and logged as in securing MCP servers.
If your asset inventory doesn't list your vector database, your prompt logs and your model providers, it is incomplete, whatever the final rule says.
What I'd build now
- A data-flow map for every AI use case: where ePHI enters, every store it lands in, and every service it reaches.
- Encryption everywhere by default, enforced in infrastructure as code so new stores can't be created unencrypted.
- MFA through a single identity provider for every tool that touches ePHI, including data science environments.
- An AI gateway that redacts or blocks ePHI before it reaches providers without the right agreements, and logs every call.
- Synthetic or de-identified data for evaluation wherever possible, with production samples handled under the same controls as production.
- Tested restores of the data platform and vector indexes on a schedule, with the results recorded.
These sit naturally on top of a governed clinical data platform like the one in FHIR to OMOP.
The cost of waiting
Commentary suggests organisations may get a limited window to comply once a final rule is published3. Retrofitting encryption, MFA and an accurate inventory across a sprawling AI estate in a few months is far harder than building them in as the estate grows. And the risk these controls reduce exists today, rule or no rule.
How I can help
I design healthcare data and AI platforms with security built in, from ePHI data-flow mapping to gateways and recovery testing. See healthcare data architecture, or analyse your challenge and bring the result to a call.
- 1HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (proposed rule)Federal Register · 6 Jan 2025
- 2HIPAA Security Rule NPRM fact sheetUS Department of Health and Human Services
- 3
- 4