Building a game changing medical App
Developing Apps of the future
Developing Apps of the future
Triteq’s Senior Mobile Application Developer shares his own experiences of developing game changing medical Apps.
Prior to joining Triteq, I had 18 years’ experience as a software developer in the defence, e-commerce, telecommunications, and financial sectors. I was a proficient full stack Java developer with some native mobile app development experience. When offered, I jumped at the opportunity to develop mobile apps at Triteq as I felt I could turn my skills to a worthy cause.
At the time it was unknown to me how to develop a medically certified app. However, it soon became clear that, at least at the code level, it wasn’t all that different to how you develop a commercial app. The difference lies in the regulatory aspects, which have to be at the heart of development from the very beginning to delivery of the product and beyond. Triteq have a proven track record of developing medical products for almost 3 decades, with expertise and experience in house to get medically certified products and software onto the market.
Over the past 5 years at Triteq, I have been involved with a number of mobile apps across the medical and commercial sectors. One app in particular I have been involved with from the very start is a potential game changer in the medical app space. This project has given me significant insight into the challenges of developing a medical app. Below I am going to take you through some of the considerations required in the development of a medical mobile app.
What is a medical mobile app?
In order to understand the requirements for developing a medical app, you must first consider what a medical app is defined as.
In the UK, the Medicines and Healthcare products Regulatory Agency (MHRA) considers a medical mobile app as a medical device and refers to the EU Medical Devices Regulation (MDR) for its definition. The MDR classifies a medical device as a device in combination with software for use on human beings intended for the purpose of diagnosis, prevention, monitoring or treatment of a disease or injury.
In the US, the FDA defines a medical mobile app as software running on a mobile device such as a smartphone or tablet that functions as an accessory to a regulated medical device or if the mobile app software transforms the mobile device into a medical device.
Examples of medical mobile apps include:
In order to begin developing a medical software, an organisation must have a Quality Management System (QMS) in place. This is a set of processes, audited to ISO62485, which an organisation must follow to deliver a safe, quality product.
Software Development Lifecycle
Once you have determined that your app fits under the category of a medical mobile app and your organisation has a QMS in place, you must then ensure that you are familiar with the software development lifecycle of such an app. Luckily, IEC 62304 is an international standard which defines what processes, plans and technical documentation you need to produce throughout this lifecycle in order to comply with regulatory requirements.
The extent of the requirements needed depends on the safety classification (Class A-C) of the software being created. Class A is defined as software that would cause no injury or damage to the health of the user whereas Class C is software that could cause death or serious injury. It is important to get this classification right and sufficiently justified from the very start as it determines what is needed to comply with the regulations from there on in.
A risk management process can be used to determine and justify the software safety classification as a whole. During this process, plausible scenarios and events which may cause harm to the user must be identified, recorded and analysed. If necessary, a Risk Control measure, such as displaying a warning on the app, will then be put in place to mitigate the risk. It is important to correctly identify and mitigate these risks to determine an accurate safety classification. When asked what the main difference between medical and non-medical app code is, I say, it’s all in the Risk Control measures applied to it.
Verification and Testing
It should be fairly obvious that verification and testing are an important part of the development of medical software. Right at the very start of the development lifecycle you will have captured a list of product requirements, which in turn will trace to a list of software requirements. Each software requirement will need to be verified in order to ensure that the end product operates as intended.
As with non-medical mobile development, verification should be completed against a variety of devices running a range of operating system versions. Obviously, it isn’t possible to test against the huge number of device and operating system combinations, especially on Android. Therefore, you must produce a rational justifying your approach to verification and how you decided which devices are used for testing.
After each verification, a report must be produced which records details of the verification, its conclusion and any issues found must be recorded and assessed against verification procedures.
Testing should not stop there. Verification against requirements only uncovers issues as a direct result of executing the requirements verification method. To uncover issues and artefacts in the app which aren’t linked to a specific requirement, QA testing must be carried out. For example, soak tests which are designed to emulate prolonged and excessive use might reveal issues that otherwise wouldn’t have been found until it is in the hands of the user. This isn’t specific to medical app development, it’s good practice.
Any software used by your mobile app, directly or indirectly, that you didn’t create yourself under your software development lifecycle is known as Software of Unknown Provenance (SOUP).
When developing mobile apps, its commonplace to use 3rd party libraries to provide certain pieces of functionality within the app as it saves time and brings down costs. Whether you’re using Realm to provide persistent storage for data, Firebase for collecting analytical insights into the usage of the app and crash report or a charting library to display graphical charts. In the unusual cases where 3rd party libraries aren’t used, an app will still be utilising the framework provided by the operating system to run the app and, at the very least, you will have the iOS and Android operating systems that the app is running on along with drivers to control the hardware on the device. All of this should be considered as SOUP.
IEC 62304 requires us to carefully consider the risks that using these items may pose to the medical app and it’s users. Generally, SOUP items are not under your control and they may contain bugs causing unexpected behaviour or malicious code. As such, it’s required that you take a risk-based approach to ensure it is safe and acceptable to use and to determine how it can be verified.
Over the past few years, security of medical apps and devices have become a focal point for regulatory bodies such as the FDA. Cybersecurity is generally a concern in all apps, but medical apps are especially exposed as they generally run on a device connected to the internet and tend to use a lot of SOUP items. Although it is unlikely that every threat can be eliminated, part of the risk management process will consider cybersecurity risks and the controls that can be put in place to mitigate them.
A few examples that may be considered include;
You must also have a process for cybersecurity analysis and testing of your app, whether that be running penetration testing tools or using 3rd party security testing services. Regulatory bodies will require evidence in the form of cybersecurity test reports which show any issues found along with rational on what you intend to do about it.
I hope this has given you a brief insight into some of the challenges faced during the medical app development process. Please get in touch if you think we can help your app to become the next game changer.