Canvas

So today, we’re chatting about Canvas and how it’s being used at your company. Before we jump into that, could you give just a brief overview of the company and your role there?

Sure! So, we’re a virtual specialty clinic. Our main objective was to establish a virtual clinic that caters specifically to individuals with low-acuity chronic conditions. We achieve this by connecting patients with a doctor, a health coach, and a care team to address their day-to-day needs. We utilize educational resources, offer messaging options for communication with the care team, facilitate prescription and lab services, and guide individuals toward treatment options including supplements. In a nutshell, our aim is to effectively assist those dealing with low-acuity chronic health conditions.

How long have you been using Canvas?

A year and a half.

What caused you to look into purchasing Canvas?

When we were setting up this clinic, we performed due diligence on what we needed to do to run a virtual specialty clinic successfully. We identified early on that we needed an electronic health record (EHR) system, since we had plans to eventually start billing insurance. To avoid any complications later on, we decided it would be easier to implement the EHR system from the beginning rather than trying to incorporate it later and completely change our documentation practices.

Additionally, we were also handling lab orders and prescription requests, so having a built-in EHR functionality for these tasks was essential.

What ultimately led you to go with Canvas?

Yeah, there were a few things we considered. Cost was definitely a factor, as it is for everyone. But for us, we wanted something lightweight. We had a belief that we needed to document in a formal way in the EHR, but since we weren’t planning to bill insurance, something like Athena seemed like too much overhead compared to what we needed.

Another thing we were particularly interested in was the description of Canvas as a headless EHR. Even though they don’t seem to use that term anymore, there were a lot of people talking about headless products at that time, and we found it intriguing. Canvas emphasized its deep API integrations, and that caught our attention. We wanted to use the Canvas APIs not just for our clinicians and care team, but also to drive clinical workflows for our patients in our mobile app. Many of us had previous experience with EHRs and health tech, so we thought it was novel and interesting to build a deeper integration between the EHR and the patient app right from the start. We wanted to make those workflows easier because we knew they would be essential to providing the best patient care and ultimately achieving better outcomes.

To expand on that, we had the intention from the beginning that we would send patients down specific care tracks, which were guided programs with educational modules and assessments. Canvas has a lot of APIs for those types of modules, so we wanted to use Canvas as the back end for our patient app. We planned for the core patient information to be stored in Canvas from where it would be fed into our patient app.

Canvas also claimed to be working with other digital health tech startups. We were really attracted to that. They understood where we were coming from. It was a much different approach than what we experienced with Healthie. Canvas had a willingness to work with us and meet us at our early stage. At the time, we were still in the process of establishing our clinic legally. So the fact that they were willing to talk to us and work with us, even at such an early stage, was a big positive for us.

Were there any other vendors that you closely compared Canvas against?

We did consider Healthie, since they also operate in the behavioral health, integrated medicine, and nutrition industry. They were one of the main competitors we looked into. However, Healthie didn’t offer the API integration we needed. Additionally, they had a lot of features that weren’t necessary for our virtual clinic, as we primarily deal with cash payments. This is why the headless nature of Canvas, which allows us to simplify our electronic health records to the essentials, really appealed to us.

We felt that Canvas had a stronger set of APIs and was easier to build on than Healthie, and then Healthie was a little bit over-featured relative to what we needed. We didn’t really need all of that. We viewed Healthie as more of a collection of different parts, and perhaps we could choose which parts we wanted and leave out the rest. With Canvas, we saw it more as a comprehensive platform solution that offers APIs. It wasn’t just selecting specific components, but rather, we could create our own user interface (UI) on this platform. This would give us a great deal of control over the entire experience, not only for the patients but also for our providers as we also intended to build a provider platform to compliment our patient app.

Do you know how the pricing compared between them?

I believe the pricing model of Canvas appealed to us, mainly because we were aware that we wouldn’t be billing insurance for a while. Their billing method was structured such that you pay a flat fee per patient and then a percentage of payments received, but since we weren’t going to utilize that service (we were managing our own billing through Stripe), it inherently made Canvas more affordable for us. I’m not sure if their pricing model has changed since then, but back then it was definitely a good fit for us because we didn’t plan on doing payments through them.

What are the strengths of Canvas?

Canvas’s biggest strength is that it delivers on the promise of being a stripped-down, basic EHR.. Canvas, being a relatively new product, is simple and straightforward to use. It doesn’t have unnecessary features that can distract from the main focus of documenting and maintaining clinical records for patients. This simplicity is a strength compared to EHRs like athenahealth or Epic, which have a lot of bells and whistles, but ultimately offer a lot of functionality that you may or may not actually need.

Another aspect I really like about Canvas is its clinical notes. They allow for quick documentation with appropriate diagnoses and prescriptions. Canvas is pretty modern and allows for formatting and easy referencing of other parts of the clinical record via commands (which are similar to dot phrases). So, overall, Canvas’s notes are simple and easy to use, which was perfect for our documentation needs.

Another thing I wanted to mention is that the Canvas UI is really modern. It looks a lot better than Athena or Epic. Even though functionality is more important to me, having a nice UI definitely adds some value. Our providers found it easy to pick up and learn how to use Canvas.

And what would you say are weaknesses of Canvas?

The main weakness was their APIs. We expected them to be more robust than they turned out to be. We had hoped to use them to power our patient app, specifically to display patient profiles. However, when we approached Canvas about this, they seemed surprised by our use case and didn’t seem to think anyone else was using their APIs for this use case. It was frustrating because we thought that was the whole point of having these APIs.

Now that I have more experience with other EHRs, I realize that it’s important to clarify whether the APIs are used for production functional workflows or just for reporting and analytics. The need for real-time data can really affect the performance of the system, and I wish we had asked more about this during the evaluation process.

Another area where the APIs lacked functionality was in the concept of tasks. We had originally planned to use the task model in Canvas to manage our clinical activity. However, we soon realized that tasks in Canvas were primarily checkboxes with assigned due dates. There was no branching logic or evaluation involved, which was crucial for driving decision-making.

We did end up utilizing the Canvas APIs to create new patients in the system whenever they went through our onboarding process and signed up. This triggered the patient-creation workflow. However, even with low volumes (single-digit user sign-ups per day), we encountered a considerable number of errors and failures from the Canvas APIs. If we had a larger number of patients, this would have posed a significant problem. Fortunately, we managed to find workarounds due to the low volume. It would have been disappointing to have to allocate engineering resources to address these issues.

So basically, we initially intended to use Canvas as a critical part of our backend, but it ended up being used mostly for documentation. We felt the headless EHR promised by Canvas was not fully realized. Consequently, we were hesitant to pursue further integrations between our systems and Canvas, as we were uncertain about the reliability of those integrations. However, Canvas recently provided a product update where they shared their roadmap for the remainder of the year. Their top priority is addressing performance and reliability, which aligns perfectly with what I, and likely other users, have been concerned about.

So, it seems like Canvas APIs lacked functionality in some cases, such as for tasks. Additionally, there were performance-related problems where it didn’t execute properly, leading to issues and errors. Were there any other recurring issues with the API, or did most of the problems fall into those two categories?

Rather than performance, I would describe our main concern with Canvas was reliability. We didn’t use the Canvas APIs to populate screens in our mobile application, so we weren’t concerned with load times. Rather we cared about things like successful patient creation, so any failure in this process was problematic for us.

Canvas also offers a component of their APIs related to clinical assessments. We initially expected to utilize this feature for the questionnaires we wanted patients to answer. However, we found that it was quite verbose and required structured versioning and question schema, which we were not prepared for as a new company. We anticipated iterating on the questionnaires quickly, but the amount of engineering effort it would require deterred us from using Canvas in that regard.

So we initially were very enthusiastic about Canvas’s capabilities in the beginning, but we gradually realized that it didn’t excel in certain areas. For example, with task management we eventually decided to evaluate other vendors and ended up developing our own task management system. Although we initially planned to use Canvas for assessments, we ended up purchasing Typeform instead.

Initially, we were only offering messaging between patients and providers in our app and didn’t offer video visits. However, when we eventually started offering video visits, instead of using Canvas’s scheduling feature, we decided to use Calendly. Essentially, Canvas became a place for us to take notes and handle crucial clinical tasks like orders, prescriptions, and clinical documentation. This was somewhat disappointing, but I believe it still serves its purpose for these important clinical tasks, and I believe we would likely encounter similar challenges if we switched to another platform like Healthie. Our expectations might have been too high.

I think many people considering an EHR like Canvas are evaluating whether it can serve as a reliable source of truth for them. They hope to run their digital health tech clinic on this platform and significantly reduce the amount of back-end development required. This is a reasonable expectation from my perspective - a product like Canvas should be capable of facilitating that. In my experience with my team though, I don’t think Canvas is currently reliable or performant enough to fulfill that role. It can exist within your ecosystem and provide some limited functionality, but it can’t drive your patient app or even a web app. So, in my opinion, it can’t be the core tool to drive your clinic.

Do you use a CRM to manage the patient relationship?

We didn’t have a typical CRM. Frankly, we just stored user data in our own back-end. In our app, each user represented an entity in our database and was connected to a Canvas patient. But at the end of the day, that user was the entity in our database, and we had our own unique identifier for them. We didn’t rely on a third-party tool; we used our own system.

As for the task aspect I mentioned earlier, we often wanted patients to complete certain actions. After they submitted assessments, we wanted doctors to review them and then discuss them with the patients. So there was this whole care pathway involved. To make it work, we needed logic that would trigger certain actions when something was completed, or take a different path if it wasn’t. We had hoped to use Canvas to handle some of this orchestration, but it just wasn’t feasible.

How did you find the sales process overall with Canvas?

Overall, our experience with Canvas was positive, and they were easy to work with. We liked that they weren’t too formal. They didn’t make us go through a bunch of sales hoops where they qualify you, have meetings upon meetings, and so on. We really appreciated the straightforward approach.

And in terms of implementation, how was the setup process?

We had a really great implementation manager working with us who had a lot of experience in healthcare. We were benefiting a lot from her expertise, not only in setting up Canvas, but also in integrating with other systems like Health Gorilla and Surescripts.

Did you integrate Canvas with any other products in your stack?

We used Health Gorilla and Surescripts. I have to give credit to Canvas for that. They really did a great job and helped us out a lot as a new clinic. We didn’t have much experience with setting up these integrations, so it was a bit overwhelming for us. But Canvas stepped in and guided us through the process of establishing those relationships for the first time. They were really helpful in that aspect.

We did do some basic API integrations between our onboarding flow and Canvas, but I’m not sure if it’s accurate to even call it a proper integration. We only ended up using a handful of Canvas APIs (less than 10).

How is the ongoing support from the Canvas team?

The implementation plan they had in place was built around the idea that when you open a clinic, everything needs to be ready to go on that day. And then around eight weeks or so after the go-live date, they considered the implementation process complete. From that point on, we were supposed to rely on their regular customer support. However, this model didn’t work well for us because we intentionally took a slow approach to ramping up. In the beginning, we didn’t need much support, as we could handle a lot of things ourselves. So once they said implementation was done, we had a more difficult time reaching out to customer support and getting the assistance we needed.

So to summarize, while the implementation itself was great, with a responsive team and a Slack channel for communication, things became more challenging after we were out of the implementation phase when the communication shifted to email-based. I have to give them credit though, as they do have a pretty good knowledge center with helpful videos and other resources.

Do you feel like you made the correct decision to go with Canvas?

Overall, I feel like we were too optimistic about what Canvas could actually deliver. Specifically, given the marketing of Canvas as a headless platform, we had high hopes for using it to power our mobile app, but it seems that wasn’t how the system was designed to be used. When we were initially talking with Canvas about our intended use cases, they didn’t mention any limitations, such as potential performance issues or lack of caching. It’s possible that they may have over-promised, leading us to believe in their product more than we should have. As a result, we have now reached a more realistic understanding of what can be accomplished with Canvas.

As a digital health company, you don’t always have the legal knowledge and resources to extensively examine whether you truly need an EHR, so the default tendency is to play it safe and opt for an EHR. If I had the chance to redo it, I would explore the concept of having a HIPAA-compliant CRM system instead of an EHR, especially early on when we only needed limited clinical functionality. This doesn’t necessarily mean we wouldn’t have still chosen an EHR, but it is possible that, depending on our specific clinical activities, billing processes, and involvement with insurance, an EHR may not have been essential, despite the typical perception within healthcare that you need one.

Any advice for buyers who are going through this decision-making process right now?

One thing to consider is that Canvas, despite being a relatively modern company and pursuing this headless approach and striving to be a modern EHR, seems to assume a pretty standard clinical model. They have the standard conventions in healthcare where patients have appointments with individual providers and come into the clinic, each patient has one main provider, etc. So their object model follows those conventions. Despite being flexible in some ways that other EHRs are not, Canvas is still an EHR at its core. If you’re trying to implement a different type of clinical care or have a different care model, you might struggle to fit your unique needs into Canvas’s predefined structure.

If you’ve already determined that you actually need an EHR, I would still suggest considering Canvas. It may not have the most extensive range of features, but that’s not necessarily a downside. If you only need to meet the basic requirements, then Canvas could be a great fit for you. So, if your clinical needs are not too demanding, I think it’s worth giving this tool a serious look.