FDA Regulation of Mobile Medical Apps


The latest communication from FDA regarding regulation of medical apps notes that mobile medical apps can greatly help patients be proactive and vigilant about their own healthcare. There has been increased demand for medical apps, and many of the apps depend on high levels of feedback between patients and clinicians. The FDA wants to regulate the apps efficiently, in a way that is tailored towards the risks and benefits of the apps.

If an app is intended to treat, diagnose, cure, mitigate, or prevent disease or other conditions, it will likely be considered a medical device subject to FDA regulation. Traditional hardware-based devices undergo change more slowly – and the traditional regulatory framework assessed moderate- and high-risk devices via a lengthy premarket review process. Software as a medical device (SaMD), on the other hand, is unique and constantly evolving.

The FDA responded to SaMD in 2011 with “Guidances with Digital Health Content” and some deregulation. The FDA has continued to oversee SaMD (including mobile medical apps), and recently the International Medical Device Regulators Forum (IMDRF) have established a framework for efficient SaMD review that meets patient and developers’ needs. In 2017, the FDA guidance document, Digital Health Innovation Action Plan, described the agency’s plan for a new regulatory model for digital health technologies consistent with the IMDRF policies – including the precertification program for developers to be assessed for quality in order to qualify for streamlined or no premarket review. Continue Reading

What the FDA Is Looking for In a Benefit-Risk Assessment


What concerns FDA when conducting a benefit-risk assessment of medical devices? The answer is a long list of variables that can vary by type of device, target population, and indications for use, but the clear focus is on patient safety and benefit. The FDA considers both the device benefit-risk assessment, as well as evidence and data showing the benefit-risk factors related to availability, compliance, and enforcement. Continue Reading

FDA MDDS – Still confusing after all this time


FDA regulation of Medical Device Data Systems has changed significantly over the years. This together with the blurred line between MDDS and general health information technology, interfaces between MDDS and regulated medical devices, the actual criteria for deciding if something is classified as a Medical Device Data System, and different regulatory requirements outside the US leaves significant confusion despite FDA’s attempts to clarify their current position.

FDA’s use of the term Medical Device Data Systems (MDDS) makes it pretty clear that MDDS fit the definition of a Medical Device in medical device law and regulation. So, the real question is how does FDA choose to regulate MDDS at a given point in time or by specific staff in specific situations. At one point FDA put significant effort into ensuring that industry understood that MDDS are regulated and compliance with the 21 CFR 820 and related regulations was required and this was specifically stated in an actual classification rule 21 CFR 880 in 2011. Representatives of FDA also worked with the Association for the Advancement of Medical Instrumentation on AAMI / ANSI SW87:2012, Application Of Quality Management System Concepts To Medical Device Data Systems which was released in Jan 2013. Continue Reading

Retrospective Validation


I don’t even really like to use the word retrospective. I prefer to use the term validation or revalidation. Validation of software and computer systems used to automate regulated activities or record keeping is required for compliance with FDA regulations. In a situation where this has not been performed prior to actual use of the automation, non-compliance with FDA requirements becomes an historical fact and regulatory exposure remains.

Retrospective validation was a term initially used by FDA several decades ago when it first began requiring computer system validation and many systems were already in use without validation procedures or evidence of validation. Special techniques were permitted to retrospectively demonstrate that a computer system works properly. This generally applied to cases where there was independent historical evidence that could be collected and used to show proper operation. An example would be an automated sterilization system used in manufacturing where data from independent logging devices recorded key process variables such as pressure and temperature. This type validation was not intended by FDA to be acceptable practice going forward. The validation requirement was intended to ensure the computer system was proven to work properly for its intended regulated purpose prior to relying on it in production or the quality system. Of course, there are also FDA requirements for design control, verification, and validation of software used in medical devices or as a standalone medical device itself. Continue Reading

How 21 CFR Part 11 Affects V&V


All FDA regulations and ​​guidance are available for free online, but this doesn't make interpretation or implementation any easier.

One of the most important aspects of Part 11 is the applicability. Does it apply to your software? Are you dealing with actual product software or quality system/manufacturing software? In certain cases, actual product software may be subject to Part 11 requirements, but more likely it is the quality system/manufacturing software that must comply. If it does apply, one thing is sure - the FDA recommends a "narrow interpretation scope" to prevent unnecessary overhead.

Here are some helpful questions you should ask:Continue Reading

The First Step of Medical Device Software Validation


Every journey starts with a single step, and often, it’s hard figuring out what that step should be when you need to validate a medical device to the expectations of FDA. Below are some high-level steps in order to kick-start your validation:

Step One: What standard operating procedures are applicable to the product you are responsible to follow? Are the procedures appropriate for the software requiring validation? Determine what process standards may be required for the medical device development. For example, should the process comply with IEC62304? For software as a medical device (SaMD) products you may want to follow a process that complies with IEC82304? For risk management, ISO14971 is likely applicable. Standards will likely give you confidence in the approach to validation and let you know what is required along the way.

Note: If no policies or procedures exist, then it’s time to create them. Consider writing a ’heavy’ plan that provides process requirements that comply with standards. Continue Reading

Epics, Stories, and the Epic Story of Agile Medical Device Companies


A short, short time ago, in this very own galaxy some companies were not making blockbusters, but medical devices. Whispers of quicker development times and better testing made the way past the water cooler until it became time to indulge and implement the mythical software development lifecycle. With the changes came weird language and rumors that the company would now create epic stories and employees would be running very fast around the building (e.g., sprinting).

Spoiler alert: There is no forced exercise, but employees would actually be writing stories and epics.

Conventional waterfall models use versions and products as the development rollercoaster. Someone (hopefully) writes the software requirements, then an exclusive group reviews and approves them. Then came the very difficult task of software design and how it should be documented. And, “what about the architecture – did it ever get copied from the whiteboard into a document?” Next, the software is implemented by “I code – I don’t document” Donnie and when that is almost finished, “do I have to test all that” Connie starts testing the software. Continue Reading

HealthIT and Software as a Medical Device


So what if my software for a medical application is "stand-alone”? That is, it simply runs on standard computing platforms - no custom hardware. What safety standards apply or would be useful for ensuring safety? Certainly 62304 provides the basic elements of the software development lifecycle, but 62304 stops at "verification" and purposely does not cover product level validation level aspects. 62304 does require use of a quality system with design validation at the system level and ISO 14971 for device risk management, but 62304 is scoped for medical devices, not HealthIT in general. This leaves a gap for stand-alone medical applications considered Health IT but not a medical device. Continue Reading

Contact Us

3 + 5 =

T: (813) 766-0563