AAMI 62304 2006 RL(Redline)
$162.84
ANSI/AAMI/IEC 62304: 2006 & A1:2016 (Redline) – Medical device software-Software life cycle processes
Published By | Publication Date | Number of Pages |
AAMI | 2006 | 98 |
PDF Catalog
PDF Pages | PDF Title |
---|---|
1 | American National Standard ANSI/AAMI/IEC 62304:2006 & A1:2016 (Redline Format) |
2 | Objectives and uses of AAMI standards and recommended practices |
3 | Title page |
4 | AAMI Standard Copyright information |
5 | Contents |
6 | Glossary of equivalent standards |
7 | Committee representation |
9 | Background of ANSI/AAMI adoption of IEC 62304:2006 |
10 | Background of ANSI/AAMI adoption of IEC 62304:2006 AMD1 |
11 | Foreword |
13 | Introduction |
17 | 1 Scope 1.1 * Purpose 1.2 * Field of application |
18 | 1.3 Relationship to other standards 1.4 Compliance 2 * Normative references 3 * Terms and definitions |
24 | 4 * General requirements 4.1 * Quality management system 4.2 * Risk management 4.3 * Software safety classification |
26 | 4.4 * Legacy software 4.4.1 General 4.4.2 Risk Management Activities 4.4.3 Gap analysis 4.4.4 Gap closure activities |
27 | 4.4.5 Rationale for use of legacy software 5 Software development process 5.1 * Software development planning 5.1.1 Software development plan 5.1.2 Keep software development plan updated 5.1.3 Software development plan reference to system design and development |
28 | 5.1.4 Software development standards, methods and tools planning 5.1.5 Software integration and integration testing planning 5.1.6 Software verification planning 5.1.7 Software risk management planning 5.1.8 Documentation planning 5.1.9 Software configuration management planning |
29 | 5.1.10 Supporting items to be controlled 5.1.11 Software configuration item control before verification 5.2 * Software requirements analysis 5.2.1 Define and document software requirements from system requirements 5.2.2 Software requirements content |
31 | 5.2.3 Include risk control measures in software requirements 5.2.4 Re-evaluate medical device risk analysis 5.2.5 Update system requirements 5.2.6 Verify software requirements 5.3 * Software architectural design 5.3.1 Transform software requirements into an architecture 5.3.2 Develop an architecture for the interfaces of software items 5.3.3 Specify functional and performance requirements of soup item |
32 | 5.3.4 Specify system hardware and software required by soup item 5.3.5 Identify segregation necessary for risk control 5.3.6 Verify software architecture 5.4 * Software detailed design 5.4.1 Refine software architecture Subdivide software into software units 5.4.2 Develop detailed design for each software unit 5.4.3 Develop detailed design for interfaces 5.4.4 Verify detailed design |
33 | 5.5 * Software unit implementation and verification 5.5.1 Implement each software unit 5.5.2 Establish software unit verification process 5.5.3 Software unit acceptance criteria 5.5.4 Additional software unit acceptance criteria 5.5.5 Software unit verification 5.6 * Software integration and integration testing 5.6.1 Integrate software units |
34 | 5.6.2 Verify software integration 5.6.3 Test integrated Software integration testing 5.6.4 Software integration testing content 5.6.5 Verify Evaluate software integration test procedures 5.6.6 Conduct regression tests 5.6.7 Integration test record contents |
35 | 5.6.8 Use software problem resolution process 5.7 * Software system testing 5.7.1 Establish tests for software requirements 5.7.2 Use software problem resolution process 5.7.3 Retest after changes 5.7.4 Verify Evaluate software system testing 5.7.5 software system test record contents |
36 | 5.8 * Software release for utilization at a system level 5.8.1 Ensure software verification is complete 5.8.2 Document known residual anomalies 5.8.3 Evaluate known residual anomalies 5.8.4 Document released versions 5.8.5 Document how released software was created 5.8.6 Ensure activities and tasks are complete 5.8.7 Archive software |
37 | 5.8.8 Assure repeatability of software release reliable delivery of released software 6 Software maintenance process 6.1 * Establish software maintenance plan |
38 | 6.2 * Problem and modification analysis 6.2.1 Document and evaluate feedback 6.2.1.1 Monitor feedback 6.2.1.2 Document and evaluate feedback 6.2.1.3 Evaluate problem report’s affects on safety 6.2.2 Use software problem resolution process 6.2.3 Analyse change requests 6.2.4 change request approval 6.2.5 Communicate to users and regulators |
39 | 6.3 * Modification implementation 6.3.1 Use established process to implement modification 6.3.2 Re-release modified software system 7 * Software risk management process 7.1 * Analysis of software contributing to hazardous situations 7.1.1 Identify software items that could contribute to a hazardous situation 7.1.2 Identify potential causes of contribution to a hazardous situation 7.1.3 Evaluate published soup anomaly lists 7.1.4 Document potential causes |
40 | 1.1.1 Document sequences of events 7.2 Risk control measures 7.2.1 Define risk control measures 7.2.2 Risk control measures implemented in software 7.3 Verification of risk control measures 7.3.1 Verify risk control measures 7.3.2 Document any new sequences of events 7.3.3 Document traceability |
41 | 7.4 Risk management of software changes 7.4.1 Analyse changes to medical device software with respect to safety 7.4.2 Analyse impact of software changes on existing risk control measures 7.4.3 Perform risk management activities based on analyses 8 * Software configuration management process 8.1 * Configuration identification 8.1.1 Establish means to identify configuration items 8.1.2 Identify soup |
42 | 8.1.3 Identify system configuration documentation 8.2 * Change control 8.2.1 Approve change requests 8.2.2 Implement changes 8.2.3 Verify changes 8.2.4 Provide means for traceability of change 8.3 * Configuration status accounting 9 * Software problem resolution process 9.1 Prepare problem reports |
43 | 9.2 Investigate the problem 9.3 Advise relevant parties 9.4 Use change control process 9.5 Maintain records 9.6 Analyse problems for trends |
44 | 9.7 Verify software problem resolution 9.8 Test documentation contents |
45 | Annex A (informative) Rationale for the requirements of this standard A.1 Rationale |
46 | A.2 Summary of requirements by class |
48 | Annex B (informative) Guidance on the provisions of this standard B.1 Scope B.1.1 Purpose |
49 | B.1.2 Field of application |
50 | B.2 Normative references B.3 Terms and definitions B.4 General requirements B.4.1 Quality management system B.4.2 Risk management |
51 | B.4.3 Software safety classification |
56 | B.5 Software development process B.5.1 Software development planning |
57 | B.5.2 Software requirements analysis |
58 | B.5.3 Software architectural design B.5.4 Software detailed design |
59 | B.5.5 Software unit implementation and verification B.5.6 Software integration and integration testing |
60 | B.5.7 Software system testing |
61 | B.5.8 Software release B.6 Software maintenance process B.6.1 Establish software maintenance plan B.6.2 Problem and modification analysis |
62 | B.6.3 Modification implementation B.7 Software risk management process |
63 | B.7.1 Analysis of software contributing to hazardous situations B.8 Software configuration management process B.8.1 Configuration identification B.8.2 Change control |
64 | B.8.3 Configuration status accounting B.9 Software problem resolution process |
65 | Annex C (informative) Relationship to other standards C.1 General |
67 | C.2 Relationship to ISO 13485 C.3 Relationship to ISO 14971 |
68 | C.4 Relationship to PEMS requirements of IEC 60601-1:2005 + IEC 606011:2005/AMD1:2012 C.4.1 General C.4.2 Software relationship to pems development |
69 | C.4.3 Development process C.4.4 Maintenance process C.4.5 Other processes |
70 | C.4.6 Coverage of PEMS requirements in IEC 60601-1:2005 +IEC 606011:2005 /AMD1:2012 |
76 | C.4.7 Relationship to requirements in IEC 60601-1-4 |
78 | C.5 Relationship to IEC 61010-1 |
81 | C.6 Relationship to ISO/IEC 12207 |
91 | C.7 Relationship to IEC 61508 |
93 | Annex D (informative) Implementation D.1 Introduction D.2 Quality management system D.3 Evaluate quality management processes D.4 Integrating requirements of this standard into the manufacturer’s quality management processes D.5 Checklist for small manufacturers without a certified QMS |
95 | Bibliography |
97 | Index of defined terms |