SO, YOU WANT TO BE A Successful Med TECH Device Developer

A guide to medical device development

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 med tech 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 distinction and boundaries between software, apps and medical devices are blurring, opening up new opportunities but presenting new complexities for developers.

med-dev-intro-info-cropped-2 (1)

As a developer, therefore, you need to make sure you’re properly focusing your time and resources from the very beginning of the process, to maximise your chances of success.

Why med tech success is now even more difficult to achieve

 In 2018 McKinsey found that sales opportunities in high-growth med tech segments were shrinking as it became more challenging to innovate and global competition continued to tighten. They concluded that successful products in this category were those that:

  • Were differentiated by a strong, user-centric design
  • Were able to come to market more quickly and more efficiently than their competitors

We conclude, therefore, that in the future successful medical device developers will need to:

  • Understand from the outset of their journey precisely what kind of device they are developing and what their regulatory obligations will be
  • Meticulously plan their approach to compliance, design, development and manufacture
  • Focus on implementing Quality Management Systems (QMS) that, from the start, can help them deliver differentiated, user-centric design as flexibly, quickly and efficiently 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 guide focuses on helping developers avoid the biggest and most common mistake in medical device development – the failure to plan effectively.

A plan is essential because designing and developing a medical device will take longer than you think, there will be set-backs and challenges you cannot possibly predict.

Your plan and the Quality System or mechanism that you create to deliver it, will be the means by which you make a product that is safe and capable of meeting all the user and regulatory demands that are made of it.

This section of our website is designed to help you prepare for these requirements. To help you realise the scale of the task before you, plus the kind of tools you’ll need to navigate the design, development and regulatory challenges that lie ahead.

med-dev-intro-img2 (1)

What is a medical device?

A short guide to medical device regulation

Is the product you are intending to develop a Medical Device (MD), an In Vitro Diagnostic Medical Device (IVD), or Software as a Medical Device (SaMD)?

These distinctions are important, because they are 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 and by extension the UK, 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.

In the EU market these legislations will dictate and define the processes you will need to go through to secure your CE marking, the only method by which you will be legally allowed to market your product in that territory.

The US has similar classifications of device with different regulatory requirements associated with them. These are all set out here by their regulatory body - the FDA.

What is the definition of a medical device?

The European Medical Devices Regulation 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.... specific medical purposes. These are:

  • diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease;
  • diagnosis, 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;
  • providing information by means of in vitro examination of specimens derived from the human body, including organ, blood and tissue donations;
  • for the control or support of conception; or
  • products specifically intended for the cleaning, disinfection or sterilisation of devices.“

What is an In Vitro Diagnostic medical device?

An 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."

med-dev-sec-1-img1 (1)

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.”

Apps or devices that monitor fitness, health or general wellbeing, are NOT usually considered to be medical devices, nor are those 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.

This definition might 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 one of the Notified Bodies which are licensed and approved in the UK by the MHRA .

The European Commission’s main objective is to help ensure that unsafe or otherwise non-compliant products do not find their way onto the EU market. 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.

med-dev-sec1-info1 (1)

Applying for a CE marking for your medical device

When planning a medical device you need to factor in the time and resources required to apply for your CE marking. 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:

  1. Developed and manufactured their device in accordance with the relevant regulations and standards,
  2. That they have a technical file for the product that provides evidence of the compliance,
  3. That they have a quality management system in place to manage the processes involved in developing, manufacturing and managing all regulatory activities associated with a medical device.
  • In the UK, conformity with these requirements is self-assessed for Class I devices by the manufacturer.  But this only applies to those devices which are not sterile or do not have a measuring function. In these cases, manufacturers are responsible for assessing and certifying that they are compliant. The manufacturer will create and sign the EC Declaration of Conformity, which is a legally binding document.
  • For Class I Sterile or Measuring medical devices, the same applies, but with one difference: the part of the technical file that relates to sterilisation or measurement must be reviewed by a Notified Body and an EC Certificate issued by them in order to CE mark the device and place it on the market.
  • 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.

Typical lead time for a 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 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)
  • 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 in excess of five years.


What's the big idea?  Defining the med tech product-customer fit.

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 it or would buy it?  

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 design control 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 complete, required insulin dose within a single inhalation. 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 New York Times, cost the pharma giant a total of $2.8 billion.

med-dev-intro-img1 (1)

User-centred design starts with the customer

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 lifecycle.

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.

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?

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 Summary Technical Documentation (STED) 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.

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.


Download your guide to understanding how best to apply risk-based thinking to quality processes

In this eBook, we break down risk assessment techniques and consider their applicability to quality management. We’ll also provide you with a six-step methodology that will help you deliver clear evidence of a risk-based approach to quality.

Cognidox-LP-eBook2 (1) (1)

Planning and Building a Quality Management System for Medical Device Development

What is a Quality Management System (QMS)?

A QMS formally documents processes, procedures, and responsibilities for achieving quality policies and objectives. A QMS helps coordinate and direct an organisation’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.

Planning and building a Quality Management System is not just best practice, it is a mandatory step in the design and product development strategy of any medical device.

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 QMS software in place when you start those processes 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, and successfully launching your product on the market.

Be prepared – why everything starts with a plan

So, you’ve had your brilliant idea. You know what kind of device you want to build. You have a vision of the product and a commercial proposition that has been validated by your research. When can you start developing?

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 follows the typical phases:

med-dev-sec2-info1 (1)

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 and it is pivotal to the successful delivery of any medical device.

Nearly all Medical Device regulations require that you are able to prove you have a compliant and operational QMS in place to martial your business processes and deliver products of a consistent quality to your end user:

In practice, certainly in the EU, 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:

med-dev-sec2-info2 (1)

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 organisation. It outlines 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 your design outputs match requirements at any stage of the development process.

What’s the big deal about a Quality Management System?

Starting development work before you have correctly understood your obligations under both the regulations and ISO 13485 - and before you have 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.

As the diagram below makes clear, you will need EVERY step of your process recorded and documented appropriately.

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

medtech-sec2-info3 (1)

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 a QMS helps you take a ‘risk-based approach’ to medical device 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 in Med Tech?

The purpose of risk management practices are to minimise the risk either to the achievement of the objectives of the med tech project or to the reliability of the developed 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 a device, associated with its design, production, storage and usage.

The identification of hazards will also need to be documented in the Hazard Identification 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 according to the procedures of the QMS.

ISO 13485: 2016 and the risk-based approach

Risk is a hot topic in ISO 13485: 2016. It is mentioned much more frequently in the current documentation than in the standard’s previous iteration (10 times more often, to be exact).

ISO 13485 design control 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 their QMS (and, therefore, 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

  1. Improved levels of regulatory compliance
  2. Process efficiency improves when attention is placed on higher risk issues and requirements and dialled down for lower risk items
  3. Enables companies to focus efforts on the aspects of the QMS with the highest risk
  4. Ensures problems are solved before they impact the product – reduces costs of remedial work
  5. Innovation through the effort of continual improvement

Risk management as part of medical device design requirements

One of the harmonized 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 medical device design process that:

  • Breaks the process down into stages and with identifiable deliverables at each stage
  • Identifies check points for reviews and specifies its participants
  • Establishes a communication plan and a mechanism for communications
  • Creates 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. To this end ISO requires that you:

  • Document the design changes
  • Approve the changes only after review and verification
  • Evaluate the effects of changes
  • Document 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.

med-dev-se2-img4 (1)

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 organisation.

Towards a more scalable solution

In a large organisation with a sizeable quality resource dedicated to training and enforcement, the adoption of a heavyweight 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 kinds 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.

So, you want to be a successful medical device developer?

Then download this guide to get an eBook version delivered to your inbox, featuring an additional Med Tech glossary.

pages shadow (1) (1) (1)

How to design and build a medical device

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 in medical device design?

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.

Medical device design inputs include:

  • functional, performance, and safety requirements, according to the intended use,
  • applicable statutory and regulatory requirements,
  • information derived from previous similar designs,
  • other requirements essential for design and development, and
  • output(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.

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.

med-dev-sec3-img1 (1)

Medical 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. As you progress your designs, the URS is the document to which you will refer. Eventually the regulators will expect you to validate your device against it.

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:

  1. 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
  2. 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?
  3. What training and information will they need to use the device safely and effectively?
  4. 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 procedure.

A good QMS will help you gather and record the inputs for this document from various parties inside and outside your organization. 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.

Medical Device 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 med tech design process

In medical device development, the phasing of the design and development process is not only desirable, it is a legal requirement.

ISO 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:

  • evaluate the ability of the results of design and development to meet requirements;
  • 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
  2. Proven to meet applicable standards
  3. Will meet performance
  4. Is 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.

Adding value to a Prince 2 approach

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.

As the diagram below illustrates, the design control cycle requires a phased approach to medical device design and development, gathering documentation together for review and approval at critical stages, while feeding into a master Design History File (DHF) that can be accessed at the end of the process. This is more than a ‘nice to have’, it’s an actual legal requirement.

The medical device design control cycle

med-dev-sec3-info1 (1)

How a digital QMS can help deliver required design controls

“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.

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

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, electronically signed and locked down for editing.

How to bring a medical device 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

The Medical Device File, also 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.

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
  • Contain the full technical detail of what your product was designed to do, how it works and the documentary proof that it
  • Be 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)

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 CEmark 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 will allow documents relating to a device to be packaged together and 'published‘ to licensed users via an extranet, as part of a complete product release process.

Launch and follow up

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.

med-dev-2 (1)

Meeting CAPA requirements within your Quality Management System

In fact, the Corrective and Preventative Action (CAPA) requirements of ISO 13485 and the regulatory bodies mandate that your QMS includes processes for regularly assessing and acting upon quality issues drawn from a range of data sources, commensurate with the level of risk they pose to the end user. This quality data (such as information drawn from customer complaints logs, returned products, service records etc) should help you identify and investigate issues quickly and throroughly, correct them and prevent their future occurrence.

In this way 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.


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 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 something like 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 want 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.

Latest Blog Posts

Why not just use Qualio as your medical device eQMS?

Qualio is an eQMS platform launched in 2012 by Irish entrepreneur Robert Fenton. From small beginnings, his ...

What are good documentation practices & how can they best be implemented?

Good documentation practices (also known as GdocP or GDP) are guidelines for document management and control ...

How to scale your medical device consultancy practice

  Many medical device consultancy practices work on a fee-based model, helping clients with regulatory and ...

Medical Device, IVD or SaMD? Medical device regulation explained

  Question for you: is the product you intend to develop a Medical Device, an In Vitro Diagnostic Medical ...