Draft

IMDRF/SaMD WG/N81 DRAFT: 2024

Medical Device Software:

Considerations for Device and
Risk Characterization

AUTHORING GROUP

IMDRF Software as a Medical Device Working Group

29 January 2024
IMDRF/SaMD WG/N81 DRAFT: 2024

Preface
© Copyright 2024 by the International Medical Device Regulators Forum.
This work is copyright. Subject to these Terms and Conditions, you may download,
display, print, translate, modify and reproduce the whole or part of this work for your
own personal use, for research, for educational purposes or, if you are part of an
organisation, for internal use within your organisation, but only if you or your
organisation do not use the reproduction for any commercial purpose and retain all
disclaimer notices as part of that reproduction. If you use any part of this work, you must
include the following acknowledgement (delete inapplicable):
“[Translated or adapted] from [insert name of publication], [year of publication],
International Medical Device Regulators Forum, used with the permission of the
International Medical Device Regulators Forum. The International Medical Device
Regulators Forum is not responsible for the content or accuracy of this
[adaption/translation].”
All other rights are reserved and you are not allowed to reproduce the whole or any part
of this work in any way (electronic or otherwise) without first being given specific written
permission from IMDRF to do so. Requests and inquiries concerning reproduction and
rights are to be sent to the IMDRF Secretariat.
Incorporation of this document, in part or in whole, into another document, or its
translation into languages other than English, does not convey or represent an
endorsement of any kind by the IMDRF.

Jeffrey Shuren, IMDRF Chair

2
IMDRF/SaMD WG/N81 DRAFT: 2024

Contents

1. Introduction 4
2. Purpose and Scope 6
2.1. Purpose of the document 6
2.2. Scope of the document 6

3. References 8
4. Device Characterization Considerations 9
4.1. Intended Use/Intended Purpose Statement 9
4.2. Device Description - Medical Device Software 10

5. Medical Device Software Risk Characterization 18

5.1. Identification and Analysis 20
5.2. Estimation 20
5.3. Approaches for Risk Categorization 21

6. Considerations for Implementation 23

Appendix A: Sample Intended Use/Intended Purpose Statement 24
Appendix B: Characterization Feature Summary Table 25
Appendix C: Example Considerations to Understand Software
Hazards Associated with Device Design and Intended Use 29
Appendix D: Example of Discussing Information Risk in
Application to Risk Characterizations 34
Appendix E: Examples Comparing Specific Risk Considerations 43

3
 IMDRF/SaMD WG/N81 DRAFT: 2024

1 1. Introduction
2 Software plays an increasingly critical role in healthcare, with a wide range of products
3 serving a variety of medical and administrative purposes in a range of clinical or
4 private settings. A subset of software that is used in healthcare is regulated as a
5 medical device globally by regulatory authorities.

6 In 2013 the International Medical Devices Regulators Forum (IMDRF) introduced the
7 concept of Software as a Medical Device (SaMD) and subsequently proposed a
8 possible risk categorization framework (IMDRF/SaMD WG/N12 FINAL:2014). Building
9 on the collective experience of its members, the IMDRF SaMD WG now has an
10 opportunity to add to those initial concepts by providing guidance related to device
11 characterization and risk characterization, for a broadened scope of medical device
12 software.

13 The term “SaMD” has evolved to include a more diverse landscape of software and
14 varied interpretations across jurisdictions. The concepts presented in this document
15 are not exclusive to any specific interpretation of the term SaMD, rather can be helpful
16 to consider more broadly for any software that meets the definition of a medical
17 device.

18 In this document we refer to this relevant set of software as “medical device software”
19 as a shorthand for document useability. This complex collection of software includes
20 various intersecting and distinct subsets, for example:
21
22 • Software that is intended to generate information for use in achieving one or more
23 medical purpose;
24 • Software that is part of a hardware medical device;
25 • Software that is not part of a hardware medical device and independent of other
26 medical devices);
27 • Software that is necessary for a hardware medical device to achieve its intended
28 use/intended purpose;
29 • Software that is driven or influenced by another medical device;
30 • Software with an output intended for a human user, medical device, and/or non-
31 medical device;
32 • Software that uses inputs from humans, medical devices, and/or products that are
33 not medical devices.

4
 IMDRF/SaMD WG/N81 DRAFT: 2024

34 Medical device software can operate in complex socio-technical environments—

35 consisting of software, hardware, information technology networks, and people—
36 which form a complex and dynamic interaction between the software function, its
37 inputs and outputs, the intended user, and the unique healthcare circumstances in
38 which the software is used. This complexity together with the interconnectedness of
39 systems, the need for cybersecurity, the speed and frequency of development cycles,
40 the speed at which a solution can be scaled up, and the various aspects of change
41 implementation contribute to the accurate depiction of a device and/or its risk-profile.
42 Medical device software can pose risks that are distinct and unique, such as those
43 that relate to the information that is generated and output by the device and the
44 capacity for varied degrees of clinical autonomy. These devices may be used
45 independently or as part of a platform and span a wide spectrum of risk profiles
46 depending on the intended use, and potential harms associated with use and/or
47 erroneous outputs.

48 The clear and accurate characterization of a medical device software is fundamental

49 and supports device quality, risk management, regulatory decision-making and device
50 use in healthcare. Stakeholders (including manufacturers, regulators, healthcare
51 providers, end-users, and patients) need to understand what a medical device
52 software is, its purpose, its context of use, how it works and how it changes due to
53 updates. This information can be necessary for proper use and to identify and
54 evaluate the associated hazards, direct and indirect harms, risks and benefits, and to
55 determine device risk classifications.

56 Risk-based device classifications, applied in accordance with each jurisdiction’s

57 regulations, assign the appropriate regulatory obligations in each jurisdiction.
58 Assigning risk categories to these devices can be challenging due to the broad range
59 of technologies and characteristics that can influence risk, the variety of terminology
60 and interpretations used to describe and qualify these devices, as well as the range of
61 classification systems across global regulatory jurisdictions. This document identifies
62 common considerations regarding device characterization and risk characterization to
63 provide a harmonized lens and common language for improved transparency and
64 consistency between stakeholders. This work can help support comprehensive
65 descriptions of medical device software, thorough risk assessments for those devices,
66 as well as interpretations of jurisdictions’ classification approaches for these products.

5
 IMDRF/SaMD WG/N81 DRAFT: 2024

67 2. Purpose and Scope

68 2.1. Purpose of the document
69 The objective of this document is to promote and inform clear and accurate
70 characterizations of medical device software (including intended use/intended purpose
71 statements) and introduce a general strategy for characterizing software-specific risks
72 that leverages the key features of a comprehensive medical device software
73 characterization.

74 This document is intended to:

75 • Highlight the importance of comprehensive characterizations for medical device
76 software;
77 • Establish key features of and common vocabulary for the characterization of
78 medical device software;
79 • Identify fundamental elements of an intended use/intended purpose statement for
80 medical device software;
81 • Establish links between characterization features and risk for medical device
82 software;
83 • Provide information for consideration during the identification and assessment of
84 medical device software risks.

85 2.2. Scope of the document

86 This document applies to the subset of software that meets the definition of a medical
87 device (referred to throughout as medical device software), including software that
88 meets the definition of Software as a Medical Device (SaMD) as is defined in the
89 document, IMDRF SaMD WG N10 Software as a Medical Device: Key Definitions.
90 • This document focuses on medical device software irrespective of the software
91 technology and/or the platform (e.g., mobile app, cloud, server, hardware medical
92 device).
93 • This document is not intended to provide guidance on the regulatory status or
94 classification of products that are not medical devices and provide inputs to
95 software that meets the definition of a medical device.
96 • This document focuses on software-specific risk considerations and is not intended
97 to be comprehensive of all relevant risk considerations for a medical device
98 software, which may also include additional risks related to interoperable or
99 associated hardware.
100 • This document is not intended to replace or conflict with existing risk management
101 practices or the development of technical or process standards related to software
102 risk management activities. This document relies on established risk management
103 principles, such as those in ISO 14971Risk Management for Medical Devices, in
104 the context of medical device software.

6
 IMDRF/SaMD WG/N81 DRAFT: 2024

105 • This document is not intended to replace or conflict with existing IMDRF
106 publications such as those published by the Artificial Intelligence (AI) or
107 Cybersecurity Working Groups; however, it is acknowledged that there are direct
108 relationships and overlap with those publications, and this document is intended to
109 be complementary.
110 • The content in this document is not regulation and does not imply a convergence of
111 regulations or categorization rules across jurisdictions. Additional work may be
112 required to apply and align these concepts in a given jurisdiction.

7
 IMDRF/SaMD WG/N81 DRAFT: 2024

113 3. References
114 • IMDRF SaMD WG N10 FINAL:2013 Software as a Medical Device: Key
115 Definitions

116 • IMDRF/GRRP WG/N52:2019 Principles of Labelling for Medical Devices and

117 IVD Medical Devices

118 • GHTF/SG1/N77 Principles of Medical Devices Classification

119 • ISO 14971:2019 Medical Devices - Application of Risk Management to

120 Medical Devices

121 • TIR57: 2016/(R)2023 Principles for medical device security—Risk

122 management

123 • IEC 80001-1:2021 Application of risk management for IT-networks

124 incorporating medical devices

125 • IEC 62304 Medical device software — Software life cycle processes

126 • AAMI TIR57 Principles for medical device security – Risk Management

127 • AAMI TIR34971 Application of Iso 14971 To Machine Learning In Artificial

128 Intelligence—Guide

8
 IMDRF/SaMD WG/N81 DRAFT: 2024

129 4. Device Characterization

130 Considerations
131 The communication of a comprehensive medical device software characterization
132 (including the intended use/intended purpose and device description) supports
133 stakeholders’ ability to understand the device and characterize the associated risks
134 and benefits. This will inform decision-making and help ensure device safety,
135 effectiveness and proper use.

136 Numerous elements contribute to a comprehensive medical device software

137 characterization, such as the medical purposes, intended users, intended use
138 environment, and intended target populations, as well as the role and timing of the
139 software’s use and output in the clinical or healthcare workflow. The characterization
140 should clearly describe what the device is and is intended to do, as well as how,
141 where, when and by whom the software is intended to be used and modified.

142 This information is essential for identifying and validating the relevant user and clinical
143 requirements, assessing the adequacy of supporting evidence, identifying and
144 controlling risks, determining user-centered labelling and transparency requirements,
145 managing product changes, ensuring proper use while mitigating against misuse, and
146 enabling patient-centered healthcare.

147 The following two sub-sections discuss considerations for manufacturers when
148 characterizing medical device software within the intended use/intended purpose
149 statement and device description. These considerations can support the determination
150 of the pertinent and meaningful information to include within medical device software
151 documentation, regulatory submissions, device labelling and user interfaces. All
152 features and attributes listed may not be relevant for every device but are included for
153 consideration. What is communicated will be dependent on the stakeholder and the
154 characteristics determined to have an impact on risk for the specific device.

155 4.1. Intended Use/Intended Purpose Statement

156 The intended use/purpose is defined within the GHTF/SG1/N77 Principles of Medical
157 Devices Classification document as the objective intent of the manufacturer regarding
158 the use of a product, process or service as reflected in the specifications, instructions
159 and information provided by the manufacturer.
160 The concept of an intended use/purpose statement is familiar in many jurisdictions
161 and is typically expected to appear within the device labelling to capture the intended
162 device function and medical purpose, including the indicated diseases, conditions and
163 / or circumstances for which the device is intended to be used. Such statements are
164 generally most useful when they are sufficiently specific and avoid excessively general
165 and/or open-ended language. It is acknowledged that the intended device function and
166 indicated diseases may be considered separate in certain jurisdictions. However, for
167 the purposes of this document, both are relevant and are suggested to be clearly
168 described. For some devices, certain information contained in the sample intended
169 use/intended purpose statement may be included elsewhere in the medical device
170 software labelling, as appropriate.

9
 IMDRF/SaMD WG/N81 DRAFT: 2024

171 In order to foster and encourage clear and comprehensive intended use statements
172 for medical device software, Key Elements of an intended use/intended purpose
173 statement are captured in section 4.1.1 below. A sample statement guide can be
174 found in Appendix A. It is important to note that not all elements will be applicable to
175 every medical device software and the information provided in these sections is solely
176 for consideration by manufacturers in the development of the medical device software
177 labelling, documentation and regulatory submissions, as appropriate. The sample
178 statement may not be appropriate for all medical device software depending on the
179 technology and intended use.

180 4.1.1. Key Elements of Intended Use/Intended Purpose Statement

181 1. Medical Purposes
182 2. Intended Conditions/Diseases/Disorders and Grade/Stage/Level
183 3. Intended Patient Populations
184 4. Intended Users
185 5. Intended Use Environment
186 6. Contraindications
187 7. Medical device software function, including:
188 • Medical device software inputs
189 • Medical device software outputs
190 • Explanation of how the medical device software inputs and outputs fit into
191 the clinical or healthcare workflow

192 4.2. Device Description - Medical Device Software

193 A detailed medical device software description, accompanying the intended
194 use/purpose statement, is often needed to ensure the comprehensive and adequate
195 communication of all necessary characteristics and information related to a medical
196 device software.

197 The following four subsections discuss detailed and interrelated information that can
198 be relevant to the characterization of a medical device software, organized according
199 to the following four types or categories of information:

200 • Medical problem and/or objective

201 • Context of use
202 • Function and/or use
203 • Change management
204 The information within each category is presented in the form of characterization
205 features with attributes. This non-exhaustive set of considerations for manufacturers is
206 intended to highlight and clarify some important aspects when characterizing a
207 medical device software. The features and attributes within each subsection are
208 tabulated proceeding the discussion; the full set of features and attributes are provided
209 in a summary table in Appendix B.

10
 IMDRF/SaMD WG/N81 DRAFT: 2024

210 4.2.1. Medical Problem and/or Objective

211 The medical problem or objective a given medical device software is used for solving
212 or addressing is an important piece of the overall device characterization. This feature
213 can be further broken down into the specific medical purpose, the intended
214 conditions/diseases/disorders, and the intended patient population.

215 A medical device may be used in different stages of the care pathway, such as
216 diagnosis (e.g., primary diagnosis, screening, triage, staging, etc.); treatment (e.g.,
217 relieving symptoms or restoring function); prevention (e.g., averting the occurrence of
218 a disease or condition); prediction (e.g., disease prognosis, anticipated treatment
219 response, etc.) or monitoring (e.g., ongoing assessment of patient parameters).
220 Understanding the specific medical purpose that the device performs or is used in
221 achieving is a key part of characterizing the medical device software.

222 The condition or disease for which the medical device software is meant to be applied,
223 and the general state of that condition or disease (for example, the grade, stage or
224 level), are important pieces of information at the center of characterizing a medical
225 device software and determining the associated criticality or seriousness of the
226 situation and importance of the output.

227 Finally, the intended patient population provides an important boundary within which
228 the medical device software is meant to apply and another defining feature of the
229 medical device software characterization. In this document, the term patient is used to
230 refer to individuals that receive or await healthcare with the use of the medical device
231 software. The intended patients may be in a specific subgroup of the population (e.g.,
232 specific age, sex, gender, ethnicity, race, disability, diagnosis; or a fragile and/or
233 vulnerable group; etc.), or specific intersection of subgroups of the population (e.g.,
234 specific age group + specific sex + those at risk of a specific condition)

235 The following table summarizes the identified features and attributes that help
236 characterize the medical problem and/or objective.

237 Table 1 Features and attributes for the characterization of the

238 medical problem and/or objective

Characterization Feature Potential Feature Attributes

Medical Purpose Diagnosis (e.g., primary diagnosis, screening, triage, etc.), Prevention,
Monitoring, Mitigation, Prediction, Treatment, etc.

Intended Conditions/Diseases/ Critical, Serious, Non-Serious condition or disease, including consideration

Disorders and Grade/Stage/Level of level of progression/stage/ grade (e.g., a chronic condition or an acute change
in a chronic condition)

Intended Patient Population General population,

Specific subgroup of the population (e.g., fragile and/or vulnerable subgroup;

specific age group, sex, gender, ethnicity, race, disability, diagnosis, etc.), or

11
 IMDRF/SaMD WG/N81 DRAFT: 2024

Specific intersection of subgroups of the population (e.g., specific age

group + specific sex + those at risk of a specific condition)

239 4.2.2. Context of Medical Device Software Use

240 The characterization of medical device software extends beyond the device, into the
241 intended circumstances and setting for medical device software use. Two otherwise
242 identical products with different intended contexts of use are distinct devices with
243 different medical device software characterizations. Aspects of that context of use
244 include the intended user of the medical device software as well as the intended use
245 environment.

246 The intended user could be a non-clinical user, a non-physician medical professional,
247 a general practitioner medical doctor (MD), a specialist physician, or a combination of
248 these users. A non-clinical user, or lay-user, includes those users that are not trained
249 or qualified to provide medical care, which might include a caregiver or patient user, or
250 other users without medical qualifications. Licensed medical professionals that are
251 non-physicians include nurses, dentists, psychologists, radiation therapists,
252 physiotherapists, etc. General practitioner (GP) medical doctors include, for example,
253 primary care physicians or family doctors, while specialist physicians include
254 radiologists, oncologists, dermatologists, psychiatrists, pathologists, surgeons, etc.

255 The intended use environment describes the setting in which patient healthcare, with
256 the medical device software, is meant to take place. This could be a non-clinical
257 environment, a general healthcare environment, or a specialty healthcare
258 environment. A non-clinical environment would include home-use; general healthcare
259 environments would include primary care clinics, dental offices, etc.; and a specialty
260 healthcare environment would include, for example, emergency rooms, intensive care
261 units, dermatology clinics, surgical operating rooms, and oncology departments within
262 a hospital.

263 Another important aspect of the context of use is the finality of the software output
264 and/or its weight in relation to the outcome of the healthcare task/intervention. The
265 timing within the healthcare task/intervention is a feature that helps to contextualize
266 the output in terms of being early, midway, or late in the healthcare task/intervention.
267 Similarly, the role of the software output within the healthcare task/intervention
268 illustrates the relationship of the output amongst the steps in the healthcare
269 task/intervention, in terms of relative chronology and the software’s dependence on
270 and/or input to the other steps. Taken together, these two features help to describe
271 the impact or influence a software may have on the overall trajectory and outcome of a
272 patient’s care. These are important to understand the “weight” of the software’s use
273 and can help to identify where and how effects from the software use can alter the
274 course of a patient’s healthcare experience.

275 The following table summarizes the identified features and attributes that can help
276 characterize the context of use.

12
 IMDRF/SaMD WG/N81 DRAFT: 2024

277 Table 2 Features and attributes for the characterization of

278 medical device software context of use

Characterization Feature Potential Feature Attributes

Intended User Lay user/nonclinical user (e.g., caregiver, patient user, user without medical
qualifications),

Licenced medical professional, non-physician (e.g., registered nurse,

dentist, psychologist, radiation therapist, physiotherapist, etc.),

General Practitioner (e.g., Primary care physician, family doctor, registered

nurse practitioner),

Specialist Healthcare Physician (e.g., radiologist, oncologist, dermatologist,

pathologist, surgeon, etc.)

Intended Use Environment Non-clinical Environment (e.g., home-use),

General Healthcare Environment (e.g., primary care clinic, virtual primary

healthcare),

Specialty Healthcare Environment (e.g., hospital, specialty clinic, virtual

specialty healthcare)

Timing Within Healthcare Early (e.g., triage, prediction of future diagnoses, early investigations upon
Task/Intervention suspicious symptoms or information, physiological signal or medical image
acquisition for use in diagnosis or treatment planning),

Midway (e.g., signal or image segmentation for use in diagnosis or treatment

planning; routine monitoring of patient health for clinically relevant changes
requiring further care and not including acute scenarios),

Late (e.g., optimal image-guided treatment plan or dosage for consideration;

adjunct diagnostic recommendations or second checks; continuous glucose
monitor output analysis automatically driving basal insulin dosage; image-
guided instrument control in robotic surgery; autonomous detection and
diagnosis of diabetic retinopathy)

* Note: these 3 phases (Early, Midway and Late) described above serve as
reference points, and it is not crucial to state which phase should be applied.
Rather, it is important to characterize the timing of the output relative to the
final intervention, decision, or action as well as the relative chronology of how
the product will be introduced in relation to other steps (e.g., prior steps,
concurrent steps, conditional steps, subsequent steps) and current standard
medical practices.

Role Of Software Output Within Software output’s relationship to the healthcare task/intervention steps,
the Healthcare Task/Intervention such as the output’s contribution to the relevant healthcare decision or action
(for example, intended as an aid that is combined with current practice);
alteration of standard/current practice (for example, intended to replace or
substitute all or part of current practice, to provide a new scheme, etc.);
dependence on other steps (e.g., uses output values or clinical decisions from
prior steps, concurrent steps, conditional steps); and/or influence over other
steps (e.g., provides input to concurrent steps, subsequent steps, conditional
steps, or final intervention/decision).

13
 IMDRF/SaMD WG/N81 DRAFT: 2024

279 4.2.3. Medical Device Software Function and/or Use

280 The function and use of a medical device software can be described by various
281 aspects, such as the generation of outputs, the output itself and how that output fits
282 into the care pathway.

283 The types of output provided by a medical device software could be a clinical
284 interpretation or intervention, a workflow recommendation, or data or information for
285 use in a medical purpose. Clinical interpretations or interventions can include, for
286 example, a probability, prediction, detection, diagnosis, severity, prognosis, grade, or
287 stage of a disease or condition; or the prescription, treatment, therapy, recommended
288 dosage or treatment plan for a disease or condition. A workflow recommendation, in
289 contrast, is not an interpretation on the clinical decision or action but rather an
290 intermediate step in the workflow, such as recommended contrast dye dosage;
291 imaging technique, modality, or parameters; surgical tool choice; supplementary
292 medical tests, etc. Data for use in medical purpose is output by a medical device
293 software for use in a medical purpose and is typically more objective, such as
294 anatomy measurements or volumes, segmented or contoured organs, tissues;
295 processed, reconstructed, or de-noised images; processed signals or waveforms such
296 as from electrocardiographs or electroencephalographs.

297 The input to the medical device software influences the function of the device and is
298 fundamental to understanding the medical device software, the output, and the
299 associated risks and considerations. The source of those inputs may be a human user
300 (e.g., patient inputted symptoms or conversations), a medical device (e.g., a medical
301 image), or a non-medical device or consumer product (e.g., smart-phone photos, EHR
302 data from patient chart). Notably, the inputs to a medical device software do not
303 necessarily have to be medical information or to come from a medical device.
304 Regulators may consider the impact that non-medical data or data sources have on
305 the safety and effectiveness of a medical device software. However, the use of non-
306 medical data sources in a medical device software does not change the regulatory
307 status of the source of non-medical data.

308 The level of automation of the task and output refers to the degree to which the output
309 requires and receives review and approval by the user, which can range from fully
310 automated or conditionally automated to semi-automated, and manual. A fully
311 automated output does not require review or approval and cannot be modified by the
312 user, while conditionally automated tasks have some outputs that are flagged for
313 review and the user has a way to go back and edit the output, for example if it is
314 assigned low confidence or high risk. Semi-automated outputs are made available for
315 critical assessment and approval or editing and, finally, for manual outputs, the user
316 controls the generation of the output. The level of automation is determined
317 irrespective of whether the user is a clinical or non-clinical user.

318 The degree of clinical autonomy is a spectrum of capacities or liberties to operate

319 independently of a clinical user’s guidance. An autonomous device provides outputs
320 that impact the subsequent clinical action or decision without a clinical user in the loop
321 (for example, with no user in the loop or a non-clinical user in the loop). Conditionally
322 autonomous outputs will meet this condition selectively (for example, for certain
323 results, input characteristics, or circumstances). Supervised outputs can impact
324 subsequent clinical actions or decisions without a clinical user having to approve the
325 output but operate under the supervision of adequately qualified clinical intended
326 users. Non-autonomous outputs are typically intended to augment, assist, or inform a
327 clinical user in their determination of a clinical decision or action.

14
 IMDRF/SaMD WG/N81 DRAFT: 2024

328 The level of intelligibility, transparency, and explainability of the underlying logic is also
329 an important characteristic of a medical device software. This includes the information
330 about the software algorithm or technology utilized (such as, deterministic formulae;
331 machine learning approaches; mathematical simulations; etc.) and information about
332 how an output or result was reached or the basis for a decision or action. This aspect
333 could be attributed as explained and comprehensible; partially explained or partially
334 evaluable (e.g., output provided with saliency maps); or as not explained or
335 incomprehensible (e.g., Black Box). Understanding this aspect of a medical device
336 software contributes to the assessment of risks and uncertainties, as well as
337 determining supporting evidence expectations.

338 The destination or target of the output could include outputs intended to be provided to
339 human users, or to medical devices or consumer products (either with or without
340 intermediate use by a human user).

341 The following table summarizes the identified features and attributes that can help
342 characterize the device function and/or use.

343 Table 3 Features and attributes for the characterization of

344 medical device software function and/or use

Characterization Feature Potential Feature Attributes

Output Type Clinical Interpretation or Intervention (e.g., diagnosis, suspicion,

probability, prediction, detection, severity, prognosis, grade, stage, direct
markers of a diagnosis, prescription, treatment/therapy, recommended
treatment, recommended dosage, radiation treatment plan),

Workflow Recommendation (e.g., contrast dye dosage; recommended

imaging technique/modality/parameters; recommended surgical tool choice;
recommended additional test based on established guidelines),

Data for use in medical purpose (e.g., anatomy measurement, volume, or

segmentation; processed image/image reconstruction/de-noised image;
processed signal/waveform (e.g., processed ECG))

Input Source From human user, medical device, or consumer product

Level of Task Automation Fully automated (i.e., output does not require review/approval and cannot
be modified by the user),

Conditionally automatic (some outputs are flagged for review or user has
a way to go back and edit the output, for example if assigned low
confidence/high risk),
Semi-automatic (processed output is made available for critical
assessment and approval or editing),

Manual (user controls generation of output)

Degree of Clinical Autonomy Independent/Autonomous (i.e., output impacts subsequent clinical action
or decision without clinical user in the loop),

Conditionally independent/ autonomous (output selectively impacts

subsequent clinical action or decision without clinical user in the loop; this
can include medical device software that require non-clinical user screening
decisions),

15
 IMDRF/SaMD WG/N81 DRAFT: 2024

Supervised (i.e., output impacts subsequent clinical action or decision

without clinical user having to approve, but with supervision from
adequately qualified operator),

Non-autonomous (output augments/ assists/ informs clinical user in their

determination of clinical decision/action)

Intelligibility/Transparency/Explainability Output is not explained or cannot be understood (e.g., Black Box),

(Underlying Logic including the
Output is partially explained or can be partially evaluated (e.g., output
Algorithm/Technology used and How
provided with saliency maps),
an Output is Reached)
Output is explained and can be comprehended

Destination/Target of Output Input to human user; Input to medical device; Input to a consumer
product

345

346 4.2.4. Medical Device Software Change Management

347 The change management approaches tied to a device form part of the device
348 characterization, including the autonomy of learning or change implementation as well
349 as the intended domain of change implementation.
350 The degree of learning or change management autonomy describes the effectuation
351 and control of training, learning and updates to the medical device software. Possible
352 attributes within this feature can include self-learning (autonomous updates
353 effectuated and controlled from within medical device software) and externally
354 controlled learning (non-autonomous updates effectuated and controlled by
355 manufacturer and/or user).
356 The domain of learning or change implementation refers to the scope or applicable
357 extent of change. This might be described as being applicable on a scale that is
358 international, national, regional, clinic-specific, or patient-specific.

359 Another aspect of software change management is the infrastructure for installation,
360 updates and error corrections. Updates and changes to the software can be provided
361 in response to software failures, errors, opportunities for improvement, critical
362 performance updates, and recalls. Software-specific risks and risk controls can
363 depend on the software distribution channels (app stores, manufacturer homepage,
364 web application, etc.) and software installation locations (mobile phones, hardware
365 medical devices, or personal computers (PCs) of the users, server anywhere in the
366 world or one single server at the manufacturer site).
367 Distribution channels, such as app stores offering medical device software, may not
368 be regulated in all jurisdictions. Surveillance challenges and unclear responsibilities
369 may occur in cases of recalls, field safety corrective actions and distribution of
370 information. Furthermore, software installation location can influence the effectiveness
371 and speed of access to updates or the deactivation of erroneous or recalled software
372 and the traceability of affected installations and users.
373 The following table summarizes the identified features and attributes that can help
374 characterize the device change management, including the degree of change
375 autonomy, the change domain and infrastructure for installation, updates and error
376 correction.

16
 IMDRF/SaMD WG/N81 DRAFT: 2024

377 Table 4 Features and attributes for the characterization of

378 medical device software change management

Characterization Feature Potential Feature Attributes

Degree of Learning/Change Self-learning/autonomous learning (autonomous updates effectuated and

Management Autonomy controlled from within medical device software),

Externally controlled user-driven learning/change (non-autonomous

updates effectuated and controlled by the user),

Externally controlled manufacturer-driven learning/change (non-

autonomous updates effectuated and controlled by the manufacturer)

Domain of Learning/Change International, National, Regional, Clinic/Site-specific, Patient-specific

Implementation

Installation, Update and Error Distribution channels (e.g., app stores, manufacturer homepage, web
Correction Infrastructure application),

Installation locations (Mobile phones, hardware medical devices, or PCs of

the users, server anywhere in the world or one single server at the
manufacturer site

379

17
 IMDRF/SaMD WG/N81 DRAFT: 2024

380 5. Medical Device Software

381 Risk Characterization
382 Identifying and estimating medical device software-specific risk can raise unique
383 questions compared to other medical devices. Risk management approaches, such as
384 those proposed within ISO 14971, often describe risk as the combination of the
385 probability of occurrence of harm and the severity of harm. Harms, however, can be
386 both direct and indirect, and a comprehensive identification of software-specific
387 contributions to possible harms can be challenging because software, on its own,
388 does not pose “physical” hazards to which harms can be easily attributed. Evaluating
389 software-specific contributions to possible harms generally requires interpretation of
390 primarily performance-related hazards 1, or more specifically information-related
391 hazards, and understanding the associated risk is then critically tied to a complete
392 understanding of a device’s intended use/purpose and particular implementation.
393 In other words, when assessing the risk of medical device software, it is important to
394 understand the contribution of information-related hazardous situations, which are
395 closely tied to the role of software in achieving an intended medical purpose. These
396 hazardous situations can generally be understood through the lens of “performance-
397 related hazards,” as described in ISO 14971, such as hazards relating to data access,
398 availability, delivery, and diagnostic information as opposed to, for example, energy,
399 biological, or chemical hazards.
400 An accurate characterization of software, including its characteristics such as intended
401 use, output type, use environment, autonomy, etc., allows for both a more
402 comprehensive identification of these direct and indirect harms and a clear
403 understanding of how software-specific harms can then lead to risks unique to a given
404 intended use/purpose.
405 While the performance-related hazards and risks related to software do not always
406 account for the totality of risk posed by a device (such as in the case of software that
407 may supply data or generate the inputs for a hardware actuator that poses associated
408 physical hazards), it is important to fully characterize the impact of a particular
409 software implementation or solution on device risk because it can still lead to
410 demonstrable impacts on patient safety or device effectiveness through direct or
411 downstream means.

1 ISO 14971:2019 Medical Devices – Application of Risk Management to Medical

Devices

18
 IMDRF/SaMD WG/N81 DRAFT: 2024

412 Further, it is important to consider that software-specific hazards often sit at the
413 junction of both safety and cybersecurity risks. Therefore, it can be helpful to consider
414 software-specific considerations pertaining to harm as a combination of how harm is
415 defined for safety and cybersecurity. In other words, medical device software-specific
416 consideration of harm could be viewed as relating to injury or damage to the health of
417 people 2 and reduction of effectiveness 3 – where “reduction of effectiveness” can result
418 from inadequate, incorrect, or absent data supplied to a human or product at an
419 inappropriate time, rate, or with an inadequate method. For example, injection of
420 unwanted or unintended bias into a decision-making system, whether or not it results
421 in direct harm to a patient, can be understood as a harmful reduction in effectiveness.
422 In other words, the introduction of the particular software solution has had a negative
423 impact on the decision-making system. Often, this can also be viewed as accounting
424 for “indirect harm” from the software, as noted above.
425 Performance-related hazards pertinent to software – that is, specifically information-
426 related hazards - can impact the function of other products or systems, how workflows
427 or processes are informed, and can directly impact user decision making. As such, a
428 harmonized discussion of how to identify, characterize, and contextualize these
429 possible harms and their impact on device risk can provide greater understanding for
430 why risk categorization for medical device software may be highly variable across
431 regulatory jurisdictions, as well as how to articulate these differences more
432 consistently.
433 Key Points:

434 • When evaluating the risk posed by software, both direct and indirect harms should
435 be considered.
436 • Because hazards associated with software are typically information-based
437 hazards (such as delayed, inappropriate, or erroneous information), it is important
438 to consider potential harm as both injury or damage to health as well as a
439 reduction in effectiveness when accounting for indirect harms.
440 • The possible harms and associated risks related to implementing software are
441 dependent on a device’s specific intended use.
442
443 Below, general considerations for identification and analysis of software-specific
444 hazardous situations are discussed, as well as considerations when carrying forward
445 these hazardous situations as part of risk estimation. These approaches are intended
446 to provide a shared means of discussing the unique risks posed by software that
447 meets the definition of a medical device, and how such an understanding may drive
448 device risk categorization across any number of risk categorization systems, layers in
449 part or in whole.
450

2While ISO 14971:2019 defines harm as “injury or damage to the health of people, or
damage to property or the environment.” it can be helpful to consider, more
specifically, harm as it relates to “injury or damage to the health of people” when
discussing medical device safety in this document. The narrower definition of patient
harm has the net effect of prioritizing regulatory review of those changes necessary to
protect public health.
3Harm is defined in TIR57: 2016/(R)2023 as “physical injury or damage to the health
of people, or damage to property or the environment, or reduction in effectiveness, or
breach of data and systems security” as described in IEC 80001-1:2021.

19
 IMDRF/SaMD WG/N81 DRAFT: 2024

451 5.1. Identification and Analysis

452 The success of risk assessment and management activities hinges on the risk
453 assessors’ understanding of what the medical device software is and is meant to do,
454 as well as how, where, when and by whom the medical device software is meant to be
455 used. The comprehensive characterization of medical device software, considering the
456 information presented in section 4 of this document, provides the foundation
457 necessary for software-specific risk characterization. Approaches to identifying and
458 considering risks within each of the information groupings in section 4 are provided
459 below, in part, to illustrate the way many variables contribute and interact to form a
460 more complete understanding of the unique risks that may impact a particular medical
461 device software.
462 To identify and characterize software risk, it is helpful to step through the process of
463 first identifying a device characteristic, then asking why the characteristic matters to
464 the intended use/purpose of the software, and then identifying the hazardous
465 situations that may arise based upon both the intentional software design decisions
466 and unintentional software failures. It remains important, however, to ensure that
467 exploring device characteristics in this manner is not done in a vacuum and
468 interdependencies of the software are carefully considered to comprehensively
469 describe a medical device software’s “risk characterization.”
470 Appendix C provides questions for consideration to accompany each characterization
471 feature previously identified in section 4. These questions are provided to help
472 develop an understanding of “why the characteristic matters to the intended
473 use/purpose of the software,” as a means to helping to identify specific hazardous
474 situations that may be related to the software’s design and intended use/purpose.
475 While not comprehensive, the questions aim to highlight how the context provided by
476 each of a device’s unique characteristics could impact an understanding of the
477 potential harms introduced by a particular software, and thereby affect the overall risk
478 of the medical device. The questions are intended to help guide a thorough
479 consideration of potential harms a medical device software could introduce, and not all
480 questions may be applicable or relevant to every medical device software.
481 Appendix D includes examples illustrating how answering the questions in Appendix C
482 can help to surface the way different characterization features and their interactions
483 may affect an understanding of the risks introduced by a particular medical device
484 software. Importantly, identifying these “software-specific” contributions to device risk
485 is intended as a means of articulating why the software for a particular medical
486 use/purpose may or may not alter device risk categorization under any number of
487 frameworks. This concept is discussed further in section 5.3 of this document.

488 5.2. Estimation

489 As noted above, risk management approaches, such as those proposed within ISO
490 14971, often describe risk as the combination of the probability of occurrence of harm
491 and the severity of harm. These risk estimation features, together with medical device
492 software characterization features outlined in section 4 of this document, can be
493 essential in assessing and managing risks.

20
 IMDRF/SaMD WG/N81 DRAFT: 2024

494 For medical device software, this determination requires the identification of the
495 potential direct and indirect harms associated with hazardous situations, such as
496 erroneous outputs from the software, followed by an assessment of the severity of
497 those harms, such as reductions in life expectancy, psychological injury, or
498 inappropriate or unnecessary invasive treatment. While probability of harm can
499 generally be helpful to consider when estimating risk, there is not broad consensus on
500 a method for quantitatively estimating probability of occurrence of software failure.
501 Additionally, cybersecurity risk management often considers exploitability of
502 vulnerabilities rather than probability of occurrence of harm; and it is generally
503 understood that probability of software-related harms can be influenced by factors like
504 usability, which can make estimation further challenging. 4 To this end, when
505 estimating software-specific risks, it can be helpful to set the probability of software
506 failure to 1 and if possible, estimate the probability based on other factors to perform
507 risk estimation.
508 The guiding questions in section 5.1 can provide a basis for isolating software-specific
509 hazards and for contextualizing their potential severity of harm, on the basis of
510 understanding how applying a specific software solution can affect the way the
511 medical device intended use/purpose is achieved.
512 These concepts can then be leveraged for risk characterization (e.g., through risk
513 assessment per ISO 14971) and the determination of the severity of direct or indirect
514 harm caused by a given, software-specific hazardous situation (e.g., catastrophic,
515 critical, serious, minor, negligible). Once harms are identified, the approach to
516 “software-contributed” risk estimation is not unique. That said, when software may
517 need to be considered in the context of a broader device to achieve an intended
518 use/purpose, it can also be helpful to consider whether the software becomes a
519 single-point failure for a given possible harm and, if so, how this may impact risk
520 estimation and associated mitigations.

521 5.3. Approaches for Risk Categorization

522 It may not be universally possible or beneficial to create completely rigid and distinct
523 categories of risk for any one type of function, disease, intervention, population, or
524 user. For any given medical device software there may be both interdependencies and
525 unequal weight amongst characterization groupings that ultimately inform the
526 understanding of device risk and, therefore, may impact a subsequent categorization.
527 Further, when addressing the specific contribution to device risk posed by software,
528 considerations like how supplied information will be ingested by a given userbase, as
529 just one example, may reasonably not have uniform or universal answers across
530 jurisdictions.

4 Ref: IEC 62304, AAMI TIR57, AAMI TIR34971

21
 IMDRF/SaMD WG/N81 DRAFT: 2024

531 Different jurisdictional authorities may have distinct philosophies and legal obligations
532 which shape their different risk-based classifications. Therefore, the discussion
533 provided in section 5 and further illustrated in Appendix B is intended as a common
534 basis for considering and articulating how characterization features impact the risk of
535 software that meets the definition of a medical device, particularly through the lens of
536 the interdependent factors shaping an understanding of risk specific to software for a
537 given intended use/purpose. Put another way, this document intends to provide insight
538 into how a particular software risk categorization could be concluded without
539 prescribing a single “correct” and universal category to any given device. As noted
540 previously, among other complications, software-specific risks may have a significant
541 but not exclusive influence on the risk categorization applicable to a given device. In
542 premise, this document can serve as the basis for discussing a given understanding of
543 a medical device software’s risk within a broader device system or regulatory
544 structure.

22
 IMDRF/SaMD WG/N81 DRAFT: 2024

545 6. Considerations for

546 Implementation
547 Harmonizing approaches to the characterization of medical device software will
548 support the assessment of device risks and benefits for all stakeholders. Providing a
549 common basis for describing these devices and considering how different
550 characteristics impact risk can help promote safety and effectiveness as well as
551 consistency and alignment across jurisdictions.
552 The considerations presented in Sections 5.0 and 6.0 can be used to support
553 understanding of a medical device software and its risks and facilitate the
554 interpretation and application of different device risk classification systems across
555 jurisdictions.
556 Device classification in a given jurisdiction will ultimately be dictated by the governing
557 authorities, laws, and regulations. To the extent possible, jurisdictions may consider
558 incorporating harmonized language and concepts from this document into their local
559 guidance or processes, for example, connecting the device and risk characterization
560 language in the document to their labelling and risk management expectations or
561 classification regulations.
562 Jurisdictions may be able to leverage a subset of characterization features and
563 attributes, together with the assessment of medical device software risks and their
564 severity, to describe their approach to applying risk categorization to medical device
565 software.
566 These concepts are intended to be used by stakeholders alongside their existing
567 frameworks, to provide additional detail and exposition for decision-making –
568 ultimately promoting and informing clear, consistent, and accurate characterizations of
569 medical device software.

23
 IMDRF/SaMD WG/N81 DRAFT: 2024

570 Appendix A: Sample

571 Intended Use/Intended
572 Purpose Statement
573 In order to foster and encourage clear and comprehensive intended use statements
574 for medical device software, Key Elements of an intended use/intended purpose
575 statement are captured in section 4.1.1. A sample statement guide can be found
576 below. It is important to note that not all elements will be applicable to every medical
577 device software and the information provided in these sections is solely for
578 consideration by manufacturers in the development of the medical device software
579 labelling, documentation, and regulatory submissions, as appropriate. The sample
580 statement may not be appropriate for all medical device software depending on the
581 technology and intended use. Although typically included in the intended use/ intended
582 purpose statement, for some devices, information such as contraindications, may be
583 included elsewhere in the medical device software labelling due to the volume of
584 information.

585 The [name of medical device software] is software intended for use in the
586 [medical purposes] of [conditions/diseases/disorders] in [intended patient
587 populations]. This software is intended to be used by [intended user
588 populations] in [intended use environments]. This medical device software is
589 contraindicated for [contraindications]. This medical device software uses
590 [inputs] in order to produce [description of outputs]. These outputs are
591 [description of how the output is intended to be used, how it fits in the clinical
592 or healthcare workflow and how it contributes to the final healthcare
593 decision/action].

24
 IMDRF/SaMD WG/N81 DRAFT: 2024

594 Appendix B:
595 Characterization Feature
596 Summary Table
Information Characterization Feature Potential Feature Attributes
Grouping

Medical Medical Purpose Diagnosis (e.g., primary diagnosis, screening, triage,

Problem etc.), Prevention, Monitoring, Mitigation, Prediction,
and/or Treatment, etc.
Objective
Intended Conditions/Diseases/ Critical, Serious, Non-Serious condition or disease,
Disorders and Grade/Stage/Level including consideration of level of progression/stage/ grade
(e.g., a chronic condition or an acute change in a chronic
condition)

Intended Patient Population General population,

Specific subgroup of the population (e.g., fragile and/or

vulnerable subgroup; specific age group, sex, gender, skin
tone, race, disability, diagnosis, etc.), or

Specific intersection of subgroups of the population

(e.g., specific age group + specific sex + those at risk of a
specific condition)

Context of Intended User Lay user/nonclinical user (e.g., caregiver, patient user,
Medical user without medical qualifications),
Device
Licenced medical professional, non-physician (e.g.,
Software
registered nurse, dentist, psychologist, radiation therapist,
Use
physiotherapist, etc.),

General Practitioner (e.g., Primary care physician, family

doctor, registered nurse practitioner),

Specialist Healthcare Physician (e.g., radiologist,

oncologist, dermatologist, pathologist, surgeon, etc.)

Intended Use Environment Non-clinical Environment (e.g., home-use),

General Healthcare Environment (e.g., primary care

clinic, virtual primary healthcare),

Specialty Healthcare Environment (e.g., hospital,

specialty clinic, virtual specialty healthcare)

25
IMDRF/SaMD WG/N81 DRAFT: 2024

Timing Within Healthcare Early (e.g., triage, prediction of future diagnoses, early
Task/Intervention investigations upon suspicious symptoms or information,
physiological signal or medical image acquisition for use in
diagnosis or treatment planning),

Midway (e.g., signal or image segmentation for use in

diagnosis or treatment planning; routine monitoring of
patient health for clinically relevant changes requiring
further care and not including acute scenarios),

Late (e.g., optimal image-guided treatment plan or dosage

for consideration; adjunct diagnostic recommendations or
second checks, continuous glucose monitor output
analysis automatically driving basal insulin dosage; image-
guided instrument control in robotic surgery; autonomous
detection and diagnosis of diabetic retinopathy)

* Note: these 3 phases (Early, Midway and Late)

described above serve as reference points, and it is not
crucial to state which phase should be applied. Rather, it is
important to characterize the timing of the output relative to
the final intervention, decision or action as well as the
relative chronology of how the product will be introduced in
relation to other steps (e.g., prior steps, concurrent steps,
conditional steps, subsequent steps) and current standard
medical practices.

Role Of Software Output Within the Software output’s relationship to the healthcare
Healthcare Task/Intervention task/intervention steps, such as the output’s contribution
to the relevant healthcare decision or action (for example,
intended as an aid that is combined with current practice);
alteration of standard/current practice (for example,
intended to replace or substitute all or part of current
practice, to provide a new scheme, etc.); dependence on
other steps (e.g., uses output values or clinical decisions
from prior steps, concurrent steps, conditional steps);
and/or influence over other steps (e.g., provides input to
concurrent steps, subsequent steps, conditional steps, or
final intervention/decision).

Medical Output Type Clinical Interpretation or Intervention (e.g., diagnosis,

Device suspicion, probability, prediction, detection, severity,
Software prognosis, grade, stage, direct markers of a diagnosis,
Function/ prescription, treatment/therapy, recommended treatment,
Use recommended dosage, radiation treatment plan),

Workflow Recommendation (e.g., contrast dye dosage;

recommended imaging technique/modality/parameters;
recommended surgical tool choice; recommended
additional test based on established guidelines),

Data for use in medical purpose (e.g., anatomy

measurement, volume, or segmentation; processed
image/image reconstruction/de-noised image; processed
signal/waveform (e.g., processed ECG)

26
IMDRF/SaMD WG/N81 DRAFT: 2024

Input Source From human user, medical device, or consumer

product.

Level of Task Automation Fully automated (i.e., output does not require
review/approval and cannot be modified by the user),

Conditionally automatic (some outputs are flagged for

review or user has a way to go back and edit the output,
for example if assigned low confidence/high risk),

Semi-automatic (processed output is made available for

critical assessment and approval or editing),

Manual (user controls generation of output)

Degree of Clinical Autonomy Independent/Autonomous (i.e., output impacts

subsequent clinical action or decision without clinical user
in the loop),

Conditionally independent/ autonomous (output

selectively impacts subsequent clinical action or decision
without clinical user in the loop; this can include medical
device software that require non-clinical user screening
decisions),

Supervised (i.e., output impacts subsequent clinical action

or decision without clinical user having to approve, but with
supervision from adequately qualified operator),

Non-autonomous (output augments/ assists/ informs

clinical user in their determination of clinical
decision/action)

Intelligibility/Transparency/Explainability Output is not explained or cannot be understood (e.g.,

of Underlying Logic including the Black Box),
Algorithm/Technology used and How an
Output is partially explained or can be partially
Output is Reached
evaluated (e.g., output provided with saliency maps),

Output is explained and can be comprehended

Destination/Target of Output Input to human user, Input to medical device, Input to a

consumer product

Medical Degree of Learning/Change Self-learning/autonomous learning (autonomous

Device Management Autonomy updates effectuated and controlled from within medical
Software device software),
Change
Externally controlled user-driven learning/change
Management
(non-autonomous updates effectuated and controlled by
the user),

Externally controlled manufacturer-driven

learning/change (non-autonomous updates effectuated
and controlled by the manufacturer)

27
 IMDRF/SaMD WG/N81 DRAFT: 2024

Domain of Learning/Change International, National, Regional, Clinic/Site-specific,

Implementation Patient-specific

Installation, Update and Error Distribution channels (e.g., app stores, manufacturer
Correction Infrastructure homepage, web application),

Installation locations (Mobile phones, hardware medical

devices, or PCs of the users, server anywhere in the world
or one single server at the manufacturer site)

597

28
 IMDRF/SaMD WG/N81 DRAFT: 2024

598 Appendix C: Example

599 Considerations to
600 Understand Software
601 Hazards Associated with
602 Device Design and Intended
603 Use
604 The questions noted in the below table are intended to help guide a thorough
605 consideration of potential harms that a medical device software could introduce. Not
606 all questions may be applicable or relevant to every medical device software. This is
607 not intended to be an exhaustive or required list of considerations for the intended use
608 or the intended user of the medical device software, rather they are optional examples
609 that may be helpful to consider while characterizing software risk.

29
IMDRF/SaMD WG/N81 DRAFT: 2024

Information Characterization Feature Considerations for Medical Device Software Risk

Grouping Characterization

Medical Problem Medical Purpose •Is the medical device software intended to be used as
and/or Objective adjunctive or alongside other tools or treatment? Is the
medical device software intended to replace or augment
a system or process? If it is meant to augment, in what
manner is the medical device software augmentative (for
example, is the software output additive or confirmatory
to another process or outcome)?

•Is the output of the software, itself, intended to be

therapeutic or a treatment? Is the software output used
for decision making with diagnosis or therapeutic
purposes? Is the software used to monitor physiological
processes or vital physiological parameters? Does the
software have alarm functions used to prompt immediate
intervention?

Intended Condition/Diseases/ Disorders •How, if at all, does the condition/disease (for example,
and Grade/Stage/Level acute or chronic) that the medical device software intended
for impact the criticality of the data output by the
software?

•Does the condition/disease modify the timing of when

the information is needed or is provided or must be
used?

•Does the condition/disease define the sensitivity or

accuracy of the information needed for the input or output
of the software? Could the nature of variation of monitored
parameters result in immediate danger to the patient?

•Could the decisions or diagnostics made by the software

output have an impact that may cause death or an
irreversible deterioration in condition/disease or a serious
deterioration in condition/disease or a surgical
intervention?

Intended Patient Population •Does the intended patient population include a specific
vulnerable subgroup?

•How diverse is the intended patient population? How

generalized does the information need to be to perform
adequately across the intended patient population? How
specific?

•Does the medical device software accurately reflect the

demographics, backgrounds, and characteristics of the
population the software will be used for?

Context of Intended User •Does the medical device software enable new/different
Medical Device users to achieve the clinical task than those who would
Software Use perform the task without the software?

•Does the user need to possess expertise, or access to

expertise, to understand the inputs and/or outputs of the
software?

30
IMDRF/SaMD WG/N81 DRAFT: 2024

Intended Use Environment •Is use of the medical device software providing a clinical
task or service in an environment that would not
otherwise have such tasks or services available (e.g.,
would otherwise require an expert present)?

•Is the device intended to be used in an uncontrolled or

unconventional setting?

•Can external factors, both physical and digital, affect the

use, input or output of the device?

•Do the expected virtual conditions and computing

environment require additional software controls and/ or
impact the users’ access to the software?

Timing Within Healthcare •Does the user have adequate time to review the basis
Task/Intervention for the information output by the software or to review and
curate the information being used as input to the software?

•Could the software output initiate a healthcare

intervention that would not otherwise be identified by a
particular user or in a particular setting (e.g., pre-screening
information prompting a patient to speak to a doctor about
a possible condition)?

•Are there possible harms or dangers related to the

healthcare task/intervention that could occur
immediate to the software’s outputs?

•Are there possible harms or dangers related to the

healthcare task/intervention that could occur distantly
from the use of the software, but are related to decision
points generated by the software’s outputs?

Role Of Software Output Within the •Does an erroneous output from the software at the
Healthcare Task/Intervention intended point in the workflow put the patient on a path
toward subsequent harm?

•Is the frequency of output appropriate to its role and

timing in the workflow (e.g., is there a potential for
notification fatigue)?

•Does the software create a single point of failure in the

clinical task/intervention?

Device Function/ Output Type •Is the output supplementing additional information to
Use contribute to a clinical interpretation or workflow
recommendation? Is it a replacement or substitution for
information meant to determine a clinical interpretation,
workflow recommendation, or as data for use in a medical
purpose?

•Is the output commonly accepted in clinical practice or

based upon sound scientific principles? Is the output
proprietary?

•Is access to the output tiered or limited by user or other

credentials?

31
IMDRF/SaMD WG/N81 DRAFT: 2024

•Is the output Boolean, e.g., values that are either true, or
false?

Input Source •Is the input source from a human user, medical device, or
consumer product?

•Is the input source unique or could the data be obtained

through other methods or sources?

•Is an adequate input source governed by specific

parameters such as rate, sensitivity, or precision
(inclusion and exclusion criteria)? Is the input relevant?

•Is the input data direct or informed or transformed by

other tools, products, or intermediaries? Are the
transformed data suitable?

•Are there multiple input sources or data types? Are they

interdependent?

Level of Task Automation •Does the user control generation of the output?

•Does the output require review/approval and allow

modification by the user?

•Are outputs flagged for review or does the software

provide a way to go back and edit the output, for example
if assigned low confidence/high risk?

•Can the user review the basis for the output?

•Does the user control or review the software inputs?

Degree of Clinical Autonomy •Is a user in the loop? Is the user in the loop a health care
professional?

Intelligibility/Transparency/Explainability •Is the functionality of the product sufficiently explained

of Underlying Logic including the and reasonably understood by the patient?
Algorithm/ Technology used and How
•Is the functionality of the product explained and
an Output is Reached
understood by users other than the patient? Is different
information provided to different user groups or patients?

•Is the functionality partially explained or partially able to

be evaluated by the user? (e.g., output provided with
saliency maps).

Destination/Target of Output •Is the output the only instruction/data/information

needed to drive the target’s next action?

Medical Device Degree of Learning/Change •Does the medical device software independently change
Software Management Autonomy its underlying algorithms?
Change
•How often is medical device software performance
Management
verified?

•Are updates to algorithmic performance driven by non-

clinical or clinical users, or manufacturer driven, or a
combination of these users?

32
 IMDRF/SaMD WG/N81 DRAFT: 2024

Domain of Learning/Change • Is domain-specific implementation necessary to

Implementation achieve adequate software performance?

• Where are changes intended to be implemented and how

variable are these domains?

Installation, Update and Error •What specific channels are used to distribute the
Correction Infrastructure medical device software?

•Does the medical device software have multiple

installation locations? Where are corrections initiated?

610

33
 IMDRF/SaMD WG/N81 DRAFT: 2024

611 Appendix D: Example of

612 Discussing Information
613 Risk in Application to Risk
614 Characterizations
615 When considering a possible framework for risk categorization, each jurisdiction
616 manages different constraints best addressed by a convergence of risk categorization
617 strategies. This section includes examples applying the considerations described in
618 sections 5 and 6. The examples below are intended to help illustrate how robustly
619 characterizing software and systematically assessing the contribution of
620 characterization factors to the software risk can provide a shared and more granular
621 means of discussing risk that remains transferrable between potentially diverse risk
622 categorization structures.
623 Below we have provided a full example of a software function applying the
624 considerations discussed in the above sections as well as specific examples
625 highlighting how changes in specific groupings of characterization features may
626 impact risk.

627 Example A: Software function that serves as a primary diagnostic to identify

628 patients with prediabetes

629 Scenario: The software is intended to analyze health related data including
630 data from electronic health records, laboratory tests, and other diagnostic
631 tests to identify individuals with pre-diabetes (i.e., an early marker of diabetes)
632 with an output that is reviewed by healthcare practitioners.

633 A.1 Sample Intended Use/Intended Purpose Statement

634 The Product X is software intended for use in the diagnosis of prediabetes
635 in adult men and women at risk of developing diabetes. This software is
636 intended to be used by medical professionals in general healthcare
637 environments. This medical device software is developed using a machine
638 learning model. This medical device software is used for patients without
639 an existing diabetes diagnosis. This medical device software uses specific
640 data within the electronic health records (EHR) in order to produce a
641 conditionally automatic algorithm output that provides likelihood of
642 developing diabetes. These outputs are conditionally independent/
643 autonomous (i.e., output is presented to healthcare providers for review
644 above a threshold %) and are intended to be used as a clinical workflow
645 recommendation for additional testing or follow-up based on
646 established guidelines.

647 As discussed in Appendix C, addressing each of the characterization features through

648 corresponding questions is helpful for evaluating risk. The below questions are listed
649 by information grouping to support comprehensive discussion of risk considerations.

34
 IMDRF/SaMD WG/N81 DRAFT: 2024

650 A.2 Software Risk Considerations:

651 A.2.1 Medical Problem and/or Objective

Characterization Considerations for Medical Device Software Risk Characterization

Feature

Medical Purpose •Is the medical device software intended to be used as adjunctive or alongside other tools or
treatment? Is the medical device software intended to replace or augment a system or
process? If it is meant to augment, in what manner is the medical device software
augmentative (for example, is the software output additive or confirmatory to another
process or outcome)?

•Is the output of the software, itself, intended to be therapeutic or a treatment? Is the
software output used for decision making with diagnosis or therapeutic purposes? Is the
software used to monitor physiological processes or vital physiological parameters? Does the
software have alarm functions used to prompt immediate intervention?

Intended •How, if at all, does the condition/disease (for example, acute or chronic) that the medical
Conditions/ device software is intended for impact the criticality of the data output by the software?
Diseases/
•Does the condition/disease modify the timing of when the information is needed or is
Disorders and
provided or must be used?
Grade/Stage/Level
•Does the condition/disease define the sensitivity or accuracy of the information needed for
the input or output of the software? Could the nature of variation of monitored parameters
result in immediate danger to the patient?

•Could the decisions or diagnostics made by the software output have an impact that may
cause death or an irreversible deterioration of condition/disease or a serious deterioration in
condition/disease or a surgical intervention?

Intended Patient •Does the intended patient population include a specific vulnerable subgroup?
Population
•How diverse is the intended patient population? How generalized does the information need
to be to perform adequately across the intended patient population? How specific?
•Does the medical device software accurately reflect the demographics, backgrounds, and
characteristics of the population the software will be used for?

652
653 In this example, we first consider questions related to the Medical Problem and/or
654 Objective:

655 In considering the Medical Purpose, we recognize that this medical device software is
656 intended to be used alongside other tools or treatments i.e., used alongside additional
657 diagnostic test results, treatments, and data available in electronic health records. The
658 medical device software is intended to augment a system or process i.e., the software
659 output is used as a tool to aid in the diagnosis of pre-diabetes. Here, it is helpful to
660 consider that the software is intended to augment and aid, which suggests the output
661 may not be the sole influence on the related clinical decision point. If the software
662 output is not a single point failure that will lead to patient harm, this can impact our
663 understanding of the software’s risk.

35
 IMDRF/SaMD WG/N81 DRAFT: 2024

664 When considering the Intended Condition/Disease/Disorders and Grade/Stage/Level

665 of the patient, we consider that the general state of the condition as a pre-disease
666 state (i.e., the state of a condition before it is a disease) does not impact the criticality
667 of the output of the software. The general state of the condition being a pre-disease
668 state determines that the information is needed or must be used before the disease
669 (diabetes) is diagnosed to predict a high likelihood of subsequently developing the
670 disease (diabetes). Furthermore, the general state of the condition as a pre-disease
671 state (i.e., the state of a condition before it is a disease) and the likelihood of a pre-
672 diabetes state being present (i.e., pre-test probability) determines the sensitivity and/or
673 accuracy of the information needed for the output of the software. Given these factors,
674 the software output is unlikely to have an impact that may cause death or an
675 irreversible deterioration of condition/disease, which can be helpful to consider when
676 evaluating the overall impact that a software failure could have on the device risk. In
677 this case, the risk may be generally lower, because the output’s relationship to the
678 condition is not one that may likely lead to irreversible harm.

679 The Intended Patient Population in which this medical device software is intended to
680 be used includes the general public but may include vulnerable subgroups such as
681 individuals of different ethnicities, different age groups (e.g., <40, 40-60, >60 years
682 old). The intended patient population is the general public that is representative of the
683 demographics in the local userbase which may include regional, state, or at the
684 national level. This information needs to be broadly generalizable to perform
685 adequately. As a diagnostic aid the performance of the software must have adequate
686 sensitivity and specificity; however, the performance is dependent on the prevalence
687 of the condition (i.e., pre-diabetes) being tested. Because this software is intended for
688 a general population, the software may need to operate in consideration of a wide
689 variety of patients in the intended population.

36
 IMDRF/SaMD WG/N81 DRAFT: 2024

690 A.2.2 Context of Device Use

Characterization Considerations for Medical Device Software Risk Characterization

Feature

Intended User •Does the software enable new/different users to achieve the clinical task than those
who would perform the task without the software?

•Does the user have the expertise, or access to the expertise, necessary to
understand the inputs and/or outputs of the software?

Intended Use •Is use of the medical device software providing a clinical task or services in an
Environment environment that would not otherwise have such services available (e.g., would
otherwise require an expert present)?

•Is the device intended to be used in an uncontrolled or unconventional setting?

•Can external factors, both physical and digital, affect the use, input or output of the
device?

•Do the expected virtual conditions and computing environment require additional
software controls and/ or impact the users’ access to the software?

Timing Within Healthcare •Does the user have adequate time to review the basis for the information output by
Task/Intervention the software or to review and curate the information being used as input to the
software?

•Could the software output initiate a healthcare intervention that would not
otherwise be identified by a particular user or in a particular setting (e.g., pre-
screening information prompting a patient to speak to a doctor about a possible
condition)?

•Are there possible harms or dangers related to the healthcare task/intervention

that could occur immediate to the software’s outputs?

•Are there possible harms or dangers related to the healthcare task/intervention

that could occur at a time distant from the use of the software, but that are related to
decision points impacted by the software outputs or behaviour?

Role Of Software Output •Does an erroneous output from the software at the intended point in the workflow put
Within the Healthcare the patient on a path toward subsequent harm?
Task/Intervention
•Is the frequency of output appropriate to its role and timing in the workflow (e.g., is
there a potential for notification fatigue)?
•Does the software create a single point of failure in the clinical task/intervention?

691 Continuing the example, we consider questions related to the Context of Device Use:

692 In considering the Intended User, we recognize this medical device software enables
693 both new and different users (i.e., different Health Care Providers (HCPs)) to achieve
694 the clinical task (i.e., to identify individuals with pre-diabetes) that would otherwise not
695 be performed without the software. This medical device software can be used by
696 different intended users (i.e., different primary care and/or specialty HCPs). The
697 software is analyzing health related data in electronic health records that does not
698 require the user (i.e., HCP) to have specialized training. This medical device software
699 requires the user (i.e., HCP) to have the necessary expertise to understand the input
700 (i.e., type of data in electronic health records that the software analyzes) and the
701 output (i.e., pre-diabetes) produced by the software.

37
 IMDRF/SaMD WG/N81 DRAFT: 2024

702 The Intended Use Environment for this medical device software includes providing
703 services in a healthcare (i.e., clinical) environment and is not intended to function
704 outside healthcare settings or in those settings where healthcare is not being delivered
705 with access to an electronic health record (i.e., settings using paper-based records).
706 External factors (i.e., those factors that can impact the function of the medical device
707 software) such as physical (e.g., physical related factors) and digital (e.g., broadband,
708 internet connectivity, access issues to different healthcare databases) factors, may
709 have a minor or negligible effect on the use, input, or output of the device. Further, the
710 restricted intended use environment reduces the variability of operating conditions
711 where the software must perform adequately.
712 As for the Timing within Healthcare Task/ Intervention, we recognize that the output of
713 this medical device software is considered routine and non-urgent. The user has
714 adequate time to review the output of this medical device software and to curate and
715 review the basis or information used as its input. Because of the intended timing, the
716 impact of the software’s risks may overall be considered lower than those risks might
717 be in a time-critical or urgent use case. Because some patients for whom review might
718 be impactful to their future care could be missed if the software does not present their
719 cases for review, there is a possible harm that could occur distantly from the use of
720 the software.
721 When considering the Role of Software Output within the Healthcare
722 Task/Intervention, we recognize that as a recommendation for further testing, the risk
723 of output from the software at the intended point in the workflow putting the patient on
724 a path toward subsequent harm is low. The frequency of output from the software and
725 timing in the clinical workflow do not present risks of notification fatigue. The software
726 also does not present a single point of failure in the clinical task/intervention as other
727 data within the patient’s primary care routine to identify symptoms of prediabetes.
728 As we consider questions related to the Context of Device Use, the Intended User for
729 the medical device software in the scenario provided is limited to healthcare
730 practitioners in the Intended Use Environment of a health care facility. This, in
731 combination with the Timing within Healthcare Task/Intervention and Role of Software
732 Output within the Healthcare Task/Intervention considerations indicates that these
733 characterisation features pose a lower impact on overall risk characterization.
734
735 A.2.3 Device Function Use

Characterization Considerations for Medical Device Software Risk Characterization

Feature

Output Type •Is the output supplementing additional information to contribute to a clinical interpretation
or workflow recommendation? Is it a replacement or substitution for information meant to
determine a clinical interpretation, workflow recommendation, or as data for use in a
medical purpose?

•Is the output commonly accepted in clinical practice or based upon sound scientific
principles? Is the output proprietary?

•Is access to the output tiered or limited by user or other credentials?

•Is the output Boolean, e.g., values that are either true, or false?

Input Source •Is the input source from a human user, medical device, or consumer product?

•Is the input source unique or could the data be obtained through other methods or
sources?

38
 IMDRF/SaMD WG/N81 DRAFT: 2024

•Is an adequate input source governed by specific parameters such as rate, sensitivity,
or precision?

•Is the input data direct or informed or transformed by other tools, products, or
intermediaries?

•Are there multiple input sources or data types? Are they interdependent?

Level of Task •Does the user control generation of the output?

Automation
•Does the output require review/approval and allow modification by the user?

•Are some outputs are flagged for review or provide a way to go back and edit the output,
for example if assigned low confidence/high risk?

•Can the user review the basis for the output?

•Does the user control or review the software inputs?

Degree of Clinical •Is a user in the loop? Is the user in the loop a health care professional?
Autonomy

Intelligibility/Transpar •Is the functionality of the product explained and understood by the user?
ency/Explainability of
•Is the functionality of the product explained and understood by users other than the
Underlying Logic
patient? Is different information provided to different user groups or patients?
including the
Algorithm/Technology •Is the functionality partially explained or partially able to be evaluated by the user?
used and How and (e.g., output provided with saliency maps)?
Output is Reached

Destination/Target of •Is the output the only instruction/data/information needed to drive the target’s next
Output action?

736
737 Continuing the example, we consider questions related to the Device Function/ Use:
738 In considering the Output Type, we recognize this medical device software provides
739 additional information (i.e., diagnosis of a pre-diabetes state) that supplements clinical
740 recommendations (e.g., for subsequent diagnostic testing) with data that is used for a
741 medical purpose (e.g., recommendations for lifestyle modification and/or treatments).
742 The output of this medical device software is commonly accepted in clinical practice
743 (i.e., the diagnosis of pre-diabetes) and, provided it has been adequately validated
744 with an appropriate indication for use, is based on sound scientific principles. This
745 medical device software output is considered proprietary, because the specific
746 calculation to arrive at a threshold to present the output to the HCP for review is
747 devised by the company and is not simply a well-known and accepted threshold or
748 calculation. Access to the output of this medical device software is first made available
749 to the HCP who ordered the use of this software (i.e., analysis of health-related data
750 for an individual who does not have pre-diabetes to determine if pre-diabetes is
751 present in this individual). Thereafter, the output of this medical device software is
752 accessible by HCPs who are providing care to this individual and information is not
753 withheld from the HCP on the basis of a specific product access tier. The information
754 is also not meant to be shared with a wide variety of users such that varying levels of
755 access is implemented, such as might be the case if the product’s outputs were meant
756 for review by both patients and their providers.

39
 IMDRF/SaMD WG/N81 DRAFT: 2024

757 The Input Source of this medical device software is unique and limited to the data that
758 is available in electronic health records for individuals in whom this software will be
759 used. The input data cannot be obtained through other methods or sources. The input
760 source of this medical device software is governed by specific parameters, notably
761 structured data in electronic health records (e.g., diagnostic testing results, vitals
762 measurements, demographic information). The input data of this medical device
763 software is not transformed by other tools or products. This medical device software
764 contains one input source (i.e., data in electronic health records) but includes multiple
765 interdependent data elements (e.g., demographic data, laboratory and diagnostic
766 testing results, treatments). These structured, regular data inputs from known sources
767 of expected uniform quality do not appear to introduce novel or altered risks as a
768 result of introducing the software solution. An HCP would review the same data to
769 make an independent decision if the software was not available.
770 In considering the Level of Task Automation, we recognize the user does not control
771 generation of the output for this medical device software. The output of this medical
772 device software does not require review/approval or allow modification by the user,
773 and the output of this medical device software does not enable retrospective editing of
774 the output. Because of the nature of the task this software is meant to perform, which
775 does not immediately impact a next clinical action without review and provides a new
776 datapoint (threshold) rather than a modification of existing data, the level of task
777 automation may not introduce risks specific for this device software. We also
778 recognize the user can review the basis for the output of this medical device software
779 and the user does not control or review the inputs for this medical device software.
780 Only certain outputs of the software will be elevated to the HCP’s attention, which
781 suggests that the software solution may introduce a different risk than those present if
782 the task was completed manually (e.g., failing to identify at-risk patients to present to
783 the HCP that they might otherwise have noted if reviewing the data manually).
784 In terms of the Degree of Clinical Autonomy, a clinician is in the loop to review any
785 outputs flagged by the software and to make the next decision in the clinical workflow
786 – such as follow up tests for the patient. However, as noted above, a clinician will not
787 be informed of patients who have not met the threshold to be considered “at risk” by
788 the software.
789 Considering the Intelligibility/Transparency/Explainability of Underlying Logic, we
790 recognize the functionality of this medical device software is explained (i.e., within its
791 indication for use and ordering requirements) and is understood by the user. The
792 functionality of this medical device software is explained to and can be evaluated by
793 the user (i.e., input data includes structured data elements in electronic health
794 records). The analysis (i.e., statistical or computational approach) is partially explained
795 to the user.
796 Considering the Destination/Target of Output, this software likely does not provide an
797 output that would be the sole instruction/data/information to drive the HCP user’s next
798 step. The output will present cases for the HCP to review and introduce a single new
799 datapoint (patient has been identified as above a threshold). The HCP will have the
800 patient’s data for review in addition to the information that the patient has exceeded
801 the threshold to help inform their next decision. However, as noted above, the HCP
802 will not be presented with any data on patients who do not exceed the software’s
803 threshold, which could result in no decision made for such patients.

40
 IMDRF/SaMD WG/N81 DRAFT: 2024

804 After consideration of questions related to Device Function Use it may be considered
805 that the output type, supplementing additional information to contribute to a clinical
806 interpretation or workflow recommendation, in this case a prediction or diagnosis
807 commonly accepted in clinical practice or based upon sound scientific principles, may
808 not greatly impact the risk of the device. However, the specific threshold calculation is
809 proprietary and the software is replacing a manual review of a patient record and
810 introduces the possibility of incorrectly filtering patients for review by the HCP.
811 A.2.4 Device Change Management

Characterization Considerations for Medical Device Software Risk Characterization

Feature

Degree of •Does the medical device software independently change its underlying algorithms?
Learning/Change
•How often is medical device software performance verified?
Management
Autonomy •Are updates to algorithmic performance driven by non-clinical or clinical users, or
manufacturer driven, or a combination of these users?

Domain of • Is domain specific implementation relevant to the performance software?

Learning/Change
• Where are changes intended to be implemented and how variable are the domains?
Implementation

Installation,
•What specific channels are used to distribute the medical device software?
Update and Error
Correction
•Does the medical device software have multiple installation locations? Where are
Infrastructure
corrections initiated?

812 Last, we consider questions related to the Device Change Management:

813 In considering the Degree of learning/change management autonomy, we recognize
814 this medical device software does not independently change its underlying algorithms.
815 The performance of this medical device software is verified on an annual schedule by
816 the product developers and validated by clinical users within the specific healthcare
817 site. Updates to the algorithmic performance are monitored by clinical users and the
818 manufacturer.
819 In Domain of learning/change implementation, we note that learning and/or change
820 management may result in different accuracy or precision when this software is used
821 across different clinical sites or regional locations (i.e., based on the demographic
822 characteristics of the individuals in whom this software is used).
823 Regarding Installation, Update and Error Correction Infrastructure, we note that this
824 medical device software’s distribution channel is a web application, and that the
825 software installation occurs on a server at the individual clinical site by clinical users.

41
 IMDRF/SaMD WG/N81 DRAFT: 2024

826 In summary, for such a product, overall impact on risk posed, or introduced, by the
827 software takes into consideration multiple characterization features across information
828 groupings, and those that are most relevant to the particular device software may be
829 different depending on the device’s intended use/purpose. For this reason, it is critical
830 to have a clear description of the software to help build an understanding of the role of
831 the medical device software and its unique implementation. For this example device,
832 the particular software solution may introduce risks related to the automation of a
833 previously manual step and new failure points in the intended workflow. However,
834 because of the device’s medical purpose and context of use, these potential risks may
835 not have notably high impact. These considerations can be taken together when
836 considering how the decision to design this software solution may impact the overall
837 risk of the device or raise different hazards.

42
 IMDRF/SaMD WG/N81 DRAFT: 2024

838 Appendix E: Examples

839 Comparing Specific Risk
840 Considerations
841 As with Example A above, addressing each of the characterization features through
842 corresponding questions is helpful for evaluating risk. The below questions are listed
843 by information grouping to support comprehensive discussion of risk considerations.
844 The pairs of comparative examples below further illustrate the hazards to be extracted
845 in risk analysis can differ based on the unique characteristics of a given medical
846 device software.

Example 1: Software intended to provide a therapeutic experience to reduce

and relieve pain.

Scenario 1.1: The software is intended to be used in conjunction with prescribed

pain management medications to reduce and relieve pain in cancer patients
undergoing chemotherapy.

Scenario 1.2: The software is intended to be used to reduce and relieve pain in
osteoarthritis patients that cannot take other pain relief medication.

847 In both scenarios in example 1 above, the intended use of the medical device software
848 is to provide therapy to reduce and relieve pain, where the cause of such pain (i.e., the
849 Intended Condition/Disease/Disorder and Grade/Stage/Level) is not the primary
850 distinguishing feature that contributes to understanding the risk of the medical device
851 software. Rather, in this case, understanding whether the medical device software is
852 intended to be used adjunctively (i.e., the Medical Purpose) contributes significantly to
853 potential hazards considered in the risk analysis of the software.
854 In scenario 1.2, the software is meant to provide therapy for patients who cannot
855 utilize other pain relief therapy. Because the software is itself intended as therapy and
856 cannot be used with, or adjunct to, additional treatment, the risk of the software could
857 be considered higher in scenario1.2 than 1.1. The failure of the software output to
858 provide efficacious therapy may be considered a single-point failure for achieving the
859 intent of patient pain reduction or relief, and therefore the intended medical purpose
860 may contribute to the hazards considered in risk analysis more than the software used
861 in conjunction with other therapy, described in scenario 1.1.
862 In these two scenarios for a similar medical device software, we see that within the
863 Medical Problem and/or Objective information grouping, characterization features
864 contribute to the risk of the software differently. For such a product, the Intended
865 Condition/Disease/Disorder and Grade/Stage/Level does not solely impact the risk
866 posed by the software, but a more detailed understanding of the Medical Purpose
867 contributes to a more complete understanding of the medical device software’s risk.

43
 IMDRF/SaMD WG/N81 DRAFT: 2024

Example 2: Software that aggregates data and highlights trends from a

wearable monitor (DHT) for patients diagnosed with heart failure

Scenario 2.1: The software is intended to aggregate data and highlight trends from
a wearable monitor for patients diagnosed with heart failure to help patients monitor
their risk of hospitalization. The software helps to provide simple data visualizations
to better understand the patient’s longitudinal data, such as tracking an individual’s
health, care usage, and outcomes over time.

Scenario 2.2: The software is intended to aggregate data and highlight trends from
a wearable monitor for patients diagnosed with heart failure to help patients and
their healthcare provider with longitudinal data about the patient’s heart health. The
software provides simple data visualizations, including highlighting trends, to help
the healthcare provider monitor their patient’s risk of hospitalization between
regularly scheduled visits and could be used to inform treatment-related decisions.

868 In example 2 above, the intended user for the medical device software in scenario 2.1
869 is limited to patients seeking to obtain more information about their own condition. In
870 scenario 2.2, healthcare providers are included in the intended user group and have
871 access to the data in addition to the patient themselves. In this case, a health care
872 professional has specialized training that provides them with additional context to
873 understand the data and trends the medical device software is highlighting, which a
874 patient may not have. For this reason, it might be considered that the Intended User in
875 scenario 2.2 may reduce hazards considered in risk analysis more than scenario 2.1,
876 because at least one intended user in scenario 2.2 has expertise and training to
877 appropriately understand and respond to the data they are receiving. The health care
878 professional is provided access to the data such that it is not essential for the patient
879 to independently identify if and when their data should be conveyed to their doctor.
880 However, it may also be worth considering that there is greater variability in the
881 Intended Users of the medical device software in scenario 2.2 than scenario 2.1,
882 because of the introduction of the clinician user. This difference also impacts the
883 understanding of risk posed by the software, where the information must be conveyed
884 adequately and appropriately to the different user groups. It is important to consider
885 that multiple factors may influence the risk associated with any given characterization
886 feature – a clinician or trained user does not always independently indicate a decrease
887 or increase applicable hazards in the risk analysis of a device.

Example 3: Software function that uses physiological data captured on a

wearable consumer product to determine the severity of symptoms in a
patient with Parkinson’s disease.

Scenario 3.1: The software is intended to aggregate measurements obtained from

a regulated medical device and analyzed to monitor the severity of symptoms such
as tremor in a patient with Parkinson’s disease.

Scenario 3.2: The software is intended to aggregate measurements obtained from

a wearable consumer product and analyzed to monitor the severity of symptoms
such as tremor in a patient with Parkinson’s disease.

44
 IMDRF/SaMD WG/N81 DRAFT: 2024

888 In example 3 above, the Input Source in scenario 3.1 is limited to measurements
889 obtained by a regulated medical device. In scenario 3.2, measurements are obtained
890 by a wearable consumer product that is not subject to regulatory oversight as a
891 medical device. In this case, the wearable consumer product may allow for expanded
892 opportunities for collecting patient data, however the aspects of the performance of
893 the wearable consumer product may be outside of the control of the developer. For
894 this reason, it may be considered that the Input Source in scenario 3.2 may pose more
895 applicable hazards for risk analysis than in scenario 3.1, because the manufacturer
896 developing the software may not have life cycle control over the source of the data it is
897 analyzing to monitor the severity of symptoms. In this case, additional steps may be
898 necessary for the manufacturer to monitor performance of the wearable consumer
899 product and to communicate any changes in performance to the user. In contrast,
900 scenario 3.1 which obtains measurements form a regulated medical device, benefits
901 from the verification and validation needed to obtain authorization (in cases where the
902 intended use is fit for purpose), which may reduce applicable hazards due to a greater
903 accuracy and precision of measurements of a product developed for the intended use.
904 Regulations applicable to software using consumer products to perform regulated
905 device functions vary by jurisdiction.

45
906

Please visit our website

for more details.

www.imdrf.org

Disclaimer
© Copyright 2024 by the International Medical Device Regulators Forum.
This work is copyright. Subject to these Terms and Conditions, you may download,
display, print, translate, modify and reproduce the whole or part of this work for your
own personal use, for research, for educational purposes or, if you are part of an
organisation, for internal use within your organisation, but only if you or your
organisation do not use the reproduction for any commercial purpose and retain all
disclaimer notices as part of that reproduction. If you use any part of this work, you must
include the following acknowledgement (delete inapplicable):
“[Translated or adapted] from [insert name of publication], [year of publication],
International Medical Device Regulators Forum, used with the permission of the
International Medical Device Regulators Forum. The International Medical Device
Regulators Forum is not responsible for the content or accuracy of this
[adaption/translation].”
All other rights are reserved, and you are not allowed to reproduce the whole or any
part of this work in any way (electronic or otherwise) without first being given specific
written permission from IMDRF to do so. Requests and inquiries concerning
reproduction and rights are to be sent to the IMDRF Secretariat.
Incorporation of this document, in part or in whole, into another document, or its
translation into languages other than English, does not convey or represent an
endorsement of any kind by the IMDRF.