Contents

2.1 Medical Device Life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.2 Design & Development Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 If a Mug was a Medical Device . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 ISO 14971 & ISO 13485 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5 The Phase Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.7 Documentation & Record Keeping . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.8 Intended Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.9 User Needs & Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.10 Requirements and Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.11 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.12 The Phase Strategy suitable for a Complex PEM Product IEC 62304 & IEC 60601 23
2.13 Design Process & Design Outputs . . . . . . . . . . . . . . . . . . . . . . . . 25
2.14 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.15 Is our Digital Thermometer Safe ? . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.16 Design Traceability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.17 Documentation Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.18 Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.19 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.20 Additional Terms and Definitions Used . . . . . . . . . . . . . . . . . . . . . . . . 34

1
 Chapter 2 Medical Device Development

CHAPTER 2: Medical Device Development

2.1 Medical Device Life cycle
Per ISO 14971 the manufacturer shall establish, implement, document and maintain an on-
going process for risk management throughout the life cycle of the medical device.

Hence, as a pre-requisite to understanding risk management we will first use this chapter to
discuss the typical development of a medical device over it’s life cycle.

We will go on to discuss when and why risk management processes are carried out during
life cycle
the life cycle.

series of all phases in the life of a medical device, from the

Life Cycle: series of allconception
initial phases oftoathe
medical [Link] designing
final decommissioning to final
and disposal.
decomposition.
(ISO 14971).

storage & distribution

production servicing
project kickoff
design & dev Installation

part of the life cycle of the medical device after the de-
Post- sign has been completed and the medical device has been
Production: manufactured. (ISO 14971).

2
Chapter 2 Medical Device Development

2.2 Design & Development Overview

The typical high-level design elements involved in the development of a medical device are
depicted below.

Objective data supporting the existence or verity of something.

Evidence: (ISO 14971).

Note: A misconception about these design elements is that

you must step through them in a sequentially fashion
starting with intended use, the user needs, then require-
ments, and so on all the way to verification.

However, this is untrue. You could very well create

your verification tests before you build prototypes, de-
sign outputs and write requirements. This approach is
sometimes adopted in software in an approach called
Test Driven Development.

It is very hard to understand design and development concepts by block diagrams alone. To
understand these concepts more deeply lets consider if a common object like a drinking cup was
a medical device, what these different design elements would be.

3
Chapter 2 Medical Device Development

2.3 If a Mug was a Medical Device

4
Chapter 2 Medical Device Development

2.4 ISO 14971 & ISO 13485

ISO 14971 as a standard does not live alone, but should live within your company’s quality
managment system.

ISO 13485 is an international standard that specifies requirements for a quality managment
system for medical device manufacturers. ISO 13485 requires the implementation of risk
management processes, which should be compliant with the ISO 14971. Hence, this two sets
of standards are linked together at the hip.

Both standards are aligned to facilitate compliance with regulatory requirements in various
jurisdictions. By adhering to ISO 13485 and ISO 14971, manufacturers can ensure that their
quality managment system and risk management practices meet international regulatory
expectations, thereby simplifying market access and demonstrating a commitment to patient
safety and product quality.

As medical device manufacturers we create procedures that comply with the clauses of
international standards like ISO 13485 and ISO 14971 in order to comply with the regulations
of different jurisdictions.

5
Chapter 2 Medical Device Development

2.5 The Phase Strategy

Design and development projects are divided into phases. design review(s) are conducted
during each phase. A phase is just an interval in time and a project is simply a collaborative
effort which is carefully planned to achieve a particular aim. This is a necessary step to comply
with ISO 13485 §7. Below is a depiction of how an organization might segregate their project
into phases.

Note: You don’t have to apply this particular phase strategy,

you may use an alternative.

As a company you should define your own phase strategy in your own design & development
SOP.
means a documented, comprehensive, systematic examina-
tion of a design to evaluate the adequacy of the design re-
Design quirements, to evaluate the capability of the design to meet
Review: these requirements, and to identify problems. (FDA Ti-
tle 21 CFR §820).

6
Chapter 2 Medical Device Development

2.6 Planning
Planning plays a central role in the application of risk management during design & devel-
opment.

Product planning shall document;

• plan risk management activities
• assign responsibilities and authorities
• define how risk management activities are reviewed
• plan activities for verification of the implementation and effectiveness of risk control
measures
Plans can be adaptable, you may for instance originally plan a single design cycle for a given
medical device. On completion of the verification phase we may decide the device is not
ready for transfer to production. Instead we will run a second design cycle, to allow feedback
from the verification phase and make significant changes to the product.

Plans are not created at project kickoff, only to be set in stone and never changed. Instead
plans are continually updated and changed throughout the development. Typically, at each
phase exit, the project plans are updated and recorded per the manufacturers document and
recording keeping procedures, that should meet clauses specified in ISO 13485.

Within a given project the manufacturer assigns responsibilities and authorities to the indi-
vidual people who will work on the project. This information would also be documented within
the project plans.

7
Chapter 2 Medical Device Development

Example 2.1. For our digital medical thermometer, begin the planning of the project by define
a suitable project team, ensure you comply with ISO 14971 §4.3 ;

Note, here ISO 14971 §4.3 states:

“Persons performing risk management tasks shall be competent on the basis of

education, training, skills and experience appropriate to the tasks assigned to them.
Where appropriate, these persons shall have knowledge of and experience with the par-
ticular medical device (or similar medical devices) and its use, the technologies
involved or the risk management techniques employed. Appropriate records shall
be maintained.”

Company Project
Person Competence
Role Role

Bruce CEO Top • B.E in Mechanical Engineering

Wayne Management • +15 years medical device experience
• Trained in project management,
ISO 14971 & ISO 13485

Sarah Project Project • PhD in Mechanical Engineering

Connor Manager Manager • +6 years medical device experience
• Trained in project manage-
ment, ISO 14971, IEC 60601-1
& IEC 60601-1-2

Systems • PhD in Electronic Engineering

Engineer • +2 years medical device experience
Lead Design • Trained in ISO 14971, IEC 60601-1
Tony Stark and
Engineer & IEC 60601-1-2
Electronics
Engineer
Junior
Mechanical • B.E in Mechanical Engineering
Kaylee Frye Design
Engineer • +2 years medical device experience
Engineer
• Trained in ISO 14971, IEC 60601-1
& IEC 62366

8
Chapter 2 Medical Device Development

Company Project
Person Competence
Role Role
Senior
Embedded • B.E in Electronic Engineering
James Bond Embedded
Developer • +2 years medical device experience
Developer
• Trained in ISO 14971, IEC 62304 &
IEC 62366

Senior
Hermione Quality • B.E in Mechanical Engineering
Design
Granger Reviewer • +2 years medical device experience
Engineer
• Trained in ISO 14971, ISO 13485 &
IEC 62366

Dr. Stephen External Health Care • Doctor of Medicine

Strange Consultant Advisor • +10 years general interaction expe-
rience

The next critical element of a plan is assigning who is responsible for the different tasks and ac-
tivities in a plan. One way to do this is create a table of the tasks to be carried out in each phase,
who is responsible for them, who has the authority to review each task, and what verifiable ev-
idence demonstrates this task has been complete. We will demonstrate this in the next example.

Example 2.2. Define the tasks to be carried out in the phase 0 preliminary design of our digital
thermometer. Ensure you define;

a. Who is doing what task?

b. Who reviews each task?
c. What verifiable record demonstrates the task has been complete?

Unique Task Description Assignee(s) Reviewer(s) Status Verification

ID

TASK-1 Draft the product de- Project Top Man- Complete

PLAN-51v0 Product Development [Link]
velopment plan Manager agement
TASK-2 Draft the risk man- Project Quality Not
PLAN-51v0 Product Development [Link]
agement plan Manager Reviewer Complete

TASK-3 Draft the intended Systems Quality Not

UND-30v0 User Needs [Link]
use Engineer Reviewer Complete

TASK-4 Draft the user needs Systems Quality Not

UND-30v0 User Needs [Link]
plan Engineer Reviewer Complete

TASK-5 Draft the product re- Systems Quality Not

PRD-30v0 Product Requirements Docu-
quirements Engineer Reviewer Complete [Link]
TASK-6 Draft the product ar- Systems Quality Not
PDD-30v0 Product Design [Link]
chitecture Engineer Reviewer Complete

TASK-7 Conduct a preliminary Systems Quality Not

RA-62v0 Preliminary Risk [Link]
risk assesment Engineer Reviewer, Complete
Project
Manager,
Health Care
Advisor

confirmation, through the provision of objective evidence,

Verification: that specified requirements have been fulfilled. (ISO 14971).

9
Chapter 2 Medical Device Development

Note: In the above example we have only planned phase 0.

When a project is kicked off you do not have to plan
the entire project from scratch to finish. You can if you
wish plan each phase as you go. Planning is essentially
a prediction of the future, and no one can predict the
future with 100% accuracy and certainty.

Planning an entire project from scratch can lead to a sit-

uation where several months down the line the plan has
become completely inaccurate, but you may have previ-
ously committed to it and promised top management
within your organization that you would stick to a given
schedule. This scenario can make companies rigid, un-
adaptable and trapped in product development plans
that are inaccurate and not functioning adequately.

top management within should recognize that for

project teams to be effective, they must be permitted
to adapt and change course as needed. This is accom-
plished by revising plans at each phase exit, which may
mean revising schedules, removing tasks, adding new
tasks etc. This is a normal part of planning.

10
Chapter 2 Medical Device Development

2.7 Documentation & Record Keeping

Documenting and record keeping plays a key role in the risk management process. We use
records to act as evidence that we have adhered to;

a. Our company’s procedures

b. International standards
c. Legislation

Setting a high level of documenting and record keeping also enables you as a company to
establish a high level of effective technical communication.

document stating results achieved or providing evidence of ac-

Record:
tivities performed. (ISO 14971).

We can see that at the end of our phase 0 activities we will have created a list of documents that
act as records. The records are typically uploaded to the companies quality managment
system at the end of each phase exit. These records will be continually updated throughout
the project as the development of the medical device progresses.

Records relating to risk management processes are also added to the projects risk man-
agment file.

Risk
set of records and other documents that are produced by
Management
risk management. (ISO 14971).
File:

The word file here simple means a set of records. You may have also come across the term
design history file which is a FDA term defined below.

Design a compilation of records which describe the design history

History of a finished device. (FDA Title 21 CFR §820).
File:

As we produce records we will also add them to their relevant files. Some records will go
into multiple files. We can consider the risk managment file to be a subset of records
contained within the larger design history file.

11
Chapter 2 Medical Device Development

Example 2.3. This example was removed.

12
Chapter 2 Medical Device Development

2.8 Intended Use

use for which a product, process or service is intended accord-

Intended ing to the specifications, instructions and information provided
Use: by the manufacturer. (ISO 14971)

The intended use of a medical device should contain information on;

a. intended medical indication

medical e.g. treatment or diagnosis of type 2 diabetes, cardiovascular
manufacturer
disease, bone fracture, infertility

b. patient population e.g. age groups (adults, children, adolescent, elderly), gender (male,
patient population
female) or disease state

c. part of the body or type of tissue interacted with e.g. leg or arm
user profile
d. user profile e.g. patient, lay person, health care provider

e. use user
environment e.g. home, hospital, intensive care unit
environment

f. operating principles e.g. mechanical piston driven syringe, X-ray imaging, MR imaging,
subcutaneous drug delivery

Example 2.4. Suppose we set out do develop a digital thermometer to aid in the diagnosis and
management of medical conditions requiring body temperature readings such as fever. Draft the
intended use statement for this device.
The device is intended to use the measurement of body temperature. it is designed to aid in the diagnosis
The DigiTherm is intended for use in the measurement of body temperature. It is designed
medical conditions tat requiring accurate body temperature.
to A)
aid in the diagnosis medical conditions requiring accurate body temperature readings.
B) suitable for usage ina all ages.
d) the device is intended to use by health care providers and lay persons.
Suitable for use in all age groups.
e) usable for home and clinical settings.
f)the device operates electronic sensing of temperature
Designed for oral use.

The device is intended for use by health care providers and lay persons.

Suitable for use in various settings, including homes and common clinical settings.

The digital thermometer operates based on electronic sensing of temperature.

13
Chapter 2 Medical Device Development

2.9 User Needs & Validation

User needs is a design term used by the FDA, the concept is also heavily explored in the book
“What Customers Want: Using Outcome-Driven Innovation to Create Breakthrough Products
and Services” by Tony Ulwick.

a statement that describes what a product must do to satisfy

User Need:
or fulfill the needs of the users without specifying a solution.

Note: the word user generally refers to both the patient

and/or operator as they are effectively both users of
the device.

A big question to answer is ...

“ Why do we need user needs do we not start design by simply drafting only
requirements?”

There are two common pitfalls you as a company can fall into when concepting a new product.
They are:

1. You design a product that is technically excellent, a wonderful piece of engineering, but
it solves no meaningful problem for the user. Hence, no one buys it.

2. You build the can-do-everything product. You add feature after feature after feature,
not realizing most users only wanted the core features. When you go to sell the product, it
has become to expensive, or too complicated to use or too physically large as a unforeseen
consequence of all the additional features.

Separating user needs from requirements ensures that as a design team we address the
problems and desires of the target users. This customer-centric approach leads to solutions that
are more effective and meaningful to users.

It also allows designers to take a step back see the potential flaws in product requirements
that may not be contributing positively to enabling the product meet a given user’s needs.

When we draft user needs we should also take a look into the future and ask, what validation
will be required to demonstrate we meet these user needs.

confirmation by examination and provision of objective evi-

Validation: dence that the particular requirements for a specific intended
use can be consistently fufilled. (FDA Title 21 CFR §820).

establishing by objective evidence that device specifica-

Design
tions conform with user needs and intended use(s). (FDA Ti-
Validation:
tle 21 CFR §820).

14
 Chapter 2 Medical Device Development

Example 2.5. Referring to the digital thermometer of the previous example, draft a list of
suitable user needs, for this product, also try determine what would act as suitable validation
that we have infact met the user needs.

Unique
User Need Design Validation Required
Identifier
Intended use : The device meets its intended Clinical Study
UN-0 Intended Use: The device meets
use
its intended use
ease of use - the device should be easily Usability Test Report
UN-1 Ease-of-Use:
operated by user The user needs the
device to be easy and intuitive to
use.
accuracy -the user needs accurate temp
A safety compliance report demon-
UN-2 readings
Accuracy: The user needs accurate strating the products meets applica-
temperature readings ble international standards.
safe:-
ty the user needs the device to be safe Inspection of the Risk Manag-
UN-3 Safety: The user needs the device
used for implementing user tracebility ment File
to be safe.

15
Chapter 2 Medical Device Development

2.10 Requirements and Architecture

“What came first, the chicken or the egg ?”

A common misconception is that you must step through each task in a medical device devel-
opment in a linear sequence or waterfall approach. Where you write the user needs then the
requirements, then the architecture etc. In reality design is an incredibly iterative process,
and often all these different parts are slowly created collectively forcing revisions to existing
parts as they occur.

Requirements and architecture are a good example of this, typically they are created together
and iterated upon to improve and progress the design.

In a design cycle, we will derive requirements from either user needs or we will define re-
quirements to act as risk control measures to reduce certain risks.

something that a product or system must do which can be

Requirement:
objectively verified by a prescribed method.

An example of requirements are;

“The device shall have a length of less than 10 cm.”
or
“The device shall weigh less than 100 g.”

A key part of writing requirements is ensuring they are objectively verifiable by some method,
which is typically a test (aka verification ).

The concept of requirements is essential to apply risk management to a design, as we can

use them as a method of implementing risk control measures.

process in which decisions are made and measures imple-

Risk mented by which risks are reduced to, or maintained within,
Control: specified levels. (ISO 14971).

Effectively, as we identify different hazards in our different risk assesments. We will also
introduce risk control measures to mitigate the risks of these hazards
̇
A common example, are hazards associated with electric shock can generally be mitigated by
introducing a risk control measure that the product shall comply with IEC 60601-1.

We add this risk control measures to our list of product requirements, we then design
the product to meet this standard and verify it meets the tests and clauses described in the
standard as part of product verification
̇
As each requirement is verified by some verification activity, our verification now acts
as objective evidence that risk control has been implemented.

16
Chapter 2 Medical Device Development

Example 2.6. For the digital thermometer of the previous examples, use the user needs as a
base to draft the product requirements and architecture. Assign each requirement a unique
identifier, and trace it back to the user need it is intended to implement.

Unique
Product Requirement Related User Need
Identifier

PR-0 Temperature Measurement: UN-0 Intended Use, UN-1 Intu-

The device shall measure tempera- itive, UN-2 Accuracy
ture with an accuracy of +/- 0.1◦ C
and display this measurement on a
3-digit display.

PR-1 Size: The device shall have a dimen- UN-1 Ease-of-Use

sions WxHxL ≤ 18 mm × 12 mm ×
125 mm

PR-2 Battery Life: The device shall UN-1 Ease-of-Use

have a replaceable LR4 coin cell bat-
tery with a battery life of greater
than 1 year.

17
Chapter 2 Medical Device Development

2.11 System Architecture

Once we start using words like product, system, item, component and interface etc. We can
very easily run into confusion, as these terms are open to fairly wide interpretations. In this
section we will expand on the use of these terms to try avoid this confusion.

As part of this course, we will adopt the following definitions for the words product, system
and item as follows.

Product: a system that is manufactured or refined for sale.

an integrated collection of items organized to accomplish a

specific function. Typically, can be considered as an encapsu-
System: lated object with interfaces to external items or users. Sys-
tem verification testing may be performed on the system
by interfacing to externally mocked items or systems.

any identifiable part of a system e.g. a mechanical compo-

nent, an electronic circuit, a PCB assembly, a plastic enclosure
etc. Typically, can be considered as an encapsulated object
Item: with interfaces to external items or users. Item or integra-
tion verification testing may be performed on the item by
interfacing it to externally mocked items.

Per these definitions a system can also be a product. And since a system is considered a
collection of items, which may be considered to be systems in their own right, a system can
contain further systems.

Consider the below possible system architecture below where this is demonstrated.

18
Chapter 2 Medical Device Development

Items are connected to each other by interfaces, which are simply defined as

a point where two or more systems or items meet and inter-

Interface: act.

Throughout this course we will try avoid the use of other words commonly used for describing
these terms like module, component, sub-system, object, part etc etc. As it just leads to con-
fusion. And instead stick to our more constrained vocabulary of product, system and item
when defining system architectures.

“Why is this important?”

How we define our architecture, plays a crucial role in how we carry out our verification. If
I decide to call the firmware controller a system, I am indicating I see the need to preform
system-level verification on it, and produce system-verification test reports which test
that system independently of the other systems in the product.

Carrying out verification testing is one of the key foundational concepts we build our risk
management processes on top of, and hence taking care with how we subdivide products
and systems into their respective parts plays a key role in risk management.

Note: Something can be 2 things at once.

For instance;

• A digital thermometer is a system and a product.

• A system can also be an item.

The terms system and item do not indicate their position in the product’s hierarchical
structure. A system may consist of more systems, which consist of more systems, and so on
so fourth. A software item may consist of more software items, which contain a mix of
software units and software items or even software systems on occasion. This scenaio
is depicted below.

19
Chapter 2 Medical Device Development

Lets reconsider the architecture we defined earlier for our digital thermometer and apply our
new definitions to this structure.

In a more complex product we may decide the product is built of several different systems.
For each system we will carefully specify their interfaces so we can carry out system-level
verification on each system before they are assembled into the final product. Let’s now
consider defining the architecture of a more complex medical device.

20
Chapter 2 Medical Device Development

Example 2.7. Consider the following electro-surgical generator which consists of a power sup-
ply, a electric pulse generator and a hand held probe. The operator uses the handheld probe
to apply electric pulses to the patient to ablate patient tissue during surgery.

(i) Suggest a suitable product architecture which decomposes the product into several sys-
tems, include and interfaces to users of the product.

21
Chapter 2 Medical Device Development

“How do we decide what is a system or item?”

You the designer decide what is a system, item, software item and software unit for
your product in order to carry out the most appropriate verification activities.

Note: When the inevitable debates arise among project team

members about what should or shouldn’t be a system,
item software item or software unit, remember
to always ask what makes sense to test. Hardware
will generally only be tested at the system level, soft-
ware will generally be tested at the software system,
software item and software unit level.

Hopefully you can see, given the wide variety of complexity in medical devices from those
with software to those without. And from relatively simple products like a digital thermometer
to the more complex electro-surgical generators, why it makes more sense for the standards to
adopt fairly open definitions like those of system, software item and software unit.

Defining these terms in this manner, enables us to apply them to any type product, and gives
you as the designer the artistic freedom to use them as you see best for the product that you
are developing.

any identifiable part of a computer program, i.e. source code,

Software object code, control code, control data or a collection of these
Item: items. (IEC 62304).

Software a software item that is not divided into other items.

Unit: (IEC 62304).

22
Chapter 2 Medical Device Development

2.12 The Phase Strategy suitable for a Complex PEM Product

IEC 62304 & IEC 60601
For a more complex product which contains multiple systems it can be wise to adopt the
phase strategy depicted below.

23
Chapter 2 Medical Device Development

With this approach, if multiple design teams are available, the “System Design” phase of each
system can now be run in parallel to try speed up the overall development.

24
Chapter 2 Medical Device Development

2.13 Design Process & Design Outputs

the results of a design effort at each design phase and at the

end of the total design effort. The finished design output is the
Design
basis for the device master record. The total finished design
Output:
output consists of the device, its packaging and labelling and
the device master record. (FDA Title 21 CFR §820).

Once requirements are created we can execute the design process to create the design
outputs. The process and design outputs depend on the type of item we are designing.

set of interrelated or interacting activities that use inputs to

Process: deliver an intended result. (ISO 14971).

Example 2.8. List some possible design processes and their respective design outputs for
the digital thermometer of previous examples.

Design Process Design Output

Electronic Design PCB Files, Schematic Files

Design Calculations Matlab Files, Excel Files

Mechanical Design CAD Files, Mechanical Drawings, Assembly

Drawings

Writing Code Source Code, .exe files, .hex files etc

Documenting Design Details PDD-0 Product Detailed Design [Link]

25
Chapter 2 Medical Device Development

2.14 Verification

confirmation, through the provision of objective evidence,

Verification:
that specified requirements have been fulfilled. (ISO 14971).

Common types of verification include;

• Testing and Documenting Safety Compliance Reports

• Testing and Documenting EMC Compliance Reports

• Bench Testing

• Software Testing

• Reviewing the product’s accompanying documentation

In order to carry out any particular test, you must first create an appropriate the test setup.
The test setup is typically built by mocking the inputs and outputs to the system or item
under test and measuring these inputs and outputs against some pass/fail criteria. This is
depicted below for an item we are testing.

The test setup above can be applied to any given example. Consider for instance the power
supply which earlier acted as a system within out electrosurgical generator product. We could
derive the following test setup to perform certain tests.

26
Chapter 2 Medical Device Development

Verification activities have a few important prerequisites. The first being, it is very impor-
tant the product, system, software system, item etc, are under version control before
performing verification. Hence, when problems in the design are found in verification you
can correct them in this version and move to the next.

If you are performing the testing yourself, any tools you use as part of the testing, whether they
be software applications or test equipment, should also be under version control.

Note: If you are conducting your own testing, as part of meet-

ing the preventive maintenance clauses of ISO 13485,
your company should have a procedure in place for
maintains the calibration of equipment used in ver-
ification activities. Evidence that equipment is cali-
brated should be included in verification test reports.

Note: If you are using an external test house for testing you
should ensure as part of your supplier evaluation (again
a part of ISO 13485) that the test house you use is
accredited to the appropriate standards.

For each test you carry out you should always ensure you document:

• a description of the test setup

• a description of the test tools (testing software, lab equipment etc. )

• who performed the testing?

• the pass/fail criteria of the test

We will often use verification as evidence that we have implemented risk control measures.
Hence, verification reports become part of the risk managment file.

27
Chapter 2 Medical Device Development

Example 2.9. Continuing with our digital thermometer example, and based on the product
requirement PR-0. Derive;
i. a suitable test setup
ii. a verification test
Describe tests with a unique ID, description of the test, the test steps needed to perform
the test, the pass/fail criteria needed to pass each test.

Related
Unique Product
Test
Identifier Require-
ment

TEST-0 Temperature Measurement Test: Measure the temper- PR-0 Temper-

ature of a liquid with known temperature and ensure the ature Measure-
accuracy meets PR-0. ment

Test Step Description Pass/Fail

Criteria
1
Set the hot plate to 40 NA
degrees Celsius
2
Wait 10 minutes NA
3
Measure the tempera- NA
ture with the digital
thermometer and the
precision digital ther-
mometer
4
Ensure the accuracy is Accuracy ≤
within 0.1 ◦ C 0.1 ◦ C

28
Chapter 2 Medical Device Development

2.15 Is our Digital Thermometer Safe ?

At this stage we have now designed and tested our digital thermometer, but we have not applied
the principles of risk management to this process. Let’s consider the question is it safe and
will it meet it’s intended use?

Let’s consider if we released this product as is what could go wrong.

• The battery starts a fire and the plastic enclosure may be flammable.

• The thermometer goes into the patients mouth, but may not be bio compatible?

• The thermometer may fail in a hospital environment, due to EMI from other electrical
equipment.

• The thermometer electronics could over heat and burn the operators hand.

• The plastic enclosure may not be durable or reliable.

• If a field failure occurs can the patient obtain the manufacturers info and the serial number.
Maybe its just this batch that has the problem etc.

• Is the device accurate?

• Is the device still accurate after 2 years.

Note: We have not gathered sufficient evidence that mitigates

these foreseeable risks to an acceptable level. Hence,
we cannot say the device is safe.

In the next chapter we will start to apply the principles of risk management to ensure we
design a safe device.

29
Chapter 2 Medical Device Development

2.16 Design Traceability

“Show me the evidence ?”

The application of design controls and risk management is written in to regulations. In

order to demonstrate we meet the clauses set out in the regulations, we must be able to show
objective evidence.

A key element of this is ensuring design traceability through our or design & development pro-
cess, which is then typically demonstrated in whats known as the DIOVV (Design Inputs,
Design Outputs, Verification & Validation matrix). Matrix here is just a fancy word
for an excel spreadsheet. The DIOVV can be created by assigning a unique ID to each design
element. A possible way of doing this is shown below.

Per this approch:

• Each user need is given a unique ID UN-X where X ϵ 1,2,3,4,...

• Each design input is given a unique ID DI-X

• Each design output is given a unique ID DO-X

• Each risk control measure is given a unique ID RC-X

• Each risk is given a unique ID RISK-X

• Each verification test or report is given a unique ID VER-X

• Each validation test or report is given a unique ID VAL-X

30
Chapter 2 Medical Device Development

Then all these different elements are linked together in the DIOVV which shows what links to
what. Similar to our image below.

Note: There is no one way to do this, in your own design

team or company you decide how to do this for your
own products or projects. Typically how this is done is
then written into the company’s design & development
procedure.

Once the design is complete, or you may also do this throughout the design if you wish, you
create an excel spreadsheet showing how the user needs, risk control measures require-
ments, design outputs, verificationand validation all link together. Effectively this
document in combo with verification and validation reports acts as evidence you have
implemented all of your risk control measures.

31
Chapter 2 Medical Device Development

2.17 Documentation Templates

We have created some templates to assist you and your company in following these processes.
They are available to download from the online course near the end of chapter 2.

Note: More templates will be made available in later chapters

also.

Note: It is common for other companies to use different nam-

ing conventions and document codes for these docu-
ments.

Note: It does not matter if you call a document PDP-0r0 Prod-

uct Development [Link] versus PDP-0r0 Risk Man-
agement [Link] etc, or that you use the document
code PDP instead of PLAN or RMP etc.

What matters is that your documents and processes

meet all the clauses set out in the applicable standards
like ISO 14971 or ISO 13485 or FDA Title 21 CFR §820
etc

32
Chapter 2 Medical Device Development

2.18 Common Questions

”What if i’m a startup, we have started our design but have not implemented
planning, phase strategy or design controls yet?”

Allow engineers and developers to keep working on the project. Start building an ISO 13485
Quality Managment System that has the key elements needed for design. mainly the elec-
tronic record keeping, the design & development procedure, a risk management procedure.
Train staff on these procedures (the sooner the better with this one).

Once you have the procedures, formally kickoff the project, enter phase 0, and proceed from
there. If certain records or design outputs or risk management activities were already
performed, you will have to just revise them as you go, and upload them to your Quality
Managment System.

“Are requirements not an instruction that tells designers what to do?”

If you allow a broader scope of the word requirement, yes. Or when we use the word requirement
with its normal English meaning yes. But doing so leads to a situation where statements like
these become requirements.

“The device shall have a Texas Instruments analog-to-digital converter that reads the ECG
signal.”

or
“The device shall have a user interface consisting of an LCD screen and a membrane switches.”

The problem with writing requirements like this is they are not verified by testing, but in-
stead by inspecting the products design. This type of verification does not demonstrate the
product more safe, reliable or effective. Moreover, it just adds alot of work to documenting and
verification activities with no real benefit.

In these situations, where a requirement acts as more a description of the product, as oppose
to a verifiable description of what the product must do. It is best to remove this require-
ment, and instead just add these descriptions to the a document that describes the design of
the product. Typically i would but stuff like this in the “product design document” or a “prod-
uct detailed design document” or similar. I would call it more a design output as it is more
a description of the design, as oppose to a design input and i would not tie it to verification.

33
Chapter 2 Medical Device Development

2.19 Conclusion

Congratulations !!!!!!!

We have reached the end of chapter 2

2.20 Additional Terms and Definitions Used

a formalized system that documents the structure, responsi-

bilities, procedures, processes, and resources needed to imple-
ment quality management in the organization. This system
is crucial for ensuring that medical devices are consistently
designed, manufactured, and distributed in accordance with
regulatory requirements and customer expectations. The key
components of a QMS for medical device companies typically
include:
• Quality policy and objectives

• Organizational structure and responsibilities:

• Document control and electronic document manage-

ment.

• Design control
Quality
Manage- • Supplier management:
ment
System • Production and process controls
(QMS): • Product quality assurance

• Nonconforming product controls

• Corrective and preventive actions (CAPA)

• Risk management

• Training and competence

• Customer feedback and complaint handling

• Internal audits

• Management review

• Regulatory compliance

34