Enter Health

Today we’re going to be talking about Enter Health, and how it’s been used at your former company. Before we jump into that, can you give a brief overview of your former company?

Well, in general, Enter Health is a revenue cycle management company. They’re part of this newer class of RCM that leverages AI for rules management, so that coders and billers don’t have to go through every single claim. My team worked with Enter to try and go live with them using a few different tools within our existing ecosystem. So using our old-school EMR within our specialty, as well as using our then-pending newer EMR, Healthie, as an EHR we wanted to go live with. And in general using the other tools within Enter’s system, such as their reporting suite, their correction suite, all the other parts of revenue cycle management that we’re interested in.

The goal of RCM is getting as much money back as we could for claims that we sent out. On our end, we were focused on Medicare and Medicaid in a value-based setting, so we worked with them to extend their services beyond what they normally provided, to focus on CMS-1450 as a claim form, within their system.

How does the CMS-1450 differ from a CMS-1500?

CMS-1450 is institutional billing, also called UB-04. I know we used it with Medicare to focus on per-patient, per-month billing, focus on general delivery of care, as opposed to services that were provided. Basically meaning that unlike a CMS-1500, you’re not just listing services, you’re listing service dates and services. And then there’s math being done, when the coder goes through, over how much you’re owed based on the percentage of care provided over that month.

So when did you actually go through and make the purchase decision with Enter and then for how long did you use it, or for how long were you in the process of implementing it?

I think we took a month to six weeks to make a full RCM decision. It was pretty quick because we were hyper-focused on looking for a more modern RCM. So we wanted a cheaper RCM, but also someone who used better software. Enter came out on the lead there for a couple of different reasons. One, they seemed at pace, if not leading, in terms of their AI and their software, and how efficient it could be. Two, their pricing model made sense to us. RCMs all charge differently, it’s often a percentage of total revenue that you’re receiving through them. As a start-up, their pricing made the most sense because it had a lower bar to start with, so it could work with us when we were at a smaller scale, essentially having a lower minimum. As we would scale up, it got significantly cheaper to work with them.

Multiple other RCMs we talked to said no to us, because they couldn’t process our specific types of claims. They either flagged the CMS-1450, the institutional claim, as something that they didn’t have a system for with our specialty as something they just weren’t used to, or didn’t have a good case study of working with someone like us, and so turned us down. So part of our vendor selection process was looking for what we wanted, and part of our vendor selection process was trying to figure out which RCMs would actually take us on. And that’s how we ended up with Enter.

Got it. And for the vendors that you spoke to that were willing to take you on, which vendors were in that selection set for you?

Two categories of RCMs that would’ve been looked at and compared against. You have the more modern, generic, tech-based RCMs like Enter. That includes Candid Health, Change Healthcare and TruCare. TruCare is hybrid because they’re a service-based company and a tech-based company. Then there are the specialty-specific billers that are definitely service-based and specific to our industry. We looked at SimiTree, as well as EMR-based providers. So we worked with an EMR that we inherited with our first practice, and in general there are other EMRs where they offer billing coding services as part of managing the EMR.

Got it. How did you think about that decision process? What pulled Enter to the front of that pack for you?

One of the reasons that it was a long implementation process is that we learned a lot as a startup and our criteria evolved over time. But one criterion was functionality - for our specialty, can this RCM provider do it? And especially if you’re talking with a tech company RCM that isn’t used to, or hasn’t worked with this type of specialty before, there needs to be really solid proof that they can do it. And we had a lot of discussions with them on that front, we asked for referrals from other customers, case studies for similar specialties. We asked about different types of claims processes to understand how they made that work without breaking their system, which is important especially with rules-based systems.

Number two was the ability to automatically correct when something gets rejected, so whether they can identify the issue at hand, fix it, etc. Most service-based billers, coders, or full RCM suites, have a person doing the work, right? They’ll have a person who knows our specialty, and that’s how they handle that. For the more tech-based teams (Candid and Enter Health), it was really working with them to figure out how much their team that analyzes claims could learn our specialty. And how would we grow at scale? Would they be able to bring someone in to spot-check? Would their rules-based system catch up?

Our third criterion was price. What was the cheapest way for us to move forward? When you look at specialty billers and coders, they’re very, very expensive at all scales, and it’s because it’s difficult, and they can own the market.

Do you recall how some of the other vendors might have stacked up for you when you were making the decision?

On the traditional side, it mostly came down to price, and to a lesser degree (this wasn’t one of our top needs) but data and reporting. So can we get rich information for viewing the results of the claims process programmatically in a dataset? That’s what knocked a lot of the more traditional, or service-based vendors, out from our original decision. On the tech-enabled side, half of that list said no either upfront, or later on as they learned what our specialty required, and they didn’t want to take on the risk, or didn’t want to take on that functionality. Of the other half, Enter had fantastic transparency and data. They were one of the most competitive on price, at both small scales and larger scales that we were looking at, and had the full-fledged functionality we were looking for. One thing that they lacked was a focus on our specialty, but their team was very organized, and gave us a lot of confidence that they could work with us and figure it out over time with us.

Did you build on top of Enter, or extend the platform in any way?

There were custom integrations made. I wasn’t involved in all of it, because some of that was on Enter’s end, but specifically to make sure Enter could play nice with our future EHR in Healthie.

How easy it was to build what you needed, how were the APIs? Were they robust and comprehensive?

It seemed great documentation-wise, but I don’t have any hands-on experience. I didn’t code with any of it, so I don’t want to speak to it, good or bad. But it was well-organized, and definitely something that we really liked, that we had the ability to build with them.

Did you do any integrations to supplement product functionality, or integrate it with other parts of your stack? And then for those different products, what was that integration process like?

The main integration, like I mentioned, was them working with Healthie, specifically to handle claims within our specialty. They manage that process pretty much all the way, both in terms of the engineering front, and project management, and expectation-setting. Working with them was nice. They seemed to have built a solution that worked, albeit since we were a newer customer in our specialty, there were a lot of hiccups along the way that weren’t necessarily Enter’s fault.

Communication was okay. It wasn’t always the best project management in terms of us understanding how integrations were going, or what we were supposed to do, versus what Enter was supposed to do, versus what a third party might be doing. And I chalked that up to the fact that this was a massive integration that wasn’t particularly normal for working with an RCM. Looking back, usually people work with RCMs that have done their specialty before and they were new to our area of healthcare, so there were a lot of big integrations that they had to build.

Once they had built the integration with your specialty, did you feel that it was done in a high-quality way?

For the most part. Seven or eight out of 10. Didn’t have a chance to test it in production, but seemed well-tested and well-organized, but not always well-communicated, and parts of it were a bit hacky.

I’m curious to talk about the product itself. So from your perspective, what was the full workflow for interacting with Enter?

Got it. So this is the part where we paused work with them, partially due to us re-evaluating what type of billing, coding and RCM we needed in general. But what we were looking at is a solution that would be fully integrated, with data coming out of our EHR setup, into their system, but with a manual set of triggers. Our providers would be pushing out information used for claims, and Enter’s system would be receiving it. This part’s a little bit less automated. There are a number of reasons for this, and this was what I mentioned with the integration being a bit hackier, so it wasn’t a fully automated solution.

Once that claims data was sent, Enter would do the processing, so they would be able to review and submit the claim. They would pre-process it and let us know if there’s anything missing yet, post-process it, so send it off for payment, and then track it within their system. This is the part of the product that we really liked. We didn’t use it in production, but their reporting suite, their general dashboard, their ability to track claims was really well organized, and something that made things a lot better as opposed to what we’re used to in our specialty, which is way more manual reporting and way less transparency.

During the claims submission process, did you have to have any billing or coding staff involved on your side? Or would they handle it end-to-end, on their team?

For our specialty, it would have required specialty coders and billers to make the system with Enter work. And really what’s going on there is that just because the data is in an EHR, it doesn’t mean that the data is in a claim form. And Enter is set up really well for CMS-1500 claims. For example, either the EHR formats it into a claim, and then sends it over to the Enter’s system, or Enter knows exactly what data they’re looking for in an EHR, and they can pull it and turn it into a claim.

Because of our specialty and because we were billing using CMS-1450, neither of those processes could happen. So we didn’t have an EHR that could bundle our data into an appropriate claim. And neither Enter, nor any tech-based RCM as far as we’re concerned, could automatically pull that data from an EHR and turn it into a claim. So the data flowed partially manually, partially automatically, from one system to the other. But billers and coders were needed to review, shape that data, and fill out form fields.

Did Enter provide good task management software, so that these lines of responsibility would be clearly delineated and organized?

It was okay. I think it was a new setup for them as it was for us. So there wasn’t quite enough expertise in the room to make that happen. For what it’s worth, I don’t think any tech-based RCM, or tech-based biller, would really know how to handle that situation. And it actually became really clear when we started to talk with service-based billers, that it’s just a very manual process right now, and that the manual process is well-known and that workflow is well-known. And we had a hard time, and Enter had a hard time, figuring out how to integrate a very manual process with their automated setup.

I still don’t know of healthcare companies that innovate both on the clinical front and the billing front. I’ve seen a lot of healthcare companies, like my former company, where they don’t mess with billing. They’ll innovate on some other piece of healthcare and they stick with a pretty manual billing process.

Are there features that stand out to you with Enter, as being particularly important, relevant, or useful for your workflows?

Yeah, a few features within Enter’s system that we really liked, some of which were on our short list, others that we just liked working with. I’ve already mentioned reporting and transparency, but also just how their platform worked. It’s a modern web app that looked really good, and was really effective at searching and finding either outstanding claims, or processed claims, to really understand revenue as a provider. That was really valuable to us because we wanted to innovate within our own specialty.

Another piece of it, how data-driven they were in general. So as much as our biggest difficulty in working with them was the shortcomings of the data-driven system and the automations that were in place that weren’t set up for our specialty, they did have a solid starting point, in terms of their automation tech, their integration tech, and how the system worked. Even though we were building out pretty big and wieldy custom integrations, we were doing it from a really robust starting point, which was their system and their backend. They were also really good with customer success and implementation. As much as our implementation was particularly difficult, and caused us to pause, that’s not all Enter’s fault, and they did a good job of breaking it down, managing us, and trying to figure out how to implement a particularly hard case, and, from their perspective, probably an edge case.

Were there any features that you were not impressed with? Or parts of the product that you felt needed to work better?

Specialty bits aside, no. If there’s one thing I could have, it would be services, but that’s not their business model. They’re not a service-based RCM, they just had a specialty biller that knew our specialty. But the pieces that were automated, if we weren’t a specialty case that wasn’t part of their, or any other more modern RCM’s use case, their features seemed pretty robust.

Yeah, maybe it’s worth double clicking on what you mentioned with there being no services component. Would they require someone from your team to do all of that work? And is that a general thing, or is it a specialty thing?

It’s a good question. As far as I know, it’s both, but more of a requirement on the specialty thing. Because they have a rules-based RCM, and claim AI process, it’s going to be very well-adjusted towards filing the same types of claims, once they’ve worked with the same customers. So there’s probably less of a need to have billers and coders there.

So I’m coming from a product and tech perspective, but through the experience of working with RCMs in general, I learned about how providers work. You have a lot of smaller providers where there’s enough medical knowledge and billing knowledge there to be able to perform basic processes. And then an RCM that’s more automated comes in to facilitate all the other pieces. So it’s not the medical billing expertise, it’s the submission process, it’s the transparency process, it’s the process of figuring out what went wrong, or if you’re leaving money on the table.

From a customer support perspective, were they planning to meet with you on a regular basis, to help you optimize your claims and revenue?

Yeah, they had a great customer support services process. They offered admin support, at an hourly rate, which seemed pretty reasonable, to help with claim reviews, not medical billing specifically, but just to double check things. You can export work to their team to help with any manual processes that are needed.

What did you like most about the product?

The tech and platform, including the automations and interface. The transparency of the data system, and the status of claims at any given time, and the option for a whole team to look at that - not just the biller, not just the admins. And the ability to scale. So because it was the system set up the way it was, it is thinking through scale from day one. So how would this work the same with 10 claims a month as it would for 10,000 claims a month.

Those things were all things I really liked about the system.

What did you most dislike about Enter?

They didn’t know our specialty. They aren’t yet integrated with every system that we worked with, and those integrations were really painful to build or watch them build, and they aren’t our specialty. So, they were doing a lot of learning at the same time we were, which is understandable, but was difficult to work with.

Is there anything we didn’t cover that could be worth mentioning? Anything you wish you had known now while making the decision?

Before starting this process, I wish we would have understood the different models between service-based RCM billing and coding, tech-based RCM, and hybrid. It’s really important to understand which model fits best and not make the assumption that a tech company needs a tech RCM, versus more manual services, which can sometimes work in a more understandable and well-defined manner.

Given your unique specialty, looking back, would you have been willing to pay a higher price from the start for a services-based EHR?

Yes. Cost was discussed at the beginning, in the middle, and at the end, but by the time that we got to the end, cost became less important.