Canvas

We’re talking today about Canvas and how it was used at your former company. Could you give a brief overview of the company as well as what your role was there?

I lead product, IT, and security at my company. We are a tech-enabled service provider that provides chronic care management, benefits support, and provider linkages to individuals in a risk based arrangement. We help them access benefits they’re eligible for and downstream community care within the existing provider community of primary care and behavioral health resources for Medicaid patients in a value-based arrangement.

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

We purchased Canvas in early 2022 and have been using it since.

Tell me a little bit how you use it within your organization. Who are the users and what are their main workflows?

We use Canvas as an EHR and a care management system for our non-clinicians (including our social workers) and nurse practitioners. Non-clinicians document their outreach attempts (successful and unsuccessful) to individuals they work with. They use it to maintain up-to-date contact information and addresses and manage their panel there – for example, they task the other caregivers with any downstream tasks they need to do. They document their interactions and implement standardized questionnaires like patient outcome measures. This could include assessments that we have created to document social needs in a very unstructured way.

Our medical assistants do a lot of pre-charting on medical records; our medical records specialists manage requests on medical records they need, like from past visits and hospitalizations for individuals that we are scheduling for nurse practitioner visits. Our nurse practitioners (NPs) use it as a typical primary care EHR – for lab orders, imaging, prescriptions, referrals, scheduling, and documentation.

What has worked well within the platform?

What works really well, even as we’re migrating away from Canvas, is the ease of customizing questionnaires for non-technical end users. Our clinical teams really appreciate that. I think we’ve created tens, if not a hundred questionnaires that are specific to our use case. We can do different things with them: for example, assessing specific elements of a person’s social needs. It has been a very easy tool to customize different questionnaires for our end users.

It was a fairly easy tool to stand up. We stood up our first iteration of Canvas within two or three weeks. The team worked really well and quickly with us; their implementation was fast and very collaborative. They set up a shared Slack channel and we almost felt like their implementation person worked part-time with us because they provided a great real-time experience by answering our questions, running things down, and doing configurations on their end.

Finally, the price was really, really cheap compared to the other vendors in the marketplace. For us to stand up operations, it just seemed like a no-brainer. It seemed like a product that was investing a lot in new capabilities, was easy to implement, and was fairly low-cost. Those were the things that attracted us to Canvas.

Got it. So, what were the challenges then with Canvas? What hasn’t worked as well?

Unfortunately, there have been a lot of critical challenges with Canvas. We got to a point where we realized we had to get off it. I cannot tell you how much positive feedback we got when we told our staff that we were migrating off of Canvas. It had gotten so bad that everybody was looking forward to adopting and trying out a new tool.

So, first and foremost, we’ve had a lot of performance challenges with Canvas on a weekly basis for almost six months. Our NPs have had times when they charted and submitted a note but it failed to save; the system loses documentation they had spent 10-30 minutes putting together. They have made some fixes for such issues, but it still happens for some users, maybe once a week. And there have been really bad lag issues where something like logging in and typing up a chart, which should have taken 30 seconds, takes 10 minutes. There will be a two to five second lag with typing something or it’ll take like 30 seconds to open up a chart. That has come down; Canvas has brought in a new head of engineering and consultants to fix some of these issues. But there have been times where we wondered if this tool was going to still be up. It has mainly been these performance issues that have driven the need to switch, even if it’s painful.

It sounds like it’s about core functionality. Were there any features or functions you were missing in the tool?

There’s a long list there. Before getting into the functionality, we have made the decision that our non-clinicians just shouldn’t be in any EHR. This is not a knock on Canvas, but at the end of the day, we just built our own internal tool. The adoption and usage of that tool, and the value we’re seeing from that is ahead of any digital health vendor I’ve ever seen. We think we’ve made the right decision recognizing we need to build a very personalized and tailored tool for non-clinicians because their activities are very unique. Even as we migrate to Elation, they will stay out of the EHR.

In terms of Canvas’ features, their APIs are not that robust. One of the really frustrating things is that they just did not deliver on having write APIs and so we always had a lot of challenges with just reading: we could read a lot of data but we couldn’t write data from Canvas to some other system, or from our databases into Canvas. That forced us to build workarounds to push and pull data out. And because they also didn’t have robust APIs, we were really beholden to this internal database that they had in order to export data out of it. We ended up taking data from the Canvas data model, using Fivetran to transfer it to our own Snowflake data cloud, and then managing the data there and doing a bunch of transformations. Now, with Elation, they have a more robust API that I think our engineers are a lot more comfortable with using; there’s more data liquidity and flexibility in getting data in and out of the EHR, especially now that we’re really investing in internal proprietary tools for non-clinicians.

Their scheduling capabilities were not good; for example, you cannot double or triple book, the way that the Canvas calendar is set up. We needed this to really manage clinicians’ calendars but couldn’t because the APIs were really poor. You can’t schedule on the go. Elation has these public-facing scheduling sites for their clinicians, where you can just go to a URL and book an appointment with a provider at a given time. Those links are mobile-optimized and we can link out to them from our internal tool that is really meant for on-the-go documentation for our care team. Canvas’ inability to do that was really problematic because for our patients, scheduling appointments is really challenging and no-show rates are really high. You need to have a really robust workflow there, because it’s one of the most frequent things that somebody on the care team is doing or coordinating.

Canvas also did not have a great role and permission structure, especially for a national scale clinic. I get the sense that their target customer segment that they’ve built for or have current capabilities for is a virtual telehealth-based centralized provider. In Canvas, there isn’t an easy way to segregate data based on clinics and pods or on different provider assignments for specific patients. This is really challenging for us because we have a complex care model. We became national very quickly; we have 15 sites across three states. And in some locations, we have multiple clinics. We can’t say that an NP in that location can only see patients in our first clinic because, sometimes they will flex to the other clinics. And then we also have flexible NPs that can see anybody. That setup was also somewhat complex and they did not have infrastructure to make sure that we had a good data privacy setup.

These are areas where we were looking for more. The challenge is that because they’ve had this issue with performance, they just haven’t shipped any new capabilities in the last year. And so, on top of having all these issues, they’re fire-fighting just to get to baseline. They haven’t been able to build any of these things that they told us that they were going to build.

I’m curious to understand what led to the decision to have non-clinicians in the EHR in the first place.

That was a matter of our not knowing what our care model was going to be. We knew we could get our non-clinicians a care management system, but there was no care management system specific for our kind of team-based care model. We have non-clinical workers in a value-based arrangement doing longitudinal work for socio-clinical needs specific to Medicaid in a hybrid model. We didn’t think a Welkin, for example, would be able to solve for this. And so we decided to put them in the EHR.

A lot of nonprofit agencies with similar care models have such workers in their EHR. So we put them in and thought we’d see how it went and re-evaluate. We then confirmed that they needed their own tool. It’s not like we wanted to move them into a different tool. We just decided to move them into our own tool.

When you decided to do this, did you do a more comprehensive evaluation of care management platforms or CRMs?

This is somewhat unique to our company – our engineering teams are really strong. So, our Head of Engineering just built the first version of the tool over Christmas. We didn’t do an evaluation: we thought we’d get to it and then they just built this tool to handle one use case that a care management system would handle. It was a hit! 50% of our frontline staff organically adopted the tool, and we decided to just keep investing in it. It incrementally became the tool we needed. Truth be told, there was some initial push back to the tool and some folks felt that we were wasting tech resources to build something that already existed; those same people are now the biggest champions for the tool. There were just so many specific use cases. We went down the list of most painful use cases for our frontline staff and built them into the tool. Two to three months later, we see it’s working way better than having to implement with a vendor. And we had had such bad experiences with vendors we didn’t trust anyone to do it as well.

What are examples of use cases that you built out of the gates that weren’t well-solved anywhere else that you’d seen?

Mobile documentation and a mobile-optimized experience that was good on the go. Our non-clinicians are so on-the-go that they really can’t have a tool unless it doesn’t have an explicit on-the-go focus. There were basic things like uploading consents on your phone. In Canvas, uploading a consent was a 10-minute thing. You basically have to print out a consent or take a paper “consent to treat” and a “consent to request medical records”. You get somebody to sign it. Some of our patients are not comfortable signing something on a phone, but they sign this paper. So then, our non-clinical team member has to take the paper consent back to the office and scan to email the consent to their laptop. Then they download the consent from their email, open up Canvas, and manually upload it. For every patient, this is a 10-20 minute workflow that our non-clinicians would occasionally make mistakes with. The office internet or fax doesn’t work, or they’re able to email to themselves but forget to download it and upload it to Canvas. We would routinely do these checks to see if everyone had submitted their consents in Canvas, and then just built it such that you could just upload a picture on the mobile tool and it would automatically push the PDF to Canvas. It takes 30 seconds now.

Did you use any patient-facing or portals in Canvas’ EHR?

We try to not put too much on our patients. Most stuff is over SMS if there’s any outreach, so we didn’t use any of those tools. We managed SMS in a different system.

Were you using any of their revenue cycle management (RCM) functionality?

No, we used their integration into ClaimMD. It wasn’t the prettiest thing but it worked. Now we’re evaluating a bunch of RCM and billing providers and the sense I get is that a lot of vendors differentiate on the margins. So we were fine just using their integration with ClaimMD.

Canvas had solid coding capabilities and this is an area where they continue to invest in. One of our coders actually reached out recently mentioning that they loved some of the new features Canvas shipped for their workflow.. We were also able to solve this workflow with process. For example, they had a capability where a claim could be queued up to be submitted to a clearinghouse and then a coder could go through the claim and propose to the clinician different codes that they might want to consider or codes that were missing. And then the clinician could go back and specify whether they wanted to add those codes or not. We added processes such that anybody could sign a claim that was open or a coder could edit and change codes on behalf of the NP. We recognized there were capabilities that would have made our lives easier but we just needed to manage with good auditing practices around the claims. Ultimately, once that claim was ready for submission and had the right diagnoses on it with the right documentation, it would be submitted to ClaimMD, which would then route it to a clearinghouse.

ClaimMD is an out-of-box integration; were there others you leveraged with Canvas?

We used Health Gorilla for e-prescription and SFax, which was their e-faxing provider. SFax was decent. For labs, we had to do a little bit of work to get Quest and LabCorps set up and some source script set up. Those were the ones that were used out of the box. Zus had a pretty strong and deep integration with Canvas around surfacing medications in meds lists. That was really effective.

While it might not have been right for your company, is there a type of organization for whom Canvas would be a good fit?

If you are a virtual telemedicine-oriented platform or if you’re a platform that primarily has centralized clinicians. If you were very clinician-oriented, or if you’re a primary care organization or a specialty organization that has a differentiated clinical care model, where the IP is in your clinical assessments and your clinical care operations,I think Canvas could actually be really effective for you. If you’re early-stage in those spaces, I think Canvas can be really effective to get started and off the ground. If you don’t have six to nine months to implement an EHR, it could also be pretty good for you.

You’ve just gone through the procurement process again. How did you evaluate EHRs and what led you to go with Elation?

We mainly evaluated Healthie, Elation and Athena. We also checked out EMRs that some of our clinical and care operations staff wanted us to look at because they had used them before – Netsmart and Qualifacts – but the main contenders were Elation, Athena and Healthie.

We looked into the robustness of their APIs and of their out-of-the-box feature sets and capabilities. How good are their integrations? We looked at data migration, though that was less important. What does pricing look like? And where do we think this platform is going in the next two to three years: how compelling is the roadmap?

Could you talk a little bit about how this was either similar to or different from the process you had when you chose Canvas the first time?

Completely different. With Canvas, we hadn’t even gone live yet. We were going to go live anywhere between one and four months from then. The EHR was a pretty big gating factor to seeing patients and billing our health plan client. We wanted to go live as soon as possible and figure it out as we went. This time we have over a hundred users that have 20 different workflows, some of which are going really well and some of which need to be improved. We have a ton of data and internal tools that we need to manage and migrate. So it was very, very different. We knew a lot more about what we wanted to do and accomplish this time around.

The process was different the second time because you were not optimizing for time. The factors or criteria you were using were also different because you were now operating as opposed to in planning mode.

That’s exactly it. This time, there was a much greater understanding of where in our care operations we needed to improve and where we actually needed to migrate. We just knew that data privacy, scheduling: those were key things that the EHR needed to have, and we just had a much better understanding of how robust APIs needed to be.

What led you to go with Elation?

Healthie was really impressive. We thought that it was a very flexible platform. Our main concern was that we would just need to rebuild a lot of stuff specific to value-based primary care that Elation already had. We didn’t want to have to build value based primary care centric clinical, coding, scheduling, or intake workflows. It seemed really flexible and they seemed to be very great partners to startups. They were actually more competitive from a price perspective than Elation. But, at the end of the day, we just think that over the next three years, Elation has and will continue to build more for customers that look like us than Healthie will. Healthie also seems to be more consumer health-oriented vs. value-based care-oriented. So, that was the main concern.

With Athena, it felt like overkill. Most folks that use Athena aren’t just using Athena Clinicals. I definitely got the sense that they had a number in mind where they needed us to pay them a certain amount in order for this to be worth it. We only wanted their clinical platform and none of the other modules because we’re building everything ourselves in-house. Athena’s sales team wanted to review our value-based contract and understand how we made money. I didn’t understand why – I didn’t see why I should share how we make money so they could maximize their pricing for us. That seemed like the wrong fit.

So it really just came down to Elation and Healthie. Elation won in terms of having a lot of capabilities out of the box: robust roles and user permissioning, scheduling, and APIs. Their roadmap, their shipping velocity – those all came together for us with Elation.

I’m curious to hear what the migration process looks like. What have you learned about migrating from one EHR to another generally, and specifically in terms of getting out of Canvas or getting into Elation?

It’s a really tough thing to do. In retrospect, we did a lot of things out of a desire for speed. We’ve built a lot of workflows that are very Canvas-specific. And so, as we’re now migrating, we’re also realizing we need to do things in a way that is not EHR-specific or do not make us so beholden to an EHR. It has been very complex. We thought that this would hit two or three engineering teams but it will be a full team effort with a lot of scoping, design, and execution work to come.

If you had to do all this over again, is there any generalizable advice that could help others in a similar situation?

I think it’s necessary to start the conversation about potentially churning from a vendor sooner rather than later. I have to give our head of engineering credit because he has gone through an EHR migration before and he saw certain things that did not pass the sniff test. With some of Canvas’ performance issues, he said that we’re going to have to migrate from Canvas two months before I thought we should start investigating it. Every single part of the process: vendor selection, migration planning, the migration itself, all take way longer than expected.

If you feel like something is off, you should convene a group to discuss sooner and at least have a plan in place for what you need to see to stay on or to decide to move off. Ideally, you communicate what you need to stay, to the vendor. And then if that doesn’t happen, you should really pull the band-aid off. Especially for early-stage startups, the easiest day to switch EHRs is always going to be today – it’s only going to get harder and harder the more staff you train, the more data you put into the legacy tool. That’s where I wish we had moved on this faster.

How is Canvas’ general support and responsiveness, from a customer service and account management perspective?

It was really good. They did a really good job of trying to make the relationship work as much as possible. I am really rooting for them.

In contracting with Elation, their salesperson did not budge on anything. I wish this space was more competitive. In general, I have heard people say that they really love being on Elation, but it took them a lot of work to get there. And so in many ways, I’m still rooting for Canvas and remain supportive of what they’re doing. Elation is going to be immensely expensive – we’re going to be paying way more for it, without certainty around the level of customer service or pace of implementation. Moreover we’re already seeing areas where what we were sold by Elation isn’t matching up to what they can actually offer in implementation. My fingers are crossed that we end up in a good place but there has definitely been a feeling like we got a bait and switch by a few team members who are implementing Elation.

What led you to choose Canvas in the first place?

We needed to be live with a functional EHR in two to four weeks. And they were ready to work with us to make that happen. And they did. Even then, Elation was just going to be very expensive for us. I think Elation changed their pricing, but originally they were charging thousands of dollars per clinician and we were going to have 10-12 clinicians in year one using the product.

We also had a clinical leader who didn’t want to be on Elation at the time (later they felt like they would have much rather been on Elation than Canvas). It was so early that we were just going at the speed of light. So it was a very different decision framework.

Is there anything else we haven’t covered? Any other advice that might be helpful?

I wish that we had given ourselves an extra two weeks to plan what we really needed from an EHR – to define our expectations. I actually don’t think that our decision would have changed in any way. But I do wish that we had done that and I think that it might have at least put our head on straight to kind of like know what we were going into with Canvas.

I’ve seen some digital health tools that work well and are effective, so I was optimistic. I didn’t account for the fact that sales teams and digital health vendors in general have room for growth. It’s important to validate what platforms can do and gauge fit through reference conversations. Now, when we start such a conversation, we try to gauge how similar the vendor’s customer base is to us. Having those reference conversations, we would have probably learned that a lot of customers were very early in their journey with Canvas, similar to us. We would have understood that we had a much greater scale. If we are likely to be the first venture-backed tech-enabled services business to use a product, that sets off a signal for me – we don’t want to be that guinea pig.