So the consensus amongst the experts we talked to was this: Digital health companies will make build or buy decisions based on their reimbursement model. This post is really intended to be more of an open source project than anything else, so please let us know what we’re missing and we’ll do an update in a few months. So with that preamble behind us, let’s talk through the layers of a typical digital health company’s tech stack. Also, I’m sure I have some gaps here so please reach out if you’ve got an addition or edit to make! Frankly, it’s hard to generalize with this stuff as companies will have very different needs depending on their care model, patient population, and so on. This post features a cross-section of perspectives, some of which you may agree with and others you may not. As we’re seeing time and time again, digital health is selling into digital health and becoming unicorns in the process. But the positive here is that it may be enough, at least for a while, to sell into other startups. The big question on everyone’s minds here is around the Total Addressable Market or TAM. What remains to be seen is whether these tools that are custom built for digital health can migrate over to the enterprise. the “building blocks,” that makes all of that happen in a more efficient and more scalable way. We’re doing that because funds we respect like a16z and Greycroft are betting big that the future of digital health isn’t just the care experiences. And we’ve asked founders as well as product /operations leaders how they’re making all important build vs. To help guide that process, my colleague Marissa Schlueter and I have spent the past few months going deep on the tech stack companies. That’ll bring you to your tech stack, ranging from your EHR to your API for ordering lab tests. If you’re providing care to patients as part of the experience, you’ll have a lot of decisions ahead of you about where to invest vital development resources. So you’re starting a digital health company.
0 Comments
Leave a Reply. |