Compliance Zen

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.

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.

Poll - Should FDA Regulate Medical Apps

The ante has been upped in the mobile medical app regulation debate. Recently, a large group of patient and provider associations along with IT companies and payors petitioned the Obama administration not to rush into regulation, urging caution.

 

Three days later, a separate coalition comprised mainly of device manufacturers, app developers, and mobile companies petitioned the government to do exactly the opposite, asking the FDA to provide final guidance on app regulation immediately.

Though patient safety is important to both sides, big businesses on each side of the debate are also incentivized by other factors.  Melissa McCormack, managing editor of The Profitable Practice, a blog for healthcare providers, recently alerted me to a new report examining the motives of each coalition. Compiled and analyzed by Software Advice, a company that helps medical software buyers evaluate products, the report makes for some interesting...and possibly disturbing...reading.

The report publishers are also running a poll on the topic, and they’d like your opinion.

Take the poll and view the results here:  Should the FDA regulate mobile medical apps?

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."

3D Printing and Nanobots - FDA Challenges Ahead

Among many products, the US Food and Drug Administration (FDA) regulates medical devices such as stents and prosthetics. FDA regulations - and compliance - are predicated on an assumption that medical device production is an involved undertaking that requires expertise, monies, and physical manufacturing.

Yet, what would happen - is happening right now - if anyone can make a fully functional, complex medical device at home in about an hour?

3D Printing of Medical Devices

Late last year, two folks collaborating from opposite sides of the planet created an articulating prosthetic hand using only a cheap 3D printer.

Then, they went one step further – they uploaded the design specs on the internet so anyone can download, make and use this 3D printer prosthetic hand today.  (*Note - this news story has embedded videos to watch as well so you can see the fully articulate hand in action.) The device design is now in the public domain.

Most prosthetics are Class I devices today, requiring only an FDA quality system (21 CFR 820)  and compliance with the medical device reporting rules (21 CFR 803); a 510(k) is not required. Sounds straightforward when such devices are designed and made in traditional manufacturing firms. But using this public domain specification, anyone with access to the internet and a 3D printer can make this Class I device.

So…is every person who prints one of these now an FDA-regulated manufacturer?

FDA rules, regulations and statutes are predicated on an assumption that in order to start a business – in order to design and sell a product – there are significant fixed costs involved, investors may need to be sought, expensive expertise to obtained, and so on.

Now though, all one needs is a cheap 3D printer and an internet connection to download, make and use a fully articulate, Class I medical device prosthetic.

The times they are a changing.

Beyond just the FDA QSR and MDR rules, the new unique device identifier (UDI) regulation will be phased in over the next six year. 3D printed prosthetics – and other Class I devices – will need their own UDI as of 2019, if not sooner. How will this work if anyone can make their own fully functional, Class I device with a 3D printer? Keep in mind – this fully articulate, 3D printed prosthetic is just the first of future medical devices made onsite, at any site, in real-time with 3D printing.

In February 2012, a woman received an impantable replacement jaw made from a 3D printer. Presumably, any hospital could make such an implantable device on the fly, in real-time, fitted to each individual patient’s characteristics. Fabulous from a healthcare perspective but a real challenge in the context of regulations that date back to last century. Will this mean each hospital in the US has to seek its own UDI? Has to have its own quality system and device adverse event reporting programs?

FDA has an overwhelming workload now. Imagine in a few years when wide-spread 3D printing allows real-time, patient-side creation of almost any type of medical device, from prosthetics to implants, at any hospital, doctor's office or home.

Nanobots and the UDI Rule

It’s only going to get worse, though. A colleague of mine is working to commercialize injectable nanobots that scour arteries for plaque and other problems, and then, within 30 days, completely dissolve. Other firms are drawing up plans for similar nanobots to tackle digestive system issues and so on.

Thankfully for the agency, these nanobot based devices are almost a decade away. And the clinical trials will undoubtedly be highly scrutinized.

Here are just two questions injectable (or injestable) nanobots raise:

1. Are these devices or drugs or combination products?
2. How do you apply a UDI to something the eye cannot discern and that will disappear in 30 days?

Fundamentally, the challenge facing FDA – and facing all of us in compliance and quality – is that scientific and technologic progress is far outstripping FDA’s ability – much less any organization's ability – to understand its implications enough to be able to craft reasonable regulations and practical SOPs and policies. This is a challenge that will get far worse before it gets better.

When I give FDA compliance training and workshops to business execs and scientists, I make a point to note that regulation in the US today takes at least 8 years to go from blank sheet of paper to reality (note that the UDI rule was drafted long before Congress actually passed the authorizing FDAAA statute in 2007). The UDI rule took almost a decade to come to fruition in Congress and then be written so as to go into place this year...and with 3D printing (much less imminent nanobot devices), the UDI rule is already outdated before it formally takes effect.

How can FDA handle 3D printed devices, nano-technology medicines and other new advances?

FDA has little choice left but to regulate through guidance. Guidance documents can take less than a year to publish. And for those of us who provide expert regulatory intelligence and quality systems advice to clients, we’ve also noticed that FDA is increasingly reliant as well upon using Warning Letters to explain rules and requirements; see the recent push of late for FDA records management requirements in warning letters and this year's Ben Venue Laboratories consent decree.

Implications for Firms Today

Firms need to proactively manage the gathering and synthesizing of FDA regulatory intelligence, incorporating and applying it into their quality systems and product planning. Relying upon a regulation written before Y2K to tell you what to do in this era of social media, iPhones and 3D printing is akin to relying on a fax machine to quickly send a document. This is why FDA officials of late have cautioned against relying on former FDA officials whose last stint with the agency was twenty years ago; too much has changed since the 1990s.

Those firms large enough to dedicate a team of personnel to regulatory intelligence and its application will manage just fine over the 5-10 years, but what of firms that don’t have that kind of manpower and money? How will firms with more needs than personnel keep up with new FDA expectations and clarifications from guidance documents, warning letters, consent decrees, and even web-based FAQs?

Stay up with FDA guidance, warning letters and FAQs to avoid enforcement and new product delays.

Small to midsized firms should look to some type of outside service. Consider asking an industry expert with a good reputation to provide you regulatory intelligence services (if you need help determining how to get a good a consultant, follow the tips in this article). Ask the trusted compliance expert to provide ongoing review, analysis and suggestions stemming from “recent and newly published relevant FDA guidance documents, warning letters, consent decrees, and FAQs.” Be sure to scope out the service appropriately. Don’t ask for a weekly update if you only plan on incorporating suggestions on a quarterly basis. Most clients I deal with want advice on a monthly or quarterly basis. A good rule of thumb is to expect the expert to spend approximately 12-20 days a year providing you analysis and suggestions from relevant FDA items. Work this out for the consultant’s hourly rate or a fixed fee.

Another option, albeit much less tailored, is to subscribe to a regulatory intelligence newsletter or a quality systems newsletter such as Cerulean’s SmarterCompliance. Keep in mind that published newsletters have a large readership and so you may not find every issue to be of immediate impact. Make sure the newsletter offers a money-back guarantee of some sort so that if you cannot find anything of any value over a handful of issues, you can at least get some monies back.

FDA regulatory intelligence is only as good as its applicability. Talk with your quality system consultant or regulatory intelligence expert on how best to apply the ongoing advice in your organization; he or she should have some level of insight into what works best in day-to-day practice.

Medical Apps, FDA and Patient Data Integrity

Two recent articles - one in the Washington Post entitled Health-care Apps of Smartphones Pit FDA Against Tech Industry and one in the Wall Street Journal entitled There's a Medical App for That-Or Not - have raised the spectre of how smartphone medical apps imply an imminent trainwreck between today's rapid-pace innovation and last century's slower-going FDA regulation.

 

  vs? 

What's the real question?

As I note in Get to Market Now!, new innovations and technologies emerge on average every 6 months while new or revised regulations take 12-14 years. Today, there are over 13,000 medical apps available for you and me; another 5,000 are available just for physicians and healthcare providers. By the time you finish reading this post, another medical app will have been published.

From a business perspective, the thought of FDA dragging down innovation to the rate of regulation is frightening. And while there is also the need to protect the public - and physicians - from medical apps that are unreliable, faulty, and just plain poor, is new regulation the answer? Is treating a $1.99 app like an MRI the answer? Innovation wouldn't stop. The price would just go up. Instead of paying $1.99, you'd just pay $1,990 for the app.

So, assuming that's not our goal, then what's the answer? Well, maybe we should step back from racing to find an answer, and reframe the question. Afterall, there's no point in arguing over the answer if we're not all answering the same question.

I suggest the real question has little to do with speeding innovation, keeping the public safe, enabling informed healthcare consumers, or making healthcare professionals more efficient. Those are all wonderful points, but they are not the core question behind how to, or even whether, we should regulate a medical app.

The real question is simpler:  How do we - as a society - ensure that patients and healtcare providers can rely upon the health data used/maintained in a medical app?

Think about it. Would you want one of the regular updates to an app on your smartphone to corrupt all the previous data you had in it?

In today's video game market, data corruption is a painful reality becoming more and more common - patches and updates to games increasingly have to be withdrawn and redone because they accidentally corrupted and destroyed people's previous game data. It's too late for those consumers whose data files were destroyed.

"Well, sure," you say, "but those are game files. I mean, come on." And then think about it:  is that what you want for your smartphone health app?  You'd be hard-pressed to find a patient or a physician okay with running that risk for all their health data. Are you okay with all your health data and trends over the past year being wiped out while an update to your app is downloaded as you sit at Starbucks sipping that latte?

So this is the core question:  how do we ensure that data entered into a medical app stays trustworthy?

And if we reframe it in this way, then we can cast about for already existing regulations, controls and tools. And yes, we already have them.

 

Today's Medical App Controls

I see four significant controls available today. The first two are pure market-driven, the second two are more "guiding hand" industry best practice combined with existing regulation:

1. Consumer reviews.  Admittedly, there are some drawbacks to this as we don't know if the person writing the review is knowledgeable, and sites that rely on consumer reviews are usually fairly easy to game. So, consumer reviews are not a stand-alone control, only a piece of the control puzzle.

2. Product liability litigation.  Yes, it's coming if not already occurring. Face it, if you can find a lawyer able to beat a restaurant for serving too hot a cup of coffee, you can find a lawyer able to beat a medical app for allowing your medical data to become corrupt. Still, because it can take up to two years for such product liability litigation to emerge, this is not a preventative except in the long, long-term. Product liability litigation is only another piece of the control puzzle. If nothing else, right now, medical app makers will want to include some level of documented risk assessment to patient data as part of their development process, otherwise, expect to defend why you didn't when you sit before the court in 18 months.

3. Software quality control practices.  Great in theory, often poor in practice. The reality is that often companies cut quality control in order to rush products to market. When a medical app can be written and quality checked by the same person all in the span of a 14-hour day, software quality control is not a stand-alone data integrity control to rely upon. Nonetheless, I'd argue it is still a part of today's control puzzle. Everything from ISO to CMM should be on the table here, and it'd be nice if we could start to see some sort of reference by medical app makers to the software quality coding method used to make their app and its inevitable updates.

4. Part 11.  Yes, I said it. 21 CFR 11 Electronic Records; Electronic Signatures. Now, before you bring up the spectre of "validate everything" (and trust me, as a recovering "validate everything" addict, I've got a lot of personally painful, embarrasing stories), I'm discussing how Part 11 (and the EU's Annex 11) are interpreted and enforced today. Today, Part 11 is all about data integrity - ensuring that data that is trustworthy. And isn't that the core question we just defined above?

So if a medical app provider can show that his/her medical app maintains data with integrity (i.e., is Part 11 compliant), isn't that enough for the vast majority of the 18,000+ medical apps out there?

Coincidentally, Sweden's Medical Products Agency just released a guide to the EU's medical device directives that discusses controls, risks, and expectations for medical software - including medical apps. Download a PDF of Sweden's guide here. It's approach seems quite reasonable. Makers of medical apps are to conduct a risk assessment of their app that includes risk to the patient (see control #2 above), and be able to demonstrate that the app meets its intended performance goals (see controls #3 and #4 above). Finally, the guide notes that smartphones and tablets, etc., will never be considered (and regulated as) medical devices unless they are specifically converted to be a medical device.

If only we in the States could be so reasonable....