Over-engineering EHR Workflows
Recently, I was presented with an interesting dilemma. The IT team had identified a potential problem whereby confusing and potentially contradictory physician orders could lead to what we in the business call a “misadventure.” Now mind you, no misadventure had occurred, but our Spidey senses were appropriately telling us to do something.
The hospital system uses one of those big, fancy electronic health records (EHRs) so we have a lot of programmatic firepower at our disposal from the build side. The current state for the workflow that we are trying to improve involves one-off physician orders based on lab tests that haven’t yet been resulted. Essentially, if this lab result is > x, then do this thing if the patient has an IV, but do that other thing if the patient doesn’t have an IV. Oh, and if the patient has an IV, if it’s a big line with central access, it’s ok to do it this way, but otherwise, do it the other way. You can imagine how this might be confusing.
The proposed fix was pretty sweet! (NB: If you use the term “pretty sweet” with respect to EHR configuration, you might have a geek problem. See a CMIO or CHIO as soon as possible for diagnosis and treatment.) The IT analyst did a great job in actually analyzing the problem, determining possible solutions, and proposing the solution she thought was best. I was impressed. Yet . . .
This was a complicated solution. It required a bunch of workflow steps be performed by different people in different roles. For it to work, everyone needed to do their jobs in the way we expected and in the order we expected. The good news is that almost always, people did do their jobs in the way and order that we expected. That’s not always the case, but with this workflow, it was!
On the build side, I asked how many records the analyst needed to create or modify in order to have this awesome workflow. I expected a big number, but when I heard 206, I was taken aback. That’s a lot of records. Of course, many of the records involve straightforward build, but you can imagine that this involves a great deal of effort. There are lots of plates in the air when you have that sort of configuration.
Is this proposed solution bad because it’s complicated? No. Will we likely implement this solution? Yes. That said, I believe the IT folks (including me) need to acknowledge ahead of time several things:
- If our users don’t do what we expect them to do (what they almost always do), some of our processes won’t work as expected.
- If an analyst in the future isn’t careful, it will be easy to break some of the workflows in potentially insidious ways.
How will we mitigate these risks? By using tried-and-true IT best practices. As best we’re able, we’ll build in redundant checks and give our users reminders and explanatory text outlining how these workflows function. We’ll do testing before major changes (unit testing, integration testing, and system testing). We’ll involve clinician end-users to ensure the workflows are stable and achieving the goals we’ve set out.
Are these workflows really over-engineered? Probably not. They’re appropriately-engineered. But with a lot of moving parts, we need to put in the maintenance work to ensure everything is properly oiled and working friction free.
Craig Joseph, MD, is the Chief Medical Officer at Avaap where he works with healthcare leaders to implement and optimize EHRs in order to increase physician satisfaction, improve efficiency, and ensure full value of the technology.