AI Medical Device Regulation: FDA PCCP, CDS Rules and CDSCO Guidance

AI medical device regulation changed meaningfully between late 2024 and 2026. The US FDA finalised how AI devices can be updated without a new submission each time, loosened its stance on some clinical decision support and wellness software, and is still finalising its lifecycle guidance. In India, CDSCO moved from a draft to a final guidance on medical device software, with specific expectations for AI.

If you build health software, or buy AI tools for a hospital, you need to know which side of the line a product falls on. This guide explains the rules in plain terms. It is not legal advice; for a specific product, work with a regulatory specialist.

The short version: what the software is intended to do decides whether it is a device. Administrative and data-management software usually is not; software that informs diagnosis or treatment usually is.

The core idea: intended use decides

Both the FDA and CDSCO regulate software based on its intended medical purpose, not its technology. The same LLM can be unregulated when it drafts an appointment reminder and regulated when it suggests a diagnosis.

FDA: the predetermined change control plan (PCCP)

The classic problem with AI devices is that every model update could require a new FDA submission. The PCCP fixes that. On 4 December 2024 the FDA issued final guidance on PCCPs for AI-enabled device software functions, grounded in section 515C of the FD&C Act added by FDORA.

A PCCP is submitted with the original 510(k), De Novo or PMA and describes:

• Planned modifications: for example, retraining on new data or extending to a new scanner model.
• Modification protocol: how each change will be developed, validated and rolled out.
• Impact assessment: benefits and risks of the planned changes.

If the FDA authorises the PCCP, the manufacturer can make those specific changes without a new submission, as long as it follows the protocol. The final guidance covers changes made manually, automatically or both.

FDA: lifecycle guidance and what is still pending

In January 2025 the FDA issued draft guidance on lifecycle management and marketing submissions for AI-enabled device software functions, covering documentation, data management, bias, transparency and performance monitoring. As of the FDA device centre's FY2027 guidance agenda, published in October 2026, finalising that lifecycle guidance is listed as a priority, so it remains a draft. The agenda also lists a broader PCCP guidance for all devices.

The FDA also keeps a public list of AI-enabled devices it has authorised and has said it plans to tag devices that use foundation models and LLM functions.

FDA: the January 2026 CDS and wellness updates

On 6 January 2026 the FDA issued revised guidances on clinical decision support (CDS) software and general wellness products, effective immediately. According to Orrick's analysis:

• The FDA will apply enforcement discretion to a broader set of CDS functions, including some single-output software where only one clinically appropriate recommendation exists.
• The 2022 language that excluded risk scores from non-device CDS was removed.
• The wellness guidance now covers more non-invasive wearables that estimate values such as blood pressure, oxygen saturation or glucose, as long as outputs are framed for wellness rather than clinical use.
• The FDA still signalled priority attention for higher-risk uses, especially where AI outputs guide care without adequate human oversight.

For builders, this widens what can ship without clearance in the US, but the conditions matter: transparency about the basis for recommendations, intended users being clinicians who can review the reasoning, and no time-critical directives. Read the guidance itself before relying on it.

India: CDSCO's medical device software guidance

India regulates medical devices under the Medical Devices Rules, 2017, with a four-class risk system (A lowest to D highest). Software was always covered in principle, but how was unclear. CDSCO issued a draft guidance on medical device software on 21 October 2025, and Emergo by UL reported in July 2026 that the final guidance was issued.

Key points as reported:

• Scope: software with a medical purpose, including SaMD, software in a device (SiMD), AI-enabled software and some mobile apps.
• Excluded: software without a medical purpose, such as quality system or ERP software, general wellness apps and data management software.
• Classification: software that drives or influences a device's hardware takes that device's class. Standalone software is classified by the condition it addresses and how significant its output is for healthcare decisions.
• AI-specific expectations: describe training, validation and test data composition, including demographic, geographic and clinical diversity; disclose bias, generalisability and robustness across sub-populations relevant to India; state whether training data is real-world or synthetic.
• Other areas: design, cybersecurity, labelling, clinical evidence and post-market surveillance.

What this means for hospital management software

Most hospital management system modules are outside device rules: registration, billing, inventory, scheduling, bed management, dashboards. CDSCO's exclusion of ERP and data management software is consistent with that. Our guide to HMS modules lists what typically sits in an HMS.

The line gets closer when you add clinical AI:

• A drug interaction alert based on a published rule set: lower risk, but check claims.
• An early warning score that tells nurses a patient is deteriorating: may be device software, depending on intended use and how it is presented.
• An AI that reads ECGs or X-rays: device software.

If you are building such features into a hospital platform, decide early whether you will seek approval, integrate an approved third-party product, or limit the feature's claims. That choice shapes architecture, documentation and cost.

What a regulatory-ready AI product needs

Whether in the US or India, the expectations overlap:

1. A clear intended use statement: condition, population, users, setting.
2. A quality management system (ISO 13485 is the common reference) and software lifecycle processes.
3. Risk management across the product lifecycle.
4. Documented training and test data, with demographic breakdowns.
5. Clinical or performance evidence in the intended population.
6. Cybersecurity controls and a vulnerability process.
7. Labelling that explains limitations.
8. Post-market monitoring and a plan for model updates (a PCCP in the US).

How the US and Indian approaches compare

The two systems are converging on the same ideas: intended use, documented data, subgroup performance, and monitoring after launch. A product built to satisfy both from the start avoids expensive rework later.

Worked example: an early warning feature in an HMS

Imagine a hospital software team wants to add a deterioration score to its nursing module. There are three realistic paths.

1. Rule-based score with clear labelling. Calculate a published early warning score from vitals, show the inputs and the published rule, and leave decisions to clinicians. Lower risk, though claims still matter.
2. Integrate an approved third-party model. The vendor holds the regulatory responsibility; your team handles data feeds, display and logging.
3. Build and register your own ML model. Highest effort: quality system, clinical evidence, India-relevant validation, post-market surveillance, and in the US a PCCP if you expect to retrain.

Most hospital software teams should start with path one or two. Path three makes sense only when the model is a core product with a long life, and when the team is ready to carry the documentation and surveillance load for years, not months.

Checklist for hospitals buying AI

• What is the product's regulatory status in India, and in which other markets?
• What is the stated intended use, and does your planned use match it?
• What data was it trained and validated on? Any Indian validation?
• How are updates handled, and will you be notified?
• What post-market monitoring does the vendor do, and what do they expect from you?
• Where is data processed, and how does that fit the DPDP Act? See our DPDP checklist for hospitals.

Conclusion

AI medical device regulation in 2026 is clearer than it was two years ago. The FDA has a working mechanism for updating AI devices, has loosened some CDS and wellness rules, and is finalising lifecycle guidance. India now has CDSCO guidance that treats AI explicitly and asks for India-relevant validation.

For builders, decide intended use early and document as if you will be audited. For hospitals, ask vendors the right questions. At Algon we help teams design healthcare software with clean boundaries between administrative features and regulated clinical functions, and integrate approved clinical AI where it fits. For how governance works inside the hospital, read our hospital AI governance framework.