Pre-production brief
| Field | Definition |
|---|---|
| Role | Founder, product lead, or first RA/QA owner of an AI-enabled device software function. |
| Scenario | The model looks strong, but the submission story is missing planned-change, data, software, and CDS boundary evidence. |
| Concrete problem | The team is treating AI performance as the story instead of preparing the evidence FDA guidance asks reviewers to examine. |
| Useful output | A PCCP-scope worksheet, AI lifecycle evidence map, CDS boundary prompts, software documentation checklist, and open reviewer questions. |
| TrueMedDevice role | Organize public FDA source material and evidence gaps without deciding device status, pathway, clearance likelihood, or PCCP adequacy. |
PCCP is about planned modifications, not AI branding
FDA's final PCCP guidance is about planned modifications for AI-enabled device software functions. A useful founder packet therefore starts by asking what the team intends to change after authorization, what methodology would govern those changes, and how impact would be assessed.
The article should not say every AI-enabled device automatically needs the same PCCP. It should separate locked-function assumptions, planned modifications, model lifecycle evidence, and open questions for qualified review.
AI lifecycle evidence belongs beside the PCCP question
FDA's draft AI lifecycle guidance points teams toward a broader evidence story: model development, data management, performance evaluation, risk management, transparency, and postmarket monitoring across the product lifecycle.
For a founder, that means the first deliverable should be an evidence map. The map should show what the team can prove today, what is assumed, and which claims need review before a submission plan or sales story is built around the model.
| Evidence area | Review question |
|---|---|
| Training data | Where did the data come from, and what populations, settings, devices, or labels may be underrepresented? |
| Validation | What performance evidence matches the intended use and user workflow? |
| Change control | Which future changes are planned, and which changes would fall outside the plan? |
| Monitoring | How will the team detect drift, user confusion, performance degradation, or safety signals? |
| Transparency | What does the user need to understand about the output, limits, and human review role? |
CDS status must be checked with current guidance
Clinical Decision Support (CDS) status is not a label the marketing team can assign. FDA's current final CDS guidance should be used to map each function, especially whether it is intended for a health care professional, what medical information it uses, and whether the user can independently review the basis for the recommendation.
If the software gives patient-specific recommendations, hides the basis for the output, or is used by patients rather than health care professionals, the packet should flag that as a review question instead of calling it Non-Device CDS.
Do not invent delay or cost certainty
AI-enabled software can add evidence work, but a public article should not state guaranteed months of delay, guaranteed Additional Information requests, or precise consultant costs without a source. Those claims become decisions dressed up as facts.
A safer packet names the work areas that may affect schedule: data provenance, validation design, software documentation, risk analysis, cybersecurity, PCCP scope, labeling, and postmarket monitoring. The schedule and budget should be set by the team and qualified advisors.
What TrueMedDevice can prepare
TrueMedDevice can prepare a source-backed AI-enabled device software review packet: intended-use map, AI lifecycle evidence table, PCCP-scope worksheet, CDS boundary prompts, software documentation checklist, cybersecurity cross-link, source ledger, and consultant handoff questions.
Source ledger
What it can tell you
FDA's final guidance recommendations for PCCPs tailored to AI-enabled device software functions and planned modifications.
What it cannot decide
Whether a PCCP is appropriate, sufficient, or acceptable for a specific device.
What it can tell you
FDA's draft recommendations for AI-enabled device software lifecycle and marketing-submission information.
What it cannot decide
Final FDA requirements or the adequacy of a specific AI lifecycle package.
What it can tell you
FDA's current final guidance on CDS software and the Non-Device CDS criteria.
What it cannot decide
Whether a specific software function is Non-Device CDS or a regulated device function.
What it can tell you
FDA's recommendations for software documentation in premarket submissions.
What it cannot decide
The final documentation level or adequacy of a specific submission.
What it can tell you
FDA's current digital-health guidance list and issue dates, including CDS and PCCP guidance status.
What it cannot decide
Which guidance controls the answer for a specific product feature.
What it can tell you
Current device submission fee tables for planning context.
What it cannot decide
The submission path, eligibility for reduced fees, or product-specific review timing.
Frequently asked questions
Is a PCCP required for every AI-enabled medical device?
No. The current FDA PCCP guidance is tied to planned modifications for AI-enabled device software functions. Whether a PCCP is appropriate for a product is a qualified review question.
Does strong model performance make a 510(k) easier?
Not by itself. FDA review can involve intended use, software documentation, risk controls, data evidence, change management, labeling, and predicate or pathway questions, depending on the product.
Can this page decide whether my software is Non-Device CDS?
No. It can help map the current CDS criteria and preserve open questions for qualified review; it does not determine device status.
Need an AI-enabled device evidence packet before submission planning?
TrueMedDevice can organize your intended-use, AI lifecycle, PCCP, CDS, software, cybersecurity, and source-ledger questions into one consultant-ready packet.