The Apple Watch: Counting Calories Counts

I've now spent a few weeks with Apple Watch, and while there's a lot to talk about, one feature in particular has "surprised and delighted" me, and it's not the one I was expecting.

I exercise regularly, but I wasn't expecting Apple Watch to help me much with respect to my routine. That's not because I didn't think it would be accurate or easy to use, but simply because Apple Watch wasn't made for me: I'm a swimmer.

Granted, it's been shown that Apple Watch can withstand a good swim, but it's still not designed to track swimming (I use my Pebble with the swim.com app for that), and Apple specifically discourages it.

So rather than lament Apple Watch's neglect of swimmers the world over, I went for a walk. A few of them, actually (dog needs exercise, too). And what I saw surprised me. Check out the following two workouts that Apple Watch saved to the Health app. Notice anything interesting?

I did a double-take when I saw these results, but then it dawned on me what was going on, and it's super cool. If you noticed, the first workout was a 0.93 mile walk that lasted 17 minutes, during which I burned 66 calories. The second workout was only 0.91 miles, lasted only 14 minutes, yet I burned 72 calories!

So how could a shorter walk (both in distance and duration) lead to more calories burned? While you mull that over, take a few minutes to head over to ABC News to view a 5-minute video about Apple's secret fitness lab. I'll wait.

Wasn't that cool? Apple is amassing what is probably the world's largest and most complete set of physiologic data during exercise (over 18,000 hours and counting), all while volunteers wear Apple Watch. This testing takes multiple factors into account, including activity level (accelerometer), heart rate, temperature, and probably also factors in height and weight when available, although I don't have access to their algorithms to know for sure. The volunteers in the fitness lab also wear specialized (and very expensive) gear designed to accurately measure caloric expenditure. These data can then be used to create accurate data models to fit almost every profile, leading to an extremely accurate estimate of calories burned.

In other words, Apple is validating the watch to be the most accurate consumer-oriented calorie-counting machine ever created.

Of course, this explains the "discrepancy" in my workout numbers. In the second workout, I had to walk much quicker in order to cover 0.91 miles three minutes faster than the 0.93 miles I walked the day before. Apple Watch knew I was working harder because it was tracking my heart rate every 5 seconds for the duration of the workout, and my heart rate reflected the increased activity.

Lesson: to burn calories, nothing can replace good old-fashioned, heart-pumpin' aerobic exercise!

Want to know the coolest part? Measuring heart rate is just the beginning! As I've mentioned before, now that we have a computer in constant contact with our skin, the market for transcutaneous sensors is going to explode, and the more data we collect, the more accurate these measurements will be.

Just hurry it up with the swim tracking, ok, Apple?

ResearchKit is upon us!

Today, Apple has unveiled the open source code to their ResearchKit framework. You can find it here:

http://researchkit.github.io/

I was pleased to see the code hosted on GitHub, which I've found to be exceedingly user-friendly and which we already use here at Duke Medicine.

Also, not only has Apple released the code for ResearchKit itself, but they've also released the code for all 5 of the ResearchKit apps developed to date, as well as the back end code used for those apps, called AppCore. That's the power of open source, folks!

We've been discussing ResearchKit internally since it was announced in March. Anyone waiting for the code to be released before starting on their ResearchKit apps is already behind. Why? I'd estimate that over 90% of the effort required to create a ResearchKit app comes before a single line of code is written. The code itself is simple and straightforward, making it easy to create a consent workflow and make use of active tasks.

But the real work comes in designing the study itself. What do you want to study? Why? What is your target population? Who gets access to the data? How many versions of the consent do you need? Do you want it localized? US? International? Has it been approved by the IRB? The list goes on.

In my opinion, this is the future of research for a certain category of studies that require access to large numbers of individuals for more refined data, or that need access to a very specific and hard-to-reach patient population, such as one with a rare disease.

I've already spent too long on this blog post. Our developers are jumping into the framework as we speak, ready to begin our study implementation. Time to dig in!

Meaningful Use of Patient-Generated Health Data

This week the NPRM for Meaningful Use 3 was made available in "unpublished" form on the Federal Register site. It seems that one of of the primary aims for MU 3 is to streamline the set of objectives applicable to eligible providers (EPs), eligible hospitals (EHs) and critical access hospitals (CAHs).

The new item most interesting to me is Objective 6: Coordination of Care through Patient Engagement (starts on page 103 of the linked document).

This proposed objective aims to "Use communications functions of certified EHR technology to engage with patients or their authorized representatives about the patient's care" and employs three measures:

Measure 1: >25% of all unique patients "actively engage with the electronic health record made accessible by the provider" either by 1) viewing, downloading or transmitting to a third party their health information; or 2) "access[ing] their health information through the use of an ONC-certified API that can be used by third-party applications or devices."

I've previously discussed the Argonaut Project Implementation Program and its relation to the SMART on FHIR project. The FHIR APIs and added functionality of the SMART project (OAuth, OpenID) will dramatically lower the barrier for third-parties to easily add functionality and significant value to current EHRs. While these APIs are already enjoying broad support even before they are complete, seeing this emphasized in the MU 3 NPRM is a testament to their importance.

Measure 2: For >35% of all unique patients, a secure message should be sent using electronic messaging function of CEHRT to the patient, or in response to a secure message sent by the patient.

It's critically important that we encourage direct engagement and interaction between patients and providers, and this measure intends to do just that.

Measure 3: "Patient-generated health data or data from a non-clinical setting is incorporated into the certified EHR technology for more than 15 percent of all unique patients."

This is exciting. While patient-generated data can come in many forms, including manual entry by patients, this measure will only be achievable if we employ technologies that reduce or remove such barriers. Apple's HealthKit is by far the easiest-to-deploy tool to facilitate this data handoff currently, and it's available right now. We're hopeful an Android-equivalent will be available soon for patients with those devices (Google Fit doesn't yet ... fit that purpose).

Neither SMART on FHIR nor HealthKit are yet widely deployed or adopted, but these technologies will undoubtedly be critical to ushering in the learning health system, and it's great to see APIs and patient-generated data being emphasized in the latest NPRM.

MU 3, welcome to the 21st century!

2015-03-24 UPDATE: Just to make sure this is clear, MU 3 is still draft at this stage, and the content is subject to change. Also, attestation for objective 6 will require meeting only 2 of 3 of the measures listed above.

ResearchKit - More Details

ResearchKit is exciting, as I've already noted. Apple has posted some additional information in the form of a Technical Overview document. This document publicly sheds a little more light on what ResearchKit will enable.

Apple describes three "modules" available within ResearchKit, including Surveys, Informed Consent and Active Tasks.

Surveys

ResearchKit provides a standardized interface to quickly build surveys. These modules are already localized. This would work for the majority of current research use cases.

Informed Consent

One of the most significant inclusions is native informed consent capability, as you may have seen in the keynote:

Credit: Apple

This is something many researchers have been scrambling to buy, create or produce since it's not currently a common feature of modern EHRs. The fact that this is now available out of the box and in open source form is compelling. The informed consent mechanism is flexible and takes into account the use of waivers, use of institution-specific ethics language, and also provides the ability to insert comprehension tests ensure the patient has capacity to sign. The consent framework then generates a PDF for upload or email.

Active Tasks

As demonstrated in the video today during the keynote, ResearchKit provides the ability to capture patient interactions which Apple calls "Active Tasks." The Active Task modules currently available in ResearchKit include:

• Motor Activities
• Gait, tapping
• Fitness
• 6-minute walk
• Cognition
• Spatial memory
• Voice
• Phonation

All of these are accomplished using hardware built-in to the phone itself.

Open Source

Probably the most significant innovation here, however, is the fact that this is all (or will be soon) open source. For this to succeed and expand, it's vitally important that academic medical centers keep this in mind when developing their apps, and that they choose to share the source of their own apps so other researchers can build on their foundation. This collaboration will be the key to accelerating the transition to a Learning Health System.

ResearchKit and the Future of Healthcare

Apple landed a pretty big bombshell today with the announcement of ResearchKit. And probably the biggest part of the announcement was this:

Yes, ResearchKit is fully open source. Why is that important? Because it means that this technology will eventually be available on any platform. Yup, including Android. And Windows. And whatever else comes in the future.

And it also means that integration between ResearchKit and other emerging healthcare technologies will be possible, including the SMART on FHIR platform, which is leading the way to modernize healthcare interoperability.

Given Apple's commitment to privacy, I have no doubt that the healthcare industry will quickly adopt this new platform, as evidenced by the high-quality institutions already participating.

As I've mentioned previously, the Learning Health System represents the vision of a world in which we are constantly learning from a stream of high-quality data, using that data to quickly make even better decisions, even at the point of care. ResearchKit will help us reach that goal even more quickly, possibly even before the 10-year goal as set forth by the ONC.

Let's get started!

The Why of Wearables

Ten years from now, 2015 may well go down as the Year of the Wearable. Activity trackers are plentiful and accurate (including those built-in to your phone), Android Wear devices are now becoming more refined, the Pebble will see its first substantial upgrade (including 10-day battery life), and, of course, the Watch will launch next month after additional details are revealed later today.

So why have these technologies recently become interesting and relevant? Did some Silicon Valley innovator simply decide that we needed more technology on our wrists (and *POOF*! VC funding suddenly made it happen)?

Of course not. The truth is actually far more interesting, and, when properly understood, is the lens through which we can peer into the future.

Time for a history lesson ...

My grandfather worked on the UNIVAC computer during his time in the Army at Ft. Meade, MD in the 1950s. It was large (and the battery life was really bad...). This is an example of a UNIVAC system that was used by the Navy:

Credit: Wikipedia

At this nascent point in computing history, could anyone have envisioned a device that's orders of magnitude more powerful, yet small enough to fit on your wrist? Perhaps (see #11). But truth is stranger than (science) fiction, and the reality is that in the realm of personal computing we've easily surpassed even the most fantastic futuristic visions of the 1950s.

The invention and subsequent miniaturization of the transistor have accounted for this success, which has followed a trajectory known as Moore's Law, which I won't rehash here. Some have warned that Moore's Law is coming to an end, at least via silicon. I wouldn't be so quick to throw in the towel. The progress is staggering (note a version of the UNIVAC at the bottom):

Credit: AMD via Technology Review

This dramatic miniaturization allowed my family to purchase its first desktop computer in the early 1990s - a Packard Bell with a 66MHz AMD chip inside. I have such fond memories playing Myst with my dad. I had a desktop in college as well (this time a Dell with a 450MHz Pentium II), and it wasn't until I started medical school in 2004 that I owned my first laptop, a sturdy IBM Thinkpad.

This miniaturization continued and I bought my first iPod touch in 2009 to use as a test device while I was teaching myself to write iOS apps in residency. This was followed by an iPad in 2010 (the day they were released, although I should note that the iPad was most certainly not the first tablet computer on the market), and then pretty much every iPhone since then (I now use an iPhone 6 Plus - the first iPhone that actually fits my hands). My first "smart watch" came in the form of the Pebble in 2013, and I've since used a plethora of other gizmos and gadgets that would fall in the "wearables" category.

Notice a trend here?

Computers have continued to progress towards smaller and faster devices, and as they've done so, new applications for that technology have inevitably been the result. "Wearables" are simply the next step in that logical progression.

So don't be surprised as these devices start to pop up in ever smaller and more discrete places, such as the buttons on your shirt, woven into your socks (you gotta know how much your feet are sweating!), mixed with your food, in your medicine ...

If we've learned anything from the past, it's that this progression is inevitable, and that it will only exceed our expectations and our wildest futurist fantasies.

With respect to his latest creation, Jony Ive seems to agree: "It’s technology worn on the wrist. I sensed there was an inevitability to it."

Despite this predicable inevitability, the future will still hold plenty of surprises. And I suppose that's the best prediction of them all.

The Argonaut Project Kickoff

Jason returning with the Golden Fleece

I just got off a kickoff call for the Argonaut Project Implementation Program.

This is, simply stated (and to paraphrase John Halamka on the call today), the most promising path towards meaningful healthcare interoperability we've ever known. Finally, we have modern protocols such as REST, OAuth and OpenID that are being applied to healthcare in a scalable way.

The SMART on FHIR platform epitomizes the work done to date in this effort, and the Argonaut Project is intended as a sprint to get the FHIR DSTU 2 deliverables in time for a May ballot. To be clear, this is still an alpha/beta product and not quite ready for public consumption, but the promise is already quite evident.

When I arrived at Duke in the summer of 2013 (and before the SMART project had been converted to work with FHIR), I had a goal to create a standardized platform for interoperability for web and native mobile apps that would work with our Epic implementation.

Starting in 2014, while we already had a functional implementation of our own framework, we realized that we shouldn't recreate the wheel, and that the SMART on FHIR project was being developed the accomplish the same goals. With that in mind we realigned our efforts to push forward with integration of the SMART platform into our Epic EHR.

As of January 2015 we have a functional implementation of the SMART platform here at Duke in our proof-of-concept environment. We currently have an iOS app and a SMART-enabled web app working against this environment with plans for several more current and future app integrations, including apps developed here at Duke.

We're looking forward to be involved in this Pilot Implementation process (see graphic below) and look forward to sharing more in the coming months, including at HIMSS in April where we will demo these integrations.

Never before have we had such a golden opportunity for robust healthcare interoperability!

Anyone can get involved in this open process.