Care Model 101

The technology to power a care model involves a cacophony of users. The care team needs their own dedicated platform that allows them to “project manage,” as a team, all the conditions in the patients in their assigned population. The patients need a simple mobile or desktop app to help them communicate with their care team and “project manage” their own conditions. The clinical operations team needs their own suite of tools to help optimize the day to day of the care model. And, sometimes, clients (like employers) even need their own tools to manage their population and view a defined set of metrics that proves the value of the care model.

Needless to say, things can get overwhelmingly complicated quite fast. So knowing what to build, for which users, and when, is something that can make or break the financial viability of a care model. And, by far, getting a care model out there in the wild, learning from real world data, and earning revenue is mission #1.

But knowing what to build vs what to buy is a massive undertaking that requires you to have a long-term strategic vision for the IP you’re building as a business. Is your IP simply aggregating patients together using off the shelf technology? Or is it building a custom platform so you can markedly increase the number of patients one provider can manage? Will an off the shelf EMR suffice? Or is an EMR designed to power scheduled oral conversations in exam rooms too limited in its foundational architecture to power a care model born for today’s online communication and processes?

Example questions we will consider are:

• What do we build as our own IP vs what can we use off the shelf?
• What elements of an EMR are mission critical to our model?
• Do we work with a new “headless EMR,” an established EMR, or do we simply build a suite of integrations that duplicate the small sliver of features we need from an EMR to avoid having to use an EMR not designed for cutting-edge care models?
• How do we standardize the building blocks of our platform?
• How do we create a standardised process to build features in a consistent, dependable way?
• What is the organizational structure of our technical team?
• What tools do we use to design and development?
• How do we measure the technical team’s performance?
• How do we communicate our roadmap with stakeholders?
• How do we ensure features are tested before released?
• How do we document our platform?
• How do we know if features are performing properly?