A medical-device proof of concept should answer a small number of consequential questions before the team commits to a product architecture. It is not a miniature production device, and it is not persuasive evidence simply because it looks finished. Its value comes from reducing uncertainty about the clinical workflow, core technology, safety strategy, interfaces and evidence plan.
The right proof of concept depends on the intended use and the decision the team needs to make. A benchtop sensing chain, actuator load rig, optical path, software simulation or workflow mockup may be more useful than an integrated enclosure. Teams waste time when they build the most visible prototype instead of the experiment that addresses the highest-risk assumption.
Define the decision before building hardware
Begin with a written decision statement. Examples include whether a sensor can achieve the required signal quality in the expected environment, whether an actuator has enough force and thermal margin, whether a user can complete a critical task, or whether an imaging geometry can maintain accuracy through the working volume.
Then define what evidence would change the decision. A useful feasibility question has a measurable output, known test conditions and a consequence. “Can the motor turn?” is weak. “Can the selected motor and transmission deliver the required output torque for the duty cycle without exceeding the allowable winding and enclosure temperatures?” creates an engineering test.
Separate product assumptions from technical evidence
Early programs contain assumptions about users, workflows, hazards, performance, price, service, cleaning, production volume and regulatory pathway. Record them explicitly and identify which assumptions affect architecture. A change in intended user, use environment or clinical claim can alter requirements well beyond the prototype itself.
For the United States, device classification and applicable controls depend on the specific product and intended use. FDA’s current How to Study and Market Your Device resource explains the risk-based classification framework and the available premarket pathways. A feasibility prototype does not determine the pathway by itself, so regulatory and quality expertise should inform the plan early.
Rank uncertainty across the complete system
A technical risk register helps the team decide what to test first. Rank uncertainties by the likelihood that they will force an architecture change, delay the program or undermine the product’s intended benefit.
- Clinical and workflow: critical tasks, use sequence, access, visibility, setup, feedback and foreseeable misuse.
- Performance: accuracy, force, speed, latency, resolution, thermal limits, battery life or signal quality.
- Interfaces: mechanical boundaries, electrical power, data, accessories, external equipment and user interaction.
- Safety: hazardous situations, single faults, detection, protective measures and recovery behavior.
- Manufacturing: materials, tolerances, suppliers, calibration, assembly, inspection and production test.
- Lifecycle: transport, storage, cleaning, maintenance, cybersecurity, service and component obsolescence.
Not every item needs a prototype. Some questions are better answered through calculation, simulation, supplier evidence, standards review, task analysis or an interface study. The feasibility plan should choose the least expensive credible method for each decision.
Choose the minimum representative prototype
Representativeness is specific to the question. A thermal test may require realistic power dissipation, heat paths and boundary conditions but not final software. A human-factors mockup may need representative geometry, controls and feedback but not production materials. An EMC investigation may require the intended switching topology, layout scale, cabling and grounding while the industrial design remains unresolved.
Document which aspects are representative and which are deliberately simplified. That record prevents the team from using evidence beyond its limits. It also makes the prototype easier to modify because nonessential details do not become accidental requirements.
Plan measurements before the test
Define the input conditions, instrumentation, sample rate, fixture, calibration state and acceptance logic before running the experiment. Capture raw data when possible. A conclusion such as “performance looked stable” cannot support a later architecture decision as well as time histories, uncertainty estimates and controlled test conditions.
Include adverse and boundary conditions. Loads, temperatures, supply voltage, alignment, contamination, communication delay or component tolerance can expose a weakness that nominal demonstrations hide. A proof of concept should reveal where the margin ends, not only where the concept works.
Connect feasibility work to risk and requirements
Early prototypes often reveal hazards and failure behavior. Record those observations in the program’s risk process rather than leaving them in laboratory notes. If feasibility evidence supports a performance limit or control measure, translate it into a measurable design input and retain the rationale.
This does not make an exploratory prototype a verification unit. Verification evaluates whether controlled design outputs meet approved design inputs, while validation addresses user needs and intended use under defined conditions. FDA’s Design Control Guidance for Medical Device Manufacturers discusses the distinction. Feasibility evidence informs later plans but does not replace controlled verification or validation.
Review interfaces before freezing architecture
Many medical-device failures emerge between disciplines. A motor-current limit affects delivered force and thermal behavior. An optical alignment feature affects mechanical tolerance and calibration. A communication delay affects software state logic and user feedback. A cleaning requirement affects materials, sealing, connectors and service access.
Use an interface table that identifies the owner, exchanged quantity or information, units, ranges, timing, fault behavior and verification method. Review the table with mechanical, electrical, software, systems, quality and manufacturing contributors. The goal is to expose incompatible assumptions while change is still inexpensive.
Define the exit criteria
A feasibility phase should end with a decision, not an indefinitely improving prototype. Possible outcomes include proceeding with the proposed architecture, changing a subsystem, running a focused follow-up experiment, changing the product definition or stopping the concept.
The review package should contain the original questions, prototype configuration, methods, data, limitations, risk updates, interface decisions and recommended next work. Open issues need owners and a planned evidence method. This creates a defensible bridge from exploratory work into controlled development.
What should happen next?
Once the major feasibility questions have evidence, the team can establish the development baseline: intended use, system boundaries, risk strategy, measurable requirements, architecture, regulatory assumptions and verification approach. The broader medical-device development lifecycle guide explains how those elements continue through design controls, integration, verification, validation and transfer.
For teams evaluating outside support, use the medical-device engineering consulting checklist to define technical ownership and evidence responsibilities. To discuss a feasibility question or integrated work package, review Outer Reef’s medical-device product-development capabilities.
