Are apps medical devices? Part two: Apps as medical devices - the regulatory framework
Continuing their advice on apps as medical devices Paul Dixey and Sam Walmsley explore the classification system of devices with regards to apps.
In part one of this series we discussed some of the marketing and organisational steps that pharma companies should consider when developing apps for HCPs, patients or the public.
This week’s post concentrates on the regulatory framework in the EU for medical devices and why this needs to be considered before starting the development of apps. In this we are indebted to James Sherwin Smith of d4 with whom we have worked on a recent paper.
Disclaimer
The following is a summary of some of the regulatory points you need to consider, however you should consult your own regulatory, compliance, medical or legal teams before making decisions.
Difference between approval of medicines and medical devices
The main difference between how medicines and medical devices are regulated lies in how a product gets onto the market. In the UK all medicines are directly approved by the MHRA which issues a 'marketing authorisation’, or licence. Medical devices however are approved by private sector organisations called 'Notified bodies'. Their approval is needed before a CE mark can be put on the device, though the manufacture of low risk devices is simply registered with the national Competent Authority (in the UK the MHRA) through self-certification (as was the case with the recently certified Mersey Burns App. ) A manufacturer needs only to register in one member state to place its device on the market across the EEA (however will need to abide by local language requirements) and can use any of the Notified Bodies in any country.
"The main difference between how medicines and medical devices are regulated lies in how a product gets onto the market."
The Regulation
The Medical Device Directive 93/42/EEC (MDD) is the primary source of regulation governing health apps across European member states. Under the MDD, prior to placing a medical device on the market, manufacturers are required to register with their Competent Authority and label their device with the CE mark.
Definition
Under clause 2(a), a medical device is defined as follows:
any instrument, apparatus, appliance, software, material or other article, whether used alone or in combination, including the software intended by its manufacturer to be used specifically for diagnostic and/or therapeutic purposes and necessary for its proper application, intended by the manufacturer to be used for human beings for the purpose of:
• 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,and which does not achieve its principal intended action in or on the human body by pharmacological, immunological or metabolic means, but which may be assisted in its function by such means,
While standalone software can be deemed a medical device under the Medical Device Directive, the definitions are not explicit and therefore are open to interpretation.
"If you have determined that your app is a medical device then the next step is to determine the correct risk class."
The May 2010 minutes of the Medical Devices Technology Forum (MDTF) suggest the MHRA applies certain characteristics that determine whether software is deemed a medical device or not.
• Electronic Health Records (EHR) – while views apparently differ across Europe, the MHRA believes that if software is purely a record archiving and retrieval system it is unlikely to be considered a medical device. However if it includes a module that interprets data or performs a calculation, then it is likely that this module (or system) may be considered a medical device, depending on the claims of the manufacturer.
• Decision Support software will generally not be considered a medical device if it exists to provide already existing information to enable a healthcare professional to make a clinical decision. However, if it performs a calculation or the software interprets or interpolates data and the healthcare professional does not review the raw data, then this software may be considered a medical device.
According to the minutes of the MDTF held in May 2010 a European working group is working on providing further guidance on the definition of software under the Medical Device Directive. This is likely to result in a formal commission guidance document (known as a MEDDEV) with an expected 2012 publication date. Some insight to how this might look is shown by the following decision tree taken from a recent blog post.
Classification of medical devices
If you have determined that your app is a medical device then the next step is to determine the correct risk class. The latest guidance on the classification of medical devices suggests that most apps would be classified under Class I and can therefore be self-certified. “Stand-alone software” is considered to be an active medical device and the rule set for classification of these devices is relatively straightforward. If Rule 9, 10 or 11 apply (see diagram below), then your app may be classified as Class IIa or IIb. However if none of these three rules apply, then by default your app would be Class I under Rule 12. Please see the diagram below for more details on this, or consult MEDDEV2.4/111.
Self-Certification
The requirements for manufacturers of Class I devices are listed within the MHRA Guidance Note 7. The cost of registering as a manufacturer under Class I is currently only £70 and the compliance requirements are in line with good practice for any organisation producing software to meet healthcare needs.
"The requirements for Classes IIa and IIb are more onerous”
The requirements for Classes IIa and IIb are more onerous and are summarised within a separate MHRA bulletin.
Other legislation
Within the EU in addition to national Codes of Practice other regulations or laws may also need to be considered such as (not an exhaustive list) Data Protection, Privacy and Electronic Communications Directive, Companies Act, Disability Discrimination, Copyright, Product Safety and Liability.
What about current pharma apps
It is not appropriate for us to comment publicly on the status of currently available apps launched by pharma companies as we are obviously not aware of the internal discussions and decisions that will have been made by those companies. We can say however that you should engage with your local Competent Authority rather than making a decision solely based on only internal departments’ interpretation of the regulations or advice from external legal counsel. We are aware of cases where external legal advice differed from that which was given when the Competent Authority was contacted directly.
Part three in this series can be viewed here.
About the authors:
Paul Dixey paul@bluelightpartners.com @pauldixey
Sam Walmsley sam@bluelightpartners.com @sammielw
Paul Dixey and Sam Walmsley are Managing Partners at Bluelight Partners, which is an independent experienced digital and mobile consultancy focusing on the healthcare and pharmaceutical industry. We develop innovative and integrated strategies, so that digital, social media or mobile can be an integral and compliant part of pharmaceutical marketing and communication mix.
Is there sufficient engagement with local Competent Authorities in app development?
