The growth in the use of mobile platforms – including smartphones, tablets and wearable devices – by the general public has made the development of mobile applications (apps) by regulated healthcare and life science companies very attractive. Some examples include:

• Healthcare professional apps
• Medical reference & databases
• Patient medical health tracking
• Interface to medical device
• Doctor appointment & clinical assistance
• Telemedicine (doctor-on-demand)

Patient apps

• Medical education
• Health tracking
• Diagnosis/Preventative
• Monitoring of medical conditions
• Interface to medical device
• Mental health
• Diet and Fitness

Automated manufacturing apps

• Warehouse management
• Interface to laboratory systems/manufacturing equipment
• Access other applications

But what may not be immediately apparent to developers and regulated companies are the regulatory implications as mobile apps may be subject to GxP regulations. In addition, there are significant challenges in putting regulated software on a platform over which you potentially have no control.

As a general rule, in the UK, if the mobile app meets the definition of a medical device, then it must carry a UKCA (or CE mark) and fulfil the regulatory requirements of a medical device – be safe to use and perform in the way the manufacturer/developer intended.

Mobile apps that openly disregard these rules can be reported to the Medicines and Healthcare products Regulatory Agency (MHRA).

But how do developers and users of this software decide whether the app qualifies as a medical device?

European Commission MEDDEV 2. 1/1 I 1.1b) medical purpose states:

Medical devices are defined as articles which are intended to be used for a medical purpose. The medical purpose is assigned to a product by the manufacturer. The manufacturer determines through the label, the instruction for use and the promotional material related to a given device its specific medical purpose.

Thus, we must understand the intended purpose of the app.
MHRA device determination flowchart  can aid you in identifying whether your mobile app meets the definition of a medical device, or perhaps determination could form part of CSIA certification.

A mobile software application with an end-use in line with a medical device may be subject to GxP regulations. That is, if:

•  it is an accessory to a regulated medical device.
• it changes a mobile platform into a regulated mobile device.
• it is used as a component (interface/instrument/control system) of a GxP regulated computerised system.

Depending on the intended use, the mobile app will require a complete life cycle approach or be addressed as part of a wider system validation or qualification activities as defined in the regulated company Quality Management System (QMS).

Qualification
A regulated company/user should be able to demonstrate through
validation evidence that they have a high level of confidence in the integrity of both the processes executed within a computer system and in
the processes controlled by the computer system within a designated
operating environment.

However, traditionally validated applications can control the platforms on which they run (and can be proven through formal qualification). In contrast, mobile apps run on multiple operating systems and hardware platforms, creating significant challenges as qualification is no longer possible.

Validation
There are commonly occurring risks in any software, and these can be aligned with GAMP® 5 and handled via the Computer System Validation Standard Operating Procedure (CSV SOP). But for mobile apps, we must identify and focus on differences in risks and apply robust Quality Risk Management (QRM).

The additional risks with mobile apps are due to differences in intended use and operating environment. These may lead to the system being compromised, with breaches in security and data integrity. 
Risks include:

• multiple operating systems (and versions) and multiple hardware platforms.
• platforms that may not be under the control of the regulated company.
• connectivity problems.
• random user actions (e.g. misuse, not applying updates, damage, alteration or loss of data or loss of hardware).
• challenges of securing, processing and storing private data.
• limited battery life, which may lead to data loss.

The route to compliance is determined by risk. Thus, the ISPE GAMP® 5 Guide: A Risk-Based Approach to Compliant GxP Computerized Systems, which covers compliance and validation of GxP regulated computerised systems, can be used as the basis for mobile app validation.

While we can scale the validation of a mobile app to the main software validation, it might be cleaner to handle it under a separate Validation Project Plan (VPP). This would require minimal documentation with testing for most cases of ‘intended use.’ A separate VPP would remove interdependencies and ensure we apply risk management across the lifecycle from a functional, security and requirements perspective.