Siemens Corporate Design PowerPoint
Transcription
Siemens Corporate Design PowerPoint
Logiciel Médical – USA, Europe, France Dr. Georg Heidenreich - COCIR Medical Software Task Force Restricted © Siemens AG 2014 All rights reserved. Page 1 Georg Heidenreich / H QT EHS TRS USA: Les lois pour les Logiciels Médicaux • Les Dispositifs Médicaux sont des produits qui répondent à la définition établie par l’article 201(h) de l’Organe de Certification des Médicaments et de la Nourriture (FDA = Food and Drug Administration). • Les documents liés aux appareils médicaux doivent être soumis à autorisation • Le titre 21 du CFR reprend les règles de la FDA • www.fda.gov permet d’accéder à de nombreuses informations légales. C’est une formidable base de données des soumissions/ rappels. • § 880.6310 Système de données de Dispositifs Médicaux. – ()…à pour but d’offrir au moins une des fonctions suivantes sans contrôler ou altérer les paramètres des dispositifs médicaux connectés: le transfert de données médicales, le stockage de données médicales, l’affichage de données médicales, la conversion de données médicales d’un format vers un autre selon des spécifications pré établies. • () ceci n’inclut pas les dispositifs dont l’utilisation prévoit une connexion avec des appareils qui « monitorent » les patients. • Dans le Registre Fédéral datant du 15 Février 2011 (76 FR 8637), la FDA a émis une dernière loi afin de classifier les MDSS dans des catégories allant de 3 (nécessitant une autorisation de mise sur ©leSiemens marché) à All 1 (soumis à des contrôles standards). Restricted AG 2014 rights reserved. Page 2 Georg Heidenreich / H QT EHS TRS Lois Européennes pour les logiciels médicaux • MDD 93/42 EEC : Les dispositifs médicaux sont prévus pour les diagnostics, les thérapies () avec des personnes identifiées. • Le document MEDDEV 2.1/6 définit si le logiciel dépend des Directives de l’EU sur les Dispositifs Médicaux. • Contrairement à ailleurs: Le sigle CE autorise la mise sur le marché • Les éditeurs doivent simplement fournir une Déclaration de Conformité qui prouve que les standards ont été appliqués. • Comme ailleurs: Les effets indirects des résultats (données) ne sont généralement pas pris en considération. • Les incidents “réels” sont des conséquences directes des SaMD (= Software as Medical Device) • Les règles des dispositifs médicaux peuvent être plus accessibles pour les logiciels médicaux lorsqu’il y a des concordances avec les IVD Restricted © Siemens AG 2014 All rights reserved. Page 3 Georg Heidenreich / H QT EHS TRS Lois Francaises pour les Logiciels Médicaux • Selon la Directive Européenne pour les Dispositifs Médicaux, les différents Etats devraient appliquer les mêmes règles … • …MAIS: Les lois françaises imposent une certification pour les logiciels liés aux médicaments. • critère #53 du référentiel de certification des logiciels d'aide à la prescription ambulatoire • http://www.has-sante.fr/portail/upload/docs/application/pdf/referentiel_certif_lap.pdf • …viole l’ Art 14 des lois sur le libre échange de l’UE • Les logiciels de prescription offrent un exemple de conséquences indirectes. Restricted © Siemens AG 2014 All rights reserved. Page 4 Georg Heidenreich / H QT EHS TRS - pas appropriés pour les Logiciels Médicaux? • Actuellement l’accent est mis sur les conséquences directes et les effets secondaires. • L’évaluation des risques n’est pas faite correctement par les structures légales en place. • Les ésultats (données) ne sont généralement pas pris en considération. • Les incidents sont des conséquences indirectes des SaMD (software as a medical device) • Les tests sont recommandés mais le développement des technologies est optionnel. • Les logiciels modernes utilisent le développement des technologies. • Les dispositifs médicaux sont soumis et approuvés par le plupart des législations. U.S.A ont tendance à dérèglementer • Le Japon vient au contraire d’adopter une réglementation pour les logiciels et la Chine vient également d’adopter une loi similaire mais pas pour les logiciels. • La plupart des pays acceptent les ventes lorsque les produits sont autorisés en Europe ou aux USA. EU a de bons schémas de qualification pour les logiciels médicaux, mais pas de contrôles spécifiques. Restricted © Siemens AG 2014 All rights reserved. Page 5 Georg Heidenreich / H QT EHS TRS Futur: La charte IMDRF - Concept Déclaration des SaMD: • But médical • Contexte d’utilisation • Fonctionnalités principales Contrôles correspondants Type I Conditions (1 -7) sont basées sur la déclaration et les risques Types I , II, III, IV font des regroupements par similarités et les profils des risques II III IV Contrôle commun Catégories des risques Niveau d’indépendance Catégories des risques Contrôles correspondants 6 Restricted © Siemens AG 2014 All rights reserved. Page 6 Georg Heidenreich / H QT EHS TRS Futur: Charte IMDRF SaMD - Résumé La charte IMDRF Phase II est plus adapté aux « conséquences indirectes prévisibles » • • • • • • • Les mesures techniques ne peuvent plus atténuer les conséquences indirectes. Les spécifications précisent l’utilisation prévue ce qui aide les intégrateurs et les opérateurs. Plus de transparence et de clarté pour toutes les acteurs impliqués. Les contrôles ont besoin de plus de clarifications et ont besoin d’être précisés Le lien vers le IEC 62304’s Safety Classes a été évité Le schéma de contrôle des risques est maintenant simplifié et mieux présenté Observation: Aucune évaluation des risques pour la population n’est couverte Proposition de travail sur « Gestion de Qualité des SaMD » • Observation: Ceci n’apparaît pas dans la Phase 2 pour des questions de timing. Restricted © Siemens AG 2014 All rights reserved. Page 7 Georg Heidenreich / H QT EHS TRS Futur: Les industriels devront émettre des déclarations d’utilisation des SaMD en alignement les uns avec les autres Une Déclaration claire et forte permettra la transparence nécessaire selon les types de SaMD Devra inclure les éléments suivants: Le but médical des SaMD: pourquoi cela correspond à la définition du Dispositif Médical. • Le Contexte d’utilisation des SaMD: pour qui, comment, l’état des patients, la population concernée, la condition médicale concernée, les limites des résultats. • Une Description des fonctionnalités principales des SaMD: : quelles sont les fonctions qui sont à but médical et le contexte d’utilisation. 8 Restricted © Siemens AG 2014 All rights reserved. Page 8 Georg Heidenreich / H QT EHS TRS Merci de votre attention! Restricted © Siemens AG 2014 All rights reserved. Page 9 Georg Heidenreich / H QT EHS TRS US Laws for Medical Software En pratique, un dispositif médical (MDDS) est un dispositif médical qui a pour but de fournir au moins une des fonctionnalités suivantes: …le transfert électronique ou l’échange de données avec le dispositif médical sans altérer les fonctions ou paramètres des dispositifs connectés. • Par exemple un logiciel qui récupère les données du respirateur d’un patient et du niveau de CO2. • Par exemple, un logiciel qui conserve les données sur la pression arterielle • Par exemple, un logiciel qui affiche un electrocardiogramme stocké d’un patient Restricted © Siemens AG 2014 All rights reserved. Page 10 Georg Heidenreich / H QT EHS TRS USA: Lois pour les Logiciels Médicaux Règles MDDS Dans le Registre Fédéral du 15 Février 2011 (76FR8637), la FDA a établi une règle afin de classifier les MDDS dans différentes classes: Catégorie III (doit être soumis à accord avant mise sur le marché) à la Catégorie I (soumis aux contrôles généraux). () Les risques associés aux MDDS inclut des transferts des données inopportuns , potentiellement incorrects ou incomplets, des problèmes de stockage, de conversion ou d’affichage des données sur les dispositifs médicaux. Dans certains cas, ceci peut amener à un diagnostic ou traitement erroné. En se basant sur une évaluation des risques, la FDA a déterminé les contrôles généraux tel que le Système de Régulation de la Qualité (21 CFR partie 820), qui assurent efficacité et sécurité. Ainsi des contrôles spécifiques et pré-évaluation de mise sur le marché peuvent être évités. Restricted © Siemens AG 2014 All rights reserved. Page 11 Georg Heidenreich / H QT EHS TRS US Laws for Medical Software In practice, a medical device data system (MDDS) is a medical device intended to provide one or more of the following functions: The electronic • …transfer or exchange of medical device data from a medical device, without altering the function or parameters of any connected devices. For example, this would include software that collects output from a ventilator about a patient's CO2 level and transmits the information to a central patient data repository. • …storage and retrieval of medical device data, without altering the function or parameters of connected devices. For example, software that stores historical blood pressure information for later review by a healthcare provider. • …conversion of medical device data from one format to another in accordance with a preset specification. For example, software that converts digital data generated by a pulse oximeter into a digital format that can be printed. • The electronic display of medical device data, without altering the function or parameters of connected devices. For example, software that displays the previously stored electrocardiogram for a particular patient. Restricted © Siemens AG 2014 All rights reserved. Page 12 Georg Heidenreich / H QT EHS TRS US Laws for Medical Software MDDS Rule In the Federal Register of February 15, 2011(76 FR 8637), the FDA issued a final rule to reclassify MDDS from Class III (subject to premarket approval) to Class I (subject to general controls). () Risks associated with MDDS include the potential for inaccurate, incomplete, or untimely data transfer, storage, conversion, or display of medical device data. In some cases, this can lead to incorrect patient diagnosis or treatment. Based on evaluation of these risks, the FDA has determined that general controls such as the Quality System Regulation (21 CFR part 820), will provide a reasonable assurance of safety and effectiveness. Therefore, special controls and premarket approval are not necessary. Restricted © Siemens AG 2014 All rights reserved. Page 13 Georg Heidenreich / H QT EHS TRS