HealthKit: Can you bill for it?

I had the opportunity to answer questions at the standing-room-only HealthKit 'Open Mic' session at the mHealth Summit 2014 this week in Washington DC (read some of my comments here and another reaction here), and one of the most frequent comments I've received since the session relates to CPT codes used for remote monitoring.

Apparently, most people don't know about CPT codes 99490, 99090 and 99091.  I didn't even know about them until recently.

But first, a disclaimer: I'm not a coding expert, and the application and reimbursement of these codes can vary by state, so please consult with your healthcare institution for details regarding how these might be used at your facility.

To review, there are two codes currently available that allow for collecting and reviewing patient data: 99090 for analysis of clinical data stored in computers and 99091 for collection and interpretation of physiologic data, with a monthly unadjusted, non-facility fee of $56.92.  The catch is that CMS has required that these codes be used in conjunction with a standard E&M service code (99201-99499), which up until now has meant an in-person office visit.

The big deal announced last month was code 99490, which is new as part of the CMS Final Rule for 2015, and will be available starting in January 2015.  This is an E&M code that can be used for remote chronic care management with a monthly unadjusted non-facility fee of $42.60.  Unlike the other E&M codes, this code does not require the patient to be present.  Thus, for the first time, this code could potentially be combined with codes 99090 or 99091 for total monthly unadjusted non-facility fee of $99.52.

While promising, no one has actually billed for this combination, yet, so it's to be determined how it will work in practice and whether other payors will get on board.  Ultimately, from my perspective as a clinician, it has the potential to allow us to care for patients with chronic disease without the inconvenience, higher-cost, or infection risk of a standard clinic visit.  That's the future, folks.

So to answer the titular question, we're getting very close to the point where we'll be able to bill for patient-generated data collected via technologies like Apple's HealthKit.  The proof is in the pudding, so to speak, and the pudding may be ready as soon as next month.

Is it any wonder why I feel technologies like Apple's HealthKit are taking us back to the future?

Additional reading:
http://www.americantelemed.org/news-landing/2014/11/07/update-on-cms-payment-decisions---two-steps-forward-one-back
http://www.mhealthnews.com/news/cms-boosts-telehealth-2015-physician-pay-schedule
http://www.techhealthperspectives.com/2014/11/05/cms-expands-telehealth-reimbursement-in-new-rule/

The Calf-Path

When attempting to solve the world's problems, whether mHealth or otherwise, sometimes it helps to take a step back and reevaluate your strategy.  Following in the footsteps of others may seem effective and efficient, but often it's necessary to blaze your own trail.

In case it's new to you, enjoy the following poem:

The Calf-Path (1895)

Sam Foss

I.
   
One day through the primeval wood
A calf walked home as good calves should;
 
But made a trail all bent askew,
A crooked trail as all calves do.

Since then three hundred years have fled,
And I infer the calf is dead.


II.

But still he left behind his trail,
And thereby hangs my moral tale.

The trail was taken up next day,
By a lone dog that passed that way;

And then a wise bell-wether sheep
Pursued the trail o’er vale and steep,

And drew the flock behind him, too,
As good bell-wethers always do.

And from that day, o’er hill and glade.
Through those old woods a path was made.
   
   
III.
   
And many men wound in and out,
And dodged, and turned, and bent about,

And uttered words of righteous wrath,
Because ‘twas such a crooked path;

But still they followed—do not laugh—
The first migrations of that calf,

And through this winding wood-way stalked
Because he wobbled when he walked.
   
   
IV.
   
This forest path became a lane,
that bent and turned and turned again;

This crooked lane became a road,
Where many a poor horse with his load

Toiled on beneath the burning sun,
And traveled some three miles in one.

And thus a century and a half
They trod the footsteps of that calf.
   
   
V.
   
The years passed on in swiftness fleet,
The road became a village street;

And this, before men were aware,
A city’s crowded thoroughfare.

And soon the central street was this
Of a renowned metropolis;

And men two centuries and a half,
Trod in the footsteps of that calf.
   
   
VI.
 
Each day a hundred thousand rout
Followed the zigzag calf about

And o’er his crooked journey went
The traffic of a continent.

A Hundred thousand men were led,
By one calf near three centuries dead.

They followed still his crooked way,
And lost one hundred years a day;

For thus such reverence is lent,
To well established precedent.
   

VII.

A moral lesson this might teach
Were I ordained and called to preach;

For men are prone to go it blind
Along the calf-paths of the mind,

And work away from sun to sun,
To do what other men have done.

They follow in the beaten track,
And out and in, and forth and back,

And still their devious course pursue,
To keep the path that others do.

They keep the path a sacred groove,
Along which all their lives they move.

But how the wise old wood gods laugh,
Who saw the first primeval calf.

Ah, many things this tale might teach—
But I am not ordained to preach.

Why you'll never use CurrentC (and why this matters to healthcare)

Oh! You've never heard of CurrentC? That's ok, you're not missing anything. With Apple Pay making news recently as a frictionless and secure payment system, the spotlight has been shone on businesses who have opted out of the new service. In fact, the biggest complaint with Apple Pay is that not enough businesses are accepting it.

It has also come to light that the reason why many large retailers have opted out of Apple Pay is because of a consortium called the Merchant Customer Exchange (MCX), which is an effort spearheaded by Walmart to encourage customers to replace credit cards (with fees that the retailers loathe) with their checking accounts.

Here is how CurrentC works (according to those who have used the currently invite-only service):

• Download the CurrentC app (Apple App Store or Google Play)
• Register for an account
• Add a PIN to the app
• Add a checking account to the app
• NOTE: this requires giving CurrentC your SSN and drivers license number, which, in their own words, "is not stored in your phone."  As if it makes us more comfortable to know that critical information commonly used in identity theft will be stored in the cloud of an organization that has already been hacked.
• Add any rewards programs you would like to use with the app

Alright! Now you're ready to pay! To do that, just perform the following steps:

• Take your phone out of your pocket/purse
• Unlock your phone (if you have a PIN/passcode)
• Find the CurrentC app on your phone
• Type in the CurrentC app PIN/passcode
• Navigate to the payments section of the app
• Hold the phone steady to scan a QR code near the cash register

Credit: TechCrunch

Finally, rest comfortably knowing that this data resides in the cloud and that your purchase history could be shared among all participating MCX retailers so they can use that information to send you targeted ads and loyalty offers.

Sounds consumer-friendly, no?

That's exactly the problem - this is a solution that primarily benefits retailers, not consumers. CurrentC is trying to use the thin veil of loyalty rewards to mask their true intentions. Some consumers will see right through this ruse, while others will simply balk at how cumbersome the service is to use. I understand the desire for retailers to bypass the 2-3% processing fees that come with credit card transactions, but until they find a solution that gives consumers a substantially better experience than the current status quo, they will fail.

While the 2-3% processing fees might hurt retailers, credit cards provide significant benefit to consumers through:

• Convenience in grouping transactions together in one monthly payment
• Robust fraud protection
• I've been automatically mailed a new credit card twice in the last year due to the Target and Home Depot breaches. Any fraudulent purchases (where were none) would have been reimbursed, no questions asked.
• Compelling rewards programs
• Cards now offer up to 2% cash back on all purchases, assuming they are paid off on time
• Last but not least, the ability to purchase something using credit, and pay it off over time

This is where Apple Pay succeeds in providing additional value to consumers. In addition to retaining all the benefits of credit cards noted above, Apple Pay:

• Simplifies the checkout process to a single motion involving moving your phone close to the checkout kiosk while holding a finger on the TouchID button. Because phones are usually immediately accessible to most people, this will be more convenient than pulling out a credit card.
• Dramatically increases security. Your credit card number is not stored on your device or anywhere else. Transactions are made via a dynamically-generated single-use number at the point-of-sale. In the event of a credit card breach, your number is safe, and no new card needs to be issued.
• Automatically works with your credit card issuer to update expired cards without any user intervention.
• Keeps your purchase history private. The credit card issuer will still know, but Apple does not have access to this information; it will not be shared with anyone else.

So what does this have to do with healthcare?

I've previously discussed the importance of creating mobile apps that start with the problem and integrate into users' workflows. These concepts are not unique to healthcare, but we happen to be at the beginning of a movement to take healthcare mobile in the hope that we can fully realize the benefits these emerging technologies may provide to healthcare quality and efficiency.

Ensuring that these technologies are useful and usable will be key to our success, and the contrast between initiatives like CurrentC and Apple Pay is instructive.

Even so, the financial world is relatively simple compared to healthcare (which includes the financial aspects plus much, much more). Integrating into a consumer's workflow is far easier than integrating a new intervention into a provider's workflow, and then attempting to scale that intervention across multiple hospitals and EHR vendors.

Yet this is exactly what we need to do. Standards-based frameworks such as the SMART platform show promise that this is achievable. I will have more to say on this topic in the near future. Until then, keep your eyes open for other examples where usability is sacrificed for secondary gains. CurrentC is not alone.

Why solving healthcare problems is so hard

In my mHealth discussions I often meet budding entrepreneurs who are frustrated that finding solutions to healthcare problems just isn't as easy as it is out in the broader tech world.  They're right.

The reasons for this are many.  I won't get into the complicated reimbursement models or ACOs or proper alignment of incentives.  For the purpose of this discussion I'll focus on just one thing - arguably the most important - the human body.

Leonardo da Vinci's famous Vitrivian Man.  Studying the outside is the easy part ... (no disrespect to da Vinci, of course)

But first, let's discuss physics.  The laws of Newtonian physics (i.e., classical mechanics) have been well understood for hundreds of years.  The understanding and application of Newton's three, simple laws eventually gave rise to the industrial revolution, and, by extension, modern society as we know it.  In just a blink of cosmic time, humanity progressed from horse-drawn carriages to landing a man on the moon, 238,900 miles away.

Even more impressive is that we have successfully sent something the size of a small dog from our dear planet Earth to another planet hundreds of millions of miles away, causing it to land (without damage!) in a very specific location on that planet.  Of course I'm talking about the Mars Pathfinder mission and Sojourner rover (and other successful missions to Mars).  For a little perspective, this would be very roughly equivalent to hitting a golf ball from earth and getting a hole-in-one on the moon.  On the first try.  And don't forget that the moon is moving, so by the time the ball arrives, the moon will be in a totally different place than when it left the end of your club.*

This is a picture taken from another planet (let that sink in).

So if we understand the basic laws governing our universe so well that we can accomplish incredible feats such as this, why is it so hard in healthcare?

To put it simply, because each living organism might as well be its own universe with its own laws.

The human body is an incredible, complex universe, governed by laws that we still know relatively little about.  Yet unlike classical mechanics, once we learn a new law or association about the human body, it's not guaranteed to hold true for each unique organism.  That's because we're all different owing to our personalized genetic makeup, something we're just beginning to understand.  Although DNA was discovered in 1869 and its double-helix structure identified in 1953, the function of each gene in our intricate genomes is still largely a mystery.

And then, even if we knew the function of each gene, it wouldn't necessarily explain the complex interplay of proteins and carbohydrates and receptors and positive/negative feedback loops ... the list goes on.  There could never be a set of simple laws to govern these unbelievably elaborate interactions.  Despite numerous advances and tremendous knowledge, we still can't eliminate pain without side effects, completely eradicate cancer, or even cure the common cold.

Wanna know a secret?

For those of you outside the field of medicine, this is why we're always speaking in the language of statistics and probability - why we say things like "maybe" and "likely" or "unlikely."  Because we can't precisely define an outcome based on predefined laws (i.e., no Mars landings here ...), we must observe the outcome in lots of human beings so that we can then make an educated guess about what will happen to you.

That's right!  That's our big secret!  As physicians, we're just guessing most of the time when it comes to how we treat you!

Now before you get too excited (or worried), sometimes those are really, really good guesses ... like, we're 99.99% sure.  For example, we know vaccines save lives (and don't cause Autism).

But it's that last 0.01%, or 0.1%, or sometimes 20%, where there remain lingering doubts and inconsistencies.  This is why healthcare innovation is hard, and will ever remain so.

BUT, this is also why it's essential that we take advantage of the latest technology advances - including mobile technology - to solve these problems.  Despite the inherent difficulties in healthcare innovation, the promise has never been greater, and the tools have never been more accessible.  Let's go heal the world together!



*And even this pales in comparison with the Rosetta mission currently underway by the European Space Agency, where they are in the final stages of landing a craft on a comet (named Churyumov-Gerasimenko) just several kilometers long, a process that involved the spacecraft orbiting the sun several times, slingshotting itself around the Earth thrice and Mars once in order to take advantage of those planets' gravity to attain the proper speed and trajectory.  I'm not kidding.  I didn't mention this one because the landing hasn't happened, yet.  That will take place on November 12th, 2014.

Why Facebook will (mostly) fail at healthcare

Simply reading the title of the Reuters article this morning gave me chills: "Facebook plots first steps into healthcare"

Perhaps the authors just shouldn't have used the word 'plot' like it's some sort of underhanded scheme.

Let me just get this out of the way:

Any company who profits off the aggregation of user data has an inherent conflict of interest when it comes to the security of those same users' healthcare information.

I've previously discussed Apple's HealthKit and how it has been positioned as a data broker of sorts.  The data never leaves the device, and thus is inaccessible to Apple for data mining, analytics, etc.  The data belongs to the user, and the user has complete control of it at all times.

This is easy for Apple to do, because Apple is a consumer electronics company first and foremost.  They almost exclusively earn revenue by selling hardware, and provide software simply to allow users to get the most out of the hardware they've purchased.  Apple used to make more money through sale of software, but over the past 7 years, the cost to upgrade Mac OS X has dropped from $129 in 2007 to free in 2013.  Apple's office suite was reduced to free last year.  Upgrades to iOS have always been free.*

Tim Cook said it best last month in an open letter discussing Apple's commitment to privacy:

A few years ago, users of Internet services began to realize that when an online service is free, you're not the customer.  You're the product.

Apple has no interest in monetizing your data - you've already paid them for the products you use.  When was the last time any of you remember handing over your credit card to Facebook?  Anyone?

That said, I'd be remiss if I didn't acknowledge that any innovation in healthcare is a good thing, and if Facebook can bring novel ideas to this space given their unique perspective, I'm all for it.  Facebook is useful for connecting groups with similar interests, and patient support groups have thrived there.  That's a great thing, especially for chronic or rare diseases.  If patients are informed and comfortable sharing their own data with Facebook, we absolutely shouldn't stop them.  It's their data.

Also, applying machine learning to Big Data has become somewhat of a holy grail for healthcare (as evidenced by Google's Baseline Study).  If Facebook has something to contribute here, and is willing to follow applicable IRB protocols and HIPPA guidelines (which wouldn't involve any data obtained via the Facebook site itself), perhaps we could learn something.  However, if Facebook decides to create a solution whereby they mediate data sharing between patients and providers via Facebook.com, I anticipate failure.

Of course, this same argument could be made with Google, and perhaps realizing this, the initial version of Google Fit is far more limited than HealthKit, focusing primarily on fitness and nutrition rather than clinical care.  That will be something to watch carefully.

For Facebook to find success in real healthcare scenarios involving direct patient care, they need to do much more to earn the trust of the medical community.  Right now, they haven't done that, and I don't see that changing any time soon.

Facebook, prove me wrong.

*Technically, Apple charged early iPod touch users $9.95 for OS upgrades due to some internal "bookkeeping" rules, but that didn't last long.

Cosmos and the Power of Knowledge

Fun fact: the 'C' and 'S' are the first letters to come out of the nebula/iris on the show's introduction and stand for 'Carl Sagan,' the host of the original 1980 series

Some of you may have heard of Cosmos: A Spacetime Odyssey, a recent remake of Carl Sagan's popular PBS science series from 1980 hosted by Carl's protege, Neil deGrasse Tyson.

It's literally the best thing I've ever seen on TV (or a screen of any kind - thank you Michael Faraday!)  I consider myself fairly well read when it comes to science and technology (and space!  Heck, I even earned my Astronomy merit badge as a Boy Scout many years ago).  But with each passing episode of Cosmos, not only have I learned multiple new concepts, but I'm often left with tears in my eyes at the simplicity and power of the ideas, as well as the emphasis on openness and accessibility of knowledge.

Despite my man-tears, the best part of Cosmos for me is that I've been able to share it with my two 8 year old daughters, Miriam and Catherine.  We've watched the first 10 episodes together, and they can't wait until we can sit down again to watch the next episode.  In their minds, Cosmos > Scooby Doo, and that's saying something.

After finishing episode 10 today ("The Electric Boy" about Michael Faraday), Miriam was particularly touched.  Her reaction prompted me to send a short thank-you note to Dr. Tyson himself, which I did via the Hayden Planetarium website.  I'm not sure Dr. Tyson will ever receive that note, so I decided to post it publicly:

Dear Dr. Tyson, 

I just wanted to take a moment to thank you for your work to popularize science in so many ways.  In particular, one of my daughters, Miriam, has immensely enjoyed watching Cosmos.  Miriam is 8 years old and is on the Autism spectrum, although fairly high functioning. 

Earlier today Miriam was asking me questions like, "How fast is the fastest race car?"  I responded, "About 300mph."  Then she asked, "How fast is the speed of light."  "670 million mph," I replied. 

She then proceeded to write out those numbers and subtract one from the other, getting answers like 669,999,700.  I asked her what she was doing, and she said, "I want to be a genius like Newton.  Do you have any of his books?"  My jaw just about dropped to the floor, then my wife and I looked at each other and started laughing in disbelief.  Of course, she was completely serious.  I told her I'd find one of Newton's books for her.  Because I wasn't fast enough (this was literally just a few hours ago), she found my 3-inch thick AP Chemistry textbook (it's been laying on a bookshelf for years) and after a brief scan of the table of contents, immediately started reading the chapter on "Electrochemistry" (probably because we had just finished watching the Faraday episode earlier today). 

So congratulations!  You've just made Sir Isaac Newton my 8 year old Autistic daughter's role model.  Mission accomplished, sir! 

Warm regards, 

Ricky Bloomfield (and his daughter, Miriam)

Dr. Tyson (and the rest of the Cosmos team), thank you for sharing your love of science and knowledge.  If nothing else, you've at least touched the life of an 8 year old little girl (and her father).

Innovating with Epic

Today I had the opportunity to present some of my recent mobile work at the 2014 Epic User Group Meeting (UGM) in Verona, WI.  This is a gathering of over 10,000 physicians and employees of hospital systems across the country who use the Epic EHR.  Duke has been live on Epic ambulatory for a little over two years, and live on Epic inpatient just over a year.  We've learned quite a bit since going live, and the goal of UGM is to share that knowledge with other hospitals, as well as to learn from them.

Taking a collaborative approach to the improvement of EHRs is not only smart medicine, but, in my opinion, essential to reaching our goals of improved clinical care, enhanced patient satisfaction, reduced costs and streamlined research.  Every hospital system brings a unique perspective owing to their own unique strengths and challenges.  They will confront and solve problems similar to our own, but likely in different, and hopefully even more effective, ways.

In March of this year, I led the roll-out of Epic's Haiku and Canto mobile applications across Duke University Health System.  These applications provide access to the EHR from iOS and Android mobile devices.  While the feature set is robust and continually improving with each iteration, there will inevitably be requests for feature improvements from discerning physicians, myself included.  Rather than wait for these features to be implemented, I decided to dig a little deeper to see what changes we might be able to make on our own.  Due the flexibily of the platform on which Haiku and Canto are built, I was pleasantly surprised by what we could accomplish in a very short time.

My UGM presentation, entitled, Hacking Haiku: When You Just Can't Leave Well Enough Alone, is a summary of this work.  Please log in to the UserWeb to view the full details of the presentation, including the presentation slides and demonstration videos.  When creating this presentation, I started with the underlying principle that anything I shared with the group should be able to be replicated by those in attendance.  To that end, I also included a detailed step-by-step guide for these modifications (or "hacks," if you will), also available on the UserWeb.

While some of these hacks involve integrations with or modifications to Epic IP and can only be shared via the UserWeb, a significant part of the presentation discussed a custom app I developed, called the Duke Medicine Mobile Companion.  The app is extremely simple, and performs one essential function: allows users to view additional content external to the Epic apps while providing a one-tap method to return to those apps.

For more information on the app and its functionality, please check out the code on GitHub.

The app is currently iOS-only, and was written in Apple's new Swift programming language, now officially available for apps released in the App Store.  I thought this would be a good opportunity to learn the new language, while at the same time ensuring that the code is modern and robust.  Suggestions and improvements are welcome, obviously.

Why no Android?  It's actually not necessary.  On iOS, the app works by accepting URLs prefixed by the dukemedmc:// URL scheme, a few of which we've added to the Epic apps.  When these URLs are tapped, the Duke Medicine Mobile Companion is opened and information is passed to the app in the form of URL parameters.  A button in the app then provides an easy way to return to the Epic apps.  On Android, a back button is built into the OS natively that not only works within apps, but also between them.  So on Android, we can simply open these URLs in other apps directly (such as the Chrome browser or Google Maps app) and then the user taps the back arrow to return diretly to the Epic app.  There's no need to reinvent to wheel when it's not necessary!

I hope these ideas along with the implementation details will be helpful to other healthcare systems.  The more we collaborate and share, the stronger we'll all be.  With the explosion of mobile health apps in the past few years - with more surely to come - it's also as important as ever to ensure that we protect and simplify our provders' workflows so they can spend even more time caring for patients, rather than simply treating diseases.

 Watch - Relevant to Healthcare?

The anticipation in advance of the Apple event this week was similar to that prior to the announcements of the original iPhone in 2007 and the iPad in 2010.  It would have been an extreme disappointment if the event ended without the announcement of a new product category.

Of course, everyone figured it would be a watch, but just like the previous announcements in 2007 and 2010, no one had any idea what it would look like or what it would do.  Apple is very good at secrecy when mass manufacturing for a product hasn't yet commenced, or when the product includes new software (as evidenced by the surprise announcement of the Swift programming language in June).  Both were true in case.  Prior to the announcement, the  Watch, as it is now known, had been produced in only limited test quantities, and the new version of iOS that it runs had never before been seen publicly.

The  Watch was announced in the context of the prior announcement of HealthKit in June.  Special emphasis has been placed on the health and fitness features of the watch, with Apple going as far as producing a separate promotional video highlighting this use.

That said, the expectations for what this watch would do for health and fitness bordered on magical.  Sources as reliable as the Wall Street Journal predicted that the device would "include up to 10 sensors."  With current technology, I couldn't imagine how that many high-quality sensors could be included in a 1st generation product while still maintaining a reasonable size, cost and battery life.  Sure enough, the actual product was more firmly grounded in reality, with just a single medical sensor to measure pulse, in addition to the activity tracking of the M8 chip and the new barometric functionality to measure elevation.

It's quite likely that these rumors have some basis in fact, however.  The  Watch is the most intimate product ever created by Apple, and I'm not just referring to the ability to share your heartbeat with that special someone.  It's a device that is in constant contact with your skin.  Just that fact alone opens the door for many sensors beyond simple measurement of heart rate.  In fact, I'd wager that the  Watch could open the floodgates to R&D into transcutaneous sensors, with the potential to transform how we see ourselves.  The quantified self has just gotten much closer to reality.

So what can the  Watch do for healthcare right now?  At the very least, the profile of wearable electronics will get a huge boost in the consumer sector.  They will become more socially acceptable, and users will come to rely on them and even trust them to make meaningful differences in their lives.  Laying this foundation now will be critical to encourage the adoption of more advanced wearable sensors in future devices.

How useful the watch ends up being for consumer health and fitness will ultimately come down to the combination of hardware and software.  The fact that all of this data will be saved to HealthKit is very attractive, because the data can then be shared with any other HealthKit-enabled health or fitness app the user chooses.  Giving this power to the user is a smart move, and will likely foster a more open and diverse ecosystem of useful health and fitness apps moving forward.

With respect to use of the  Watch in the clinical setting, I love learning about and using new technology, but I’m also cognizant that the modern reality of electronic medical records has resulted in tension within the physician-patient relationship.  During a typical visit, physicians often find themselves staring at a computer screen rather than interacting with the patient.

In medical school we were taught the Latin phrase, “primum, non nocere” or, “first, do no harm.”  When technology interferes with the relationship we have with our patients, harm is being done.  When technology enhances our work while remaining transparent to the interaction, we can make progress.  Technologies such as the  Watch have the potential to take us a step in that direction by providing another avenue for relatively unobtrusive data access.  As a developer myself, I’m looking forward to the arrival of the WatchKit SDK so I can see more fully how this functionality might be integrated into our medical environment, both from the perspective of a user as well as a physician.

How could the watch be improved?  It'll be easier to see once the watch has been released and the limitations become more apparent.  But for starters, the watch needs to be waterproof.  While there's no official statement on this, David Pogue revealed that it's likely just water resistant.  I'm an avid swimmer, and one of the reasons I love my Pebble Smartwatch is because I never have to take it off (plus, it lasts up to 5-7 days per charge).  This would be critical for any users whose primary form of physical activity involves water sports.  Many of our patients who participate in cardiac rehab are often involved in water aerobics, and they would have to remove the watch to participate, thus nullifying much of the activity tracking benefit.

Battery life also needs to be at least several days.  I've heard some lamentations that the watch doesn't have sleep tracking functionality like some of the other popular wearables.  If the  Watch has a battery life of only 24 hours as rumored, sleep tracking would be an impossibility given that the watch would need to charged at night, every night.  The watch also appears a bit too bulky in its current iteration to keep on while sleeping (in my opinion).

I'm confident all these issues will be resolved over time in future iterations of the watch (or competing watches).  Progress will continue and app developers will surely come up with uses that Apple hasn't even considered.  Mobile health innovators should pay close attention to this new product category.  It will eventually revolutionize how we care for our patients and ourselves.

Apple's HealthKit - A Flexible Platform for Healthcare Innovation

This week Apple officially released the latest version of iOS, complete with their solution for management of a user's health and fitness data, HealthKit. They also announced the  Watch, which includes several health and fitness features.  I've shared some preliminary thoughts on HealthKit already, but now that I've actually had a chance to use it and integrate it into our EHR via the Epic MyChart app, I have a few more thoughts.

It's really easy to use.

Our patients already have a couple ways to securely share data with us.  First, they can write the information on a piece of paper with their option of a pen or a pencil (we're that flexible) and bring it in to their provider.  Second, they can manually enter the information into our online patient portal, Duke MyChart (when enabled by their provider).

HealthKit will eventually provide a third option, but rather than having to remember to write the values down and bring in the piece of paper, or having to remember to manually enter data in to a website, HealthKit will automate this process.

For example, if patients choose to share their blood pressure with their provider using HealthKit, and this feature is enabled by their provider, they need only give permission to the appropriate app, after which their data is securely saved to their electronic medical record.  Any subsequent blood pressure measurements can be saved directly to the medical record in the same way without any intervention by the patient.

It sets a clear expectation that users are in control of their data.

Unlike personal health records that have come before, Apple has approached this problem differently, and has decided to be a data broker rather than a consumer of the health data.  This is a big deal.  At every step along the way, users are informed that they have control of this data.  No data is shared without their express permission, and at any point in the future the user can easily revoke any app's access to the data. The data itself is only stored locally in the device's secure HealthKit data store.

It's secure

While cloud services and Big Data promise to revolutionize data sharing, HealthKit will have none of it. In fact, Apple recently updated their App Review Guidelines to expressly forbid that any data obtained from HealthKit be stored in iCloud:

"27.3 Apps using the HealthKit framework that store users’ health information in iCloud will be rejected"

The only exception to this of which I'm aware is that the user's encrypted iCloud backup could still contain this data.  Personally, as a consumer of these products, I agree with having the option to back-up this data to iCloud.  While it may be considered sensitive, the risk of losing the data without a convient backup would be more detrimental, at least to me as a consumer.  When I put on my physician and privacy hat, I'd recommend that Apple consider giving users the option to exclude this data from iCloud backups, just as the TouchID fingerprint information is always kept in the device's Secure Enclave, and never leaves the device (which will presumably be the same case with credit card information as part of the new  Pay initiative - healthcare and financial data are usually afforded similar levels of security).

As I've mentioned previously, probably the most exciting aspect of a platform such as HealthKit is that it opens up a new avenue for healthcare innovation.  There will be many new ideas that take root and grow owing to the ease-of-use and scale HealthKit provides.  There will also be many failed experiments.  Ultimately, users will be able to decide which new ideas are relevant to them, and which are worthwhile enough to be entrusted with their healthcare data.

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.

Who wants better mobile apps?

Who doesn't?

Since I arrived at Duke almost one year ago I've had many opportunities to share my vision for mobile technology in healthcare. In particular, I've had numerous conversations with budding developers and entrepreneurs asking for advice on how to produce a successful health app. While the real answer is probably something along the lines of: "It's complicated ...," there are several pieces of advice I can offer with a high degree of confidence. In other words, if a developer doesn't do these things, the chance of a successful app is slim.

Without further ado, here are my Core Tenets for Mobile App Development:

1. Start with the problem

This is first for a reason. Despite seeming blindingly obvious, it's one of the most prevalent mistakes I encounter. Technology moves quickly, and often in the wake of a new technology release (HealthKit comes to mind ...) there's a surge of interest to create something quickly to capitalize on the excitement. While there's some merit to this "see what sticks" strategy, the majority of these apps will fail to gain traction. The few that do gain traction were often already in the works, and are simply a reimplementation of the idea with fresh technology.

Instead of chasing the latest technology fad, take some time to look around and identify a need, taking into account your timeline and resources. If it's something you're passionate about or that will have a direct impact on your own health, even better. You're far more likely to be persistent if it's personal. If you're still having a hard time finding a problem to solve, either you're in the wrong field, or you need to ...

2. Involve the experts

Unless you're a healthcare provider creating an app for your own use (which happens from time to time), enlisting the help of a domain expert to assist or advise is an absolute requirement. Anecdotally, neglecting to do this is the second most common mistake I find when reviewing new app concepts. This error is typically the result of a developer or entrepreneur from a non-healthcare field who sees an opportunity in healthcare, yet either doesn't understand the importance of this expertise, or doesn't understand how to break into the academic ivory tower to reach these content experts.

I'll be the first to admit that physicians at large academic medical centers (AMCs) are not easy to reach. And even if they were, it's not easy to know who among the thousands of physicians would be willing and able to help. There's not an easy fix for this, although many AMCs are establishing centers of innovation that serve to connect innovators within an institution to interested innovators and entrepreneurs on the outside. Through the Duke Institute for Health Innovation (DIHI) we're attempting to accomplish exactly that through regular "office hours" and forums open to the local startup and business communities.

3. Integrate. Integrate. Integrate.

While all three tenets are important for practical reasons, integration is one of my passions. According to IMS Health statistics from October 2013, there were 43,000 health/nutrition/fitness apps in the App Store. How many of those do you have on your phone? How many do you use regularly?

In a highly scientific poll conducted at the 2014 mHealth@Duke Conference this past April, I asked the audience to raise their hands if they had 1 health/nutrition/fitness app on their devices that they used regularly (i.e., once per week). About 70% of the audience of about 200 self-selected mHealth aficionados raised their hands. 2 apps? About 20% remaining. 3 apps? Down to 10 people. 4 or more apps? Only the conference organizer still had his hand in the air.

Wow.

Should we be surprised that further saturation of this market with one-off apps consistently yields more busts than booms? Yet, integration in the current market is hard. Many popular fitness services offer convenient APIs, but integration with EHRs remains elusive. Hence my excitement about the HealthKit and Google Fit announcements. These technologies will enable a new generation of consumer-centric apps.

Of course, consumer-centric apps are only half the story. Providers also want apps that increase efficiency while enabling them to spend less time on the computer and more time with living, breathing patients. This problem - enabling provider-centric apps in healthcare - is one I'm actively working to solve, and I hope to have more to announce later this year.

Next steps ...

If you've taken into account these three tenets while planning your new app, you're well on your way. Of course, you still need to target the right audience, ensure that it's easy to use, make sure it's visually appealing, market appropriately, etc., etc., but you already know about those. Over the coming weeks I'll further expound on each of these three tenets, but in the meantime I welcome your thoughts and ideas. The world of mobile healthcare is still young, and we have much to learn from one another.