The Case for a Patient-Centered EHR: My Dad (full post at Medscape.com)

In the 10 years since my father was diagnosed with multiple myeloma, he has accumulated thousands of lab results, hundreds of physician progress notes, and dozens of imaging studies. Because his myeloma has been hard to treat, and perhaps because he is a well-regarded physician in his field, he has accessed the best care available, including fantastic doctors and new therapies available at distant research centers.

Despite the fact that all of his physicians use electronic health records (EHRs), nobody actually has his medical record. It does not exist. Rather, his thousands upon thousands of data points are scattered across the country, with no one health system or physician having unified access to all of it, including my dad.

As a clinical informaticist, I spend a lot of time thinking about interoperability—the extent to which systems are able to exchange data and subsequently present those data such that they can be understood by a user—but nothing prepared me for seeing my dad play the role of his own health data aggregator.

Tracking data over time is a key component of multiple myeloma care. Imaging scans looking for bone lesions and the “light chain” blood tests that measure the myeloma cancer protein are done periodically to assess response to treatments. Each result, depending on its direction, either brings a sigh of relief or a rise in stress and fear along with a shift in treatment regimen. To optimize my dad’s care, his doctors would need to see the full picture: the imaging, labs, and each historical chemotherapy treatment over time.

You can imagine how this ideal interface would look, with a nice, clean graph showing his light chain results, imaging, medications tried (and failed), and the location of his treatment. But no such graph exists. Worse, it cannot exist in our current system because each health system where my father is treated is only responsible for their portion of his overall medical record.

Keep reading full post at Medscape.com (warning: requires Medscape account)

The Four Key Features of EHR Integration: Move Beyond “Data Dumping”

A rapidly growing number of health innovations such as mobile apps, diagnostic tools, and sensors are being developed with a focus on enabling health and wellness outside of the traditional medical office visit. As Eric Topol points out in his new book, The Patient Will See You Now, many of these tools will help people independently understand and manage their health. A long history of medical paternalism will be overturned as health information is returned to the individual and autonomy restored. This is a great trend.

However, we do not have to create an “either-or” dynamic where some health information is held by the healthcare system and other information by the individual. These new technologies will be maximally useful when they enable and facilitate a deeper, richer dialogue within the context of existing doctor-patient relationships. To achieve this more coherent and comprehensive healthcare, we need to bring together the patient, her digital health information from new sources, the doctor, and the EHR.

These concepts of interoperability and EHR integration are being widely recognized as crucial over the next few years in healthcare, as evidenced by the JASON Task Force’s recommendations and the formation of the Argonaut Project.

What concerns me as a practicing physician and informaticist is when I hear people discuss EHR integration as if it means only this:

Data Dump

This represents the idea of taking every single data point collected by mobile apps, sensors, and other tools and passing it all straight through into the EHR. I am always reminded of one of my favorite scenes from I Love Lucy, but instead of desperately trying to stuff chocolates into my cheeks and clothing, the medical conveyer belt could make physicians unable to keep up with massive quantities of inbound data from patients.

I Love Lucy

I think it is this sentiment that has led to articles like this one posted in August 2014, saying that “doctors don’t care about your FitBit data.”

Doctors Dont Care About FitBit Data

I disagree. The truth is that I might care about your FitBit data, depending on the clinical situation, the context of that data, and the way in which it is presented to me. I just don’t know yet. I think it is very likely that there will be many of these situations where your activity tracker data matters a lot! We can do better. We can use new information sources when they are helpful and add value by weaving together a comprehensive view of a patient’s health information that facilitates better conversations between individuals and their doctors, and thus better care. This means that patient-generated data cannot be siloed off from the EHR. It instead must be incorporated into clinical workflows as part of the EHR. To achieve this vision of a more complete EHR integration, I think we need the following:

Four Key Features of EHR Integration

1: Discrete data points: I know, I know. Didn’t I just say we don’t want this? I actually believe we still do want access to discrete data. It just cannot be the beginning and then end of integration. Also, this refers not just to data coming in to an EHR from outside, but clinical data flowing out from an EHR to an app or analytic tool, such as your medication list, medical history, or recent hemoglobin A1c values.

2: Analytics and decision support: We need intelligent rules, filters, and analytics to help route information at the right time to the right person and right place. These rules will work best if they can use data from inside the EHR along with these new, patient-generated data sources.

3: App and workflow integration: Talented and innovative software developers and others are creating new ways of presenting information, such as disease-specific data visualizations. We need to make it easy for physicians to access these within the context of their daily work in the EHR. Physicians are not going to launch and log-on to their EHR and three different applications to compare data, no matter how snazzy and how much media buzz your new app has. Moreover, we should be able to do clinical documentation, make a therapy change, or order further diagnostic testing from within the confines of a new tool and have that documentation, prescription, or lab “order” feed back into our EHR for action. This will keep your medical chart and health record more comprehensive and easier to follow, with less information scattered around different places.

4: Communications integration: Finally, with all of this information passing back and forth, each system is going to be capable of sending and receiving messages between the doctor, patient, family members, and other care team members. Nobody will want to log-on to every individual account to check messages. So, we need to be able to intelligently integrate and route messages so that each person can send and receive messages from the “hub” application that makes most sense to them.

At the UCSF Center for Digital Health Innovation, we are excited to be working toward this vision of comprehensive, workflow-driven EHR integration.

(This post is based on a talk I gave at the Diabetes Technology Meeting in Bethesda, Maryland in November 2014.)

A Lesson In Clinical Decision Support: We Cannot Defeat Human Nature

      Our UCSF Clinical Informatics group met a few months ago with several representatives from a major Health IT vendor. The vendor, we’ll call them RxLabs, is a provider of pharmaceutical related knowledge in many domains, including decision support tools for the EHR. Our conversation centered around how to better customize medication alerts. We talked about the popular topic of “alert fatigue,” and how to improve EHR decision support tools to improve their impact, rather than just being white noise annoying clinicians.
      The vendor was walking us through a slide-deck about their hypotheses and data about EHR medication alerts and we were having a vibrant discussion about how to improve provider adherence with decision support. We saw slide after slide about how to make pop-ups smarter and about trying to get more buy-in from providers with paying attention to alerts. After all, why would a provider trying to take care of her patient ignore an alert that is trying to help provide an important message? It must be sloppiness or laziness on the part of providers!
      Ten minutes in to this conversation about drug alerts, up pops the following:
Windows 7 Display Alert
      I’ll give you a second to guess what happened next.
      Without a moment’s hesitation or thought, the presenter clicked the little X in the upper right corner. Our conversation went on. More slides. More data about medication alerts in the EHR. Ten minutes later, guess what happened?
      Up came the same pop-up Windows alert. The presenter again, hastily, without paying attention, and perhaps giving a small huff of displeasure, clicked the little X in the upper right corner. More slides, ten more minutes, same thing. You get the idea.
      This happened three times, with each passing pop-up, the presenter becoming slightly more annoyed. The fourth time the pop-up appeared, my colleague Russ Cucina, the Associate CMIO at UCSF, paused the presenter to have us all read the pop-up alert message. We took ten seconds together to learn that selecting any of the three choices rather than clicking the “x” would have satisfied the alert and kept it from coming back.
      The room broke out into laughter. We all understood our own hypocrisy. We cannot defeat human nature.

What I Learned At Epic UGM… And Other Random Thoughts

Epic’s User Group Meeting (UGM) is a Healthcare Conference
The Epic EHR is so ingrained in healthcare now that the UGM conference is really a healthcare conference, not an IT conference. This was a conference where more than 10,000 healthcare professionals met to share best practices about how to run a healthcare organization and deliver care, and oh by the way, the tool you’re using is this software called Epic.

There were clearly dominant themes this year among the priorities of the healthcare organizations in attendance:
1— Population health and ACOs
2— Patient-______: patient-engagement, patient-centeredness, patient reported outcomes, patient collected data, patient portal, etc
3— Health information exchange
4— Capture and use of discrete data by physicians
5— E-visits and video visits to improve access (and maybe end the long reign of the office visit)
6— Algorithms and analytics, especially with combining of multiple data sources
7— Personalized medicine using genomic data and home-collected data alongside traditional clinical data

Epic Should Do SaaS
If I were Epic, I would develop a SaaS (Software as a Service) version (call it “EpicLite”) and cannibalize my own business from the bottom up. Epic is making some fantastic improvements to their software, but a major complaint you hear around the lunch tables at UGM is that no organization has the resources to implement all of Epic’s features and functions. Epic has made their software endlessly customizable in an attempt to please customers who asked them for such customization. But the end result is that we all bog ourselves down. I’d like to see Epic push back a bit more against what we all tell them we want, be bolder, and push out software to us all that just works out of the box. They can start with the “EpicLite” version and sell it to organizations less complex than the very large customers they most frequently serve now. Follow the 80/20 rule, pick the things that work best, and give it to people. I promise that we will complain, but then we will deal with it and save a lot of money and effort. They could then slowly move up-market with this SaaS version to sell it to the more complex and large customers in true Clayton Christiansen-esque disruptive innovation to disrupt their own core business. To analogize based on one of Christiansen’s examples, they won’t want to be selling mainframes in ten years when everyone wants PCs.

Open.Epic and Apple HealthKit Integration
I’ve heard a lot of skepticism about this effort over the past year because Epic has always had the reputation of being a very closed system, but Open.Epic should change that perception. I think that this is going to be a big deal. I believe that a major reason for the lack of success of many digital health apps is that they are silos and built in standalone fashion. Let’s face it: the EHR is the hub of clinical workflows and no matter how cool and important your app is, it is still just an add-on. Apps cannot be successful if they don’t fit into clinical workflows. Therefore, to be successful, the workflow of using an app needs to blend in with the use of the EHR. Epic publishing APIs through Open.Epic for people to connect apps in is a game-changer and will enable an entirely new generation of apps that bolt on alongside the EHR.

Similarly, I think the Epic and Apple Healthkit integration will catalyze many of the currently stagnant use cases for sensor and device data, as it will now easily feed into the clinical environment.

Random Thoughts and Impressive Numbers
I found myself wondering what Epic would be like if it were in Silicon Valley instead of Wisconsin. I don’t think it would be very Epic-like. You probably wouldn’t see them announcing next year’s product releases in the form of a musical.

It is hard to tell how much the healthcare system is shaping Epic’s software development plan versus the other way around. I’m sure it is some of both.

Epic is incredibly successful at energizing its customers and getting them to evangelize and espouse the virtues of their product for them. And we all pay to fly out to Wisconsin to do it! When I walked by it, their usability testing lab had a more than half-hour wait to get in and a line down the hallway.

54% of the US and 2.5% of the global population have an EpicCare chart. There were 5,000,000 Epic<—>Epic information exchanges in Aug 2014.

%d bloggers like this: