Unlocking Cardiac AI: Navigating Cures Act Software Exemptions

The line between a health app and a regulated medical device isn’t just for lawyers to debate. For health tech founders, it’s the whole ballgame, it dictates your path to market, your ability to get investment, and the operational risk you carry every day. Trying to navigate this, especially with AI tools, demands a sharp understanding of the statutory exemptions. If you get it wrong, you’re not just facing a setback. You’re looking at significant FDA enforcement actions that can kill your commercialization plans.

Deconstructing the 21st Century Cures Act: Section 3060 and Software Exemptions

Congress passed the 21st Century Cures Act, and specifically Section 3060 (Public Law 114-255), to try and clean up the regulatory confusion around digital health and get innovation moving faster. The main goal was to officially carve out certain software functions from the definition of a “device” under the Federal Food, Drug, and Cosmetic (FD&C) Act, effectively removing them from active FDA oversight. For anyone building an AI health tool, this distinction is everything. It determines whether your product needs a premarket review, a full-blown Quality Management System (QMS) like ISO 13485, or postmarket surveillance. The FDA uses Section 3060, along with frameworks from groups like the International Medical Device Regulators Forum (IMDRF), to draw the line between regulated SaMD (Software as a Medical Device) and non-device software. To stay out of the device category, your software has to meet four specific statutory criteria. These aren’t just suggestions. They’re the absolute foundation of your regulatory strategy for any AI tool in the health space.

The Four Pillars of Exemption: A Deep Dive into Statutory Criteria

You have to know every one of these four criteria from Section 3060 cold, especially if you’re building AI-powered clinical decision support (CDS) tools. A failure to meet just one can flip your product from an unregulated IT tool into a regulated medical device, bringing on a mountain of compliance work you probably didn’t budget for. The four statutory criteria for software to be excluded from the definition of a medical device are:

1. Administrative Support for a Healthcare Facility

This covers software for the business side of a healthcare facility. Think scheduling, billing, processing claims, or managing inventory. The bright line here is that the software doesn’t directly touch patient diagnosis or treatment decisions. An AI tool that helps a hospital optimize bed turnover or predicts supply chain needs would almost certainly fit under this exemption.

2. Maintaining or Encouraging a Healthy Lifestyle

This is the category for general wellness apps, your fitness trackers, calorie counters, and meditation guides. These tools don’t claim to diagnose, treat, mitigate, or prevent a disease. The moment they do, they’ve crossed the line. An AI app that gives you personalized workout plans or general diet tips based on what you log is likely exempt, as long as it stays away from making any medical claims.

3. Electronic Health Record (EHR) Functionality

Software that just transfers, stores, converts, or displays clinical data (like lab results) gets a pass under this criterion, which covers a lot of core EHR functions. But this isn’t a free pass for any AI you plug into an EHR. It’s all about the verb. If your AI is just displaying data, you’re probably fine. But if it starts analyzing or interpreting that data to recommend a clinical action, it has likely become a regulated device.

4. Clinical Decision Support (CDS) without Diagnostic or Treatment Recommendations

This is where most companies get into trouble, because the CDS exemption is complex and frequently misunderstood, particularly when AI is involved. To qualify for the exemption, your CDS software must hit three sub-conditions:

• Providing or Suggesting Recommendations: The software has to be aimed at a healthcare professional, giving them recommendations related to prevention, diagnosis, or treatment.
• Not Acquiring or Processing Medical Images, Signals, or Patterns: This is a hard stop for many AI diagnostic companies. Your software can not be intended to acquire, process, or analyze medical images (like an MRI), signals from an IVD, or patterns from a signal acquisition system. An AI that reads ECGs or flags anomalies on a CT scan is unequivocally outside this exemption and is a medical device.
• Enabling Independent Review: The software must be designed so a healthcare professional can independently review the basis for its recommendation. They can’t be in a position where they have to rely primarily on the software to make a clinical call. This means the AI needs to be transparent and explainable. If a doctor can’t see why your AI made a recommendation and has to just trust it, the FDA will likely classify it as a device. That “black box” nature of some sophisticated AI models becomes a massive regulatory liability here.

The FDA’s updated guidance on this topic dives deeper into these points, making it clear that the level of human oversight and how the software fits into the clinical workflow are what really matter FDA guidance on Clinical Decision Support Software. This guidance was officially issued on January 6, 2026.

The Rising Tide of Enforcement and Health Plan Exclusion Risk

Companies building AI health tools in the gray area of CDS without a defined SaMD pathway are facing bigger and bigger risks. The FDA is taking a much closer look at software that’s marketed as “support” but is actually making diagnostic or treatment recommendations without giving clinicians a way to independently verify them. We’re seeing more FDA warning letters for these kinds of software violations. That’s not a coincidence. The agency is signaling its intent to enforce these rules. These enforcement actions aren’t just a slap on the wrist. They can range from forcing a product reclassification and a full regulatory submission to a mandated recall, which can cause devastating financial and reputational harm. On top of direct FDA enforcement, the risk of getting shut out by health plans is growing. Payers are getting smarter about how they evaluate digital health tools. If your product doesn’t have a clear regulatory status or looks like it’s trying to dodge SaMD requirements, payers will see it as high-risk and may refuse coverage and reimbursement. Without a 510(k) clearance or De Novo classification, good luck getting CPT codes and proving clinical utility. No reimbursement means a very limited, if any, market.

The Hello Heart Benchmark: SaMD-Informed Architecture at Scale

While we’re focused on the CDS exemptions, it’s worth looking at companies who’ve gotten this right. Hello Heart is a good example of a company that has gained real traction with its digital platform for chronic disease. A big part of their success comes from building their platform from the ground up with SaMD in mind, carefully separating the regulated functions from the general wellness and educational pieces. This isn’t an accident. By either designing core functions to meet SaMD requirements from day one or strategically walling off other features as non-device functions, Hello Heart built a defensible regulatory position. This kind of architectural discipline reduces regulatory debt and creates a clear road for future product development and expansion. Their approach shows that treating regulation as a core part of your strategy, not an afterthought, is how you de-risk the business and build something that can actually scale.

Conclusion

Figuring out if your AI tool is an exempt piece of software or a regulated medical device is one of the first and most important jobs for any health tech company. Section 3060 of the 21st Century Cures Act gives you the rulebook, but interpreting it correctly means sweating the details of each criterion and what it means in practice. If you don’t rigorously test your software against these exemptions, especially the tricky parts of CDS, you’re taking on a huge amount of regulatory and commercial risk. Building with a SaMD-informed architecture, like the successful platforms have done, isn’t just about checking a compliance box. It’s a strategic decision that determines your company’s long-term viability and credibility in the market. Methodology and Source Note: This analysis is based on the statutory text of the 21st Century Cures Act and public FDA guidance documents. It is a statutory and regulatory review.