Medical Device Milestone Management: How to Prove a Milestone Is Truly Complete

Key Takeaways

• Medical device milestones are complete only when a defined completion claim is supported by controlled, traceable, configuration-specific evidence.
• Milestone closure must connect evidence to design controls, risk management, verification, validation, design transfer, production readiness, and submission strategy.
• A defensible milestone decision can be reconstructed from records showing the claim, evidence, configuration, exceptions, risks, authority, and authorization.

A medical device milestone is not simply a project date, meeting, or set of tasks. It is a quality-system decision that authorizes a transition to a new technical, regulatory, manufacturing, or commercial state.

A milestone is complete only when valid evidence supports the defined claim, the claim applies to the correct product configuration, and the appropriate decision authority accepts the claim. Teams may finish testing and route documents without proving that the milestone itself is complete.

 

The Case Before the Organization

The case statement

This article proposes four review gates for evaluating whether an organization should authorize the next stage.

 

 

U.S. medical device manufacturers should connect milestone decisions to their quality management system and applicable design and development, risk management, verification, validation, transfer, production, and regulatory processes. The four-gate model described here is an internal governance framework, not an FDA-mandated structure.

 

The Milestone Claim Card

A milestone label should be converted into a precise, evidence-based claim.

Claim Elements

• State: What has been achieved?
• Configuration: What product version is covered?
• Evidence: What proves the claim?
• Exclusions: What remains outside scope?
• Authorization: What may proceed next?

Example: Verification Complete

Approved evidence shows that the defined design outputs satisfy applicable design inputs for the identified configuration. Deferred variants, unresolved changes, and excluded features remain outside scope.

Claim Rule

Milestone Label → Defined Claim → Supporting Evidence → Authorized Next Step

 

The Rules of Evidence

Teams should establish milestone criteria before they know the results. When teams define success after they have substantially completed testing or review, the standard can shift to fit the available evidence. Teams should therefore define entry criteria, exit criteria, required deliverables, approvers, permitted exceptions, and reopening triggers in advance.

Before evidence supports milestone closure, it should pass six tests.

Before evidence supports milestone closure, it should pass six tests.

• Relevance

Does the evidence directly support the milestone claim?

• Control

Are the version, approval status, owner, and authoritative location known?

• Configuration Fit

Does the evidence apply to the device, software, process, labeling, or manufacturing state being approved?

• Technical Validity

Are the method, sample, equipment, environment, execution, and analysis justified?

• Traceability

Is the evidence connected to applicable requirements, risks, controls, deviations, and conclusions?

• Sufficiency

Does the evidence resolve the decision without material unexplained gaps?

Proposed Closure Rule

Relevant + Controlled + Configuration-Fit + Technically Valid + Traceable + Sufficient = Admissible Evidence

Terms such as “substantially complete” or “documentation nearly final” should not support closure unless they are converted into objective, reviewable conditions.

 

The Milestone Case File

A milestone package should present a clear chain of evidence from execution to authorization.

File A: Source Evidence

Raw data, executed protocols, inspection results, software builds, manufacturing records, sample records, and configuration records.

File B: Evaluated Evidence

Approved reports, analyses, usability findings, cybersecurity assessments, validation reports, and performance conclusions.

File C: Traceability Record

Links between evidence, requirements, risks, and controls, deviations, and the approved configuration.

File D: Integrative Conclusion

A formal statement of what was proven, what remains outside scope, and whether the milestone claim is supported.

File E: Governance Record

Reviewers, approvers, rationale, conditions, open actions, and authorized downstream activity.

Proof Chain

Source Evidence → Evaluated Evidence → Traceability → Integrative Conclusion → Governance Decision

 

The Configuration Identity Record

Evidence supports only the configuration to which it applies. A test may be technically successful but fail to support closure if it uses an obsolete software build, a nonrepresentative hardware revision, alternate-supplier material, a prototype process, or outdated labeling. The milestone record should contain an explicit configuration identity covering relevant hardware, software, firmware, materials, suppliers, manufacturing process, packaging, sterilization status, labeling, accessories, interoperable systems, samples, test environment, and methods.

The applicability challenge

When teams apply evidence beyond the exact configuration they tested, reviewers should document what the teams tested, which configuration they propose to approve, how the configurations differ, why those differences do not invalidate the evidence, and whether those differences require additional testing.

 

The Risk Objection

Risk management should actively influence milestone closure. Teams should not update risk records after the gate merely to align them with a decision they have already made. They should review the current risk status when failures, anomalies, changes, or dependencies affect safety.

As a governance practice, organizations can authorize designated risk reviewers to challenge closure when the evidence does not support the documented risk conclusion. This control aims to reduce the likelihood of unsupported milestone decisions.

Grounds for a risk objection

A risk objection may be appropriate when a required control is not implemented, effectiveness is not demonstrated, residual risk is not accepted, a failure changes the risk profile, a new hazard emerges, dependencies change, or the tested configuration differs from the risk-assessed configuration.

The objection may be resolved through additional evidence, design modifications, a revised risk analysis, a narrowed scope, conditional authorization, or rejection of closure. A risk-based approach should calibrate rigor to consequence.

 

 

The Exception Ledger

Whether a milestone may close with open items depends on the organization’s predefined criteria, applicable procedures, and the significance of those items. Any open item should be classified and dispositioned based on its impact on the completion claim, risk, and permitted downstream activity. Treating unresolved technical uncertainty as administrative cleanup creates a false sense of closure.

Classifying Open Items by Closure Impact

The exception ledger should make clear whether an item blocks the decision, limits downstream activity, permits bounded follow-up, or has no effect on the technical conclusion.

Exception Classes

One possible internal classification model is:

1. Blocking exception

This contradicts or materially weakens the claim.

2. Conditionally blocking exception

This prevents full closure but allows restricted downstream work.

3. Nonblocking technical exception

This requires follow-up but does not invalidate the approved state.

4. Administrative exception

This does not affect the technical or regulatory conclusion.

Required Exception Details

Each exception should identify the issue, affected requirement or risk, affected configuration, rationale, owner, due date, permitted downstream work, and condition that would invalidate authorization.

 

The Milestone Closure Hearing

The gate review should serve as a decision forum, not the first point at which reviewers identify evidence gaps. Reviewers should identify major failures, incomplete reports, unstable baselines, or unresolved risk questions during pre-review. As a governance practice, the organization should avoid making the person accountable for the project schedule the sole authority for declaring the milestone complete. Schedule performance and evidence sufficiency are related but not the same responsibility.

The Decision Pipeline

Intake

The milestone owner assembles the case file. Evidence owners confirm the status, approval, and applicability of their records. Quality, Regulatory, technical reviewers, and functional experts identify gaps and disagreements.

Adjudication

The decision authority evaluates the claim, configuration, sufficiency of evidence, risk objections, exceptions, unresolved disagreements, and downstream authorization.

Record Lock

The organization records the verdict, rationale, conditions, dissenting views, authorized activities, follow-up obligations, and triggers for reopening.

 

The Closure Verdict

A binary complete-or-incomplete decision may not capture all of an organization’s permitted conditions or restrictions. The framework proposed here uses five possible levels of authorization.

Defining the Level of Authorization

1. Complete

The claim is fully supported.

2. Complete with Bounded Follow-Up

The claim is supported, but nonblocking actions remain controlled.

3. Conditional Authorization

The milestone is not complete, but limited downstream work may proceed under restrictions.

4. Not Complete

Evidence does not support the claim, or a blocking item remains unresolved.

5. Re-Baseline Required

The original scope, configuration, or evidence strategy is no longer valid.

 

Different Cases Require Different Proof

The same closure logic applies throughout the medical device lifecycle, but each milestone makes a different claim and therefore requires different evidence.

 

 

Document approval may be necessary, but it is not sufficient. Milestone completion depends on evidence that satisfies the technical acceptance criteria and supports the defined claim.

 

 

The Audit Replay Test

A milestone decision should withstand personnel turnover, restructuring, regulatory inspection, due diligence, and subsequent technical investigation. The test has two parts: whether the original decision can be reconstructed, and whether the organization knows when that decision must be revisited.

Part 1: Reconstruct the Decision

An independent reviewer should be able to reconstruct why the decision was reasonable based on evidence available at the time.

If the decision depends on memory, verbal explanation, or undocumented assumptions, the milestone was not closed under a durable control model.

Part 2: Reopen When Facts Change

A milestone may be considered complete upon approval, yet still require reopening if the facts supporting closure materially change.

Potential reopening triggers may include material changes to the design, supplier, manufacturing site, labeling, risk status, or cybersecurity posture; new performance, usability, or clinical evidence; regulatory feedback; data-integrity concerns; or discovery that tested units were not representative of the approved configuration.

Completion remains valid only while the underlying evidence, configuration, risk status, and assumptions remain valid.

 

Final Judgment: Completion Must Be Defensible

Medical device milestone management is not primarily about tracking dates, task completion, or percentage progress. It is the controlled process by which the organization determines whether enough valid evidence exists to authorize the next product or process state.

A milestone is truly complete when the organization defines its scope, identifies its configuration, satisfies its requirements, confirms the validity of its evidence, acceptably resolves or documents the disposition of its risks and exceptions, and maintains controlled records that allow reviewers to reconstruct the decision.

Closing a milestone without adequate evidence can carry unresolved uncertainty into later verification, validation, manufacturing, regulatory review, or commercial distribution. The organization should declare a milestone complete only when it can demonstrate that the evidence justifies moving forward.

 

 

Enlil Helps Turn Milestone Evidence Into Decision Readiness

At Enlil, we built our platform for the realities of MedTech development: milestone decisions depend on evidence that spans requirements, risks, design outputs, verification, validation, manufacturing readiness, and regulatory submissions. When disconnected tools fragment that evidence, teams lose time reconstructing the story and increase the risk of incomplete closure.

Enlil is a purpose-built MedTech development traceability platform and unified source of truth across the product development lifecycle. Our Agentic AI helps teams secure traceability and compliance while accelerating product development across PLM, QMS, ERP, MES, regulatory, and manufacturing workflows.

Because milestone closure spans multiple functions, Enlil supports the broader MedTech ecosystem, including OEMs, contract manufacturers, contract design and development organizations, and regulatory or compliance consultants. The platform helps teams connect configuration-specific evidence, risk disposition, exception management, and audit-ready traceability within a single controlled environment.

To make milestone decisions faster, smarter, and more defensible, explore Enlil’s unified development traceability platform for MedTech OEMs and see how it can strengthen your next product development program. Download the product information sheet to learn more about Enlil’s Milestone View capabilities.