Inclusion Inspires Innovation

This inspires me:



"From the very beginning,
we have been a collective
of individuals.

Different kinds of people
from different kinds of places.

Artists, designers,
engineers and scientists,
thinkers and dreamers.

An intersection of technology
and the liberal arts.

Diverse backgrounds,
all working together.

One powerful thing we share
is the belief that we can make
a difference in the world.

Through our products.
And through our values.

Through who we are.

For this reason, we put inclusion
and diversity at our very center.

Inclusion that opens a broader
view and seeks a diversity
of thought and perspective.

We honor individuality,
human dignity, and equality.

We want people to be themselves.

And contribute through
their own, individual experiences.

Because this environment
inspires creativity and innovation.

And empowers us all to do
the best work of our lives.

Together."

- Apple, Inc.

Just Say No to Email (after hours, weekends and on vacation)

How many of you wish that when you were on vacation, any emails directed to you were simply deleted from your inbox, leaving you with a clean slate on your return?

That's exactly what German auto-maker Daimler has proposed per this recent Time article.  Vacations are not optional for optimal human performance. In fact, recent data have demonstrated that unstructured free play promoted healthy brain development in children resulting in improved social skills. And "in one study, researchers found that the best predictor of academic performance in 8th grade is a child's social skills in the third grade." To see this principle hilariously depicted:

Not Just Vacations

I applaud Daimler for this move, and I've long felt strongly that separating work and home life is essential to personal happiness and fulfillment. One way I attempt to achieve this is to avoid sending or responding to work-related email outside of work hours. This is especially applicable to anyone in a managerial position. When a manger sends an email to an employee at 10pm, it's natural for the employee to feel an obligation to reply, whether or not that was the manager's intent.

The most common excuse for this behavior is that late at night or in the wee hours of the morning are just the only times the manager has to work through the packed inbox. Some managers make it very clear to employees that a response is never expected after work hours. Most, however, do not make this explicit.

So what can be done? Here are a few suggestions:

1. Don't work on email at home (if possible)
2. Write the email drafts at your convenience and send the next business day
3. Send the emails anyway, but make it very clear to your employees or coworkers that a response is never required after work hours
4. Use technology to solve the problem for you

While I try to follow option (1) whenever possible, I employ option (4) when I just have to catch up on email after hours. I use a Mac Mail add-on called SendLater. As the name implies, it allows me to compose emails at my convenience. Rather than save as a draft, I simply click the "SendLater" button which queues up the email to be sent the next business day at 8am. As soon as the next business day rolls around, the emails are automatically sent on or after 8am as long as my laptop is connected to a network. This might explain why many of you have received lengthy emails from me around 8am. It doesn't mean I was up early working on them.

For you Outlook users on Windows, there's a built-in option to do the same thing.

Of course, I work in the healthcare profession, and despite my best efforts patients are still getting sick after 5pm and on weekends, which means I occasionally have to send emails at these times. But hopefully I've prevented a few of you from feeling pressure to respond to email that can and should be left until the next business day.

Here's hoping even more of you adopt this practice. Until then, I promise I'm not ignoring your 10pm email question. I'm probably just sleeping. Or playing.

Triangle Health Startup Weekend & The DreamCrusher™

Unlike this T-shirt, the weekend didn't flatline...

This past weekend I had the opportunity to serve as a coach and panelist for the first ever health-related Startup Weekend here in Durham, NC. Held in the historic American Underground at Main St., it was 54 hours of excitement about mHealth, telemedicine, medical devices and more. We heard pitches about EHR integration (one of my favorite topics!), an improved laryngoscope, deriving meaning from unstructured data, a pet treatment service, and an alternative medicine treatment for yeast infections, among others.  This event united participants from numerous universities (both local - Duke, NCSU, UNC - and out of state, such as Clemson) as well as many local startups, established enterprises, law firms and hospitals. The mood was positive, collaborative, and energizing.

Here are some of my lessons learned or reinforced:

Apparently I'm a DreamCrusher.

This was not intentional, of course, but it doesn't help anyone to beat around the bush. For example, the first group I met with (whose idea received the most votes in the Friday evening selection round) proposed a solution to standardize electronic health records nationwide. Obviously, this is a fantastic idea, and born out of the frustration many of them experienced firsthand in their own care (i.e., the inability of their physician to see their medical records from the hospital down the street). They asked my thoughts, and 10 minutes later, after giving them a 30,000-ft view of the current state of federal mandates (i.e., Meaningful Use) and consumer initiatives (i.e. HealthKit and GoogleFit), they immediately saw the need to pivot from their general idea of standardization to a specific one related to consumer health. I provided a couple suggestions to get them started, and they quickly refocused to start dreaming up their next big idea. Making informed strategic decisions is critical in healthcare, which leads me to the second lesson:

Healthcare is a black box to those outside the field.

As someone in the healthcare profession - and informatics in particular - it's easy to take for granted how much we have to know to do our jobs. While there were many healthcare experts in attendance this weekend, there were also many who saw this as a great opportunity to kickstart a career in healthcare innovation. For the latter, coming up with what seems to be a novel idea only to learn twenty reasons it wouldn't work in our current healthcare environment is one of the best ways to become initiated. To understand healthcare is to understand limitations and how to work with them or around them. These groups stayed positive in the face of nearly constant Dream Crushing!

Involve the content experts.

There were many MDs coaches in attendance this weekend, representing primary care, hospital medicine, psychiatry, emergency medicine, and cardiology. One particular idea involved a novel treatment for yeast infections. There was preliminary in vitro data demonstrating efficacy of the treatment, but when presented to the panel of expert providers, several red flags became apparent. None of these were deal-breakers, but this highlighted the need for a well-done clinical trial to demonstrate both efficacy of this treatment as well as possible adverse outcomes. The sooner an idea can be reviewed by someone with domain expertise, the sooner any glaring omissions can be addressed and novel products such as this can get to market.

Surround yourself with people who think differently.

I heard many perspectives this weekend and learned a lot from each. The teams varied in size from one person to a dozen. It was fascinating to see the medical student hashing out an idea with an MBA or the security expert debating the need for legal review with the engineer. The more diverse the group and the more opinions offered, the more robust the ideas became. It's easier and more comfortable to surround ourselves with those who think just like we do, but that's also the fastest way to fail. Multidisciplinary collaboration yields success.

I hope that at the end of the weekend everyone felt that they either had an idea that was worth their time or that the knowledge gained was worth the 54 hours of hard work, excitement, and ... yes ... Dream Crushing.

Congratulations to the winners of the various categories!

• Best business model: Waggin Aid
• Best execution: Aura (alternative treatment for yeast infections)
• Best customer validation: HeartThrob Cardio
• Best overall: Aura (alternative treatment for yeast infections)

Finally, thanks to all the organizers for making this a reality. Let the dreaming continue!

- Ricky "DreamCrusher" Bloomfield

Listening to the mid-day Saturday status updates.

FDA Further Eases Restrictions on Areas of Potential mHealth Innovation

I recently reviewed the timeline for FDA regulation of mobile apps and devices and shared my perspective on the path forward.  At the time, I was unaware of another recent draft document released by the FDA on August 1, 2014 explaining their "Intent to Exempt Certain Class II and Class I Reserved Medical Devices from Premarket Notification Requirements."  Given that the devices listed in this document have been targets for mHealth innovation, this is a positive development for the industry.

The document lists devices in the following categories (items currently relevant in mHealth are emphasized, this is not a complete list):

• Anesthesiology Devices
• algesimeters, NO2 analyzers, cutaneous O2 monitors, pneumotachometers, rocking beds, portable air compressors
• Cardiovascular Devices
• trocars, lung sound monitors, oscillometers, body composition analyzers
• Dental Devices
• pulp testers, denture pads/cushions/reliners, plastic dentures, endodontic splits, parallelometers, teething rings
• Ear, Nose & Throat Devices
• hearing aids, middle-ear molds
• Gastroenterology - Urology Devices
• fiberoptic/endoscopic light sources, colostomy rods, hemorrhoidal/esophageal ligators, biliary lithotriptors, urethrotomes, esophageal dilators, ostomy irrigators
• General and Plastic Surgical Devices
• alcohol pads, talking first aid kits, surgical drapes/lights
• General Hospital and Personal Use Devices
• electrical thermometers, support stockings, finger cots, UV water purifiers, patient restraints
• Neurological Devices
• vibration threshold devices, temperature discrimination testers, ataxiagraphs, preformed cranioplasty plates
• Obstetrical and Gynecological Devices
• fertility diagnostic devices, cervical drains, obstetrical forceps, vaginal specula, umbilical clamps, perineal heaters, menstrual cups/pads, genital vibrators
• Ophthalmic Devices
• ophthalmic cameras, photorefractors, euthyscopes, transilluminators, trephine engines, electrolysis units, headlights/lamps, magnets, sponges
• Physical Medicine Devices
• reflex hammers, finger-sucking devices, hydro-massage baths, sitz baths, paraffin baths, measuring exerciser, external limb overload warning devices

Given that mHealth regulation will likely require increased resources, this notably has the potential to free-up resources in the low-risk device categories arena so that the FDA can focus on high-risk devices and applications.

I applaud the FDA for their consideration and attention to this area.

FDA Mobile App Guidance - The Path Forward

In my last post I described the current state of mobile app regulation, including a summary of the FDASIA Health IT Report, which rather than expand FDA oversight on mobile health applications, recommends that "a better approach is to foster the development of a culture of safety and quality; leverage standards and best practices; employ industry-led testing and certification; and selectively use tools such as voluntary listing, reporting, and training to enable the development of a healthcare environment that is transparent and promotes learning to foster continual health IT improvement."

This approach, while pragmatic, leaves a significant unanswered question: does the risk associated with leaving these apps unregulated outweigh the benefits in allowing them to come to market more quickly? Nathan Cortez, J.D., et al attempt to answer this question in the recent article entitled "FDA Regulation of Mobile Health Technologies" from the July 24, 2014 issue of the New England Journal of Medicine. The authors recognize this dilemma: "The true challenge ... is creating a regulatory framework that encourages high-value innovation while also preventing the market from being overcome with products that are ineffective or unsafe."

While the authors give several examples of apps that have not functioned as designed and raise relevant concerns regarding the process (e.g., "it seems inefficient for app manufacturers to submit repeated [510(k)] applications for each update or change"), they suggest few solutions or alternatives. Aside from increasing FDA resources (possibly through an approval fee imposed on mobile app developers) along with a new center to regulate mobile apps, their single substantive recommendation consists of a conditional approval process, whereby the developers pledge to gather safety and effectiveness data after app release in exchange for expedited premarket review. Also, while the FDA recommends enforcement discretion for all clinical decision support apps, the NEJM article authors recommend that "the FDA should regulate mHealth products that incorporate clinical-decision support."

None of these are bad ideas. If fact, increasing resources to support an expedited approval process would seem to be the only tenable solution, if not for the possibility that - by the authors' own admission - "there could be 1.7 billion mHealth users worldwide" by 2017, and likely over a million mobile health apps (assuming 97,000 mobile health apps in 2013, roughly estimated to double annually per the article).

Let me say that again: there could be over a million mobile health apps by 2017, and if you want a less ephemeral number, there were already 97,000 as of early last year alone. Granted, not all of these will be high-risk clinical decision support apps, but, of course, how could we know which ones are high-risk unless we review them all, at least in a cursory way?

While the policy recommendations in the NEJM article strike me as an idyllic moonshot attempt, the FDASIA Health IT Report is grounded with an acknowledgement of the enormity of the task.

Furthermore, the NEJM authors do not fully account for the perspective of the innovators themselves, who are often mobile developers unfamiliar with the long waits required for 510(k) approval. In fact, they state that "the FDA reports that the average total time from a 510(k) submission to a decision by the FDA is only 110 days." Only 110 days. I recognize that this is short by medical device standards, but we're talking about developers who are already miffed that they have to wait 1 week for initial app approval and several days for each app update. Speaking of updates, mobile apps are updated frequently - monthly or more in many cases. How does that fit with a "short" 110 day approval process?

It's difficult to predict where the next great idea will come from. I recognize the desire to ensure that each of the hundreds of thousands of potential healthcare apps is as risk-free as possible, but the barriers recommended by the NEJM article - including an approval fee and conditional approval with post-marketing follow-up assessments - would all but guarantee that many potential life- and cost-saving clinical decision support innovations never see the light of day (at least those not supported by venture capital).

So what can be done?

I don't have a panacea. This is a hard problem. But I think that the recommendations of the FDASIA Health IT Report serve as an excellent starting point: "foster the development of a culture of safety and quality; leverage standards and best practices; employ industry-led testing and certification; and selectively use tools such as voluntary listing, reporting, and training to enable the development of a healthcare environment that is transparent and promotes learning to foster continual health IT improvement."

For me, this boils down to:

• Education: help providers understand the risks inherent in new technologies, the danger of over-reliance on such technologies, as well as the importance in following best practices. Providers should learn to integrate new and unfamiliar technologies slowly, or use software trusted by peers.
• Expertise: as I've discussed earlier, the developer of every mobile health app should enlist appropriate domain expertise to ensure success. Providers interested in mobile health should make themselves available where possible. Lack of provider involvement in the app development process should be seen as a red flag.
• Environment: a culture of safety and quality accompanied by continual improvement describes the promise of a learning healthcare system. Mobile technology is positioned to deliver on this promise.

I want to stress that of the three categories of health IT functionality described in the FDASIA report (Administrative, Health Management, and Medical Device), the suggestions above are most applicable to decision support apps in the Health Management category. This is the current grey area, but also likely to be the largest of the three in terms of app volume. These apps will still be subject to FDA enforcement discretion (reactive as opposed to proactive), which I feel is appropriate.

On the other hand, apps that purport to be medical devices would fall into the third category, which I feel should be carefully regulated since they would pose far more risk. Examples of such apps currently in the App Store include Instant Blood Pressure & Pulse Oximeter.  Instant Blood Pressure includes a disclaimer at the bottom of the app page ("for recreational use only. It is not an FDA cleared medical device. Consult a doctor if you have any health concern.") while Pulse Oximeter does not. I personally tested pulse oximeter a couple months ago and found it lacking.

I believe that the only practical way to catch these apps prior to release would be to work directly with app store curators (e.g., Apple and Google) to add an additional layer of review to screen for apps that claim medical device functionality. If they are found to meet the definition of a medical device, they should be referred to the FDA prior to app store approval.

We still have a long road ahead of us and I applaud the work of the FDA as well as the perspectives of the authors of the NEJM article. Reaching an appropriate balance of innovation and risk while achieving our goals of improved patient care, safety, and cost savings will be critical to ensure a thriving healthcare system well into the future.

FDA Mobile App Guidance for Dummies (or, why Mobile Health Apps ≠ Drugs)

I've heard a lot of assumptions and misconceptions with respect to FDA regulation of mobile health technologies. This is partly due to the fast-moving nature of this field, but also due to the reputation the FDA have earned over the years for slowing the pace of innovation through appropriate regulatory oversight, particularly in the pharmaceutical industry.

It takes many years and hundreds of millions of dollars to develop a blockbuster new drug and then see it through regulatory approval. On the other hand, a mobile health app could be developed in weeks to months with nothing more than sweat equity. Only a fool would have trouble distinguishing these two, or would attempt to apply the regulatory framework of the former to the latter.

Fortunately, the FDA are not fools, and should be given credit for anticipating the trend towards proliferation of mobile healthcare at least as quickly as would seem reasonable in the current political climate.

Mobile Apps Regulation Timeline

Just over three years ago, on July 21, 2011 (back when only 23% of all adults used a smartphone to go online in a typical day, and most iPhone users were running iOS 3 and iOS 4), the FDA released draft guidance on mobile medical applications.

One year later, on July 9, 2012, the Food and Drug Administration Safety and Innovation Act, or FDASIA, was signed into law. One important component of this act was to "Promote Innovation," which included a provision to "further medical device innovation."

Fourteen months later, on September 23, 2013, the FDA issued "final guidance on mobile medical apps" that included a report summarizing their nonbinding recommendations. Despite the common misconception that the FDA plan to regulate all apps with any component of clinical decision support, this document makes clear that the FDA plan to focus "its oversight on mobile medical apps that:

• are intended to be used as an accessory to a regulated medical device – for example, an application that allows a health care professional to make a specific diagnosis by viewing a medical image from a picture archiving and communication system (PACS) on a smartphone or a mobile tablet; or
• transform a mobile platform into a regulated medical device – for example, an application that turns a smartphone into an electrocardiography (ECG) machine to detect abnormal heart rhythms or determine if a patient is experiencing a heart attack."

Note that there is no mention of clinical decision support here, which the agency makes explicit in a prior disclaimer (emphasis mine): "The agency intends to exercise enforcement discretion (meaning it will not enforce requirements under the Federal Drug & Cosmetic Act) for the majority of mobile apps as they pose minimal risk to consumers. The FDA intend to focus its regulatory oversight on a subset of mobile medical apps that present a greater risk to patients if they do not work as intended."

In April 2014, as a result of the FDASIA, a report was published that detailed "Proposed Strategy and Recommendations for a Risk-Based Framework" for health IT. The report recommended "that no new or additional areas of FDA oversight are needed," and also called for the creation of a "Health IT Safety Center" created by ONC (in collaboration with FDA, FCC and AHRQ) "with the ultimate goal of assisting in the creation of a sustainable, integrated health IT learning system that avoids regulatory duplication and leverages and complements existing and ongoing efforts."  The report describes three distinct groups of medical apps, each requiring varying levels of oversight:

Three categories of health IT functionality as described in the FDASIA Health IT Report, April 2014

Oversight is as follows:

• Administrative Functionality (billing and claims processing, practice and inventory management, and scheduling): no additional oversight
• Health Management Functionality (health information and data exchange, data capture and encounter documentation, electronic access to clinical results, most clinical decision support, medication management, electronic communication and coordination, provider order entry, knowledge management, and patient identification and matching): no intention to focus oversight here if the product meets the statutory definition of a medical device
• Medical Device Functionality (computer aided detection software, remote display or notification of real-time alarms from bedside monitors, and robotic surgical planning and control): oversight required

Finally, on June 20, 2014, draft guidance was issued in the form of an update to the September 2013 guidance on mobile medical apps that further limited the scope of regulatory oversight with respect to Medical Device Data Systems (MDDS).

The Path Forward

To summarize, the FDA's current guidelines reflect a pragmatic approach to regulation of the 97,000+ healthcare apps currently available, with emphasis placed on apps that mimic the functionality of medical devices, and not on most clinical decision support apps. Rather than significantly augment the the abilities of the FDA to handle this accelerating volume of healthcare apps, the FDASIA Health IT Report recommends that "a better approach is to foster the development of a culture of safety and quality; leverage standards and best practices; employ industry-led testing and certification; and selectively use tools such as voluntary listing, reporting, and training to enable the development of a healthcare environment that is transparent and promotes learning to foster continual health IT improvement."

Despite the guidance provided by the FDA to date, tremendous uncertainty remains, especially for the developers of these mobile applications who often are not medical or policy experts. Thus far, however, there's been a clear trend towards minimizing regulatory oversight.

Some argue that there may be significant risk in allowing so many unregulated healthcare apps to flood the market.  In my next post, I'll share my opinion on the FDA guidance to date and compare the guidance with a summary article just released in the July 24, 2014 issue of the New England Journal of Medicine entitled "FDA Regulation of Mobile Health Technologies", which includes additional policy recommendations.

Update: click here to read my assessment of the current landscape and the path forward for FDA mobile app regulation.