PLC usage in the Pharmaceutical industry
- Thread starter MCW
- Start date
Allen Nelson
Member
Are you sure you want to know about this?
The absolute honest answer is - I don't know, and neither does anyone else, regardless of what they tell you.
After that, there are several layers to your question, and I'll try to peel the onion. I'm no Part 11 expert, but my company does have several on staff, and I've talked with them, and done Part 11 work, so here goes:
First off, "Electronic Signatures". PLCs are not operator interfaces. Therefore, BY THEMSELVES, they cannot get an electronic signature from a human, because they don't talk with humans. They talk with SCADA/HMI, and SCADA/HMI talks with humans. Therefore, it falls on the duty of the SCADA/HMI to be "Part 11 Compliant".
Even with that, I'm fond of Intellution's (maker of the iFix SCADA) approach. Their software is not "Part 11 Complient" It is "Part 11 Capable". All the security, and data protection that they can chove into a package CANNOT be complient, unless the programmer implements it properly. There are lots of parts to Part 11. You need to address them ALL.
Second, "Electronic Batch Records". PLCs don't have too much memeory. They don't store lots of historical records. Usually, at most, they collect a days (perhaps as much as a weeks) worth of data, before being polled by a SCADA (which has things like hard drives to store lots of information.)
And even if you DID store multiple batch records (and I'm talking 3 to 7 YEARS worth of records - that's how long the FDA recommends keeping these types of records) on a PLC (excluding for a moment, soft PLCs, which might be considered PLC emulators running on a PC), there is the issue of data integrity.
One of the parts of Part 11 (my copy of 21 CFR is at work, so I can't quote it), states that there will be an audit trail associated with the electronic record, so that any alteration of the record can be traced back to who made it, when they made it, and what the new and old values were. And the audit trail must be secure from accidental or casual attempts at tampering. (It is acknowledged that a sufficiently skilled forger can alter an electronic file so that it cannot be detected. But the same holds true for the paper records that the electronic ones are replacing).
The best metaphor for how a Part 11 system should operate is the ATM. The transactions are secure, the operator has no access to the background processing. Within the bank, it takes TWO people to process the transction. The SysAdmin has the passwords to unlock the system (including the audit trail), and the Processor has the passwords to manipulate the data (but not the audit trail).
And there's questions that the FDA hasn't clarified yet. Take the concept of Tokens with electronic signatures. A secure system should use 2 tokens, a user name and a password (unless you've got a biometric system (now THAT might be able to interface with a PLC)). Each transaction that the operator performs must be "signed" and include the two tokens.
But here's the question: Do you have to have the operator enter BOTH tokens for each transaction, or can he be "logged in" the system, and just pass one token (the password) as an acknowledgement of a transaction (akin to putting initials on a form, instead of signing every line)? The FDA doesn't say. The pharmaceuticals aren't sure (and they're scared). The SCADA manufacturers are scambling (again, I think Intellution has done the best job - but that was as of 3 months ago - ancient history in the software biz).
In most systems that I saw (prior to Part 11), the operator entered a password, and he was logged in until he logged out - possibly not until next week when the supervisor would log in to get privileges that he needed (and then HE'D be logged in for weeks). And passwords were well known (I've often asked the line operators for the SuperUser password so I could get in and make changes - they know it about 50% of the time).
That's the tip of the iceberg. Each pharmaceutical has it's own take on the exact interpretation of the regulation (which just adds to the joy, don'tcha know).
But I think, the bottom line it - NO PLC can be Part 11 complient.
The absolute honest answer is - I don't know, and neither does anyone else, regardless of what they tell you.
After that, there are several layers to your question, and I'll try to peel the onion. I'm no Part 11 expert, but my company does have several on staff, and I've talked with them, and done Part 11 work, so here goes:
First off, "Electronic Signatures". PLCs are not operator interfaces. Therefore, BY THEMSELVES, they cannot get an electronic signature from a human, because they don't talk with humans. They talk with SCADA/HMI, and SCADA/HMI talks with humans. Therefore, it falls on the duty of the SCADA/HMI to be "Part 11 Compliant".
Even with that, I'm fond of Intellution's (maker of the iFix SCADA) approach. Their software is not "Part 11 Complient" It is "Part 11 Capable". All the security, and data protection that they can chove into a package CANNOT be complient, unless the programmer implements it properly. There are lots of parts to Part 11. You need to address them ALL.
Second, "Electronic Batch Records". PLCs don't have too much memeory. They don't store lots of historical records. Usually, at most, they collect a days (perhaps as much as a weeks) worth of data, before being polled by a SCADA (which has things like hard drives to store lots of information.)
And even if you DID store multiple batch records (and I'm talking 3 to 7 YEARS worth of records - that's how long the FDA recommends keeping these types of records) on a PLC (excluding for a moment, soft PLCs, which might be considered PLC emulators running on a PC), there is the issue of data integrity.
One of the parts of Part 11 (my copy of 21 CFR is at work, so I can't quote it), states that there will be an audit trail associated with the electronic record, so that any alteration of the record can be traced back to who made it, when they made it, and what the new and old values were. And the audit trail must be secure from accidental or casual attempts at tampering. (It is acknowledged that a sufficiently skilled forger can alter an electronic file so that it cannot be detected. But the same holds true for the paper records that the electronic ones are replacing).
The best metaphor for how a Part 11 system should operate is the ATM. The transactions are secure, the operator has no access to the background processing. Within the bank, it takes TWO people to process the transction. The SysAdmin has the passwords to unlock the system (including the audit trail), and the Processor has the passwords to manipulate the data (but not the audit trail).
And there's questions that the FDA hasn't clarified yet. Take the concept of Tokens with electronic signatures. A secure system should use 2 tokens, a user name and a password (unless you've got a biometric system (now THAT might be able to interface with a PLC)). Each transaction that the operator performs must be "signed" and include the two tokens.
But here's the question: Do you have to have the operator enter BOTH tokens for each transaction, or can he be "logged in" the system, and just pass one token (the password) as an acknowledgement of a transaction (akin to putting initials on a form, instead of signing every line)? The FDA doesn't say. The pharmaceuticals aren't sure (and they're scared). The SCADA manufacturers are scambling (again, I think Intellution has done the best job - but that was as of 3 months ago - ancient history in the software biz).
In most systems that I saw (prior to Part 11), the operator entered a password, and he was logged in until he logged out - possibly not until next week when the supervisor would log in to get privileges that he needed (and then HE'D be logged in for weeks). And passwords were well known (I've often asked the line operators for the SuperUser password so I could get in and make changes - they know it about 50% of the time).
That's the tip of the iceberg. Each pharmaceutical has it's own take on the exact interpretation of the regulation (which just adds to the joy, don'tcha know).
But I think, the bottom line it - NO PLC can be Part 11 complient.
Terry Woods
Member
- Join Date
- Apr 2002
- Posts
- 3,170
All I can say is, I've written PC-based, PLC-Emulating programs for packaging in the Pharmaceutical industry. It was a BIG company in Roanoak, Virginia. I can't remember who it was.
This process was for the container, not the product. The process involved finishing the container seal surface.
That's all I can say at this point... I don't know the spec you are referring to.
This process was for the container, not the product. The process involved finishing the container seal surface.
That's all I can say at this point... I don't know the spec you are referring to.
Allen Nelson
Member
Terry Woods said:
How long ago was that? Part 11 was added to 21 CFR (Code of Federal Regulations) in about 1999 or so.
Did you have to go through the "validation" process. If yours was a packaging line, then it was probably under cGMP and needed to (although, even as with Part 11, they might not of thought it was, at the time). But I'm seeing LOTS of work for HVAC systems needing to be retro-validated because they are considered GMP ("ANYTHING that can affect the quaility of the product....").
If you've done validation (and you'd know it if you had), then you've touched on at least 21 CFR (although cGMP is a different standard, but the goal is the same. Be as sure as you can that this pill is and does exactly what it's supposed to be and do).
paraffin power
Member
I think Allen's reply was spot on.
PLC can't be part 11 compliant, it is the job of the SCADA (or whatever)
We produce a lot of packaging machines for the pharmaceutical industry with either a SCADA type hmi or something more simple like a Siemens TP170, Bradley PanelView etc.
Both support the use of passwords, but not username and password, but our customers have taken an approach that this is adequate. (No logging of data or electronic signatures)
Following on, our machines are subject to rigorous validation. Ranging from 2000 compliant(?) to 'if this sensor fails, and there's a full moon and I had *** last night then what happens to that product'
Moan.
When customer comes for acceptance, they have an expert in every field (mechanical, validation, controls, QA, project etc) and I'm meant to bluff them all at my end. Should I ask my boss for a payrise?
PLC can't be part 11 compliant, it is the job of the SCADA (or whatever)
We produce a lot of packaging machines for the pharmaceutical industry with either a SCADA type hmi or something more simple like a Siemens TP170, Bradley PanelView etc.
Both support the use of passwords, but not username and password, but our customers have taken an approach that this is adequate. (No logging of data or electronic signatures)
Following on, our machines are subject to rigorous validation. Ranging from 2000 compliant(?) to 'if this sensor fails, and there's a full moon and I had *** last night then what happens to that product'
Moan.
When customer comes for acceptance, they have an expert in every field (mechanical, validation, controls, QA, project etc) and I'm meant to bluff them all at my end. Should I ask my boss for a payrise?
PLCs and 21 CFR Part 11
Just looking at the PLC part of this the PLC software is considered an record under on of the FDA rulings, (cant remember which) and therefore under the predicate rule the PLC Software becomes an electronic record.
PLC Software is not compliant for a number of reasons including the fact that (as of yet) no manufacturer has a yet developed an electronic audit trail for changes to the PLC Software.
PLC's and for that matter DCS's are used extensivley within the Pharma Industry for the automated manufactuing process. Many without a SCADA or even HMI, interfacing simply to the operator with lamps and switches.
Without the technology and the fact that drugs must still be manufactured the current controls are based around validation, security and change control. All systems which are GxP significant must be validated (GAMP provides a template). Security procedures should be established to restrict access to the PLC Code, this can be take a number of steps, reducing access to PLC Programming Software, Tamper Evident Labels over programming ports etc. Software should be routinely checked to ensure that unauthorised changes to the software have not been made. Finally creating a paper based audit trail via Change Control Procedures, maintaining previous versions of the software (for inspection) can improve compliance.
To date I have not seen any 483 warning letters from the FDA for the use of PLCs. However systems without adequate controls (as detailed above) are often written up.
SCADA Systems and HMI's are a totaly different matter and must be assessed as to the functions.
Hope this is of help
Just looking at the PLC part of this the PLC software is considered an record under on of the FDA rulings, (cant remember which) and therefore under the predicate rule the PLC Software becomes an electronic record.
PLC Software is not compliant for a number of reasons including the fact that (as of yet) no manufacturer has a yet developed an electronic audit trail for changes to the PLC Software.
PLC's and for that matter DCS's are used extensivley within the Pharma Industry for the automated manufactuing process. Many without a SCADA or even HMI, interfacing simply to the operator with lamps and switches.
Without the technology and the fact that drugs must still be manufactured the current controls are based around validation, security and change control. All systems which are GxP significant must be validated (GAMP provides a template). Security procedures should be established to restrict access to the PLC Code, this can be take a number of steps, reducing access to PLC Programming Software, Tamper Evident Labels over programming ports etc. Software should be routinely checked to ensure that unauthorised changes to the software have not been made. Finally creating a paper based audit trail via Change Control Procedures, maintaining previous versions of the software (for inspection) can improve compliance.
To date I have not seen any 483 warning letters from the FDA for the use of PLCs. However systems without adequate controls (as detailed above) are often written up.
SCADA Systems and HMI's are a totaly different matter and must be assessed as to the functions.
Hope this is of help
Similar Topics
Hi everyone
I am using Winproladder software for programming FATEK FBs PLCs and in programming, we often use Timers for activation of the...
Dear all,
I have some query about the use of Timers in Fatek PLC Module by using WinproLadder Software. I am trying to use one timer instance in...
Is it possible to trend PLC memory usage in the historian? We are getting few faults on the compactlogix controllers. They are old running V17. I...
I would like to create an AOI which throw me an alarm when cpu usage is more than 75%. Since GSV doesn not support this functionality I am...
Hello All,
I'm looking to receive data remotely from a site, and was looking to get connectivity to the site via a 3g connection. Does anyone...