7 best practices for Medical Mobile Apps connected to a device
Updated: Aug 29
Standalone medical devices with in-built displays are becoming a rarity in favour of devices using mobile apps as the display and ecosystems that expect connection to the cloud. However, the regulatory approval of device connected medical apps is a young field with standardised best practices still to emerge. Jurisdictions across the globe still in the process of harmonizing their guidance. As Genesys grows in its experience in this space, we offer the following insights and best practices:
1. Mobile Apps versus built-in displays
a. Key points: Mobile Apps allow the developer to access the rich utility of a mobile device and use it as a gateway between the medical device and the cloud. Apps also help reduce power consumption in battery powered medical devices and you don’t need as much processing power. However built-in displays offer reliability, security and usability advantages as well as a simpler regulatory approval process.
b. Genesys Insight: Build the App into the system architecture anyway and let the market decide. Genesys normally builds an app into all its medical device projects because, if for no other reason, it is a powerful enabler of the debugging process and enables the ability to do over-the-air updates of prototypes. However, the decision to integrate an App into the approved product is ultimately a commercial one.
2. Classification of the Mobile App
a. Key points: Mobile Apps will be classified as a medical device when used to diagnose, treat, prevent, cure or mitigate a medical condition. Apps that control or adjust the operation of a programmable hardware-based medical device will have the same classification as the hardware. Where software simply transfers, stores, converts or displays data without any transformation of the data, it may be class A or a Non-Device-MDDS (Medical Data Display System).
b. Genesys Insight: Getting the classification right involves a thorough analysis of the app's intended use, functionality and risk profile. One of the simplest and most overlooked ways of determining if the App is a medical device is to consider the impact of time criticality to the procedure. If the App absolutely needs to perform within a certain time frame, then it’s probably a medical device. If failure is no worse than an inconvenience then it may not need to be a medical device. Having said that, why risk the commercial impact of an unreliable commercial mobile App as part of your system? Develop your mobile App as if it was a medical device anyway, with all the associated reliability but without the overhead (and cost) of the full regulatory documentation suite.
3. Design Controls and IEC 62304 Compliance
a. Key points: Medical Mobile Apps need to be developed under design controls and standards specified in the pivotal IEC 62304 lifecycle standard for medical device software. Design controls involve a systematic approach to development, including requirements gathering, risk management, testing, and documentation. The design controls must apply to every element of the mobile App including navigation, user profiles, account management, graphical data displays, file management, parameter management, device connection management, cloud connectivity, cross platform compatibility and more.
b. Genesys Insight: To start from scratch developing all the App’s features under design controls is a major exercise. It is better to build your Apps business logic on top of a template that has all the common features already developed in compliance with IEC 62304. Genesys has done exactly that, making use of reusable software modules for both the hardware device and the mobile App. This frees up the team to focus on development of the application layer and the App’s business logic.
4. Managing Software of Unknown Provenance (SOUP)
a. Key points: A key challenge medical App developers face is Software of Unknown Provenance, which is any software the App relies on whose origin, validity or reliability is uncertain. This include the mobile device’s operating system, third-party libraries or platforms, software development kits, device drivers, and open-source software generally. Not knowing how the SOUP will function means it can’t be relied upon, which impacts the risk assessment of any functions relying on the SOUP. A robust and defensible strategy is needed to mitigate the risks posed by SOUP.
b. Genesys Insight: Genesys has approached this challenge by creating a wrapper around all operating system calls to ensure proper control and validation. The wrapper is a way of intentionally limiting the access of the App to the SOUP libraries so that only the required APIs are accessible. It also allows the addition of checks and balances to all calls including parameter validity checking and error handling. Limiting the access limits the burden of validating the SOUP.
5. Delivering Reliability
a. Key points: Regulatory requirements demand that developers demonstrate a medical App is safe and effective. In other words, the App needs to reliably deliver on its intended purpose. Reliability of medical Apps and their integration with a hardware device and the cloud, arises from a range of best practices set out in the IEC 62304 standard, in conjunction with thorough system level risk and usability analysis as set out in the ISO 14971 and IEC 62366 standards.
b. Genesys Insight: In practice high reliability is a function of rigorous software engineering methods and features that promote data integrity and robust connection management. Rigor comes from unit verification and system integration testing with traceability of unit tests to requirements, robust version control with traceability of changes as well as comprehensive in-line documentation. Robust connection management is facilitated with automatic retries and timeouts. Data integrity is facilitated by data packet tracking and cyclic redundancy checking, time synchronisation and more. Genesys builds reliability in its Template Mobile App by leveraging a library of proprietary reusable modules to facilitate all the “under the hood” functions, themselves developed under IEC 62304.
6. Cyber Security
a. Key points: Medical devices must comply with cybersecurity requirements of regulators in various jurisdictions. Whilst regulators provide non-binding guidance documents on their cybersecurity requirements, there is currently no globally harmonised cybersecurity standard for medical devices, that multiple regulators recognize. This leaves us with a maze of separate but overlapping cybersecurity standards and other documents that regulators recommend, but do not mandate. Deriving a coherent set of medical device cybersecurity requirements that will satisfy all regulators is a major challenge. The level of detail and range of possible security threats is large and complex. Given determined attackers seem to be able to penetrate even large well-funded organisations, MedTech developers need to identify a pragmatic approach to cybersecurity that is fit for purpose and will satisfy the medical device regulators.
b. Genesys Insight: Our general approach is to ensure that any device we develop has a coherent cybersecurity architecture addressing a clearly defined attack surface. We identify relevant classes of threat actors and the type of attacks likely to come from each class. Once cybersecurity threats and vulnerabilities have been identified, we apply IEC 62304 and in particular Software Risk Management in accordance with ISO 14971, to analyse, quantify and mitigate cybersecurity risks. We then identify, implement, verify and validate cybersecurity risk control measures. Cybersecurity risks are addressed during usability engineering and we ensure that user documentation includes instructions to maintain cybersecurity.
7. Updating your App
a. Key points: If you want to make a change to your App, after it has been launched on the market, you will need to evaluate the change rigorously and determine if it requires a new submission to the regulatory authorities. A new submission is generally required if there is change to the intended use of the App. If the changes are just to upgrade cybersecurity and has no other impact on the operation of the App’s functions, for example, then you may be able to note the changes internally in your quality system. Also, changes may be required when the operating system of mobile devices are upgraded. In any event, there needs to be a rigorous, documented and planned approach to managing changes.
b. Genesys Insight: The easiest way to address this challenge is to supply mobile devices as part of your system, operating in Kiosk mode with locked operating system version, so that the operating system (OS) of mobile device is controlled. This allows the medical device (App) manufacturer to better control the rollout of any changes. Changes can be trialed and tested on a known OS, giving confidence of any impact of the changes. However, many Apps rely on personally owned mobile devices where the mobile device manufacturer will roll out changes to the operating system regularly. It’s hard to guarantee these OS changes will not impact the performance of your App. The solution to this is make the App only work on certain versions of the operating system. Developers can gain access to beta versions of the OS to plan ahead for App updates to accommodate these.
Developing a medical app for connection with medical devices demands a much higher level of rigor in comparison to normal commercial apps. The above points are designed to provide an insight into just some of the considerations. There are many other topics as user interface design, interoperability and more.
The key to ensuring a clear pathway to regulatory compliance is to have a comprehensive Software Development Plan in place that addresses all the challenges and regulatory requirements, while generating the many documents required to prove compliance.
Genesys has templates of all the plans, analyses and reports that will be required for your Software Development Plan. Contact us for more information on how we can help with your medical Mobile App.
Following is a list of some of the most useful resources for this topic.