In the development of active medical devices with embedded software, the writing of the software section of the product technical requirements often confuses the R&D team.
As the “brain” of active devices, the normative nature of the technical requirements for embedded software directly determines the compliance and safety of the product. The “Guidelines for the Registration Review of Medical Device Software (2022 Revised Edition)” (Document No. 9 of 2022, hereinafter referred to as the “Software Guidelines”) and related regulations have clearly defined the framework for writing software technical requirements. This article will focus on the core points, breaking down the complete writing logic of the software section from basic information to performance indicators.
1. Basic Identification Information: The Software’s “Identity Profile” Must Be Clear
The basic identification is the “first impression” of the software and is also the core basis for subsequent traceability and management. The “Software Guidelines” require that it must be “uniquely identifiable, with no information omitted,” which includes three core elements:
1. Software Name and Model: Strongly Bound to Product Attributes
The software name must directly reflect its functional positioning in the medical device, avoiding vague expressions. For example, “Embedded Control Software for ECG Monitors” is more precise than “Monitoring Device Software,” as it clearly associates with the core purpose of the product. The model specifications must match the overall machine model; if the same product contains multiple software components, they must be labeled separately, such as “Model XX Ultrasound Diagnostic Device – Image Processing Software (Model: UIS – A), Control Software (Model: UIS – B).”
The key principle is to be “completely consistent with the registration declaration information” to avoid contradictions in names or models. A certain company had to correct materials later because the software name was written as “Smart Infusion Pump Management Software” in the technical requirements but was declared as “Infusion Pump Control Software,” leading to discrepancies.
2. Software Version Number: Standard Format + Clear Meaning
The version number is the “core identifier” of the software technical requirements. The “Software Guidelines” clearly require the use of the complete format “Major Version.Minor Version.Patch Number” and must indicate the release version. For example, “V2.1.0 (Full Release Version)” cannot be simplified to “V2.1” or “V2.”
More importantly, the version naming rules must reflect the nature of updates: a change in the major version number (e.g., V1.0.0→V2.0.0) corresponds to significant updates, including safety-related feature upgrades, core algorithm restructuring, etc.; a change in the minor version number (V2.0.0→V2.1.0) corresponds to functional expansions that do not affect safety; a change in the patch number (V2.1.0→V2.1.1) is only for bug fixes or minor optimizations. A certain ventilator company clearly stated in the technical requirements that “a change in the major version number requires re-conducting safety verification,” which is a compliance implementation of this requirement.
3. Software Component Description: Clarifying the Association with Hardware
It is necessary to clearly describe the coupling relationship between the software and the medical device hardware, for example, “This software is an embedded component of Model XX Surgical Robot and cannot operate independently; it must be used in conjunction with the main control unit hardware of model SR – H.” If there are purchased software components (such as open-source operating systems), their source, version, and usage scope must be indicated to avoid the risk of “concealed software composition.”
2. Functions and Core Algorithms: Clearly State “What It Does” and “How It Does It”
This part reflects the “core value” of the software technical requirements, achieving “function and risk matching, algorithm and performance correspondence.” The “Software Guidelines” emphasize that it must form a closed loop with the product’s applicable scope and clinical evaluation conclusions.
1. Core Functions: List Each Item + Associate with Clinical Value
The core functions of the software must be listed item by item according to “functional modules,” with each function clearly indicating its corresponding product use. For example, the ECG monitor software must specify “Heart Rate Data Collection (Sampling Frequency ≥ 1000Hz), Arrhythmia Analysis (Supports Atrial Fibrillation/Ventricular Fibrillation Recognition), Alarm Information Push (Response Time ≤ 1s),” rather than a vague statement of “having ECG monitoring capabilities.”
If the software includes non-medical device functions (such as log management, device parameter backup), they must be handled separately: separable functions must explain their coupling with medical functions (e.g., “Log management function operates independently and does not affect heart rate data collection”); inseparable functions must conduct risk analysis to justify their necessity (e.g., “Although the device parameter backup function is not core to medical use, it can reduce the risk of data loss and must be retained”).
2. Core Algorithms: Disclose by Process + Sufficient Basis
Algorithms are the core of software function realization and must be described in a complete logic of “data input → processing process → result output.” For example, the image reconstruction algorithm of an ultrasound diagnostic device must specify “Receive ultrasound echo signals → Remove noise using filtering algorithm (specific algorithm name) → Use iterative reconstruction algorithm (step description) to generate images → Output image data with a resolution of ≥ 1024×768.”
If it is a brand-new algorithm (not applied in similar products), it must be noted in the technical requirements that “This algorithm is self-developed; see attachment ‘XX Algorithm Research Report'” and the report must supplement supporting materials such as algorithm principles and verification data. A certain AI-assisted diagnostic software company had to supplement a large number of explanatory documents because it did not clearly specify the algorithm processing flow in the technical requirements, only writing “uses AI algorithms to achieve lesion recognition.”
3. System Architecture and Operating Environment: Define the Software’s “Survival Boundaries”
This part is the “basic guarantee” for the stable operation of the software, which must reflect the software’s deployment logic and environmental dependencies through graphical displays and clear requirements, including three core parts:
1. System Architecture: Clearly Present Module Relationships with Diagrams
A software layered architecture diagram must be provided, clearly showing the composition of modules such as “Application Layer, Core Algorithm Layer, Data Layer, Hardware Interface Layer,” and labeling the core functions, interface relationships, and data flow directions of each module. For example, “The user interaction module of the application layer calls the signal processing module of the core algorithm layer through the API interface, and the processed data is stored in the encrypted database of the data layer.”
At the same time, a physical topology diagram must be submitted to describe how the software is deployed within the hardware device, such as “Embedded software is solidified in the main control chip (Model: STM32H743) and interacts with the sensor module through the SPI interface,” making the connection logic between software and hardware clear at a glance.
2. Operating Environment: Software and Hardware Requirements Must Be Precise and Unambiguous
The operating environment must distinguish between “essential software” and “hardware configuration” to avoid vague expressions:
– Essential Software: Clearly specify the operating system (e.g., “Linux 5.4.0,” “Windows 10 Professional Edition 21H2”), database (e.g., “MySQL 8.0”), and other dependent components’ names and specific versions, rather than just writing “supports mainstream operating systems”;
– Hardware Configuration: Indicate the minimum processor model (e.g., “Intel Core i5 – 10400”), memory capacity (e.g., “≥8GB DDR4”), storage space (e.g., “≥256GB SSD”), etc., to ensure that the hardware foundation for software operation meets the standards.
4. Performance Indicators: Quantitative Requirements + Align with Standards
Performance indicators are the “quantitative basis” for software compliance. The “Software Guidelines” require coverage of four types of requirements: general, specific, safety, and quality, and must comply with the corresponding product standards:
1. General Requirements: Cover Basic Operating Capabilities
Including response time (e.g., “User operation command response time ≤ 500ms”), data accuracy (e.g., “Blood pressure measurement data error ≤ ±2mmHg”), user permission management (e.g., “Supports three-level permission division, administrators can configure operation permissions”), etc. The indicators must be quantifiable and verifiable, avoiding vague expressions like “responsive” or “high accuracy.”
2. Specific Requirements: Closely Follow Product-Specific Standards
Must comply with the national/industry standards corresponding to the product. For example, ECG machine software must meet the requirement of “Heart Rate Measurement Range 20 – 300 beats/min” in YY 1139 – 2023, and ultrasound diagnostic device software must comply with the image performance indicators of GB 10152 – 2022. A certain company’s multi-parameter monitor software had compliance defects in the technical requirements because it did not reference the alarm function requirements in YY 0709 – 2010.
3. Safety Requirements: Guarding Against Risk Bottom Lines
Core includes alarm functions and network security: the alarm function must clearly state “alarm trigger conditions, response time, alarm methods (audible and visual alarms),” in compliance with standards such as YY 0709; network security must cover data encryption (e.g., “transmitted data uses AES – 256 encryption”), anti-tampering (e.g., “modifications to critical medical data must retain logs”), permission control, etc., echoing the “Guidelines for the Registration Review of Medical Device Network Security.”
4. Quality Requirements: Ensuring Long-Term Stable Operation
Including reliability (e.g., “Continuous fault-free operation time ≥ 1000 hours”), compatibility (e.g., “Supports data interaction with LIS system version 5.0 and above”), maintainability (e.g., “Software fault repair time ≤ 4 hours”), etc., to ensure that the software performs stably throughout its lifecycle.
Practical Pitfalls: 3 Common Misunderstandings to Watch Out For
Based on the “Software Guidelines” and actual cases, the following three types of issues are most likely to occur in writing software technical requirements and should be avoided:
1. Non-standard Version Number Statements: Only writing the major version number or omitting the patch number, failing to clarify version update rules, leading to difficulties in determining whether to adjust technical requirements during subsequent software upgrades;
2. Vague Algorithm Descriptions: Using terms like “advanced algorithms” or “intelligent processing” to avoid specific processes, failing to provide supporting materials, which does not meet the “traceability” requirement;
3. Unquantified Performance Indicators: Lacking specific values or unclear referenced standards, making it impossible to determine whether the software meets the standards during inspection.
For active medical devices with embedded software, the core logic of the software technical requirements is “compliance throughout the entire lifecycle”—from the uniqueness of basic identification to the transparency of functional algorithms, and to the quantifiability of performance indicators, each item must serve the goal of “software safety and control, functional stability and reliability.” The R&D team must closely adhere to the “Software Guidelines,” combine with the actual functions of the product, and ensure that “content is not redundant, information is not missing, and indicators are verifiable” to truly maintain the compliance bottom line.