Is it “wellness”, or is it a device? Software as Medical Devices in the EU

The buzz surrounding the development and use of smartphone apps and other software to “manage healthcare” and “wellness” isn’t going away any time soon.

It is a situation that creates significant headaches for people developing software that may, or may not, be viewed as (part of) a medical device. Uncertainty that presents significant risk to their development plans, activities and investment, especially when the software part of the product sits on the cusp of the medical device space.

Earlier this year, we discussed how the FDA’s approach to this rapidly evolving market segment was bringing clarity (if you’d like a refresher, you can read the article here).  Let’s turn now to the approach taken in the EU.

EU treatment of software as a medical device

Developers have often referred to the MEDDEV Guidelines, as tools to help interpret the requirements of directives/regulations for medical devices.  The guidelines have been regarded as just that, and not legally binding – so there hasn’t been certainty over how well they interpret EU law.  But, now there is a legal ruling from the EU Court of Justice (CJEU) on the grounds for classifying software as a medical device.

Essentially the CJEU ruled that software is a medical device if it has at least one functionality that allows its use for a medical purpose set out in the definition of a medical device in the MDD (as amended):

  • Diagnosis, prevention, monitoring, treatment or alleviation of disease,
  • Diagnosis, monitoring, treatment, alleviation of or compensation for an injury or handicap,
  • Investigation, replacement or modification of the anatomy or of a physiological process,
  • Control of conception

The software does not have to work directly in or on the human body to be classed as a medical device.  The purpose of using the software is important, rather than the manner in which an effect is produced to the human body.

Why this should matter to you

The CJEU decision validates the criteria in MEDDEV guidance for classification of software medical devices, so they can be relied on with greater confidence both by the industry and regulatory authorities.  Developers of medical devices that are entirely or partly software can use the MEDDEV decision tree with confidence.

Determining if Software is a Medical Device or IVD

MEDDEV 2.1/6 includes a handy decision tree to help you determine if your software is a medical device:

Click to enlarge

There’s a similar decision tree to help you determine if your software is an in-vitro diagnostic device:

Click to enlarge

As you might expect, the devil is in the detail, for both of these classification routes.

Reducing and Managing Risk

The CJEU ruling means that development projects can have a greater degree of confidence that they’re applying the correct classification to their products, and hence massively reduce the risk that their activities are inadequate to satisfy regulatory authorities. The ultimate benefit is in avoiding unnecessary costs, unwarranted testing and use of resources, whilst ensuring that, for those software that are truly medical devices, sufficient testing and documentation are provided to demonstrate regulatory compliance.

You may find it useful to seek an independent, expert opinion on the outcome of using the decision trees for classifying your software development, before embarking on an expensive and lengthy programme.

If you would value a conversation to get the ball rolling, get in touch with us today.

 

Medilink Innovation Day 2018, and a Prize Draw

Our team had to pleasure of, once again, attending Medilink East Midlands’ Innovation Day earlier this month.

Unusually for industry conferences, there’s a broad mix of people attending Innovation Day, from academia, industry and the NHS, along with a variety of exhibitors – all of which make for an interesting day’s conversations.

A steady stream of visitors to our stand (we were there will colleagues from the Medical Device Alliance) led to discussions on a wide range of medical device development topics.  Passers by gravitated to our route map for medical technology development, with many printed copies leaving in people’s bags.

Many people chose to enter a draw to win a printed copy of our book introducing Human Factors for medical devices “How Humans Factor (in medical device design)”.

Congratulations to the two winners in our prize draw, who will each receive their book in the post over the next few days.

And yes, the team’s preparations are already underway for next year’s Innovation Day.

Rising cost of compliance for medical devices in Canada

Our recent insight post highlighted a key change in Health Canada’s requirements for companies seeking authorisation to market their devices.  A change that is leading to disquiet amongst manufacturers for the Canadian market.

From 1 January 2019, Health Canada will only accept manufacturer audits performed under the MDSAP programme, closing the current conformity assessment system.  Manufacturers are not expected to make the switch overnight, however.  Health Canada published specific criteria in April, for manufacturers to preserve their current ISO 13485 certification and surveillance cycles whilst transitioning to the new arrangements.

Perhaps understandably, the change is causing consternation to manufacturers of smaller volume medical devices.  Companies are reporting a ten-fold increase in audit costs as a result of the change, an increase that is likely to hit small businesses hardest, according to a recent report by Canadian national newspaper The Globe and Mail.

Whilst having a successful MDSAP audit would aid registration in other territories, the way MDSAP audits are performed may result in a more lengthy and costly process for Canadian manufacturers.  The scarcity of resources to perform the audits, and the passage of time, may exacerbate the situation.

It should be noted that the regulatory requirements remain the same in 2019, it is the method for confirming compliance that will change.  Health Canada expect adopting the MDSAP requirement will “strengthen the post-market surveillance and risk management” for medical devices.

The Globe and Mail reports Health Canada as “offering to reduce, for small companies, the time spent performing the audit” alongside giving more time to have the audit completed, as long as its scheduling is done in 2018.

It has been said that the change could bring advantages to manufacturers in the EU and US looking to market their devices in Canada – as having a successful MDSAP audit stands them in good stead for registration in multiple countries. Closure of the Canadian conformity assessment system removes a hurdle for those companies, reducing the “cost of entry” somewhat.

This situation underlines the long-term benefits of considering regulatory requirements for a range of territories when developing medical devices, instead of focusing in on requirements of the launch market.

Only time will reveal the true impact of the change, on both domestic Canadian medical device manufacturers and those looking at entry into the country’s health care market.  We will keep you posted on developments.

 

Riding the wave of Software as a Medical Device

For years there’s been an indistinct, blurry area, surrounding software and apps that are deemed medical devices and so called “wellness” or “lifestyle” applications. Signs of change have emerged over the past few months, in the US at least. And where the US leads, other territories will follow.

It’s probably little surprise, given that software apps rely upon a stable platform to operate effectively.

If, like us, you’ve ever experienced an update to one of the apps on your smartphone either “break” functionality or impact on how another, seemingly unconnected, app performs, then you will appreciate why this is a challenge that needs to be resolved.

FDA publishes and updates guidance documents

Signs of the changes for Software as Medical Devices (SaMD) are mainly found in the activities of the FDA (the US regulator for drugs and medical devices) and forms part of the US government’s drive to bring regulation up to date, by passing the “21st Century Cures Act” into law.

Agency guidances have since been published for a range of topics;

Clearly, FDA view the changes as important to the health of the US populace.  Taking the case of apps used to support drug treatment as just one example, here’s what the FDA commissioner, Scott Gottlieb had to say;

“Mobile devices and software linked to specific drugs can help patients stay on therapy for treatments where medication compliance is traditionally a challenge”

International guidance for software as medical devices

The flurry of activity comes on the heels of the last in a series of documents produced in the area by the IMDRF (International Medical Device Regulators Forum).

Perhaps you’re not too familiar with the work of the IMDRF? That’s ok, it is after all a rather niche topic. Regulators from the EU and 9 countries have been working together “to develop guidance that supports innovation and timely access to safe and effective Software as a Medical Device”.

Work completed by this IMDRF working group produced a suite of guidance documents relating to SaMD, including;

If you’re considering, or are already a long way down the path to, developing, pure software medical devices or “accessory” apps, such as those used to manage a chronic disease such as diabetes, then you need to be aware of the shift and adjust your approach accordingly.

Help is at hand for software as a medical device

Clearly, there’s a lot to take in with the swathe of documents, before assessing the impact the changes may have upon your development plans.

Over the coming weeks, we’ll be sharing insights for each of the documents mentioned in this article.

Subscribe (add your email to the box on the right of this page), to ensure that you’re alerted as soon as new information is published.

Perhaps you want to get to grips with the changes today?  Get in touch now.