HIPAA, AI procurement in US healthcare

HIPAA was enacted in 1996 and has been extended by subsequent legislation including the HITECH Act of 2009, which strengthened obligations for Business Associates, and the Omnibus Rule of 2013, which gave those requirements the force of direct regulation. Three rules carry the operational weight for AI procurement: the Privacy Rule, the Security Rule, and the Breach Notification Rule.

The Privacy Rule governs the use and disclosure of PHI. PHI includes any individually identifiable information relating to the past, present, or future physical or mental health of an individual, the provision of healthcare, or payment for healthcare, where that information is held by a covered entity or its business associates. Electronic PHI (ePHI) is the subset of PHI held in electronic form, and it is the most relevant category for AI systems.

The Security Rule requires covered entities and Business Associates to implement administrative, physical, and technical safeguards to protect ePHI. Administrative safeguards include a documented risk analysis, security policies, and workforce training. Physical safeguards govern facility access and workstation controls. Technical safeguards include access controls, audit controls, integrity controls, and transmission security, which in practice means encryption in transit and, for ePHI at rest, encryption or equivalent controls.

The Breach Notification Rule requires covered entities and Business Associates to notify affected individuals, the Department of Health and Human Services, and in some cases the media when unsecured PHI is impermissibly disclosed. This obligation applies to Business Associates as well as covered entities, a provider who experiences a breach involving a client's PHI has notification obligations to that client.

A Business Associate is any person or organisation that performs services for a covered entity that involve creating, receiving, maintaining, or transmitting PHI. An AI provider that processes clinical notes, diagnostic images, lab results, or other PHI on behalf of a hospital, health system, health plan, or healthcare clearinghouse is a Business Associate. The relationship must be formalised in a Business Associate Agreement (BAA) before any PHI is disclosed.

A BAA must specify the permitted uses and disclosures of PHI, require the Business Associate to implement safeguards, and require the Business Associate to report breaches to the covered entity. A Business Associate may engage sub-contractors who also handle PHI, but each sub-contractor then becomes a sub-Business Associate and must sign a BAA with the Business Associate, not only with the covered entity. This chain-of-contract requirement is where AI pipelines most commonly fail.

The chain-of-BAA failure typically looks like this: a provider signs a BAA with a health system, but their pipeline routes PHI through a commercial LLM API or a third-party vector database that has not signed a BAA. The absence of a BAA at that point in the pipeline constitutes an impermissible disclosure, regardless of whether the third party is a reputable company. The question to ask is not whether a provider uses reputable third parties, but whether every third party in the pipeline that touches PHI has signed a BAA.

HIPAA applies when the data is PHI and the organisation is a covered entity or Business Associate. It does not apply to all health-related data: a fitness app that collects step counts without a healthcare affiliation is generally not a covered entity, and its data is generally not PHI. Nor does HIPAA address every aspect of AI risk in healthcare, it governs data protection, not model accuracy, clinical safety, or AI Act-style risk classification.

Compliance with HIPAA is necessary but not sufficient for healthcare AI procurement. A provider who can sign a BAA and implement the Security Rule's safeguards has cleared a meaningful bar, but buyers in regulated healthcare settings should separately assess clinical risk, explainability, and regulatory requirements specific to medical software, such as FDA oversight of Software as a Medical Device (SaMD).

Trustgent's provider profiles include a HIPAA readiness attribute. At L2 cross-reference level and above, that attribute is checked against sources outside the provider's control, published case studies, client-side documentation, third-party references. A claimed HIPAA readiness at L0 or L1 reflects self-assertion only. We do not issue BAAs, assess PHI handling, or verify legal compliance; we make the distinction between claimed and evidenced HIPAA experience visible to buyers in the index.