Understanding the Process of Medical Device Software Testing

Countless medical and healthcare innovations have entered the market in recent years. As per a report, adoption of IoT and benefits offered by SaMD (Software as a Medical Device) are driving the software as a medical device market growth, resulting in more innovative healthcare devices.

These technological innovations are designed to provide high-quality care to patients, aid in healthcare data security and transmission, facilitate remote care options, and offer easy access to medical records.

Though healthcare technology gives numerous benefits, it comes with its own set of risks as well. Data breaches, faulty devices, and cyber crimes are a result of a gap in creating a medical device or software. In order to ensure that quality medical device software reaches the market, developers and testers need to assure to perform a thorough medical device software testing.

Process of Medical Device Software Testing

1. Compliance and Regulations Verification

One of the key regulations to consider for medical devices is IEC 62304, which determines the life cycle requirements for a medical device software. Set of activities, processes, and tasks defined in this regulation establishes a common framework for medical device software life cycle processes.

Manufacturers have to follow these regulations to receive FDA approval in the USA to develop FDA compliant medical software. Further, a medical device software falls into either of the following three categories:

a. Class A: No damage or injury to health is possible

b. Class B: Possible injury but not serious

c. Class C: Serious or death injury is possible

Regulations are rigorous for Class C as compared to Class A due to risks and incorrect outcomes caused by a faulty device. Regulations cover all standards needed during the development process, however specifically for software testing consider sections 5.6 that covers integration, and section 5.7 that defines software system testing.

Additionally, for medical devices that need upgrades, section 7.4 is considered that talks about risk management. Other regulations to note are ISO 13485 that determines international standard for quality management. IEC 60601 is an essential regulation for electrically operated medical devices.

Since, medical device software can contain ePHI (Protected Health Information), it’s important to ensure HIPAA compliance of software to safeguard patients’ medical records.

2. Functionality Testing

The main objective of functionality testing is to check working of a software, and it focuses on testing the basic usability of the medical device system; checks whether a user can smoothly navigate through screens without any hinderances.

Further, functionality testing also includes testing the mainline functions of a software, along with verifying accessibility of the system for users. Some of the functionality testing tools which can be used are QTP, Selenium, soapUI, and JUnit.

Functionality testing is executed in five steps, which are as follows:

a. Understanding the basic functional needs.

b. Identifying test data or test input as per requirements.

c. Computing expected outcomes with chosen test input values.

d. Executing test cases

e. Comparing computed and actual expected results.

3. Software Verification

Under software verification, a medical device software is checked whether it meets the expected requirements without executing the code. Commonly used software verification methods include:

a. Peer Reviews: Here, developers review documents to identify faults in the software. During peer reviews process, the SRS (Software Requirements Verification) document is reviewed thoroughly.

b. Walkthroughs: This is a systematic verification method as compared to peer reviews. The author of the software document presents it in front of people, and this method helps to find faults in medical device software.

c. Inspection: A group of three to six people are consulted for software review. This is an effective way to find problems in documents such as SDD, SRS, etc., and improve them, along with bettering software development life cycle process.

4. Interoperability Testing

Developers check whether medical device software can interact with other software systems and components, without any compatibility issues. Levels of interoperability testing consists of data-type, physical, semantic, and specification level interoperability.

This type of testing ensures end-to-end service provision for two or more medical devices. However, certain risks associated with interoperability testing are loss of data, unreliable operation, and low maintenance.

5. GUI or Design Validation

The purpose of GUI (Graphical User Interface) testing is to assure that all functionalities of medical device software work as per specifications, and this is done by checking controls and screens such as menus, buttons, icons, etc.

The following aspects are validated under GUI testing:

a. Correct display of error messages

b. Text alignment

c. Colors, fonts, and images

d. Positioning of GUI elements for various screen resolutions

e. Clear demarcation of sections on screen

6. Confirming Software Requirements

Creating software requirements list is an essential task, as it helps testers to save time and costs looking for hidden requirements themselves, and what to test for.

Developers may not know whether medical device software testing is complete or not, and they may end up making assumptions, resulting in release of half checked software in the market.

This indirectly provides faulty devices to the users. Additionally, unclear software requirements allows bugs to enter the system, leading to a failed device.

During software requirements, testers can check for the following aspects:

a. Clear and defined objects/ entities in the user story.

b. User story captures the essence of the product and both programmer and user can co-relate with the details of software.

c. Task story to be completed in a day or in one sprint.

7. Bench and Reliability Testing

Bench testing is a crucial step in the initial device design process, and is created to tease out design and mechanical flaws in medical devices. This test also helps to check endurance of a human body without having to implant a device in a human being.

Further, according to the FDA, non-clinical bench performance testing can be wrapped up by third party testing facility or device manufacturer, and it depends on the device type or actual device.

Test covers biological engineering performance such as tensile strength, wear, compression, fatigue, etc. Test report summaries must include test objectives, tests performed, result summary, pre-defined fail/pass criteria, discussions, and conclusions.

8. Code Reviews

For this stage, adopt code quality guide to define the requirements, software complexity, clarity, and maintenance. Conduct a source code analysis to verify compliance with respect to guidelines, and setup code reviews as part of the software coding practice.

Further, increase share of testing performed by the development team as it aids to identify defects when they’re less and easy to fix.

The demand for medical device software will continue to rise in the coming years due to its varied benefits such as enhanced patient care, treatment for chronic conditions, and access to medical records. If you’re looking to develop a cutting-edge healthcare software for your organization, then contact Arkenea, which specializes in healthcare software development.

Scroll to Top