🎧 Part I Podcast free on Apple Podcasts and Spotify.
🎧 Part II Podcast episode for paid subscribers only. Also available on Apple Podcasts and Spotify.
To listen to paid episodes in Apple or Spotify, link your Substack subscription via the show settings on those platforms (instructions inside the Substack app under Subscriptions → Podcast).
Table of Contents
What the FDA actually put on the table
A release becomes an evidence project
The data contract behind the model update
What monitoring can and cannot tell the buyer
Software that connects the plan to the deployed device
The customer and the unit economics
Where a defensible business could emerge
What investors should ask to see
Abstract
Predetermined change control plans give medical device manufacturers a way to secure FDA authorization for specified future modifications before implementing them. That creates a plausible recurring business around the evidence needed to execute those changes: independent clinical data, statistical evaluation, version control, release documentation, and performance monitoring. The opportunity depends on how often manufacturers actually update their products, how much work can be reused, and which activities they will outsource. A company that writes a plan may earn a consulting fee. A company that helps execute successive updates could build recurring revenue. The strongest products would connect an authorized modification to its supporting evidence and the exact device version deployed at each customer. This essay examines the regulatory boundaries, technical workload, purchasing decisions, and business economics behind that opportunity, including why regulatory flexibility alone does not establish a large software market.
What the FDA actually put on the table
A medical AI company improves its model. Engineering has a better result, the product team has promised an update, and a hospital customer wants it installed before the next contract discussion. Then somebody asks which patients were used for testing, whether those patients appeared in training, whether performance held up across scanners, and whether the change fits the device’s existing authorization. The meeting gets longer. Somewhere, a spreadsheet acquires another tab. This is the work behind the commercial opportunity in predetermined change control plans, or PCCPs. Model development creates a candidate update. Getting that update into clinical use requires evidence that the manufacturer can explain, reproduce, and connect to the conditions under which the device is allowed to operate.
The FDA’s August 2025 guidance, issued on August 18, 2025, describes how manufacturers can seek authorization for specified future AI-enabled device software modifications through the 510(k), De Novo, and premarket approval pathways. Its scope includes changes implemented manually and changes implemented automatically by software. Guidance itself contains nonbinding recommendations, and manufacturers are not universally required to adopt a PCCP. The commercial implication is therefore a hypothesis about recurring work: sponsors that choose this approach may need better ways to execute the evidence process they proposed. There is no general permission slip allowing a deployed model to learn whatever it wants from whatever happens to arrive next.
The plan generally contains a Description of Modifications, a Modification Protocol, and an Impact Assessment. Those names translate into practical questions. What exactly may change? How will the manufacturer develop, test, and implement the change? What happens to the device’s benefits and risks, including the cumulative effects of multiple modifications? The planned changes must maintain the device within its intended use, and devices using the 510(k) pathway must remain substantially equivalent to the predicate. These constraints matter commercially because a useful product roadmap contains both predictable maintenance and genuinely new capabilities. A PCCP can help with specified changes that fit its boundaries. Its existence does not establish authorization for every future item in the roadmap.
There is another distinction that belongs in every business model built around this policy. A change outside the plan does not automatically require a new submission. It goes through the applicable device modification assessment, and some changes can proceed without additional premarket review. Conversely, a change described in the plan still has to satisfy its protocol. Failing a performance criterion cannot be cured by pointing out that retraining appeared somewhere in the document. Revising the authorized plan itself generally requires further FDA review. For a prospective vendor, this means the product must support several possible decisions, including proceeding under the plan, documenting another permissible route, or preparing a new submission. A system that treats every engineering ticket as either automatically permitted or automatically prohibited will create expensive confusion.
A release becomes an evidence project
Actual authorizations help make the opportunity concrete. Beacon Biosignals’ SleepStageML received FDA 510(k) clearance on March 8, 2024, with a PCCP covering updates to the sleep-staging machine-learning algorithm and related processing. The FDA’s clearance documentation confirms that the substantial-equivalence determination included review and clearance of Beacon’s PCCP. The company described the clearance publicly on March 27, 2024. That scope is useful because it shows how much of a clinical software product sits around the model itself. Changing an input filter can alter which signals reach the algorithm. Changing postprocessing can alter the classifications a clinician sees. A release record that captures only the model weights leaves substantial behavior unexplained. The business opportunity extends into tracking and testing the complete processing pipeline, including components that might look like routine engineering work until they affect clinical output.
Consider a hypothetical imaging triage manufacturer that wants to reduce false alerts while preserving sensitivity. The proposed change may involve retraining, a different operating threshold, or both. Before executing the study, the team needs to establish the comparison, the clinically acceptable performance limits, the intended population, and how uncertainty will be handled. A higher area under the receiver operating characteristic curve would not, by itself, answer whether the deployed threshold still catches the relevant findings. Nor would a pooled result necessarily establish acceptable performance on a scanner configuration that contributed relatively few cases. An evidence vendor could help translate the proposed change into a controlled evaluation, but the clinical tradeoff still requires judgment. A template cannot decide how many additional missed findings are acceptable.
Sample size makes this uncomfortable quickly. In a separate illustrative calculation, a model that correctly identifies ninety of one hundred independent patients who truly have the target condition has observed sensitivity of ninety percent. Its approximate ninety-five percent Wilson confidence interval runs from eighty-three percent to ninety-four and a half percent. At the same observed sensitivity in one thousand independent positive patients, the interval narrows to roughly eighty-eight to ninety-two percent. Those are very different evidentiary positions despite the identical headline metric. The required study size depends on the acceptance criterion and analysis design. Thousands of images from a small number of patients also cannot casually be treated as thousands of independent patients. A startup selling validation should understand the sampling unit before quoting a price per image.
Successive releases introduce another problem. If each new version is compared only with its immediate predecessor, a sequence of individually tolerated losses can accumulate into a meaningful decline. Repeatedly inspecting the same holdout set while revising candidates can also make that set less independent in practice, even when nobody copies its files into the training folder. These are reasons to design evaluation governance across releases, including the role of the original device, prior versions, refreshed data, and controlled access to results. The precise method depends on the device and protocol; a universal statistical recipe would be hard to defend. Research on repeated approval policies has examined this cumulative deterioration problem directly. For an evidence business, managing it could be substantially more valuable than generating another performance chart.
The data contract behind the model update
Clinical data procurement starts with a deceptively simple request: find enough representative cases to test the change. Then the qualifications arrive. The cases must fit the intended use, contain usable inputs, support an appropriate reference standard, and remain sufficiently independent from development data. The FDA’s good machine learning practice principles explicitly identify patient, acquisition, and site factors as potential sources of dependence between training and testing. In practice, a large dataset can still be poorly suited to a particular update. A collection dominated by one referral center may miss the operating conditions of community hospitals. A dataset rich in obvious disease may tell little about borderline cases. Buying more records does not necessarily buy more useful evidence.
Reference labels deserve their own budget. For an imaging product, a report produced during routine care may answer a different question from the one the validation protocol asks. A billing code may establish that a condition was recorded without establishing exactly when it appeared or what was visible in the original image. Expert review can help, but disagreement needs a predefined treatment. Excluding every difficult case can leave a beautifully clean evaluation that avoids the cases where the device is most likely to struggle. A credible service would document case selection, reviewer qualifications, adjudication, exclusions, and missing information. That work has a different cost structure from selling access to a warehouse of claims. Both businesses may involve healthcare data, but their deliverables are quite different.
Repeated updates also change the commercial agreement. A sponsor may need access to fresh cases, permission for repeated evaluations, source verification, and a way to establish that future test cohorts have not entered development. An agreement designed for one retrospective study may not cover that operating model. The technical architecture could keep sensitive data inside a participating institution and bring an approved evaluation environment to it, although that creates its own integration and reproducibility work. A vendor could offer cohort feasibility, controlled evaluation, and a documented chain from source records to results as a recurring service. Its useful asset would be dependable access to suitable cases under workable agreements. A slide announcing access to millions of patients says little about whether the next required subgroup can be assembled before the release date.
What monitoring can and cannot tell the buyer
Once an update reaches customers, several things can change at once. A hospital replaces an imaging system. A laboratory changes its reference range. Documentation practices shift. Referral patterns bring in a different patient population. An interface starts dropping a field. Each event can affect a model differently, and detecting a changed input distribution does not establish that clinical performance has deteriorated. Conversely, an apparently stable distribution does not prove that the relationship between inputs and outcomes remains stable. A useful monitoring product should distinguish observable pipeline behavior from measured clinical performance. It should also identify what cannot yet be known because the reference outcome has not arrived. A dashboard that calls all of these conditions “drift” may look busy while leaving the quality team with most of the investigative work.
A simple hypothetical shows why the operating context matters. Suppose a classifier is used in ten thousand encounters where the target condition occurs in one percent of cases. At ninety percent sensitivity and ninety percent specificity, it produces ninety true positives and nine hundred ninety false positives. Only about eight percent of positive results are true positives. If specificity improves to ninety-eight percent while sensitivity holds, false positives fall to one hundred ninety-eight and positive predictive value rises to roughly thirty-one percent. This calculation assumes the stated prevalence and performance actually apply to that population. It also shows why a seemingly modest change in specificity can matter enormously to the people reviewing alerts. A buyer may care more about that workload than about a small movement in a global discrimination metric.
Measuring clinical performance after deployment is harder than counting alerts. Definitive labels may arrive slowly, and patients with positive results may receive more follow-up than patients with negative results. A successful intervention may also prevent the event that a model predicted, complicating the interpretation of an apparently incorrect prediction. Monitoring therefore needs a deliberate outcome collection and sampling strategy, with awareness of how clinical behavior affects the available evidence. The product opportunity could include arranging adjudication, investigating missing outcomes, and linking findings to the exact version used at the time. That is a more demanding service than observing model outputs. It also explains why real-time accuracy claims deserve scrutiny when the underlying clinical truth takes weeks to establish.
Software that connects the plan to the deployed device
A practical software product could begin with the authorized PCCP and represent its permitted modifications, evaluation procedures, and acceptance criteria as controlled records. When engineering proposes a release, the system would connect that proposal to the relevant part of the plan and assemble the evidence needed for review. This requires more than document storage. The sponsor should be able to establish which dataset, preprocessing implementation, model, threshold, and analysis code produced a particular result. The record should also preserve the criteria in effect before testing began. Otherwise, a passing result can become difficult to distinguish from a result that passed after the rules quietly moved. The product’s contribution is making those relationships explicit and inspectable.
That architecture needs to coexist with the manufacturer’s quality system and engineering tools. Replacing both would turn a focused purchase into a much larger organizational project. A narrower product could obtain version information from the model registry, execution results from the testing environment, and controlled approvals from the quality system. The interfaces need clear ownership of each record and a way to handle disagreement between systems. If engineering marks a build ready while quality still considers its evidence incomplete, the software should preserve that distinction. Release authorization, whether performed by designated people or through an appropriately controlled automated process, must remain connected to the sponsor’s established procedures. A green status indicator is only useful when everyone knows what it means.
The regulatory environment also affects the supplier’s own implementation. The FDA’s Quality Management System Regulation became effective on February 2, 2026, and incorporates ISO 13485:2016. The FDA’s February 2026 computer software assurance guidance describes a risk-based approach to establishing confidence in software used for production or quality management. For a vendor entering this workflow, customer evaluation of its own software is therefore a serious implementation consideration. Evidence automation that changes frequently without controlled testing could create additional work for the manufacturer. The same applies to an AI assistant that writes plausible explanations disconnected from the underlying records. Generated prose may help prepare a package, but statistical results and supporting evidence need a reproducible basis.
Deployment records complete the picture. Different hospitals may be using different versions, particularly when installation depends on local infrastructure or customer approval. If an issue appears, the manufacturer needs to identify the affected configurations and evaluate an appropriate response. A useful system could connect each deployment to its release evidence, labeling, known limitations, and subsequent findings. Rollback also needs thought: restoring an older model may depend on compatible preprocessing, interfaces, and runtime components. A model checksum helps establish which file was used. It cannot establish that the surrounding pipeline was correct. The strongest product would make the deployed device reconstructable enough to investigate, rather than leaving quality staff to assemble its history from tickets, messages, and several people’s memories.
The customer and the unit economics
The initial customer is likely to be a medical device manufacturer with a concrete release problem. Regulatory affairs may support the purchase because the evidence must fit the authorized plan. Quality may care about traceability and controlled execution. Clinical validation may own the study budget, while engineering owns the systems that must supply the records. These functions can support the same purchase for different reasons, which makes ownership important. A small developer preparing its first authorization may need substantial help but have little recurring volume. An established sponsor with several products, active installations, and repeated updates may offer a better starting point. The useful qualification question is how the next release will be evaluated and who is responsible for getting that work finished.
The economics should be modeled with uncomfortable specificity. Suppose, purely for illustration, that a manufacturer performs four substantial updates annually. Each consumes four hundred hours of internal work at a fully loaded cost of one hundred fifty dollars per hour. That implies two hundred forty thousand dollars of annual labor. A platform priced at one hundred fifty thousand dollars that removes one quarter of those hours saves only sixty thousand dollars in labor. It still needs ninety thousand dollars of additional defensible value before implementation costs enter the calculation. Faster releases might supply that value, but only when the software actually removes a critical delay and the earlier release has economic consequences. A generic claim that every saved week equals another week of revenue is the sort of arithmetic a finance team will inspect closely.
Clinical data and expert review costs also do not disappear because the documentation becomes easier. A vendor should separate work it eliminates, work it accelerates, and work it helps procure. A useful initial engagement could reconstruct a recently completed release, identify the steps that consumed time, and then support a defined upcoming update. Pricing might follow active device programs and the scope of recurring services, with substantial data acquisition and expert evaluation priced separately. Per-seat pricing could discourage the cross-functional participation that gives the system value. Whatever the model, the first renewal should rest on completed releases and documented savings. “Preparing for the future of AI regulation” is a difficult line item to defend when the customer is cutting its operating budget.
Where a defensible business could emerge
A software business could start with a narrow workflow such as assembling release evidence for a particular class of imaging or physiological signal products. Specialization would make it easier to understand the relevant inputs, metrics, failure modes, and existing systems. The risk is that a quality management vendor or model infrastructure provider adds similar functionality. To earn a durable position, the product would need to handle difficult connections between clinical evidence and the authorized release process, with less reconciliation work than customers can achieve themselves. Historical records can create switching costs, but customers should still be able to export them. Trapping essential evidence in proprietary formats would make a regulated buyer more nervous about the supplier, which is not a great sales strategy.
An independent evaluation business could combine statisticians, clinical reviewers, data operations, and software to execute recurring studies. Its revenue may be predictable even if much of the work remains services. The important operational question is whether the second and third releases require less setup without weakening independence or clinical rigor. Reusable integration, established reviewer networks, and consistent study execution could improve margins. Every product still brings specific scientific questions, so investors should inspect how much delivery remains bespoke. This could suit a profitable specialist firm or a healthcare services acquisition strategy. Calling the entire operation software does not change the staffing schedule. The business should be valued according to what customers buy and what it costs to deliver.
A data and evaluation network offers another possibility. Its advantage would come from repeatedly locating suitable patients, coordinating access, and producing evidence with enough provenance to support the sponsor’s decisions. Building that network requires institutional relationships and reliable operations. Buying a consulting firm could supply expertise and customer access, while partnering with clinical sites could supply cases and adjudication. Those choices need diligence on agreements, permitted uses, reviewer capacity, and dependence on individual relationships. A combined company would also need to preserve appropriate separation between helping improve a model and evaluating its performance. The commercially useful network effect is better coverage and faster execution under controlled conditions. It should never depend on quietly recycling a customer’s validation data into somebody else’s development program.
What investors should ask to see
Market sizing should begin with purchasing organizations and recurring programs. Device authorization records are useful research inputs, but multiple records can belong to the same sponsor, and an authorized plan does not establish how often it has been used. For an illustrative market model, two hundred paying manufacturers at an annual contract value of one hundred twenty-five thousand dollars would produce twenty-five million dollars in recurring revenue before services. Those assumptions would require validation. They nevertheless force a useful discussion about the number of reachable accounts, likely penetration, and the expansion opportunity inside each sponsor. A company could become a strong business at that scale. A much larger venture case would need evidence of broader spending, additional workflows, or substantially greater revenue per customer.
Investors should then examine release histories. How many customers have used the product for more than one completed update? What proportion of the evidence was generated automatically, and what still required manual reconstruction? Did the product reduce elapsed time, internal effort, or external spending? What happened when a candidate failed? A credible system should help stop an unsuitable release and preserve the reason, even when that makes the customer’s quarterly product presentation less cheerful. Retention based on continuing operational use is stronger evidence than contracts kept alive because nobody has migrated the documents. Expansion into additional devices is also more persuasive when it follows successful releases instead of a discounted enterprise agreement signed before implementation.
The diligence should become particularly concrete when products depend on third-party foundation models or other externally managed components. A sponsor needs enough control and information to understand what was evaluated and what is deployed. A supplier that changes underlying behavior without a usable version history can make that difficult. The evidence vendor’s response should be visible in its architecture and contracts, including how it handles dependency changes and missing information. Before underwriting the business, an investor could ask it to replay a customer’s completed update from proposal through deployment. The team should be able to show the applicable plan, the test population, the results, the release decision, and the installations affected. Then ask it to do the same for a failed candidate. That second demonstration may reveal more about the product than the entire sales deck.
