Costa Rica MedTech

Who this article is for

This article is for MedTech project managers, product managers, software leads, QA/RA, systems engineers, cybersecurity leads, and supplier-quality partners working with regulated software, SaMD and SiMD, connected devices, or hybrid medical-device programs.

It is especially useful for teams trying to reconcile two pressures that often feel opposed:

• the need to move quickly through agile or hybrid delivery, and
• the need to preserve patient safety, regulatory compliance, quality-system evidence, and release control.

How to read this article

• Start with the operating model: change control as patient-safety governance.
• Then the conversion mechanism: Change → Evidence → Decision → Release.
• Then the running example: a cybersecurity library update that looks small but touches many evidence owners.
• Then the agile/hybrid layer: how backlog items, sprints, releases, and CCB decisions work together.
• Then the standards overlay: how PMI, IEC 62304, ISO 14971, FDA, IMDRF, AAMI TIR45, and the QMS reinforce the same operating model.
• If you implement only one pattern: adopt Change → Evidence → Decision → Release as your default workflow.

Change control as patient-safety governance

MedTech projects need change. Requirements evolve, clinical feedback reveals better workflows, cybersecurity vulnerabilities must be patched, suppliers change, algorithms improve, and post-market data teaches the organization what the product is really doing in the field.

In PMI language, the older Perform Integrated Change Control concept is now expressed in the PMBOK Guide, Eighth Edition largely through Assess and Implement Changes in the Governance Performance Domain. The terminology has evolved, but the underlying logic remains the same: proposed changes should be made visible, assessed across the whole project system, decided by the right authority, documented, communicated, implemented only if approved, and monitored afterward.

In MedTech, that PMI logic becomes sharper:

Change control is not bureaucracy for its own sake. It is patient-safety governance.

A requested change may look small when viewed by one stakeholder. A sponsor may see a supplier substitution as a sustainability improvement. A software engineer may see a dependency update as routine maintenance. A product owner may see a new workflow as a valuable feature. A cybersecurity team may see a patch as urgent.

But in a regulated medical product, each of these changes can affect safety, effectiveness, intended use, risk controls, verification evidence, validation evidence, labeling, clinical workflow, released configurations, or post-market obligations.

Therefore, the MedTech version of integrated change control asks:

If this change is accepted, what happens to patient safety, clinical performance, regulatory status, design controls, risk management, traceability, verification, validation, configuration, and released product integrity?

The North Star:
Change → Evidence → Decision → Release

Use this chain as the operating model for the rest of the article:

1. Change
   • Change signal – A request, defect, vulnerability, supplier change, complaint, post-market signal, or backlog item appears.
   • Impact analysis – The team evaluates safety, risk, regulatory, technical, schedule, cost, release, configuration, and post-market impact.
2. Evidence
   • Requirements, traceability, risk file, V&V, configuration records, cybersecurity documentation, labeling, regulatory assessment, or release records are updated as needed.
3. Decision
   • The right authority approves, rejects, defers, fast-tracks, or approves the change with conditions.
   • Controlled implementation – The team implements only the approved change under configuration and release controls.
4. Release
   • The change is verified, validated as needed, approved, deployed, and monitored.

My rule of thumb: if a change cannot be traced through the chain: Change → Evidence → Decision → Release, it is not yet under control.

A running example: a cybersecurity library update

Let’s consider one common example to use as running example throughout the article:

A SaMD team discovers that a third-party authentication library used in its cloud platform has a serious cybersecurity vulnerability. The software team wants to update the library in the next sprint. The product owner agrees because the patch protects users and preserves trust. Regulatory affairs asks whether the update affects released behavior. QA asks whether the changed library is part of the validated release configuration. Cybersecurity asks whether the SBOM and threat model must be updated. The project manager must coordinate the decision.

This example shows why MedTech change control cannot be reduced to either “just add it to the backlog” or “send everything to a heavy CCB.” The right level of control depends on impact.

The library update may be urgent and valuable, but it still raises integrated questions:

• Which released versions are affected?
• Does the change affect authentication behavior, session management, logging, encryption, or user access?
• Does it affect clinical workflow or availability?
• What regression testing is needed?
• Does the SBOM change?
• Does the vulnerability require customer communication or regulatory reporting?
• Does the patch need an expedited release pathway?
• What evidence is required before deployment?

This is the practical world where PMI, agile, IEC 62304, cybersecurity, regulatory affairs, and QMS controls meet.

One change, many stakeholders

A change request in MedTech is rarely owned by one function. The coding task may be small. The evidence system is not.

In the cybersecurity-library example, one change may touch:

• Cybersecurity: vulnerability severity, threat model, SBOM, monitoring, and security-risk rationale.
• Engineering: implementation, dependency impact, architecture, rollback feasibility, and regression scope.
• Risk owners: hazard impact, risk controls, residual risk, and risk-benefit rationale.
• V&V/Test: verification strategy, regression evidence, anomaly disposition, and test coverage.
• QA/RA: QMS records, release approval, regulatory impact assessment, and audit-ready rationale.
• Configuration/Release: version control, build reproducibility, deployment package, and released configuration history.
• Service/Support: customer communication, rollback instructions, support readiness, and monitoring runbooks.
• Postmarket/CAPA: complaint linkage, field-signal monitoring, effectiveness checks, and escalation rules.

That is why I treat change control as a stakeholder-and-evidence system, not just an engineering workflow.

Evidence Debt

In regulated software, late change does not only add coding work. It can invalidate evidence, either partially or completely. Evidence debt is the latent financial, operational, and regulatory liability that accumulates when a system’s engineering velocity outpaces its corresponding proof.

Evidence debt is broader than documentation debt. It appears when the product evolves faster than the evidence system that proves the product is safe, effective, usable, secure, compliant, and valuable. FDA design-control frames verification as objective evidence that design outputs meet design inputs, and validation as objective evidence that the device conforms to user needs and intended uses under defined conditions. When a change breaks those links, the team has not merely created paperwork cleanup; it has weakened the proof chain that supports release and regulatory confidence.

A late change may require:

That redo cost is evidence debt. It is not mainly engineering effort. It is coordination, re-review, re-verification, re-validation, and re-approval across the acceptance authorities who make the QMS real. Every time your team makes a change and does not perform a Change Impact Analysis, you are creating and accumulating evidence debt.

Why evidence debt compounds

Evidence debt compounds because MedTech evidence is interconnected. A software requirement may link to a risk control, a verification test, a validation rationale, a cybersecurity control, a configuration record, a regulatory assessment, and a release decision. When the product changes but only the code or backlog is updated, every downstream artifact becomes less trustworthy.

This matters because medical device development does not end with a prototype or a regulatory milestone. Development programs must plan for design verification, design validation, documentation, usability, safety, scalability, and regulatory requirements as the design matures. Market access and adoption also depend on clinical and economic evidence, not just regulatory clearance. The most important lesson you acquire while working in Medtech is that clinical validation, regulatory review, manufacturing scale-up, market adoption, and value demonstration are connected milestones rather than isolated tasks.

In practical terms, evidence debt grows when a team treats early evidence as disposable instead of architectural. A startup may optimize for a near-term regulatory conversation, investor milestone, or prototype demo, while postponing:

• a clear intended-use and claims strategy,
• clinical endpoints and evidence-generation assumptions,
• traceability from user needs to requirements and tests,
• risk-management-file discipline,
• cybersecurity and SOUP evidence,
• usability validation planning,
• payer, provider, or economic-value evidence,
• post-market data strategy.

Those shortcuts can look efficient early. Later, they become expensive because the team must reconstruct why decisions were made, repeat studies or tests, rework traceability, explain undocumented assumptions, or redesign evidence around a product that has already moved forward.

Evidence debt across the product life cycle

Evidence debt can appear at several levels:

1. Design-control debt
   • Requirements, design outputs, verification, validation, and DHF records no longer tell a coherent story.
   • The team cannot clearly show that the changed product still meets user needs, intended use, and design inputs.
2. Risk-management debt
   • Hazards, hazardous situations, risk controls, residual risk, and benefit-risk conclusions are not updated when the product changes.
   • A change is labeled “minor” because the code diff is small, even though the risk-control logic changed.
3. Software and configuration debt
   • Source code, dependencies, SOUP items, build outputs, test evidence, release notes, and configuration records drift apart.
   • The organization cannot reliably recreate what was built, tested, approved, released, or deployed.
4. Cybersecurity evidence debt
   • Threat models, vulnerability assessments, SBOMs, authentication behavior, logging, encryption, monitoring, or update mechanisms are not updated with the software change.
   • A security patch may reduce one risk while creating undocumented regression, availability, privacy, or interoperability questions.
5. Clinical and usability evidence debt
   • Workflow, user interface, claims, patient population, clinical performance, or use-error assumptions change without corresponding validation analysis.
   • The product may still work technically but no longer be supported by the original clinical or usability rationale.
6. Economic and adoption evidence debt
   • The product’s value story, workflow economics, resource utilization assumptions, reimbursement logic, or buyer evidence does not keep pace with the product.
   • This can delay adoption even after regulatory clearance because the evidence needed by payers, providers, or economic buyers is incomplete.
7. Post-market evidence debt
   • Post-market surveillance, complaint trends, real-world evidence, monitoring, or CAPA links are not designed into the change process.
   • Post-market clinical follow-up (PNCF) and real-world data are increasingly important for showing continued safety and performance after launch; if the data strategy is added late, the team may struggle to prove continued performance in normal use.

Running example:

In the authentication-library example, evidence debt appears if the team treats the patch as only an engineering dependency update. The actual change may require:

• updated SBOM,
• updated vulnerability rationale,
• regression evidence for authentication, session management, logging, and access control,
• updated threat model,
• configuration record updates,
• release notes,
• regulatory impact assessment,
• monitoring and rollback plan,
• customer or field communication assessment.

If those evidence updates are deferred, the team may deploy quickly but pay later during release review, audit, incident investigation, customer escalation, or regulatory questioning. The patch may be technically correct and still be evidence-incomplete.

Why MedTech change is different

MedTech change is different because the product is not only a deliverable; it is a regulated system used in or around healthcare decisions. Software may be a medical device by itself, part of a physical device, or part of a connected ecosystem involving cloud services, mobile apps, hospital systems, sensors, algorithms, and users.

A change can affect:

Impact area	Change-control question
Patient safety	Does the change introduce or modify a hazardous situation?
Clinical effectiveness	Does it alter diagnostic, therapeutic, monitoring, or decision-support performance?
Intended use and claims	Does it change what the product is intended to do or how it is marketed?
Regulatory status	Could it require a new submission, notification, technical file update, or documented no-submission rationale?
Risk management	Does it affect hazards, sequences of events, risk controls, residual risks, or benefit-risk conclusions?
Software safety classification	Does it affect the level of rigor required for the changed software item?
Requirements and traceability	Can the change be traced from user need to requirement, design, implementation, risk control, test evidence, and release?
Verification and validation	Are new tests, repeated tests, regression tests, simulated-use tests, or validation activities needed?
Cybersecurity	Does it affect threat models, authentication, encryption, logging, vulnerability management, SBOM assumptions, or update mechanisms?
Usability and human factors	Could it affect user workflow, alarms, labeling, training, critical tasks, or use error?
Supplier and component control	Does it affect supplier qualification, component specifications, inspection criteria, or purchasing controls?
Configuration and release management	Can the organization identify exactly what version was changed, built, tested, approved, released, and installed?
Post-market obligations	Does it connect to complaints, CAPA, adverse events, recalls, field safety corrective actions, or trend analysis?

This is what “integrated” means in a regulated product environment.

PMI’s integrated change-control idea

PMI’s core idea is that change should be managed as part of the whole project system, not as an isolated local decision.

In the PMBOK Guide, Eighth Edition, Assess and Implement Changes recognizes that changes can occur from project start through completion and may affect project scope, product scope, project management plan components, and project documents. The right amount of change management depends on scope, complexity, contracts, and development approach.

That is especially relevant in MedTech because change decisions are rarely only technical or only commercial. A software change may affect regulatory strategy. A regulatory change may affect schedule. A supplier change may affect verification. A cybersecurity patch may affect release planning. A user-interface change may affect usability validation. A risk-control change may affect architecture and regression testing.

PMI’s practical message is:

• Do not implement first and analyze later.
• Do not reject every change as scope creep.
• Do not accept a change simply because a senior stakeholder requested it.
• Do not let the technical team decide alone when safety, regulatory, or release implications exist.
• Do not let documentation become detached from what the product actually does.

Instead:

1. Capture the change
2. Analyze its impact
3. Involve the right experts
4. Decide through the defined authority
5. Update affected plans, baselines, documents, requirements, risks, and records
6. Implement only the approved change
7. Verify, validate, release, and monitor the result

PMI does not punish change. PMI punishes unmanaged change.

Standards overlay: how the main frameworks fit together

The operating model comes first: Change → Evidence → Decision → Release. The standards then explain what must be controlled, which evidence must exist, and who must approve or operate it. Each framework answers a different part of the same question.

Framework or source	Role in MedTech change control
PMI / PMBOK v8	Provides the governance mindset: assess change integratively, decide through defined authority, update plans and records, implement only approved changes.
IEC 62304	Provides the software life cycle discipline: planning, requirements, design, implementation, verification, release, maintenance, configuration management, and problem resolution.
ISO 14971	Provides the risk-management logic: identify hazards, evaluate risks, define controls, assess residual risk, and maintain the risk-management file.
FDA software change guidance	Supports regulatory decision-making for whether a software or firmware change may require a new submission or documented no-submission rationale.
IMDRF SaMD QMS guidance	Reinforces quality-management, configuration-management, change-management, and traceability expectations for SaMD.
AAMI TIR45 / agile MedTech guidance	Shows that agile practices can be used in medical-device software when iterations remain mapped to regulated life-cycle activities and evidence.
QMS / design controls	Converts project decisions into controlled records, approvals, release evidence, and audit-ready documentation.

A mature MedTech project combines these rather than treating them as competing approaches.

Translation into MedTech QMS language

In MedTech, PMI’s governance idea must be translated into the organization’s Quality Management System (QMS). A change request is not just a schedule or scope decision; it may require updates to controlled documents, design outputs, risk files, software documentation, verification protocols, validation reports, traceability matrices, supplier files, regulatory assessments, release records, complaint analysis, or post-market surveillance plans.

The project change process should connect to:

• Design controls
• Software life cycle processes
• Risk management
• Configuration management
• Document control
• Supplier quality management
• Verification and validation
• Regulatory affairs assessment
• Clinical and usability considerations
• Cybersecurity and data protection
• Release management
• Problem resolution
• Software maintenance
• CAPA and post-market monitoring

The project manager does not need to be the regulatory expert, software architect, clinical expert, cybersecurity lead, or quality leader. However, the project manager does need to integrate those perspectives so the change decision is complete, timely, and traceable.

In the running cybersecurity-library example, this means the project manager does not personally decide whether the patch requires regulatory action, whether regression testing is sufficient, or whether the vulnerability is reportable. Instead, the project manager ensures those decisions are made by the right experts and captured in the right records.

IEC 62304: software life cycle control

IEC 62304 is central to medical device software change control because it provides the software life cycle framework used to keep development and maintenance in a state of control. It applies to Software as a Medical Device (SaMD) and Software in a Medical Device (SiMD), and it covers planning, requirements, architecture, detailed design, implementation, integration, testing, release, maintenance, risk management, configuration management, and problem resolution.

For a project manager, the practical takeaway is:

A software change is not only a coding task. It is a controlled life cycle event.

The IEC 62304 is the de facto global standard for medical device software life cycle processes and that regulators expect evidence that software was developed and maintained in a controlled way. This strengthens PMI’s point: integrated change control is not merely a project governance preference; in medical device software it is part of the evidence trail that supports patient safety and regulatory confidence.

IEC 62304 enriches PMI’s integrated change-control logic in five important ways:

1. Risk-based rigor
   • IEC 62304 classifies software by potential harm from failure. Class A has the lowest safety impact, Class B can contribute to non-serious injury, and Class C can contribute to serious injury or death. A non-safety display text change and a change to an insulin-dosing algorithm should not receive the same level of review, evidence, or approval.
2. Traceability
   • Requirements, risk controls, design, implementation, and tests should be traceable. For change control, the team should be able to show which requirement changed, which risk control was affected, which design element changed, which tests were added or repeated, and which release contains the approved change.
3. Configuration management
   • Software artifacts such as source code, requirements, design records, test scripts, executables, documentation, build outputs, tools, libraries, and released configurations must be controlled. Without configuration control, the organization cannot reliably recreate a prior release, investigate field issues, perform regression analysis, or prove what was actually deployed.
4. Maintenance discipline
   • Post-release changes are part of the software maintenance process. Bug fixes, cybersecurity patches, enhancements, and field corrections still need risk analysis, implementation control, verification, and documentation. A maintenance change may move quickly, but it should not move invisibly.
5. Problem resolution
   • Software anomalies and problem reports require a formal process. Defects are not only development tasks; they are quality records that may require severity assessment, root-cause analysis, risk-file updates, verification of fixes, and closure evidence.

PMI gives the project governance logic; IEC 62304 and the QMS provide the regulated software execution discipline.

FDA and IMDRF: regulatory and SaMD quality expectations

FDA software change guidance is especially relevant because a software or firmware change to an existing device may require a new premarket notification, depending on the impact of the change. The project manager may not personally decide whether a new submission is required, but the project manager must ensure that the regulatory assessment happens before the change is released.

A medical device software change-control package should often include a documented regulatory impact assessment. The conclusion may be:

• A new submission is required before release.
• A new submission is not required, with documented justification.
• More analysis is needed.
• The change should be deferred, modified, or rejected.

IMDRF SaMD quality management guidance also supports the same logic. SaMD evolves through frequent updates, cybersecurity patches, model changes, user-interface changes, cloud or infrastructure changes, and interoperability updates. Even in an agile environment, SaMD needs systematic documentation, configuration management, change management, traceability, and the ability to recreate past versions.

In the running example, the authentication-library update may or may not require a regulatory submission. The important point is that the regulatory assessment should be explicit, documented, and completed before the patched version is released.

Agile and hybrid projects

Agile and hybrid delivery are especially relevant for MedTech software, SaMD, connected devices, digital therapeutics, and AI-enabled products because these products evolve through rapid feedback, frequent software increments, cybersecurity updates, interoperability changes, and post-market learning.

The challenge is that medical device teams cannot treat agility as permission to bypass design controls, risk management, configuration management, regulatory assessment, verification, validation, or release approval.

A strong MedTech agile process needs two operating rhythms at the same time:

1. Fast learning rhythm
   • Backlog refinement, sprint planning, prototypes, increments, demos, usability feedback, defect fixes, spikes, and technical discovery.
2. Controlled evidence rhythm
   • Requirements traceability, risk updates, software safety classification, architecture/design updates, verification, validation, configuration control, regulatory assessment, release approval, software maintenance records, problem-resolution records, and post-market monitoring.

The project manager’s job is to connect these rhythms so the team can move quickly without creating uncontrolled change. IEC 62304 supports this connection because it does not require a single waterfall model; it requires that the chosen life cycle be planned, documented, risk-based, traceable, and controlled. Agile sprints can therefore work in MedTech when each increment leaves behind the required evidence.

The important distinction is:

Level of done	Meaning	Typical evidence
Technically done	The team implemented the item and local acceptance criteria pass.	Code review, unit tests, story acceptance, local demo.
Evidence complete	The regulated evidence affected by the change is complete.	Traceability, risk updates, design updates, verification, validation, cybersecurity assessment, anomaly disposition.
Release approved	The change is approved for deployment under the QMS and regulatory strategy.	Release approval, configuration record, regulatory assessment, known anomalies, release notes, monitoring plan.

A backlog item may be technically complete in a sprint, but it is not necessarily ready for release until risk, traceability, verification, validation, cybersecurity, regulatory, configuration, and QMS expectations are satisfied.

Layered change-control model

A useful way to manage agile and hybrid MedTech change is to separate decision-making into layers. This prevents two common extremes:

• Treating every backlog change as a heavy formal CCB event, which destroys agility.
• Treating every backlog change as only a sprint-level decision, which creates regulatory and safety risk.

Layer	Typical cadence	Main change-control question	Evidence expected
Story	Days	Does this item change a requirement, risk control, interface, UI behavior, algorithm, cybersecurity control, or regulated claim?	Acceptance criteria, requirement link, risk link if applicable, unit or story-level test evidence.
Increment	1–4 weeks	Does the increment create integrated behavior that affects safety, effectiveness, usability, interoperability, cybersecurity, or performance?	Traceability updates, integration evidence, regression scope, risk updates, review records.
Release	One or more months	Can this version be released under the QMS and regulatory strategy?	V&V evidence, configuration record, known anomalies, release notes, cybersecurity assessment, regulatory impact assessment.
Product / project	Milestones or phases	Does the change affect business case, intended use, regulatory pathway, clinical evidence, manufacturing, supplier controls, service, or post-market obligations?	Design review outputs, change log, approved baselines, regulatory decision, risk-benefit rationale, launch readiness evidence.

The right approach is proportional control. Low-impact changes can move quickly through lightweight workflows. Safety, effectiveness, cybersecurity, labeling, intended-use, or regulatory-impacting changes need stronger review and approval.

Decision Rights

A common source of confusion in hybrid MedTech is the difference between prioritization and approval.

My rule of thumb is simple: the product owner can prioritize value, but the product owner alone should not approve changes that affect safety, effectiveness, intended use, regulatory status, controlled design outputs, released configurations, or post-market obligations. The agile team may decide how to implement a backlog item, but the agile team alone should not decide whether a regulated product change is releasable.

Decision rights should be explicit:

Decision area	Typical decision owner	Why it matters
Backlog priority	Product owner / product management	Balances customer value, business value, technical needs, and timing.
Technical implementation approach	Agile team / technical leads	Determines architecture, design, code, tests, and feasibility.
Risk impact	Risk owner, systems, clinical, software, QA	Determines whether hazards, risk controls, or residual risks change.
Regulatory impact	Regulatory affairs	Determines whether submission, notification, technical-file update, or no-submission rationale is needed.
QMS and design-control compliance	Quality assurance	Confirms required records, reviews, approvals, and controlled artifacts are complete.
Release approval	Defined release authority / CCB / quality-regulatory workflow	Confirms the change is safe, effective, verified, validated, documented, and approved for release.
Business or baseline tradeoff	Sponsor / governance board / CCB	Approves significant scope, schedule, cost, contract, supplier, or strategic changes.

This division preserves agility while preventing unsafe local decisions. Agile teams can move quickly within their authority, while patient-safety, regulatory, release, and business-impacting decisions receive integrated review.

Change control within Agile

Agile ceremonies can support regulated change control when each ceremony has a clear evidence purpose.

Agile ceremony	Change-control purpose in MedTech
Backlog refinement	Screen backlog items for regulated impact, affected requirements, risk links, SOUP, cybersecurity, V&V needs, and escalation triggers.
Sprint planning	Confirm Definition of Ready, expected evidence, dependencies, acceptance criteria, test approach, and whether QA/RA input is needed during the sprint.
Daily coordination	Surface blockers, unexpected impact, new risks, defects, or changes that require escalation.
Sprint review	Demonstrate technical progress and gather feedback; do not treat the demo itself as release approval.
Retrospective	Improve the workflow for evidence creation, traceability, defect handling, review timing, and cross-functional coordination.
Release readiness review	Confirm V&V evidence, risk updates, configuration record, cybersecurity assessment, regulatory assessment, unresolved anomalies, labeling, and release notes.
CCB / governance review	Approve, defer, or reject changes that affect baselines, safety, effectiveness, regulatory status, released configurations, business commitments, or launch readiness.

This prevents the common misconception that a sprint review equals approval to release. A sprint review shows progress. A release readiness review and defined approval workflow determine whether the change can be deployed.

Special cases

SOUP and third-party libraries

IEC 62304 environments often involve SOUP: Software of Unknown Provenance. This can include third-party libraries, open-source components, operating systems, cloud services, SDKs, drivers, AI models, or other externally developed software where the manufacturer does not fully control the development history.

A SOUP change-control review should ask:

• What SOUP item is being added, removed, replaced, or updated?
• What known defects, vulnerabilities, or limitations exist?
• Which software items and released configurations depend on it?
• Does it affect hazards, risk controls, cybersecurity, performance, interoperability, or clinical behavior?
• What verification or regression testing is needed?
• Does the change affect the SBOM, vulnerability monitoring, or supplier evaluation?
• Can the organization recreate the released configuration that used the prior SOUP version?

In the running example, the third-party authentication library is a SOUP item. Updating it may reduce cybersecurity risk, but the team still needs to understand dependency impact, regression scope, configuration history, and field-deployment implications.

Cybersecurity patches and expedited change control

Cybersecurity patches may need to move faster than ordinary release cycles, but urgency does not eliminate control. It changes the pathway.

An expedited change pathway should define:

• who can declare the change urgent,
• what minimum impact analysis is required before implementation,
• which QA/RA, cybersecurity, clinical, and release approvals are mandatory,
• what testing is required before release,
• what documentation may be completed after release and by when,
• whether customer communication, field action, or regulatory notification is needed,
• how rollback and post-release monitoring will work.

For the running authentication-library example, the team may use an expedited pathway if the vulnerability is severe. But the expedited path should still produce a defensible record: vulnerability rationale, impacted versions, risk assessment, regression evidence, SBOM update, release approval, deployment plan, and monitoring plan.

The goal is not to slow urgent updates. The goal is to make urgent updates safe, traceable, and defensible.

AI/ML model changes

AI/ML-enabled medical software creates additional change-control questions. A model update may not look like traditional code change, but it can affect clinical performance, bias, generalizability, explainability, and safety.

AI/ML change control should ask:

• Does the model change affect intended use, claims, patient population, clinical workflow, or decision support?
• Were training, tuning, and validation datasets controlled and representative?
• Does the model update affect sensitivity, specificity, false positives, false negatives, or clinical performance thresholds?
• Has bias or subgroup performance been assessed?
• Is performance drift being monitored?
• Is the change within an approved change protocol or predetermined change control plan?
• Does the change require regulatory review before release?

For AI/ML, change control must manage not only source code but also data, model version, training method, validation evidence, monitoring, and clinical risk.

Post-market corrections and CAPA-driven changes

Many critical MedTech changes happen after release. Complaints, adverse events, service reports, cybersecurity signals, trend analysis, audits, or CAPA investigations may trigger changes to software, labeling, manufacturing, suppliers, workflows, or risk controls.

Post-market change control should ensure:

• The field signal is evaluated for patient risk and regulatory reporting.
• The root cause is linked to the problem-resolution or CAPA process.
• The change is assessed for safety, effectiveness, regulatory impact, and installed-base impact.
• Verification, validation, regression, and release evidence are updated.
• Customers, regulators, service teams, or users are notified when required.
• Post-release monitoring confirms that the change solved the problem without introducing new unacceptable risks.

In MedTech, change control does not end at launch. Launch begins the maintenance and surveillance phase.

Practical workflow

A practical MedTech flow for integrated change control is:

1. Capture the request
   • Record the change request, defect, enhancement, supplier substitution, cybersecurity patch, backlog item, complaint-driven issue, or CAPA-driven need.
2. Classify the change
   • Determine whether it affects product design, software, manufacturing, labeling, supplier controls, cybersecurity, clinical workflow, post-market obligations, or regulatory commitments.
3. Triage the level of control
   • Decide whether the change can follow a lightweight backlog workflow, needs QA/RA review, requires CCB approval, affects a baseline, or requires regulatory assessment before release.
4. Perform integrated impact analysis
   • Assess scope, schedule, cost, quality, resources, requirements, risks, traceability, verification, validation, regulatory status, cybersecurity, usability, configuration, and patient safety.
5. Consult the right experts
   • Include quality, regulatory, software, systems, risk, cybersecurity, clinical, usability, supplier quality, manufacturing, service, and V&V experts as appropriate.
6. Decide through the approved authority
   • Use the product owner, CCB, sponsor, regulatory decision forum, or QMS approval workflow according to the change type and decision rights.
7. Update controlled artifacts
   • Update the change log, requirements, risk file, design documents, traceability matrix, verification plan, validation plan, regulatory assessment, cybersecurity records, project management plan, and release documentation as needed.
8. Implement only the approved change
   • Execute the change according to the approved plan and configuration controls.
9. Verify, validate, and release
   • Confirm that the change works as intended and does not introduce unacceptable risk.
10. Monitor after release
    • Watch complaints, support tickets, adverse events, cybersecurity signals, field data, performance metrics, and post-market surveillance outputs to confirm the change achieved its intended value.

MedTech project managers

PMI’s change-control logic becomes very strong when the scenario involves medical device software, SaMD, regulated products, component substitutions, safety concerns, defects, cybersecurity patches, or sponsor-requested changes.

A strong PMI-style response often sounds like:

• Document the change request.
• Assess the impact before acting.
• Follow the change management plan and QMS procedure.
• Involve regulatory, quality, risk, clinical, cybersecurity, supplier quality, and technical experts as needed.
• Determine whether the change affects baselines, safety, effectiveness, intended use, regulatory submissions, or released configurations.
• Use integrated change control or the approved backlog/change workflow.
• Update the change log, requirements traceability, risk file, verification plan, validation plan, and affected project documents after approval.
• Implement only approved changes.
• Continue planned work while the change is being analyzed, unless there is an approved safety or compliance reason to stop.

A weak response often sounds like:

• Implement first and document later.
• Accept the sponsor’s request without impact analysis.
• Reject the change automatically as scope creep.
• Let the software team decide alone.
• Treat a software change as minor because the code change is small.
• Skip regulatory assessment because the feature seems beneficial.
• Update the backlog but not the controlled design or risk documentation.
• Assume a supplier-provided “equivalent” component is acceptable without qualification and verification.

The MedTech PM mindset is:

Be open to change, but never let speed bypass safety, evidence, traceability, regulatory assessment, or controlled approval.

Key Takeaways

• Integrated change control translates to patient-safety governance in MedTech. It protects more than scope, schedule, and cost; it protects safety, effectiveness, regulatory compliance, product quality, and business value.
• PMI’s change-control logic translates into QMS-controlled execution. In PMBOK 8 language, the concept appears through Assess and Implement Changes in the Governance Performance Domain. In MedTech language, it becomes controlled change through design controls, IEC 62304 software life cycle processes, ISO 14971 risk management, configuration management, regulatory assessment, V&V, release control, maintenance, problem resolution, and post-market monitoring.
• The core operating model is Change → Evidence → Decision → Release. A change is not under control until it is visible, impact-assessed, evidenced, approved by the right authority, implemented under configuration control, verified or validated as needed, released, and monitored.
• Agility is valuable only when it remains traceable and releasable. Agile and hybrid teams can move quickly, but sprint/increment completion is not the same as release approval.
• The practical MedTech rule: adapt when change improves value, but never drift through unmanaged change that weakens safety, effectiveness, compliance, traceability, approval, or release readiness.

Definitions and acronyms

This article uses the following terms in a MedTech, SaMD, and regulated software context.

• AAMI TIR45: A technical information report on using agile practices in medical device software development while maintaining regulated life-cycle evidence.
• Agile / adaptive delivery: An iterative delivery approach that uses backlog refinement, sprints, increments, demos, and feedback loops. In MedTech, agile work must still produce controlled evidence before release.
• CAPA: Corrective and Preventive Action. A QMS process for investigating quality problems, identifying root causes, implementing corrections, and verifying effectiveness.
• CCB: Change Control Board. A defined decision-making group or governance forum that reviews and approves, rejects, defers, or conditions changes with significant impact.
• Change control: The process of making proposed changes visible, assessing their impact, approving or rejecting them through the right authority, implementing approved changes, and updating the affected evidence.
• Configuration management: The discipline of identifying, controlling, and being able to reproduce product versions, software items, documentation, build outputs, tools, dependencies, and released configurations.
• Controlled artifact: A QMS-controlled record or document, such as a requirement, risk file entry, design output, test protocol, validation report, traceability matrix, regulatory assessment, SBOM, or release record.
• Design controls: QMS controls used to ensure that medical device design and development outputs satisfy inputs, intended use, safety, effectiveness, verification, validation, and approval requirements.
• DHF: Design History File. The collection of records showing that a medical device was developed according to the approved design and development process.
• Evidence debt: The rework created when product or software changes move faster than the regulated evidence needed to support them, such as traceability, risk updates, V&V, cybersecurity records, regulatory assessment, and release approval.
• FDA: U.S. Food and Drug Administration. In this article, FDA guidance is referenced for software change and premarket-submission considerations.
• IEC 62304: International standard for medical device software life-cycle processes, including software development, maintenance, configuration management, risk-related software work, and problem resolution.
• IMDRF: International Medical Device Regulators Forum. In this article, IMDRF guidance is referenced for SaMD quality-management expectations.
• Integrated change control: PMI’s concept of assessing and managing change across the whole project system rather than treating changes as isolated local decisions.
• ISO 14971: International standard for medical device risk management, including hazard identification, risk evaluation, risk control, residual risk assessment, and risk-management-file maintenance.
• MedTech: Medical technology, including medical devices, connected devices, SaMD, software in medical devices, digital health products, and regulated healthcare technology.
• PMBOK: Project Management Body of Knowledge. PMI’s guide to project management principles, performance domains, and practices.
• PMI: Project Management Institute. The professional body associated with the PMBOK Guide and project management standards.
• QMS: Quality Management System. The organization’s controlled set of processes, procedures, responsibilities, records, and approvals used to ensure product quality and regulatory compliance.
• RA / QA: Regulatory Affairs / Quality Assurance. RA assesses regulatory implications; QA ensures QMS compliance, controlled records, approvals, and audit readiness.
• Release approval: The formal decision that a product version or software change is ready to be deployed under the QMS and regulatory strategy. Sprint completion alone is not release approval.
• SaMD: Software as a Medical Device. Software intended to be used for one or more medical purposes without being part of a hardware medical device.
• SBOM: Software Bill of Materials. A structured inventory of software components, dependencies, and versions used in a product or release.
• SiMD: Software in a Medical Device. Software that is part of, embedded in, or used to control a hardware medical device.
• SOUP: Software of Unknown Provenance. Externally developed software, such as third-party libraries, open-source components, operating systems, SDKs, cloud services, or drivers, where the manufacturer does not fully control the development history.
• Traceability: The ability to connect user needs, requirements, risks, design outputs, implementation, tests, approvals, and release records so the impact and evidence for a change can be followed end to end.
• V&V Verification and Validation. Verification confirms the product was built correctly against specified requirements; validation confirms the right product was built for intended users, uses, and environments.

References

• Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Eighth Edition.
• Project Management Academy. “How to Successfully Perform Integrated Change Control.” https://projectmanagementacademy.net/resources/blog/perform-integrated-change-control/
• Project Management Institute. “Integrated change management.” https://www.pmi.org/learning/library/integrated-change-management-5954
• ProjectManagement.com. “The role of the CCB.” https://www.projectmanagement.com/blog-post/71287/the-role-of-the-ccb
• U.S. Food and Drug Administration. “Deciding When to Submit a 510(k) for a Software Change to an Existing Device.” https://www.fda.gov/regulatory-information/search-fda-guidance-documents/deciding-when-submit-510k-software-change-existing-device
• U.S. Food and Drug Administration. “Content of Premarket Submissions for Device Software Functions.” https://www.fda.gov/regulatory-information/search-fda-guidance-documents/content-premarket-submissions-device-software-functions
• International Medical Device Regulators Forum. “Software as a Medical Device: Quality Management System.” https://www.imdrf.org/sites/default/files/docs/imdrf/final/technical/imdrf-tech-151002-samd-qms.pdf
• ISO. “IEC 62304:2006, Medical device software — Software life cycle processes.” https://www.iso.org/standard/38421.html
• Greenlight Guru. “AAMI TIR45: Closing the Gap Between Agile Software Development & Medical Device Regulations.” https://www.greenlight.guru/blog/aami-tir45
• Johner Institute. “TIR 45: Agile software development for medical devices.” https://blog.johner-institute.com/iec-62304-medical-software/tir-45-agile-software-development/
• Greenlight Guru. “Ultimate Guide to Agile Design and Development for Medical Devices.” https://www.greenlight.guru/blog/agile-design-development-medical-devices
• Orthogonal. “Agile in an FDA Regulated Environment.” https://orthogonal.io/insights/agile/ebook-agile-in-an-fda-regulated-environment/