Elation

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

That company was focused on delivering virtual care solutions. We started out owning and delivering in the virtual urgent care and behavioral health space. During the course of the pandemic, we realized that there was an opportunity to start owning more of the patient’s care virtually. And so we wanted to pivot into virtual whole-person care, specifically virtual primary care, and really own that primary “relationship” with the patient, with all the wraparound services around them. My role with the company was to lead the clinical platforms team. And so we were really responsible for the way that we data across the platform.

When did you actually procure Elation and how long had you been using it by the time that you left?

We procured it in the summer of 2020, I believe. We had contracts in place around August and we launched in October so it was a pretty quick turnaround time between procuring and launching, which is one of the major reasons we went with Elation to begin with. It had been live for about 10 months before I left.

I’d love to better understand how you used Elation within the organization. Who were the users that were interacting with the product and what were their workflows?

There were two primary users. One of them was what we called our Clinical Operations users. Those were the nurses, the MAs, that were really responsible for prepping the visit and prepping the patient, gathering some key bits of data ahead of the visit for the physician to be able to use. Our other set of users were the physicians themselves, who were documenting the clinical visit within Elation.

Patients didn’t interact with any Elation-specific portals?

No, we wanted to own 100% of the patient surface area. And so one of our goals was that the patient would never know that we were using any EHR, whether it be Elation or anything else, underneath the covers. It was purely a branded experience for them.

What were some of the features that you used with Elation? What worked well and what didn’t work so well?

Outside of just clinical documentation and CPOE (computerized provider order entry), and all the functions that come with EHR as part of facilitating a visit, we had some scheduling and practice management capabilities (messaging between team members and that kind of coordination between team members). We wanted to eventually move that out of the Elation platform and into our own stack, just so we could own much more of that overall experience management and really hone in on Elation being our clinical documentation system, more than anything.

Were there any features that you were actively using, but that you felt didn’t necessarily meet your standards?

There was a simplicity to Elation that we really liked in one instance but then also felt, perhaps, a bit limited in terms of our ability to create visit templates, for example, or really flexible flow sheets. Elation, to a certain degree as software, was very opinionated on how you should capture clinical data. On one hand, that made it very simple for us to deploy and for us to train around. The physicians got used to clinical documentation very quickly. But on the other hand, it really did limit us in our ability to really customize visit templates, especially considering that we were a virtual modality. So I think that simplicity was a bit of a double-edged sword for us.

A couple of other areas: the referral functions and the ability to send direct messages; I think the functionality was there. We were happy with it. It probably could have been a little bit more robust in terms of the types of documents that you could attach and the provider directories that were associated with it. And the configuration around that – message templates, for example.

On that point, did the referral directories come pre-installed? Or did you have to configure them?

We didn’t have to configure it. It was a bit of a hybrid, so we had certain instances where we were configuring destinations. But, to a certain degree, there was also a Direct Trust referral directory that we had access to use with Elation if I recall correctly. And then messaging, I think, was also one of those double-edged swords where messaging worked, but there was some confusion around who had access to those messages, what sort of queues we could set up based on what different clinical pods were and message lifecycle around that. I think Elation had put some good thought into it, but that was something that was continuing to evolve.

Were there features that you didn’t use, either because they didn’t fit into your workflows or potentially because you didn’t feel that they met your needs or they weren’t up to par?

So one thing that was really missing was a really solid billing module and integration. Elation had gotten their start in direct primary care. And so billing was definitely an afterthought. We understood that going into it. And while I had mentioned that the majority of our customers were direct-pay, there was definitely a move towards MA-sponsored populations at some point and potentially taking on or working with commercial payers directly to be an in-network provider for them. And so, it limited our ability to potentially leverage their billing module directly. We had to layer in a separate external billing module instead. Review workflows around coding and whatnot were also maybe something that we didn’t necessarily use quite as much just because of some of the limitations of that billing module.

Apart from that I don’t want to say that we didn’t use them because they were deficient, but we didn’t really use patient education materials. We didn’t really use any sort of UpToDate integration or anything like that, either. Frankly, I don’t know if that existed at the time – if that integration existed. And then from an API perspective, there were really no standards-based APIs that we were able to leverage at the time. I’m sure that’s changed since I’ve moved on, but they had a custom proprietary API. It was something that was continuously evolving. And so, that was something that we would have to build directly, as opposed to leveraging something like FHIR.

For what it’s worth, I think they have opened up their API somewhat more recently.

I think they had gone through a series C just after we had made our investment and had purchased them. And so I think a lot of the funds that were coming in through that series C were going to be allocated towards building out much more of a robust API and standard support around it. I think that was the right thing to do.

Did you end up using the API or extending the platform in any way? Or did you use it as was?

We actually ended up using some of their patient registration stuff. So we could create visits on the platform and then have those visit IDs flow through the rest of the platform. We were planning on doing clinical data integration but clean data integration is extremely difficult. Syncing clinical data between two disparate systems is really a deceptively difficult exercise. And so, as we started to explore the complexities of that, we wanted to focus more on how to make the lives of the MAs easier so that, as they’re flipping between platforms on visit scheduling and visit management, into Elation, we wanted to make sure there was alignment between the visit structures between our two platforms.

At a high level, how did some of those integrations work? What were the workflows that you implemented and what was that process of implementing the workflows?

Ultimately, it was defining the entirety of the visit cycle. So we had pretty robust swim lanes in terms of system responsibilities for each part of the visit and what they use, what system of record the user was operating in. So, you know, one of the first things we did was implement SSO between the two systems. And then we wanted to have the ability to create visits, the moment that a visit was requested, within our core technology. So, there was that visit creation interface. And then there was some management around that if a visit was rescheduled or moved or canceled, or whatever that sort of visit lifecycle management was. Once the visit was completed, we were notified within our platform that it had been completed. So there could be some post-visit tasks that were kicked off and. We did have one clinical interface in terms of pulling a patient’s visit summary, so that we could embed that within our app, or give the patient visit summaries after their visit.

We were looking at integrating lab data, medication status, medications list, problems list, allergies lists, etc. That was not work we had really started in earnest by the time that I left. It was more in design. And the APIs were available to do that. So it was more around us just spending the implementation cycles internally to leverage those APIs and really understand the data workflow between systems. What I mean by that is, if you’ve got a patient that’s reporting a problem through an urgent care visit that Elation is not being leveraged for, how do you ensure that that problem list is accurate in Elation by the time their primary care physician looks at the record. And vice versa, if there’s a problem that’s reported within Elation, how do you make sure that propagates to our other modalities so that as the patient has behavioral health care or urgent care with us, we’ve got a really accurate problem list without a bunch of duplications. So we had resorted to mechanically tracking that information, because it was just so difficult to maintain consistency and integrity across these disparate systems. Again, those were outstanding problems on our end, not necessarily with API. Those are just difficult problems to solve.

I’d be curious to dive into off-the-shelf integrations that you might have used. Did you supplement any product functionality? Or integrate it with other tools in your stack, beyond just extending and syncing clinical data? Maybe this isn’t a good question, because you built a lot of your own tech stack, but a lot of folks buy an EHR, integrate it with their RCM software they purchase and do data syncing there. They’ve got clinical ops tools and other SaaS solutions that you can integrate with your EHR.

Yeah, most of our stack was homegrown, with the exception of our billing system, which was provided by another vendor. The vast majority of integrations that were going into and out of Elation were basically our code.

Going back to the original sales process and the procurement decision, how did you find Elation’s sales process overall?

Easy. We worked with a great salesperson there. We kind of stumbled onto Elation randomly. This was before Elation was large and well-known. We had kicked off a pretty rigorous search and we were segmenting the market in either large, traditional EHRs like Athenas and your AllScripts, NextGens of the world that were really ambulatory-focused. Then you had this long tail of much smaller EHRs like DrChrono, AdvancedMD, and others.

The benefit of some of the larger players was just that feature richness. There was that trust. My company was doing 14 million urgent care visits a year at that point. So, we were looking at something that we could get up and running quickly. We needed to launch quickly, but we also were looking for something that we knew could scale with us. So, I think some of the larger EHRs were super expensive and we knew it was going to take them a while to actually get up and running. There was going to be a huge amount of investment on our part for that. With some of the smaller ones, we could get up and running more quickly, but they were less feature-rich – there was less trust, less robust APIs, etc.

Elation, we found to kind of be in the middle, having a relatively robust API stack. Our clinicians loved the user experience. And they had promised us that they would get us up and running as quickly as we needed them to. To their credit, they kept their promise. We got through the procurement process in August and were up and running with some basic integration by October. That’s actually a pretty impressive feat. So, very much credit to Elation for being able to support that for us. But the sales process was easy. We went through a number of different negotiations. We fit outside of their traditional pricing structure, you know – a per-doctor fee didn’t make sense to us. And there were a couple of different rounds that it took to get the right pricing structure, but we eventually got there. It was considered a win-win for both organizations in terms of how we aligned.

You talked about the high level and heuristics of how you made your choice. I’d be curious about any competitors that you looked at more closely. I’m not sure if you looked at Athena more closely, or Drchrono, or some of the others?

Funnily enough, those are the other two. We looked at eCW, but there were a number of reasons why we decided to move away from eCW. So it was kind of like you’ve got Athena on one hand, where they’re super feature-rich and they’ve got the right API structure in place. We knew it was going to take us time to get them up and running. And this was a much more robust project plan that they had put together for us. We knew that internally, we needed to align a lot more resources to get something like Athena up and running. And that was going to be a massive investment for us. Their visit fee structure was really pretty rough at scale for us.

Then you flip over to the other side with DrChrono, where we didn’t have the best sales experience. We found that the user experience was horrible. During the evaluation process, we brought physicians with us to look at the user experience, because that was a huge part of our selection process. The physicians absolutely hated the user interface for DrChrono, liked it for Athena, and loved it for Elation. We were on the fence about DrChrono. We thought it was an economical option, but we understood the inherent risk there. We didn’t know enough about where we were going to be in one to two years, so we wanted to leave ourselves decision-making capacity to say, okay, a year down the line, do we feel like the approach of leveraging a lighter weight EHR works for us? Do we need something a little bit more robust and traditional? Elation provided us with a really good opportunity to get up and running quickly, start delivering visits, and do some basic integration and then re-evaluate where we were a year later.

In terms of the value or the price among different companies, how was it different? How did these three competitors compare on price? Are you comfortable sharing the pricing structure or the price that you ended up getting to?

I probably can’t share the price, but we landed on a per-visit structure, which made sense for us. I mean my company was getting paid on a per-visit basis as well, so that was just part of our COGS.The others, either didn’t align with our own COGS, or had a really rough platform fee structure with a visit fee on top, which would have required quite a bit of volume before we get to reasonable delivery costs.

Looking back, do you feel like you made the correct assessment at the time with Elation?

100%. I mentioned that a huge part of the decision was to leave ourselves outs, you know. When you make a massive investment in something like Athena, it’s hard to come off of that platform when you’ve invested so much in it. So the really nice thing about Elation was the lack of upfront investment that we needed to make. We were able to test the market as quickly as we possibly could, and get up and running. And, they ended up doing what they said they would do, in terms of getting us up and running quickly, and supporting us through the process.

Regrets would be that we didn’t invest as much into integration as we probably should have. We just used duct tape and gum for the launch, as most good product launches do, but I think there was an opportunity for us to be a little bit more scalable in our own internal processes and integrations coming out of the gate. But from the point of getting a platform that the physicians enjoyed, or at least didn’t complain about, which is a win in the EHR world, getting up and running quickly, and then giving us that decision flexibility down the line, it was a home run for us. I think we did a great job of putting together all the pros and cons for all these different options, and coming up with the right decision for the business.

I think you’ve touched on this several times, maybe it’s worth just talking about explicitly. I’d love to chat through the Elation setup and process implementation, and then subsequent support. So once you’d made the purchase decision, what was the onboarding and implementation process? At a high level, what were some of the work streams that you were doing? And how long did it take?

It was a month before it was actually deployed. We made the decision in August, and we launched in October. So it was a lightning-quick implementation. They gave us a test environment very quickly. Playing devil’s advocate with myself, it really did help that we didn’t have a huge integration, you know, to start. It was our clinical ops team. A lot of the burden fell on that team and they were willing to say: okay, let’s, let’s take on some more of these manual processes in favor of launching quickly and getting patients in the door. So, we were able to do that.

It was a very vanilla setup. We customized a couple of visit types and forms, but again, there was not a lot of customization possible with the system. And so we didn’t have to spend a lot of time really building up visit templates, because we just didn’t have the flexibility of being able to do that. So it was kind of like: Okay, let’s just use this visit structure that we have here. Honestly, the majority of the time was spent less on Elation configuration and more on just understanding and nailing down our internal processes for how we were going to flip between two systems and, you know, dual screen and “swivel chair” through that process. How do we make that as seamless as possible for our provider pool (which wasn’t huge at the time, thankfully)? But then also continuing to think about how we’re going to potentially scale that up over time and start removing some of the manual burden from our Clin Ops team members. So that was, that was really the majority of it.

We had an integration stream that was set up as well that was purely focused on building out an integration roadmap. And so we had two sets of recurring meetings, or two streams, with Elation. One of them was a general Elation implementation stream. And then you had another stream that was much more technology and integration-focused. That was really working through our integration roadmap. We were one of their largest customers at the time. And so we got a lot of white glove treatment from their team and had direct access to product managers and integration leads that I would imagine most people don’t get access to at this point. So that helped. We were able to influence the roadmap to a certain degree as well, and had a good understanding of where their roadmap was heading in general as well.

It sounds like you got a lot of attention. Do you feel like the support team that you had, the engineers that you were working with, were competent? In other words, did they have a fast response time and resolve issues fairly quickly for you?

Yeah, they were. We had a really great, initially, a really great implementation lead. She helped us work through training and setup and everything else – she was phenomenal. I think the challenge that they had was a lack of willingness to say no to a large customer. And so they were saying no implicitly, not explicitly, to things. What I mean by that is that we were, as most large customers working with a smaller company will tend to do, pushing them all over the place in terms of the roadmap, asking for requests. And what we were finding was that they were saying yes to us at the cost of previous requests, without necessarily us having that transparency. I think something that indicates maturity in a team when they can help a customer understand the tradeoffs for their requests.

That really wasn’t happening. That set us up for a surprise down the line when we found out all this other stuff on their roadmap that we were expecting had been abandoned because of our newer requests, and we weren’t really made aware of that. That was probably one of our biggest misses in working with Elation. But from an implementation perspective, especially as we were implementing some of their standard stuff, it was really pretty smooth. And they had a really robust set of documentation and training modules that were also really helpful for us through the process.

What did you like most about the product?

Honestly, the user interface and its simplicity was a selling point for us. The clinicians really loved it. It just worked. It was sensible and clearly designed by people that were delivering clinical care. Instead of taking a billing-first approach to EHR, which many traditional EHRs have done, they really took a care-first approach, which I thought was really commendable.

What did you dislike most about the product?

So, it’s a double edged sword, right? We were forced into certain ways of documenting. Sometimes there was a lack of structure and documentation that we really missed. The billing was pretty much non-existent. That was going to be a pretty big opportunity for us in the future. And then messaging, I think, was kind of a miss as well. It was pretty confusing the way that the team messaging worked in certain instances. Message lifecycle management, like inbox management, was really something that needed more attention.

Do you know if Elation is still being used today?

No, it’s not. And one of the reasons for that is the company wanted to move away from homegrown technology for their EHR stack altogether. And so they made the decision to bring in a much larger, acute-first vendor to really replace the EHR across the organization. And so Elation, I think, was a little bit of collateral damage with that. It wasn’t necessarily a knock on Elation. It was just that they wanted to actually standardize EHR across the entire company.

Is there anything that we didn’t cover that might be worth mentioning? Anything you wish you’d known while making the decision or while operating with Elation?

I would say, I think Elation has done a pretty good job at honing in on tech-enabled care organizations at this point. My advice would be to do something similar to what we did where we had a crawl-walk-run approach, and it was very sort of roadmap-y, right. We didn’t try to fully do the integration all at once. I would say maybe really deeply think about what your integration patterns look like, and ensure that you’ve got a really good sense of processes around using your existing systems alongside Elation or any EHR for that matter. And really think about what your critical path integrations that you must get done as quickly as possible are, and really invest in doing those. But apart from that, that crawl-walk-run approach of getting it up and running, getting used to using it, getting that feedback, and adjusting the system and moving forward that way, was the right one to take.

One of the best decisions that we made through the evaluation process was including physicians. One of our evaluation criteria was UX. And the evaluation came purely from the physicians – who cares what I think about the UX, right? It’s ultimately up to the physicians that are using it. And so having their input at the beginning, and having their buy-in helps from a decision perspective. Physicians carried a lot of weight at my company. So when we’re presenting to our executive team, ‘Here’s the decision; I want to bank our brand new, shiny products on this EHR company that nobody’s heard of in this room,’ having the physicians come in and say this is the experience that we need went a long way. That was one. And then two, when we were going through the rollout and adoption, there were a lot of concessions that physicians needed to make and the MAs needed to make in terms of user experience – like having to switch between two systems and the dual system nature of it. And so, the fact that physicians had bought in on the front end of it, like helped make the decision, really helped us gain traction through the end of it. So that was to me, bar none, probably the best decision that we made through the process.