As clinicians, we always want what’s best for our patients and to make our work more efficient and less frustrating. In the digital age, we’re used to using all sorts of mobile applications and software to improve our productivity, and one may expect it to be just as easy to implement a new app to help with our clinical care. I definitely thought this way.
I was so very wrong.
Not understanding the structures and barriers on the organization (hospital) side made my attempts to implement digital change very frustrating and ultimately not particularly fruitful. It wasn’t until I became a quality improvement leader in my own department, a founder of a healthcare startup, and helped other providers in different organizations go through their own change management processes, that I truly got a sense of the process.
The purpose of this series of articles is to provide a bit of a primer for well-meaning clinicians (such as yourself) in the road from idea to implementation for digital healthcare solutions. It’s meant to introduce you to the administrative and logistic things you may not have realized, and to arm you with the right tools and information so when you finally sit down with your stakeholders and decision makers, you won’t be as woefully unprepared as I was the first time around.
What problem are you actually trying to solve? While you may feel the pain on a daily basis, anecdotal evidence is not enough to sway the people holding the authority and (more importantly) the purse strings. Find a way to quantify the issue and build a compelling case that the change that you are trying to make will directly impact the outcome you wish to achieve, and frame it in such a way so that the person you’re talking to cares, not just you. Sometimes those values line up perfectly, and sometimes it doesn’t. Make sure you speak their language and hit their pain points.
The temptation is to heap on potential solutions before truly understanding the problem. Take the time to dig deeper into the root causes, draw out the process map of all the inputs that lead to the desired outcome. It might be fruitful at this stage to do a pre and post of the workflow through a process map to ensure your proposed change can actually solve the problem.
The process map will also show you all the different players in the process, and each of those will need to be engaged. Don’t expect to make wholesale changes to another person’s workflow without talking to them first (unless you want a very quick way to make enemies). They may have other ideas or perspectives you haven’t thought of in your original process map and plan. Identify your champions and your detractors. Empower and entice your champions, make them as passionate and knowledgeable about the problem as you are. Try to understand and address the concerns of your detractors. While you may never be able to convert them to champions, at least come to a point where they won’t (or can’t) actively try to undermine your project.
Once you have a good grasp of all the factors and people that contribute to and are affected by the issue, you must make the case that this project or change is worth the hassle (the value proposition). That goes back to quantifying it to a metric or outcome that others care about. Can I make the case that it improves patient safety and satisfaction? Does it reduce the length of stay, therefore improving department flow? Can I save costs by eliminating waste or errors? Can I increase revenue because of this improved process? Proving the case and putting numbers together may be difficult, but it is an essential step.
Once you have a quantifiable and coherent value proposition, it’s time to pitch your proposed solution to the stakeholders you’ve engaged (and ones you have yet to discover). Convince yourself and decision makers that what you want to do is feasible with the resources you have available, and that the fix and the effort to implement the fix isn’t worse than the problem. As clinicians we think in terms of risk/benefits for patient care all the time, so apply that same thinking to this problem. What are the risks and benefits of bringing this new solution on? What are the risks and benefits of doing nothing? Ensure that your solution can improve as many of the pain points as possible, and that the potential downsides and cost have been considered and mitigated.
A common issue I face in emergency medicine is that specialists may take a while to respond to pages and consultation requests. While I sit and stare at the phone for minutes (hours?) waiting for that call back, it’s easy to blame the things I know and get exposed to (Fixed lines are stupid! Pagers are dumb! Switchboards are error prone!).
Now before I go running into my chief’s office and vow to destroy all the pagers in the hospital and replace it with Hypercare (an on-call and messaging solution for healthcare), I must go through the process of building the case of why they should care, and why my potential solution will make a difference. How big of a problem is it actually? Who is affected? What are all the steps and factors that can possibly influence the pain point I want to solve (time from me deciding the patient needs a specialists’ assessment to the specialist contacting me with advice and a plan)? Where does Hypercare fit into this mess?
Do any of my non-emergency colleagues feel the same pain, in the same way? I want to engage as many other departments/specialties/disciplines as I can to get their thoughts and perceptions of the problem I am trying to solve. I say this with a caveat - you want to be careful about how big of a scale you want a project to be. While it may be nice to get everyone onto Hypercare tomorrow, the bigger the project, the bigger the risk, and slower it will progress.
Finally, I have to make a compelling argument to explain why anyone should bother with this issue at all. Literature has shown that long emergency department stays are not good for patient satisfaction or outcomes. Increased lengths of stay lead to bed blocking, which leads to longer wait times and decreased flow. Decreased flow leads to less revenue generated (not to mention a bad reputation for your department, which further leads patients to avoid your department). Constant bed block causes provider frustration and burnout, which affects other providers and patients.
Let’s say you’ve drawn a beautiful process map, engaged all the relevant stakeholders, and built an air-tight value proposition. Everyone on the clinical/operational side agrees with your every word. They think this tech solution should’ve been implemented decades ago!
Time to move onto the due diligence part (which is really an extension of the above process of understanding the problem, stakeholder engagement, and value proposition steps above). This stage often frustrates front line providers because we don’t necessarily think about the same things they do, and conflicts arise. Fear not, there are things you can do to ease the process.
Stay tuned for part 2 of this series that goes through the nitty-gritty of how to speak the language of stakeholders from privacy, security, finance, and other corporate departments that is required to get the project off the ground.