{"id":383752,"date":"2023-12-15T10:36:33","date_gmt":"2023-12-15T15:36:33","guid":{"rendered":"https:\/\/platohealth.ai\/testing-strategies-for-bluetooth-medical-devices\/"},"modified":"2023-12-16T00:00:21","modified_gmt":"2023-12-16T05:00:21","slug":"testing-strategies-for-bluetooth-medical-devices","status":"publish","type":"post","link":"https:\/\/platohealth.ai\/testing-strategies-for-bluetooth-medical-devices\/","title":{"rendered":"Testing Strategies for Bluetooth Medical Devices","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
<\/div>\n
\n

This blog will be part of a future Orthogonal white paper on Bluetooth for connected medical devices.<\/p>\n

For more in-depth discussions on Bluetooth from medical device experts, visit our page on our Bluetooth Low Energy for Medical Devices Webinar Series<\/a>, co-presented by MedSec<\/a>.<\/p>\n

\u2013 \u2013 \u2013<\/p>\n

Part 5: Testing<\/span><\/h2>\n

Innovation requires iteration. Developers and manufacturers only arrive at safe and effective Bluetooth-enabled medical device solutions through strategic testing practices. In Part 5 of this white paper, we\u2019ll discuss the objective of testing and share our recommended approaches.<\/p>\n

Verification and Validation<\/span><\/h2>\n

Bluetooth-enabled medical device testing should be undertaken with a clear objective: to verify and validate<\/a> the medical device system. Verification and Validation (V&V) are evidence that a medical device works as intended in the environment in which it is meant to be used. Through V&V testing, manufacturers demonstrate that they have achieved compliance, appropriately mitigated patient risk and crafted good User Experience (UX) design for their connected device.<\/p>\n

Manufacturers verify<\/em> that the device or system meets its requirements, including when it is run on platforms of which the developer doesn\u2019t have full control. Orthogonal accomplishes verification throughout our Agile development process by leveraging user stories for acceptance test criteria, employing Test-driven Development and Behavior-driven Design and implementing documentation automation. We also perform automated testing of UX edge cases.<\/p>\n

Manufacturers validate<\/em> that the device meets its intended use. Orthogonal achieves validation by engaging in summative human factors testing as well as clinical validation.<\/p>\n

Testing best practices<\/span><\/h2>\n

No matter the size of the budget or the length of a development process, it is not possible to test every aspect of a device in its entirety. This is particularly true for devices that run on consumer hardware (a.ka., Bring Your Own Device (BYOD)), where changes to the environment (e.g., new smartphones or operating systems (OS)) are beyond the control of developers. Instead, developers need to be strategic about what they test and how they test.<\/p>\n

Risk analysis<\/span><\/h3>\n

Risk analysis is the process of identifying risks and challenges in a medical device software system, whether they be risks to the safe operation of the system, cybersecurity risk or risks to patient health. Once identified, risks can be further analyzed to determine if they are low risk, medium risk or high risk.<\/p>\n

Risk-based approach to testing<\/span><\/h3>\n

A risk-based approach is when aspects of the device are prioritized for testing based on the results of risk analysis. The higher the risk to the system, the more testing is required. This strategy is used by the FDA<\/a> when conducting clinical investigations.<\/p>\n

At the outset of development, the location of the most critical dependencies in a device may not be clear. Developers might need to test more widely at first and use the data from tests to narrow their scope. A narrowed scope is also advantageous when presenting to the FDA, as it\u2019s easier to add to testing in resubmissions than it is to pare the scope back.<\/p>\n

Edge cases<\/span><\/h3>\n

We previously discussed testing strategies for edge cases in Part 2: Managing Edge Cases for Bluetooth Medical Devices<\/a>. Likewise, we recommended taking the results of identifying, testing and mitigating edge cases and placing them in an edge case library that can be used as a baseline for future projects. Edge case libraries significantly cut down on the edge case workload for future Bluetooth devices.<\/p>\n

BYOD testing layers<\/span><\/h3>\n

Managing a BYOD environment for a Bluetooth-enabled medical device is best done using a layered approach. Depending on the levels of risk, the following layers can be employed to maximize assurance out of a testing budget.<\/p>\n

Platform compatibility assurance elements<\/span><\/h4>\n