EHRs and Daylight Saving Time

So I had noticed that whenever it was time to "fall back" for daylight saving time, our hospital's EHR would have downtime.  I always had assumed this was sort of a coincidence, or maybe that the downtime was a 'change the battery in your smoke detector' kind of event.  But then I read a brief article in Becker's (https://www.beckershospitalreview.com/ehrs/daylight-saving-time-stumps-ehrs-5-things-to-know.html).  And it occurs to me that my hospital's EHR has been shutting down during the fall back overlap because it is unable to handle daylight saving time change.

A quick review of areas that use daylight saving time (DST): at some point during the spring, the clocks will "spring forward" and skip over the entire 1 AM hour, going from 12:59 to 02:00.  This is the 'GAP', and represents the start of DST.  This does not seem to cause a problem with EHRs.

On the other hand, at one point during the fall, the clocks will "fall back".  When the clocks hit 2 am, they go back to 1 am.  In other words, 1:59 AM is followed by 1:00 AM.  This is the 'OVERLAP', and represents the end of DST. This is when apparently many Epic and Cerner systems schedule a downtime.  Per the article, those systems that don't have downtime have the expectation that any observation/result value entered in during that time won't persist.

There is really no excuse for this.  There are a number of software libraries relating to time that can adequately deal with this.  Java version 8 integrated a modified version of the Joda-Time library, which makes this type of issue fairly trivial.  (FYI, the solution in Java speak is to make the timestamps for observations and other important values based on an 'Instant' rather than a 'LocalDateTime'.  The 'Instant' can be represented by the number of milliseconds that have elapsed since Jan 1, 1970 00:00:00 GMT.  There is no ambiguity here.  The EHR software should convert the Instant into a LocalDateTime for display.  And when there is an overlap, the software can even append the time with either 'DT' or 'ST'.  If the EHR is receiving external messages in local time (which it really should not be), it can convert these to instants using the current time zone.

And to put things into perspective, Tesla has software than can essentially drive a car for you.  This is an incredibly intricate system that utilizes state of the art image recognition coupled with complex algorithms to decide the automobile's next move.  EHRs cannot handle inpatient diabetes management, despite discrete structured data (blood glucose values).  And they apparently can't handle daylight saving time changes.

Progress Notes and the Enlarging Assessment/Plan Sections

Problem:

I have seen a common pattern popup over the last ten years in daily inpatient progress notes, specifically the assessment and plan section. This only occurs in copy-and-paste notes, and I don't have a good name for it at the present time.

Here is a fictional example of a partial A/P:

Day 1:
GI Bleed 
    -has been going on for at least a week before admission
    -GI requests holding anticoagulation for a-fib

Day 2:
GI Bleed 
    -has been going on for at least a week before admission
    -GI requests holding anticoagulation for a-fib
    -GI performed colonoscopy, no clear source of bleed.  
    -PPI q12h for now

Day 3:
 GI Bleed 
    -has been going on for at least a week before admission
    -GI requests holding anticoagulation for a-fib
    -GI performed colonoscopy, no clear source of bleed.   GI also performed EGD, small ulcer in fundus, no active bleeding.  
    -PPI q12h for now

Day 4:
  GI Bleed 
    -has been going on for at least a week before admission
    -GI requests holding anticoagulation for a-fib
    -GI performed colonoscopy, no clear source of bleed.   GI also performed EGD, small ulcer in fundus, no active bleeding.  
    -PPI q12h for now
    -patient had hematemesis, and GI performed another EGD, noted a large duodenal ulcer, cauterized



Essentially, the previous progress note is copied into the current one, and additions (with some slight alterations of previous details) are made.  Now imagine this pattern goes on for 11 or more days. On day 21, the A/P section for the progress note is insanely verbose. 

I am not a fan of this style for a few reasons.
1. Assessment and plan are sort of mixed together randomly (which is not unique to this pattern)
2. The bigger culprit: CLUTTER!

This pattern junks up the assessment and plan with a lot of repeat, old data.  In handwritten notes, the plan would be a line or two or three.  It would not recap every single development.  One of my colleagues tells interns/residents not to type anything that they would not have written by hand in the pre-EMR days, and this is good advice.

But there IS a very beneficial aspect to this note style.  For anyone who has had to write a discharge summary on a patient they had for only a brief part of the patient's overall stay, this sort of sums everything up for them. 

So how does an EMR handle progress notes while making things easy for the provider who writes the discharge summary?

Solution 1:

One possible solution: for the A/P each day, the provider only puts what is relevant for the current day.   The EMR would recognize the A/P for each problem, and could provide the provider with a summary of care for each problem (ie a compilation for the plans for that section of each daily progress note).

Summary example:
Problem : GI bleed
Day 1: 
Unclear source; has been going on at least a week before admission.
-holding anticoagulation
-GI will perform colonoscopy

Day 2:
Colonoscopy without clear source of bleed. 
-will monitor
-PPI IV q12h

Day 3:
EGD with small ulcer in fundus, unclear if this is source of bleed.
-will continue to monitor
-PPI IV q12h

Day 4:
Patient had episode of hematemesis, and GI performed another EGD.  Noted large duodenal ulcer, cauterized.  
-will continue PPI q12h
-will monitor


So while the summary may be longer when compared to an individual progress note, it is much more clear regarding the assessment and plans for each individual day.  And the progress notes for each day are not cluttered.

Solution 2:

This would still employ a "clutter-free" progress note, but it would involve another document...a wiki-style perpetually edited "Summary of Stay" document.  This is essentially a Discharge Summary document that is started when the patient enters the hospital, with each problem having its own section.  Every day (as needed), the document is edited to include the recent developments.  When it is time to discharge the patient, the discharging provider has to simply make a few cosmetic edits to the document.

Example of EMR unusability - finding the correct order

Just an example of why current EMRs are so unusable is the difficulty in searching for the appropriate order in CPOE.  Just as an example, a few years ago I tried searching for normal saline in a popular EMR implementation:

• "NS" - failed search
• "Normal saline" - failed search
• "Saline" - failed search
• "NaCl" - failed search
• "Sodium chloride" - successful search

About halfway through that search list is when I wanted to throw the computer across the nursing station.

An EMR company may defend such results, saying that it is the client who is responsible for creating the orders and synonyms.  But my dictum is "Never let the client have a bad configuration."  Another way of saying that is, "Never let the client make your EMR software look bad."

Or "Don't invite comparisons between your software and Vista/CPRS".


EMR vendors should provide basic synonym support for orders.  And in addition to that, it should provide an automated test system, where each of these search terms is entered in and the results are evaluated for the expected order type.

EMR development's fundamental flaw

As I've said before, I think one of the core flaws in the typical process of EMR development is that the programmers do not actually use the software--they are not physicians/nurses/etc.  Let's contrast this with the development of word processing software--practically every programmer is also a potential user of the software, and so when something during the execution of the software is "off", the programmer will likely spot it him/herself, and go in and correct it.  Or if indenting something took an unusually large amount of mouse clicks, then they would catch on to this and fix it.  An even better example might be the programming of an IDE (ie software for programming software).  While I may have the occasional gripe about NetBeans or similar software, modern IDEs (with the possible exception of Apple's XCode) are incredible pieces of software.   

With EMR development, the programmer does not actually use the software, at least not in a real life kind of way.  Instead, they often rely on the advice of consultant physicians.  But this one degree of separation from use is very significant in my opinion.  While the physician knows the "it would be nice if it [did such-and-such]" things, the programmer knows the underlying data structures and what the EMR IS and IS NOT capable of doing.  While reconciling these two things (what is desired vs what is possible) can be done between two people, it is very inefficient.  When the programmer and the physician are the same person, this process is exceedingly more streamlined.

Moreover, the small things that a physician may find wrong with an EMR may just get ignored, because the process of explaining to the programmer why some part of the UI is annoying to use may be too much effort.  EMRs should actively solicit feedback from ALL users, not just paid consultants.  There should be an easy-to-access menu option that a user can select to provide such feedback--a suggestion box.  FEEDBACK, FEEDBACK, FEEDBACK is what is needed.