Athenahealth

Today we’re discussing Athenahealth and some other technologies that you’re using at your company to help fulfill your workflows. Can you provide a brief overview of your company and your role there?

We’re a virtual women’s care company, and I lead the product and data teams, acting as the head of product and data.

When did you purchase Athena, and how long have you been working with it?

We purchased Athena really early on, before we even had a product on the ground. So we’ve been using Athena for a couple of years now, and really been using it in earnest for about 18 months.

So, you’re practicing value-based care, which can be a bit different from traditional fee-for-service businesses. How does that affect your EHR usage, and what are the overall workflows and features Athena provides for you?

We use Athena for a number of things. First of all, it’s our source of truth for the medical record for our patients. So I think it’s a struggle that a lot of health tech companies have, do you develop your own homegrown medical record, or do you rely on a third party medical record? We chose to go on to rely on a third party medical record, at least in the early stages of our company, which we’re still in today. At some point, that may change, but we currently use Athena as our source of clinical truth, and it should reflect all of the meaningful patient care we have delivered. We interact with a lot of our patients through chat, so meaningful chat encounters get documented in Athena, as well as any video or virtual visits. We also use Athena for submitting $0 claims per the compliance requirements of the value-based contracts that we have.

Are you also using Athena for front office workflows?

No, we do not use it for any of the front office functions; it primarily serves as the source of clinical documentation for us. Athena has a lot of features related to quality, like you can code in HEDIS metrics within Athena, and we don’t use any of those features, it’s really just clinical documentation, continuity of care management. So sending documents to other clinicians, sharing documents through HIEs, and the RCM functionality that it has.

For the front office, we use Acuity to support our scheduling function, and we use a combination of our own forms and Typeform as well, with the eventual goal of moving on to something that’s a bit easier to manage, like Jotform.

Can you share more about how Acuity and Athenahealth interact? How does Acuity help with your workflows, and what are your thoughts on its quality and integrability with your other systems?

Acuity is an excellent starting point for early-stage health tech companies. It might not be the best for scaling, but it’s better than building a scheduling system from scratch in the early days of a company, especially when scheduling is not going to be a differentiator for us as a company. So we decided, let’s buy something off-the-shelf and integrate it, writing some code to help tie what happens in Acuity to Athena. So for instance, if someone books an appointment in Acuity, our code will go and create an encounter for them in Athena that our clinicians can use. If an appointment gets canceled, we’ll manage the linkage between the two. Unfortunately, Acuity doesn’t have any native EMR integrations, so we’ve had to really build that out ourselves.

So the majority of scheduling you’re doing is self-service patient scheduling?

Yes, so patients will choose the time and Acuity will also use Google Calendar as our calendaring system- it does have a really nice off-the-shelf integration with Google Calendar, so it can read your Google Calendar, you can set your availability, your hours for specific appointment types. There’s all sorts of other features to help manage scheduling and availability for individual clinicians and groups of clinicians, and it will sync appointments into Google Calendar as well. We’ve found that patients will typically book an appointment using the UI managed by Acuity, but they can also book appointments within our application, which is a frontend on top of Acuity.

Are patients able to select a specific time and a specific provider, or do they select a time and then they’re just kind of matched with the best provider available at that time?

Yeah, Acuity has the ability to do both. Acuity’s core model is based on appointment types, and you can assign different clinicians who are able to take appointments within a given appointment type. And so let’s imagine it’s sort of like a general wellness visit. You can choose here’s the five clinicians who can have this type of appointment. Here’s how long the appointment is by default, it’s 30 minutes, as an example and you can also set aside a block off time immediately after the appointment for documentation purposes or for overflow. So you can say, on this 30 minute appointment, it’s going to take the average clinician 15 minutes to type up notes and to be ready to see someone else. Acuity allows you to configure that on a per appointment basis.

So if you’re sending out a scheduling link to a patient, you can send out a link to just book for that appointment type and you can book on the first available clinician basis, or you can also send out a link that’s specific to one clinician and that appointment type. So I’m booking a 30 minute wellness visit with clinician X that’s built into the link. It’s sort of like a URL parameter. Acuity will also allow you to have a dropdown so people can choose the first available clinician or choose a specific clinician that they would like to book with for a given time or given appointment type.

The other piece that we haven’t touched on is Acuity also has this notion of Classes. Classes are what Acuity calls them, but they’re really like group care sessions. So you can imagine if you’re running something like a substance abuse support group, you can schedule those as Classes within Acuity and people can sign up for multiple sessions all at once. And so essentially you’ll say okay, I’m enrolling for this “class”, and it books 10 distinct times on your calendar on a recurring basis. Acuity also manages all of the appointment reminder workflows for us, which are configurable on either a per appointment or a global basis. So you can say, I want by default all of my patients to get a reminder email 24 hours before, a reminder SMS 20 minutes before, and Acuity will handle all of that for you, regardless of whether it’s a class or just a regular appointment type.

So you opted for Acuity due to the richness of its feature set and its high configurability, correct?

Exactly. The opportunity cost of building similar features ourselves, especially early on, seemed too high compared to other features we could have been working on.

Can you tell me more about your decision to use Athenahealth as an EHR? What were you looking for, and who were the other EHRs you considered?

Yeah, our search really came down to Athena versus Elation as the two EHRs we were considering. We looked at maybe 10 or so, but those two really stood out as being the most feature complete. The choice between Athena and Elation was based on a couple of things:

First, one of our founding clinicians had used Athena extensively before, so we thought if we went with Athena, we could really hit the ground running. This would save us from having to re-educate her and learn about a new EMR.

Second, Athena had built-in RCM (Revenue Cycle Management) support. Even though we weren’t planning to do billing in the very early days of our company, we wanted the flexibility in case that’s where our product market fit evolved. We haven’t gone in that direction yet, but the RCM features in Athena were something that Elation didn’t have, and we thought that would be favorable from the standpoint of managing our tech sprawl.

Those were the main reasons we chose Athena over Elation. Elation did seem to have better support for digital health companies like ours, like a much better set of APIs. Unfortunately, Athena’s API service model is incredibly frustrating. They charge you on a per API call basis, and their APIs aren’t written with a consolidated development approach in mind. Each API behaves completely differently, and they’re not optimized to reduce the number of calls you have to make.

As a user of Athena’s APIs, you end up feeling frustrated because you’re charged per call, but the APIs aren’t designed to function effectively in terms of the number of calls you have to make to use them. We knew when we chose Athena over Elation that we were giving up a better experience with technical integration. It continues to be a point of frustration even now.

So working with Athena’s APIs is time and labor-intensive compared to another EHR like Elation?

Yes, that’s correct from a technical perspective. But from a clinical workflow perspective, it’s probably comparable, and there are some features for our specialty that Athena has that Elation doesn’t. So far, we’ve decided the trade-off is worth it, but the likelihood of us leaving Athena within the next 24 months is about 40 to 60%.

What would Athena need to do to reduce the probability of attrition? What would they have to change about the product or the service overall, from your perspective?

I think there are two main points of frustration that go hand in hand. Athena offers different tiers of service and support, depending on the contract you have. We’re on the cheapest one, called Athena One Essentials. They take the smallest percentage of your claims on this tier, but they also provide almost no support. So, for example, if we have a question about the behavior of an API within Athena, we have to submit a support ticket that typically takes two weeks for them to pick up, and then another two weeks to triage. We can’t expect a quick email response or a simple question about one of their APIs to be answered for at least 30 days. Sometimes, they’ll even charge us for asking questions about their APIs on this support tier, though that’s not true for their certified APIs, like their FHIR APIs, which they must provide for free by law.

The worst part about working with Athena, from a technical integration perspective, is a process called solution validation. If you want to use one of Athena’s API endpoints, you must prove to them that you are using it responsibly. If you’re on Athena Essentials, this process can take up to three months. It involves submitting a request, waiting four weeks, scheduling a call three weeks out, then doing a demo. The demos can be absurd. You must integrate the API endpoints into your app and demo them in Athena’s preview environment. You have to perform actions that call the Athena endpoint while someone monitors the API calls you make in real time. Finally, they sign off and send you a document via DocuSign to sign, which can take an extra week even after they give you the thumbs up. This process is incredibly frustrating for an early-stage tech company as it hampers fast iteration.

That’s one big point of frustration. The other is the lack of support in general and the ridiculous solution validation process. Then the third piece would be that the APIs do not behave consistently, relative to how they’re documented. Sometimes, even with certified API endpoints, we find that an endpoint is not returning a FHIR resource as it should, or an identifier is not working. Calls to the endpoint fail, and then six weeks later, they admit to a bug and fix it. But by then, you’ve gone without access to crucial data.

So, for us to stay with Athena, three things would have to change: better support, elimination of the solution validation process, and making the APIs behave as documented, or updating the documentation to reflect the actual API behavior.

How is Athenahealth performing for you on the billing and claims side, especially given your operation in a value-based care world?

We’re very early on in using Athenahealth for billing; we just finished actual billing and submitting zero-dollar claims. We’ve previously billed through invoices, so we haven’t had to go through Athena for that. We’re starting to go through credentialing now. So far, it’s as expected, slow to set up, both from Athena and the payer side. I think we’ll have a better idea of that in the next 6-12 months.

Do you feel that you made the correct assessment when you decided to go with Athena at the time?

If I were to evaluate where we are today, this very day, where we’re not submitting $0 claims yet, I’d say we made the wrong choice based on the features we’re using. I think I would have preferred working with Elation, even if it meant more toil for the clinical team in the early days, learning new workflows, and more time spent by myself learning those workflows too.

In six months, once we start submitting $0 claims, that’s when it might become worth it. If it’s a smooth process and Athena makes it simple for us, then I’ll feel like it was probably the right decision. But the main factor that made us choose Athena over Elation was this aspect. If Athena doesn’t handle that well, then I would have rather been with Elation from the start.

Can you describe the workflows you are using Zus for?

We use Zus to consolidate data that we might not otherwise have on the patients we’re seeing. We typically get claims data, like medical, pharmacy, and lab claims from the plans we work with, but clinical data adds depth to the patient’s picture. It’s valuable because it’s more real-time than claims, which can sometimes lag for months depending on how the payer processes them.

Our use case for Zus today is primarily for risk modeling on our patients. We want to understand the risk factors that an individual patient might have when they walk into our clinic or virtual clinic, and what we can do to address them. There are also things not typically coded in claims that you can discover through HIE data, so we use Zus to get a more comprehensive picture of the patient.

Zus doesn’t integrate with Athena off the shelf. Instead, we maintain a centralized data store, a sort of harmonized repository, pulling together all the different clinical data sources, including Zus, Athena, claims data from payers, and direct patient data. We manage this clinical warehouse ourselves, including the sync between Zus and the data warehouse.

I think Zus is still in the early stages of product maturity. Setting up the sync with the Data Warehouse has been labor-intensive, but they’ve been very collaborative. Even though their product isn’t on the mature side and we still encounter unexpected errors, the underlying data we get is invaluable to our practice.

Zus has recently increased its data completeness, which I think is an important step in the right direction. They used to only integrate with Commonwell, and got access to some Carequality records through that, but now they have access to both Commonwell and Carequality. They don’t have plans for eHealth Exchange for now, but that’s not super relevant for our practice since it’s very VA-heavy, and we don’t have patient overlap.

What’s also useful for health tech companies is that Zus manages other ancillary clinical data sources like Admission, Discharge, and Transfer (ADT) information. They take care of enrolling you in the appropriate ADT, which is quite helpful.

One challenge with nationwide virtual practice is the state-by-state variation in ADT information completeness. For example, state X might be 90% complete, while another state might be 30%. Zus is working on a product to manage subscribing patients into the correct ADT network based on where they live. It’s a work in progress, but it promises to be really useful.

I should add, with Zus, there’s a caveat that a lot of their features are still being built today. Anyone who works with them should be prepared for the fact that they’re still developing their product. However, they’re very transparent about that in their sales process.

How did you decide between Particle and Zus, what drew you to one versus the other?

Well, the difference between them really made us think a lot about what we wanted. The first and foremost differentiator was pricing. We got more favorable pricing from Zus, which made sense because they’re in an earlier stage. So, you’re taking on more risk and their data is going to be less mature. Zus’s pricing was generally modeled on a per-patient basis, whereas Particle’s was modeled on a per-query basis. Zus has since tweaked their pricing model, but the pricing at our volume and query rate was substantially advantageous to us, especially when we considered that we wanted ADT information too. So pricing was the primary differentiator.

Zus also integrates with Quest and LabCorp, something Particle doesn’t have off the shelf. They both have access to Allscripts and Surescripts, but Zus now also has Carequality. They started off with just Commonwell, but now have more. The differentiator with eHealthExchange was something Particle stood out for, but after looking into the practices within eHealthExchange, we didn’t think it would add much incremental completeness for our patients.

Another thing Zus had, which Particle did not, was a UI for accessing data. The moment you sign up for Zus, there’s a frontend that your clinicians or team members can log into to see patient health information. Particle doesn’t have that, so to get value from their data, you have to build a UI. Though you can still query it in SQL and such, we wanted something that allowed clinicians to use the data right away while we were still building out our UI. Zus had that, and I think those were many of the factors we considered when comparing Particle to Zus.

Now, I will say Particle had some strong points. They’re a well-established vendor with a lot of customers, so the quality of their API and engineering reliability is very high. Zus is a bit variable; we’ve occasionally run into bugs with their APIs. But they’re generally responsive, which I think is typical for an early-stage company. We knew that would be a trade-off when we signed up, but we still work through bugs and other issues with them.

Can you tell us about your usage of CustomerIO and its workflows?

We use CustomerIO for traditional marketing automation tasks. The marketing team can design campaigns for when a patient registers for our services. They can set branching logic like if a patient schedules an appointment, they get a certain type of activation email. The technical team’s work is to maintain data synchronization between our data and CustomerIO, so the marketing team’s decision trees are up to date. We use it for simple tasks like email campaigns or SMS campaigns to our customers. With CustomerIO’s webhook feature, we can automate tasks for our clinical team based on specific triggers. For instance, if a patient with a specific risk factor hasn’t been contacted in over a week, an automated set of rules in CustomerIO can create a task for a clinician to reach out to the patient. They also integrate with our primary data store, BigQuery, which saves us a lot of time.

So the setup time with CustomerIO was essentially lower because of the existing integration they had with BigQuery?

Yes, exactly.

Got it. On the webhooks, are those for reaching out to an external setup, or are they used for ingesting events?

I’m not certain if they have webhooks for ingesting events. We have direct integrations with data stores like BigQuery. When we were considering alternatives such as Braze and Iterable, neither of them had off-the-shelf BigQuery integrations, which was a standout feature for us with CustomerIO.

Did you need to build on top of their API or does the integration handle all the data syncing, allowing the marketing team to operate within their platform?

To my knowledge, we don’t use the API at all. We utilize their BigQuery integration, managed simply by writing SQL in their UI. We import events and synchronize customer data via their BigQuery sync job.

How would you rate CustomerIO’s customer service, support, and account management?

Their support team is notably responsive and helpful when it comes to debugging complex flows. They’ve also been helpful in devising workarounds for features not inherently supported in their workflows.

From a UI and usability perspective, does CustomerIO compete with other patient engagement platforms?

Yes, I believe so. There are minor technical nuances when you delve into the platform’s usage, but there are always workarounds. For example, the repeated campaign configuration for a patient based on their eligibility could be challenging. However, we have found ways to navigate these nuances.