Prototype

A prototype is a physical or functional representation of a medical-device design created to test specific features, performance, usability or manufacturability before the design is finalized. Within medical device design and engineering, prototypes can range from early proof-of-concept models to verification-grade units manufactured under formal design controls before design transfer.

What is a prototype?

A prototype is any physical or functional representation of a medical device built before the product design and manufacturing configuration are finalized.

A prototype may be:

• A foam model used to evaluate size and handling
• A 3D-printed housing used to assess fit and ergonomics
• A benchtop circuit used to demonstrate technical feasibility
• A software user-interface simulation
• A functional subassembly
• A fully integrated device built with production-intent materials
• A pilot-production unit manufactured using the planned production process

A prototype does not need to look like a finished commercial product. Its purpose is to answer a defined engineering, manufacturing, usability or clinical question.

For example, an early prototype may evaluate whether a pumping mechanism can deliver the required flow rate. A later prototype may determine whether representative users can operate the device safely. A verification-grade unit may be used to demonstrate that the finished design meets approved performance requirements.

An electromechanical medical device often requires several coordinated prototype streams. Mechanical structures, electronics, firmware, sensors, actuators and user-interface elements may initially be developed separately before being combined into an integrated system.

Types of medical-device prototypes

Medical-device teams commonly progress through several prototype levels as the design matures. The terminology varies among organizations, but the underlying progression is similar.

Proof-of-concept prototype

A proof-of-concept prototype evaluates whether the fundamental technical idea can work.

It may use:

• Off-the-shelf components
• Development boards
• Temporary wiring
• Generic materials
• Simplified software
• Laboratory fixtures
• Oversized or non-representative components

A proof-of-concept model is normally unsuitable for formal verification because it does not represent the intended production design. Its job is to reduce technical uncertainty before substantial investment is made.

Appearance or form prototype

An appearance prototype evaluates the device’s external size, shape, visual design and physical relationship with users or surrounding equipment.

It may be used to review:

• Product dimensions
• Grip and handling
• Control placement
• Screen position
• Cable routing
• Port accessibility
• Compatibility with the use environment
• Industrial-design direction

These models may have little or no internal functionality.

Functional prototype

A functional prototype demonstrates one or more intended device functions.

It may integrate working electronics, software, sensors, mechanisms or fluid paths without using the final enclosure, materials or manufacturing processes.

Functional prototypes help teams evaluate:

• Performance feasibility
• Component selection
• Control algorithms
• Thermal behavior
• Signal quality
• Power consumption
• Mechanical loads
• Failure modes
• Subsystem interfaces

Alpha prototype

An alpha prototype combines major subsystems into an early integrated device. It may resemble the intended product but still use prototype-grade components, temporary manufacturing methods or unfinished software.

Alpha builds are useful for:

• System integration
• Architecture evaluation
• Early usability studies
• Risk-control development
• Preliminary electrical-safety testing
• EMC pre-scans
• Reliability exploration
• Design-for-manufacturability reviews

Beta or production-intent prototype

A beta prototype more closely represents the planned production device. It should use production-intent materials, components, tolerances, software and assembly methods wherever possible.

These units may support:

• Formal usability studies
• Design verification
• Packaging development
• Reliability testing
• Electrical-safety testing
• EMC testing
• Manufacturing-process development
• Regulatory evidence generation

Any differences between the prototype and the planned commercial device should be documented and evaluated for their potential effect on test validity.

Verification-grade prototype

A verification-grade prototype is built to support formal design-verification testing. It should represent the approved design configuration closely enough that the resulting evidence applies to the product intended for release.

The team should document:

• Applicable design revision
• Bill of Materials revision
• Software and firmware versions
• Materials and component specifications
• Manufacturing processes used
• Unit serial numbers
• Deviations from the production configuration
• Justification for any deviations
• Inspection and release status

Pilot-production unit

Pilot units are built using production-intent equipment, tooling, work instructions and quality controls. They help demonstrate whether the manufacturing process can produce conforming devices consistently.

Pilot builds may support:

• Process validation
• Operator training
• Fixture qualification
• Production-line balancing
• Packaging validation
• Final device validation
• Manufacturing-yield assessment
• Design-transfer completion

Why prototypes matter in medical-device development

Prototyping is where design assumptions encounter physical reality. A design that appears sound in drawings or simulation may behave differently when materials, tolerances, user interaction and subsystem interfaces are introduced.

For regulated medical devices, discovering problems early has significant financial and regulatory value. A design issue found in a foam model may require only a few hours of redesign. The same issue discovered after design transfer may require new tooling, controlled design changes, repeated testing and updated regulatory documentation.

Prototypes help teams:

• Demonstrate technical feasibility
• Evaluate alternative design concepts
• Identify integration problems
• Refine requirements
• Develop and verify risk controls
• Assess usability
• Evaluate manufacturability
• Prepare test methods
• Estimate production costs
• Reduce development uncertainty
• Generate controlled design evidence

Prototypes also contribute to verification and validation. Verification confirms that design outputs meet approved inputs, while validation confirms that the finished device meets user needs and its intended use.

The distinction between prototype stages is important. Evidence from an early, non-representative prototype generally cannot demonstrate compliance for the finished device. If a unit used for formal testing has different materials, tolerances, software, components or production processes, the manufacturer must determine whether those differences affect the validity of the results.

Regulators and auditors may examine whether tested units genuinely represent the final design. Using a non-representative prototype without adequate justification can invalidate otherwise successful testing.

The prototype-development process

Prototyping in a design-controlled environment is not a single build. It is a sequence of planned builds, each associated with a defined objective and appropriate level of control.

1. Define the question

Every prototype should exist to answer a specific question.

Examples include:

• Can the proposed mechanism generate enough force?
• Will the sensor achieve the required accuracy?
• Can representative users connect the disposable correctly?
• Does the enclosure provide adequate ingress protection?
• Will the device remain within acceptable temperature limits?
• Can the assembly be manufactured within the required tolerances?
• Does the risk control prevent the identified hazardous situation?

The question should connect to a requirement, identified risk, design decision or development uncertainty.

2. Define the prototype’s intended use

Before building, document how the prototype will be used.

A prototype may be intended for:

• Internal engineering evaluation
• Demonstration
• Formative usability testing
• Risk-control evaluation
• Test-method development
• EMC pre-compliance testing
• Formal design verification
• Design validation
• Manufacturing-process development
• Pilot production

Defining its intended use helps determine the necessary fidelity, controls and documentation.

3. Establish acceptance criteria

Where practical, define what constitutes a successful prototype before testing begins.

Acceptance criteria may include:

• Performance thresholds
• Dimensional limits
• User-task completion
• Thermal limits
• Electrical characteristics
• Mechanical strength
• Accuracy or repeatability
• Assembly time
• Manufacturing yield
• Failure behavior

A prototype should produce a decision, not merely an observation.

4. Translate requirements into a controlled build

Approved design inputs, engineering requirements and risk controls are translated into models, drawings, software, specifications and build instructions.

Computer-Aided Design (CAD) models may define prototype geometry, component interfaces and tolerance requirements. A controlled build package may also include:

• Engineering drawings
• Schematics
• Bill of Materials
• Software or firmware version
• Assembly instructions
• Material specifications
• Inspection criteria
• Approved deviations

Revision control should begin early enough to identify which design produced each physical unit.

5. Select the appropriate fidelity

Prototype fidelity describes how closely the build represents the intended final device.

Important fidelity dimensions include:

• Geometry
• Materials
• Components
• Tolerances
• Weight
• Surface finish
• Software
• Manufacturing processes
• User interface
• Packaging
• Sterilization state

Not every prototype needs maximum fidelity. The level should be sufficient for the specific question being evaluated.

6. Choose the build method

Early prototypes may use:

• Additive manufacturing
• CNC machining
• Vacuum casting
• Laser cutting
• Soft tooling
• Breadboard electronics
• Development boards
• Temporary wiring
• Simulated software
• Commercial off-the-shelf components

Later builds should move toward production-representative tooling, materials and processes when the evidence must apply to the final design.

7. Build under configuration control

Each unit should be identifiable. Even early feasibility prototypes benefit from:

• Serial or unit numbers
• Build dates
• Revision identifiers
• Component records
• Software-version records
• Deviation logs
• Inspection status
• Build photographs
• Test history

Configuration control prevents teams from confusing test results from different prototype versions.

8. Test against the objective

Testing should follow the predefined purpose and acceptance criteria. Results may feed into:

• Design inputs
• Architecture decisions
• ISO 14971 risk management
• IEC 62366-1 usability engineering
• Test-method development
• Verification plans
• Manufacturing requirements
• Supplier specifications

Failures are valuable when they are documented and used to improve the design.

9. Review the results

A design review should determine:

• Whether the prototype answered its intended question
• Whether acceptance criteria were met
• Which risks or assumptions remain open
• Whether the design needs revision
• Whether another prototype iteration is necessary
• Whether the program is ready for higher-fidelity development

The review should document decisions, actions, owners and completion dates.

10. Advance through controlled gates

Prototype maturity should align with the program’s Phase-Gate Process. A program should not advance simply because a build has been completed.

The relevant gate should confirm that the prototype generated sufficient evidence to support the next development stage.

This iterative loop continues until the design is mature enough for formal verification, validation and design transfer.

Prototype fidelity and regulatory evidence

Prototype fidelity is especially important when test data will support a regulatory submission.

A verification or validation unit should generally represent the planned production device in:

• Design configuration
• Critical components
• Materials
• Dimensions and tolerances
• Software and firmware
• Manufacturing processes
• Assembly methods
• Risk controls
• Labeling where applicable

If differences remain, the team should document:

1. The difference
2. Why it exists
3. Which requirements or risks it could affect
4. Why the test result remains applicable
5. Whether supplementary testing is required

Testing a representative unit does not necessarily mean using equipment from a fully validated production line. However, the manufacturer must demonstrate that prototype construction differences do not undermine the conclusions drawn from the test.

Common challenges and best practices

Treating all prototypes as equivalent

A proof-of-concept model and a verification-grade unit serve different purposes. Successful testing on an early prototype does not automatically demonstrate that the released design meets its requirements.

Define prototype tiers and the evidence each tier may support.

Insufficient documentation

Teams often move quickly during feasibility and fail to record component substitutions, software versions or assembly deviations. Months later, they cannot determine which configuration generated an important result.

Maintain proportional but useful build records from the beginning.

Poor configuration control

Two prototypes that look identical may contain different firmware, components or internal revisions. Without unit-level configuration records, test evidence can become ambiguous.

Assign serial numbers and maintain a configuration record for every test unit.

Using non-representative units for verification

A prototype may pass testing even though it uses a stronger material, tighter tolerance or different production process than the commercial device.

Confirm representativeness before formal testing begins, not after the report is completed.

Delaying manufacturing involvement

An engineering prototype may work but remain difficult or expensive to produce. Manufacturing engineers should review the design during early prototype stages to identify tooling, assembly, inspection and process risks.

Ignoring prototype-specific risks

Prototype units may lack production guards, insulation, labeling or software protections. Define who may use them and under what conditions. Test personnel should understand any differences from the final safety configuration.

Underestimating verification-grade build time

Production-intent parts, controlled components, inspected assemblies and complete documentation take longer than informal engineering builds.

Include realistic time and budget for verification-grade prototypes in the program schedule.

Prototype-development best practices

Strong teams generally:

• Assign a clear objective to every prototype.
• Match fidelity to the question being evaluated.
• Establish acceptance criteria before testing.
• Use controlled CAD, drawings and Bills of Materials.
• Identify every test unit with a serial number.
• Record components, software versions and deviations.
• Connect results to requirements and risks.
• Involve manufacturing before tooling decisions are finalized.
• Review representativeness before formal verification.
• Document why prototype evidence applies to the final design.
• Treat unsuccessful builds as controlled learning.
• Use formal design reviews to approve progression between prototype levels.

Design transfer and pilot manufacturing

The final prototype stages connect development to medical-device contract manufacturing.

During design transfer, the team converts the approved design into controlled production information, including:

• Released drawings
• Product specifications
• Approved Bill of Materials
• Work instructions
• Inspection criteria
• Manufacturing fixtures
• Test equipment
• Packaging instructions
• Labeling requirements
• Supplier controls

Pilot manufacturing determines whether the proposed production system can build the device consistently. Feedback may require updates to tolerances, fixtures, assembly methods or inspection plans before the design and processes are fully released.

Prototype and pilot-build records therefore form an important bridge between design outputs and validated production.

How SJML helps with prototypes

SJML supports medical-device programs from initial concept models through functional, verification-grade and design-transfer-ready prototypes. Multidisciplinary teams work across mechanical engineering, electronics, embedded software, firmware and systems engineering.

Prototype builds are supported by in-house laboratories for:

• IEC 60601 electrical-safety testing
• EMC testing
• Reliability testing
• Environmental testing
• Endurance testing
• Engineering bench evaluation

ISO 14971 risk management and IEC 62366-1 usability engineering are integrated into the process. Phase-gate program management keeps each prototype associated with a documented objective, review and development decision.

This support spans early feasibility builds, integrated electromechanical prototypes, production-intent verification units and the pilot builds used to carry an approved design into manufacturing.

Frequently asked questions