Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Mdcg 2019 11 guidance on qualification and classification of software mdr-ivdr

7,771 views

Published on

Mdcg 2019 11 guidance on qualification and classification of software MDR and IVDR. Mistakers (and horrors)

Published in: Law
  • The community has truly come to feel like a family, somewhere I can be open, honest and myself. For me it has taken the battle out of my head and instead to somewhere I can get advice or simply tell about my daily struggles and triumphs. And be understood! Shaye's guide and her support and advice on the site are invaluable tools in this recovery journey, for which I am truly grateful :-) ▲▲▲ https://tinyurl.com/y88w4b6s
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Positions Available Now! We currently have several openings for writing workers.  https://tinyurl.com/vvgf8vz
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Mdcg 2019 11 guidance on qualification and classification of software mdr-ivdr

  1. 1. 1 FINALLY PUBLISHED Guidance on Classification for Software in MDR 2017/745 and IVDR 2017/746 MDCG 2019-11 Mistakes (and horrors) ☺ Antonio Bartolozzi antonio.bartolozzi@bartolozzi.it 18/06/2019 State of Healthcare situation or condition Significance of information provided by SaMD to healthcare decision Treat or diagnose Drive clinical management Inform clinical management Critical III/IIb III/IIb III/IIb Serious IIa IIa IIa Non-serious IIa IIa IIa
  2. 2. 2antonio.bartolozzi@bartolozzi.it MDCG 2019-11 - Document https://ec.europa.eu/docsroom/documents/37581?locale=en Guidance on Classification for Software in MDR 2017/745 and IVDR 2017/746 MDCG 2019-11
  3. 3. 3antonio.bartolozzi@bartolozzi.it WARNING – MDCG 2019-11 The document is not a European Commission document and it cannot be regarded as reflecting the official position of the European Commission. Any views expressed in this document are not legally binding and only the Court of Justice of the European Union can give binding interpretations of Union law
  4. 4. 4antonio.bartolozzi@bartolozzi.it Software – MDCG 2019-11 For the purpose of this guidance, “software” is defined as a set of instructions that processes input data and creates output data. • It is not a standard definition • The definition does not define a product !!! • Classification and Qualification process is only for products !!!!
  5. 5. 5antonio.bartolozzi@bartolozzi.it Software - ISO/IEC/IEEE 26512:2018 3.22 software all or part of the programs, procedures, rules, and associated documentation of an information processing system Note 1 to entry: For the purposes of this document, the term “software” does not include on-screen documentation. [SOURCE: IEEE Std 828-2012] A product include documentation and labeling !
  6. 6. 6antonio.bartolozzi@bartolozzi.it ISO 12207 : 2017 3.1.54 software product 3.1.54 software product set of computer programs, procedures, and possibly associated documentation and data Note 1 to entry: A software product is a software system viewed as the output (product) resulting from a process.
  7. 7. 7antonio.bartolozzi@bartolozzi.it Software - ISO/IEC 2382:2015 software <fundamental terms> all or part of the programs, procedures, rules, and associated documentation of an information processing system Note 1 to entry: Software is an intellectual creation that is independent of the medium on which it is recorded. Note 2 to entry: software: term and definition standardized by ISO/IEC [ISO/IEC 2382-1:1993]. Note 3 to entry: 01.01.08 (2382) [SOURCE: ISO-IEC-2382-1 * 1993 * * * ]
  8. 8. 8antonio.bartolozzi@bartolozzi.it MDSW – MDCG 2019-11 Medical Device Software (MDSW) Medical device software is software that is intended to be used, alone or in combination, for a purpose as specified in the definition of a “medical device” in the medical devices regulation15 or in vitro diagnostic medical devices regulation.16 This is not a product ! -> software is defined as a set of instructions that processes input data and creates output data SO it could be any part of a computer program • Do not define a product ! • I cannot apply the MDR to the MDSW!!!
  9. 9. 9antonio.bartolozzi@bartolozzi.it 3.12 MEDICAL DEVICE SOFTWARE EN 62304 software system that has been developed for the purpose of being incorporated into the medical device being developed or that is intended for use as a medical device NOTE This includes a medical device software product, which then is a medical device in its own right • Same name ! • Different defintions ! • Overlapped purposes! • This is a right defintion ! • it is appropriate only for the purposes of the EN 62304 (not for qualification and classification purposes) It is NOT a product Product
  10. 10. 10antonio.bartolozzi@bartolozzi.it ISO 12207 : 2017 3.1.55 software system 3.1.55 software system system for which software is of primary importance to the stakeholders Note 1 : In the most general case, a software system is comprised of hardware, software, people, and manual procedures. Note 2 : In a software system, software is the leading driver in meeting system requirements.
  11. 11. 11antonio.bartolozzi@bartolozzi.it Software as a Medical Device - IMDRF SaMD is defined as software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device. http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech- 140918-samd-framework-risk-categorization- 141013.pdf#search=%22Framework%20for%20Risk%20Catego rization%20and%20Corresponding%20%22 NOT software Embedded in hardware MD SAMD IS A PRODUCT ! I can use this definition for qualification process This is appropriate for a classifcation and qualification guideline!
  12. 12. 12antonio.bartolozzi@bartolozzi.it Is there a Legal base for using IMDRF Guide (with MDR)? (5) To the extent possible, guidance developed for medical devices at international level, in particular in the context of the Global Harmonization Task Force (GHTF) and its follow-up initiative, the International Medical Devices Regulators Forum (IMDRF), should be taken into account to promote the global convergence of regulations which contributes to a high level of safety protection worldwide, and to facilitate trade, in particular in the provisions on Unique Device Identification, general safety and performance requirements, technical documentation, classification rules, conformity assessment procedures and clinical investigations Legal base We can use IMDRF definitions in a qualification and classification guideline ! … So why not use it ?
  13. 13. 13antonio.bartolozzi@bartolozzi.it Qualification MDCG 2019-11 However, software which is intended to process, analyse, create or modify medical information may be qualified as a medical device software if the creation or modification of that information is governed by a medical intended purpose. For example, the software which alters the representation of data for a medical purpose would qualify as a medical device software. You can qualify only products ! Are they talking about standalone software ? Software can directly control a (hardware) medical device (e.g. radiotherapy treatment software), can provide immediate decision-triggering information (e.g. blood glucose meter software), or can provide support for healthcare professionals (e.g. ECG interpretation software). This software are part of the medical devices are not product ! And for sure are not stand-alone software!
  14. 14. 14antonio.bartolozzi@bartolozzi.it Decision steps for qualification of software as MDSW There is no definition of a product ‘Software’ in the guideline. Is this Software or product ‘software’ or software included in the product ? MDR Covers only products !!! Software and MDSW are not products !!! What about Rule 11 ?
  15. 15. 15antonio.bartolozzi@bartolozzi.it MDR rule 3.3 of Annex VIII Software, which drives a device or influences the use of a device, shall fall within the same class as the device. If the software is independent of any other device, it shall be classified in its own right. This means that a external software product that drives a MD or influences a MD has the same class. Software product that drives a infusion pump Software has the same class of the infusion pump
  16. 16. 16antonio.bartolozzi@bartolozzi.it MDR rule 3.5 of Annex VIII 3.5. If several rules, or if, within the same rule, several sub-rules, apply to the same device based on the device's intended purpose, the strictest rule and sub-rule resulting in the higher classification shall apply.
  17. 17. 17antonio.bartolozzi@bartolozzi.it MDR rule 3.5 - Example - MDCG 2019-11 Melanoma image analysis software intended to be used with a near-infrared laser light scanner, which is considered class IIa per Rule 10. The software “drives or influences the use of” the near- infrared laser light scanner as it is intended to take control of the scanner by letting it execute proprietary multi-exposure programs for the detection of melanoma. As such, implementing rule 3.3 applies. However, Rule 11 would also apply based on the intended medical purpose of the software e.g. cancer diagnosis. The MDSW would be classified as class III based on Rule 11 (see section Classification Rules) and per implementing rule 3.5 of Annex VIII. Is there a unacceptable RISK - of death or an irreversible deterioration of a person's state of health - after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM? NO There are a number of RISK CONTROL measures before a death or an irreversible deterioration of a person's state of health (e.g. patient visit by the physician). Is there a unacceptable RISK - of a serious deterioration of a person's state of health - after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM? YES Class IIb
  18. 18. 18antonio.bartolozzi@bartolozzi.it c.1.) Electronic Patient Record Systems (EPR)- MDCG 2019-11 Electronic patient record systems are intended to store and transfer electronic patient records. They archive all kinds of documents and data related to a specific patient. The electronic patient records should not be qualified as a medical device, i.e. an electronic patient record that simply replaces a patient’s paper file does not meet the definition of a medical device. What about Rule 11 ? Sub-rule 11a), states that MDSW (which is intended to provide information which is used to take decisions with diagnosis or therapeutic purposes) is classified as class IIa. (Pag 13 4.2 Classification Rules MDCG 2019-11) EPR are intended to provide information which is used to take decisions with diagnosis or therapeutic purposes! E.g. Vital parameters (SpO2, NIBP, IBP, HR, etc.) are stored and shown by EPR CLASS IIa
  19. 19. 19antonio.bartolozzi@bartolozzi.it c.1.1.) CIS / Patient Data Management Systems – PDMS – MDCG 2019-11 A CIS/PDMS is a software-based system primarily intended to store and transfer patient information generated in association with the patient’s intensive care treatment (e.g. intensive care units). Usually the system contains information such as patient identification, vital intensive care parameters and other documented clinical observations. These CIS/PDMS are not qualified as medical devices. PDMS intended use is to automatically document vital parameters sampled by monitors and to replace handwritten medical files for clinical use. Clinical Benefits of PDMS* Yes(%) No(%) Undecided(%) PDMS helps save time 68 10 22 PDMS faciliates compliance with standards of therapy 66 16 18 PDMS supports therapy- planning 42 12 46 PDMS faciliates therapeutic decision 34 14 52 *Patient Data Management Systems in Critical Care REINHOLD FRETSCHNER, WOLFGANG BLEICHER, ALEXANDRA HEININGER, and KLAUS UNERTL Klinik für Anaesthesiologie der Universität Tübingen, Tübingen, Germany PDMS are intended to provide information which is used to take decisions with diagnosis or therapeutic purposes! Class IIa What about rule 11?
  20. 20. 20antonio.bartolozzi@bartolozzi.it Rule 11 – subrule b) Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as class IIb.
  21. 21. 21antonio.bartolozzi@bartolozzi.it Sub-rule 11 b) - MDCG 2019-11 Sub-rule 11b) was introduced to ensure that MDSW which has the same intended purpose as (hardware) devices which would fall under rule 10, third indent, are in the same risk class. However, this sub rule applies to MDSW intended to be used for monitoring any/all physiological processes and not just vital physiological processes (equivalent to rule 10, third indent ). Vital physiological processes and parameters include, for example, respiration, heart rate, cerebral functions, blood gases, blood pressure and body temperature. the same intended use implented in a pure hardware MD, and in a pure software MD have two different classifications. monitoring NON vital physiological processes Hardware MD Class I Software MD Class IIa/IIb Is a Art 51 violation?
  22. 22. 22antonio.bartolozzi@bartolozzi.it MDR Art. 51 Art.51: Devices shall be divided into classes I, IIa, IIb and III, taking into account the intended purpose of the devices and their inherent risk. <omissis> Devices cannot be divided into classes, taking into account the «device design and construction methods» Is Rule 11 complaint with Art. 51?
  23. 23. 23antonio.bartolozzi@bartolozzi.it Medical Device Software (MDSW) MDCG 2019-11 Medical device software (MDSW) is a term used throughout this document and shall be meant as all software that is intended to be used, alone or in combination, for a medical purpose specified in the definition of a “medical device” in the MDR or IVDR, regardless of whether the software is independent or is driving or influencing the use of a device. MDCG 2019-11 MDSW <> SaMD
  24. 24. 24antonio.bartolozzi@bartolozzi.it What about Rule 11 and Art. 51? SaMD standalone is for sure more dangerous than MD hardware and MD firmware. SaMD (standalone) is running into not strictly controlled environment (low controls for operating systems, hardware, other running software /SOUP, antivirus). If (Software = SaMD ) then Software in Rule 11 complies with Art. 51.
  25. 25. 25antonio.bartolozzi@bartolozzi.it Reductio ad absurdum. Rule 11 vs art. 51 absurdum Software embedded (i.e. firmware) is more dangerous than hardware Software embedded (i.e. firmware) is safe as hardware. Really, there is no difference at all between hardware and firmware: some CPUs has microcode (=firmware) that runs inside processors. Firmware is running in a strictly controlled environment. There is no reason that software embedded part of hardware MD, is more dangerous than «pure» hardware device. Devices cannot be divided into classes, taking into account the device design and construction methods Devices shall be divided into classes I, IIa, IIb and III, taking into account the intended purpose of the devices and their inherent risk If (Software = MD firmware ) then Rule 11 Software = SaMD
  26. 26. 26antonio.bartolozzi@bartolozzi.it Usability of the IMDRF risk classification framework in the context of the MDR - MDCG 2019-11 Significance of Information provided by the MDSW to a healthcare situation related to diagnosis/therapy StateofHealthcare situationorcondition High Treat or diagnose ~ IMDRF 5.1.1 Medium Drives clinical management ~ IMDRF 5.1.2 Low Informs clinical management (everything else) Critical situation or condition ~ IMDRF 5.2.1 Class III Type IV.i Class IIb Type III.i Class IIa Type II.i Serious situation or condition ~ IMDRF 5.2.2 Class IIb Type III.ii Class IIa Type II.ii Class IIa Type I.ii Non-serious situation or condition (everything else) Class IIa Type II.iii Class IIa Type I.iii Class IIa Type I.i The IMDRF codes are inverted from what defined in IMDRF document!!!!!!
  27. 27. 27antonio.bartolozzi@bartolozzi.it Factors Important for SaMD characterization The intended use of the information provided by SaMD in clinical management has different significance on the action taken by the user: 1. Treat or diagnose 2. Drive clinical management 3. Inform clinical management
  28. 28. 28antonio.bartolozzi@bartolozzi.it To treat or to diagnose Treating and diagnosing infers that the information provided by the SaMD will be used to take an immediate or near term action: • To treat/prevent or mitigate by connecting to other medical devices, medicinal products, general purpose actuators or other means of providing therapy to a human body • To diagnose/screen/detect a disease or condition (i.e., using sensors, data, or other information from other hardware or software devices, pertaining to a disease or condition). We can take (immediate) decisions with diagnosis or therapeutic purposes
  29. 29. 29antonio.bartolozzi@bartolozzi.it To drive clinical management Driving clinical management infers that the information provided by the SaMD will be used to aid in treatment, aid in diagnoses, to triage or identify early signs of a disease or condition will be used to guide next diagnostics or next treatment interventions: • To aid in treatment by providing enhanced support to safe and effective use of medicinal products or a medical device. • To aid in diagnosis by analyzing relevant information to help predict risk of a disease or condition or as an aid to making a definitive diagnosis. • To triage or identify early signs of a disease or conditions. We can (aid to) take decisions with diagnosis or therapeutic purposes
  30. 30. 30antonio.bartolozzi@bartolozzi.it To Inform clinical management Informing clinical management infers that the information provided by the SaMD will not trigger an immediate or near term action: • To inform of options for treating, diagnosing, preventing, or mitigating a disease or condition. • To provide clinical information by aggregating relevant information (e.g., disease, condition, drugs, medical devices, population, etc.) We can take decisions (non-immediate) with diagnosis or therapeutic purposes
  31. 31. 31antonio.bartolozzi@bartolozzi.it Factors Important for SaMD characterization The intended use of the information provided by SaMD in clinical management has different significance on the action taken by the user: 1. Treat or diagnose 2. Drive clinical management 3. Inform clinical management 1. ...Immediate.. 2. …To Aid… 3. ..Non-immediate... decisions with diagnosis or therapeutic purposes
  32. 32. 32antonio.bartolozzi@bartolozzi.it IMDRF SaMD Categories State of Healthcare situation or condition Significance of information provided by SaMD to healthcare decision Treat or diagnose Drive clinical management Inform clinical management Critical IV III II Serious III II I Non-serious II I I
  33. 33. 33antonio.bartolozzi@bartolozzi.it IMDRF SaMD Categories State of Healthcare situation or condition Significance of information provided by SaMD to healthcare decision diagnosis or therapeutic purposes always involved Treat or diagnose Immediate Drive clinical management aid Inform clinical management Non-immediate Critical IV III II Serious III II I Non-serious II I I
  34. 34. 34antonio.bartolozzi@bartolozzi.it Considerandum 58 (serious adverse event) “serious adverse event” means any adverse event that led to any of the following: a) death, b) serious deterioration in the health of the subject, that resulted in any of the following: i. life-threatening illness or injury, ii. permanent impairment of a body structure or a body function, iii. hospitalisation or prolongation of patient hospitalisation, iv. medical or surgical intervention to prevent life-threatening illness or injury or permanent impairment to a body structure or a body function, v. chronic disease, c) foetal distress, foetal death or a congenital physical or mental impairment or birth defect;
  35. 35. 35antonio.bartolozzi@bartolozzi.it IMDRF Critical vs MDR Serious IFMDR Guide (Critical condition) MDR Serious «condition» Situations or conditions where accurate and/or timely diagnosis or treatment action is vital to avoid death, long-term disability or other serious deterioration of health of an individual patient or to mitigating impact to public health. SaMD is considered to be used in a critical situation or condition where: • The type of disease or condition is: o Life-threatening state of health, including incurable states, o Requires major therapeutic interventions, o Sometimes time critical, depending on the progression of the disease or condition that could affect the user’s ability to reflect on the output information. • Intended target population is fragile with respect to the disease or condition (e.g.,pediatrics, high risk population, etc.) • Intended for specialized trained users. a) serious deterioration in the health of the subject, that resulted in any of the following: i. life-threatening illness or injury, ii. permanent impairment of a body structure or a body function, iii. hospitalisation or prolongation of patient hospitalisation, iv. medical or surgical intervention to prevent life- threatening illness or injury or permanent impairment to a body structure or a body function, v. chronic disease, MDR Rule 11 : a serious deterioration of a person's state of health or a surgical intervention (IIb) MDR Rule 11 : death or an irreversible deterioration of a person's state of health (III) WARNING: A life-threatening disease is a very serious one that can cause death!
  36. 36. 36antonio.bartolozzi@bartolozzi.it MDR inconsistency life-threatening disease (➔may cause death) and an irreversible deterioration of a person's state of health seems included in a serious deterioration in the health of the subject (see Considerandum 58) Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause: • death or an irreversible deterioration of a person's state of health, in which case it is in class III; or • a serious deterioration of a person's state of health or a surgical intervention, in which case it is classified as class IIb. Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as class IIb. All other software is classified as class I !?
  37. 37. 37antonio.bartolozzi@bartolozzi.it Serious situation or condition (IMDRF) Situations or conditions where accurate diagnosis or treatment is of vital importance to avoid unnecessary interventions (e.g., biopsy) or timely interventions are important to mitigate long term irreversible consequences on an individual patient’s health condition or public health. SaMD is considered to be used in a serious situation or condition when: • The type of disease or condition is: o Moderate in progression, often curable, o Does not require major therapeutic interventions, o Intervention is normally not expected to be time critical in order to avoid death, longterm disability or other serious deterioration of health, whereby providing the user an ability to detect erroneous recommendations. • Intended target population is NOT fragile with respect to the disease or condition. • Intended for either specialized trained users or lay users. Note: SaMD intended to be used by lay users in a "serious situation or condition" as described here, without the support from specialized professionals, should be considered as SaMD used in a "critical situation or condition". Seriuous condition (IMDRF guide) Non-Serious condition (MDR)
  38. 38. 38antonio.bartolozzi@bartolozzi.it MDR Classification using IMDRF guide State of Healthcare situation or condition (IMDRF) Significance of information provided by SaMD to healthcare decision (always Treat or diagnose Drive clinical management Inform clinical management Critical IIb IIb IIb Serious IIa IIa IIa Non-serious IIa IIa IIa Non-serious MDR serious MDR
  39. 39. 39antonio.bartolozzi@bartolozzi.it Better one ☺ Significance of Information provided by the MDSW to a healthcare situation related to diagnosis/therapy StateofHealthcare situationorcondition High Treat or diagnose ~ IMDRF 5.1.1 Medium Drives clinical management ~ IMDRF 5.1.2 Low Informs clinical management (everything else) Critical situation or condition ~ IMDRF 5.2.1 Class III/IIb Type IV.i Class III/IIb Type III.ii Class III/IIb Type II.iii Serious situation or condition ~ IMDRF 5.2.2 Class IIa Type III.i Class IIa Type II.ii Class IIa Type I.ii Non-serious diagnostic or therapeutic actions Class IIa Type II.i Class IIa Type I.i Class IIa Type I.iii
  40. 40. 40antonio.bartolozzi@bartolozzi.it Example II.i – MDCG 2019-11 (pag. 27) MDSW intended to rank therapeutic suggestions for a health care professional based on patient history, imaging test results, and patient characteristics, for example, MDSW that lists and ranks all available chemotherapy options for BRCA-positive individuals, should be classified as class IIa per Rule 11(a) ‾ IMDRF Risk Category II.i as it informs clinical management for cancer, a critical disease. State of Healthcare situation or condition Significance of information provided by SaMD to healthcare decision Treat or diagnose Immediate Drive clinical management aid Inform clinical management Non- immediate Critical IV III II Serious III II I Non-serious II I I II.iii SaMD that provides information to inform clinical management for a disease or conditions in a critical situation or condition is a Category II and is considered to be of medium impact. Class IIb/III
  41. 41. 41antonio.bartolozzi@bartolozzi.it Type II.iii IMDRF ➔ III/IIb MDR Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes <when> such decisions have an impact that may cause: • death or an irreversible deterioration of a person's state of health, in which case it is in class III (?) • a serious deterioration of a person's state of health or a surgical intervention, in which case it is classified as class IIb Significance of Information provided by the MDSW to a healthcare situation related to diagnosis/ therapy StateofHealthcare situationor condition Low Informs clinical management (everything else) Critical situation or condition ~ IMDRF 5.2.1 Class IIa Class III(?)/IIb Type II.iii Software can cause a (non immediate) critical condition (a serious deterioration of a person's state of health or a surgical intervention, life-threatening illness or injury included ) III(?)/IIb critical condition It is not «II.i» !
  42. 42. 42antonio.bartolozzi@bartolozzi.it Conclusions • IMDRF definitions do not map the MDR definitions • Does the MDSW definition comply with MDR Rule 11 and Art. 51? • There is a lot of mistakes • Some Examples and the flow chart are nearly the same in MDCG2019-11 as in the old MEDDEV 2.1/6 (it seams do not take into account the new rule 11) This guideline is not legally binding, but … please justify any deviation Stay tunned for video lesson! ☺

×