AI regulation in healthcare — what moved, what it means, what to do about it.

This Week

01

FDA updated its cybersecurity guidance to align with the QMSR. The core requirements haven’t changed since June 2025 — but if you’re not compliant yet, the clock is already running.

On February 3, FDA published the revised final guidance “Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions.” This is the third iteration since September 2023, updated specifically to align with the QMSR transition (see Section 02). The core cybersecurity requirements are unchanged from the June 2025 version — but if you haven’t caught up to those yet, the clock is already running.

Why it matters: This guidance has statutory teeth. Section 524B of the FD&C Act — added by the Consolidated Appropriations Act of 2023 — makes cybersecurity requirements legally enforceable for any “cyber device”: a device that includes software, can connect to the internet (directly or indirectly), and has characteristics making it vulnerable to cyberthreats. That definition covers every AI-enabled medical device, every SaMD product, and most connected diagnostics on the market.

The SBOM requirement is the headline. Under Section 524B(b)(3), every cyber device submission must include a machine-readable Software Bill of Materials in SPDX or CycloneDX format. This is not a recommendation — it is a legal requirement. The SBOM must meet the NTIA Minimum Elements baseline: supplier name, component name, version, unique identifier, dependency relationships, author info, and timestamp. FDA also expects support level documentation, end-of-support dates, known vulnerability assessments against CISA’s Known Exploited Vulnerabilities catalog, and mitigation controls.

FDA has been enforcing this through Refuse to Accept (RTA) decisions since the statutory requirements took effect in 2023. Submit a 510(k), PMA, or De Novo without adequate cybersecurity documentation — including an SBOM — and FDA will not review your application. It goes back in the pile.

Beyond the SBOM, the guidance requires a Secure Product Development Framework (SPDF) covering the entire device lifecycle. FDA recommends AAMI TIR45, IEC 81001-5-1, or ANSI/ISA 62443-4-1. You need documented threat modeling, security architecture, and testing. Postmarket obligations include continuous vulnerability monitoring, responsible disclosure, and timely patching.

The False Claims Act angle: Morgan Lewis flagged in November 2025 that manufacturers certifying compliance while lacking adequate cybersecurity documentation may face FCA liability. If your company signs FDA submissions attesting to cybersecurity compliance and your SBOM is incomplete or your SPDF is a paper exercise, that is a potential FCA exposure.

HIPAA connection: If your device creates, receives, maintains, or transmits ePHI, FDA cybersecurity requirements and HIPAA Security Rule requirements apply simultaneously. Both use a risk-based framework — HIPAA’s “reasonable and appropriate” standard and FDA’s device-risk-proportionate expectations overlap on authentication, encryption, audit logging, patch management, and incident response. Companies treating these as separate compliance tracks are doing double the work for half the protection.

Sources:  FDA Cybersecurity Guidance (Rev. Feb 2026)·Federal Register Notice (Jun 2025)·Section 524B — FDA Cybersecurity Program

02

Your quality management system just changed. The QMSR is live, and FDA has new powers to inspect what it couldn’t before.

On February 2, the FDA’s Quality Management System Regulation (QMSR) officially replaced the Quality System Regulation (QSR) that governed medical device manufacturing since 1996. The old 21 CFR Part 820 — 15 sub-parts, A through O — is now 2 sub-parts that incorporate ISO 13485:2016 by reference. If you manufacture a medical device sold in the United States, your quality management system must now comply with the QMSR.

Why it matters: The alignment with ISO 13485 sounds like a simplification, and for companies already ISO-certified, it partially is. But there are three changes that significantly expand FDA’s enforcement surface:

1. FDA can now inspect your management reviews, internal audits, and supplier quality audits. Under the old QSR, these records were explicitly protected from FDA inspection. The QMSR eliminates those protections. FDA’s reasoning: ISO 13485 never shielded these records, and other regulatory authorities worldwide already review them — so FDA aligned its access to match. Your internal quality candor is now discoverable.

2. Design traceability is now mandatory, not best practice. Documented traceability between design inputs, outputs, verification, and validation was previously a recommendation. Under QMSR, it is required. For AI/ML device companies, this means your model training data, validation datasets, evaluation evidence, and design history files must form a traceable chain that FDA investigators can follow.

3. New inspection program. FDA retired the Quality System Inspection Technique (QSIT) on February 2 and replaced it with Compliance Program 7382.850. Investigators will have “a different set of experiences, interpretations, and expectations” compared to the old approach. Industry observers expect more findings in early inspections as FDA calibrates.

For AI-enabled device companies specifically: AI/ML devices are not exempt. SaMD developers face the same design control and risk management obligations as hardware manufacturers. Risk-based thinking must now be embedded across all operations — supplier management, software validation, production controls, change management, CAPA, and complaint handling. ISO 13485 certification alone does not exempt you from FDA inspection; only MDSAP participants retain that exemption.

Sources:  QMSR Final Rule (Federal Register, Feb 2024)·FDA QMSR FAQ·QMSR Technical Amendments (Dec 2025)

03

HHS proposed rewriting the HIPAA Security Rule. If finalized, the “reasonable and appropriate” standard gets teeth.

HHS published a Notice of Proposed Rulemaking to modernize the HIPAA Security Rule — the first significant update since the rule was last amended in 2013. The proposed rule targets cybersecurity requirements for electronic protected health information (ePHI), and it signals a clear direction: what used to be “addressable” implementation specifications are moving toward mandatory.

Why it matters — and why it’s uncertain: The NPRM was published January 6, 2025. Two weeks later, President Trump issued the Regulatory Freeze Pending Review executive order. Industry coalitions including CHIME have petitioned HHS to withdraw the rule. OCR currently lists it on the regulatory agenda for May 2026, but finalization is genuinely uncertain. The current HIPAA Security Rule gives covered entities flexibility through its “addressable” vs. “required” distinction — organizations can implement alternatives if they document why the addressable specification isn’t reasonable and appropriate. In practice, this flexibility has become a loophole. HHS’s proposed changes would end the era of “we addressed it by deciding not to do it.”

For AI-enabled healthtech: This proposed rule converges directly with the FDA cybersecurity guidance in Section 01. If your product handles ePHI and qualifies as a cyber device, you will face parallel cybersecurity requirements from both FDA and HHS — with increasing overlap in encryption, access controls, audit logging, and incident response. The convergence is a regulatory signal that unified cybersecurity frameworks are becoming the expected approach, not a nice-to-have.

Our read: The regulatory freeze and industry pushback mean this rule may be delayed or altered. But the direction — stronger cybersecurity mandates for ePHI — has bipartisan support and aligns with OCR’s enforcement pattern (see Section 04). Companies that wait for the final rule to start planning will be scrambling.

Sources:  HIPAA Security Rule NPRM Fact Sheet (HHS)·Federal Register — HIPAA Security Rule NPRM (Jan 2025)·HHS HIPAA Security Rule Program

04

Three healthcare organizations reported cybersecurity incidents in a single week. The disclosure pattern is the enforcement story.

Delta Medical Systems (disclosed March 18), Meadowlark Hills (disclosed March 17), and MedPeds (disclosed March 17) all reported cybersecurity incidents in the same week — but these were not simultaneous attacks. Delta’s incident was an email breach from July 2025 disclosed in March 2026. MedPeds was a September 2025 ransomware attack disclosed in March. The clustering is about notification timing, not coordinated targeting. Different organizations, different sizes, but consistent with patterns OCR has identified in similar investigations: insufficient access controls, inadequate encryption, and delayed patch management.

Why it matters: Individual breach notifications are noise. The pattern is the signal. OCR doesn’t just investigate the breach — it investigates whether the organization’s security posture met the “reasonable and appropriate” standard at the time of the attack. With HHS simultaneously proposing to tighten that standard (Section 03) and FDA requiring cybersecurity documentation for device submissions (Section 01), the regulatory environment is compressing from multiple directions.

The enforcement precedent: OCR has settled multiple ransomware-related cases for seven-figure penalties in the past two years — not because the organizations were hacked, but because their security programs had documented gaps that predated the attacks. The attack is the trigger; the inadequate program is the violation.

For AI-enabled healthtech: If your product processes or stores ePHI, your cybersecurity posture is part of your customers’ compliance surface. A breach at their facility that involves your product puts both organizations under OCR scrutiny. Your Business Associate Agreement defines the boundary — make sure it reflects your actual security practices, not aspirational ones.

Sources:  CISA Healthcare Ransomware Advisory·CISA Healthcare Cybersecurity Best Practices·HHS ASPR Cybersecurity Program

05

FDA warned 30 telehealth companies for illegal marketing of compounded GLP-1 drugs. FDA is also increasing enforcement in telehealth — through a different regulatory channel than Issue #002.

On March 3, FDA issued warning letters to 30 telehealth companies for illegally marketing compounded drugs — including GLP-1 weight loss medications — through online platforms. These are FD&C Act drug marketing violations, a different agency and statute from the OCR/HIPAA privacy enforcement we covered in Issue #002. But the broader pattern is the same: regulators are tightening oversight of telehealth from multiple directions simultaneously.

Why it matters: The shift from individual enforcement actions to coordinated batch warnings signals that FDA is treating telehealth marketing as a systemic compliance problem, not a series of one-off violations. For healthtech companies using AI to power telehealth platforms, clinical decision support tools, or patient engagement systems, the marketing claims your platform enables are now squarely in FDA’s enforcement crosshairs.

Our read: The FDA warning letters targeted compounded drug marketing claims under the FD&C Act — not AI specifically. But the implications for AI-enabled platforms are worth flagging. If your platform algorithmically generates, suggests, or personalizes marketing content for telehealth services, you are responsible for the claims that content makes. “The AI wrote it” is not a defense FDA will recognize. Review what your platform says about drug efficacy, treatment recommendations, and clinical outcomes — especially if those claims are dynamically generated.

Sources:  FDA: Warns 30 Telehealth Companies (Mar 2026)

Your three-item punch list this week

What’s the one compliance question you wish someone would answer this week? Hit reply.

The Compliance Signal — compliancesignal.io
AI regulation in healthcare — tracked, analyzed, and translated into action.

Questions? Reply to this email or contact jay@compliancesignal.io

You received this because you subscribed at compliancesignal.io. Unsubscribe.