Building Class III Medical Software apps on an Android Platform, Part 1: A case study

Sri Kanajan, Sri Ventures; Shrirang Khare, Persistent Systems, India; and Richard Jackson, Biolase Inc

April 21, 2014

Sri Kanajan, Sri Ventures; Shrirang Khare, Persistent Systems, India; and Richard Jackson, Biolase IncApril 21, 2014

In this first in a two-part article the authors describe the software development of an FDA-compliant Class III medical software application that was successfully ported from a Windows CE environment to an Android 4.1 tablet platform. The authors also discuss the lessons learned about how to integrate off-the-shelf components without affecting design goals.

Part 1 describes the specifics of the case study, the software architectural challenges and the automated verification framework used to complete the project. Part 2 addresses regulatory standards, development process, and outsourcing strategy utilized to complete this project within the timeline and organizational constraints.

Smartphone and Tablet usage is growing at an exponential rate. The hardware capability and available sensors on these mobile devices enable use cases that were previously unimaginable. Consumers are responding accordingly and adopting new technologies faster than ever. By 2017, the number of people in the world having access to a smartphone is expected to be over 3 billion.

This trend forces other industries to adopt these mobile technologies at an equivalent pace just to meet expectations of the users. The medical device industry is especially affected by this.

The case study - a soft real-time safety-critical medical application
Implantable defibrillators are devices that are implanted into the human patient. This device continually monitors the heart’s electrical rhythm for potentially life-threatening rhythms that may cause death. When such a rhythm is detected, the device provides shock therapy that may save the patient’s life (Figure 1). This implanted device can be accessed and monitored through a wireless connection with a mobile programming device typically called the Programmer.


Figure 1: Implantable defibrillator system – implantable device (IMD), Programmer

The legacy platform in this case study was a C++ based WinCE Netbook that was equipped with Bluetooth and a 16-bit PCMCIA custom hardware telemetry radio card. The new target platform is a tablet (Figure 2) with Android 4.1 software based on Java with a USB-based radio card. The wireless protocol used between the Programmer and implanted device is a custom protocol that conforms to the Medical Implant Communication Service (MICS) specification. The goal of the port was to transfer the same functionality onto the Android platform (the following areas were unchanged – wireless communication protocol, implant device side functionality, business logic state machine).


Figure 2: Target programmer (Android tablet) platform

The software in this case study is deemed Class III, which implies the highest level of criticality because a defect could cause patient death. Hence, compliance to a variety of external standards is required, the details of which will be discussed in the second part of this article. The conditions and constraints under which this legacy Windows project operated included (exact numbers are not given due to confidentiality reasons):
  • ~5000 requirements
  • ~10000 test cases
  • ~40 features
  • ~200k LOC of legacy Windows CE C++ code
  • ~5 in-house developers
  • Complete localization for five languages.
  • No in-house experience in Android and Java

To fully understand the challenges of porting the design from a legacy Windows CE design and at the same time transforming it into an Android-based platform that met the requirements for Class III software, it is important to be cognizant of a few technical differences between this Class III medical Android application and other applications on Android. Two important differences to note at this point are the following:
  • This application cannot be killed, suspended, or deprioritized relative to other applications or services. The application needs to be continually active so there is no room for memory leaks or anomalies that may lead to a crash. We implemented a lightweight GUI and memory manager to achieve this. The application has complete autonomy and there is no way for the user to leave the application once the tablet is turned on. The user interface (UI) needs to follow FDA standards and the legacy system that users are familiar with. Hence the UI had to be customized instead of using the native Android interface elements.
  • Relating to power management, since the wireless radio interface between the Programmer and the implantable device is custom, special hardware needs to be permanently attached to the 30-pin connector on the tablet. This hardware must be continually active and hence requires specific custom power management software.

Developing the application
Since this is a soft real-time system that works with a wireless embedded system and is used globally, there are multiple requirements that need to be considered. The list below captures the various dimensions of the requirements within this system. Note that each feature may contain a mix of one or more of these types including:
  • Functional requirements (Figure 4 below) capture the screen flow and are normally specified in terms of flow diagrams. Captures all possible scenarios of user interaction and reaction to the telemetry commands and the data to/from the implantable device.
  • GUI requirements (Figure 5 below) define the user observable screen layout, text and images.
  • Telemetry requirements define the sequence of commands from the Programmer and the expected reactions from the implanted device based on those commands. The exception paths are also detailed in these requirements, e.g. the screen that is presented when expected telemetry commands are not received or timed out.
  • Performance and safety requirements refer to the timing requirements, critical error handling and application stability. For example, the application must be able to run continually for over 4 days without reboot.
  • Printer requirements define the content and layout of the printed reports.
  • Multilingual requirements define the translations of all user observable text to the five supported languages.
  • Session requirements define the attributes of a session (captures the activities the user performs) that are stored and maintained on the non-volatile memory (SD card).



Figure 3: A Screen from the final Android application indicating implanted device information (real-time ECG in the bottom, programmable parameters in the middle, and implantable device status indicator and feature links in the top ribbons)


Figure 4: Example of requirements to describe a user flow (note that each transition is tagged uniquely)



Figure 5: Example of requirements for user interface text

The following productivity enhancement and early defect identification tools were utilized:

Git
- governs the change management of all verification and development code assets.

Code Pro Analytics
- a static analysis plugin within Eclipse (development environment) that analyzes the Java code against various best coding practices.

Implantable Device Simulator
- an in-house developed application that simulates all implantable device states and telemetry commands and responses. It allowed all developers to test their code as if it were interacting with a real device. It is a key tool to allow for simulation of state and error conditions that were difficult or impossible to duplicate with a real device.

Emma
- a utility within Eclipse that allows the developer to measure code/branch coverage of the unit tests.

Robotium
- an Android library that is the basis of the test automation framework. This library provides for APIs that enable UI interaction and the execution of automated test scripts.

Bugzilla
- the bug tracking system used between the IH and OS teams to track all defects and their lifecycles.

Test Management Suite
- a suite of in-house scripts stitched together around a Microsoft Access database and MS Excel data. All the test cases, test procedures, and traceability between requirements and test cases are captured within the database. The scripts allow the generation of various reports of interest.

Automated Build System (ant, Jenkins)
- automates the nightly code build

Software architecture
Given the set of requirements, the next challenge was to establish a robust architecture. Since we were moving to the Android 4.1 OS, we had an opportunity to redesign and optimize the application architecture. Below were the key technical architectural drivers:

Temporal determinism
- This implies that the architecture must ensure that functionality is met per specification under all possible conditions and that temporal requirements are met.

Reliability and availability
- The system must be operational for long periods of continuous usage without any restart or crashes (long MTTF) Also, the Programmer must reboot upon a failure quickly (short MTBF).

Fail safe
- Due to the safety critical nature of the application, failures must be dealt in a fail safe manner, i.e. upon failure, any loss of functionality will not result in any user or patient harm.

Extensibility -The ability to easily extend the design as requirements are changed or added.

Portability - The ability to move the Programmer software to another hardware platform and/or operating system version with minimum porting effort.

Reusability - The ability to reuse the core framework design in future programmer platforms.

Testability - The ability to automate all the forms of testing.

The software architecture based on these drivers is illustrated in Figure 6. The Android OS is an open and widely-used OS that can be customized for the needs of a safety-critical soft real-time system and that can also be ported quickly to other hardware platforms such smartphones. Hence, the choice of using Android. The architecture is based on a Model, View, Controller framework where the feature state machines that react to the user interactions and interact with the model data elements through getters and setters, represent the Controller. There are a number of data management classes (e.g. ACS/Communication system, Session Manager) that represent the Model. The view is at the top level of the architecture and would handle all the user interaction.


Click on image to enlarge.

Figure 6: Software architecture

< Previous
Page 1 of 2
Next >

Loading comments...

Parts Search Datasheets.com

KNOWLEDGE CENTER