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