Today, C-CDA Goes Mainstream at Duke Health with HealthKit in iOS 10

Back in June I broke the news that support for HL7s C-CDA was coming to Apple's HealthKit, giving consumers more control over their health information. This is a major step forward for patient empowerment, and also - of particular interest to me - standards-based interoperability.

But this cool new feature is meaningless if patients can't get access to their health information!

So, I'm very happy to report that today, with the launch of Apple's iOS 10, Duke Health is ready to allow patients to download their C-CDA from our Duke MyChart portal and import it into the Health app, ready for sharing with other compatible apps! This process currently requires accessing the Duke MyChart website, but we hope to add the same functionality to the MyChart iOS app in a future release.

To start, simply log into the Duke MyChart portal from the Safari browser on your iPhone or iPod touch (the iPad doesn't currently support HealthKit). Tap on the My Medical Record tab along the top, then on the Download My Record option. This will take you to a page fitting called Download your Continuity of Care Document. Simply tap the green Download button here (Note: if you choose the option to encrypt the document, you will not be able to open it in the Health app).

The document will then download, and you'll be presented with a screen asking you what you'd like to do with it. If it doesn't say "Open in Health," tap the "More..." button and then select "Add to Health" from the top list. It'll be the icon with the heart on a white background as shown below:

     

You'll then be shown a preview of the record:

     

Including a searchable view of the C-CDA itself (some information here redacted):

If you're happy with this information, simply tap "Save" (see left screenshot above), and the record will be imported into the Health app.

To view this record later, simply open the Health app and select Health Records, where you will be able to view all imported records:

     

If you tap on the individual record from here, you will be able to view it as well as share it with other apps that can accept C-CDAs.

Also note that you are not prevented from importing documents from other individuals. I was able to import my daughters' C-CDAs and view them all from the Health app.

As I've mentioned previously, on import into the Health app there is very little parsing going on - just enough to identify the individual. If you share this document with another app, it will need to handle document parsing itself in order to make use of the structured content. Fortunately, there are already some open source tools popping up to handle such tasks, such as this one written by Alex Nolasco as part of HL7's C-CDA Rendering Tool Challenge, which contains a C-CDA parser as well as an iOS viewer written in Objective-C.

This is a great step forward in our march towards greater patient empowerment and health system transparency. I can't wait to see where the next steps take us!

iPhone 7 and the Case of the Frustrated Consumer

So you've probably heard by now that the iPhone 7 was announced on Wednesday. According to most outlets (and Apple themselves), it's an evolutionary upgrade. Yet, there has been palpable disappointment from many corners of the internet that this version bump didn't follow the traditional "tick tock" cycle of "major upgrade" (i.e., when the version number changed) followed by "speed upgrade" (with the addition of the "S," a tradition harking back to the iPhone 3GS introduced in 2009).

Something has been bothering me about this disappointment, and not in an "Apple Fanboy (or girl)" kind of way. I usually get my best insights while monotonously swimming laps in the mornings, and today was no exception. I was struck by this obvious thought: the majority of consumers (and the media, and Wall Street) - perhaps unconsciously - judge the novelty of new products primarily based on its aesthetic appearance. Beauty is only skin deep. Perhaps there's a greater lesson there for society, but that's not the point of this post ...

But that's not all. The problem with that thought as it relates to the iPhone (and smartphones in general) has to do with Apple's general design philosophy of "form follows function." In other words, the product will be designed with the singular purpose of enabling it to function at the highest level for its intended use.

When it comes to the iPhone, this largely seems to be a solved problem. How much has the iPhone design truly changed since its introduction in 2007?

There's a screen, a home button, speaker(s), volume buttons, a power button, a mute switch. It's obvious that despite the marketing and the version numbers and the minor cosmetic tweaks, the most significant changes have always been related to internal components. Every time. Just take a look at the major advertised features of each release:

• iPhone (first release, need I say more?)
• iPhone 3G: 3G, GPS
• iPhone 3GS: speed, better camera with video recording
• iPhone 4: Retina display, custom A4 chip, front-facing camera
• iPhone 4s: Siri, custom A5 chip, 1080p video recording
• iPhone 5: larger display, LTE, Lightning connector, custom A6 chip
• iPhone 5s: TouchID, dual-LED flash, A7 (first 64-bit mobile chip with M7 motion coprocessor)
• iPhone 6: larger (higher resolution) displays, Apple Pay, custom A8 chip
• iPhone 6s: custom A9 chip, 3D Touch, LTE Advanced
• iPhone 7: custom A10 Fusion chip (quad-core), dual-cameras, water resistance, stereo speakers (no audio jack!)

Throughout all those upgrades, has the design truly changed? If you count moving from rounded edges to squared edges (then chamfered edges) to rounded edges again, yeah, a bit. I guess (if I squint).

So why hasn't there been the revolutionary design change the people are clamoring for (and constantly disappointed when it doesn't materialize)?

Because it's not necessary.

The minor design updates have had no noticeable impact on how people use the phone. Changes in usage have all been driven by the internal upgrades noted above (I count the screen and buttons as internal - the design is the same).

The basic design is already nearly optimal for the device's intended usage. For more proof, look no further than the competition. Since the original iPhone was released in 2007, smartphone designs in general have converged on the standard Apple pioneered: a screen and a button.

So should Apple change the design of the iPhone simply for the sake of change? This seems to be what the public is expecting. Hence their disappointment.

Yet Apple, through Jony Ive's disembodied voice, continues to make it clear that the design evolution (rather than revolution) is quite intentional:

"We have created a product that is the most deliberate evolution of our original founding design." "Our obsession remains to continuously simplify and improve." "iPhone 7 is the most singular, the most evolved representation of this design."

Understanding this is the key to unlocking the future of the iPhone. Do I expect the next iPhone to be the big design revolution people are expecting? Of course not. Do I expect some pretty cool internal changes that might cause me to rethink how I use the device? Absolutely.

In the end, Apple's courage to challenge these consumer expectations is probably the most revolutionary thing of all.

The views contained within this post are my own and do not reflect the views of my employer. Furthermore, I have no financial interest in Apple whatsoever.

Is ResearchKit right for you?

Note: This is the second in a special series of posts jointly written by both Katie Donohue McMillan and me. Katie recently joined Duke as our Innovation Portfolio Manger and brings with her a wealth of experience and a unique perspective from outside the stodgy halls of academia.

In March of 2015, Apple announced ResearchKit, and open-source framework intended to accelerate medical research on mobile platforms. For those of us in healthcare, this made our ears perk up. One of the largest companies in the world is taking an interest in medical research? And providing tools to help us with it? For those of you unfamiliar with the details of ResearchKit, it is a software framework to facilitate the collection of  data from study participants via an iPhone app. The first apps announced at the event supported research around Parkinson’s , Diabetes, and Asthma (to name a few.) Later, apps were released for LGBTQ health and Autism Screening. The possibilities are seemingly endless.

But how do you know if ResearchKit is right for you?

Let’s say you have an idea to study people who have blue freckles. You want to know when people first noticed their blue freckles, how many they have, and if things like sunlight or moonlight increase the number of them. Maybe blueberries have something to do with it? No one really knows, because this blue freckle condition is rare and it’s hard to find more than 10 people in your area with them. You really just want to find more people with the condition and ask them a few questions at different intervals, over 12 months. In this case, Research Kit would be a good fit for you. It is great for surveys. Also, because the app can be downloaded from the Apple App Store, you can enroll patients all around the US and increase the sample size of your rare patient population to ensure that your evidence has statistical significance.

Here are some example screens of survey questions:

Image credit

In addition to surveys, ResearchKit has other standard capabilities, like a self-consent process  (a crucial part of any study), active tasks and data visualizations.

Image credit

Studies that require use of the hardware found in an iPhone would also be ideal candidates for ResearchKit. For example, the Parkinson’s app makes use of the accelerometer and gyroscope to assess the gait and balance of participants. It also employs the touch screen to assess fine motor control through repetitive tapping activities. The MyHeart Counts app uses the pedometer in a walk test that is used to calculate heart risk.

The Autism and Beyond app stretched beyond these standard capabilities to include facial recognition and recording video. If you have an idea that technology can support, ResearchKit’s open-source nature makes it amenable to exploration and experimentation.

So, when wouldn’t you want to use ResearchKit?

ResearchKit works best as an encapsulated study, meaning that everything the participant is required to do to participate occurs within the app. If you are interested in a study that includes both a survey and blood samples, a ResearchKit app could facilitate some of the data collection, but other aspects of the study would be more traditional, and study participants should be educated on the various aspects of their involvement.

Likewise, if your survey questions take an hour to fill out, this also might not be the best choice. People spend an average of 2.6 - 7.5 minutes in a mobile app. If you want them to continually submit data over time, it needs to be quick and easy. 

Are you interested in collecting data unbiased by socioeconomic factors inherent in supporting only a single platform? While ResearchKit is iOS-only, ResearchStack, a comparable toolkit, is available on Android. If you are interested in collecting data from people with either iPhone or Android devices, you’ll have to plan your budget accordingly to pay for the development of two apps. (Likely an additional 75% to 100% of the cost of the first app).

Would you like to track people for more than a year? You may want to also make use of more traditional study methods. Just as we didn’t know about ResearchKit a year ago, who knows what new technology will arrive on the scene in the next year? The possibilities in healthcare tech are endless and rapidly changing and you may not want to tie a long term study to a new mobile technology.

The tools ResearchKit provides to simplify research app creation have already demonstrated that there are ways to dramatically improve our ability to collect data at scale by tapping into the supercomputers that billions around the world have in their pockets. Research is no longer constrained to the ivory towers of academia. Understanding the strengths and limitations of the current version is important to ensure the success of your study. The beauty of ResearchKit and ResearchStack is that due to being open source, they will continue to evolve to meet the ever-growing needs of researchers around the world and improve our understanding of human health.

About Us: Ricky Bloomfield, MD, is the Director of Mobile Strategy and practicing pediatrician at Duke Health. In his spare time he likes to develop software and play with emerging technologies. Katie Donohue McMillan is the Innovation Portfolio Manager at Duke Health. Together, they’re attempting to accelerate the entrepreneurial spirit within Duke and amplify great solutions that improve healthcare.

More information on CCDA and HealthKit

Last week I reported that Apple is bringing support for CCDA to HealthKit, enabling users to download their medical records from any Meaningful Use Stage 2-compliant electronic health record system. At the time there wasn't much additional information available. Since that time, Apple has publicly posted the WWDC session on the topic, which can be viewed here. The portion on Health Records starts at the 17:20 mark.

From the presentation it is clear that Apple allows users to download and view their documents:

One question I've received, however, is what HealthKit does with the document once it has been downloaded, i.e., is it "parsed" in such a way that makes the discreet data elements available for use by other applications, or visible in HealthKit? For example, would blood pressure, weight, or glucose values be added automatically to the appropriate fields in HealthKit?

Currently, the answer appears to be "no." According to the limited documentation of the HKCDADocument Class, the class has 5 instance properties, one of which is the document data as a blob. The other 4 instance properties are parsed from the XML, and include: authorName, custodianName, patientName, and title. These 4 data elements appear to have been chosen to allow the consumer of the data to identify the document and compare with other health documents that might be saved to HealthKit.

At this point it's important to note that each CCDA document saved to HealthKit becomes a distinct entity, and that any de-duplication of data would need to be done by the consumer of the data. For example, if a user downloads a CCDA from their patient portal, then re-downloads the document a month later, those are saved as two, separate documents, and the second document would contain all the information from the first document, plus any additions from the past month.

So, if the user gives your shiny new health app access to these documents, you (as the developer) will need to decide whether you pull only the most recent document or whether you pull all of the documents and harmonize the data yourself (a good bit of work).

In speaking with some of my colleagues, it might also be helpful in a future version of this implementation to have access to additional HKCDADocument properties to facilitate positive patient identification, such as date of birth or phone number (which is increasingly becoming part of our identities!). This will be important because HealthKit does not limit a user to only import his or her own health records. Work on a national patient identifier would definitely be helpful here!

Despite these limitations, the importance of giving patients access to their own data in this way cannot be overstated. This is a watershed moment. Yes, it allows hospitals and users to fulfill the intent of the MU2 requirements, but more importantly, it empowers patients to be stewards of their own data, and to decide when and how it will be used to improve their health.

CDA/CCD Coming to Apple's HealthKit!

HK and HL7, together at last!

Today I was fortunate to be able to attend the keynote presentation for Apple's annual Worldwide Developers Conference, or WWDC (aka, "dub dub"). The presentation itself focused on Apple's four primary OSs: watchOS, tvOS, macOS (bye "Mac OS X"!), and iOS. Personally, the most exciting keynote announcement (besides emojis that are 3x the size!!!) was a new apps called Swift Playgrounds, intended to help teach children to code. My 10 year-old daughters will love it (heck, I will love it)!

But for me, the most exciting announcement did not come as part of the keynote. The most exciting announcement is that for iOS 10, Apple will add support for HL7's Clinical Document Architecture (CDA) and the Continuity of Care Document (CCD) directly to HealthKit. For those unfamiliar with CDA/CCD, it's basically a standard way (using XML) to describe an individual's health history in a single, structured data format.

This means that any app (such an EHR patient portal app) will be able to share a CCD with the user in order to save it to HealthKit, and that any app can then get permission to read the CCD from HealthKit.

In other words, this gives a user more control over his/her medical information than ever before.

This is huge. I've spoken previously about paternalism in medicine and how patients are often the least empowered of their own care team. This needs to change fast, and Apple's inclusion of CCD as a first class citizen in HealthKit will usher in a new breed of health apps that empower patients and give them more choice in what they can do with their health information. The is one of the precise goals of the NIH and ONC's Sync for Science project: to allow individuals to 1) access and 2) donate their data to science.

The contents of the CCD are also informing the work on SMART and FHIR related to the Argonaut Implementation Program, which aims to standardize the way we implement FHIR on various systems, focusing on use cases that represent what the CCD can do.

Ultimately, the more we can put users in control of their own health, the better of they will be. I welcome this significant step in that direction.

Update: The developer documentation isn't yet available, but the placeholders for HKCDADocument and HKCDADocumentSample are on the web.

What is Health Technology Innovation?

Note: This is the first in a special series of posts jointly written by both Katie Donohue McMillan and me. Katie recently joined Duke as our Innovation Portfolio Manger and brings with her a wealth of experience and a unique perspective from outside the stodgy halls of academia.

A new app? A new device? An old device used in a new way? And old interface put to a new use? None of the above?

We bet many of you share our frustration with the term innovation. Overused, cliché, and now practically blasé, the word has clearly lost its way, the meaning diluted through inclusion in overzealous marketing phrases and conference taglines. If we had a dime for every time someone around here used the word innovation, we’d probably have enough funding to build several ResearchKit/ResearchStack apps that incorporated the HoloLens and Scanadu Scout. We’d get all our transplant patients a 3D-printed organ (or two). We’d be able to buy all of Duke Health patients their own Apple Watch.

Yet, with all the overuse and confusion around the term, it still means something to people that is not represented more clearly through use of another word. For us, it’s the belief that we can find new ways to improve health for all humankind. So we’re not advocating that you jettison “innovation” from your vocabulary. At least not yet.

Merriam-Webster defines innovation as “a new idea, device, or method.” Yet in healthcare, we see “new” things all the time that subjectively don’t rise to the level of innovation. Does a new generic drug, another patient portal app, moving data to the cloud, or the implementation of an electronic health record really fit the bill?

Some would argue, though, that something doesn’t have to be groundbreaking to be innovative. Maybe integrating an existing clinical risk calculator into an EHR could be considered innovative - it could save time and improve care. Allowing patients to view their doctors’ notes is breaking down the centuries-old paradigm of paternalism in health care. Giving patients a way to electronically consent for a study with tools like Research Kit can increase study enrollment by orders of magnitude.

Perhaps we’re simply demanding too much of the poor word and the people who use it? Or we’re spoiled by the constant miracles technology has wrought to the extent that the miraculous has become mundane. That one entrepreneur’s great idea has simply become another executive’s IT expenditure.

We will be exploring the concept of innovation over the next year. What is innovation? What does innovation mean? How do you cultivate it within a healthcare system? How do you support innovations and entrepreneurs?

This question may be unanswerable, or there may be a thousand right answers. What do you think? What does innovation mean to you?

About Us: Ricky Bloomfield, MD, is the Director of Mobile Strategy and practicing pediatrician at Duke Health. In his spare time he likes to develop software and play with emerging technologies. Katie Donohue McMillan is the Innovation Portfolio Manager at Duke Health. Together, they’re attempting to accelerate the entrepreneurial spirit within Duke and amplify great solutions that improve healthcare.

Work Can Wait!

That's at least a weeks' worth of email!
Image credit: http://ios.wonderhowto.com/

Work-life balance has always been a topic about which I've been passionate. It's important to enjoy life outside work! Achieving - and maintaining - such balance is not only good for our interpersonal relationships and mental health, but I believe allows us to bring more energy and creativity to our work.

Now, the medical profession isn't known for being conducive to work-life balance. Medical residents work up to 80 hours per week (and it used to be more!) and many physicians end up working even more than that post-residency, when there are no duty hour restrictions.

As you all know, I'm passionate about the power of technology to transform our lives, and I have no doubt that we are beginning to see real change in healthcare because of it. Arguably the greatest technological advance in the last century has been the Internet, with the greatest benefit being the ease with which we now communicate. Messages that used to take weeks or months to arrive now take milliseconds. In place of quill and ink we now have Skype and FaceTime. Collaboration can now take place in real time with multiple users around the world editing the same document simultaneously.

But with the obliteration of our communication barriers has also come the obliteration of critical boundaries between work and our personal lives. Since it only takes seconds to send a text or email (or millions of them, for that matter ...), we do it without a second thought. And while we may not intend for the person on the receiving end to feel obligated to immediately respond, they often do, especially if the email is sent from someone higher in the chain of command.

I understand that in healthcare there are times when it's important to respond immediately to a request. People don't just get sick M-F, 8-5pm (that would be innovation!), but that's not what I'm talking about here. Most of my time is spent in healthcare IT, and while there are healthcare IT emergencies (we want our EHR running 24/7, after all), those are fortunately very rare. Most of what I do - and most of what typical office workers do - can wait. That's right. Work can wait.

And not only can it wait, but it should wait. The following dialog has been uttered many times in our household when my (10-year old) daughters have been overcome with emotion related to needing something immediately: "Are there meteors raining down upon us? Are there volcanoes erupting in central North Carolina threatening to submerge us in boiling lava? Are there earthquakes rending the earth and attempting to swallow us whole? No? Ok, then we can probably take a breath and deal with this a little later." In work terms, "a little later" is usually the next business day.

For many, this is easier said than done. One of the most common reasons I hear for after-hours email is: "That's the only time I have to do it! I have meetings all day!" Okay, well, that's a problem for another day. The most common malady I encounter at Duke is not bronchitis, but meetingitis. There are ways to improve that, too, like scheduling a personal, recurring meeting every day - with yourself - to do your email. I also understand that there are also times when it's just more convenient to respond to an email after hours, or perhaps you just want to get that email out of your inbox (I do like a clean inbox!).

But how can you handle that email without making the recipient feel obligated to immediately respond? One way is to set an expectation with your coworkers that they are not obligated to respond to after-hours correspondence (which I do), but another way is to compose the email, but schedule it to go out on the next business day. I actually use a Mac Mail plug in called SendLater (although now called MailButler) that does this exact thing. Microsoft Outlook has a similar feature built in. This way I can tend to the email when convenient for me, yet not burden others unnecessarily. Of course, my first priority is to get the email done during the work day, but this works for me as a backup when needed. So for those of you who may have noticed flurries of emails from me at 7:00am sharp on weekdays, now you know why!

This is something I've been thinking about for a long time, but I have to admit that my post was in response to reading David Hansson's (the creator of Ruby on Rails) comments found here. That's also where I borrowed #WorkCanWait. So kudos to David!

I also recently read John Halamka's post on business spam - BIDMC has instituted a "Zero Tolerance" policy and has set up a blacklist on their network using a commercially available appliance. That's another approach to simplifying our work lives, and one I'd love to try out!

So let's all roll up our sleeves and get to work ... enjoying our newfound free time! I've been meaning to teach myself how to play the guitar ...

Does HIPAA Apply to Your App?

There has been lots of confusion in the marketplace regarding when the Health Insurance Portability and Accountability Act, or HIPAA (one 'p' and two 'a's), should apply to mobile apps. You can read more about HIPAA here.

Typically, confusion ≠ innovation.

Recently the Department of Health and Human Services released a new website targeted at mobile health app developers via the Office of Civil Rights. This site was intended to open a dialog regarding issues relevant to mHealth developers, and one of the issues likely raised by many was the applicability of HIPAA. In response to this, they recently updated the site with additional guidance, found here.

This document, only a few pages long, helps to clarify a number of issues through relevant examples. The questions it attempts to address are:

1. How does HIPAA apply to health information that a patient creates, manages or organizes through the use of a health app?
2. When might an app developer need to comply with the HIPAA rules?

Please refer to the document for all the detail (and it makes clear that a slight change in the facts of a situation may change the applicability), but here are some highlights:

"A consumer downloads a health app to her smartphone. She populates it with her own information."

Developer is NOT a HIPAA Business Associate.

"Consumer downloads a health app to her smartphone that is designed to help her manage a chronic condition. She downloads data from her doctor's EHR through a patient portal, onto her computer and then uploads it into the app. She also adds her own information to the app."

Developer is NOT a HIPAA Business Associate.

"Doctor counsels patient that his BMI is too high, and recommends a particular app that tracks diet, exercise, and weight. Consumer downloads app to his smartphone and uses it to send a summary report to his doctor before his next appointment."

Developer is NOT a HIPAA Business Associate.

"Consumer downloads a health app to her smartphone that is designed to help her manage a chronic condition. Health care provider and app developer have entered into an interoperability arrangement at the consumer’s request that facilitates secure exchange of consumer information between the provider EHR and the app. The consumer populates information on the app and directs the app to transmit the information to the provider’s EHR. The consumer is able to access test results from the provider through the app. "
Developer is NOT a HIPAA Business Associate.

In all of these cases, the developer is not a HIPAA Business Associate because the developer is not creating, receiving, maintaining or transmitting protected health information (PHI) on behalf of a covered entity or another business associate. That last piece is the key. The consumer made the choice to take these actions, and the consumer has the right to do what she wants with this information.

This last example is also what would likely apply when a consumer chooses to make use of Apple's HealthKit, which we have been using for over a year here at Duke. The way it's set up here, even when a physician makes a recommendation to have a consumer share his/her information in order to facilitate care, the consumer can choose to do so manually via MyChart or via HealthKit. HealthKit is never required - it's the consumer's choice.

There are two additional examples in the document regarding cases when the developer would be a business associate. Those include the following:

"At direction of her provider, patient downloads a health app to her smart phone. Provider has contracted with app developer for patient management services, including remote patient health counseling, monitoring of patients’ food and exercise, patient messaging, EHR integration and application interfaces. Information the patient inputs is automatically incorporated into provider EHR."

"Consumer downloads to her smart phone a mobile PHR app offered by her health plan that offers users in its network the ability to request, download and store health plan records and check the status of claims and coverage decisions. The app also contains the plan’s wellness tools for members, so they can track their progress in improving their health. Health plan analyzes health information and data about app usage to understand effectiveness of its health and wellness offerings. App developer also offers a separate, direct- to-consumer version of the app that consumers can use to store, manage, and organize their health records, to improve their health habits and to send health information to providers."

Hopefully this helps provide a little clarity regarding when HIPAA is relevant. If you have additional questions, I suggest submitting them to the mHealth HIPAA site referenced above.