Cognidox - A Complete Guide To Medical Device Development

A complete
guide to
medical device
development
Contents
INTRODUCTION 3
The scale of the challenge 3

Why success is now even more difficult to achieve 4
How to avoid the biggest mistake in medical device development 5
A note for readers: 5
SECTION 1: DEFINING THE CHALLENGE 6
Is it a Medical Device? 6
So, what is a medical device? 7
What is an In Vitro Diagnostic Medical Device? 7
When is software classed as a medical device? 8
Medical Device Classification, Conformity Assessment and CE marking 8
Applying for a CE marking for your medical device 10
What’s the big idea? 12
Have you identified a real gap in the market and designed a solution for it? 12
Product-customer fit 13
SECTION 2: CREATING A PLAN & A QUALITY MANAGEMENT SYSTEM 14
Be prepared – why everything starts with a plan 14

How to avoid the biggest mistake in medical device development 15
What’s the plan? 15
Planning a Quality Management System for Medical Device Development 16
What is a Quality Management System (QMS)? 17
Quality Management Systems – what’s the big deal? 17
How a QMS helps you take a ‘risk-based approach’ to design and development 20
The Risk-based Approach in Medical Device Development 20
5 benefits of adopting the Risk-based approach to quality management in ISO 13485:2016 21
Risk management as part of medical device design requirements 22
Choosing a digital QMS solution for medical device development 23
SECTION 3 EXECUTING YOUR PLAN - THE KEY STAGES OF DESIGN & DELIVERY 25
What is a design input? 26

Compiling your specification documentation 26
Device User Requirement Specifications (URS) 27
Engineering Design Specification (EDS) 28
Managing the design process 28
How a digital QMS can help deliver required design controls 30
Design verification and validation 31
Final steps to getting to market 32
Preparation of your Medical Device File 32
The Design History File (DHF) 33
Certification by Notified Bodied 33
Transfer to manufacture 33
Launch and follow up 34
CONCLUSION 35
GLOSSARY 36
2 A complete guide to medical device development

Introduction
If you want to be a medical device developer
you need a great idea for a product, as well as
the ability to build it.
But if you want to be a successful medical device developer, you’re

going to need to do considerably more than that.
The scale of the challenge

Medical device development is one of the most heavily regulated
sectors in the world.
The consequences and penalties for making mistakes and releasing

unsafe or poorly designed devices can be serious.
But the rewards for success are considerable:
THE MED £7.6 billion The distinction and boundaries between

software, apps and medical devices are
IS WORTH a year
TECH SECTOR in the United blurring, opening up new opportunities but
Kingdom. presenting new complexities for developers.
Competition is stiff and success difficult to achieve:

There are approximately 98% of them It now takes 6–10 years for a
3,700 companies in are small to typical medical device to come
the UK’s medical medium-sized to market and a cost of between
technology sector enterprises £2–£10 million to get there
As a developer, therefore, you need to make sure you’re properly

focusing your time and resource from the very beginning of the
process, to maximise your chances of success.

Why success is now even more difficult to achieve
The world is emerging from an international pandemic with an ageing

population and a new set of health challenges. The demand for cheaper
and more usable diagnostics and medical treatments is growing
fast. Meanwhile, advances in miniaturised tech and AI are offering
unprecedented opportunities for developers and disruptors alike.
Demand is strong with different competitors bringing wearables, apps

and other innovations to the market. But there’s risk at every turn. Just
consider the following:
M
edical device production cycles have become 50% faster over the
last five years

Medical device recalls increased by 71% between 2016 and 2019
Software
failures are now the number 1 reason for medical device
product recalls
To succeed in this market, therefore, medical device developers must:
U
nderstand from the outset precisely what kind of device they are
developing and how they will meet changing regulation and quality
standards
M
eticulously plan an integrated approach to design, development
and manufacture to manage risk while expediting delivery
Focus
on implementing Quality Management Systems (QMS) that
can help them deliver differentiated, user-centric design as flexibly
and rapidly as possible.

How to avoid the biggest mistake in medical
device development
Given the heightened stakes and the pressure in the sector to deliver
more complex products faster and to a higher quality than ever before,
this eBook focuses on helping developers avoid the biggest and most
common mistake in medical device development. The failure to plan
and implement a QMS (Quality Management System) that can flex and
scale with your needs.
The resilience and flexibility of your planning and QMS is essential

because your project will take longer than you think will and there will be
set-backs you cannot possibly predict.
Only a flexible, digital QMS will be able to manage and control your
documentation as your team iterates designs and responds to new market
challenges in real time.
Whatever happens in the white heat of development, the right QMS can
keep your project on track through structured workflows, automated
change control and phase-gated design processes.
This eBook is designed to help you prepare for these requirements.

To help you realise the scale of the task before you, and the kind of
tools you’ll need to navigate the design, development and regulatory
challenges that lie ahead.
A note for readers

This eBook is broken down into three sections designed to support device
manufacturers at various stages in their thinking and development of a
product. Readers are encouraged to move forwards and backwards to
find the section that is most relevant to them:
Section 1: Defining the challenge
Section 2: Creating a plan and a Quality Management System
Section 3: Executing your plan

SECTION 1
Defining the
challenge
Is it a Medical Device?
First things first. Is the product you are intending to develop a Medical
Device, an In Vitro Diagnostic Medical Device (IVD), or Software as a
Medical Device (SaMD)?
These distinctions are important, because it is going to impact on the

lead time and the rigour of the certification processes you will have to
undertake before your product can launch.
In Europe the regulations that govern the development of medical

devices will either be the Medical Devices Regulation (MDR) EU
2017/745 or the In Vitro Diagnostic medical devices Regulation (IVDR)
EU 2017/746.
Following Brexit, medical devices in Great Britain are now regulated

by the UK MDR 2002 However, the MHRA are continuing to accept
medical devices developed using the EU MDR and IVDR regulations
until July 2024. At this point, new UK legislation will apply (full details
of which have yet to be released as of September 2022).
The US has similar classifications of device to the E,U with details

contained in the regulation: FDA 21 Parts 800 - 1299.

So, what is a medical device?
The European Medical Devices Regulation (the EU MDR) defines a

medical device as: Any instrument, apparatus, appliance, software,
implant, reagent, material or other article intended by the manufacturer to
be used, alone or in combination, for human beings for one or more of the
following specific medical purposes:
d
iagnosis, prevention, monitoring, prediction, prognosis, treatment
or alleviation of disease;
d
iagnosis, monitoring, treatment, alleviation of, or compensation
for an injury or disability;
investigation, replacement or modification of the anatomy or a

physiological or pathological process or state;
p
roviding information by means of in vitro examination of
specimens derived from the human body, including organ, blood
and tissue donations;
f or the control or support of conception; or
p
roducts specifically intended for the cleaning, disinfection or
sterilisation of devices.
What is an In Vitro Diagnostic Medical Device?

In Vitro Diagnostic Medical Device (IVD) is defined as:
“any medical device which is a reagent, reagent product, calibrator, control

material, kit, instrument, apparatus, piece of equipment, software or system,
whether used alone or in combination, intended by the manufacturer to be
used in vitro for the examination of specimens, including blood and tissue
donations, derived from the human body, solely or principally for the purpose
of providing information on one or more of the following:
(a) concerning a physiological or pathological process or state;
(b) concerning congenital physical or mental impairments;
(c) concerning the predisposition to a medical condition or a disease;
(d) to determine the safety and compatibility with potential recipients;
(e) to predict treatment response or reactions;
(f) to define or monitoring therapeutic measures.
Specimen receptacles shall also be deemed to be IVDs.

When is software classed as a medical device?
Software as a Medical Device (SaMD) is defined as:
“software intended to be used for one or more medical purposes that

perform these purposes without being part of a hardware medical device.”
Examples include devices that monitor fitness, health or general

wellbeing as well as devices that simply digitise information that would
normally be printed or completed by hand, such as patient diaries for
recording blood pressure.
However, many other apps and pieces of stand-alone software

are classified as medical devices and will be subject to the same
compliance requirements.
These include apps which gather patients’ data (such as diet, heartbeat,
or blood glucose levels) and then analyse that data to make a diagnosis,
prescribe a medicine, or recommend treatment.
The MHRA has published an interactive guide to help you determine the
exact classification of your device. However, it is still a new area of medical
device regulation, so it may be worth reaching out to the MHRA directly or
even a Notified Body for their opinion.
Medical Device Classification,

Conformity Assessment and CE marking
A Medical Device can only be CE marked and placed for sale on the EU
market when it meets all of the applicable regulatory requirements.
Manufacturers need to demonstrate that the medical device meets

the requirements of the MDR or IVDR by carrying out a Conformity
Assessment. The assessment route depends on the classification of the
device and may require your quality management system to be audited
by EU Notified Bodies.

Note
While the UK is currently accepting products with a CE marking, from 1st
July 2024, you will require a UKCA marking in order to place a new device
on the market. The UKCA will be issued by UK Approved Bodies and will
demonstrate compliance with new UK regulations (unpublished at time of
writing but see here for updates). Right now, every medical device or IVD
for sale on the UK market must be separately registered with the MHRA.
In the EU when it comes to compliance, the burden of proof is higher

or lower depending on the classification of the device and the degree
of risk that its use could present to the patient or user. The risk of harm
represented by the device will also determine whether you can self-certify
the device or if its conformity needs to be certified by an external body.

Applying for FDA approval, CE, and UKCA markings
When planning a medical device you need to factor in the time and resources
required to apply for your FDA approvals, CE marking and UKCA marking (from
June 2023). Depending on the complexity of your product and which bodies
needs to review and audit your QMS, technical file and/or clinical trial results,
this requirement can add months or even years to your overall timeline.
Every medical device developer must be able to prove that they have:
Developed and manufactured their device in accordance with the relevant

1.
regulations and standards,
That they have a quality management system in place to manage the processes
2.
involved in developing, manufacturing and managing all regulatory activities
associated with a medical device.
They can share the required technical documentation with auditors to

3.
demonstrate compliance. In the US this means sharing your Design History File,
Device Master Record and Device History Record as part of your FDA audit.

In the EU, conformity with these requirements is self-assessed for Class I
devices by the manufacturer.

For Class I Sterile or Measuring medical devices, the same applies, but the
technical file that relates to sterilisation or measurement must be reviewed
by a Notified Body and an EC Certificate issued by them

For the other classes (Class IIa, Class IIb and III), conformity assessment
needs to be carried out by a Notified Body. You will, therefore, need to
factor in the time required for them to review your product technical file
and your QMS to be audited by them.
The typical lead time for an EU notified body to review your technical file is currently
6 – 12 months.

For all devices you will need to complete a Clinical Evaluation (see
MEDDEV 2.7/1 Clinical Evaluation: a Guide for Manufacturers and Notified
Bodies) and for Class IIa and higher you will also be required to complete a
Clinical Investigation, more commonly known as a Clinical Trial or Study to
EU standards (BS EN ISO 14155:2011)

In general, the higher the risk class of device, the more patients
should be included in the clinical trial or study and the longer the
study should run. Time to complete any clinical studies must be
factored into your overall product development time frame.
It is not uncommon for implantable device clinical studies, to last 5 years+

Approval by the FDA
In the US, market approval of your product is undertaken by the FDA itself. Most Class I
devices should be self-registered with the regulator, which usually takes between 30 –
90 days to complete. However, Class II devices require you to make a 510(k) submission
which can take up to 9 months to process. For Class III devices, a more demanding
Pre-Market (PMA) submission process is needed that can take up to 36 months, not
including potentially years-long clinical trials to generate required evidence.
FDA Medical Device Classification

What’s the big idea?
So, you know what classification your product falls
into and what you need to do to meet the regulatory
requirements to place it on the market, but have you
asked your potential customers and users if they actually
need and would want to buy your product?
Have you identified a real gap in the market and

designed a solution for it?
One of the main reasons for a medical device start up failure is that someone had a
great idea for a product but didn’t verify that there was a problem in the market that
needed it as a solution.
This is true of start-ups in general, where it is reckoned 42% of all failures are a result
of having created a product for which there was no customer demand. Of course,
the cost of getting it wrong in medical device development can be far higher than for
other products due to the exacting demands of the tech expertise required and the
regulatory hurdles you will need to clear to get to market.
But it’s not just small med tech start-ups who are guilty of inadequate research and
forging ahead without the proper research to back up their convictions.
When drug giant Pfizer started working on delivering insulin via an inhaler they went
in all guns blazing. They thought there was huge customer demand for a non-painful
alternative to injections among diabetics and believed that the technology could be
developed to deliver it.
The Exubera product was eventually launched in 2007 to much fanfare. But the
product did not live up to the hype. For a start, the company had found it impossible
to deliver a normal insulin dose within a single dosage of Exubera. Added to this, in
the seven years that it had taken to get the product to market the industry had found
a different solution to their complex and painful injection problem, with the advent of
an easy-to-use pre-packaged „pen“ device.
To make matters worse customers responded badly to the appearance of the

device which was regarded as unwieldy and difficult to use. The spectacular
lack of customer demand for a product that was initially hailed as a great medical
breakthrough led to the withdrawal of the product altogether and, according
to the NYT, cost the Pharma giant a total of $2.8 billion.

Product-customer fit
This should be a lesson to all developers to do detailed research about
what their customers really want before they start developing, and to
regularly review those requirements throughout the development lifecyle.
The ideal starting point to validate your idea is to investigate your chosen
user group (these might include patients suffering from a specific disease or
condition or clinicians of a specific medical specialty).
Find out from them what their biggest problem or unmet need is.
Ultimately, this will become part of the User Requirement Specification

against which you will design a device to solve their problem.
Gathering and meeting user needs is part of a compliant

medical device design process
In fact, gathering a comprehensive set of ‘user needs’ for your medical

device is part of the requirements of ISO 13485 and, therefore, necessary
for successful CE marking or other regulatory product approval.
The Technical Files or Medical Device File that you will need to produce
as part of your compliance documentation must contain evidence that
user needs have been collected at the beginning of a project and then
validated against the finished product at the end.
Not only is this a compliance requirement it is also a common sense

requirement that will save you money and keep you focused on customer
needs throughout your design process.
After all, the more successful and efficient a product is at meeting

user needs, the greater the demand for it should be and the more
commercially successful your company will become.
Regardless of whether the concept for your medical device design has
come to you fully formed, you will still need to test the waters of the market
to see if it is going to solve a problem or not. You need to keep in mind that
even if it does solve the problem, does it solve the problem in a way that
customers will be happy with?
This may result in tweaks or a major redesign to make your product what
the market wants and needs. But if you fail to do this bit properly then you’re
going to spend time and money on a product that will not sell, no matter how
brilliant you think it is.

SECTION 2
Creating a plan
and a QMS
Planning and building a Quality Management System is a
mandatory step in the design and development process
of any medical device.
It is necessary to obtain ISO 13485 and a requirement for gaining a CE marking in the
EU, a UKCA marking in the UK and FDA approval in the US.
A QMS should govern and record every element of your device planning, design and
development in line with the needs of your end user and the demands of the regulator.
If you don’t have a QMS in place when you start those process it may be difficult or
impossible to back solve those requirements.
This in turn, may prove a huge hurdle in winning confidence and funding from
investors, obtaining ISO 13485, gaining a CE marking/FDA approval, and ever
successfully launching your product on the market.
Be prepared – why everything starts with a plan

If you don’t have a QMS in place when you start those process it may be difficult or
impossible to back solve those requirements.
This in turn, may prove a huge hurdle in winning confidence and funding from
investors, obtaining ISO 13485, gaining a CE marking/FDA approval, and ever
successfully launching your product on the market.

How to avoid the biggest mistake in
medical device development
While the temptation is to get ‘stuck’ in and start building your prototype
straight away, the regulatory environment requires you to take a more
measured approach. This measured approach is the means by which you can
mitigate the risk of failure (or the possibility of making dangerous errors).
It requires that you put together a plan for the safe delivery of your end
product. It requires that you define and observe a set of systematic
processes and procedures that will allow you to manage, review, and
document every step of that plan and its delivery.
What’s the plan?

A medical device development plan will cover all the typical phases:
1 2 3 4 5
People & Concept Planning & Design & Test & Validation
Materials Architecture Development Optimization & Launch
The plan is going to be what keeps your project on track, it’s what will stop
you from disappearing permanently down unprofitable rabbit holes.
It should define the objectives and parameters of each stage of a project

and help you deliver against them. Of course, particular elements
within your plan will inevitably fail and fall apart, change and reshape
themselves as you go along.
An unexpected test result or failure of a prototype component may send

you back to the drawing board. They can result in a radical reshaping of
your designs. But the central tenants of your plan will still remain in place;
the order in which phases are tackled and the requirements that need to
be met before each phase can progress.
The plan’s existence as a baseline for your projects’ deliverables and the
procedures you adopt to validate and deliver against it are what counts.
As a formal, approved document the plan can be used to guide both project
execution and project control. The plan should set out your assumptions and
the important decisions you have made prior to commencing the build.
It will form the basis of a shared understanding amongst project

stakeholders, since it will contain within it the approved scope of the
project, including a basic schedule and timeline for completion.

Getting the plan right
It’s important that your plan covers all parts of the process and is realistic
about timelines - as well as the scale of the scientific and engineering
challenges involved.
It may be used as a measure of the time commitment required by investors

and your ability to correctly judge the amount of work involved.
If the plan looks amateur and wildly optimistic it may put potential backers
off. If it proves unrealistic in practice and you end up meeting none of its
targets, it may cause backers to refuse further funding and your entire team
to lose confidence in your ability to deliver.
Planning a Quality Management System

for Medical Device Development
Now you need to describe and define a set of processes and standard
operating procedures (SOPs) by which you can deliver your plan.
This set of process and procedures is your Quality Management System

(QMS) and it is pivotal to the successful delivery of any medical device.
In practice, ISO 13485 is the de facto QMS standard you will need to adopt
to meet these requirements.
And as the diagram below shows, almost the entire product development
lifecycle of a medical device needs to be governed and controlled by the
kind of QMS it specifies:

The design of a functional, effective and fully auditable QMS is no easy task.
Among other things it defines the way risk is reduced and potential non-
conformance mitigated within every function of your organisatioon. It
defines an approach to your work that will prioritise the delivery of an end
product that is safe, effective and performs as intended.
For this reason, ISO 13485: 2016 focuses heavily on the way your QMS will
implement design controls, creating a phased process that verifies and
validates that design output meets the required design inputs at every
stage of the development process.
What is a Quality Management System (QMS)?

A QMS is a system that formally documents processes, procedures, and
responsibilities for achieving quality policies and objectives. A QMS helps
coordinate and direct an organisatioon’s activities to meet customer and
regulatory requirements, improving its effectiveness and efficiency on a
continuous basis. It should be always and easily accessible to stakeholders and
auditors for guidance, review and implementation.
Quality Management Systems – what’s the big deal?

Starting development work before you have correctly understood your
obligations under both the regulations and ISO 13485 and put in place
at least the procedures for device development, risk management and
document control - can have serious consequences for your timeline and
your sanity.
The idea of a developer coming up with a brilliant concept, then slaving away
in their workshop to bring it to life, before showing it to investors, winning
funding and selling their device for millions - is at odds with the reality.
In fact, one of the worst-case scenarios for an investor or quality consultant

is being presented with a fully formed prototype by a developer but no
documentary evidence about how they have got the product to that stage.

Given the lengthy timelines involved in getting from initial idea to applying
for a CE marking, having to go back and reconstruct any of the key stages
of a project, could elongate the whole process unacceptably for an investor.
And, as the diagram below makes clear, you will need EVERY step of your
process recorded and documented appropriately.
Documenting those processes retrospectively may prove to be difficult

or impossible. Although it can be a complex task, creating a plan and
designing a QMS should, therefore, be your top priority.
In the end, your QMS, which has defined, tracked and logged every part of
your design and development process, will also be the tool by which you
draw out and compile your Medical Device File (also known as a Technical
File, Design Dossier or STED file).
These are the documents that are essential to be audited by your Notified
Body to secure your CE marking and finally get your product to market.
If you have been documenting all your processes as you’ve gone along it
should be easier to do this.
The QMS, then, is critical to creating a smooth running, properly organised

and documented design and build process that delivers a product that
meets customer needs and is safe to use.
And it should do this by managing the risk of technical and commercial

failure in a highly proactive way.

How it really happens: Common quality road blocks
in medical device development

How a QMS helps you take a ‘risk-based approach’
to design and development
By guarding against the risk of failure of the design and build processes, a
QMS should ultimately help guard against customer harm or dissatisfaction,
and, therefore, the commercial failure of the product itself.
What is Risk Management?

The purpose of risk management practices are to minimise the risk either
to the achievement of the objectives of the project or to the reliability of the
device and safety of the users.
In any medical device development project a Risk Management Plan needs

to be prepared. This plan lays out the approach to identifying, tracking and
resolving each risk to the device.
The identification of hazards will also need to be documented in the Hazard

Idenitification Document (HID).
All of these documents will ultimately be contained within the “Risk

Management File”
And the elements of the plan should be implemented and evident within
the QMS.
The Risk-based Approach in Medical

Device Development
Risk is a hot topic in ISO 13485: 2016. It is mentioned much more frequently
in the documentation than in the standard’s previous iteration (10 times
more often, to be exact).
ISO 13485 describes a developers’ responsibility in this area as an

overarching risk prevention strategy. But it also acknowledges that this
‘risk-based thinking’ should be commensurate with the level of threat of
harm posed by non-conformance in each area.
“The organisation shall apply a risk-based approach to the control of the

appropriate processes needed for the Quality Management System”

Elsewhere the approach to risk is defined as:
“the systematic application of management policies, procedures and

practices to the tasks of analysing, evaluating, controlling and monitoring risk”
Helpfully, the regulation draws our attention to areas of particular

importance here, including design and development, training and
purchasing (i.e. working with third party suppliers).
These are areas where there is particular danger posed by non-conformance

(e.g. a malfunction in design) or where there is increased risk of losing control
over a particular area of compliance, for example in training or outsourcing.
The responsibility for assessing the compliance of your suppliers against

the relevant regulations might seem an onerous one, but it is entirely
consistent with the risk-based approach. And you will need to have
a process in place to assess whether any product or service they are
supplying to you is compliant.
But this risk-based approach, with its focus on outcomes and reducing risk
of customer harm or dissatisfaction can also be an opportunity.
It is intended, after all, to move away from an ‘inspect and control’

regulatory paradigm for the improvement of quality in the medical device
industry and save companies the effort of endless remedial work.
It should mean you are continually reviewing processes and focused on

improving the consistency and quality of your end product before anything
goes wrong. This is an opportunity for innovation as you strive to make your
processes as efficient, innovative and error free as possible:
5 benefits of adopting the Risk-based approach to quality

management in ISO 13485:2016
Improved levels of regulatory compliance
P
rocess efficiency improves when attention is placed on higher risk
issues and requirements and dialled down for lower risk items
E
nables companies to focus efforts on the aspects of the QMS with the
highest risk
E
nsures problems are solved before they impact the product –
reduces costs of remedial work
Innovation through the effort of continual improvement

Risk management as part of medical device
design requirements
One of the harmonised standards associated with ISO 13485 is ISO 14971 –
“Application of Risk Management to Medical Devices”
Those requirements are clearly stipulated within ISO 13485 itself.
Clause 7.1 of ISO 13485: 2016 specifies the way the risk management requirements of
the QMS should be implemented as you begin to formally design and build.
It describes a mandatory process for planning and product realisation, which governs,
captures and records every material stage of the design and development of a
medical device. These processes are put in place to minimise the risk of failure, while
promoting transparency and accountability at all times. And you need to plan for this.
ISO 13485 expects you to create a design process that:
B
reaks the process down into stages and with identifiable deliverables at
each stage
Identifies check points for reviews and specifies its participants
E
stablishes a communication plan and a mechanism for communications
C
reates and updates necessary records as the process continues
As part of the way risk is managed throughout the process the QMS must also make
provision for proper design change control; devising processes that assess the
potential risks involved in making alterations. ISO requires that you:
D
ocument the design changes
A
pprove the changes only after review and verification
E
valuate the effects of changes
D
ocument the results, and take any necessary corrective and preventive
actions to solve problems arising from them
It will take time and effort to ensure you get all this right. It will take considerable time
and effort to create and define the SOPs that form your QMS as a whole, as well as
building the system of digital or real world files where all its outputs will reside.
It will be expensive, time-consuming, and even impossible to piece all that together
retrospectively.
But the reality is you will not be able to deliver or legally market your product without
doing this.

Choosing a digital QMS solution for medical
device development
A QMS can be paper based or it can be a piece of software or an app which allows you
document your procedures, as well as store and lockdown project documentation for
review and approval by key stakeholders in a project.
It needs to be a repository for all your quality documentation and be accessible to

everyone involved in a project or by auditors on demand.
Once it is established it should help you effectively organise and deliver all the
required elements of a development plan.
This is particularly significant in medical device development where there are multiple
dependencies and the need for strict adherence to regulations around the storage and
approval of documentation and iterations of designs.
For this reason it is highly recommended that you consider using a digital QMS rather
than struggle with a paper/email/Excel solution.
Having said that, there are many different kinds of digital solutions on the market with
very different price tags and capabilities.
A ‘full blown’ eQMS, as used by major pharma and device development companies
may be prohibitively expensive for a SME and may require your business or processes
to be structured in ways that don’t make sense for a smaller organisatioon.

In a large organisatioon with a sizeable quality resource dedicated to training and
enforcement, the adoption of a heavy weight eQMS may be precisely what is required.
It will help properly administer and control the contributions to, and workflows within
projects created by thousands of employees over many years.
However, for smaller businesses, a lightweight, process driven intranet, which

can be installed in a few days and mastered quickly by your staff, may be a more
sensible investment.
These systems are highly robust, but less proscriptive in their demands about the
exact way they are set up and deployed.
Using these kind of tools will make it easier for you and others to store the huge
amount of documentation that will inevitably be generated by this process.
Nevertheless, it will be rigorous enough for you to be able to lock down quality
documents, observe change control requirements, as well as record and track version
histories for future review.
They can help you set up your own processes, workflows and file storage hierarchy in
line with legal requirements, but in a way that makes sense for you, rather than forcing
you to work in ways a ‘med tech giant’ might need to.
At the same time, the flexibility of these solutions can also help you scale up more
effectively as you grow.
They can take you from an ‘entry level’ QMS, which can help you meet the most
fundamental regulatory requirements of ISO 13485, to the highest level of ‘quality
maturity’ that helps embed a culture of proactive QA at every level of your organisation

SECTION 3
Executing your plan

- the key stages of
design and delivery
So, how does all this work in practice? What are
the key stages of design and development and
how can a QMS help you achieve these goals in
a user centric, efficient and compliant way?
The right QMS will help you define, martial and manage all the required
inputs, outputs and processes that will get you through to launch and make
the auditing process required by ISO and the regulators in every market
smoother and more efficient.
In doing so your QMS should help you keep the wants and needs of the
end user at the very centre of all your design considerations. This is, after
all at the heart of ISO 13485 and the key to commercial success.
Design is not just about making objects pretty.

Design is the process of understanding customer
needs and then creating a product or service – physical,
digital or both – that addresses their unmet needs.
McKinsey ‘”The Changing Face of medical-device design”
The right digital QMS should help you gather, store and collate all of the
necessary design inputs from across your organisation.
These inputs require material from every function, creative, marketing and
commercial, as you begin to pinpoint user needs, building a regulatory
and business case for your project, and the foundation of a powerful, user-
centric design.

What is a design input?
Design inputs include those mandatory elements and other requirements, derived
from user research or regulation, that you will need to understand and incorporate
into your final, definitive product designs.
You need them to deliver a product that will ultimately answer market needs.
Inputs include:
F
unctional, performance, and safety requirements, according to the intended use,
A
pplicable statutory and regulatory requirements,
Information derived from previous similar designs,
O
ther requirements essential for design and development, and
O
utput(s) of risk management
According to some experts, the process of defining your inputs could take up 30% of
your project timeline, but it is absolutely essential to get this right.
If there is a problem with a product that has come to market, it can usually be traced
back to some inadequacy or missing element within that project’s design inputs.
The design process is all about managing these inputs and turning them into outputs
(designs, specifications, plans, prototypes etc). The final design and device outputs
should be capable of being verified and validated against these original inputs.
QMS rather than struggle with a paper/email/Excel solution.
Having said that, there are many different kinds of digital solutions on the market with
very different price tags and capabilities.
A ‘full blown’ eQMS, as used by major pharma and device development companies
may be prohibitively expensive for a SME and may require your business or processes
to be structured in ways that don’t make sense for a smaller organisatioon.
Compiling your specification documentation

From your initial ideation process will emerge a set of specification documents which
will govern your design work.
These are your User Requirement Specifications and Engineering Design

Specifications.

Device User Requirement Specifications (URS)
The URS is the primary design input document. This is a critical document which
should form the bedrock of your design work. It is the document to which you will
refer as you progress your designs. Eventually the regulators will expect you to
validate your device against them.
User requirements should be at the heart of everything you do. After all, there is no
commercial point in developing a product that does not meet the identified needs of
its intended users.
The URS should focus on the way the device is intended to be used. Without
specifying solutions, it should state a series of discrete requirements for the device
and how the user should interact with it.
The document should state:
The known physical characteristics of the device to be developed;

• The imagined operating logic of the interface
• How it should be interacted with
• How it is expected to perform
What is known about the user population and their characteristics;

• Will they be clinical professionals, trained or untrained?
• What age and gender are they?
• Are they likely to have disabilities or infirmities that will affect the way they use
the device?
• What training and information will they need to use the device safely and
effectively?
What is known about the environment where the device is expected to be used;
• Is it for clinical or domestic?
• Will it be used in a home, hospital or ambulance?
• What are the potential environmental impacts on use of the device in
particular settings, i.e. is it expected that there will be noise, traffic?
It should be expected that a URS will develop in the early phases of the project. Once
initially issued, the URS shall be subject to change control procedures.
A good QMS will help you gather and record the inputs for this document from
various parties inside and outside your organisatioon. It should allow you to share
drafts of the URS in progress, gathering feedback and, eventually, final approval for
the next stage of design planning to begin.
The way the final device functions will eventually be validated against these Device
User Requirements.

Engineering Design Specification (EDS)
This may alternatively be called a Functional Specifications or a Design Specification.
It is the primary device specification. It is the second Design Input document.
The creation of the EDS should start in parallel with the system/architecture definition.
Initially it will be incomplete and top level, but will grow in completeness and detail
as the design evolves. It is in this document that solutions will be proposed. This will
typically be a much more detailed document than the URS.
The EDS is the design team’s response to the URS and therefore every clause of the
URS must be addressed by at least one clause in the EDS. The EDS may also respond to
outputs from risk analyses e.g. Failure Mode and Effects Analysis (FMEA) mitigations.

It traces all design inputs (from URS, Product Requirement Specifications,
FMEAs, User Studies, Risk Analyses, etc.)
Defines which are mandatory requirements or not
Creates quantifiable and testable independent requirements clauses

Describes a strategy for how this will be achieved (e.g. design controls,
manufacturing process, choice of materials, etc
Describes the strategy for verifying that the requirement has been met
The final design outputs, schematics, diagrams will be developed against these
specifications.
Managing the design process

In medical device development, the phasing of the design and development process
is not only desirable, it is a legal requirement.
ISIO 13485 is clear about what is expected from a design process:
“At suitable stages, systematic reviews of design and development shall be

performed in accordance with planned and documented arrangements to:

a) evaluate the ability of the results of design and development to meet
requirements;

b) identify and propose necessary actions. Participants in such reviews
shall include representatives of functions concerned with the design and
development stage being reviewed, as well as other specialist personnel.
Records of the results of the reviews and any necessary actions shall be
maintained and include the identification of the design under review, the
participants involved and the date of the review.”

The presence of design controls, therefore, are central to building a
compliant QMS.
They are designed to address the needs of users and patients, ensuring
that the product is:
1. Designed according to its inputs and requirements.
2. Proven to meet applicable standards.
3. Will meet performance criteria.
4. s safe for use as a medical device.
Controls are achieved by breaking the process down into phases with their
own plans, inputs and expected outputs.
At the end of each phase its outputs are reviewed and documented against
its original objectives. Progress is recorded and changes accounted for.
The design of the product is continually checked against the end user
requirements, helping to prevent the risk of deviation from the plan and
non-conformity in the end product. The documentation is then stored to
aid traceability and future auditing.
The Prince2 Project Management methodology also champions this

approach, ensuring projects are tackled in distinct phases while allowing
plans to be tweaked to meet new and unexpected requirements that
emerge along the way. Prince 2 ensures that project objectives are
regularly reviewed in formal phase gate meeting and mistakes are not
replicated across an entire development process. Digital QMS tools
can help with these objectives and add further value to the Project
Management function.

How a digital QMS can help deliver required
design controls
Digital tools that support phase gating of documentation can help
organisations structure their processes in exactly this way.
A modern, lightweight QMS solution can give you the ultimate flexibility for
cross functional collaboration.
It can help you:

Create a user-centric design process that supports multiple
iterations of designs and prototypes

Impose formal digital checkpoints where progress can be
regularly checked against specific requirements to ensure quality
processes have been observed and maintained.
A digital QMS can help you:

gather documents, feedback and contributions from key
stakeholders within each phase

seek final approval when reviews have been done, in order to
trigger the next phase of a project.

record and store all the relevant documentation, together with
their version histories, which will be vital for future audits.
Many med tech companies could benefit from moving

their development processes beyond the traditional
V shaped water fall model. That doesn’t mean
descending into chaos. You still need robust stage-
gates with clear “pass or fail” criteria and strong leaders
who don’t let weak projects progress. However, for
in-between stage gates, it’s important that designers
can work fluidly, iteratively and creatively rather than
ticking boxes in a beaurcratic process.
Steve Eichmann - Johnson and Johnson.

Medical device design control cycle
The Design and Development clause of ISO follows the PDCA (Plan-do-check-act) cycle.
Design verification and validation

At the end of these steps, ISO requires a process of verification and validation of the
design and device to take place against both user needs and the design.
The objective here is to demonstrate and document that you have delivered what
you set out to deliver, in other words that your outputs match the requirements laid
out in your inputs.

Design Verification confirms that you have designed the device correctly
(according to your Engineering Design Specifications)

Design Validation ensures that you designed the right device (according to
your user requirement specifications)
These are mandatory processes that you will need to evidence and incorporate within
your Design History File, so you will need to devise a careful plan for these tasks.
Verification and validation are done at the end of a lengthy process that could have
taken weeks, months or even years to complete.
For this reason having an easily auditable document storage system is vital, including
clearly labelled definitive, final versions of requirement specs, time and date stamped,
locked down for editing.

Final steps to
getting to market
The right QMS will also help you fulfil the auditing
requirements that will determine whether you
pass or fail the certification and/or inspection
process and whether your product can finally be
legally marketed.
Preparation of your Medical Device File

Your technical documentation, known as a Technical File, Design Dossier
or STED file, is the critical part of getting to market. For Class II devices and
above your technical file will be subject to review by a notified body before
your CE marking can be granted.
Note
This technical file requirement will be difficult or impossible to compile
retrospectively from lost, scattered or incomplete records. Having a QMS
in place early on (with document control at its heart), will make it easier
and quicker to assemble the technical file later.
Your technical file includes detailed information about the design,

function, composition, use, claims, and clinical evaluation of your medical
device. Technical documentation has to be developed during the design and
development process of a device and maintained throughout its entire life cycle.
It should:
Include details drawn from your product description, product

specifications, as well as your product verification and
validation processes.
Contain the full technical detail of what your product was

designed to do, how it works and the documentary proof that
it works.
B e available on request for the whole product life cycle,

but at least for a period of 5 years from production.

The Design History File (DHF)
For FDA approval a Design History File must be maintained for every device that you
manufacture.
The DHF demonstrates that a device was developed in accordance with both the
design plan and all the documented requirements.
Your design plan must reflect compliance with the design controls process and
should be included as part of the DHF.
The DHF must either contain or reference the necessary documents. This means that
you should either create a folder that contains the required documents or create a
document that acts as a reference sheet for the required materials. In this case, the
materials would be stored in a software QMS and the DHF would link out to them.
Certification by Notified Bodied

As referenced above the Notified Body will inspect, then pass or fail a device created
by an organisation based on technical file and an audit of your QMS.
If successful, a manufacturer will then make their ‘declaration of conformity, place a

CE mark on the device – put it to market and sell it.
Transfer to manufacture
This is the final part of the process and a good digital QMS will help you instantly
share all the relevant documentation, digitally and in a risk free way,
Don’t forget, as mentioned above, you are responsible for the compliance of your
manufacturers’ processes as much as your own.
You will need a documented plan and process for the handover of the designs and
plans necessary to build the product.
A digital QMS will allow you to set up a work flow that should help you assemble all
the appropriate documentation including the specifications and technical files that will
be needed by your partner to produce your item to the required standard.
Certain digital QMS can even let you create a new extranet connection instantly at
the touch of the button, so all of the relevant diagrams, schematics, QMS and SOP
documentation, checklists and flow charts can be delivered to and accessed from
one location.

Launch and follow up
Don’t forget, you will also need to carry out post-market follow-up studies, analysing
the device’s use in practice, how it interacts with other devices and drugs, whether it
has had any performance failures etc.
Make sure your QMS is set up to capture and record reports of defects. Make sure
there is a procedure in place for acting on them. At this time you should have a clearly
defined cycle of continuous improvement for your device.
You also will be subject to further audit, depending on the classification of your device.
Following successful certification notified bodies are required to perform an annual

audit of your quality management system and then additional unannounced audits.
For Class I Sterile or Measuring, Class IIa and IIb manufacturers there may be at least
one unannounced audit every three years.
For a Class III device you can expect at least one unannounced audit every 2 years,
Higher risk device manufacturers and/or manufacturers with a poor history of

compliance may be subject to unannounced audits with even greater frequency.
Manufacturers have a responsibility to implement an effective post-market

surveillance system to ensure that any problems or risks associated with the use
of their device once freely marketed are identified early, reported to competent
authorities, and acted upon. This is known as the medical devices vigilance system.
For software, a system of registration / activation may aid the manufacturer trace
devices that have been distributed by third party distributors or by app stores. This is
important when undertaking any field safety corrective action.

Conclusion
If you want to be a successful medical device
developer you cannot avoid the issue of compliance.
The way you create, amend and archive all your records must be meticulous and
conform to required standards. Quality documentation must be accessible to your staff
and auditable at all times. Your QMS should demonstrate how a ‘risk-based approach’
lies at the heart of the way your teams collaborate together and with third party suppliers.
But the good news is that a lot of this regulatory burden, and the quality systems
mandated by the MHRA, ISO and the FDA, are practical and common sense measures
that will make your processes safer and more efficient.
Having said that, and as we have illustrated, bringing a medical device to market is a
complex process with many bear traps for the unwary and disorganised.
A paper-based approach to Quality Management will inevitably fail to adequately

contain the scale and complexity of the documentation that will be generated by this
process. Likewise, using Google Drive and Dropbox to digitally manage and administer
this system will likely not offer sufficient document control to satisfy the regulator.
At the same time a modern, agile business doesn’t want to get bogged down with
heavyweight eQMS solutions, or get sidelined attempting to build their own with SharePoint.
A plan that rests on back solving compliance is not going to convince potential
investors that you can bring them return on their investment in realistic timescale in a
competitive market. It won’t help you concentrate on creating a functioning product, as
you approach critical delivery deadlines.
Finding a scalable, digital QMS solution that can help you create and manage a compliant
end-to-end design and development process should, therefore, be a top priority.
Because if you want to be a successful medical device developer – if you want to

create a product that delivers unique benefits to patients, if you‘re going to beat the
rest to market and achieve all the commercial rewards you deserve - you need to be
properly prepared for what’s to come.
You need to get organised.

Glossary
If you want to be a successful medical device developer you

cannot avoid the issue of compliance.
API – Active Pharmaceutical FMEA – Failure Mode Effects Analysis

Ingredient – biologically active – model used to prioritise potential
ingredient in pharmaceutical drug. defects based on their severity, expected
occurrence and likelihood of detection.
BOM – Bill Of Material – list of raw
materials, components and FTA – Fault Tree Analysis – a top down,
subassemblies that make a product. deductive failure analysis in which an
undesired state of a system is analysed
DFM – Design For Manufacture – using Boolean logic to combine a series of
designing a product for easy lower level events.
manufacturing.
FTO - Freedom To Operate – determining
DHR – Device History Record (batch whether testing or commercialising a
record) – combination or records product can be done without infringing
containing the production history of a valid intellectual property rights of others.
finished device.
HID – Hazard Identification – identification of
DoE – Design of Experiment – systematic potential conditions, events or circumstances
method to determine the relationship that could lead to, or contribute to an
between factors affecting a process and unplanned or undesirable event.
the output of the process (cause and effect
relationship). IFU – Instructions For Use – information
provided by the manufacturer to inform
DP – Detail Part (drawing) – drawing the device user of the medical device’s
containing sufficient information for intended purpose and proper use and of
production of a part. any precautions to be taken.
DQ – Design Qualification – documented IP - Intellectual Property – intangible

verification that the proposed design of property that is the result of creativity, such as
the device is suitable for the intended patents, copyrights, designs, inventions, etc.
purpose.
MO - Marketing Opportunity –
EDS – Engineering Design Specification – opportunity to attract new customers,
document detailing the requirements that introduce new products, etc.
must be met in order for the product to
meet the User Requirement Specification. PCB – Printed Circuit Board –
collection of electronic components
FEA – Finite Element Analysis – connected via conductive tracks on
computerised method for predicting how a non-conductive board.
a product reacts to real-world forces,
vibration, heat, fluid flow, and other
physical effects.

PIL – Patient Information Leaflet / TI – Task Instruction – detailed written
Packaging Insert Leaflet – information instruction to achieve uniformity of the
provided by the manufacturer about performance of a task.
doses, side effects and contraindications
for a pharmaceutical product or a drug/ TPR – Test Protocol – detailed written
device combination product. document that outlines the requirements,
activities, resources, documentation and
PoP - Proof of Principle – realisation schedules to be completed in order to
of a method or idea to demonstrate execute a test.
its feasibility.
UET – User Event Tree - a bottom
PRS – Product Requirement Specification up, causal failure analysis in which an
– definition of requirements needed to be undesired state of a system caused by the
achieved in order for the product to meet user is analysed using Boolean logic to
the User Requirement Specification. model risk.
QC – Quality Control – activities intended URS - User Requirement

to ensure manufactured product meets Specification – document specifying
acceptance criteria. what the user requires the product to do.
RA - Risk Analysis – systemic use of

available information to identify hazards
and eliminate risk.
RMP - Risk Management Plan –

documented plan for systematic
application of management policies,
procedures and practices to the tasks
of analysing, evaluating, controlling and
monitoring risk.
SOP – Standard Operating Instruction

– detailed written instruction to achieve
uniformity of the performance of a
specific function.

Discover how
Cognidox can
help you.
See how Cognidox can help tame the
document anarchy that is costing you
time and money.
Book A Demo Here

Cognidox - A Complete Guide To Medical Device Development

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cognidox - A Complete Guide To Medical Device Development

Uploaded by

Copyright:

Available Formats

A complete

The scale of the challenge 3

SECTION 1: DEFINING THE CHALLENGE 6

SECTION 2: CREATING A PLAN & A QUALITY MANAGEMENT SYSTEM 14

Be prepared – why everything starts with a plan 14

What is a design input? 26

2 A complete guide to medical device development

But if you want to be a successful medical device developer, you’re

The scale of the challenge

The consequences and penalties for making mistakes and releasing

But the rewards for success are considerable:

THE MED £7.6 billion The distinction and boundaries between

Competition is stiff and success difficult to achieve:

As a developer, therefore, you need to make sure you’re properly

3 A complete guide to medical device development

The world is emerging from an international pandemic with an ageing

Demand is strong with different competitors bringing wearables, apps

To succeed in this market, therefore, medical device developers must:

4 A complete guide to medical device development

The resilience and flexibility of your planning and QMS is essential

This eBook is designed to help you prepare for these requirements.

A note for readers

Section 1: Defining the challenge

Section 2: Creating a plan and a Quality Management System

Section 3: Executing your plan

5 A complete guide to medical device development

These distinctions are important, because it is going to impact on the

In Europe the regulations that govern the development of medical

Following Brexit, medical devices in Great Britain are now regulated

The US has similar classifications of device to the E,U with details

6 A complete guide to medical device development

The European Medical Devices Regulation (the EU MDR) defines a

investigation, replacement or modification of the anatomy or a

f or the control or support of conception; or

What is an In Vitro Diagnostic Medical Device?

“any medical device which is a reagent, reagent product, calibrator, control

(a) concerning a physiological or pathological process or state;

(b) concerning congenital physical or mental impairments;

(c) concerning the predisposition to a medical condition or a disease;

(d) to determine the safety and compatibility with potential recipients;

(e) to predict treatment response or reactions;

(f) to define or monitoring therapeutic measures.

Specimen receptacles shall also be deemed to be IVDs.

7 A complete guide to medical device development

Software as a Medical Device (SaMD) is defined as:

“software intended to be used for one or more medical purposes that

Examples include devices that monitor fitness, health or general

However, many other apps and pieces of stand-alone software

Medical Device Classification,

Manufacturers need to demonstrate that the medical device meets

8 A complete guide to medical device development

In the EU when it comes to compliance, the burden of proof is higher

9 A complete guide to medical device development

Developed and manufactured their device in accordance with the relevant

They can share the required technical documentation with auditors to

It is not uncommon for implantable device clinical studies, to last 5 years+

10 A complete guide to medical device development

FDA Medical Device Classification

11 A complete guide to medical device development

Have you identified a real gap in the market and

To make matters worse customers responded badly to the appearance of the

12 A complete guide to medical device development

investigation, replacement or modification of the anatomy or a

f or the control or support of conception; or

(a) concerning a physiological or pathological process or state;

Improved levels of regulatory compliance

Innovation through the effort of continual improvement

Identifies check points for reviews and specifies its participants

Information derived from previous similar designs,