Athenahealth

So, we’re discussing Athenahealth and a few other products and their usage at your company today. Before we delve into that, could you give a short introduction of the company and your role within it?

Our company is a tech-enabled primary care provider focused on less-urban markets across the US. We usually work with small independent primary care practices. I head up the technology team, which encompasses everything from our clinic’s IT operations to our EMR solutions and other tech solutions.

Understood. When did you purchase Athena and how long has it been in use?

We’ve been using Athena for just over a year now. We chose it because it’s a fully integrated EMR RCM solution, meaning we don’t have to deal with multiple vendors. Plus, Athena is quite popular with independent primary care practices. The idea behind the procurement decision was that it would be easier to integrate their existing Athena solution with our operations as we continue to grow and partner with different practices.

Did you consider any alternatives, or was it clear from your research that Athena was the best fit? I’m interested to know more about your procurement process.

Yes, we considered both Canvas and Elation. Canvas was budget-friendly and highly customizable, but it had gaps in terms of capabilities and is a smaller player overall. We thought the change management for providers, many of whom have been working in independent practices for decades, would be quite high with Canvas. On the other hand, choosing between Athena and Elation was more challenging, but we decided on Athena for its full integration across different areas, reducing our deployment and procurement concerns.

Could you elaborate on what you were concerned about setting up?

The biggest concern was the RCM. I’ve heard about the challenges others have faced trying to set up an effective billing solution. While we are working towards a zero-dollar claims model, we needed a solution to manage our claims with minimal friction due to our mixed patient panels, ensuring we can handle our revenue management to some degree.

Elation has integrations with various types of solutions. Could you share why you think Athena’s integrated RCM provided more value over another tightly coupled but not fully integrated RCM plus EHR combo?

That’s a good question. I think it ultimately comes down to reducing friction and switching costs when running the clinics. Athena’s RCM solution is not extraordinary, but it does a good job and checks most of the boxes for claim closures and tracking various errors or rejections. We incorporated some integrations as part of Athena’s package that has made things relatively frictionless. Any chance to reduce change management costs has value for us, considering our business model involves significant change management after partnering with a practice.

That makes sense, especially if you’re moving fast and looking to fit your product into the market. Given your business model, a big part of your approach was minimizing change management. In practice, how does this look when you go out to clinics, partner with them, and then implement your tech stack?

Well, for one, Athena already has a sizable market share in the type of markets we’re operating in. This often means we encounter fewer clinicians and staff who need training on an entirely new EMR system. This allows them to get up and running with daily operations more quickly. It also lets us concentrate more on what I consider to be the real change management that we’re doing, which involves integrating more wraparound care services and team members that they didn’t have previously. We train them on new workflows, emphasizing proactive patient engagement, which is very different from some of these practices that just wait for patients to show up. A lot of the actual care model piece of what we’re doing on top of an EMR is where the real change happens. If we were spending all our time teaching them to manage an encounter, fill out all the notes, or figuring out the right way to track various types of coding issues, it would just be a distraction.

I see. You mentioned that data integration with Athena might not be as seamless as expected. Could you expand on that?

Certainly. I had anticipated a smoother experience with Athena’s data migration. I understand that data migration is never easy, but I expected them to better handle the transition of information from an existing Athena instance to our Athena instance. However, a lot of things, including file-based documents or images, don’t necessarily make the transfer. This affects everything from losing progress on quality measures in the new instance to clinicians’ frustration when their work on procedures, like colonoscopies or screenings, isn’t reflected in the new instance. While Athena has since addressed this, we were initially unable to bring over structured versions of lab result data and imaging result data. That was a significant pain point for us during our first set of migrations.

That makes sense. So, continuity of patient data might not be a primary reason to choose Athenahealth?

Correct. There are certain things that transfer over nicely, like all of the patient’s insurance information, so we’re not starting from scratch. However, in terms of clinical data, a lot of things that should have been able to transfer didn’t. This includes lab data, imaging data, and even structured versions of that data. The transition has been particularly challenging for clinicians and staff who were already using Athena. They expected a seamless transition to the new instance of Athena but ended up losing significant information about their patients, which has been a source of frustration.

Additional issues that we found are that athena often requires creating duplicate “shell” user accounts for our clinicians when they need to work across departments and practices. It’s a terrible identity management system that leads to lots of confusion and breakdown around which user account to send a document or order to. Also, encounter document composition is lost in migrations, which negatively impacts quality gaps and provider summaries. Encounter sections like “history of present illness (HPI)”, “review of systems” are typically stored in a structured way that enables easy translation for quality gap closures and surfacing up information that a provider can re-use for the next encounter. All of that document metadata is lost in migrations.

I can see how that would be frustrating. Shifting gears a bit, I’m curious to understand the workflows and features you use that might be outside of what you’d find at a typical small practice physician’s office.

It varies a bit. Some practices have basic patient health record portals with limited functionality. Others don’t have any kind of automated communication or reminder systems for appointments. They often rely on staff to manually call and remind patients about upcoming appointments. So, a lot of what we bring with our current version of Athena falls into the CRM category and goes beyond what you’d find in many legacy EMRs. Beyond that, we’re also adding more population health views and panel level views, something I haven’t seen much of in the EMRs I’ve encountered.

Are you building on top of Athena using their APIs? From your perspective, how has the process of building on Athena been for you?

Yeah, I was planning to discuss this topic at some point. Athenahealth has greatly improved their API capability. However, when compared to something like Elation, it still lacks certain features that we prioritize. For example, if a patient’s information or critical parts of a patient’s chart change, we’d like to receive an event notification webhook. Athena offers some great APIs, but it doesn’t have a comprehensive events framework yet. This forces us to put in extra work to generate a real-time signal for activities at clinics. They’ve made significant strides in certain areas, but some crucial elements that we care about, such as updating a patient’s problem list or quality-related matters, are quite limited in terms of what we can accomplish. This remains a puzzle we’re trying to solve, especially when we need to incorporate a variety of external data and sources, be it from payers, Particle, or other systems, and ensure that this information reaches the point of care. I’d also add that athena’s API documentation isn’t great. We end up having to resort to a lot of trial and error in testing environments to get information to load correctly into a chart. As a whole, I’d give their API capabilities a B-.

With that said, I’ve been generally satisfied with their back end. They use Snowflake for their data view system, providing a comprehensive nightly refresh of everything in the chart. This has been beneficial to us, particularly in mitigating some of the migration pain. We can easily tap into older versions of Athena and bring in our own subset of data. It’s a bit ironic: we can upload our own data into a patient’s chart but Athena can’t do the same on their side. Nevertheless, having full backend visibility has been a positive experience. The system is easy to work with, well-maintained, and the documentation is generally pretty good. They’ve been progressively expanding its coverage which has been a plus.

I see. So, if I understand correctly, all the data within the EHR is mirrored over to the Snowflake data warehouse every night for analytical purposes. Any changes you make to that underlying data don’t affect the EHR, right? It’s a one-way sync?

Correct. That sync is read-only. Any changes we make are processed through the API.

I see. Could you share some of the workflows you’re implementing with the Snowflake instance?

We primarily use Snowflake for panel management, work lists, and various types of alerts based on charting activity. For example, it allows us to assess provider capacity better, helping us balance provider panels based on schedules, identify opportunities for additional visits like annual wellness checks or comprehensive care visits. It also directly influences our patient outreach and engagement strategies. We perform follow-on analytics and categorize patients based on their engagement level or risk stratification. This helps us identify which patients need appointments quickly or those who may benefit from a specific disease management program. We’re also building some lightweight MVPs for population health using the data from Snowflake.

Understood. So you’re basically writing data pipelines with some tool and reflecting these workflows back to Athena. Is Athena your primary system for engaging or interacting with patients, or are you using additional patient engagement tools?

We utilize a separate CRM solution like Salesforce for initial patient engagement, and then a lightweight CRM for targeted patient engagement, handled by community health workers or medical assistants. The core of our tech strategy and architecture involves building a wraparound ecosystem around the EMR. A lot of work that leaves the EMR doesn’t return to it, forcing staff to navigate different systems. We strive to ensure that data from different venues is accessible to the staff within the EMR to reduce their workload. Of course, Athena and most EMRs have limitations, so we need separate workflows specific to certain care team members. For instance, community health workers may not do a lot of clinical documentation, but their patient interactions provide valuable data. We aim to bring relevant information back into the chart, which then informs the rest of the care team on whom to reach out to and work with next.

I’m interested to understand why more automated patient engagement workflows aren’t usually used. Is it because the patient’s acuity or complexity level is typically high and therefore difficult to manage with specific workflows, given the broad variation across your population?

When you say “automated”, are you referring to things like an IVR solution or various text-based or other solutions?

Yes, it could be a text-based system, for example, using branching logic. If a patient exhibits these conditions, then take this action.

We often rely on customized communication protocols and similar strategies, mostly using Athena’s capabilities because it works well enough. Creating customized campaigns can require a lot of manual work, though. For instance, if we’re planning a campaign to encourage people to get flu shots, we can quickly and easily create a list of those who need a flu shot, load that into a system, and start a targeted campaign. It’s not entirely automated, but the friction of creating the list is not overwhelming. More nuanced and highly tailored automation is something we might look into later. We have other higher priority issues to deal with for now.

Understood. I’d be interested to learn about other integrations you’ve had with Athena, whether you supplemented product functionality with other tools and how you managed that process.

Sure, I can discuss one particular integration where we attempted to work with a separate vendor to help identify areas where we were missing certain types of diagnoses or codes. This would allow us to better understand and focus on providing an accurate picture of our patient panel. Unfortunately, this solution did not perform well. The idea was to feed Athena’s Chart API and provide potential diagnoses and other conditions to address at the point of care. Due to its poor reliability and performance, our providers defaulted back to Athena’s built-in suggestions. This showed us the difficulty of getting a provider to venture outside of the EMR, even with a simple side-window. We also tried integration with RubiconMD, aiming to streamline referrals and get consults and recommendations related to behavioral and mental health. It’s early days for that integration, and while adoption has been mixed, it does seem to be adding value.

What’s the workflow and integration points between Athena and RubiconMD? How do you manage to close the loop?

The integration isn’t extensive. We provide a limited set of patient information to create a referral. The usual workflow involves an asynchronous consult and review, which eventually gets added back as a note in the patient’s chart.

I see, and then the primary care provider (PCP) uses that information and potentially communicates back to the patient.

Exactly, this may lead to changes in medication management, alignment to a different care plan, or even in-person specialty visits. There are a few potential outcomes from the process.

That makes sense. Earlier, you mentioned trying to provide diagnoses or give providers more insight into a patient’s condition. It got me thinking about data interoperability - pulling together a patient’s past history and medications to provide context, not necessarily make recommendations. Do you integrate with clinical data providers?

We’re currently piloting a project with Particle, a data provider. There are many vendors that work with Health Information Networks (HINs) or do some form of integration to collate information about a patient’s history. However, these solutions often lead to one-way data flow, where the data enters their system, and we have to manually access their system to retrieve it, without the data making its way back into the patient’s chart. Particle gives us more control over the data flow, which is vital as we want to ensure that information makes its way directly back to the patient’s chart and is available at the point of care.

Did you compare Particle Health with other potential data providers? How did you conclude that Particle might be the right fit for you?

We looked at a few other providers, but our decision came down to cost, coverage, and the compatibility of their APIs with our workflows. In our model, clinical data from the provider flows into our data platform where we perform initial cleanup and filtering, then this gets inserted into the patient’s chart. Particle Health offered us substantial control over this process.

In terms of coverage, what clinical data were you looking for?

Regarding ADT, that’s a different story. This was specific to where we operate. We looked at various options early on since the timeliness and usefulness of ADT are vital. Having information about emergency room visits or inpatient visits can be invaluable for our care team and home care model. However, most vendors didn’t cover our market, so we had to build a separate process to bring in an ADT feed from the state. While this took longer than we would’ve liked and had its friction points, it essentially does the same job. Ideally, Particle would have been great as it offers an ADT option, but it didn’t provide value for us. We’ve primarily been using it for quality-related closure gaps and gaining a better understanding of events happening outside our direct care. It also helps fill in some of the diagnosis information from specialists and other relevant patient data. We’re working on some medication-related aspects too.

Got it.

Yeah, classic issues include medication reconciliation and up-to-date awareness about a patient’s quality gaps. Often, managing these conditions involves many different systems.

What do you like most about Athena?

In general, I would say Athena has been satisfactory. Over time, my perception has changed in terms of its actual usage in the clinics. It’s not easy to build apps on top of it, and there is friction even in getting approvals to use certain APIs, let alone trying to link to external tools. However, in terms of clinical workflow, it tends to work pretty well. Their clinical inbox structure is decent, and they are investing more into it. That said, there are friction points. Document routing and approval often lead to additional work at the clinic level. Moreover, for new providers or patients, it’s difficult to suggest codes at the checkout point, which creates more work for the providers. During the migration, we lost all the historical settings that used to work fine in the old system, leading to more difficulties. Overall, while it’s good enough, it’s not great. I expect that we’ll have to continue building more capability on top of it to deliver the level of care we aspire to.

How likely are you to continue using this product over the next two to three years?

For our existing clinics, the probability is high due to the challenges of introducing a new EMR. However, for expansion into new areas, we might consider other products that are easier to build on top of.

Lastly, do you have any advice for someone who is currently selecting an EHR?

That depends on the level of development. For the tech enablement we are aiming for, Athena works well enough. However, platforms like Elation and Canvas are much easier to use, especially with a headless EMR approach, if you’re pursuing a digital strategy. For existing clinics with active providers, Athena strikes a good balance between cost and capabilities. They are continually improving interoperability, so it works well enough. But if you haven’t been involved in migrations or aren’t deeply embedded on the clinical side of EMRs, there can be pain points in setting up the billing and tax entities with an EMR. So, be aware of that before rushing into migrations. We’ve had to adjust our whole approach to EMR go-lives to reduce the friction tied to these aspects.

Overall, my recommendation is to be critical of the desired end-state for core capabilities needed for the health services that you are offering versus nice-to-haves. There are definite tradeoffs between a fully integrated EMR and a more flexible EMR that’s paired with other systems. Going with a lightweight EMR plus other systems introduces significant vendor overhead and potential for interdependency failures, but it might be best-in-class for each independent clinical workflow. Reducing how many different systems clinical and administrative staff have to work in has a lot of value for adoption.