A prototype is a physical or functional build of a medical device design, created to test specific features, performance, or manufacturability before the design is finalized. In medical device development, prototypes range from early proof-of-concept models to verification-grade units built under formal design controls (FDA 21 CFR 820.30, ISO 13485) ahead of design transfer.
What is a Prototype?
A prototype is any physical or functional representation of a medical device built before the design is locked. It might be a 3D-printed housing that only checks fit and ergonomics, or a fully wired electromechanical unit that mirrors the intended production device down to the connector type. The common thread is purpose: each prototype exists to answer a specific engineering or clinical question, not to look finished.
Medical device teams typically move through several prototype tiers as a program matures: proof-of-concept, alpha, beta or verification-grade, and pilot production units. Fidelity increases at each stage. A proof-of-concept model might use off-the-shelf electronics and generic materials; a verification-grade prototype should use production-intent materials, tolerances, and manufacturing processes so that test data holds up under scrutiny.
Why prototypes matter in medical device development
Prototyping is where design assumptions meet physical reality, and for regulated devices, the stakes are higher than for consumer products. A design flaw caught in an early foam model costs a few hours of rework. The same flaw discovered after design transfer, when tooling exists and a design history file (DHF) is already populated with verification data, can mean scrapped tooling, a design change under formal change control, and a delayed submission.
Prototypes also generate the evidence base for design verification and, later, design validation. If a prototype used for verification testing does not represent the production build (wrong material, wrong process, wrong tolerance stack), the resulting data may not be defensible in front of an FDA reviewer or a notified body auditor under EU MDR 2017/745. Getting prototype fidelity wrong is a quieter risk than a failed bench test, but it surfaces later, usually during an audit.
The prototype development process
Prototyping in a design-controlled environment is not a single build. It is a sequence of builds, each tied to a design review gate and a documented objective.
- Define the question. Every prototype should map to a specific design input or risk the team needs to evaluate, whether that is fit, function, usability, or manufacturability.
- Translate design inputs into a build. CAD models, a bill of materials, and engineering drawings feed the build, with revision control from the first iteration.
- Choose a fidelity level and build method. Early builds might use 3D printing, CNC machining, or benchtop electronics; later builds shift toward production-representative tooling and processes so test results are traceable to the final device.
- Build under configuration control. Even pre-design-control prototypes benefit from serial numbers, revision logs, and a clear build record, since it is far easier to maintain traceability from the start than to reconstruct it later.
- Test against acceptance criteria. Results feed back into design inputs, risk management activities under ISO 14971, and usability evaluation under IEC 62366-1.
- Gate to the next stage. A design review decides whether the prototype has answered its question and whether the program is ready for the next fidelity tier.
This loop repeats, tightening tolerances and increasing realism, until a design is mature enough to enter formal design verification and, eventually, design transfer to manufacturing.
Common challenges and best practices
The most common mistake is treating all prototypes as equivalent evidence. Teams sometimes run verification-style testing on an early, non-representative build because it is available, then try to use that data to close out a design control activity. Reviewers and auditors look closely at whether the unit under test actually reflects the production configuration.
A second recurring problem is skipping documentation on early-stage builds. Teams move fast during feasibility work, and configuration records get thin. Months later, when the DHF is assembled, there are gaps nobody can fully explain.
Good programs avoid both problems by defining prototype fidelity levels and their intended use up front, before the first build starts. Manufacturing engineering gets involved early, during alpha-stage reviews, so design-for-manufacturability issues surface before tooling commitments are made. They also budget realistic time and cost for verification-grade prototypes, which almost always take longer and cost more than teams expect, rather than compressing that stage under schedule pressure.
How SJML helps with Prototype
SJML supports medical device programs from early concept models through verification-grade and design-transfer-ready prototypes, working across mechanical, electronics, embedded software, and systems engineering. Builds are supported by in-house labs for electrical safety and IEC 60601 testing, EMC, reliability, and environmental testing, so prototype data holds up through design verification. Risk management under ISO 14971 and usability engineering under IEC 62366-1 are built into the process rather than added later, and phase-gate program management keeps each prototype tied to a documented design review. This spans everything from initial feasibility builds to the units that carry a design into transfer.
Talk to SJML’s engineering team →
Frequently asked questions
A prototype is built to test or demonstrate specific design features and is not intended for commercial distribution. A production unit is built using validated, controlled processes intended for consistent, repeatable output. Later-stage prototypes may closely resemble production units, but only validated production builds carry the full quality system controls required for market release.
There is no fixed number. It depends on device complexity, novelty, and risk. Simple mechanical devices might need two or three iterations; complex electromechanical or software-driven systems often need more, especially when usability testing or verification failures require design changes and re-testing.
Sometimes, if the prototype is representative of the final production device in materials, tolerances, and manufacturing process, and the build is properly documented and traceable. Data from early, non-representative prototypes is generally not acceptable for design verification or validation and should not be used to support a submission.
Early feasibility prototypes often fall outside formal design controls, but once a device program enters verification and validation activities, prototypes used to generate that evidence should be built and documented under the design control requirements in FDA 21 CFR 820.30 and ISO 13485.
Related terms
- Design Verification
- Design Validation
- Design Controls
- Design Transfer
- Design History File (DHF)
