Compliance Zen

More FDA Data Integrity FAQs

FDA updated its FAQ page on Good Manufacturing Practices with several data integrity and Part 11 related questions and answers, including:

• Why does FDA object to using actual samples to perform system suitability testing?
• Why is FDA concerned with the use of shared login accounts for computerized systems?

The answer to the latter should be obvious.  You can't prove the authenticity of the data or hold the data owner accountable if you cannot identify who actually created or modified the data.  Shared logins blur the lines and hide clarity around who created, or modified, or destroyed data.

As regards to using actual samples to perform system suitability testing, here's what FDA states:

"FDA wants to discourage the practice of “testing into compliance.” In some situations, the use of actual samples to perform system suitability testing can be a means of testing into compliance.

 

According to USP, system suitability tests should include replicate injections of a standard preparation or other standard solutions to determine if requirements for precision are met (ref. USP General Chapter <621> Chromatography). System suitability tests, including the identity of the preparation to be injected and the rational for its selection, should be performed according to the firm’s established written procedures and the approved application or applicable compendial monograph (§ 211.160). 

 

If an actual sample is to be used for system suitability, it should be a properly characterized secondary standard and written procedures should be established and followed (§ 211.160 and 211.165). All data should be included in the data set that is retained and subject to review unless there is documented scientific justification for its exclusion."

 

(see http://www.fda.gov/Drugs/GuidanceComplianceRegulatoryInformation/Guidances/ucm124787.htm#7)

 

One way to read this is to state that the use of actual samples can be too tempting for some firms.  Better for firms to all use industry-standard samples (e.g., standard solutions).

 

From FDA's perspective, if a system is tested using a standard solution, and the system works fine; then when using the firm's actual production samples, the system produces errors, the system is not at fault - the firm's actual product is faulty.  This is FDA's logic and aside from some unique, one-off situations, it's difficult to disagree.

 

Notice that all data integrity FAQs at FDA are filed under the "Records and Reports" heading; again emphasizing that data integrity and Part 11 compliance are NOT about computerized systems and software per se, and instead about:

• Reliability and integrity of the regulated data and records; and/or
• Reliability and consistency of any automated process that is a regulated process (e.g., an automated GMP or GLP or GCP processes).

If your firm needs independent guidance on data integrity, FDA recordkeeping and cost-effective Part 11 compliance, consider an onsite, private data integrity best practices workshop or an expert data integrity consultant.

Is Your Software a Medical Device – 3 Steps to Find Out

As the regulatory landscape for healthcare apps and Software as a Medical Device (SaMD) begins to firm up, there are three key steps that firms should take as they develop and commercialize smartphone apps and stand-alone software:

1. Review the current best-of-breed regulatory guidance

2. Create a yes/no decision tree to document your decision

3. Clarify the decision and communicate.

 

Step 1:  Review the Current Best-of-Breed Regulatory Guidance

There are four critical guidelines to review that software (and medical device) makers will want to read through:

• The US FDA has dedicated section on its website that summarizes FDA’s current thinking in how FDA regulates Software as a Medical Device.  If your software falls under FDA’s SaMD interpretation, you will need to comply with 21 CFR 11 Electronic Records; Electronic Signatures (e.g., Part 11), 21 CFR 820 Quality System Regulation, and 21 CFR 807 Medical Device Reporting (MDR).

• The EU released its guidance document in January 2012, Guidelines on the Qualification and Classification of Stand Alone Software Used in Healthcare within the Regulatory Framework of Medical Devices (PDF). These are the EU "regulations," but see the next two items below before you just rely upon this.

• Sweden’s Medical Products Agency has release a very good analysis of the EU’s medical app guideline (PDF) that is well worth skimming through all six pages.  On page 5 is a very nice, short summary of the requirements for the EU to view an app as a medical device.

• The UK’s MHRA released its own guidance and webpage early in 2014, Guidance on Medical Device Stand-Alone Software (including Apps), on how it will assess and regulate Software as a Medical Device, including smartphone apps. The guidance gives numerous, clear examples along with keyword functionality that the MHRA will look for which will cause MHRA to classify your software as a medical device. In addition, this guideline provides several situational clarifications for the EU’s guidance document based on recent cases.

 

Step 2:  Create a Yes/No Decision-Tree to Document Your Decision

Using information from the above guidance documents, draft a decision-tree diagram of a series of yes/no questions. This decision-tree has two immediate audiences:  the software engineers developing your software and the firm’s senior management. For both audiences, simplicity and straightforwardness is important as you should expect your initial assessment to be second-guessed.

Ideally the decision-tree will be used to help guide development and commercialization. For instance, firms may want to avoid a quick bit of functionality that will inadvertently tip an app from non-regulated into regulated territory. One yes/no question to ask might be:  “Will the app perform a calculation on the raw health data and only present the results of the calculation (rather than the raw data as well)?” In such a situation, the app is likely to be regulated as a medical device. Thus, this decision-tree can be very helpful to developers and project managers looking at different functionalities and the impact to the software; just because a set of coding may be easy might obscure that adding the code will cause the app to suddenly become regulated.

Likewise, senior management (including venture capitalists) must be comfortable with an app’s final functionality target(s) in order to decide its path of commercialization. Is the software unregulated and thus simply released, or will it require regulatory approval and/or costly compliance with 21 CFR 11, 21 CFR 807, and 21 CFR 820 in the US? This type of decision early in commercialization is critical to help executives avoid costly mistakes and potential risky product liability situations.

As an example of what a straightforward yes/no decision-tree might look like, review the EU’s example yes/no diagram on page 10 of the PDF version of its guidance.

Finally, note that by the end of 2015, the International Medical Device Regulators Forum (IMDRF) has stated its intent to release an internationally harmonized regulatory guideline, so keep an eye out for that on the IMDRF website (www.imdrf.org).

 

Step 3:  Clarify the Decision and Communicate

Document the decision-path taken to identify the regulatory status of the software. This record should be retained as part of the software development project documentation (or in the case of a Software as a Medical Device, its Design History File).

In addition, distribute a copy of this highlighted, documented decision path to the developers and any future support engineers. It’s important to communicate the need to stay within the agreed-upon functionality guidelines, not just in initial development but also in post-launch support, bug fixes, and product enhancements.

For new product enhancements and full version revisions (1.xx to 2.xx), consider reviewing and verifying the decision-tree diagram documentation; this will show a traceable path of informed decisions for each software revision.

 

For more on Software as a Medical Device, see several of my earlier blog posts:

- Poll:  Should FDA Regulate Medical Apps

- Majority of Mobile Health Apps Class II Devices for FDA

- Medical Apps, FDA and Patient Data Integrity

 

And if you need to educate your team on the regulations affecting Software as a Medical Device, how to cost-effectively comply, or help drafting the policies and procedures required, consider contacting me through the Cerulean Associates LLC website.

FDA Inspection Handling – 10 FAQs and Tips for 2014

FDA inspections are stressful and worrisome.  Failed FDA inspection costs include sales revenue loss, stock price decline, and public embarrassment from FDA warning letters and FDA-483 observations.

Every so often, it’s good to recalibrate by looking at frequently asked questions when it comes to FDA inspections.  I’ve gathered these questions, answers and tips over the past two years with clients, and with current and retired FDA officials.  When reading through these FDA inspection FAQs, use your own best judgment or that of an FDA expert you’ve hired to help you succeed.

 

1.  Does FDA look at and trend product liability litigation for food, drugs, medical devices, cosmetics, etc. in order to figure out which companies to inspect?

Yes.  The FDA is not blind to reality.  FDA’s charter is to protect public safety.  If people, through product liability litigation, are having to take matters into their own hands to go after companies for putting ineffective or unsafe products on the market, FDA could be seen as not performing its task.  So yes, FDA pays very close attention to product liability litigation.

- summarized from Lori Lawless, FDA, Office of Regulatory Affairs, and Larry Spears, retired FDA Deputy Director for Regulatory Affairs

 

2.  How does an FDA investigator prepare for an inspection?

Prior to an inspection, the investigator(s) will create an inspection plan that is largely based on the following information:

• Any previous establishment inspection reports (EIRs)
• Any previous FDA Form 483 observations, especially those that require follow-up
• Company responses (to FDA-483s) and commitments
• Firm’s website (including product literature, executive profiles, physical location profiles, recent press releases, etc.)
• Consumer complaints that have come in since the last inspection
• Adverse events that have come in since the last inspection
• Any recalls or other field activities that have occurred since the last inspection
• Any product submissions and applications, specifically to find critical components or ingredients or processes that were of concern to FDA reviewers
• Online research through the web.

Online web research can be further broken into three main areas:

• Online videos of your products in use (including if consumers have posted videos comparing/contrasting to other competing products, etc.)
• Social media sites (especially for complaints about your product)
• Searches for your company name or product name(s) along with key words (such as “review” or “fraud” or “FDA”).

- summarized from Rachel Harrington, FDA, Office of Regulatory Affairs and Tim Wells, retired FDA Team Leader for the QSIT Project

An effective, independent FDA compliance gap analysis can help you pinpoint areas to strengthen in your compliance efforts before the FDA investigator arrives.

 

3.  Is a follow-up inspection (a closeout inspection from a warning letter) still a “regular” inspection?

Yes.  FDA investigators treat a closeout or follow-up inspection as a normal inspection.  You can be cited for new or additional items.

- summarized from Lori Lawless, FDA, Office of Regulatory Affairs

 

4.  Do pre-approval inspections (PAI) rely upon QSIT, and if so, what level are they?

PAI inspections are Level 2 QSIT inspections by default.  FDA reviewers of a submission will identify areas of concern for the investigator to look at during the inspection (such as GCP data integrity controls).  PAI inspections may cover everything from nonclinical supporting GLP-compliance, through GCP compliance, to GMP compliance, and even delve into how the company will monitor and control the product once it is approved and on the market.

- summarized from Lori Lawless, FDA, Office of Regulatory Affairs, Erin McFiren, FDA, Office of Regulatory Affairs, and Tim Wells, retired FDA Team Leader for the QSIT Project

A level 2 QSIT inspection is a comprehensive inspection, covering all four major quality system subsystems - management controls, development, CAPA, and production and process controls – as well as reviewing the remaining three subsystems (facilities and equipment controls, materials and supplier controls, and records controls) throughout as these three subsystems cut across all four major subsystems.  Thus, 21 CFR 11 controls will be reviewed and inspected throughout the PAI, not just during review of the design and development (e.g., design control) subsystem.  Learn more about the details of Level 2 QSIT inspections at the FDA:  www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm244267.htm

 

5.  Will FDA investigators ask for supplier audit reports?

FDASIA 2012 expressly granted FDA the power to require supplier audit reports during regular inspections (see Title VII of FDASIA).  That said, by internal policy, FDA discourages investigators from asking for the report in the hopes that this will encourage firms to be more candid and clear in supplier audits.  Unfortunately, as was painfully shown during the recent Heparin scandal, FDA’s hope has not panned out.  Far too many firms conduct “meet and greet” supplier audits with little meaningful impact.  Thus, increasingly FDA investigators are taking advantage of FDASIA’s new powers and requesting copies of supplier audit reports.

It should also be noted that FDA has always requested supplier audit reports under various conditions as identified in the FDA Compliance Policy Guide, section 130.300, FDA Access to Results of Quality Assurance Program Audits and Inspections (www.fda.gov/ICECI/ComplianceManuals/CompliancePolicyGuidanceManual/ucm073841.htm):

• During directed or “for cause” inspections of a sponsor or monitor of a clinical trial
• In inspections where access to such records is authorized by statute (such as FDASIA)
• When public safety is at risk
• In litigation (or in support thereof)
• When executing a search warrant
• When a firm’s internal audit program is insufficient or otherwise deemed ineffective by FDA.

This last point is often overlooked.  Technically, if the FDA investigator writes down a Form FDA-483 observation that a firm’s quality audit program is insufficient, the FDA investigator can then review the firm’s supplier audit reports.  (Note:  Personally, I’m not aware of any incidents where this has occurred, and so I encourage you to be cognizant that an effective quality system audit program is necessary to show FDA you are overseeing your suppliers appropriately.)  It is thus in a firm’s interest to ensure that it has a robust, FDA supplier audit program that can withstand both FDA investigator and product liability litigator scrutiny.

Finally, always remember that FDA counts any corrective actions from supplier audits as CAPA documentation and freely open to review by any FDA investigator.

- summarized from Lori Lawless, FDA, Office of Regulatory Affairs, and Rachel Harrington, FDA, Office of Regulatory Affairs

 

6.  How does computer validation play into regular inspections?

As of the end of 2013, FDA’s special enforcement of 21 CFR 11 (e.g., "Part 11") is still ongoing.

Part 11 will come up throughout an inspection as it is a regulation that cuts across all quality system subsystems. If records are used or kept in digital form, or if a computerized system is used to automate a regulated process (such as production, lab testing, etc.), then the FDA investigator will ask Part 11-relevant questions.

FDA looks to see if you are verifying the functions that you use of a software or a computerized system in your environment, especially those functions related to data integrity.  For instance, with a  spreadsheet macro, the FDA investigator will expect to see a simple verification of your use of the macro in your environment, documented with a validation protocol, document testing, and a summary report.  Do not validate Excel, just the use of the macro within your environment.  Questions that the FDA investigator might ask include:  How do you know the results of the macro are correct?  Are complete?  Did not drop off various data inputs?  and so forth.  These types of Part 11 validation are the ones to concentrate on.

- summarized from Lori Lawless, FDA, Office of Regulatory Affairs, and David Chesney, retired FDA District Director

 

7.  How does FDA handle a situation when – during photo taking during the inspection – confidential patient information and/or trade secret information is accidentally captured in the photograph?

FDA treats all photographs, videos, documents, notes, etc. as confidential.  All such items go through FOIA to redact such sensitive information before they are released.

- summarized from David Chesney, retired FDA District Director

Personally, I suggest you consider making sure to identify in your inspection notes what photographs the FDA investigator took; if possible, take a similar photograph.  Then, in your response to the inspection, make sure to identify the photograph and any specific confidential or trade secret information that may have inadvertently been captured by the FDA photograph.  This will help FDA to redact the appropriate information while providing you some degree of assurance that they understand and acknowledge the situation.

 

8.  Where is FDA on adapting or accepting remote or online/virtual inspections?  Is FDA ready for online/remote inspections like a number of other notified bodies?

FDASIA 2012 granted FDA the power to conduct remote and even online/virtual inspections.  However, FDA is currently not positioned to take advantage of this.  The agency is planning to start a pilot program wherein part of the inspection will be conducted remotely (e.g., remote document review) followed by a briefer onsite inspection portion.

Keep in mind that at its core, FDA is a regulatory enforcement agency.  As such, during inspections, it is technically collecting evidence.  For companies doing all the right things, it is in their interest to have FDA investigators physically visit and see firsthand how well the company is doing.  For firms with more … “soft” …. approaches to compliance, a remote or online/virtual inspection has less of a chance to uncover gaps.  FDA is well aware of this.  In order to address this, expect FDA over the next few years, to take a two-step approach to an inspection:  part one is a remote review of policies, SOPs, etc., (presumably through PDFs sent to the agency); this will then inform and shape part two, the onsite inspection.

- summarized from Lori Lawless, FDA, Office of Regulatory Affairs, and Rachel Harrington, FDA, Office of Regulatory Affairs

When I conduct FDA compliance gap and remediation analyses, I prefer this two-step approach because it provides a high degree of efficiency, effectiveness, and enhanced ROI for everyone involved.

 

9.  What are “management discussion items” and what are the implications to a firm?

Management discussion items are non-compliance observations not written onto the Form FDA-483.  Management discussion items are compliance deviations that the FDA investigator believes to be of lesser significance than the documented 483s.

However…

Management discussion items can still end up as warning letter citations because the FDA district office or FDA head office believes they are more serious than originally assumed. Thus, if you address management discussion items in your response to FDA, you may want to notify the district that you are working to resolve the items as well as the written 483 observations.

Keep in mind that to FDA, as long as an observation of non-compliance was documented in the FDA investigator’s notes, written on a Form FDA-483, or spoken about to a firm's management, FDA considers the observation “documented by FDA.”  FDA is, at its heart, an enforcement agency collecting evidence when it conducts an inspection.

Finally, be aware that management discussion items can be treated as repeat violations if found again in a follow-up or a second FDA inspection.

- summarized from Rachel Harrington, FDA, Office of Regulatory Affairs, Erin McFiren, FDA, Office of Regulatory Affairs, and David Chesney, retired FDA District Director

 

10.  How long after an inspection will we receive a copy of the EIR (Establish Inspection Report) and/or any warning letter?

Technically, up to 45 days after the inspection.  In reality, depending on the type, depth, and other FDA inspection conditions, it can be up to 3-6 months after the FDA investigator leaves.  Nonetheless, your FDA inspection response and remediation plan is still due to the agency within 15 business days after departure of the FDA investigator.

- summarized from Lori Lawless, FDA, Office of Regulatory Affairs, Tim Wells, retired FDA Team Leader for the QSIT Project, and Larry Spears, retired FDA Deputy Director for Regulatory Affairs

 

If you have any further questions, or need help complying cost-effectively with FDA regulations, please contact me through my consulting firm, Cerulean Associates LLC.

Poll: FDA Should Regulate Medical Apps

In a new poll, 68% of physicians, healthcare professionals, medical app developers, and members of the general public voted that the FDA should regulate medical apps.  You can see the results and a discussion of the poll online at The Profitable Practice blog.

For app developers, the key point to keep in mind is that FDA is only planning to regulate software apps that will “transform a mobile device into a medical device already regulated by the FDA” or that can be used “as an accessory to a medical device.”  This is in line with the common sense approach taken by a number of EU member states such as Sweden.

Back in a March posting Should FDA Regulate Medical Apps?, I noted that the vast majority of so-called “medical apps” or “health apps” are really geared for the general public and layman to provide basic medical or health information. Trying to regulate these 17,000+ apps would bring FDA to its knees even if all of its personnel were magically transformed into medical app expert reviewers. This point was taken up and agreed to by FDA’s Baku Patel, as I pointed out in a July posting, Majority of Mobile Health Apps Class II Devices for FDA.

Now, with the release of FDA’s final guidance on medical apps, FDA has stepped back from the precipice and taken the more common sense approach advocated by this blog, the EU, and by the many, many critics of FDA’s initial draft guidance on mobile health apps. FDA’s regulatory focus is on apps that – if they malfunction – have a direct risk of harming the patient.

With this approach, FDA will not inadvertently treat the Apple, or Google, or Amazon’s app stores as distributors or pharmacies. This was another minefield in the initial draft guidance that is now resolved.

That said, Apple has formally implemented a policy for new medical and health apps on its app store wherein developers need to provide specific medical citations and sources for any medical information contained in an app.  This is no different than how medical journal articles must cite sources.  Read more about Apple’s new policy on health app medical source requirements.

See the FDA press release on the new mobile medical app final guidance

Download the final FDA mobile medical app guidance

Read more about the poll conducted by medical software resource Software Advice

List of 21 types of health apps that FDA will not regulate.

Majority of Mobile Health Apps Class II Devices for FDA

A June interview with FDA’s Bakul Patel, author of FDA's draft guidance on mobile medical apps, revealed that the majority of mobile health apps FDA has reviewed to date are classified as Class II Medical Devices.  Of the 27,000 medical apps available today, FDA has reviewed less than .003%.  Classifying even ten percent of the 27,000 medical apps as Class II Medical Devices risks bringing FDA to its knees, dramatically increasing the number of inspections and enforcement actions FDA needs to take each year.

As more developers around the world jump into the fast paced medical app business, the problem will get worse.  Compounding this is the lifespan of the average mobile app:  14 months.  And during that time, the app will be significantly revised or completely rewritten 3-4 times.  In device terms, that’s a new model every 3-4 months. And yet FDA needs an average of 67 days to review a medical app.  So by the time FDA has finished its review and clearance, the version the agency reviewed may well be obsolete.

This is going to be problematic if the majority of mobile medical apps are classified as Class II Devices as suggested by FDA's draft guidance on mobile medical apps.

Class II Medical Devices are higher risk than Class I devices.  Example Class II devices today include powered wheelchairs and infusion pumps.  Class II devices require their maker to fully comply with FDA's Quality System Regulation (21 CFR § 820) and the Medical Device Reporting (21 CFR § 803) rules, from design control to supplier (including distributor) qualification to postmarket monitoring.  Assuming a firm takes a traditional approach to compliance with the QSR and MDR, their cost of doing business will increase an average 30%.

Many questions about QSR and MDR compliance for medical apps abound.  Is Apple a distributor of the medical mobile app?  What about Google’s Android store?  Or Amazon.com?  How should a maker of a mobile health app qualify Google or Amazon.com or Apple?  If a user posits a poor review and bug problems he/she had on the app store’s reviews section, what responsibility does the developer – or Apple or Google – have to consider that user review for postmarket reporting?  How strict will FDA be in inspecting and enforcing design controls when device models completely change every 3-4 months.  Far too few firms today get design control right with an 18 month development lifecycle.  What is the agency’s compliance expectation for a 90-day development lifecycle?  And for apps that include the ability for a healthcare provider to enter patient data and track treatment plans, for instance, who is responsible for ensuring the app is 21 CFR § 11 compliant such that any data within it has integrity, much less remains confidential and private?

FDA’s current draft guidance on mobile medical apps is woefully short of such practical specifics.  And yet it’s these specifics that will get even the most forthright medical app developer in trouble with FDA-483s and Warning Letters.  Warning Letters have been shown to reduce product sales by at least 8% the first year and for three years thereafter.  For many of these developers, a Warning Letter might be the kiss of death and bring a painful chill to the innovation marketplace.

FDA will need to tread carefully in its final guidance.  I am less concerned about apps that clearly turn a smartphone into a medical device or diagnostic tool (a perfect example is the recent “It Has Come to Our Attention Letter” to Biosense Technologies in California for its mobile medical app, uChek Urine Analyzer).  I am more concerned about missteps in two areas:

1.  Misinterpretations around technological capabilities vis-à-vis wellness versus treatment versus diagnosis.  Many mobile medical apps help healthcare providers and patients track conditions – from weight loss to insulin levels.  It seems to me that FDA’s draft guidance identification of apps doing calculations as Class II devices is extremely broad.  After all, if my weight loss app calculates my body mass index, doesn’t that technically meet the criteria defined by FDA:  “Apps that act as calculators or utilize algorithms to produce an index, score, scale, or other similar calculations.”  And what if my doctor decides to rely upon that to prescribe a weight loss drug or exercise regimen?  Or a clinician, in the midst of a clinical trial, decides that this is how he/she is going to verify and track dosing?

2.  Enforcement of the QSR and MDR requirements.  How will FDA enforce these regulations given the enormous numbers of medical apps and the comparative dearth of FDA investigators and reviewers?  Few app developers today use anything like design control for their rapid development and release cycle.  And many medical app developers are virtual companies.  What is the actual likelihood they will comply versus simply shutdown shop after 14 months (the lifespan of their app) only to re-open under another name?  Think about how the video game development industry operates.  Game studios open and close all the time.  Individual developers jump ship to form a new studio, release a game, and then shut down the studio, only to reform with a slightly different group of developers and reopen a new studio 30 days later.  I can easily foresee this happening in the mobile medical app space, particularly as more and more overseas developers join the fray.  FDA can clarify all it wants that app developers need to register as device makers and comply with the QSR and MDR, but enforcement needs to be realistic to work.  The ability of an app maker to open up, develop the app, sell it for 14 months, and then close up shop faster than FDA can realize the app even existed is going to make for a lot of frustration in FDA, in the marketplace, and among patients and providers.

While FDA continues its case-by-case enforcement and tries to craft guidance-based rules in which to understand and frame the fast-paced mobile health landscape, the market marches forward at double time.

Let’s hope mobile medical app makers are not surprised when FDA finalizes the rules of the game.

Should FDA Regulate Medical Apps?

This week, Congress is holding hearings on FDA's plan to oversee and regulate medical apps for smartphones as medical devices. As I wrote back in my Medical Apps, FDA and Patient Data Integrity posting, the regulation of medical apps is a perilous road for FDA to take given the agency's track record when it comes to technology and innovation.

Congress is using the device tax as the leitmotif, but in reality, this three-day hearing is really about whether FDA should even be tackling medical apps right now. Today, the agency can barely get a handle on its current responsibilities to oversee approximately 25% of the entire US economy. Adding the ultra fast-paced landscape of medical apps to FDA's regulatory plate seems to lie somewhere between a foolhardy power grab and a tragically noble safety effort.

According to Clinical Innovation & Technology, there are already 27,000 medical app products on the marketplace today, most of which are either free or less than a few dollars in cost. An additional 500 new medical apps are launched each day. Even if every FDA employee, from Commissioner Hamburg all the way down to the agency's latest summer intern, were to instantly (*poof*) turn into expert "FDA medical app reviewers," the agency does not have enough human beings to review all the apps on the market today much less keep pace with all the new, daily medical app product launches and nor the countless updated revisions to earlier released apps.

For a medical app to go through the FDA 510(k) process takes 3-18 months of FDA review and costs a company hundreds of thousands of dollars. So far, only 80 apps have gone through the approval process.

And to what end?  What known, quantifiable, tangible public health and safety risks are being eliminated or mitigated?

What are the Public Health Risks?

For the vast majority of these apps - at least 90-95% - there are no public-wide health or safety risks not already covered under other rules such as false advertising (FTC) or market mechanics (bug-ridden apps tend not to get used very much). These are the apps geared toward you and me (i.e., the general public).

For the tiny sliver of apps for whom intended users are professional, trained medical personnel - doctors, nurses, clinicians, etc. - the risk is not direct harm to the patient; the risk is that the data within the app will become corrupted somewhow and not allow an accurate reading, an accurate diagnoses, an accurate display of trends, etc.

And its these professional, clinical apps that pose a risk - not to public health and safety - but to the ability of healthcare professionals to rely upon medical apps as helpful tools, just as the healthcare professional relies upon an office computer or Microsoft Word or the fax machine or a sharps disposal bin. FDA does not regulate these as devices...does it?

Oh wait, FDA does regulate sharps trash bins as medical devices (we'll save that for a future post).

A Simple, Common Sense Regulatory Approach to Medical Apps

Last year, Sweden's Medical Products Agency (Sweden's "FDA") published a very reasonable, balanced regulatory view with their guide on how medical software falls under the EU health regulations such as the EU GMPs and EU Annex 11. Sweden clarifies that smartphone medical apps do not - and will not ever - fall under the category of actual medical devices unless the smartphone or tablet is specifically converted into a medical device to be used largely for the detection, diagnoses and/or treatment of medical conditions (such as a smartphone specifically into a patient monitoring device).

Under that rubric, only apps strictly designed for healthcare professionals, clinical settings and/or dedicated to patient monitoring and reporting (to healthcare professionals) would fall into FDA's purview. You can download an English translation of Sweden's simple, common sense approach to regulating medical apps here.

Congress and FDA would best serve the public by adopting such a common sense approach, at least for now until actual risks materialize enough to justify heavier regulatory oversight.

Implementing heavy FDA oversight of medical apps as medical devices in the US today will only verify Winston Churchill's wry observation, "Americans can always be counted on to do the right thing...after they have exhausted all other possibilities."