IEC62304实用模板Word格式文档下载.docx

1、Standard:EN 62304:2006 Medical devicesMedical device software-Software life cycle processes结 论：Result:符合EN 62304:2006要求编写piled by:（Name/Title/Dept.）日期Date:评审Reviewed by 批准Approved by:EN 62304：2006的应用软件预期目的和用途识别的危害的可能来源与处理医疗器械数据有关的危害判定和合理可预见的危害已进展的安全性标准验证已进展的风险控制方法软件安全性级别： A级 B级 C级确定软件安全性级别的依据：IEC 62

2、304:2006软件安全性级别要求章和条A级B级C级第四章 全部要求X5.6 全部要求5.7 全部要求6.1 6.1 6.3 全部要求7.1 全部要求7.2 全部要求7.3 全部要求第8章 全部要求第9章 全部要求2006Possible test case verdicts:- test case does not apply to the test object:N/A- test object does meet the requirement :Pass （P）- test object does not meet the requirement:Fail （F）4General re

3、quirementsQuality management systemThe MANUFACTURER of MEDICAL DEVICE SOFTWARE shall demonstrate the ability to provideMEDICAL DEVICE SOFTWARE that consistently meets customer requirements and applicableregulatory requirements.RISK MANAGEMENTThe MANUFACTURER shall apply a RISK MANAGEMENT PROCESS ply

4、ing with ISO 14971.Software safety classificationa） The MANUFACTURER shall assign to each SOFTWARE SYSTEM a software safety class （A, B, orC） according to the possible effects on the patient, operator, or other people resulting froma HAZARD to which the SOFTWARE SYSTEM can contribute.The software sa

5、fety classes shall initially be assigned based on severity as follows:Class A: No injury or damage to health is possibleClass B: Non-SERIOUS INJURY is possibleClass C: Death or SERIOUS INJURY is possibleIf the HAZARD could arise from a failure of the SOFTWARE SYSTEM to behave as specified, theprobab

6、ility of such failure shall be assumed to be 100 percent.If the RISK of death or SERIOUS INJURY arising from a software failure is subsequentlyreduced to an acceptable level （as defined by ISO 14971） by a hardware RISK CONTROLmeasure, either by reducing the consequences of the failure or by reducing

7、 the probabilityof death or SERIOUS INJURY arising from that failure, the software safety classification maybe reduced from C to B; and if the RISK of non-SERIOUS INJURY arising from a softwarefailure is similarly reduced to an acceptable level by a hardware RISK CONTROL measure, thesoftware safety

8、classification may be reduced from B to A.b） The MANUFACTURER shall assign to each SOFTWARE SYSTEM that contributes to theimplementation of a RISK CONTROL measure a software safety class based on the possibleeffects of the HAZARD that the RISK CONTROL measure is controlling.c） The MANUFACTURER shall

9、 document the software safety class assigned to each SOFTWARESYSTEM in the RISK MANAGEMENT FILE.d） When a SOFTWARE SYSTEM is deposed into SOFTWARE ITEMS, and when a SOFTWAREITEM is deposed into further SOFTWARE ITEMS, such SOFTWARE ITEMS shall inherit thesoftware safety classification of the origina

10、l SOFTWARE ITEM （or SOFTWARE SYSTEM） unlessthe MANUFACTURER documents a rationale for classification into a different software safetyclass. Such a rationale shall explain how the new SOFTWARE ITEMS are segregated so thatthey may be classified separately.e） The MANUFACTURER shall document the softwar

11、e safety class of each SOFTWARE ITEM if thatclass is different from the class of the SOFTWARE ITEM from which it was created bydeposition.f） For pliance with this standard, wherever a PROCESS is required for SOFTWARE ITEMS of aspecific classification and the PROCESS is necessarily applied to a group

12、 of SOFTWAREITEMS, the MANUFACTURER shall use the PROCESSES and TASKS which are required by theclassification of the highest-classified SOFTWARE ITEM in the group unless theMANUFACTURER documents in the RISK MANAGEMENT FILE a rationale for using a lowerclassification.g） For each SOFTWARE SYSTEM, unt

13、il a software safety class is assigned, Class Crequirements shall apply.5Software development PROCESSSoftware development planningSoftware development planThe MANUFACTURER shall establish a software development plan （or plans） for conducting theACTIVITIES of the software development PROCESS appropri

14、ate to the scope, magnitude, andsoftware safety classifications of the SOFTWARE SYSTEM to be developed. The sOFTWAREDEVELOPMENT LIFE CYCLE MODEL shall either be fully defined or be referenced in the plan （orplans）. The plan shall address the following:a） the PROCESSES to be used in the development o

15、f the SOFTWARE SYSTEM （see Note 4）;b） the DELIVERABLES （includes documentation） of the ACTIVITIES and TASKS;c） TRACEABILITY between SYSTEM requirements, software requirements, SOFTWARE SYSTEMtest, and RISK CONTROL measures implemented in software;d） software configuration and change management, incl

16、uding SOUP CONFIGURATION ITEMS andsoftware used to support development; ande） software problem resolution for handling problems detected in the SOFTWARE PRODUCTS,DELIVERABLES and ACTIVITIES at each stage of the life cycle.Class A, B, CKeep software development plan updatedThe MANUFACTURER shall upda

17、te the plan as development proceeds as appropriate. Software development plan reference to SYSTEM design and developmenta） As inputs for software development, SYSTEM requirements shall be referenced in thesoftware development plan by the MANUFACTURER.b） The MANUFACTURER shall include or reference in

18、 the software development plan proceduresfor coordinating the software development and the design and development validationnecessary to satisfy 4.1.Software development standards, methods and tools planningThe MANUFACTURER shall include or reference in the software development plan:a） standards,b）

19、methods, andc） toolsassociated with the development of SOFTWARE ITEMS of class C. Class CSoftware integration and integration testing planningThe MANUFACTURER shall include or reference in the software development plan, a plan tointegrate the SOFTWARE ITEMS （including SOUP） and perform testing durin

20、g integration. Class B,CSoftware VERIFICATION planningThe MANUFACTURER shall include or reference in the software development plan the followingVERIFICATION information:a） DELIVERABLES requiring VERIFICATION;b） the required VERIFICATION TASKS for each life cycle ACTIVITY;c） milestones at which the D

21、ELIVERABLES are VERIFIED;d） the acceptance criteria for VERIFICATION of the DELIVERABLES.Software RISK MANAGEMENT planningconduct the ACTIVITIES and TASKS of the software RISK MANAGEMENT PROCESS, including themanagement of RISKS relating to SOUP. Class A, B, CDocumentation planningThe MANUFACTURER s

22、hall include or reference in the software development plan informationabout the documents to be produced during the software development life cycle. For eachidentified document or type of document the following information shall be included orreferenced:a） title, name or naming convention;b） purpose

23、;c） intended audience of document;d） procedures and responsibilities for development, review, approval and modification.Software configuration management planningThe MANUFACTURER shall include or reference software configuration management informationin the software development plan. The software co

24、nfiguration management information shallinclude or reference:a） the classes, types, categories or lists of items to be controlled;b） the software configuration management ACTIVITIES and TASKS;c） the organization（s） responsible for performing software configuration management andACTIVITIES;d） their r

25、elationship with other organizations, such as software development or maintenance;e） when the items are to be placed under configuration control;f） when the problem resolution PROCESS is to be used.Supporting items to be controlledThe items to be controlled shall include tools, items or settings, us

26、ed to develop the MEDICALDEVICE SOFTWARE, which could impact the MEDICAL DEVICE SOFTWARE. Class B, CSoftware CONFIGURATION ITEM control before VERIFICATIONThe MANUFACTURER shall plan to place CONFIGURATION ITEMS under documented configurationmanagement control before they are VERIFIED. Class B, CSof

27、tware requirements analysisDefine and document software requirements from SYSTEM requirementsFor each SOFTWARE SYSTEM of the MEDICAL DEVICE, the MANUFACTURER shall define anddocument SOFTWARE SYSTEM requirements from the SYSTEM level requirements. Class A, B, CSoftware requirements contentAs appropr

28、iate to the MEDICAL DEVICE SOFTWARE, the MANUFACTURER shall include in thesoftware requirements:a） functional and capability requirements;b） SOFTWARE SYSTEM inputs and outputs;c） interfaces between the SOFTWARE SYSTEM and other SYSTEMS;d） software-driven alarms, warnings, and operator messages;e） SECURITY requirements;f） usability engineering requirements that are sensitive to human errors and training;g） data definit