Developing mobile apps as medical devices: Understanding U.S. government regulations

What medical mobile app developers need to know


Close to a million mobile health apps are now available from 62 app stores. Many of them might soon be regulated as medical devices. In response to the ever-growing marketplace of health and wellness applications for mobile platforms, the U.S. Food and Drug Administration (FDA) issued Draft Guidance for Industry and Food and Drug Administration Staff: Mobile Medical Applications in July 2011 (see Related topics for a link). That document proposes that some mobile applications intended for medical use be considered medical devices and placed under FDA scrutiny before they can be marketed.

Mobile medical apps are apparatuses, like scalpels and stethoscopes. These apps have great power to help diagnose, treat, or heal — but they can also fail, and failure can have detrimental consequences for the user. Even seemingly simple apps are complex instruments of code, with complex implications for health. They deserve the same attention to safety and efficacy as all medical devices, both during the development life cycle and after release.

Final guidance from the FDA is forthcoming, but in the meantime, many mobile medical app developers have already sought FDA clearance or approval. As more mobile medical apps are created, regulation will tighten — whether that regulation comes from the FDA, the Federal Trade Commission (FTC), the Office for National Coordinator for Health IT (ONC), the Federal Communications Commission (FCC), and especially the Department of Health & Human Services (HHS) Office for Civil Rights (OCR). The requirements set forth in the Draft Guidance (and most likely in future regulation) consistently ask mobile medical app developers to ensure safety and efficacy, particularly in processes such as verification and validation, as well as in specific design protocols that address user needs.

This article's goal is to help mobile app developers understand the FDA Draft Guidance and its implications for their work. If medical mobile apps are subject to regulation, significant changes in development processes might be needed that could affect the time and cost involved in taking such apps to market. For example, a development team might need to change its development methodology, document proof of verification and validation (among other controls), or apply for clearance or approval by the FDA. Also, an understanding of the Draft Guidance can help mobile medical app developers understand client needs in detail and state those requirements in such a way that clearly distinguishes the end product as either a medical application or as a general health and wellness app not meant to diagnose, cure, mitigate, treat, or prevent diseases.

Why the FDA wants to regulate mobile healthcare apps

Medical device regulation came about in 1938 as great advances in medical technology were coming to the marketplace, starting with the passage of the Food, Drug, and Cosmetic Act (FDCA). In 1976, after a commission determined that more than 700 deaths and 10,000 injuries were associated with medical devices, the FDA was given the ability to review these increasingly complex medical devices before they entered the marketplace.

Today, new technologies relating to health and wellness, including mobile applications, are rapidly being developed and marketed through various platforms. Because of mobile medical apps' unique capabilities to diagnose, cure, mitigate, treat, or prevent diseases, the FDA thought it important to consider formal regulation of such apps to protect patients from injuries and deaths that might result from their use.

Mobile medical apps can pose the same risks of failure as other medical devices, including mechanical failure, faulty design, poor manufacturing quality, and user error, among other safety issues. For instance, a blood-glucose monitor that gives an incorrect reading, whether through a stand-alone glucometer or an integrated mobile medical app on a cell phone, could result in significant harm to a diabetic patient who relies on that reading's accuracy.

Another example is an app that compresses radiology images — including magnetic resonance imaging (MRI), positron emission tomography (PET), and computed tomography (CT) taken in a hospital or by a physician — and sends them via the app to another physician. The physician who receives the images can then evaluate and interpret the test results and confirm a diagnosis. However, mobile device displays can have significant variations in luminance levels, some of which can result in poor image display and misdiagnosis of important conditions.

Such was the case with Mobile MIM — one of the first mobile medical apps in the Apple App Store in 2008. Concerned about regulatory issues, MIM Software pulled Mobile MIM from the app store until the product received FDA clearance. The FDA asked for information to ensure that the quality of the images sent through Mobile MIM would not adversely affect patients because of the risk of poor image display resulting from improper screen luminance or lighting conditions. In 2011, the app finally received FDA clearance, though only after including many special controls including labeling and safety features, an interactive contrast test, and a safety guide.

Which mobile medical apps does the FDA seek to regulate?

The FDA is not seeking to regulate all apps that concern health and wellness. Primarily the FDA looks at the intended use of an app to determine whether it is in fact meant for a medical purpose or simply for general health and wellness. Part of this determination is based on how the app is marketed, promoted, labeled, or advertised. However, both the intended use and actual use will factor into whether the app is ultimately regulated as a mobile medical app.

Apps that carry a potential risk to the public if they fail to function properly are the FDA's primary concern in this arena. Many if not most healthcare apps at this point are not considered mobile medical apps. The FDA specifically states that the following are not medical mobile apps:

  • Electronic copies of medical textbooks, teaching aids, or reference materials
  • Apps used only to log, record, track, evaluate, or make decisions or suggestions related to developing or maintaining health and wellness, as long as those decisions or suggestions are not intended for curing, treating, seeking treatment for mitigating, or diagnosing a specific disease or health condition
  • Apps that only automate general office operations
  • Apps that are generic aids that assist users but are not marketed for a specific medical indication — such as a magnifying glass or notebook
  • Apps that function as electronic health records or personal health record systems

Categories of mobile medical apps that the FDA proposes it will regulate

The Draft Guidance states that the FDA will apply regulatory oversight to apps that fall into one of three specific categories that it defines as mobile medical apps. First are apps that "are an extension of one or more medical devices by connecting to such a device for purposes of controlling the device or displaying, storing, analyzing, or transmitting patient-specific medical-device data." These apps include, but are not limited to those that:

  • Enable a user to view medical images for diagnosis
  • Analyze, assess, or interpret electrocardiograms or electroencephalograms
  • Connect mobile platforms to vital-signs monitors, bedside monitors, or cardiac monitors
  • Control a blood-pressure cuff connected to a mobile platform that measures a person's blood pressure
  • Act as wireless remote controls or synchronization devices for MRI or X-ray machines

Second are apps that "transform a mobile platform into a medical device by using attachments, display screens, or sensors, or by including functionalities similar to those of currently regulated medical devices." This category might include apps that:

  • Connect wirelessly to a blood-glucose tester to display, calculate, trend, convert, or download results or act as a glucose meter
  • Act as an electronic stethoscope
  • Monitor sleep apnea or detect falls
  • Use the light source to treat and cure specific conditions
  • Score and interpret cognitive-testing results
  • Determine blood-donor eligibility

The third category consists of apps that "allow the user to input patient-specific information and — using formulae or processing algorithms — output a patient-specific result, diagnosis, or treatment recommendation to be used in clinical practice." Such apps might:

  • Act as calculators or use algorithms to produce an index, score, or scale, as in the Glasgow Coma Scale, pain index, or Apgar score
  • Calculate parameters associated with the use of radioisotopes or the amount of chemotherapy
  • Assist with patient-specific dosing
  • Calculate osteoporosis risk
  • Collect blood-glucose readings and caloric intake to help manage diabetes
  • Define disease stage or progression and provide a prognosis or predict a patient's response to treatment

The FDA proposes to regulate apps that fall into any of these three categories as medical devices. As such, they will be subject to the regulatory process discussed here.

Regulatory process: Classification, clearances, and approvals

Mobile medical apps are subject as medical devices to either the FDA 501(k) Approval Process or the FDA Premarket Approval Process (PMA) before they can be marketed. Depending on the level of control — general or special — necessary to ensure safety and effectiveness, each medical device is placed into one of three classes, which in turn affects which approval process the device must undergo.

Three device classes

Class I devices are those devices that require only general controls. They present a relatively low risk of illness or injury if they fail. General controls are provisions in the 1976 Medical Device Amendments to the FDCA that relate to adulteration; misbranding; device registration and listing; premarket notification; banned devices; notification, including repair, replacement, or refund; records and reports; restricted devices; and good manufacturing practices. Examples of Class I devices include elastic bandages, examination gloves, and hand-held surgical instruments.

The FDA defines Class II devices as "those for which general controls alone are insufficient to assure safety and effectiveness, and existing methods are available to provide such assurances." In addition to complying with general controls, Class II devices are also subject to special controls such as special labeling requirements, mandatory performance standards, and post-market surveillance. Examples of Class II devices include powered wheelchairs, infusion pumps, and surgical drapes.

Class III devices are those that support or sustain human life; are of substantial importance in preventing impairment of human health; or present a potential, unreasonable risk of illness or injury. They are devices "for which insufficient information exists to assure safety and effectiveness solely through general or special controls." For Class III devices, special controls might include meeting performance standards, post-market surveillance, patient registries, development and dissemination of guidelines, recommendations, and other appropriate actions that provide reasonable assurance of the device's safety and effectiveness. Examples of Class III devices that currently require a premarket notification include implantable pacemaker pulse generators and endosseous implants.

Many of the Class I devices are exempt from the 501(k) and PMA processes altogether. Most Class II devices undergo the traditional 501(k) process, showing that they are substantially equivalent to other devices on the market. For these devices, developers must submit notification to the FDA at least 90 days prior to their intent to market. However, Class III devices are subject to PMA. Only about 2 percent of new medical device applications must undergo PMA.


PMA is required for all Class III devices (devices that pose a significant risk of illness or injury) before they can be marketed (by being available in an app store, for example). Many medical devices that need to obtain PMA are novel — not seen before on the market — such as the Mobile MIM app. When MIM Software's app came out in 2008, it could not easily be compared to other mobile medical apps that could be defined as Class I or II devices — no "substantial equivalent" existed — and thus the FDA categorized it as a Class III device. Now, however, with the proliferation of mobile medical apps seeking FDA approval, developers of new apps might be able to avoid the PMA process by finding substantially equivalent apps that have already been cleared or approved.

Still, if the FDA finds that the mobile medical app might pose risks that are life-threatening, result in permanent impairment, or necessitate surgical intervention to preclude permanent impairment — regardless of the comparison to other devices — PMA will be required. A PMA application must include documentation that estimates the severity of injury or illness the app could permit or inflict, including through device failures or design flaws.

General controls: Quality System Regulation

All devices, regardless of class, are subject to basic regulatory requirements that include:

  • Establishment registration
  • Medical Device Listing
  • Quality System Regulation (QSR)
  • 510(k) or PMA
  • Labeling requirements
  • Medical Device Reporting, Reporting Corrections, and Removals
  • Investigational Device Exemption for clinical studies

QSR is of particular importance to mobile medical app developers. The FDA requires mobile medical app manufacturers to comply with QSR — also known as good manufacturing practices (GMPs) — which includes developing requirements for an app to ensure its safety and effectiveness and establishing methods and procedures to design, produce, and distribute their devices.

QSR requires that:

  • Various specifications and controls be established for devices
  • Devices be designed under a quality system to meet these specifications
  • Devices be manufactured under a quality system
  • Finished devices meet these specifications
  • Devices be correctly installed, checked, and serviced
  • Quality data be analyzed to identify and correct quality problems
  • Complaints be processed

Additionally, as part of QSR, mobile medical app developers are required to verify and validate their apps.

Among the many aspects of QSR, this article's focus is on verification and validation (V&V) and design. These aspects are unique to software development — particularly mobile medical app development — because of issues such as branching, constant updating, failures that can occur with little advance warning, and seemingly insignificant changes in code that can create unexpected and significant problems elsewhere in a program.

QSR does not prescribe which practices must be used in developing and implementing V&V — or design controls (discussed below). Rather, the FDA provides guidance as to how to integrate software life-cycle management and risk-management activities to meet these requirements.

Much of the emphasis in all of QSR is on documentation and traceability, particularly for V&V. The type of life-cycle management approach a developer undertakes — waterfall, agile, or V-model, for example — can affect the developer's approach to meeting regulatory requirements. For more information on the interaction of life-cycle approaches and medical device regulation, see "Being agile while still being compliant: A practical approach for medical device manufacturers."

FDA guidance on software validation

Between 1992 and 1998, the FDA found that 242 of 3,140 (7.7 percent) medical-device recalls were attributable to software failures. Of these, 192 were caused by software defects introduced when changes were made to the software after its initial production and distribution. Considering that this time frame does not include complex technological advances made in the last 15 years, one can only imagine the number of recalls attributable to software failures that could occur in mobile medical apps. With increasingly complex systems, the possibility of failure through defects in software increases exponentially, reinforcing the need for validation.

The FDA provides guidance on general principals of software validation for software that is:

  • A component, part, or accessory of a medical device
  • Itself a medical device
  • Used in the production of a device
  • Used in manufacturing design and development or other parts of the quality system

Through validation, mobile medical app developers can gather evidence that the final product is safe, effective, and ready for clearance or approval. In addition, the validation can increase usability and reliability, which will result in decreased failure rates, fewer recalls, less risk to patients and users, and reduced liability.

The FDA considers software validation to be:

Confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled.

As part of validation, the FDA requires software developers to define, document, implement, and maintain procedures for validating medical device design.

Whether software is validated depends on comprehensive software testing, inspections, analyses, and verification tasks performed at each stage of development. But the FDA realizes that manufacturers cannot infinitely test their software. Thus, software validation must be based on a "level of confidence" established through the verification activities, which will differ for each app.

Because validation is dependent on each individual app's complexity and safety risk, when considering whether a "level of confidence" is met, software developers should keep principles of documentation and defect prevention in mind. To be most effective, they should implement verification processes in early development stages and continue throughout the software life cycle. Defining a plan — including scope, approach, resources, schedules, and the types and extent of activities — and executing the plan through clear procedures will guide them through the validation process. Ultimately, software developers are responsible for proving validation regardless of the processes used to achieve it.


Design is of particular importance when considering mobile medical apps. These apps often place intricate tools in the hands of doctors and patients — tools that can affect health outcomes significantly — and so must be designed with usability in mind. Special attention should be paid to how the software addresses human factors including user errors that are due to design. Again, consider the example of an app for testing blood glucose levels. If a user cannot understand and interact with the app, the result of the test, or perhaps inability to test at all, could seriously affect treatment for a diabetic patient.

To ensure the design and later validation of a safe and effective mobile medical app, designs should specify (among other details):

  • Risk analysis
  • Hardware to be used
  • Built-in error, alarm, and warning messages
  • Communication links to hardware and user
  • Security measures

After design specifications are developed, they should be verified by a traceability analysis, and at least one formal design review must be performed. The design review should comprehensively document and systematically examine the design to evaluate the adequacy of design requirements and identify problems. A proper design review enables developers to confirm that all the goals defined in the software validation plan have been met and that the design is complete, correct, consistent, unambiguous, feasible, and maintainable.

Changes in software

Even a small change in software can drastically change how a mobile medical app functions. Changes might come about from debugging, changes in requirements, modifications in design, or on request by the FDA to "correct problems." To ensure the continued safety of mobile medical apps, any change in software should undergo its own "mini life cycle" and validation process. Regression testing should show that the changes were implemented correctly and, most important, did not adversely impact other parts of the software product.

If mobile medical app developers voluntarily or on request by the FDA make corrections to an app, they must report the correction within 10 days to the FDA if the correction is to reduce a risk to health posed by the app or remedy a violation of the FDCA that presents a risk to health. Regardless, any corrections must be documented.

Furthermore, if the change affects the safety or effectiveness of a device that has already been approved, a medical mobile app developer must submit a PMA supplement including PMA amendments — or additional information — for the FDA to review. Changes that need PMA supplements include new indications for the mobile medical app and changes in the performance or design specifications, circuits, components, principles of operation, or physical layout of the app if these changes affect the safety and effectiveness of the device.

Interactions with other federal laws

With an eye toward patient protection through regulation of mobile medical apps — from their development, to market clearance, to monitoring changes that affect safety and effectiveness — the FDA is one of the first government agencies to provide regulatory guidance. Other agencies are beginning to join these regulatory efforts and provide their own guidance, including the FTC, ONC, FCC, and OCR.

The FTC is charged with preventing deceptive or unfair business practices and enhancing informed consumer choices. It enforces truth-in-advertising laws by investigating false advertising. In September 2011, the FTC settled with the developers of Acne App and Acne Pwner, who claimed that a light emitted from the screen of a mobile device would cure acne when the device is held next to the skin. These apps were based on no competent and reliable scientific evidence, and in fact the light emitted was not in the right spectrum to provide any kind of light therapy.

The ONC supports the adoption of health information technology through health information exchanges, electronic health record (EHR) certification, and developing rules for Meaningful Use. Several industry leaders and politicians would like to see the ONC lead the efforts in regulating mobile medical apps. If the ONC were to regulate apps, it might implement a certification process like that used for EHRs. Currently the FDA is charged with consulting with the ONC and FCC to produce a report that proposes a strategy and recommendations for an "appropriate, risk-based regulatory framework pertaining to HIT, including mobile medical applications...."

The FCC regulates interstate and international communications by radio, television, wire, satellite, and cable. In 2010, the FTC released a National Broadband Plan, which, among other things, pushed for the development of strategies to facilitate the use and development of health information technology and called for collaboration with the FDA to develop a regulatory approach to mobile health technologies. In 2011, it dedicated spectrum for Medical Micropower Networks (MMNs) and in 2012 adopted rules to allocate spectrum for Medical Body Area Network (MBAN) devices, making the United States the first country to set aside spectrum for this technology, which can help doctors remotely monitor patients' vital signs. Considering the FCC's proactive approach, more guidance and a push for clarification on the use of medical mobile apps will most likely come soon from this agency.

Finally, the OCR, which enforces regulations from the Health Information Portability and Accountability Act (HIPAA) and the Health Information Technology for Economic and Clinical Health (HITECH) Act, has already entered the regulatory space for mobile medical apps with the January 2013 release of HIPAA "Omnibus Rules." The OCR is charged with ensuring the privacy and security of personal protected health information (PHI). With this release updating the HIPAA Privacy and Security Rules, the OCR clarifies that entities that create, receive, maintain, and transmit — functions typical of mobile medical apps — are subject to regulation and direct liability for breaches of PHI. As mobile medical apps become more complex and integrate with other systems or devices, privacy and security scrutiny will likely increase.


Conservative estimates say that by 2017 at least 1.7 billion people will download health-related apps. Many such apps can be used — intentionally or not — to diagnose, cure, mitigate, treat, or prevent diseases and thus might come under FDA regulation. Developers should be aware of the proposed regulations issued in the FDA's Draft Guidance for Industry and Food and Drug Administration Staff: Mobile Medical Applications and how they affect development processes.

The FDA has stated that final guidance on mobile medical app regulation will be a priority for 2013. In concert with other government agencies, final guidance is needed to clarify regulation that might deter developers from entering the realm of health information technology and impact getting apps to, or keeping them in, the marketplace. In addition, final guidance will clarify how to ensure that consumers have access to safe and effective products to improve their health.

Going forward, medical mobile app developers should discuss a client's intent at length when developing an app that addresses health. They should define the app's intended use as they set out requirements and specifications, being aware that requirements can change throughout the software life cycle. As they discuss intent, clients and developers should focus on design, particularly usability. Throughout the process, validation requirements should be incorporated, including sufficient documentation so that the FDA can appropriately review a 501(k) or PMA submission. Then if changes to the mobile medical app are implemented, further validation should be performed and submitted for review as appropriate. Again, the FDA is not seeking to regulate every app that addresses health. The focus is instead on safety and efficacy for the user, which can be shown through proper verification and validation procedures.

Finally, mobile medical app developers should look to guidance from other government agencies, such as the FTC, ONC, FCC, and OCR, as each looks to take a role in regulation of these apps. Mobile app developers who follow the FDA Draft Guidance will already be a step ahead of competitors who ignore it — and can save time, money, and ultimately lives.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=Mobile development, Industries, Rational, DevOps
ArticleTitle=Developing mobile apps as medical devices: Understanding U.S. government regulations