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.

SNOMED vs ICD-10

Meaningful use dictates that EMRs use SNOMED as the vocabulary for problem lists (as opposed to ICD-10).  This is absolutely reasonable, as ICD-10 is NOT useful for general things such as problem lists.  For example, ICD-10 only has following diagnoses:
E87.2 Metabolic acidosis
E87.2 Respiratory acidosis

Notice anything?  The acidosis diagnoses all have the same code.  That's right.  There is just one code for acidosis: respiratory acidosis, metabolic acidosis with elevated anion gap, metabolic acidosis with a normal anion gap.

But ICD-10 does have multiple codes for dealing with parrot attacks:

W61.01 Bitten by parrot
W61.02 Struck by parrot
W61.09 Other contact with parrot

Now, if that wasn't enough, ICD-10 has codes for interactions with macaws, a type of parrot.
W61.11 Bitten by macaw
W61.12 Struck by macaw

And there are codes for other "psittacines" (ie parrots):
W61.21 Bitten by other psittacines
W61.22 Struck by other psittacines


While SNOMED has simple, to-the-point codes, ICD-10 has very "pre-coordinated" codes, such as I13.2, "Hypertensive heart and chronic kidney disease with heart failure and with stage 5 chronic kidney disease, or end stage renal disease".  And for billing reasons, this code is OFTEN the principal diagnosis for inpatient admissions.  While this type of code may help with DRG assignment/billing, it is not practical for patient care.  In fact, any diagnosis name with an "or" in it is potentially a bad thing to use.

That's why we use SNOMED, a rational, level-headed diagnosis vocabulary.