Building Class III Medical Software apps on an Android Platform, Part 2: Developing an FDA-compliant framework

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

April 20, 2014

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

As noted in Part I of this series, many of our design decisions and the methodology adopted for developing an Android-based Class III medical software platform were based on the need to comply with the FDA guidance documents and external standards. Figure 13 shows the set of standards that drove the development methodology we used.

Figure 13: Standards driving the development process

Our development process for both production code and verification assets was based on the following essential elements:

Requirements. Every requirement is uniquely tagged.

Traceability. Every requirement must have at least one or more test cases. Additional traceability between design elements and the requirements is desirable but not required.

Accountability. Reviews are documented and comments of the review meeting attendees are recorded so that how and when decisions were made and who made them can be traced.

Change management. All product modifications are recorded in the form of change requests or change orders that capture all aspects of that change’s life cycle, including independent verification of the change.

Risk-based development process. The degree of code verification coverage of a specific software component is determined by the component’s risk level. Standard risk analysis techniques such as FMEA and fault trees were applied.

Peer review. All work output (requirements, design, code, test procedures) are peer reviewed by at least one independent reviewer.

Figure 14 illustrates the specific methodology that was employed at every Agile sprint until all features were completed. The verification assets were developed in parallel with the feature code development such that the requirements could be refined as early as possible and the development could be tested as soon as a build was available.

Figure 14: Software development methodology. Note that each iteration involves all the activities mentioned.

Ripple effects analysis (REA). One of the biggest challenges most software projects face is last minute requirement modifications. These can cause unpredictable delays and defects. In order to accommodate requirement changes, we established a checklist-based formal REA process that involved evaluating the specific requirement change and all the impacts it could have on the development and verification assets. This was peer reviewed by all the stakeholders to ensure that the change was adequately verified with minimal likelihood of side-effects and without an overly burdensome verification plan.

Outsourcing strategy
One of the challenges we encountered was the lack of Android and Java experience within the team and the relatively short deadline for project completion. Given these constraints, outsourcing was the only viable option. Nevertheless, as a team, we recognized the criticality of being able to internally maintain and extend the software over a long period (an approximate eight-year software platform lifecycle) independently from the outsource partner. Hence one of the goals of the outsourcing contract was to ensure that the deliverables were maintainable and extensible beyond the outsourcing contract. As shown in Figure 14, some of the elements in our outsourcing strategy included the generation of a statement of work, creation of an Agile development process to support it, and coming up with ways to integrate various external outsourcing partners.

Statement of work (SOW). Since Class III medical software requires significant process control that the outsource (OS) partner did not have, the SOW was broken into three major phases. The first phase was a quick sprint of implementing a single low-complexity feature. The goal of this sprint was for the outsource partner to learn the specific process that the in-house (IH) partner wanted, as well as to derive a basis to estimate the work needed to complete all the deliverables necessary to complete the project.

The second phase was the development of all features and the development of the verification assets (automated and manual). This phase was broken up to eight sprints of one month duration each, where both the OS and IH teams collaborated to complete development and verification of all the features. The first sprint involved prototyping the architecture such that feature development could be done concurrently. Figure 15 illustrates the collaborative process that was employed for each of these sprints. The deliverables coming out of this process were as follows:
  • Design document for each feature and architectural component
  • Unit tests report indicating code and branch coverage for all components
  • Verification test case, protocol, and automated test script (if automated)
  • Source code (including unit test code)
  • Verification test execution report indicating results as well as log files of the execution
  • Screenshots for all screens in all languages (this was for the multi-lingual verification)
  • Automated test execution infrastructure and all test protocols and test cases
  • Work instructions for all process elements ranging from verification to software installation
  • Peer review reports for code/test case reviews
  • Validated set of screenshots per user experience testing using Android GUI widgets

< Previous
Page 1 of 2
Next >

Loading comments...