Intégration des instruments dans l’architecture du laboratoire : bien plus qu’un simple projet informatique

Solutions propriétaires

Les capacités techniques de transmission des données varient considérablement d’un fabricant à l’autre et ne sont pas normalisées. Historiquement, chaque fabricant a développé de manière indépendante ses propres protocoles de communication, structures de données et plateformes logicielles. Des interfaces mal documentées, voire non documentées, ainsi que certaines spécificités de l’infrastructure informatique, compliquent encore davantage l’intégration des instruments. Bien qu’il existe d’importantes initiatives visant à normaliser les interfaces – telles que SiLA et AnIML, qui constituent respectivement des exemples de protocoles standard et de formats de données standard –, celles-ci ne sont pas encore largement adoptées dans la pratique. Cela s’explique en partie par le fait que de nombreux instruments plus anciens, encore utilisés aujourd’hui, ont été développés avant l’existence de ces normes et que de nombreux fabricants continuent de s’appuyer sur leurs solutions propriétaires.

Différents modèles de données

Outre le transfert technique des données, leur interprétation constitue un autre défi. La question n’est pas seulement « Comment transférer les données ? », mais aussi « Comment s’assurer que les données conservent la même signification dans le système cible ? ». Le simple transfert d’une valeur mesurée ne suffit généralement pas. Il faut en outre transférer les méthodes et les paramètres, les unités, les références d’échantillons, les informations de mesure (telles que l’utilisateur et l’heure de la mesure), les informations sur l’état de l’instrument, les messages d’erreur et d’autres métadonnées. Dans les interfaces bidirectionnelles, les séquences de mesure, les listes de travail et les consignes de travail sont également transmises à l’instrument. L’échange d’informations nécessite généralement un mappage approprié des données entre l’instrument ou le logiciel de pilotage et le LIMS. Un concept global de gestion des données de référence et, le cas échéant, des efforts d’harmonisation de ces données sont donc absolument indispensables.

GxP et validation

Dans un environnement réglementé, l’intégration des instruments pose des défis supplémentaires. Cet aspect revêt une importance particulière au vu des exigences réglementaires croissantes en matière d’intégrité des données. Des termes tels que ALCOA+, FDA 21 CFR Partie 11 ou Annexe 11 des BPF de l’UE font partie intégrante de tout projet de numérisation dans un environnement réglementé. Cependant, la question reste toujours la même : pouvons-nous démontrer que nos données sont complètes, précises, traçables et fiables ? Dans l’environnement GxP, la mise en place d’une interface validée entre un instrument d’analyse et, par exemple, un LIMS s’inscrit dans le cadre d’un processus de validation structuré, basé sur les directives GAMP 5. L’objectif est de fournir une preuve complète et infalsifiable que les données sont transférées en garantissant leur intégrité et leur traçabilité. Pour une interface, on se base généralement sur la catégorie 4 ou 5 de GAMP. Cela signifie que le logiciel utilisé est fourni par le fabricant sous forme de logiciel standard ou de pilote, puis configuré ou développé selon les exigences de l’utilisateur. L’accent est alors mis sur les tests fonctionnels (OQ, PQ) afin de garantir un mappage des données sans erreur. Dans certains cas spécifiques – par exemple, lorsqu’il s’agit d’un instrument plus ancien pour lequel aucun connecteur standard adapté n’est disponible –, il peut s’avérer nécessaire de développer une interface sur mesure. La validation doit couvrir l’ensemble du cycle de vie du logiciel d’interface. En d’autres termes, l’effort requis dans de tels cas est proportionnellement élevé.

Facteurs organisationnels

Les fabricants fournissent généralement un instrument opérationnel et, si nécessaire, le logiciel de pilotage requis. Les fournisseurs de LIMS proposent des interfaces prêtes à l’emploi ou personnalisées. La responsabilité de l’intégration de l’instrument dans l’environnement de l’entreprise incombe généralement à l’opérateur. Par conséquent, les fournisseurs de LIMS, les fabricants d’instruments, les équipes informatiques, l’assurance qualité et les unités opérationnelles interviennent souvent dans des domaines de responsabilité distincts, sans qu’aucun acteur n’assume la responsabilité globale de l’intégration de bout en bout. Les facteurs organisationnels peuvent ainsi compliquer l’intégration des instruments, au-delà des seuls défis techniques.

La complexité de l’intégration constitue souvent un problème pour l’ensemble du système. L’absence de protocoles, d’interfaces et de modèles de données normalisés, ainsi que les problématiques liées à la gouvernance et à la collaboration, représentent les principales lacunes. La complexité de l’intégration des instruments, ainsi que les besoins en temps et en ressources qui en découlent, sont souvent sous-estimés et peuvent entraîner des retards dans les projets ou des dépassements budgétaires. De plus, l’intégration des instruments est fréquemment planifiée comme un sous-projet de la mise en œuvre ou du remplacement d’un LIMS. Elle se retrouve ainsi souvent placée à la fin du planning du projet. Si la configuration du LIMS prend du retard, l’intégration des instruments se retrouve alors sur le chemin critique du projet. Le laboratoire est alors mis en service avec une automatisation incomplète ou, dans le pire des cas, sans aucune automatisation.