Le piège non détecté ? La boîte noire des nouvelles exigences DiGA

Chez medXteam, l’accent est mis sur les données cliniques. Dans ce contexte, en tant que CRO, nous effectuons non seulement des essais cliniques avec des dispositifs médicaux conformément aux normes MDR et ISO 14155, mais proposons également toutes les autres options et formes de collecte de données. Cette fois, le sujet du DiGA s'inscrit à nouveau dans ce contexte. Des données sont également collectées ici. Mais cette fois, l'accent est mis sur la question : quels défis potentiels se cachent derrière les exigences DiGA pour les fabricants ?

Abréviations

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

Application de santé numérique DiGA

Dossier patient électronique ePA

KBV Association nationale des médecins de l'assurance maladie légale

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 (MDR)
Loi de mise en œuvre des dispositifs médicaux (MPDG)
ISO 14155
ISO 27001
Guide DiGA V3.4
Loi sur la modernisation de l'approvisionnement et des soins numériques (DVPMG)
Règlement UE 2016/679 (RGPD)
Directive technique TR -03161

1. Introduction

Les DiGA (Digital Health Applications) sont devenues de plus en plus importantes en tant qu'applications numériques dans le domaine de la santé ces dernières années. Ils peuvent contribuer à améliorer les soins médicaux et faciliter l’accès aux services de santé. Ils offrent aux patients la possibilité de surveiller leur santé et de gérer leur maladie tout en fournissant aux médecins des données précieuses pour prendre de meilleures décisions.

Cependant, outre les opportunités pour les patients et le personnel médical, le contexte réglementaire des DiGA présente également des défis pour les fabricants de ces produits. De nombreuses exigences ont déjà été définies, qui doivent être mises en œuvre par les fabricants dans certains délais et documentées par des preuves appropriées. En raison de ces exigences, que nous examinerons plus en détail dans cet article, les fabricants sont notamment confrontés à la question clé de la classification de leur logiciel médical. Bien que la plupart des DiGA soient actuellement classés comme produits de classe I, une classification plus élevée pourrait résulter de la mise en œuvre des nouvelles exigences. Il ne s’agit pas seulement d’une question fondamentalement réglementaire : la certification du système de gestion de la qualité (QMS), les problèmes de coûts et de délais qui en résultent ainsi que l’argumentation auprès des investisseurs constituent également des piliers importants de cette réflexion.

Si l’on prend en compte le débat dans notre dernier article de blog sur les raisons pour lesquelles les médecins sont particulièrement réticents à prescrire des DiGA, 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

En tant que fabricant DiGA, il est actuellement nécessaire de mettre en œuvre certaines exigences dans le cadre du développement de produits et des processus internes de l'entreprise. Le chapitre suivant met en évidence à la fois les exigences actuelles et celles à mettre en œuvre à l'avenir, qui sont en grande partie basées sur les directives DiGA.

2.1 Exigences applicables

Tous les fabricants ont actuellement besoin d'un système de gestion de la sécurité de l'information. L’établissement/mise en œuvre et la certification sont requis comme preuve. Il existe deux options : selon la norme ISO 27001 ou « ISO 27001 basée sur l'IT-Grundschutz (norme BSI 200-2 : méthodologie IT-Grundschutz) ».

La loi sur la modernisation de l'approvisionnement et des soins numériques (DVPMG) stipule également qu'un test d'intrusion doit être effectué pour tous les composants, quelles que soient les exigences de protection du DiGA. Les tests d'intrusion font partie des « exigences de base applicables à toutes les applications de santé numérique » figurant à l'annexe 1. Le concept de mise en œuvre du BSI pour les tests d'intrusion et les 10 principaux risques de sécurité actuels de l'OWASP doivent servir de base au concept de test. Sur demande, le BfArM doit être présenté avec la preuve que les tests correspondants ont été effectués.

2.2 Quoi de neuf et quand ?

L’authentification sécurisée des assurés via l’identité numérique doit être mise en œuvre le 1er janvier 2024 Initialement, cette exigence devait être mise en œuvre au plus tard le 1er janvier 2023. Toutefois, les mutuelles ont jusqu’au 1er janvier 2024 pour créer l’identité numérique :

"Code social (SGB) Cinquième Livre (V) - Assurance maladie obligatoire - (Article 1er de la loi du 20 décembre 1988, BGBl. I p. 2477)
§ 291 Carte de santé électronique :
(8) À partir du 1er janvier 2024 à En plus de la carte de santé électronique, les caisses d'assurance maladie peuvent, sur demande, fournir à l'assuré une identité numérique sécurisée et sans obstacle pour le système de santé, qui répond aux exigences du paragraphe 2, numéros 1 et 2 et permet à l'assurance maladie les entreprises doivent fournir des données conformément à l'article 291a, paragraphes 2 et 3."

À partir du 1er janvier 2024, une exportation régulière et automatisée des données collectées par le DiGA vers le dossier électronique du patient (ePA) doit être garantie. L'Association nationale des médecins de l'assurance maladie légale (KBV) définit les exigences correspondantes en matière d'interopérabilité sémantique et syntaxique.

Une preuve sous la forme d'un certificat conformément à l'article 42 du RGPD (Règlement (UE) 2016/679) du respect des exigences en matière de protection des données doit être disponible 1er août 2024

"Code social (SGB) Cinquième Livre (V) - Assurance maladie obligatoire - (Article 1 de la loi du 20 décembre 1988, Journal officiel de la République fédérale d'Allemagne I p. 2477)
§ 139e Annuaire des applications de santé numériques ; Autorisation d'édicter des règlements :
( 11) L'Institut fédéral des médicaments et des appareils médicaux, en accord avec le Préposé fédéral à la protection des données et à la liberté d'information et en accord avec l'Office fédéral de la sécurité de l'information, devra, pour la première fois avant le 31 mars 2022, puis généralement chaque année , précise les critères de test pour les exigences à démontrer par les applications de santé numérique Protection des données conformément au paragraphe 2 phrase 2 numéro 2. À partir du 1er août 2024, la preuve du respect des exigences en matière de protection des données par le fabricant doit être fournie par la présentation d'une certificat conformément à l’article 42 du règlement (UE) 2016/ 679 pour conduire."

La directive technique TR-03161 comprend les exigences définies par l'Office fédéral pour la sécurité de l'information (BSI) pour les applications dans le secteur de la santé et fait partie des exigences en matière de sécurité des données d'un DiGA selon l'article 139e paragraphe 10 SGB V. À partir du 1er janvier, 2025, il y en a un correspondant Certificat à présenter.

"Code social (SGB) Cinquième Livre (V) - Assurance maladie légale - (Article 1 de la loi du 20 décembre 1988, BGBl. I p. 2477)
§ 139e Annuaire des applications numériques de santé ; Autorisation d'édicter des règlements :
(10 ) L'Office fédéral de la sécurité des technologies de l'information, en accord avec l'Institut fédéral des médicaments et des dispositifs médicaux et en accord avec le Préposé fédéral à la protection des données et à la liberté d'information, fixe les exigences en matière de sécurité des données qui doivent être démontrées par les applications numériques de santé. conformément au paragraphe pour la première fois avant le 1er janvier 2024, puis généralement chaque année 2 phrase 2 numéro 2. À partir du 1er juin 2024, l'Office fédéral de la sécurité de l'information proposera également des procédures de contrôle du respect des exigences selon la phrase 1 comme procédures permettant de confirmer le respect des exigences selon la phrase 1 au moyen de certificats appropriés. Le respect des exigences en matière de sécurité des données par le fabricant doit être effectué par la présentation d'un certificat conformément à la phrase 2 à partir du 1er janvier 2025 au plus tard.

3. Autres exigences

En principe, toutes les exigences réglementaires qui s’appliquent généralement à tous les dispositifs médicaux s’appliquent également aux applications de santé numérique. Une documentation technique doit également être créée pour une application de santé numérique, qui est utilisée pour démontrer la conformité aux exigences de base en matière de sécurité et de performances du MDR. Chaque fabricant d'un dispositif médical a besoin d'un système de gestion de la qualité basé sur la norme ISO 13485 basé sur la réglementation applicable. Depuis l’entrée en vigueur du MDR, cela s’applique également aux fabricants de produits de classe I.

Mais l’éventail des exigences liées à l’environnement numérique continue de s’élargir. Par exemple, se pose désormais la question supplémentaire de savoir si une forme de droit de retour de 14 jours devrait être introduite pour les patients après la prescription initiale du DiGA.

4. Conséquences de ces nouvelles exigences

Quelles conséquences ces exigences supplémentaires pourraient-elles entraîner ? Il faut dire que les délais se situent actuellement dans le futur, c'est pourquoi la gestion réelle des conséquences possibles pour les fabricants reste encore un espace hypothétique. Une expérience réaliste ne sera disponible que dans les mois à venir. Néanmoins, un aspect en particulier apparaît particulièrement sensible au regard des exigences : la classification . La classification des logiciels s'appuie généralement sur les règles de classification de l'annexe VIII du MDR. Cependant, il existe également des documents d’orientation valides qui peuvent être utilisés à titre d’aide. La règle 11 précise que « les logiciels destinés à fournir des informations utilisées pour prendre des décisions à des fins diagnostiques ou thérapeutiques appartiennent à la classe IIa ».

Imaginez maintenant le scénario hypothétique suivant : en tant que fabricant, vous avez mis en œuvre avec succès toutes les fonctionnalités d'exportation et exigences d'interopérabilité requises. Il est désormais possible de réaliser un export régulier et automatisé des données collectées avec votre DiGA vers l'ePA du particulier, ainsi que d'exporter certaines informations du DiGA en tant que patient. Votre concept DiGA comprend, entre autres, la mise à disposition de matériel pour les exercices que les patients doivent faire à la maison. Supposons maintenant que Mme Müller se voit prescrire son DiGA et qu'elle l'utilise ensuite avec diligence. Les données collectées sont envoyées à l'ePA de Mme Müller afin que son médecin traitant ait accès à ces données. En outre, Mme Müller exporte le contenu générique fourni par vous en tant que fabricant, qui contient également des données sur la candidature individuelle de Mme Müller. Lors de la prochaine visite chez le médecin de Mme Müller, l'utilisation du DiGA est discutée (l'exportation de Mme Müller ainsi que les données de l'ePA sont disponibles), après quoi son médecin traitant lui suggère de ne plus faire l'exercice n° 5 dans son cas explicite de maladie à réaliser. Ainsi, selon la règle 11, nous nous retrouvions en théorie dans un scénario dans lequel la DiGA fournissait des informations qui conduisaient le médecin à faire des recommandations de traitement à Mme Müller. Résultat du scénario : un produit de classe I est devenu un produit de classe IIa grâce à la mise en œuvre des exigences.

Les conséquences possibles d’une telle classification sont examinées en détail dans les chapitres suivants.

4.1 Attestation

Nous avons déjà expliqué que depuis l’entrée en vigueur du MDR, tout fabricant d’un dispositif médical doit disposer d’un QMS. Cependant, ce n'est que pour les fabricants possédant un produit de classe IIa ou plus que ce système de gestion de la qualité doit également être certifié. Pour les fabricants de classe I, mettre en place et vivre une telle structure de processus est suffisant. Si les exigences aboutissent à une classification plus élevée, votre système de gestion de la qualité doit être certifié afin que vous, en tant que fabricant, continuiez à vous conformer aux réglementations applicables. Compte tenu des délais de transition MDR, cet aspect est probablement l'un des facteurs les plus critiques et nécessite une considération immédiate des conséquences possibles de la classification pour votre produit .

4.2 Question de coût/investisseurs

Les exigences actuelles entraînent déjà des coûts élevés pour les fabricants. Il est non seulement important de réussir un audit de la mise en œuvre du système de gestion de la sécurité de l’information (ISMS), mais le chemin depuis la collecte de données jusqu’à l’inscription réussie sur DiGA est également long et coûteux. En raison des exigences supplémentaires à mettre en œuvre, les fabricants sont désormais confrontés à un bloc de coûts supplémentaire, qui, d'un point de vue économique, dépend souvent de la volonté de leurs investisseurs.

4.3 Documentation technique

La documentation technique constitue la base de chaque produit médical et constitue la preuve du respect des exigences fondamentales de sécurité et de performance du MDR. Les composants essentiels de cette documentation technique comprennent, entre autres, la gestion des risques et le dossier d'utilisabilité avec les tests correspondants pour l'utilisation du produit. Dans le cas des logiciels, le fichier logiciel constitue également une partie importante de la documentation. Cela comprend à la fois la définition des exigences et la mise en œuvre réelle sous la forme de l'architecture ainsi que d'autres documents de processus pertinents pour vérifier et valider le développement réussi. Le niveau de détail de cette documentation technique, notamment en ce qui concerne le dossier logiciel, dépend entre autres de la classification du produit logiciel. Si cela aboutit à un classement plus élevé, la documentation technique doit également être révisée en conséquence, ce qui entraîne des coûts et peut immobiliser temporairement des ressources dans l'entreprise. En outre, celui-ci doit également être certifié par un organisme notifié ; le fabricant ne peut plus délivrer lui-même la déclaration UE de conformité.

5. Relation avec le dernier article du blog

Notre dernier article de blog a examiné de plus près la réticence des médecins à prescrire des DiGA. Malgré les nombreux avantages des DiGA, de nombreux médecins hésitent à les prescrire. L’une des raisons à cela est qu’ils ne sont pas sûrs de l’efficacité réelle des DiGA. Il existe également des inquiétudes concernant la sécurité des DiGA ainsi que la sécurité des données. Un autre facteur est le manque de temps et de ressources pour accompagner les patients dans l’utilisation des DiGA. De plus, de nombreux médecins s’inquiètent du fardeau supplémentaire que représente la prescription et la surveillance des DiGA. Enfin, il y a la question de savoir si les caisses d'assurance maladie prendront réellement en charge les frais ou si une prescription correspondante pourra donner lieu à un recours.

Les exigences décrites précédemment pour les DiGA concernent en grande partie la sécurité et, surtout, la sécurité des données des applications mises sur le marché, ce qui répondrait à au moins un aspect de la réticence à prescrire. Cependant, la mise en œuvre des exigences entraîne également un risque entrepreneurial majeur pour les fabricants. Si l'on considère les coûts supplémentaires liés à la mise en œuvre de tous ces aspects et que l'on tient également compte du fait que la prescription du DiGA coté avec succès pourrait ne progresser que lentement, le seuil de rentabilité s'éloigne de plus en plus et la viabilité économique du développement de tels DiGA doivent être sérieusement remis en question.

6. Conclusion/Conclusion

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

Conséquence importante de la mise en œuvre des exigences mises en évidence, nous avons pu identifier la question de la classification résultante du DiGA. Cela concerne aussi bien les fabricants qui en sont encore au développement initial de leur produit que ceux qui ont déjà obtenu un listing provisoire ou définitif pour leur DiGA. L'éventuelle classification plus élevée qui en résulte a des conséquences considérables - cela affecte à la fois la certification du système de gestion de la qualité et de la documentation technique ainsi que tous les aspects commerciaux (par exemple les coûts, les délais, les investisseurs). Les fabricants devraient donc d'abord se pencher sur cette question de la future classification correcte de leur dispositif médical afin de pouvoir engager de nouvelles démarches.

La question posée au début de savoir comment les immenses défis seront liés aux avantages potentiels des applications numériques à l’avenir ne peut recevoir de réponse concluante. Les exigences ne doivent être mises en œuvre que dans les délais définis, de sorte que les conséquences qui en résultent pour les fabricants ne deviendront claires que dans les mois à venir. Cependant, l’examen de la multitude d’exigences montre clairement que la réglementation stricte de ce type particulier de logiciels médicaux doit être remise en question de toute urgence. En fin de compte, il est important d’apporter une valeur ajoutée au patient et de le soutenir et de l’accompagner au quotidien face à sa maladie.

7. Comment nous pouvons vous aider

Nous serions heureux de vous aider à répertorier avec succès votre DiGA au moyen d'une évaluation précoce de la classification du produit en fonction de vos caractéristiques 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 exigent un système de gestion de la qualité (QMS), y compris 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