Proof of Concept (PoC)

A Proof of Concept (PoC) is a preliminary demonstration that a proposed medical-device idea, technology or design approach can work in principle. During early medical device design and engineering, teams build a simplified test article or conduct a focused experiment to evaluate technical feasibility before committing substantial engineering, regulatory and manufacturing resources.

What is a Proof of Concept?

A Proof of Concept sits near the beginning of the medical-device development lifecycle, after an unmet need or product opportunity has been identified and before the complete product design is developed.

It answers a narrow question:

Can this idea work in principle within the relevant physical, biological, software or engineering constraints?

A PoC is not a finished medical device. It is also different from a complete prototype, which normally represents more of the intended product’s form, function or user interaction.

The primary output of a PoC is evidence that supports a decision. Depending on the result, the team may:

• Proceed into broader feasibility work
• Revise the technical approach
• Compare alternative solutions
• Conduct another focused experiment
• Pause the program
• Stop development before further resources are committed

A PoC should remove or substantially reduce a meaningful technical uncertainty. Building something merely because it is visually impressive does not make it a useful proof of concept.

Examples of medical-device PoCs

A medical-device PoC may be:

• A breadboard circuit demonstrating that a sensor can detect the target physiological signal
• A benchtop rig showing that a proposed pump can achieve the required flow rate
• A 3D-printed fixture demonstrating that a catheter feature can be formed
• A simplified optical setup confirming that an analyte can be detected
• A microfluidic cartridge showing that a sample moves through the intended channel
• A software model demonstrating that an algorithm can extract a signal from noisy data
• A basic actuator proving that sufficient force or displacement can be generated
• An electronics and firmware assembly showing that two subsystems can communicate
• A laboratory setup demonstrating that a proposed treatment mechanism produces the expected output
• A preliminary manufacturing experiment showing that a feature can be produced within a plausible tolerance range

The test article should be only as complex as necessary to answer the defined question.

PoC versus prototype

A PoC and a prototype are related but serve different purposes.

A PoC demonstrates whether an idea or technical principle can work. It may use temporary fixtures, development boards, generic materials, off-the-shelf components or laboratory software.

A prototype represents more of the intended product. It may be used to evaluate:

• Form and fit
• Mechanical integration
• User interaction
• Product architecture
• Materials and tolerances
• Subsystem interfaces
• Manufacturability
• Verification readiness

A successful PoC may lead to several prototype iterations. However, a PoC should not quietly become the production design without the requirements, architecture, risk management, documentation and verification expected during formal development.

Why a Proof of Concept matters

The cost of discovering a fundamental technical problem increases sharply as a medical-device program progresses.

A failed PoC may cost several days and a small number of components. The same problem discovered after architecture, detailed design or tooling may require months of redesign. If it is discovered during formal bench testing, electrical-safety testing or a regulatory submission, it can delay market entry and invalidate earlier evidence.

A disciplined PoC forces the development team to test its most important assumption before that assumption becomes embedded in the design.

PoCs help organizations:

• Reduce technical uncertainty
• Compare competing approaches
• Identify physical or biological limitations
• Estimate achievable performance
• Discover integration risks
• Refine the development scope
• Improve resource planning
• Support investment decisions
• Inform early intellectual-property strategy
• Avoid premature tooling or supplier commitments

The purpose is not to prove that the complete product is ready. It is to determine whether the central concept deserves further development.

PoC and medical-device safety

A PoC usually operates under simplified conditions. It may not contain the final enclosure, production components, protective circuits, alarms, software controls or labeling.

This means a PoC should not be assumed to satisfy the safety requirements applicable to the finished device. For medical electrical equipment, formal evaluation against IEC 60601 occurs later using a representative device and controlled test configuration.

Nevertheless, safety should not be ignored during PoC work. The team should identify hazards associated with:

• Electrical energy
• Moving parts
• Heat
• Pressure
• Lasers or optical radiation
• Biological materials
• Chemicals
• Software-controlled motion
• Temporary wiring
• Unprotected test fixtures

Only trained personnel should use an experimental PoC, and its limitations should be documented.

How a Proof of Concept works

A useful PoC follows a short but disciplined process.

1. Define the technical uncertainty

Start by identifying the single technical assumption that presents the greatest threat to the proposed concept.

Examples include:

• Whether a sensor can achieve sufficient sensitivity
• Whether a mechanism can generate the required force
• Whether a fluidic design can maintain the desired flow
• Whether an algorithm can classify the intended signal
• Whether a material can tolerate the proposed process
• Whether two subsystems can exchange data reliably

Broad questions such as “Will the device work?” are unsuitable because they cannot be answered by one focused experiment.

2. Write a testable hypothesis

Express the uncertainty as a measurable prediction.

For example:

A sensor using the proposed optical configuration will detect the target signal with a signal-to-noise ratio of at least X under defined laboratory conditions.

The hypothesis should state:

• What will be tested
• Under which conditions
• What result is expected
• What constitutes success or failure

3. Establish decision criteria

Define the pass-or-fail criteria before building the test article. This prevents the team from interpreting an ambiguous result as success after the test.

Decision criteria may address:

• Accuracy
• Sensitivity
• Force
• Flow rate
• Signal-to-noise ratio
• Repeatability
• Response time
• Temperature
• Power consumption
• Dimensional capability
• Software performance

A PoC does not always need to meet the final product requirement. However, the team should explain how the selected threshold supports the decision to proceed.

4. Plan the work

Even a short PoC benefits from basic planning. A program manager or engineering lead should define:

• Objective
• Scope
• Owner
• Required expertise
• Materials and equipment
• Safety precautions
• Schedule
• Budget
• Test method
• Decision authority
• Expected deliverable

Within broader medical-device program management, PoC results may determine whether the concept proceeds to the next development phase.

5. Build the minimum test article

Construct only what is necessary to evaluate the hypothesis.

Possible methods include:

• Breadboard electronics
• Development boards
• Laboratory software
• 3D-printed parts
• CNC-machined fixtures
• Commercial off-the-shelf components
• Simplified mechanical rigs
• Test cartridges
• Optical benches
• Simulated input data

Where geometry or mechanical interfaces matter, controlled Computer-Aided Design (CAD) models can define the test article and preserve a record of the configuration evaluated.

6. Control important variables

A PoC may use simplified conditions, but uncontrolled variables can make its results meaningless.

Document factors such as:

• Environmental conditions
• Component specifications
• Material properties
• Software version
• Equipment settings
• Sample preparation
• Calibration status
• Number of test repetitions
• Known limitations

The controls should be proportionate to the decision being made.

7. Run the experiment

Perform the planned test and record objective results. Avoid changing the test setup or acceptance criteria during execution without documenting why.

When unexpected behavior occurs, capture it. An unplanned result may reveal a more important risk than the original hypothesis.

8. Analyze the evidence

Compare the observed result with the predefined decision criteria.

The conclusion may be:

• Hypothesis supported
• Hypothesis not supported
• Result inconclusive
• Additional testing required
• Alternative approach recommended

A result should not be declared successful merely because the test article produced some output.

9. Review manufacturability

A technically successful concept may still be unsuitable for production. Early Design for Manufacturability (DfM) review can identify whether the concept depends on unrealistic tolerances, unavailable components, manual adjustment or laboratory-only processes.

A manufacturability PoC may evaluate:

• Material-forming capability
• Assembly access
• Repeatable alignment
• Joining methods
• Tooling approach
• Component availability
• Inspection feasibility
• Process variability

The objective is not to finalize manufacturing but to identify whether the proposed approach has a realistic production path.

10. Make a documented decision

The final PoC review should decide whether to:

• Proceed into feasibility
• Develop a higher-fidelity prototype
• Run another PoC
• Modify the architecture
• Select an alternative technology
• Narrow the product claims
• Stop the program

Record the decision, supporting data, remaining uncertainties and follow-up actions.

Common types of Proof of Concept

Technology PoC

A technology PoC determines whether the core sensing, actuation, treatment or diagnostic principle works.

Integration PoC

An integration PoC evaluates whether two or more subsystems operate together. Examples include:

• A disposable cartridge and reader
• A sensor and embedded controller
• An actuator and mechanical mechanism
• A device and mobile application
• Firmware and a communication module

Software or algorithm PoC

A software PoC evaluates whether an algorithm, data-processing method or user workflow can achieve the proposed objective.

It may use simulated or retrospective data and is not equivalent to validated production software.

Manufacturability PoC

A manufacturability PoC evaluates whether a material, feature or process can be produced repeatedly within a realistic tolerance range.

Clinical-workflow PoC

A workflow PoC explores whether the proposed device concept can fit within the intended care pathway. It may use mock equipment, simulated users or representative clinical environments without involving actual patients.

Usability PoC

A usability PoC explores an interaction concept, control layout or workflow before the complete interface is developed. It may support early formative work but does not replace formal usability validation.

PoC versus feasibility study

A PoC evaluates a focused technical question. A feasibility study is broader and considers whether the complete product opportunity is viable.

A feasibility study may address:

• Technical feasibility
• Regulatory classification and pathway
• Clinical-evidence needs
• Market need
• Reimbursement considerations
• Manufacturing strategy
• Supply-chain availability
• Development budget
• Intellectual property
• Commercial viability

A program may complete several technical PoCs as part of a larger feasibility phase.

PoC versus verification and validation

A PoC asks whether an idea can work in principle. Formal verification and validation occurs later using approved requirements, predefined acceptance criteria and representative test articles.

PoC results generally should not be used to close formal verification requirements because:

• The design is not finalized.
• The test article may not represent the production configuration.
• Components and materials may be temporary.
• Test methods may not be validated.
• Configuration control may be incomplete.
• The work may not have been conducted under the required design controls.

PoC evidence can inform requirements and test planning, but later verification must demonstrate that the final design meets its approved inputs.

Design controls and PoC documentation

It is common for exploratory PoC work to occur before formal design inputs and detailed development records are established. However, it is inaccurate to assume that every PoC automatically sits outside design controls.

If PoC results are used to:

• Select the product architecture
• Establish a safety-critical requirement
• Justify a risk control
• Choose a critical material or component
• Support a regulatory claim
• Close a formal design activity

then the manufacturer should determine whether those decisions and records belong within the controlled design and development documentation.

Good practice is to maintain a proportional PoC record containing:

• Objective and hypothesis
• Test-article description
• Drawings or configuration information
• Components and materials
• Software version
• Test method
• Acceptance criteria
• Raw results
• Analysis
• Photographs where useful
• Limitations
• Conclusion
• Review decision
• Follow-up actions

This information provides context for later design decisions and reduces the need to reconstruct early development history.

Common challenges and best practices

Allowing the PoC to become the production architecture

A quickly assembled breadboard may work well enough for a demonstration, leading teams to carry temporary architecture or ad hoc firmware into formal development.

Components selected for convenience may lack lifecycle support, regulatory documentation or production suitability. Treat the PoC as evidence—not automatically as the final design.

Testing several hypotheses at once

A test article intended to evaluate sensor accuracy, mechanical durability and manufacturability simultaneously may produce unclear results.

Isolate one important uncertainty wherever possible.

Writing the acceptance criteria after testing

Defining success after seeing the data creates confirmation bias. Establish criteria before running the experiment.

Building too much

Teams sometimes build a nearly complete device before demonstrating the riskiest technical principle. This wastes resources and makes failures more expensive.

Use the smallest test article that can answer the question.

Keeping no records

An informal PoC may still influence major design decisions. Without records, the team may later be unable to explain why an architecture, component or technology was selected.

Treating a failed PoC as wasted effort

A failed PoC is valuable if it eliminates an unsuitable approach before the organization commits significant resources.

The goal is an informed decision, not a positive result at any cost.

Moving from PoC to formal development

A successful PoC does not mean the product is ready for verification or manufacturing. It demonstrates only that the evaluated principle has sufficient promise for further development.

The next steps may include:

1. Broader technical and commercial feasibility
2. Intended-use definition
3. Regulatory-pathway assessment
4. System-requirement development
5. ISO 14971 risk-management planning
6. Product architecture
7. Higher-fidelity prototypes
8. Formative usability work
9. Design-for-manufacturability reviews
10. Formal verification and validation planning

Progression should be controlled through a Phase-Gate Process with defined evidence and decision criteria. The gate review should confirm what the PoC demonstrated, what remains uncertain and which activities are authorized next.

How SJML helps with Proof of Concept

SJML supports medical-device programs from early Proof of Concept through feasibility, architecture, prototyping, verification and design transfer.

Multidisciplinary teams cover mechanical engineering, electronics, software and embedded systems, allowing PoCs involving sensing, actuation, signal processing or subsystem integration to be developed under one organization.

In-house engineering laboratories support early bench evaluation, electrical measurements, functional testing and preparation for later IEC 60601, EMC, reliability and environmental testing.

SJML also integrates ISO 14971 risk-management thinking into early development so that PoC findings can inform subsequent requirements and design decisions. Phase-gate program management keeps the experiment connected to a documented development decision rather than allowing it to remain an isolated technical exercise.

Frequently asked questions