I think my innovation might be a medical device. What do I do?

OK, so you’ve come up with an amazing idea for a new healthcare software innovation. Maybe it’s an app, or a SAAS platform. It’s perfect, you know people will love it, it meets a clear need, you can charge for it and people will happily pay. The only problem is, you think it might need to be certified as a medical device.

What do you do?

Well the first thing is, don’t panic. 

Sometimes it’s not that clear cut whether a product does need to be certified or not. So the first thing is to check the definitions available online. But even if it definitely is a medical device, still don’t panic. Some people like to make out that certification is really hard, and really expensive. Of course it does involve some effort and some expense, but it shouldn’t be that way. We’re going to take a closer look at what you need to do to get your device certified.

What is a Medical Device?

But firstly, some more information about what a medical device is. In this post we’re going to be looking at the regulations for Europe. Other regions and countries have different systems and definitions, but the basic principles will be similar.  It's also worth saying that current indications are that the UK will continue to operate a similar system of certification after the Brexit transition period, so even if you're only planning to launching your product in the UK, the following is still relevant.

Also we’re going to be looking at Software as a medical device. If your innovation involves a physical product there are more things you need to think about, although what I say here applies pretty much to any software you need to run on your device as well.

The EU definition of a medical device goes back to the Medical Device Directive: MDD (93/42/EEC), but is about to be replaced by the new Medical Device Regulation (MDR EU 2017/745). The regulation defines a medical device as ‘anything which is used for treating or preventing disease, or for restoring, correcting or modifying physiological function’. 

Any “instrument, apparatus, appliance, software, implant, reagent, material or other article” intended to be used for any of the following medical purposes:

• Diagnosis, prevention, monitoring, treatment or alleviation of disease, disability or injury, where prevention of disability and injury is excluded
• Investigation, replacement or modification of an anatomical, physiological or pathological process
• Providing data via in vitro examination of samples derived from a human body
• Products intended for cleaning, disinfection and sterilization of medical devices
• Devices for the control and support of conception, even if they achieve their intended purpose by pharmacological, immunological or metabolic means.

So if your software does any of those things, it's a medical device.

Next you need to decide what class of medical device you are. These are laid out in the MDR. There are four categories:

• Class I. This is the lowest risk. Non-invasive devices are class I unless they are caught by other rules.
• Class IIa. Some rules relate to Active Devices. Standalone software is considered to be an Active Device. Devices intended for diagnosis may be class IIa
• Class IIb would apply where there is more specific risk of harm or injury
• Class III is for the most potentially hazardous medical devices.

In the UK, the agency which oversees the regulation is the MHRA. They provide a helpful guide to software as a medical device here, although this hasn't yet been updated to reflect the new MDR. The MDR includes a new 'rule 11':

Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause:

• death or an irreversible deterioration of a person’s state of health, in which case it is in class III; or
• a serious deterioration of a person’s state of health or a surgical intervention, in which case it is classified as class IIb.

This rule significantly increases the chances that your medical device software will be classified as IIa, where previously it would have been classified as class I.

How do I get my Device Certified?

At the heart of the certification process is the creation of a technical file. This is a collection of documents about the product which demonstrate that it is compliant with the rules of the directive.

If your device is Class I you can self-certify. This means you create a technical file and then submit this the regulator (in the UK, the MHRA). If the MHRA agrees, you can then consider your device certified and may apply the CE logo.

If your device is Class IIa you need to provide evidence to a Notified Body who will confirm whether or not you have met the requirements of the Directive. The Notified Body will undertake audits and review your Technical File. It’s helpful to consider that the Notified Body is confirming that the organisation is capable of complying with the regulations as much as assessing that the information in the Technical File itself is compliant. As such, you need to think about your compliance activity as being company wide, not just a separate activity you can bolt onto the side of your organisation.

Needless to say, the Notified Bodies are large consulting organisations. They will happily take your money to help you become compliant, before then performing the assessment. This is not necessarily the cheapest way to gain certification.

How do I create a Technical File

Essentially, the regulations require the technical file to demonstrate that the device has been created in accordance with the ‘state of the art’. In other words that you’ve done something that can be recognised as a good job.

Fortunately there’s some handy standards that are considered to represent the state of the art, so if you comply with the standards, you’re in a good position. It’s worth clarifying that the regulations do not directly require compliance with the standard. If you feel you can demonstrate you’ve done a good job by other means, that’s fine. However it’s generally easier to show compliance to the standard and work from there.

For software, there are five standards you should be familiar with:

●       ISO 13485. This is the general standard for medical devices and describes what a Quality Management System needs to be to ensure compliant medical devices are produced.

●       ISO 14971. This standard describes how to manage risks relating to medical devices.

●       IEC 62304 is a specific standard for medical device software. It covers software which is part of a medical device.

●       IEC 82304 specifically considers standalone software as a medical device. 

●       IEC 62366 looks at how to evaluate the usability of your software.

That’s a lot of reading!

But here’s a very high level overview of what you need to do.

1. Write a company Quality Management System (if you don’t already have one). It should provide:

• A company quality statement. Something that commits the organization to taking quality seriously
• A document management system that allows significant documents to be identified, tracked and approved
• A development process that describes how software is developed and deployed in your organization
• A verification and validation process. Verification is testing that you build the software right. Validation is testing that you built the right software
• A supplier management process (especially if you are using sub-contractors to write your software)
• A HR policy which covers how you provide training to your staff so that they understand their responsibilities and obligations under the system
• A Post Market Surveillance process. How you continue to check and evaluate that your software is working correctly after you’ve released it. In particular how you react if someone informs you that they have suffered harm from your software.
• A Continuous Improvement process which captures ideas of how to improve things and implement those improvements

2)        Define the intended purpose of your device. This is very important. The better you define the purpose, the easier it will be to demonstrate you’ve considered all the risks associated with that purpose, and that you’ve mitigated them.

3)        Assess the risks. Since there’s a whole standard just for this, you can tell it’s important. The basic process is:

• Identify all the risks you can think of
• Assess the risks in terms of the potential harm your device could cause to its users
• Assess how likely that harm is
• Think of ways to reduce the harm (either how likely it is to occur or how bad it will be if it does happen). These are called mitigations
• Assess the risks after you’ve reduced the harm by implementing the mitigations
• Assess whether the mitigations have themselves introduced new risks of harm
• Assess whether, after all the mitigations, the benefits to people of using your system outweigh the remaining potential risk of harm.

4)        Write down the requirements for your device. As much as possible, demonstrate that these really are requirements, and not just something you made up to justify developing your device. In particular, demonstrate there is evidence that if your device does what it claims, this has a clinical benefit to users (this is called a clinical evaluation).

5)        Define how you’re going to verify that your device actually does what your requirements say it should, and nothing else. Also demonstrate that you’ve proved this is the case. We usually do this by writing tests, linking the tests to the requirements, and then providing evidence those tests have been performed and passed.

6)        Gather evidence that you are working in compliance with your Quality Management System. This can be the results of internal audits, records produced by the work as it is being done or logs output by tools you use.

When you’ve done all these things you can assemble your technical file. There is a sort of standard for the format of technical files, prepared by the Global Harmonization Taskforce and called Summary Technical Documentation (STED). This does provide some helpful guidance on how to structure your technical file, but it has no official standing as such. Complying with STED will not guarantee that your technical file will be accepted, but it is a useful guide and reminder.

Summary

Obviously this is just dipping a toe into the water of compliance for software which is a medical device. It is a potentially huge subject. However it’s not insurmountable. Keep a clear head, review the information available, seek expert advice and you’ll get through it.

Perhaps the most important thing is to think about what the regulations are trying to achieve. They want to avoid the possibility of harm. Hopefully this is something you want to prevent too. If you approach compliance as something you want to do, because it’s good for your business and your customers, you’ll find it’s not that hard to implement. Fundamentally it’s about doing the sorts of things you ought to be doing anyway.

And the great thing is, once your product is certified, you’ve just made it harder for your competitors!

If you'd like to discuss your software certification requirements with us, please feel free to message or connect with me here on LinkedIn.