figure 1) that addresses the specific software development requirements from relevant regulatory bodies, standards, customer expectations, and integrates those constraints with a SPI framework. The proposed SPI framework will be based on identifiable and relevant components of existing SPI models, such as ISO/IEC15504 (SPICE) and CMMI [5]. The model will be flexible in that relevant elements of the SPI framework may be adopted as required to provide the most significant benefit to the business. The major process improvement frameworks that currently exist, namely ISO/IEC15004 (SPICE) and CMMI, do not address regulatory requirements of the medical device industry. The US Food and Drug Administration (FDA) and the European Medical Device Directives (MDD) are the regulatory standards that control the design, development, manufacturing and support of products within the medical device industry. 5. Project Outline In order to deliver an endorsed framework it was essential that a steering group was formed with members from various medical device companies and a notified body with experience in auditing medical device companies. The involvement of medical device companies also adds an ownership element to the model and should improve its acceptance and implementation within each company. The software development model will cover the complete lifecycle, defined by default, as the in Figure 2. No restriction will be made on the development life cycle processes undertaken by individual companies, although it is understood that companies within the medical device sector typically implement this V-Model. The model will be expanded to incorporate applicable aspects of software improvement programs such as ISO/IEC15504 (SPICE) in addition to checking that all applicable standards and regulations are adhered to in a seamless manner and are focused upon software process improvement. The framework will also ensure that developed, reused or off-the-shelf [6] software satisfies functional, operational and regulatory requirements
throughout the system lifecycle. As each stage of the life cycle can be performed using various methodologies and project management processes, the model will be flexible to support the implementation and integration of preferred methodologies into the framework. Figure 2: Software lifecycle V 6. Design The framework will provide a software development roadmap, which complies with the regulatory guidance criteria, while introducing best practice techniques and methodologies that can be selected as required. For example a risk management process can adopt a Failure Mode and Effects Analysis (FMEA) method of identifying, mitigating and tracking risk and hazard issues. Also the continuous management of verification and validation testing can be controlled and planned under a structured Test Process Improvement (TPI) model. The framework will provide a means of assessing software engineering capability in twelve areas that have been defined by the FDA [7] as: Level of Concern Software Description Device Hazard and Risk Analysis Software Requirements Specification Architecture Design Design Specifications Requirements Traceability Analysis Development Validation, Verification and Testing [8] Revision Level History Unresolved Anomalies Release Version Number To ensure compliance whilst also achieving software process improvement the following six software process have been identified as areas to be focused upon as a mapping can be made from these process areas to the twelve areas listed above. Requirements Management Risk Management Project Management Configuration Management Verification, Validation and Testing Software Design and Development The model will help companies to measure their organisational capability and to track progression and achievements in each of the six process areas and against process capability levels defined in ISO/IEC 15504-2 [16]. 7. Assessment framework
The assessment framework will provide a method for the assessment of software processes in medical device organisations. The framework will include an assessment model that will provide a structured approach for assessment and that may be used by organisations involved in the development, maintenance and support of software with the following purposes: Understanding the of a company’s own processes for process improvement; Determining the capability of a company’s own processes for a particular contract; Determining the capability of another organisation’s processes for a particular contract. The assessment model will include coverage of all associated medical device regulatory standards. The project will take a similar lead in the approach to defining the assessment model based on SPICE for Space (S4S) in the space sector, and AutomotiveSPICE in the automotive sector that have adapted the ISO/IEC 15504 assessment model to applicable domain standards. Additionally, the outcome will have similarities to the Capability Assessment Tool [10] that was developed by the Office of Government Commerce, in that it helps an organisation to measure organisational capability and to track progression and achievement in key process areas (with a mapping back to the twelve FDA key areas). The framework will not provide requirements but rather guidelines and recommendations and ensure it endorses the essence of the SPICE and CMMI frameworks. 7.1. Contents of the framework The contents of the framework will include a description of the following: Introduction to the framework; Intended audience and implementation strategy; Software Development Roadmap - a suggested step-by-step guide to developing software including: Life cycle development models and milestones, Roadmap checklists, Recommended best practices; Architecture consisting of: An assessment model, An assessment method, Assessment activities; Process assessment and improvement concepts Process improvement, Process capability determination, Compliance with medical device regulations; 7.2. Software development roadmap Of key importance to medical device companies is a model that identifies the major software development activities and indicates how they
The capability section is introduced by listing the capability scale against which each process is measured. The capability scale will be based upon ISO/IEC 15504-2 capability scales. 7.3.2. Process Assessment activities. A medical device software process assessment will consist of the following activities: Initiation; Planning; Briefing; Information and metrics acquisition; Information and metrics validation; Process rating; Reporting and inputs to the risk management process. A detailed breakdown of each activity into tasks will be described in the framework. Each process included in the assessment will be assessed on the basis of available evidence. The evidence may be gathered using interview, inspecting organisational documents or analysing metrics. The information collected for each process area will meet assessment objectives and scope. Information that supports a particular process rating will be recorded and maintained as evidence to substantiate the ratings and to verify compliance with the requirements. 7.3.3. Risk management. The framework will include a last important step “Reporting and providing inputs to the Risk Management Process”. The risk management process area is both a process area and the step of the assessment activities, as it is important that risk management is assigned a separate process area and that issues found in other process areas are also reported into the risk management process. This is particularly important to software developed or implemented in the medical device industry, as it is necessary to implement a risk management strategy throughout development. The risk management guidelines within the framework will acknowledge and endorse the ISO14971:2000 standard for “Application of Risk Management to Medical Devices”. In addition to ISO14971, best practice models such as FMEA for medical devices will be introduced to identify, assess, reduce, accept, and control software risks in a systematic proactive, comprehensive and cost effective manner taking into account the project’s technical and programmatic constraints. Risk identification within the framework will consist of 5 stages Stage 1 – Creation of a forum for risk assessment. Stage 2 – Systematically identify risk. The Software Risk Taxonomy checklist (that includes checklists relating to the regulatory standards and the SEI Software Risk Taxonomy