SO, YOU WANT TO BE A Successful Med tECH Device DevelopER?

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:

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

When is software classed as a medical device?

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

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.

Applying for a CE marking for your medical device

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.

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.

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?

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.

What is a Quality Management System (QMS)?

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:

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.

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:

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:

Elsewhere the approach to risk is defined as:

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:

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.

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

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.

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:

• 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

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

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

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.

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.

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.

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.