Evidensbasert testing for regulerte forskningssystemer

OpenFactory kan automatisere avgrensede infrastruktur- og applikasjonskontroller for en contract research organization. Det avgjør ikke FDA-compliance, validerer ikke automatisk et helt datasystem og erstatter ikke det regulerte selskapets kvalitetssystem og ansvarlige godkjenninger.

21 CFR Part 11  gjelder for spesifiserte elektroniske poster og signaturer og omfatter kontroller utover et operativsystemimage: system validation, record protection and retrieval, access and authority checks, time-stamped audit trails, training, policies, documentation controls og signature requirements. Applicable predicate rules og intended use må fastsettes av qualified legal, regulatory og quality personnel.

FDAs gjeldende Computer Software Assurance guidance  beskriver en risikobasert tilnærming for production and quality-management-system software. Team bør vurdere applicability for systemet og konteksten i stedet for å behandle et generisk antall tester som validation.

Hva OpenFactory-evidens kan støtte

• nøyaktig recipe og source provenance for en image build;
• package-, service-, file-, port- og command assertions i en bootet guest;
• avgrenset GUI- og screenshot-evidens der et supported assertion kjører;
• timestamps, output og artifact identifiers per kjøring;
• repeterbare negative og recovery tests; og
• sammenligning av et nytt artifact mot en approved baseline.

Hvert punkt er evidens for et angitt requirement. Ingen punkt etablerer regulatory acceptability alene.

Start med intended use og risiko

Før du skriver tester, dokumenter:

1. intended use for datasystemet;
2. regulated records og signatures, hvis aktuelt;
3. users, roles, interfaces og data flows;
4. patient-, product-quality- og data-integrity risks;
5. requirements og acceptance criteria knyttet til disse risikoene;
6. supplier og component responsibilities; og
7. change-, incident-, backup-, recovery-, retention- og decommissioning procedures.

Operativsystemimage er bare ett configuration item i det systemet.

Eksempel på avgrenset scenario

Eksemplet sjekker en syntetisk integrasjonstjeneste og lokal auditkonfigurasjon. Det hevder ikke at EDC, LIMS, safety database eller Part 11-workflow er validert.

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

Bruk bare syntetiske, ikke-sensitive testdata i delte build- og skjermbilde-systemer. Et skjermbilde kan avsløre subject identifiers, credentials, varsler eller annet skrivebordsinnhold. Definer kontroller for capture, redaction, access, retention, export og deletion før du samler inn materiale.

Evidence packet

For hver approved test run, bevar:

• requirement- og risk identifiers;
• test protocol og expected result;
• recipe revision, source commits, dependency inventory og image digest;
• environment og test-data identity;
• raw output, screenshots der det er begrunnet, timestamps og runner version;
• deviations, failed steps, investigations og retest links;
• reviewer identity, decision og date; og
• traceability fra requirement til evidence og release decision.

Ikke merk en automatisert event log eller screenshot-mappe på nytt som Part 11 audit trail. Part 11 audit-trail controls gjelder regulated record actions, retention, availability og integrity i det aktuelle systemet.

Change- og regressionsworkflow

1. Vurder impact av den foreslåtte change.
2. Velg tester basert på risiko og berørte requirements.
3. Bygg et nytt immutable artifact; behold det tidligere approved artifact.
4. Kjør protocol i et controlled environment.
5. Gjennomgå failures og deviations uten å slette ugunstig evidens.
6. Innhent required quality-, security-, business- og regulatory approvals.
7. Deploy via change control og verifiser production configuration.
8. Overvåk drift og kjør den testede recovery path ved behov.

OpenFactory kan forkorte evidence collection for trinn det faktisk automatiserer. Det regulerte selskapet er fortsatt ansvarlig for intended-use validation, procedural controls, data governance og den endelige release decision.