Evidencegericht testen voor gereguleerde onderzoekssystemen

OpenFactory kan afgebakende infrastructuur- en applicatiecontroles voor een contract research organization automatiseren. Het bepaalt geen FDA-compliance, valideert geen volledig geautomatiseerd computersysteem en vervangt het kwaliteitssysteem en de verantwoordelijke goedkeuringen van de gereguleerde organisatie niet.

21 CFR Part 11  is van toepassing op bepaalde elektronische records en handtekeningen en omvat maatregelen die verder gaan dan een besturingssysteemimage: systeemvalidatie, bescherming en terugvinden van records, toegangs- en autorisatiecontroles, audit trails met tijdstempel, training, beleid, documentatiebeheer en eisen voor handtekeningen. De toepasselijke predicate rules en intended use moeten worden vastgesteld door gekwalificeerd juridisch, regulatoir en kwaliteitspersoneel.

De huidige Computer Software Assurance guidance  van de FDA beschrijft een risicogebaseerde aanpak voor productie- en quality-management-systemsoftware. Teams moeten de toepasbaarheid voor hun systeem en context bepalen in plaats van een generiek aantal tests als validatie te beschouwen.

Waarmee OpenFactory-evidence kan helpen

• exacte recipe- en bronherkomst voor een image build;
• package-, service-, file-, port- en command-assertions in een opgestarte guest;
• afgebakende GUI- en screenshot-evidence waar een ondersteunde assertion draait;
• timestamps, output en artifact identifiers per run;
• herhaalbare negatieve en recovery tests; en
• vergelijking van een nieuw artifact met een goedgekeurde baseline.

Elk item is evidence voor een vastgelegde requirement. Geen enkel item bepaalt op zichzelf de regulatoire acceptatie.

Begin met intended use en risico

Documenteer vóór het schrijven van tests:

1. de intended use van het computersysteem;
2. gereguleerde records en handtekeningen, indien van toepassing;
3. gebruikers, rollen, interfaces en data flows;
4. risico’s voor patiënt, productkwaliteit en data-integriteit;
5. requirements en acceptance criteria gekoppeld aan die risico’s;
6. verantwoordelijkheden van leverancier en component; en
7. procedures voor change, incident, backup, recovery, retentie en buiten gebruik stellen.

De besturingssysteemimage is slechts één configuration item binnen dat systeem.

Voorbeeld van een afgebakend scenario

Dit voorbeeld controleert een synthetische integratieservice en lokale auditconfiguratie. Het claimt niet dat een EDC, LIMS, safety database of Part 11-workflow is gevalideerd.

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

Gebruik alleen synthetische, niet-gevoelige testdata in gedeelde build- en screenshotsystemen. Een screenshot kan subject identifiers, credentials, meldingen of andere desktopinhoud tonen. Leg vóór het verzamelen vast hoe capture, redactie, toegang, retentie, export en verwijdering worden geregeld.

Evidence packet

Bewaar voor elke goedgekeurde testrun:

• requirement- en risk identifiers;
• testprotocol en verwacht resultaat;
• recipe revision, source commits, dependency inventory en image digest;
• identiteit van omgeving en testdata;
• ruwe output, screenshots waar gerechtvaardigd, timestamps en runner version;
• afwijkingen, mislukte stappen, onderzoeken en links naar retests;
• identiteit van reviewer, beslissing en datum; en
• traceability van requirement naar evidence en released beslissing.

Label een geautomatiseerd event log of screenshotmap niet opnieuw als Part 11 audit trail. Part 11 audit-trail controls betreffen gereguleerde recordacties, retentie, beschikbaarheid en integriteit in het toepasselijke systeem.

Change- en regressieworkflow

1. Beoordeel de impact van de voorgestelde change.
2. Selecteer tests op basis van risico en getroffen requirements.
3. Bouw een nieuw immutable artifact; bewaar het eerder goedgekeurde artifact.
4. Voer het protocol uit in een gecontroleerde omgeving.
5. Beoordeel failures en afwijkingen zonder ongunstige evidence te verwijderen.
6. Verkrijg de vereiste kwaliteits-, security-, business- en regulatoire goedkeuringen.
7. Deploy via change control en verifieer de productieconfiguratie.
8. Monitor op drift en voer het geteste recovery pad uit wanneer nodig.

OpenFactory kan evidence collection verkorten voor stappen die het daadwerkelijk automatiseert. De gereguleerde organisatie blijft verantwoordelijk voor intended-use validatie, procedurele controls, data governance en de definitieve released beslissing.