Concept Feasibility Study is an early-stage assessment in medical device development that tests whether a proposed device concept can work technically, satisfy user and clinical needs, meet applicable regulations, and be manufactured at acceptable cost and risk, before a company commits significant resources to full design and development.
What is a Concept Feasibility Study?
A Concept Feasibility Study sits at the front end of the device lifecycle, after an initial idea or unmet need is identified and before formal design controls under FDA 21 CFR Part 820.30 or EU MDR 2017/745 fully kick in. Its job is to answer one question: should we build this, and can we?
The study converts a rough concept into evidence. Teams build early models, run bench tests, sketch the regulatory pathway, and estimate manufacturing reality. The output is a go, no-go, or pivot decision backed by data rather than optimism. Some organizations call this proof of concept or front-end feasibility, but the intent is the same: reduce uncertainty cheaply, while changes are still inexpensive.
Why does a Concept Feasibility Study matter in medical device development
The cost of a design change rises sharply as a program advances. A flaw caught during a Concept Feasibility Study might cost a few weeks of lab time. The same flaw caught after design verification, tooling, or a regulatory submission can cost months and a large budget, and it may force a redesign of a device already promised to clinicians and investors.
Feasibility work also surfaces regulatory exposure early. Misjudging device classification, the predicate strategy for an FDA 510(k), or the clinical evidence an EU MDR technical file will demand can derail a launch. A study that maps these requirements upfront protects the timeline and the eventual audit trail.
There is a safety dimension too. Identifying the hazards a concept introduces, in line with ISO 14971 risk management thinking, helps a team decide whether the residual risk is even controllable before they invest in the architecture.
How the Concept Feasibility Study process works
A feasibility study is rarely a single document. It is a short, structured investigation across several dimensions, sized to the risk and novelty of the concept.
- Define user needs and intended use. Capture who uses the device, the clinical or operational problem, and the use environment. This frames everything downstream and aligns with usability work under IEC 62366-1.
- Assess technical feasibility. Build breadboards, mockups, or proof-of-concept prototypes. Run bench tests on the riskiest assumptions first: the novel sensor, the optical path, the power budget, the fluidics.
- Screen the regulatory pathway. Determine likely device class, applicable standards (for example, the IEC 60601 family for electrical safety, IEC 62304 for device software), and the submission route in target markets.
- Evaluate manufacturability. Ask early whether the concept can be produced at volume, what materials and processes it needs, and where supply or tooling risk lives.
- Run an initial risk assessment. Apply ISO 14971 principles to list hazards, harms, and whether controls are plausible.
- Model cost and timeline. Estimate development effort, bill-of-materials targets, and time-to-market so leadership can weigh the investment.
Surrounding these activities is a phase-gate decision. The deliverable is a feasibility report and a recommendation that feeds the formal design and development plan once a program proceeds.
Common challenges and best practices
The most frequent mistake is testing the easy assumptions instead of the dangerous ones. Teams sometimes polish an enclosure while the core technical risk, the thing that could kill the product, goes unexamined. Attack the highest-uncertainty item first.
A second trap is scope creep. A feasibility study is meant to be fast and cheap. When it quietly becomes fully developed, the de-risking value evaporates. Set clear questions and a fixed budget, then stop when they are answered.
Skipping the regulatory and manufacturing voices is a third error. Pulling QA/RA and manufacturing engineers into feasibility early prevents a technically elegant concept that cannot clear a submission or be built affordably. Good feasibility work also documents what was learned, including dead ends, so the eventual design history file inherits a clear rationale.
What good looks like: a small cross-functional team, prioritized experiments, honest reporting of negative results, and a decision gate that managers actually respect.
How SJML helps with Concept Feasibility Study
SJML is an end-to-end medical device CDMO that supports programs from concept and feasibility through architecture, design, verification, and design transfer. During feasibility, its engineering teams work across mechanical, electronics, embedded software, and systems engineering to test the riskiest assumptions early, with risk management (ISO 14971) and usability engineering (IEC 62366-1) built in from the start. In-house labs for electrical safety, EMC, reliability, and environmental testing let teams validate technical assumptions quickly, while QARA input helps map the regulatory pathway up front. The aim is a clear, evidence-based go decision and a shorter path to market.
Talk to SJML’s engineering team →
Frequently asked questions
A proof of concept usually answers a single technical question: can this part of the idea work at all? A Concept Feasibility Study is broader. It bundles technical proof with regulatory, manufacturing, risk, and commercial assessment to produce an overall go or no-go decision for the whole device concept.
It happens at the front end, after a need or idea is identified and before formal design controls and full development begin. It is the bridge between an unstructured idea and a planned, design-controlled program governed by FDA 21 CFR Part 820.30 or EU MDR 2017/745.
Formal design controls generally apply once a program moves into design and development. Feasibility work itself usually precedes them, but smart teams document feasibility findings so the rationale flows cleanly into the design history file and later risk files under ISO 14971.
It should be deliberately short, sized to the risk and novelty of the concept. The goal is to answer the highest-uncertainty questions cheaply, then make a decision. If a study stretches into months of building, it has usually drifted into development and lost its de-risking purpose.
Related terms
- Design Verification
- Design Controls
- Proof of Concept
- Design Transfer
- Risk Management (ISO 14971)
