Welcome to the Mindset Extended Reality (XR) for digital mental health programme learning resources, which include three series: medical regulation, clinical evidence and lived experience involvement. Mindset-XR is helping to catalyse the growth of immersive digital mental health solutions in the UK, through funding, tailored support and training. It is delivered by Innovate UK and the Health Innovation Network South London (HIN).
This series focuses on medical regulation, with key insights from Hardian Health. Across 10 modules, we provide an accessible introduction to people and companies that want to learn more about medical device regulation, with a focus on XR devices. Each module offers a high level overview of a different topic, including medical device regulation in the UK and EU, core medical device standards and overseas regulation. Each module includes additional resources to support your learning and a quiz to test your understanding.
Outline
Welcome to Module 8: General XR and health software standards (non-medical device). In this section, we’re looking at the standards for XR and for health software and how to apply them to medical device development and deployment. Topics include:
What are the standards for XR?
An overview of key XR standards and relevant medical device standards.
What are the lifecycles, risk management and documentation for XR standards?
A closer look at lifecycles, requirements, risk management, control of change and traceability.
Multiple choice questions to test your understanding of the general XR and health software standards (non-medical device).
What are the standards for XR?
The ISO catalogue lists the standards related to XR. Keywords to search for include augmented reality (32 results) and virtual reality (42 results). These standards relate to the phases of design control for a medical device (see Module 4), such as The Design Control Procedure, which governs the Product Development Life Cycle (PDLC) or Software Development Life Cycle (SDLC).
It is important to go through the ISO catalogue standards to formulate a set of requirements of your own product. This will help you to satisfy any guidance in the standards that are relevant and helpful to your product. This will also strengthen the case that you are developing to the state of the art, a term used repeatedly in the EU Medical Device Regulation but most pertinently to this point as one of the General Safety and Performance Requirements, or GSPRs, that all medical devices have to satisfy in order to be certified, namely in this case GSPR number 17.2:
For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.
Relevant medical device standards – software
The key international standard for all medical devices and other healthcare software is IEC 62304, which you will use under its British guise as BS EN 62304. This standard defines the Systems Development Life Cycle (SDLC) processes that map into the design controls required for medical device quality assurance.
Wrapping around IEC 62304 is IEC 82304-1, or BS EN 82304-1, which explains how to apply the SDLC processes to software that you build to install on so-called ‘general computing platforms’. This can be taken to mean apps to install on AR headsets as well as apps to install on companion mobile device, laptops or other computers, such as servers in the cloud.
What are the lifecycles, risk management and documentation for XR standards?
Standards-based software development lifecycle processes
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.
Requirements and risk management
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.
Control of change, documentation, identification and traceability
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:
Tier 0 changes
Significant changes to design and/or operating principle must be discussed with regulatory authorities (UK Approved Body, EU Notified Body, US FDA). May need the product to be recertified.
Tier 1 changes
Changes to product (black box) requirements generally need revalidation (usability, clinical).
Tier 2 changes
Changes to system/software requirements – generally need reverification.
Tier 3 and Tier 4 changes
Minor fixes or internal changes not visible to users.
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.
Summary
In this module, General XR and health software standards (non-medical device), we explored how to apply a standards-based approach to XR development. After using this resource, you should have a understanding of the following:
There are standards for XR software that are useful to consider to drive the requirements for your own application. There are also standards that you must implement when realising medical devices including software as a medical device.
The standards help you to implement and coordinate design control, clinical evaluation and risk management to assure safety, effectiveness and cybersecurity of your device.
“The Software Development Life Cycle is for life, not just for Christmas” – you must control change throughout the lifetime of the device.
Quiz
Got questions, comments or feedback?Get in touch with the teamhin.mindset@nhs.net | mike@hardianhealth.com
PowerPoint: General XR and health software standards (non-medical device) – click to download
Next module – Module 9: What are the timelines and costs for medical device regulation?
Back to Module 7: How to document clinical evidence for medical devices