Mind the gaps: Part 2 — Building a comprehensive set of software requirements

While use requirements define the safe and effective installation, use, and maintenance of a medical device at a high level, software requirements translate that intent into technical specifications to guide implementation.

Our previous post discussed use-requirements analysis, emphasising the importance of building a comprehensive set of them in line with the expectations of IEC 82304-1.

Once your comprehensive set of use requirements is established, and risk analysis and evaluation activities have defined necessary software-based risk controls, IEC 62304 Clause 5.2 guides you to conduct software-requirements analysis. At this stage, you will decompose any use requirements to be implemented in software and software-based risk controls into detailed technical software requirements.

Comprehensiveness remains essential at the level of software-requirements analysis. A complete set of unique, testable software requirements that are fully traceable to use requirements and risk controls is vital to ensuring the development of high-quality, safe, medical device software.

It is worth noting that IEC 82304-1 also discusses the concept of system requirements. For SaMD, it is advantageous to conflate system requirements (IEC 82304-1 Clause 4.5) and software requirements (IEC 62304 Clause 5.2) for simplicity. The article here assumes that strategy. However, a manufacturer can define and maintain use, system, and software requirements if desired.

Frequently missed categories

Our previous post provided a detailed overview of the broad array of use requirement categories outlined by IEC 82304-1 Clause 4.2. This was complete with the advice to consider each category in relation to your device to avoid unintended omission of the less obvious requirements categories. This, in turn, will avoid unnecessary delays in certification or increased risk of post-market issues with the medical device.

Similarly, caution is advised when interpreting the requirements laid down in IEC 62304 Clause 5.2. This clause details various technical software requirements categories, and unintentionally omitting some can have the same negative consequences.

The following categories should be considered when conducting software-requirements analysis to ensure a comprehensive set of software requirements. If any categories do not apply to your medical device, justifying their exclusion can be highly beneficial to aid efficient assessment by a Conformity Assessment Body.

Functional software requirements

This category of software requirements ensures the intended behaviour of the medical device is implemented. The requirements may include:

• Feature-specific logic and decision making
• Use cases and workflows
• Responses of the medical device software to expected inputs or events
• Data handling/management, including access and authorisation

Performance software requirements 

This category defines measurable characteristics for the correct function of the medical device software. These requirements may include:

• Timing constraints (e.g. response time, startup time)
• Data throughput or refresh rates
• System capacity (e.g. number of concurrent users or sessions)
• Performance under load or stress conditions

Software risk-control requirements

This category focuses on the safe design and operation of the medical device software and aims to mitigate safety and/or security risks. These requirements are traced directly to risk-control measures defined through risk-management activities and may include:

• Software functions to mitigate hazardous situations
• Alarms, alerts, warnings, and operator instructions related to risk scenarios
• Fault detection and error handling
• Fail-safe behaviour and transitions to safe states

Software user-interface requirements

This category specifies the interface design between the user(s) and the medical device software. This includes usability engineering specifications that ensure the medical device software is safe to use (consult IEC 62366-1 Clause 5.6 for more information). These requirements may include:

• Layout and navigation rules
• Control behaviour and response
• Accessibility features
• Prevention of use errors

Software interface requirements

This category describes interactions between software elements or external systems, and may include:

• Interfaces between components within the medical device software
• Interfaces to accessories or external software systems
• Interfaces to external hardware
• APIs and protocol specifications
• Valid inputs and outputs of the software systems
• Error handling for interface communication failures
• Support for healthcare network protocols (e.g. HL7, FHIR, DICOM) and interoperability

Software data-definition and database requirements

This category defines characteristics and handling rules for data used or produced by the software:

• Data formats, types, and ranges
• Units of measurement and precision
• Input validation and error handling
• Storage, backup, and retrieval expectations

Artificial Intelligence requirements

This category addresses requirements unique to software that incorporates machine learning or AI elements. This may include:

• Training data quality and representativeness
• Training data inclusion and exclusion criteria
• Model-design requirements
• Model-performance thresholds (e.g. sensitivity, specificity)

Operational and lifecycle requirements

This category supports the deployment, use, and maintenance of the software throughout its life. It may include:

• Hardware or environmental dependencies
• Installation, configuration, and validation procedures
• Network configuration and resilience
• Software update and rollback mechanisms
• Backup and restore functionality
• Maintenance modes or tools for service personnel
• Error recovery and self-diagnostics

Cybersecurity requirements

This category defines software requirements to ensure secure operation in connected and local environments. This may include:

• User access control, including authentication and role-based authorisation
• Data protection (e.g. encryption in transit and at rest, and integrity verification)
• Security configuration and hardening (e.g. password policies and disablement of unused ports & services)
• Cyber-threat mitigation, including malware resistance and intrusion detection
• Monitoring and audit logging for security events and traceability
• Security update and patch management
  

Compliance and regulatory requirements

This category of software requirements covers regulatory and legal obligations, and adherence to relevant international standards. This may include:

• Management of healthcare data and personally identifiable data
• Audit logging
• Data retention and/or deletion
• Country- or region-specific mandates (e.g. GDPR)
• State-of-the-art software development and cybersecurity practices

Note that not all compliance and regulatory use requirements must be decomposed into software requirements. Only requirements that specify technical implementation within software should be captured here.

Many compliance and regulatory use requirements, such as GDPR mandates and development practices, could be implemented and validated through alternative means, such as accompanying documents and quality management procedures. 

Summary

Requirements analysis is a foundational element of medical device software development. It spans both high-level use requirements analysis, as defined in IEC 82304-1, and detailed technical software-requirements analysis, as specified in IEC 62304. These are not separate or sequential activities, but integrated processes: high-level use-requirements, together with risk-control measures, are systematically and traceably decomposed into precise software requirements that form the technical basis for implementation.

In earlier blog posts, we provided practical guidance on crafting requirements and ensuring testability. In this post and our previous publication, we concentrated on the importance of comprehensiveness.

Ensuring that you have constructed comprehensive sets of use requirements and software requirements will avoid unintended gaps in coverage and reduce both delays in the Conformity Assessment Body’s assessment of your technical documentation and post-market operational issues with your medical device.

By heeding this advice on requirements analysis early in your development process, you will set yourself up for success in your journey to medical device certification.