Todisteisiin perustuva testaus säännellyille tutkimusjärjestelmille

OpenFactory voi automatisoida rajattuja infrastruktuuri- ja sovellustarkistuksia contract research organizationille. Se ei määritä FDA-yhteensopivuutta, validoi koko tietokoneistettua järjestelmää automaattisesti eikä korvaa säännellyn organisaation laatujärjestelmää ja vastuullisia hyväksyntöjä.

21 CFR Part 11  koskee määriteltyjä sähköisiä tietueita ja allekirjoituksia ja sisältää kontrollit, jotka ulottuvat käyttöjärjestelmäkuvaa pidemmälle: system validation, record protection and retrieval, access and authority checks, time-stamped audit trails, training, policies, documentation controls ja signature requirements. Applicable predicate rules ja intended use on määriteltävä qualified legal, regulatory ja quality personnelin toimesta.

FDAn ajankohtainen Computer Software Assurance guidance  kuvaa riskiperusteista lähestymistapaa production and quality-management-system softwarelle. Tiimien tulee arvioida applicability omalle järjestelmälleen ja kontekstilleen sen sijaan, että yleistä testimäärää pidettäisiin validationina.

Mitä OpenFactory-todisteet voivat tukea

• tarkka recipe ja source provenance image buildille;
• package-, service-, file-, port- ja command assertions käynnistetyssä guestissa;
• rajattu GUI- ja screenshot-todiste, kun supported assertion ajetaan;
• timestamps, output ja artifact identifiers kullekin ajolle;
• toistettavat negative ja recovery tests; ja
• uuden artifactin vertailu approved baselineen.

Jokainen kohta on todiste ilmoitetulle requirementille. Mikään kohta ei yksinään määritä regulatory acceptabilitya.

Aloita intended usesta ja riskistä

Ennen testien kirjoittamista dokumentoi:

1. tietokoneistetun järjestelmän intended use;
2. regulated records ja signatures, jos niitä on;
3. users, roles, interfaces ja data flows;
4. patient-, product-quality- ja data-integrity risks;
5. requirements ja acceptance criteria, jotka liittyvät näihin riskeihin;
6. supplier ja component responsibilities; ja
7. change-, incident-, backup-, recovery-, retention- ja decommissioning procedures.

Käyttöjärjestelmäkuva on vain yksi configuration item kyseisessä järjestelmässä.

Esimerkki rajatusta skenaariosta

Esimerkki tarkistaa synteettisen integraatiopalvelun ja paikallisen audit-konfiguraation. Se ei väitä EDC:n, LIMS:n, safety databasen tai Part 11 -workflowin olevan validoitu.

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

Käytä jaetuissa build- ja kuvakaappausjärjestelmissä vain synteettisiä, ei-arkaluonteisia testidataa. Kuvakaappaus voi paljastaa subject identifiers, credentials, ilmoituksia tai muuta työpöydän sisältöä. Määritä capture-, redaction-, access-, retention-, export- ja deletion-kontrollit ennen keräämistä.

Evidence packet

Säilytä jokaisesta approved test runista:

• requirement- ja risk identifiers;
• test protocol ja expected result;
• recipe revision, source commits, dependency inventory ja image digest;
• environment ja test-data identity;
• raw output, screenshots perustelluissa tapauksissa, timestamps ja runner version;
• deviations, failed steps, investigations ja retest links;
• reviewer identity, decision ja date; ja
• traceability requirementista evidenceen ja release decisioniin.

Älä merkitse automatisoidun event login tai screenshot-kansion uudelleen Part 11 audit trailiksi. Part 11 audit-trail controls koskevat regulated record actions, retention, availability ja integritya sovellettavassa järjestelmässä.

Change- ja regressioworkflow

1. Arvioi ehdotetun changen vaikutus.
2. Valitse testit riskin ja vaikutettujen requirementsien perusteella.
3. Rakenna uusi immutable artifact; säilytä aiempi approved artifact.
4. Aja protocol controlled environmentissa.
5. Käy läpi failures ja deviations poistamatta epäedullista evidencea.
6. Hanki required quality-, security-, business- ja regulatory approvals.
7. Deploy change controlin kautta ja varmista production configuration.
8. Seuraa driftiä ja suorita testattu recovery path tarvittaessa.

OpenFactory voi lyhentää evidence collectionia vaiheissa, joita se todella automatisoi. Säännelty organisaatio vastaa edelleen intended-use validationista, procedural controlsista, data governancesta ja lopullisesta release decisionista.