I posted the following to the control.com forums. Let’s keep it going here.
I’m trying to find out all I can about 21CFR11. I’m working on implementing a system with FactorySQL and FactoryPMI that is 21CFR11 compliant.
Per this spec, it looks like a self certified standard. Thou shalt “use electronic signatures” and so on and so forth.
21CFR11 Spec from the FDA web site
Is anyone aware of actual implementation guidelines (ie use 128 bit encryption with such and such algorithm) or third party certification organizations/procedures that will verify your implementation?
Are there other useful sources of info? I’d be happy to hear what you have to say on 21CFR11.
Integrator, Microsoft Certified Systems Engineer
“Design simplicity cures engineered complexity”
Mar 31, 2006 10:58 am, by Jonas Berge
Do a web search on “21CFR11 validation” and pick somebody closest to you
To learn more about 21CFR11 take a look at chapter 10 of the book “Software for Automation: Architecture, Integration, and Security”. Preview, see contents, and buy online: www.isa.org/autosoftware
Learn fieldbus and Ethernet at your own pace: www.isa.org/fieldbuses
Learn OPC and automation software at your own pace: www.isa.org/autosoftware
Re: Let’s talk about 21CFR11
Mar 29, 2006 12:30 pm, by Walt Boyes
You should check the back issues of our sister magazine, Pharmaceutical Manufacturing… they have lots of data on validation and compliance issues. pharmamanufacturing.com
Editor in Chief
Blogging at Sound OFF! at controlglobal.com or direct at
555 W. Pierce Rd #301
Itasca, IL 60143
+1-630-467-1301 x 368
Re: Let’s talk about 21CFR11
Mar 30, 2006 12:16 am, by Paul Thomas
We just published a general update on Part 11. It may give you some good context for your search. You’ll notice at the very bottom of the page there are links to similar articles, including a white paper on software and one on validation.
pharmamanufacturing.com/arti … 6/029.html
E-newsletters: Pharma Track & Trace, PAT Insider, PM E-News
I would LOVE to see 21CFR-11 compliance in FactoryPMI.
We are getting more and more medical jobs that require this, and Rockwell has nothing decent for 21CFR-11. We are looking around for HMI packages that have support.
I personally hate 21CFR11. The requirements are vague and confusing. Clauses like “Validation of systems to ensure accuracy, reliability…”. What does that mean? To what standard and by whom? I read white papers from several of the top vendor’s products, and my interpretation was that their response wasn’t meeting the intent of many of the requirements. But in many of the cases it’s unclear how to answer the questions satisfactorily.
I wrote a similar white paper on using FactorySQL to create a 21CFR11 compliant application. Unfortunately many wickets are “It is the responsibility of the customer to…”, just like all the other vendors do. That’s all you can say to requirements that ensure that end users “have the education, training, and experience to perform their assigned tasks”.
The bottom line is that 21CFR11 compliance is mostly about implementing the software to the FDAs spec, and convincing yourself of that. It’s possible with FactoryPMI. If someone was creating a compliant app and ran into a problem that we couldn’t help you with, we would introduce a feature (probably a script function) to make it possible.
However, there is more or less that you can “pre-can” with 21CFR11 compliance. FactorySQL/PMI are very flexible, but weren’t designed specifically to cater to that. Expect a lot of work and planning before you begin to get it right. At this point I’d recommend using an appliance that’s designed for 21CFR11. I’d love to be able to cater toward it on our end, but at this point I can count how many serious 21CFR11 requests we’ve received on one hand.
[quote=“porksmash”]I would LOVE to see 21CFR-11 compliance in FactoryPMI.
We are getting more and more medical jobs that require this, and Rockwell has nothing decent for 21CFR-11. We are looking around for HMI packages that have support.[/quote]
My opinion differs slightly from nathans, although I agree for the most part.
The way I see it, FactorySQL / FactoryPMI are 21 CFR part 11 compliant, as is. Does this mean that running our unified installer on your server means its time to invite the FDA over for an inspection? No!. Why not? Because 21 CFR part 11 isn’t a compliance standard for HMI/SCADA design software. Its a compliance standard for HMI/SCADA project implementations. Those are two very different things. Can you design an HMI/SCADA implementation using our software that is 21 CFR part 11 compliant? Yes! Can you design one that isn’t compliant? Yes.
It seems to me that when people come to us and ask for “compliance”, I’m highly suspect that they haven’t actually read the spec themselves, and are just hoping to install a piece of software that will absolve them of any responsibility for knowing what 21 CFR part 11 is. Nathan - can we make that whitepaper that you put together public?
Just reviewed it, all is possible in FactoryPMI. Carl is right yet again. The ones that don’t sit well with me are:
11.10(a) - the part about the ability “to discern invalid or altered records”.
Using a hash function would satisfy the requirement. It does not, however, prevent a knowledgeable user with appropriate permissions from forging records. A combination of that and write only database permissions to the historical logging tables would satisfy me (we should add a hash function to the audit log). I would read the intent as using a public key crypto system - no vendor does this to my knowledge. It would impact system performance for little useful gain. The closest approach I saw was “storing it in a proprietary format”, which scratches the surface. There may be a better way to meet this requirement that isn’t coming to mind…
11.200(a)(3) - Two person integrity (attempted use of electronic signature by anyone other than genuine owner require collaboration of two or more individuals).
Some wacky versions of Unix and operating systems that NSA and security researchers tinker with support this kind of thing. Neither Windows nor Linux are compliant here (maybe possible with 3rd party apps, but I doubt it). This is possible to solve as a process issue. DoD is actually compliant here in that CAC (common access cards, your ID and the device used to log into the network, which contain your security certificate) are issued by separate people than network administrators. You could do the same. The key is to ensure that whoever deals with the biometrics/login media CAN NOT be a network administrator. Possible? Yes. Does anyone actually do it? Well…you tell me.
There may be other pesky requirements. All points are possible to satisfy with a combination of software/database/network implementation issues AND process/procedure. Solutions may be involved and expensive depending on how far you want to take your compliance. To be fair, this is probably the case with any vendor. Many end users that I’ve talked to have seen “21CFR11 Compliance” stamped on hardware/software products and decide that it’s on the vendor. I’ve never heard of what they look for in an actual FDA audit. I strongly doubt that a significant percentage of end users have verified compliance point for point using any platform/package. I know that a software/hardware package alone CANNOT satisfy all requirements. Ignorance is bliss??? Or maybe it’s a standard written by dreamy beaurocrats.
21cfr11.pdf (114 KB)
It does seem that 21CFR11 is mostly up to interpretation, and a LOT of standards like this are vague on purpose. What that purpose is I have no idea.
We usually go over with our customers what their specific requirements are for 21CFR11 (or any other standard). If you promise to build something that will get FDA approval, I think it is a mistake. If we promise to meet the customer’s specs, our job is very well defined and removes a lot of liability.
(also: resurrecting an ancient thread )