Data integrity is at the root of a number of 483s issued this year by FDA. In some cases, firms have not been able to demonstrate their IT department’s ability to maintain documentation or to deal effectively with violations, said John Avellanet, CEO of the IT consulting firm Cerulean Associates LLC at a July 25 briefing sponsored by FDA Expert Briefings, Washington Information Source and FDA Info.
When considering whether your IT is truly addressing the need for data integrity, ask yourself the same questions you might ask about your driver’s license, he advises. Are you really the weight you say you are?
Data management is particularly difficult when clinical trial data are involved, since so much of the documentation is handled manually and there are so many transfer points.
|Graphic courtesy of Cerulean Associates LLC. All rights reserved.
PharmaManufacturing.com asked Avellanet about two of the allegations brought up in the Novartis legal complaint. We wondered whether other companies were experiencing any of the issues brought up in that document.
Here are his responses. (Please note that these comments reflect his general experience in the life sciences industry and have absolutely nothing to do with the case, the companies involved or their affiliates.)
PM — What are the essential steps required for validating drug safety data to ensure compliance with 21 CFR Part 11?
JA — Well, first, the short answer: There are roughly six core steps to ensure Part 11 compliance for clinical data:
- Determine ahead of time how the data are to be collected and stored at the clinical site, transmitted to the pharma company, and then stored and archived there.
- Test this process with some test data. Focus on loss of data integrity along the path – if you have four patients, during the process all the way through to pharma company archival, is patient three’s data lost…that kind of thing (obviously not that simplistic of a problem).
- Identify the risks at each of these points on the path, then identify the controls.
- Craft the procedures around these points and their controls.
- Verify that all is working as intended.
- Periodically audit and verify; making sure to report findings – good or bad – and then identify and implement (and monitor) any improvements or new controls.
It’s really a pretty straightforward process, isn’t it? Of course, human nature being what it is, we just can’t seem to leave well enough alone.
PM — What mistakes have you seen that pharma companies typically make in this area?
JA — Here are the top three:
- Lack of clarity and accountability for data integrity.
- To date, in every company I’ve dealt with, “someone else” is always held accountable for data integrity. Records Management says it’s an IT issue because IT holds the keys to the computer systems the data is stored on; IT says it’s a Records Management issue because they support systems, not information; the scientists claim that they are responsible for it and so they want to burn it on CD and stick it in their desk drawer because they just know IT won’t be able to find it down the road when the scientist might need it; management assumes that just like quality is accountable for the paper quality systems files (SOPs and the like), they must be accountable for the electronic stuff too…and so on, and so on, and so on.
- A division between R&D/preclinical data and the clinical and production data.
- From the FDA’s perspective, this makes no sense (think Quality by Design). From a cynical IT perspective and from a big consulting firm perspective, this makes it easy. Either you deal in the R&D world or you don’t. If you don’t deal with R&D/preclinical, it’s not your problem. One big pharma company is just beginning to grasp this nightmare; they hired a big consulting firm to handle all their data integrity issues world-wide … only to find out that the contract specifically excludes anything not already in clinical or in production (the big consulting firm doesn’t deal in R&D and preclinical). You can just imagine where this is heading.
- Inability to “translate” and achieve mutual understanding between functional units.
- More and more, I’m convinced this is one of the root causes of the problem. IT can’t understand Compliance, who can’t understand the scientists, who can’t understand Purchasing, who can’t understand senior management — you get the picture. It’s not that they all need to be in mutual agreement — they won’t be — but they do need to figure out how to be in mutual understanding, all marching to the same beat of the drum.
And there are others, of course: egos, competitive pressures, etc. Part of the 'others' depend on where within the company you’re looking. R&D often makes similar mistakes from company to company, but the same types of mistakes don’t occur from R&D to manufacturing within the same company.
PM — What is wrong with "hard coding" randomization codes. What impact would this have on results, and is the practice ever appropriate in some cases?