Skip to Content
TestingTests orientés preuves pour systèmes de recherche réglementés

Tests orientés preuves pour systèmes de recherche réglementés

OpenFactory peut automatiser des vérifications d’infrastructure et d’application bornées pour une organisation de recherche sous contrat. Il ne détermine pas la conformité FDA, ne valide pas automatiquement un système informatisé entier, ni ne remplace le système qualité de l’organisation réglementée et les approbations responsables.

Le 21 CFR Part 11  s’applique à certains enregistrements et signatures électroniques et inclut des contrôles au-delà d’une image de système d’exploitation : validation système, protection et récupération des enregistrements, contrôles d’accès et d’autorité, pistes d’audit horodatées, formation, politiques, contrôles documentaires et exigences de signature. Les règles prédicates applicables et l’usage prévu doivent être établis par du personnel juridique, réglementaire et qualité qualifié.

Le guide Computer Software Assurance  actuel de la FDA décrit une approche basée sur le risque pour les logiciels de production et de système de management qualité. Les équipes doivent déterminer l’applicabilité à leur système et contexte plutôt que de traiter un décompte de tests générique comme validation.

Ce que les preuves OpenFactory peuvent soutenir

  • provenance exacte de recette et source pour un build d’image ;
  • assertions paquet, service, fichier, port et commande dans un invité démarré ;
  • preuves GUI et capture d’écran bornées lorsqu’une assertion supportée tourne ;
  • horodatages, sortie et identifiants d’artefact par exécution ;
  • tests négatifs et de reprise reproductibles ; et
  • comparaison d’un nouvel artefact à une baseline approuvée.

Chaque élément est une preuve pour une exigence énoncée. Aucun n’établit à lui seul l’acceptabilité réglementaire.

Commencer par usage prévu et risque

Avant de rédiger des tests, documentez :

  1. l’usage prévu du système informatisé ;
  2. enregistrements et signatures réglementés, le cas échéant ;
  3. utilisateurs, rôles, interfaces et flux de données ;
  4. risques patient, qualité produit et intégrité des données ;
  5. exigences et critères d’acceptation liés à ces risques ;
  6. responsabilités fournisseur et composants ; et
  7. procédures de changement, incident, sauvegarde, reprise, rétention et décommissionnement.

L’image de système d’exploitation n’est qu’un élément de configuration dans ce système.

Exemple de scénario borné

Cet exemple vérifie un service d’intégration synthétique et une configuration d’audit locale. Il ne prétend pas qu’un EDC, LIMS, base de sécurité ou workflow Part 11 est validé.

{
  "id": "synthetic-integration-smoke",
  "name": "Synthetic integration and audit smoke test",
  "enabled": true,
  "tests": ["boot", "login", "packages", "services"],
  "custom_tests": [
    {
      "description": "Confirm the synthetic receiver and audit controls are present.",
      "assertions": [
        {
          "type": "service_running",
          "description": "The synthetic receiver is running.",
          "params": {"service": "synthetic-receiver"}
        },
        {
          "type": "port_listening",
          "description": "The synthetic receiver listens on its lab port.",
          "params": {"port": 2575}
        },
        {
          "type": "service_running",
          "description": "The Linux audit daemon is running.",
          "params": {"service": "auditd"}
        },
        {
          "type": "file_contains",
          "description": "The approved synthetic data path has an audit watch.",
          "params": {
            "path": "/etc/audit/rules.d/research-system.rules",
            "content": "-w /var/lib/synthetic-study"
          }
        }
      ]
    }
  ]
}

Utilisez uniquement des données de test synthétiques non sensibles dans les systèmes de build et capture partagés. Une capture peut exposer identifiants sujet, identifiants, notifications ou contenu bureau non lié. Définissez contrôles de capture, caviardage, accès, rétention, export et suppression avant collecte.

Dossier de preuves

Pour chaque exécution de test approuvée, conservez :

  • identifiants d’exigence et de risque ;
  • protocole de test et résultat attendu ;
  • révision recette, commits source, inventaire dépendances et digest image ;
  • identité environnement et données de test ;
  • sortie brute, captures lorsque justifiées, horodatages et version runner ;
  • écarts, étapes en échec, investigations et liens de retest ;
  • identité relecteur, décision et date ; et
  • traçabilité de l’exigence à la preuve et à la décision de release.

Ne requalifiez pas un journal d’événements automatisé ou un dossier de captures comme piste d’audit Part 11. Les contrôles de piste d’audit Part 11 concernent les actions sur enregistrements réglementés, rétention, disponibilité et intégrité dans le système applicable.

Workflow changement et régression

  1. Évaluez l’impact du changement proposé.
  2. Sélectionnez tests selon risque et exigences affectées.
  3. Construisez un nouvel artefact immuable ; conservez l’artefact approuvé précédent.
  4. Exécutez le protocole dans un environnement contrôlé.
  5. Relisez échecs et écarts sans supprimer preuves défavorables.
  6. Obtenez approbations qualité, sécurité, métier et réglementaires requises.
  7. Déployez via contrôle de changement et vérifiez la configuration production.
  8. Surveillez la dérive et exécutez le chemin de reprise testé si nécessaire.

OpenFactory peut raccourcir la collecte de preuves pour les étapes qu’il automatise réellement. L’organisation réglementée reste responsable de la validation d’usage prévu, des contrôles procéduraux, de la gouvernance des données et de la décision de release finale.

Preuves benchmark CISAssertions personnalisées