Mindset XR Module 8: How to apply medical device standards to XR

You need to plan the processes that will underpin the quality assurance of your software. Although modern software tends to be built in an incremental or iterative fashion and development teams prefer to use agile methodologies, such as scrum or kanban, it is still necessary to consider design control, including design transfer and the control of change.   

Therefore, we tend to write-up a succinct mapping, in the form of a diagram. This shows how design control is undertaken in an iterative and incremental way, including the need to formalise reviews at judicious points in each release cycle and to formalise the release itself.

You need to establish product requirements, which are often expressed in terms of user stories, as well as software requirements, which are more technical.

Product requirements: define the problem to be solved, from the viewpoints of users, regulators and other stakeholders. The product requirements must be traceable down to software requirements, to show that solutions are implemented for all the problems, and across to validation tests that show that the problems have been solved effectively.  

Software requirements: define the solutions chosen to solve those problems. The software requirements must be traceable back to product requirements and across to verification tests that show that the requirements have been implemented correctly. 

An important subset of the requirements for a medical device, including software as a medical device, is the mitigations for patient and user safety and for cybersecurity, known as Risk Control Measures (RCMs). There is a standardised way to express these, based on the international standard ISO 14971 (see Module 5). 

When machine learning is applied, risk management extends to the creation of the model itself, including measuring its performance and integration of the model into the deployable software.

Once a version of software has been released, and during the development of each release, change has to be controlled.  A factor in the medical device world is that once a device has been certified, there are certain changes that may need recertification. The tiers of changes include:

As well as this, all the documentation created for the original release for certification must be kept up-to-date for each subsequent release. Hence the concept of transferring feature requests and problem reports from an overall product backlog into a release backlog takes on the need to answer a set of questions about how far the company needs or wants to go with each release.