Testare orientată spre dovezi pentru sisteme de cercetare reglementate

OpenFactory poate automatiza verificări limitate ale infrastructurii și aplicațiilor pentru o contract research organization. Nu stabilește conformitatea FDA, nu validează automat un întreg sistem computerizat și nu înlocuiește sistemul de calitate al organizației reglementate și aprobările responsabile.

21 CFR Part 11 se aplică anumitor înregistrări și semnături electronice și include controale dincolo de imaginea sistemului de operare: validarea sistemului, protecția și regăsirea înregistrărilor, verificări de acces și autoritate, piste de audit cu marcaj temporal, instruire, politici, controale documentare și cerințe de semnătură. Predicate rules aplicabile și intended use trebuie stabilite de personal juridic, de reglementare și de calitate calificat.

Computer Software Assurance guidance actual al FDA descrie o abordare bazată pe risc pentru software de producție și pentru software de sistem de management al calității. Echipele ar trebui să determine aplicabilitatea pentru sistemul și contextul lor, în loc să trateze un număr generic de teste ca validare.

Ce poate susține evidence OpenFactory

recipe exact și source provenance pentru un image build;
package, service, file, port și command assertions într-un oaspete pornit;
dovezi GUI și capturi de ecran limitate unde rulează un assertion acceptat;
timestamps, output și artifact identifiers per rulare;
negative și recovery tests repetabile; și
compararea unui artifact nou cu o baseline aprobată.

Fiecare element este dovadă pentru un requirement enunțat. Niciunul nu stabilește singur acceptabilitatea reglementară.

Începeți cu intended use și risc

Înainte de a scrie teste, documentați:

intended use al sistemului computerizat;
records și signatures reglementate, dacă există;
utilizatori, roluri, interfețe și data flows;
riscuri pentru pacient, calitatea produsului și integritatea datelor;
requirements și acceptance criteria legate de aceste riscuri;
responsabilități ale furnizorului și componentelor; și
proceduri de change, incident, backup, recovery, retention și decommissioning.

Imaginea sistemului de operare este doar un configuration item în acel sistem.

Exemplu de scenariu limitat

Acest exemplu verifică un serviciu de integrare sintetic și configurația locală de audit. Nu afirmă că un EDC, LIMS, safety database sau workflow Part 11 este validat.


{
  "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"
          }
        }
      ]
    }
  ]
}

Folosiți doar date de test sintetice, neconfidențiale, în sistemele partajate de build și capturi de ecran. O captură poate expune subject identifiers, credentials, notificări sau conținut de desktop nelegat. Definiți controale de capture, redaction, acces, retention, export și deletion înainte de colectare.

Evidence packet

Pentru fiecare rulare de test aprobată, păstrați:

requirement și risk identifiers;
test protocol și rezultat așteptat;
recipe revision, source commits, dependency inventory și image digest;
identitatea mediului și a datelor de test;
output brut, screenshots unde este justificat, timestamps și runner version;
abateri, pași eșuați, investigații și legături de retest;
identitatea reviewer, decizia și data; și
traceability de la requirement la evidence și decizia de release.

Nu redenumiți un event log automatizat sau un folder de capturi ca Part 11 audit trail. Part 11 audit-trail controls vizează acțiunile asupra înregistrărilor reglementate, retention, disponibilitate și integritate în sistemul aplicabil.

Workflow de change și regresie

Evaluați impactul change-ului propus.
Selectați teste după risc și requirements afectate.
Construiți un artifact immutable nou; păstrați artifactul aprobat anterior.
Rulați protocolul într-un mediu controlat.
Examinați failures și abateri fără a șterge dovezi nefavorabile.
Obțineți aprobările necesare de calitate, security, business și reglementare.
Implementați prin change control și verificați configurația de producție.
Monitorizați drift și executați recovery path testat când este nevoie.

OpenFactory poate scurta evidence collection pentru pașii pe care îi automatizează efectiv. Organizația reglementată rămâne responsabilă pentru intended-use validation, procedural controls, data governance și decizia finală de release.