MedTech Product Development: From Concept to Regulatory Clearance
MedTech product development is the regulated process of designing, engineering, verifying, validating, and submitting a medical device or device software for market clearance under FDA design controls, EU MDR requirements, or both.
The medical device product development lifecycle spans six phases: concept and intended use definition; feasibility and regulatory strategy; design and development under design controls; verification and validation; regulatory submission; and manufacturing transfer with postmarket surveillance. Medical device projects most often stall not because of bad engineering but because of misunderstandings of regulatory gates, skipping design controls, or underestimating verification requirements. MedTech product development is typically viable for teams with a minimum development investment of $100,000 for an MVP and a 12 to 36-month timeline through clearance; teams below that threshold should consider partnering with an existing FDA-registered manufacturer rather than building independently. This guide covers each phase, including the decision criteria, key deliverables, and failure modes that determine whether a product achieves clearance or stalls.
Atta Systems provides MedTech product development services covering device software, SaMD, and digital health platforms from concept through regulatory submission.
What MedTech product development covers
MedTech product development covers four product categories: physical medical devices (Class I through III), Software as a Medical Device (SaMD), device software embedded in or controlling hardware, and in vitro diagnostic (IVD) devices. Each category is subject to different classification rules, submission pathways, and design control requirements.
- Physical medical devices range from low-risk items such as bandages and tongue depressors (Class I) to moderate-risk devices such as powered wheelchairs and diagnostic imaging equipment (Class II) to high-risk implantable devices such as pacemakers and heart valves (Class III). The classification determines the regulatory submission pathway and the depth of clinical evidence required.
- Software as a Medical Device (SaMD) performs a medical function independently of hardware. AI diagnostic tools, clinical decision support systems, and remote monitoring platforms that analyze patient data and provide clinical recommendations qualify as SaMD. The FDA, EU MDR, and IMDRF each define SaMD classification differently.
- Device software is embedded in or controls a physical medical device. Insulin pump controllers, MRI scanner firmware, and ventilator operating systems are device software. This software complies with IEC 62304 lifecycle requirements and is classified according to the parent device’s risk class.
- In vitro diagnostic (IVD) devices analyze samples taken from the human body to provide diagnostic information. Blood glucose monitors, pregnancy tests, and laboratory analyzers are IVDs. IVDs follow separate regulatory pathways: the FDA’s IVD guidance in the US and the IVDR (Regulation 2017/746) in the EU.
This guide focuses on the lifecycle phases common to all four categories. Where requirements diverge (such as IEC 62304 for software or IVDR for diagnostics), the relevant standard is named and linked to more detailed content.
The six phases of MedTech product development
MedTech product development follows a stage-gate lifecycle. Each phase produces specific deliverables and must clear regulatory gate criteria before proceeding. Skipping a gate or producing incomplete deliverables at any stage is the most common cause of submission delays and clearance failures.
| Phase | Key Activities | Deliverables | Regulatory Gate | Timeline Range |
|---|---|---|---|---|
| 1. Concept & intended use | Define the clinical problem. Identify the intended user and use environment. Conduct market research and competitor analysis. Preliminary regulatory classification. | Intended use statement. User needs document. Initial risk assessment. Regulatory strategy memo. | Is the intended use clear enough to determine whether the product is a medical device? Is the preliminary classification defensible? | 1–2 months |
| 2. Feasibility & regulatory strategy | Proof of concept prototyping. Engineering feasibility studies. Lock regulatory classification and submission pathway. FDA pre-submission (Q-Sub) if needed. Budget and project planning. | Feasibility report. Proof-of-concept prototype. Regulatory classification rationale. Submission pathway decision. FDA pre-sub feedback (if filed). | Is the concept technically achievable? Is the regulatory pathway confirmed? Has a pre-sub been filed for novel or ambiguous devices? | 2–4 months |
| 3. Design & development | Detailed design under FDA design controls. Design inputs from user needs and risk analysis. Design outputs (specifications, drawings, software architecture). Design reviews. Usability and human factors engineering. Design History File (DHF) maintenance. | Design input specifications. Design output documents. Software development plan (if applicable, per IEC 62304). Risk management file (ISO 14971). Usability engineering file. Updated DHF. | Do design outputs satisfy all design inputs? Has the traceability matrix been maintained? Has risk management been updated? Has usability been evaluated? | 4–12 months |
| 4. Verification & validation | Verification testing: does the device meet specifications? Validation testing: does the device meet user needs? Biocompatibility testing (if applicable). Software V&V (if applicable). Process validation for manufacturing. Sterilization validation (if applicable). | Verification test reports. Validation test reports. Biocompatibility test results. Software V&V reports. Process validation records. | Do verification results confirm the device meets all design output specifications? Do validation results confirm the device meets all user needs and intended uses? | 3–6 months |
| 5. Regulatory submission | Compile submission package. File 510(k), De Novo, or PMA (US), or submit technical documentation to a Notified Body (EU). Respond to FDA questions or Notified Body deficiency letters. Clinical investigation required by classification. | Complete submission package. 510(k) summary or PMA application. Technical documentation per EU MDR Annex II and III. Clinical evaluation report (EU) or clinical data (US if required). | Has the submission been accepted for review? Have all deficiency questions been answered? Has clearance or approval been granted? | 3–12 months (varies significantly by pathway and complexity) |
| 6. Manufacturing transfer & postmarket | Transfer design to manufacturing. Compile Device Master Record (DMR). Establish a postmarket surveillance plan. Adverse event reporting procedures. Ongoing risk management updates. | Device Master Record. Manufacturing process documentation. Postmarket surveillance plan. Complaint handling procedures. Periodic safety update reports (EU). | Are manufacturing processes validated? Is the Device Master Record complete? Is the postmarket surveillance system operational? Are adverse event reporting procedures in place? | 2–6 months |
Total timeline from concept to clearance ranges from 12 to 36 months, depending on device complexity, risk classification, and regulatory pathway. Class I devices with a 510(k) exemption can reach the market in under 12 months. Class III devices requiring PMA with clinical trials can take 3 to 5 years. Software-only SaMD products targeting De Novo classification typically fall within the 12 to 24-month range.
The Design History File (DHF) is the living document that captures every design decision, test result, change order, and review throughout the lifecycle. The DHF should be opened on day one of the project, not during verification. Teams that start their DHF late spend months reconstructing documentation that should have been captured in real time.
Regulatory frameworks and submission pathways
MedTech product development in the US is governed by FDA design controls under 21 CFR Part 820, which, as of February 2, 2026, is the Quality Management System Regulation (QMSR). The QMSR incorporates ISO 13485:2016 by reference, aligning US and international quality management requirements for the first time. In the EU, MDR 2017/745 and associated MDCG guidance documents define the regulatory framework.
| Framework | What It Governs | Key Update | Impact on Development |
|---|---|---|---|
| FDA QMSR (21 CFR 820) | Quality management system requirements for US medical device manufacturers. Covers design controls, production controls, CAPA, and management responsibility. | In effect since February 2, 2026. Incorporates ISO 13485:2016 by reference. Replaces the previous Quality System Regulation (QSR) structure. | Teams already operating under an ISO 13485 QMS are now directly aligned with US requirements. Teams building a new QMS should build to ISO 13485 from the start. |
| ISO 13485:2016 | International quality management system standard for medical device organizations. Covers design and development, production, measurement, and improvement. | Now incorporated by reference into the FDA QMSR. Recognized by EU MDR as a harmonized standard. | The single QMS standard that satisfies both US and EU requirements. Certification scope must cover the specific device types and processes relevant to the product. |
| ISO 14971 | Risk management for medical devices. Covers hazard identification, risk estimation, risk evaluation, risk control, and residual risk assessment. | Required alongside both FDA design controls and EU MDR. Must be maintained throughout the entire product lifecycle, not just during design. | Risk management must start in Phase 1 (concept) and be updated at every gate. The risk management file is one of the most scrutinized documents in regulatory submissions. Gaps here are a leading cause of submission delays. |
| EU MDR 2017/745 | Regulation governing the design, manufacture, and market placement of medical devices in the EU. Replaced the Medical Devices Directive (MDD) in May 2021. | Full application since May 2021. MDCG guidance documents continue to be published for specific topics (software classification, clinical evaluation, cybersecurity). | EU market access requires CE marking via a Notified Body assessment. Technical documentation must follow the structures in Annex II and Annex III. Clinical evaluation is mandatory for all device classes. |
Submission pathways determine the depth of evidence and review timeline required for market access:
| Pathway | When It Applies | What You Submit | Review Timeline | Notes |
|---|---|---|---|---|
| FDA 510(k) | Class II devices with a substantially equivalent predicate device on the market. | Premarket notification demonstrating substantial equivalence to a predicate. Performance data, bench testing, and sometimes clinical data. | 3–6 months average (FDA goal: 90 days for standard review). | Most common US pathway. Predicate device selection is a critical early decision. |
| FDA De Novo | Novel low-to-moderate-risk devices without a predicate. Common for new SaMD categories. | De Novo request with clinical and performance evidence. Risk-based classification rationale. | 6–12 months. More variable than 510(k). | Creates a new classification and becomes the predicate for future 510(k) submissions in the same category. |
| FDA PMA | Class III high-risk devices. Life-sustaining or life-supporting devices. | Premarket approval application with comprehensive clinical trial data, manufacturing information, and proposed labeling. | 12–24 months. Includes clinical trial time. | Most rigorous and expensive US pathway. Often requires an Investigational Device Exemption (IDE) for clinical trials. |
| EU CE Marking (via Notified Body) | All medical devices marketed in the EU. Notified Body review required for Class IIa, IIb, and III devices. | Technical documentation per MDR Annex II and III. Clinical evaluation report. QMS certification (ISO 13485). | 6–18 months. Notified Body capacity constraints can extend timelines. | Notified Body capacity has been a bottleneck since the implementation of MDR. Plan for longer review queues. |
What goes wrong at each phase, and how to avoid it
MedTech product development projects fail most often at three points: incomplete design inputs that force rework during verification, missing risk management documentation that delays submissions, and manufacturing transfer problems that surface after clearance.
The table below maps the most common failure mode at each lifecycle phase to its root cause and prevention strategy. No competitor guide covers this. Competitor guides describe what happens at each stage, but not what can go wrong.
| Phase | Common Failure Mode | Root Cause | How to Prevent It |
|---|---|---|---|
| 1. Concept | Wrong regulatory classification. The team assumes the product is Class I (exempt) when it is actually Class II and requires a 510(k). | No FDA pre-submission filed. No regulatory professional consulted during the concept phase. | File a pre-submission (Q-Sub) for any novel device or ambiguous classification before committing to a development timeline. A Q-Sub costs months but saves years. |
| 2. Feasibility | No viable predicate for 510(k). Team discovers midway that no substantially equivalent device exists, forcing a switch to De Novo. | Predicate search conducted superficially. Marketing-driven predicate selection rather than regulatory-driven. | Conduct a thorough predicate analysis using the FDA’s 510(k) database, device classification database, and relevant guidance documents. Validate the predicate with a regulatory specialist before starting design. |
| 3. Design & development | Design inputs do not trace to design outputs. The traceability matrix has gaps or was started too late. | Design History File opened during verification instead of at the start of design. Design reviews are skipped or treated as formalities. | Open the DHF on day one. Maintain the traceability matrix (inputs to outputs to V&V) as a living document. Conduct design reviews at every gate with documented decisions. |
| 4. Verification & validation | Test failures require design changes and the restart of V&V cycles. Timelines blow out by 3–6 months. | Design outputs were not verified incrementally during development. First comprehensive testing happens too late in the lifecycle. | Verify design outputs incrementally during Phase 3, not all at once in Phase 4. Use risk-based testing priorities: test the highest-risk elements first. Plan for at least one re-test cycle in the project timeline. |
| 5. Regulatory submission | Submission rejected or delayed due to deficiency questions about risk management, software documentation, or clinical evidence gaps. | The ISO 14971 risk management file is incomplete. Software documentation does not follow the IEC 62304 structure. Clinical evaluation relies solely on the literature when clinical data are expected. | Conduct a mock submission review against the FDA or Notified Body checklist before filing. Verify that the risk management file is complete and up to date. For software, ensure documentation follows the IEC 62304 clause structure. For EU submissions, verify the completeness of the clinical evaluation report against MDCG 2020-13. |
| 6. Manufacturing transfer | The manufacturing process produces devices that do not match the design transfer specifications. Process validation fails. | Design for manufacturability was not considered during Phase 3. Manufacturing partner engaged too late in the process. | Involve manufacturing engineering from Phase 2 (feasibility). Conduct Design for Manufacturing (DFM) reviews during Phase 3. Run process validation protocols before filing the regulatory submission. |
Risk management is the thread that runs through every failure mode on this list. ISO 14971 risk management should start in Phase 1 with initial hazard identification and be updated at every subsequent gate. Teams that treat risk management as a documentation exercise completed before submission, rather than a continuous engineering activity, consistently produce incomplete risk files that lead to regulatory deficiencies.
How to choose a MedTech product development partner
Choosing a MedTech software development partner requires verifying three things: ISO 13485 certification scope covering the relevant device type, documented design control experience with named cleared or approved products, and capability across the specific disciplines required by the project.
Five evaluation criteria:
- ISO 13485 certification scope. Request the partner’s ISO 13485 certificate and review the scope statement. The scope should cover the specific activities relevant to your project: design and development, software development, manufacturing, or a combination of these. A partner certified for distribution only is not certified for design.
- Named cleared or approved products. Ask for examples of products the partner helped bring to clearance or approval. The answer should include the device name, the regulatory pathway (510(k), De Novo, PMA, CE marking), and the partner’s specific role. If the partner cannot name a cleared product, they have not completed a regulated development cycle.
- Discipline coverage. MedTech product development requires multiple disciplines: mechanical engineering, electrical engineering, software engineering, industrial design, usability and human factors, regulatory affairs, quality assurance, and sometimes clinical affairs. Evaluate which disciplines the partner covers in-house versus which they subcontract.
- Submission support experience. Ask whether the partner has prepared or supported regulatory submissions. Preparing a 510(k) is different from designing a device. A partner with design experience but no submission experience will hand off incomplete documentation to a separate regulatory consultant, creating translation gaps.
- Postmarket capability. Regulatory clearance is not the end. IEC 62304 clauses 6 through 9 cover software maintenance and problem resolution. EU MDR requires postmarket surveillance plans, periodic safety update reports, and complaint handling. Evaluate whether the partner can support these ongoing requirements or will exit after clearance.
Red flags when evaluating MedTech development partners:
- “FDA-compliant” without naming a single cleared device. FDA compliance is demonstrated through cleared or approved products, not through marketing claims. Ask for the 510(k) number or PMA approval letter.
- ISO 13485 logo displayed without specifying the certification scope. The logo alone means nothing. The scope statement on the certificate defines what the partner is actually certified to do.
- “End-to-end medtech development” without evidence of verification, validation, or regulatory submission. Many engineering firms can design and prototype. Fewer can produce the V&V documentation and submission packages required for clearance.
- “Clinical-grade AI” without FDA SaMD submission experience. AI in a medical context requires regulatory classification, submission, and often pre-submission engagement with the FDA. Marketing an AI algorithm as “clinical-grade” without a regulatory pathway is a red flag.
Atta Systems provides MedTech product development services for device software, SaMD, and digital health platforms, aligned with ISO 13485 quality practices, focusing on software-led medical devices and IEC 62304 Class B and C safety classifications rather than physical device fabrication, Class III implantable hardware, or wellness apps outside regulatory scope. Atta Systems has delivered medical device software, including Eupnoos (a respiratory diagnostics platform) and SkinVision (a CE-marked dermatology screening application), from concept through regulatory documentation.
FAQ about MedTech product development
MedTech product development takes 12 to 36 months from concept to market clearance for most Class II devices using the 510(k) pathway. Class I exempt devices can reach the market in under 12 months. Class III devices requiring PMA with clinical trials typically take 3 to 5 years. Software-only SaMD products targeting De Novo classification fall in the 12 to 24 month range. Timelines are most affected by three factors: device complexity, regulatory pathway, and whether clinical trials are required.
A Design History File is the compilation of all design control records for a medical device, including design inputs, outputs, reviews, verification results, validation results, and change orders. The DHF should be opened on day one of the project, not during verification or submission preparation. Teams that start the DHF late spend months reconstructing documentation that should have been captured in real time. Under the FDA QMSR (in effect since February 2026, incorporating ISO 13485), the DHF is part of the quality management system and subject to audit.
SaMD follows the same design control framework (design inputs, outputs, V&V, design transfer) but adds software-specific requirements from IEC 62304 (software development lifecycle) and cybersecurity documentation. SaMD also has its own classification frameworks: IMDRF defines risk categories based on the seriousness of the healthcare situation and the significance of the software’s output. The FDA’s current guidance on device software functions (2023) and draft guidance on AI-enabled device software functions shape submission documentation for software-heavy products.
The FDA’s Quality Management System Regulation (QMSR) took effect on February 2, 2026, replacing the previous Quality System Regulation (QSR) and incorporating ISO 13485:2016 by reference. US regulatory requirements and the international ISO 13485 standard are now directly aligned. Medical device manufacturers who already maintained an ISO 13485-certified QMS before the transition found their existing processes largely satisfy the new QMSR requirements. Teams building a new QMS today should build to ISO 13485 from the start rather than to the legacy QSR structure.
Related Articles
