Hello good people of the world! Data integrity is an important topic in the information age and has come into focus for regulatory agencies as more and more parts of manufacturing processes become automated. Agencies know that data integrity can directly affect drug quality.
This post covers the MHRA (UK) guidance on data integrity version 2, released March, 2015, which can be found here.
The guidance document defines data integrity as “the extent to which all data are complete, consistent, and accurate throughout the data lifecycle.”
Of course, the concept of data integrity also applies to paper records, but it is the novelty and complexity of computerized systems that makes data integrity applied to electronic records a subject worthy of discussion and exploration. While we’ve had generations to get used to maintaining paper records, electronic records are relatively new, and the best practices for assuring data integrity may still be maturing.
Raw electronic data typically comes from one of four sources:
- Direct data capture via instrument/device output (e.g. temperature transmitter, valve actuator feedback, etc.)
- Capture of data stream from another computerized system (e.g. electronic chart recorder, electronic scale, etc.)
- Automated import of data from another computerized system (e.g. event or alarm log, recipe, etc.)
- Manual entry via HMI (Human-Machine Interface)/OIT (Operator Interface Terminal)
Each of these methods is subject to qualification/validation. Method #4 is a unique case in that is may require secondary verification by a separate operator or, in some cases, a supervisor, for critical data or any case where data is being transcribed from another location (electronic or paper-based).
The rules that apply to paper-based data also apply to electronic data. Data must be (ALCOA):
- Attributable – it must be clear who made the entry
- Legible – it must be clear what the entry is
- Contemporaneous – the data must be recorded at the time of action/event
- Original – the data must be raw
- Accurate – the data must be correct, complete, and accurate
In order to maintain electronic data integrity, the following concepts are applied:
- Access Control
- Each user shall be uniquely identified
- Password controls shall be adequate
- User’s shall have only the permissions necessary to perform their job functions
- A list of current and historic users shall be maintained
- Change Control
- Changes to the system shall be controlled and only available to authorized users
- Training
- All users shall have the training necessary to perform their job functions
- Record and Retain Data
- Required data shall be recorded ALCOA and retained through the lifecycle
- Audit Trail
- Modifications to raw data shall be recorded in an audit trail, with who made the change, the original data, the modified data, when the change was made, and why
- The audit trail may also record system events, transactions, logins, etc.
- Review Data
- Data shall be available for review
- Backup Data
- Data shall be backed up to ensure redundancy and eliminate any single point of failure
Originally, audit trails only captured changes to raw data, the way a line-out would capture a correction on a paper record. Now, much more may be expected of the audit trail, and audit trail functionality may consist of multiple system reports, for example record of logins (attempted and successful), application transactions, any change to application data or metadata. In addition, the audit trail report is expected to:
- Record the original and modified values of any data change with user and date/time stamp
- Not be editable
- Be viewable and understandable by end-users (that means no foreign key values or other coded/hex values please!)
- Be reviewed as part of batch release
- Be regularly backed up
Some more considerations around your audit trail:
- Do administrators have the ability to modify or disable the audit trail? If yes, how to control the added risk
- Does the audit trail contain enough data to allow robust data review?
- Do the items in the audit trail include enough relevant items that will permit the reconstruction of the process or activity?
- What is the process for audit trail review?
Some more considerations around your user access procedures:
- Is there a procedure that describes how access is granted to a user, defines each user group, and their access levels?
- Is user access granted only after a documented training has been completed?
- Do users have only access rights appropriate for their job role (tied to SOP ideally)?
- Is it clear what rights to a specific individual (e.g. via user rights report)?
- Is historical information regarding user access levels available?
- Are shared logins or generic user access accounts used? Should avoid these!
- Is administrator access restricted to the minimum number of people required? Don’t want excessive numbers of admins!
- Is the generic administrator account available for use? Don’t allow this!
How do you assure data integrity in your organization?
Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!
Mike Williamson Validation 