There are many issues a physician should be aware of when choosing an EMR. Some are in regards to the features and functionality of the EMR software, some in regards to the service levels provided by the vendor. Others involve costs and whether the vendor is compliant with the current standards in the province or state in which the physician operates. There are also other issues that are not normally discussed at the point when a clinic is looking for a new EMR because they are not something that physicians think of at the time of purchase, and these issues can come back to haunt the clinic later in time. However, the proper time to address them is before you are signing a contract! That is because one of the areas you will encounter these data issues is when, in the future, you want to move to another EMR – and then it is too late to try to negotiate with your current vendor.
This issue is only going to increase in importance as EMRs move from being a place to record a patient’s medical record to being an incredibly important source of medical data for research and improving patient care. This shift is already well underway and will only snowball over the next few years.
Disclosure: TimeAcct is a company that specializes in EMR data extraction, so we have an interest in seeing that data is open and accessible. Because of our line of work, we have experienced most of the data issues out there in terms of EMR data.
Vendors Locking the Data in the EMR
This is one of the nastier issues that are almost never discussed in the EMR community. The patient is supposed to own the data and the doctor is supposed to own the record – but what happens to that rule when the vendor ‘locks’ the data in the EMR and does not allow the clinic to have full access to it. How can any physician claim to own a record that they cannot access, except at the behest of the vendor? After all – in an ‘electronic’ medical record system, the database record is the ‘record’! How can the physician claim to be the custodian and responsible to the patient when they do not have access to the original record? How might this affect the patient care by that doctor in the long term?
There are various ways that this might occur, but the most common are when a vendor encrypts or password protects the database. In these cases the physician cannot access the database except through the use of the EMR application. Now, this might not sound all that bad, but it can have some rather serious ramifications. What happens when the clinic wants to do something that is not built into the EMR? Such as:
- – Export data to a third party (CPCSSN for example)
- – Perform data analytics
- – Run custom reports or queries
- – Convert to a new EMR
If they cannot access their database directly, they may not be able to perform any of the previous tasks. By far, the most serious would seem to be converting to a new EMR, as this could impact the actual business of the clinic. However, being able to access the data for other purposes can also have a big impact. Take for example that fact that we are moving to a new compensation system, where a clinic will not be reimbursed for simply using an EMR, but will have to prove that they are using it properly by generating certain reports for the government. And I believe this is just the beginning of the changes to come. However, if your vendor is slow getting these changes out to your clinic, or goes out of business, how will you be able to generate these reports? Oh that’s right – you will just move to another EMR! But wait – you cannot access the data and the vendor is either out of business, or just VERY slow to respond to you – so you cannot move to another vendor – because your data is ‘stuck’ in the current EMR application. This is the situation for many clinics in Canada right now. They have EMR software where the vendor does not allow them to access their data directly – and will not provide them with the raw database. These are ‘closed’ systems. In effect, some of these systems basically hold the EMR data hostage – forcing the clinic to continue dealing with the current vendor.
There are various ways that this is done. Some vendors will encrypt a few key fields or tables in the EMR, some will password protect an entire database. Others will not provide the administrator password to the machines (administrator in Windows, root in Linux, etc.) – even though the clinic has paid for and owns those machines.
Another way this is done, but not necessarily intentionally – is when you use an EMR that only provides an ASP solution. Basically, the EMR is usually served via a web browser and the application and the database are hosted remotely. While this is not a case of the vendor deliberately making it difficult for the clinic to access their data directly, usually that capability is not there. The questions then revolve around issues like; can the clinic get access directly to their data? If not, can they get a backup or copy from the vendor? And most importantly – how much would this cost the clinic? These costs can be prohibitive (from some vendors) – thus locking the clinic into the vendor’s solution. Don’t get me wrong, there are some huge advantages to using an ASP solution. However, you should also be aware of the pitfalls and possibly hidden costs.
One of the final ways a vendor may lock a clinic’s data is with very restrictive contracts. We have seen some contracts that are so restrictive that they prevent the clinic from doing almost anything with the EMR or data that the vendor does not approve of. One example of a vendor’s contract in Canada, hobbled together almost every nasty contract clause you can find on the internet in an effort to restrict the clinic and protect the vendor. These contracts are not “Good Business” and should be avoided at all costs. Why does a vendor think it is necessary to restrict/handicap the clinic and impose massive penalties if the clinic tries to access their data?
I have heard many reasons as to why a vendor might want to ‘lock’ the data. Most of them revolve around protecting the data from accidental changes. I am sorry – but for the most part this reasoning is just an excuse. Most doctors are not going to use database programs to try to alter the data. They are going to use the EMR – because it is what they are used to. As well, there are not many doctors, or staff, in clinics that have the skill set to do so. Yes – a consultant hired by the clinic could potentially alter the data. But it is unlikely. In fact I have seen more data corruption caused by vendors trying to ‘fix’ something in the data then by any outside consultants. Almost all of the requirements I spoke about above – are really just reading the data! There should be no changing of the data outside of the EMR under normal circumstances.
Ability to Export ALL the Data
Many vendor exports do not export out all the data from an EMR system. They normally only match what the government transfer specification says they have to. While this meets the government requirements, what about a physician’s legal requirements? Take for example electronic WCB forms or prenatal information. These are part of the patient record, but are no part of any government standard for data transfer. What happens if a physician moves from EMR ‘A’ to EMR ‘B’ – and then a few years down the road they need to review one of those WCB forms for a patient? This could be a legal request from a lawyer or the court. But the doctor is not able to review that data, because the data was stuck back in the old EMR which is no longer used. What happens if the patient loses that court case because the data was not available? Is that doctor then liable to the patient for not maintaining the medical record as the custodian?
There are a few ways to deal with this issue. One way is to get a full backup of your original EMR database as well as the export provided by the vendor when you are looking to move to a new EMR. The problem with this is that the custodian is responsible to make sure any records in their possession are destroyed in a timely manner – and each patient’s retention period expires at a different time. So, it becomes almost impossible to delete the records in the database without the current EMR. However, it can make a great safety backup for a few months while you iron out any issues associated with the conversion.
Custom Data Types in the EMR Software
Each vendor strives to make their system better and different then their competitors. And to that end they all try to add in features that make it easier for a doctor to enter the information that is important to them. However, occasionally this can cause problems when a clinic wants to utilize the data stored in their EMR. This issue can take many forms, using RTF tags to record data (i.e. using Bold to denote the patient response (Yes/No), storing data in custom forms that cannot be queried or storing data in PDF forms. These are just some of the various ways we have seen custom data types cause issues for a clinic when they are looking to utilize their data or move to another EMR.