I have shared pieces on two different aspects of building an excellent EHR experience for your physicians, Building for the Physician: Customization and Building for the Physician: Documentation and Ease of Access. This piece will be on the third aspect: iteration. This is rather simple compared to the other two. The overall idea, iterating on what has been built based on feedback and new requirements, needs little explanation. However, while it is the most straightforward part to explain, it is also the easiest to ignore. It will be impossible to get everything from the prior steps right in one shot. Iterating well is the piece that can bring everything together and is the ultimate path to excellent EHR implementation over time.
While iteration itself is fairly easy to talk about in an overarching way, I wanted to examine parts of that iteration process that, when concretely considered, offer a good target for systems to be built to optimize the iteration process itself.
The pieces of the framework that I’ll work within are: lack of stagnation, balancing decided-on improvement versus putting out fires, and communication, wrapping up with the emergent benefit of being able to work on the right problems once organizing, deliberate systems are in place. None of this is to say that you will ever be finished. Iteration also teaches that it is forever. Systems either take in feedback and continue to improve, or they eventually collapse, too brittle to go on.
Swift and Moving, Not Stagnant
A system that enables updates and fixes to occur swiftly is an important start. Swift in this case does not necessarily mean immediate, and what swift means in each case is dependent on the context of the problem, change, or build. I consider it a relative swiftness. A fix may take months, but that is an improvement over the year it took prior to the development of a better system. The focus here is movement. What you are avoiding is stagnation. Inflow of ideas and feedback will be the lifeblood of improvement and iteration; stagnation degrades this inflow. Keep a trained eye on what is going out and keep the system prepped to keep moving. Like a river, some of this will move quick as rapids, others will meander along, but consistent movement forward is the key. A system that allows relative swiftness will be one that is nimble, allowing you to change course as needed, scrap the old as necessary, and build something completely new as the current environment calls for it. Do not let a stagnant task become invisible, simply not moving because you avert your eyes. Make deliberate, ongoing decisions. Either work on something or deliberately decide not to, but continue to move things forward, lest your system become a brackish swamp. Deliberately removing the detritus while propelling the rest forward keeps fresh ideas flowing in and through.
Focus, Not Fires
Having a system that supports relative swiftness and nimbleness feeds nicely into the next important part of iteration, which is actually deciding what to work on rather than only being able to respond to fires. Keeping things moving, allowing feedback to flow in, leads to constantly improving understanding of the situation on the ground regarding use of your EHR, allowing strategic decisions to be made about what to work on while anticipating potential problems. This helps avoid some fires altogether, leading to intentional improvement rather than simply having to fix the loudest and most broken. The former means living within the proverbial important not urgent rather than remaining stuck in the urgent and important. Working on the important not urgent is what moves things forward. These are the significant improvements, the good ideas, the deep understanding that leads to insights regarding what the health system needs, allowing you to provide those things proactively. The urgent and important are what keep things from burning to the ground, but that is mostly where the benefits end. As their names imply, both are important, but the nuance is what they fundamentally allow. The balance is crucial. You will, of course, have fires that need putting out, but if the balance is heavy in that direction, the true innovation and improvement cannot occur. All you are doing is keeping the system running, but it is running in place, never truly going anywhere, and your people are still getting burned.
Communication
As mentioned, you will rarely one-shot the perfect tool or update. Needing to iterate is not a fault. Operating with this as a given means you build your systems correctly, anticipating this need, and designing things to handle this fact well. You know this, but your users are unlikely to have considered it. All they see is the gap between what they need/want and what is present. Part of handling iteration well is a system of communication. Your job is to consider how and where you communicate. Is your communication hidden behind 95 clicks within a confusing labyrinth of a SharePoint site that is only used by your team? Is it buried within a 30-point update email about the health system in its entirety? Clarity and simplicity are the key to communicating well. Much like high-quality documentation of your tools, consider a central, easily accessible spot for your communications. Organize said communications by breadth of utility and set it up in a way that allows for progressively disclosing more information, starting with the simplest, most focused representation of the information, allowing for more complex information to be disclosed as desired. Not to beat a dead horse from the prior pieces, but your EHR champion is a great leverage point for communication as well as for deciding placement of focused communication.
Externally revealing projected completion dates is likely a bad idea. This introduces rigidity. It should be expected that the ground will shift under you and things will be moved, take longer than anticipated, or reveal further complexity. Instead, let this communication system as well as the one you built for swiftness stand on their own. If you communicate well and consistently move things forward swiftly, a natural trust will develop between you and your users, even if extended time is needed. While concretely setting completion dates is not ideal, communicating complexities, problems, and new considerations (progressively disclosed so as not to overburden the user on first glance) will likely be helpful for those users who are invested in any particular update, fix, or change. Additionally, forcing your team to concretely consider and document these complexities leads to further clarity that is beneficial to the team itself.
A system built for clear communication, organized by breadth of utility, with the ability to progressively disclose more information to invested users will improve your users’ perception of their EHR experience and the team behind it, leading to more positive engagement and supporting the ever-important inflow of feedback.
Emergent Properties
Well-designed systems encompassing the above will lead to emergent properties for your health system and team. These systems work together, allowing for the development of a vision as a whole. This coherence leads to an overall feeling of ease of flow. There is nothing more draining than an unorganized pile of things on fire and lack of systems leading to each individual team member needing to retread the same ground to figure things out, feeling harried the entire time. This is burnout-inducing for your team and dissatisfying for your users.
The feeling of overall organization, with systems to lean on and leverage, even and especially when things do go awry, lends itself to feeling in control with the ability to change course as needed. You have the luxury of deliberate choices on what to work on, crafting rather than simply responding. This leads to a positive view of your work by your on-the-ground-physicians, which then builds up a base of engaged users. This will help provide valuable feedback, which can flow into your system, cascading down each part we have touched on, feeding everything in a virtuous cycle with ongoing improvement and excellent builds coming out the other end.
It would be a great feeling to be the health system where physicians tell those outside the system that they have never worked anywhere they actually enjoy using the EHR, that it supports them, feedback is listened to, and improvements occur on an ongoing basis. While this would be great, it is itself not the end goal, only part of it. I believe the well-built EHR as a foundation feeds a myriad of other important improvements and positive growth of the health system as a whole, connecting and improving things beyond the EHR itself. The goal is to design it as if designing an elegant tool rather than simply a required aspect that quickly becomes just a burden.
Thoughts miss the mark? Building something interesting? As always please reach out. These are my ideas from an on-the-ground perspective.