After clearance, every software release goes through change control with a documented regulatory assessment, verification scaled to the change, updated labeling and an updated SBOM. Model retraining or new input sources are allowed without a new submission only when an authorized PCCP covers them and the modification protocol is followed exactly. Engineering also collects field data such as logs, failures, complaints and performance on new sites, so drift or new failure modes are caught and fed back into risk management.
On the map: Releases under change control. Retrain under the PCCP. Monitor real-world performance.
Rows are disciplines, columns are stages 1 to 8. Select a square to open that task.
Back to the full map
Bring every planned change to regulatory for a letter-to-file or 510(k) call before coding. Keep cybersecurity's SBOM monitoring tied to each release.
Each release is classed as major, minor or patch. The team walks the FDA software change guidance flowcharts and records the answer at every decision point in a note to file in the design history file. Changes that affect safety, effectiveness or the indications go to a new submission. Bug fixes and cybersecurity patches are documented as a regulatory assessment.
Only if the PCCP was in the original submission and lists that specific modification with its protocol, reference standard and acceptance criteria. A retrained model that cannot follow the protocol, for example because the reference standard changed, needs a new submission. A device cleared without a PCCP treats retraining as an ordinary change assessment.
The team picks signals the deployment can actually produce: run failures and rejected series from logs, complaint and feedback trends, MAUDE review, and periodic spot checks against new reference reads where data access allows. Thresholds that trigger an investigation are written into the post-production plan.
See the open positions and apply.