Solution Briefs and Overviews

Developing Reliable Medical Devices with Confidence

Issue link: https://resources.windriver.com/i/1170189

Contents of this Issue

Navigation

Page 1 of 2

2 GAINING APPROVAL UNDER THE IEC 62304 STANDARD The IEC 62304 standard provides a set of best practices for companies making medical devices, to ensure the safety and security of the software used in these devices. To release medical equipment to market, OEMs and medical device developers must meet requirements based on one of three risk levels: Class A (no risk), Class B (low to moderate potential harm), and Class C (risk of serious injury or death). VxWorks Cert Edition is a medical-grade OS that is approved for use in devices up to and including Class C. Using VxWorks Cert Edition as a component in a medical device reduces, or in some cases even eliminates, the need for manufacturers to validate the OS using software of unknown provenance (SOUP) to ensure IEC 62304 compliance. If the software components being used in a device cannot be traced back to their origins, this injects an element of risk into the device design that must be resolved by the manufacturer. Integrating VxWorks Cert Edition into a medical device represents a significant step toward achieving the necessary regulatory approval to compete successfully in this market sector. In such cases, additional testing for the OS is not required as part of the approval process. ENHANCING THE DEVELOPMENT PROCESSES Efficiency and improved productivity in the software engineering pipeline are achieved more easily with an approach that includes preplanning to assess the requirements for regulatory approval. Figure 1 shows the activities that are included in the IEC 62304 requirements at each class level. The safety classifications (Class A, B, and C) that apply to medical device software have been amended in the latest release of IEC 62304 to place stricter requirements on the software components of a solution. The earlier version of the standard, based solely on the degree of harm, allowed hardware-based risk mitigation— external to the software—to downgrade the classification (for example, from C to B or from B to A). Now the decision tree for assessing harm still evaluates external hardware mitigation, but it also determines whether a software failure poses a unique risk by itself. Customer Needs Customer Needs Satisfied Activities Outside the Scope of This Standard System Development Activities (Including Risk Management) 7 Software Risk Management 8 Software Configuration Management 9 Software Problem Resolution 5.1 Software Development Planning 5.2 Software Requirements Analysis 5.3 Software Architectural Design 5.4 Software Detailed Design 5.5 Software Unit Implementation and Verification 5.6 Software Integration and Integration Testing 5.7 Software System Testing 5.8 Software Release Figure 1. Processes involved in the software development of medical devices as per IEC 62304:2006+AMD1:2015 WIND RIVER SOLUTION BRIEF

Articles in this issue

view archives of Solution Briefs and Overviews - Developing Reliable Medical Devices with Confidence