ID: Lorem ipsum dolor sit amet, consectetur.
The goal of this SOP is to define the software development process for software to be used in a medical device product. The intention of this SOP is to develop software products that are safe and perform as intended. The process is intended to follow the standards of IEC 62304 and IEC 62366 for the lifecycle of the software.
This SOP covers all medical device software products that are created by the manufacturer. Aspects of risk management and usability evaluation activities into the software development process. This SOP shall cover initial releases of software products as well as changes to existing software products according to SOP Change Management.
The following documents and standards are referenced in this SOP:
The software development process includes multiple stakeholders. Team members involved in the software development process should be trained on software SOPs and the quality management system that relates to them. The following functional groups have responsibility for the software development process.
The risk management process is described in SOP Risk Management.
The process diagram is from EN 62304:2006 and provides a basic process flow for software development. These process steps will be defined in more detail below. An additional step of software validation will be performed that isn't included in this diagram.
A diagram of the review process for the software development process is provided below. Not included are the inputs and outputs of each review stage which are covered in the sections below and in the individual documents listed in each stage.
Software development requires input from multiple stakeholders and should have qualified reviewers during the various testing and review cycles. The user needs will serve as design input for the software.
This section is applicable within the scope of this SOP only for Software only Medical Devices. For a system/hardware-software interaction based products, see SOP Design Control for User Needs.
User needs for a software product can be defined at a system level by identifying the overall functionality and performance requirements that the software must fulfill. This involves gathering input from various stakeholders, including end-users, business analysts, and technical experts, to ensure that the software meets the intended use and regulatory requirements. The system-level user needs should encompass high-level objectives such as usability, reliability, and safety, and should be detailed enough to guide the development of specific software requirements. These needs should be documented and reviewed to ensure they align with the strategic goals of the product and comply with relevant standards and regulations.
The software requirements are generated based on the user needs, the technical requirements, the intended use, and the user interface of the intended medical device or application. Software system define system requirements and subsystem requirements. For standalone software systems, subsystem requirements can be considered equivalent to the software requirements.
The software development and maintance plan is then created to provide an overview of the software development processes for the specific software product. The software plan shall contain the following information:
Software requirements are reviewed by following the checklist for Design Review. If the review is successful, move forward to the next step (Section 6.4). If it's not, the software requirements have to be updated and Stage 1 should be repeated.
Using software requirements and user needs, software architecture is designed to meet the needs of the specified product. For Software Risk Class C devices, a detailed design is also created. Software architecture and detailed design may need to be updated following testing or if new software requirements are needed. The end result should be that both the implementation and the documented software architecture are synchronized.
The software architecture should include the following information, as needed:
The Software of Unknown Provenance (SOUP) is documented in the SOUP List for the product and should be identified within the software architecture when critical to the software performance or safety. SOUPs should be managed according to the Software Development Plan.
Software verification and integration is performed according to the Software DDP. A software unit should be verified by code review or by automated unit tests. The verification ensures that the implemented software requirement has been adequately created and implemented. Software verification should be performed on a software unit level. Verification performed with automatic testing should be exported into a test report.
If the code review is successful, then the code can be considered feature complete and ready for software system testing (which occurs in stage 3).
The review of stage 2 is performed following code review and integration testing. The review is performed by completing the verification and integration activities outlined in section 5.4.2 and completing a design review. If the software architecture section of design review is successful, move forward to the next step (Section 6.5). If it's not, the software architecture needs to be updated and Stage 2 should be repeated.
A software system test plan is created according to the Software DDP. The software system test plan is used to test the software requirements and ensure that the software functions as intended at a system level. Software system tests should cover all aspects of the software requirements.
The software system test is executed and the software system test report is created as a result.
If any anomalies are detected during the software system testing, they are added to the list of known anomalies and/or entered as new software problems to be resolved according to SOP Software Problem Resolution. Any new risks that arise during system testing should be added to the risk assessment.
If the software system test is successful in that all acceptance criteria have been met, then all software requirements have been successfully implemented. Stage 3 review is complete if the List of Known Anomalies has been completed and the software system test report has been created and confirmed as successful according to the software requirements and acceptance criteria.
Software validation is confirmed using a summative usability evaluation according to SOP Usability Engineering. A usability evaluation plan is created to define what formative and summative usability activities should occur. The usability evaluation protocol is created in order to perform usability evaluation testing on the software user interface.
The list of hazardous situations and critical tasks are defined according to the SOP Usability Engineering. The usability evaluation protocol is performed and the results are documented in the Usability Evaluation Report.
The usability evaluation report is created and reviewed. If any new risks were identified during usability testing, they are added to the risk management file. If all critical tasks were successfully completed and the validation was considered successful, the software is considered validated and can continue into Stage 5. If the validation is not successful and other processes from stages 1-3 need to be repeated in order to ensure the software is validated, the software development process will repeat from that stage.
Software notes should be created to document the new features or updates to the software. Product registration should be performed according to the SOP Product Certification and Registration. The software release checklist (or product release checklist)should be reviewed and approved prior to any software release to ensure that all necessary steps have been completed and all required documentation have been created or updated.
Finally, the software is assigned required labeling and is provided alongside required Instructions for Use.
Once the regulatory requirements are met for the product, a product version release can be performed for the software.
Changes to the software are managed by the SOP Change Management and change requests result as input to the SOP Software Development and are implemented accordingly.
