EMR Companies Holding Practice Data for “Ransom”

UPDATE: JamesNT sent me an update to his comments in this post. It’s interesting to see the EHR vendors’ evolution on the question of openness.

JamesNT wrote a really interesting forum post recently about how a number of EMR vendors are holding doctor’s patient information “ransom” (his word) from them. Here’s his whole description and he even names a few EMR vendors and the challenges related to getting the EMR data out of their systems:

To many EMR’s lock up the practice’s data and hold it for ransom. The data entered into an EMR belongs to the practice, not the EMR. It is not fair for EMR’s to not provide ways to interface or export data from the database. If a doctor wants to hire an IT person or developer such as myself to write custom reports or export data from the EMR, then it should be possible. Consider the following examples:

Amazing Charts: They use SQL Server 2005 Express as their database but they remove the built-in Administrator account from the SQL instance and change the SQL Server SA password. This means anyone hoping to interface or export data is at a loss – and Amazing Charts will not share the SA password. Amazing Charts also does not publish a database diagram.

eClinicalWorks: Overly complicated database. Does not publish mySQL password (you can find it, though). Does not publish database schema. If you ask them for help, they want to charge $5000 to build an interface.

PODMED (now TrakNet): Kudos for sharing the SQL Server SA password – but does not offer a published database schema.

GE Centricity: Database schema available – if you are willing to tell a bold-faced lie to someone to get it.

Medinotes: Even after sunsetting the product, Allscripts refuses to give out the ODBC driver and database password.

MD Logic: Uses a pathetic HL7 file interface. You can place only one patient demographic in each file – so if you have 200 patients to update that means sending 200 files.

Officemate: Uses SQL Server and it is easy to get to their database – but they do not offer the schema.

I find this situation deplorable. Every EMR should make it easy to get to the data and not try to hide it or charge outrageous amounts for an interface. Seriously – who here would pay $5000 to make an interface?

Of course, he’s just highlighting the EMR software he’s used. I’m sure there are hundreds more EMR vendors like this.

Then, there’s also EMR vendors that don’t hold your EMR data for ransom like Medtuity. Here’s what Matt Chase from Medtuity said about what they provide to users of their EMR:

At Medtuity, we provide open access to the SQL database. We also provide an export facility under Options. You can export each and every encounter, years and years worth if you wish, to a PDF file for each visit, neatly labeled with the date of the encounter and pt’s name to keep it from colliding with other PDF documents. You can also export a CCR for each pt.

We also have our own proprietary format in XML. For a group with a huge number of records, they may wish to hire a consultant to write a program to consume that xml into a new system. Our xml format is most complete and includes the stuff you would not usually wish to transfer (the audit trail on that chart, for example). But it is there. We also have CSV format, but let’s face it, you cannot export sophisticated data in a CSV format. It’s fine for demographics.

How “liquid” is the data in your EMR software? This discussion is a very important one between you and your EMR vendor when you’re selecting an EMR. Make it part of your EMR contract.

More EMR vendors need to voluntarily step up to the plate and provide this type of EMR data liquidity.

About the author

John Lynn

John Lynn

John Lynn is the Founder of the HealthcareScene.com, 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, EXPO.health, 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.


  • John,

    Great post and I agree 100%. For one client I am currently working with, in order for them to switch to Praxis we had to hire a part time employee to manually convert 6000 patient records from their old EMR. Disgusting.

    What are your thoughts on a mandate for vendors to allow client access to the EMR database as one of the requirements for certification?

    This issue is only going to become more and more common as more doctors look to switch to better products.

    There is only one thing worse than using a bad EMR and that is being stuck with one……

  • I think instead of client access to the database, a better certification requirement might be for the EMR vendor to provide all the EHR data in an exportable format similar to what Matt from Medtuity describes above. Plus, they should have to publish the data diagram for the format they used to export.

    I agree this is going to become more and more common.

  • Just pointing out that this has been an issue for a while, and it’s highly recommended for doctors these days to, regardless of the EMR vendor’s past and current stance about practice data (usually most EMRs these days are quite amicable about this), put a data ownership clause in the contract signed with the vendor. AMA (although I know they tend to get a bit of a stiff shoulder from most physicians) for instance made and still makes quite a big deal about these clauses, for example.

    Would it help if it was possible to alert more physicians about these things? Of course. But it’d be nice to be able to alert them about things like the June 30th deadline for e-prescribing as well, but it’s tough ;(

  • We experience this often when trying to help new Practice Fusion users export data to transition to our EHR. As for our system, we provide free exports of all practice data on request when a user decides to leave for any reason at any time.

  • To put the shoe on the other foot… from a vendor standpoint, what is the upside to allowing 3rd parties to have full admin access to your databases and a schema listing? Do you really want some fly-by-night consultant stumbling around your system with admin access? And should something “go wrong” from either incompetence or nefarious reasons, who is responsible for cleaning up the mess?

    I realize for an interface developers, data mining consultant, or new EHR company trying to convert data it’s a pain in the head. But from a Vendor standpoint of data security and integrity it seems like opening a can of worms to just give over the keys.

  • MSangston,
    That’s why the EMR vendors should provide the data in an exportable format with the format details. Then, they don’t have to worry about people screwing around with the data and causing other issues.

    Making the healthcare data liquid doesn’t have to be direct access to the database. It is direct access to the data.

    Every SaaS EHR vendor should be doing this as well. Then, their providers could download the export regularly as their own in house backup of the SaaS EHR data.

  • We have a pharmacy vendor who refuses to give us the database user account with full rights to the tables, making it impossible to interface or plug our business intelligence software for reporting into. The vendor is HBS RxGenesys, and it makes me feel sick because I recommended the software. http://www.hbsrx.com/

  • That’s incredibly unfortunate Travis. I know the feeling. Not much you can do other than work your way up the hierarchy at that company to try and find a way to get access. Of course, making a buzz on sites like this, Twitter, EMRUpdate.com, etc doesn’t hurt either. I imagine HBS RxGenesys doesn’t like bad PR. At least most companies don’t like it.

    As my accountant recently told me, “the squeaky wheel usually gets oiled.”

  • When we looked for am EMR Vendor to partner with, one of our requirements was that the data be portable in case of a vendor failure of need to move the practice to another system. Another was that the database be scalable so we felt good whether we were working with a one provider practice or a 50 provider one.

    We picked Glostream because it runs on MS SQL and we control the SA account when we install it. We need that as we have complimentary solutions like automated appointment reminder systems that we did not want to have to pay thousands of $$’s for interface development by the EMR vendor.

  • I agree that practices should own their data. However, there are very good reasons for not allowing easy access to an EMR database, especially with full administrative privileges. EMRs are legal business records and full access to the database can compromise the legality of the record. This could be devastating to a practice in case of a lawsuit or a regulatory challenge. Moving records from one system to another may also be problematic because the meta-data (e.g. log files, audit trail, etc.) from the original system could be lost. Without meta-data, proving that data have not been altered or improperly accessed could be difficult or impossible.
    E-Discovery rules set forth in the FRCP detail requirements for retrieval of information from electronic records and how electronic information must be stored in order to be admissible in legal proceedings. Before moving data between EMRs or accessing the full EMR database consultants and IT personnel should be aware of the potential legal implications of their actions. For HIMSS members there is a good white paper, “The Legal Health Record in the Age of e-Discovery – Other Pubs (11/3/2008)”, that provides good background info on this topic.
    The safest pproach would be for vendors to provide export/reporting capabilities that allow flexible access to data without the need for admin access to the underlying database.

  • Jerome,
    Definitely some good cautions. This is why I prefer one that provides an export. You bring up some interesting things about needing the previous audit logs and other meta data. Thanks for sharing. You do have to be very careful with the access you have and controlling it properly.

    I still prefer access though. I can implement my own restrictions to prevent issues.

  • Some very good points for and against; bottom line is, like John specifies, 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. It can happen and this problem need to be addressed. At EHIconnect we make sure that the provider has access to his/her full set of data; additional help in porting the data over to the next system does invove time and effort which the new system vendor has to take care of or the provider has to address. But there is no doubt that the data has to be provided to the practice in a format useful to port to the next system.

  • Regarding the comment about GE Centricity in the original post. I’ve found the schema for the EMR easily available and completely open. I’d prefer that they publish more views to support backward compatibility but I’ve used it several times.

  • Who owns the data? Do I own my SSN or does the US Government? Do I own my EHR Record or Paper Record or does my provider? The simple rule is who paid for it owns in. Another simple rule is “possession is 9/10 of the law”. So if EHR Company A must export data easily what downstream liability exists? Should the EHR vendor obtain a BA agreement with each export so the HIPAA Security rule is preserved? Anyone with access to PHI automatically assumes up to $1.5M in liability if there is a breech so why would any sane person take on this liability? I believe that the answer is “economics”. There is economic value in exporting, parsing, importing, storing, and archiving data. I believe that the real solution is to have every individual simply created a Microsoft Health Vault Account, and then every EHR Vendor simply improved this account once the patient grants permission. PHI would only then be stored in the EHR for Billing and historical purposes, the most current data would always be in the control of the patient and the patient would have responsibility for its disclosure. 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.

  • We had a lot of this discussion on another thread. However, it’s a different issue storing information in a PHR versus a doctor accessing the data in their EMR.

  • Same comment as Cole (#14): GE Centricity EMR schema has been made available by GE for years to clients of their software. It’s not available publicly, but it has always been available to licensed users. They first published a paper version, but now it’s online. UN/PW required to access.

  • There are a number of issues and themes in this thread. Two that continue to surface and cause confusion …

    – How easy is it to get to my data?
    – How easy is it to convert to another system?

    These are two very different issues. If you can print the data, simple techniques allow you to “get at it”. Most all systems have some sort of export and backup features.

    The database schema is like a blueprint to a building. Many HIT vendors consider this part of their “secret sauce” and highly proprietary. The DB schema could be a valuable asset or a rat’s nest and source of embarrassment. Either way, many are reluctant to publish.

    Simply having the schema (the blueprint) won’t necessarily make conversion “easy”. The FROM system or the TO system DB structure (or both!) could still be a mess.

    Concerns to name a few …
    – Naming conventions
    – Normalization
    – De-normalization
    – Time variant data de-normalization
    – Generalization

    Lastly, to what extent does the vendor’s DB structure and related policies “lock you in”? Either inadvertently or intentionally.

  • I know this article and thread is almost 2 years old but the problem has not changed. If anything it is worse as the EMR companies are creating their own datamarts and selling access to the data back to the practices.

    Regarding the eClinical reference “eClinicalWorks: Overly complicated database. Does not publish mySQL password (you can find it, though). Does not publish database schema. If you ask them for help, they want to charge $5000 to build an interface.” How do I find the password?

  • Hi Chuck,
    Yes, this is still a problem and will only get worse as more people adopt EHR.

    Unfortunately, I’m not sure about the eCW password comment. Maybe someone else in the thread will be able to help you.

  • The saga continues into 2013. Very good conversation. As a BI Specialist for an organization that uses an “open” EHR in which we are able to do just about whatever we want to at minimum read-only access can and should be provided as a requirement. Especially with the movement toward integrated care. If customers were more adamant about this before buying then these vendors would have a change almost overnight.

    In the case of most SQL based solutions it would be as simple as providing a read-only login and if your “secret-sauce” is so important then provide a list of views for this and provide only that schema. For most purposes this would be a trivial task technically, requiring minimal time and effort on the part of the vendor. It is this technical ease that really makes it apparent that these vendors are doing this as part of their business plan. The part they will not be forthright about because they already know that it’s ethically questionable.

  • This may be inappropriate, but I invented a piece of software the currently has a provisional patent, it solves this problem. It circumvents the admin password, allows you to reset it to whatever you want, then shows you the entire schema and you can export it. I am currently looking at either purchasers for the idea or people who may wish to utilize the service.

  • Watch out for this one called MDLOGIC EMR. NOT “real time”, constant errors, poor customer support. I’m stuck with it full of regrets and paying over $1500/month for the next long 5 years…

  • Has anyone figured out how to extract patient charts notes from Medinotes and convert them to simple PDF files yet?

    Just curious..everyone seems to have issues with McKesson these days…we just want to extract the patients actual chart notes, we are not worried about demographics or insurance data…and make PDF files
    Is this even a possibility now or still a problem to do cause McKesson has it on lockdown…?

  • Actually even the website you mention only describes converting and exporting data, assuming one has access already. It does not claim to be able to get at the data even without the administrator password. That is what we do. We don’t do the conversions or other items. We simply grab your data, regardless of whether you have the admin password or not, and provide it to you in a standard format like and SQL datatabse (or something similar). I have interacted with several conversion companies, and everyone I have spoken too can only extract and convert your data IF you have an administrator password.

  • I believe they have a solution that doesn’t require the admin password. They can grab PDFs of it. Although, I haven’t talked to them for a while. Just thought I’d share another company so they could look at the options. There is also http://healthport.com/let-us-assist-you/flexible-solutions/on-site-conversion-services.aspx and http://ellkay.com/ to name a few more for Sharra to reference. Their websites don’t always do the work they do justice.

    I hope this helps Sharra and you report back what you find.

  • John,
    Thank you for your comments, but I may not be clear on what it is we can do. We give the clinic its data, in complete database form. That means SQL Server, or whatever they wish. From there anyone can easily export, convert, manipulate. Now if some companies offer a service not listed on their website,that I don’t know. However, I would suggest that if many companies could easily extract data that is being ‘held ransom’ then this article and this entire thread would not exist.

  • A lot has changed in the EHR conversion world since this article was written 2 years ago. However, one thing that hasn’t changed is EHRs holding practice data hostage. Talked to one this week.

  • Me too. Amazing Charts and NextGen, worked with a site using NextGen last week. The CIO of the hospital really isn’t Chief anything, their EHR vendor is. Unfortunatley they too often choose these products without realizing the signifcance of access to ones own data. Another site I’m aware of is using ADP’s solution which doesn’t even “live” on site.

  • Update, NextGen has done a 180 with their latest versions and our partners have no trouble with getting to their data unless it is lack of expertise. Could be getting better!

Click here to post a comment