Category 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.  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 “” 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 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.


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.


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.



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?

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.