Healthie

Today, we’re talking about Healthie and how it’s being used at your, at your company. Before we jump into that, could you give a brief overview of your company and your role there?

Yep. So I’m the Chief Product Officer at a respiratory care management company. So we focus longitudinally on folks with chronic respiratory disease, doing things like virtual pulmonary rehab, behavior change, smoking cessation, exercise, building an exercise habit and all of that. We primarily work in a value based care setting and our coaches are clinical coaches. So they have both clinical licensure as well as training and health and wellness coaching.

When did you purchase Healthie and how long have you been using it?

Yeah, so we went through an evaluation and ended up signing on with Healthie in December 2021. And so we’ve been using it since then. We were primarily looking for a solution that would give us an out-of-the-box coaching interface where our coaches could use to track notes and their interactions with our patients. And then we were looking for a solution that could connect via API to our, to our own mobile apps. We make our own mobile apps, both native iOS and Android apps. So we needed a solution that would connect to that but also have an out of the box interface for our coaches.

Got it. That totally makes sense. Just to double click on that. Part of the reason Healthie was appealing to you is because the API was extensible and easy to build on, but there was still kind of like the base architecture there so that providers could come in and utilize the software from day one.

Yeah, absolutely. So we knew that we didn’t have the bandwidth to build out our own clinician interface, which actually knocked out a lot of the headless EMR options, which I know, since then, some of them have added clinician interfaces. I do think one of the benefits of Healthie was that they had started off as a provider tool, so you could tell that they had done a good amount of research, you know, user testing and validation with actual providers. Even though those providers were more in the Health Nutrition Wellness space. It was clear that there was thought put into a lot of those provider features and what they would need.

So it was essentially a good enough interface for that even you know, it takes a few more clicks than we’d like to do for some of the most common actions that we have, but they’re doable, and they were doable out of the box. And so it gave us a lot of options and a lot of tools to play with that we knew that we didn’t have the engineering bandwidth to build out kind of each integration for, while still giving us options to tie into that patient interface. We also use their out-of-the-box web interface which has allowed us to reach members that are or desktop only. So that’s been a really big benefit that we actually didn’t originally anticipate. We’ve found that 50% of our logins are actually happening on desktop, so it’s allowed us to reach those people sooner than we would have been able to if we had to build that out ourselves.

And that’s the white labeled interface that you basically branded?

Yeah.

Cool. So it feels like you’ve been using Healthie for, what, two and a half years now. I’m curious to understand, how has it evolved or how has it changed over that period of time?

Yeah, so we were one of the earlier customers that actually purchased them as an API solution. So I think we kind of caught them in the middle of the pivot of marketing as an out of the box solution to marketing as an API layer. And so we have run into, especially in the earlier days, a few areas where you could tell kind of they were they were making that transition. Some of the API documentation had been clearly built for more internal consumption. And we’ve seen the documentation improve dramatically. We’ve also seen their support system, especially their developer support, expand out a lot because they’re now supporting developers rather than just clinician customers. So that’s been something that’s updated and changed. One of the things we really appreciate is that their roadmap is sort of publicly available and you can see what they’re working on kind of “now next later”, even if it’s just to know that something that we’re interested in that isn’t going to be coming for a while, versus some of the things that they are focused on.

I think the biggest change has actually been in their support. Previously when we started, we basically got put into a Slack channel. And we were kind of tossing questions back and forth there. They’ve since really expanded out their customer support. You have an account rep. We have a ticket filing system and in a way to escalate some of those concerns. And so that’s really become a lot more systematized. We still have that slack channel where we can ping folks and have more discussions. Especially, you know, that happens a lot with some of the questions that our developers have working with their API. I do think it’s still a little bit uneven in terms of how solid it is, basically like how often we have to go back and forth with them versus how much we can self-serve based on the documentation. So there are still some places where it feels like there is more friction than there should be or doesn’t work in quite the way that our team is anticipating. So there are still some places where we have to go back and forth with our team on that.

Pivoting just a little bit, and I think you covered some of this earlier, but I’d be curious to kind of get a breakdown of basically how do you use Healthie at your organization, like, you know, what types of users interact with the product, what are their what are their workflows, just from a product managers perspective, like what are all the different needs that it’s filling?

Yeah, so we’ve got I would say, three main types of users for Healthie. So the first one would be the members interacting with Healthie; they are primarily interacting with Healthie via our mobile apps and the health API, as well as through the white label desktop version of Healthie. The second use case is our coaches, so the coaches that are working with members, so they manage the member panels, they do their notes there. And then the third use case is actually more of our ClinOps or our internal what we call CareOps, which is a combination of products and clinical looking at the workflows and the systems, so it’s more of the meta level of practice management. I would say the strongest use case is that coach to patient interface for Healthie- that’s where we have probably the most interactions.

Most of our members we do host the video calls through Healthie so we do most of our appointments are scheduled through Healthie and then they’re run via the Zoom that’s hosted through Healthie. Most of our members are able to do that. The ones who can’t, we’re able to call them on the phone or they’re able to call in with the Zoom number. That generally works pretty well. With the mobile app and the API, we see pretty good usage there. We have pretty much like a 50/50 split of people who use web logins on web and logins on mobile. And then within mobile, we have pretty much a 50/50 split between Android and iOS. Our members, I think it’s good to know, they’re typically older, the average age is like 60 to 70 years old, and so we’re getting people that are 65+. So it’s a heavily Medicare population. It’s also a population that has a much wider range of comfort with technology. So we have run into some issues for example, you know, like email addresses are the main kind of way to log into Healthie and manage accounts and distribute unique accounts. We have a lot of people who don’t have email addresses. That’s not Healthie’s problem, that’s more of a challenge on our side to solve. But we do have a fair number of folks that have problems in technology. So we’ve had to create some solutions to deal with that.

On the coach side, we do a lot of things in Healthie to try to streamline their workflows. So we actually have created, I would say we are power users in creating forms, templates, and charting note templates on Healthie. And that’s where, you know, we’ve created these maps that allow our coaches to make sure that they’re hitting all of the questions that they need to ask from a quality perspective. And they’re, they’re basically documenting it- it is both acting as a script and as documentation as they’re talking to a patient. So they’re able to check things off as they ask those questions, to make sure that we’re covering all the things that need to be covered, and that we’re documenting that in the moment so they’re not spending a lot of time retroactively documenting. So those templates are really helpful. The other thing that we’re able to do is to actually trigger actions from those forms in Awell so we can actually trigger actions from those in automations that allow Awell to actually take care of a lot of the automated follow up so if someone if a coach checks off in Healthie to send a resource, they don’t have to go afterwards. To find the resource and send them they can actually just check that item in the form. And then Awell in the background actually sends that resource to the member. So that’s one of the ways that we’ve used that combination to really empower our coaches and to streamline their workflow.

From the practice management side, I think that’s really, that’s probably one of the places that Healthie falls short. So their reporting structure and just tracking from an overall panel perspective, is something that we’ve had a little bit of trouble with. We’ve been basically piping all of the data from our Healthie appointment data, responses metrics into our own data lake. So we have a data lake that’s hosted on AWS. We actually pull all the data into the data lake, and what’s nice about Healthie is that they actually make it easy to do that, so we’ve created our own business intelligence dashboards to run some of the practice management. Things like letting coaches know how people are tracking, rescheduled or missed appointments, tracking you know, how many coaches are completing the surveys or, you know, our overall like survey completion rate or being able to highlight members that are at risk of becoming inactive or members that haven’t had a visit in in a long time. So, a lot of those things are more about managing how our coaches are running on the meta level than that we actually have to do outside of Healthie.

Got it. My intuition was that Healthie spiked in practice management, perhaps on kind of like the scheduling, forms, and templates side, but perhaps like you say on the reporting, there’s still some development to be done.

On the reporting side, I will say that’s one of the places where there could be a little bit more work because their reporting is basically just like exporting reports, and sort of like manually exporting reports. So like, you create a report that’s exported on a regular interval, but it’s not like a proactive dashboard that you can use for managing, so there is that disconnect between how fast you can use that data, it’s more of like the retroactive review. So we can export reports- for example, for external providers, we can export out that practice level view, but from a day to day operation standpoint, we have to do that outside of Healthie.

Yeah, that totally makes sense. You’ve talked through a number of the features here that I was curious to kind of dig into but on the patient scheduling side, do you feel like Healthie stacks up well, or do you have any kind of feedback on that feature?

I think it does okay with the scheduling. I think from a patient perspective, it does pretty well. Just in terms of, you know, finding a time, scheduling it, and sending a confirmation email. We do have a system now that we’ve built out again, between Healthie and Awell, where we actually send reminders to schedule an appointment if someone is due for an appointment and they don’t have one already scheduled, but Healthie in general takes care of all the like, Oh, you have an appointment coming up. That’s been working pretty good.

We had some problems at the beginning with syncing Outlook to Healthie. I haven’t heard anything recently about that. So that might have been fixed. I know that that was something that was specific to Outlook being difficult to work with, which is, you know, some of the other solutions that we had only had Google Calendar syncing anyway. So I don’t necessarily blame Healthie for that. I don’t think that’s come up recently. In terms of Outlook syncs, I think that’s actually gotten more reliable. In general, we don’t have that many states where we’re scheduling, so I can’t tell you too much about how it’s able to deal with really complicated scheduling situations, situations of like, licensure and geography and time zones and all of that. I think in general, it’s done a pretty okay job for where we are, but most of our members are in a limited number of geographies and time zones, and so we haven’t had to deal with too much complexity there.

Got it. That makes sense. I also wanted to double click on one other feature that you had mentioned earlier, which is the complex conditional forms and templates. I wanted to just check in and see how you’re finding creating very complex workflows within Healthie?

I would say you can probably get to like one or two levels of complexity. I would say on a scale of like one to five in terms of how complex you can go conditionally, it probably sits around it to two or three, so it’s able to do some basic conditional formatting on the forms but those forms do start to get very long. And there have been a couple of places where we’ve broken Healthie’s Form Builder. One of the other things that we found is, you know, it does require a login to fill out some of those forms. So we actually have a test pathway for filling out the PHQ-9 and GAD-7, where we send it out via Awell and we use that to log the form in Healthie. I would say their user interface for the forms is okay on the member side. We use them much much more as templates for the coach charting so that’s one place where we’re looking.

One of the other issues that we’re having is it’s hard to generate a good snapshot or summary of a patient. And so it’s either you know, you look at all the charts, all the forums, and it’s too much information or you’re relying on each of the coaches to kind of update that quick description, which does require some manual work and some manual summarizing so that’s one place where we wish we could do a little bit more in terms of like just summary, summarizing and pulling out the salient information from those forums to be able to be viewed at a glance when reviewing when reviewing a patient chart, especially for clinicians that are unfamiliar. So right now we’re actually building out an escalation pathway where you know, we can escalate a concern to our medical director. So that is one of the concerns right now- how do you actually summarize the information so that the medical director can kind of get a good brief understanding of that patient history and the concern that they have to weigh in on at a glance so that they can respond quickly, especially if it is if it’s an emergent issue.

Are there any features that you perhaps don’t use because it doesn’t work the way that you would need it to?

I would say that one of the things that we commonly get asked about a lot that we don’t use, just by virtue of our business model, is the billing piece of it. We have talked in various ways about billing for RPM codes and generating super bills. It’s something we’re still kind of exploring in our business model, but it’s not the most common use case. So we just don’t use it from that perspective, but we do get asked about it a lot. The other one is prescribing- we don’t do medication management. So that’s one where again, it’s not one that we interact with much. We don’t use the Healthie report export feature, we would much rather just pipe it all into our data lake than get the reports from their reporting tool. And that’s why that’s why we’re leaning on that data being imported into the data lake and then combined with the other sources of information that we have kind of like everyone else.

Their metrics function is okay. We don’t really use their journaling. But I think that’s mostly because our patients don’t really use journaling. So we actually have the action items set up as a to do list within our own native apps. And then we realized our coaches were not actually assigning action items to people and it was just kind of like something that was taking up space on the homepage. So that wasn’t really being used, as we thought it would. But I think that’s mapping out more of a use case on our side. Not necessarily an issue on how it’s implemented on the Healthie side.

We have actually made more use of the conditions and the medications piece of it since we started integrating Zus. With the Zus integration, it is able to pre-populate the medications, conditions, and encounters with actual medical history. So prior to actually pulling that from the record via Carequality and Commonwealth, we weren’t really using those modules because it required a lot of sort of manual fill in. And reliability from patient self-reported data is pretty low. So we just weren’t using those functions. But I would say that being able to import those records from Zus has actually been really helpful.

That makes sense. I want to get to the integrations piece since you’re mentioning Awell and Zus. What was the integration process like? Did you have to write code, or did they come out of the box? How do you feel about the quality?

Yeah, I would actually say that the place where Healthie shines is the ability to do those integrations without us having to do any work. And I would say that that is both like Healthie and the partners that we’re working with, so part of the reason we chose Zus and Awell and actually Impilo is also working on integration with Healthie as well. So they’re actually managing our 3PL and shipping our welcome kits and then some of our customer service call center lines. So that’s actually been one of the biggest strengths of Healthie is how willing they are to integrate and how easy they make that integration. I know they’re currently working on one with Change Healthcare and they’ve got a couple of integrations with other RCM vendors as well.

So that was honestly some of the biggest benefits because for us, that’s filling in a lot of the missing pieces of Healthie. In a way, I think Healthie is acknowledging that they’re not going to be able to be the best in every single feature and function. But by being open to partnering with people who are working, you know, part of the reason Elion exists is because like every single facet of healthcare like the health tech stack has like 10 different companies working on just one single function. And so being able to pull that together under one roof and acknowledge and say we’re not going to be the best at this, but we’re going to find whoever the customers have decided is the winner in this space, we’ll work with them. I think that is actually a really good philosophy to have. And so, you start to get into places where it’s like, well, we could run this through Healthie or we could do this through Awell.

So I think our integration was the Healthie and Zus integration. And that’s been really helpful, both of those companies have been putting in a fair amount of engineering work to get that up and running. I think from Healthie’s perspective they were happy to work with any Carequality/Commonwell implementer. And so, you know, when we had been doing our vendor evals, Healthie actually jumped in on some of those evaluations. And so we were talking to Particle, Health Gorilla, and Zus, so those ended up being kind of like our three finalists, and Healthie was in conversations with all three and what they said was basically, we’re looking for a first customer. We’re looking to implement this if you tell us which one you want, but for them they’re building out a common data structure. So if we’re working with Zus, and then someone else wants to bring on Particle, they’re gonna be able to reuse the same modules that they’re using on Healthie side, which to me is like, that’s smart. It’s just smart if we decide to switch off of any one of those vendors. They’ve been working really well together. We get asked for user feedback a lot. So we were really tied in closely with both of those teams, and they’ll show us mock ups so they’ll kind of walk us through it. We were able to give a lot of feedback back to them. There’s a shared Slack channel where we’re able to talk with both entities and troubleshoot. So that’s been helpful.

The Healthie and Awell interaction has also been pretty good. So we actually work primarily with the Awell team there because Awell has already worked with the Healthie API and built out the whole listeners and webhooks structure, and so they’ve made it really easy to work with them. A lot of it has been figuring out, you know we test things within staging environments. Oh, one, one minor gripe that I have. There is not a good way to copy forms and templates, from staging to production, and we usually keep a copy of the forms in staging so that we have a way to do versioning of the forms. So versioning forms is annoying, and not being able to copy those like very complicated forms that we’ve set up from staging to production is kind of a pain. That’s a minor gripe.

But yeah, generally, I think they’ve been very open to integrations. Generally, when we ask Oh, do you have an integration with XYZ, they will usually say we don’t yet- they’ll either say we do here’s documentation, or we don’t yet, are you looking for this? We’ve been waiting for our first use case or like, we’ve been talking to these folks, and we’ve been waiting for a customer to bring up a use case. And what’s really nice, and I think this is a contrast with some of the more traditional EHR vendors- anytime someone brings in an integration, every customer gets to benefit from it. So it’s not being built out custom for every single customer that’s using it. It’s sort of like a rising tide is lifting all boats. Us bringing in Zus means that everybody else gets to benefit from that connection, which to me is just smart. And it means that that platform is likely to get better and better as more customers come on.

It’s certainly good strategy. Somebody’s been reading Ben Thompson around here, probably. I’m curious to dig into the integration with Awell. You mentioned some, perhaps duplicativeness between the forms on both platforms? How do you think about the incremental value of Awell on top of Healthie?

Yeah, so it’s allowed us to reduce the number of tabs that our coaches have to have open. And it standardized a lot of those things. So one example is resource sending, so as a sample use case- we connect people to things that address SDOH concerns. So if I take medication affordability as an example depending on the partner, patients will have access to different resources. So we might have you know, Partner A might just use GoodRx, whereas Partner B has a whole Pharmacy Benefits person that can help find cheaper versions of medications. And so what we can do is we can actually set up a pathway in Awell where, when a clinician is going over the form and they check off that someone has problems with affording medications and send them a resource for medication affordability. The Awell pathway allows us to actually create the kind of conditional resource to say, if this person is under contract A, send them this resource versus if they’re in contract B, connect them to the pharmacy benefit person and give them this phone number. And then that lets us give someone the best available resource without having the coach have to memorize, you know, a dictionary or a compendium of every single contract and resource available. So it means that our clinical operations team can keep that list updated, that database updated, those workflows updated, and the frontline clinicians don’t have to memorize that. They just need to know I’m going to send you the best available resource for you under your contract that you’re eligible for for medication affordability. And so that’s been really powerful.

It also means that our clinicians don’t have to find links to things so it allows us to standardize, because what was happening was saying like, Oh, you know, we’re gonna send you a link on how to do pursed lip breathing, for example, which is a breathing technique. And so a lot of times our coaches would just Google a YouTube video and pull that link and send it to someone in chat. We created a video for the coaches to actually find that video and send it, but we were still having people sending a lot of different versions of the same information. And so we actually built that into Healthie to send pursed lip breathing video as an item. It allows the clinician to control what gets sent because they really don’t want to give over that control. So they want to say, I don’t want any messages going out automatically. I want to be the one to trigger the message. So that can trigger it from Healthie. And then Awell handles the backend of how it gets sent. So we send them the personal greeting video, we have the link to our version of that video. And we actually send that via the Healthie chat through Awell. In Awell, if a form gets saved with this checkmark checked, then send a message to the member that says Hey, thanks for joining the call today, we mentioned the pursed breathing, here’s a link to our pursed lip breathing video. And so it composes the message and sends it via chat, which saves the coach an extra two minutes of time to find the link, compose the message, send it over, but you know, from a clinician perspective, any click you save is like gold.

Got it. So maybe the right way to think about it is like when you want to pursue these asynchronous conditional workflows that might involve multiple different types of resources and communications. You might want to extend from Healthie into a third party potentially like Awell.

Yeah, so for example, another one would be like if we wanted to send appointments, reminders or messages as SMS, we could do that through Awell versus Healthie having to integrate with an SMS provider. Awell is already integrated with one so we can actually have Awell do that. We do another one for reminding people to sign up for appointments if they don’t have their next one scheduled.

Actually, this one’s a fun one. So, after 90 days, we typically send someone a reassessment. So we asked them for the NPS (net promoter score), and we asked them to fill out the assessment and so we actually are able to count like from the day that they first completed their first assessment, we then send out a reminder and say, you know, hey, it’s been 90 days. Can you fill out this form with the NPS and the assessment and so that we’re able to do because our coaches don’t like having automated messages sent out, what we actually do is have Awell create a task in Healthie to the coach to say this member is due for an NPS. Can you either bring it up in your next appointment with them or here’s the link where you can send it to them asynchronously, so it creates a task in Healthie for them to do that. Once they send that out, Awell can then keep track of who’s filled out the survey and will send a reminder you know, it’ll say after after seven days, if this member has not filled out the survey, send them a brief chat message reminder to say, hey, as a reminder, can you fill out this NPS survey so it takes care of keeping track of who hasn’t like you know who’s kind of overdue for things and it keeps track of the reminders and so that’s something that Healthie has some some ability to do that. But Awell gives us much more granular control over that.

That’s a really helpful take on how both of these products add value. I think just switching gears a little bit, I wanted to go and revisit maybe the procurement decision itself. How did you find the sales process overall?

Um, it was okay. I mean, none of them had really transparent pricing. It was all the like, especially for our use case. You know, I think some of them have per provider pricing or some of that. But as soon as you start getting into the API side of things and wanting white labels and all of that it’s all like a “call for pricing” kind of model which, you know, I think it’s fairly common. I got into conversation with Erica and Healthie pretty early so we got connected directly to Erica. So in that sense, you know, our call with Healthie was very high touch and that was nice.

We knocked out a lot of candidates that if we were doing this today would actually make it onto the list. So like Canvas, I think Medplum hadn’t actually hadn’t even started yet. I would say for us, we would probably have been looking at Canvas and Elation as kind of two other places and actually probably Welkin- I’m not actually sure why we didn’t go too far into Welkin at the time, but I think that also would have made our list to compare too. But yeah, so Canvas got knocked out early because they were only headless at that point. They didn’t have a lot of out of the box interface. We were also talking to Capable at the same time, which… RIP. They also did not have a really fully built out clinician interface at that time. So that also knocked them out pretty early into the process. Elation, I think, wasn’t selling their API and so that kind of knocked them out on the other sent other settings.

So we were mostly evaluating Healthie to make sure that it was going to fit for what we needed on the API side rather than just using it as the coaching interface. So I think we were actually trying to figure out what tier of Healthie we would be in. So we had two sides of the evaluation. One was having our coaches be in Healthie and run sample patients and do charting and, and kind of run through all of their actions to make sure that the out of the box interface was going to work. And the review was essentially like this is going to be fine for at least the time being, for us to really learn and figure out what processes are going to be crucial that we will want to start to build out really robustly. I think our approach is generally buy then build, so like buy to figure out what are the workflows that we’ll need, and what’s the kind of real solid use cases and then figure out you know, how much we need to actually build out to really optimize for those use cases. So Healthie really fit in well with that model. And then we actually had the developers do a proof of concept as well. So we had the developers create a proof of concept within our app. We created a sandbox version of our app. And actually, one of them was playing around with the chat API to try to integrate that into our own app. What we found actually was that when it came time to actually implement the API, there were a lot of things that we had to fix with, like the webhooks, but in general, it provided a good proof of concept of like, what is it to work with the API? And so that actually those two things in combination, the coach interface, kind of out of the box tests and then playing around with implementing a sample feature. Those two things combined helped us make the decision to go with the full API solution white label kind of level.

And you were able to kind of do all this iteration on a free trial?

Yeah, so they were willing to kind of create a staging environment for us and for us to be able to do that. We signed. I think it took us probably about two months. To really do that full evaluation on the dev side. Like the dev spike and the coach evaluation. We signed on with them in December. It took us a while to fully get the app connected. Our coaches were able to start using Healthie right away, and then the full integration with our app. And that was mostly because we had to basically connect feature by feature, hook it up to the API that took probably about four, four to six months depending on kind of all of that, but that was mostly our dev. That pace was mostly our devs, so the full integration I think would if we were full speed ahead would have been faster.

Got it. That totally makes sense. And honestly that brings me to another question I had. The onboarding, the implementation process, it sounds like most of the time there was taken by developing and actually implementing the integration with your application, which you’d already built the front end for. Were there other aspects that required effort from your end? Did Healthie have to expend a lot of energy on their side in order to get things going?

So they had to provision out the white labeled web version, I don’t remember exactly how long it took. I remember it being pretty quick though. It was on the order of a couple of weeks to get that set up and then provisioning up the staging interface, getting all the API key setup so that wasn’t too painful. I think getting all the Outlook calendar set up and saying that was actually a bit of a process. Again, I’m more willing to blame outlook for the trouble on that. And I actually don’t know how it is for folks, how that process has been for folks running off of Google. Yeah, in general, most of the time was hooking up the API to our mobile app front end. Again, part of the issue there was mostly our devs were refactoring the app like you know, they were basically rewriting features from scratch to do that, because we had learned so much in the time, like when we had launched the first version to when they were ready to start consuming someone else’s API. So that was again, mostly scope creep on our side. I think the only other thing was turning features on and off. So we actually turned a number of features off on the patient web portal side, because those were not features that were available in our app. And so we wanted to make sure that those two experiences aligned as much as possible.

I do think one thing that is going to be something that we’re keeping an eye on is the fact that it is really hard to add things to any of their interfaces. They are out of the box, but they’re not really extensible. And so the most that they’ll do and that they’ve mentioned, is being able to create a separate tab where you can load an iframe which, you know, is not the best user experience. We can’t bolt on features to those interfaces without basically essentially going headless and rebuilding it from scratch. So at the time when we start to have features that are going outside of what Healthie is planning in their roadmap, we’re basically going to have to rebuild the entire website of things from scratch, which I am not looking forward to. We’d love to have an intermediate solution that allows us to kind of build up and bolt on additional features as we start to build them. I don’t know if that’s in their plan to be able to start to do that. But I do know that that’s something that we’re looking forward to having to do.

I want to say go back to the high level recap. Some sort of lightning round type stuff. What do you like? What do you like most about the product?

I think the responsiveness of their team and their willingness to work with third parties for integrations, I think that’s really been the thing that has made Healthie, the most accessible. I think when we were looking at it, we were looking at Healthie as a good solution for the 18 to 24 month timeframe, especially as we were still finding product-market fit and still building and testing. We felt that it was a good solution for us to kind of get started, get up and running, start to test out and validate that and start to understand what we really needed to build out as competitive advantages. I think if their products didn’t kind of improve and get better, the 18 to 24 month timeframe was where we were looking at switching- and our contract with them is a three year contract, but we were looking at, you know, value-wise, even if we only use it for two years, it would still be worth it. Since then they’ve made a lot of improvements. They’ve made those integrations- working with Zus and Awell has been really helpful. And so I think it’s extended out that timeline that we would stick with them. But there’s still some things you know, that aren’t aren’t ideal, or when we start needing to scale up. We’d still be looking at other solutions or potentially building out more in house.

It’s almost like you’re looking at my interview guide. What’s the likelihood of you continuing to use the product in 18 to 24 months?

I would say it was not high when we started. Higher now, based on some of the improvements that they’ve made and some of the sort of strategic decisions that they’re making. I do think some of our clinical team are used to more traditional EHRs and they want things that are more similar to what they’ve used in the past. But I would say on the 18 month timescale likely that we’re going to still be with Healthie. Longer than that, it’s hard to say. It is going to really hinge on how our business scales because even since we signed on with Healthie, our clinical model has changed significantly and we’ve gotten a lot more clinical. We had started off as a coaching solution, and we’ve since added a lot more clinical medical management, all of that. And so that’s probably ending up in a place where instead of this patient engagement and coaching-focused solution, we are going to have to build in a lot more like these clinically-focused features: prescribing, escalating, triaging, and all of that, which might be more suited, at least from a clinical staff perspective for a traditional EHR. And so that’s something that we are still figuring out right now as we go. Healthie could meet us there. But it’s also possible that we’re going to need to do more. It’s possible that we’re going to outgrow Healthie in terms of either the capability or the scale that we need to do that.