Thursday, December 23, 2010
Tuesday, December 21, 2010
LabWare LIMS Validation
Written by Kimberly Stanton - Associate, Validation Manager
As with all LIMS applications implemented in regulated environments, LabWare LIMS implementations must go through Validation prior to being released for routine use. LabWare implementations present unique challenges due to the ability for companies to create complex static data and work-flows, configure many different Sample Types, manage Standard/Reagents, manage Equipment/Instruments and the ability implement Stability Studies.
A Validation Plan for any LIMS implementation must be created to detail the Purpose, Scope, Deliverables, Responsibilities and the Acceptance Criteria to release the new LIMS application in the Production environment for routine use. If the LIMS application is to be installed in multiple sites with different hardware and potentially different requirements due different regulatory constraints or business work-flows it maybe necessary to create more then one Validation Plan.
User Requirements for a LabWare LIMS application should document the following to ensure a smoother implementation and Validation effort:
A Risk Assement(s) should be created to determine the Risk Level of the Requirements documented for the LIMS application. Risk Levels will help determine the level of testing that will need to be performed, Standard Operating Procedures that should be created and the level of Training that should be conducted. For example if there is Requirement that has a high Impact if it fails, high Probability that it will fail (mainly if it is a configured or customized part of the application) and Data Integrity could be impacted if the Requirement fails, testing activities would include Unit Testing, Operational Testing and Performance Testing. A corrective action for this Requirement could be User Training and Standard Operating Procedure development. If a Requirement is considered less of Risk if it fails, for example a core part of the LIMS application that satisfies the Requirement, testing may not even be necessary if the company implementing the application is satisfied with the level of testing LabWare performs on their core product, this would be verified during a Vendor Audit or minimal testing in the Operational Testing could be conducted.
Considerations regarding how to document Design/Configuration Specifications should be planned, since the complexity of a LabWare implementation can vary it may be helpful to create multiple Design/Configuration Specifications. For example a separate Design/Configuration Specifications for System Administration, Material Management, Lot Manager, Batch Manager, Project Manager, Sample Manager, Stability Manager and any applicable Interface functionality maybe a good approach. This approach will need special attention from the Project Manager since managing multiple documents can be very difficult.
One of the most overlooked pieces of a LabWare implementation is Static Data planning, configuration, verification and process testing. Static Data, depending on the Data’s complexity can be as or sometimes more complicated then the software piece of the LabWare implementation.
A Data Migration plan is key to Static Data planning, the plan should include references to all of the Static Data that will be implemented into LabWare, the instance (environment of the application) the Data will be configured in, how the configuration of the Static Data will be documented (separate Design Spec to include LIMS Basic Code design) and how the Data will be verified prior to being imported into the Validation (and Training environment if applicable) environment.
As with other LIMS and regulated applications implementation there should be multiple instances (environments) of the application one for software development, one for Static Data development, one for Validation testing, and the Production environment. It is also recommended that a Training environment is available, the Training environment should include verified Static Data for the new Users to train with. If it is not possible to obtain a Training environment one of the Development environments can be used as the Training environment as long as verified Data is available and software developments/updates are not taking place during training sessions.
The Validation and Production environments must go through an Installation Qualification. It is not required that the Development or Training environments go through an Installation Qualification, however, there must be adequate controls in place that ensures that any software changes or Static Data updates are implemented into all of the environments that are not required to go through IQ verification.
Since LabWare implementations can be very ‘data centric’ careful consideration must be made regarding what Static Data will be used during testing, if the Static Data has not been setup correctly any testing conducted has a potential of failing due to the Data. For example say a Product Specification that has Test Method that cannot be completed unless the Sample the Test Method is associated to is added to a Batch and the Quality Control Samples are not properly configured in the Batch Protocol has been selected for testing, the Sample will never be able to be Reviewed or Approved and the Lot the Sample is associated to cannot be approved if the Sample is not Approved the testing will fail.
Also, careful considerations on Requirements that may require special Static Data setup must be made. If a script requires the tester to verify that a Result entered on a Component of Test Method can be canceled, the Test Method selected for testing must have ‘Allow for Cancel’ option selected in order for the Result(s) to be canceled. If the configuration of the Static Data is not correct the script will fail.
Prior to formal Validation testing informal Unit Testing maybe considered, informal testing can minimize deviations either caused by system inconsistencies (nice way of saying Bug) or script errors. The Unit Testing can be conducted with Operational Qualification scripts created by the Validation team. This also provides the testers the opportunity to learn the system and become familiar with Test scripts that will be executed during the Operational Qualification.
The Operational Qualification testing phase for a LabWare implementation should include functional and negative testing much like any other Validation project, however, a LIMS OQ can be a large undertaking due to the complexity of the configurations of the Software and Static data, therefore, multiple testers (preferably from different Labs) should be used to reduce the amount of time it takes to execute OQ test scripts. Since the training of the testers on the new LabWare application maybe limited it is important for the OQ scripts to be created using a ‘point and click’ methodology, this will make the execution effort easier for the testers.
User Training must be conducted prior to the Performance Qualification testing phase of the LabWare implementation. Training tailored to the individual Labs may help be a better alternative as oppose to large Training sessions that include all users. Since the Labs using the new LIMS application will have different access to functionality of the system an overall Training session may confuse Users. For example let’s say if one Lab will primarily do their work in the Batch Manager and they do not have access to Lot Manager, Training on Lot Manager will be lost on them.
Performance Qualification testing can either be conducted in a simulated Production environment of the LabWare application or in a live Production environment depending on the confidence level of the implementation. If the Performance Qualification is conducted in a simulated Production environment it recommended that Performance Monitoring testing phase is conducted once the application is considered approved for routine use. Critical business/regulatory processes and Products/Testing for all Laboratories involved with the new LabWare application should be included in any Performance Qualification testing phase to ensure the new LIMS application is meeting all business and regulatory needs.
A Traceability Matrix is recommended to ensure testing coverage, corrective actions for non testable requirements and/or reasoning for lack of testing for all User Requirements documented for the LabWare LIMS implementation. The Traceability Matrix will also trace Configuration Requirements and possibly Standard Operating Procedures where system Configuration Requirements cannot satisfy a User Requirement.
There are many points to consider when implementing a LabWare LIMS application; this blog just highlights some of major components to ensure a successful implementation. We sincerely hope that the information presented is helpful.
As with all LIMS applications implemented in regulated environments, LabWare LIMS implementations must go through Validation prior to being released for routine use. LabWare implementations present unique challenges due to the ability for companies to create complex static data and work-flows, configure many different Sample Types, manage Standard/Reagents, manage Equipment/Instruments and the ability implement Stability Studies.
A Validation Plan for any LIMS implementation must be created to detail the Purpose, Scope, Deliverables, Responsibilities and the Acceptance Criteria to release the new LIMS application in the Production environment for routine use. If the LIMS application is to be installed in multiple sites with different hardware and potentially different requirements due different regulatory constraints or business work-flows it maybe necessary to create more then one Validation Plan.
User Requirements for a LabWare LIMS application should document the following to ensure a smoother implementation and Validation effort:
- All applicable Regulatory requirements
- System Administration requirements
- Multiple Site requirements if applicable
- Laboratories that will be utilizing the new LIMS application
- User Roles that will need to be implemented
- All Sample Types that will need to be implemented
- Work-flows to include Lots, Samples, Projects, Batches and Stability as applicable
- Test Methods functionality must be documented, however, since the amount of Test Methods that will need to be documented will vary, the use of an Appendix to the URS or a reference to Data Migration plan may be considered
- Product Specification functionality must also be documented and similar to Test Methods mentioned above if there are many Product Specifications to be implemented an Appendix or Data Migration plan reference may be considered
- Reports to include Certificate of Analysis, Standard and Reagents, Stability Results, and any other applicable reports
- Any Interface requirements such as Instruments, SAP, TrackWise, etc.
- Standard Operating Procedures applicable to the LIMS implementation
A Risk Assement(s) should be created to determine the Risk Level of the Requirements documented for the LIMS application. Risk Levels will help determine the level of testing that will need to be performed, Standard Operating Procedures that should be created and the level of Training that should be conducted. For example if there is Requirement that has a high Impact if it fails, high Probability that it will fail (mainly if it is a configured or customized part of the application) and Data Integrity could be impacted if the Requirement fails, testing activities would include Unit Testing, Operational Testing and Performance Testing. A corrective action for this Requirement could be User Training and Standard Operating Procedure development. If a Requirement is considered less of Risk if it fails, for example a core part of the LIMS application that satisfies the Requirement, testing may not even be necessary if the company implementing the application is satisfied with the level of testing LabWare performs on their core product, this would be verified during a Vendor Audit or minimal testing in the Operational Testing could be conducted.
Considerations regarding how to document Design/Configuration Specifications should be planned, since the complexity of a LabWare implementation can vary it may be helpful to create multiple Design/Configuration Specifications. For example a separate Design/Configuration Specifications for System Administration, Material Management, Lot Manager, Batch Manager, Project Manager, Sample Manager, Stability Manager and any applicable Interface functionality maybe a good approach. This approach will need special attention from the Project Manager since managing multiple documents can be very difficult.
One of the most overlooked pieces of a LabWare implementation is Static Data planning, configuration, verification and process testing. Static Data, depending on the Data’s complexity can be as or sometimes more complicated then the software piece of the LabWare implementation.
A Data Migration plan is key to Static Data planning, the plan should include references to all of the Static Data that will be implemented into LabWare, the instance (environment of the application) the Data will be configured in, how the configuration of the Static Data will be documented (separate Design Spec to include LIMS Basic Code design) and how the Data will be verified prior to being imported into the Validation (and Training environment if applicable) environment.
As with other LIMS and regulated applications implementation there should be multiple instances (environments) of the application one for software development, one for Static Data development, one for Validation testing, and the Production environment. It is also recommended that a Training environment is available, the Training environment should include verified Static Data for the new Users to train with. If it is not possible to obtain a Training environment one of the Development environments can be used as the Training environment as long as verified Data is available and software developments/updates are not taking place during training sessions.
The Validation and Production environments must go through an Installation Qualification. It is not required that the Development or Training environments go through an Installation Qualification, however, there must be adequate controls in place that ensures that any software changes or Static Data updates are implemented into all of the environments that are not required to go through IQ verification.
Since LabWare implementations can be very ‘data centric’ careful consideration must be made regarding what Static Data will be used during testing, if the Static Data has not been setup correctly any testing conducted has a potential of failing due to the Data. For example say a Product Specification that has Test Method that cannot be completed unless the Sample the Test Method is associated to is added to a Batch and the Quality Control Samples are not properly configured in the Batch Protocol has been selected for testing, the Sample will never be able to be Reviewed or Approved and the Lot the Sample is associated to cannot be approved if the Sample is not Approved the testing will fail.
Also, careful considerations on Requirements that may require special Static Data setup must be made. If a script requires the tester to verify that a Result entered on a Component of Test Method can be canceled, the Test Method selected for testing must have ‘Allow for Cancel’ option selected in order for the Result(s) to be canceled. If the configuration of the Static Data is not correct the script will fail.
Prior to formal Validation testing informal Unit Testing maybe considered, informal testing can minimize deviations either caused by system inconsistencies (nice way of saying Bug) or script errors. The Unit Testing can be conducted with Operational Qualification scripts created by the Validation team. This also provides the testers the opportunity to learn the system and become familiar with Test scripts that will be executed during the Operational Qualification.
The Operational Qualification testing phase for a LabWare implementation should include functional and negative testing much like any other Validation project, however, a LIMS OQ can be a large undertaking due to the complexity of the configurations of the Software and Static data, therefore, multiple testers (preferably from different Labs) should be used to reduce the amount of time it takes to execute OQ test scripts. Since the training of the testers on the new LabWare application maybe limited it is important for the OQ scripts to be created using a ‘point and click’ methodology, this will make the execution effort easier for the testers.
User Training must be conducted prior to the Performance Qualification testing phase of the LabWare implementation. Training tailored to the individual Labs may help be a better alternative as oppose to large Training sessions that include all users. Since the Labs using the new LIMS application will have different access to functionality of the system an overall Training session may confuse Users. For example let’s say if one Lab will primarily do their work in the Batch Manager and they do not have access to Lot Manager, Training on Lot Manager will be lost on them.
Performance Qualification testing can either be conducted in a simulated Production environment of the LabWare application or in a live Production environment depending on the confidence level of the implementation. If the Performance Qualification is conducted in a simulated Production environment it recommended that Performance Monitoring testing phase is conducted once the application is considered approved for routine use. Critical business/regulatory processes and Products/Testing for all Laboratories involved with the new LabWare application should be included in any Performance Qualification testing phase to ensure the new LIMS application is meeting all business and regulatory needs.
A Traceability Matrix is recommended to ensure testing coverage, corrective actions for non testable requirements and/or reasoning for lack of testing for all User Requirements documented for the LabWare LIMS implementation. The Traceability Matrix will also trace Configuration Requirements and possibly Standard Operating Procedures where system Configuration Requirements cannot satisfy a User Requirement.
There are many points to consider when implementing a LabWare LIMS application; this blog just highlights some of major components to ensure a successful implementation. We sincerely hope that the information presented is helpful.
Monday, December 13, 2010
Auditing Your Aggregate Spend Program
Written by Alexis Stroud, Director Quality and Compliance, QPharma
1. What components of the audit process need to be implemented to ensure compliance with state aggregate spend and Healthcare Reform regulations?
In order to comply with state aggregate spend and healthcare reform legislation and regulations, you need to have policies, procedures, systems, controls, and monitoring and auditing processes designed to maintain data integrity and compliance with the various state and federal reporting requirements.
Life science companies must clearly understand and interpret the regulatory challenges to comply with each States’ reporting requirements, as well as begin preparation for the Patient Protection and Affordable Care Act (PPACA) – and possibly new state legislation. Based on these interpretations, their policies, procedures, monitoring controls, and auditing steps need to be developed and implemented to ensure reporting compliance is maintained. This becomes even more challenging for a life science company, because the necessary data and systems are generally not centrally located or maintained (i.e. a cross-functional effort). In addition, the required data elements required to comply with the current Federal reporting requirements may be incomplete or non-existent within these systems.
Using a process-based audit approach enables a company to understand all of its interactions with Healthcare Providers (HCPs) and how those interactions are performed and recorded within its existing systems. This type of assessment delivers a detailed understanding of the current environment in which your company is operating; identifies policy and procedure gaps, control weaknesses, and opportunities to implement industry best practices; and positions your company to ensure accurate and complete state and federal disclosure.
Note: Some of the state laws (NV and MA, for example) require certification that a manufacturer has conducted audits as part of its compliance program.
What should your Auditing and Monitoring Program consider?
Things to consider when auditing your aggregate spend program:
1. What components of the audit process need to be implemented to ensure compliance with state aggregate spend and Healthcare Reform regulations?
In order to comply with state aggregate spend and healthcare reform legislation and regulations, you need to have policies, procedures, systems, controls, and monitoring and auditing processes designed to maintain data integrity and compliance with the various state and federal reporting requirements.
Life science companies must clearly understand and interpret the regulatory challenges to comply with each States’ reporting requirements, as well as begin preparation for the Patient Protection and Affordable Care Act (PPACA) – and possibly new state legislation. Based on these interpretations, their policies, procedures, monitoring controls, and auditing steps need to be developed and implemented to ensure reporting compliance is maintained. This becomes even more challenging for a life science company, because the necessary data and systems are generally not centrally located or maintained (i.e. a cross-functional effort). In addition, the required data elements required to comply with the current Federal reporting requirements may be incomplete or non-existent within these systems.
Using a process-based audit approach enables a company to understand all of its interactions with Healthcare Providers (HCPs) and how those interactions are performed and recorded within its existing systems. This type of assessment delivers a detailed understanding of the current environment in which your company is operating; identifies policy and procedure gaps, control weaknesses, and opportunities to implement industry best practices; and positions your company to ensure accurate and complete state and federal disclosure.
Note: Some of the state laws (NV and MA, for example) require certification that a manufacturer has conducted audits as part of its compliance program.
What should your Auditing and Monitoring Program consider?
- Is the process documented? What is the process for reporting findings?
- Does the compliance auditing and monitoring program incorporate key approval points such as HCP credentialing, needs assessment, payment authorization, and reporting accuracy?
- Have you built into the formal compliance audits a degree of independence?
- Are audits performed at least annually?
- How aware are your Internal Audit teams of the requirements of the state and federal regulations.
- When reviewing past audit reports, how comprehensive were those reviews? Were findings investigated and closed out?
Things to consider when auditing your aggregate spend program:
- Do you have a Federal- and State-specific reporting policy? Is it adequate and is it being followed? How are you keeping up to date with the changing legislation and regulations and how is that information being communicated within the organization and to any third party providers?
- Do you have assessments of third party vendors?
- Third party vendors are acting as agents of a Company. Their activity is ultimately the activity of the Company.
- Monitoring/auditing should include activities of third party vendors. Perform contract reviews.
- Third party vendors should be informed of this requirement and will have to potentially provide data and other documentation for the audit.
- Do you understand the underlying data controls?
- Process – How is data captured, approved, and updated?
- Systems – What systems are the data maintained in and what are the relevant controls and validation procedures?
- Data – What data elements are available to meet the reporting requirements?
- Procedures – What processes are necessary to capture accurate and complete relevant data?
- What are your data collection challenges? How can you improve current processes to address these challenges?
- Are there enough resources within your organization to perform various data gathering, validation, and reporting functions?
- Have you had any prior incomplete or inaccurate State reporting filings?
- What tools/procedures (checklists, sign-offs, sub-certification process) and monitoring controls are in place to address the day-to-day process designed to enhance compliant state reporting?
- ensure accuracy of data through consistent and efficient data review
- identify and investigate outliers and compliance red flags
- Have you tested any system-based tools to ensure they are working properly?
- Is your system flexible enough to change and adapt over time with new/updated laws and are you collecting data at the most granular level?
- Has training been provided to all levels of the organization related to the current and future reporting environment requirements, company policies and standard operating procedures, and monitoring and auditing techniques?
- Is the company using the information obtained for state reporting requirements to enhance business operations, as well as overall corporate compliance?
- Do you have disciplinary actions for employees that do not comply with your procedures?
Monday, December 6, 2010
The FDA Enters Education E-Style
The FDA, in its process improvement program, is enhancing education for companies and consumers on the FDA website, www.FDA.gov.
CDRH is the first center to add course material at CDRH Learn, www.fda.gov/Training/CDRHLearn. Most material is available in three languages: English, Spanish and Chinese. Courses offered are in most medical device regulations, regulated software, BIMO and the 510K process. The e-learning posted represents the areas that lead in lack of compliance for medical device folks with the code of federal regulations. Most educational courses that are currently listed are focused on the health care industry, manufacturers and clinicians.
For those of use seeking to enhance our knowledge on regulations, it represents a good starting point. However, it will not stop the foolish manufacturers who continue to rack up 483s, Warning Letters and other noncompliance notifications by willful violation. It may assist the unwitting violator, who broke the regulations because they were unclear or unlearned. The courses do not replace annual site training in the good manufacturing practices.
Can we guess why FDA has done this? We shouldn't have to. Over the last two decades, many companies have reduced their budgets for employee education. This has become evident by the fall-off in professional conference attendance. Companies don't have the time to train employees in groups on site, and conference costs continue to rise. A company may send one employee to a conference and expect them to return to the site and train others. - a common practice that often falls short in follow-through and substance. Trying to bring a conference on-site also becomes expensive.
QPharma offers both Lunch & Learns and customized onsite training, as well as compliant e-Learning for the entire organization. Lunch & Learns consist of one hour programs on hot button FDA topics; never a sales pitch and as the name states, lunch is on us. Customized training solutions are offered on a fee basis. They represent truly site specific training. They are more detailed, transparent to the client’s own education platforms and tailored for the client site’s processes. They represent better value as the instructor is not lecturing to a mixed audience, but a group with specific needs; and since CDRH is the only FDA center offering e-learning, QPharma can supply your needs from specifics on the other centers, such as CDER, CVM and CBER. We take education seriously, considering the environment we come from!
For those of use seeking to enhance our knowledge on regulations, it represents a good starting point. However, it will not stop the foolish manufacturers who continue to rack up 483s, Warning Letters and other noncompliance notifications by willful violation. It may assist the unwitting violator, who broke the regulations because they were unclear or unlearned. The courses do not replace annual site training in the good manufacturing practices.
Can we guess why FDA has done this? We shouldn't have to. Over the last two decades, many companies have reduced their budgets for employee education. This has become evident by the fall-off in professional conference attendance. Companies don't have the time to train employees in groups on site, and conference costs continue to rise. A company may send one employee to a conference and expect them to return to the site and train others. - a common practice that often falls short in follow-through and substance. Trying to bring a conference on-site also becomes expensive.
QPharma offers both Lunch & Learns and customized onsite training, as well as compliant e-Learning for the entire organization. Lunch & Learns consist of one hour programs on hot button FDA topics; never a sales pitch and as the name states, lunch is on us. Customized training solutions are offered on a fee basis. They represent truly site specific training. They are more detailed, transparent to the client’s own education platforms and tailored for the client site’s processes. They represent better value as the instructor is not lecturing to a mixed audience, but a group with specific needs; and since CDRH is the only FDA center offering e-learning, QPharma can supply your needs from specifics on the other centers, such as CDER, CVM and CBER. We take education seriously, considering the environment we come from!
Wednesday, December 1, 2010
$4.3 Billion - The Current Price of Compliance?
Written by Nancy Tomoney - Associate Validation Manager, QPharma
In October 2010, two major news releases coincided. First, the Inspector General of Health and Human resources and the Commissioner of the FDA decided to enforce an existing rule that allows industry executives to be prosecuted and barred from industry even if they have a left a company where compliance issues were found by FDA or reported by a whistleblower. Second, the initial fine by the courts in the Case of the United States of America versus GlaxoSmithKline (GSK) was awarded, $750 million dollars. There is still potential for additional fines by the 50 US states and other US territories against GSK. Cheryl Eckerd, the GSK whistleblower who pointed FDA and United States Department of Justice to additional problems at the GSK Cidra Puerto Rico site, will receive close to $100,000,000 dollars out of the collected court fines.
In October 2010, two major news releases coincided. First, the Inspector General of Health and Human resources and the Commissioner of the FDA decided to enforce an existing rule that allows industry executives to be prosecuted and barred from industry even if they have a left a company where compliance issues were found by FDA or reported by a whistleblower. Second, the initial fine by the courts in the Case of the United States of America versus GlaxoSmithKline (GSK) was awarded, $750 million dollars. There is still potential for additional fines by the 50 US states and other US territories against GSK. Cheryl Eckerd, the GSK whistleblower who pointed FDA and United States Department of Justice to additional problems at the GSK Cidra Puerto Rico site, will receive close to $100,000,000 dollars out of the collected court fines.
In the last year, six companies have amassed fines totaling $4.3 billion dollars based on whistleblower testimony. All of the whistleblowers were insiders, quality compliance personnel, fed up with their individual companies push off of GMP issues reported in audits by internal staff.
FDA had performed an inspection of the GSK Cidra site and issued significant 483s in June of 2002 and a subsequent Consent Decree in 2005. Cheryl Eckerd was a key person leading the compliance remediation team for GSK at the GSK Cidra Puerto Rico facility where FDA found the issues. She reported additional issues of noncompliance to her superiors at Cidra. Cheryl refused to focus solely on fixing just the FDA noted violations and was eventually terminated in 2003. GSK stated that her termination was part of position cutbacks for redundant job descriptions that were no longer required. Ms. Eckerd took her amassed documentation and ran to the FDA. The United States Department of Justice, in coordination with FDA, then began further undercover investigations of GSK at Cidra and documenting evidence for their case.
The products made in Cidra were slowly transferred to other GSK facilities and Cidra closed. The compliance issues at the plant, once unique to facilities operated off shore of North America have now spread onshore. Quality obedience has become second to profits and market share; and pardon my skeptic nature but, I think it will continue to be such, until Congress, FDA, physicians, and consumers start fighting back.
There are changes pending to the Pure Food, Drug and Cosmetic Act, but most outside of the industry have not taken notice. To the companies receiving the judicial fines, $4.3 billion dollars, an average of $710,000,000 per company, is substantial, but they seem not to care. Management seems to still not hear the cries of quality first. Hence more and more Warning Letters are issued daily. When will the industry learn?
Quality is not cheap, it is not easy, and sometimes it is inconvenient. I once had $4 million dollars of product on quarantine for nine months while we investigated the testing surrounding it. We knew it was an analyst error, but proving it takes time. However, my management would rather do the right thing than potentially maim or kill someone. In the end, the investigation was well documented, and the material was sent to market. Sales hated me for the backorders, but I was not punished. But then I worked for a company run by a physician concerned with quality.
Part of the problem in our industry is who is at the top. Are they ethical? Are they scientists or medical professionals? Too often they are professional business people, great at business management, but with no real knowledge of what is required to put a pharmaceutical or medical device product on the market that is safe, pure and effective. However, they are very willing to cut costs in quality. Often, they look at quality and compliance as unnecessary and government mandated. Quality and compliance are not the enemy, they are the last line of defense. Quality and compliance are all that stands between success and a tarnished corporate image, but management does not often recognize that. Let quality and compliance do their jobs.
The profitability of whistleblower cases is hurting industry, hurting corporate market share, hurting corporate profits. The CEOs and boards need to wake up and understand this. Fund quality, let them investigate, do the right thing, and Oh My Goodness, you will actually make more money. The offset spent on quality will help, not hurt, the bottom line.
The FDA and Justice Department have mastered the art of the whistleblower investigation. They are now smarter than the cost cutters who are cutting corners on compliance and quality enforcement in our plants. Cheryl Eckerd may earn a payout from her whistle blowing, but for all the good she feels about it, it would be nice for her to be able to take an aspirin and wonder - wonder if that aspirin was made in a plant with compliance and GMP issues. We would not need whistleblowers if we just do it right the first time. Quality in, quality out. We can only hope the board room wakes up so we can all take our medications without fear.
Subscribe to:
Posts (Atom)