Evidence-oriented тестування для regulated research systems

OpenFactory can automate bounded infrastructure and application checks for contract research organization. It does not determine FDA compliance, validate entire computerized system automatically, or replace regulated organization quality system and accountable approvals.

21 CFR Part 11  applies to specified electronic records and signatures and includes controls beyond operating-system image: system validation, record protection and retrieval, access and authority checks, time-stamped audit trails, training, policies, documentation controls, signature requirements. Applicable predicate rules and intended use must be established by qualified legal, regulatory, quality personnel.

FDA current Computer Software Assurance guidance  describes risk-based approach for production and quality-management-system software. Teams should determine applicability to system and context rather than treating generic test count as validation.

What OpenFactory evidence can support

• exact recipe and source provenance for image build;
• package, service, file, port, command assertions in booted guest;
• bounded GUI and screenshot evidence where supported assertion runs;
• per-run timestamps, output, artifact identifiers;
• repeatable negative and recovery tests; and
• comparison of new artifact against approved baseline.

Each item is evidence for stated requirement. None establishes regulatory acceptability on its own.

Start with intended use and risk

Before authoring tests document:

1. intended use of computerized system;
2. regulated records and signatures, if any;
3. users, roles, interfaces, data flows;
4. patient, product-quality, data-integrity risks;
5. requirements and acceptance criteria tied to those risks;
6. supplier and component responsibilities; and
7. change, incident, backup, recovery, retention, decommissioning procedures.

Operating-system image is only one configuration item within that system.

Example bounded scenario

Example checks synthetic integration service and local audit configuration. Does not claim EDC, LIMS, safety database, or Part 11 workflow validated.

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

Use only synthetic, non-sensitive test data in shared build and screenshot systems. Screenshot can expose subject identifiers, credentials, notifications, unrelated desktop content. Define capture, redaction, access, retention, export, deletion controls before collecting.

Evidence packet

For each approved test run preserve:

• requirement and risk identifiers;
• test protocol and expected result;
• recipe revision, source commits, dependency inventory, image digest;
• environment and test-data identity;
• raw output, screenshots where justified, timestamps, runner version;
• deviations, failed steps, investigations, retest links;
• reviewer identity, decision, date; and
• traceability from requirement to evidence and release decision.

Do not relabel automated event log or screenshot folder as Part 11 audit trail. Part 11 audit-trail controls concern regulated record actions, retention, availability, integrity across applicable system.

Change and regression workflow

1. Assess impact of proposed change.
2. Select tests based on risk and affected requirements.
3. Build new immutable artifact; retain prior approved artifact.
4. Run protocol in controlled environment.
5. Review failures and deviations without deleting unfavorable evidence.
6. Obtain required quality, security, business, regulatory approvals.
7. Deploy through change control and verify production configuration.
8. Monitor for drift and execute tested recovery path when needed.

OpenFactory can shorten evidence collection for steps it actually automates. Regulated organization remains responsible for intended-use validation, procedural controls, data governance, final release decision.