Client: Global Medical Devices Manufacturer – Medtronic Diabetes
Background
Medtronic Diabetes is the legal manufacturer of the Guardian Connect Continuous Glucose Monitor system. The system consists of:
- Guardian Connect Transmitter – A Bluetooth Low Energy (BLE) enabled interstitial glucose sensor
- Guardian App – A Mobile Medical App for use on a smartphone
- CareLink – A backend web portal for Healthcare Professionals (HCPs) and Caregivers to monitor their patients
Medtronic Diabetes designed and developed the glucose sensor, the HCP portal, and the iOS smartphone app.
Medtronic contracted BlueBridge Technologies to design and develop the Android mobile medical app.
Challenge
Medtronic (MDT) Diabetes requested BlueBridge Technologies (BBT) design and develop the Android mobile medical app. This surfaced several challenges
- The original design was created for Apple handsets and the iOS operating system. The design had to be adapted to suit Android handsets and the Android operating system. A significant portion of the design history file had to be created to detail the Android app.
- The app was due to be deployed via the Google Play Store using a “bring-your-own-device” policy.
- The hardware in Android handsets (Bluetooth modules, screens, processors, ram etc.) vary greatly across handsets, and even vary significantly within the same handset families. Apple has fewer devices (being only one manufacturer) and has a lot less variability.
- The Android OS itself varies significantly across different Android handset manufacturers – manufacturers typically modify a base version of the operating system in different ways to suit their own design needs and accessories.
- There are many combinations of Android OS versions and handsets. Many of these combinations are applicable to the target population. It is imperative that the device is safe, effective and secure on each combination.
- The Android app needed to be localized for 23 different geographic regions. The localisation included changing the language, and also changing the default units of measurement for some metrics within the system (e.g. mg/dL vs mmol/L). Some of the target locales used right-to-left languages.
- Some of the existing iOS risk management file (RMF) was applicable to the Android design efforts, but a wide range of new risks existed for Android which had to be uniquely identified, analysed, and mitigated. These risks included both safety risks and cybersecurity risks.
- Some of the existing iOS usability file was applicable to the Android design efforts, but (i) the UI had to be adapted at times to suit the Android and (ii) iOS-centric UI had to be implemented at times as these were the approved designs for the system.
The system is a Class III medical device in the US.
The IEC 62304 Software Safety Classification is Class B, but the strategic decision was taken to develop to Class C standards.
Approach
It was agreed with the client that the design and development of the Android mobile medical app should be undertaken though BBT’s Quality Management System. BBT is certified to ISO 13485:2016, ISO 14971:2019 and IEC 62304:2006+A1:2015.
BBT undertook a significant information transfer exercise with MDT to thoroughly understand the design and development that had been undertaken to date.
A design & development plan was drawn up and mutually agreed upon. As safety is paramount, a risk management plan was created which underpinned all the work. A software development plan was drawn up to clearly define the software design and development details for this project.
The design team set about analysing the system requirements and distilling these down to software requirements for the Android system. Parity was respected where possible between the iOS software requirements specification (SRS) and the new Android software requirements specification. The software risk analysis also gave rise to risk control measures which became detailed as software requirements.
The Android software architecture was designed, and user stories were authored in preparation for implementation. The UI elements were designed such that the UX was as identical as possible to the iOS app.
The test team authored automated test cases while code implementation was underway. The final test case suite thoroughly tested (i) the software requirements detailed in the SRS, (ii) the interfaces between the app and the backend, (iii) the interfaces between the core app and the OS / hardware layer, and (iv) the interoperability of the app with the Bluetooth continuous glucose monitor.
Cybersecurity formed a large portion of the undertaking as the system handled both valuable information and a cyber attack could also result in serious safety risks. Well thought out cybersecurity risk mitigations were managed holistically with the safety risk management.
To support the localization of the app, language packs were created by certified translators to ensure the medical terminology was clear and accurate. The automation test suite was leveraged to capture contextual screenshots of each screen in each language and each configuration, so that thorough in-context localization reviews could be undertaken. Obtaining a certificate of translations accuracy for all languages and locales was a key milestone in the project.
The app was thoroughly tested on an initial family of devices, and a blacklisting/whitelisting approach was applied to ensure that the app could not be used on untested devices post deployment. The automation testing and remote blacklisting/whitelisting approach permitted the expansion of the handset and OS combinations that the app was safe to be used on.
Outcome
The design history file was completed for the Android component of the system, and a design transfer was undertaken to transfer the app and the documentation to the legal manufacturer. The legal manufacturer subsequently created the submission pack and obtained FDA market clearance.
BBT remained engaged with the client for maintenance and post-market surveillance activities for a period following market clearance.
