When is data data?

The following blog post is an excerpt from our Data Integrity & Data Science Newsletter. This excerpt was written by Monica Cahilly and published in August 2018. Click the link above to subscribe and receive future newsletters.

Question 1:  When is data data?

Answer... Data is 'data' at the time of the activity. When must data be recorded? At the time of the activity. In some instances, there have been mis-understandings or ‘blind spots’ in the application of Good Documentation Practices (also known as “ALCOA+” principles) to electronic records versus paper records. A common ‘blind spot’ that has increased data integrity risk and compromised the ability of data reviewers and Health Authorities to ‘completely and fully reconstruct the conduct of the GXP activity’ in original electronic data sets is the mis-conception that "electronic data is not GXP data until it is permanently recorded." This ‘blind spot’ also creates a double-standard, since if this principle were applied to paper records, it would (inappropriately) imply that data can be initially recorded in pencil (or held for indefinite periods in mental temporary memory) and does not become CGXP data until it is written in permanent ink. Most would agree that recording data to paper using 'disappearing ink' or in pencil or several days after the activity would be inconsistent with the 'Legibility' and 'Contemporaneous' requirements embodied in the ALCOA+ principles.


One way for us to view Part 11 is simply as providing the basic tenets of ALCOA+ or ‘Good Documentation Practices for Electronic Data.’ 21 CFR Part 11.10(f) encourages us to design our systems, (using technical controls, as well as procedural controls when necessary), to adequately address the CGXP requirement to record data contemporaneous with the GXP step or event and prior to the next step or event in a sequence of events, so that each step or event can be legibly and traceably reconstructed. However, when we believe that ‘electronic data is not data until saved to durable media’, we may incorrectly believe that it is compliant to perform multiple steps under one transaction, such as processing electronic data multiple times in temporary memory and over-writing each associated step or event and only saving the data associated with the final processing step or event. When this happens, example risk scenarios (such as ‘trial runs’, successive reprocessing of data, changes to and deletions of source data entries, and other potentially critical GXP actions) performed in temporary memory would not be visible in the stored data or in associated audit trails.

Other risk scenarios may include those whereby critical source GXP electronic data is generated in a source system with limited technical controls and persons may believe that the electronic GXP data in these more vulnerable environments (such as a mobile device) does not need to be considered GXP data until it arrives at a more robust environment (such as an Electronic Data Capture database system). However, this assertion forgets the (comforting) advice of Quality Risk Management principles to ‘do the best we can, recognizing we will never be perfect’ (my paraphrase ;) That is, we will always have residual risk and imperfections in our various environments relative to regulatory requirements and technical features that may be ideal. It is important that we not delude ourselves into believing that critical source GXP data in our more vulnerable environments doesn’t exist. Instead, if we ‘do the best we can’ to control the source GXP data in these environments (using a combination of technical and procedural controls) and then move the GXP data set to more robust environments in as timely a manner as possible, with appropriate verification checks, we may demonstrate ‘risk-based data governance across the end-to-end data process’. In such an example data flow, we may consider the critical source GXP electronic data in the more vulnerable environment (such as a mobile device) to be our ‘original records’ or ‘source data’ and the copy of this dataset that is transferred to the more secure database system (such as an EDC system / LIMS / MES-EBR / Data Historian / etc.) to be a ‘true and exact copy’—if we can demonstrate that our end-to-end data process governance and verification controls provide for the full reconstruction of the GXP data process. Specific attention should be paid to controls that prevent and detect the alteration, corruption, or deletion of the data in temporary memory or transient locations, including proper security and verification of the complete data flow.

Please refer to the (just released this week!) Technical Report #80 from Parenteral Drug Association on Data Integrity Management System for Pharmaceutical Laboratory, for more helpful clarification and examples on this topic (as well as others such as audit trails!). I highly recommend this reference not just for pharma GMPs, but also for laboratory data integrity in other GXP areas, including medical devices, GLPs and GCPs.