PROPOSED DOCUMENT. International Medical Device Regulators Forum

Transcription

1 1 SaMD WG(PD1)/N12R PROPOSED DOCUMENT International Medical Device Regulators Forum Title: Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Controls Authoring Group: IMDRF SaMD Working Group Date: 26 March

2 Table of Contents 1.0 Introduction Scope Definitions Intended Use / Intended Purpose Critical condition Serious condition Non-Serious condition SaMD Definition statement Framework principles SaMD Types SaMD that supplies information as a sole determinant to treat: SaMD that supplies information which is the sole determinant to diagnose: SaMD that Drives Clinical Management SaMD that Informs Clinical Management SaMD Controls Appendix Clarifying SaMD Definition Recommendations on specific controls that may apply to SaMD February 2014 Page 2 of 25

3 Preface The document herein was produced by the International Medical Device Regulators Forum (IMDRF), a voluntary group of global medical device regulators from around the world. The document has been subject to consultation throughout its development. There are no restrictions on the reproduction, distribution or use of this document; however, incorporation of this document, in part or in whole, into any other document, or its translation into languages other than English, does not convey or represent an endorsement of any kind by the International Medical Device Regulators Forum February 2014 Page 3 of 25

4 Introduction Software as a Medical Device (SaMD) is increasingly being used in a wide range of medical settings and for a wide range of medical purposes, and has become an innovative tool with the potential to enhance the quality of care. SaMD has the potential to be beneficial to both healthcare providers and patients/consumers by enhancing the ability to make the best possible clinical decisions. Existing regulations address public health risks of software when embedded in a traditional medical device. However, the current application of regulations and controls does not always translate or address the unique public health risks posed by SaMD nor assure an appropriate balance between patient/consumer protection and promotion of public health by facilitating innovation. There is a need for all stakeholders (manufacturers, users, and regulators) to have a common approach and understanding of SaMD risks and expected controls that promotes patient safety and public health. The objective of this working group is to provide a possible framework for SaMD. Regulators can utilize this document as a reference when considering their regulatory requirements. The framework is intended only to be used as a foundation and common understanding for SaMD; it is not intended to replace or modify existing classification schemes or regulatory requirements in jurisdictions/countries. Each jurisdiction/country can potentially implement this framework within their respective regulatory approaches, subject to existing legal requirements in each jurisdiction/country. This working group finalized the first document - IMDRF SaMD WG N10 / Software as a Medical Device: Key Definitions which provided definitions for the key terms used to decide when software is considered to be a medical device. This document IMDRF SaMD WG N12 / Software as a Medical Device: Framework for Risk Categorization and Corresponding Controls is the second in this collection of documents that provides a common approach to: Create a framework that categorizes types of SaMD based on their risk profiles. Identify controls that assure safety and effectiveness required to address risk associated with different types of SaMD February 2014 Page 4 of 25

5 Scope This document provides a possible approach to: Identify essential information for describing the SaMD in terms of the medical purpose, context of use, and core functionality Characterize types of SaMDs, based on the essential information, similarity in risk profile and the hazards associated with SaMD. Identify measures considered appropriate for assuring reasonable safety and effectiveness. This risk framework uses the definition of SaMD provided by the related document, IMDRF SaMD WG N10 / Software as a Medical Device: Key Definitions. The content of this document is not meant to replace or conflict with the content and/or development of technical or process standards related to software risk management, e.g., ISO 14971, IEC 62304, IEC/TR February 2014 Page 5 of 25

6 Definitions 3.1 Intended Use / Intended Purpose The objective intent of the manufacturer regarding the use of a product, process, or service, as reflected in the specifications, instructions and information provided by the manufacturer. (GHTF/SG1/N70:2011 Label and Instructions for Use for Medical Devices ). 3.2 Critical condition For the purposes of this document, a critical condition is considered to be a life-threatening state of health, sometimes incurable, which requires major therapeutic interventions, sometimes time critical. Examples include serious disease (cancer, end stage renal disease), serious injury (e.g. 3rd degree burns), AIDs, hepatitis, and congestive heart failure. Accurate diagnosis or treatment action is vital to mitigate the impact of the critical disease or condition to avoid death, long-term disability or other serious deterioration of health, on the individual patient or to mitigate the public health impact of the critical condition. 3.3 Serious condition A serious condition is a health condition that is not considered to constitute a life-threatening state of health. A serious condition is a health state: that is often curable or does not require major therapeutic interventions; where an intervention normally is not expected to be time critical in order to avoid death, long-term disability or other serious deterioration of health, but where an accurate diagnosis is of vital importance to mitigate the individual patients health condition. 3.4 Non-Serious condition A non-serious condition covers diseases and conditions that are not covered by the definition of critical or serious condition and may include minor chronic illnesses or states February 2014 Page 6 of 25

7 SaMD Definition statement Essential information to define a SaMD is reflected in various sources such as the manufacturer s specifications, instructions for use, labeling and other information provided by the manufacturer. Using the essential information, the manufacturer should compile a definition statement addressing key factors that should be used to categorize SaMD in to appropriate types and associated controls. The SaMD definition statement should include a clear and strong statement about the following: The medical purpose of the SaMD: The statement should explain how the SaMD meets one or more of the purposes described in the definition of a medical device 1, e.g. supply information for diagnosis, prevention, monitoring, treatment etc. The Context of use of the SaMD o Who it s for intended user, expected skills (e.g. medical professional, administrator, lay persons) o How they will use it (that includes information that is relevant to the use) how is the output expected to be used in the care process Treat or diagnose Drive clinical Management Inform clinical management If applicable, patient condition if applicable, for which target population if applicable, for which target disease, disorder, condition or risk factor of interest disease type(s) or patient condition(s) (seriousness of the disease) if applicable, specific contraindications/limitations of the SaMD output A Description of the SaMD s core functionality 2 : What features/functions of the SaMD are essential to the intended medical purpose and context of use. This description should include only the critical features, required for the SaMD to fulfill a medical purpose in the context of use. 1 IMDRF key definitions Final document medical purposes 2 These could include specific functionality that is critical to maintain performance and safety profile, attributes identified by risk management process undertaken by the manufacturer of SaMD 21 February 2014 Page 7 of 25

8 Example: SaMD Definition Statement The following is an example of a SaMD definition statement for a data aggregation tool whose information is used for predicting early onset of sepsis. Medical Purpose: continuous multi-organ variability monitoring Who it s for: Attending clinicians monitoring a ICU (physician or nurse) How they ll use it: o for patients under observation in an ICU o for critically ill patients o to receive alerts when a patient in an ICU shows trend/signs of early onset of sepsis so action can be taken to prevent future complications Core functionality: o aggregate data from a variety of sources at the bedside in the ICU o analyze the variability of this aggregate data create a base line of patient condition by collecting information from bedside monitors clinicians establish time and situation to begin observation allow trigger point for alerts set by clinician and use this as alarm condition perform moving average for each parameter collected and alert clinician when variability matches trigger points Consolidated definition statement: Software that provides continuous multi-organ variability monitoring in critically ill patients (e.g., software that aggregates data from a variety of sources at the bedside in the ICU, analyzes the variability of these data and based on the variability predicts a change in health status (e.g., early on-set of sepsis) Examples of Non-core functionality / other description o Moving average algorithm for parameters and allowed trigger set-points are based on study evidence in Journal of XX (site link to the study) o A rolling log of aggregated data stored locally o Exception handling create an UI and remote alert when certain base line signal is missing or has abnormal variation detected in the collected data. o Background tracking/ processing; server integration with hospital information system; patient identification and record lookup, mobile alert text message capability based on subscription from authorized users o Patient privacy enabled authorized user access 21 February 2014 Page 8 of 25

9 Framework principles As medical devices, SaMD are subject to regulatory oversight. It is widely accepted that the level of oversight should increase in line with the potential of a medical device to cause harm to a patient/consumer or user (i.e., the hazard it presents). The following are fundamental principles used to categorize types of SaMD into similar risk profiles: the definition statement in section 4.0; the importance of the information (sole determinant or one of several), taking into consideration the disease or disorder including presenting signs and symptoms which may guide a user including a healthcare professional, individual or a caregiver; the impact of an invalid result (e.g., false positives or false negatives) to the individual and/or to public health. Using the above principles, SaMD are categorized in to four risk-based types based on the levels of impact as shown in table 1 below. Table 1: Risk Framework TYPE IMPACT LEVEL SAMD EXAMPLES I Very High Impact Skin cancer diagnosis II High Impact Software that analyzes heart rate, rhythm or other physiological parameters to detect if a patient condition under intensive care has critically deteriorated III Medium Impact Software that is used for the presenting heart rate or other physiological parameters during routine checkups to track long term progression of a condition IV Low Impact Software that allows patients to monitor their physiological health on a daily basis 21 February 2014 Page 9 of 25

10 SaMD Types 6.1 SaMD that supplies information as a sole determinant to treat: SaMD that supplies information which is the sole determinant to treat a disease or condition (e.g., radiation treatment planning software). Condition SaMD that supplies information which is the sole determinant to treat a critical condition are considered to be of very high impact and are categorized as Type I. Condition 1.1a -- SaMD that supplies information which is the sole determinant to treat in an imminent life threatening or life sustaining situation to the patient is considered to be of very high impact and are categorized as Type I. Condition SaMD that supplies information which is the sole determinant to treat a serious condition are considered to be of high impact and are categorized as Type II. Condition SaMD that supplies information which is the sole determinant to treat a non-serious condition are considered to be of medium impact and are categorized as Type III. 6.2 SaMD that supplies information which is the sole determinant to diagnose: SaMD that supplies information which is the sole determinant to diagnose a disease or condition (e.g., leads a user to determine drug intervention, determine medical device intervention / use of drug through a medical device). Condition SaMD that supplies information which is the sole determinant to diagnose a critical condition are considered to be of very high impact and are categorized as Type I. Condition 2.1a -- SaMD that supplies information which is the sole determinant to diagnose in an imminent life threatening or life sustaining situation to the patient are considered to be of very high impact and are categorized as Type I. Condition SaMD that supplies information which is the sole determinant to diagnose a serious condition are considered to be of high impact and are categorized as Type II. 21 February 2014 Page 10 of 25

11 Condition SaMD that supplies information which is the sole determinant to diagnose a non-serious condition are considered to be of medium impact and are categorized as Type III. 6.3 SaMD that Drives Clinical Management SaMD that supplies information which is used as an aid in treating or diagnosing or in screening, predicting, risk-scoring and monitoring disease or conditions requiring further user decisions or actions (e.g., leads a user to take actions to screen for a disease state, create a treatment plan, monitor conditions, and predict risks). Condition SaMD that supplies information which is used as an aid in treating or diagnosing or in screening a critical condition, are considered to be of high impact and are categorized as Type II. Condition SaMD that supplies information which is used as an aid in treating or diagnosing or in screening a serious condition, are considered to be of medium impact and are categorized as Type III. Condition SaMD that supplies information which is used as an aid in treating or diagnosing or in screening a non-serious condition, are considered to be of low impact and are categorized as Type IV. Condition SaMD that supplies information which is used in predicting or riskscoring a critical condition are considered to be of high impact and are categorized as Type II. Condition SaMD that supplies information which is used in predicting or riskscoring a serious condition are considered to be of medium impact and are categorized as Type III. Condition SaMD that supplies information which is used in predicting or riskscoring a non-serious condition are considered to be of low impact and are categorized as Type IV. Condition SaMD that supplies information which is used in monitoring a critical condition are considered to be of high impact and are categorized as Type II. 21 February 2014 Page 11 of 25

12 Condition SaMD that supplies information which is used in monitoring a serious condition are considered to be of medium impact and are categorized as Type III. Condition SaMD that supplies information which is used in monitoring a nonserious condition are considered to be of low impact and are categorized as Type IV. 6.4 SaMD that Informs Clinical Management SaMD that supplies information which is used in preventing/mitigating a disease or condition or to supplement clinical management of a disease or condition (e.g., software outputs used to supplement a user s information). Condition SaMD that supplies information which is used in preventing/mitigating a critical condition are considered to be of medium impact and are categorized as Type III. Condition SaMD that supplies information which is used in preventing/mitigating a serious condition are considered to be of low impact and are categorized as Type IV. Condition SaMD that supplies information which is used in preventing/mitigating a non-serious condition are considered to be of low impact and are categorized as Type IV. Condition SaMD that supplies information which is used to supplement clinical management of a critical condition are considered to be of medium impact and are categorized as Type III. Condition SaMD that supplies information which is used to supplement clinical management of a serious condition are considered to be of low impact and are categorized as Type IV. Condition SaMD that supplies information which is used to supplement clinical management of a non-serious condition are considered to be of low impact and are categorized as Type IV. 21 February 2014 Page 12 of 25

13 289 Table 2: Risk Type 1 Condition Examples Type I Condition SaMD that supplies information which is used to treat a critical condition are considered to be of very high impact and are categorized as Type I. Radiation planning and simulation system, surgery planning system for brain implantable Pulse Generator(IPG) programmer Condition 1.1a -- SaMD that supplies information which is used to treat in an imminent life threatening or life sustaining situation to the patient is considered to be of very high impact and are categorized as Type I. Software that monitors a combination of ventilator data and patient monitor respiratory system (RR, CO2, SpO2 etc) signals to determine if breathing assistance is needed and advises either specific changes to ventilator settings (e.g. increase FiO2, increase PEEP etc), or commencement of resuscitation efforts (Ventilator and breathing both stopped!), as appropriate Condition SaMD that supplies information which is used to diagnose a critical condition are considered to be of very high impact and are categorized as Type I. Software for cancer determination (CADx) Condition 2.1a -- SaMD that supplies information which is used to diagnose in an imminent life threatening or life sustaining situation to the patient are considered to be of very high impact and are categorized as Type I. Software that supplies information used to diagnose the presence of meningitis February 2014 Page 13 of 25

14 Table 3: Risk Type II Category Condition Examples Type II Condition SaMD that supplies information which is used to treat a nonserious disease or condition are considered to be of high impact and are categorized as Type II. Software intended to reduce tinnitus through music therapy Condition SaMD that supplies information which is used to diagnose a serious condition are considered to be of high impact and are categorized as Type II. Software intended for diagnosis of pediatric Attention Deficit Hyperactivity Disorder (ADHD) Condition SaMD that supplies information which is used as an aid in treating or diagnosing or in screening a critical condition are considered to be of high impact and are categorized as Type II. Software that evaluates proteomic patterns as an aid in early diagnosis of ovarian cancer Condition SaMD that supplies information which is used in predicting or risk-scoring a critical condition are considered to be of high impact and are categorized as Type II. Software that calculates stroke risk for patients with atrial fibrillation Condition SaMD that supplies information which is used in monitoring a critical condition are considered to be of high impact and are categorized as Type II. Software that evaluates proteomic patterns as an aid in monitoring ovarian cancer progression 21 February 2014 Page 14 of 25

15 Table 4: Risk Type III Category Condition Examples Type III Condition SaMD that supplies information which is used to treat a nonserious condition are considered to be of medium impact and are categorized as Type III. Software that uses the microphone to "listen" for sounds of interrupted breathing (during sleep apnea events) and sounds a short tone to rouse the sleeper "just enough" to limit the pause to an acceptable interval. Condition SaMD that supplies information which is used to diagnose a non-serious condition are considered to be of medium impact and are categorized as Type III. Software that helps pinpoint the causes and triggers for asthma so that patients/consumers can take appropriate action; software that monitors wheezing and responses to treatment Condition SaMD that supplies information which is used an aid in treating or diagnosing or in screening a serious condition are considered to be of medium impact and are categorized as Type III. Software that calculates the fractal dimension of a mole and surrounding skin and builds a structural map that reveals the different growth patterns of the tissues involved and alerts whether a medical visit is required Condition SaMD that supplies information which is used in predicting or risk-scoring a serious condition are considered to be of medium impact and are categorized as Type III. Software that is a risk assessment tool which uses information from the Framingham Heart Study to predict a person s chance of having a heart attack in the next 10 years 21 February 2014 Page 15 of 25

16 Category Condition Examples Condition SaMD that supplies information which is used in monitoring a serious condition are considered to be of medium impact and are categorized as Type III. Software intended for use in spectral analysis of heart rate fluctuations for the study of short-term cardiovascular control function on non- Myocardial Infarcted patients Condition SaMD that supplies information which is used in preventing/mitigating a critical condition are considered to be of medium impact and are categorized as Type III. Software that aids in the recovery of brain injuries, including stroke, through targeted gameplay individually tailored to the rehabilitation of the patient s condition with real-time data capture and analysis in order to provide information to therapists on patient progress and further improvement; software that provides daily puzzles and mental challenges to prevent or slow the onset of dementia Condition SaMD that supplies information which is used to supplement clinical management of a critical condition are considered to be of medium impact and are categorized as Type III. Software that collects information from laboratory results and displays this alongside the ICU monitor information February 2014 Page 16 of 25

17 300 Table 5: Risk Type IV Category Condition Examples Type IV Condition SaMD that supplies information which is used an aid in treating or diagnosing or in screening a non-serious condition are considered to be of low impact and are categorized as Type IV. Software that quantifies how patients with tinnitus (ringing in the ears) "hyper monitor" their tinnitus (the neurological phenomenon of perceiving tinnitus to be much louder than it is when measured objectively) Condition SaMD that supplies information which is used in predicting or risk-scoring a non-serious condition are considered to be of low impact and are categorized as Type IV. Software used in the evaluation of skin lesions or in automatically evaluating the extension of the involved area in the SCORAD index, e.g., atopic dermatitis Condition SaMD that supplies information which is used in monitoring a non-serious condition are considered to be of low impact and are categorized as Type IV. Software that enables smart phones to detect anomalies in sleep, by comparing movements to normal sleeping and waking patterns Condition SaMD that supplies information which is used in preventing/mitigating a serious condition are considered to be of low impact and are categorized as Type IV. Software that monitors public sources of pollen count data along with the user s health conditions to alert asthma sufferers from engaging in prolonged outdoor activities Condition SaMD that supplies information which is used in preventing/mitigating a non-serious condition are considered to be of low impact and are categorized as Type IV. Software that allows patients to monitor their physiological health on a daily basis and provides a link to their health care team from their home 21 February 2014 Page 17 of 25

18 Condition SaMD that supplies information which is used to supplement clinical management of a serious condition are considered to be of low impact and are categorized as Type IV. Scoring software to assess postoperative pain to assist with pain management follow-up Condition SaMD that supplies information which is used to supplement clinical management of a non-serious condition are considered to be of low impact and are categorized as Type IV. Software used to track insulin intake and glucose levels, and compare any changes in glucose levels with daily activities. May include charts, graphs, and tables to help patient and healthcare provider identify patterns and problems and make therapy adjustments February 2014 Page 18 of 25

19 SaMD Controls Manufacturers of a SaMD are expected to undertake appropriate controls for mitigating risk to an acceptable level and for achieving the intended performance. Generally controls that are typically applicable for a medical device may also be considered by the manufacturer for applicability for a specific SaMD. This section discusses controls that should be considered for a SaMD, based upon the SaMD framework. There is a common expectation that a SaMD is developed in a safe and effective manner using quality management principles that are commonly found in best industry practices. The recommended controls for all types of SaMD are: i. a quality management system (QMS), including ii. a system for post-market surveillance, iii. technical documentation, Quality Management System The manufacturer should implement, document and maintain a QMS that ensures the SaMD it designs and supplies to the market are safe and effective and perform as intended. The scope and complexity of the QMS are influenced by the range of different SaMD types. Since manufacturing and final control are not considered as QMS elements that effectively mitigates risk for SaMD, emphasis should be on controls focused on the elements of quality systems that include good design and development practice including human factors design, software testing, configuration and change management (version control) and risk management principles. Post Market Surveillance As for all medical devices, the manufacturer should establish, as part of its QMS, a process to monitor the safety, effectiveness and reliability of its SaMD. The inherent nature of SaMD allows for efficient methods to understand and capture user experiences. It is recommended that where feasible SaMD manufacturers utilize these more sophisticated and easier to use feedback techniques to understand failure modes and perform analysis (though admittedly it may not always be easy to isolate and attribute cause directly to the SaMD) to address safety situations. This process should include complaint handling and any subsequent corrective & preventive actions. Special considerations specifically associated to SaMD include: 1) Due to its non-physical nature, a SaMD may be duplicated in numerous copies and widely spread, often outside the control of the manufacturer. 2) Often an update made available by the manufacturer is left to the user of the SaMD to install. Although the user may have legitimate reasons for not performing the installation, such as lack of resources, it is a crucial task for the manufacturer to 21 February 2014 Page 19 of 25

20 ensure that the update is implemented in a timely fashion. Failure to do so may result in different versions of the SaMD on the market. 3) Incident investigations needs to take into considerations any specific case or combination of use cases that may have contributed to the failure. Although similar to hardware medical devices, these combinations may be far more complicated and require exhaustive verification techniques. Technical Documentation The manufacturer should prepare and hold technical documentation that shows how each SaMD was developed and designed together with the descriptions and explanations necessary to demonstrate that the SaMD are safe and effective/perform as intended. This technical documentation is updated as necessary to reflect the current status, specification and configuration of the device. Particular attention should be made to the documentation accompanying the device, Clinical Evidence and Non-Clinical Performance Evidence. The documentation accompanying the device (i.e., Labeling which includes Instructions for Use) should include the SaMD description. Clinical Evidence contains a Clinical Evaluation and Clinical Data 3. In a Clinical Evaluation the manufacturer assesses Clinical Data to verify the clinical purpose and capabilities that are being claimed for a medical device and to verify the clinical safety, effectiveness and performance of a device. Clinical Data is safety, effectiveness and/or performance, information that is generated from the clinical use of a medical device. The Clinical Evaluation should be closely related to the Risk Management Process and the Usability Engineering Process. The general principles for Clinical Evaluation in GHTF SG5/N2R8:2007 are applicable for SaMD. All medical devices, irrespective of type, must undergo Clinical Evaluation, unless the manufacturer can demonstrate that it is not necessary or appropriate. E.g. for software the possibilities to perform bench tests and simulations, not involving patients, may to a greater extent replace the need for some Clinical Data. If relevant Clinical Data is deemed necessary, but doesn't exist, the manufacturer must conduct a clinical trial. Clinical evaluation involves analysis and evaluation of clinical data applicable for a medical device. Clinical evaluation is a continuous process that shall be carried out during the entire life cycle of a device. It starts during the design phase, before the device is placed on the market, and is thereafter continuously updated at regular intervals with new clinical experiences about the device s safety from daily use. This information is fed back to the manufacturer's risk management process where it is used. 3 GHTF SG5/N1R8:2007 Clinical Evidence- Key Definitions and Concepts; GHTF SG5/N2R8:2007 Clinical Evaluation 21 February 2014 Page 20 of 25

21 Table 6 below provides an example of how controls could be applied for the different types of SaMD. These may vary for particular circumstances such as availability of clinical data, clinical novelty and the results of the risk management process. The X indicates where mechanisms for assessing conformity for the controls indicated may be achieved through an independent verification (3 rd party) or regulatory oversight. The absence of X indicates that manufacturers of SaMD should follow due process (including quality management systems process, configuration management, risk management and maintaining technical documentations, clinical evaluation). Clinical effectiveness control highlighted in Table 6, indicates that the data generated by the clinical evaluation should also include the effectiveness of the information provided by the SaMD. The X for this control indicates that for the very high impact SaMD this effectiveness data should undergo independent verification. Clinical safety and performance control highlighted in Table 6, indicates that the data generated by the clinical evaluation process should also include the clinical safety and performance of the information provided by the SaMD. The Xs for this control indicates that for the very high impact (Type I) and high impact (Type II) SaMD this data should undergo independent verification. 21 February 2014 Page 21 of 25

22 394 Table 6: Example of How Controls Could Be Applied for Different SaMD Types Summary of Controls I II III IV Risk Management ISO X X X X Software development lifecycle IEC class A requirements X X Software development lifecycle IEC class B requirements X Software development lifecycle IEC class C requirements X Labeling 4 accompanying the device X X X X Clinical effectiveness X Clinical safety and performance X X Clear clinical efficacy statement accompanying the SaMD may be based on bench test, simulated, or already available set of data. X X SaMD Changes Manufacturers of all medical devices are expected to have an appropriate level of control to manage SaMD changes. Due to the non-physical nature of software, a software change management process needs specific considerations to achieve the intended result regarding traceability and documentation. With any product lifecycle, change is inevitable. Software failures occur and may be due to errors, ambiguities, oversights or misinterpretation of the specification that the software is supposed to satisfy, carelessness or incompetence in writing code, inadequate testing, incorrect or unexpected usage of the software or other unforeseen problems. Once perfectly working software may also break if the running environment changes. Changes to software can affect its safety, quality and performance. SaMD changes refer to any modifications made throughout the lifecycle of the SaMD including the maintenance phase. The nature of software maintenance changes can include adaptive (e.g. keeps pace with the changing environment), perfective (e.g. recoding to improve software performance), corrective (e.g. corrects discovered problems), or preventive changes (e.g. corrects 4 Includes instructions for use, user documentation and other accompanying (GHTF SG1 N70:2011 Labels and Instructions for Use for Medical Devices) 21 February 2014 Page 22 of 25

23 latent faults in the software product before they become operational faults). These changes should be clearly identified and defined with a method of tracing the change to the specific affected software. In order to effectively manage the changes and their impact, manufacturers must perform a risk assessment to determine if the change(s) affect the risk classification and the core features of the SaMD as outlined in the definition statement. Changes that effect core functionality (identified by the manufacturer in the SaMD definition statement) or to changes that are necessary to maintain safety profile identified through risk management process for a SaMD type I (treat or diagnose) are important significant changes that require independent oversight to assure that the change made does not adversely affect the safety profile, performance or use of SaMD type I. 21 February 2014 Page 23 of 25

24 Appendix 8.1 Clarifying SaMD Definition This Appendix provides a representative list of features and functionalities that either meet or don t meet the definition of SaMD. This list is not exhaustive; it is only intended to provide clarity and assistance in identifying when a feature or functionality is considered to be a SaMD. Examples of devices that are SaMDs: - Medical purpose software that could operate on a general purpose computing platform which has no medical purpose is a SaMD. For example a medical plug-in running on a consumer digital camera. - Software with a medical purpose of its own that is connected to or part of a medical device without being needed by the medical device to achieve its intended purpose is a SaMD and not an accessory. For example, software that allows a commercially available smartphone to view images obtained from an ultrasound sensor connected to the smart device is a SaMD. Note: it does not make the smartphone a medical device. - Software with a medical purpose that receives information from a second medical device, where the software is not needed by the second device to achieve its intended medical purpose is a SaMD. For example, software that performs image post-processing for the purpose of aiding in the detection of breast cancer (CAD), whether loaded on an imageacquisition medical device or not, is a SaMD. - Medical purpose software that requires data from a medical device or from other sources is a SaMD and not an accessory to the medical device that provides the data. For example, software used in an intensive care unit that centralizes information from patient monitoring sensors to analyze according to specified parameters. - Medical purpose software that provides parameters which become the input for a different medical device is a SaMD. The different medical device could or could not be a SaMD. For example, a treatment planning software is a SaMD that supplies information which is used in a linear accelerator. Examples of devices that are not SaMDs: - Software that relies on data from a medical device, but does not have a medical purpose, is not a SaMD. For example, software that encrypts data for transmission from a medical device is not a SaMD. - Software that monitors performance or proper functioning of a device for the purpose of servicing the device is not a SaMD. For example, software that monitors X-Ray tube performance to anticipate the need for replacement is not a SaMD; or software that integrates 21 February 2014 Page 24 of 25

25 and analyzes laboratory quality control data to identify increased random errors or trends in calibration on IVDs is not a SaMD. - Software that provides parameters which become the input for a SaMD is not a SaMD if it does not have a medical function. For example, a reference database used by a SaMD is not a medical device and therefore not a SaMD. - Software needed by a hardware medical device to perform the hardware s medical device intended use is not a SaMD. For example, software that controls an infusion pump is not a SaMD, it is considered part of the infusion pump. 8.2 Recommendations on specific controls that may apply to SaMD Selection and implementation of a quality-assured formal process for the planning, design, development, deployment, and documenting of robust and dependable software is commensurate with its risk criticality as informed by its intended purpose and foreseeable use. An efficient process for the development of correct and reliable software Development of software in a quality-assured manner involves the appropriate selection and implementation of software design and development methods that: include a formal development process using models, methods, architecture, and designmodelling techniques appropriate for the development language(s) and the safety criticality of the device s intended purpose and foreseeable use covering different software lifecycle stages o e.g., via compliance with IEC 62304, SWEBOK guide implemented with suitable tools o which are linked in a systematic way o and which systematically produce, derive or generate detailed design source code traceability records and test specifications Also see Design Methodology (SE VOCAB, IEEE Computer Society,, Wash DC, Technical measures are not always sufficient or feasible to mitigate all the consequences of using SaMD 21 February 2014 Page 25 of 25