Colloque SIDIV - SFIL

Connexions informatiques des systèmes de DIV

Eurosites Paris République

15 mars 2016

Ivan Monneret

• 1. Contexte d’une évaluation

• 2. Questions soulevées en évaluation

o Pourquoi ?

o Qui ?

• Fournisseurs

• Laboratoires

o Quand ?

• Validation

• Vérification

• Qualification

o Comment ?

• NF EN ISO 15189 version 2012

(approche processus et analyse de risques)

• SH REF 02

• SH GTA 02

• Recommandations, guides, veilles de :

SFIL, CNIL, ASIP, ANSM

Recommandations

(non évoquées ici)

Critères d’achat

Critères d’acceptation

Identification

Modes d’emploi

Maintenance

Gestion des incidents

Dans le contexte des échanges de données entre automates et SIL/SGL :

Systèmes = Informatique embarquée sur l’automate

Postes informatiques liés à l’automate (intégrés)

Interfaces intermédiaires : drivers, systèmes de contage / stats…

Middleware

SIL

Mais aussi SI de gestion des températures, des CQ, des documents…

Niveaux de criticité variables (élevé si données de santé)

Dans le contexte des échanges de données entre automates et SIL/SGL :

Données = Résultats analytiques (valeurs, unités)

Résultats des CQ

Données de calibration

Lots réactifs ou consommables

Identifiants utilisateurs

Paramétrages (en général non échangés)

Dans le contexte des échanges de données entre automates et SIL/SGL :

Processus = Collecte

Traitement

Enregistrement

Compte rendu

Stockage

Récupération

Validation - Fournisseurs

Vérification - Laboratoire

Documentation

Mise à jour documentaire

Diffusion aux utilisateurs

Autorisations

Gestion

documentaire

(GED)

Protection en interne : gestion des droits utilisateurs

Protection vis-à-vis de l’extérieur (lors des télémaintenances,

supervisions en continu, échanges de données…

Gestion des sauvegardes et des modalités pour réintégrer une

sauvegarde dans le cadre d’un Plan de Reprise d’Activité (PRA)

Etapes de vérification de la conformité.

Archivage, gestion des incidents

CNIL, HDS (Hébergement de Données de Santé)

Réglementaire…

Disparaitra du SH REF 02 mais reste une obligation.

Note, non opposable.

Concernant les connexions informatiques :

Pourquoi s’y intéresser?Qui s’en charge?

Quand les regarder?Comment faire?

Pourquoi se préoccuper des connexions automates et systèmes informatiques ?

En évaluation (technique et qualité), on cherchera à savoir si le laboratoire a conscience ou non des risques liés au processus d’échange de données entre un automate et des systèmes informatiques.

A-t-il fait une analyse des risques ?

Comprend-il que ce processus est critique ?

Comprend-il comment ça marche ?

Vinton Cerf (un des fondateurs d’internet) :

Mon épouse utilise une voiture électrique Tesla qui est en fait un ordinateur géant sur roues. L’autre jour elle me dit enthousiaste « regarde ce que la voiture peut faire aujourd’hui et qu’elle ne pouvait pas faire hier, car j’ai mis à jour le logiciel de contrôle ». Mais moi je ne pouvais m’empêcher de penser : quels outils ont utilisé les programmeurs pour s’assurer que la fonctionnalité ajoutée n’a pas changé quelque chose dans le système qui compromettrait la sécurité ?

(La Recherche Février 2016)

Pour les systèmes critiques, des informaticiens commencent à utiliser des outils qui permettent de formaliser mathématiquement les programmes afin de garantir qu’ils fonctionnent conformément aux attentes. Mais ils sont encore trop rares…

Les modèles dans lesquels évoluent les données échangées sont logiques (puisque informatiques) mais les interactions entre systèmes imposent une approche empirique, et donc des plans expérimentaux pour valider et vérifier.

Une connexion informatique équivaut à un système : éléments d’entrée – Processus de transformation – éléments de sortie.

MesurandeRésultat

exprimé

sur SIL

En ce qui nous concerne, le processus en question est celui-ci :

Document utile pour définir les étapes et les terminologies

utilisées mais doit être complété et adapté à chaque LBM en

fonction des questions réponses suivantes…

• Fournisseurs : Validation et Vérification

• LBM : Vérification et qualification

MesurandeRésultat

exprimé

sur SIL

Réaction

physico-

chimique

Mesure

physique

Calibration

Réactifs

Paramétrage

automate

Driver

connexion

Middleware

SIL

Validation

analytique

Résultat brut

Unités, décimales, arrondissage, calculs, conversions, limites de rendu

Fournisseur automate

Fournisseur Mw / SIL

Laboratoire

Fournir les protocoles ou éléments attendus pour y répondre : procédures,

manuels, guides…, y compris les paramétrages types ou dits d’usine pour

les tests paramétrés sur automates.

OK – Répond à des exigences de la norme : &4.6 (Services externes et

approvisionnements), &4.13 (Enregistrements), &5.3 (Matériels)

Utile pas uniquement pour établir un devis mais aussi pour comprendre les

protocoles d’échange et réaliser les paramétrages en fonction.

Accompagner le laboratoire : établissement d’un cahier des charges et

idéalement d’un contrat.

OK – Début de contractualisation : charte signée, engagement sur les documents

supports, engagement par rapport aux spécifications du laboratoire.

Accompagner le laboratoire lors des étapes de validation ou vérification.

OK – Norme &5.10 : coopération, validation, vérification,

documents d’enregistrement.

Informer de toute mise à jour ou patch correctif.

S’informer mutuellement uniquement ? Et informer le labo ?

Accompagner le laboratoire sur les incidents

Etablir un contrat de maintenance.

OK - &5.3 et &5.10.3

• Etablir avec le laboratoire des connexions à distance sécurisées pour télémaintenance ou export de données (stats, facturation…) – Point sensible -

• S’engager à la confidentialité sur les donnes de santé consultées – En général facile à obtenir -

• Aider le laboratoire à protéger les paramétrages mis en place par une gestion des utilisateurs et des droits – En amélioration -

• Guider le laboratoire sur sa politique de sauvegarde et archivage des données – Point sensible – Les moyens existent mais sont mal compris et moyennement bien gérés par les laboratoires.

• Intègre ces documents dans sa propre documentation

• Est impliqué et co-responsable de la vérification

• Est responsable de la qualification

• Recueille les documents preuves : copies d’écrans, dossiers tests…

• Constitue les dossiers de gestion des évolutions des systèmes (MAJ)

• Exprime ses besoins et utilise les ressources proposées en y associant les ressources du LBM pour :o Gestion des droits

o Gestion des traces primaires

o Gestion des sauvegardes, archivages…

o Politique sécurité vis-à-vis de l’extérieur

• Validation : Concerne surtout les fournisseurs –« Première »

• Vérification : Application au client (LBM)

• Qualification : mise en conformité vis-à-vis de la norme 15189

• Première connexion

• Un seul labo (pilote) est concerné

• Etape qui produit un document unique �idéalement, ce document doit servir de référence pour les étapes suivantes (autres LBM)

Est-il prévu de le communiquer ?

• Intervient au moment de l’installation, dans un LBM, d’une connexion déjà validée.

• Doit s’appuyer sur les éléments obtenus lors de la validation.

• Se produit à une étape initiale (livraison d’un nouvel automate ou d’un nouveau SIL ou nouveau MW)…

• …mais aussi dans d’autres situations :

…

• Changement d’automate ou de méthodes de mesures sur un automate.

• Ajout d’automate ou de module ou de méthodes de mesures sur un automate.

• Mise à jour d’une interface informatique intégrant dans ses composant tout ou partie du processus d’échange de données (logiciel de l’automate, driver de connexion, middleware, SIL) – A définir selon une analyse de risque ou d’impact. – Point sensible -

Coopération avec LBM / fournisseurs ?

• Procédure fortement associée à l’étape de vérification.

• Importance de l’étude d’impact/risque en cas de changement.

• Pas ou peu d’intervention des fournisseurs (ce qui n’exclue pas leur aide)

• Mêmes situations déclenchantes que la vérification plus :

o Modifications de paramétrages des dictionnaires (unités, calculs, conversions, limites de rendu…

o Ajout ou modification de règles d’expertises (repasses, conclusions, dilutions, tests réflexes…)

o Ajouts ou modifications de règles de validation (alertes, delta-check, validation auto…)

o Qualifications régulières pour apprécier la robustesse du processus.

• En évaluation, après le pourquoi, qui et quand, on détermine les moyens mis en œuvre au travers des :

• Dispositions : quels documents sont mis en place pour décrire les situations, les modes opératoires, les méthodes, les supports d’enregistrements…

• Applications : ces documents sont-ils appliqués, quels sont les éléments de preuves et de traçabilité, dates, responsables, conclusions quant à la conformité…

• La politique mise en place est-elle pertinente ?

• Les moyens déployés sont-ils adaptés aux besoins ?

• Documentation externe (fournisseurs) : modes opératoires, guides de référence, procédures opérationnelles, protocoles de communication, spécifications techniques, releases notes, fiches de mises à jour… - Engagements de la charte –

• Documentation interne, adaptée au fonctionnement du LBM:

o modes opératoires, procédures de secours, sauvegarde, archivage,

politique sécurité…

o Enregistrements décrivant les systèmes et leur état à une date donnée,

les dates, les responsables, les conclusions.

o Eléments traces (dossiers tests, copies d’écrans…)

• « Non régression fonctionnelle » :

o Peu utile sauf si le fournisseur peut réellement le

garantir (avec quels outils? Modèle mathématique ?)

o Document « façade » lors d’une évaluation Cofrac.

o La réalité du terrain montre que ça ne suffit pas et que

seule la vigilance associée à une bonne coopération

LBM / fournisseurs est efficace.

• Fiches validation et vérification de la charte :

o Documents référencés avec date d’application et version.

o Assez complets pour ce qui est de décrire une situation.

o Deux contenus identiques – Seul le contexte change.

o Responsabilités définies.

o Dates et signatures prévues.

o Situations pour chaque modalité sont complètes (Tr / NA / T /

OK / NOK)

o Références des dossiers tests prévues.

o � Documents conformes et adaptés.

• Fiches validation et vérification de la charte :

Manque :

o Contexte de la vérification (initiale, ajout, mise à jour,

modification…)

o Conclusion générale quant à la conformité ou non (dans

ce cas quelles actions à prévoir ou limites d’utilisation)

o Quelques informations :• Robustesse de l’identifiant de l’échantillon (longueur et

composition du code à barre, format)

• Redondance des identifiants (avec purge des identifiants non

utilisés)

• « Fiche de vérification » de la charte

• Analyse théorique

• Dossiers tests

• Echantillons de contrôles externes de la qualité EEQ

• Vigilance

• Fiche de suivi de modification logicielle

• Objectifs :

o Décrire toutes les tables de correspondance de tous les

mesurandes, les éditer des SI et les vérifier : codes

d’échanges, unités, décimales, conversions…

o Définir et comprendre en analysant les protocoles des

fournisseurs les transformation ou transmissions qui se

produisent dans les limites de mesure, de calcul,

d’expression ou de linéarité des résultats.

o La fiche de vérification est une bonne base…

o … mais doit être appliquée à tous les examens et pour

toutes les situations.

o Vérifier l’impact d’une modification ou mise à jour.

• Avantages :

o Couvre toutes les étapes du processus.

o Améliore la compréhension des échanges de données.

o Permet une analyse des risques.

• Inconvénients :

o Approche théorique uniquement.

o Peu d’élément de preuves.

o Nécessite un investissement en temps pour comprendre

et la participation des fournisseurs.

• Objectifs :

o Vérifier les échanges de codes : traduction, unités, décimales, arrondis, commentaires…

o Vérifier l’envoi des éléments d’identification du patient.

o Vérifier la prise en compte des amendements.

o Vérifier les règles (expertise, validation…) et calculs.

• Avantages :

o Se fait avant mise en production mais aussi pendant.

o Retour immédiat d’information et traçabilité assurée.

o Possibilité de tester des cas précis (ex. valeurs basses)

• Inconvénients :

o N’évalue pas tout (résultats rares, combinaisons…)

o Lourd à mettre en œuvre et documenter.

o Doit être fait intelligemment…

• Objectifs :

o Vérifier les échanges de codes : traduction, unités, décimales

• Avantages :

o Facile à mettre en place.

o Traçabilité assurée.

o Couvre tout le panel des examens.

o Fréquence définie.

o Répond au besoin de qualification régulière des connexions.

• Inconvénients :

o N’évalue jamais les valeurs extrêmes ou situations rares.

o Planning défini et peu modifiable.

• Objectifs :

o Mise en évidence de dysfonctionnements (heureusement souvent mineurs)

• Avantages :

o Facile à mettre en place

o Traçabilité assurée (si rédaction de non-conformités)

o Evalue les situations rares

o Peut faire l’objet d’une déclaration ANSM

• Inconvénients :

o Dépend de l’utilisateur

o Aléatoire

o Nécessite une centralisation des réclamations informatiques et des biologistes impliqués dans le paramétrage.

Fiche de suivi d’évolution

ou de modification de logiciel

Analyser la documentation

fournisseur de MAJ

En définir les impacts et

précautions

Protocoliser les tests à

effectuer :

vérification à revoir ?

Qualification : quels tests,

quelles fonctions ?

• Les moyens mis en œuvre par les fournisseurs, les intentions exprimées dans la charte et les supports documentaires proposés constituent un point fort.

• Le laboratoire doit transformer l’essai et poursuivre jusqu’à la qualification.

• A évaluer sur le terrain…

MERCIMERCIMERCI