Speculation about EHR role in Texas Ebola debacle vs. real evidence - will it take a lawsuit to know what's real? Probably.

In the past several days the media has been abuzz with stories about the admission, then the following retraction, by a Texas hospital that and EMR "flaw" had caused a man who had been in West Africa and was infected with the Ebola virus to be sent home, instead of admitted and put into isolation.

I wrote about these matters at my Oct. 2, 2014 post "Did Electronic Medical Record-mediated problems contribute to or cause the current Dallas Ebola scare?" (http://hcrenewal.blogspot.com/2014/10/did-electronic-medical-record-mediated.html) and the followup October 4, 2014 post
"Dallas Hospital reverses EHR-related explanation for fumbling Ebola case" (http://hcrenewal.blogspot.com/2014/10/dallas-hospital-reverses-ehr-relarted.htm).

A spectrum of the healthcare IT ecosystem seems represented (see http://cci.drexel.edu/faculty/ssilverstein/cases/?loc=cases&sloc=ecosystem).  The technology enthusiasts and hyper-enthusiasts seem to believe the computer could have done no wrong (and usually lack medical and Medical Informatics expertise).

Some people such as myself with specific Medical Informatics experience and who know the failure modes via AHRQ, FDA, ECRI Institute etc. believe the EHR was quite likely contributory or causative of the mistake (see my April 9, 2014 post "FDA on health IT risk:  "We don't know the magnitude of the risk, and what we do know is the tip of the iceberg, but health IT is of 'sufficiently low risk' that we don't need to regulate it" (http://hcrenewal.blogspot.com/2014/04/fda-on-health-it-risk-reckless-or.html).

The reason I have written little after my initial two posts is that the only was to resolve the controversy is to actually examine the EHR screens, screen navigation and behavior of the EHR, if possible both before and after the hospital's stated "fix" of the problem, the EHR audit trails (automatically generated EHR accounting logs of user accesses, action taken, time, location etc.) and to examine the EHR in actual operation to evaluate it in context with the clinical setting in which it was installed.

Barring that, everything else is speculation usually biased either by the speculator's own beliefs about either the beneficence or fallibility of information technology in healthcare, and perhaps IT generally, and/or conflicts of interest.

Unfortunately, considering the health IT industry and environment, the only way I believe such an examination of the EHR can come about is via litigation.  I doubt it will come from the traditional regulators of medical devices and healthcare safety.

I do note the following of interest at Politico:

... While all EHRs difficult to use, some are set up better than others.

At Mount Sinai Hospital in New York City, information that a patient was feverish and recently flew in from Liberia would have set off an alarm, with the nurse’s screen flashing yellow and giving instructions to immediately isolate the patient, said Jason Shapiro, an emergency room physician and informatics expert at the hospital.

The nurse entering “fever” into the record would “get a hard stop. They immediately have to enter a response to a travel history question. And if there’s fever and the right kind of travel history, the whole isolation mechanism is supposed to swing into play,” Shapiro said.

... Both Mount Sinai and Texas Health Presbyterian have health records systems they purchased for hundreds of millions of dollars from Epic.

Read more: http://www.politico.com/story/2014/10/ebola-texas-electronic-records-111598_Page2.html

At least some users of EPIC seem to have a system configured to catch such a problem.  In my mind, this speaks the need to industry regulation, to ensure all EHRs meet basic standards of safety and reliability and are not haphazardly designed or implemented from one hospital to the next.

-- SS

10/9/14 Addendum:  

Prof. Jon Patrick of Australia, cited numerous times on this blog, relates this:

"I always talk about data capture and data reuse and the reuse is defined by the data flows required in the design of the system. EPIC might well have allowed for the the data capture but failed to deal with the data flow to properly effect the required reuse."

As may the implementers at the hospital in question also have failed at the flows supporting appropriate and fail-safe reuse in a hectic ED environment.

He adds, for further clarification:

A footnote to this point. We separate data flow from work flow. Data flow is the movement of data from context to reuse in another context, or you collect data on this screen(first context) and then you see it later on another screen (=another context).

Workflow is the route staff team members take in moving from one context to another, that is the movement from using one screen to another screen. Most often triggered by clicking a button that moves you to the chosen screen(next context).

The two are very different things and require close thinking in both cases to not trip up with unhelpful and frustrating system solutions.

Historically, Information Systems development has dealt with these issues both poorly and without adequate separate planning. In the past the focus has been on the data capture and storage, because the notion of reuse and context shifting has been left behind. This has been OK for many business systems where contexts have only small variations and workflow are simple or unimportant.

In medicine that just isn’t the case.

-- SS