You may already be familiar with hospital management engineers. Industrial engineering is sometimes called management or health systems engineering (“Cheaper by the Dozen” is based on the lives of the first industrial engineers to study medical workflow. Read myy EHR riff on CbtD!).
An EMR designed and implemented using industrial engineering principles and techniques is a fundamentally different EMR that the traditional EMR. Instead of starting with a user interface that looks like a paper form, the user interface is essentially derived, using scientific and engineering principles, from the human body’s response to physical, physiological, and cognitive workload. Perception, attention, cognition, motor control, memory storage and retrieval all interact with work environment and job demands to result in a body of knowledge about mental workload, vigilance, decision making, skilled performance, human error, human-computer interaction, and training. (This is not dissimilar to the way in which medical knowledge is derived using scientific methods from the structure and function of the human body.)
The resulting EMR should not necessarily look like what has gone before. (In fact, the first use of computer displays in aircraft cockpits mimicked physical dials and switches. Today’s “glass cockpits” do not.) Many EMR designers are seduced by the idea that since users are already familiar with paper forms that the paper form metaphor is a good user interface. It is not. EMRs that try to mimic traditional paper medical records are not well designed for high-usability, high-productivity data and order entry.
Hi Chuck,
Your blog provides some great insights!
I was directed your way by Dirk Stanley off the AMDIS listserv. I’m a hospitalist and I’ve created a shared mobile rounding list with two co-founders. Currently we’re focused on centering the project management aspect of clinical care around the patient rounding list. I was curious if you had some time for a phone call in the coming weeks to get your feedback on our product.
regards,
Trevor
Hi Trevor,
Just had a great call with you and your team at ListRunner (). There’s a wonderful potential fit between clinical list sharing apps within hospitals and the need for more healthcare task transparency between healthcare organizations. I don’t just want to know when my patient has been admitted or discharged; I want to know what’s going on behind hospital walls! I’d love to see task interoperability APIs become a thing. If healthcare workflows are to become more usable, interoperable, safe, satisfying, and productive, workflow engines (perhaps in the cloud) need access to task state, context, and other properties, across healthcare organizational boundaries. I’ve suggested an extension to FHIR () and perhaps that is a route forward. But I’d hate for task (and by extension, workflow) interoperability get tangled up in the kind of analysis paralysis that plagues so many health IT standard initiatives. I’d rather see a grass roots effort, as in, I’ll show you my task and workflow state if you’ll show me your task and workflow state. If this is done in a win-win way, so we both create value for each other, we potentially have the beginning of a virtuous cycle that might eventually get us all the way to healthcare workflow interoperability (ie, transparent task events in one organization automatically triggering task events in another organization….. which events? That’s for the workflow definitions created and edited by users to decide).
Anyway, wonderful speaking to you et al. You’ve got a great app. It sprang organically from your needs as a hospitalist. You’re pulling important task data from a variety of systems. I’d love to see you expose and share that data with other specialists in other healthcare organizations, and, in exchange, obtain valuable task data back.
Oh, here are some thinking-out-loud tweets our conversation (and a strong morning coffee) provoked!