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.