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.

ResearchKit is Official at Duke: Autism & Beyond

Over the past 6 months there's been something brewing at Duke ... something that we're now incredibly excited to share with the world.

But first, a bit of background:

• 1 in 68 children will be diagnosed with Autism
• Autism can be diagnosed as young as 18 months old
• The average age of Autism diagnosis in the US is over 5 years old
• A child's brain will grow at a rate of 700 synapses/sec in the first years of life
• 70 counties in NC have no access to a childhood mental health specialist
• In Africa, where there are approximately 500 million children, there are only about 50 childhood mental health specialists

Do you detect a need?

We do, too.

Thus, Autism & Beyond was born. Autism & Beyond is an incredible new ResearchKit study that builds upon the groundbreaking work of Geri Dawson, Helen Egger and Guillermo Sapiro, who over the past several years have been working to refine novel video algorithms that can analyze and detect a child's emotion in real-time. They've been conducting studies at Duke clinics using an iPad prototype app for almost 2 years.

In early 2014 I had the pleasure of working with Kathleen Campbell, a wonderful 2nd-year medical student on her inpatient Pediatrics clerkship. I was her attending physician at the time. Shortly thereafter, and knowing I had an interest in mobile technology, she gave me a demo of an app that the aforementioned team had put together. The idea and technology were amazing. I thought it was great work, although I really had nothing to add at the time. I looked forward to seeing the results of that research.

Fast forward to March 2015, and the announcement of ResearchKit. It was clear that we needed to put this technology to the test, and quickly. We cast a wide net looking for "shovel-ready" projects, and of course, the autism app Kathleen showed me bubbled to the top. The project was already underway (with an iOS app no less!), and had a great team that had already made significant strides in this area. It was an natural fit.

It was also a remarkable coincidence that at this exact time within the Duke Institute for Health Innovation (DIHI) we had just hired two talented mobile developers, Mike Revoir and Jamie Daniel, who were (are) passionate about mobile technology, health, and research. They were so excited about the project that they were eager to dive in even before their first official day of work! As the scope of the project grew, so did the number of individuals and teams involved. In the end, it was a peerless example of cross-institutional collaboration across Duke University and the Health System. This project couldn't have happened without any of them.

Autism & Beyond

So what about the actual app? I could explain it in detail here, but seeing is believing, so go download it now! And if you want more info, check out the website. Even if you don't meet the eligibility criteria, we've made it simple to get a taste of the cool technology that's gone into it without ever signing up.

    

The app basically comes down to our need to know one thing: could we one day use a mobile phone to automate screening for conditions such as autism or anxiety? To start, we first need to know if it's even feasible to analyze facial expressions on such a small device. That's what this study is intended to determine: feasibility.

As you can see from the screenshot above, the software algorithms developed by Guillermo and his team not only detect facial features, but also expressions, and can do so in real time. The data from this study will help to refine those algorithms.

In addition to the facial recognition pieces, we've also included several critical questionnaires with the help of Helen and Geri. For example, we ask about temper tantrums and provide feedback to users regarding where their child falls compared to his/her peers.

Additionally, study participants will be able to see how many other families have enrolled as well as a few additional aggregate data points:

Check out the number of enrolled
participants in near real-time!

While the release of the app marks the end of one chapter (and a whole lotta work by our incredible team!), it's clearly just the beginning. We hope that the app will have an impact in the US, but also plan to roll it out in China and South Africa soon. The more children we can reach, the more we can help. While ResearchKit allows us to reach millions, we still need to take care of one child at a time, and ensure that those children have access to the resources they'll ultimately need for full diagnosis and treatment. That's going to take even more teamwork!

Duke's on FHIR (for real this time)!

In June I described our work to date on integrating the SMART and FHIR APIs into our Epic-based EHR.

As a recap, we started this process in 2014 with a custom Android app that pulled patient problems, medications and demographics directly from the EHR via simple REST-based APIs. As we became more familiar with SMART and FHIR, we realized the value in joining forces with a common standard. It was never our intention to create something that would only be useful to us, and it was clear that the momentum around FHIR was building.

Fast-forward to January 2015, when we had our first SMART apps running in our proof-of-concept environment. It could be done! We followed this with integration of several additional apps and a demo at HIMSS in Chicago. You've seen this before:

This was all fine and dandy, but it was still all in our proof-of-concept system with "fake" patient data.

Since that time our amazing development team, led by Felipe Polo-Wood, has been diligently working to move this infrastructure into our production environment, an important milestone in order to show that SMART and FHIR can do more than just play in the sandbox.

I'm happy to report that as of August 26, 2015, the infrastructure has been live for some Duke-specific internal use-cases. In fact, Felipe was so excited to share that I had a screenshot waiting in my inbox that morning, demonstrating that the systems were, indeed, calling the FHIR APIs, and that the transition was seamless from the outdated infrastructure FHIR was intended to replace:

Duke was officially on FHIR!

But not ones to rest on their laurels, the team immediately got to work to enable a more visible example of what FHIR can do: a true SMART-compatible app, Pediatric Growth Chart.

Drumroll ...

On October 9, 2015 I successfully logged into our production system for the first time to view real patient data in a FHIR app! I'd love to share screenshots with you, but they contain real patient data, so I can't! Let me say that again: real patient data, via FHIR, within Maestro Care, our Epic-based EHR.

And, of course, the best is yet to come!

Kudos to Felipe and the rest of the incredible CATS development team for making this happen. It has truly been a team effort, and I know they share the same enthusiasm for this project as I do, because they're always smiling!

The incredible CATS team:

• Felipe Polo-Wood (Señor Manager)
• Vince Guaglione
• Lusia Li
• Luiz Omori
• Carrie Porterfield

White House Champions of Change in Precision Medicine: Duke's Commitment

Today I had an opportunity today to attend a White House event highlighting work in the field of precision medicine. I was joined by my colleague Geoff Ginsburg who directs the Duke Center for Personalized and Precision Medicine (video replay here, with Geoff's comments at 2:08:30). As part of the event, Duke was highlighted for our commitment to precision medicine. This was for two reasons:

• The innovative MeTree platform created by Geoff, Lori Orlando and the rest of the MeTree team. This platform provides a way for patients to work together with their doctors to improve the recording of their detailed family health history - information that is critical to the success of precision medicine.
• The fact that the MeTree platform will be integrated into our Epic-based EHR using SMART on FHIR. Duke is an "Implementer" of the Argonaut Project, and was the first health system with an Epic-based EHR to run unmodified SMART apps directly (see our HIMSS demonstration video here).

As I've said elsewhere, we're on the verge of a renaissance in healthcare technology modularity and interoperability, led by open and familiar standards. The same principles that have led to the successful mobile app ecosystem are being applied to healthcare, with the result that many more innovators will have access to tools that allow them to build EHR-compatible apps. The problems in healthcare are enormous, and the more brilliant minds we have focused on these problems, the more likely it is that we'll find compelling solutions, and soon.

Geoff shared a few comments with the group at the event today, which I've shared here with his permission:

Good afternoon. My name is Geoff Ginsburg and I direct the Duke University Center for Applied Genomics and Precision Medicine. 

It is an honor for our work to be recognized at this Champions for Change for Precision Medicine event. I want to acknowledge up front the support of the Duke Health System, of my colleague Ricky Bloomfield (Director of Mobile Technology Strategy and hospitalist at Duke) who is in the audience and of Lori Orlando (a health services researcher and internist at Duke) who could not be here today but who has been key to the development of this idea and making it real. 

Today we are announcing the development of a platform that will make it easier for the patient to provide information about their family history to their provider and for providers to access family history and risk information to better care for their patients
 -- information that is critical to precision medicine. 

Several years ago we recognized that family history is fundamental to optimizing effective clinical approaches to personalized and precision medicine. However, our research showed that seldom, if at all, was a patient’s family history captured and adequately documented by providers. Furthermore, when histories were taken, there were challenges in interpreting the risk information in a multigenerational family history.

How many of you in the audience have had a truly detailed family history taken by your doctor and learned something from the results?

To address this challenge we created a patient facing, web-based, evidence based software platform to capture family health history – called MeTree. Patients talk to their families and loved ones about what illnesses family members have had and their age of onset and enter the information via the web into our software platform. The information is used to calculate risks for developing disease and the results are reported back both to the provider and to the patient creating an effective provider-patient interaction about their hereditary health risks and what to do about them. 

Two years ago we were fortunate to be funded by National Human Genome Research Institute to expand the reach of this platform to five different health systems across the country representing a variety of care environments and demographic groups. 

Now thousands of patients are learning about their family history of disease and using that information with their providers to get appropriate screening, genetic counseling and testing and taking actions to enhance disease prevention. 

Duke is pioneering the use of open, vendor-neutral standards espoused by the Argonaut Project. These standards will be in place by year’s end to enable this platform to be integrated into multiple patient portals and EHRs, which will allow will near universal accessibility of family history information to patients and providers seamlessly --  improving shared decision making related to prevention of inherited disease. 

With commitment comes responsibility. We will now get to work to honor this commitment to the President and to our patients. It is our hope that this work will help facilitate many more innovations from health systems and technology companies in the future so that we can realize our shared goal of higher quality and more cost-effective healthcare in our country.