Posted on

Case Study: Mobile Medical Apps or mHealth Apps, do they have to follow medical device regulations (FDA/EU) or not?

Mobile Medical Applications

There has been a rapid development of mobile health apps or mHealth apps in the last few years. The rapid increase has caught the eye of regulatory institutes worldwide. Valid resources of information regarding related legislative issues are available, despite it is not easy for application developers to interpret the specific laws, directives, and definitions per country. In this article we are going to summarize the main points of the US and EU medical device directives and regulations for developers of mobile medical applications. This will help developers decide whether their application will be subjected to these regulations. As example we will describe the process for evaluation a drug dose calculation application on a smartphone.

Why?

Mobile applications  can help people manage their own health and wellness, promote healthy living, and gain access to useful information when and where they need it. These tools are being adopted almost as quickly as they can be developed. 51% percent of the more than 3.4 billion smartphone and tablet users have downloaded a mobile health application, users include health care professionals, consumers, and patients.

Mobile Medical Application – US (FDA)

Mobile apps are software programs that run on smartphones and other mobile communication devices. They can also be accessories that attach to a smartphone or other mobile communication devices, or a combination of accessories and software.

Mobile medical apps are medical devices that are mobile apps, meet the definition of a medical device and are an accessory to a regulated medical device or transform a mobile platform into a regulated medical device.

More so…

A “mobile medical app” is an application that: Meets the definition of a device in section 201(h) of the Food, Drug and Cosmetic Act; and is intended to be used as an accessory to a regulated medical device, or transforms a mobile platform into a regulated medical device.

If the intended use of the mobile app is for the diagnosis of disease or other conditions; or the cure, mitigation, treatment, or prevention of disease; or is intended to affect the structure or any function of the body of man, it is subject to FDA regulations. The intended use is determined through examining labeling claims, advertising materials, or oral or written statements by manufacturers or representatives. (FDA)

mHealth Applications – EMEA

Mobile health (hereafter “mHealth”) covers “medical and public health practice supported by mobile devices, such as mobile phones, patient monitoring devices, personal digital assistants (PDAs), and other wireless devices”. It also includes applications (hereafter “apps”) such as lifestyle and well-being apps that may connect to medical devices or sensors (e.g. bracelets or watches) as well as personal guidance systems, health information and medication reminders provided by SMS and telemedicine provided wirelessly. (European Commission)

Platform (i.e. iPhone or Android smartphone)

The platform for the mobile application is irrelevant for regulatory institutes.

Mobile Medical Applications or mHealthOut of scope

Mobile Medical Applications that function as an Electronic Health Record, mobile devices, and mobile app stores are out of scope of this case study.

Entities that exclusively distribute mobile apps are not considered to be medical device manufacturers by regulators. Mobile platform manufacturers and smartphone manufacturers are not considered to be medical device manufacturers.

Potential of Mobile Medical Applications for Healthcare

  • Increased Quality of Life;
  • Increased Prevention and even extent life expectancy by promoting healthy behaviors;
  • Efficient and sustanable healthcare (e.g. reducing unnecessary consultations);
  • Raise awareness of health issues;
  • Facilitate mining of large amounts of health data;
  • More empowered patients.

Disadvantages

  • Data protection issues;
  • Health data security issues;
  • Data mining of big data not in compliance with regulatory and ethical requirements;
  • Hard to verify the efficacy of mobile medical application solutions.

Types of Mobile Medical Apps

  • Information – the application provides information on for example the nature and levels of allergens present in a particular location, on symptoms, and has a diary function;
  • Early detection – Calculates the risk of suffering from a certain disorder;
  • Prevention – Reminds users of opcoming injections/vaccinations;
  • Diagnosis – Recommends potential diagnoses and courses of actions in response to symptoms entered by the user;
  • Treatment decision – Online decision aids for patient, whether to undergo a treatment or not;
  • Treatment – Apps using functionalities for treatment of patients (e.g. Speech therapy for stroke patients);
  • After-care and monitoring – Monitoring the patient health status (e.g. Mental health monitoring using a smartphone, doctors are notified if the patient’s condition is deteriorating;
  • Self-Management – Apps supporting chronic patients with information training, medication reminders, patient doctor communication, etc.
Applied to the EU regulatory system

The main organization responsible for medical device regulations is the European Commission (EC), the EC has 3 medical device directives in place:

  • Active Implantable Medical Devices 90/385/EEC, replaced by 2017/745;
  • Medical Devices Directive 93/42/EEC, replaced by regulation 2017/745;
  • In Vitro Diagnostic Medical Devices 98/79/EEC, replaced by regulation 2017/746.

.

Note: Recently the 2017/745 regulation has been adopted to replace the 93/42/EEC and 90/385/EEC, there is a transition period of three years. 

Note: Recently the 2017/746 regulation has been adopted to replace the 98/79/EEC, there is a transition period of three years. 

Classification of medical devices

Following this directive, a product will be considered an accessory if the manufacturer intends for to be used in conjunction with one or several medical devices.

EU CLASSIFICATION OF MEDICAL Software / Mobile Applications

It is necessary to clarify that software in its own right, when specifically intended by the manufacturer to be used for one or more of the medical purposes set out in the definition of a medical device, qualifies as a medical
device, while software for general purposes, even when used in a healthcare setting, or software intended for life-style and well-being purposes is not a medical device. The qualification of software, either as a device or an accessory, is independent of the software’s location or the type of interconnection between the software and a device. – (Regulation 2017/745)

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.

Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in  immediate danger to the patient, in which case it is classified as class IIb.

All other software is classified as class I (Regulation 2017/745)

 

In a nutshell…

  • Not a medical device: software for general purposes, even when used in a healthcare setting, or software intended for life-style and well-being;
  • Class III: Software intended to provide information which is used to take decisions with diagnosis or therapeutic purpose that might cause serious deterioration of a person’s state of health or a surgical intervention; 
  • Class IIa: Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes that will not cause serious deterioration of a person’s state of health or a surgical intervention;
  • Class IIb: Software intended to provide information which is used to take decisions with diagnosis or therapeutic purpose that might  cause a serious deterioration of a person’s state of health or a surgical intervention and Software intended to monitor physiological processes where the nature of variations of those parameters is such that it could result in  immediate danger to the patient;
  • Class I: All other medical device software.
APPLIED TO THE US REGULATORY SYSTEM

 

A “mobile medical app” is a mobile app that meets the definition of device in section 201(h) of the Federal Food, Drug, and Cosmetic Act (FD&C Act) ; and either is intended:

  • to be used as an accessory to a regulated medical device; or
  • to transform a mobile platform into a regulated medical device.

In general, if a mobile app is intended for use in performing a medical device function (i.e. for diagnosis of disease or other conditions, or the cure, mitigation, treatment, or prevention of disease) it is a medical device, regardless of the platform on which it is run.

FDA’s oversight approach to mobile apps is focused on their functionality, just as they focus on the functionality of conventional devices. The FDA oversight is not determined by the platform.  FDA’s oversight applies to mobile apps performing medical device functions, such as when a mobile medical app transforms a mobile platform into a medical device. However the FDA intends to apply this oversight authority only to those mobile apps whose functionality could pose a risk to a patient’s safety if the mobile app were to not function as intended.

Note: The FDA will not regulate the sale or general/conventional consumer use of smartphones or tablets.

US CLASSIFICATION OF MEDICAL SOFTWARE / MOBILE APPLICATIONS
  • Not a medical device: software for general purposes, even when used in a healthcare setting, or software intended for life-style and well-being (e.g. logbook diabetes). 
  • Class III: Software intended to provide information which is used to take decisions with diagnosis or therapeutic purpose that might  cause serious deterioration of a person’s state of health or a surgical intervention or death;
  • Class II: Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes that will not cause serious deterioration of a person’s state of health or a surgical intervention;
  • Class I: Software intended to provide information which is used to take decisions with diagnosis or therapeutic purpose which does
    not present a potential unreasonable risk of illness or injury.

The FDA classification is risk based with mobile medical device application of low risk as class I and an application of high risk as a class III, keep in mind for FDA classification it’s important to check for precedent in their medical device database, an application that is similar to yours.

Unknown mobile medical applications will be filed as a class III until it’s risk level can be properly defined and reviewed by the FDA.

 

Posted on

Failure Mode and Effect Analysis – FMEA

DISCLAIMER: This blog post solely represents my own opinion based on experience and/or interpretations. As a former Subject Matter Expert Quality Risk Management and trainer in one of the pharmaceutical big 5 companies I have extensive experience in performing and guiding failure mode and effect analyses.

EPISODE – 1 In this series I will give an in-depth view on the different risk assessment techniques, starting with FMEA. The FMEA series will contain 5 episodes.

Failure Mode and Effect Analysis (FMEA)

What

FMEA is used to define, identify, and eliminate known and/or potential failures, problems, errors… from the system, design, process, and/or services before they reach the customer.

FMEA’s motto ‘ DO THE BEST YOU CAN WHEN YOU CAN‘.

Origin

The FMEA technique was developed by army reliability engineers in the late 1950s (9 november 1949 to be exact) to study problems that might arise from malfunctions of military systems.

FMEA Types

Generally, four types of FMEA can be distinguished, they all gave their own focus and objective:

  • System or concept FMEA: A system FMEA focuses on potential failure modes between the functions of the system caused by system deficiencies;
  • Design FMEA: A design FMEA focuses on failure modes caused by design deficiencies;
  • Process FMEA: A process FMEA focuses on failure modes caused by process or assembly deficiencies;
  • Service FMEA: A service FMEA focuses on failure modes (tasks, errors, mistakes) caused by system or process deficiencies.

    Why

The quality of the product and/or services must be a company’s number one priority in order to achieve customer satisfaction (focus of ISO, FDA and other standards/legislation) by reducing known or potential problems. FMEA will map the way to continual improvement.

Potential benefits are:

  • Helps to select the best design;
  • Helps in determining redundancy;
  • Increases the likelihood that potential problems will be detected;
  • Establishes a priority ranking for implementing improvements;
  • Helps identify and eliminate potential safety concerns.

When

A FMEA is best started as early as possible, as soon as a reasonable amount of information is known about the product, process, service, design… the FMEA should be started. Typically an FMEA is started as soon as the project was approved and a preliminary design was approved. You should never wait for all the information to be available.

An FMEA process should start:

  • When preliminary design of new products, processes, systems, or services are finished;
  • When existing products, processes, systems, or services are changed (update existing FMEA(s) or start FMEA(s) when there is none available);
  • When new technology is used/found for existing products, processes, systems, or services;
    When improvements are considered.
  • After the FMEA process is started, the FMEA documentation becomes living documentation meaning it’s a true dynamic tool of improvement.

Finished

An FMEA is never truly finished, the documentation will become static when the system, process, product, or service is discontinued.

Inputs

Information may include:

  • Drawings;
  • Flow Charts;
  • Pictures;
  • Video;
  • Error or incident data;
  • Nonconformities;
  • CAPA (Corrective and Preventive Actions);
  • Post market surveillance data.
  • Outputs

The primary output of FMEA is a list of failure modes, the failure mechanisms and effects for each process step. Information is also given on the causes of failure and the consequences.
Outputs may include:

  • List of potential failure modes ranked by risk probability number;
  • List of recommended actions to avoid the potential failure modes;
  • List of recommended actions that could identify the potential failure modes on time.

FMEA Team

FMEAs should be performed by a cross-functional and multidisciplinary team and cannot be performed on an individual basis.

A multidisciplinary team is best comprised of, but not limited to:

  • Operator(s);
  • Engineer(s);
  • Project Manager;
  • Quality Representative;
  • Customer(s).

A team is always defined for a specific project and there cannot be a predefined universal team that will perform all assessments in a company.

Time

FMEA Process

The FMEA process is a time consuming process but it’s worthwhile. There are no specific length or time limits, the length and time is defined by the experience of the team, objectives, and complexity of the process, product or system in scope.

FMEA Sessions

In my experience it’s best to organize short sessions of maximum 3 hours with a short break included. People tend to lose their focus after one hour and half. I’ve been in 8 hour long sessions and I can only state that I’ve achieved more in the 3 hours sessions than I ever would in a complete workday session.

Next Episode (2/5) will focus on the FMEA process itself.