Application sectorielle · Framework RAISE
Healthcare & Life Sciences est, à ce jour, le secteur où la doctrine RAISE est la plus densément testée. Le présent dépliage instancie les cinq piliers sur le corpus normatif applicable, les modes de défaillance typiques, et les engagements opérationnels qu'ils imposent.
Healthcare est un environnement où l'IA n'est pas un sujet d'innovation, c'est un sujet d'engagement de responsabilité. Une décision algorithmique en oncologie, en imagerie, en pharmacovigilance, dans un dispositif médical de classe IIa et au-delà, mobilise des chaînes de responsabilité juridique, médicale et institutionnelle qui pré-existent au système numérique. Le rôle d'un cadre d'architecture n'est pas d'inventer ces chaînes, c'est de garantir que le système numérique se rende compatible avec elles avant d'être déployé.
RAISE produit cette compatibilité par construction. La présente application sectorielle décrit, pour chacun des cinq piliers, l'instanciation Healthcare attendue, les corpus normatifs mobilisés, les modes de défaillance qui qualifient une instanciation insuffisante, et l'engagement opérationnel concret que RAISE impose au système. La granularité reste intentionnellement architecturale : les grilles d'évaluation détaillées et les modèles d'ADR sectoriels figurent dans le document de référence.
Le corpus réglementaire applicable à l'IA en Healthcare est l'un des plus denses tous secteurs confondus, et il s'épaissit à chaque cycle législatif. Le pilier R en environnement médical demande de tenir simultanément, dès la conception, la lecture croisée de quatre régimes au minimum : le règlement Dispositifs Médicaux MDR (UE 2017/745) ou son équivalent diagnostique IVDR (UE 2017/746) qui qualifie le produit comme dispositif médical et fixe sa classe de risque ; l'EU AI Act dont l'Article 6 redéfinit la qualification haut risque dès lors qu'un dispositif médical à composante IA franchit certains seuils d'autonomie décisionnelle ; le RGPD dont l'Article 9 régit le traitement des données de santé en tant que catégorie particulière ; et la grille d'évaluation de la HAS pour les dispositifs médicaux à base d'IA (Grille DM-IA, 2024) qui conditionne l'admission au remboursement en France et qui formalise des exigences techniques que le MDR seul ne capte pas.
La défaillance la plus fréquente est la collision ontologique : un système conçu uniquement sous l'angle MDR découvre tardivement les obligations supplémentaires de l'AI Act (transparence vis-à-vis du clinicien utilisateur, journalisation des décisions, supervision humaine effective au sens de l'Article 14), et doit être réarchitecturé en cours de processus de certification. RAISE pilier R impose qu'à la phase de spécification, un Architecture Decision Record explicite la lecture croisée MDR + AI Act + RGPD + HAS DM-IA, identifie les exigences cumulatives, et acte les arbitrages lorsque les régimes divergent (par exemple : la classification haut risque AI Act peut imposer des obligations qu'un dispositif MDR de classe IIa n'aurait pas par défaut). Cette lecture croisée n'est pas une formalité, elle est une condition de déployabilité.
La gouvernance d'un système d'IA en Healthcare s'inscrit dans une chaîne de responsabilité qui pré-existe au numérique : responsabilité du fabricant au sens du MDR (Personne Chargée de Veiller au Respect de la Réglementation, Article 15), responsabilité du clinicien utilisateur, responsabilité de l'établissement de santé, responsabilité du Délégué à la Protection des Données pour les traitements RGPD. Le pilier A impose que cette chaîne soit explicitement cartographiée et que les flux d'information entre acteurs soient documentés et opposables.
Concrètement, cela signifie : un système qualité conforme à ISO 13485 qui couvre l'ensemble du cycle de vie du dispositif, une cartographie RACI sur les décisions algorithmiques (qui valide une mise en production, qui peut décider d'un retrait, qui qualifie une dérive comme incident matériovigilance), un comité de validation interne avec représentation clinique, qualité, réglementaire, et données, une procédure de matériovigilance conforme aux Articles 87 à 92 du MDR pour les incidents graves, et un protocole de communication avec l'organisme notifié pour les modifications substantielles. La défaillance typique est la responsabilité diluée par contrat de service : l'éditeur logiciel se positionne comme prestataire technique, l'établissement comme utilisateur final, et personne ne porte la responsabilité du fabricant au sens MDR. RAISE rejette cette dilution : il existe un fabricant identifié, signataire de la déclaration de conformité, qui assume la conformité du système dans la durée.
L'interopérabilité en environnement médical n'est pas un confort d'intégration, c'est une condition de continuité des soins et de traçabilité réglementaire. Les standards mobilisés sont stables et bien documentés : HL7 FHIR R5 pour les échanges cliniques structurés, DICOM pour l'imagerie, SNOMED CT et LOINC pour la terminologie, IHE pour les profils d'intégration, et plus récemment les profils InteropSanté spécifiques à l'écosystème français. Un système d'IA en Healthcare ne devrait jamais reposer sur des formats propriétaires non documentés ni sur des connecteurs non versionnés vers les SIH (Systèmes d'Information Hospitaliers), DPI (Dossiers Patients Informatisés), DMP, SNDS, ou registres.
Le pilier I impose en outre des exigences que les standards seuls ne couvrent pas : un hébergement HDS (Hébergeur de Données de Santé) pour les données patient, une politique de sécurité applicative conforme à ISO/IEC 81001-5-1 qui spécifie les exigences de cybersécurité pour le cycle de vie des logiciels en santé, et un référentiel de cybersécurité IEC 62443 ou équivalent pour les composants connectés. La défaillance typique est l'interopérabilité par export CSV vers le DPI (anti-pattern documenté sur la page principale) : le système expose des données structurées, mais la traçabilité de l'échange n'est pas garantie, les versions de schéma ne sont pas négociées, et la responsabilité de l'intégrité du flux est implicitement transférée au DSI hospitalier. Une interopérabilité Healthcare conforme à RAISE expose des contrats d'interface FHIR versionnés, journalisés, et opposables.
La validation opérationnelle d'un système d'IA en Healthcare est régie par un corpus dédié et exigeant : IEC 62304 sur le cycle de vie des logiciels de dispositifs médicaux, ISO 14971 sur la gestion du risque (FMEA, analyse des risques résiduels, balance bénéfice-risque), ICH E6 R3 (Bonnes Pratiques Cliniques) pour les phases de validation impliquant des données patient, et 21 CFR Part 11 de la FDA pour les systèmes électroniques en environnement réglementé US. La grille HAS DM-IA ajoute des exigences spécifiques sur la performance clinique, la robustesse algorithmique, et la transférabilité entre populations.
Le pilier S exige que la validation ne soit pas une étape, mais un régime maintenu : protocoles de validation pré-déploiement (clinical investigation au sens MDR Annexe XV, ou clinical evaluation au sens Annexe XIV), surveillance post-marché continue (PMS, Article 83 MDR, et PMCF pour la performance clinique), monitoring de dérive de modèle en production avec seuils explicites, procédure de retrait ou de suspension activable sur signal de dérive ou d'incident. La défaillance typique est la validation par cohorte unique : le système est validé sur une population, déployé sur une autre, et la perte de performance n'est observée que par incidents matériovigilance. RAISE pilier S impose la documentation explicite du domaine de validité du système — populations couvertes, hôpitaux représentés dans la cohorte d'entraînement, conditions cliniques d'utilisation prévues — et le rejet de toute prédiction hors domaine plutôt que la production d'une sortie non qualifiée.
L'explicabilité en Healthcare ne se réduit pas à une exigence d'interface utilisateur. Elle est une condition de la pratique médicale elle-même : un clinicien qui ne comprend pas la sortie algorithmique ne peut pas en assumer la responsabilité, et ne peut donc pas légalement l'intégrer dans sa décision sans la requalifier. Le pilier E doit produire une explicabilité située, c'est-à-dire calibrée sur les questions cliniques que le clinicien doit pouvoir poser au système, pas sur les variables que l'algorithme a effectivement utilisées.
Concrètement : pour un système de stratification de risque en oncologie, l'explicabilité utile n'est pas la liste des features SHAP avec leur poids, c'est la capacité à répondre à la question « pourquoi ce patient est-il classé haut risque alors qu'un patient comparable du même service est classé risque modéré ». Pour un système de pharmacovigilance, l'explicabilité utile est la traçabilité des signaux de la base ayant déclenché l'alerte. Pour un système de détection d'imagerie, l'explicabilité utile est la heatmap localisée plus la documentation des cas négatifs où le modèle est connu pour échouer. Le corpus mobilisé inclut l'EU AI Act Article 13 sur la transparence et l'information de l'utilisateur, l'Article 14 sur la supervision humaine effective, le RGPD Article 22 et Considérant 71 sur le droit à l'explication d'une décision automatisée affectant la personne concernée, et la grille HAS DM-IA qui formalise des exigences d'interprétabilité spécifiques au contexte médical. La défaillance typique est l'explicabilité décorative : SHAP affiché à côté de chaque prédiction, sans pratique de contestation effective ni protocole pour qu'un clinicien puisse renvoyer une décision pour révision. RAISE pilier E rejette cette décoration : la sortie explicative doit être consommable par le clinicien dans son flux de travail, et opposable institutionnellement.
Cette page restitue l'instanciation publique de RAISE en environnement Healthcare. Le document de référence développe les grilles d'évaluation par classe MDR, les modèles d'ADR sectoriels, les arbres de décision pour la lecture croisée MDR + AI Act, les protocoles de validation post-marché, et les modèles de documentation HAS DM-IA.
🔒 S'inscrire pour accéder au document de référence
Accès gratuit · Document nominatif · Aucun démarchage commercial