Tag Archives: EMR

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.

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?