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.