The Medical Device Development

Process at DeviceLab
Part 1: Introduction 3
A Medical Device Development Model 3
The Model: Tracks, Phases, and Tasks 3

Part 2: The 6 Phases of a Medical Device Development Project 5

The Research Phase 5
The Proof-of-Concept Phase 6
The Alpha Phase 7
The Beta Phase 8
The Pilot Production Phase 9
The Manufacturing Phase 10

Part 3: The FDA “Waterfall” and DeviceLab’s 6 Phases 12

Part 4: The 6 Development Tracks - Design in Parallel 14

The Intellectual Property Track 14
The Medical Product Development Track 15
The Risk Management Track 15
The Manufacturing Track 15
The Human Factors Track 16
The Regulatory Track 16
Conclusion 17

Part 5: Agile Hardware Development - Why It’s Important to Iterate a Design 18

Part 6: The Project Management Process at DeviceLab 20

Part 7: Leveraging Prototypes in Medical Device Development 22

Research Phase 22
Proof-of-Concept Phase 22
Alpha Phase 22
Beta Phase 23
Pilot Production Phase 23
Manufacturing Phase 23
Conclusion 23

Part 8: Tips for Outsourcing Medical Device Development 24

Scope of Projects 24
Micro-management 24
Subcontractors 25
Development Contracts 25
Communications 25
Points of Contact: 25
Work Tracking: 26
Planning: 26
Conclusion 26

Part 9: When to Invoke Design Controls in a Medical Device Project 27

Part 1: Introduction
In this nine-part series of blog posts, we’ll be talking about the process of medical device
development practiced at DeviceLab.

Some of the information discussed will be the implementation of internationally recognized

standards for quality systems, and the distillation of 20 years’ experience in project
management, design, and engineering. You’ll learn how we organize our efforts and resources,
and how we manage activities, timelines, and budgets. We also describe our commitment to
producing optimal designs through iterative development practices and building prototypes.

A Medical Device Development Model

DeviceLab has refined a model of medical device development that captures both regulatory
imperatives and best practices in business and engineering. This blog series presents that
model and explores how it accomplishes the goals we set for it. While some products are too
simple or too complex for this model, most projects benefit from iterating the product through
four design embodiments that we’ll call ​Proof-of-Concept​, including;

● AlphaBeta
● Pilot Production
● Manufacturing

Each of these embodiments is associated with a set of goals and requirements that become
more complex and stringent over time. This “multi-pass” approach facilitates thorough
debugging, selection of best options, and design for manufacturing and testing. Most projects
also incorporate a Research Phase where conceptual design is performed prior to invoking
Design Controls.

The Model: Tracks, Phases, and Tasks

The DeviceLab RoadMap below diagrams how we organize our projects. Time flows left-to-right,
and the six tracks (rows) shown represent different functional areas of the effort, with tasks
generally being performed by the same specialists over the course of the program. In each
track, individual tasks are shown, but they really represent just a summary of the actual tasks in
the plan. Some projects won’t need all these tasks, and tasks can slide forward or backward
when opportunities or problems present themselves. In that way, we adapt our RoadMap to the
needs of the individual client.
We’ll dig deeper into the process depicted in our RoadMap in this series. Below is a list of
upcoming titles:

● The Six Phases of a Medical Device Development Project

● The FDA “Waterfall” and DeviceLab’s 6 Phases
● ​6 Development Tracks: Design in Parallel

● ​Agile ​Hardware​ Development: Why It’s important to Iterate a Design

● The Project Management Process at DeviceLab

● ​Leveraging Prototypes in Medical Device Development

● Tips for Outsourcing Medical Device Development

● ​When to Invoke Design Controls in a Medical Device Project

Please stay tuned for each of these posts. Together they’ll give you a good view of how medical
devices are designed – all the way from ideas to products that make patients’ lives better every
day In our next post, we’ll talk about how DeviceLab organizes projects into six distinct phases,
and what gets done in each. See the ​Process​ and ​Compliance​ ​pages​ ​on our website for more
information on how we do things.
Part 2: The 6 Phases of a Medical Device
Development Project
In the second part of this series, we explore the temporal aspect of projects. What
follows is a description of how DeviceLab organizes the sequence of events in a project
into distinct phases.

We typically employ six phases for every project. Sometimes we participate in all of these
phases, while in other projects our clients bring us in for a limited period. For each phase below,
there’s a brief description of its purpose, activities along our RoadMap’s parallel design tracks,
what sorts of prototypes might be made, and the criteria used to advance to the next phase
(phase gate).

The Research Phase

Purpose​: To discover everything you need to know about the user, use the environment,
product, market, technology, regulatory landscape, and intellectual property situation to make a
go/no-go decision on proceeding with a medical device project.

Intellectual Property​: Work begins with patent searches followed by analyses of patentability
and freedom to operate. Based on the results of these analyses and what markets are targeted,
a legal strategy can be established for protecting IP developed and/or mitigating the business
impact of existing patents.

Product Development​: Designers start with design research and conceptual design.
Competitive and alternative products are investigated as baselines, and “blue sky” ideation is
applied to develop a range of design alternatives. Sometimes the design work of the research
phase can be accomplished very quickly (e.g., “me too” products), while other times, it is
necessary to do conceptual design renderings and even simple prototypes to convince
everyone that success is possible. While DeviceLab is typically not involved, our clients also
focus on validating the clinical need, researching pricing and reimbursement, and sketching out
how the product might be marketed.

Prototypes​: In the Research Phase, prototypes are generally just mockups with little function,
produced in small quantities. They are typically used for fundraising presentations and Key
Opinion Leader discussions.

Risk Management​: Activities start with an evaluation of known hazards (typically from predicate
devices), and once a design concept is established, consideration of safety characteristics is
taken into account.

Manufacturing​: Development begins with a process plan – how each of the components will be
made and assembled based on the conceptual design. Tradeoffs based on expected production
volumes are considered, and investigations are begun into whether needed capabilities are
available.

Human Factors​: Work begins with a consideration of who the Users are (patients, doctors,
nurses) and the Use Environment (hospital, office, home, mobile), followed by a definition of the
Intended Use and User Needs.

Regulatory​: Activities begin in the research phase with a search for predicate devices and an
analysis of classification and applicable standards for the device. Based on this information, an
initial regulatory strategy can be developed for target markets.

Phase Gate​: The basic question being asked in the Research Phase is, “Is there a product
here?” By this, we mean:

● ​Is there a real clinical need?

● Can our device address that need?
● ​Does it have a competitive advantage?

● ​Can we build it?

● Can we get it approved for sale?

● ​Can we protect it with a patent?

● Can we market/sell it profitably?

It may not be possible to answer these questions fully during the Research Phase, but if the
team’s impression is that the answers are probably “yes,” then the project can be greenlighted.

The Proof-of-Concept Phase

Purpose​: In the Proof-of-Concept Phase, the team seeks to identify and eliminate any fatal
weaknesses in the design concept established in the Research Phase. There may be questions
about safety, efficacy, cost, ease of manufacture, regulatory uncertainties, or patentability that
should be identified, ranked, assessed, and summarized. If uncertainty remains, more research
is done and test systems or subsystems are prototyped and tested to answer these questions.
This is also the time where Design Controls are usually invoked, starting with a formal release
with documents worked on in draft form during the Research Phase.

Intellectual Property​: Work begins on provisional patent applications for key elements of the
product with disclosures of invention by team members.

Product Development​: The next step is to evolve the conceptual design into a preliminary
design, incorporating enough features and details that it can be prototyped and tested.
Placeholder components in the research phase design are specified in greater detail, and
interfaces between components are designed. System diagrams are created, and preliminary
software requirements are developed.
Prototypes​: Proof-of-Concept prototypes are produced (often by additive manufacturing) in
intermediate quantities and a variety of configurations in this phase. Software deliverables are
typically just for demo at this stage, and mechanisms are simple breadboards.

Risk Management​: A Use Hazard Analysis is developed based on the evolving design,
considering intended uses and foreseeable misuses. The risks assessed here are those of the
actual use of the device on patients, not the failures of the device to operate as designed.

Manufacturing​: Some products are so novel or contain such novel components that they
require the development of new processes to make them. In the POC stage, preliminary
vendors are found, and experiments are performed to demonstrate that an effective way exists
to manufacture the device.

Human Factors​: Based on the User Needs, Human Factors work proceeds into the design of
interfaces inherent in the design. Considerations include physical shape/size, controls, displays
& annunciators, ergonomics, and safety.

Regulatory​: The regulatory strategy is now crystallized into Regulatory Requirements in the
Requirements Trace Matrix, and a formal Design Plan is created, including all the tasks implied
in the strategy.

Phase Gate​: At the end of the Proof-of-Concept Phase, the team should be convinced that
there are no insurmountable problems ahead and that solutions have been identified for all
known issues. While the conceptual design may be simple, it should indeed “prove the concept.”

The Alpha Phase

Purpose​: In the Alpha Phase, the design is refined to incorporate the learnings from
proof-of-concept evaluations, to seek out the best alternatives among the many ways most
devices can be built, and to explore the many tradeoffs inherent in any design.

Intellectual Property​: Work continues with the development of alternative embodiments for the
device, as well as methods of making or using the device.

Product Development​: In the Alpha Phase the POC design is refined, eliminating placeholder
components. Detailed design of the parts is begun, and functional code modules are developed
and connected. Components and subsystems are tested to assure needed performance can be
obtained.

Prototypes​: Alpha prototypes are made to facilitate testing and user evaluations, aiming to
show that proven concept can be an actual product. These prototypes are sometimes both
aesthetic and functional (but usually limited to a few functions of interest). In Alpha prototypes,
the software is usually demonstrated offline, often using a non-functional simulation. Electronics
might be spread across the lab bench and hooked up to instruments, but basic functions are
shown to be operable. Mechanisms, sensors, and interconnects are selected, and software
tools and platforms are established. Occasionally, several design embodiments may survive
and compete through the Alpha stage.

Risk Management​: Now that the design concept is firming up, the risks in the design can be
identified and evaluated, using tools such as FTA, FMECA, etc. Plans for risk mitigation are
formed and put into place. While the design is still evolving, much of this work can be done at
this time.

Manufacturing​: Around this time, it’s important to begin the process of vendor selection and
qualification. Oftentimes our clients need no new vendors, but any new design may bring new
requirements those vendors must agree to and comply with.

Human Factors​: With Alpha Prototypes and user testing, the interface design candidates are
finalized, and a protocol for the Formative Study is written.

Regulatory​: Important tasks in this phase include the release of the Design Input Requirements
and a Requirements Traceability Matrix.

Phase Gate​: At the end of the Alpha Phase, the team should be convinced there’s a proven
way to make the device. All of the important design options have been explored, and choices
made among them.

The Beta Phase

Purpose​: In the Beta Phase, the design incorporates features that aren’t necessary during
earlier evaluations, like shielding, water ingress, and safety features. Prototypes are built that
combine functions that may have been demonstrated separately during Alpha. Details like
assembly breakdowns, fastening methods, the system block diagram, and software division of
labor are decided upon and evaluated with Beta Prototypes. Material selection, especially for
patient contact components, and packaging design, are begun. The design is reviewed for
manufacturability, and any issues are addressed prior to tooling start.

Intellectual Property​: A lot is learned during medical product development, and in response,
there are often additional patents, continuations, or divisionals that need to be filed. Depending
on the markets sought, foreign patent applications may be filed.

Product Development​: In the Beta Phase design documentation is assembled into a Device
Master Record. Preparations are made for Design Verification and Validation testing, including
the development of protocols and liaison with outside labs. Any design issues that arose in
Alpha Phase testing must now be resolved.

Prototypes​: Beta prototypes are made as needed to support refinement testing and user
evaluations post-Alpha. There is typically only one embodiment tested at this stage.
Risk Management​: Risk Mitigation is the primary task in this phase, including verification of
mitigation. Aside from the risks associated with manufacturing processes, all known risks should
be mitigated to acceptable levels.

Manufacturing​: At this time, the design of many parts are already frozen, and tooling
production can begin. Arrangements are made with vendors for the production V&V (verification
and validation) units, and work instructions for any new processes are written.

Human Factors​: Using Beta prototypes, the Formative study is performed, and any findings
impacting the design are incorporated into the Pilot Production version.

Regulatory​: In the Beta Phase, the Device Master record is compiled and critically reviewed for
Pilot Production suitability.

Phase Gate​: With the update of the design based on the learnings of the Beta phase, the
design is frozen. It’s expected that any design changes proposed during or after Pilot Production
will be minor enough as to require little or no re-validation. The big question at this time is
whether the product is “Pilot Production-ready,” including all parts of the supply chain.

The Pilot Production Phase

Purpose​: In the Pilot Production Phase, the primary purpose is to work out any bugs in making
the product in volume. It’s also the time where V&V and safety testing is performed, and where
much of the paperwork is wrapped up.

Intellectual Property​: Prior to this time, it’s safe to be stealthy, but when your baby leaves
home, it needs protection. If any patentable art hasn’t been filed, it gets filed now.

Product Development​: This phase is all about V&V testing, including building the test units.
Activities include a lot of vendor liaison and paperwork.

Prototypes​: Pilot Production units are as close to sales units as we can make them so that V&V
testing remains valid when you enter production. Depending on the types of V&V tests required,
they may be produced in anywhere from tens to thousands of units. Pilot Production prototypes
are also often used for sales and support training.

Risk Management​: As the manufacturing processes have been established, a Process FMEA
(failure mode and effects analysis) can be performed and used to mitigate any risks found.
Together with the Use and Design analyses, residual and overall risks can be shown to be
mitigated to an acceptable level.

Manufacturing​: This is a very busy time, with operator training, process validation, and the
manufacture of Pilot Production units.
Human Factors​: Using Pilot Production prototypes, the Summative study is performed,
demonstrating that the device will be properly and safely used.

Regulatory​: At this time, activities depend on the device classification. Tasks may include
preparing technical files, 510(k) submissions, PMA supplements, or IDE filings. Clinical trials are
performed, and preliminary meetings are held with FDA, Notified Bodies, Institutional Review
Boards, and Ministries of Health.

Phase Gate​: The Pilot Production Phase ends when development is over, and manufacturing
begins in earnest. So, the phase gate questions are all about “is it ready to sell”:

● Is the design Verified and Validated?

● ​Have all individual risks and overall risk shown to be acceptable when compared to

benefits?
● Has all-important intellectual property been secured by patent, license, or other means?
● ​Are all regulatory requirements fulfilled?

● ​Is the design properly documented in the DMR?

● ​Is the development properly documented in the DHF?

● ​Is the design intuitive, ergonomic, and safe to use?

● Are the manufacturing processes capable?

● Can the device be produced for an acceptable cost?

The Manufacturing Phase

Purpose​: This is the only phase where a long duration is desirable. At this time, you want the
development team to be done and off on their next project. This is only possible if the design
has been properly transferred during Pilot Production, and the Manufacturing team knows
everything it needs to.

Intellectual Property​: When you start selling your product, the competition may try to invalidate
some of your IP (intellectual property) or show that you infringe on some of theirs. Defending
your IP against such assaults, and extending the range of your patent umbrella become the
important things. It’s also a time to consider whether other companies might benefit from your
inventions and would be willing to pay for a license.

Product Development​: It’s done now. Negative customer feedback or adverse events are two
ways that the design team might be called back in to help evaluate device failures or assist in
any needed redesign and revalidation. Customer feedback sometimes identifies opportunities
rather than problems and a re-design might stem from one of these.

Prototypes​: Prototyping is also over, except to support any redesign efforts arising from
post-market feedback. Prototyping resources may be involved in making tools for support and
training activities.
Risk Management​: Once a product is in production, Risk Management takes a monitoring role
for the field use of the product and the processes used to make it. When any new risk-pertinent
information comes in from the field or if any design changes are made, Risk Analyses may need
to be performed again.

Manufacturing​: Production, support, and service are the focus now. Efforts to reduce COGS
(cost of goods sold), improve process capability, reduce WIP (work in progress) and lead time,
or increase quality become routine work.

Human Factors​: As with Risk Management, Human Factor issues may arise if users find a new
way to misuse the product, or if continued use results in ergonomic or safety issues.
Documentation such as manuals and labeling may require revision to address such issues.

Regulatory​: Maintenance of the system established during the design by monitoring and
measurement, quality audits, CAPA (corrective and preventive action), and management review
is the mission. In the case of adverse events or complaints, it may be necessary to perform
investigations and notify regulators.

Phase Gate​: Manufacturing ends when you don’t want to sell the product anymore. But as long
as your product is in the field, you remain responsible for it in many ways. Before you can kill a
product, you need to plan for how you will continue to service and support existing customers,
transition them to your new product, or even decommission equipment.

So, that’s how we look at projects here at DeviceLab. In our next post, we’ll talk about how
DeviceLab’s process for medical device development compares to the famous FDA “waterfall”
diagram. See the Process and Compliance pages on our website for more information on how
we do things.
Part 3: The FDA “Waterfall” and DeviceLab’s 6
Phases
You’ve all seen it. It’s one of the first slides in the Design Controls training class deck:

FDA Waterfall Image Credit

It’s a description of the interactions between certain factors and processes in the development
of medical devices. In the white boxes are a series of steps from User Needs to the Medical
Device, with progression governed by Design Reviews, and based on two comparisons: Design
Output to Input during Verification and Medical Device to User Needs during Validation. This
structure is a logical construct; more a map than a plan. It also omits the required steps of
Design Planning and Design Transfer, but that’s because they don’t participate in the explicit
feedback loops that are the meat of the diagram.

While this map is intended to drive the development process to a high assurance of safety and
efficacy, it cares not about business imperatives and offers no help on how to actually design a
device or run a project. This is deliberate – people can find many ways to accomplish things,
and the FDA doesn’t care how you do it as long as your process incorporates the necessary
controls and can prove that they work. So, each organization that seeks to develop a medical
device must develop its own system for product development that meets regulatory
requirements and works for their particular needs.
At DeviceLab, we have developed a framework for medical device projects that incorporates six
phases (see the prior post in this series for more details). These phases are established to
capture the elements of the waterfall diagram, as well as an iterative development approach so
successfully employed in Agile Software Development. Of course, some projects are so much
bigger or smaller than typical that this model can’t be applied, and often we get involved with a
subset of the phases. However, this framework is a useful tool for thinking about the
organization of a project, regardless of size.

So, how does our six-phase approach map to activities on the traditional FDA waterfall? While
not an exact match, here’s what we deploy:

● Proof-of-Concept maps to Design Planning

● ​Alpha maps to Design Inputs

● ​Beta maps to Design Output

● Pilot Production maps to Design Verification and Validation

● Manufacturing maps to Design Transfer

We work by incrementally chipping away at the very long list of things to do in digestible chunks
along six parallel design tracks. We see the FDA Waterfall as a framework by which an evolving
design progresses through successive versions, each accomplishing a greater portion of the
requirements until they are all satisfied.

In our next post, we’ll talk about the six parallel tracks of activity that operate during a medical
device project. You’ll learn more about how the project looks to each of the various disciplines
involved and how they cooperate to achieve your goals. Please visit the Process and
Compliance pages on our website to find out how we do things.
Part 4: The 6 Development Tracks - Design in
Parallel
Medical device development is an interdisciplinary task. Designers, engineers, scientists,
manufacturing, regulatory, medical, legal, and business specialists all work together toward a
common goal but have distinct contributions to the medical device development. At DeviceLab,
we’ve organized these efforts into six tracks, which covers the needs of most projects. Our
RoadMap below shows this structure graphically.

The Intellectual Property Track

This track begins with patent disclosures and searches and continues through a Freedom to
Operate and Patentability analysis. As the product design evolves, provisional patent
applications are prepared and alternative embodiments, such as “methods of making” and
“picket fence” ideas are explored. One the design is mature, but before public disclosure, key
design and method patents are filed. After this basis is established, an international IP strategy
is implemented, and any available licensing options are explored.

While much of this work is done by lawyers, the development team contributes many of the
ideas, depictions, data, and technical argument. There is often some patent coverage extent
before the start of a project, but valuable additional art is usually acquired during product
realization, especially alternative embodiments and discovery of key design parameters.

The Medical Product Development Track

Product Development begins with Research and Conceptual Design. Building on this concept
and User Needs, regulatory requirements, predicates, and known hazards, designers and
engineers craft Design Input Requirements that capture the essential features of the intended
product. Working from these inputs, the team creates and tests multiple iterations of the product
design until all requirements appear to be met, and records the resultant design as Design
Outputs. When Outputs are complete, they are compared against the Design Inputs in Design
Verification, and the medical device itself is compared against the User Needs in Design
Validation. Design Transfer follows, to ensure that the design is correctly transferred to
manufacturing (Device Master Record) and all requirements will continue to be met. Throughout
the process, a Design History File is accumulated.

Product Development is often done by specialist engineers and designers, rather than the
inventor or technical team of the manufacturer. Along the way, multiple prototypes are created
and tested, and design reviews are executed to ensure that the project is meeting its goals.

The Risk Management Track

Risk Management starts with an investigation of similar products and known hazards, and as a
design concept emerges, a consideration of safety characteristics. In combination with User
Needs, Intended Use, foreseeable misuses, and regulatory requirements, a Use Hazards
Analysis is performed so that mitigation means can be incorporated into the design. Once
detailed design features are established, Risk Analysis using tools such as FTA, FMECA, etc.
are applied. Hazards are mitigated as far as possible and verified in the Risk Management
Report. During Pilot Production, a process FMEA is performed, and residual and overall risks
are assessed to ensure acceptability. Before transfer to manufacturing, a HACCP analysis is
performed and a control plan is implemented. Depending on the device, Post-Market
Surveillance systems may be established.

Depending on the size of the organization, the team players on the Risk Management Track
may be specialists or the same people performing the design, human factors, manufacturing, or
regulatory tracks. Many companies rely on consultants for tasks such as predicate and known
hazard research.

The Manufacturing Track

The Manufacturing Track starts with a plan to manufacture, assemble, test, and package the
device. If necessary, manufacturing processes are developed and demonstrated as a part of
Proof-of-Concept. Vendors are selected and qualified in the Alpha Phase, and tooling and work
instruction development follows in Beta. Operator training and process validation are completed
as the first part of Pilot Production, where units needed for validation testing, marketing, or other
purposes are produced. The Design Transfer Design Review marks the transition to production
for sale.

As with Risk Management, manufacturing specialists (with a contract manufacturer, for

example) can perform the tasks on this track, but they are often performed by development
engineers due to their familiarity with the design.

The Human Factors Track

30% of medical device adverse incidents reported to the FDA are user errors, not device
failures. Human Factors Engineering is applied to mitigate these risks by creating intuitive,
comfortable, and fault-tolerant designs with proper instructions and/or training. The process
begins with a consideration of user needs, combining information from literature, the MAUDE
reporting system, and user research. During Design Input, the device interfaces, intended uses,
and foreseeable misuses are considered. During Design Output, interface approaches are
prototyped and tested to assure that they address Human Factors properly. Approaching
Design Freeze, protocols are developed for Human Factors User Studies; generally, a
Formative Study followed by a Summary Study.

Most Human Factors/Usability engineering is typically performed by Industrial Designers

working with the engineers doing the detailed mechanical, electrical, system, and software
engineering.

The Regulatory Track

The Regulatory typically begins with a consideration of predicate devices. Even for entirely
novel devices, there may be predicates for major components or functions to be found in earlier
devices. Based on this review, a strategy can be formulated for regulatory approval in the
markets targeted. Beginning with an evaluation of the likely Classification (I, II, or III) of the
device, and requirements coming from consensus standards covering the device type (e.g., IOL,
heart monitor, scalpel) pertinent regulations can be applied. A plan for regulatory compliance is
incorporated into the Design Plan. During Design Input and Output, a Design History File is
maintained, and Design Reviews are performed to document compliance. During Design
Verification and Validation, protocols are populated with any tests required by regulation or
standard, and test outcomes are compared with requirements. Around the time of Design
Transfer, the Regulatory Track is usually consumed with the production and presentation of a
Design History File and Device Master Record in an approval process before FDA and/or an
ISO Notified Body.

Regulatory Track tasks are usually performed by specialists. At larger companies, these people
are usually in-house, but it is typical for startups and common for small companies to hire
regulatory consultants to help out.
Conclusion
We hope this look into how the various disciplines operating in a project work and cooperate
stimulates your thinking about how to accomplish project goals in device development. Our next
post in this series talks about how the Agile approach can be applied to the development of
hardware as well as software, and what benefits this approach provides to the client. See the
Process​ and ​Compliance​ ​pages​ ​on our website to learn more about how we do things.
Part 5: Agile ​Hardware​ Development - Why It’s
Important to Iterate a Design
In the Agile Manifesto, Agile Values are defined by a series of preferences:

1. Individuals and interactions​ over ​processes and tools

2. Working software​ over ​comprehensive documentation
3. Customer collaboration​ over c​ ontract negotiation
4. Responding to change​ over ​following a plan

All of these values can be applied to the development of hardware, but as others have noted,
hardware is different in procurement and changes lead times, component costs, and the
diversity of disciplines working in the team. Daily stand-up meetings may not be able to include
the whole team. New working deliverables can’t appear after an all-nighter. Making dramatic
changes late in the game can be a lot harder because component interfaces can be more
complicated.

Medical device projects face additional regulatory requirements that make it hard to adhere to
some of the values. One can’t work without a plan or comprehensive documentation (at least of
the final product), development contracts are required (as is vendor qualification), and
adherence to defined processes is beloved in the hearts of device manufacturers (and enforced
by their Quality Management Systems).

So, with all these obstacles, what parts of the Agile approach can be applied to hardware
development, specifically medical device hardware? DeviceLab does the following things to
implement Agile values in our work:

1. We take care in establishing our project teams to select not only the right technical
background, but also the right capabilities, desire, and fit with the rest of the team. We
collaborate very closely in a common workspace and with frequent client contact. Our
telecommunications infrastructure promotes high-bandwidth exchanges.
2. Comprehensive documentation, unfortunately, is a requirement in medical devices. We
can’t really value it very much, but we can be efficient about how much we do and when
we do it. Lots of important design questions in a project can be answered in a Research
Phase prior to invoking Design Controls, which significantly reduces paperwork. The
emphasis on working product over comprehensive documentation is something we
respect with a focus on the frequent delivery of working components and subsystems in
a series of prototypes with ever-improving fulfillment of design requirements.
3. DeviceLab believes that frequent client feedback is essential for success in our projects.
We find that it’s better to have development contracts which don’t tie down requirements
too much too soon, and evolve the plan as we go. We meet regularly with clients so that
they know exactly what’s going on. When the client is in the loop, and trust is earned,
 contracts can be less prescriptive and thus more flexible. And, everyone benefits by
spending less time on tracking and haggling over numbers that don’t measure success.
4. QMS regulations require that all medical development projects must have a plan and
that you actually use it. However, they ​don’t​ say a whole lot about just how detailed your
plan must be. They ​do​ say that plans can be revised during a project and encourage you
to do so. Everybody knows that things change during a development project. You
change course, like choosing to do something in hardware instead of software. While the
end device may look identical to the user, the development plan will be much different.
The trick to balancing these competing factors lies in developing plans that acknowledge
possible forks in the road and don’t contain unnecessary detail in future phases. We
then make it easy to revise the plan and review it regularly as we work through the
phases. For example, as we’re wrapping up the Beta Phase, we’ll update the plan for
Pilot Production phase from a simplified placeholder to a real plan for the upcoming
weeks or months.

It may seem like the dogma of Design Controls is incompatible with the Agile Manifesto, but it
turns out that you can adopt a lot of Agile thinking in medical device development. It’s really
more about teamwork and the process of doing development projects, so much of the Agile
mojo is available. See the ​Process​ page​ ​on our website for more information on how we do
things.

Following that line of thought, our next post is about project management specifically. We’ve
done a whole lot of projects at DeviceLab, so we have a few thoughts on the matter…
Part 6: The Project Management Process at
DeviceLab
Because we’ve done so many projects in our 20 years, we have developed a process for
managing projects that establish needed controls, allows our teams to work effectively, and
provides visibility to the client. This process is in compliance with regulations for outsourced
development work and embraces the values of the Agile manifesto.

Medical project development starts with a discussion. There are many things we need to learn
before we can determine that we have access to the skills needed for the project and that our
organization has the capacity to handle your project. We need to understand the technologies
involved, where you are in your work so far, and what goals you have for the product. This
discussion is usually between our client’s program manager and a few of DeviceLab’s senior
staff, often in a teleconference.

Based on all the input we receive, and if the project looks like a good fit for DeviceLab, we then
prepare a Project Proposal which includes a description of tasks to be performed, estimated
timelines and costs, and the deliverables to be provided. We submit our proposal and follow-up
with a call to answer any questions or make any requested tweaks. If the proposal meets with
your expectations, a Development Contract is executed, and DeviceLab begins work.

A Project Manager is assigned as the main point of contact for all business issues (budgets,
billing, and reporting), but they also serve as a technical leader for the DeviceLab team. We
appoint designers and engineers to the team so that it is properly resourced, and establish
project directories and charge numbers. A Project Plan is prepared so that you can see all of the
required tasks and can track progress against each one. The plan typically shows the first
phase in detail and the big picture in subsequent phases.

We like to start projects with a Kick-Off Meeting with all stakeholders present to make sure we
receive all inputs available. It’s a good way to make contacts within the team and achieve
consensus on the path ahead.

Once a project is underway, the project manager is responsible for keeping the customer in the
loop. Regular progress reports, detailed billing, and frequent meetings prevent runaway
projects. The project manager is also responsible for resolving technical disputes, providing
resources, and chairing meetings, including design reviews. As the project proceeds, the project
manager updates the project plan and associated cost and time estimates going forward.
When a project reaches completion, the project manager oversees the transfer of all of the
materials, product, and information accumulated back to the client. Records may be retained,
depending on the contract and whether future work is anticipated.
So that’s how we do project management at DeviceLab. We have a well-honed process that
keeps problems at bay and delivers quality designs by design. In the next post in this series,
we’ll talk about why we like to build prototypes in device projects, generally several times.
Part 7: Leveraging Prototypes in Medical Device
Development
There’s a long list of reasons why we believe it’s wise to build prototypes when you’re
developing a medical device, but the overriding reason is to facilitate learning. Even
experienced designers, aided by powerful design and analysis tools, learn a lot by building
prototypes. Predicting things like the best shape for a surgical handpiece or the best way to
organize an input form can be difficult without trying it out in actual or simulated use.
Performance of mechanical or electronic systems can be simulated, but simulations are rarely
complete and can be fooled by unexpected things in the real world. Only by building actual
prototypes you can interact with, criticize, and improve can you truly achieve an optimal design
for your product.

So, when should you build a prototype? How many should you build? What functionality should
they have?

Using our six development phases as a framework, what follows is a discussion of the
prototypes that might be made in a project, and their purposes and uses.

Research Phase
Prototypes made in this phase are usually about providing a tangible representation to facilitate
user discussions and support presentations for fundraising. They rarely are functional but are
sometimes made with fine finishes to appear realistic. Few units are needed, but there are often
multiple embodiments depicted. These prototypes are inexpensive and can be produced very
rapidly.

Proof-of-Concept Phase
In this phase, prototypes are used as tools to prove the product concept. Usually, they’re used
in tests of functions where there is some doubt about feasibility. This may mean whether users
can accept a surgical tool of this weight in the intended procedure, that a fluidic circuit can
separate cells as intended most of the time, or that a patient can understand what a diagnostic
device is telling them and act properly. It usually doesn’t take more than a few units to prove out
a problem area of a product concept, but there are sometimes several areas that need testing in
separate prototypes. Except in cases of high complexity, POC prototypes are usually modest in
price and can be built quickly.

Alpha Phase
Alpha Phase prototypes are used to determine specific use details and performances of the
device and to work out details of how it will be put together. These prototypes help work out the
specific requirements that are important to safety and efficacy and facilitate major design
decisions. Since Alpha testing is more specific and precise, multiple units may be required and
their functionality will be greater than POC prototypes. They will also be more expensive and
may take longer to build.

Beta Phase
Beta Phase prototypes are used to evaluate whole systems in the design. Final component
choices are often used, and things like battery life, cabling, ingress protection, grounding,
shielding, EMC, and ESD are subjected to preliminary tests. The quantity of Beta prototypes
needed varies by type of product, and the tests needed to verify required performances. Cost
and lead times are similar to Alpha prototypes.

Pilot Production Phase

Pilot Production prototypes can be extremely important. These units are intended to be
functionally equivalent to production units and are used in verification and validation testing. Any
design change after V&V testing may create the need for revalidation, so the design is generally
frozen after all the learnings of the Beta Phase have been incorporated. V&V protocols will
determine the number of pilot production units needed. These units generally cost a bit more
than production units due to small batch sizes and more expensive labor and take a little longer
to build.

Manufacturing Phase
The need for prototypes pretty much disappears when production units appear, but they are still
occasionally produced for trade shows and manufacturing operator, user, and sales training.
Sometimes units are built to show design options our client would like to explore or lacking
expensive or hazardous components to be used for demo only.

Conclusion
At DeviceLab, we make prototypes early and often throughout the process. It’s true that they
can sometimes be costly, but the learning they provide is invaluable. They also provide
assurance that things are on track in a project and reveal opportunities for design
improvements. Altogether, making prototypes is money well spent. Check out the Process and
Compliance pages on our website to discover how we do things.

In the next post in this series, we’ll talk about the design process from our client’s point of view
and offer several tips on how to successfully outsource design projects to companies like
DeviceLab.
Part 8: Tips for Outsourcing Medical Device
Development
DeviceLab has been doing medical device projects for 20 years, with over 100 major programs
completed. Our team also includes members who have worked at other design firms, and have
seen lots of different approaches to program management. As a result, we have developed a
set of practices that reduce friction, speed progress and maximize synergies. Looking at this
body of knowledge from our client’s point of view, we can offer a series of tips for doing
business with a firm like DeviceLab.

Scope of Projects
Our clients have a wide range of capability in-house. Some of them are large, capable
companies that come to us for work in a single discipline, like Industrial Design or Software
Engineering, because of our talents or experience in the field. Others are startups, seeking to
outsource all or nearly all of the development work. There are advantages to both approaches,
as well as difficulties. If you bring in just one discipline (say Industrial Design), you save money
by using your in-house Mechanical Engineers. However, you also accept the responsibility for
how ID interfaces with ME and Software. If both are outsourced, the coordination is our
responsibility and occurs between people that work together every day. Outsourcing entire
projects to a design firm puts all of your eggs in one basket but also precludes pissing matches
between multiple contractors when things don’t go right.

Design firms have a culture of moving fast that’s very hard to duplicate in a large firm. So even if
​ o some of it yourself, consider the advantages of outsourcing more to a company who
you ​can d
does new products every day. ​Our tip is to use a vendor who has the scope to handle all of the
things you need and put as much as you can on them.

Micro-management
Sometimes, our client contact is a development professional who cares deeply about the
process of design. If their ideas about program management differ from the project manager
DeviceLab has assigned, our contact may become overly involved in assignments, scheduling,
and work tracking in minute detail. This is counter-productive. Our project managers know how
to best leverage the talents of the teams we assemble and have a lot of experience in managing
disparate assets to accomplish plans. Insisting on justifications for minutes charged (for
example) not only takes your project manager away from value-added activities like resolving
technical issues but imparts a chilling effect on the team that makes them want to prematurely
end activities to meet a budget. ​Our tip is to resist the temptation to micro-manage a project.
Subcontractors
Sometimes, DeviceLab doesn’t have a specific skill (or enough bandwidth in a skill) to support a
project. We turn to our subcontractor network in these situations, a set of individuals and firms
we work with all the time. Our network contains resources with deep technical expertise, but it’s
also informed with their observed performance on multiple projects. In this sense, our
subcontractors are more deeply vetted than is possible for a company who doesn’t do a bunch
of development projects every year. ​Our tip is to let your design firm choose their subcontractors
– you may know a really great resource, but ours are great too, and we know how to work with
them.

Development Contracts
Medical device development work is usually outsourced under a development contract formed
between the design firm and client. The contract usually specifies the work to be performed, the
requirements imposed, the results expected, and estimated costs and duration. As development
work resolves many unknowns, it’s not possible to produce accurate budgets or timelines before
a project starts. Attempts to do so only create a dangerous fiction that can be clung to in the
face of a very different reality. Moreover,firms that claim to be able to do a large project on a
fixed bid are the same ones that come back for more money when you’re 80% done. ​Our tip is
that it’s more sensible to expect rough estimates for whole project budgetary purposes, and
specific budgets for only the current phase and the next one.

Communications
Many companies, especially large ones, have communication problems. People get comfortable
in their silos and don’t talk as much as they should. When you outsource a development project,
communications can be even worse, but they can also be better. Why is that? The internal
communication between the folks at DeviceLab is really great, probably better than in most of
our clients, and unlike your internal team members, our folks deal with outside contacts every
day. We’re also accountable for communications in a way that often exceeds the accountability
of our clients’ employees. What this means is that we can be trusted to hold up our end of
important knowledge flows. ​Our tip is to expect great communication about the project and insist
on it from start to finish.

Points of Contact:
In the same area of communications is the designation of points of contact in a program. Both
the client and DeviceLab must make it clear who is the point of contact for each topic or area.
We insist that all communications to DeviceLab be copied to the project manager, but we also
designate specific points of contact in-house who have assumed responsibility for portions of
the design like electronics or ID. To the extent that client employees are also working on the
project, it’s important to designate specific ones as points of contact, empower them, and assign
responsibility for liaison with the design firm resources. ​Our tip is to make sure you know who is
responsible for each aspect of the project, both in-house and at the design firm.

Work Tracking:
Every project establishes expectations when started, and nobody wants to wait for the end to
know whether those expectations will be met. This impatience expresses itself as a desire for
information that purports to measure progress so that the measurement can be compared to the
expectation. While it’s true that “% of task effort completed” and “% of task budget spent” can be
compared to measured progress, it’s important to remember that the budget is a number you
estimated before you began and the % completed is an estimate from a worker still working the
incomplete task. It’s dangerous to fall into the trap that the plan is infallible in predicting effort
and browbeat individuals because unknown things changed our predictions of reality. ​Our tip is
to use progress tracking at a coarse level – ignore individual tasks and focus on phases to
manage budgets and schedules.

Planning:
You have to have a Design Plan in any medical device project. You may already have created
one – if so, that’s great. You may also have a plan for the development project, including things
that don’t bear mention in the Design Plan. In fact, most clients walk in with one or both of these
plans at some level. So, we see a lot of plans for medical device development,and have written
many ourselves. What we’ve learned is that planning new product development is different from
planning more predictable activities like putting up a new commercial building. There is far more
uncertainty, including the “unknown unknowns,” which are impossible to plan for. Fortunately,
reducing this uncertainty is a prime objective of development, so as a project moves forward our
view of the future improves. ​Our tip is to plan the distant future in broad terms and the near
future in specific terms, then refine the plan as you progress through the phases.

Conclusion
DeviceLab gets a lot of repeat business because we’re good at being an outsourced team. To
get the best out of us (or any other design firm), follow these tips and you’ll have much
smoother sailing. See the Process page on our website for more information on how we do
things.
Part 9: When to Invoke Design Controls in a
Medical Device Project
Many medical device executives bemoan the burdens of Design Controls, claiming that they
stifle creativity and drive up costs. That may be so, but we’re stuck with them. Given their
unavoidability, we’re left to find ways to make these controls less burdensome and perform
whatever work than can be done outside their strictures “off the books.”

The first part of this is making your QMS agile and easy to use so that compliance with design
controls carries as little cost as possible. This means a less prescriptive approach, elimination of
low-value process requirements like restrictive formats, and efficient approval routing. This style
provides less hand-holding and can be problematic with inexperienced workers, but can be
safely used by the experienced development professionals at DeviceLab.

The second part is embodied in what we call the Research Phase. At DeviceLab, we use the
research phase to answer known questions and discover unknown unknowns prior to
establishing the proof-of-concept design. Documentation is limited to research notebooks, which
are not released to document control. In this mode, we’re free to change paths instantly, try
multiple alternatives, and pursue ideas.

The research phase ends when a conceptual design has been formulated. A formal design plan
is created, and the design requirements are accumulated. Information can flow from the
Research phase into Proof-of-Concept (like design choices), but if there is an important
research test result underpinning the design, you may want to go back and repeat it under
controlled and documented conditions.

So, in our experience, most projects benefit from a little time in the unsupervised sandbox
before moving to the pool with its long list of rules. When playtime’s over, we invoke Design
Controls built for rapid evolution. In this way, we keep the burdens of Design Controls from
vexing our clients.

That’s the last post in this series about the process of medical device design at DeviceLab. If
you haven’t read the previous ones, please check them out!