The content of character: defining safety and security characteristics in SaMD

Safety and security characteristics are foundational when it comes to SaMD certification, impacting many of the core pillars of regulatory compliance. But what exactly are they?

We’ve previously covered the importance of interface definitions and having testable requirements for Software as a Medical Device (SaMD). However, at the root of these concepts (and many others) are the actual device characteristics of the SaMD in question. 

What are device characteristics?

Fundamentally, a device’s characteristics describe what it is, what it is capable of, and what limitations it may have. They are high-level, outcome-oriented qualities that describe the device’s behaviour. Additional information can be found in ISO/TR 24971 Annex A — which provides a useful list of questions that can be applied to your device to assist in the identification of safety characteristics.

Some examples of characteristics: 

• The device handles confidential patient data
• The device is used in an ICU
• The device is used by authorised clinicians
• The device provides output and warnings for users
• The device detects and handles corrupted or incomplete input data
• The device provides information through a visual display

In contrast, requirements represent concrete, testable elements of the device that explain how these goals might be met — and are typically derived from device characteristics.

Some examples of requirements (based on the characteristics above):

• The device implements end-to-end encryption using TLS 1.3
• The device shall integrate with existing ICU monitoring systems
• The device shall require two-factor authentication for all users with access to patient data
• The device shall display confidence scores or uncertainty levels with each diagnostic output
• The device shall validate input file integrity (e.g. format, completeness) before analysis
• The device’s display font size for critical information (e.g. patient name, diagnosis, measurements) shall be at least 24 points (or equivalent pixels) on standard device resolution

In short, device characteristics tell regulators, users, and other stakeholders what your device is capable of, while requirements tell you what needs to be implemented and evidenced for those characteristics to hold true.

Why do they matter?

In the realm of SaMD, characteristics relating to a device’s safety and security are of critical importance. These inform a cascading list of important regulatory concepts, including:

• Use requirements
• Risk management
• Software requirements
• Software lifecycle management
• Usability engineering

These in turn help ensure that devices are safe, secure, and compliant with regulatory standards, including ISO 14971, IEC 62366-1, IEC 62304, and IEC 82304.

As a result, it is important to get these definitions right to avoid knock-on effects later in the device’s lifecycle.

Where do we start?

Given the above, it should be clear that the best time to define your device’s characteristics is right at the beginning of the entire development process. Software and safety characteristics form the foundation of a device’s performance and risk profile.  

Prioritising this is essential, as it ensures that the other pillars of the risk management, design, and development processes are built on accurate and thoughtfully considered device characteristics. Getting these correctly defined up front will put you in the best position to identify and manage potential risk early on, which in turn will empower you to tackle regulatory compliance and bring a better, safer, and more secure product to market.

The sum of its parts

The collection of characteristics used to describe your device should paint a clear picture of your device and its specific attributes, allowing you to meaningfully reflect on the risks associated with your device. Defining these early will not only increase confidence in the safety, security, and performance of your device, but also allow you to more easily support device compliance.

As with all aspects of SaMD development, keeping safety and security top of mind when addressing all areas of your product will ensure alignment with the best interests of all stakeholders, including patients, clinicians, and regulators.