Compass Health AI Risk Management SOP PDF

Compass Health AI SOP: Risk Management Approvals Author Position Role Signature Date DD-MMM-YYYY Tenzin Head of Author 02-Jan-2024 Yangzom QA/RA James...

Compass Health AI SOP: Risk Management Approvals Author Position Role Signature Date DD-MMM-YYYY Tenzin Head of Author 02-Jan-2024 Yangzom QA/RA James Approver 02-Jan-2024 02-Jan-2024 Baskin COO Kevin Approver 02-Jan-2024 Kennedy Engineering Scott Approver 02-Jan-2024 Crawley CEO Document #: QMS-SOP-0013 Revision History Version Date Description 1.0 03 Jan 2024 Initial Release Document #: QMS-SOP-0013 1 Introduction This document outlines the risk management process used at Compass Health as part of product development and manufacturing. 1.1 Scope Risk management shall be performed for all medical device products that are developed by Compass Health. The risk management process is part of the overall medical product development process and part of the Compass Health Quality Management System. The risk management process shall be applied to the risks arising at any phase from the concept phase for a medical product until its end of life per ISO 14971 and IEC 62304. This includes any risks that may arise from approved changes instigated as a result of complaint resolution activities. The risk management process followed by Compass Health meets the requirements of both ISO 14971:2019. risk management plans (this document serves as both the RM plan and report) records of the risk analyses (included in Hazard Analysis, and in the Product/Project Risk Assessment sections of this document) risk evaluations and control measures (included in the table below). 2 Applicable and Reference Documents 2.1 Applicable Standards The following standards and regulations are intended to be met by this procedure: Document #: QMS-SOP-0013  FDA QSR § 820.30 Design Controls ISO 13485:2016 Section 7.3. Design and Development ISO 14971:2019 Application of Risk Management to Medical Devices (mandatory reference for all countries) IEC 62304:2015 Medical Device Software – Software Life-cycle Processes IEC 63266:2015 Medical devices – Application of usability engineering to medical devices IEC 60812:2018 – Failure modes and effects analysis (FMEA and FMECA) TG(MD) Sch1 P1 2, Sch3 P1 Cl 1.4(5)(c)(iii) 2.2 Reference Documents The following documents, templates, and forms are referenced for informational purposes within this procedure and are related to the Product Development Process. Document Title Document # SOP: Product Development Process QMS-SOP-0007 SOP: Usability Engineering Process QMS-SOP-0011 Risk Management Plan and Report Template QMS-TMP-0054 Usability Engineering Plan and Report Template QMS-TMP-0055 SOP: Post-market surveillance QMS-SOP-0030 3 Acronyms and Definitions Table 1: Acronyms Document #: QMS-SOP-0013  Acronym Meaning MTR Maximum Tolerable Risk EEA European Economic Area MDD Directive for Medical Devices (MDD) SOUP Software of Unknown Provenance Table 2: Definitions Term Definitions Any condition that deviates from the expected based on requirements specifications, design documents, standards, etc. or from someone’s perceptions or experiences. Anomalies may Anomaly be found during, but not limited to, the review, test, analysis, compilation, or use of software products or applicable documentation. A systematic determination of the extent to which an entity meets Evaluation its specified criteria. Failure Mode and An evaluation of potential failure modes for processes and their Effect Analysis likely effect on outcomes and/or product performance. Physical injury, damage, or both to the health of people or damage Harm to property or the environment. Document #: QMS-SOP-0013  A form of risk assessment to determine potential areas of the system that could cause harm. It is done to ensure that the product is properly designed and tested to eliminate or reduce Hazard Analysis any risk to the patient or operator. By using measures for protection of the patient or the operator, hazard risks are reduced to A.L.A.R.P. (As Low as Reasonably Possible). Hazard Potential source of harm. A situation where people, property, or environment are exposed to Hazardous Situation a hazard. Risk of harm becomes present. Intended purpose; use for which a product, process or service is Intended Use intended according to the specifications, instructions and information provided by the manufacturer. The natural or legal person with responsibility for the design, manufacture, packaging and labeling of a device before it is Manufacturer placed on the market under its own name, regardless of whether these operations are carried out by this entity or on its behalf by a third party. Software System that has been developed for the purpose of Medical Device being incorporated into the medical device being developed or Software that is intended for use as a medical in its own right (per IEC 62304). A record of actual or potential behaviour of a software product that a user or other interested person believes to be unsafe, inappropriate for the intended use, or contrary to specification Problem Report (per IEC 62304). Note: A “problem report,” as defined in IEC 62304, is distinct from any of the reports submitted to Health Canada and/ or FDA Document #: QMS-SOP-0013  following the occurrence of a “reportable” event involving a Compass Health-made device. Likewise, “Problem Reports” do not trigger the MDR/ MPR system unless the nature of the event described in the report meets the reporting criteria (see SOP: Medical Device Reporting/ Mandatory Problem Reporting). Risk is defined as a combination of the probability of occurrence Risk of harm and the severity of that harm that could be caused by that failure, if undetected. Systematic use of available information to identify hazards and to Risk Analysis estimate the risk. Process in which decisions are made and measures implemented Risk Control by which risks are reduced to, or maintained within, specified levels. Systematic application of management policies, procedures, and Risk Management practices to the tasks of analyzing, evaluating, and controlling risk. Risk Management A set of records and other documents, not necessarily File contiguous, that are produced by the risk management process. Safety Freedom from unacceptable risk. Protection of information and data so that unauthorized people or Security systems cannot read or modify them and so that authorized persons or systems are not denied access to them. injury or illness that directly or indirectly: Serious Injury a) is life-threatening; Document #: QMS-SOP-0013  b) results in permanent impairment of a body function or permanent damage to a body structure; or c) necessitates medical or surgical intervention to prevent. Note IEC 62304 definition. Software Item Any identifiable part of a computer program (per 62304). Set of computer programs, procedures, and possibly associated Software Product documentation and data. Model for rating the relative safety of standalone software systems or software systems incorporated into medical devices featuring hardware components. The classification model is based on the possible effects on the patient, operator, or other people resulting from a hazard to which the software system can contribute. Devices are assigned an A, B or C classification rating, with A representing the highest level of safety associated with a Software Safety given software system, and C the highest. Refer to Appendix A for Classification (IEC details. 62304) Note that the Software Safety Classification model adhered to by IEC 62304 is distinct from the overall device classification models subscribed to by MDD, Health Canada, and FDA. Likewise, the “Level of Concern” classification scheme prescribed by FDA is not directly related to the Software Safety Classification Scheme described here. For details, refer to the device’s individual risk management plan and report. An integrated collection of software items organized to Software System accomplish a specific function or set of functions (per IEC 62304). Software Unit Software Item that is not subdivided into other items. Document #: QMS-SOP-0013  Software Item that is already developed and generally available Software of and that has not been developed for the purpose of being Unknown incorporated into the medical device (also known as “off the-shelf Provenance (SOUP) software”) or software previously developed for which adequate records of the development processes are not available. Degree to which a relationship can be established between two or Traceability more products of the development process. Confirmation through provision of objective evidence that Verification specified requirements have been fulfilled. 4 Process Roles Role Description of Responsibilities Product Manager · Responsible for the decisions and rationale given by the RMT. · Carries out regular audits to ensure that Compass Health products are developed in accordance with the requirements of this SOP. QA/RA · Responsible for relaying the results of these audits to be presented at each scheduled Quality System Management Review · Comprise, at minimum, personnel from Engineering, Marketing, Customer Success, QA/RA, and the Product Manager Risk Management *Members of the RMT are documented in the Risk Management Plan. Team (RMT) Evaluates collectively whether a design or process FMEA is required, based on the nature of the device (e.g. regulatory classification) and associated hazards and functions. Document #: QMS-SOP-0013  Decides if a design FMEA (DFMEA), or process FMEA (PFMEA) is warranted for a particular product (documented in the Risk Management Plan and Report). Rates the Occurrence, Severity and Detectability of each failure found, and calculates a risk priority number (RPN) 5 Risk Management Process The Risk Management Process is applied throughout a product’s development, with the goal of identifying and controlling risks, ensuring residual risk is outweighed by the benefits of using the product and ensuring changes made in later phases of development do not introduce unforeseen risks. The Risk Management Process proceeds at a high level according to Figure 1. Figure 1: Risk Management Process The process begins with the assignment of Risk Management responsibilities to a Risk Management Team (RMT). The RMT shall comprise, at minimum, personnel from Engineering, Marketing, Clinical, QA/RA, and the Product Manager, with the Product Document #: QMS-SOP-0013 Manager being responsible for the decisions and rationale given by the RMT. The members of the RMT shall be documented in the Risk Management Plan. The process continues with performing a Hazard Analysis and Risk Evaluation. The RMT evaluates collectively whether a design or process FMEA is required, based on the nature of the device (e.g. regulatory classification) and associated hazards and functions. The outputs of Risk Evaluation and FMEA activities are used to identify mitigation strategies for any unacceptable risks. Any adopted mitigation measures are evaluated explicitly for potential impact to hazards and risks. Residual risks are identified and weighed against the clinical benefits of using the product. Software is classified according to the process in IEC 62304. Depending on the classification, additional hazard analysis (e.g. SOUP) and risk control evaluation is performed. 5.1 Process Inputs The Risk Management Process makes use of the Usability Spec and, later, the Usability V&V Report which arise from activities in the SOP: Usability Engineering Process. 5.2 Process Outputs The Risk Management Process will result in the generation of the outputs described in the following subsections. 5.2.1 Risk Management Plan The Risk Management Plan and Report Template shall be completed for each medical device product. The completed plan (RMP), as a phase transition deliverable, shall be monitored and revised as an exit criteria deliverable of the Product Development Plan and will include the required elements as prescribed in Risk Management Plan and Report Template. 5.2.2 Usability Engineering Plan The Usability Engineering Plan and Report Template documents the specific risk management activities related to usability considerations and shall be completed for each program/ medical product. The completed plan (UEP), as a phase transition deliverable, Document #: QMS-SOP-0013 shall be monitored and revised as an exit criteria deliverable of the Product Development Plan and will include the required elements as prescribed in Usability Engineering Plan and Report Template 5.2.3 Hazard Analysis Document A Hazard Analysis for each medical product shall include the following information (as appropriate for the product development phase) maintained in Document Control: A description and identification of the medical product that was analyzed (qualitative and quantitative characteristics) Identified potential hazards Initiating causes and outcomes for each identified hazard The categories of severity classifications and the like severity estimates for each hazard An estimation of risks for all identified hazards Reference to the requirements and methods used to eliminate, mitigate or reduce/control the risk of the hazards Results of the verification of the implementation of the risk reduction and control measures Results of the verification and validation of the appropriateness and effectiveness of risk control methods (reference reports) Residual risk levels (severity and risk) All relevant information regarding residual risk, including descriptions of the hazards and any actions by the operator or the user necessary to avoid/mitigate them Evidence of compliance and/or records shall be maintained. For software products assigned a safety classification of Class B and above, the product’s hazard analysis shall provide traceability between software hazards, as appropriate: from the hazardous situation to the software item from the software item to the specific software cause from the software cause to the risk control measure from the risk control measure to the verification of the risk control measure For Class A software systems (per IEC 62304) – and when a decision is made to forgo adherence to one or more of the traceability requirements outlined above – the RMT shall produce a rationale to support the decision. Document #: QMS-SOP-0013 5.2.4 Failure Mode and Effect Analysis (FMEA) The RMT will decide if a process FMEA (PFMEA) is warranted for a particular product (documented in the Risk Management Plan and Report). A FMEA contains the following information: Potential component or process failures Effect of failure (potential hazard) Severity of failure Cause of potential failure Occurrence Severity Mitigations and detection steps Detectability Rating Risk profile number (RPN) rating for each potential hazard Any action item(s) for each identified potential failure Evidence of compliance with action items shall be maintained. 5.2.5 Risk Management Status The status of risk management activities shall be reviewed during project team meetings, and documented in minutes from the meeting. Risk management status shall also be reviewed as part of reviewing the deliverables for a phase transition (as documented in the SOP: Product Development Process). Issues concerning residual risk and/or other concerns shall be escalated to Top Management as appropriate. 5.2.6 Software Safety Classification This section applies to standalone software systems and software systems incorporated into medical device products containing hardware. The Risk Management Team is responsible for assigning to the software system an overall software safety classification ranking – A, B, or C – in accordance with IEC 62304 based on the level of risk associated with the product following implementation of risk control measures. Document #: QMS-SOP-0013 The classification decision is identified in the product’s individual Hazard Analysis and the Risk Management Plan and Report. Refer to Appendix A for the standard’s classification scheme and the standard itself when additional guidance is required. 5.3 Risk Management File Compass Health shall establish and maintain a Risk Management File for each medical device, to maintain records of Risk Management Activities for each product considered. The Risk Management file shall provide traceability for each identified hazard to: 1. The risk analysis; 2. The risk evaluation 3. The implementation and verification of the risk control measures; 4. The assessment of the acceptability of any residual risk(s) 5.4 Hazard Analysis 5.4.1 Identifying Potential Hazards Potential hazards for a product shall be identified by considering the characteristics of the medical product technology, the product users, and the environment within which the technology will be used. All components of the product, including hardware and software items, which could contribute to a hazardous situation, shall be identified as part of the overall hazard identification process outlined above. A list of potential hazards associated with the medical product in both normal and fault conditions and in both normal use and incorrect use conditions shall be reviewed for each product (some examples are listed in the Hazard Analysis Template). The level of detail required for the hazard analysis shall be determined by several factors, including the type and level of risks associated with the medical product. Foreseeable sequences of events or potential use scenarios that may result in a hazard shall be considered. Testing prototypes with users may identify other unanticipated use scenarios resulting in hazards. Document #: QMS-SOP-0013 5.4.2 Initiating Causes/Outcomes A medical product may have multiple potential hazards associated with it. Likewise, each hazard may have multiple potential causes. The degree of effort and detail in characterizing the potential causes of a hazard shall be commensurate with the severity of the resulting consequences. For each cause identified as leading to or contributing to a hazard, determine the outcomes that could arise. There may be several possible outcomes of a cause; document and evaluate each one. Also, consider outcomes that may cause the customer to be out of compliance with legal and regulatory requirements placed on them. When the medical device is—or contains—a software system, the potential cause(s) behind the software item contributing to the hazardous situation (see 3.1) are identified and documented in the hazard analysis. To support the process of identifying the cause(s) behind the software item contributing to the hazardous situation, the following potential causes shall be considered: incorrect or incomplete specification of functionality software defects in the identified software item functionality failure or unexpected results from SOUP hardware failures or other software defects that could result in unpredictable software operation reasonably foreseeable misuse. If failure or unexpected results from SOUP is a potential cause of the software item contributing to a hazardous situation, Compass Health shall evaluate as a minimum any anomaly list published by the supplier of the SOUP item relevant to the version of the SOUP item used in the medical device to determine if any of the known anomalies result in a sequence of events that could result in a hazardous situation. The above requirement is optional when the software system is Class A under IEC 62304 (see Appendix A). The sequences of events that could result in a hazardous situation are documented in the product hazard analysis (optional when Class A under IEC 62304). Document #: QMS-SOP-0013 5.4.3 Estimate the Risks for Each Hazard For each of the possible hazards identified under section 3.1, the risks under both normal and fault conditions shall be estimated using available information/data. Risk estimation shall include examination of the initiating events or circumstances, the sequence of events that are of concern, any mitigating features, and the nature and frequency of the possible deleterious consequences of the identified hazards. In order to analyze risks, their components (i.e. severity) shall be analyzed separately. This may be done by quantitative or qualitative methods as appropriate. This includes answering the following questions: Does the hazard exist in the absence of a failure? Does the hazard exist in a failure mode? Does the hazard exist only in multiple fault conditions? 5.4.4 Assign Severity For each hazard, the potential harm that may be experienced is determined. Table 1: Severity Classifications Classification Possible Consequences of a Hazard Potential of death or serious injury: Category IV A failure or latent flaw directly affects the patient and/or operator and could result in death or serious injury to the patient and/or Critical operator, or indirectly affects the patient and/or operator such that incorrect or delayed information could result in death or serious injury of the patient and/or operator. Potential of minor injury. Category III A failure or latent flaw directly affects the patient and/or operator Major and could result in non-serious injury to the patient and/or operator, or indirectly affects the patient and/or operator where incorrect or Document #: QMS-SOP-0013  delayed information could result in non-serious injury of the patient and/or operator. Little potential of injury. Category II A failure or latent flaw would not be expected to result in any injury Minor to the patient and/or operator. Category I Negligible – product is controlled as a non-diagnostic, medical Negligible device intended for consultation only. 5.4.5 Assign Risk Probability Risk Probability estimation should examine the initiating causes or circumstances, that is, the sequence of events that are of concern. This includes answering the following questions: Does the hazard occur in the absence of a failure? Does the hazard occur in a failure mode? Does the hazard occur only in a multiple fault condition? Table 2: Probability of occurrence of harm (P) Probability of Description occurrence of harm Frequent Likely to occur frequently in the operating life of the system. Likely to occur multiple times in the operating life of the Probable system. Document #: QMS-SOP-0013  Occasional Unlikely, but may occur in the operating life of the system. Remote Very unlikely to occur in the life of the system. 5.4.6 Assign Risk: For each hazard an estimation of risk severity/frequency is conducted. This involves determining the numerical acceptability of the risks that have been evaluated. This is determined by estimating the following, based on: How often the device is used A lifetime of the device Who makes up the user and patient population # of patients/users Impact on user/patient Feedback Post-market surveillance (complaints) Clinical evaluations Corrective and Preventive Actions 5.4.7 Risk Classifications Harms were allocated a severity, and the combined probability of harm was used to assign a net risk: High (H) Medium (M) Low (L) Negligible (N Table 3: Risk Classifications and Default Actions Document #: QMS-SOP-0013  Risk Action Required Classifications Take action to eliminate the hazard or bring risk classification to Low High (H) or Negligible level (by reducing the severity or likelihood of the hazard). Take action to bring risk classification to Low or Negligible level (by Medium (M) reducing the severity or likelihood of the hazard). Perform risk/benefit analysis. Take appropriate action to reduce the Low (L) risk of hazard as far as possible. Risk reduction need not be actively pursued. Risk is negligible Negligible (N) compared with the risk of other hazards that are accepted and has been reduced as far as possible 5.5 Process FMEA A PFMEA can be used to analyze a production operation and its effect on product or process. It identifies activities and processes with a potential for occurrence of a failure. Early identification of such failures enables Compass Health to initiate the implementation of a preventive action in order to eliminate / mitigate the chance for the occurrence of the failure. 5.5.1 Identification of Failure Modes Potential failure modes are identified by the risk management team (or a subset of the RMT as needed), using the following information as input: Production workflow (as outlined in the Production Plan) Work instructions, drawing, specifications, first article inspections Production environment Customer complaints and previous CAPAs Document #: QMS-SOP-0013  RMAs Any other documents the risk management team decides will be beneficial The Process Failure Mode and Effect Analysis Form [QMS-FRM-2539] is used to document the PFMEA. The team analyzes of the production steps and processes required, and identifies potential failure modes. 5.5.2 FMEA Ratings The Design and Process FMEAs use the rating systems defined in Process Failure Modes and Effect Analysis Master Form [QMS-FRM-2539], outlining the definitions of Occurrence, Severity, Detectability. The RMT rates the Occurrence, Severity and Detectability of each failure found, and calculates a risk priority number (RPN). 5.6 Risk Evaluation 5.6.1 Maximum Tolerable Risk 5.6.1.1 Hazard Analysis For each identified hazard, the risk levels for the appropriate actions to be taken shall be evaluated. The Maximum Tolerable Risk (MTR) is defined as a hazard or failure mode having risk level of “Low” or “Negligible”. This definition for MTR shall be applied as the default, unless the MTR is otherwise defined in the Risk Management Plan for a specific product. Table 4: Risk Probability Document #: QMS-SOP-0013 5.6.1.2 FMEA For each identified failure mode, the risk levels for the appropriate actions to be taken shall be evaluated. The Maximum Tolerable Risk (MTR) for FMEA is defined as a failure mode having a RPN score of >=20. This definition for MTR shall be applied as the default, unless the MTR is otherwise defined in the Risk Management Plan for a specific product. Document #: QMS-SOP-0013 5.6.1.3 Risk/impact evaluation criteria When risk levels are being assessed during impact evaluation of many QMS related activities (such as CAPAs, process changes, process validation, complaints and others), the following criteria in under the three categories: Business, Product and Regulatory must be evaluated and reported. Risk level of Category II/Minor and Category I/Negligible are considered to be the Maximum tolerable Risk (MTR) levels. Clas sific Business Product Regulatory atio n Issues that can Critical events that An issue that a) causes a total system lead to potential can cause failure, causes defects that corrupt recalls, medical Cat reputational and images or cause loss of images or device license egor economic damage, misrepresentation of data, and b) could withdrawal, y affecting business cause serious injury to a person, and c) security and IV/C and client base, as there is no workaround at the privacy risks ritic well as employee application level, and d) reports of and/or al safety and incidents alleging adverse events, with mandatory experience. respect to any MDR/MPR applicability problem reporting. Lack of Significant events Cat that can cause An issue which a) potentially hinders document egor major changes clinical use of the product, b) results in control, y a significant deviation from functional inadequate within the business III/ or performance requirements, and c) change with regards to Maj process and there is no workaround at the management or or application level. regulatory function, as well as requirements not impact on external being met that Document #: QMS-SOP-0013  customers due to can lead to audit these changes findings Events that can Regulatory cause changes requirements are Cat within the business An issue which hinders general being met but egor with regards to functionality of the product and results process could be y process and in a degradation of productivity which is improved and II/Mi function, but has an inconvenience to the user. A documents nor minimal impact on workaround is available. could be better external completed. customers. Cat No impact on the egor An issue which may be considered an No impact on business activities. y annoyance or inconvenience to the user QMS and Employee and/or I/Ne but do not impact the functionality or regulatory Customer Service gligi performance of the product activities are controlled ble 5.6.2 Determine if Risks are Reducible If any risk level (residual risk after control/mitigation) is judged to be above the MTR (i.e. H or M), it shall be eliminated or reduced to at or below the MTR (i.e. L or N) by the appropriate hazard mitigations. 5.7 Risk Reduction & Control 5.7.1 Implement Risk Control and Mitigation Possibilities for mitigations include but are not limited to the risk control methods listed below: Eliminate or reduce the hazard by inherent safe design or redesign Reduce the risk by protective measures or preventive actions Document #: QMS-SOP-0013  Reduce the risk by adequate user information, such as sufficient warnings, however, this mitigation will not be the only source of risk mitigation for a hazard but can be used as a supplemental risk control method. Redefine the intended use Note: Compass Health will consider all risk control options available to mitigate a hazard, beyond those required merely to reduce the risk to a low as reasonably possible (A.L.A.R.P) level. Corrective action shall be taken as necessary to implement the designated hazard mitigations and controls. The designated hazard and failure mode mitigations and controls shall be documented. The degree of corrective and preventive action taken to eliminate or minimize actual or potential hazards/failure modes shall be appropriate to the magnitude of the problem and commensurate with the risks encountered. Risk control measures, to include those specifically established to mitigate the potential cause of the software item contributing to a hazardous situation, are defined and documented in the {product} hazard analysis and FMEA. When Risk Control/Reduction is necessary, Compass will identify, if applicable, these Risk Control/Reduction measures by: 5. Providing inherent safety design and manufacture 6. Protective measures on the medical device itself 7. Providing information for safety, and where appropriate training to users (instructions for use, labeling, etc.) Compass will use Risk Assessment to decide on whether a new product should be introduced or not. After the risk control measures are implemented, COMPASS shall any residual risk using the criteria for risk acceptability defined in the Risk management plan. If this evidence does not support the conclusion that the medical benefits out weight this residual risk, then COMPASS may be considered the manufacturer of the modified medical device or its intended use. Training to users can be an important aspect of delivering information for safety. The COMPASS can consider providing mandatory training for the intended users. Document #: QMS-SOP-0013 If a risk control measure is implemented as part of the functions of a software item, the manufacturer shall: include the risk control measure in the software requirements. assign a software safety class to the software item based on the possible effects of the hazard that the risk control measure is controlling; and develop the software item in accordance with SOP-Software Development Process. Note: this requirement is optional when Class A under IEC 62304. 5.7.2 Verify and Validate Risk Control and Mitigation Verification of the risk controls shall be in two parts: Verify that the mitigation and risk control measures were implemented Verify that the mitigation and risk control measures were appropriate and produced the desired reduction in risk level Functional and operational requirements shall be verified, and the results of the verification shall be recorded. Safety and effectiveness of the medical product shall be validated within the confines of the product’s intended use statement. Validation results shall be recorded and maintained in keeping with SOP: Control of Records. 5.7.3 Evaluate Residual Risk and Acceptability of Residual Risk Risk levels for each hazard that required mitigation shall be re-assessed after mitigation is complete. The result is the documented residual risk level. Those hazards whose risk levels still exceed the MTR shall repeat the risk control process and shall be re-examined for additional risk control measures. All hazards must have risk levels at or below the MTR. If the residual risk is at the Low-risk level, the Risk Management Team shall review existing data and literature on the efficacy of the intended use/purpose to determine if the medical benefits outweigh the residual risk. The default action is to bring the risk of the hazard as low as reasonably practicable. All relevant information regarding residual risks shall be placed in the appropriate Instructions for Use. Document #: QMS-SOP-0013 5.7.4 Determine if New Hazards Have Been Introduced A review of the hazard mitigations shall be performed to determine if changes made to eliminate or minimize hazards have introduced new hazards or causes. If any new hazards or causes have been introduced, the Risk Management Team shall perform the required risk analysis, risk evaluation and risk control activities. 5.7.5 Determine if Medical Product Safety is Adequate If the residual risk from all identified hazards for the medical product is at or below the MTR, then the medical product safety shall be determined to be adequate. 5.8 Ongoing Activities 5.8.1 In-Service Experience When new information or data becomes available, a new risk analysis shall be considered. Information with possible relevance to hazards obtained during in-service experience with the medical product or similar medical products shall be evaluated to determine: If previously unrecognized hazards or causes are present, or If the estimated risks arising from a hazard exceeds the lowest reasonably possible risk level. If either of the above conditions is satisfied, the results of the evaluation shall be fed back as an input to the risk management process. 5.8.2 Design Modifications The risk management impact of proposed design modifications shall be reviewed as part of detailed and technical reviews. Refer also to SOP: Change Control (QMS-SOP-0023). 5.8.3 Production Process Modifications The risk management impact of proposed changes to production processes shall be reviewed as part of change requests. Refer to SOP: Change Control (QMS-SOP-0023). Document #: QMS-SOP-0013 5.8.4 Post-Market Surveillance The post-market surveillance (PMS) stage ensures ongoing communication of information that has an important bearing on a device’s benefit-risk assessment (or would indicate a need for labeling and/or instructions for use changes regarding contraindications, warnings, precautions) between Compass Health and relevant conformity assessment bodies/ regulatory authorities in accordance with local reporting requirements (see SOP: Post-Market Surveillance [QMS-SOP-0039]). The post-market surveillance activities are documented in the Risk Management Plan and Report for the product. 6 Process Monitoring Audits shall be carried out regularly by Quality Assurance (QA) to ensure that Compass Health products are developed in accordance with the requirements of this SOP. These audits shall be part of the Quality System compliance audits performed by QA (see the SOP: Quality System Audits [QMS-SOP-0032]). Results of these audits shall be presented at each scheduled Quality System Management Review 7 Quality Records Record type Description Documentation of Hazard Analysis performed for each medical Hazard Analysis product (as appropriate for the product development phase). See Document section 5.2.3 for all the details required for this document. Completed for each medical device product. Includes the required elements as prescribed in Risk Management Plan and Risk Management Report Template (QMS-TMP-0054). Includes classification Plan and Report decision, decision of whether a design is warranted for a particular product, and post-market surveillance activities Usability Documents the specific risk management activities related to Engineering Plan usability considerations and shall be completed for each and Report program/ medical product. Includes classification decision, decision of whether a design FMEA (DFMEA), or process FMEA Document #: QMS-SOP-0013  (PFMEA) is warranted for a particular product and post-market surveillance activities. Risk Management A form outlining all the responsibilities as a member of the Risk Team Management Team (RMT), and acknowledgment of such Acknowledgment responsibilities by all RMT members Form Appendix A: IEC 62304 Safety Classification Scheme Per IEC 62304, Compass Health assigns to software systems that are—or are contained within—a medical device software product a software safety class (A, B, or C) according to the possible effects on the patient, operator, or other people resulting from a hazard to which the software system can contribute. Class A: No injury or damage to health is possible Class B: Only NON-SERIOUS INJURY is possible Class C: DEATH or SERIOUS INJURY is possible Note: If the RISK of death or SERIOUS INJURY arising from a software failure is subsequently reduced to as low as reasonably possible (A.L.A.R.P) level by a hardware risk control measure, either by reducing the consequences of the failure or by reducing the probability of death or SERIOUS INJURY arising from that failure, the software safety classification may be reduced from C to B; and if the RISK of non-SERIOUS INJURY arising from a software failure is similarly reduced to as low as reasonably possible (A.L.A.R.P) level by a hardware risk control measure, the software safety classification may be reduced from B to A. This software safety classification scheme reflects classification requirements established in IEC 62304. If additional guidance is required, consult the standard itself. Document #: QMS-SOP-0013