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.

The Trouble With RxNorm SCDFs

When an outpatient provider writes a prescription, the strength of the tablet (capsule, etc) will be specified.  For example, the prescription will read, "Prednisone 20 mg tablet; Take 2 tablets by mouth every day".  This is a prescription for 40 mg of prednisone daily. 

For inpatient providers, the strength of the tablet (etc) is typically not specified.  They only want to specify the total amount of drug.  For example, "40 mg of prednisone by mouth daily".


RxNorm is the vocabulary that is used for medications.  It has various different types of term.  The "SCD" term type refers to "Semantic clinical drugs".  This is the type that specifies the specific type of drug tablet (etc).  For example, "Prednisone 20 mg tablet" has the RxNorm code "312615". As mentioned above, the SCD term type is not as useful for inpatient medication orders.  What type would be useful?  When originally examining RxNorm, the "Semantic Clinical Drug Form" (SCDF) seemed to be what I wanted.  It was essentially like the SCD terms, but without the specific strength.  For example, the SCDF code for "prednisone tablet" is "373585".

The Issues:
For one, the SCDF is actually a combination of REGULAR ingredients (IN) + the dose form.  By stressing "regular", I mean to point out that this does not use the "precise ingredients" (PIN).  (Quick example of regular ingredient vs precise ingredient : "metoprolol" is a regular ingredient, "metoprolol succinate" is a precise ingredient).  This will work for most medications, but when you have medications where the precise ingredient matters, you may find that the SCDF is inadequate if those precise ingredients use the same dose form.

Example--the SCDF for "Penicillin G injectable suspension" includes the following different medications:
* Penicillin G procaine
* Penicillin G benzathine
* Penicillin G procaine + penicillin G benzathine combo

 Another issue is that injections don't really fit the expected behavior.  Normal saline and hypertonic saline share the same SCDF, despite being dramatically different in their indications.

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. 

UMLS errors

I frequently find errors in the UMLS.  The most recent one was this past week (version 2015AB).  The atom ID was 'A23834045';--a MTHSPL atom--and had the title:

 Phenytoin 50 g ORAL TABLET, CHEWABLE

"50 g" (ie 50,000 mg) is probably a fatal dose (for most horses).  This obviously was meant to be "mg".  And if someone were entering this by hand, then this mistake would be a little more acceptable (although in that case, they should have an algorithm that parses the strings and throws out warning signs if it does not appear to be valid.  And why are they doing it by hand?)  I'm not sure that this was hand entered.   I went and downloaded some DailyMed data that these entries are derived from, but this data did not have the error.  (It was released a few days ago, so it may have been corrected since then).  So how did the error make it into UMLS?  Perhaps I'll never know.