Elation

So today, we’re talking about Elation, and how it’s being used at your company. Before we dive in, could you give a brief overview of your company and your role there?

Sure. Our company helps people build the families they want with fertility care. We’re three years into it, and we launched telehealth fairly recently, so we’ve been building both the operational and technical stack to support that over the past six to nine months. I’m a co-founder and the Chief Product Officer, leading the technical side of our company.

Awesome. When did you purchase Elation, and how long have you been using it in production?

We purchased Elation in April, and we launched telehealth at the beginning of June.

So you’ve learned a lot about what actually works, maybe what doesn’t work. I’d love to learn more about your workflows and how your users are interacting with the product.

Yeah, so the way we use Elation overall is as a clinician-focused application, as opposed to a patient-facing application, which it is not at all. And largely, it’s about the things we don’t want to build. We don’t want to build clinical documentation. We don’t want to build lab-ordering interfaces. We don’t want to build billing processes and flows. And so that’s what we use it for, just the basics of truly clinician-facing experience.

To double click into our workflow, most of the patients’ experience happens through registration, onboarding, intake, etc, which happens before they ever see a clinician. One of the challenges with Elation’s scheduling flow is how it’s really a closed system. So when we actually go to schedule, there’s no way really to pass data between our application and Elation’s system through their scheduling interface. They won’t allow us to put an iframe into their scheduling application, and there’s no way to get our user ID into their scheduling workflow, so we can have a lookup key to map our patients across their APIs. That’s a major frustration of mine with Elation. I have been very direct with them about that. There are workarounds, so what that really means is that I can’t use Elation’s scheduling directly.

The other piece on scheduling is consent forms and the way that their forms work is not very flexible. For example, you can’t do signatures, so we can’t really use that feature either, and you need that to do telehealth. In other words, it just feels like the scheduling and intake process is one that Elation decided they’re not going to focus on, and that’s fine, but it does mean you need to find another solution.

Once our patients are created, we create their charts. Today, we do that manually, but we’ll do that via API in the future. We populate those charts with information from our intake process. Today, we’re doing that with care coordinators, and in the future, we can do it via API, but we need to get this scheduling issue fixed. And then from there, our clinicians have an initial visit, follow up visits, order labs, do billing, do coding, and document from there.

We’re also going to build some integrations with other EHRs. Most likely, starting with Athena, potentially eIVF, and a few other EHRs. So that would be where things go from there. But the reason I chose Elation was I didn’t want to overbuild and they’re really good at the basics of clinical workflow: documenting, billing, ordering labs, and prescriptions. They got the basics right; they got the seal of approval from my clinician that it works for doing their clinical visit and taking the right next steps. In terms of the billing piece, we can choose how and what integrations we use for that, and we feel pretty good about the way we’re setting it up.

With some of the workarounds you’ve mentioned on the scheduling side, does that mean that you have operations folks that are filling in those gaps, or did you write code to fill in the gaps?

Today, we have operations folks to fill in those gaps, with a little bit of code. In the future, we’re going to likely use Acuity for scheduling and use APIs to write code to do it. The nice thing about Elation’s API structure is that its reads and writes are comprehensive and robust. So for example, we write to our database that there’s a new patient, and they’ve got a schedule as part of the new scheduling API, and we’ll use the API to create a chart in Elation, and that’s how we can pass the patient information. So that’s the workaround that we can use, which is perfectly fine. It adds a couple of months to that workflow being available, but in the long term, I think it’s probably better that Elation is just good at what they do, and they leave scheduling to people who focus on scheduling.

I think maybe one of the things that is implicit in that statement is that it sounds like Elation makes it a safe operation to plug-and-play with other types of vendors because of the way that their API is structured. Is that correct?

That’s right, exactly. All I wanted was a clinical workflow that my clinician was happy with. And then as you describe it, their API is robust enough out-of-the-box that I run very little risk, and I’m also not boxed in to anything when it comes to the patient experience or anything else.

So it sounds like you’re planning to build and extend the platform, especially once you add Acuity and some of the other things. Have you already used the API?

We have not. We tried a few things out in the sandbox to test it, but until we have that unique patient identifier that sits in both places, we can’t do anything. There’s no point in us doing anything automatically because if one part of the flow is automatic, but the other part of the flow is operational, then we don’t know which thing is working.

Yeah, that makes sense. So that’s like a pretty key. Have they been responsive and reactive to the issue that you need to pass your own unique ID through their APIs?

We’ve discussed various ways to solve the issue and have talked directly to the scheduling product person, but I don’t think this is a priority for them. The issue is that the Elation scheduling page is its own page, and there’s no way to embed anything. So when a user clicks a schedule link, they are sent to a page on Elation.com, and we can’t pass in any parameters.

I’m just wondering, how do other people do it?

My assumption is that most people don’t use their scheduling functionality. It just isn’t very robust at all, or it’s not made for a telehealth practice. It’s more geared towards a physician’s office, and it’s perfectly fine for that.

Did you get any out-of-the-box integrations with Elation?

We use Spruce Health for our HIPAA-compliant one-to-one texting, and we’ll probably end up using Candid Health and Hint Health at some point as well. There are pretty good integrations with those two as well. With the Spruce integration, everything’s fine; it could be a little tighter, more bi-directional. One of the hardest things to tell when you’re evaluating new software is how deep the integrations actually are.

I’ll give you an example. Elation was promoting their Zocdoc integration. So we wanted to see if we could use Zocdoc and its API for scheduling since it’s already integrated with Elation (in theory). As it turns out, the integration was not a very deep one, and it would not have been very useful for us, whereas the Spruce Health integration is relatively deep to the point that it is genuinely useful. And it’s hard to tell the difference between the two in any sales process. You can’t go down every single rabbit hole, and I think that’s a real challenge for anyone in our shoes to figure out. You kind of have to pick your five or six things you really want to push on, and everything else is gravy.

Before we started the call, you mentioned you were also looking for something to tie up your SMS and email. Can you help me understand how you’re using Spruce right now?

We’re looking at some tools for email and text-based patient engagement, which is different from patient care or coaching, which is one-to-one and manual, very much in the weeds of a patient’s specific situation, tied in with their health data, etc. For us, Spruce fills that need, and we’re happy with the way it works. It helps us not to lose context in the chart, and the Spruce integration into Elation’s charting is important for us. That’s different from how we think about patient engagement, i.e. “You didn’t finish signing up”, “Here’s an offer for you”, or “You’ve got your first appointment coming up in two weeks.” The latter are specific workflows and patient journeys that can be set up beforehand. They still need to be HIPAA-compliant, but it’s a different sort of tool than what we’re getting with Spruce.

Yeah, that totally makes sense. Going back to your procurement decision, you were looking at a couple of different providers. Who were you stacking up and then how do they stack up?

The three we looked at were Healthie, Elation, and Athena. Healthie has a decent amount of buzz in terms of, “Hey, it’s this new thing”. But Elation just makes sense to me. The way that they position themselves has always made sense to me. With Athena, a lot of our provider partners are on Athena already, so they’ve got a lot built in. That’s why we had those three.

What ultimately made Elation the right product for you?

It was in the right box and it didn’t veer too far outside of that box. So for us, the box we needed to fill was a clinical workflow with extensible labs and billing options. Athena tries to be more than that. They’re still clinically focused, but they felt like a very heavy solution for us, along with a price point to go with that, and their pricing structure didn’t really make sense for us as a startup. Over time, it makes more sense, but not now. And then Healthie felt like it was coming from patient into clinical, and the two experiences were tightly coupled in a way that I didn’t want it to be.

You mentioned pricing structure. Do you recall how the three ranked or how the three compared on price and pricing structure?

Elation and Healthie were pretty comparable. When you looked at all of the options, it would end up working for us at a certain scale, with less risk as we scaled, and Athena was more expensive to start, but with fewer scaling risks.

How did you find the sales process overall?

What we’re paying for was much more transparent with Elation and Healthie than with Athena. Athena was just sort of this machine. It was clear to us with Athena that it would work for us, but they weren’t targeting those that look like us, right? It just wasn’t friendly, despite talking to the right people. They just didn’t have the right levers to pull for a company that looks like us.

You mentioned earlier that you’re doing billing in Elation now and it seems to work. And you also mentioned that you’re looking at maybe going to Candid later. Can you help me understand the driver there?

It’s more about our business model, and the way that we work with providers as our partners. To some extent, it’s more a degree of automation and integration made possible with Candid, than necessarily requirements to meet. I think Candid is just more of a robust solution over time that we’ll need.

How did you feel about onboarding, implementation, and the overall customer support you’re getting with Elation?

It was generally pretty good, but we still felt like a small fish with them. There’s no special service or anything, you just get an account manager and work with them. They still feel like a small enough company that you can do things like, “Hey, can I talk to the product leader for scheduling”, or they’ll offer us the opportunity to be a part of the beta group. Things like that. So that’s been nice. From that perspective, it feels like the right balance for us. We’re not going to be a big fish yet, but we do have some level of access, which is nice. With Athena, I don’t believe that would be the case. With Healthie, I think that might be a selling point for them.

What do you like most about the product?

It makes my clinician happy.

What do you dislike most about the product?

I can’t get my unique user ID through their scheduling workflow.

What’s the likelihood of you continuing to use the product in two to three years?

I’d say greater than 80%. I don’t know what happens at scale yet. I don’t see another product that exists right now that I would move for, but I could see us building my own. At some point, if my workflow is so unique, and the scale is so high, then it’s really just documentation, and I can build my own documentation.

What could Elation do to keep you?

Better pricing at scale.

Do you have any advice for someone selecting this type of product right now?

Yeah, the reality is when you go through evaluating these products, you can only get so deep. Even with what Elion is building, that will help, but you still end up needing to choose the core of what you need. For us, we needed something that was going to work for our clinicians and be extensible, at the right price point. And Elation is the prototype for that idea, and that’s why we went with it. And I think that really clarifies things for the shopping experience.