Compass Health AI Software Development SOP PDF

Compass Health AI SOP: Software Development Position Name Role Signature Date Kevin Kennedy Engineering +BO Author Head Q...

Compass Health AI SOP: Software Development Position Name Role Signature Date Kevin Kennedy Engineering +BO Author Head QA/RA +BO Tenzin Yangzom Author James Baskin COO Approver +BO Document# QMS-SOP-0008 Revision History Version Date Description 1.0 03-Jan- Initial Release 2024 Document# QMS-SOP-0008 1 Introduction This document outlines the process and responsibilities for design and development of software products at Compass Health Inc. 1.1 Scope This procedure applies to all software developed at Compass Health for use in a medical device application. The SOP: Product Development Process describes the overall product development process, from early research activity through product launch and product end of life. The SOP: Software Development (this document) describes the software development activity performed during the 4 core product development phases, and breaks the “Development” phase into three stages to provide additional direction regarding the transition from implementation through verification and validation. This aligns with the requirements of IEC 62304. 2 Applicable and Reference Documents 2.1 Applicable Standards The following standards and regulations are intended to be met by this procedure:  FDA QSR § 820.30 Design Controls  ISO 13485:2016 Section 7.3 Design and Development  IEC 62304:2015 Medical Device Software – Software Life-cycle Processes 2.2 Reference Documents The following documents, templates and forms are referenced within this procedure and are related to the Product Development Process: Document Title Document Number Document# QMS-SOP-0008  SOP: Document Controls QMS-SOP-0002 SOP: Product Development QMS-SOP-0007 Process SOP: Risk Management QMS-SOP-0013 SOP: Change Control QMS-SOP-0014 3 Acronyms and Definitions Table 1: Acronyms Acronym Description I&T Integration and Test International Electrotechnical IEC Commission OS Operating System PDP Product Development Plan SDP Software Development Plan SOP Standard Operating Procedure Document# QMS-SOP-0008  SOUP Software of Unknown Provenance V&V Verification and Validation 4 Process Roles Table 2: Process Roles Role Description Report on the status of Software Development at regularly Project Manager scheduled reviews with Management Project Leader Provide final approval for process transitions Conduct the actual requirements definition, development, Engineers verification, and validation Review design stage. (Independent Reviewer is an individual(s) Independent who does not have direct responsibility for the design stage being Reviewer reviewed) 5 Software Development Process Software development at Compass Health comprises, at the highest level, the following activities:  Planning  Development Document# QMS-SOP-0008   Verification & Validation  Maintenance These activities occur continuously and iteratively. A software product is typically revised and updated over time. To support this, a product is effectively a collection of Releases, defined by Release activities and documentation. The primary development activities (e.g. requirements analysis, architecting, designing, implementation, integration, and testing) are performed. Compass applies the requirements in IEC 62304 in the context of these levels and the software safety classification. 5.1 Software Safety Classification One of the earliest activities in the software development process is safety classification. Per IEC 62304, software is classified as A, B, or C, based on the possible effects on the patient, operator, or other people resulting from a HAZARD to which the SOFTWARE SYSTEM can contribute. The software safety classes shall initially be assigned based on severity as follows:  Class A: No injury or damage to health is possible  Class B: NON-SERIOUS INJURY is possible  Class C: DEATH or SERIOUS INJURY is possible Classification is re-performed regularly throughout the development for any changes to design that could change the risk profile. The software class may be reduced from C to B, or from B to A if a non-software (hardware) measure exists to reduce the risk of the injury from software in that class to an acceptable level. For example, a robot that could experience a lethal joint run-away due to software failure, but strong physical hard-stops may make the risk of harm from such an occurrence impossible. Note: Though referenced below, Compass does not currently produce any Class C software, that is, software capable of causing death or serious injury. If the software safety classification activity for any future product results in a Class C, continued development under this SOP shall halt, and this SOP shall be reviewed and revised to encompass all the requirements for development of Class C software. Document# QMS-SOP-0008 5.2 Project / Product Level The Project / Product level (including the Release level below it) comprises all activities required to create a finished medical device software product, including all documentation required to provide evidence of compliance with regulatory and quality system requirements. 5.2.1 Planning The project level comprises primarily planning activities. Planning here begins with creation of the Software Development Plan (SDP) per Section 6.1. Top-level and system requirements are analyzed to inform:  definition of software requirements  identification of potential hazards  traceability and testability of requirements, and overall V&V strategies  security requirements  feasibility of design, operation, and maintenance  definition of software architecture, including external interfaces and workflows (class B & C). Further, high-level planning is performed with regards to distribution and maintenance. That is, how will the software product be delivered to customers, how will it be installed, and how will it be updated in future if required? These planning activities are continuously revisited as activities at the lower levels proceed, informing changes to requirements and architecture, development priorities, and resource/infrastructure needs. Backlog management and release planning is conducted at this level. 5.2.2 Detailed Design For safety class B and C software, architecture is refined at the project / product level down to the level of software units. For class C software only, detailed design of each software unit is performed, as well as detailed design of interfaces. Document# QMS-SOP-0008 5.2.3 Development No development activities occur at the Project / Product level. All development is performed at the Epic and Story levels. 5.2.4 Verification & Validation For class A and B software, no V&V activities occur at the Project / Product level. For class C software, the detailed design is verified for implementation of the architecture, and that it is free of conflict with the architecture. 5.2.5 Review Requirements levied on the software are reviewed by Product and Engineering personnel, as well as an Independent Reviewer, who does not have direct responsibility for the design stage to validate feasibility and appropriateness. This includes requirements arising out of regulatory and risk management activities. 5.2.6 Maintenance No Maintenance activities occur at the Project / Product level. 5.3 Release Level The Release level comprises all activities required to create a safe and effective software product, known as a Release. A software product is a collection of Releases developed and constructed over time. Release level activities are intended to create a complete and consistent set of functionality, including all documentation required to provide evidence of compliance with product, regulatory, and quality system requirements. Release Builds are what may be provided to customers to fulfill the product’s intended use. Document# QMS-SOP-0008 5.3.1 Planning At the Release level, planning encompasses evaluation of a build for suitability for Release, based on V&V results, identification of the history of changes since any prior release for the purpose of providing information to other business departments, and detailing any required documentation to be created for the specific release. 5.3.2 Development No development activities occur at the Release level. All development is performed at the Epic, Task and Story levels. 5.3.3 Verification & Validation All classes of software (A, B, and C) shall have documented the version being released. For class B and C software, V&V activities at the Release level include ensuring that System and I&T verifications are complete. Residual anomalies discovered at any level of testing, but not fixed through the software problem resolution process, shall be documented and evaluated against acceptable risks and fitness for the intended use of the software, or device as a whole. For class B and C software, the method for creating the released software shall be documented, including the procedure and environment used to create the release. For class B and C software, all activities and tasks shall be confirmed completed, including required documentation. This includes any updated training materials, marketing materials, labelling, and packaging, if any. 5.3.4 Review A formal review is held prior to execution of the actual release activities. This review encompasses the evaluations above, ensuring that the product to be released has been tested in its to-be-released form, that all supporting materials are in place, and that the product is prepared for sale or incorporation into a larger product for sale. 5.3.5 Maintenance Maintenance activities at the Release level include: Document# QMS-SOP-0008   Receiving, documenting, evaluating, resolving, and tracking feedback as software problem resolutions  Risk management evaluations for all software changes  Configuration management for all software changes  Evaluation of changes to SOUP  Passing information for regulators and users to the Marketing and Communications departments in order to satisfy regulatory requirements.  Compilation and archival of documentation pertaining to a specific release. 5.4 Unit level There are no software changes that are made at a unit level. As part of the product development process, features can be added that create design changes in the unit. These unit changes can involve changes to the firmware which have the potential to create a new requirement in the firmware. Firmware updates would be made at a release level to accommodate these changes. 5.4.1 Planning Planning is performed only at the Release level. 5.4.2 Development Development is performed only at the Release level. 5.4.3 Verification & Validation Verification and validation is performed only at the Release level. 5.5.4 Maintenance Maintenance is performed only at the Release level. 6 Primary Process Documentation This section identifies the documentation generated under this SOP. Document# QMS-SOP-0008 6.1 Software Development Plan (SDP) For all classes of software (A, B, and C), a Software Development Plan shall be created. This may exist as part of the broader Product Development Plan (PDP). The SDP is a plan that documents the task breakdown, development schedule, and assignment of responsibilities for the software project/product. The SDP documents the resources required, deliverables, and the timing of phases. The SDP also documents the development approach and methodology, and may supersede the contents of the PDP. Any deviations from the PDP shall be documented in the SDP, with justification for the deviation. The SDP shall assign and justify the ‘software safety class’ of the software system. The SDP shall identify what processes the development will follow, what deliverables will be created over its lifecycle (including documentation), what traceability will exist between standards, top-level requirements, derived system and software requirements, specs, risks, and verifications. The plan shall also identify what configuration management tools and processes shall be followed, including explicit treatment of Software of Unknown Provenance (SOUP), as well as what defect resolution processes are to be followed at each stage in development. The SDP shall include the following sub-plans:  Integration and Test (I&T) Plan (for class B and C software only) – detailing plans for integration and test at the system level and for interface with external products.  Verification Plan (all classes) – identifying deliverables, verification tasks, the phasing of those tasks by development stage (e.g. sprint, epics, release), and acceptance criteria for those activities. Per SOP: Verification and Validation (QMS-SOP-0009).  Risk Management Plan (all classes) – created and performed in accordance with both SOP: Risk Management (QMS-SOP-0013), and IEC 62304. This may refer to a system-level Risk Management plan for products that are not software-only.  Documentation Plan (all classes) – including titles, purposes, audiences, and processes for review, approval, and modification. This plan may refer to SOP: Document Controls (QMS-SOP-0002) for handling of the documentation release cycle. Document# QMS-SOP-0008   Configuration Management Plan (all classes) – including which classes/categories/types are to be controlled, CM activities and tasks, personnel responsible for conducting these activities, when items should be placed under configuration control, when a problem resolution process should be followed, what supporting items used to develop the software should be controlled (e.g. tools, environment, configuration), what documentation of CM status will be produced, and a plan for placing CM-required items under documented CM prior to beginning verification.  Software Maintenance Plan (all classes) – including procedures for managing reported feedback after release, evaluation criteria for determining if feedback represents a problem, use of the risk management process, software problem resolution process, and configuration management process, and procedures to evaluate and implement changes to SOUP. 6.1.1 Verification Plan Details The verification plan shall establish the software unit verification process (class B and C only), including strategies, methods, and procedures. The test procedures shall be evaluated for correctness. Acceptance criteria shall be established for acceptance of software units prior to integration into larger items. Verification shall ensure the software item meets the acceptance criteria. Any deviation from these criteria shall be documented and evaluated as a residual anomaly prior to release. For software integrated into a larger system, the integration shall be verified. This is to verify that the integration has occurred, not that it functions as expected, and can be done by inspection if practicable. Following integration and according to the integration plan, the integrated software shall be tested to verify:  Required functionality  There are no regressions from existing functionality  Implementation of risk control / mitigation measures  Specified timing and behaviours  Functioning of internal and external interfaces  Testing under abnormal circumstances, including foreseeable misuse. Document# QMS-SOP-0008 Integration test procedures shall be evaluated for correctness. This could be performed, for example, by inspection or “green-run” tests. Integration testing shall include regression tests to verify that defects have not been introduced into previously integrated software. Integration tests shall be documented, including test results (pass/fail, list of anomalies), records sufficient to repeat the test (test case specs, equipment used, test environment configuration), and the identity of the person(/system) who(/which) conducted the test. Integration test anomalies shall be entered into a software problem resolution process. Integration tests may be combined into the same effort as software system testing. Software system testing shall be conducted to cover all software requirements. The tests shall include input stimuli, expected outcomes, pass/fail criteria, and procedures for execution. Each test may verify one or more requirements as appropriate. System test anomalies shall be entered into the software problem resolution process. If software changes are required during the system test phase, tests shall be repeated, tests shall be modified or added as needed to verify the effectiveness of the change, and risk management activities shall be conducted as appropriate. Re-testing shall demonstrate that unintended side-effects have not been introduced. System test procedures and verification strategies shall be evaluated to ensure they are appropriate. System test procedures shall trace to software requirements, including those arising from risk mitigation measures. All requirements shall be tested or otherwise verified, and shown to meet pass/fail criteria. System tests shall be documented, including test results (pass/fail, list of anomalies), records sufficient to repeat the test (test case specs, equipment used, test environment configuration), and the identity of the person(/system) who(/which) conducted the test. Note: Additional verification requirements exist for Class C software, including event sequencing, fault handling, and self-diagnostics, among others. This SOP shall be modified to account for these requirements prior to continuation of Class C development. Compass does not currently manufacture Class C software. Document# QMS-SOP-0008 6.2 Risk Management Plan Details In addition to risk management plan activities at the system level, software specific activities are identified here. SOUP anomaly lists (generally maintained by the manufacturer of the SOUP) shall be evaluated for effects that could contribute to a hazardous situation. Risk control measures implemented in software shall be included in software requirements, and shall not be used to reduce the safety class of the software item. Software changes shall be analyzed with respect to system safety to determine if additional hazards or hazard causes may be introduced, and whether additional risk mitigation measures are required. Changes shall additionally be evaluated against existing risk mitigation measures to determine if the change could interfere and diminish the mitigation. 6.3 Software Requirements The Software Requirement Specification (SRS) provides a detailed overview of the software system to be developed, including functional and non-functional requirements. The software requirements are derived from, or traceable to, the system requirements and/or product requirements (for a standalone software product, there may not be a difference between the system and software requirements). The software requirements are reviewed and updated throughout the “Design” and “Development” phases of software development and should be finalized prior to transitioning to the “Verification” phase of the software for each release. For all software classes (A, B, and C), the software requirements are documented in a Software Requirements Document at each Release, and reviewed to verify that the software requirements:  Implement the system requirements including those related to risk control  Do not contradict one another  Are expressed in terms to avoid ambiguity  Are stated in terms that permit establishment of test criteria and performance of tests to determine whether the test criteria have been met  Can be uniquely identified  Are traceable to system requirements or other source Document# QMS-SOP-0008 The requirements shall encompass, as appropriate:  Functional (e.g. what it does)  Performance (e.g. how well it does it)  Environmental (e.g. platform/OS, network conditions, upgradeability)  Input / Output / Interfaces (e.g. what systems, data characteristics, ranges/limits, defaults)  Alarms and Warnings  Security  Usability  Data Definition / Database requirements  Installation  Documentation to be developed  User maintenance (e.g. download)  Software-specific regulatory concerns  Risk control measures (added as requirements over time) For classes B and C software, changes to requirements shall require update to the system and/or software hazard/risk analysis. The Software Requirement Specifications serve as a design input and as such, the software requirements are used to derive design outputs. Software system testing are conducted to cover all software requirements. Each verification test case within a software verification test plan for software system testing should be able to trace to a software requirement as specified within the Software Requirements Specifications to clearly show the traceability of the design outputs to the design inputs. 6.4 Design Transfer The production elements of the software cycle are performed in advance of final verification, the transition to production is, in effect, the final technical gate before product release. Design transfer activities include the Release Readiness Meeting (RRM), during which the cross-functional team reviews the status of the development, verification, and validation work, and all associated documentation. An Independent Reviewer, who does not have direct responsibility for the design stage shall be included in the RRM. Document# QMS-SOP-0008 The RRM includes a review of design, risk, usability & validation, marketing; labelling, and verification documentation, as well as specification of the build to be released. Status of these documentation items is captured in a Transition to Production Checklist (QMS-FRM- XXXX). The checklist serves dual record duty as minutes and documentation checklist, and captures the collective decision to proceed. It is signed by the Product Manager and QA/RA. Upon clearing the product through to Production, the app may be made available through the software release process. 7Process Monitoring 7.1 Documentation QA-RA shall conduct regular evaluation of the status of software documentation, identifying any elements not aligned with this SOP or the Software Development Plan for the given software item. Results of reviews and status of documentation shall be communicated to Management and reviewed at each regularly scheduled QMS Management Review meeting. 8 Quality Records Record type Description Checklists Phase gate transition checklists List/Description of residual anomalies present at completion of Residual anomalies development (generally tracked in Jira) Document# QMS-SOP-0008