If you’re getting health care in the U.S., chances are your providers are now trying to give you a better patient experience through a website called MyChart.

This is supposed to be yours, as the first person singular pronoun My implies. Problem is, it’s TheirChart. And there are a lot of them. I have four (correction: five*) MyChart accounts with as many health care providers, so far: one in New York, two in Santa Barbara, one in Mountain View, and one in Los Angeles. I may soon have another in Bloomington, Indiana. None are mine. All are theirs, and they seem not to get along. Especially with me. (Some later correction on this below, and from readers who have weighed in. See the comments.)

Not surprisingly, all of them come from a single source: Epic Systems, the primary provider of back-end information tech to the country’s health care providers, including most of the big ones: Harvard, Yale, Mayo, UCLA, UChicago, Duke, Johns Hopkins, multiple Mount Sinais, and others like them. But, even though all these MyChart portals are provided by one company, and (I suppose) live in one cloud, there appears to be no way for you, the patient, to make those things work together inside an allied system that is truly yours (like your PC or your car is yours), or for you to provide them with data you already have from other sources. Which you could presumably do if My meant what it says.

The way they work can get perverse. For example, a couple days ago, one of my doctors’ offices called to tell me we would need to have a remote consult before she changed one of my prescriptions. This, I was told, could not be done over the phone. It would need to be done over video inside MyChart. So now we have an appointment for that meeting on Monday afternoon, using MyChart.

I decided to get ahead of that by finding my way into the right MyChart and leaving a session open in a browser tab. Then I made the mistake of starting to type “MyChart” into my browser’s location bar, and then not noticing that the top result was one of the countless other MyCharts maintained by countless other health care providers. But this other one looked so much like one of mine that I wasted an hour or more, failing to log in and then failing to recover my login credentials. It wasn’t until I called the customer service number thankfully listed on the website that I found I was trying to use the MyChart of some provider I’d never heard of—and which had never heard of me.

Now I’m looking at one of my two MyCharts for Santa Barbara, where it shows no upcoming visits. I can’t log into the other one to see if the Monday appointment is noted there, because that MyChart doesn’t know who I am. So I’m hoping to unfuck that one on Monday before the call on whichever MyChart I’ll need to use. Worst case, I’ll just tell the doctor’s office that we’ll have to make do with a phone call. If they answer the phone, that is.

The real problem here is that there seem to be hundreds or thousands of different health care providers, all using one company’s back end to provide personal health care information to millions of patients through hundreds or thousands of different portals, all called the same thing (or something close), while providing no obvious way for patients to gather their own data from multiple sources to use for their own independent purposes, both in and out of that system. Or any system.

To call this fubar understates the problem.

Here’s what matters: Epic can’t solve this. Nor can any or all of these separate health care systems. Because none of them are you.

You’re where the solution needs to happen. You need a simple and standardized way to collect and manage your own health-related information and engagements with multiple health care providers. One that’s yours.

This doesn’t mean you need to be alone in the wilderness. You do need expert help. In the old days, you used to get that through your primary care physician. But large health care operations have been hoovering up private practices for years, and one of the big reasons for that has been to make the data management side of medicine easier for physicians and their many associated providers. Not to make it easier for you. After all, you’re not their customer. Insurance companies are their customers.

In the midst of this is a market hole where your representation in the health care marketplace needs to sit. I know just one example of how that might work: the HIE of One. (HIE is Health Information Exchange.) For all our sakes, somebody please fund that work.

Far too much time, sweat, money, and blood is being spilled trying to solve this problem from the center outward. (For a few details on how awful that is, start reading here.)

While we’re probably never going to make health care in the U.S. something other than the B2B insurance business it has become, we can at least start working on a Me2B solution in the place it most needs to work: with patients. Because we’re the ones who need to be in full command of our relationships with our providers as well as with ourselves.

Health care, by the way, is just one category that cries out for solutions that can only come from the customers’ side. Customer Commons has a list of fourteen, including this one.

The first of these is identity. The self-sovereign approach to that would start with a wallet that is truly mine, and includes all these MyCharts. Hell, Epic could do one. Hint hint.

*Okay, now it’s Monday, and I’m a half-hour away from my consult with my doctor, via Zoom, inside MyChart. Turns out I was not yet registered with this MyChart, but at least there was a phone number I could call, and on the call (which my phone says took 14 minutes) we got my ass registered. He also pointed me to where, waaay down a very long menu, there is a “Link my accounts” choice, which brings up this:

Credit where due:

It was very easy to link my four known accounts, plus another (the one in Mountain View) that I had forgotten but somehow the MyChart master brain remembered. I suspect, given all the medical institutions I have encountered in my long life, that there are many more. Because in fact I had been to the Mountain View hospital only once, and I don’t even remember why, though I suppose I could check.

So that’s the good news. The bad news remains the same. None of these charts are mine. They are just views into many systems that are conditionally open to me. That they are now federated (that’s what this kind of linking-up is called) on Epic’s back end does not make it mine. It just makes it a many-theirs.

So the system still needs to be fixed. From our end.






9 responses to “TheirCharts”

  1. Doc:

    Sometimes the “MyCharts” do interoperate. My previous healthcare provider used MyChart, and when I relocated, my new healthcare provider had their own MyChart. Apparently the two organizations (both within Western Washington) had an interoperability deal, as when I logged into the newer one, it offered to link to my previous records, which my new healthcare provider appreciated.
    Usually this stuff doesn’t work… but sometimes it does.

    Steve Stroh

  2. Good to know, Steve.

    Thanks! I’ll check it out.

    [Later…] I did, as you can see from my update to the post. Thanks again.

  3. It seems to me it all boils down to two aspects for inter-operability. One is the Epic APIs and how they are implemented. Two would be some kind of common data format, I’m not talking about HL7 which has to do with diagnostics, my reference is how these different apps are actually storing Data in their own proprietary formats. Hence Vendor lock it

  4. Thanks, Jim.

    Better APIs and common data formats would be good. So would better ways for health care providers to gather information from each others that are not (as I have too often seen) scans of faxes of scans of faxes, and worse. (When I was in the Harvard system, they helped me reach out to nineteen former providers, who sent in a horrible mess of ugly, often upside down and sideways, scans and faxes, none of which were made available or came with me when I left that system.)

    Ideally the system would adapt to formats and protocols and standards that are essentially ours, rather than theirs. We actually got that with TCP/IP, HTTP and other ways of getting along we’re using right now. But we’ll never get it in health care as long as tech giants, insurance companies and captive regulators are running the show for the sake of a market that is by design theirs rather than ours.

    But I do think there are ways to break that apart from the outside, from our side. Starting with funding the likes of HIE of One.

  5. Even with a so-called “national health service” in England, we have the same problem. I’ve had a condition since birth and can’t recall a time when I went into hospital and they had even the most basic history about me available, other than what was sent in the referral. In an emergency, it just doesn’t happen.

    They have been trying to join things up for over 20 years and spent as many billions but frankly, nothing has really changed from a patient perspective.

    I do point to the US as perhaps one of the better examples. They at least had the foresight to understand the need for access and put it into law, perhaps before most others. Moving to APIs is a big leap forward and again, having them open and accessible.

    The NHS has obsessed over its app, but they will never join everything up and even if they could, this app won’t be all things to all people. It’s delusional and/or perhaps politically motivated.

    Even now as they start to open up some of the APIs, there are eyewatering layers of bureaucracy and procedures that can take literally years to get through. It’s not likely my preferred apps or services are going to work with the NHS, so I’m left with whatever the NHS foists on to me.

    I just want my data, on my terms, to use with the apps and services I choose.
    Market forces will do the rest.

  6. RIP Google Health (2008–2012)
    (paraphrased from Wikipedia)

    – starts —
    Google Health was the name given to a 2008–2012 version of a service allowed Google users to volunteer their health records—either manually or by logging into their accounts at partnered health services providers—into the Google Health system, thereby merging potentially separate health records into one centralized Google Health profile. Volunteered information could include “health conditions, medications, allergies, and lab results”. Once entered, Google Health used the information to provide the user with a merged health record, information on conditions, and possible interactions between drugs, conditions, and allergies. Google Health’s API was based on a subset of the Continuity of Care Record.

    The original Google Health was under development from mid-2006 […] In 2008, the service underwent a two-month pilot test with 1,600 patients of The Cleveland Clinic. Starting on May 20, 2008, Google Health was released to the general public as a service in beta test stage.

    On June 24, 2011, Google announced it was retiring Google Health on January 1, 2012. The reason Google gave for abandoning the project was the lack of widespread adoption

    — ends —

  7. Christopher Herot Avatar
    Christopher Herot

    CMS says they started enforcing their new interoperability rule last July. This includes a Patient Access API based on FHIR.

    Given how much the EHR vendors complained about nebulous “security threats” maybe this rule will really have an effect?

  8. Christopher F Herot Avatar
    Christopher F Herot

    This paper describes how interoperability is not just a problem of competition between EHR vendors. A lot of the problem comes from choices each hospital makes in how to configure and use the system.

  9. Daniel, thanks for the U.K. report. Disappointing, but not surprising. It should also provide a helpful perspective to those in the U.S. yearning for reforms toward single-payer or other forms of nationalized health care. And thanks for pointing out at least one of the ways the U.S. deserves credit for putting the need for personal access to health care data into law. (Does anyone have a pointer to that?)

    Marion, thanks for reminding us of Google Health and its failings. Microsoft HealthVault (2007-2019) was a competing personal health record (PHR) that took longer to fail, but for the same reasons. One was lack of adoption. Another was complexity. Another was that it was a centralized on one company’s non-substitutable platform, and worked only on that company’s website rather than on the patients’ own apps and devices—or those of a trusted (and substitutable) agent (as HIE of One proposes).

    And Christopher, thanks for the links and documents. In my many years of dealing with many doctors, clinics, hospitals, pharmacies, insurance companies and other service providers, I can attest to the woeful lack of interoperability (or even the willingness to interoperate) among most of them. I’ve heard a number of doctors complain that there are too many ways that Epic has provided multiple different versions of its software and services, that are then implemented too many different ways by its client health care providers: so many that sharing of some information, or collaboration among care providers is simply prevented within the overlapping systems. But that was a few years ago, and maybe it’s not as bad now.

    An additional problem for everyone is that all fields, including medicine, are in the midst of being digitized while we still haven’t found ways to make digitized information fully trustworthy or secure. The Internet is, after all, a copy machine.

Leave a Reply

Your email address will not be published. Required fields are marked *