Skip to product information
1 of 12

PayPal, credit cards. Download editable-PDF & invoice in 1 second!

YY/T 1843-2022 English PDF (YYT1843-2022)

YY/T 1843-2022 English PDF (YYT1843-2022)

Regular price $550.00 USD
Regular price Sale price $550.00 USD
Sale Sold out
Shipping calculated at checkout.
Quotation: In 1-minute, 24-hr self-service. Click here YY/T 1843-2022 to get it for Purchase Approval, Bank TT...

YY/T 1843-2022: Basic requirements of cybersecurity for medical electrical equipment

This document specifies the basic requirements for cyber security of medical electrical equipment, medical electrical system and medical device software. This document applies to medical electrical equipment, medical electrical system and medical device software with functions of user access, electronic data exchange or remote control.
YY/T 1843-2022
YY
PHARMACEUTICAL INDUSTRY STANDARD
OF THE PEOPLE REPUBLIC OF CHINA
ICS 11.040.01
CCS C 30
Basic requirements of cybersecurity for medical electrical
equipment
ISSUED ON: MAY 18, 2022
IMPLEMENTED ON: JUNE 01, 2023
Issued by: National Medical Products Administration
Table of Contents
Foreword ... 3
Introduction ... 4
1 Scope ... 5
2 Normative references ... 5
3 Terms and definitions ... 5
4 General requirements ... 10
5 Test methods ... 22
Appendix A (Normative) Requirements for the security capability testing process ... 23 Appendix B (Informative) Relevance between this document and other documents . 27 Appendix C (Informative) Guidance and rationale for specific clauses ... 28 Appendix D (Informative) Considerations regarding personal sensitive data in this document ... 36
References ... 38
Basic requirements of cyber security for medical electrical
equipment
1 Scope
This document specifies the basic requirements for cyber security of medical electrical equipment, medical electrical system and medical device software. This document applies to medical electrical equipment, medical electrical system and medical device software with functions of user access, electronic data exchange or remote control.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
The following terms and definitions are applicable to this document.
3.1 Safety
Do not pose an unacceptable risk to persons, property or the environment. [Source: ISO/IEC GUIDE 51:2014, 3.14, modified]
3.2 Confidentiality
The characteristic that information is not available or disclosed to unauthorized persons, entities or processes.
[Source: GB/T 29246-2017, 2.12]
3.3 Malware
Software designed to maliciously disrupt normal functionality, collect sensitive data, and/or access other connected systems.
3.4 Firewall
A network security product that analyzes the passing data stream and realizes access control and security protection functions.
3.5 Risk
The combination of the probability of occurrence of an injury and the severity of that injury.
[Source: YY/T 0316-2016, 2.16]
3.6 Risk analysis
The process of systematically using available information to identify hazard (sources) and estimate risks.
[Source: YY/T 0316-2016, 2.17]
3.7 Risk control
The process of making decisions and implementing measures to reduce risk or maintain risk at a specified level.
[Source: YY/T 0316-2016, 2.19]
3.8 Risk management
The systematic application of management policies, procedures and practices for risk analysis, evaluation, control and monitoring.
[Source: YY/T 0316-2016, 2.22]
3.9 Personal sensitive data
Personal information which, once leaked, illegally provided or misused, may endanger personal information and property safety, and may easily lead to damage or discriminatory treatment to personal reputation, physical and mental health. Note 1: Personal sensitive data may include ID number, personal bioinformation, bank account number, communication records and content, property
information, credit information, whereabouts, accommodation information, health and physiological information, transaction information, and personal information of children under or of the age of 14.
Note 2: In GB/T 35273-2020, it is called personal sensitive information. Since this document mainly regulates data, it is rewritten as data in this document. Note 3: For the determination method and type of personal sensitive data, refer to Appendix B in GB/T 35273-2020.
[Source: GB/T 35273-2020, 3.2, modified]
3.10 Emergency access
Through the technical processing of personal sensitive data, the subject of personal sensitive data cannot be identified or associated, and the processed information cannot be restored.
[Source: GB/T 35273-2020, 3.14, modified]
3.17 De-identification
Through the technical processing of personal sensitive data, the subject of personal sensitive data cannot be identified or associated without additional information. Note: De-identification is based on individuals, retaining the individual granularity, and using technical means such as pseudonyms, encryption, and hash
functions to replace the identification of personal sensitive data.
[Source: GB/T 35273-2020, 3.15, modified]
3.18 Equipment data
Data describing the operating status of the equipment, which is used to monitor and control the operation of the equipment or for the maintenance of the equipment, and does not involve personal sensitive data itself.
3.19 Audit logging
Data about information security events, which is collected for review and analysis, as well as ongoing monitoring.
[Source: GB/T 25068.1-2020, 3.4]
3.20 Security capability
Technical measures ?€? based on risk management ?€? enabling product data and/or functions to have acceptable levels of confidentiality, integrity, availability and other cyber security features.
Note: In this document, in order to distinguish the Chinese characters of security and safety, security is called cyber security, and safety is called safety. [Source: IEC/TR 80001-2-2:2012, 3.27, modified]
3.21 Security capability description
The document ?€? clarifying the security capability of the product ?€? whose main purpose is to serve as a basis for the tester to test the product.
Note: The form of security capability description ?€? which is not specified in this document ?€? can be a document, a set of documents, or a part of a document. 3.22 Integrity
The attribute that data shall not be altered in an unauthorized manner since it is created, transmitted or stored.
[Source: ISO/IEC 29167-19:2016, 3.40]
3.23 IT-network
One or more systems consisting of communication nodes and transmission links, to provide a physical link or wireless transmission between two or more designated communication nodes.
[Source: IEC/TR 80001-2-2:2012, 3.10]
3.24 Medical device software
A developed software system included in a medical device, or a software system developed for use as a medical device itself.
[Source: YY/T 0664-2020, 3.11]
3.25 Medical electrical equipment
ME equipment
Electrical equipment that has an applied part or transmits or obtains energy to the patient or detects the transmitted or obtained energy. Such electrical equipment: a) has no more than one connection to a specified power supply mains; and b) its manufacturer intends to use it for:
1) diagnosis, treatment or monitoring of patients; or
2) eliminating or reducing disease, damage or disability.
[Source: GB 9706.1-2020, 3.63]
3.26 Medical electrical system
ME system
A combination of several devices that are functionally connected or connected to each other by a multi-position socket under the manufacturer?€?s regulations. At least one of the combination is an ME equipment.
[Source: GB 9706.1-2020, 3.64]
3.27 Medical IT-network
4.1.1.3 The security capability description shall clarify the security capability according to the application of the product, in accordance with the requirements of 4.1.4 ~ 4.1.20.
4.1.1.4 The cyber security characteristics stated in the security capability description shall be testable or verifiable.
4.1.2 *Classification
4.1.2.1 According to the type of expected access network, it can be divided into products expected to access private network and public network.
4.1.2.2 According to the domain expected to be connected to the network, it can be divided into products expected to be connected to personal area networks, local area networks, and wide area networks.
4.1.2.3 According to the type of connection, it can be divided into products expected to be independently wired and wirelessly connected with other information equipment.
Note: The wired connection may include: USB, RS232, etc., and the wireless connection may include Wi-Fi communication, Bluetooth communication,
wireless communication of a private protocol in a private frequency band, etc.
4.1.2.4 According to the data transmission direction in the data exchange process, it can be divided into one-way transmission and two-way transmission.
4.1.2.5 According to usage scenario, it can be divided into medical scenario and non-medical scenario.
Note: Medical scenario may include treatment, diagnosis or monitoring scenario, and non-medical scenarios may include maintenance scenario, etc.
4.1.3 Product feature description
4.1.3.1 The security capability description shall classify products according to 4.1.2. 4.1.3.2 The security capability description shall specify the intended use of the product.
4.1.3.3 The security capability description shall provide a list of all electronic interfaces of the product in its intended configuration, including:
a) all remote interfaces;
b) all local interfaces, product local internal interfaces;
Note: The internal interface refers to the interface between the various components in the ME system.
c) all wireless interfaces;
d) input interface for all external files;
e) all communication protocols supported by each interface and their usage. 4.1.3.4 *The security capability description shall list the software name and version number of the product, including all third-party and open-source software included in the product.
4.1.3.5 The security capability description shall indicate the different configurations used in the product or the supported configurations.
Note 1: The configuration here refers to software and hardware configuration, such as:
-- operating system, system software or other supporting software;
-- processor and its size, main memory and its size, input and output
devices;
-- network environment.
Note 2: Different configurations can be specified for different requirements. However, manufacturers need to recognize the cyber security risks posed by different operating systems.
4.1.4 Storage confidentiality
The security capability description shall include a statement about the confidentiality of storage of sensitive data.
4.1.5 Transmission confidentiality
The security capability description shall include a statement about the confidentiality of transmission, especially considerations for sensitive data.
Note 1: Special consideration should be given to the confidentiality policy of sensitive data during the network data transmission process of the device on the public network.
Note 2: For more information on transmission confidentiality in wireless networks, refer to IEC/TR 80001-2-3:2012.
4.1.6 Identity information in health data
4.1.12 Node authentication
When applicable, the security capability statement shall contain a statement of node certification.
If the device is deployed in an HDO, the authentication policy shall be flexibly adapted to the security policy of the local HDO IT-network.
If the product contains multiple nodes, and the nodes may be accessed by other nodes outside the product, node authentication in this case shall be considered. Note: Node authentication methods generally include white list, user name/password, certificate, etc.
4.1.13 Malware detection and protection
The security capability description shall include a statement of whether the product supports malware detection and protection, which shall include how the security product is configured, and how malware is handled and repaired when it is detected. Note: Security products generally include antivirus software, auxiliary security software, and firewalls.
4.1.14 *System and application software hardening
Manufacturers shall take into account product system and application software hardening. If hardening is required, the security capability description shall include a statement of system and application software hardening measures. Such measures are used to ensure that only those resources and services relevant to the intended use are provided and that maintenance activities are kept to a minimum.
Note: Examples of such measures:
-- closing/disabling access ports unrelated to the product?€?s intended use; -- closing/disabling services unrelated to the product?€?s intended use;
-- closing/disabling software applications unrelated to the product?€?s intended use;
-- restricting/controlling access to the resource layer;
-- restricting/controlling access to the task layer.
4.1.15 Physical protection
The security capability description shall include a statement about the physical protection of the data exchange ports on the product.
If the product is deployed in an HDO, the security capability description shall include a statement about the physical protection of the product.
Note: Even if the asset of the physical equipment does not belong to the manufacturer, if there is an associated risk, it needs to be stated.
4.1.16 Non-repudiation
The security capability description shall include a statement about non-repudiation of the product.
4.1.17 Integrity and authenticity of health data
The security capability description shall include a statement about ensuring the integrity and authenticity of health data.
4.1.18 Accountability
The security capability description shall include a statement about the product?€?s accountability content and its means.
Note: Examples for such content:
-- successful or failed login attempts;
-- access, modification and deletion of health data;
-- import and export of health data;
-- changes in security configuration (e.g., changing credentials for user authentication, changing the list of valid user accounts);
-- remote access (which may be used for product maintenance or intended use);
-- emergency access.
4.1.19 Data backup and disaster recovery
The security capability description shall include a statement about the product?€?s data backup and disaster recovery strategy.
Note: The objective is to ensure the continuity of medical operations. Utilization of third-party and operating system functions for data backup is permitted in this document. This includes the consideration of system disaster recovery. In particular, products that need to archive health data need to consider
strategies to provide disaster recovery.
4.1.20 Maintainability
If the product is deployed in an HDO, the user documentation set shall clarify the user?€?s administrative functions, especially the responsibilities of IT administrators. Note 1: Considering the independence of the IT administrator?€?s functions, it is recommended to publish a separate administrator manual so that it can only be kept and viewed by the administrator.
Note 2: Regarding ?€?functions?€?, when necessary, clearly point out what tasks the administrator needs to complete, such as managing, customizing and
monitoring system information (such as access control lists, audit logging), and require the administrator to clearly understand the security-related functions.
Note 3: Even if the IT administrator is dispatched by the supplier/manufacturer, such responsibilities shall be clarified.
4.2.3 Identity information in health data
The user documentation set shall provide the necessary guidance on how to de-identify health data as stated in the security capability description. 4.2.4 User access control
The user documentation set shall contain guidance on the functions of user access control.
4.2.5 User authorization
The user documentation set shall state all existing roles and their access rights. 4.2.6 Automatic logoff
The user documentation set shall provide reference information on automatic logoff as stated in the security capability description.
4.2.7 Emergency access
The user documentation set shall state the directions for accessing necessary product functions or health data under the state of emergency.
4.2.8 Security product
If the security product can be installed by the user, the user documentation set shall state the security products compatible with the product, and shall provide configuration guidance for the security product.
4.2.9 Physical protection
The user documentation set shall provide reference information on physical protection as stated in the security capability description.
4.2.10 Accountability
The user documentation set shall provide guidance on how to view internet security incident records as stated in the security capability statement.
4.2.11 Data backup and disaster recovery
The user documentation set shall provide necessary guidance for product data backup and disaster recovery according to the statements of the security capability description.
4.2.12 Maintainability
The user documentation set shall include guidance on the maintainability-related content stated in the security capability description.
The user documentation set shall state the maintenance services related to the product maintenance plan and cyber security.
The user documentation set shall include guidance on ensuring that sensitive data is inaccessible when the storage device is decommissioned.
Note: Decommissioning may include discarding, reusing, reselling or recycling, etc. 4.3 Security capability requirements
4.3.1 Confidentiality
4.3.1.1 The product shall be implemented in accordance with the confidentiality features stated in the security capability description.
4.3.1.2 The product shall be provided with confidential means for all sensitive data generated, stored, used or transmitted by the product.
4.3.2 Identity information in health data
If the product can export personal sensitive data, the product shall provide the means to make it impossible to identify the necessary information of the patient. Note 1: Such means may include anonymization, de-identification, etc.
Note 2: It is also acceptable to use third-party tools specified by the manufacturer to accomplish the above goals.
4.3.3 *User access control

View full details