Athenahealth

Today we’re going to be talking about Athena and how it’s being used at your company. Before we jump into that, could you give a brief overview of your company and your role there?

Yeah, so we’re creating a network of pulmonary clinics, tech-enabled, right now fee for service, eventually moving into value-based care once we figure out how specialists can do that in a meaningful way without stepping on primary care providers toes. And so kind of in that, in that sense, we’re focused on quality metrics on the front end before patients go to the hospital and trying to engage in preventive care, in an outpatient setting and then post discharge, how do we keep them out of the hospital so thinking more about readmissions, on the back end. We’re a hybrid clinic network, so we have a very strong in-person element with specialists and APPs (advanced practice providers) as part of our core team, delivering care but we also do a lot of home monitoring so that we can have a tight feedback loop and make sure that we can catch exacerbations or decompositions before they happen. So that’s fundamentally what we do. I helped start the company from the ground up with our CEO. Technically, I’m the head of clinical informatics but I’m focused on product, legal strategy, and revenue cycle management.

So when did you purchase Athena? And how long have you actually been using it in production?

Sure. So we started in like August, September, October, sometime in that range, and we signed the contract pretty quickly, maybe within a month and a half of looking at EHRs. The decision was more or less made for us, but that’s why we moved so quickly. We went live sometime in January or February. But that was more on our end than it was Athena as just because we didn’t have our providers lined up the way that we needed to to launch the clinic. But I think February might have been like the official go-live month or maybe it was March, something like that. We just kept pushing back until we were ready to go.

That makes sense. And then how do you use Athena at your organization? So you know, one of the ways to maybe frame that is like, what types of users interact with the product. And what are their sets of workflows?

Yeah, that is a pretty loaded question. Because an EHR is pretty integral to running a clinic. Right? Like this isn’t a virtual model where we’re doing a lot of care at home and can use our own system. So because we are providers and have to deal with MIPS, MACRA, ACOs and all of that. We are in our EHR for basically everything. Now, when you think of an EHR, people just tend to mesh together the PM (practice management) piece and the actual clinical charting piece. Those are separated for us. So we didn’t actually take Athena as a practice management solution, what they call a AthenaOne as the whole package. We only have their charting. So our MAs (medical assistants), for example, who are cross trained to be in the front, back, PFT (pulmonary function technologists), all of that good stuff. They’re doing a lot of the work that you think of in the clinics. They’re checking patients in, checking them out, scheduling appointments, doing a PFT, uploading reports, pulling reports from the hospital and uploading the discharge summaries, all that kind of stuff is happening by the MAs and Athena. And then the providers are more or less using it to do two things. One is to do their notes when they actually see the patient and two is to respond to orders and tasks that are associated with managing a patient’s care. So for example, let’s say the patient calls in a med refill. The MA will line that up in Athena and the provider has to approve it in Athena. So all of that’s happening in Athena. Everything else that you would imagine traditionally happens in the EHR, like eligibility checks, submitting claims, managing claim status according to the encounter. We’re doing that as a homegrown piece of software. So that’s not happening in Athena for us, unlike I think 99% of their customers. According to them, at least.

So the set of features that you’re using is much smaller than the regular, maybe set of features for an EHR. It sounds like you’re using clinical notes, charting task management, perhaps telehealth, e-prescribe. Does that all sound right from your perspective?

So we’re not using any telehealth through Athena. We’re doing all of your basic charting and clinical features like the prescriptions through Athena. But when we bought the package, we bought Athena clinicals only. So that’s why it sounds like that because that’s exactly what it is where we only bought the clinicals package.

Yeah, I’d love to kind of dive into that some more. So, for more of the practice management side of things, the non clinical features, did you make your purchase decision because you felt like those features didn’t stack up? Or were there other strategic or technical reasons for going that way?

Yeah, so I think to give you a good answer to this question, it helps to really understand what we’re doing and how our business model works. We are, at the moment, a fee for service business. We have a very strong mission to reduce the total cost of care. But ultimately, our payment model isn’t totally dependent on that- at least not at the current point in time. And we don’t know exactly when that’s gonna happen. And so our revenue is very much claims driven, if nothing else, and so we cannot sacrifice a percentage there because you lose a percentage on claims, you don’t get it on a sub-cap model the way that Oak Street was. So for me making sure that we have a very, very, very strong claim system, that I have full transparency and to have full control over and a very good understanding of was way more important than how the charting process worked.

That being said, charting defines how you can code and therefore your revenue. So it wasn’t something I could ignore. But from a business case perspective, the RCM matters a lot. The way that Athena makes their RCM process work, at least what we were pitched or what I recall from being pitched is we were going to give up a very significant percentage of our revenue, like think double digits for them to let us submit claims to their system. And we would have to hire our own billers and coders to work denials, work appeals, understand credentialing, all of that stuff. So they weren’t going to offer any of that.

And on top of that, we’re taking a massive chunk out of our total revenue, and therefore our bottom line. So when you think about it that way, even if the practice management system is at the 90th or 95th percentile, there’s no way that they’re going to increase our coding by like 30% to offset like 10-15% that they wanted, right? And so the thought process for us was if we can find a separate vendor who charges less and provides similar quality services, if not better than Athena, and we have engineers because we’re a tech enabled company, why can’t we just build our own pipelines from the clinical systems back into the RCM?

Looking back on it, it was hard, but I still think it was totally worth doing it that way. And our RCM vendor, I’m pretty happy with so far. I don’t think there’s really a good RCM process out there just because insurance companies make that process hard on purpose. But as far as the one that we selected, I’m very happy with. So anyways, putting that all aside, that’s kind of why we decided to choose the package that we did. We still got a lot of the API access we needed to build tight integrations with the clinical system. And it allowed us to do the integration with Enter Health, but it just didn’t make sense to give up like 12% or even 8% of our revenue, just to be able to submit claims. That was ultimately how that decision came to be.

Maybe this is a good time to answer why Athena?

Yeah, I think that’s a good place to go.

Okay, so ultimately, so we launched our first clinic in Georgia for a number of strategic reasons. But as a consequence of that, I know that the two best rates like contracts for fee for service building in Georgia are either through Piedmont or through Emory. And I have a very strong relationship with Emory already, again for a different number of reasons. So Emory’s rule was that we had a choice of a few EHRs if we wanted to be part of their network and take their fee for service contracts. And so I figured if that was true in Georgia, if we expanded to another state, like let’s say we went to North Carolina and partnered with Duke to work in rural areas, then I’m sure that there’s going to be some interoperability clause that Lifepoint has put on everybody or Zion Health has put on everybody, because they’re only able to integrate with some number of EHRs.

So I didn’t want to choose a newer, maybe flashier EHR like Canvas or Elation if it meant locking us out of really great fee for service contracts that could increase our revenue 20-30% across the board, depending on our payer mix. So I wanted to choose an incumbent that I knew that more or less everybody would be integrated with somehow. And then secondly, I wanted to make sure that for our first clinic, we had great contracts which required us to choose one of six EHRs. And Athena was basically the only one that had an open API that we could even meaningfully interact with to build our tech around. So that’s kind of how that decision came to be. And that’s why the decision was quick. Our vendor list was cut down into six because of the network and we said, okay, out of these six, which ones aren’t even viable to use and scale with us. So that’s kind of how that decision was made.

Yeah, I think that harkens back to the point that you made earlier around, Athena almost being chosen for you from the beginning.

Yeah, and I think that’s kind of what healthcare is right is like, there’s no way to just go it or there’s very few instances in healthcare, where you can go in and just disrupt incumbents completely. It takes a lot of work and a lot of energy. And you have to make small meaningful steps at each level before you become an incumbent yourself and then can start making really big disruptions. And so I think Athena was one of those steps where we had to compromise and say, Hey, we can’t use the best EHR out there. We didn’t even go in to evaluate Canvas or Elation or one of these other ones, because we knew that this is a sacrifice we’ll make up front, but we’ll probably but it’s not going to be a sacrifice of quality of care or bottom line, to the extent that it’s going to meaningfully distort our business model or ultimate vision and goal for how we deliver care.

So the reason for choosing Athena is because you had to choose an incumbent due to the contracts that you were entered into. This was because you were partnered with health systems, and they require you to use one of a given set of EHRs. Is that the right way to think about it?

Um, yeah, I think that’s more or less the right way. But I don’t think that this is actually a health system problem. Five or six years ago, I was working on this interoperability project for free clinics and I read somewhere that there were like almost 1200 EHRs in America. So if you’re an IPA (independent physicians association) or a CIN (clinically integrated network) somewhere in Georgia, or Tennessee or Alabama or what have you, like small non-Florida, California, Texas, New York type states, just like how many EHR integrations can you really support? Like maybe, if you’re really well capitalized, have lots of customers, maybe like 400-500, you’re still not even getting to 50% EHR integration saturation, then theoretically these companies Redox, OneUp, Healthjump can solve some of those problems, but they’re expensive. They’re really, really, really expensive. So if you’re any type of CIN or IPA, and let’s say you’ve capitalized to maybe like $20 million, that’s not an investment that makes sense. If most providers are on one of these 6 incumbent EHRs, and if you can integrate directly with those and you can cover let’s call it 45% of the market, then that’s a much better decision from an ROI perspective, rather than trying to use Redox to integrate with the long tail of EHRs across the system.

The consequence of that is when new entrants like us come in and we want to use something new, we’re locked into it, but this isn’t an issue of health systems. This is an issue that we probably would have run into if we used a smaller CIN or a smaller independent IPA, because they would have been facing the same challenges and would have had a lot smaller pockets or what Emory already has to pay for these kinds of integrations. So I think that this is just a challenge that if you’re in fee for service, and maybe even in value based care, you’re just going to keep running into it. Until there is true interoperability, which I’m skeptical that will ever happen. But anyways, I think that even if we weren’t with Emory, I probably would have pushed to use a bigger player that I know would have been able to support working across state lines and systems. Just because I know that healthcare is one of those places where it’s kind of like energy, right? Once you have a big ERP or system that most people already know how to play with, it just makes your life easier down the line.

Yeah, I think that makes sense. I mean, given the nature of the healthcare you’re providing, you need to be able to share data, share patient records with your partners. And so as a result, you were opted into, you know, one of the majors.

Yeah, I think that’s a great way to describe it. And ultimately healthcare is not siloed. Right. So everybody works together one way or another, and I think care management and care coordination. It’s like, it sounds so cliche, but those are really going to be the lowest hanging fruits for how do you reduce unnecessary spend or over testing on patients? And I think that these bigger systems are going to be a lot easier to work with when you use Athena or an eClinicalWorks or another EHR like that.

Pivoting a little bit, did you build on top of the products or extend Athena in any way?

Yeah, so that’s actually something we’re doing right now as we speak. So I really love Chrome extensions. I think that they’re phenomenal and there are a few little things you can do, especially as everything moves on to the cloud and away from servers. You know, we extended the EHR into a practice management system to begin with, so we have a tight integration between Athena and our PM, and therefore our RCM system as well. But that’s not happening on top of Athena, that’s happening in a separate portal that just speaks bidirectionally with Athena. Now. Now what we’re working on is how do you take that and actually interface it on top of Athena so that nobody’s bouncing between two websites? And how can you Athena and turn it into your own product? Even though you’re using their baseline structure and UI? There’s a company called Pixiebricks that we used to build proof of concepts just to see how they work. And we basically took some of those principles and now we’re doing it in house with more tight API integration so that it actually works without breaking randomly.

In terms of the development experience, how easy has it been or how easy is it right now to build what you need? Are the APIs robust and comprehensive? Are there gotchas or anything like that?

Yeah, so the APIs are surprisingly very robust. There are 700 endpoints or something like that, and you can basically manipulate the whole system without ever touching it from their UI, if you really wanted to. So that’s actually something we had thought about long term but just using Athena as a glorified database, and then building our own complete interface that just uses APIs to run everything like that’s how robust their API is, that is that you could theoretically do that if you really, really, really wanted to. I don’t recommend doing that for what it was, but it is technically possible, I think.

Now, the interesting thing about their API is like everything is super validated and also the API isn’t free anymore. It used to be an open, free API. That’s not the case with Athena anymore. So you have to pay to use the API and then you have to validate every time you change your use of the API. So like, let’s say I’m using an endpoint today to fetch all my patient data, and then using that to fill out my practice management solution or let’s say I want to fetch appointments. And that’s what I’m doing today. And then tomorrow, I decide, hey, I’m going to create a separate interface that lets me place orders on top of the calendar in my system. That separate API requires me to go through a pretty meaningful two to three weeks of validation, testing and QA on the Athena side before they approve that, so you can’t just go do wherever you want, then go live. There’s actual checks and balances before you do that, which honestly is probably a good thing, given that they’re holding a lot of patient data.

If you wanted to switch systems down the road, would there be substantial switching costs?

I think no matter how you look at it, there’s going to be substantial switching costs by choosing another EHR, but that is more of a nature of how EHRs are built than it is Athena’s fault. Don’t get me wrong, I have complaints, but generally, I think Athena is actually one of the better ones when it comes to letting you plug and play into your solution and actually supercharge it. You know, I’ve used other tools, old school legacy ones like Practice Fusion and eClinicalWorks. I don’t have too much experience with Epic or Cerner. And then I’ve seen APIs on some of the new ones like DrChrono and Elation. Athena is probably of a similar quality in terms of documentation and actually using APIs as DrChrono, RXNT, and Elation. I haven’t used Canvas’ and I know that everybody loves them. I can’t really speak to that one. And it’s by far better than ECW and PracticeFusion, which do not have API’s that I’ve ever been able to use. I know I don’t think ECW even has those. I think they’re just pure HL7 still. But I think Athena has done a generally good job. Now the one thing that I find very comforting about Athena is they actually have two endpoints that you can use are two types of endpoints. So what they call certified and then there are non-certified APIs, and the certified APIs are all FHIR-based. So at least there’s like some semblance of being able to, you know, change things so it’s better than probably that industry standard. But is it as easy as changing from like, Rippling to Gusto? Definitely not. That’s I think that’s how I would put it in relative terms. But generally, I’m pretty happy with what they’ve done as far as API goes.

Switching gears a little bit. I’d love to chat about integrations that you have, or how you thought about supplementing Athena with other products, whether you know, homemade or off the shelf. And, and kind of what that experience was like.

Yeah, this is a very interesting question. The homemade process is more or less just about APIs. I think that that’s more or less a dead horse from what I’ve just described, unless you want me to get deeper into it, but I think it’s just like using any other set of EHR APIs that actually have real APIs. Not much more I can say about that. But using off the shelf products has been a completely interesting and incredibly variable experience from vendor to vendor. So we use, for example, ZocDoc, which we stopped using for some reasons, but we were using ZocDoc to try to get more patient volume, which has an Athena integration. We use Schiller for our EKG, which has an Athena integration and then see, I was looking at some AI scribes like Suki, which theoretically integrate with Athena, although I haven’t seen those in practice. So let’s just talk about the experience of ZocDoc versus Schiller. Schiller is one of those incumbent types like people who are trying to buy some random device from Medtronic. So definitely a lot slower and a lot less aggressive on the integration. And obviously, their incentives are completely different from ZocDoc because ZocDoc prices on a per-visit basis instead of a subscription basis, where Schiller is like you pay one time for the EKG, and then it’s yours kind of thing. So the incentives are a little different for them. But for ZocDoc, the integration process was maybe like 30 minutes and three days, really the speed of it just depended on how quickly I was able to get on a phone call. They had a very good system with LogMeIn, that made that process pretty easy and painless. So I didn’t actually have to do anything except login and let them take control, they set up the integration, but that was maybe like 30 minutes maximum, an hour of work.

We bought that EKG maybe like a month and a half ago, and we still do not have our Athena interface live. And I don’t I don’t think it’s a female boss. There’s just some weird contract stuff with Schiller where they’re like, trying to get us to sign their BAA and we want them to sign BAA and that was a whole mess. Nobody really understood what was going on. And that is why that is not live, but the integration process could be very easy. ZocDoc did it in like a week, maybe two weeks. Now. Schiller took a month and a half and we’re still not done. But they’re both marketplace partners. So I don’t know if that really answers the question that you’re asking. But that’s kind of like to two extremes that I’ve seen on trying to use third party partners off the shelf that have EHR integration,

Yeah the variance there seems pretty high. I know you also mentioned an RCM partner earlier. And that you were using the Athena API to submit claims. Do you feel like that process was overall pretty smooth?

Yeah, that process was a pain. But I don’t think that the process was a pain because of Athena. Like I said, part of it might have been because of Athena and their APIs are not really intended to do this, and they’re not designed by us. But I think part of it is like, our engineers are great. They’re very smart. But none of them have ever been in a claims system at all. And I was trying to do a bunch of different things. So I was saying, like, we need this and then they would build something and then by the time I’d get to it, it was like just slightly off, but in RCM that makes a big difference. And then, actually getting the data from Athena into our system, like our middleware component, then part was easy. Getting the data appropriately back into the RCM system was much harder. That’s the two sides of the coin, one was pretty straightforward and that straightforward piece was Athena. I don’t actually have qualms with them about how we were able to pull data to submit a claim. There are some things that they could do better, like for example, if you have APPs that are rendering a service underneath the supervision of another provider, that has implications for how you submit a claim. There’s not really an easy way that I have figured out yet with Athena to mark that or to note that that is the case. So for things like the incident to billings, Athena is not going to make your life easy. At least if you buy clinicals only but theoretically, they claim that if you have AthenaOne, they can solve that problem. I don’t know how. That’s what they told me. I think they’re just trying to upsell me.

I think maybe it’d be interesting to chat about the kind of product setup in subsequent support. So once you’ve made the purchase decision, what was onboarding and implementation? Like, how long did it take before the product was deployed?

Yeah, so you get I forgot what her exact title was. You get like an onboarding Success Manager is the best way to describe this person. All the way up until go live and then six weeks after, and then after that, you transition over to a CSC- a Community Success Manager, something like that. Basically, an account executive or account manager. And she was great to work with. She basically went through each piece. They have like a checklist like these are the things that are clinical workflows, that no matter what type of outpatient clinic you are, you’re gonna have these kinds of things to deal with like faxes and clinical inboxes orders, i.e. prescriptions, controlled substances, all that kind of stuff. She helped us go through each of the steps and said, Here is what you need to configure, tell me how you want to configure it and I’ll teach you how to do that. So that you can change it later if you want to. So that process was actually pretty good. They do an online training type thing. So like 40 hours of EHR training online and then some live online classes as well.

If you want to bring somebody out to your site to train the providers and staff, it is very cost prohibitive and it’s something that we did not spend money on and we may spend money on it down the line. It is really expensive to do that, so we avoided that. But otherwise their support system was good. Their knowledge base leaves a lot to be desired, to be honest. There’s no semantic search. So you’re not going to get an Algolia-style experience in searching for information. Obviously, it’s more old school than that, but for your very basic requests it’s pretty straightforward. Most of our support is through email, which is what I like, but they also have a 24-hour line where you can try to get help if you need it. It’s not always super helpful, but I’ve never used it so I can’t speak to that in a meaningful way. Let’s see what other lines of communication do we have? I think those are the big ones at this stage.

Do they have a developer support team or support line?

Oh, yeah, they do have a developer support team. You can get that. It’s kind of like if you get an AWS or Azure package, you can pay for different levels of support, but we’re not paying for any support. We’re using the basic support package and it works more or less fine. You know, there’s a question of how technically competent their team is on the developer side. Because most of the time, you’re not going to get engineers answering the questions, they’re like, product managers. So that’s, that’s been somewhat of a challenge. But generally, if you’re like a decent engineer, you can kind of make do for the most part for like, 90% of what’s going on.

I think maybe going back to the high level or trying to recap some of the discussion. Is there any one particular feature or thing that you would say you like most about the product compared to other EHRs?

I would say that the charting process is a little bit easier, maybe like 5-10% easier, which can be worth a lot if you have a lot of providers. The API is definitely better than a standard in the industry, especially for old school EHRs like eClinicalWorks and some of these other ones. Like nobody’s ever really happy with their EHR. Those are two highlights of the experience. Another really nice thing I would say is that they have their eFax system included in the price. And then they sort and organize our fax documents and they assign it to the appropriate patient and all of that we’re not spending staff time on that. So that is like a really nice feature.

Is there anything that you really dislike about the product?

It is a lot of clicks to chart, I’m not a fan of that. I think they have dot macros and stuff like that, but I don’t know, you really have to prune their templates. They’re out-of-the-box templates are pretty abysmal. If you’re trying to document things effectively, quickly, efficiently. It is not like that for you right out-of-the-box. So I found that pretty frustrating because I spent probably like 5-10 hours just setting up templates for providers to use. It would ask, do you have chest pain three times- one in the review of systems, one in the HPI, and one in the physical exam, so that you can ask that question once. You don’t need to ask that three different times. Just things like that. That was frustrating. And then some of the UI is very disjointed. Like some of the new features have a really nice slick interface. They have new types of fonts, new colors, like the modern frontend stack, and then all the old like standard things like adding a new patient still uses really old UI features that have not been refreshed probably since like, the late 2000s. That’s a pretty nitpicky one.

What do you think is the likelihood of you continuing to use the product in 18 to 24 months?

I mean, I’m sure you know this better than me, but it is hard to switch your EHR, so the likelihood is pretty good. Unless they double our price, then we’ll have to switch. But otherwise, It’s pretty hard for me to imagine we’re switching off in 24 months, especially because we’re building the Chrome extension for Athena. So if we’re investing so much engineering money and extending its capabilities, it doesn’t really make sense for us to switch within two years.

Otherwise, if massive networks move away from it, that would push us out pretty quickly. From an engineering perspective, if they’d shut down their APIs, that would be bad, and we would have to move out, although I can’t imagine them ever doing that. So, price, network, core features shutting off, that will be bad. Oh, if somebody developed a significantly better EHR and I thought more like 25-50% gains in efficiency somehow. That could potentially make us switch. But it’s really hard for me to imagine someone building something that just perfectly fits our workflows.

Anything that we haven’t covered that you think would be interesting to talk about that other folks should know?

Have you heard of zapEHR?

Yeah, there are a couple of products that play in that space of headless EHRs.

Okay, yeah. Well, I looked at that and I heard about Medplum recently and I didn’t really understand what was going on there. I think their website is just less fancy than ZapEHR.

So ZapEHR’s website was a lot clearer about what it was to me. So I think that that value proposition is really interesting. I don’t know how long they’ve been around, and I was not aware of them when we made the decision. I’m not sure we could have made a decision to use that EHR anyway because of network reasons. But I think if you’re like a true tech-enabled clinical services business, like let’s say you’re starting a new primary care clinic like Oak Street and you’re gonna build your own tech stack or you’re building that a new Carbon Health competitor and you want your own tech stack, if you can get ONC-certified using these types of headless EHRs will build your own complete experience, it honestly might be worth it if you’re not in a major rush and if you have a really good vision for what that technology is going to do.

None of these traditional EHRs are going to behave the way that you want them to- you’re gonna have to do a lot of work. Like we have a Chrome extension right now that suppresses error messages that are irrelevant because of the way that it was configured for us. Like that’s a waste of a week of engineering time that could have been used doing something more productive. Yes, you probably saved like one and a half years trying to build your own EHR but with these headless ones, you could probably build something pretty quickly. Like I would imagine, two, three months, you could have an MVP out.

I think that that is really valuable if your goal is to get to like 100 clinics, like our goal, we don’t need to get to 100 clinics, we can get to 25-50 and still meet venture-type goals and still make a very massive clinical impact because the way that pulmonology is, but if you need 100-200 clinics, and that’s your goal, then I think building that kind of tech stack from the get-go might just be a better decision. Now, that honestly works a lot better when you’re value-based care because if you’re fee for service, you’re gonna hit the network issues. But anyways, that’s kind of my two cents on if I could do this all over again and this is a slightly different situation, how I would have handled the procurement process and thought about the product.