Skip to content

Clause 7.11: Control of data and information management

Validation of software before use and after changes, data integrity and protection, and what the AccreditBook validation pack provides.

Screen: Settings Clause 7.11 Updated

What the clause asks for

Clause 7.11 requires the laboratory to have access to the data and information it needs to perform its activities. A laboratory information management system, in the standard’s broad sense, includes any computerized or non-computerized system used to collect, process, record, report, store or retrieve data, so a system that holds your equipment, PT and audit records falls within it.

The main requirements:

  • the system is validated for functionality, including the proper functioning of interfaces, before introduction, and changes are authorized, documented and validated before implementation (7.11.2),
  • the system is protected from unauthorized access, safeguarded against tampering and loss, operated in an environment that complies with supplier or laboratory specifications, maintained in a way that ensures data integrity, and system failures and corrective actions are recorded (7.11.3),
  • when the system is managed or maintained off-site or through an external provider, the laboratory ensures the provider complies with the applicable requirements (7.11.4),
  • instructions, manuals and reference data are readily available to personnel (7.11.5),
  • calculations and data transfers are checked in an appropriate and systematic manner (7.11.6).

Commercial off-the-shelf software in general use within its designed application range can be considered sufficiently validated, but many assessors still expect a short record showing what you checked for your intended use.

What assessors sample

Assessors ask what software holds or produces your quality records, how you know it does what you rely on it to do, who can change data, and how changes to the software reach you. Common findings: no validation record at all for a cloud tool, and no evidence of reviewing updates.

The AccreditBook validation pack

Every tagged release of AccreditBook produces a validation pack:

  1. A requirements specification in which every function has an id, for example REQ-EQ-003 for the next-due calculation, and names the tests that cover it.
  2. Test evidence generated from the automated test suite for that release: every test, the requirements it covers, pass or fail, the commit and the run date.
  3. A traceability matrix from requirement to tests. A release is blocked if any requirement has no passing test.
  4. Release notes listing what changed and which requirements it touched.
  5. The change control procedure: how a change is proposed, reviewed, tested, deployed and rolled back.
  6. An infrastructure and backup statement: hosting region, encryption, backup schedule and restore drill log.
  7. A cover template on which your laboratory records its intended use, the version validated, who reviewed it, and signs.

The pack is evidence for your validation, not a substitute for it. Your laboratory remains responsible for validating AccreditBook for its intended use and for reviewing changes before relying on them. The current pack is also placed in the validation folder of each assessor pack.

See Validation, Security and Assessor pack contents.

Not answered here? A person reads every message.

support@accreditbook.com