Giving Patients Ownership of Their Clinical Data

The healthcare industry is among the most aggressive when it comes to issues related to data collection, access, and privacy, but one clinical data expert believes that the future of health data management lies in turning data ownership over to patients.

Robert Rowley, MD, the chief medical information officer and founder at Flow Health in San Francisco, who previously started physician software vendor Practice Fusion, spoke with Information Management about the growing complexity with capturing and sharing a complete patient data profile, and how these challenges are impacting quality of care.

As noted recently by Health Data Management (a sister publication to Information Management), both patients and physicians complain of a lack of access to important electronic data regarding healthcare procedures, medications, and consultations.

Indeed, at a recent hearing on patient access by the Senate Health, Education, Labor and Pensions Committee, Senator Susan Collins (R-Maine) observed that the “Meaningful Use provision that requires individual providers to have their own patient portals has led to fragmentation, patient frustration with having to access multiple portals, and a lack of incentives for investment in patient access capabilities that extend beyond a single provider,” Health Data Management noted.

Rowley, who has developed a healthcare data platform aimed at turning clinical data “ownership” over to the patient, agrees with Collins’ observation, and says it is the patients themselves that would do the best job of managing patient data access, privacy and security. His views on the topic follow.

Information Management: Please tell us about your firm, and about your patient data platform.

Robert Rowley: Flow Health is my second startup. My first one was Practice Fusion. Flow Health is a platform, a patient-centered data structure for gathering all information about a patient – having it be patient-centered, rather than institution centered.

It can pull in data from payers, from EHRs, from hospitals, from patient entrance sources, from check-ins, from all the different channels that can feed that platform. The patient owns the data. They can grant permission to its access, and it’s something that I believe will be the foundation for the next generation of health IT.

I believe we will move away from the giant one-size-fits-all enterprise solutions that are institution-centric, and which we all know and hate, and will be replaced by a whole new era or stage of health IT that can be characterized as a collection of small apps.

Just like with your smartphone, if your data is in the cloud, you choose the apps that make the most sense to you. They may be different than to the person sitting next to you. But they all interact with the same external data. Since there are so many different settings of care it’s very difficult for anyone to do a good job for every single facet of care, so my belief is that there will be the emergence of focused apps around the workflows of particular kinds of settings, and apps that do things like population health surveys and other ways of extracting data from the data platform once it’s there. That’s the future that we’re going towards.

IM: How does this differ from what we’ve been used to, and how is it that the patient owns their data?

Rowley: Most of the health data now has been built around institutions – institution-centered data, and that results in the data silos. I am the HR exec in my practice and the data that I have is my internal data. If somebody else is using the same or a different EHR, at best we can exchange data though some sort of a data exchange -- which is better than not being able to exchange data at all. But it’s still not universal data. It’s only as good as the hubs of the connectors. The data is still institution-centric.

When you build a data layer that has the patient at the center it implies several things. It implies that you have to do a really good job of unique patient identification, so that you can attach not just the EHR data, but claims data, and other sources of data – hospital notifications, ADT notices that the patient was in the emergency room, or that the patient was just discharged from the hospital; those kinds of things.

When they all come together into one central place, you can populate a very rich longitudinal record around the patient. There are some implied permissions. If you have submitted a bill for the patient it is implied that you have a therapeutic relationship with the patient.

Based on the sources of data you can create a graph around the patient of who is taking care of them and who has permission to see them. You can also have patient-facing apps that say, “This is who you receive care from because you’ve seen them in the office, we have HR data or have received bills from them for you.” You can edit that, and say, “No I’m not seeing that person anymore” or, “Yes, but there are people I’m seeing that you don’t have on here.” The patient is at the center of granting permission, which really addresses much of the problem that we have in connecting different hubs of data together. One of the challenges with EHRs the way they are now is the question of permission.

I’ve seen in my own back yard in Northern California that you’ll have hospital-based hubs, and then you have a health plan-based hub. The question of who has permission to pull data from each location is really a challenge because it’s the institutions that have to figure out permission. When you build a structure where the patient is at the center, that issue is much more easily resolved. The patient determines who can see their data, and it’s prepopulated by the inferred connections based on who has done billing or who has records in their system about you.

IM: Is ICD-10 complicating this picture?

Rowley: Somewhat, but most of the EHR players have done a pretty good job of making the transition. In my practice I use Athenahealth and its ICD-10 capabilities have been built into it. Yes, you have to learn a new coding system but it’s pretty intuitive. All of the patient problem lists are default pre-populated to a best guess, which you can then modify if you want. If it can’t do a best guess than it will pop down with ways of filtering the list to have it be what you want. It’s just not that big of a burden.

IM: We read that many physicians complain that they don’t have a complete patient record at their disposal and they’re very frustrated. Why so?

Rowley: That is the center of the reason why we have something like Flow Health. That is exactly true. Physicians are doing what they can with the information that they have but the information that they have is an incomplete picture. If you rely on physicians to be the documenters, then you’re going to have an “as-good-as-time-allows” type of data. If you don’t have other sources of data to supplement what you put in, you will have a pretty incomplete picture.

At Flow Health, we have three apps that give ways of populating the patient data layer as well as demonstrating to the app developer community what’s possible. One is a check-in app deployed on iPads that substitutes for the clipboard and asks patients why they are here and goes through the family history and those sorts of things.

You can direct your questioning around that fairly intelligently. By the time the physician sees the patient much of that piece of the chart has already been fleshed out, probably more thoroughly than you would have in an encounter. Patients telling their own story is an important piece that is not well addressed in most of the EHRs.

IM: Are there some general best practice thoughts that you can share about patient data?

Rowley: One of them is going to be making sure that you can create templates, or macros, or shortcuts. If you do certain things repetitively, you want to be able to set up good quick documentation about that. I’m in family medicine but much of what I do is adult internal medicine. Diabetes and hypertension are sort of the bread and butter of what I take care of, so I have good templates set up. So it’s just, boom, boom, boom.

The challenge is trying to get documentation done well in the timeframe allowed when you’re seeing patients in a busy clinic. I know the emergency department will often hire scribes to follow the physician around and do the documenting for them. I think that is a failure of user interface – a bad system that makes it so burdensome and slows you down so much in a busy setting that you have someone do the interface work for you.

I believe that this will not fundamentally change until there is a new paradigm, which I think is going to be a myriad of small apps that compete with each other based on how well they perform. That is down the road but I think that is the direction that things are going to go in.

IM: Anything else?

Rowley: One of the things that is really interesting is a study that I just saw about using algorhythms to comb through patient records and flesh out and discover red flags that were missed by clinicians. If there is a good store of data to look at in a machine-learning kind of way, you can pop up and display in front of a physician – “Oh, by the way, this patient has X, Y and Z.” In other words, red flags, you should be aware of it. That is something I think is exciting and will be more commonplace with ways of analyzing the data and ways of getting hold of accurate, full scope, full story data. To me, that is an exciting thing. The role of physicians is going to be less an originator of knowledge and more the interpreter of data.