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.  However, it is still the most popular and widely used Open-Source encryption program.  It is also the one we will use in this example.  You could also use VeraCrypt – which is an offshoot of TrueCrypt and supports the same basic command line interface we are going to use.  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 TrueCrypt 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 TrueCrypt program, included in the download, to do this.  There is a PDF document attached to this article, showing how to use TrueCrypt to create an encrypted file container – (HowtoUseTrueCrypt.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
  •                       Secured
  •                       TrueCrypt

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

  • Where the Secured directory contains the TrueCrypt Encrypted Container File
  • Where the TrueCrypt directory contains the TrueCrypt program
  •             (Note: TrueCrypt 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.

MountUSB

In this example – the drive letter “T” will be mapped to the TimeAcct.sec file.  This will give the user with the standard TrueCrypt password box.  Upon entry of the correct password drive T 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.

DismountUSB

In the above batch file the /dt command will dismount the Drive T 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 (TAMountSecureUSB.bat).  This will prompt you for the password and then add the drive letter “T” (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 (TADismountUSB.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

EMR “Dead End Data”

 

When a physician uses his/her EMR they expect all the data to be saved in the database in a useful format.  This is becoming more and more important as we move into the era where the information entered into the EMR is not just for the doctor to take care of the patient (i.e. a replacement for the old paper record) – but will be used for required government reporting, research and analytics (think Big Data Analytics).  In order for the entered data to be turned into useful information – it must be stored in a way that is accessible by the query tools we have today.  Ok – there is a little more to it than that – but if you cannot access it in a meaningful manner – then you are at a dead stop and you cannot move forward.  This is what we call “Dead End Data”.  It can be either data that you cannot access at all – or data that only retains its meaning and usefulness in the original graphical user interface that was used to create it.

The following items are some examples of dead end data that we have found in various EMRs in Canada.  It is by no means the complete list – but should give the reader an idea of some of the data issues that are common in the EMRs.

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.

 

Storing Data in PDF or Other Electronic Documents

Some of the EMRs in Canada utilize PDFs for storing entered data.  This means that the discreet data is not accessible to normal queries.  In these circumstances we have seen the EMR popup an editable PDF, where the user enters data points (height, weight, etc.) into the PDF fields.  When the user clicks a button – the data points are converted into a graph that is shown in the PDF document.  The problem here is that the entered data is not held in discreet database fields where they could be easily queried – but are held instead in FDF fields (a separate file from the PDF – which is designed to hold data in an XML like structure).   The other aspect is that the PDF file does not hold the Graph either – as it is created at run time.  So – when the physician wants to access the data that they entered for those graphs – it is not possible using any normal querying tools.  During a conversion – not even the vendor was able to extract out the data or the graphs – thus the data was ‘lost’ to the clinic.

Using RTF or HTML Documents to Store Meaning

During our years of performing data conversions, we have encountered this a few times.  Some vendors like to add some ‘flash’ to their EMRs by adding the ability to enter rich text (bolding, underline, italics, etc.) either by using RTF or HTML abilities.  While this may look good on a screen – it can cause some issues when moving that data to a new EMR.  Most other EMRs do not support the use of Rich Text.  So when they import that data – it can either look odd, due to the markup tags – or it may lose some of its meaning.  Take for example a clinic that was holding choices in a document using Rich Text.  They had questions / answers in the text note like the following:

Did you ask the patient about their exercise habits?    Yes    No

In the above the user highlighted the word Yes and bolded it – denoting that the doctor had asked them about their exercise habits.  However, when the Rich Text was stripped out – it looked like…

Did you ask the patient about their exercise habits?    Yes    No

Which means – it has lost its meaning.  Now, the above is not how the vendors would recommend using the Rich Text – but it was how it was used by the clinic.

 

Encrypting Data

Some EMRs use encrypted fields or encrypt their entire database.  While this has some security benefits (minimal) – it really serves as a way for the vendor to block access to their database information.  It locks the clinic into the vendor’s tools as they are the only ones that can access the data contained in them.  No query tool, except perhaps one created by the vendor, will be able to access the data in those fields or database.

 

Embedded Images in Chart Notes

Some EMRs allow the physician to add an image to the chart note.  These images may be something as simple as an image of a body that the physician can mark up to show where the issue was.  The issue here – is that if that is the only way a physician notes the location – it may be lost when transferred to a new system.  The problem is that most EMRs do no support the ability to embed images in a chart note – so there is no way to represent it in the new system.  It also means it cannot be queried – as you cannot query an image.  Another issue is that of transfer specifications.  No transfer specification in Canada allows for embedded images in chart notes.

Some vendors try to get around this by exporting all the chart notes as PDF documents – but that creates other issues.  Most EMRs do not allow PDFs to be chart notes – so they have to be held as attachments.  This means doctors in the new system are looking in two different areas for the same information.  As well – for the most part you are not able to query the content of PDFs in an EMR.  This means that you can search for that information.

 

Custom Formats for Data

In some cases the data stored in some text fields is not encrypted – but stored in a proprietary format (or custom format).  This means that while all the text might be there it is not in a readable form.  This is sometimes done when the EMR uses a custom form or template – and stores the data and the presentation (GUI) together in one field.  So – while the text the physician entered is there – it is not in a readable format.  Neither are you able to query it.  When the physician brings up the chart note in the EMR – it deciphers the cryptic text and rebuilds the custom form or template – displaying the data as the physician expects.  While this can make for some very useful user interfaces – it can make the data almost useless for other purposes.

The following image shows what that sort of text might look like…  This is a simple chart note in an EMR – which when displayed in the EMR will make sense – but shown in the database is nothing more than nonsense, as the following screen shot shows.

CustomData_customdataformat

 

Custom Forms & Templates

Most EMRs do a decent job at implementing custom forms and templates.  However, some do not.  Some require user interaction before information is displayed.  This means that is impossible to then transfer the full information in a custom form to a new EMR or query that data.  This occurs very infrequently – but it is a good example of dead end data.  You cannot export it, you cannot query it – all you can do is display it in the current EMR.

 

Undocumented Fields

Many fields in database systems may have field values something like 1, 2, 3, etc.  In many cases these values reference look up tables.  So – you might have a field – say Marital Status that can have values of 1, 2, 3, 4, 5 – where there is look up table that would have records such as

Key     Description

1          Single

2          Married

3         Divorced

4         Widow

5         Unkown

This makes the database easy to access and query, because you can easily find out what the values for the field stand for. However, there are many fields that are not documented as well. What if you have a field called Category for attachments – and it has values 1, 2, 3, 4… 21 – but does not have a lookup table to define what these values really mean. This can make querying the database in a meaningful way very difficult – if not impossible. Many times the only place these fields are documented is in the source code of the EMR – which is readable only by the programmers.

EMR Data Issues to Consider

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.

The Un-Intended Consequences of ASP EMRs

In the past it was all about encouraging doctors to adopt EMRs.  Part of using an EMR meant maintaining the computer systems upon which they run.  But that is not core to a medical practice – and not something most physicians want to deal with.  Doctor’s don’t want to be bothered with maintaining computers, doing backups, worrying about what version they are running, etc.  They want to practice medicine.  So – a reasonable solution in the last 5 to 10 years was to move all the maintenance, backups, etc. into the world of Application Service Providers (Hosted Applications).  This solved the doctor’s issues with having to take care of the computer ‘stuff’ and let them concentrate on what they do best – help patients with their medical issues.  Yes – there were higher monthly fees and the occasional issue with Internet connectivity, but the computer hassles were largely taken out of the day to day lives of the clinics and it was seen as generally a good thing by most physicians and clinics.

 However, looking at it in view of what is happening today in the field of Health Care Analytics, it might not be as positive, moving forward, as it was once viewed.  The real value is no longer in the EMR itself – but in the data they contain.  Over the next few years Health Care Data Analytics will only continue to get bigger and drive more of the revenue in the medical system.  Whether we are talking about changes to the ‘Fee for Service’ model, or just being able to do real research on medical conditions – the data will be the driver.  Just look to the USA’s Meaningful Use push to see where the world is moving.

 Now, if the data is now the most important asset a clinic or physician might have – then it should be important for them to be able to control and utilize that data.  If an organization does not understand and utilize their most important asset – then they are doomed to be controlled by those that do.  This brings us to an un-intended consequence with ASP EMRs.  The doctor does not have real control of their own data.  It is stored remotely in data centre controlled by their EMR vendor.   What happens if the clinic would like to participate in an EMR research study?  How do they get ‘access’ to their data?  The simple answer, in most cases, is that they are dependent on the EMR vendor to provide the data to them so that they can provide it to the research organization.  How long will it take to get the data?  Does the vendor already have the export format that the physician will need?  Or will it have to be developed?  Then there is the subject of cost!  The vendor will charge the clinic to get access to their own data.  The vendor has to in order to stay in business.  The question is what is a fair charge?  I have seen a vendor charge $2,000 just to provide a single backup of the clinic’s database (which took a grand total of 15 minutes to create).  How many studies could a clinic participate in if they had to pay that fee each time?

 I am not against ASP EMRs, in fact I think they can offer some excellent value to clinics.  However, with the health care world moving toward a more and more data centric view – where will clinics that have their most valuable resource under someone else’s control fit in?  Will they be able to participate in the studies and research initiatives?  Will their patients be able to benefit from being part of these studies?  What if any are the possible solutions to the situation?  Standard APIs would be nice – but as we have seen getting everyone to cooperate and exchange data nicely is still just a pipe dream…

 What are you thoughts?

EMR Data Archiving Issues

In Canada everyone that works in the medical record industry should know that the doctor owns the record and the patient owns the information contained therein.  This makes the doctor the custodian of the patient medical information (record).  Most also know that the doctors are required to keep their medical records for a certain period of time, after the last time they saw the patient (referred to as the retention period).  In fact, doctors are required to keep these records even after they are retired – and their estates continue that responsibility after they have died – until the end of the retention period.  In British Columbia (which has the longest retention period) – this could amount to almost 35 years for a doctor who sees a new born child.  That is a long time to have to keep a record, especially after retirement.  There is a great page on the CMPA website (https://oplfrpd5.cmpa-acpm.ca/-/a-matter-of-records-retention-and-transfer-of-clinical-records) that gives a good summary of the retention periods for each province/territory, as well as some good general information.

There are many issues that surround the doctor’s requirement to keep those records.  Some of which are:

  • They must be kept in a      secure location, as to protect the patient’s privacy.
  • They must be accessible so      that the doctor can provide a copy to the patient (or other legal entity,      such as an officer of the court) upon authorized request.
  • When they are destroyed,      they must be destroyed in such a manner that reconstruction at a later      date is not reasonably possible.   And when they are destroyed, the physician      should record who destroyed them, when they were destroyed, the patient’s      name and the method in which they were destroyed.
  • The retention period for      each patient’s records expires at a different time.  So doctors cannot keep all their records      until the final one expires and then just destroy them all.  They must be destroyed for each patient,      as that patient’s particular retention period comes to a close.
  • The destruction must also      include all other copies of the data, including computer backups, records      stored in portals/cloud storage, and even records in an EMR that is being      actively used.

Every province has a minimum time that a doctor is required to retain their medical records.  But what happens after that retention period is reached?  In most provinces the doctors are required to destroy the records.  However, a few provinces, such as Ontario and Alberta, do not have any legislation one way or another.  This has led some doctors in those provinces to adopt the policy that they never have to destroy their medical records.  While this is a gray area, keeping the medical records forever it just not a smart thing to do, for a doctor or clinic.  It provides absolutely no benefit to the physician, while increasing their liability.  Imagine the case where a physician keeps the medical records after the retention period.  Then they are contacted with a legal request for the medical records for a lawsuit regarding the patient.  They, at that time, are legally bound to provide the medical records, if they still have them.  However, because they should not have kept them and then provided them to the court, is the patient able to then take legal action against the doctor because they should not have retained them after the retention period?

The issues around EMR record retention, destruction and archiving are going to come up more and more often as the number of doctors retiring after years of using EMRs in Canada increase.

Hopefully, the following blog posts will help encourage discussion on the subject.

 

#1 – EMR Data Archiving – The Problem with Continuing to use Old EMRs

Some doctors/clinics try to continue using their EMR on an older computer as a way of dealing with the issue of archiving their medical records.  However, while this solution has the advantage of a familiar look and feel, it has many issues that may not be obvious to a retiring doctor.  The strategy, while simple at a surface level comes with significant costs (licensing), data state control (i.e. keeping records read only), selective purging of patient records and data management beyond the practitioner’s death.

The first issue are the costs associated with continuing to use an existing EMR, especially if it is hosted at an ASP.  This would include things like EMR software licenses and maintaining hardware/operating systems.  There are also add-ons required for many EMRs, such as Microsoft Office, etc.  As well, you now have to keep that system running for anywhere from 15 to 32 years…  Can you guarantee that your system will be operating after a few years?  Keeping in mind that if it fails, your EMR vendor may not be able to get that version up and running again – and then you will have to pay for an upgrade, etc. – assuming that the vendor is even still in business.

The second issue is that of keeping the records in a Read-Only state.  This is a way of keeping the records ‘frozen in time’.  That way there is no reason to question whether the medical record is in the same state it was when the physician retired.  This may be important in any legal issues that arise.  The problem here is that most EMRs are not designed to be run in a Read-Only fashion and cannot function with that restriction.

The third issue is that of purging of data.  Most EMRs are designed to not ‘lose’ any data.  They do not allow a patient to be truly deleted from the system.  They are simply flagged so that they do not show in the GUI.  This violates the privacy laws that state that a record must be destroyed in such a way as to make later reconstruction not reasonable possible.

The fourth issue is that of ease of use and the continued liability of the doctor’s estate after his/her death.  Since a doctor’s spouse and/or children might then be responsible for the medical records, will they know how to navigate the EMR software well enough to print out a patient record if it is requested?   Most of these programs are fairly complex and are meant for an experienced user.

The final issue is that very few, if any, EMRs have the ability to select patients based on the criteria of expired retention periods, making selection and purging of patient data difficult, if not impossible.

So, in most cases, continuing to use an older EMR as an archiving solution is not ideal.

Issue with using VMWare and other Virtualization Programs

This is another popular way of providing the Physician with his/her older data – in the familiar setting of his/her existing EMR.  Some provincial bodies are even providing funding for this – as part of an archiving solution for Physicians who are converting to new EMRS.  The problems here are exactly the same as continuing to use the existing EMR.  The doctor still has to deal with licensing issues with the vendor to be able to legally use the EMR, thus possibly incurring ongoing costs.  And more important is the lack of a purging ability in the EMR being virtualized – thus exposing the physician to additional liability around retaining patient medical records that are no longer supposed to be in their possession.

However, by far the biggest problem with virtualizing an existing machine is that it may violate your Microsoft Windows license!!  In effect it makes doing so illegal.  Basically, depending on your existing Windows license for the existing machine cannot be legally virtualized into a Virtual Machine.  The only general exception to this is if it was originally purchased under a “Volume License Agreement” – which is usually only done by larger organizations – and almost never by clinics and doctor’s offices.  And there is no way to transfer the license, etc.  The older the operating system – the more likely it is to NOT allow virtualization.  Windows Server 2003 does not allow it – but Windows Server 2008 and later allow virtualization in some circumstances.  So, you need to carefully check what your license agreement says!  Otherwise, the physician is taking on the risk of having an illegal copy of Microsoft Windows in their possession.  Similar issues arise around the virtualization of an Apple machine as well.  If you would like to know more about this issue, you can contact us directly.

 

#2 – EMR Data Archiving – The Problem with Storage Centres – COST$

While used more for paper based records, storage centers offer the doctor a head ache free (almost) way of dealing with the requirements of keeping their records.  However, you end up paying for that ease of use.  Dr. John O’Brien-Bell wrote an interesting article for Canada Healthcare Network in 2013 about the costs, when BC decided to move from a 7 year retention period to a 16 year retention period.  The full article can be found here in this link:

http://www.canadianhealthcarenetwork.ca/physicians/discussions/opinion/did-bcma-do-enough-to-try-to-defray-med-records-storage-costs-29699

However, to summarize it – he estimates that the cost of maintaining the medical records for 16 years to be somewhere around $25,000 dollars.  That is a lot of money for a retired doctor to shell out, especially when there is no revenue coming in to offset it.

 

#3 – EMR Data Archiving – The Problem with PDFs of Patient Records

Another very popular strategy many physicians use to archive records is to export them to series of PDFs.  However, it has many issues of its own.

The first issue is that of whether attachments, or scanned documents, are included in the actual PDF itself.  If they are then there are concerns as to whether or not the PDFs actually meet the Colleges/CMPA requirements of ‘Legibility’ for all records in a doctor’s care.  The problem here is that most scanned documents are scanned in from pieces of paper in a doctor’s office – which would mean 8.5×11 inch sheets of paper.  As most vendors use standard reports to export the patient information out to a PDF file this means that you are then trying to print a 8.5×11 document on a 8.5×11 document – which cannot be done without scaling.  It is the scaling that causes the problem.  As most export functions use a standard report to do this – and they print typically to a laser printer – the resulting PDF has the same characteristics.  These characteristics including having a standard ¼ to ½ inch border around each side of the document – which means that you are no longer able to print an 8.5×11 on an 8.5×11 area – but rather at best an 8×10.5 area.   As well – on that page you probably would want some Meta data – such as doctor name, date of the document and possibly some notes.  This means your printable area is now more likely at best 8×9 inches.  So – you have two choices at this point.  You can either print proportionally or stretch to fit the area.   Either are compressing the image to fit – and possibly distorting it.  Because computers scale down images often during document handling, the worry is information could be lost in that scaling – either through distortion, or strict data loss.  Will commas read as periods alter the meaning of the document?  Will the height to width ratio of a black spot on a tumor change the diagnosis?  We cannot tell with certainty – certainly not to the level required by college retention requirements.

The second issue is that of purging.  The doctor needs to purge each medical record as it reaches the end of its retention period.  Considering that a typical doctor will have at least 6,000 patients in his/her EMR when they retire (with only about 2,000 being active patients) – the doctor will have to search through each PDF every 3 to 6 months (to show due care) and find that last time they touched that medical record.  That would probably have to be the last chart entry – and not appointment – as patients will just not show up at times.  How many doctors (especially those who are retired) do you think will take the time, or even remember to do this?  This means that they are exposing themselves to added liability by not properly destroying the records when they are required to do so.

The doctor cannot simply delete the file (from Windows, Apple or Linux computers)  – but must use a tool like Eraser – which securely deletes a file from disk.  Add to that the requirement to delete all external attachments if the PDF was created properly with the scanned documents being stored externally to the PDF.  As some patients can have 100+ attachments – this can become a rather long, cumbersome and error prone task.

 

 

#4 – EMR Data Archiving – Other Miscellaneous Issues

As well as the issues that need to be considered for doctors archiving their medical records, the following four items should be of concern to the medical community as well.

1.       Patient Portals

When a doctor is using a patient portal that allows the patient to book their appointments online, or communicate with the doctor, view their medical records, etc. – there may be issues when it comes to the purging of that data.  If the portal has its own storage, then how does the doctor know that when he has deleted a record from his/her EMR that the same purge has occurred in the portal?  Is the doctor still liable for the information stored in the portal?  The physician should make sure he/she has the agreement/permission from each patient who will have their data sent to the portal in order to protect themselves.  What happens to all those records when a doctor retires?  Are they purged from the portal?

2.       Cloud Storage

As many EMRs are now moving to an ASP type solution – more and more of a doctor’s patient data is being stored in another site that is out of his/her control.  While this is not necessarily a bad thing – it does raise some questions for the doctor and his/her liability to those records.  Can he/she be assured that when they have requested a purge of a record that is done and complete?  See Backups below.

3.       Backups (especially in the Cloud)

Where does a doctor’s responsibility end?  Backups are a good example of this.  Take for example a typical doctor office might use a different backup drive for each day of the week and cycle through them.  This allows the doctor to be able to guarantee that the data will be purged from all backups after a 7 day cycle.  However, when using an ASP or Cloud based solution – the doctor does not have control over this cycle.  Some service providers can keep backups for a year or more.  How does this affect the doctor’s liability regarding the purging and proper destruction of the medical records under his/her care?

4.       Records in your current EMR – for Non-Retired Doctors

This is an interesting question that needs to be discussed – as most EMRs do not have the ability to truly purge a patient’s medical record.  If a doctor last saw a patient 10+ years ago – should he/she not purge that record from the EMR?  The doctor no longer has the right to continue to have that patient’s medical information in the EMR.  Yet – as TimeAcct converts EMR data every day – we see this more and more as doctors continue to use EMRs over longer periods of time

5. Operating System Functions – journaling and caching. 

In theory, data will be recorded in caches, file system journals, etc.  All of these must be deleted too.

Is All EMR Data Created Equally?

The simple answer is no – not all the data is equal.   Some EMR data is useful and some is just barely usable.  I guess I should first put some context around what I am referring to.  When a doctor enters data into his/her EMR, they are recording information about the patient.  Many, but not all, use it as a note taking process that has replaced the old paper charts they used to use, even though they may enter discreet data elements.  This serves their purpose of having a record of the patient health in their office that is usable by them.  However, as we continue to move forward in the use of EMRs, the doctors and clinical staff are not the only ones interested in the patient data.  Society as a whole has an interest and a role to play in the data gathered about patients.  The government could use that data to help control the spiraling costs of health care, research companies could use that data to perform better research – leading to new cures, etc., drug companies could use the data to learn more about how their drugs are really performing and make appropriate changes.  And this could all be done while ensuring patient confidentiality (a sticky subject for another time).  The real value of EMRs is moving away from the EMRs themselves – and towards the data.  The problem we have is that the data is not all the same quality.  Some of it is good, coded, discreet data (useful to everyone) and some of it is not (usable by the physician only).

EMR Data – the Good, the Bad and the Ugly…

A few years ago in Canada – when Doctors thought about using an EMR system – they were simply thinking of recording their paper notes on the computer.  In some ways this was a big step up from paper charts – take for example that the doctor’s notes could now be shared with anyone in the office at any time.  However, by far and away the biggest impact that these early systems had on the doctor’s offices was to move the scheduling and billing systems off of paper day sheets and onto the computer.  These systems did very little to improve patient care – they were mostly about automating some of the tasks in the physician’s office.

The Problem with Unstructured Text

As with all computer systems – you get out of it what you put into it.  So the quality of the data you can get out of them is only as good as the quality of the data you put into them.  That was really the problem with the early EMR systems.  Since they were really glorified note taking applications – they offered the user ultimate flexibility by entering in unstructured text.  Take for example entering Allergies.  The early systems would usually just allow the doctor to type in the allergy names right in the note itself.  So the allergy was documented – but there was no way to find it except for scanning the entire patient notes.  The next step up from this came along pretty quick – which was separate entry of things like Allergies, Problems and Medications.  The problem here was that everything was still unstructured text.  Take for example a clinic with five doctors – each entering their own medical information.  Let’s look at Problems as an example.  How would they enter a problem like Diabetes?  Well – because there were no enforced rules for entry – in many cases the entries would look like the following:

        • Diabetes
        • diabetes
        • diabetic
        • Type 1
        • type 2
        • Diabetes
        • T1
        • Etc…

While the above might make sense to most readers in a clinical environment (although I question the ‘T1’ entry) – it does NOT make sense to a computer.   They are just text entries – and when you try to pull out which patients have diabetes – it is almost impossible to do so across the patients of different doctors in a reliable fashion.  In fact, unless the doctor was very careful to enter the exact same value each time – it would be difficult to select all his/her patients that had Diabetes.  If you told the computer to find all the patients that had ‘Diabetes’ – it would only return two from the above set.  None of the others match exactly.

This is a prime example of the computer phrase – ‘Garbage in – Garbage Out’.  The doctors were entering their data – but it was not in a reliable/standard format– so there was no value to the doctors when they wanted to know things about their patient populations – even simple things like ‘How many of my patients have Diabetes?’.  And you could forget asking the application more complicated things.  What would they do if there was a drug recalled by the government and they needed to get a list of their patients taking it?  Or what if they needed to get a list of their patients who had a particular condition, like diabetes, to update them on a new treatment?  Either of these simple tasks would be almost impossible to do accurately, without any sort of reliably entered data.

The Problem with Pick Lists

As the EMR systems evolved – the vendors/governments tried to make the data more useful by forcing the users to pick things like allergies and problems from pick lists.  Here the clinic would setup a list of allergies, a list of problems, etc – that the doctors would pick from.  This worked well in theory – but still had some drawbacks.  The first was that if a doctor didn’t immediately see the problem he was looking for – he would simply add it.  Thus you could end up with two problems listed for diabetes.  Or the clinics would setup a problem for

      • Diabetes
      • Diabetes – Type 1
      • Diabetes Type 2

Thus when you wanted to find a list of all the patients who had Diabetes, you had to remember to select all three – if the software even allowed that.

However, the real problem with these pick lists is not immediately obvious to most people.  The problem lies in how the data is stored…  (Warning – I am about to get all techie on you for a few moments)

When you have a pick list – it is stored in a separate table in the database.  That table is ‘keyed’ usually by another field that is an Integer field (i.e. a numeric field).  Then when that pick list value is chosen for a problem – the Integer value is stored – not the name from the pick list.

To make sure we all understand this – lets use the following example.  The first table below shows a sample list of problems that a clinic might setup.  Note that the first column is the one that identifies the record.

The second table shows the problems that have been assigned to patients.  In this example – you can see that there are two patients with Diabetes.

List of Problems – Table is called ProblemList

List of Patient Problems – Table is called PatientProblems

In the diagrams above you can see that most references to other tables are stored as numbers.  This is a very common way of setting things up for two reasons:  First it saves space in the database.  Storing the integer takes less than 50% of the space than storing something like ‘Diabetes’.  It also allows the user to change the name of the problem (i.e. correct spelling mistakes, etc.) at any time without affecting any of the records where that problem had been used – because it just points to the record number.

This solution can allow the Clinic to more reliably report on their patient populations.  It can improve their ability to ask questions like “how many of my patients have Diabetes?”

While this has become somewhat of a standard in the computer industry for how to store data – it does present some issues when used in the evolving EMR environment.  This type of solution was perfect when doctor’s offices and clinics were isolated work places that did not share their data with anyone else.  The issues start to arise when doctor’s offices and clinics want or need to share their data with others, such as when the clinic is part of Community of Practice or when they need to communicate with the government.  This is one area where the above technical solution falls down.  Since the numeric keys that are assigned to the records in sequence – each clinic will have its own numeric sequences.  So – in Clinic ‘A’ the Diabetes problem might have a key value of 1 – while in Clinic ‘B’ the Diabetes might have a value of 2 because they were entered in a different order.  If this is the case, then you cannot compare by key value.  And while there is the text of the Problem name –we are then back to the problem of trying to compare unstructured text again.

At this point, the main question is how can Doctor’s offices provide better care to their patient population, share information with other members of their Community of Practice and other agencies.  The simple answer is to collect the data in a better way.  So the obvious next question is how can we achieve this goal?

Using an International Standard to Codify the Data

The first step toward collecting better data that can be shared and reported on accurately – is to establish a consistent way of identifying or codifying it.  The best way to do this is to use a well-recognized international standard.  The benefits can be realized because the standard will be consistent across all software/clinics that use it.  This means that when doctors need to share patient data with other clinics in the community of practice or with other medical professionals, governments, etc. – a problem such as Diabetes will be recognized by the receiving parties as Diabetes – no matter how it is spelt or dealt with in the originating system.

This is why there is a push to use codification standards such as SNOMED CT as a way of identifying conditions and terms in our EMR systems in Canada.  It will help us share and accurately report on the information about our patient populations.

Take our Diabetes example again.  There are SNOMED CT terms for each type.

      • Diabetes                           73211009
      • Diabetes – Type 1       46635009
      • Diabetes – Type 2       44054006

And these codes will never change – they will always mean the same thing in each clinic and system in which they are used.  This is a huge step forward from how we have stored the data in the past.  This starts to make the data truly useful – not just to the physician, but to the patient, governments and other organizations.

All EMR Data is not Equal…

Collecting better data is really just about entering better data.  Sounds simple enough – right?  Well – not really.  The first step toward entering better data is having a software application that allows you to do that.  By this I don’t mean just being able to pick a code from a list while entering a note.  But by being able to encode all entered data – whether it is problems, medications, labs and even recognizing typed text in entered chart notes!  The more data you are able to encode – the better off you and your patients will be in the future.  The second step is changing the data entry habits of users, so that they are choosing to enter discreet, coded data – rather than taking the easy way of just typing in text.  The old saying of “You can lead a horse to water, but you cannot make him drink” applies here.  There has to be perceived value to the physician in order for this to be adopted.  And the final step is to improve the data transfer/conversion capabilities so that when a clinic moves from one EMR to another, they do not lose all their high quality, discreet, coded data in the process.

With a system that allows you to encode all the entered data – you can move from asking questions like ‘Give me a list of all the patients in my practice who have diabetes?’ – to asking questions like ‘Give me a list of all my patients who are at risk of developing diabetes?’.  Imagine being able to be recall a patient and help them treat their condition before it develops in a real problem?  To be able to show them their risks and what they need to change and live a healthier life.

Without an EMR that properly encodes that entered data – you simply cannot provide these types of services that the public will come to demand in the near future.

So – no, not all EMR data is created equal.  It depends on how the data is stored, how it is encoded and how much of it is encoded.  If you don’t have an EMR that does and does it right – then you are just entering more ‘Dead-End’ data.

 

 

EMR Data Security – Product Recommendations

The following are some products we use regularly – and recommend to our clients.  They are usually free to use and are very well known.

 

7Zip (http://www.7-zip.org/) – FREE

7Zip is a free program that is well known and automatically uses 256 bit encryption when you put a password on the archive.  It is easy to use – very much like WinZip that was popular years ago.  The two main things in favour of this program are that it is free and automatically uses 256 bit encryption.  It is great for encrypting small numbers of files into one file before emailing it or sharing it with others.

TrueCrypt (http://www.truecrypt.org/) – FREE

TrueCrypt is a great program for encrypting entire hard drives or creating encrypted containers on hard drives.  This is great if you want to create a large encrypted container that you can mount and store files in.  TimeAcct has easy to follow and use documentation on how to use TrueCrypt.  If you would like a copy, just contact us at info@timeacct.com and we will happily send you a document.

Eraser (http://eraser.heidi.ie/) – FREE

When you delete a file on Windows (or Mac/Linux for that matter) – it does not actually delete the file.  All it does is mark the file as deleted.  It is fairly easy to recover deleted files – sometimes even after they have been overwritten with other data.  In order to meet government requirements for properly destroying files, you need to use a program like Eraser.  It overwrites the file data up to 7 different times, following proper processes for data destruction. If you do not use a program like Eraser on a hard drive, then you are most likely not meeting your legal requirements under PIPEDA (or like legislation) in Canada.

Note – if you are dealing with removable hard drives, USB keys, etc. we would recommend using this program and then destroying the actual drive by driving nails through it, etc. before disposing of it.

EMR Data Security #3: EMAIL – The Dangers of Gmail and Other Email Technology

This is another situation we deal with far too often.  We are all so used to using email to communicate that we use it without really understanding the underlying technology.  Since we deal with doctors and clinics during the extraction and conversion process, validating their data – there are times when we need to have a copy of the original medical record to be able to compare it to what we have extracted.  In one case last year, a doctor simply exported the record and emailed it to us as free text.  It had the patient demographics and the full medical record in the text.  Now, this in itself violates Canadian law – as they have breached patient privacy by sending the record through the internet without any encryption.  However, it was made even worse by using Gmail.  Gmail will parse that email and store it on its servers, which are all based in the USA.  So, not only was it sent without encryption, it was now stored outside of Canada.  The doctor was horrified when we explained what he had done, however the damage had been done.

First of all, no medical record information should be sent via email without a very strong encryption.  See a post below for product recommendations.  Second, no medical office in Canada should use the free email services from Google (Gmail), AOL, Microsoft (Hotmail), etc. for their businesses.  These systems all host their email systems outside of Canada and will simply complicate any breach that may occur.

However, it is not just email systems that may cause you issues.  There are other ‘personal’ technologies that people use without understanding the consequences that they may bring.   Take for example various Cloud services that synchronize data between your computer and your phone and other devices (iCloud from Apple for example).  These services are usually hosted outside of Canada.  This means that even if you have taken care to use a Canadian hosted email address, by syncing with your phone or tablet, second computer, etc., you may be storing email data outside of Canada and therefore violating Canadian laws without realizing it.

Summary:

1.  Do not use foreign email hosts for your office work.  Exmples woud be GMail, HotMail, Yahoo Mail, etc.

2. Becareful of what technologies you use, as there may be un-intended consequences.

3. Always encrypt anything regarding patients that you must send via email.

EMR Data Security #2: Removable Storage – Must be Encrypted

We deal with this situation more often than I would like to admit and it takes many forms.  Some examples are:

–          The IT staff performs regular backups of the server on which the EMR is installed.  These backups are then taken off site on a regular basis

–          IT staff take a backup of the data and ship it to a vendor for extraction/conversion

–          Old data is stored on external drives to save space

There are various other situations, but they all have the same issue – patient identifiable data is stored on removable storage that is easily transported or stolen without any encryption.  This is simply illegal.  It does not matter that it is part of a nightly backup, it doesn’t matter that it will only be on the drive for a short period of time, it doesn’t matter that it is ‘old’ data.  All that matters is that it is encrypted and that the patient data is protected.

We have two great examples of the above situations.  The first was a clinic in Nova Scotia that had a locally installed EMR and they faithfully backed up their server every night – and even had a five drive backup rotation schedule for the best protection.  Each night a drive was taken home by a staff member and the next day they brought back a drive.  So – there was always at least one drive off site at the home of a staff member.  This is a decent IT practice to help protect the clinic from data loss.  The clinic had even hired an IT Consultant to set it up for them – the same company that took care of all their IT needs.  The problem was that none of the drives where encrypted and the ‘backup’ was a clear copy of the data drive on the server.  So – each drive contained easily accessible (dBase files) that contained all the patient information in the clinic.  And to make matters worse – it was being taken out of the business environment to the home of one of the staff.  What would have happened if that staff member’s home had been broken into?  I would not want to be the doctor making the report to the RCMP about exposing all his medical data because someone stole a drive from the home of a staff member.

Just like the first example this next one shows how, even with good intentions, you can expose yourself when you are simply trying to protect the data.  Another clinic had data from an older EMR that they wanted to hold onto.  They got the data scanned into PDFs and held it on a special external hard drive device.  This device contained four hard drives in what is called a Raid 5 configuration – which really just means that if one drive fails, you don’t lose your data.  The problem was that, like many smaller doctors’ offices, the spouse did the accounting from home – and this drive constantly went back and forth between the doctor’s office and their home.  They had purchased it to protect the data, but had not thought to encrypt it.  The problem they ran into was that they could not just simply move the data to a new drive, encrypt the old drive and copy it back.  The information on the old drive would first need to be purged in a secure fashion using a program like Eraser (see Recommended Tools in another post below) – in order to meet legal requirements.  As this was a fairly large drive – it was going to take time and effort to solve their problem correctly and reduce their liability moving forward.

Summary:

1.  Never put data on removable media, unless it is encrypted with a minimum of 256 Bit encryption.

2. Make sure your backups are encrypted and well protected.

3. When you destroy the data, take special care to make sure you have done it properly.

EMR Data Security #1: I will just take my old EMR home for Reference

We dealt with this situation few years ago, where a doctor was converting from one EMR to another.  He wanted to keep his old system for reference, but did not want it taking up space in the office.  So his solution was to take it home with him.  We mentioned to him that doing so would expose him to a lot of liability if he did not first encrypt the disks on the computer he was going to bring home – due to it containing medical records.  His response was that he only used to the old EMR for billing and therefore it only contained the patient billing information, which did not, in his opinion, violate patient privacy.

This response showed his total lack of understanding of what he was dealing with.  First, the term “just billing information” is anything but.  The Billing information in Canada uses ICD9 codes – and a direct link to patients.  This means that the billing information, the doctor was referring to, contains the diagnosis for all his patients!  As well, the tie to the patient was a direct link to the entire patient demographics (name, address, phone, birthdate, sex, health card number, social insurance number, etc.).  Billing data is anything but ‘just billing information’!

Aside from diagnosis information in the above example, which would make any privacy breach just that much worse, the demographics information alone is considered personally identifiable information and is protected by both Federal and Provincial legislation.

Another point to consider is that the doctor was moving a business asset out of the business environment and into his home.  Would his insurance company have covered any loss of that hardware or liability if the breach occurred outside of the business premises?  The risks associated with this action far exceed any possible gains on the part of the physician.  Thankfully, once we pointed out these issues, the physician chose to leave the server in his office and over a period of a year and then decommissioned the entire older EMR.

Summary:

1.  Almost all data in an EMR should be kept private.

2. Do not take data outside of your business environment unless you have a very good reason.