New FDA Regulation for Medical Device Data Systems (MDDS)

Written By Elise Miner - Validation Manager, QPharma

Earlier this month, the FDA proposed a regulation that will reclassify certain hardware and software products used with medical devices.  The new regulation defines these products, known as Medical Device Data Systems (MDDS), as systems that are intended to provide one or more of the following uses:

• The electronic transfer or exchange of medical device data from a medical device, without altering the function or parameters of any connected devices
• The electronic storage and retrieval of medical device data, without altering the function or parameters of connected devices
• The electronic display of medical device data, without altering the function or parameters of connected devices
• The electronic conversion of medical device data from one format to another format in accordance with a preset specification

Previously, MDDS were categorized as Class III, high-risk and requiring pre-market approval.   This was the case because all medical devices unknown prior to 1976 were automatically placed in Class III by default.  However, according to the new rule, MDDS will now be Class I, low-risk and subject to general controls and quality standards.   The rationale behind this reclassification stems from the amazing growth and development of the use of medical devices and MDDS over the past decade.   Such expansion has led to new risk factors that did not previously exist.

But the changes the FDA are making to the MDDS rule affect both sides of the spectrum.  It simultaneously enlarged the MDDS category to include more software that might have been thought to be unregulated, but also now captures products that might otherwise have been placed in higher risk categories.  

Manufacturers finding themselves with products that fit the MDDS description must now adhere to all Class I requirements including registering with the FDA, listing their MDDS products, reporting adverse events and complying with FDA’s Quality Systems regulation.  By the same token, manufacturers that had previously categorized their MDDS as high –risk now stand a less taxing path to market.

The rule is set to become effective on April 14, 2011.  By May 14, 2011, companies that make MDDS must have registered with FDA and listed the MDDS product. By April 2012, companies making MDDS must have fully functioning quality systems and be in compliance with the medical device reporting rules.

Is this measure a preview of more to come?  It proves to clarify the boundaries around this one particular class of products, but begs the question - When the FDA will take steps to further define and reclassify more software and hardware.   At the very least, it’s a step in the right direction.

FDA Proposed Rule:  http://www.fda.gov/OHRMS/DOCKETS/98fr/E8-2325.pdf

 

Patient Assistance Programs are Consolidating

Written by Michael Milunec - Manager of Operations PDMA and Fulfillment Services, QPharma

Pharma’s Mergers & Acquisitions impact on Manufacturer provided Patient Assistances Programs

Looking back over the past decade, Pharma mergers and acquisitions (M&A) have been an ebb and flow relationship with 2009 being a tidal wave.  I am sure Pfizer /Wyeth, Merck/Schering-Plough and Roche/Genentech mergers were the number one contributing factors.   In a ten year M&A data review from DealSearchOnline.com, Pharma’s M&A hit a whopping 147.2 billion – translating into a 66% increase from the second highest M&A in that ten year span (2000-97.4 billion).[refer to chart below]

What does this mean for PAP?
Regardless of the reasons for companies consolidating with other companies (growing generic competition, shrinking drug pipeline, our Economy) the fact remains it is happening and that means a changing landscape for patient assistance programs.  As these mergers continue on patients, patient advocates, healthcare community will feel, to some extent, the pain before they feel the gain.  In this case the gain being greater program continuity.

When manufacturers merge together, many decisions relative to PAP programs need to be made.  Some of these considerations are if the program(s) will stay independent or if they will be consolidated?  Given the mega mergers mentioned above in all cases they consolidated all their support programs into and under one company with the exception of Roche keeping their ACCU-CHECK program in place.  Consolidating Patient Assistance programs is not an easy task.  here are many other considerations that need to be addressed such as standardizing enrollment rules, keeping the same medication(s) or even the same access points i.e. phone, IVR, web?  Furthermore, if these manufacturers outsource their programs (as most do) it now begs the question of which vendor to consolidate with and how comprehensive their program transition plan is so they do not leave patients behind or without medication.

As QPharma has been consolidating PAP programs for some time now, we have seen an increased need to ensure the client’s transition plan to address outdated access points, primarily on the web.  Furthermore not only should they address these avenues but there should be a monitoring program in place to ensure these points of access do not change or lead to a dead end, broken web-link or busy signal. 

To test my opinion, I applied our content site consolidation methodology as a hypothetical for the Pfizer/Wyeth PAP, a merger that happened over a year ago… and found that there were still some sites that think Wyeth exists as Wyeth as well as their assistance programs.  Furthermore, you can still get an outdated application form off them.  What is even more shocking to me is that one site in particular refers to themselves as a leading provider of online patient assistance. 

To conclude Companies are looking to acquire, consolidate and streamline their business and this will eventually lead to easier access points into those companies Patient Assistance Programs.  If I could be so bold as to make a future prediction regarding the Sanofi-Aventis/Genzyme consolidation I would say it could go one of two ways – Currently they are using 2 vendors between the both of them to run their programs, 18 all together.  One vendor provides services to both companies and the other vendor only provides services to Sanofi-Aventis.  I would implement an RFP proposal, engage other service providers not currently engaged, assess their price points, use these price points to negotiate new terms/pricing with the vendor who currently holds the most knowledge of both programs and establish service level agreements to ensure patients who utilize these programs are handled compassionately and receive their medication in a timely manner.   

Managing the Validation of Custom Databases

Written by Frederick Sperry - Validation Manager, QPharma

The management of custom databases does not need to be an onerous task.  When taken seriously, one can justify the management of the details associated with the database as Good Business Practices.  Even the elephant can be eaten – one bite at a time. 

Initially, as in any other activity in the regulated industry, know your process.  Identify the key parameters that user requirements have defined for the database.  What are the macros supposed to be doing, or any critical connections or formulas expected to produce?  Document the findings as an initial deployment of the system, and get a system user review and approval of the requirements for the database.

Validate your process.  Document the settings and verify the any formulas, macros of interfaces do what they are supposed to accomplish.  Adjust any settings that do not meet the needs of the end users.  Then update your documentation, and get review and approval signatures of the documentation.  Typically this is in the form of a System Design Specification, System Configuration or Functional Specification document.  The title of the document is not important; the current information is the critical item.

After the ‘deployment’ of the database keep the documentation current.  The database configuration and settings are liable to change over the course of normal system usage.  Keep track of the changes and periodically update the system documentation, and obtain the crucial user or management review, approval and sign off of the updated system settings.

Keep current with the data and database and embrace the new era paradigm shift from documentation to information.  The documentation must empower the system users to be able to use the information as knowledge.  In this new millennia day and age of information, knowledge is truly power.

The Twelve Towers - A Project Management Novel: Excerpt 2 – Identify Stakeholders

Written by Bruce Fieggen - VP of Project Management & Training

Below is the second excerpt from the Project Management novel Bruce Fieggen, QPharma’s V.P. of Project Management, is writing in his ‘spare time’. The book follows the Project Management Body of Knowledge Guide (PMBOK) but uses the format of a novel, and promises to be much more readable. The novel tells the story of a Gwilym, a Project Manager, charged with building twelve towers scattered throughout King Arthur’s Britain. Gwilym’s oldest son, Bleddyn, also appears in this excerpt. There is some overlap between this excerpt and the one posted November 1 2010, so you can see where it fits in the novel. 

Readers, think about the various projects you are tasked with and see how you can use the tools shown in these blog posts to assist you in ‘building your towers’.

This second excerpt shows the development of the second tool: The Stakeholder List.

 King Arthur stood, gravely shook Bleddyn’s hand, then Gwilym’s and told them he would be keeping a close eye on this tower and on them. “And there is no need to worry about Tarrant. I didn’t trust those beady eyes when he came here. You, I trust.”

Gwilym and Bleddyn were asked to join in the feast in exchange for a tale to add to the merriment. He told a story of his travels as a young man. “I was in a bazaar in an Arab town near the Holy Land”. This caught all the knights’ attention. “The men there sold their wares to all comers and it was to their advantage to guess the language of their customers as they walked by and to speak to them in that language with what little they could pick up. I passed a seller of brass-works in a street full of brass. He looked at me, smiled and shouted, in highly accented English, ‘Just looking! Just looking!’ He must have heard these words so many times from other Englishmen he became sure this was a greeting of some kind.”

The knights roared in laughter and toasted Gwilym, begging for more stories. He obliged them once, then turned the conversation back to them and listened to their stories until he saw his son stifling his third yawn. “I must return early on the morrow, gentlemen. Thank you so much for your hospitality. My king; thank you for the royal charter. I shall not disappoint you.”

Bleddyn walked by his father’s side on their way to the tavern, looking up at him with a new respect. “Did you really have those adventures, Da? I never knew you had traveled so far. Was I with you?”

“No lad. That was during my misspent youth. I did many dangerous and fool-hardy things at that age that I don’t want you to try. Please forget the stories.”

“But Da, what did your father say about the things you did while you were traveling?”

“My Mother and Father were dead when I was quite young. I did no-one else’s bidding at that age.”

                           ___________________________

At the second cock crow, they left Caerleon, arriving at the ferry dock in time to see the boat approaching from Brycgstow. While they waited, Bleddyn asked his father about the charter.

“It’s a document that describes the project to everyone who cares about it. That way there can be no arguments about what to do. It’s also a contract between all the people who work on the project and King Arthur. And that includes me. I have to make sure I build it for the amount of silver I promised and as quickly as I promised.”

“Who are all these people who care about the project?”

“The quarryman is one. He’s the one who started this whole thing and caused me to make up the charter. I’ll be looking forward to showing him King Arthur’s signature. But there will be others who argue in the future and I can show them the charter at that time.”

“Why not show them the charter first, Da, before they make any trouble?” Bleddyn questioned. “That might save some time.”

“That’s a grand idea, son! Let’s make a list of everyone we should show it to while we wait. There are all the builders on the site, Father Drew, the quarryman, the bishop, the forester, the masons, the carter, the village chief, the inn-keeper who brings food to the site. Who else?”

“What about Tarrant?”

“Now that’s an interesting point. I should also be thinking of people who want the project to fail. I’ll have to keep them in mind for this list of people who care. Though I may not go out of my way to find him, I’ll keep the charter safe so I can show him if he argues again. It clearly says who’s in charge.”

“What do you call this list of people, Da?”

“They are all people who have a stake in this project, one way or another. I’ll call it a list of ‘stakeholders’ then.”

The ferry arrived and they made their way back to Brycgstow and spent the rest of the day and night there. Gwilym hobbled from square to square, sitting down in each and allowing Bleddyn to explore each place. He was exhausted when they returned to the tavern and fell immediately to sleep. Bleddyn, his mind racing from all he’d seen, lay awake for another hour, and then fell into a contented sleep.

They arose early again and rode as fast as Gwilym was able to the quarry near Huish, and found the quarryman hard at work in the pit.

A Practical Guide to Handling Product Complaints

Written by Zina Bulbuc - Validation Engineer, QPharma

Complaints System

Complaints, complaints, complaints….
Everybody gets them: from friends and family members, from customers and business partners, from bosses and co-workers. How do we handle them to keep everybody happy?
I will start with customer product quality complaints and later, we may extrapolate the model for other types of product complaints (Adverse Events, Medical Device Reports) or even for complaints in other areas of our lives (but that will be part of another blog…)

All marketed products (drugs, medical devices or combination products), will sooner or later generate a number of complaints. Handled correctly, complaints can be used by the manufacturer  and others, in a constructive way.
While the number and content of complaints may vary for each product, they all have something in common: they have to be acknowledged, investigated, resolved, reviewed, and where applicable, reported. We must have a system in place that will handle them in a timely and organized manner.

What do we expect from a complaints system?

1. First, we want to make sure it is compliant with the CFR requirements.
2. Second, it has to be a good feedback tool for the manufacturer: on the product’s design, on the product’s efficiency or efficacy and on users’ satisfaction.
3. And third, the complaints system should be user friendly and economical to run.

When creating a complaints system we are faced with two - often opposing - decisions: business and compliance. The first one will guide us to spend the least possible amount of money and resources and the second, to invest as much as necessary to ensure a thorough and safe handling of complaints.

The main steps to follow in creating a complaints system are:

1. Define complaints (CFR provides different definitions for different types of complaints);
2. Decide how you can assure a complete and consistent collection of complaints;
3. Decide how you will keep track and monitor complaints: will you use an electronic log, or a paper based system? Do you have an electronic system in place to handle them (TrackWise, Oracle)?
4. Designate a quality group / quality unit to handle complaints;
5. Define the content of a complete complaint file;
6. Define the time frame to close a complaint and retention time for complaint files.

Now, that we have a overview of what is expected from a complaint handling system, let’s get to answering some of the most frequent questions on this subject.

Complaints Defined
Q: How do we define drug complaints? 21 CFR 210.3 does not have a definition for complaints.
A: This is true, 21CFR 210.3 does not explicitly define ‘complaints’. We have a guidance of what the Agency considers a drug complaint through 21CFR 211.198(a) which states: … Such procedures shall include provisions for review by the quality control unit, of any complaint involving the possible failure of a drug product to meet any of its specifications…
In the mean time, we have a clear definition for complaints for medical device in 21CFR 820.3(b); … any written, electronic or oral communication that alleges deficiencies related to the identity, quality, durability, reliability, safety, effectiveness or performance of a device after it is released for distribution.
Since the medical device complaints definition is more comprehensive and includes “identity, quality, … safety, effectiveness or performance” one can equally apply it to drugs.

Q: Are dissatisfaction about price or availability considered complaints? They do not meet the definition of a complaint as per the 21CFR.
A: FDA does not include these in their ‘complaints’ definition because they do not pose any direct risk for the patient / user (although, the indirect effects of such complaints can be disputed). The difference here is the investigating entity and the corrective action’s target. Do we want to treat them as ‘regular’ complaints? The answer is ‘yes, absolutely’! But, they should be labeled as ‘non product-quality’ complaints (or a similar term), to draw a regulatory distinction between them and those other ‘complaints’ that we are specifically required by regulation to maintain files for. This way, we satisfy the strict legal obligations for complaint handling (keeping the lawyers happy), while continuing to capture and act on customer satisfaction issues (keeping the product managers happy).

Q: Are Service Calls (for medical devices) complaints?
A: This is a hot topic in medical device companies; due to the number of incoming service calls, risking overload to the complaints system. First, service calls are “allegations of … performance” and fit the definition of a (quality) complaint. You may argue that in some cases, the allegations are about an ‘error message’ that is in line with the instrument’s specifications. The regulations cover the ‘failure to meet specifications’ in the definition of an MDR, but not so in the definition of a (quality) complaint. Second, these are calls that require an investigation and a corrective action, so they do not fall in the ‘inquiries’ category. And third, sometimes it is hard to delimitate where a ‘service call’ ends and a ‘complaint’ begins. The safest way is to have them handled as complaints. And make sure to have them clearly identified for trending purposes (also required by 21 CFR 820.200 Servicing and 21 CFR 820.250 Statistical Techniques).