The PCCP Constraint

In February 2026, Labcorp announced it would deploy PathAI's AISight Dx platform across its national network of anatomic pathology labs. The press release called it cloud-based, AI-powered, efficient. The word that matters is buried three paragraphs down: the FDA clearance included a Predetermined Change Control Plan, or PCCP. If you are the engineer who built this system, that phrase is not a feature. It is a contract you signed in code before the regulator would let you ship.

Authorized by the 2022 Food and Drug Omnibus Reform Act and codified in Section 515C of the FD&C Act, the PCCP allows manufacturers to predefine and preapprove planned device modifications within a single marketing submission. The theory is elegant: medical AI changes faster than the traditional device-approval cycle, so you write down what you will change, how you will verify it, and what impact it will have, and the FDA pre-clears those updates so you can ship them without filing again. By pre-clearing specified updates, PCCPs allow device improvements to proceed rapidly while upholding safety standards. That is what the lawyers say. Here is what it means if you are writing the software.

You scope the modifications before you know what the field will need. PathAI's PCCP covers support for additional scanners, file formats, and display configurations, which sounds like table stakes for a digital pathology platform. It is. It is also the outer boundary of what you can ship without going back through a 510(k). The pathologist three states over needs the system to handle a Leica scanner in a way you did not anticipate? That was in the plan, you ship it. The hospital network wants an integration with a lab-information system you have never touched? Not in the plan. You file, you wait, or you walk.

The PCCP changes the product map. You are no longer building features in response to what the customer asks for next week. You are building a system architecture flexible enough to absorb a category of change you defined eighteen months ago, and rigid enough everywhere else that you do not trigger a new submission. The FDA recommends that PCCPs detail planned device modifications, methods and standards for repeat safety evaluations, and a plan to communicate changes to existing users. The phrase "planned device modifications" is doing heavy conceptual work. It presumes you can predict, in the first submission, the kinds of changes the deployed system will require over the next two or three years. If you are an engineer who has shipped medical software, you know how that prediction performs.

The safe move is to write the narrowest PCCP you can defend. Authorized modifications must not alter a device's intended use or, in most cases, indications for use. That constraint cuts both ways. You keep the clearance valid, but you also freeze the clinical scope at the moment of approval. The model gets better at detecting artifacts in H&E-stained slides? That was in the plan. You want to add immunohistochemistry? Different stain, different tissue prep, different failure modes. Not in the plan.

Twenty-six devices had authorized PCCPs as of May 2025, all through the 510(k) and De Novo pathways. That number is still small enough that every one is a test case. The vendor pitch is that the PCCP buys you speed. The plan accelerates the platform's ability to evolve while maintaining regulatory compliance, helping institutions stay ahead in diagnostic innovation. Speed within a fixed envelope, maybe. The envelope itself does not move. You ship scanner support faster; you do not ship a new clinical indication faster, because that was never what the mechanism was built to allow.

There is a second constraint the announcement does not mention. Manufacturers submit a documented plan outlining the specific changes to be made, the methods for implementing and verifying those changes, and an impact assessment of safety and effectiveness. The verification method is not a post-hoc formality. It is the method you committed to in the original filing, and it has to run every time you make a change the PCCP covers. If the verification protocol you wrote eighteen months ago says you will revalidate against a held-out test set with minimum performance thresholds, you run that protocol on every scanner update, every file-format patch, every configuration tweak. The PCCP does not eliminate the validation work. It front-loads the commitment to a process that has to be good enough to satisfy the regulator for modifications you have not written yet.

This changes what you can afford to promise in a customer pilot. The health system asks if you can tune the model to their population's disease prevalence. Technically, yes. Regulatorily, no, unless retraining on site-specific data was in the modification plan and the re-validation method can prove it did not degrade performance on the original clearance population. The PCCP gives you a budget. You spend it on the changes that keep the platform commercially viable at the largest number of sites, which means the long tail of site-specific customization is the first thing you stop doing.

It also changes your QMS. Post-market surveillance procedures must align with ISO 13485 and the QMSR, effective 2 February 2026. The quality system has to support not just the device you shipped, but the iterative change process you pre-committed to. Version control is no longer a convenience for the engineering team; it is evidence in the regulatory record. You need to be able to demonstrate, on demand, that modification 7 of 22 in the approved PCCP was implemented using the protocol in appendix C of the original submission, that the impact assessment showed no degradation, and that affected customers were notified per the communication plan. That is not how most software teams track releases. It is how you track them now.

The pathology vendors will tell you the PCCP solves the adaptive-AI problem. AI-enabled medical devices are not static products; unlike a traditional implant, the device that receives FDA approval may continue to evolve once it is on the market, which creates a regulatory paradox. The mechanism does not solve the paradox. It narrows it. You get to adapt within the modification boundaries you defined up front. Outside those boundaries, you are in the same cycle you were trying to escape: file, wait, defend, ship.

I have seen three vendor responses to this constraint. The first is to write a PCCP so broad that it covers every foreseeable modification, accept the risk that the FDA will reject it or demand a narrower scope, and negotiate down to something you can live with. The second is to write the narrowest possible plan, ship the clearance, and then come back with a separate supplement for anything outside the envelope. The third is to split the product: everything that touches a diagnostic decision goes through the 510(k) with a PCCP; everything else ships as a non-device software update on a different release cycle. That third option is only viable if you can draw a legally defensible line between decision support and workflow tooling, and that line is thinner than most vendors admit.

The Labcorp deployment is interesting because it is national scale on a platform that was cleared eight months ago. The platform enables fully digital workflows for case management, slide review, collaboration and annotation, and integrates AI-powered image analysis, secure storage and system connectivity. Some of that is the regulated device. Some of it is lab IT. The customer does not care about the distinction, but the engineer shipping the update does, because one half of that sentence can be patched under the PCCP and the other half cannot.

In January 2026, Aidoc received FDA clearance for the first foundation model-powered clinical AI device, a single body CT triage solution covering 14 conditions. That clearance almost certainly came with a PCCP, and the modification plan almost certainly does not include adding a fifteenth condition. The foundation model can technically do it. The regulatory envelope does not cover it. The engineer building the next version knows which constraint binds.

If you are a health system evaluating one of these platforms, the question to ask is not whether the vendor has a PCCP. The question is what modifications the plan actually covers and what the verification protocol requires. A vendor that can add scanner support in six weeks is useful. A vendor that can retrain the model on your population without a new submission would be transformative, but that is not what most PCCPs allow, because the modification must not alter the device's intended use or indications for use, and retraining on a different population is a change in the performance envelope the original clearance was based on.

The PCCP is a regulatory innovation. It genuinely does let AI-enabled devices update faster than the old framework allowed. It is also a scoping exercise, written in advance, that defines the product the vendor is actually able to ship over the next 24 to 36 months. The press release talks about cloud-native and AI-powered. The person writing the code is looking at a list of pre-approved modification types and a verification protocol that has to run on every release, and that list is what the roadmap is built around.

Tarry Singh is the founder and CEO of Real AI (realai.eu), an enterprise AI advisory and deployment firm working with global enterprises on production agent systems, model risk, and AI sovereignty strategy. He also leads Earthscan (earthscan.io) for Energy AI, and is a founding contributor to the EU-funded HCAIM and PANORAIMA programmes for responsible AI education across European universities. He writes at tarrysingh.com.