This is NOT your usual article about data integrity. You should already know about the usual topics of ALCOA+, Data Lifecycle, Audit Trails and so on. If not, please read about them here.
This is a part-fiction/mostly real-life experience-sharing of data integrity as experienced by an IT system owner living through an FDA audit no less.
After more than 2 years of slogging through the green field (literally) site to manufacturing plant construction, the pre-commercial PPQ (process performance qualification) batches were completed successfully. This is a state-of-the-art, next-generation biomanufacturing facility, complete with as much automation as possible, for the industry.
As a key IT system owner of several key systems supporting manufacturing and QC labs, I beamed with pride as we successfully rolled out the grand vision of the overall IT architecture. We have all the advanced IT systems we could possibly get, including:
- Enterprise Resource Planning (ERP) system – for supply chain planning
- Manufacturing Execution System (MES) – for eBR (electronic batch records)
- Electronic Quality Management System – to manage changes and any non-conformances
- Online Document repository system – where all the latest SOPs were stored and on which training was based
Then came the US-FDA facility and product licensure audit. The atmosphere is intense amidst the buzzing in the Audit Preparation room. It was almost like I was preparing for this day for the whole of the last 2 years.
===
As part of the Audit support team, I was intently watching the screen to see what the scribe (the person taking notes about the proceedings in the audit room and sharing his/her screen while doing so) was writing, as the audit conversation flowed, using the various IT systems like the eBR (electronic Batch Records), Document Management system (for SOPs), and Deviation Management system (for non-conformances during manufacturing).
I am familiar with the IT systems since I was the system owner for a couple of them and my team helped to set up the layout of the computer desktops in the audit room. However, at this point, it was hard for me to follow, because either the scribe was confused, or the auditing train-of-thought was all over the place, like a scatterplot. The team seemed to be flipping in between the systems.
The nerve-wracking session for the IT systems walk-through finally ended and the good news was that there wasn’t any major or critical finding related to IT systems.
===
I spoke to one of the auditees (from the manufacturing team) over lunch to understand what happened during the session because I could not follow the notes by the scribe. The scribe had a tough job, for good reason. Read on…
It seems one of the auditors had noted an NC (non-conformance), which was reviewed the day before. As soon as the overview slide on how the various IT systems worked appeared, the auditor wanted to dive into exactly where and how the NC (noted the previous day) was reflected in the eBR. Thus, the auditee was literally searching for the specific eBR execution, showing the data recorded and the associated NC details. Once the eBR was confirmed, the team had to switch over to the Deviation Management system and show that the IDs recorded in both systems data were aligned. The auditor also made sure to verify that the date/time stamps in both systems supported that the data was recorded in a logical sequence and in a timely manner.
Of course, at this point, the auditor had a good idea of how the manufacturing team used both the systems, while ensuring that the data integrity was preserved!
Finally, the auditor wanted to look at the SOP to confirm whether what was verified and understood was as stated in the SOP. And thus, the team had to switch over to the Document Management system.
====
My understanding is that the auditor went away impressed with the manufacturing team’s confidence in using the systems and how data integrity of the manufacturing batch records was ensured across all the IT systems.
What are the lessons learnt?
Personally, this experience enforced my belief that data integrity issues picked up during the audit are just the symptoms of the underlying issues. For example, if the IDs of the NC (non-conformance) were not aligned across the systems, it would mean the failure of the underlying issue of non-adherence to SOPs. Thus, avoiding underlying issues is really about going back to the basics of ensuring good computer validation practices, strong staff training and adoption of computerised systems, adherence to SOPs and having the integrity to follow through on the above basics.
If you’d like us to help you understand your current situation about CSV, data integrity or audit readiness, please do contact us for a discussion at hello@nodeviation.com.
You can also visit our website for more information on our services.