February 26, 2015

FDA Applauds GUDID Progress, Eyes Class II Compliance Efforts

Jeff Mazik, Vice President, Life Science Solutions, AssurX

Jeff Mazik, Vice President, Life Science Solutions, AssurX

The Food and Drug Administration (FDA) reported that there have been over 240 user accounts setup in the agency’s Global Unique Identifier Database (“GUDID”) since the rule’s effectiveness date, and from those accounts there have been over 33,000 Device Identification numbers entered into the GUDID. This was identified as a very good start by agency personnel at the 6th Annual UDI conference this week in Baltimore.

The deadline for all Class III Medical Device manufacturers has now passed and the agency thanked those that have worked so hard to get in compliance by last month’s due date. It also shared updates and lessons learned over the last 13 months since the rule was finalized and released.

The clock now starts ticking for manufacturers (FDA uses the term “labelers”) of Class II devices that are implants, life sustaining or life supporting in nature. These labelers must complete their UDI implementation and enter their Device information into the FDA’s GUDID by September 24, 2015.

FDAlogoHowever, FDA said that the labelers of these Class II life sustaining/supporting devices will not be granted user accounts until January of 2015, at the earliest. This does not mean that this group of manufacturers should stand around doing nothing, though. There are many preparatory and investigatory activities that this group should begin actively moving forward on. Some of these activities include developing a project team, reviewing current labeling processes and artwork, identifying/obtaining a DUNS number (if one is not currently defined for the labeler), and most importantly, ensuring upper management is aware and fully supports the UDI initiative in their organization in order to drive internal commitment and resources.

Attendees also were informed that all other Class II devices must be in compliance by Sept 24, 2016, and all Class I devices by Sept 24, 2018. Unfortunately, if the current practice remains in effect, those labelers in these other two groups will not be given account access to do any submissions until late 2015 or early 2016. For now, the FDA will focus only on Class III and Class II implants/Life Sustaining/Life Supporting labelers.

Other topics during the conference included recaps of the UDI Rule and GUDID system. One interesting update: the FDA’s UDI web interface will no longer be made available to the public/healthcare workers for directly accessing and searching the GUDID for medical device information. FDA’s UDI group has recently partnered with the National Library of Medicine, and will be integrating the GUDID with the NLM’s online system for public searches, database downloads, and web service access of medical device information stored in the GUDID. This will reportedly be available 1st Quarter of 2015.

Although the first phase of UDI compliance with Class III labelers has been deemed successful, it was reported that there have been several dozen extensions provided to members of this group. However, the FDA hasn’t said if extensions will be granted to Class II or Class I labelers, as well. So, if you haven’t already, it is in your best interest to start your UDI project soon.

If you are interested in seeing a low-cost solution for UDI record management that provides electronic submissions to the GUDID, and integration to other quality processes, such as complaints management, please request a demonstration.

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

FDA Works to Soothe Industry at Medical Device Cybersecurity Webinar

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

The FDA will focus more on a device maker’s overall approach to ensuring cybersecurity rather than burrowing down and kicking the tires on each individual risk mitigation program, FDAs Abiy Desta said at an agency webinar Oct. 29.

That’s not to stay the agency is lightening up on its quest to make industry take device cybersecurity seriously. Rather, it appears to be the FDA’s way of reminding device makers to focus first on addressing the overall big picture with a sound rationale and then apply it to any number of potential risks down the decision tree.

In its Oct. 2 guidance “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices,” the agency laid out its basic requirements, though at today’s event the agency stressed it would accept other approaches — as long as their strategy was defensible.

That “alternate” approach must have controls in place, and be able to prove to the FDA that its program contains the proper response to those controls as outlined in the premarket submission.

Cyber SecurityDesta, Office of the Center Director at the Center for Devices and Radiological Health (CDRH), also urged industry to take advantage of the FDA’s posted consensus standards contained on page 7 of the Oct. 2 guidance. It’s available online. To use it, type “security” in the title search to find the current list of IT and medical device security consensus standards recognized by the FDA. It’s a handy reference.

He also outlined some of the core functions FDA wants to see addressed in a comprehensive cybersecurity program, including:

  • Limiting access to trusted users by using layered privileges, appropriate authenticity, and strong passwords.
  • Protecting users and data by terminating sessions after a period of inactivity, setting up physical locks, and limiting access ports.
  • Detecting, responding and recovering by implementing features that tell a user if the device has been compromised, provide information on what to do when it occurs, implement features to preserve critical functions with the ability to reboot and recognize drivers, and provide methods for retention and recovery of device configuration.
  • Establishing a hazard analysis program that clearly evaluates risk potential, provides information on control put in place and the appropriateness of those controls to mitigate an identified risk, and a matrix that links cybersecurity controls to the risk being mitigated.

Finally, the agency expects to be able to read a document that shows a plan to provide patches and updates as needed and that assures overall device integrity.

While FDA noted that cybersecurity is also the responsibilty of others in the chain including hospitals and patients, it made it clear that the first place it will look in the event of a breach is the device maker’s office.

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

Medical Device Cybersecurity Risks Are The Wrong Kind of Halloween Fright

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

Well, Halloween is approaching boys and girls. And while it’s fun to don a Dracula (or Miley Cyrus) costume and get some yucks faux scaring folks, the FDA is acting like a responsible parent by setting up a medical device cybersecurity educational seminar later this month in Arlington, VA. It appears to have filled up already, but a webcast recording will be made available.

Getting a tiny adrenalin rush when a nine-year-old Frankenstein jumps out at you in the dark is one thing; finding out some nineteen-year-old hacker has infiltrated your proprietary product and customer information isn’t the right kind of fright.

Seems like someone out there in the bureaucracy has a little sense of humor, because October is National Cybersecurity Awareness Month. FDA, along with the Department of Health and Human Services and the Department of Homeland Security, hope to bring together a wide swath of stakeholders, including medical device makers, to their Oct. 20-21 “Collaborative Approaches for Medical Device and Healthcare Cybersecurity.”

Participants will be encouraged to help regulators identify barriers to promoting medical device cybersecurity; discuss innovative strategies to address challenges that may jeopardize critical infrastructure; and enable proactive development of analytical tools, processes, and best practices by the stakeholder community in order to strengthen medical device cybersecurity. It’s shaping up to be a good agenda, but it’ll probably only be as strong as the attendees who show up to share war stories and discuss best practices with regulators and others.

iStock_000020037007SmallBroadly speaking, the symposium hopes to help advance medical device cybersecurity by swapping information about the most current online threats, identifying gaps, advancing usage of the feds’ “Framework for Improving Critical Infrastructure Cybersecurity”, and developing tools and standards to build robust, comprehensive protection programs, among other areas of focus.

One of the topics will be the FDA’s new guidance “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices,” released Oct. 2. That guidance provides some helpful definitions (helpful in the sense that this is how the FDA views the world), and what kind of cybersecurity protection program the agency expects from medical device makers and their kin.

Some say the threat of medical device security hacks has been hyped up a bit. I’m no expert there. But a report issued earlier this year from a cyber expert at SANS Institute (sponsored by cybersecurity vendor Norse), says some 94% of medical institutions report being victims of some type of cyberattack. This isn’t a report specifically about medical device makers, and I’m certain the vast majority of the attacks were relatively small and easy to thwart. Regardless, those numbers deserve some attention.

Hyped or not, I don’t imagine you’ll see an attendee at FDA’s event getting a jump on Halloween and showing up dressed as a sophisticated hacker, though. That’s just too scary.

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

The FDA is Reading Your Facebook Page and They Don’t ‘Like’ What They See

Tamar June

Tamar June, VP, Strategic Marketing, AssurX, Inc.

In a previous post we looked at the FDA’s relatively ho-hum guidance on social media. Since then, the agency has issued an interesting warning letter to a Utah-based dietary supplement maker for, among other alleged infractions, “liking” off-label claims made about its product on Facebook.

In its warning letter, the FDA has determined that the supplement maker’s website promotes conditions that cause products to be drugs under section 201(g)(1)(B) of the Federal Food, Drug, and Cosmetic Act (the Act) [21 U.S.C. § 321(g)(1)(B)] and that the products are intended for use in the cure, mitigation, treatment, or prevention of disease. Examples of violation in the warning letter include:

  • “[C]linically supported to work fast and offer congestion relief so you can breathe better in every season”
  • “Proven congestion relief”

But it doesn’t stop there.

The FDA then continues with the company’s Twitter page, pointing out additional “evidence” that their products are indeed intended for use as drugs because the page has a direct link back to the company’s website where products can be purchased. The letter provides two examples of tweets that bolster the FDA’s case.

  • On February 7, 2014: “Try @Zarbees #naturalremedies for Cold and Cough Season…”
  • On January 30, 2014: “RT@MomCentral Have you tried #ZarbeesCough for cold and cough relief?”

And then there’s Facebook.

Once again, the letter points out the website link from their Facebook page where these products can be purchased. According to the FDA’s letter, “Your Facebook page also contains evidence of intended use in the form of personal testimonials recommending or describing the use of products for the cure, mitigation, treatment, or prevention of disease.”

The FDA also specifies nine instances of the company “liking” or replying to comments made by satisfied customers claiming various degrees of symptom relief or cures.

facebook Is this warning letter a blip, or could it be the start of a new FDA online enforcement trend? Because this one was sent to a dietary supplements maker, an industry segment that plays it pretty loosey goosey with claims in the first place, it’s not clear whether this kind of scrutiny will spill over into the medical device and drug market segments. We’ll keep an eye out and report back as newer warning letters emerge.

Customers can praise your products all they want, but don’t you dare “like” any of them.

As interactive technology and social media increasingly plays a prominent role in advertising and promotion, the FDA has attempted to issue several draft guidance documents at the request of industry. These include:

Guidance for Industry: Internet/Social Media Platforms with Character Space Limitations—Presenting Risk and Benefit Information for Prescription Drugs and Medical Devices is intended for using Twitter and sponsored links in Google or Yahoo that have character limitations.

Guidance for Industry: Internet/Social Media Platforms: Correcting Independent Third-Party Misinformation About Prescription Drugs and Medical Devices is intended to provide guidance regarding a manufacturer’s voluntary correction of misinformation that is “created or disseminated by an independent party.”

Guidance for Industry: Fulfilling Regulatory Requirements for Postmarketing Submissions of Interactive Promotional Media for Prescription Human and Animal Drugs and Biologics extends guidance beyond traditional print media to websites, chat rooms, forums, etc.

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

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