Le piège insoupçonné ? La boîte noire des nouvelles exigences de DiGA

Chez medXteam, les données cliniques sont au cœur de notre activité. En tant qu'organisme de recherche sous contrat (CRO), nous réalisons des essais cliniques avec des dispositifs médicaux conformément au règlement MDR et à la norme ISO 14155, et proposons également toutes les autres options et modalités de collecte de données. Cette fois-ci, nous nous intéressons de nouveau aux applications de santé numérique (DiGA). Les données sont également collectées dans ce domaine. La question centrale est la suivante : quels sont les défis potentiels que les exigences des DiGA peuvent poser aux fabricants ?

Abréviations

BSI Bureau fédéral de la sécurité de l'information

Application de santé numérique DiGA

Dossier patient électronique ePA

Association nationale des médecins affiliés à l'assurance maladie obligatoire (KBV)

Règlement sur les dispositifs médicaux MDR ; Règlement UE 2017/745

Système de gestion de la qualité SMQ

Réglementations sous-jacentes

Règlement (UE) 2017/745 (RDM)
Loi relative à la mise en œuvre des dispositifs médicaux (MPDG)
ISO 14155
ISO 27001
Ligne directrice DiGA V3.4
Loi sur la modernisation des soins de santé numériques (DVPMG)
Règlement (UE) 2016/679 (RGPD)
Ligne directrice technique TR-03161

1. Introduction

Les applications de santé numérique (ASN) ont pris une importance croissante ces dernières années dans le domaine de la santé. Elles contribuent à améliorer les soins médicaux et facilitent l'accès aux services de santé. Elles offrent aux patients la possibilité de suivre leur santé et de gérer leurs maladies, tout en fournissant aux médecins des données précieuses pour une prise de décision éclairée.

Cependant, le cadre réglementaire des applications de santé numérique (ASN) présente non seulement des opportunités pour les patients et le personnel médical, mais aussi des défis pour les fabricants de ces produits. De nombreuses exigences ont déjà été définies, que les fabricants doivent mettre en œuvre et documenter dans des délais précis. Ces exigences, que nous examinerons plus en détail dans cet article, confrontent les fabricants à la question fondamentale de la classification de leurs logiciels médicaux. Si la plupart des ASN sont actuellement classées comme produits de classe I, la mise en œuvre des nouvelles exigences pourrait entraîner un reclassement. Il ne s'agit pas uniquement d'un enjeu réglementaire fondamental ; la certification du système de management de la qualité (SMQ), les coûts et les délais qui en découlent, ainsi que la nécessité de présenter le dossier aux investisseurs sont également des aspects importants de cette analyse.

Au vu du débat suscité dans notre dernier article de blog sur les raisons pour lesquelles les médecins hésitent principalement à prescrire des DiGAs, la question se pose de savoir comment les immenses défis seront liés aux avantages potentiels des applications numériques à l'avenir.

2. Exigences réglementaires pour les fabricants de DiGA

Même aujourd'hui, en tant que fabricant DiGA, vous êtes tenu de respecter certaines exigences en matière de développement de produits et de processus internes. Le chapitre suivant examine les exigences actuelles et futures, qui s'appuient en grande partie sur les directives DiGA.

2.1 Exigences applicables

Tous les fabricants sont actuellement tenus de disposer d'un système de gestion de la sécurité de l'information. Sa mise en place et sa certification, attestant de la conformité, sont obligatoires. Deux options sont possibles : la norme ISO 27001 ou la norme ISO 27001 basée sur la protection de base des systèmes d'information (norme BSI 200-2 : méthodologie de protection de base des systèmes d'information).

La loi relative à la modernisation des soins de santé numériques (DVPMG) stipule également que, quelles que soient les exigences de sécurité de l'application de santé numérique (DiGA), un test d'intrusion doit être réalisé sur tous ses composants. Les tests d'intrusion figurent parmi les « exigences fondamentales applicables à toutes les applications de santé numérique » énumérées à l'annexe 1. Le concept de mise en œuvre des tests d'intrusion du BSI et la liste des 10 principaux risques de sécurité de l'OWASP doivent servir de base à la conception des tests. La preuve de l'exécution des tests correspondants doit être fournie à l'Agence fédérale fédérale pour la recherche médicale (BfArM) sur demande.

2.2 Quelles nouvelles fonctionnalités seront ajoutées et quand ?

L’authentification sécurisée des assurés par le biais d’une identité numérique doit être mise en œuvre au 1er janvier 2024. Initialement, cette exigence devait être mise en œuvre au plus tard le 1er janvier 2023. Toutefois, les organismes d’assurance maladie ont jusqu’au 1er janvier 2024 pour créer cette identité numérique.

"Code social (SGB) Livre Cinq (V) - Assurance maladie obligatoire - (Article 1 de la loi du 20 décembre 1988, Journal officiel fédéral I p. 2477)
Section 291 Carte de santé électronique :
 (8) Au plus tard le 1er janvier 2024, les caisses d'assurance maladie doivent, sur demande, fournir aux assurés une identité numérique sécurisée pour le système de santé en plus de la carte de santé électronique, qui répond aux exigences du paragraphe 2, points 1 et 2, et permet la fourniture de données conformément à l'article 291a, paragraphes 2 et 3, par les caisses d'assurance maladie.

À compter du 1er janvier 2024 , l’exportation régulière et automatisée des données collectées par les applications de santé numérique (DiGA) vers le dossier patient informatisé (DPI) devra être garantie. L’Association nationale des médecins conventionnés (KBV) définit les exigences correspondantes en matière d’interopérabilité sémantique et syntaxique.

Une preuve sous forme de certificat conformément à l'article 42 du RGPD (Règlement (UE) 2016/679) de conformité aux exigences en matière de protection des données doit être disponible à partir du 01.08.2024

« Code social (SGB), Livre V – Assurance maladie obligatoire – (Article 1 de la loi du 20 décembre 1988, Journal officiel fédéral I, p. 2477),
Section 139e : Liste des applications de santé numérique ; Autorisation d’édicter des règlements :
(11) L’Institut fédéral des médicaments et des dispositifs médicaux, en accord avec le Préposé fédéral à la protection des données et à la liberté d’information et en consultation avec l’Office fédéral de la sécurité de l’information, établit, pour la première fois au plus tard le 31 mars 2022 et ensuite généralement chaque année, les critères de test relatifs aux exigences de protection des données que doivent démontrer les applications de santé numérique conformément au paragraphe 2, deuxième alinéa, point 2. À compter du 1er août 2024, le fabricant doit apporter la preuve de sa conformité aux exigences de protection des données en soumettant un certificat établi sur la base des critères de test visés au premier alinéa, conformément à l’article 42 du règlement (UE) 2016/679. »

La directive technique TR-03161 englobe les exigences relatives aux applications de santé définies par l'Office fédéral de la sécurité des technologies de l'information (BSI) et fait partie des exigences de sécurité des données pour une application de santé numérique (DiGA) conformément à l'article 139e, paragraphe 10, du livre V du Code social allemand (SGB V). Un certificat correspondant devra être fourni à compter du 1er janvier 2025

« Code social (SGB), Livre V – Assurance maladie obligatoire – (Article 1 de la loi du 20 décembre 1988, Journal officiel fédéral I, p. 2477),
Section 139e : Liste des applications de santé numérique ; Autorisation d’édicter des règlements :
(10) L’Office fédéral de la sécurité de l’information, en accord avec l’Institut fédéral des médicaments et des dispositifs médicaux et après consultation du Préposé fédéral à la protection des données et à la liberté d’information, établit, pour la première fois au plus tard le 1er janvier 2024 et ensuite généralement chaque année, les exigences de sécurité des données que doivent démontrer les applications de santé numérique conformément au paragraphe 2, alinéa 2, point 2. À compter du 1er juin 2024, l’Office fédéral de la sécurité de l’information propose des procédures de vérification de la conformité aux exigences visées à l’alinéa 1, ainsi que des procédures de confirmation de cette conformité au moyen de certificats correspondants. La preuve de la conformité aux exigences de sécurité des données par le fabricant doit être apportée par la soumission d’un certificat conformément à l’alinéa 2 au plus tard le 1er janvier 2025. »

3. Autres exigences

En principe, toutes les exigences réglementaires applicables aux dispositifs médicaux s'appliquent également aux applications de santé numérique. Cela signifie qu'une documentation technique doit être établie pour chaque application de santé numérique afin de démontrer sa conformité aux exigences essentielles de sécurité et de performance du règlement relatif aux dispositifs médicaux (RDM). Tout fabricant de dispositif médical est tenu de mettre en place un système de management de la qualité (SMQ) conforme à la norme ISO 13485 et à la réglementation applicable. Depuis l'entrée en vigueur du RDM, cette obligation s'applique également aux fabricants de dispositifs de classe I.

Cependant, les exigences en matière de numérique ne cessent de croître. Par exemple, la question se pose désormais de savoir s'il convient d'instaurer un droit de rétractation de 14 jours pour les patients après la première prescription de l'application de santé numérique (DiGA).

4. Conséquences de ces nouvelles exigences

Quelles conséquences ces exigences supplémentaires pourraient-elles entraîner ? Il convient de noter que les échéances étant encore lointaines, la gestion concrète des conséquences potentielles pour les fabricants reste hypothétique. L’expérience pratique ne sera acquise que dans les prochains mois. Néanmoins, un aspect des exigences apparaît particulièrement critique : la classification. La classification des logiciels repose essentiellement sur les règles de classification de l’annexe VIII du règlement (UE) 2017/7948 (RDM). Cependant, des documents d’orientation pertinents peuvent également être utilisés. La règle 11 stipule que « les logiciels destinés à fournir des informations utilisées pour la prise de décisions à des fins diagnostiques ou thérapeutiques sont classés en classe IIa ».

Imaginez le scénario hypothétique suivant : en tant que fabricant, vous avez implémenté avec succès toutes les fonctionnalités d’exportation et les exigences d’interopérabilité requises. Il est désormais possible d’exporter régulièrement et automatiquement les données collectées par votre application de santé numérique (DiGA) vers le dossier patient électronique (DPE) du patient, ainsi que d’exporter certaines informations de la DiGA en tant que patient. Votre concept DiGA inclut, entre autres, la fourniture de supports pour des exercices à réaliser à domicile. Supposons que Mme Müller se voie prescrire votre DiGA et l’utilise assidûment. Les données collectées sont transférées vers le DPE de Mme Müller, et son médecin traitant y a ainsi accès. De plus, Mme Müller exporte le contenu générique fourni par vous en tant que fabricant, qui contient également des données relatives à son utilisation personnelle de la DiGA. Lors de la consultation suivante de Mme Müller, l'utilisation de l'application DiGA est abordée (les données exportées par Mme Müller et celles de son dossier médical électronique sont disponibles). Son médecin traitant lui conseille alors d'interrompre l'exercice n° 5 dans son cas particulier. Ainsi, conformément à la règle 11, nous sommes théoriquement parvenus à un scénario où l'application DiGA (Application de santé numérique) a fourni des informations ayant incité le médecin à formuler des recommandations thérapeutiques pour Mme Müller. Résultat : grâce à la mise en œuvre des exigences, un produit de classe I est devenu un produit de classe IIa.

Les chapitres suivants examineront en détail les conséquences possibles d'une telle classification.

4.1 Certification

Nous avons déjà expliqué que depuis l'entrée en vigueur du règlement MDR, tout fabricant de dispositifs médicaux doit disposer d'un système de management de la qualité (SMQ). Cependant, seuls les fabricants de dispositifs de classe IIa et supérieures sont tenus de faire certifier leur SMQ. Pour les fabricants de classe I, la mise en place et le maintien d'une telle structure de processus suffisent. Si les exigences entraînent une classification supérieure, votre SMQ doit être certifié afin de garantir votre conformité continue à la réglementation applicable. Compte tenu des délais de transition liés au règlement MDR, cet aspect est sans doute le plus urgent et exige une attention immédiate quant aux conséquences potentielles d'une modification de la classification de votre produit.

4.2 Question des coûts/Investisseurs

Les exigences actuelles engendrent déjà des coûts importants pour les fabricants. Outre la réussite de l'audit de leur système de gestion de la sécurité de l'information (SGSI), le processus de collecte de données nécessaire à l'inscription de leurs applications de santé numérique (DiGA) est long et onéreux. Ces exigences supplémentaires représentent désormais une charge financière supplémentaire pour les fabricants, dont la viabilité économique dépend souvent de la volonté de leurs investisseurs.

4.3 Documentation technique

La documentation technique atteste de la conformité de chaque dispositif médical aux exigences fondamentales de sécurité et de performance du règlement MDR. Ses éléments clés comprennent la gestion des risques et le dossier d'utilisabilité, incluant les tests correspondants pour l'application du produit. Dans le cas d'un logiciel, le dossier logiciel constitue également une part importante de la documentation. Il englobe la définition des exigences et leur mise en œuvre concrète sous forme d'architecture, ainsi que toute autre documentation de processus pertinente permettant de vérifier et de valider le bon déroulement du développement. Le niveau de détail de cette documentation technique, notamment concernant le dossier logiciel, dépend entre autres de la classification du logiciel. En cas de classification supérieure, la documentation technique doit être révisée en conséquence, ce qui engendre des coûts et peut immobiliser temporairement les ressources de l'entreprise. De plus, elle doit alors être certifiée par un organisme notifié ; le fabricant ne peut plus établir lui-même la déclaration de conformité UE.

5. Lien avec le dernier article de blog

Dans notre dernier article de blog, nous avons examiné de plus près la réticence des médecins à prescrire des applications de santé numériques (ASN). Malgré leurs nombreux avantages, beaucoup de médecins hésitent à les prescrire. L'une des raisons est leur incertitude quant à leur efficacité. Des inquiétudes subsistent également concernant la sécurité et la confidentialité des données. Un autre facteur est le manque de temps et de ressources pour accompagner les patients dans l'utilisation des ASN. De plus, de nombreux médecins s'inquiètent de la charge de travail supplémentaire liée à la prescription et au suivi de ces applications. Enfin, la question du remboursement par les compagnies d'assurance maladie reste posée : une prescription pourrait-elle donner lieu à une demande de remboursement ?.

Les exigences relatives aux applications de santé numérique (ASN) décrites précédemment concernent principalement la sécurité et, surtout, la protection des données des applications mises sur le marché, répondant ainsi en partie aux réticences à les prescrire. Cependant, leur mise en œuvre représente également un risque commercial important pour les fabricants. Compte tenu des coûts supplémentaires engendrés par cette mise en œuvre, et considérant également la possibilité d'une progression lente des prescriptions pour les ASN homologuées, le seuil de rentabilité s'éloigne de plus en plus, et la viabilité économique du développement de telles ASN doit être sérieusement remise en question.

6. Conclusion

Les applications de santé numérique (ASN) ont le potentiel d'améliorer les soins médicaux et de faciliter l'accès des patients à ces soins. Cependant, les formidables opportunités offertes par ces produits sont contrebalancées par d'immenses défis, notamment pour les fabricants.

Suite à la mise en œuvre des exigences identifiées, nous avons pu déterminer la classification de l'application de santé numérique (DiGA). Cette classification concerne aussi bien les fabricants encore en phase de développement initial de leur produit que ceux ayant déjà obtenu une homologation préliminaire ou définitive de leur DiGA. Une classification potentiellement plus élevée aurait des conséquences importantes, notamment sur la certification du système de management de la qualité et de la documentation technique, ainsi que sur tous les aspects commerciaux (coûts, délais, investisseurs, etc.). Par conséquent, les fabricants doivent impérativement se pencher sur la question de la classification future appropriée de leur dispositif médical avant d'entreprendre toute démarche ultérieure.

Il est impossible de répondre avec certitude à la question initiale de savoir comment les immenses défis se traduiront par les avantages potentiels des applications numériques à l'avenir. Les exigences doivent être mises en œuvre dans les délais impartis, ce qui signifie que les conséquences pour les fabricants ne seront claires que dans les prochains mois. Toutefois, la multitude d'exigences démontre clairement que la réglementation stricte applicable à ce type de logiciel médical doit être réévaluée de toute urgence. En définitive, l'objectif est d'apporter une valeur ajoutée aux patients et de les accompagner dans la gestion de leur maladie au quotidien.

7. Comment nous pouvons vous aider

Nous serions heureux de vous aider à obtenir une inscription réussie de votre produit DiGA grâce à une évaluation préliminaire de sa classification en fonction des fonctionnalités prévues.

Chez medXteam, nous clarifions si et si oui quel essai clinique doit être réalisé dans quelles conditions et selon quelles exigences pendant la phase préalable à l'étude : En 3 étapes, nous déterminons la stratégie correcte et rentable par rapport à l'essai clinique requis. dans votre cas Collecte de données.

Si un essai clinique doit être réalisé, les exigences fondamentales de sécurité et de performance doivent d’abord être respectées. Les données de l’essai clinique alimentent ensuite l’évaluation clinique, qui à son tour constitue la base des activités de suivi clinique post-commercialisation (PMCF) (y compris une étude PMCF).

De plus, tous les fabricants de dispositifs médicaux doivent disposer d'un système de gestion de la qualité (SGQ), même lors du développement de produits de classe I.

Nous vous accompagnons tout au long de votre projet avec votre dispositif médical, depuis une première consultation gratuite, une aide à l'introduction d'un système QM, la planification et la mise en œuvre de l'étude jusqu'à la documentation technique - toujours avec une référence primaire aux données cliniques du produit : de du début à la fin Fin.

Avez-vous déjà quelques premières questions ?

Vous pouvez obtenir une première consultation gratuite ici : première consultation gratuite