AAMI 62304 2006
$140.32
ANSI/AAMI/IEC 62304:2006 & A1:2016 – ANSI/AAMI/IEC 62304:2006 & A1:2016 (Consolidated Text)Medical device software-Software life cycle processes
| Published By | Publication Date | Number of Pages |
| AAMI | 2006 | 82 |
This standard applies to the development and maintenance of MEDICAL DEVICE SOFTWARE when software is itself a MEDICAL DEVICE or when software is an embedded or integral part of the final MEDICAL DEVICE. This standard describes PROCESSES that are intended to be applied to software which executes on a processor or which is executed by other software (for example an interpreter) which executes on a processor.
PDF Catalog
| PDF Pages | PDF Title |
|---|---|
| 1 | ANSI/AAMI/IEC 62304:2006 and A1:2016 (Consolidated Text); Medical device software—Software life cycle processes |
| 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 | Foreword |
| 11 | Introduction |
| 14 | Introduction to Amendment 1 |
| 15 | Medical device software—Software life cycle processes Scope 1.1 * Purpose 1.2 * Field of application 1.3 Relationship to other standards 1.4 Compliance |
| 16 | 2 * Normative references 3 * Terms and definitions |
| 21 | 4 * General requirements 4.1 * Quality management system 4.2 * Risk management 4.3 * Software safety classification |
| 22 | Figure 3 – Assigning software safety classificationThe |
| 23 | 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 |
| 24 | 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 5.1.4 Software development standards, methods and tools planning |
| 25 | 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 |
| 26 | 5.1.10 Supporting items to be controlled 5.1.11 Software configuration item control before verification 5.1.12 Identification and avoidance of common software defects 5.2 * Software requirements analysis 5.2.1 Define and document software requirements from system requirements 5.2.2 Software requirements content |
| 27 | 5.2.3 Include risk control measures in software requirements 5.2.4 Re-evaluate medical device risk analysis |
| 28 | 5.2.5 Update 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 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 |
| 29 | 5.4 * Software detailed design 5.4.1 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 5.5 * Software unit implementation 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 |
| 30 | 5.5.5 Software unit verification 5.6 * Software integration and integration testing 5.6.1 Integrate software units 5.6.2 Verify software integration 5.6.3 Software integration testing 5.6.4 Software integration testing content 5.6.5 Evaluate software integration test procedures 5.6.6 Conduct regression tests |
| 31 | 5.6.7 Integration test record contents 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 Evaluate software system testing |
| 32 | 5.7.5 software system test record contents 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 5.8.8 Assure reliable delivery of released software |
| 33 | 6 Software maintenance process 6.1 * Establish software maintenance plan 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 |
| 34 | 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 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 |
| 35 | 7.1.3 Evaluate published soup anomaly lists 7.1.4 Document potential causes 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 |
| 36 | 7.3.3 Document traceability 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 |
| 37 | 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 9.2 Investigate the problem |
| 38 | 9.3 Advise relevant parties 9.4 Use change control process 9.5 Maintain records 9.6 Analyse problems for trends 9.7 Verify software problem resolution 9.8 Test documentation contents |
| 39 | Annex A (informative) Rationale for the requirements of this standard A.1 Rationale |
| 40 | A.2 Summary of requirements by class |
| 42 | Annex B (informative) Guidance on the provisions of this standard B.1 Scope B.1.1 Purpose |
| 43 | Table B.1 – Development (model) strategies as defined in ISO/IEC 12207 B.1.2 Field of application B.2 Normative references |
| 44 | B.3 Terms and definitions B.4 General requirements B.4.1 Quality management system B.4.2 Risk management B.4.3 Software safety classification |
| 45 | Figure B.2 – Pictorial representation of the relationship of HAZARD, sequence of events, HAZARDOUSSITUATION, and HARM – from ISO 14971:2007 Annex E |
| 47 | Figure B.1 – Example of partitioning of SOFTWARE ITEMS B.4.4 Legacy software |
| 49 | B.5 Software development process B.5.1 Software development planning |
| 50 | B.5.2 Software requirements analysis B.5.3 Software architectural design |
| 51 | B.5.4 Software detailed design |
| 52 | B.5.5 Software unit implementation and verification B.5.6 Software integration and integration testing |
| 53 | B.5.7 Software system testing B.5.8 Software release B.6 Software maintenance process B.6.1 Establish software maintenance plan |
| 54 | B.6.2 Problem and modification analysis B.6.3 Modification implementation |
| 55 | B.7 Software risk management process B.7.1 Analysis of software contributing to hazardous situations B.8 Software configuration management process |
| 56 | B.8.1 Configuration identification B.8.2 Change control B.8.3 Configuration status accounting B.9 Software problem resolution process |
| 57 | Annex C (informative) Relationship to other standards C.1 General Figure C.1 – Relationship of key MEDICAL DEVICE standards to IEC 62304 |
| 58 | C.2 Relationship to ISO 13485 Table C.1 – Relationship to ISO 13485:2003 C.3 Relationship to ISO 14971 |
| 59 | Table C.2 – Relationship to ISO 14971:2007 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 |
| 60 | Figure C.2 – Software as part of the V-model C.4.3 Development process C.4.4 Maintenance process C.4.5 Other processes |
| 61 | C.4.6 Coverage of PEMS requirements in IEC 60601-1:2005 + IEC 606011:2005 /AMD1:2012 |
| 62 | Table C.3 – Relationship to IEC 60601-1 |
| 67 | C.4.7 Relationship to requirements in IEC 60601-1-4 C.5 Relationship to IEC 61010-1 |
| 68 | Figure C.3 – Application of IEC 62304 with IEC 61010-1 |
| 69 | C.6 Relationship to ISO/IEC 12207 |
| 70 | Table C.5 – Relationship to ISO/IEC 12207:2008 |
| 74 | C.7 Relationship to IEC 61508 |
| 76 | 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 |
| 77 | Table D.1 – Checklist for small companies without a certified QMS |
| 78 | Bibliography |
| 80 | Index of defined terms |
Related products
-
AAMI TIR80002 3 2016
AAMI/IEC TIR80002-3: 2016 – Technical Information Report Medical Device Software – Part 3: Process reference…
-
AAMI 62304 2006 RL(Redline)
ANSI/AAMI/IEC 62304: 2006 & A1:2016 (Redline) – Medical device software-Software life cycle processes Published By…
-
AAMI TIR80002 1 2009
AAMI/IEC TIR80002-1:2009 – Medical device software – Part 1: Guidance on the application of ISO…
