What you need to know about traceable requirements for medical devices
A key piece of the technical documentation for a medical device is a requirement stack that covers the total product lifecycle (TPLC) of that device, including the requirements.
The two questions often come up, that we will answer in this blog, are:
How extensive does the requirements stack need to be?
Where and how do I store the requirements?
Organising the requirements stack
We must begin with outlining the essential content that should be included in the requirements stack and organise these requirements effectively. The organisation of these requirements is vital, as the stack isn’t just for the initial regulatory submission – whether to a UK Approved Body (UKAB), an EU Notified Body, the US FDA, or any other certification body. The requirements stack must also be maintained throughout the Total Product Life Cycle (TPLC). Therefore, establishing a system that ensures ongoing maintenance is efficient, effective, and as painless as possible is crucial.
Tiered requirements approach at Hardian Health
At Hardian Health, we categorise requirements into four tiers:
Tier 0: Provides a narrative of the Intended Use and the subsequent Regulatory Strategy.
Tier 1: Defines the Problem Space – the issues brought to the development team by the marketplace and the Product Manager or Product Owner.
Tier 2: Defines the Solution Space – instructions for developers to solve the problems outlined in Tier 1.
Tier 3: Defines the components or artefacts resulting from developing Tier 2, such as software executables, AI models, databases, hardware specifications, and documentation.
Understanding each tier
Tier 0
These are not written in formal language but represented in an Intended Use Statement and a Regulatory Strategy Record that includes Risk Classification.
Tier 1
Also known as User Needs, Product Requirements, or System Requirements. Tier 1 requirements for software are detailed in sections 4.2 and 4.5 of the International Standard IEC 82304-1:2016 and BS EN 82304-1:2017 in British Standard guise.
| 4.2 |
|
|
| 4.5 |
The manufacturer shall specify and document the system requirements for the health software product. These requirements shall include the functionality for intended use and, as applicable:
|
If we break this down further:
We find the expected content of Tier 1 requirements for hardware in other standards such as the 60601-1 series.
Section 4.2.5 shows that accompanying documents (instructions for use for users such as patients and clinicians, instructions for IT staff working with the software, etc.) also need to be considered in Tier 1.
Section 4.2.7 emphasises that we must consider not only the initial release of software (and hardware) but also how we maintain and update these systems over time.
Section 4.2.6 highlights that we need to dive into regulations, such as:
The EU Medical Device Regulation (MDR) and In vitro Diagnostic Medical Device.
Regulation (IVDR) and/ or the UK Medical Device Regulation.
The EU Electronic Instructions for Use Regulation.
The EU AI Act.
The General Data Protection Regulation rules for protected information.
Equivalent US Federal Regulations for Medical Devices, and for information security, such as HIPAA (the Health Information Portability and Accountability Act).
Equivalent regulations for other target markets outside of the UK, EU and USA.
Section 4.5 tells us to consider not only software and hardware performance (4.5.5) but also cybersecurity measures (4.5.6-7).
For us, the term ‘User Needs’ is correctly placed in for Tier 1. We believe Tier 1 is more about a holistic view of all stakeholders’ requirements, rather than just the end users' needs.
Tier 2
Also known as Design Inputs, Tier 2 requirements for software are listed in sections 5.2.2 and 5.2.3 of IEC 62304:2006+A1:2015 and BS EN 62304:2006+A1:2015 in its British Standard guise. These requirements detail functional and capability aspects, software system inputs and outputs, interface requirements, security needs, and more.
| 5.2.2 |
|
|
| 5.2.3 |
The manufacturer shall include risk control measures implemented in software in the requirements as appropriate to the medical device software. |
In section 5.2.2 we see how it neatly traces from 4.2.6 in 82304-1, as listed above; also 5.2.2.5 traces from 82304-1’s 4.5 – more on tracing later in this article.
In section 5.2.3 there is key point that ties formal risk analysis back to software (and hardware) requirements – all risk control measures are themselves Tier 2 requirements, that is features implemented to mitigate risks – be they mitigating safety, effectiveness or cybersecurity.
Tier 3
Also known as Design Outputs, these specifications detail the components, including hardware and software platforms (operating systems), on which the Tier 2 requirements are implemented. These are also the accompanying documents into which information is written.
Organising requirements by lifecycle phases and user groups
At Hardian Health, we organise individual Tier 1 requirements logically by lifecycle phases and user groups. This approach allows us to derive Tier 2 and Tier 3 requirements logically as well. The lifecycle phases go through the TPLC from cradle (development) to grave (requirement and disposal) of the product.
|
The user groups, as mentioned above, cover not only the end users (primary and secondary), but also supporting functions including those relating to quality assurance and regulatory compliance. We individually identify requirements with unique prefixes so that we can search our documentation for them.
|
Tier 1 requirements
We think of three types of Tier 1 requirements, namely functional and nonfunctional requirements, and risk mitigations.
Functional requirements or use cases – identified as “-UCxxx”
These are what define the behaviour of the system that end users interact with
We tend to write the use cases in user need language e.g. “as a user I need to log in to the system” or “as a system I need to process a chest x-ray image”
Nonfunctional requirements or system attributes – identified as “-SAxxx”
These define the attributes that end users do not necessarily consider directly but would be concerned with if not working correctly. Examples include:
Overall System Effectiveness (OSE) – This encompasses the availability, resilience, performance (analysis throughput, or roundtrip time limits), and quality (accuracy, precision, etc.) of analyses performed in software. The OSE requirements align with the clinical performance claims for a device, generally taken from literature reviews or other demonstrations of scientific validity. These claims are crucial for ensuring the device is superior (or at least non-inferior) to the current state of the art in its target market.
Security – Ensuring the protection of sensitive data and system integrity.
Interoperability with other systems – The ability of the device to work seamlessly with other systems.
We write these system attributes in imperative language, such as “The image analysis will take a maximum of 1.0 seconds until a report is presented on-screen.”
Risk mitigations – identified as “-RMxxx”
These relate to the aforementioned IEC 82304-1 section 4.5.3 “Risk control measures that have to be implemented in the health software product at the system level, based on the initial risk assessment.” Risk mitigations can arise from two primary sources:
Foreseeable Misuse Analysis – Typically documented in the Use Specification, the very first technical document for any product.
Characteristics Related to Safety Overview – Detailed in the product’s Risk Management Plan (RMP) as a list of triggers, which are then used to develop a comprehensive Device Hazard Analysis (DHA).
Tier 2 Requirements
Also known as Design Inputs, Tier 2 requirements are derived from Tier 1 requirements and further specify the system’s design. These are written as imperatives and identified as:
SRxxx for System or Software Requirements
HRxxx for Hardware Requirements
Every Tier 2 requirement should trace up to one or more Tier 1 requirements, and conversely, every Tier 1 requirement should trace down to one or more Tier 2 requirements. This strict traceability helps identify gaps, such as Tier 1 requirements that lack corresponding Tier 2 solutions, or Tier 2 requirements that do not address a Tier 1 problem.
For example, consider the requirement for logging into a system:
Tier 1: “As an end user, I need to log in securely” – this considers factors such as accessibility and environmental conditions (e.g., whether users can utilise keyboards, fingerprint sensors, facial recognition, or passcards due to physical or environmental factors).
Tier 2: Authorisation - Is it achieved via username & password, biometrics, or a passcard?
Tier 3: This includes end-user instructions, administrator processes for granting/revoking access, etc. The implementation would then involve:
Client hardware specification to allow biometrics (Fingerprint? Face?) and/or passcard reader.
Client hardware specification to read a passcard (Magnetic? NFC/RFID?).
Keyboard only?
Authentication: How is secure authentication achieved?
Instructions to Users: Where are these instructions documented?
Rule of thumb for writing requirements
Expect to write at least 100 Tier 1 requirements for a small to medium system.
As each Tier 1 requirement is decomposed into three or more Tier 2 requirements (client, server, documentation), you should expect at least 300 Tier 2 requirements.
All Risk Control Measures (RCMs) identified in the Device Hazard Analysis are treated as Tier 2 requirements. The analysis of existing Tier 2 requirements may lead to some being classified as RCMs or may result in the definition of additional RCMs.
Verification, validation, and traceability
Verification ensures that each Tier 2 requirement has been correctly implemented in the corresponding Tier 3 components and artefacts.
Validation confirms that Tier 1 requirements satisfy user or market needs, aligning with the intended use as specified in the Use Specification.
Traceability can be represented in the V-model, which maps out the relationships between Tiers 3, 2, 1, and even Tier 0, and links these to verification and validation testing. The V-model gets its name from the V-shape formed by the arrows representing the flow from requirements to testing.
SaMD tiered requirements
Containers and tools for managing requirements
The organisation of all the above requires digital tools:
A dedicated Requirements Management System (RMS) is ideal, but it can be relatively expensive for a startup or scaleup to subscribe to
A dedicated eQMS such as Greenlight Guru’s Design Matrix that offers features for requirements capture and tracing though these systems can also be relatively expensive to subscribe to, and have particular workflows that can be quite rigid, which must be weighed against whether the users (product owner, software developers, …) can use them effectively
An Issue Management System (IMS), such as Atlassian Jira can be configured to contain the requirements (the left side of the V) and the test protocols and results (the right side) but requires configuration of multiple paid add-ons to be able to expose and use the trace effectively
To overcome the above – at least to begin with for the first certifications of an agile startup looking to reduce costs – you can simply use a spreadsheet solution that runs in Microsoft Excel and Google Sheets.
Our solution at Hardian contains the requirements that our experience suggests should be established. We can handle (and teach you to handle) the tracing that must be submitted for a medical device certification and part of the change impact analysis that are key features of a dedicated RMS.
Hardian Health is a clinical digital consultancy focused on leveraging technology into healthcare markets through clinical strategy, scientific validation, regulation, health economics, and intellectual property.
