Evidensorienteret test af regulerede forskningssystemer
OpenFactory kan automatisere afgrænsede infrastruktur- og applikationskontroller for en contract research organization. Det afgør ikke FDA-compliance, validerer ikke automatisk et helt computersystem og erstatter ikke den regulerede organisations kvalitetssystem og ansvarlige godkendelser.
21 CFR Part 11 gælder for specificerede elektroniske poster og signaturer og omfatter kontroller ud over 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 skal fastsættes af qualified legal, regulatory og quality personnel.
FDAs aktuelle Computer Software Assurance guidance beskriver en risikobaseret tilgang til production and quality-management-system software. Teams bør fastlægge applicability for deres system og kontekst i stedet for at behandle et generisk antal tests som validation.
Hvad OpenFactory-evidens kan understøtte
- præcis recipe og source provenance for en image build;
- package-, service-, file-, port- og command assertions i en bootet guest;
- afgrænset GUI- og screenshot-evidens, hvor et supported assertion kører;
- timestamps, output og artifact identifiers pr. kørsel;
- gentagelige negative og recovery tests; og
- sammenligning af et nyt artifact mod en approved baseline.
Hvert punkt er evidens for et angivet requirement. Intet punkt etablerer regulatory acceptability alene.
Start med intended use og risiko
Før du skriver tests, dokumentér:
- intended use for computersystemet;
- regulated records og signatures, hvis nogen;
- users, roles, interfaces og data flows;
- patient-, product-quality- og data-integrity risks;
- requirements og acceptance criteria knyttet til disse risici;
- supplier og component responsibilities; og
- change-, incident-, backup-, recovery-, retention- og decommissioning procedures.
Operativsystemimage er kun ét configuration item i det system.
Eksempel på afgrænset scenario
Eksemplet kontrollerer en syntetisk integrationstjeneste og lokal auditkonfiguration. Det hævder ikke, at EDC, LIMS, safety database eller Part 11-workflow er valideret.
{
"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"
}
}
]
}
]
}Brug kun syntetiske, ikke-følsomme testdata i delte build- og skærmfotosystemer. Et skærmfoto kan afsløre subject identifiers, credentials, notifikationer eller andet skrivebordsindhold. Definér kontroller for capture, redaction, access, retention, export og deletion, før du indsamler 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 hvor begrundet, 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.
Ommærk ikke en automatiseret event log eller screenshot-mappe som Part 11 audit trail. Part 11 audit-trail controls vedrører regulated record actions, retention, availability og integrity på tværs af det relevante system.
Change- og regressionsworkflow
- Vurder impact af den foreslåede change.
- Vælg tests ud fra risiko og berørte requirements.
- Byg et nyt immutable artifact; behold det tidligere approved artifact.
- Kør protocol i et controlled environment.
- Gennemgå failures og deviations uden at slette ugunstig evidens.
- Indhent required quality-, security-, business- og regulatory approvals.
- Deploy via change control og verificér production configuration.
- Overvåg drift og kør den testede recovery path ved behov.
OpenFactory kan forkorte evidence collection for trin, det faktisk automatiserer. Den regulerede organisation er fortsat ansvarlig for intended-use validation, procedural controls, data governance og den endelige release decision.