| by Douglas C. Fair
Does your statistical process control (SPC) software enable you to comply with Food and Drug Administration regulations? This can be a scary question for professionals responsible for satisfying federal requirements while identifying process improvement opportunities. Ultimately, compliance with FDA 21 CFR Part 11 is about data authenticity, traceability and integrity. Anyone viewing SPC data should be able to trust the information and know that the person's name on the record is truly the one who interacted with it.
In the world of SPC, manufacturers gather data to identify process and product improvements. SPC software developers must take into account complex manufacturing environments with shop floor computers that are shared among different users with potentially competing privileges.
For example, consider a situation where machine operators enter quality data into an SPC software system during their shift. At some time during that same shift, an auditor walks up to the same computer to view data. Two users are accessing the same computer for very different reasons. In this example, the SPC software must automatically prevent the auditor from erroneously entering data or modifying a record that he or she isn't authorized to change. How can this be done easily, while also allowing users to access the information that they uniquely need?
The answers aren't always apparent, but to properly manage the FDA's regulations, your SPC software must be robust enough to stand up to an FDA audit, and be able to quickly generate reports to satisfy internal and regulatory partners.
By focusing on these two items, it's possible to discern whether SPC software can appropriately support the stringent requirements of FDA 21 CFR Part 11.
Is your SPC system robust? It must have a set of security features that are flexible enough to manage situations like the one described above. It must also manage multiple users with different privilege levels while simultaneously eliminating security breaches.
Therefore, an SPC system is robust when it has superb password security, traceability and change history, and privilege discrimination.
Imagine that someone hacks into your banking institution's computing system and accesses social security numbers and passwords. This situation could be devastating to all of the bank's customers and to your financial situation specifically. It could threaten the very existence of the bank itself.
If a breach of your SPC software system occurred, it could put your company in jeopardy while holding certain people accountable. Such a breach could affect your company's finances in the form of fines, fees and bad press. To prevent this situation, the SPC system should have strict requirements for how passwords are managed. Here are a few considerations when evaluating an SPC system's password features:
• Passwords must be secret, and users must be uniquely identified . To access SPC software, the user typically must enter a login name and a separate password. These two words must uniquely identify the user.
• Passwords must be encrypted. Passwords must not be readable by anyone accessing the system, and all passwords must be encrypted before being saved in the software.
• Passwords must have a minimum length. A minimum password length must be enforced by the SPC system. Too short a password makes it easy to decipher, and a long password is more difficult to remember. Typical minimum password length should be between six and eight characters.
• Passwords must be changed periodically. SPC systems should specify a maximum password age so that passwords automatically expire. Once the password has expired, users should be able to change their passwords before they're once again granted access to the system. A typical maximum password age is 30 days.
• Password recycling must be prevented. SPC software must prohibit users from switching between two or three favorite passwords during password changes. A good practice is to inhibit the reuse of previous passwords for six to 12 months.
Traceability refers to who did what, but it encompasses more than just this basic information. Where traceability is concerned, an SPC system must be able to automatically trace and track access to the system, the number of times users have attempted to login, and other items. Here are a few traceability issues that your SPC system must address:
• Track who did what. The SPC system must be able to automatically identify, at a minimum, the user, time and date for any data entry or record modification. Modifications might include edits, data additions, changes to specification limits or creation of control limits. Regardless of the action, all changes and additions should be tracked. If your software allows deletions, those data should still be retained in the database and flagged with the person who deleted it along with the time and date.
• Limit attempts to access the system. After repeated unsuccessful attempts to gain system access, users' accounts should be locked and their passwords revoked. This security measure prevents someone from trying to guess another person's password. After an account has been locked, the system should automatically require the user to create a new password.
• Change history. Changes to critical records must be tracked with all the necessary details.
• Require "reason for change" codes . When an SPC system record is changed, the user must identify a reason for the change. User-specific notes should accompany the selected reason code to allow for more detailed data surrounding the record change.
• Maintain a log of all login attempts. The SPC system should log any and all login attempts, whether successful or not.
• Maintain a log of all security violations . The system should create and maintain a log of security violations by individual users.
• Track unused accounts and close them. If a user's account remains inactive for a period of time, the account should be automatically deactivated.
When a user logs in, the system should be able to automatically identify what the user can and can't do, regardless of where the user signs in or what computer he or she is using.
• Limit access based on needs. Security privileges should be appropriate to the individual's function. Data entry, edit and delete privileges should be based upon the user and his or her organizational function. For example, a shop floor operator should be able to enter data but not change specification limits. Likewise, a quality manager might be allowed to create control limits but be precluded from data entry, while a manager may be allowed only data-viewing privileges.
• Track user privileges no matter where the user is. Privileges, security codes and user passwords should be stored in a database so that no matter where the users are or what computer they use, their unique security profiles will be enforced.
• Allow group and individual privileges . Privileges should be flexible enough to allow individuals to inherit group privileges (e.g., those applied to all quality engineers, managers or operators), yet apply unique privileges at the user level. This allows users access to group privileges while applying custom privileges to certain individuals with special needs.
• Automatically force logins for data entry and data saving. By doing so, shared computers can prevent other users from entering or modifying data when another person is already logged in.
Can you quickly generate the reports needed to satisfy your most demanding internal and regulatory partners?
Any SPC system should be able to generate control charts, histograms, box-and-whisker plots, and assorted statistical analyses, and it must also provide critical traceability reports for managers, auditors and the FDA. Even if a system is robust enough to manage access and traceability, it must also generate relevant traceability reports for an auditor to find it acceptable.
Reports that should be supported in any SPC software include:
• Change history reports. Any change to existing records (such as a data edit, or a modification of specification limits or control limits) should be retained in the database and included in a change history report. These reports should highlight any and all changes made to product data and records related to information an auditor might require. For example, if an auditor needs to evaluate a particular product code, the original data should be shown along with the values that were edited; the reason for change codes; and the times, dates and users who performed the modifications.
• Metadata. Reports should include complete information on the data set (i.e., metadata) so that the report can be regenerated at any time.
• Lot genealogy reports . Some manufacturers track lot numbers from incoming goods through work in process, all the way to finished-good lot numbers. SPC software should be able to track all lot numbers using a "tree view" of data. This allows users to view where received lot numbers were used in the manufacturing process. Additionally, a finished lot number could be selected, and the SPC software should identify the specific component lots and received lots that were used in its manufacture. Lot genealogy should provide companies with critical information necessary to reduce the number of held lots because of a failure, while allowing managers to pinpoint reasons for recalls or product failure. Finally, important statistical data should be viewable in the genealogical reports.
• Violation reports. SPC software should allow users to visually report violations, assignable causes, corrective actions and events.
• Precision reports. SPC software should allow precision reporting, easily providing auditors with views of the most detailed, mundane information they need to see. Any data should be visible on a chart. That includes the ability to compare and contrast multiple part numbers and processes on the same chart--even if the specification limits are different. This means that normalization techniques must be supported to allow fair comparisons between different part numbers. Additionally, look for SPC software products where each chart is a query, and the query is easily changed. The best SPC products allow any data in the database to be selected, easily identified and sorted for any field or combinations thereof.
Selecting a comprehensive SPC software product is difficult enough, but selecting one that allows you to easily satisfy FDA 21 CFR Part 11 requirements can be a daunting task. If you look closely, you'll find the telltale signs of a superb SPC package: sophisticated password security features, full record traceability and excellent privilege discrimination combined with reporting features that auditors look for. The next time you have an audit, don't sweat it. Instead, spend a little extra time finding the most robust SPC software, and you'll be able to relax, knowing that the authenticity, traceability and integrity of your data are certain.
Note: For more information about this topic and a case study from an FDA-regulated manufacturer, register for a Webinar hosted by the author at www.infinityqs.com/webinar .
As vice president of statistical applications at InfinityQS International Inc., Douglas C. Fair helps clients understand statistical methods and implement InfinityQS software in diverse environments and challenging situations.
Fair has co-authored two books on statistical methods: Innovative Control Charting (ASQ Quality Press, 1997) and Principles and Methods of Quality Management in Health Care (Jones and Bartlett Publishing, 2000). He is a bimonthly columnist for Quality Digest's QualityInsider ( qualitydigest.com/qualityinsider ).
|
