EMR Software and EHR Audit Trails

Posted on September 26, 2011 I Written By

Priya Ramachandran is a Maryland based freelance writer. In a former life, she wrote software code and managed Sarbanes Oxley related audits for IT departments. She now enjoys writing about healthcare, science and technology.

This morning, I read about a case that engaged me on many, many levels. On the Health Care Renewal blog, blogger InformaticsMD has a fascinating post on a medical malpractice and how EMRs allow this to happen. Here are the key points noted by the blogger:

  • Samuel Sweet, a health 62 year old, was admitted to University of Pittsburgh Medical Center (UPMC) with a headache. It turned out to be a treatable amount of bleeding in the brain. He died three days after he was admitted, on May 16, 2009, much to the surprise of his family with whom he had been conversing only six hours earlier.
  • Apparently, Mr. Sweet had been intubated. His breathing tubes were removed on the day of his death, and it was soon apparent that he could not breathe on his own. Doctors tried to intubate him again, but could not do so, and this resulted in his death.
  • At UPMC, difficult intubations cases must be flagged as such in the EMR. The patient’s record from the EMR then displays a bright yellow banner on top, noting the intubation problems. This is done so that when physicians change, the attending physician is alerted to the problem, and consults with prior notes in order to fix the problem. “Difficult intubation” was not noted in Mr. Sweet’s record.
  • A civil case against UPMC was filed by Mr. Sweet’s family. Some detective work later, their defense team alleges that a full three days after Mr. Sweet’s death, after a post-mortem meeting, Dr. Simmons, a QA official from UPMC “accessed” the UPMC EMR system, and apparently entered data stating that Mr. Sweet was a patient with difficult intubation. The defense has audit trail evidence from the EMR to back their claims. They further allege that when that action failed to post-facto flag his existing records with yellow warning banner, Dr. Simmons tried to retract the “diff intub” entry, and unfortunately for him, even that cancellation of status was logged.

While I am fascinated by InformaticsMD’s write-up, I don’t fully agree with the apparent conclusion reached – namely that “EMR’s can detract from a clear narrative, and facilitate spoliation and obfuscation of evidence presented.”

I would argue to the contrary – that because there is an EMR, there is even an audit trail possible. And rather than facilitating “spoliation and obfuscation of evidence”, the EMR audit trail has shown up whatever tampering was involved. If UPMC simply had a paper based system, think about how much easier it would be to create paper records on official stationery, without date/time stamps I may add, post-facto.

EMRs can also be designed to meet certain additional needs – for example, a lock-down feature that locks down patient records from editing once a patient is flagged as deceased. There is no real counterpart for such a feature in the paper records world. Other lessons learned: If you’re springing for an EMR, it makes sense to know what metadata is being logged, and how you can access them – a pickle Dr. Simmons would have clearly avoided had he been IT savvy enough.

But a word to the wise: even an audit trail isn’t fool-proof. And if you’re in the market for an EMR, here’s a key difference between a “free” EMR somewhere on the cloud, or a pricier product on your own servers, administered by a savvy IT administrator on your payroll. Who administers the data makes a huge difference – if you own the database and your IT administrator has access to the database itself, you *can* manipulate any audit records generated from the EMR front end. Conversely, you must research what your vendor administered EMR is doing with your data, and what checks the vendor has on its IT staff.

Read more about the Sweet case on the Health Care Renewal blog.