Care Modeling Part III: How to Choose Your Technology Partners

Note: This is the third installment of a three-part series. Check out Part I to review the introduction to this series and our discussion about the seven core elements of care modeling. Part II lays out four strategies for approaching buy vs. build decisions and for evaluating enabling software tools and partners.

‍

At this point you've thought deeply about your initial care model and how you might evolve it (see: Part I). You've thought about enabling technology and how you might fake it, retrofit it, gather it, or harness it (see: Part II). Making decisions is the tough part. Below are a few suggestions on how to think through the process. 

The most important thing to do is get your hands dirty. Try before you buy. Truly. There is no good reason in today's world why you shouldn't be able to poke around UIs, fire off some requests to APIs, or implement an SDK class or two. Nothing replaces direct experience with the system(s) you're betting your business on… before you make the bet.

Assess Workflow Controls and Automation Boundaries

Think of a workflow as a path through a care model, and workflow control as care model governance. Traditionally, workflow control has been accomplished with a combination of: 

• Customized settings and content in the EMR
• Documented standard operating procedures and clinical protocols 
• Workforce training on the above 

Step one is understanding what kind of content and settings can be customized in any enabling software system you're looking at. This can be pretty tough to sort out and it’s not easy to understand everything, but the more you've thought through your care model, the smarter the questions you'll be able to ask in areas that really matter to you.

The next level of control is looking for logical control, bona fide algorithmic control to support evidence-based clinical objectives and operational policies, often called clinical decision support. If you're looking at a system that advertises no-code or low-code functionality, how much logical control do you retain across clinical, operational, and financial domains? Can the layers be peeled back so that clinician-developer dyads can implement the nuanced logic that clinical excellence requires? Or maybe algorithmic capabilities aren’t needed and easy custom content is the right thing to focus on.

To the extent you envision automation as a key dimension of your care model now or in the future, system boundaries will be your grand challenge. Remember that from a technical perspective, consequential automation means writing data. Automating report generation and the like is valuable, but doesn't achieve the kinds of scalable productivity or care model control the best care delivery companies are realizing. For that, you would need writable API endpoints across the many different systems you gathered together. Often those endpoints just don't exist, which is ok, and many vendors will work with you on the roadmap. When that's the case, dig deep on vision alignment as discussed below.

Assess Duplicate State Risk

There's only one way around the Automation Boundary Problem: duplicate state in a separate system under your control. Assuming each of your component systems will allow you to export data from their domain (even some EMRs are now providing customers full copies of their databases…), you can attempt to build and maintain an aggregated data store that you've designed for purpose. Your team can then train statistical models and/or develop automations against this aggregate state.

It's not a horrifying idea if you expect to deal with only a small handful of stable systems which themselves don't have much risk of state conflict. But if automation is important to your business, you're going to need virtually everything available as input to your automations, because some of your competitors are likely to have virtually everything as input to theirs. So the assessment here should result in: (a) making peace with automation not being critically important to your business, so you can do a little bit of manageable duplication; (b) choosing a highly-aligned partner as your system of record and affording you unfettered access to all of your data; or (c) if neither of the first two options are available, multiplying your capital requirements by 10 and switch to the Become It strategy.

Check Vision Alignment

For your core technology partners, get an understanding of where they're going. Your core technology partners should scale with you because the pain of switching later will be prohibitive. How do they think about the monetization of your data? What kinds of customers are most important to them? How concentrated or diverse is their customer base? On one hand, a diverse customer base may suggest maturity. But it could also indicate a lack of focus and resulting poor level of service. On the other hand, a concentrated customer base may suggest good product market fit. Or, if you don't look at all like the other customers, that's dislocated concentration that can signal a risky bet. 

The product roadmap your technology partners choose will largely be a function of the other customers they serve, and that will impact you in a big way. The best guarantee of continuously receiving enhancements that matter to you is knowing that your voice harmonizes with other customers and your partner isn't getting pulled apart with demands in every direction.

Estimate Direct Costs

The first step in cost estimation is getting your own projections in order. Depending on your care model and the number of partners you want to evaluate, you'll need to forecast quite a few things: patient/member volume, encounters to the extent your model includes billable encounters versus subscriptions, revenue, prescribing clinicians, and non-prescribing clinicians. That may seem like a funny distinction but it's one that many software vendors require for invoicing. For instance, Practice Fusion, at the time of writing, limits the number of non-prescribing clinicians to 3 per prescribing clinician, and charges a monthly fee for that. Administrative systems like Hint and upstart EMRs like Akute charge per patient on top of monthly minimums. And the juggernaut Athena, like most RCM systems, price as a percentage of revenue. PRM company Welkin prices per user and includes a few other components as well. You get the picture… pricing is all over the place! For transparency, Canvas prices like this. 

As you layer on direct variable costs from each vendor in your stack, you'll notice things pile up fast. A few hundred dollars a month for an EMR, a few hundred for PRM, a few hundred for payments-related software. Then you've got setup fees, potential integration fees (ask about these!) and support fees.

The cost estimation exercise can be pretty challenging. So much so, in fact, that we frequently see care delivery companies that don't have a clear picture of what their total cost of ownership is for their tech stack. That may not be the worst thing in the world, as long as they're clear on the biggest cost component: opportunity cost.

Be Clear-eyed on Opportunity Costs

Years ago, a successful Bow-tied Bureaucrat and fellow entrepreneur once admonished me to "focus… focus… focus…" in a slow, subdued, and ever-so-slightly-demeaning tone. Or as the modern management marvel Frank Slootman says, narrow the focus and increase the quality. It's hard to do in any business. But I'd argue it's an especially insidious challenge to overcome in healthcare, where everything seems so connected. Decisions on build vs. buy boundaries – particularly for your system of record – are one of the most important levers you have to manage capital efficiency and speed to market. 

For example, take a single software engineering team, one PM and three SWEs with some design support. For a high-performing team of senior folks, that will cost you $1M a year fully loaded. One. Million. Dollars. So if you're taking a Retrofit approach or a Gather approach, and you have one team like that building your retrofitted care management app or data integration software, you've now set the bar super high for justifiable ROI. If instead you paid your software partner $1k per clinician per month, your breakeven is at 83 clinicians. Is that the right investment horizon for your capital projects? If your care team's capacity is, say, caring for 500 patients a month, that’s around 40,000 patients annually. How far away is that in your projections? Three years? Five?

Perhaps more important is to answer the question: Could this engineering team be building more specialized assets to help you compete, versus commodity assets that already exist elsewhere? 

Building specialized assets make your company more valuable: great patient apps, smart clinical protocols, predictive population health models. Building commodity assets drags on your capital efficiency: scheduling, clinical notes, order entry, document integration, billing and insurance handling, none of it adds to your equity value and building all that will certainly drain your cash value.

Here's where I'll plug Canvas again. The crux of the decision between building and buying is often speed vs. control. Canvas blows up that trade-off. Have your cake and eat it too: gain the speed of a turnkey system and harness the power of programmatic workflow control and broad extensibility across clinical, operational, and financial domains.

Consider Incentive Alignment or Misalignment

Great technology partnerships are like healthy marriages. Each party helps the other grow, takes into account their changing needs, and has a long-term vested interest in the other's success. Athena plays aligned incentives up big time in their sales, for good reason. Incentive alignment means a technology partner is more likely to go the extra mile for you — sequencing their roadmap in a way that aligns with your priorities, fixing bugs that align with your priorities — because it's also for them.

If growth expectations and product interdependencies are high, then incentive alignment matters a whole lot. If your needs rhyme more with "vendor" than "partner," meaning relatively low-stakes dependency, easily substitutable, then incentive alignment may not matter too much – it could be better to go with the cheapest option. We see that often in low-growth, low-competition markets, care delivery companies just want the cheapest system to get the job done. But if problem-solving is dynamic and stakes are high, you want all eyes on the same prize.

Where To Go From Here

It's worth taking a beat to appreciate the work everyone is doing in the care delivery ecosystem at this singular moment in time. The market is under pressure — explosive pressure. Our communities need more care even as the industry has less capacity to give it. And trends are accelerating in the wrong direction.

The way I see it, every new entrant provider group is an expression of joyful defiance that we can do better. Daring people can design and deploy and improve care models that outcompete the incumbent extractive system. Software can speed it up. If Canvas can help, excellent. That's why we're here.