When is “clinical software” not “software as a medical device”?

The stakes are always high when developing regulated medical devices. Where software is involved, there are huge practical and financial implications to working out whether your software is or is not a medical device, says Rose Le Doux, quality specialist at Cambridge Design Partnership.

Nobody ever said that getting medical devices regulated to international standards was easy. But it just so happens to be my job. Here at Cambridge Design Partnership (CDP) my role is to guide projects from start to finish in terms of their regulation. A major focus of our work here is on products that need to meet the stringent European Medical Device Regulations, in which we’ve developed something of a reputation for expertise.

Since 2017, European medical device and in-vitro diagnostic manufacturers have worked within the many thousands of pages of the Medical Device Regulations, which replaced the old Medical Device Directive that had been in place for 20 years. These regulatory documents have profound implications – they clarify the regulatory requirements both when developing devices and maintaining them during their lifecycle. Meeting these expectations is a painstaking and far from cheap exercise.

When developing software for use in clinical settings, there is a question that we always recommend our clients consider first. A question that could save them a great deal of time and money.

So, ask yourself: is your software actually a medical device, or is it just… software?

The reason I’m asking this is because there’s been a shift in regulations, which is driving a more pragmatic attitude to classifying clinical software.

Looking back to 2017, many manufacturers will have reviewed the new MDR and gained the impression that all stand-alone clinical software must be classified as a medical device (to be specific, at least as Class IIa, following the Annex VIII Rule 11). Besides which, software that forms part of an overall medical device system inherits the classification (within the MDR or IVDR) of that medical device. This seemed to mean that it had to be developed under the MDR.

But help was soon at hand. The Medical Device Regulation (2017/745) had also established a Medical Device Coordination Group (MDCG). This group is aimed at implementing a unified approach to the application of the MDR by European member states. The group created a guidance document to help manufacturers and Notified Bodies (who review regulatory submissions for medical devices). As a result, fast-forward to 2019 and the MDCG issued new guidance, meaning that the regulation of software could become easier to interpret and, in some cases, allow for a completely different approach.

Under this guidance, software that might previously have been designated as a medical device or accessory, might not be after all. It’s a complex set of parameters, but once you’ve found your way around it a few times, the guidance is pretty clear. Essentially, the categorization hinges on whether or not the software is intrinsic to treatment or purely for data storage, communication, or searches.

If the software informs and influences treatment, it’s a medical device. If it’s purely for data handling, then it’s not.

This may sound complicated, so let’s have a look at a real-life example. Consider a pre-hospital Electrocardiograph (ECG) system. Suppose the software attached to this pre-hospital ECG is intended for ambulance staff to use for storing information about the patient while treatment is being given in the field. From that point, the information is then handed over by the software to the hospital team on arrival in A&E. You’d be looking at data such as a patient’s name, their vital parameters, and clinical observations. Now, according to the 2019 MDCG guidance, this sort of pre-hospital ECG system does not qualify as a medical device. 

For clients who are working on creating such a system, this freedom from MDR regulation has major financial implications and can also save enormous amounts of time during its development, too.

So what would make our ambulance ECG software into a medical device? The key to this is whether the software is used to provide or inform medical treatment. Coming back to my earlier example, if the ECG system uses its software to inform and influence the patient’s ECG treatment, then that software is a medical device and must be regulated as such. That’s because the software system is providing information that has a bearing on the patient’s treatment at the point that the treatment is given.

This can all seem a bit of a minefield, but here at CDP we’re well used to finding our way around the MDCG guidance. Of course, it’s crucial for medical devices to be traceable, transparent, and of the correct quality – all of which takes time and expertise. But if your software isn’t actually a medical device after all then life becomes much simpler. If you’re developing software for a clinical environment, it’s well worth contacting our team of quality and regulatory experts for advice. We can help you identify the applicable regulations for your product and chosen markets, manage the development process and prepare your regulatory submission. And often you’d be surprised at the savings we can help you make along the way.

---