YY/T 0708-2009 PDF English
Search result: YY/T 0708-2009_English: PDF (YY/T0708-2009)
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Name of Chinese Standard | Status |
| YY/T 0708-2009 | English | 245 |
Add to Cart
|
0-9 seconds. Auto-delivery.
|
Medical electrical equipment. Part 1-4: General requirements for safety. Collateral standard: Programmable electrical medical systems
| Obsolete |
BUY with any currencies (Euro, JPY, GBP, KRW etc.): YY/T 0708-2009 Related standards: YY/T 0708-2009
PDF Preview: YY/T 0708-2009
YY/T 0708-2009: PDF in English (YYT 0708-2009) YY/T 0708-2009
Medical electrical equipment-Part 1-4. General requirements for safety.Collateral standard. Programmable electrical medical systems
ICS 11.040.01
C30
People's Republic of China Pharmaceutical Industry Standard
Medical electrical equipment. Part 1-4. General safety requirements
Parallel Standard. Programmable Medical Electrical System
Released on.2009-11-11
2010-12-12-01 implementation
Published by the State Food and Drug Administration
Foreword
This collateral standard is equivalent to IEC 60601-1-4..2000 "Medical Electrical Equipment Part 1-4. General requirements for safety.
Programmable Medical Electrical System.
This collateral standard is GB 97.16.1-2007 "Medical Electrical Equipment Part 1. General Safety Requirements" (IEC 60601-1. 1988,
IDT) A juxtaposition of common standards.
Appendix AAA of this collateral standard is a normative appendix, Appendix BBB, Appendix CC, Appendix DDD, Appendix EEE, Appendix FFF are all
It is an informative appendix.
This collateral standard is under the jurisdiction of the National Medical Electrical Equipment Standardization Technical Committee (SAC/TC10).
This juxtaposed standard was drafted by. State Food and Drug Administration Hangzhou Medical Device Quality Supervision and Inspection Center, National Wuhan Medical Supervision
Acoustic Instrument Quality Supervision and Testing Center.
The main drafters of this collocated standard. Du Yan, Ma Li, He Anshi, Zheng Jian.
introduction
Computers are increasingly used in medical electrical equipment and often play a role closely related to safety. Computer Application Technology in
The use of medical electrical equipment makes the complexity of the system second only to the diagnosis and/or treatment of medical equipment --- the patient's physiology department
System. This complexity means that systemic failures may exceed the ability to be judged by practically acceptable test limits. Accordingly, intrinsic safety
The full standard goes beyond the traditional testing and evaluation of existing medical electrical equipment; this safety standard includes requirements for the medical device development process.
The finished product test itself cannot fully explain the safety of complex medical electrical equipment.
This document is a juxtaposition of common standards. It requires following a process and producing a record of the process to support the
Sub-system safety of medical electrical equipment. The concepts of risk management and development life cycle are the foundation of the standard, and these concepts
It is also valuable to develop medical electrical equipment without programmable electronic subsystems.
For the task to be handled, the effective application of this standard requires the following capabilities.
--- Safety factors that should be considered in specific medical electrical equipment applications;
--- The development process of medical electrical equipment;
--- security guarantee method;
--- Risk analysis and risk control skills.
Medical electrical equipment. Part 1-4. General safety requirements
Parallel Standard. Programmable Medical Electrical System
First overview
1 Scope, purpose, and relationship with other standards
1.2001 range
This collateral standard applies to medical electrical equipment and medical electrical systems with programmable electronic subsystems (PESS) [hereinafter referred to as
Programming Medical Electrical Systems (PEMS)] safety requirements.
Note. Some systems with software for medical purposes are beyond the scope of this collateral standard, for example. many medical information systems. Identification elements (criteria)
For. Does the system meet the definition of medical electrical equipment in GB 2.706.1-2.07 or 2.2.1 in GB 2.706.15-2008?
Definition of medical electrical systems.
1.202 Purpose
This collateral standard specifies requirements in the design of programmable medical electrical systems. This collateral standard is also used as the basis for the requirements of specific standards.
Foundations, including guidance on security requirements for risk reduction and management purposes. This collateral standard addresses.
a) certification body;
b) the manufacturer;
c) Special standard preparation staff.
This standard covers.
d) requirements specifications;
e) architecture;
f) detailed design and implementation, including software development;
g) modification;
h) verification and validation;
i) Marking and random files.
This standard does not cover.
ii) hardware manufacturing;
k) software replication;
l) installation and delivery;
m) operation and maintenance;
n) Exit use.
1.203 Relationship with other standards
1.203.1 GB 970.1
For medical electrical equipment, this collateral standard is a supplement to GB 97.16.1.
When quoting GB 9706.1 or this juxtaposed standard separately or jointly, it is clear as follows.
--- "This General Standard" refers only to GB 976.1;
--- "This juxtaposed standard" refers only to ＹＹ/T 0708-2009;
--- "This standard" refers to the general standard and this juxtaposed standard.
1.203.2 Special standards
The requirements in the dedicated standard take precedence over the corresponding requirements in this collateral standard.
1.203.3 Normative references
The clauses in the following documents have been incorporated into the clauses of this standard by reference. For dated references, their
All subsequent amendments (excluding the content of errata) or revisions are not applicable to this collateral standard, however, it is encouraged that
The parties to the agreement study whether the latest versions of these documents are available. For undated references, the latest edition applies to this document.
Tied standards.
GB 970.1-2007 Medical electrical equipment Part 1. General requirements for safety (IEC 60601-1. 1988, IDT)
GB 9706.15-2008 Medical electrical equipment. Part 1-1. General requirements for safety. Collateral standard. Safety for medical electrical systems.
Requirements (IEC 60601-1-1..2000, IDT)
GB/T.1990-2000 Quality Management System Requirements (idt ISO 9001..2000)
IEC 60878. 1984 Medical Radiology Terminology
2.2001 Terms and Definitions
The following terms and definitions apply to this collateral standard. In this juxtaposed standard, terms used in bold typeface and common standards,
GB 9706.15 is consistent with the definitions in this collateral standard or IEC 60878. 1984.
This collateral standard gives an index of terms in Appendix AAA (normative appendix).
2.201.1.1
Necessary activities from the conceptual design phase of the project to the completion of the verification of the programmable medical electrical system (PEMS).
2.201.2
Identification of hazards and causes.
Note. Quantification of hazards is not part of the hazard analysis.
2.201.3
Specify the maximum acceptable amount of risk.
Note. The amount of risk can be either the regulation of the entire hazard of a programmable medical electrical system, or the regulation of a specific hazard.
2.201.4
Medical electrical equipment or medical electrical system containing one or more programmable electronic subsystems.
2.201.5
Systems based on one or more central processing units, including their software and interfaces.
2.201.6
After implementing risk management, the remaining risks are derived from the hazard analysis.
2.201.7
Probability of harm causing harm and severity of harm.
2.201.8
The part of the quality record required by this standard.
2.201.9
Provide traceability documentation for the cause of each hazard in the hazard and risk analysis, and verification that the risk has been controlled.
Note. Documents can be stored on paper or electronic media.
2.201.10
Avoiding unacceptable risks.
2.201.11
Potentially harmful effects on patients, other persons, animals, or the environment caused directly by medical electrical equipment.
2.201.12
Not adopted.
2.201.13
A qualitative measure of the possible consequences of a hazard.
2.201.14
The process of evaluating a programmable medical electrical system or its components during or at the end of the development process to determine whether it meets expectations
Use requirements.
2.201.15
The process of evaluating a programmable medical electrical system or its components to determine whether a product at the development stage meets the requirements for development at that stage.
Specific requirements from the beginning.
2.202 required degree and other terminology
In this juxtaposed standard, certain words have the following special meanings.
--- "shall" means a mandatory requirement that must be met.
--- "Should" means strongly suggested but not necessarily achieved.
--- "May (may)" means a permissible method adopted in order to comply with the requirements or avoid the need to comply.
--- "Specific" is used to indicate certain information quoted in this juxtaposed standard or other standards, usually about specific
Operating conditions, test arrangements, or standards related to compliance.
--- "Required" Limits stated by the manufacturer in a random document or other document under consideration related to PEMS
Qualitative information, usually related to its intended purpose or parameters, or conditions related to its use or tests used to determine compliance.
6 Identification, marking and documentation
6.8 Random files
6.8.2001 All information related to significant residual risks, including a description of the hazard and what the operator or user is trying to avoid (reduce)
The measures to be taken for hazards should be recorded in the instruction manual and risk management documents.
6.8.202 The random file of the programmable medical electrical system should at least identify the manufacturer and a unique identifier, such as the version number and release of the file.
(Publication) date.
Note. Information applicable to certain specific devices intended to be used with the software, as well as the manufacturer's contact information, should be located in the outer packaging or user manual
Medium, so that the user can operate independently of the software.
Chapter IX Abnormal Operation and Failure State; Environmental Test
52 Abnormal operation and fault conditions
52.2001 Documents
52.2.11.1 The documents formed by the application of this standard shall be maintained and made part of the quality record; see Figure.201. Should follow
The requirements of 4.2 in GB/T.1990-2000 are implemented.
52.201.2 These documents (hereinafter referred to as risk management documents) shall be approved, released and changed in accordance with the prescribed configuration management mechanism.
It should be implemented in accordance with the requirements of 4.2.3 in GB/T 19001-2000.
52.201.3 Throughout the development life cycle, a risk management profile should be formed and used as part of the risk management document. Its content
Should include.
a) identified hazards and their causes;
b) risk estimation;
c) proof of security measures taken to eliminate or control the risk of hazards;
d) evaluation of the effectiveness of risk control;
e) proof of verification;
Check compliance by checking risk management documents.
52.202 Risk Management Plan
52.202.1 The manufacturer shall establish a risk management plan.
52.2.2 The plan shall include the following.
a) the scope of the plan, identifying the project or product and the stages of the development life cycle to which the plan applies;
b) applicable development life cycle (see 52.203), including verification plans and validation plans;
c) Management responsibilities in accordance with 5.1 of GB/T 12001-2000;
d) risk management processes;
e) audit requirements.
52.202.3 If changes are planned during development, records of the changes shall be maintained.
Check compliance by checking risk management documents.
52.203 Development Life Cycle
52.203.1 A development life cycle shall be defined for the design and development of programmable medical electrical systems.
52.203.2 The development life cycle should be broken down into phases and tasks. For each phase and task, inputs and outputs should be clearly defined to
And activities.
52.203.3 The development life cycle shall include the entire process of risk management.
52.203.4 The development life cycle shall include requirements for documentation.
52.203.5 Risk management activities shall be properly implemented throughout the development life cycle, see 52.204.
Note. An example of a development life cycle is given in Appendix DDD (Informative).
Check compliance by checking risk management documents.
52.203.6 A clear set of problem solutions shall be established and maintained at all stages of the development life cycle and where applicable within or between tasks.
Decision system as part of the risk management documentation. According to the problem, the system can have the following characteristics.
--- Defined as part of the development life cycle;
--- Allows reporting of potential or existing security and/or performance issues;
--- Include an assessment of the risks associated with each issue;
--- determine the criteria for the end of the problem analysis [security and/or performance aspects];
--- Determine the measures taken to resolve various issues;
--- determine the method of confirmation of each measure;
--- Determine the steps to verify continued compliance.
52.204 Risk Management Process
52.204.1 Elements
A risk management process that includes the following elements should be used.
---Risk Analysis;
---risk control.
52.204.2 Requirements
The risk management process should run through the entire development life cycle.
52.204.3 Risk analysis
52.20.3.1 Hazard analysis
52.204.3.1.1.1 Hazards shall be identified in accordance with the risk management plan, see 52.202.
52.20.4.3.1.2 Hazard identification shall be performed for all reasonably foreseeable situations, including.
--- Under normal use;
--- Incorrect use.
52.20.4.3.1.3 Appropriate hazard conditions shall be considered, including.
--- the harm to patients;
--- Harm to the operator;
--- hazards to maintenance personnel;
--- hazards to nearby personnel;
--- Harm to the environment.
52.20.4.3.1.4 Consideration shall be given to a reasonably foreseeable sequence of events that may lead to a hazard.
52.20.4.3.1.5 Consideration shall be given to appropriate causes of hazards, including.
--- Human factors, including ergonomic constraints;
---hardware malfunction;
--- software failure;
--- Integration error;
--- Environmental conditions.
52.20.4.3.1.6 Consideration shall be given to appropriate matters, including.
--- system component compatibility, including hardware and software;
--- User interface, including command language, warnings and error messages;
--- Accuracy of translation of text used in user interface and instruction manuals;
--- Data protection against intentional or unintentional human factors;
--- risk (benefit) criteria;
---third-party software.
52.20.4.3.1.7 Hazard identification methods appropriate to the stages of the development life cycle shall be used.
52.20.4.3.1.8 The methods used (eg fault tree analysis, failure mode and effect analysis) shall be filed in the risk management file.
52.20.4.3.1.9 The results of the method application shall be filed in the risk management file.
52.204.3.1.10 Each identified hazard and cause shall be recorded in the risk management summary.
Check compliance by checking risk management documents.
52.204.3.2 Risk Estimation
52.20.4.3.2.1 For each identified hazard, the risk shall be estimated.
52.20.4.3.2.2 Risk estimates shall be based on the likelihood of each hazard and/or the severity of the consequences of each hazard
estimate.
52.20.4.3.2.3 The classification of severity levels shall be recorded in the risk management file.
52.20.3.4.2.4 The estimation method of the possibility of occurrence of hazards can be either quantitative or qualitative and should be recorded in risk management
Document.
52.20.4.3.2.5 For each hazard, the estimated risk shall be recorded in the risk management summary.
Check compliance by checking risk management documents.
52.204.4 Risk Control
52.204.4.1 Risks shall be controlled to reduce the estimated risk of each identified hazard to an acceptable level.
52.20.4.2 If the risk is less than or equal to the maximum allowable risk, and the risk has been reduced as reasonably and practicably as possible, then
Is acceptable.
52.204.4.3 The risk control method shall reduce the possibility of occurrence of the hazard, the severity of the hazard, or both.
The possibility of the correct implementation of risk reduction measures shall be stated in a qualitative or quantitative manner; see Appendix CCC (informative).
52.20.4.4 Risk control methods should be oriented towards the cause of the hazard (for example, by reducing its likelihood) or when the cause of the hazard appears
Protection measures, or both, have the following priorities.
--- inherent safety design;
--- Protective measures include alerts;
--- Sufficient user information about residual risk.
52.204.4.5 The various requirements for controlling risk shall be documented or referenced directly in the risk management profile.
52.20.4.6 The evaluation of the effectiveness of risk control shall be recorded in the risk management summary.
Check compliance by checking risk management documents.
52.205 Personnel qualifications
According to the requirements of 6.2.2 in GB/T.1990-2000, the design and modification of the programmable medical electrical system shall be regarded as a specified
task.
Check compliance by checking relevant documents.
52.206 Requirements Specification
52.206.1 There shall be requirements specifications for programmable medical electrical systems and their corresponding subsystems (such as programmable electronic subsystems).
Note. An example of a programmable medical electrical system architecture is given in Appendix EEE (informative).
52.206.2 The requirements specification shall detail risk-related functions. Includes functions to control risks arising from.
a) causes caused by environmental conditions;
b) causes caused by other aspects of the programmable medical electrical system;
c) possible failures.
52.206.3 The requirements specification shall include information necessary to ensure that risk control measures have successfully reduced the identified risks.
52.207 Architecture
52.207.1 The architecture shall meet requirements specifications.
52.207.2 The architecture of the programmable medical electrical system and its subsystems shall be specified.
52.207.3 Specifications for programming medical electrical systems and their subsystem architectures shall be implemented by reducing
Performance or the severity of the hazard, or both, to reduce the risk control requirements.
52.207.4 In order to reduce the possibility of hazards, they should be used where appropriate in the architecture specification.
a) high reliability components;
b) fail-safe function;
c) redundancy;
d) diversity;
e) protection design;
f) Limitation of potential hazards, such as limiting the available output energy and/or by limiting the travel of the actuator.
52.207.5 Architecture specifications shall take into account the following factors.
a) the configuration of risk control measures on programmable medical electrical system components and subsystems;
Note. Subsystems and components include. sensors, actuators, programmable electronic subsystems, and interfaces.
b) failure modes and effects of components;
c) failure for general reasons;
d) systemic failure;
e) test interval, test duration and test diagnostic range;
f) maintainability;
g) Protection against intentional or unintentional human factors.
52.2008 Design and implementation
52.208.1 The design shall be appropriately decomposed into subsystems where appropriate. Each subsystem shall have design and test specifications.
52.208.2 Descriptive data on the design environment shall be included in the risk management document.
Note. For examples of design environment elements, see Appendix DDD (informative).
52.209 Verification
52.209.1 The realization of safety requirements shall be verified.
52.209.2 A verification plan shall be developed to explain how the safety requirements are verified at each stage of the development life cycle. The plan should include.
a) selection and documentation of validated strategies, activities and technologies;
b) the selection and use of verification tools;
c) Verification coverage criteria.
Note. Examples of methods and techniques are.
--- Walk-up and inspection;
--- Static (dynamic) analysis;
--- White box (black box) test.
52.209.3 Verification shall be performed in accordance with the verification plan. The results of the verification activities shall be documented, analyzed and evaluated.
52.209.4 The summary of risk management shall include verification of verification methods, techniques and results.
52.210 Confirmation
52.2.10.1 The safety of the programmable medical electrical system shall be verified under the conditions of intended use.
52.100.2 A validation plan shall be established to demonstrate that the correct security requirements have been achieved.
52.210.3 Confirmation shall be carried out in accordance with the confirmation plan. The results of the validation activities shall be documented, analyzed and evaluated.
52.210.4 The team leader responsible for implementation validation shall be independent of the development team.
52.210.5 Confirm that the professional relevance of team members and design team members shall be recorded in the risk management file.
52.210.6 Design team members cannot assume responsibility for the confirmation of their designs.
52.210.7 The risk management document shall include the method of confirmation and proof of results.
Check compliance by checking risk management documents.
......
Source: Above contents are excerpted from the PDF -- translated/reviewed by: www.chinesestandard.net / Wayne Zheng et al.
|