What you will learn
By the end of this topic, you should be able to identify configuration items, establish baselines, maintain configuration status, run an evidence-based change process, assess regulatory and lifecycle impact, and control implementation across production and the installed base.
Configuration control makes the evidence meaningful
A test report is useful only when the tested product, software, requirements, method and acceptance criteria are known. A complaint investigation is useful only when the fielded configuration can be reconstructed. Configuration management preserves these relationships as the device evolves.
At every consequential decision, be able to state what configuration is proposed, built, tested, released and present in the field.
Identify the items that define the product and its evidence
Product
Hardware, components, materials, software, firmware, accessories and consumables.
Definition
Requirements, architecture, drawings, bills of material, specifications and code.
Production
Processes, tooling, equipment, recipes, work instructions and test software.
Information
Labels, instructions, translations, training, service and promotional claims.
Evidence
Risk files, reviews, verification, validation, clinical and regulatory records.
External items
Supplier parts, SOUP, libraries, cloud services, standards and reference data.
Assign identifiers and revisions at a level that supports decisions. Excessively coarse control hides differences; unnecessary granularity creates administration without clarity.
Establish baselines and maintain configuration status
A baseline is an approved set of configuration items used as a stable reference for further work. Typical baselines may cover design inputs, architecture, verification configuration, production release and market-specific product versions.
Configuration status accounting should answer which version exists, where it is used, what evidence supports it and which changes are pending or implemented.
Begin every change with a defined need
Describe the problem or opportunity, affected products and urgency. Identify the source—complaint, obsolescence, vulnerability, supplier change, cost, corrective action, regulation or improvement—and distinguish temporary deviation from permanent change.
- State the current and proposed configuration clearly.
- Record why the change is needed and what success means.
- Identify affected variants, markets, lots and fielded devices.
- Assign an accountable owner and cross-functional reviewers.
- Define containment if action is needed before the permanent solution.
- Link the request to complaints, CAPA, risk or supplier records.
Assess impact across the complete evidence system
A local component or code change can affect interfaces, hazards, usability, manufacturing, cybersecurity, clinical claims, labelling, service and regulatory status. Use a structured assessment rather than relying on the originating function.
- Intended purpose, claims, users, use environment and essential performance.
- System architecture, interfaces, requirements and dependent components.
- Safety, cybersecurity, privacy and usability risks.
- Verification, validation, reliability and clinical or performance evidence.
- Materials, biocompatibility, sterilisation, packaging and shelf life.
- Processes, suppliers, tooling, test methods and production validation.
- Labels, instructions, UDI, registrations and technical documentation.
- Regulatory submissions, notifications, approvals and certificates.
- Existing inventory, service parts, field updates and mixed configurations.
Document market-specific regulatory conclusions before implementation. For US devices, the type and impact of a change may determine whether a new premarket submission is required.
Approve evidence before controlled implementation
Define the changed outputs and required verification or validation before executing confirmatory work. Review results, deviations, residual risks and regulatory actions, then approve the exact release configuration.
Implementation planning should cover supplier cut-in, stock disposition, production instructions, software deployment, labels, training, service information and effective date. Preserve the previous baseline and make rollback possible where appropriate.
Use MTL-109 — Design Transfer when a change alters the production system or receiving site.
Know what is installed in the field
Serialisation, software version reporting, service records and distribution traceability should allow the organisation to identify affected devices. Connected products may have hardware, embedded software, application, cloud and configuration versions that change independently.
Define compatibility rules, supported combinations, update sequence, migration, failed-update recovery and evidence needed after deployment. When only some fielded units are updated, risk and support decisions must address the resulting population of configurations.
Scale governance to consequence and urgency
Not every typographical correction needs the same review as a safety-critical software change, but every change needs appropriate control. Define categories, required reviewers, approval authorities and emergency routes without allowing urgency to erase documentation.
Periodically review open changes, ageing deviations, obsolete baselines, unsupported components and field configuration. Configuration audits can confirm that records, physical product and released evidence agree.
Common misconceptions
“Version control is configuration management.”
It controls revisions of selected files; configuration management also controls baselines, product relationships, release status and fielded combinations.
“A like-for-like replacement needs no assessment.”
Equivalence must be demonstrated for the characteristics and risks that matter to the device.
“A passed regression test approves the change.”
Testing is one part of the evidence. Risk, clinical, production, labelling and regulatory consequences also require closure.
Authoritative external references
- ISO 13485:2016 — Medical devices — Quality management systems
- FDA — Deciding When to Submit a 510(k) for a Change to an Existing Device
- FDA — Deciding When to Submit a 510(k) for a Software Change
- Regulation (EU) 2017/745 on medical devices
Use current market-specific change guidance and involve the relevant conformity-assessment body or regulator where required.
A controlled change preserves a coherent product and evidence chain
Identify the baseline, assess every affected lifecycle element, approve the necessary evidence and know exactly where the changed configuration is used.