Tag Archives: EMR Data

Who Really Controls Your EMR Data??

Who actually has control of your EMR data? It might not be who you think it is…

It wasn’t that long ago that people discussed who owned the data stored in Electronic Medical Record systems in Canada. Even though there were laws defining this – they were not commonly understood (or perhaps possibly willfully misunderstood?). In 2006 I actually had a conversation with a vendor in Western Canada who stated quite clearly that they ‘owned’ the data and that they had every right to restrict the clinic’s access to it. This incorrect understanding of who owned the data led to a few vendors encrypting fields in a database or entire databases in order to restrict the clinic’s ability to access their data. Or using database licensing or contract clauses to ensure that the clinic had no right to interact with their EMR data without using the EMR. Now, there are a few very valid reasons for doing this, such as a desire to not allow a clinic to accidentally alter the live EMR data – which could cause problems with the use of the EMR.  However, this could be accomplished without removing control from the physician/custodian.

Since 2006 the EMR world has changed quite a bit. No longer is there any doubt that the patient owns their data and that the doctor is the legally responsible custodian of that data. However, now the issue is about Control. Who actually has control of that data? It is not the patient, as they do not have access to it other than when they visit their physician. Yes, they can request a copy, etc. – but that is not real control. The physician while legally responsible for the data (custodian) does not, in many cases, have control of the data either. Especially those who are using an ASP style EMR (see our article on the Unintended Consequences of ASP EMRs). In many cases it is the EMR Vendor who has the control of the data. They host it on their ASP systems, they have encrypted fields or licensing contracts that prevent queries from being run by tools other than the EMR itself, and charge large fees to provide the clinic with a ‘copy’ of their ‘own’ data.

This has become a huge issue for some clinics in Canada as they try to better understand their data, provide better patient care, generate reports, and do research.

For full disclosure, TimeAcct is a company that specializes in accessing EMR data, data conversions and helping clinics move from one EMR to another. As such we have an interest in making sure that clinics have full access to their data. We also get to see how all parties (government, vendors and clinics) treat, deal with, and utilize the data in the EMR.

There is an old saying “Those who do not control their own data, will be controlled by those that do!” What this means is that if you do not have control over the data you use to run your business, you will be controlled by whomever has control over that data. In 2017 data is usually the most important business asset of any company. You do not see companies like the Royal Bank saying, you know we should give control of all of our financial data over to some hosting company – where we have to pay to access it and have to beg them to get access to it. No, they see their data as their most important asset and they take steps to not only safeguard it, but make sure they have full control over that very important asset.

In years gone by the vendors used to be able to charge physicians a lot more for their EMRs, as the government paid up to 70% of the monthly costs. However, as the various funding programs have ended, the vendors had no choice but to lower the monthly fees. This has resulted in many changes in the industry, including the vendors (and many others) realizing how valuable the data stored in the EMRs actually was. This value can take many forms and is potentially different depending on whether you are the clinic, a research company, ‘big pharma’, or the EMR vendors themselves. For the EMR vendors, with the drop in what they could charge for the ‘base’ EMR, they have had to look at other ways of generating revenue from their clinics – and many times this involves the clinic’s data. Now – I am not talking about the vendors secretly selling off patient data – there are none doing it, that I am aware of. What I am referring to is selling the clinics additional services based on their data. Things like selling portals, data extraction tools, backups, and specialized reporting, etc. In many cases the clinic has no choice but to take the services from the vendor – as the clinic does not control access to its own data!! And in many cases the vendor will charge very high fees for you to be able to get even something as simple as a database backup for you to then access an off-line copy of your data.

So, if you as a physician want to access and report on your data in specialized ways (most vendors provide the standard reports), or do research, etc. and you are using an EMR from a vendor that does not provide easy access to your own data – then you are in effect being controlled by the organization that controls your data.

Another interesting time when this lack of control over your own data may come into play is when you are leaving your current vendor for a new EMR company. Now, many of the contracts that the EMR vendors put forth may comment on that they will provide an extract of the data in your EMR when you leave. In the past you could be certain that in Western Canada they would provide the data in the POSP defined COPD/TOPD format – or in Ontario in the OntarioMD CDS format. However, recently some vendors have softened their support for those formats – as they allow the easy exchange of data and allow clinics to change vendors relatively easily. This is not in the interest of the vendor you are leaving. So – some vendors have taken it upon themselves to create their own data export formats (and thus basically abandon the government formats) – which means it makes it harder for a clinic to move to other vendors. What boggles my mind about this is none of the medical associations or government agencies are standing up to the vendors and protecting the physicians and their data. This begs the question as to why?

In my opinion, this move away from a standard data format is not being done because the vendor formats are so much better than the government formats (which admittedly have their own issues) – but because it creates an additional barrier to a clinic looking to move to a new vendor. The new vendor now must write an import program for that new format – thus increasing the costs of the data conversion – and the time it will take to move them to the new EMR. In fact we have recently seen one vendor in particular start to take extraordinary steps to restrict data movement from their EMR, like trying to force Non-Disclosure agreements on other organizations (and clinics) looking to use their data export format when doing a data conversion. This has nothing to do with protecting their data structures – after all it is an export format – not the database structure of their application. Once again – this is an issue of CONTROL over the EMR data – being exercised by a vendor – not the custodian of that data (the physician) who has all the legal liability regarding that data.

The only way to avoid this is to have special clauses in your EMR contract – allowing you access to all of your own data when you want it and when you are leaving a vendor.  The only time a clinic has any ability to negotiate these clauses is when they are first agreeing to move to that vendor’s EMR.  And if you do not have those types of clauses in your contract, you are at the mercy of the EMR vendor… and will be controlled by the entity that controls your data!

Medical Information and Encryption

Medical Information and Encryption

We deal with a lot of medical information – and as such all of our hard drives on all our machines are encrypted.  We even encrypt our USB keys and our backups.

For a physician or clinic, the rule should be if a computer system will ‘possibly’ hold any medical related information – it should be encrypted!  No exceptions.  A few years ago we encountered a well-meaning clinic that had a portable hard drive that moved between two offices and a home office.  The issue was that it was used to contain billing information – which the clinic did not consider to be patient sensitive data.  That was until it was pointed out to them that the patient personal health numbers and billing codes in that data could indicate exactly which patients had what conditions.  They quickly moved that data to an encrypted drive – and destroyed the original.

There are stories every year in Canada about a stolen laptop, a portable hard drive that has gone missing, etc. and contained medical records that should underline to clinics how easy it is for electronic information to be compromised or stolen.  Yet, we continue to encounter situations where data is not properly encrypted or encrypted at all.  Most of these situations are due mainly to ignorance of the actual requirements and the understanding of the technology, while some are done due to a belief that it is ‘too complicated’ to comply with.

Let’s try to clear up a few issues – and then discuss what can be done to easily encrypt external hard drives…

Encryption Strength – 256 Bit and higher

In Canada, it is recommended to use at least 256 bit encryption for medical data.  This makes it harder for someone to use a ‘brute force’ attacks to see your information.  However, as well as using strong encryption – you should also use a strong password.  The best encryption is useless if you use weak passwords – like ‘password’ or your name, etc.

Level of Encryption

The simplest solution would be to go out and just purchase an encrypted drive or USB key.  However, it turns out that it is not all that ‘simple’.  There are many external drives out on the market that make the claim to be ‘encrypted’ drives – and they are.  However, the question we always have is what type of encryption is being used.  This is a concern because a fair number of the encrypted drives out on the market do not use 256 bits – but lower strength algorithms like 128 bit, etc.  We have a rule in general – if they do not publish that the manufacturer is using 256 bit encryption – they aren’t.  This means that as a physician, when you purchase these drives you have to be careful and read the labels.  In Canada, any device that stores medical information must use at least 256 bit encryption.

Encrypting your own drive/files

Another option from purchasing a drive that is already encrypted – is to use a product to encrypt it after you purchase a regular drive.  This has some advantages – as many of these types of products will allow you to encrypt individual files, create encrypted areas (allowing more than one file to be stored) as well as encrypting the entire drive.  The down side is that you have to learn how to use the product and configure it.  However, we will try to make this a little part a little easier by providing a solution we use for encrypting our USB keys and external hard drives.

What Products are Available to Encrypt your Hard Drives?

There are a few different things to consider when you are choosing a program to use to encrypt your data.   The first is which operating system are you going to be using – Windows or Apple (we won’t discuss Linux in this article).  Windows has its own program called BitLocker.  It is available on Windows Vista and later.  Apple computers also have their own program called File Vault.  There are also some other programs like PGP and Symantec Drive Encryption that offer good solutions.

The second thing for some people to consider is do you go with Close-Source systems (all the above examples are Closed-Source).  Or do you go with Open-Source systems – such as TrueCrypt, VeraCrypt, Ciphershed and others.  Some people prefer using a Closed-Source system that they purchase.  They offer better support and the backing of a recognized company.  Others prefer Open-Source systems because the source is open for inspection – and any back doors that are probably in the Close-Source systems (thank you Department of Homeland Security) are most likely not there in the Open-Source systems.  But let’s be honest – does any of that really matter to the average clinic – Probably Not.  You just want to encrypt your disk/data and show that you have taken reasonable steps to protect patient privacy.  It is all about risk mitigation – nothing more.  So if that is the case, just about any of the above products will work for you.  Note:  TrueCrypt was mysteriously discontinued last year.  It has been replaced by VeraCrypt – which is very, very similar – and compatible with versions 6.x and 7.x.  VeraCrypt is also the one we will use in this example.  We use the open source products in this article because they are free and available to everyone.

Every one of the products mentioned above can be configured to support 256 bit encryption.

Our Solution

Encryption has to be easy and quick to use if it is going to be used at all.  The initial setup may require a little technical knowledge – but the day to day usage must be straightforward or people will just not use it.

To this end we have created a very simple setup that will allow you to easily access your encrypted drives.  There is a file called “EHD.zip” file associated with this article that has the complete directory structure we note below – including all the necessary files and a sample VeraCrypt encrypted container file (1MB in size).  This will allow you to get started quickly (you just need to replace our encrypted container file with one of your own making).

Once you have download the EHD.zip file, the first step is to create your own encrypted file container.  You can use the VeraCrypt program, included in the download, to do this.  There is a PDF document attached to this article, showing how to use VeraCrypt to create an encrypted file container – (HowtoUseVeraCrypt.pdf).

You can make this new encrypted file container as large or as small as you need.  I usually suggest making it about 20% larger than what you think will be the largest you need.  The reason is that you cannot enlarge it later.  If you need more space than you planned – you may have to destroy the current encrypted file container and create a new, larger one.

For the file name we usually put a .sec file extension on it – standing for secure file.  You can use whatever file extension and name you want.  We use the file TimeAcct.sec as our default.  If you change the file name, you will have to update the batch file that is used to mount the encrypted file container to a drive letter (TAMountSecureUSB.bat)

Directory structure we will need on the hard drive

The setup of our system depends on the following directory structure.

  • Root directory
  • TimeAcctSecured
  •  VeraCrypt

Where the root directory contains the batch files we will be creating

  • Where the TimeAcctSecured directory contains the VeraCrypt Encrypted Container File
  • Where the VeraCrypt directory contains the VeraCrypt program
  •           (Note: VeraCrypt is not installed – but in Portable Mode)

Now the Root Directory can be either the root of a drive, such as when you use this with an external drive or USB key – or it can be a directory anywhere on the hard drive.

The Batch Files

We have two batch files that are used.  One to mount the encrypted file container and the other is to dismount the encrypted file container.

In this example – the drive letter “H” will be mapped to the TASecDrive.sec file.  This will give the user with the standard VeraCrypt password box.  Upon entry of the correct password drive H will then point to the encrypted data.

At this point – you can now use drive T as you would any other Windows drive.  You can perform a back up to it, copy files to it or from it, etc.

In the above batch file the /d h command will dismount the Drive H from whatever encrypted file container it is associated with.

How to use

When you plug in the hard drive, you need to double click (or run) the batch file (VCMountSecureDrive.bat).  This will prompt you for the password and then add the drive letter “H” (or whatever drive letter you have set in your batch file) to your system and point it to the encrypted file container.

You can then do your backup, copy files, or whatever you want.   When you are done – you simple double click the other batch file (VCDismountSecureDrive.bat) – which will dismount the drive letter from the encrypted file container and you can safely remove the hard drive.

You can download the associated Files from here

We also have a quick overview of how to use VeraCrypt – which can be downloaded from here