Development planning
Activities, deliverables, responsibilities, interfaces, reviews, configuration, suppliers, milestones and controlled updates.
Medical device quality and regulatory engineering
Build quality and regulatory evidence into the engineering program.
Outer Reef helps product teams connect intended use, design controls, risk, technical documentation, verification and manufacturing transfer around the actual device and target markets.
- Design and development planning
- Risk and traceability
- Verification and validation evidence
- Transfer and lifecycle controls
Start with product-specific obligations
The device, intended use and markets determine the evidence plan.
A credible quality and regulatory program begins with the manufacturer, product definition, risk, market strategy and applicable requirements. Templates become useful only after those inputs are understood.
Outer Reef's engineering support does not replace the manufacturer's regulatory authority, quality-system ownership, legal counsel, notified body or regulator. Responsibilities should be explicit in the project plan.
- 01
Device and intended use
Users, patient population, use environment, indications, claims, operating principle, accessories and product boundaries.
- 02
Markets and pathway
Target jurisdictions, product classification, predicate or conformity strategy, submission timing and external review needs.
- 03
Manufacturer and quality system
Legal manufacturer, specification developer, sites, suppliers, procedures, records, authorities and existing certifications.
- 04
Technology and architecture
Mechanical, electrical, software, materials, sterile barriers, accessories, interfaces and manufacturing processes.
- 05
Risk and clinical context
Hazards, use-related risk, benefit-risk inputs, clinical evidence, standards and risk controls that require design evidence.
- 06
Current records and gaps
Requirements, plans, reviews, traceability, risk files, test evidence, changes, supplier controls and open observations.
Evidence architecture
Connect product decisions to controlled records and objective evidence.
Design controls work when requirements, risk controls, outputs, reviews, verification, validation, transfer and change remain connected as the device evolves.
- 1
Establish context
Define manufacturer roles, device, intended use, markets, pathway assumptions and applicable quality-system scope.
Regulatory and quality context - 2
Plan controls
Define development activities, responsibilities, reviews, deliverables, traceability, configuration and evidence strategy.
Controlled development plan - 3
Develop traceably
Maintain requirements, risk controls, design outputs, software, supplier inputs and changes in a connected baseline.
Design and risk records - 4
Verify and validate
Use approved methods, representative configurations and predefined acceptance criteria to build objective evidence.
Reviewed V&V evidence - 5
Transfer and sustain
Connect released design to production controls, postmarket inputs, nonconformance, corrective action and controlled change.
Lifecycle evidence baseline
Quality and regulatory engineering scope
Make the technical file reflect the product that was actually built and tested.
The strongest records come from the engineering workflow. They should explain decisions, configurations, risks and evidence without reconstructing the program after development is complete.
Requirements and traceability
User and product needs translated into unambiguous, verifiable inputs linked to outputs, risk controls and evidence.
Risk-management integration
Hazards, hazardous situations, failure modes, risk controls, verification and residual-risk inputs maintained with design changes.
Design reviews
Planned, documented reviews with appropriate independence, clear decisions, open actions and controlled closure.
Verification and validation
Test strategy, methods, samples, configurations, acceptance criteria, deviations, results and traceable conclusions.
Software lifecycle evidence
Architecture, requirements, risk, configuration, reviews, implementation evidence, anomalies, tests and controlled release.
Explore medical softwareSupplier and process controls
Specifications, qualification needs, acceptance activities, changes, process evidence and records tied to product risk.
Technical documentation
Structured product, design, risk, performance, manufacturing and lifecycle evidence aligned to the target pathway and market.
Traceability that supports decisions
A document is useful when it explains what was required, built and proven.
Quality records should let a reviewer follow the product from intended use and requirements through risk controls, implementation, test configuration, results, deviations and release.
Decision areaQuestion to resolveUseful evidence
Design inputsAre requirements complete enough to design and objectively verify the product?Approved requirements, rationale, source, interfaces, acceptance criteria and review records.
Risk controlsAre risk-control measures implemented, verified and connected to affected requirements and outputs?Risk analyses, trace matrix, implementation records, verification results and residual-risk review.
Test configurationDoes the tested article represent the controlled design and intended use conditions?BOM, drawings, software versions, calibration, samples, environment and configuration records.
V&V methodsCan the method and acceptance criteria answer the requirement without ambiguity?Approved protocol, method validation where needed, sample rationale, data, deviations and report.
Design transferDo production specifications preserve the verified design and its critical controls?Released outputs, process controls, inspection and test, supplier records and transfer review.
Design changeAre technical, risk, regulatory and verification impacts assessed before release?Change request, impact analysis, updated traceability, re-verification rationale and approval.
Practical engagement model
Close the highest-consequence gaps first.
A focused quality or regulatory engineering engagement should establish scope, prioritize evidence gaps and leave the owning organization with controlled, usable records.
- 01
Assess context and baseline
Review device, intended use, markets, manufacturer roles, quality system, current records, issues and milestone.
Decision outputScope and evidence inventory - 02
Prioritize gaps
Connect missing or weak evidence to product risk, pathway needs, project dependencies and decision timing.
Decision outputRisk-ranked remediation plan - 03
Align engineering records
Clarify requirements, interfaces, risk controls, configuration and traceability while the design team can still act.
Decision outputConnected controlled baseline - 04
Build and review evidence
Develop or improve plans, methods, records and reports with defined acceptance and accountable review.
Decision outputReviewed objective evidence - 05
Transfer ownership
Close actions, release records and define how production, postmarket inputs and changes will maintain the evidence.
Decision outputUsable lifecycle controls
Quality and regulatory FAQ
Define the manufacturer, device and market before promising a pathway.
The answers below describe general engineering support. The responsible manufacturer and qualified regulatory leadership must confirm the requirements for the specific product and jurisdiction.
What changed for FDA device quality systems in 2026?
FDA's Quality Management System Regulation became effective February 2, 2026. It amended 21 CFR Part 820 and incorporates ISO 13485:2016 by reference, with additional FDA requirements. Applicability and implementation should be assessed for the specific manufacturer and products.
Does engineering support make a company ISO 13485 certified?
No. Certification, when pursued, is issued to a defined organization and scope through an accredited certification process. Project support can help develop or improve relevant procedures and records, but it is not itself certification.
Can the submission pathway be determined from device class alone?
No. Intended use, technological characteristics, classification regulations, predicates where relevant, jurisdiction and available evidence all affect pathway planning. A qualified regulatory assessment should document the rationale.
What is the difference between design verification and design validation?
Verification evaluates whether design outputs meet specified design inputs. Validation evaluates whether the resulting device meets user needs and intended uses under defined conditions. The program should specify configurations, methods and acceptance criteria for both.
Can Outer Reef review an existing design history or technical file?
Yes. A focused review can map available requirements, risk records, design outputs, reviews, verification, validation, transfer and changes, then identify technical gaps without claiming regulator or notified-body approval.
What information is useful for a first discussion?
Share the intended use, device description, target markets, manufacturer roles, quality-system context, pathway assumptions, development stage, current records, known gaps and the next external or internal milestone.
Start with the device and evidence baseline
Bring the product context, current records and the decision that needs support.
An initial discussion can identify the responsible parties, evidence boundary, highest-consequence gaps and a practical first work package without promising a regulatory outcome.