What you will learn if you follow this series
(in no particular order)
Concepts and Skills:
- Data Integrity Concepts and Requirements
- Technical controls for Data Integrity: Prevention and Observability
- What to look for when evaluating Instrument vendor software for 21CFR Part 11 compliance
- Computer Systems Validation
- Build tools and processes for your Laboratory to show that you have control over your data
- How to conduct Data Integrity investigations
Tools:
- Bash scripting
- Plethora of Linux command line tools
- Vim
- SIEM software, in particular Elastic Stack (Elasticsearch, Kibana and Beats)
- WSL, Git Bash, Powershell
This is the first post in hopefully a series of posts on data integrity compliance in a regulated industry, specifically an FDA regulated testing lab, but I'm sure the concepts have a board reach. These posts will focus more on the practical side, fleshing out the ideas that are in the guidance issued by the FDA formally known as 21CFRP11, Electronic Records; Electronic Security. I'm writing this first post with a broader audience in mind, who may or may not have a lab background.
Here's the cliff notes to the overarching problem:
At the end of the day, FDA guidelines are here to protect the consumer i.e. the patient. We want to make sure the products that we're making are safe and effective, and not adulterated. So how does 21CFRP11/Electronic Records/Security factor in?
I think the best way to explain this is with a practical example:
There's something in my industry known as "lot-release" testing. Often an analyst operates an instrument in accordance to what's known as a validated method (that's a whole other topic). Basically how to test a sample using an analytical technique (e.g. lab instrument), and how to process results from said technique to see if they meet pre-determined specifications per the method. If they do, they can move forward on the next steps of releasing the lot, and if not, an OOS (Out of Specification) occurs and investigations begin to find a root cause. As you can imagine, getting an OOS is not ideal: if it's a "true" OOS, it means the lot can't be released or if there's another explanation, it takes many resources to reconcile (time spent investigating, QA review, controlled retesting if applicable, explaining to stakeholders why their lot can't be released etc...). As you can probably guess, there could be motive for somebody in the process to do something nefarious to avoid the situation of an OOS.
Here's where Electronic Records Security comes in. Controls need to be in place to ensure the integrity of the results, i.e. Data Integrity. In order to protect the patient, we need to make sure that we can trust the results that we're getting and that means protecting the data from accidental and from not-so accidental modifications or deletions.
I've been working in the industry for over 15 years see this concept of data integrity evolve over the years. 15 years ago, most of the vendors for our instruments were creating their instrument control software and analysis software not with the regulated industry in mind, but with unregulated areas such as academic and pure R&D labs. Therefore, such needed features and concepts as audit trails and preventing data from being modified and deleted were never really considered. One exception was Empower software by Waters, often called the "Gold Standard" and ahead of the curve for years in terms of data integrity (it's not perfect, but it set the standard for many other venders to copy). Thankfully, a lot more of the other instrument vendors are catching their instrument control software "up-to-regs" the past 5 years or so, but it's still a new concept for most. As an aside, always take a vendor's claim of their software being "21CFRP11 Complaint" with a grain of salt, vendors are still playing catch up so always do your do diligence.
Phew, now that we got the introductory matters out of the way, in the next Lab DI Issue, I will hopefully get to more practical examples and the tools I have created and use day-to-day to meet 21CFRP11 guidelines.
Top comments (0)