Over the past few editions we’ve covered the various stages and numerous steps of selecting a new video visit vendor. This is the fifth and final article in our series on Vendor Selection.
We started by setting the stage with “Defining Needs and Requirements” and then expanded with more information on “Gathering the Requirements”. Next, we covered the second phase of taking all of that information to “Select a New Vendor”.
Finally, a couple of weeks ago we covered the first four steps of the third stage of vendor selection: “Effective Implementation”:
1. Engage the Vendor
2. Study Vendor Features and Functionality
3. Define/Revise Workflows
4. Develop Training for Clinicians, Nurses, Schedulers; Patients
5. Prepare for a Proof-of-Concept
6. Conduct Proof-of-concept and refine workflows, training
7. Manage transition to new vendor/workflows across the org
In today’s article, we’ll talk about the last three steps: preparing for and conducting a proof of concept and then rolling out the solution across your whole team.
Validating Assumptions
There are many ways of deploying a new health IT solution, and most of them are fraught with big problems and frustration. In some cases, such as the switchover to a new EHR system, the “overnight big bang” approach is the only feasible way.
In the case of switching to a new video visit vendor, we have the choice to start small before we “go big”.
But I’m not talking about a “pilot”. Many organizations are running “pilots” without defined success criteria. “Let’s try this out with a few people and see what they think and what we can learn” is an all too common approach to implementing any kind of technology.
A much better approach is that of a “proof of concept”: To launch with the intent to validate (“to proof”) the assumptions we’ve been making (“the concept”).
Thus, the purpose of a proof of concept is to validate assumptions and to refine all the aspects of the solution: from the configuration and customization of the vendor solution to the revision of workflows and optimization of the training for maximum efficacy.
Designing and planning for a proof of concept comprises three steps:
(a) Identify and prioritize assumptions to validate;
(b) develop metrics to validate assumptions
(c) define measurement collection & analysis systems.
Here are some common assumptions when it comes to video visit solutions:
- Overall Clinician Satisfaction is high
- Overall Patient Satisfaction is high
- Specific Usability – starting, conducting, ending — is good
- Technical Quality is sound
- Ability to Engage the Patient is good
- Utilization of the new video solution is higher than the old
- etc.
(a) To systematically develop assumptions, you can actually use all the outcomes of the first stage: all the needs, requirements, and specifications are implicit assumptions of what the solution should be capable of doing, once deployed.
(b) Once you’ve identified all assumptions and whittled them down to the vital few (could be a dozen or more), you can then define the metrics to validate each assumption. E.g., most of the assumptions listed above would be measured on a 5-point Likert scale. Other assumptions’ metrics are based on targets or comparison (like utilization).
(c) Next, for each metric, define how, by whom, and how often the metric will be collected and analyzed. E.g., satisfaction for clinicians can be assessed for a day, once a week, on a piece of paper. Satisfaction for patients could be assessed after each visit, with the clinician asking the patient for participation and honest feedback to help make the service better.
Armed with assumptions, metrics, and a metrics collection system you are now ready to launch the proof-of-concept.
Refining and Improving
In today’s complex world it is foolish to believe you could anticipate all possible obstacles, so it’s a fair assumption that the workflows and training you developed has room for improvement.
In addition to building confidence in the numerous assumptions made throughout the process, the key benefit of a proof of concept is to have an opportunity to quickly made changes and updates to the various updates of the solution, namely (1) the configuration of the solution, (2) the various workflows, and (3) the training provided to clinicians, staff, and patients to familiarize them with the solution and the workflows.
While some updates are blatantly obvious, some may come from the analysis of the metrics that is being collected to validate the assumptions. E.g., if the acceptance by clinicians is low (in other words, if the clinicians don’t like using the new solution), we need to probe deeper to identify the root causes of that resistance. Was the training not sufficient? Is an aspect of the user experience cumbersome? Did we miss a step in the process?
Given the usually low number of users involved in a proof of concept, it is typically very easy to make some improvements or refinements to the overall solution (technology, workflow, training) and roll out those changes right away.
A proof of concept is typically completed when all or most of the assumptions were validated to everyone’s satisfaction, which could be days, weeks, or months, depending on how long it will take to “dial in” the solution.
Going wide and deep
After the proof-of-concept phase it is finally time to start the system-wide rollout of the new video visit vendor solution.
To plan that rollout, carefully consider the variety of lessons learned during the proof of concept. Typically the participants chosen for a proof of concept are the more easy going, early adopter, trailblazer kind of people.
Now that you are going beyond those early adopters, it is much more important to really think about the rollout from a change management perspective:
What type of change resistance are you likely to run into and how will you overcome it?
Where would you anticipate hesitancy or frustration occurring and how can you prevent that?
Where are people most likely to go back to the old ways and how would you prevent that?
One aspect that I did not emphasize much is that beyond the technology configuration, workflow design, and training, the ongoing success of the rollout will also hinge on having easy access to qualified support to assist with troubleshooting or problem solving, especially during the first days and weeks of use.
Systematically selecting & deploying a new Video Visit Vendor
This wraps up our 5-part series on the three stages of vendor selection.
A. Identify the needs and define the requirements
B. Evaluate and select a vendor
C. Switch over to the new vendor
You can read all five articles (and a few additional articles) on the Resources section of our website.
What are your best practices in change management to roll out new health IT solutions? I’d love it if you reach out to share those insights with me.
To receive articles like these in your Inbox every week, you can subscribe to Christian’s Telehealth Tuesday Newsletter.
Christian Milaster and his team optimize Telehealth Services for health systems and physician practices. Christian is the Founder and President of Ingenium Digital Health Advisors where he and his expert consortium partner with healthcare leaders to enable the delivery of extraordinary care.
Contact Christian by phone or text at 657-464-3648, via email, or video chat.
