Dans Partie 1 de cette série, les appareils de bien-être général et les applications médicales mobiles (MMA) ont été pris en compte. La partie 2 de cette série est consacrée aux logiciels d’aide à la décision clinique (CDS).

Le 27 septembre 2022, la Food and Drug Administration (FDA) a publié sa version finale conseils pour le logiciel d’aide à la décision clinique (CDS) du personnel de l’industrie et de la FDA, qui a été anticipé depuis que le Center for Devices and Radiological Health (CDRH) a classé les orientations comme une priorité absolue pour l’exercice 2022.

Les directives finales font suite au projet de directives sur le logiciel CDS publié à la même date en 2019. Depuis lors, les développeurs ont demandé des éclaircissements concernant le statut réglementaire du CDS, qui est décrit comme une variété d’outils, y compris, mais sans s’y limiter : des alertes et des rappels informatisés pour les prestataires et les patients ; directives cliniques; ensembles de commandes spécifiques à une condition ; rapports et résumés ciblés sur les données des patients ; modèles de documentation ; aide au diagnostic ; et des informations de référence contextuellement pertinentes.

Critères de réglementation

La FDA réglemente les logiciels qui répondent à la définition d’un dispositif médical dans la section 201(h) de la Federal Food, Drug, and Cosmetic Act (FD&C Act). Dans les directives finales, la FDA précise que certains types de fonctions logicielles CDS sont exclus de la définition d’un dispositif médical lorsque ces produits répondent aux quatre critères énoncés à l’article 520(o)(1)(E) de la loi FD&C. . Ces CDS non-dispositifs sont :

(1) n’est pas destiné à acquérir, traiter ou analyser une image médicale ou un signal provenant d’un appareil de diagnostic in vitro ou un motif ou un signal provenant d’un système d’acquisition de signaux (Critère 1) ;

(2) destinés à afficher, analyser ou imprimer des informations médicales sur un patient ou d’autres informations médicales (par exemple, des études cliniques évaluées par des pairs et des directives de pratique clinique) (Critère 2) ;

(3) destinés à soutenir ou à fournir des recommandations à un HPC concernant la prévention, le diagnostic ou le traitement d’une maladie ou d’un état (Critère 3) ; et

(4) destinés à permettre à ces professionnels de la santé d’examiner de manière indépendante la base de ces recommandations que ce logiciel présente, de sorte qu’il n’est pas dans l’intention que ces professionnels de la santé se fient principalement à l’une de ces recommandations pour établir un diagnostic clinique ou une décision de traitement concernant un patient individuel (Critère 4).

Critère 1

La FDA a noté que si le type de données décrit dans le critère 1 (c’est-à-dire une image médicale ou un signal d’un DIV ou un motif/signal d’un système d’acquisition de signaux) est utilisé comme entrée, alors la fonction logicielle reste un dispositif médical réglementé .

La FDA considère qu’une « image médicale » inclut les images générées par des systèmes d’imagerie médicale (par exemple, la tomodensitométrie, les rayons X, les ultrasons, l’imagerie par résonance magnétique) pour visualiser toute(s) partie(s) du corps ou des images acquises à des fins médicales. Les images qui n’ont pas été initialement acquises à des fins médicales, mais qui sont traitées ou analysées à des fins médicales, sont également considérées comme des « images médicales ».

La FDA considère que le « signal » fait référence aux signaux qui nécessitent généralement l’utilisation d’un DIV (par exemple, une réponse photométrique générée par un test et un instrument qui est ensuite traité par un logiciel pour générer un résultat de test clinique) ou un système d’acquisition de signaux qui mesure un paramètre. de l’intérieur, attaché ou externe au corps à des fins médicales (par exemple, dérivations ECG).

La FDA interprète le « modèle » comme faisant référence à des mesures multiples, séquentielles ou répétées d’un signal ou d’un système d’acquisition de signaux.

Notez cependant que les moniteurs d’activité ou autres systèmes d’acquisition de signaux qui mesurent des paramètres physiologiques qui ne sont pas spécifiquement destinés ou commercialisés à une fin identifiée dans la définition de l’appareil ne sont pas des appareils médicaux.

Critère 2

Les fonctions logicielles destinées à afficher, analyser ou imprimer des informations médicales sur un patient ou d’autres informations médicales (par exemple, des études cliniques évaluées par des pairs ou des directives de pratique clinique) répondent au critère 2 et ne sont pas des dispositifs médicaux soumis à la réglementation et à la surveillance de la FDA.

La FDA considère que les « informations médicales sur un patient » sont le type d’informations qui sont normalement, et peuvent généralement être, communiquées entre les professionnels de la santé lors d’une conversation clinique ou entre les professionnels de la santé et les patients dans le contexte d’une décision clinique, ce qui signifie que la pertinence de les informations relatives à la décision clinique prise sont bien comprises et acceptées.

La FDA interprète les « autres informations médicales » comme incluant des informations telles que des études cliniques évaluées par des pairs, des directives de pratique clinique et des informations qui sont également vérifiées et validées de manière indépendante comme étant exactes, fiables, n’omettant pas d’informations importantes et étayées par des preuves.

La FDA note que la fréquence est importante pour déterminer si une information est considérée comme une « information médicale » ou un « signal » ou un « modèle », de sorte qu’un seul résultat de test ou de mesure (par exemple, un résultat de test de glycémie) est considéré comme une information médicale, alors qu’une information continue l’échantillonnage de celui-ci serait considéré comme un motif ou un signal soumis à la réglementation de la FDA en tant que dispositif médical.

La FDA explique que le critère 1 et le critère 2 décrivent les types d’entrées de données utilisées dans les appareils (critère 1) et les types d’entrées de données utilisées dans les CDS non-Device (critère 2).

Critère 3

Les fonctions logicielles du critère 3 soutiennent ou présentent des recommandations aux professionnels de la santé, qui peuvent ensuite intégrer ces informations dans leur prise de décision concernant les soins d’un patient, ainsi que d’autres informations et facteurs dont le professionnel de la santé a connaissance.

La FDA interprète le critère 3 comme faisant référence à un logiciel qui fournit des recommandations spécifiques à une condition, à une maladie et/ou à un patient à un HCP pour améliorer, informer et/ou influencer une décision de soins de santé (par exemple, interaction médicamenteuse et contre-indication d’allergie médicamenteuse notifications pour éviter les événements indésirables liés aux médicaments) mais n’est pas destiné à remplacer ou à orienter le jugement d’un professionnel de la santé et n’inclut pas dans la prise de décision urgente ou un résultat ou une directive spécifique de prévention, de diagnostic ou de traitement, car ces fonctions ne sont pas destinées à cet effet de soutenir ou de fournir des recommandations aux professionnels de la santé.

La FDA considère que les fonctions logicielles qui fournissent les sorties suivantes ne sont pas des CDS de dispositif tant qu’elles ne sont pas destinées à prendre en charge la prise de décision urgente et/ou à remplacer ou diriger le jugement d’un HCP :

• Une liste d’options de prévention, de diagnostic ou de traitement ;
• Une liste hiérarchisée d’options de prévention, de diagnostic ou de traitement ; ou
• Une liste d’options de suivi ou d’étape suivante à prendre en considération.

La FDA note que deux aspects de la fonctionnalité logicielle peuvent affecter l’utilisation d’une fonction logicielle pour soutenir ou fournir des recommandations à un professionnel de la santé : (1) le niveau d’automatisation du logiciel et (2) la nature urgente de la prise de décision du professionnel de santé. . Un biais d’automatisation peut se produire si le logiciel fournit à un professionnel de la santé une sortie ou une solution unique, spécifique et sélectionnée, par opposition à une liste d’options ou d’informations complètes à l’attention du professionnel de santé.

Critère 4

Selon le critère 4, la fonction logicielle permet aux professionnels de la santé d’examiner de manière indépendante la base des recommandations présentées par le logiciel, de sorte que les professionnels de la santé ne se fient pas principalement à ces recommandations, mais plutôt à leur propre jugement, pour prendre des décisions cliniques pour des patients individuels.

La FDA explique que quelle que soit la complexité du logiciel et qu’il soit propriétaire ou non, la sortie ou l’étiquetage doit fournir aux utilisateurs HCP des informations de base adéquates en langage clair sur les entrées, la logique ou les méthodes de l’algorithme, les ensembles de données et validation. En outre, les sources pertinentes doivent être identifiées et mises à la disposition de l’utilisateur HCP.

Bien que le projet de directives ait donné son avis sur les logiciels d’aide à la décision clinique (CDS) destinés à être utilisés par les patients ou les soignants, les directives finales ont noté que les politiques de santé numérique existantes de la FDA continuent de s’appliquer à ces fonctions logicielles, de sorte que les fonctions logicielles qui soutiennent ou fournissent des recommandations aux les patients ou les soignants – et non les professionnels de la santé – répondent à la définition d’un dispositif.

Les directives finales publiées par la FDA comprennent plusieurs exemples de CDS de dispositifs et de non-dispositifs, qui doivent être soigneusement examinés par les développeurs lors de la conception et de la mise en œuvre d’une stratégie réglementaire de la FDA.

A propos de l’auteur

Kyle Faget est associé et avocat d’affaires chez Foley & Lardner LLP. Elle est coprésidente du groupe de pratique des soins de santé du cabinet, coprésidente du secteur des soins de santé et des sciences de la vie – Dispositifs médicaux et membre clé des équipes du secteur des sciences de la vie et de la télémédecine du cabinet. Kyle conseille des investisseurs, des centres médicaux universitaires, des cabinets médicaux et des consultants sur une gamme de questions commerciales, juridiques et réglementaires affectant l’industrie de la télémédecine. Kyle aide les entreprises à élaborer et à affiner les programmes de conformité d’entreprise, notamment en conseillant les clients sur les questions de réglementation et de conformité concernant la loi sur les aliments, les médicaments et les cosmétiques, la loi sur les fausses allégations, la loi anti-pots-de-vin, le code AdvaMed et le code PhRMA. Elle rédige et négocie régulièrement les accords nécessaires au développement et à la commercialisation de produits pharmaceutiques et de dispositifs médicaux, y compris des accords de licence, des accords de collaboration, des accords d’essais cliniques et un éventail d’accords de services. Avant de se joindre à l’entreprise, Kyle a occupé des postes internes dans des entreprises précommerciales et commerciales.