Uz pierādījumiem balstīta testēšana regulētām pētniecības sistēmām

OpenFactory var automatizēt ierobežotas infrastruktūras un lietojumprogrammu pārbaudes līgumpētniecības organizācijai. Tas nenoteic FDA atbilstību, automātiski nevalidē visu datorizēto sistēmu un neaizstāj regulētās organizācijas kvalitātes sistēmu un atbildīgos apstiprinājumus.

21 CFR Part 11  attiecas uz norādītajiem elektroniskajiem ierakstiem un parakstiem un ietver kontroles, kas pārsniedz operētājsistēmas attēlu: sistēmas validāciju, ierakstu aizsardzību un atgūšanu, piekļuves un pilnvaru pārbaudes, ar laika zīmogu auditēšanas takus, apmācību, politikas, dokumentācijas kontroli un parakstu prasības. Piemērojamās predicate noteikumus un paredzēto lietojumu jānosaka kvalificētiem juridiskajiem, regulējošajiem un kvalitātes speciālistiem.

FDA pašreizējais Computer Software Assurance guidance  apraksta uz risku balstītu pieeju ražošanas un kvalitātes vadības sistēmas programmatūrai. Komandām jānosaka piemērojamība savai sistēmai un kontekstam, nevis jāuzskata vispārīgs testu skaits par validāciju.

Ko var atbalstīt OpenFactory pierādījumi

• precīzu receptes un avota izcelsmi attēla build laikā;
• pakotņu, pakalpojumu, failu, portu un komandu apgalvojumus ielādētā viesī;
• ierobežotus GUI un ekrānuzņēmumu pierādījumus, kur darbojas atbalstīts apgalvojums;
• katra palaišanas laika zīmogus, izvadi un artefakta identifikatorus;
• atkārtojamus negatīvos un atjaunošanas testus; un
• jauna artefakta salīdzinājumu ar apstiprināto bāzes līniju.

Katrs punkts ir pierādījums norādītajam prasījumam. Neviens pats par sevi nenosaka regulējošo pieņemamību.

Sāciet ar paredzēto lietojumu un risku

Pirms testu rakstīšanas dokumentējiet:

1. datorizētās sistēmas paredzēto lietojumu;
2. regulētos ierakstus un parakstus, ja tādi ir;
3. lietotājus, lomas, saskarnes un datu plūsmas;
4. pacientu, produkta kvalitātes un datu integritātes riskus;
5. prasības un pieņemšanas kritērijus, kas saistīti ar šiem riskiem;
6. piegādātāju un komponentu atbildību; un
7. izmaiņu, incidentu, dublējumu, atjaunošanas, glabāšanas un izņemšanas procedūras.

Operētājsistēmas attēls ir tikai viens konfigurācijas elements šajā sistēmā.

Ierobežota scenārija piemērs

Šis piemērs pārbauda sintētisku integrācijas pakalpojumu un vietējo audita konfigurāciju. Tas neapgalvo, ka EDC, LIMS, drošības datubāze vai Part 11 darbplūsma ir validēta.

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

Koplietotajās build un ekrānuzņēmumu sistēmās izmantojiet tikai sintētiskus, nejutīgus testa datus. Ekrānuzņēmums var atklāt dalībnieku identifikatorus, akreditācijas datus, paziņojumus vai nesaistītu darbvirsmas saturu. Pirms vākšanas definējiet tveršanas, rediģēšanas, piekļuves, glabāšanas, eksporta un dzēšanas kontroles.

Pierādījumu pakete

Katram apstiprinātajam testa palaišanai saglabājiet:

• prasības un riska identifikatorus;
• testa protokolu un sagaidāmo rezultātu;
• receptes revīziju, avota commit, atkarību sarakstu un attēla digest;
• vides un testa datu identitāti;
• neapstrādātu izvadi, ekrānuzņēmumus, ja tas ir pamatots, laika zīmogus un runner versiju;
• novirzes, neveiksmīgos soļus, izmeklēšanu un atkārtota testa saites;
• recenzenta identitāti, lēmumu un datumu; un
• izsekojamību no prasības līdz pierādījumam un izlaišanas lēmumam.

Automātisko notikumu žurnālu vai ekrānuzņēmumu mapi nepārdēvējiet par Part 11 audita taku. Part 11 audita taku kontroles attiecas uz regulēto ierakstu darbībām, glabāšanu, pieejamību un integritāti visā piemērojamajā sistēmā.

Izmaiņu un regresijas darba plūsma

1. Novērtējiet ierosinātās izmaiņas ietekmi.
2. Izvēlieties testus pēc riska un ietekmētajām prasībām.
3. Izveidojiet jaunu nemainīgu artefaktu; saglabājiet iepriekšējo apstiprināto artefaktu.
4. Izpildiet protokolu kontrolētā vidē.
5. Pārskatiet neveiksmes un novirzes, nedzēšot neizdevīgos pierādījumus.
6. Iegūstiet nepieciešamos kvalitātes, drošības, biznesa un regulējošos apstiprinājumus.
7. Ieviesiet caur izmaiņu kontroli un pārbaudiet ražošanas konfigurāciju.
8. Uzraugiet novirzi un vajadzības gadījumā izpildiet pārbaudīto atjaunošanas ceļu.

OpenFactory var saīsināt pierādījumu vākšanu soļiem, kurus tas patiešām automatizē. Regulētā organizācija paliek atbildīga par paredzētā lietojuma validāciju, procedūras kontrolēm, datu pārvaldību un galīgo izlaišanas lēmumu.