Bizonyíték-központú tesztelés szabályozott kutatási rendszerekhez

Az OpenFactory korlátozott infrastruktúra- és alkalmazás-ellenőrzéseket tud automatizálni egy contract research organization számára. Nem határozza meg az FDA-megfelelőséget, nem validálja automatikusan a teljes számítógépes rendszert, és nem helyettesíti a szabályozott szervezet minőségirendszerét és az elszámoltatható jóváhagyásokat.

A 21 CFR Part 11  meghatározott elektronikus feljegyzésekre és aláírásokra vonatkozik, és az operációs rendszer képén túlmutató kontrollokat foglal magában: rendszervalidáció, feljegyzésvédelem és visszakeresés, hozzáférési és jogosultság-ellenőrzések, időbélyeges audit trail, képzés, irányelvek, dokumentációs kontrollok és aláírási követelmények. Az alkalmazandó predicate rules és intended use képzett jogi, szabályozási és minőségügyi személyzet határozza meg.

Az FDA jelenlegi Computer Software Assurance guidance  dokumentuma kockázatalapú megközelítést ír le a gyártási és minőségirányítási rendszer szoftverére. A csapatoknak a saját rendszerükre és környezetükre kell megállapítaniuk az alkalmazhatóságot, nem pedig egy általános tesztszámot validációként kezelniük.

Mit tud támogatni az OpenFactory evidence

• pontos recipe és source provenance egy image buildhez;
• package, service, file, port és command assertions bootolt vendégen;
• korlátozott GUI és képernyőkép evidence, ahol támogatott assertion fut;
• timestamps, output és artifact identifiers futásonként;
• ismételhető negative és recovery tests; és
• új artifact összehasonlítása jóváhagyott baseline-nal.

Minden tétel evidence egy megfogalmazott requirementhez. Egyik sem állapít meg önmagában szabályozási elfogadhatóságot.

Kezdje az intended use-szal és a kockázattal

Tesztek írása előtt dokumentálja:

1. a számítógépes rendszer intended use-ját;
2. a szabályozott records és signatures meglétét, ha van;
3. a felhasználókat, szerepköröket, interfészeket és data flows-t;
4. a beteg-, termékminőség- és adatintegritási kockázatokat;
5. a requirements és acceptance criteria kapcsolódását ezekhez a kockázatokhoz;
6. a beszállítói és komponensfelelősségeket; és
7. a change, incident, backup, recovery, retention és kivezetési eljárásokat.

Az operációs rendszer képe csak egy configuration item ebben a rendszerben.

Példa korlátozott forgatókönyvre

Ez a példa egy szintetikus integrációs szolgáltatást és helyi audit konfigurációt ellenőriz. Nem állítja, hogy EDC, LIMS, safety database vagy Part 11 workflow validált.

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

Megosztott build és képernyőkép rendszerekben csak szintetikus, nem érzékeny tesztadatot használjon. Egy képernyőkép felfedhet subject identifiers, credentials, értesítéseket vagy kapcsolódó asztali tartalmat. A gyűjtés előtt határozza meg a capture, redaction, hozzáférés, retention, export és deletion kontrollokat.

Evidence packet

Minden jóváhagyott tesztfutáshoz őrizze meg:

• requirement és risk identifiers;
• test protocol és elvárt eredmény;
• recipe revision, source commits, dependency inventory és image digest;
• környezet és tesztadat azonosságát;
• nyers output, screenshots ahol indokolt, timestamps és runner version;
• eltéréseket, sikertelen lépéseket, vizsgálatokat és retest hivatkozásokat;
• reviewer azonosságát, döntését és dátumát; és
• traceability a requirementtől az evidence-ig és a release döntésig.

Ne nevezzen át automatizált event logot vagy képernyőkép mappát Part 11 audit trailnek. A Part 11 audit-trail controls a szabályozott feljegyzési műveleteket, retentiont, rendelkezésre állást és integritást érintik az alkalmazandó rendszerben.

Change és regressziós workflow

1. Értékelje a javasolt change hatását.
2. Válasszon teszteket kockázat és érintett requirements alapján.
3. Építsen új immutable artifactot; tartsa meg a korábban jóváhagyott artifactot.
4. Futtassa a protocolt ellenőrzött környezetben.
5. Vizsgálja a failures és eltéréseket kedvezőtlen evidence törlése nélkül.
6. Szerezze be a szükséges minőségügyi, security, business és szabályozási jóváhagyásokat.
7. Telepítsen change controlon keresztül, és ellenőrizze a produkciós konfigurációt.
8. Figyelje a driftet, és szükség esetén hajtsa végre a tesztelt recovery path-ot.

Az OpenFactory rövidítheti az evidence collectiont azoknál a lépéseknél, amelyeket ténylegesen automatizál. A szabályozott szervezet továbbra is felel az intended-use validationért, procedural controls-ért, data governance-ért és a végső release döntésért.