Sure, Cupid has a fancy bow and arrow.
But playing matchmaker — romantic or otherwise — of the gods and mortals would be a whole lot easier if Cupid were working with the brains behind DispatchHealth’s logistics platform rewrite.
The healthtech company allows people to request on-demand medical care sent directly to their home via its supply of physicians, matching patients with providers. And soon, creating that perfect match is about to be that much simpler.
“We want to provide the best service at the right time and in the most optimal way,” Mike Lockwitz, engineering manager, said. “From a patient’s point of view, the optimal way would take their availability, location and how sick they are into consideration. From a provider’s point of view, it would account for their schedule, proximity to patient and accreditation.
In short, this logistics platform rewrite is going to solve for both to enable the most optimal match.
This challenging and important rewrite, which has been in development since the end of 2021, has required a collaborative effort between multiple departments. Once it’s released at the end of the summer, it will make a big impact on healthcare providers’ daily workflow and make healthcare more accessible overall.
What goes into a project of this magnitude, and what is it like in the weeks and months leading up to a big release? Built In Colorado sat down with a product manager, product analyst and engineer — the Cupids of DispatchHealth — to find out.
Why is this rewrite currently necessary, as opposed to when DispatchHealth started, or five years from now?
Kayla Bose, product manager: With every rewrite, you obviously have a product that’s already in place, and then a product that’s replacing it. When DispatchHealth initially started, we mainly serviced acute care patients — think care that happens in your home in replacement of going to the ER. But as we’ve grown, we have gained the ability to do advanced care, or continuation of care in lieu of hospitalization. For example, we now have people who can go into your home to do lab work or blood dialysis. Because our services are evolving, our engine has to, too. We are always thinking about who can deliver care and asking how they should deliver that care. We’re at a time where we’re ready to evolve, which is great. This rewrite is part of that evolution.
Mike Lockwitz, engineering manager: Simply put, our product and services have evolved to a stage where we could solve some challenges with this rewrite. By using constrained optimization, we are shooting for the best we can with this logistics platform rewrite. Instead of just matching the first available provider with the first available patient, it will allow us to achieve optimization across more goals. For example, we want to make sure that when we send a provider to a pediatric patient, that the provider has the correct licenses. Our rewrite can also spread out the patient load evenly across all of our available providers, so that no provider is overworked. It’s all about supply and demand and finding a perfect match.
Katie Ernst, product analyst: Currently, a lot of the problems we’re trying to solve are being done manually by people, such as making sure providers don’t have too high of a workload and aren’t getting home too late. That is currently being looked at by actual humans. This rewrite is going to make it much more automated and scalable as we continue to grow our business and our service lines.
What has been your role on this product release?
Bose: As the product manager, I play two major roles. One is coordinator. We have folks within our tech organization and other product managers who own other product suites who are reliant on the logistics engine. My major role is creating alignment within those orgs and clearly communicating throughout the entire buildout. My second major role is stakeholder management. Our clinical operators, our medics and folks running different service lines are all impacted by changes in user flow. With them, my job is to manage expectations for the scope of work. I coordinate between those two groups of stakeholders.
Ernst: As a product analyst, I’m responsible for establishing the metrics that we care about, how they relate to our product, and then making them digestible. The whole business needs to understand these metrics — not just the logistics team. Once we have the infrastructure and reporting for those metrics, it’s about evaluating areas of opportunity, using the data to prioritize different product features, and figuring out where we’re going to get the most bang for our buck based on the data. Once we launch, my key responsibilities will shift to experimenting and evaluating the performance of the rewrite.
Lockwitz: As the engineering manager, my responsibilities are around team health, team happiness and team productivity. It’s my job to make sure we have the right people with the right skills working on the right things at the right time. I work really closely with Kayla to understand what problems need to be solved, and then make sure we have the people who can get that work done.
What have been some of the unexpected challenges across the board?
Lockwitz: It’s been a very interesting technical challenge. The engineering needs to be robust and scalable. But it also has to be accurate and something that works well for the business, and something that we can implement in a way that serves the business. The challenge is building an internal service that can be consumed by other teams internally. Because the logistics engine isn’t something that an end-user interacts with directly; it’s going to be a tool that another team at DispatchHealth owns and uses. The logistics customers are our other teams. So we have to coordinate the implementation across many teams, and make sure that what we’re building is going to be a value to how they’re thinking of their products and their users. That’s been a fun and tricky challenge.
Ernst: My biggest challenge has been defining the right metrics. Our marketplace is complex; it’s not just a supply and demand problem. We also have service lines and acuity credentialing that need to be taken into account. My early focus has been to make sure we’re crafting the proper metrics to know how successful we’re matching patients to providers, and where there are potential mismatches. The more efficient we can operate, the more patients we can provide quality care to. The suite of metrics has been socialized across the business so that we’re all speaking the same language. It helps us stay on the same page as we talk about the goals of this rollout and interpreting results.
Bose: We’re trying to solve an interesting and complex problem. This is a rewrite. We already have a tool within our product suite that supports matching patients and providers. That touches every side of our business. During this rewrite, we’re now tasked with taking away some of those touchpoints, and either improving them or removing them completely. We’ve been tasked with some pretty big decisions. What is necessary? What’s the workflow that this product is supporting? How does it work? How should it work? How should we change it? These complex and interesting challenges don’t feel so insular. Because it affects the whole company. Thus, it feels empowering that we’re going to help solve problems for how we onboard patients, how our partners should think about that, and how our providers execute care. It’s a big deal.
CULTURE FIT
What is it like at the company in the weeks and months leading up to a big release like this?
Lockwitz: It’s all about prepping. From a technical perspective, getting the logistics engine up and running is the first milestone. Then we want to start putting a split in the road, so that all the information that’s coming in will go to the old logistics system and the new logistics system at the same time. We can run them both and start comparing the two and see how the new one is working. Then, we can make adjustments. Once we think the new one is ready to turn on, we’ll test it out in a small market. Only some users will be interacting with the new logistics platform. And then we’ll just iterate again, make sure it’s working properly, fix any problems that arise and then finally, transfer all of our users to the new system. It’s an incremental process that builds confidence that what we’re doing is working as expected.
Ernst: The first priority is getting strong alignment with all of the stakeholders and then having a strong team working on the right problems, adjusting challenges as needed, being nimble and building that quality product. Beyond that, we need to ensure we have a strong communication plan, training plan and overall rollout plan. We need to make sure that we don’t break anything when we roll it out and that the transition is as seamless as possible. We’re doing a smaller rollout initially in one or two markets to ensure that everything behaves like we want it to. Once we go to our full rollout, we’ll start measuring the success through experimentation.
Bose: Training and communication is huge, because we are reteaching users how to do a job that they’ve been doing. Training and alignment is coordinated across multiple product managers, because user interface and different components for the end users have been altered by those teams. That means a strong change management plan is going to be important for us to remain communicative and empathetic to our end-users.
What has collaboration looked like on this project?
Lockwitz: We’re a remote-first engineering organization. So a lot of what we do within collaboration is asynchronous. To do this, we rely on tools that provide transparency and ease of communication. We use Atlassian, and are always video chatting. We do our code review via GitHub. Async work comes with its own challenges. But it’s enabled us to get a high level of confidence that what we’re doing and when we’re doing things is something that’s agreed upon, and that it’s the best decision for everybody involved. Everyone has a chance to participate. It’s not like, “Oh you weren’t there, and didn’t get to hear that part of the conversation.” Everything we do is transparent, and we want to encourage as much participation as possible.
Bose: I think collaboration for our hub is a lot about learning from each other. We spend a lot of time on calls understanding each other’s workflows and work streams within this project, and being advocates not only for our work, but other departments as well. For example, Katie’s expertise in data analytics and coordinating a rollout plan to set us up for experimentation has helped us collaborate more effectively. Overall, there’s a lot of visibility into our work and how we communicate, from video chatting to comments on tickets.
Ernst: There’s also collaboration outside of our insular group. We have to coordinate with other business areas to not only get stakeholder approval, but also to better understand how other people do their jobs, and how this platform rewrite is going to impact them. To achieve success on this team you must be able to bring together all of the business areas, and not just stay within tech.
