Challenges with EMR and EHR Data Sharing

In the last blog post, Dr. Rowley discussed an interesting example where data sharing would be useful and various methods of sharing that data.

I think we can all agree with Dr. Rowley that in the ideal world #6 (sharing patient data within the same EHR system) is the best way to facilitate sharing of clinical information between doctors. Having a unified database of all patient records would of course make sharing information easier. However, there are a number of challenges with this scenario. Let’s discuss a few of these.

The first problem is that the dream of one system is just a dream. There are just too many disparate systems already in place and so we have to be practical and plan for scenarios that aren’t ideal (ie. multiple EHR systems). It’s hard enough to get consensus around one EHR vendor amongst a small set of doctors in a group practice. Try selling the same EHR to doctors from multiple specialties across a geographic region to choose the same EHR. At the end of the day, even if you had the best EHR it is likely that one doctor will just want to be different for different’s sake. Thus killing the idea of a unified system across all providers.

Just for fun, let’s say every doctor in the area does implement the same hosted EHR system. Even then it’s not very likely at all that the hospital is going to use the same EHR. Software that works well in a hospital setting doesn’t usually work well in an ambulatory setting. So, you still don’t have the patients hospital information because they’re using a different system.

I don’t want to be a complete naysayer about the idea. I have seen this implemented rather effectively in a Hospital system which had 116 multi-specialty clinics. From what I heard, they had a huge majority of the health care in their regional market. At the time they’d only implemented 25% of those clinics, but they’d implemented an EHR across specialties of almost every kind. They have a unified database where patient information was available regardless of where it was done. They even had an interface with the hospital system (the hospital system owned the clinics so this made sense). I also think it’s important to mention the interface they had with their various labs. Essentially, they had the dream that Dr. Rowley espouses. Interesting that this was all done with a client server based EHR.

While I describe the above scenario as a wonderful example, they aren’t without their challenges. They faced head on some of the challenges I described in my previous post. For example, an update to the EHR software affected every clinic using the EHR whether they liked the update or not. Anyone that’s gone through an update to an EHR is familiar with some “new feature” causing untold heartache because the EHR company didn’t realize how that “new feature” would affect the doctors using the EHR. Often the “new feature” isn’t listed in the release notes and so there was no notification to prepare for the change. Even more difficult is that with 116 clinics of varying specialties it’s nearly impossible to know how changes to the EHR software will affect each of the doctors. I’ve seen both of these problems happen even with a small 2 clinic implementation. Multiply this times 58 and you can imagine the challenge.

One other problem this implementation faced and certainly PracticeFusion or other one database web 2.0 type implementations will face is scalability. Obviously, it’s possible to scale the application if done right. Google’s done a pretty good job proving it’s possible. However, that’s much easier said than done. Many a Web 2.0 company has gone under due to their inability to scale properly. A doctor relying on a web 2.0 EHR will not likely support any significant down time. Once an EHR is implemented, most doctors become nearly paralyzed and unable to function when they can’t connect to it. While not impossible to scale a web EHR, amazing attention must be paid to the reliability of the web application. Any significant down time by a web EHR will ensure that it won’t need to worry about scaling their application for long since no doctors will want a web EHR that isn’t reliable.

My point is that in order to reach the Nirvana state of a unified web 2.0 EHR where data sharing is possible, you’ll need to be able to scale the application with near 100% reliability. Users of an EHR won’t be nearly as forgiving as social networking users when downtime occurs.

I also think it’s worth mentioning that sharing becomes much more complicated when it’s done in a unified database. Let me explain. Sharing with a fax machine (or the likes) requires a request for information to be made and a reply made. With a unified database you open up a new world of sharing which can be very powerful, but also difficult to manage. For example, if I sign a release of information which is in effect for 90 days, then why not allow me to turn on sharing of the information for the entire 90 days? Then again, one clinic might have a policy that they want to share prescriptions with another clinic for 90 days. Another clinic might want to share all clinical notes except those marked confidential with another clinic for 30 days. Once again, this can all be coded into an EHR, but it adds one more layer of complexity for the EHR to program and support and for the end users to have to learn.

At the end of the day, my biggest question is not whether there’s value in sharing data between clinics. It’s not whether the technology can support sharing of data in any number of ways. My question is increasingly whether the barriers to sharing patient data are so large that the cost is not worth the benefit. The jury’s still out on this one….and may not be back for a while.

About the author

John Lynn

John Lynn

John Lynn is the Founder of the, a network of leading Healthcare IT resources. The flagship blog, Healthcare IT Today, contains over 13,000 articles with over half of the articles written by John. These EMR and Healthcare IT related articles have been viewed over 20 million times.

John manages Healthcare IT Central, the leading career Health IT job board. He also organizes the first of its kind conference and community focused on healthcare marketing, Healthcare and IT Marketing Conference, and a healthcare IT conference,, focused on practical healthcare IT innovation. John is an advisor to multiple healthcare IT companies. John is highly involved in social media, and in addition to his blogs can be found on Twitter: @techguy.


  • Great post John and I agree with most everything you said. But…I have a radical idea… What if the Patient owned the data for his/her health records? What if their PHR became the “system of record” and providers and facilities updated the PHR with appropriate information from their EHR?

    That may solve one of the problems you mentioned…they can choose any EHR they want.

    They will only have to make sure they can interface with the PHR for updates (assuming appropriate access/security) – by the way, Pharmacies can do this today with the leading PHR software products.

    Just a thought.

  • Deborah,
    It’s a good point that I don’t think I talked about. I think the idea of having the patient manage their medical record is a great idea and honestly could be the only solution that will actually work.

    However, even that idea has its own problems. What if a doctor relies on a lab result that says everything is normal when in fact it wasn’t normal. Who would be liable for that?

    I’m sure there are a lot more, but that was just one problem with the patient managing the data in their health record. Possibly with a drug list or something it might be useful. Would solve the problem of the patient coming in and saying, “I’m taking the white pills that are really big.”

    I think this is the idea that Google Health and Microsoft HealthVault are trying to accomplish. Considering the financial resources they’ve put towards it, I wouldn’t be surprised if this is the end result in sharing patient data.

  • Very thoughtful post John. I enjoyed it.

    I think Google Health and MS HealthVault will be good awareness catalysts for the quiet e-health revolution that is taking place. However, I do not think the defining change we need lies with their business model. A patient-centric model sounds good but we’d be assuming that everyone has an account with one of these systems and that they know how to use them. How will the data about a patient that is stored in a hospital be reconciled with Google Health? Which of course leads to interoperability concerns.

    Web 2.0 does not lend itself to creating a reliable e-health solution either as service A is dependent on service B and if service B is down, service A won’t function and has no power to fix it by their own volition.

    I think so far the industry, aka hospitals, has been trying to solve the problem by adding a patient interface to large hospital systems so patients can see their records. It’s also a step in the right direction but again it is not the golden calf we are looking for.

    So what is the ideal system of the future?
    A patient should be able to enter any hospital in the world, conscious or unconscious, and the hospital should have all the information they need about the patient to administer correct treatment and to notify the right people.

    How do we do this?
    I am a believer in the HIE / RHIO model. In the [not too distant] future, hospitals should concern themselves with healing people and not how to spend their IT budget. Hospitals, insurance agencies, smaller providers and patients will all be connected to an RHIO (Region Health Information Organization) where they will have a wealth of services; either to enter sensitive data or to discover data about one patient or the entire population. RHIOs will be connected to a larger e-health backbone consisting of HIEs that are the great data aggregators of the world. RHIOs would be responsible for conforming to regional regulations. This model is similar to how we connect to the Internet today. We don’t jack directly into one of the main Internet hubs of the world but go through an ISP that can provide us with an email address, a web page AND connect us to the rest of the world.

    HIEs and RHIOs run on a software platform where health IT vendors can deploy their software applications. Some required components:

    – User discovery
    o Any one node on the system should be able to query the other nodes to find a user and her data
    – Portable user
    o This goes with the first bullet point in that a user should be able to log in to the system anywhere in the world and even though the user does not have an account with the RHIO she is directly interfacing with, RHIO should know how to authenticate her correctly
    – Interoperability / Standards / Data aggregation and discovery
    o The key to any successful e-health venture. Services need to be able to talk to each other. It shouldn’t matter whether the services reside within the same application or in different parts of the world. I believe the semantic web (web 3.0) will be a key facilitator of making this possible.
    – Federated security
    o If we take the previous examples of Google Health and MS HealthVault, they would all have to have their own security scheme and user authentication and access control. Multiply that by a dozen and suddenly a lot of money is being spent on recreating the wheel over and over. We need a unified system for this.
    – Updates
    o All applications should reside server side and users should have thin-client access only. When the applications are being updated, it should happen across the board overnight. If something goes wrong, there should be a way to undo the upgrade without hospitals or anyone else having to do anything.
    – Data sharing
    o The patient-centric network will definitely happen as users become more educated. But hospitals still need to be able to have access to patient data even though they have not been granted access, in case of emergency.

    Ok, this suddenly got really long 😉 There is a lot of work to do for everyone in order to get true e-health solutions to work. The biggest obstacles aren’t technical but political and also the willingness to adopt a new way of interfacing with your health.


Click here to post a comment