Votre outil d'appariement par IA ne distingue pas un cathéter veineux central d'un cathétérisme cardiaque. Cela vous coûte 800 000 $ par jour.

En quoi l'appariement piloté par ontologie diffère-t-il de ce que proposent déjà Tempus ou IQVIA ?

Tempus Patient Query et les outils d'appariement d'IQVIA utilisent de grands modèles de langage pour lire les notes cliniques et évaluer la pertinence par rapport aux critères d'essai. Cela fonctionne bien pour les critères simples, mais échoue sur les distinctions ontologiques. Lorsqu'un protocole exclut le « cathétérisme cardiaque » et qu'un dossier patient mentionne une « pose de cathéter veineux central », un LLM fonctionnant sur la similarité vectorielle voit deux procédures de cathéter impliquant le système cardiovasculaire et signale une correspondance. Un système ancré dans SNOMED-CT reconnaît que celles-ci se situent sur des branches entièrement différentes de la hiérarchie des procédures (SCTID 41976001 vs. 392230005) et juge correctement le patient éligible.

La différence pratique se manifeste dans les taux d'échec de présélection. L'appariement fondé sur les LLM atteint généralement une précision de 85 à 94 % sur des critères bien structurés, mais chute à 70-80 % sur les protocoles comportant des distinctions ontologiques complexes, une logique temporelle ou des clauses d'exception. L'appariement piloté par ontologie maintient une précision supérieure à 95 % sur tous les types de critères, car la décision d'éligibilité est calculée par un raisonneur symbolique, et non prédite par un modèle de langage.

L'autre différence structurelle est l'auditabilité. Un LLM produit un score de pertinence. Notre système produit une trace de raisonnement : le patient a le SCTID X, le critère exige non-SCTID Y, X n'est-pas-un-sous-type-de Y selon la hiérarchie SNOMED, donc éligible. C'est cette trace dont les équipes des affaires réglementaires ont besoin pour la documentation de soumission à la FDA.

Cela peut-il s'intégrer à notre système DSE existant sans envoyer les données des patients à des API externes ?

Oui, et c'est un principe architectural fondamental, et non une réflexion après coup. L'architecture neuro-symbolique sépare la couche neuronale (LLM pour l'extraction d'entités) de la couche symbolique (graphe de connaissances et solveur logique). Les deux peuvent s'exécuter entièrement au sein de votre pare-feu.

La couche d'extraction par LLM se déploie sous la forme d'un modèle local, généralement un modèle de langage clinique ajusté finement s'exécutant sur votre infrastructure ou sur une instance de cloud privé sécurisée. Elle n'envoie jamais de texte patient brut à des API externes. Le graphe de connaissances (Neo4j ou équivalent) et l'ontologie SNOMED-CT résident sur site. FHIR R4 est la norme d'entrée. Pour les environnements Epic, nous développons sur les points de terminaison FHIR R4 disponibles via App Orchard, en extrayant les ressources Patient, Condition, Procedure et MedicationAdministration. Pour Oracle Health (Cerner), l'intégration utilise leurs API FHIR Millennium.

La couche d'extraction traite les notes cliniques localement, mappe les entités aux SCTID, et le raisonneur symbolique évalue l'éligibilité par rapport aux critères du protocole. Les informations de santé protégées ne quittent jamais votre environnement sécurisé. Nous concevons l'architecture pour une conformité HIPAA BAA dès le premier jour, y compris la journalisation d'audit, les contrôles d'accès limités au strict nécessaire et les capacités de désidentification pour toute donnée devant effectivement circuler entre les systèmes.

Pour quels domaines thérapeutiques cela fonctionne-t-il, et combien de temps prend la mise en place de l'ontologie ?

L'architecture fonctionne pour tout domaine thérapeutique, car SNOMED-CT couvre plus de 350 000 concepts médicaux. La variable est la profondeur de l'ontologie, c'est-à-dire le nombre de mappages, synonymes et relations hiérarchiques spécifiques au domaine préconfigurés pour vos protocoles particuliers.

L'oncologie est le domaine par lequel nous commençons la plupart des missions, car les critères y sont les plus complexes : exigences de biomarqueurs (niveaux d'expression de PD-L1, statut mutationnel BRCA1/2, variants EGFR), systèmes de stadification (TNM, 8e édition de l'AJCC), antécédents de traitements antérieurs avec contraintes temporelles, et scores d'état de performance. Une ontologie oncologique prête pour la production couvrant les 50 principaux biomarqueurs, plus de 200 schémas thérapeutiques et les systèmes de stadification standards prend 6 à 8 semaines à construire et valider.

Le cardiovasculaire et le SNC sont les domaines les plus courants ensuite. L'ontologie cardiovasculaire se concentre sur les hiérarchies de procédures (la distinction du cathétérisme cardiaque n'est qu'une parmi des dizaines), les chaînes d'interactions médicamenteuses via les voies enzymatiques du CYP, et les plages de valeurs de laboratoire avec ajustements de référence propres à chaque site. Le SNC ajoute la gestion des critères d'évaluation subjectifs et le mappage des scores d'évaluation cognitive.

La maladie rare est techniquement la plus difficile, car la couverture SNOMED peut être limitée pour les affections ultra-rares. Nous complétons avec des mappages de l'ontologie Orphanet et construisons des extensions de concepts personnalisées qui réalimentent le graphe. La mise en place d'un domaine thérapeutique de maladie rare dure 8 à 12 semaines. Chaque ontologie est validée par rapport à des critères de protocole réels de votre portefeuille d'essais avant la mise en production.

Comment cela gère-t-il les clauses complexes « sauf si » et « excepté » des protocoles d'essai modernes ?

C'est là que la logique déterministe surpasse le plus clairement les modèles de langage probabilistes. Le TAL standard traite les critères d'éligibilité comme du texte à interpréter. Nous les traitons comme de la logique formelle à calculer.

Prenons un critère réel : « Exclure les patients atteints d'hypertension, sauf si elle est bien contrôlée par un traitement stable depuis au moins 3 mois. » Un LLM voit le mot « hypertension » et doit décider à partir du contexte s'il faut exclure. Il y parvient la plupart du temps, mais « la plupart du temps » signifie perdre des patients éligibles à chaque essai.

Notre analyseur décompose ceci en opérateurs déontiques. Interdiction : hypertension présente. Condition de permission : hypertension ET contrôlée (TA inférieure à 140/90 selon la définition du protocole) ET traitement stable (même schéma antihypertenseur) ET contrainte temporelle (durée de 3 mois ou plus). Le système interroge ensuite l'historique médicamenteux du patient à partir du graphe de connaissances, identifie l'antihypertenseur, vérifie la date de début de la prescription, calcule l'écart de durée par rapport à la date de présélection, et vérifie les relevés de tension artérielle dans la fenêtre d'observation. Chaque étape produit une sortie vérifiable.

La même logique gère des chaînes telles que « aucune chimiothérapie antérieure sauf si un traitement néoadjuvant a été achevé il y a plus de 6 mois » en vérifiant l'attribut d'intention thérapeutique (néoadjuvant vs. adjuvant vs. palliatif), la date de fin et l'écart temporel. Ce ne sont pas des cas limites. Les données d'IQVIA montrent que les protocoles comptent désormais en moyenne 27 critères d'éligibilité ou plus, dont beaucoup avec des conditions imbriquées. Une seule clause d'exception mal gérée par protocole, sur des centaines de patients présélectionnés, se cumule en dizaines de recrutements perdus.

À quoi ressemble une mission type, et combien coûte-t-elle par rapport à la licence d'une plateforme ?

Une mission type se déroule en trois phases sur 14 à 20 semaines. La Phase 1 (3 à 4 semaines) est un audit des opérations de recrutement : nous analysons vos taux actuels d'échec de présélection, cartographions le paysage de vos données DSE, examinons 10 à 15 protocoles représentatifs de votre portefeuille d'essais, et identifions les types de critères spécifiques à l'origine du plus grand nombre de faux positifs et d'appariements manqués. Cette phase fournit un document d'architecture technique et un modèle de ROI basé sur vos données réelles.

La Phase 2 (8 à 12 semaines) est la construction : développement de l'ontologie pour votre domaine thérapeutique prioritaire, ajustement fin du LLM sur vos schémas de notes cliniques, construction du graphe de connaissances, configuration du raisonneur symbolique, et intégration FHIR avec votre environnement DSE. La Phase 3 (3 à 4 semaines) est la validation : tests rétrospectifs par rapport à des essais terminés dont les résultats de recrutement sont connus, étalonnage de la précision, et intégration au workflow des coordinateurs.

Le coût dépend du périmètre. Une construction pour un seul domaine thérapeutique avec une intégration DSE coûte généralement de 180 000 $ à 350 000 $. Les déploiements multithérapeutiques ou multisites évoluent selon l'ampleur de l'ontologie et la complexité de l'intégration. À titre de comparaison, les licences des plateformes Tempus et IQVIA coûtent de 200 000 $ à plus de 500 000 $ par an, avec des frais par patient ou par essai en sus.

La différence économique fondamentale est la propriété. Une licence de plateforme est une dépense récurrente assortie d'une dépendance vis-à-vis du fournisseur. Une construction sur mesure est un actif que vous possédez, maintenez et étendez. Pour les organisations menant plus de 20 essais par an, la construction sur mesure devient généralement rentable par rapport à la licence de plateforme en 18 mois, avec l'avantage supplémentaire d'une précision d'appariement ajustée à la complexité spécifique de votre protocole.

Cela nécessite-t-il une autorisation de la FDA, ou cela relève-t-il de l'exemption CDS ?

Les lignes directrices actualisées de la FDA de janvier 2026 sur l'aide à la décision clinique constituent le cadre pertinent ici. La question clé est de savoir si le système prend des décisions cliniques autonomes ou s'il soutient la prise de décision humaine.

Notre architecture est conçue pour l'exemption CDS au titre de la section 3060 du 21st Century Cures Act. Le système répond aux quatre critères d'exemption : il n'est pas destiné à acquérir, traiter ou analyser des images ou des signaux médicaux ; il affiche le fondement des recommandations (la trace de raisonnement complète) ; il est destiné aux professionnels de santé disposant d'une capacité d'examen indépendant ; et il ne remplace pas le jugement clinique dans la détermination de l'éligibilité.

En pratique, cela signifie que le système produit des appariements patient-essai classés assortis de scores de confiance et de traces de raisonnement. Un coordinateur de site ou un attaché de recherche clinique examine chaque appariement avant tout contact avec le patient. Le système ne procède jamais à un recrutement automatique.

Cela dit, l'interprétation par la FDA du périmètre des CDS continue d'évoluer. Si votre organisation prévoit d'utiliser la sortie d'appariement pour exclure automatiquement des patients sans examen humain, le système peut basculer dans le domaine des dispositifs nécessitant une autorisation 510(k) ou une classification De Novo. Nous recommandons d'impliquer le Digital Health Center of Excellence de la FDA dès la phase de conception. Nous élaborons la documentation réglementaire, y compris la justification de l'exemption CDS, la déclaration d'utilisation prévue et le rapport d'évaluation clinique, en tant que livrable standard de la Phase 1.