Testiranje, usmerjeno v dokaze, za regulirane raziskovalne sisteme

OpenFactory lahko avtomatizira omejene preglede infrastrukture in aplikacij za contract research organization. Ne določa skladnosti z FDA, ne validira samodejno celotnega računalniškega sistema in ne nadomešča sistema kakovosti regulirane organizacije ter odgovornih odobritev.

21 CFR Part 11  velja za določene elektronske zapise in podpise ter vključuje kontrole onkraj slike operacijskega sistema: validacijo sistema, zaščito in pridobivanje zapisov, kontrole dostopa in pooblastil, revizijske sledi s časovnim žigom, usposabljanje, politike, kontrole dokumentacije in zahteve glede podpisov. Veljavna predicate rules in intended use morajo določiti usposobljeni pravni, regulativni in kakovostni kadri.

Trenutni Computer Software Assurance guidance  FDA opisuje pristop, ki temelji na tveganju, za proizvodno programsko opremo in programsko opremo sistemov vodenja kakovosti. Ekipe naj ugotovijo uporabnost za svoj sistem in kontekst, namesto da splošno število testov obravnavajo kot validacijo.

Kaj lahko podpira evidence OpenFactory

• natančno recipe in source provenance za image build;
• package, service, file, port in command assertions v zagnanem gostu;
• omejeni dokazi GUI in posnetkov zaslona, kjer teče podprto assertion;
• timestamps, output in artifact identifiers za vsak zagon;
• ponovljivi negative in recovery tests; in
• primerjava novega artifact s odobreno baseline.

Vsaka točka je dokaz za navedeno requirement. Nobena sama po sebi ne vzpostavi regulativne sprejemljivosti.

Začnite z intended use in tveganjem

Pred pisanjem testov dokumentirajte:

1. intended use računalniškega sistema;
2. regulirane records in signatures, če obstajajo;
3. uporabnike, vloge, vmesnike in data flows;
4. tveganja za pacienta, kakovost izdelka in integriteto podatkov;
5. requirements in acceptance criteria, povezane s temi tveganji;
6. odgovornosti dobavitelja in komponent; in
7. postopke change, incident, backup, recovery, retention in razveljavitve.

Slika operacijskega sistema je le ena configuration item v tem sistemu.

Primer omejenega scenarija

Ta primer preveri sintetično integracijsko storitev in lokalno konfiguracijo revizije. Ne trdi, da so EDC, LIMS, safety database ali workflow Part 11 validirani.

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

V skupnih sistemih build in posnetkov zaslona uporabljajte le sintetične, neobčutljive testne podatke. Posnetek zaslona lahko razkrije subject identifiers, credentials, obvestila ali nepovezano vsebino namizja. Pred zbiranjem določite kontrole capture, redaction, dostopa, retention, export in deletion.

Evidence packet

Za vsak odobren zagon testa ohranite:

• requirement in risk identifiers;
• test protocol in pričakovani rezultat;
• recipe revision, source commits, dependency inventory in image digest;
• identiteto okolja in testnih podatkov;
• surov output, screenshots kjer je upravičeno, timestamps in runner version;
• odstopanja, neuspele korake, preiskave in povezave na retest;
• identiteto reviewer, odločitev in datum; in
• traceability od requirement do evidence in odločitve o release.

Ne preimenujte avtomatiziranega event log ali mape s posnetki zaslona v Part 11 audit trail. Part 11 audit-trail controls zadevajo regulirane dejanja nad zapisi, retention, razpoložljivost in integriteto v ustreznem sistemu.

Workflow change in regresije

1. Ocenite vpliv predlagane change.
2. Izberite teste glede na tveganje in prizadete requirements.
3. Zgradite nov immutable artifact; ohranite prej odobren artifact.
4. Zaženite protocol v nadzorovanem okolju.
5. Preglejte failures in odstopanja brez brisanja neugodnih dokazov.
6. Pridobite zahtevane odobritve kakovosti, security, business in regulative.
7. Namestite prek change control in preverite produkcijsko konfiguracijo.
8. Spremljajte drift in po potrebi izvedite preizkušeno recovery path.

OpenFactory lahko skrajša evidence collection za korake, ki jih dejansko avtomatizira. Regulirana organizacija ostaja odgovorna za intended-use validation, procedural controls, data governance in končno odločitev o release.