SaMD Startup: Design Controls, Agile Sprints and an Unqualified Cloud Supplier
You are advising a nine-person software-as-a-medical-device (SaMD) startup that expects an ISO 13485 certification audit in 10 weeks. Its product is a Class IIa ECG interpretation application; a 510(k) is pending. The design history file contains user needs but no traceable design inputs, no risk management file aligned with ISO 14971, and no documented software configuration management. Developers use Git branches informally and cannot identify the exact software version in released builds. The cloud infrastructure provider is not on the approved supplier list, and the CI/CD pipeline has never been validated. Management review has been held once, with a sales update as the only input. The complaint procedure mentions customer satisfaction but not reporting to regulatory authorities. The CEO asks whether the company can exclude clause 7.3 design and development because it works in agile sprints.
1. Can the company exclude ISO 13485 clause 7.3 design and development because it uses agile sprints? Justify your answer.
Read the worked answer
No. ISO 13485:2016 permits exclusion of 7.3 only when the organization can justify it because the product is not designed by the organization and applicable regulatory requirements do not require design controls. A startup that owns the SaMD design, even in agile sprints, is performing design and development. Agile is a development method, not a basis for exclusion. The design history file already contains user needs, which is design activity. If the company claimed exclusion while continuing to design, the scope statement and the audit evidence would contradict each other. The correct approach is to apply 7.3 in a scalable way: design planning, inputs, outputs, review, verification, validation, transfer, and design changes. Because a 510(k) is pending, US design control requirements also apply. The company should document a justification only if it truly does not design, which is not the case here. Exclusion would create a major certification risk and undermine the regulatory submission.
2. Identify the top gaps and propose a defensible sequence of remediation before the certification audit.
Read the worked answer
Prioritize by risk to patient safety and audit impact. First, establish a risk management file under 7.1 and ISO 14971: identify hazardous situations, risk controls and residual risk. Second, build traceability from user needs to design inputs, outputs, verification and validation under 7.3; define the released software version and configuration management. Third, qualify the cloud provider under 7.4.1 and validate the CI/CD pipeline under 4.1.6 and 7.5.6. Fourth, correct complaint handling and 8.2.3 regulatory reporting. Fifth, strengthen management review under 5.6 with required inputs such as complaints, CAPA, regulatory changes and risk. A realistic 10-week sequence is risk file and design traceability in weeks 1-4, supplier and software validation in weeks 3-6, complaint and management review in weeks 5-7, then internal audit and CAPA before the certification audit. Do not write procedures first and evidence later; the audit will sample records.
3. What should be done about the cloud infrastructure provider and the unvalidated CI/CD pipeline?
Read the worked answer
The cloud provider is a critical supplier because it hosts the SaMD and may affect availability, security and data integrity. Under 7.4.1, add it to the approved supplier list after a risk-based evaluation: security certifications, service level agreements, breach notification, data location, backup and disaster recovery, and right to audit. A quality agreement should define change notification and incident reporting. Under 4.1.6, validate software used in the quality management system, including the CI/CD pipeline where it affects product verification, release and configuration control. Validation should be proportionate: define intended use, test scripts, acceptance criteria, results and a conclusion. Record the exact software version of each released build. If the pipeline has never been validated, perform retrospective validation for releases already shipped and prospective validation before the next release. Link these activities to risk management and design controls, because a build error could affect the ECG interpretation algorithm.