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.