Thomas Eric Duncan, the Ebola patient released from Texas Health Presbyterian Hospital, died this morning at 7:51 a.m. The hospital first blamed a flaw in EHR workflow, but then retracted that claim the next day. Social media has been fractious. Basically, whether you like EHRs, as currently designed and implemented (“See, I told you so!”), or dislike EHRs, as currently designed and implemented (“Statement retracted, no flaw, case closed.”), predicted most reactions.
"so much wrong w/this picture" workflow flaw retraction sets dangerous precedent http://t.co/zPDxLf0Gb1 pic.twitter.com/2mSp04HxWq
— Charles Webster MD ()
Unfortunately, I fear, we well never know for sure, the answer to the question, “”What did the EHR users know and when did they know it?” Barring some enforced Epic EHR contractual gag clause, accounts will be forthcoming. But, given the variety of strong biases many stockholders bring to the subject of EHRs and EHR workflow (and I am one of them), it seems unlikely that all will be satisfied. There are too plausible reasons why hospitals, EHR vendors, nurses, and physicians might be reluctant to potentially admit culpability.
We need an evidence-based workflow account of the complete who-what-why-where-when-and-hows sequence of EHR-mediated user activity that may, or may not, have contributed to Mr. Duncan’s release. The problem is, even if a blue-ribbon panel of experts, akin to the Rogers Commission that investigated the Challenger explosion, takes up the matter, current EHRs, of which Epic is emblematic, don’t represent workflow in a way that allows us to make the necessary inferences to explain what when wrong and who or what is to blame.
What do I mean by “represent workflow”? What I mean is, just as current EHRs represent data about patients and drugs and procedures and such, EHRs need to explicitly represent sequences of tasks (data gathering, order entering), the resources consumed (time, money, user attention), and, most important of all, the goals the tasks are intended to together accomplish. Why is representing goals so important? Because goals go to intent. Why was the nurse or physician trying to do when they clicked that button or spoke that command?
THR blames release on .
Then flawless.
Docs? Nurses?
Cheesy workflow? ←
http://t.co/JPovIVhUpp pic.twitter.com/SzrApcDJ4o
— Charles Webster MD ()
What I have just described — the explicit representation of tasks, resources, and goals — is how workflow management system work. True workflow systems, sometimes also known as business process management or dynamic and adaptive case management systems, execute or consult models of work and workflow to automatically do for users what would normally require users to do for themselves. Since these models are easier for clinical users to understand than computer code (Java, C#, Mumps, etc.) it’s easier for users to tell analysts how to design their preferred workflows. Sometimes precocious users even start tweaking workflows themselves. It makes them happier, to make workflow fit their work than make their work fit programmers workflow.
But here’s the important thing, EHR workflow systems leave a detailed, time-stamped trail of who-what-why-where-when-and-how users interacted with the EHR workflow systems. Right now, this kind of data is either absent, locked up in opaque event logs, or misleading, even if one were to be able to extract it. The very best event logs are generated by workflow management and business process management systems.
Even more important than open source and open data, is open and transparent workflow. I call this kind of EHR workflow “figureoutable” and “buildonable.” Mere mortals, who are not programmers, can figure it out and leverage it in ways that the original programmers might not have specifically imagined. These mere mortals include investigators trying to piece together what went wrong.
. TX: open workflow is both "figureoutable" & "buildonable"
— Charles Webster MD ()
I’ve written several other blog posts about how process-aware EHR and public health IT systems might have operated to prevent Mr. Duncan’s release (see below). But even if even they will have failed us, they’d at least leave a trail of time-stamped workflow context from which to reconstruct past workflow and improve future workflow. So they won’t fail us the next time.
We, as a nation of patients, providers, payers, policy wonks, and politicians need more evidence-based workflow data, to create more effective, efficient, and safer workflows. We need the kind of open and transparent workflow that will only result from what academics call process-aware information systems.
- Ebola, APIs & Workflow: We Need A More Process-Aware Health IT Ecosystem
- If I Could Change One Thing About EHRs That Might Have Prevented Release Of The Dallas Ebola Patient
- EHR Business Process Management: From Process Mining to Process Improvement to Process Usability (EHR Event Log Maturity portion, but read it all!)
If you’d like a well-received short course on workflow technology in healthcare, I can’t do any better than suggest my own five-part series:
BPM-based Population Health Management & Care Coordination: Workflow, Usability, Safety & Interoperability Perspectives