Proof of Concept (PoC) is a preliminary demonstration that a proposed medical device idea, technology, or design approach can work as intended. Teams build a simplified prototype or run a bench test to confirm technical feasibility before committing full engineering, regulatory, and manufacturing resources to the concept.
What is Proof of Concept (PoC)?
A Proof of Concept (PoC) sits at the front of the medical device development lifecycle, right after an initial concept or unmet need is identified and before formal design controls begin under ISO 13485. It answers one narrow question: can this idea work in principle, given the physics, biology, or engineering constraints involved? A PoC is not a finished design, and it isn’t validated against user needs in the formal sense. It’s a targeted experiment meant to remove the single biggest technical unknown.
A PoC might be a breadboard circuit proving a sensor can detect a target signal, a benchtop rig showing a novel catheter tip can be formed reliably, or lab software proving an algorithm can extract a signal from noisy data. The output is evidence, not a product. Teams typically move from PoC into feasibility studies, then into formal design inputs once the core technical risk is retired.
Why Proof of Concept (PoC) matters in medical device development
For regulated devices, the cost of a fundamental technical flaw grows sharply at every later stage. A PoC failure at the bench costs days and a few components. The same flaw found during design verification testing under IEC 60601-1 costs months of rework. Found after a 510(k) submission or CE mark, it can mean a recall or a device that never reaches patients. A disciplined PoC forces a company to confront its riskiest assumption before that assumption becomes load-bearing in the design.
PoC results also shape how a program gets resourced. Investors and program managers use them to decide whether to fund the next phase, kill the project, or pivot the approach. A weak or skipped PoC often shows up later as scope creep or a design history file that cannot explain why a given architecture was chosen.
How Proof of Concept (PoC) works
A PoC typically follows a short, informal but disciplined sequence, one good team’s document even before formal design controls begin, since the record becomes useful context for the eventual design history file (DHF).
- Define a single technical hypothesis narrow enough for one bench experiment to prove or disprove.
- Build the minimum test article needed, often a breadboard, 3D-printed fixture, or software prototype.
- Run the test under simplified conditions, without full IEC 60601 or biocompatibility rigor.
- Capture objective data on whether the result matches the prediction.
- Decide whether to proceed with feasibility work, revise the concept, or stop.
Some PoC types recur often in MedTech. A technology PoC proves a sensing or actuation principle works at all. An integration PoC proves that two subsystems, such as a cartridge and a reader instrument, interact correctly. A manufacturability PoC proves a material or process can be produced within a plausible tolerance band. Larger programs often run several PoCs in parallel, each retiring a different risk.
A PoC differs from a feasibility study, which is broader and covers commercial and regulatory feasibility alongside technical feasibility, and from design verification, which happens later under a locked design against defined acceptance criteria per ISO 13485.
Common challenges and best practices
The most common mistake is letting a PoC quietly become the actual design. Because it gets built fast and often works well enough to demo, teams carry the same breadboard architecture or ad hoc firmware into formal development. That erodes traceability and creates rework later, when a component picked for convenience lacks the documentation a design output needs.
A second failure is testing the wrong hypothesis, or several at once. A PoC that tries to prove sensor accuracy, mechanical reliability, and manufacturability in one build usually proves none of them convincingly. Isolating one variable at a time produces clearer evidence.
Good practice: write the hypothesis and pass or fail criteria before building, keep the test article as simple as the hypothesis allows, log results even informally, and treat a failed PoC as a success if it retires a real risk cheaply. Teams that skip documentation here often struggle to reconstruct early decisions, which matters when a reviewer asks for design history.
How SJML helps with Proof of Concept (PoC)
SJML supports medical device programs from the earliest PoC stage onward, working with OEM and startup teams to translate a concept into a testable technical hypothesis. Its design and engineering group covers mechanical, electronics, embedded systems, and software disciplines, so a PoC involving sensing, actuation, or signal processing can be built and evaluated under one roof. In-house labs support early bench testing, and risk management aligned with ISO 14971 is built into the process, so findings feed cleanly into later design inputs and the design history file rather than becoming disconnected experiments.
Talk to SJML’s engineering team →
Frequently asked questions
A PoC proves an idea or mechanism works at all, often with a rough breadboard or bench setup. A prototype is a fuller representation of the intended device, built to explore form, fit, or user interaction once the concept is already shown to be feasible.
A PoC happens early, before formal design controls begin under ISO 13485. It follows initial concept generation and precedes feasibility studies and design input development, since its job is to retire the biggest technical unknown first.
No. A PoC generally runs outside the formal quality management system, using simplified test articles instead of a design-controlled build. Full compliance with IEC 60601-1 and ISO 13485 applies later, once the concept moves into formal development.
A failed PoC is valuable information, not wasted effort. It means the team ruled out an approach cheaply, before committing engineering, regulatory, and manufacturing resources. Teams typically revise the hypothesis, try an alternative approach, or stop the project.
A small cross-functional group typically runs a PoC: an engineering lead and a subject matter expert for the specific risk, often joined by a program manager who decides whether to move into feasibility. Formal QARA involvement usually begins afterward.
Related terms
- Feasibility Study
- Design Verification
- Design History File (DHF)
- Design Controls
- Design Inputs
