It’s All About State Compliance

Written by Alexis Stroud - Director, Quality and Compliance, QPharma

 We are approaching the end of 2010, and by now, you should have filed your state aggregate spend reports for D.C., Massachusetts, Maine, Minnesota, Vermont, and West Virginia* .  You are most likely also preparing for the Physician Payment Sunshine Provision, included in the Patient Protection and Affordable Care Act (PPACA).  But are you aware of the numerous other state laws and regulations that affect the sales and marketing teams within your organization?  In this post, I will review some of the state legislation that you should be aware of including:

•    Compliance Programs
•    Sample Theft/Loss Reporting
•    Sample Transparency
•    Lobbying
•    Data Privacy
•    Representative Licensing

*Medical Device companies – You are not off the hook!  You too are required to track and report aggregate spend in CA (declaration of compliance), MA, and VT.  You will also be required to report under the federal PPACA in 2013.

Compliance Programs
The company must have a compliance program in place with certain elements. For example:
•    Adhere to, at a minimum, PhRMA Code (CA, MA, NV, CT)
•    Program must be in accordance with OIG Guidance (CA, CT)
•    Compliance Training (CA, CT, MA, NV, VT)
•    Compliance Monitoring (CA, CT, MA, NV, VT)

Sample Theft/Loss Reporting
Certain states require the reporting of sample thefts and/or losses in addition to federal reporting. For example:
•    Vermont and Washington require reporting immediately
•    Arkansas, Florida, Hawaii,  Indiana, Louisiana, Oregon, Wyoming require reporting within 3 working days
•    Colorado and Ohio require reporting within 30 days
•    New Mexico, North Dakota, South Carolina, and Virginia also have reporting requirements

Sample Transparency
Vermont’s Senate bill 88 (“SB88”) amends Vermont’s Pharmaceutical Marketing Disclosure Law by requiring manufacturers of prescribed products to disclose to the Vermont Attorney General’s Office all free samples of prescribed products provided to health care providers during the preceding calendar years.
•    “Sample” includes starter packs and coupons or other vouchers that enable an individual to receive a prescribed product free of charge or at a discounted price

•    This bill requires manufacturers to identify for each sample the product, recipient, number of units, and dosage
•    The first report is due on April 1, 2012 for the previous year's sampling activity

Lobbying
These laws require “lobbyists” to register and file a report that contains certain expenditure data. For example:
•    Colorado requires expenditures in excess of $50 to be reported
•    Florida requires a signed statement under oath of expenditures in excess of $25
•    Connecticut and Kentucky require a report for all expenditures
•    Louisiana requires reporting on expenditures that exceed $50 on any one occasion or $250 in a reporting period

Data Privacy
These laws require that certain prescriber data remain private. For example:
•    New Hampshire became the first state to pass a law that restricts the sale and use of prescriber data.
•    Vermont enacted a data privacy law which keeps prescriber data confidential unless practitioners request that their data be made available to the public.

There are also several other states that provide prescribers the option to “opt out” of being included in lists.  This includes lists of practitioner licensure data used for practitioner validation.  States also vary on the type of information they will provide within the list.

Representative Licensing
D.C. is currently the only state which requires all “detailers” doing business in DC to be licensed and held to a professional code of conduct. The bill also requires detailers to have an appropriate educational background.

Keep On Top of State Laws!
These were just a few of the state issues you should familiarize yourself with.  Others include mid-level prescriptive authority, distributing controlled substances, distributor licensing (wholesaler, virtual, 3PL, samples only), and pedigrees.  Many of the states also have fines for violating their laws (and investigate noncompliance). Pleading ignorance is not acceptable, so it’s important that you understand the legislation and know how to comply with it.

Looking for Regulatory Compliance help? Email us your questions at info@qpharmacorp.com!

Best Practices for Validation of a Software as a Service (SaaS) Customer Relationship Management (CRM) Solution - Part 2

Part 2: Best Practices for the Validation of a SaaS Application

Written by Gregg Mauriello - Validation Manager, QPharma

In Part 1, I gave an overview of what Cloud Computing and SaaS are, and I promised more information in the coming months. Part 2 is here, and now I can discuss the best practices for the validation of a SaaS application.   I will look at the methodology for the validation of a SaaS CRM Application and compare it to the conventional methodology for the validation of a CRM Application. 

Since all customers utilize the same instance of a SaaS application, the core functionality of the application can be validated just once.  Also, the vendor may perform a baseline configuration of the application to meet best practices for a CRM application.  This baseline would also be validated just once.  The customer validation, therefore, can be limited to the customer-specific configuration of the application that deviates from the pre-validated baseline.   The validation of the core application and baseline configuration will follow the conventional methodology for validation, including installation and operational qualification.  The vendor must develop business requirements and functional specifications against which to test including the definition of the baseline configuration.  Note: The focus of validation testing will be on functionality of the system with regulatory impact.

Deliverables:

• The Vendor Validation Plan will document the process, activities, and deliverables required for the validation of the core application and baseline configuration. 
• An Installation Qualification will be developed to document all core software and hardware required for the application. Note: The vendor IQ will not address the field device used for the sales force as this will vary greatly by customer. 
• An Operational Qualification will be developed to test the functionality of the core application and baseline configuration. 
• A Performance Qualification will not be developed as the system will not be utilized in a production environment until it is deployed for a particular customer. 
• All validation activities will be summarized in a Validation Summary Report and a Release Memo will be generated, which will document that the application has been validated and is ready for customer configuration and implementation.

All customers utilizing the application will be able to leverage the validation of the core system and baseline configuration, allowing for a lean validation to be performed by the customer.  It is recommended that the customer perform a vendor audit of the core configuration validation package to determine two factors:  

A) If the validation documentation is in line with their internal quality processes and 

B) How much validation of their specific configuration will be required.  

The vendor will also provide a service level agreement which will define the vendor’s role in maintenance and the administration of the system and data.  All procedures that are performed by the vendor, such as backup and recovery, change management (for code and infrastructure), disaster recovery, physical and logical security, system administration, and training, will be documented by the vendor.

Still interested in hearing more? I will be presenting information on this subject during an interactive workshop, at IVT’s 16th Annual Validation Week on October 26th (Session 4 on Day 2!).  The workshop will be presented along with my colleague, Elise Miner.

If you are not attending Val Week, stay tuned for Part III, where I will discuss customer responsibilities in the validation of a SaaS CRM system.

The Drug Safety and Accountability Act of 2010

Written by Elise Miner - Associate Validation Manager, QPharma

Michael Bennet,
courtesy of politico.com

On August 3rd, 2010, Senator Michael Bennet, a Democrat from Colorado, introduced a new piece of legislation - the Drug Safety and Accountability Act of 2010.  The Act aims to put in place the steps needed to ensure the safety of the U.S. drug supply.  The bill would grant the Food and Drug Administration (FDA) more authority regarding drug safety, and at the same time increase the accountability that drug companies own over the drugs that they manufacture and sell to the public.

The introduction of this Act comes at the same time as the release of a survey commissioned by the Pew Prescription Project and conducted by Public Opinion Strategies and Hart Research Associates.  The poll included interviews from approximately 800 likely voters in 2010, which were sampled demographically to represent the national electorate.  The results showed that Americans strongly endorse individual regulatory measures.  For example, 85% strongly favored that manufacturers must inform the FDA when they find contamination.  Similarly, 82% strongly favored the FDA having the power to issue mandatory drug recalls.  Overall, nearly 9 in 10 Americans supported new measures be put in place to ensure drug safety.

Senator Bennet’s bill would improve upon the system the FDA uses to track international manufacturers providing ingredients and drugs to the U.S., thereby giving the drug companies better oversight of their contractors.  However, one of the most significant authorities the bill would grant would be to empower the FDA to mandate drug recalls when safety issues arise. 

What do you think?  What are your attitudes towards prescription drug safety in the U.S.?  Is the system working well the way it exists now, or do we need stronger safety measures?

Don't Validate That Software! Part II

NOTE: This discussion is a continuation of Monday's post by Jeff Boatman - CQA and Sr. Subject Matter Expert, QPharma. To read the 1st part of this post, please click here.

INTEGRAL SOFTWARE

Suppose I have three autoclaves. They’re used to sterilize final product for human implantation: major potential for serious health consequences (and remember, you don’t get to say “it doesn’t matter because we wind up testing our product”—it matters). All three of these autoclaves use software.

The first one has a separate PC connected to it, and the software resides on that computer’s hard drive, interfacing with the autoclave through a serial port. The PC is a general-purpose computer that can interface with a number of different autoclave models, and allows the user to set up specialized cycle profiles and alarms. Does that software need to be validated? You bet!

The second one sounds different, but in most ways, it’s not. That autoclave has a computer built right into it, running software with a user interface that permits customized cycles and alarms. Now there is indeed a difference: it is not designed to be disconnected from one autoclave and hooked up to another. Clearly there is some amount of scale-down that is appropriate in not needing to check that the computer can be reliably moved from one autoclave to another. But the core expectations remain the same: not only does the software, as it is configured right now, run the autoclave in such a way that it consistently works (OQ = correct temperature/pressure/cycle profiles, PQ = actually sterilizing loads); it also must demonstrably provide confidence that a range of different parameters and program sequencing will be reliably translated into actual machine operation and that those profiles are consistently implemented. That’s a qualification that goes beyond simply how the machine itself operates: it is software validation. We may have used a risk assessment to scale down the amount of testing needed, but there is definitely a separate software aspect to this.

Now consider the third example. This autoclave is computerized, but the software is programmed for one specific cycle profile; it is not customizable. There are a couple of ways this could be done: the autoclave could truly be a one-trick pony, with the computer no more customizable than a four-function calculator; or more and more commonly, the software is customizable, but the manufacturer has decided that the configuration will be “locked down” and never changed, at least not outside formal change control (which includes, of course, a process for evaluating changes for the need to perform re-validation).

I contend that in this last example, the whole concept of “software validation” goes out the window. If indeed the system has any potential for changing settings and parameters, then certainly you must both explain the measures used to preclude anyone from making unauthorized and unvalidated changes, and then demonstrate the effectiveness of those controls; and if the autoclave electronically captures or transmits any digital records that are used for GxP purposes, then validation for Part 11 may still apply. Those could include actual cycle monitoring records, any data input by users such as batch identification, or confirming the identity of authorized users.

But provided you have covered these Part 11 items, there is no regulatory obligation to...

Don't Validate that Software!

Written by Jeff Boatman - CQA and Sr. Subject Matter Expert, QPharma

BACKGROUND

General software validation became an official part of U.S. regulated Life Sciences in 1996 with the finalization of the Quality System Regulation. Contained within that Rule is 21 CFR 820.70(i), which states when computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol. It is important to note that while Part 820 is a Medical Device regulation, another section [21 CFR 820.1(b)] gives FDA the authority to apply this requirement to other companies as well.

Prior to this, there was no specific regulation dealing with software validation; the closest was 21 CFR 211.68, which since 1964 has stated that if a manufacturer uses an automated system to produce a drug product, it shall be routinely calibrated, inspected, or checked according to a written program designed to assure proper performance. Bear in mind that computers were practically a novelty when that Rule was finalized, and modern validation practices were only beginning to emerge; the first software inspectional guidance wasn’t issued until 1983.

In 1997, FDA followed up with 21 CFR 11, which states that systems that create, store, process, or transmit electronic records used to satisfy regulations must include validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records [21 CFR 11.10(a)].  Shortly after, the Center for Devices and Radiological Health published Guidance for Industry: General Principles of Software Validation, which has since gone through several draft and Final revisions. While that guidance is from FDA’s Medical Device division and does include sections on the validation of software which is, or is used within, a Medical Device, it also has broad applicability to other Life Science firms as well.

The broad applicability of 21 CFR 820.70(i), the virtually universal applicability of Part 11, and the adoption of the standards in FDA’s software validation guidance make it clear that FDA has very high demands for software validation at Life Science firms, and indeed consulting firms like QPharma rely upon FDA’s comprehensive expectations to stay in business. It must be obvious to the reader that the problem that we see most often is too little software validation, too poor software validation, and too poorly executed software validation. Further complicating this is the latest move by CDRH to vastly increase the scope of what FDA considers to be "Medical Device Software" into areas that traditionally have been considered outside CDRH’s (and even FDA’s) jurisdiction.

THE USUAL...AND THE UNUSUAL

When we do audits, our comments are usually: you need to validate this...you forgot to validate that...you didn’t consider this. But once in a while, our comment is: why did you validate that?

Let’s hit some of the basics.  First, you need a Traceability Matrix (TMX), which shows all of your requirements, all of your testing planned (and performed), and linking them together. Traceability of requirements to testing is always a good idea, but for software validation, it’s mandatory: the FDA guidance mentions it repeatedly.  The most important purpose of a TMX is to ensure that every requirement actually gets validated or otherwise verified. But it also goes the other way: if you are testing something and it is not traceable back to a requirement, then why are you testing it?

Another low-hanging fruit is risk assessment. If you take the validation requirements of 21 CFR 11.10(a) and 820.70(i) literally, you’ll probably never manage to make any product for sale: all you will ever do is validate, validate, validate. (As an example, if you literally accept 820.70(i)’s obligation to validate all software changes prior to implementation, can you imagine the potential implications for daily antivirus definitions and Microsoft Windows patches?) In both its software validation guidance and the 2003 Guidance for Industry: Part 11, Electronic Records; Electronic Signatures – Scope and Application, FDA has been putting increasing emphasis on doing risk assessments of systems to determine exactly what truly needs to be validated. In particular, the Part 11 guidance offers companies the possibility of exempting broad swaths of functionality from validation provided that you can back that up with documented risk assessments. FDA may object to lesser validation based on a risk assessment they disagree with, but they will object to lesser validation without a written risk assessment at all.

In both of these examples—validation of functions that aren’t required, and validation of functions that a risk assessment could have exempted—we would caution our client that they are going overboard and that their validation dollars are better spent elsewhere. But how about software that runs a manufacturing process, and that process (and therefore that software) really does have a significant impact upon product quality, and even public health?

More on this topic and the answer this Wednesday, September 29th!