My last post on EMR companies holding practice data for ransom was very popular and had some very interesting discussion in the comments. Honestly, every EMR vendor should be considering the impact of the choice to not liberate the data in the EMR.
No, I’m not talking about being loose with the data. HIPAA will come back to bite you if you do that. Plus, no doctor will want to use your system. What I’m talking about is making the data in the EMR available to the doctor. In fact, if your a doctor or practice manager reading this post, you should make this a requirement of the EMR vendor you select. If you already have an EMR vendor, you should work to have them incorporate this feature in their EMR ASAP.
Lest you think that I’m just being pro doctor and not considering the EMR vendor, let me provide you some business reasons why an EMR vendor would want to create a plan to make the data in their EMR available to their doctor in a liberated format.
As one EMR vendor put it:
Bottom line, its a good business practice to provide the data in an accessible manner to the client when and if he/she wishes to move on to another EHR.
Let me add the following:
If you don’t hold the EMR data ransom then you will have a better image in the community.
1. If someone wants to leave and you make it hard, word will travel that you held them ransom and others will be afraid to choose you because they know they’ll be locked in. We all know how tight the medical community is.
2. If you free the data, users will trust you more cause they know they can leave at any time. Plus, they see you’re doing what’s best for the customer. This narrow minded focus on the customer’s needs will certainly carry over into other areas of your application and lead to happy customers who can leave, but won’t have any reason to leave.
3. SaaS EHR vendors in particular should offer this service. One of doctors biggest complaints about SaaS EHR is their fear that their EMR data isn’t stored in their office. What easier way to allay this fear than to provide them a regular copy of their data?
Do NOT underestimate the power of your image with the customer. It leads to happy long term customers, but also leads to future customers. I saw a recent study (which I can’t find right now), but it was amazing to see the amount of influence that other colleagues EMR recommendations made on a doctor’s EMR selection decision. Providing doctors their EMR data which may lose you a few customers along the way, but it will retain and find more customers than you lose.
Vendors have a tough time with Data Liberation. This is because nearly all vendors store the “data” in a complex relational database. These relational databases have a complex schema that changes as needs change (versions). So for EHR vendors to “export” data from the database in a useful way depends largely three things; Size, Structure and Schema. Size is the biggest concern; there could be Tera bytes of data generated for some systems. Structure is next; how does the target system need the data (SQL, XML, XLS, TXT, CSV, HTML, etc…)? Schema, this is the complex part, which version of the database are you using and how do the complex relationships (Patients Have Primary Insurance and Secondary Insurance links to a Table of Insurance companies which in turn have links to Tables of Fee schedules which in turn have links to CPT codes…. How does this get exported in a meaningful way? This is precisely why XLEMR uses a FLAT structure which is instantly exportable in all of the possible formats listed above. And our data is instantly importable into any database. Your data is your data, demand that your EHR vendor never prevent you from accessing it and moving it to any future system.
Tripp,
No doubt there can be complexities. Especially around importing the data into a new EMR. However, if the data is there, they can generally leave the challenge of importing that data to someone else. The problem is when you can’t get at the data to import to the new system. All EMR vendors can solve this problem and as you say users should demand it.
Amen to Tripp and John. Its getting there. Currently we are working with a Client to move them from AS to our platform. Its not there yet; but access to the Practice’s data and ownership issues will become streamlined in the not so distant future; and like John says, its better to have the client off of the platform rather than having a disgruntled client who can only hurt more.
As in all cases ‘no one shoe fits all’. And its better for the Practice and for the Vendor to split amicably, with the Practice moving on to a solution of their choice.
Much of the previous discussion centered around the availability of the database schema as a measure of openness.
I would find an API (programatic interface) more useful as there are many things I would like to do with the data while I’m using the vendor system.
Certainly the ability to move to a new system is a good safety net but it produces little real value for the practice and underscores the challenges many have with selecting an appropriate system to begin with.
Hopefully the meaningful use requirements for integration will drive vendors to provide more open access to the data as well.
Cole,
I think an API would work in many cases, but part of the export is backup as much as moving to a new EMR. Many doctors will feel much more comfortable with a SaaS EMR if they had an onsite copy of the data.
I agree that many EMR should provide API’s. Although, my only question would be how many providers would actually use that API. Would be a good question to the few EMR companies that have an API. I’d say an API would probably be more used in a hospital than the small doctor’s office.
John,
I agree that practice data should be available outside of the EHR vendor, though the practice would have to buy and maintain the server space to store it.
What are your thoughts about EHRs that employ cloud-based storage that solves the data backup problem and facilitates HIE?
Akshay,
I actually really like that option. As long as the clinic has access to that cloud based storage at anytime to be able to get their data, that’s a great idea and does help to solve the storage issues. Although, there’s no reason a backup of your EHR data has to be on a server. It could be on another device that’s encrypted and secured.
I’m not sure how that relates to HIE unless you mean an EHR that has an HIE component. I like that option, but it doesn’t usually solve liberating all of the EMR data.
The reason I thought of HIE is because all providers in a patient’s provider panel (PCP, dentist, ophthalmologist, surgeon, etc.) could access the data an add to it after each visit.
Hey John and Akshay,
Cloud based storage bothers me for 2 reasons. Reason 1) Imagine in a breech the prosecuting attorney asks you these simple questions. 1) Do you know where the data was physically stored? (no) 2) Do you know the names, identities or credentials of any of the individuals you trusted to secure this data? (no) 3) Did you verify that the data was encrypted before sending, while in transport and while at rest at it’s final destination? (no). “The court finds the defendant guilty of willful neglect and hereby orders $1.5M in fines…” Reason 2) Imagine in a Disk Crash you need a 500BG Database restored like NOW… it’s noon. You have a descent 10megabit/sec download speed, you would have to wait at least 4 Days 23 Hours 18 Minutes 16.73 Seconds (If the remote server stays up) http://www.t1shopper.com/tools/calculate/downloadcalculator.php “Yes Dr. Wilson that’s correct, I should have you back up and running by this time next week….” This is why at XLEMR we provide a remote backup solution that sync’s two identical low cost high capacity USB disk drives over the internet using Secure FTP so as a file changes on one Drive it’s synced to the to the other drive, in a catastrophic crash our clients simple drive home, pickup the backup and drive back and we are on-line. Both drives have Full disk encryption which is nice because in a loss we don’t even have to report the loss.
Tripp,
It’s worth consulting your lawyer, but you can answer those questions. Plus, you’ll have a business associate agreement with that company that will cover you for the first 2. They are covered by HIPAA as much as you. The third part can be verified and should by a clinic. If they don’t, that’s a risk they’re taking for sure.
This type of cloud backup strategy is a disaster recovery strategy for a clinic. It’s not meant to be a fast backup recovery in case of a disk crash. There should be a different strategy for that for sure. I’d also say that a 500 GB database for a small clinic would be huge. The EMR vendor should probably do a better job optimizing it. At least until we get to the point that we’re storing Radiology images and videos from the visit.
Tripp,
Having an additional, physical backup solution is definitely sensible. How do you parse the data? Labs, images, orders, nurse’s notes, doctor’s notes, and so on? Is it searchable by patient MRN?
Hey Akshay,
Data is stored in XML flat files per encounter and is searchable by simple text string matches. Then it is parsed and loaded into a database capable of SQL queries. All images are stored as DICOM or JPG files and orders, notes and letters are stored in there native file format (Word,PDF,etc…)
[…] into a new EHR company. Some of you might remember my post asking EHR vendors to consider the value of EHR data liberation. In it I describe why not only is it the right ethical thing to do, but it also can make a lot of […]
[…] example of the business case I outlined in my post about EMR data liberation. That’s a subtly different situation than what Vince described, but I believe you can make […]
[…] Data Liberation – I’ve wanted EHR data Liberation for a long time, but I think in 2012 this is one thing on the list that could become a reality. […]