Who We Serve: Technology
Software as a Medical Device and AI-Enabled Devices
Software teams release on a cadence most quality systems were never designed for. The gap usually is not the engineering. It is that the evidence lives in tickets, pull requests and pipelines rather than in the QMS, and we help software and AI-enabled device makers connect the two.
Standards and Regulations to Know
- IEC 62304Medical Device Software Lifecycle Processes
- IEC 82304-1Safety of Health Software Products
- IEC 81001-5-1Security Activities in the Health Software Lifecycle
- IEC 62366-1Usability Engineering for Medical Devices
- ISO 14971Risk Management for Medical Devices
- ISO 13485Quality Management Systems for Medical Devices
- 21 CFR Part 820 (QMSR)Quality Management System Regulation
- ISO/IEC 42001Artificial Intelligence Management Systems
Typical Regulatory Exposure
Software as a medical device, and software in a medical device, sit under the same quality system requirements as hardware, with standards that describe good software practice. IEC 62304 covers software lifecycle processes, IEC 82304-1 covers health software products as a whole, IEC 81001-5-1 covers security activities across the health software lifecycle, IEC 62366-1 covers usability engineering, and ISO 14971 frames the risk management that ties them together.
Cybersecurity is both a premarket and a postmarket concern. For cyber devices, section 524B of the FD&C Act requires premarket submissions to include a software bill of materials, a plan to monitor and address postmarket vulnerabilities, and a process for security updates, and FDA investigators can review them. Every release, including a security patch, is a design change that needs to be evaluated and recorded.
AI-enabled devices add questions about the data and the model. Auditors look for how training and test data were sourced, curated and kept independent, how model performance is verified and monitored after release, and how retraining is controlled. FDA has described predetermined change control plans as one way to plan certain model changes in advance; whether one fits depends on your device and your submission strategy.
Where Audits Find Gaps
- 01
Release Records That Live Only in Tooling
Builds, test runs and approvals exist in the CI pipeline and issue tracker, but the QMS has no controlled record tying a released version to its verification and its risk review.
- 02
Third-Party Software Untracked
Open-source libraries and off-the-shelf components are not listed with versions and known anomalies, and there is no process for monitoring their vulnerabilities.
- 03
Change Impact Not Assessed per Release
Frequent releases go out without a documented assessment of whether each change affects safety, effectiveness or the claims in the cleared or approved labeling.
- 04
Complaints Hidden in Support Channels
App store reviews, support tickets and in-app feedback contain complaints that never reach the complaint handling process or a reportability decision.
- 05
Training Data Without Provenance
For AI-enabled functions, the firm cannot show where training and test data came from, how they were labeled, or that the test set was kept separate from development.
- 06
No Postmarket Performance Monitoring
Algorithm performance is verified at release and then not watched, so drift in real-world inputs would go unnoticed until it showed up as complaints.
Relevant Standards and Regulations
- IEC 62304Medical Device Software Lifecycle Processes
- IEC 82304-1Safety of Health Software Products
- IEC 81001-5-1Security Activities in the Health Software Lifecycle
- IEC 62366-1Usability Engineering for Medical Devices
- ISO 14971Risk Management for Medical Devices
- ISO 13485Quality Management Systems for Medical Devices
- 21 CFR Part 820 (QMSR)Quality Management System Regulation
- ISO/IEC 42001Artificial Intelligence Management Systems
Relevant Services
Software Validation and Device Software (CSV, IEC 62304)
Validate software used in production and the QMS, and build device software on an IEC 62304 lifecycle.
AI-Assisted QMS Gap Assessment
An AI-assisted first pass over the QMS documents you already have, with every result reviewed by an advisor.
Submission Readiness (510(k), De Novo, PMA, Pre-Sub, 513(g))
The design, risk and V&V evidence behind a 510(k), De Novo or PMA, organized and gap-checked.
FDA Inspection Readiness (CP 7382.850)
FDA device inspection preparation built around Compliance Program 7382.850 and its risk-based approach.
Ongoing Advisory and Continuous Readiness
Periodic re-assessments, a live action plan and yearly mock inspections that keep readiness from decaying.
Audits and Inspections You May Face
FDA Baseline Surveillance Inspection
FDA's comprehensive surveillance inspection of your quality system under Compliance Program 7382.850.
ISO 13485 Surveillance Audit
The periodic audits, at least annually, that support continued ISO 13485 certification between renewals.
EU Notified Body Audit (Including Unannounced Audits)
Conformity assessment, surveillance and unannounced audits by an EU notified body under the MDR or IVDR.
Questions
Can we keep using our engineering tools as the system of record?
Often, yes. The QMS needs controlled, retrievable evidence, not a particular tool. The usual fix is to define which tool records which activity and how a released version is tied to its approvals, then show that the tools you rely on for quality records are validated for that use.
Is every software release a design change?
Every release changes the design, so each one needs a recorded evaluation. The depth of that evaluation can scale with the change: a minor fix and a new algorithm should not need the same paperwork, but both need a decision someone can find later.
What do auditors want to see for an AI-enabled function?
Typically the intended use and its limits, how data were collected and managed, how the model was verified against independent data, and how its performance is monitored after release. Expect questions about how retraining and model updates pass through your change process.
Do you review our cybersecurity documentation?
We review it as part of the quality system: whether threat modeling, the software bill of materials, vulnerability handling and security updates are defined in procedures and backed by records. We do not perform penetration testing.
Software as a Medical Device and AI-Enabled Devices
Get an Advisor's View of Your Quality System
Tell us about your devices and the audit or inspection ahead, and an advisor will scope an assessment for your kind of product. Please don't send confidential documents yet: secure upload is set up after onboarding.
