Michael Causey, Editor & Publisher, eDataIntegrityReport.com
Gotta give the FDA some credit here. In addition to its transparency initiative we’ve talk about before, the agency is also trying to remove some of the mystery about how it handles inspections and other inner workings at the FDA. From where I sit, it appears to be a sincere effort and I believe it is helping outsiders better understand what the FDA is trying to do – and how it is trying to do it.
For example, at the second in a new series of monthly online webinars, FDA’s Michael C. Rogers, deputy director, Office of Regional Operations, said today (March 25, 2010) tried to outline how an FDA inspection tends to work, and what drives inspectors before, during and after an inspection.
As an aside, Rogers also said that the agency currently has about 1,800 total inspectors across its full portfolio, though food gets the bulk of the bodies. He also said there will be more foreign inspections this year, and that the number should continue to grow.
Inspections are based on risk, Rogers said. In other words, the riskier the potential drug, device or food item, the more likely they will be inspected.
Most inspections are unannounced, Rogers said. Before they go on-site, the inspector on inspection team will look at previous inspection reports and identify what corrective actions were promised during prior inspections. They also prepare inspection tool kits with sampling equipment, info to drive inspection based on guidance documents and the Investigation Operations Manual. They also carry a camera to document evidence.
They also conduct “for cause” inspections driven by consumer complaints or other outside activity.
Typically, the inspection begins with a discussion with management to explain the purpose of the inspection, and they try to learn about the corporate structure and any changes made since last inspection. They also ask about complaints, positive tests or returns. Answers to those questions help FDA inspectors focus their on-site efforts.
Next, they go to the physical manufacturing area. They try to observe and understand the on-site process. They ask about acceptance criteria and want specifics on failures, especially the reasons.
Inspectors also draw a diagram of the facility showing the manufacturing process from start to finish. They’re looking for problems in the system and looking to identify critical control points in the manufacturing process.
FDA inspectors then identify procedures in place and assess if company is actually following them. They also look for controls in place to mitigate any contaminated products.
They also look at training and cleaning programs. They also watch employees while they are actually making the product.
If they find evidence of an adulterated product, they collect evidence based on inspector observations and collect samples to prepare their case for possible legal action in court.
At conclusion of inspection, the FDA team meets again with management. They then inform the top company official what is in the official Form 483. That form documents observations during the inspection but does not include final recommendations. They also ask for the firms corrective actions planned or in place to get into compliance.
These corrective actions are taken into account as agency formulates official recommendations.
After the inspection at the firm, the inspector develops a report back at the home office. It includes evidence collected and what the firm has already agreed to do about any shortcomings.
In some cases firms can offer voluntary corrections. But sometimes the agency decides it needs enforcement action such as a warning letter, and can also impose civil and/or monetary penalties.
The webinar was extremely popular. In fact, it “sold out” so many who tried to join it could not get in to the live event. There will be a recording available on Monday March 29.
UPDATE: Slides are now available from this event here in PDF format.
Eric Cooper, Manager - Professional Services, AssurX
So, you’re evaluating software packages and request a sales demonstration. During this demonstration the sales rep is going to focus your attention on the cool, “shiny” aspects of their system and there will likely be a lot of “talk” about how the software can be implemented to meet your requirements. The key question you want to ask is “how”. How will this software be configured to meet those requirements?
This is where the 80/20 rule comes into play. The best case scenario is that the software you purchase will only meet 80% of your requirements and that the other 20% will have to be achieved through some sort of customization, modification, or configuration. In some instances the gap could be much greater. The key then is to figure out how that 20+% are accomplished. Here are three questions to ask:
- Is the base code altered?
- Who performs the customizations?
- How do these customizations affect future upgrades?
There is a difference between customization and configuration. Customization implies code changes. Customization is also generally done by the vendor. Some vendors consider this their bread and butter. They’re basically selling you half a system and then charging you to create the other half. Customization can also prevent you from applying future upgrades without shelling out even more money to the vendor to reapply your customizations. Configuration implies no code changes and is generally performed by you, the customer. As such, configuration changes should not affect future upgrades. However, again the key words here are “should not”.
This goes to the substance of the system. The best systems in the market are the ones that allow you, the customer, to perform configuration changes on your own. Keep in mind that this is not only a factor for your initial implementation, but also for future growth and change of the business requirements. Maybe the vendor will only charge a nominal fee for the initial customizations, but what happens when your requirements change?
Having been involved in a myriad of software purchases, I can tell you that the differences between packages can be great. At a former employer of mine we implemented a document control system that probably only met 60% of our initial requirements. However, the business unit was wowed by what they did see, and therefore we were pushed to approve it. When it came time to do the implementation, the next 40% of the requirements needed customization, which meant that the vendor provided core code changes. Jump ahead five years now. Several upgrades have come out from the vendor and the business decides its time to look at upgrading. Do you see where this is going? In order to apply the upgrades all of the customizations would have to be evaluated and then re-created after the upgrade. Care to guess how much the vendor wanted to perform this job? We’re talking at least high six figures.
So take it from someone who has been there and done that. Make sure you get straight information from the vendor regarding configuration vs. customization. Your initial cost of purchase may seem very attractive, but the long-term total cost of ownership may end up being extremely high.
