Elation

Note: We spoke with two individuals at the same time, so we’ve used normal text for one of the speakers, and italics for the other.

We’re talking about Elation, and how it’s being used at your company. Before we jump into that, could you give maybe a brief overview of the company and what your roles are there?

Yeah. So we do virtual specialty care for women with chronic hormonal, metabolic, or gynecological issues. We pair them with a medical provider, and a registered dietician to come up with a care plan and health goals, sort of work with them through medication and lifestyle adjustments to help them achieve those goals. I’m in charge of our product and engineering teams.

I’m the Director of Operations, I oversee our clinical, insurance, concierge, and customer support teams.

Awesome. It’s great to meet you. When did you guys purchase Elation? And how long have you actually been using it in production?

We purchased it in June or July 2021 and started using it in production a few weeks later.

Wow, that was fast. What’s the work that Elation is doing for you?

So Elation is our complete comprehensive electronic medical record. We first send patient intakes to Elation. We schedule appointments. The full patient’s chart is in Elation with their clinical information. We order labs and receive results. We order medications; we refer out to specialists; notes from visits, billing, etc.

Yeah, for some color on where it sits in the product: we use a different system for scheduling. We use another tool for scheduling the appointment record, so that’s our source of truth for the appointment. The appointment record is then shared with our database. Our database then creates a copy in Elation so that the providers can see their schedule there. Once that’s created in Elation, that sends out the form to the patient, and those are Elation forms, they fill them out… anything from there is fully in the clinical experience in Elation.

Basically, as soon as you get the scheduling component into your database, that triggers an API call over Elation’s scheduling and appointment API. It creates it with Elation, and then you’ve configured the product such that it automatically sends out the appropriate patient forms from there.

Exactly. And when a patient becomes a patient, their chart is created by Elation so they don’t need an appointment to be a patient there. But that sort of kicks off like the main workflow. I will note that we use Elation in a sort of headless way, where the patient is never interacting directly with Elation. Instead, the patient interacts with our patient dashboard. The only situations where they might see it is in their intake forms, since those are hosted through Elation, or if they request their medical records, we would send them credentials for the Elation Portal so they could log in.

Got it, that makes sense. So it sounds like the main work or the bulk of the function that Elation is providing is on the clinician side. I’d love to understand, from a clinician’s perspective, how they like Elation. How did it stack up against other products that you might have been evaluating at the time?

I can speak to the clinician’s perspective. They like it fine. I think if you use one EMR, you can use Elation. It’s really user-friendly. Plus, I think Elation was built in a very similar format to traditional EMRs. So it’s really easy to learn. It’s not as quick as an Epic. There’s a lot more clicks, so to speak. And workflows. I think the biggest frustration is likely the intake forms for us for our clinicians.

What’s the friction there?

Well, it’s a web page that is hosted in Elation and they’re not very flexible, so there are only a few types of questions you can use. So if you want to do anything custom, the only other question type is “Other”, and it’s just an open form field. So when you compare it to a more digitally native tool, it feels like a very dated intake form experience. And because it gets sent via email to the patient, there’s not a great way to take another type of form and use that instead, so it’s really a clunky experience. We’d like to do something where we use another tool for forms and submit it via the API.

The clinical experience is pretty typical of what clinicians are used to, within an EHR. Most of our clinicians are part-time, so this isn’t their full time job. As a result, we don’t have a lot of time to teach them brand new software and expect them to go up a really steep learning curve, so it was important for us to have something that they know and are already familiar with. We talked to other vendors that were also technically savvy, but the UI didn’t look as familiar to our providers. We were aiming to find something that was in the middle of the traditional EHRs and the more tech-forward, newer EHRs, which we also evaluated, but found them to be a little too different from a UI perspective, or not yet feature-complete.

Did you find Elation to be very opinionated in its workflows? How did you feel about creating your own charting templates and clinical workflows that may be different from the standard configurations?

We did appreciate the ability to create our own visit note templates; we do that frequently. Our medical providers like Elation a lot. However, Elation is less of a fit for our dieticians and their workflows. From the beginning, there’s no way to set up a registered dietician. We set up their account as we would a medical provider. It’s the same structure and they’re just different types of clinicians. Also, dietician note templates need to be different, more detailed, and have more variability for dieticians.

That makes sense. Are there any features that don’t work the way that you need them to, causing you to modify your workflows or supplement with external products?

Yes, the biggest thing that comes to mind is lab results. For our practice, we require partial lab results – they allow us to re-order labs if necessary before they are finalized. Our clinicians like to see those initial results. However, we’ve had to modify our workflows because that’s been challenging to do.

Yeah, so it’s like “Yes, you get notified when a lab is back.” But we need to know what the status of the order is, and that the lab is back, before we tell a different system that the lab is back. So there are little ‘gotchas’ in their API that sometimes we think we can do something and then as you dig, dig, dig, eventually you hit something where it’s like, “Oh, there’s not actually enough coverage there for us to effectively make this workflow work.”

So I don’t know if there are any features in Elation where the features just don’t work the way we need them to, maybe Intake Forms. But in a perfect world, if we had an EHR built directly for our needs, there would be a section for pregnancy history, women’s health history, everything related to specialty care, and that doesn’t exist in the chart. On the dietician front, there should be a more robust lifestyle section around food, diet, and the like. I feel like that sticks out to me the most in terms of having to modify the Intake Forms quite a bit to get around that. So most of the workflow issues we’re facing are because of integration limitations.

What I’m hearing is that they have the basics down: ordering medications, ordering labs, maybe with the exception of partial labs, but from a clinical perspective, they kind of get the job done. Where you would want to see changes are in customizing the UI a little bit more, storing structured data in a better way for you, enabling more integrations and swapping out technologies. Is that correct?

I would say so.

Yeah. We anticipated that there would be certain aspects where we could create our own user interface and allow patients to use it in their own dashboard, but the main thing we were prioritizing here was a seamless clinical experience, where taking notes, ordering medication, and other tasks feel intuitive and natural.

Yeah, just out of curiosity, I have a question that may involve some sensitivity analysis. If your providers weren’t contracted or part-time, do you think you would have still made the same decision?

That’s an excellent question. Personally, I lean towards the “never build your EHR” perspective from a technical standpoint. So perhaps I would have been more open to something innovative, highly virtual, and extremely flexible. However, even if all the providers were full-time, I still believe there is value in providing them with tools that feel intuitive for their use. If given the option, would you switch to a more flexible tool?

That’s a difficult question. My goal with the providers here, even though they are contractors, is to have them focus on what they do best, which is practicing medicine. The current format we have is the easiest way to facilitate that. So, I’m not entirely sure if I would consider switching to something else. I think it does make sense to stick with what we have.

It sounds like you have built pretty extensively on top of the Elation product. You’ve developed your own patient experience using Elation as the underlying data store. Is that correct? Or do you have your own separate database?

We have our own separate database. Elation serves as our clinical data repository. Our database complements it with additional features that a traditional portal wouldn’t have, such as CRM-like tools. We use another platform for that purpose. I see it as enhancing the Elation experience from a provider standpoint. It creates a digital-friendly environment with messaging, tasking, and other tools. It’s highly flexible for us to incorporate, and both systems communicate with our database, which serves as our primary data store.

Got it. And how does your patient-facing portal interact? Does it communicate with your own APIs or Elation’s APIs?

It interacts with both. There are certain areas where uploads, like labs or insurance information, go directly to our patient experience and then get transmitted to Elation.

It sounds like you had to interact extensively with Elation’s APIs. How was the process? Did you find them to be robust and comprehensive?

Overall, there is a substantial amount of functionality available. Sometimes you need to dig deep to address specific issues, like the case of partial labs that initially weren’t covered. We raised this concern for about three to six months, and eventually, it was addressed. As a whole, I would say the APIs were reliable. The documentation could be improved, but that’s typical. Individually, they seemed to work well. We haven’t encountered any significant speed issues. There is a wide range of capabilities, and for relatively straightforward tasks, such as data transmission from us to Elation, it’s quite straightforward. We don’t usually encounter many unexpected hurdles unless it’s something niche that we didn’t anticipate.

It sounds like bi-directional syncing capability of Elation’s data is really strong. What’s the best way to architect an EHR that combines clinical data with non-clinical data that doesn’t fit neatly into a FHIR format? If you have different applications interacting with the system, how would you approach designing such a system if you were to build it from scratch?

Take my response with a grain of salt since I’m not an engineer, but here’s how I think about it. Our database is the primary place where we capture data. We aim to position our backend between the patient experience and the clinical tools we use to create a layer of abstraction. This means that if we decide to switch to a different EHR or tool, it’s not directly integrated into our patient experience throughout. Instead, we have multiple points of data integration, so if something goes wrong with Elation’s API, we avoid sending data into the abyss. That’s the general advice I’ve received, to architect the system in a way that the patient experience isn’t entirely dependent on a vendor API, especially when dealing with older EHR systems. We try to minimize redundancy and avoid storing excessive clinical data in our database, while still being able to reference it when needed. So, we aim to reduce duplication while maintaining the ability to look across systems when necessary.

When we first started, we received advice to keep the experience we care about, our “special sauce,” within our own system. For most virtual care companies, the charting experience and how family history data is stored is not so unique to the business that it can’t be managed using the links the database provides. However, certain aspects, like the care programs and the steps patients take in their care journey, are vital to us. Those need to be directly accessible to us at all times, so we wouldn’t incorporate them into our EHR. Instead, we ensure we have direct access to them whenever needed.

That makes a lot of sense. It’s an interesting paradigm that differs from if you had chosen a solution that focuses more on pre-built patient-facing workflows with white-labeling.

Absolutely. We evaluated many of those options, and one of the factors for us was wanting to have control over certain aspects. So it really depends on what you’re trying to achieve and at what stage you’re in. I know some people who use certain tools for the first year and a half, and it works well for them because their primary focus is on testing the quality of the service, rather than being concerned about the UI. It’s a valid approach as well.

I’m curious to hear about any integrations you implemented with Elation. Did you supplement the product with different integrations?

I think Candid is a significant integration for us. I’m not sure if the lab integrations are specifically what you’re referring to, but I’m grateful that I didn’t have to handle those integrations personally.

We decided to utilize Elation’s eligibility check, which is integrated with Change Healthcare. So we perform eligibility checks for our patients. Additionally, we have a broader integration with Candid for revenue cycle management (RCM).

How was your experience with the eligibility checks? It sounds like it was pre-packaged and didn’t require much setup on your end, is that correct?

Mostly, but there was some backend setup involved to connect eligibility payer IDs and insurance IDs.

It’s worth noting that almost every product claiming to have an eligibility check feature is essentially utilizing Change Healthcare behind the scenes. Even with Candid, their eligibility check is powered by Change Healthcare. It’s interesting how it’s a commonality among different vendors.

Just out of curiosity, why did you choose to go with Elation’s native eligibility check instead of Candid’s option?

We opted for Elation’s native eligibility check because it allows us to see the eligibility status in real-time before the patient’s visit. I don’t believe Candid offers the same functionality. So as soon as a patient uploads their insurance card, we can check their eligibility. It also performs an eligibility check the night before the visit to ensure it’s still active.

That makes sense. Regarding Candid, what was the setup process like, and how do you feel about the integration quality?

From my perspective, the setup process for the integration between Elation and Candid was seamless. I didn’t have much involvement, to be honest. There were a few initial calls, but then it was handled on the technical side. Elation often handles integrations by simply enabling them for you, and then you’re good to go without needing to think about it further. I’m not sure about the setup process on the Candid side, but in terms of getting the data flowing, it was a straightforward experience.

Do you feel that the integration with Candid is bi-directional? Can you see the status of claims within Elation, or is it more of a “fire-and-forget” approach where you have to go into Candid to interact with the claims?

You have to go into Candid to interact with the claims. However, if there’s an issue with a claim before it’s submitted, it will send it back to Elation as well.

I see. So you’re able to quickly fix claims within Elation, leveraging the clinical notes at your disposal for making corrections.

Yes, for certain errors based on the information from the insurance card, we can make corrections in Elation. It’s quite convenient.

Regarding the account management support and onboarding process, how do you feel about the overall experience and support from Elation?

I love their team. They are easy to work with and very understanding. Whenever we ask for help with urgent matters or highlight specific issues, they are responsive and supportive. For example, when we had concerns about lab partials or other issues, we reached out to them, and they were attentive. We have been working with a specific person from their team for years, and recently, we were assigned a new account manager. We have monthly calls with them, and I often send them questions or items in advance to discuss. They are always available and will bring in an engineer if needed. In the vendor universe, it has become common to struggle to get in touch with an engineer on a vendor’s team, but Elation makes that process easy. I truly appreciate their accessibility. Additionally, if we make a strong case for a specific feature or improvement, they may ask us to write an impact statement explaining its importance, and they bring that to their team. This shows that they value customer feedback and are willing to make changes based on it. I have only positive things to say about them. They were incredibly helpful during the initial setup, and we had numerous calls with them. They were always available and eager to assist. In terms of support, I don’t have any major concerns.

I agree. Our monthly meetings with them are great, and I appreciate their receptiveness to our feedback and their dedication to quickly resolving any issues. However, the support within the interface itself can sometimes be a bit slow, but I haven’t encountered any major problems that required urgent assistance, so overall, it’s been great.

I remember talking to someone from a larger company who used Elation, and they mentioned that getting good service was easier for them because of their size. Initially, I was concerned that being a smaller account, we might not receive the same level of attention. However, I keep detailed notes about our needs and communicate them clearly during our monthly calls. I always mention specific pain points, such as labs or other issues that need attention. While certain features may not be implemented immediately, they are transparent about their roadmap and release timelines. They provide insights into what they plan to address in the next three months. If a feature is not coming soon, they let us know, and we find workarounds. I appreciate their transparency and the fact that they involve us in their development process. They have a list of digital companies that they collaborate with or discuss innovative projects, and they involve us in beta-testing or seeking our feedback. It feels nice to be a part of their development journey.

Indeed. I’d like to return to the original procurement decision. Which other products were under consideration? And ultimately, what tipped the scale in favor of Elation?

We evaluated Athena, Canvas, and Akute Health. Pricing played a significant role, and we felt at the time that Canvas was too expensive, though they might have changed their pricing model since then. Regarding Athena, we had heard great reviews, but their pricing model based on the number of API calls can escalate costs quickly. There can be a lot of back and forth just to access certain features. In the end, both were too pricey for us given what we needed and their pricing models at the time.

Akute Health was a strong contender; we were close to selecting them, but the product was still too nascent at the time. When we needed to get things running in a matter of weeks, it became evident that some critical features were still in development and not ready for use. For instance, labs and prescriptions, two vital features for us, pushed us towards an EHR instead of building our own solution. I’m not sure if this is the case anymore, but at that time in 2021, Akute required an extra integration for labs, which didn’t make sense for us.

Let’s return to Elation. Could you share some final thoughts? What do you like most about the product?

From my standpoint, I appreciate that they are open to collaborating on problem-solving. The reliability of the product is another strong point – there are minimal outages, and it performs solidly for the most part.

From a clinical perspective, the usability is a standout feature. It’s straightforward to train new providers and onboard them. Additionally, Elation interfaces well with traditional healthcare systems, which facilitates the process of giving and receiving referrals.

What do you dislike most about the product?

It’s not the first time we’ve pointed this out, but their form management needs improvement. This is where Formsort shines. Building forms is tedious, and finding a vendor that excels at it can be a game-changer. We’re likely to use a service like Formsort for our forms. It’s a fickle thing.

Looking back, do you feel like you made the correct decision in choosing Elation?

Of all the decisions we made two years ago, this was one of the most solid. I’m genuinely pleased with the outcome. Even if it only got us to where we are today, I’d still be satisfied with it. I haven’t had to worry about it as a part of the product for quite some time. While that’s not the only metric, it’s a comforting aspect. The product scales well, which is another advantage.

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

I always recommend having in-depth discussions with your doctors or clinicians. Understand as if you’re going to build the product down to each feature because that’s where you’ll find discrepancies. Everything sounds amazing when vendors pitch. However, you may realize that they aren’t catering to a crucial aspect of your needs.

It’s essential to thoroughly understand your current and future (about three years out) use cases considering the business model, insurance, and so on. Speaking with customers who resemble your business model and asking them about their preferences is highly beneficial.Most of the useful information we got came from customers. The information the vendors provided was just the tip of the iceberg. We asked numerous customers about their EHRs, which significantly influenced our final decision. So, in my opinion, that’s the best way to go about it.

The advice about sitting down with clinicians and understanding their needs is spot on. Especially clinicians who have practiced telemedicine before as their needs might differ significantly from those who have only practiced in-person. Additionally, it’s important to consider how the EHR integrates with other platforms you use and how it fits into your patient engagement strategy.