Testowanie oparte na dowodach dla regulowanych systemów badawczych

OpenFactory może automatyzować ograniczone kontrole infrastruktury i aplikacji dla contract research organization. Nie ustala zgodności z FDA, nie waliduje automatycznie całego systemu komputerowego ani nie zastępuje systemu jakości i odpowiedzialnych zatwierdzeń organizacji podlegającej regulacjom.

21 CFR Part 11  dotyczy określonych elektronicznych zapisów i podpisów oraz obejmuje kontrole wykraczające poza obraz systemu operacyjnego: walidację systemu, ochronę i odtwarzanie zapisów, kontrole dostępu i uprawnień, ścieżki audytu ze znacznikiem czasu, szkolenia, polityki, kontrolę dokumentacji oraz wymagania dotyczące podpisów. Obowiązujące predicate rules i intended use muszą ustalić wykwalifikowany personel prawny, regulacyjny i jakościowy.

Aktualne Computer Software Assurance guidance  FDA opisuje podejście oparte na ryzyku dla oprogramowania produkcyjnego i systemów zarządzania jakością. Zespoły powinny określić stosowalność dla swojego systemu i kontekstu, zamiast traktować ogólną liczbę testów jako walidację.

Czym może wspierać dowody OpenFactory

• dokładne recipe i pochodzenie źródeł dla image build;
• package, service, file, port i command assertions w uruchomionym gościu;
• ograniczone dowody GUI i zrzutów ekranu, gdy działa obsługiwane assertion;
• timestamps, output i artifact identifiers dla każdego przebiegu;
• powtarzalne negative i recovery tests; oraz
• porównanie nowego artifact z zatwierdzoną baseline.

Każdy punkt to dowód dla określonego requirement. Żaden sam z siebie nie ustala akceptacji regulacyjnej.

Zacznij od intended use i ryzyka

Przed pisaniem testów udokumentuj:

1. intended use systemu komputerowego;
2. regulowane records i signatures, jeśli występują;
3. użytkowników, role, interfejsy i data flows;
4. ryzyka dla pacjenta, jakości produktu i integralności danych;
5. requirements i acceptance criteria powiązane z tymi ryzykami;
6. odpowiedzialność dostawcy i komponentów; oraz
7. procedury change, incident, backup, recovery, retention i wycofania.

Obraz systemu operacyjnego to tylko jeden configuration item w tym systemie.

Przykład ograniczonego scenariusza

Ten przykład sprawdza syntetyczną usługę integracyjną i lokalną konfigurację audytu. Nie twierdzi, że EDC, LIMS, safety database ani workflow Part 11 są zwalidowane.

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

Używaj wyłącznie syntetycznych, niewrażliwych danych testowych we współdzielonych systemach build i zrzutów ekranu. Zrzut ekranu może ujawnić subject identifiers, credentials, powiadomienia lub inną zawartość pulpitu. Zdefiniuj kontrole capture, redaction, dostępu, retention, export i deletion przed zbieraniem.

Evidence packet

Dla każdego zatwierdzonego przebiegu testu zachowaj:

• requirement i risk identifiers;
• test protocol i oczekiwany wynik;
• recipe revision, source commits, dependency inventory i image digest;
• tożsamość środowiska i danych testowych;
• surowy output, screenshots tam gdzie uzasadnione, timestamps i runner version;
• odchylenia, nieudane kroki, dochodzenia i linki do retest;
• tożsamość reviewer, decyzję i datę; oraz
• traceability od requirement do evidence i decyzji release.

Nie oznaczaj ponownie zautomatyzowanego event log ani folderu ze zrzutami ekranu jako Part 11 audit trail. Part 11 audit-trail controls dotyczą regulowanych działań na zapisach, retention, dostępności i integralności w całym stosownym systemie.

Workflow change i regresji

1. Oceń wpływ proponowanej change.
2. Wybierz testy według ryzyka i dotkniętych requirements.
3. Zbuduj nowy immutable artifact; zachowaj wcześniej zatwierdzony artifact.
4. Uruchom protocol w kontrolowanym środowisku.
5. Przejrzyj failures i odchylenia bez usuwania niesprzyjających dowodów.
6. Uzyskaj wymagane zatwierdzenia jakości, security, business i regulacyjne.
7. Wdróż przez change control i zweryfikuj konfigurację produkcyjną.
8. Monitoruj drift i wykonaj przetestowaną ścieżkę recovery w razie potrzeby.

OpenFactory może skrócić evidence collection dla kroków, które faktycznie automatyzuje. Organizacja podlegająca regulacjom pozostaje odpowiedzialna za intended-use validation, procedure controls, data governance i ostateczną decyzję release.