December 22, 2014

It’s Time to ‘Get’ IEC Before It ‘Gets’ You

Russ King, Managing Partner, Methodsense

Russ King, President, Methodsense

FDA medical device recalls are on the rise. An increasingly active FDA, coupled with the rise in software components for medical devices is adding up to new challenges for manufacturers. Given this reality, it’s important to understand how the FDA uses the IEC 62304, an international standard developed that, among other things, says product testing by itself is not enough to prove software is safe for patients using the medical device.

The standard provides a common framework for medical device manufacturers to develop software. Conformance with this standard provides evidence that there is a software development process in place that fulfills the requirements of the Medical Device Directive. Because it has been harmonized with the Medical Device Directive in the EU and recognized as a Consensus Standard by the FDA in the US, IEC 62304 can be used as a benchmark to comply with regulatory requirements in both markets. To date, this standard has been recognized in most countries that use compliance standards to fulfill regulatory requirements.

Complying with 62304 enhances the reliability of your device’s software by requiring attention to detail in design, testing and verification, ultimately improving the overall safety of the medical device.

Here’s the $64,000, or usually much higher, question: Does your device have to meet IEC 60601-1 requirements?

The EU has been using IEC 62304 since 2008, but it has gained even more traction with its incorporation into the third edition of IEC 60601-1’s Amendment 1. The inclusion of Amendment 1 shifted the standard from a recommendation to a requirement if your device utilizes software.

For those who design or manufacture electromedical equipment, 60601-1 is one of the most important safety and performance standards to meet. The standard addresses critical safety issues, including electrical shocks and mechanical hazards, such as pinching, crushing, and breaking. Devices that must meet IEC 60601-1 requirements include those which:

  • Diagnose, treat, or monitor the patient under medical supervision
  • Make physical or electrical contact with the patient
  • Transfer energy to or from the patient; and/or
  • Detect such energy transfer to or from the patient.

60601-1 Clause 14 requires manufacturers to comply with IEC 62304 unless the device’s software has no role in providing basic safety or essential performance or risk analysis demonstrates that a failure of any Programmable Electronic Safety System (PESS) does not lead to an unacceptable risk.

insulin pumpBasic safety is the main focus of IEC 60601-1. It’s important that you conduct a risk analysis to identify your device’s level of unacceptable risk and determine the role of software in risk mitigation. This analysis will determine the applicable basic safety requirements for your device, and, for some requirements, the test parameters that need to be used by the test laboratory.

The most common mistake that medical device manufacturers make is that they do not always assess which elements of risk their software mitigates. These are the elements that must be addressed by IEC 62304. For example, what would happen if the creator of a hoist didn’t properly vet the software that signaled the hoist to lower the patient at a certain speed? If a patient were lowered to quickly–or not  at all –there would be a risk management nightmare. Since software plays a role in the Basic Safety functions of the hoist, it must comply with 62304’s requirements.

In conjunction with IEC 60601-1, 62304 is intended to minimize the occurrence of these situations. When device software is mitigating a known potential hazard, ensuring that the code is developed properly is critical for the management of patient safety, as well as liability to the manufacture.

It can be difficult to determine if a device’s software is tied to its Essential Performance (EP), especially because the definition of EP has been widely debated for years. Thankfully, the definition and requirements for Essential Performance changed with Amendment 1 of IEC 60601-1 to help provide more clarity.

Determining Essential Performance begins with a list of all functional aspects of your device, including accuracy, measurements and its capabilities. Once you identify these items, determine whether any of these are already covered by the Basic Safety requirements of IEC 60601-1 or whether any item is not part of the device’s intended use. Then, and this is key, every item remaining gets posed the question, “If this item degrades, will it create a risk for the patient?”If the answer is yes, you must identify how its functionality must be maintained so the risk is still acceptable. This is your Essential Performance.

A good example to help clarify the impact of Essential Performance on IEC 62304 is accuracy. Consider a device that claims its EP is accurate within 5%. If the device is relying on software to maintain that accuracy or provide an alert when outside of 5%, and that software fails, then the manufacturer will be unable to detect if the device’s Essential Performance is being met. This means the software is providing Essential Performance.

Once you know your device software is responsible for Essential Performance, you must comply with IEC 62304 to ensure there is no unacceptable risk to a patient.

There are several situations that manufacturers often don’t realize require compliance with IEC 62304. These product features can create major headaches and costly delays if they are not properly developed. These scenarios include:

Alarms & Alerts
Alarms are often an Essential Performance requirement because they are intended to detect abnormalities. If the alarm was removed, the device would no longer meet it’s performance requirements, making the risk unacceptable. Software is used to detect the issue, instigate the alarm and make the sound.

Speed & Position Sensors
These sensors are in place to address Basic Safety concerns. For example, a hospital bed has a position sensor to keep it from crushing the operator’s foot and mammography has sensors to gauge compression. Devices like these use software to limit range of motion, speed and force.

Algorithms
Algorithms are frequently used with physiological monitoring. If the software is removed, the device is no longer able to operate as intended, resulting in the algorithms being part of Essential Performance.

It is important to note that these situations apply to the patient, operator or service personnel.

Once you know you must comply with IEC 62304, how do you go about preparing for it? To start, know that compliance with this standard is defined as implementing all of the processes, activities and tasks identified in the standard in accordance with the software safety class. 62304 itself does not prescribe a particular organizational structure or specific format for documentation, however. Compliance is determined by a review of all required documentation, including the risk management file.

Editor’s Note: In Part Two, we’ll take a look at the best way to approach risk management.

About the author:

Russ King is President of MethodSense, a life science consulting firm with offices in the US and Europe. They guide medical device, biotech and pharmaceutical companies with quality, regulatory and technology solutions. Their services enable clients to operate more effectively during the commercialization process and beyond. As it relates to IEC 60601-1 and 62304, MethodSense provides expert guidance and interpretation, helping you with:

  • Reviewing the standard you must comply with
  • Conducting a gap analysis of your Risk Management Program against ISO 14971
  • Updating your Risk Management Documentation
  • Completing the IEC 60601-1 and other relevant tables
  • Submitting your documentation for review

MethodSense offers special thanks for the input of Medical Equipment Compliance Associates, LLC for information that significantly contributed to the content of this article. 

For questions and information, contact Russ King, rking@methodense.com

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

FDA IDE Guidance Offers Industry Important Clarity

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

In its August 19 guidance for Investigation Device Exemption (IDE) Clinical Investigators, the FDA attempts to better outline its thought process for reviewing, accepting, accepting with conditions, or denying an IDE. It can literally be a matter of life and death for patients and trial subjects. Thus, the agency and industry continue to take it seriously.

FDA approval of an IDE allows the initiation of subject enrollment in a clinical investigation of a medical device that has potentially significant risks — widely defined as a device that could pose a serious health risk or death to the user, is used to support to prolong life, or is part of a diagnosis tool also being used to support or sustain life.

The guidance covers a number of important areas, some with new wrinkles, including:

IDE Decisions

FDAlogoFDA must inform sponsors or sponsor-investigator of its decision, or must notify the sponsor that the investigation may not begin, within 30 days from the date of receipt of the IDE application, or the IDE application will be deemed approved. If an IDE application is approved or approved with conditions, the sponsor may begin subject enrollment, up to the number of subjects and investigational sites specified in FDA’s decision letter, upon receipt of Institutional Review Board (IRB) approval, which may occur prior to FDA approval.

IDE Approval

An IDE application is approved if FDA has determined that: the sponsor has provided sufficient data to support initiation of a human clinical study; no subject protection concerns preclude initiation of the investigation; and no additional conditions must be met. 

IDE Approval with Conditions

FDA has clarified matters here somewhat, and appears to have given industry a touch more leeway if used wisely and safely.

If FDA approves an IDE application with conditions, the sponsor may begin subject enrollment upon receipt of IRB approval and in accordance with the limits described in FDA’s decision letter, including the maximum numbers of U.S. subjects and investigational sites, and must submit information addressing the issues identified as conditions of approval in FDA’s letter within 45 days.

An IDE application is approved with conditions if FDA has determined that: the sponsor has provided sufficient data to support initiation of subject enrollment in a human clinical study; no subject protection concerns preclude initiation of subject enrollment; but additional conditions must be met to address certain outstanding issues.

Previously known as “conditional approval,” the phrase “approval with conditions” is now used to convey that the outstanding issues do not raise concerns that preclude FDA from granting approval for initiation of subject enrollment in the clinical investigation. FDA now says resolution of those issues isn’t required prior to initiation of subject enrollment in the study, except for certain issues related to the informed consent document.

The guidance reiterates how seriously FDA takes clear, simply informed consent forms for trial participants, noting it “closely reviews” those as part of an IDE determination.

Staged Approval, Staged Approval with Conditions

In the guidance, FDA says it may grant IDE approval or approval with conditions for a portion of the intended study cohort, enabling certain outstanding questions to be answered concurrently with enrollment in this cohort. Staged approval permits the clinical investigation to begin in a timely manner while maintaining appropriate subject protections. In some cases, the sponsor proposes a staged enrollment in the IDE application. In other cases, the sponsor requests approval for the full subject cohort but the agency may decide to grant staged approval for a limited number of subjects as an alternative to outright disapproving the IDE.

IDE Disapproval

Broadly speaking, little has changed here in regards to what the FDA deems most important in an IDE request. If the agency raises patient risk issues the device company cannot adequately address, and/or if the device maker is unable to persuade the FDA that the product is important enough (e.g. life-saving) to quality for IDE designation, it will get the thumbs down.

FDA Communications

The agency says it will send a letter discussing any rejection or question about an IDE request. The letter should include the agency’s thoughts on how the study design assessment, considerations, and other suggested improvements the device maker should consider if it plans to try again.

 

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

FDA Guidance Advises Device Makers to Think About Home-Use

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

Medical device manufacturers would be well-advised to address any potential home-use products risk at the design state, says an August guidance from the FDA.

As the agency notes, “Failure to adequately consider potentially hazardous situations during the design of home use devices may result in inappropriate use, use error, or incompatibilities between the use environment, the user, and the device. This could cause the device to malfunction, possibly contributing to death or serious injury.”

It could also make the FDA really angry.

The guidance offers advice designed to address then entire manufacturing process — and beyond. It covers environmental issues, user issues, design issues, human factors, labeling challenges, postmarket considerations, and the always fun human factor

Digging a little deeper into the guidance, FDA covers many layers of these topics, including:

  • Environmental considers such as location, contaminants, water supply, temperature, dampness and humidity, atmospheric pressure changes, air flow, travel and international use, fluid exposure and storage.
  • User considerations such as physical location, sensor/perception requirements, plus cognitive and emotional product demand.
  • Design issues, including lock-out mechanisms, maintenance and calibration, mechanical issues and special emphasis of electrical issues. As noted earlier, this is probably the section deserving the closest examination by medical device makers.
  • Human factors ranging from user training to certifications.
  • Labeling issues including describing the basic handling of the device, how to dispose of it in an emergency, disposal, and hygienic maintenance.
  • Post-market considerations such as robust customer service and medical device reporting.

electronic document managementFDA’s Medical Device Reporting (MDR) regulation requires manufacturers to submit reports to the FDA whenever it becomes aware of information that reasonably suggests that a device it sells may have caused or contributed to a reportable death or serious injury, or has malfunctioned and the malfunction would be likely to cause or contribute to a reportable death or serious injury should it recur.

For the FDA Form 3500A, instructions for completing specific items on the form, and the coding manual see MedWatch: The FDA Safety Information and Adverse Event Reporting Program.

For additional guidance on the MDR regulation and the reporting requirements refer to FDA’s guidance Medical Device Reporting for Manufacturers (March, 1997). FDA advises medical device manufacturers to also take a look at its draft guidance Medical Device Reporting for Manufacturers (July 9, 2013).

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

FDA Spreads Regulatory Love Nationwide

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

Detroit may be struggling with bankruptcy, but in a flurry of activity that would make industrialist Henry Ford proud, the local FDA office has been active in our latest warning letter round-up.

Indiana-based Med-Mizer, manufacturer of AC powered, adjustable and bariatric hospital beds, was hit by FDA’s Detroit office with a 12-point letter dated July 21.

Among FDA’s accusations, Med-Miser failed to:

  • Establish procedures for reviewing and evaluating incoming complaints
  • Develop, conduct and control and monitor its production process
  • Establish and maintain design controls
  • Validate a manufacturing process
  • Ensure its products meet acceptance criteria

Ventilab LLC, a manufacturer of manual resuscitation bags based in Grand Rapids, was also dinged by the Detroit office for CAPA shortcomings, inadequate complaint management, and failing to establish an acceptable risk management plan.

warning640Moving east to the City of Brotherly Love, FDA’s Philadelphia District office sent a warning letter to the maker of a sleep apnea monitor citing it for failure to ensure its device conformed to specifications and requirements. That June 30 letter was the result of a series of April 2014 inspections.

A June 27 letter called out Zynex Medical, manufacturer of the NexWave multiple mode electrical stimulator and the IF8000 electrical stimulator for perceived CAPA and design control and verification shortcomings. Zynex, baed in Lone Tree, Colorado, was also hit for failure to have adequate device master records and internal audit procedures.

Out in Napa, California where the weather is lovely and the wine flows, June 25 was probably not a day to celebrate for Dexta Corporation, manufacturer of medical chairs used for Lasik surgery and other procedures. FDA hit them for, among other things, failure to adequately train personnel, inability to verify test results, CAPA issues, and process controls problems.

Henry Ford, a man who tried to build his own utopian city in the jungles of the Amazon and modestly name it Fordlandia, would be proud of the FDA’s devotion to hard work these past few months. Perhaps there is an FDAlandia on some city planners drawing board just waiting for the green light. You never know.

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

Time to Take a Closer Look at FDA MDDS Moves

Russ King, Managing Partner, Methodsense

Russ King, Managing Partner, Methodsense

The FDA recently released a new draft guidance document for Medical Device Data Systems (MDDS). The FDA defines MDDS as “hardware or software products that transfer, store, convert formats and display medical device data. An MDDS does not modify the data, and it does not control the functions or parameters of any connected medical device. MDDS are not intended to be used in connection with active patient monitoring.”

The core issue it raises, I believe, is one of data integrity. More on that later.

The new draft guidance cites the growing trend “that many medical devices be interoperable with other types of medical devices and with various types of health information technology.” And further “[s]ince down-classifying MDDS, the FDA has gained additional experience with these types of technologies, and has determined that these devices pose a low risk to the public,” the FDA wrote. “Therefore, the FDA does not intend to enforce compliance with the regulatory controls that apply to MDDS devices, medical image storage devices and medical image communications devices.”

The FDA’s interest in this kind of risk based approach has pleased a great many. On the one hand, the draft guidance demonstrates a proactive approach by the FDA for addressing the explosion of mobile health applications in the light of pending legislation on the same topic in the US Congress. It frees application developers to innovate without the additional burden of regulatory compliance, and it dovetails with the rapidly expanding electronic health ecosystem servicing the informational appetites of healthcare providers and patients alike.

Driving this trend are advances in mobile networks and the proliferation of smart phones and tablet devices, which the Cisco Visual Networking index projects will result in 10 billion mobile devices around the world by 2016. This revolutionary expansion constitutes a global service delivery platform for many industries, including health care. Creating affordable and efficient health care systems is a critical challenge for everyone, and mobile health solutions offer tremendous potential by improving and lowering the cost of health care interactions for everyone.

But, there are also some complications to consider with this overall approach. Creating mobile medical device applications is relatively easy and inexpensive, which enables developers inexperienced with the medical device industry to quickly develop applications that are, in fact, medical devices. This ranges from hospital software developers creating interfaces that network device data to Electronic Health Records to college students with a basic understanding of iOS for iPhone applications.

mobile health appRegardless of whether the applications are distributed to clinicians by hospital IT staff or available as a download from iTunes to clinicians and patients alike, once in the hands of the user, the data from MDDS applications will be used for diagnostic purposes –even if the expressed intended use of such applications is to the contrary. We would be naïve at best to believe otherwise.

The use of a device “off label”or contrary to its intended use, however, is not the concern here. Reconciling the conflicts between the intended use of devices and the intentions of end users is a different kind of problem more properly framed by the argument between those advocating stronger more far reaching government controls and those advocating more personal responsibility. Instead, the issue here is one of data integrity and the risks associated with compromising that data.

The draft guidance for MDDS, in essence, proposes a lifting of controls that are otherwise designed to ensure data integrity of MDDS software applications. In the absence of those controls, what assurances will we have that the data stored, transferred or converted was done so in a way that did not create an unintended change in the data? At this point, advocates for the draft guidance might remind us that the FDA “has determined that these devices pose a low risk to the public.”

Here is the rub: however simple the application, there is very little credibility in claiming that a particular software application is “bug free.” Simply ask “how frequently does your iTunes Store app alert you to application updates for bug fixes?” This gives you a sense for the state of software development in the absence of strong quality controls and the rigorous software lifecycle planning that are part of medical device regulations and standards, such as 21 CFR Part 11 and IEC 62304.

If MDDS application developers are not required to have a competent software development lifecycle, not required to test or validate their software, not required to manage their quality…what assurances does the user have that the software operates as intended, and the data is not compromised in some fashion due to software bugs? And, if we take for granted that the data from MDDS applications will be used for diagnostic purposes despite their stated intended use, what risks are we accepting on behalf of patients?

In short, the risk of misdiagnosis, either by the clinician or the patient themselves, increases as do the consequences for misdiagnosis. The more widely distributed mobile health care monitoring and treatment options become and the fewer requirements for ensuring data integrity, the more likely patients will be exposed to such risks.

Russ King is President of Methodsense, a consulting firm that helps clients deliver medical and technological breakthroughs by effectively meeting the requirements needed to bring their products to market.   He can be reached at (919) 313-3962 or rking@methodsense.com.

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

FDA Lets MDDS Off The Regulatory Hook

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

FDA won’t enforce compliance with regulatory controls that apply to medical image storage devices (MDDS) and medical image communications devices recognizing the “low risk” they pose to patient safety and the importance they play in advancing digital health.

The good news came in a guidance released June 20, “Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices.”

Specifically off the hook are MDDS’ subject to 21 CFR 880.6310, medical image storage devices subject to 21 CFR 892.2010, and medical image communications devices subject to 21 CFR 892.2020. Devices in these categories won’t be subject to FDA regulatory enforcement regarding registration and listing, premarket review, postmarket reporting and quality system regulations.

As defined by the FDA, MDDS is a medical device intended to store and/or move edata without controlling or altering the functions or parameters of any connected medical device.

 

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

Charles Darwin, Social Media & The FDA’s New Guidance

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

If someone out in there in the wild wonderful world of the Web takes a potshot at your drug or device, the first thing to do is take a deep breath and think. Any crisis communications executive worth his or her salt will tell you it’s often best to let the attacker eat silence rather than draw more attention to their criticism or cheap shot.

But if the criticism is relentless, or damaging and unfair, if it looks to be gaining traction, then a measured response can be part of the solution.

The FDA just released a guidance it says “responds to (among other things) stakeholder requests for specific guidance regarding a firm’s voluntary correction of misinformation when that misinformation is created or disseminated by an independent third party.” In other words, how to fight back fairly.

But the short guidance is vague on specifics, though it does give us a “helpful” reminder that the Internet makes it much easier for third-parties to easily disseminate information about your products and your company. The agency calls it User-Generated Content (UCG). I don’t mean to sound like an elitist snob, but this sounds kind of obvious to me.

“I wouldn’t call this guidance useless…well, yes I would,” a device industry consultant told us. He asked to remain anonymous on the off chance anyone at the FDA ever reads this blog.

Is the guidance helpful? You be the judge. Here’s how the FDA advises a drug or device company to address negative and or inaccurate claims online:

  • Be relevant and responsive to the misinformation;
  • Be limited and tailored to the misinformation;
  • Be non-promotional in nature, tone, and presentation;
  • Be accurate;
  • Be consistent with the FDA-required labeling for the product;
  • Be supported by sufficient evidence, including substantial evidence, when appropriate, for prescription drugs;
  • Either be posted in conjunction with the misinformation in the same area or forum (if posted directly to the forum by the firm), or should reference the misinformation and be intended to be posted in conjunction with the misinformation (if provided to the forum operator or author); and
  • Disclose that the person providing the corrective information is affiliated with the firm that manufactures, packs, or distributes the product.

I suppose writing all of this down somewhere doesn’t hurt anything except the trees killed when it is printed out. Still, it feels a bit like FDA is talking down to future winners of the Darwin Awards. That’s the “prize” named in honor of Charles Darwin, the father of evolution. The Darwin Awards commemorate those who “improve our gene pool by removing themselves from it.”

Here’s a good example of a Darwin Award: In 2000, a motorcycle taxi driver challenged his neighbor to stand beneath a hornets’ nest, while two men pelted it with stones. The 53-year old man should have known better, but he had a local reputation as a strong man to uphold. He stood beneath the nest and the pelting commenced. The man endured the pain of countless stinging hornets before expiring from the toxic injections.

To be fair, if you need an FDA guidance to tell you to “be accurate,” I’d also say you may need a reminder to stay away from hornets or men holding stones. Otherwise, there’s no harm bookmarking this new guidance in your computer.

But don’t print it out, please. It’s not fair to the trees.

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

FDA Acts to Harmonize Global Adverse Event Reporting

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

It’s a small world after all. One of the by-products of globalization is the speed and spread of everything from t-shirts to medical devices.

But everything has its plusses and minuses. When it comes to globalization, a plus for American’s is something like high-quality inexpensive clothes from my haberdasher of choice, J. Crew. On the minus side, we’ve got MERS hitting our shores.

Of course, t-shirts are one thing and safe medical devices and drugs are quite another.

As the FDA has learned, health regulations and standards in one nation do not often translate, figuratively and literally, to another nation.

Zeroing in on one of the most pressing requirements, FDA is working with the International Conference on Harmonization (ICH) to harmonize global adverse event reporting forms and requirements. It won’t be easy, but the two organizations appear to be off to a good start.

A recent notice in the Federal Register outlines a step forward covering three parts of the globe: the United States, Japan and the European Union. It does not address other parts of the world.

The core of the new effort is the Periodic Benefit-Risk Evaluation Report (PBRER) draft guidance first issued in 2012, building on a guidance issued in 1997 and amended in 2004. PBRER is designed to “promote a consistent approach to periodic postmarket safety reporting among the ICH regions and improve efficiency by reducing the number of reports generated for submission to regulatory bodies.

FDAlogoFDA advises that companies operating in more than one country or region may find it easier to prepare a single PBRER rather than preparing multiple types of reports for multiple regulators.

FDA also outlines some situations where medical device companies must be granted a waiver, and other situations where they can apply for a waiver. Existing regulations permit applicants to request waivers of any post marketing safety reporting requirement, and the information collections associated with those waiver requests are “generally are approved” under existing regulations, FDA says.

Comments are due by June 9th.

 

 

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

Medical Device Warning Letter Round-Up: FDA Won’t Take No For an Answer

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

This latest round of warning letters is all about pushback.

The FDA is not happy with the responses it received from Acme Monaco Corp., a New Britain, Connecticut-based manufacturer of medical guardwires for cardiovascular and urologic use.

In an April 28 letter, the agency reminds the company that an earlier FDA inspection revealed that these devices are adulterated within the meaning of section 501(h) of the Act, 21 U.S.C. § 351(h), in that the methods used in, or the facilities or controls used for, their manufacture, packing, storage, or installation are not in conformity with the current good manufacturing practice requirements of the Quality System regulation found at Title 21, Code of Federal Regulations (CFR), Parts 820.

Mar Cor Purification in Minnesota was hit with an April 17 letter that found fault with, among other things, its CAPA, complaint handling, and document control. In addition, the FDA said Mar Cor’s March responses were inadequate. Mar Cor manufactures water purificaiton systems used to diagnose diseases.

FDAlogoHeading over to Wisconsin, a March FDA letter hit Cytophill Inc, a manufacturer or synthetic bone graft material, bone void fillers, and an intranasal splint, for a number of shortcomings.

In addition to hitting the firm for below mark CAPA, process and storage controls, FDA warned it about failure to:

  • Control environmental conditions
  • Validate a process whose results cannot be verified by subsequent inspection and test
  • Establish procedures to handle changes to a specification.

As many former FDA inspectors have told us over the years, a bad response to a warning letter is a really bad idea. Most FDA inspectors will work with you if they believe you are acting in good faith to correct the problem. It’s not unlike the IRS. If you call them and work out a lenient, reasonable payment plan, everything’s fine. Unless you miss a payment or two without giving them a heads-up. That’s when the trouble usually begins.

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

The Six C’s of Document Management Best Practices for Life Sciences

Jeff Mazik, Vice President, Life Science Solutions, AssurX

Jeff Mazik, Vice President, Life Science Solutions, AssurX

Implementing a best practice solution for any quality process is essential to help an emerging Life Science company insure compliance and quality for their organization.  Especially when it comes to Document Management, regulatory agencies in the Life Science industries expect that your company has proper controls in place that insure the documents you are using have been properly authored, reviewed and approved and that your staff have been adequately trained on them and, of course, can easily access and use the effective documents at all times.  As documents are truly the backbone of all of your quality processes, this is indeed appropriate.  For if your documents are not controlled, neither will be your processes.

Utilizing an electronic Document Management System is the first step.  A workflow and task-based electronic system can provide you with a central repository for all documents and gives you the potential to implement an infrastructure that allows for much more control and interoperability than if you try to manage documents manually or on a server file share.  Some advantages of using a workflow based process include activity reminders for those tasked to do work, automated activities and notifications, virtual collaborations, metrics tracking, and providing overall increased control and visibility.

electronic document managementMany start-ups and emerging companies in the Life Science industries are constrained in a number of ways, particularly in funds and resources.  This can present many hurdles in trying to get a useful Document Management System in place.  In order to minimize costs and expending copious resources, some options to consider include: selecting a solution that can effectively address multiple business or quality needs to increase ROI, a solution that provides a lower cost option of hosting off-site (e.g. Cloud based solution), one that utilizes non-proprietary infrastructures, and one that can be configured without requiring programming resources.

A best practice approach for implementing an electronic Document Management system can be summed up into “Six C’s”.  These six terms help identify the areas that should be addressed when implementing an electronic Document Management system.  The Six C’s are:

Consistency:  Use the system as a central repository for all documents, implementing consistent workflow path(s) for documents depending on document type.  Use consistent Document Templates and standardize attributes (e.g. approvers, periodic review timelines) for similar document types.

Communication: Information must be easily available to your staff throughout the
workflow process, allowing virtual collaboration no matter where the team is located.  Furthermore, those people in this document review/approval process that are assigned tasks must be provided communication and follow-up reminders to insure their tasks are being completed on-time and never “fall through the cracks”.  Finally, notifications of new and revised documents must be communicated effectively to the training organization to insure requirement employee training is accomplished.

Client experience: The electronic system should incorporate end-user functionality that increases performance and acceptance such as: including built-in instructions within the process itself as well as visual hints or cues that make it obvious to the user where the document is in the process and what to do next.  Also, provide varied search functionalities and options that allow users to easily find documents they need.  Plus, automate as many activities as possible, especially those that can be easily forgotten by a user, causing re-work.  

Control: As with any validated system, changes to the process need to be controlled and managed under change control procedures.  Control of the “original” electronic document files themselves is also an important concept.  Insuring there is no back-door to access/change documents at a file server level or shared folder perspective is very important.

Compliance: The electronic system must meet all applicable regulatory requirements (e.g. 21 CFR Part 11).  Also, implementing reminders and escalations when tasks are due (or late!) helps you to stay in compliance to objectives and agreed upon timelines.  Furthermore, by implementing an effective integration with a training management system allows you to stay compliant with employee training requirements.

Configurability: The solution you use should be easily configured, maintained, and updated, breaking you from a strong reliance on costly programmers, consultants, and specialized IT resources to make a change or to add a step to the process.

If you are interested in getting more detailed information on the Six C’s of Document Management Best Practices please request to view our recent 60-minute “Life Science Best Practices for Document Management” Webinar here.

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare