Santé
Les organisations de recherche et cliniques adjacentes travaillent avec des données génomiques, épidémiologiques et proches des patients qui ne peuvent pas quitter l'établissement et ne peuvent pas être exploitées sans l'examen d'experts. Cette page explique comment un tel flux de travail serait planifié et exécuté sur inTheEU Assist, et non un enregistrement d'un déploiement terminé.
Comment le flux de travail serait structuré
Les données institutionnelles (dossiers génomiques, ensembles de données épidémiologiques, documents de cas adjacents aux patients) seraient ingérées et indexées sur place, alimentant ainsi un ensemble de connaissances destiné au propre locataire de l'établissement. Aucun document ou ensemble de données ne traverse un autre locataire de la plateforme.
Un agent configuré pour le flux de travail proposerait des signaux, des résultats ou des indicateurs de risque candidats à partir de cette base de connaissances, chacun étant lié à un cas ou à un ensemble de données spécifique et saisi avec le statut proposé. Rien n'est traité comme établi, et rien n'atteint un dossier patient ou un résultat publié, jusqu'à ce qu'un clinicien ou un chercheur nommé l'examine et l'approuve.
Là où se situe l’approbation humaine
Chaque étape qui produit un indicateur, un résumé ou une recommandation nécessiterait une approbation explicite avant l'ouverture de l'étape suivante. Il ne s’agit pas d’une politique superposée au flux de travail. C'est le mécanisme par lequel le flux de travail se déroule : une étape non approuvée n'exécute tout simplement pas l'étape suivante.
Un premier projet pilote délimité
Un premier déploiement concret utiliserait un service, une catégorie de documents ou un workflow d'étude définis, un ensemble limité de sources institutionnelles approuvées et des examinateurs cliniques ou de recherche désignés. Assist préparerait, au sein de l'infrastructure contrôlée de l'établissement, une synthèse reliée aux sources, une comparaison, une chronologie, un tableau de preuves ou une liste de problèmes potentiels. Il ne poserait pas de diagnostic, ne prescrirait rien, ne modifierait pas le dossier d'un patient et ne prendrait aucune décision clinique autonome.
L'établissement choisirait les critères de réussite. Les mesures utiles comprennent le temps de préparation, la couverture des sources, les corrections des examinateurs, les affirmations non étayées détectées avant approbation, la cohérence entre des cas répétés et l'exhaustivité du dossier de décision obtenu. L'objectif est de tester la valeur opérationnelle sur les propres documents de l'établissement, et non de revendiquer une validité clinique à partir d'un benchmark générique.
Ce sur quoi cela s’appuie aujourd’hui et ce qu’il ne fait pas
L'ingestion des documents, l'extraction examinée, les connaissances limitées au dossier ou à l'étude, l'exécution délimitée des workflows, le passage de la proposition à l'approbation, la réutilisation contrôlée des connaissances et les journaux d'exécution traçables sont des composants opérationnels de la plateforme. La plateforme ne fournit pas comme fonctionnalité standard une autorité clinique ni un modèle génomique, épidémiologique ou diagnostique universel. Le jugement métier reste du ressort des cliniciens et chercheurs de l'établissement, tandis que toute capacité spécialisée est configurée avec leurs documents et règles approuvés.
Une partie de l'architecture sous-jacente à cet ensemble de capacités est documentée dans des dossiers encore en cours. Cette page décrit ce pour quoi la plateforme est conçue, à un niveau approprié pour la planification d'un projet pilote, et non une spécification de mise en œuvre.
Apportez un workflow contrôlé
font l'objet d'améliorations continues. Les descriptions contenues dans ce guide peuvent ne pas refléter la présentation ou le libellé exact de la dernière version publiée.