NIST illustration showing AI research applications including health, cybersecurity and manufacturing
Healthcare data protectionHealthcare AI security: what to check before sharing patient data
NIST's AI research illustration, used as background context for healthcare AI. This is not a photograph of the September conference.Image: N. Hanacek / NISTNIST reuse policyImage fitted for layout; headline added by Securelay. Editorial context, not endorsement.
Primary source NIST and HHS OCR: 2–3 September 2026 conference and published agendaPrimary source HHS: summary of the HIPAA Security Rule currently in effect

A timely reason to review healthcare AI

The published agenda for NIST and HHS OCR's 2–3 September 2026 HIPAA Security conference included healthcare AI, privacy-enhancing technologies and risk management. Those topics provide a useful starting point for an internal review. This article draws on the published agenda and current HHS guidance; it does not report remarks from the event.

Separate current obligations from proposals

HHS's current Security Rule summary describes safeguards for electronic protected health information handled by covered entities and business associates. It also distinguishes the rule in effect from proposed modifications. A new AI tool does not remove the need to assess risks, manage access and evaluate safeguards. HIPAA does not apply to every health app simply because the app handles health-related information.

Draw the complete patient-data route

Our practical starting point is one synthetic document and one AI task. List the source system, extraction step, prompt, retrieval store, model provider, response destination and support logs. Ask which parts retain a copy. A provider's promise not to train on inputs does not, by itself, answer questions about retention, support access or subprocessors.

Choose the information the task really needs

For a test summarisation workflow, compare the result with and without direct patient identifiers. Check whether narrative details still identify someone. Protecting names and phone numbers can reduce exposure, but tokenisation alone is not a determination that the record meets HIPAA de-identification requirements. Review the applicable use, disclosure and contractual requirements with the responsible privacy team.

Agree a reviewable acceptance test

Use synthetic records to test an unauthorised user, an unavailable policy service and a request to reveal a protected value. Check the result and the audit reference. Also assign an owner for disabling the integration, handling deletion requests and investigating a suspected disclosure. Do not put real patient data into an initial vendor evaluation.

Where Securelay fits

Securelay can support configured protection of sensitive values before connected AI calls, access decisions and value-free audit evidence. Your organisation must still evaluate the full deployment, contracts, retention and operational safeguards. Start with one document route and a written division of responsibilities, rather than treating a single product as a HIPAA compliance certificate.

Put the control on the data path.Discuss an architecture review