DrChrono

Could you give a brief overview of your company and role there?

I work at a tech-enabled orthopedic care clinic, and I’m the Director of Product. We are building what can tritely be described as the “One Medical” for specialty surgical care with a focus on orthopedics, to start. We’ve gone out and acquired a few clinics in our market, and are also building new clinics. Ultimately, our goal is to build a value-based care health system that goes out and contracts for episodic care with payers and employers, and provides world-class clinical and administrative care for patients undergoing surgery.

You are currently using DrChrono as your EHR. When did you purchase it, and how long have you actually been using it?

We’ve been using DrChrono for about a year. Prior to acquiring any clinics, we had decided that we were going to use Athena, and started implementing it. We went out and we acquired two clinics and both of those clinics were on DrChrono, so we ultimately just made the decision that, in the short term, we would stay on DrChrono because the switching costs were really high. Everyone knew DrChrono well and was adept at using the DrChrono workflows. It’s not that we went out and did a massive evaluation and thought DrChrono was the best of all the EHRs out there. It was more just, “Easiest to stay with DrChrono for now.” Folks on our team and I had experience using DrChrono at our previous company. It was definitely a known entity, even though we’re probably not going to be using DrChrono in three to five years.

When you are acquisitive in nature, I think you have to be thoughtful in your tech stack strategy. You’re not going to be able to plan everything and have everything be totally centrally decided. I’d be curious to understand how you use DrChrono at your organization.

We use it as our EHR and our RCM system. Our doctors are basically doing everything in DrChrono. Other than for occasionally texting or emailing with patients, DrChrono is the system that they’re in. Our staff are also mainly in DrChrono, although they’re starting to use some of the other tooling that we’re building outside of DrChrono. Our goal is to use DrChrono for the things that we don’t want to build ourselves, like clinical workflows, charting, even scheduling, etc. Our goal is not to build something completely separate outside of DrChrono, but there are a lot of things that DrChrono doesn’t necessarily support well. So our strategy has been to build tools that augment DrChrono, for workflows that our staff are doing outside of DrChrono. So basically, DrChrono plus our native solution makes up the clinical workflows that our staff and doctors are using.

What are the features that you’re using from DrChrono that do seem to work well?

For scheduling, it works pretty well. We haven’t had too many issues with scheduling thus far. It’s administrative scheduling. So, patients can’t self-schedule. Patients can submit inquiries, but we ultimately are the ones that are scheduling them. We can get into this later because I’m sure you’ll have questions about what’s not working well. We’re having a lot of issues with office locations. As we add more providers, that’s starting to get super cluttered. But for now, scheduling has been fine. We have no plans to build something ourselves.

DrChrono is our source of truth for patient information. We are heavily utilizing the patient profile. All the demographic information and insurance information that gets entered into DrChrono acts as the source of truth. We’re using that information in some of our other workflows, but DrChrono is where we go for that source of truth. In terms of charting and clinical documentation, that’s worked out pretty fine for us, thus far.

So, I’d say those are the three core things. We’re using DrChrono for referrals and faxing out, etc. So I’d say those are the core use cases that we’re using DrChrono for and we’ll probably continue to use DrChrono for.

Some things that we’re using DrChrono for that we’re not happy with are billing and RCM. We’ve just run into a ton of issues with both patient payments, as well as submitting claims to insurance companies. I think at some point, relatively soon, we’re going to have to rethink whether we want to use DrChrono or if we want to use an outside billing system. We started using DrChrono for tasking. That’s also something that hasn’t worked out super well, thus far. In the short term, we’re going to try and really rethink some of our tasking workflows and see if we can make those work better. But, I definitely see a world where we start doing tasking outside of DrChrono, as well.

Gotcha. What isn’t working well on the RCM side?

We’re losing money because claims aren’t being submitted correctly. That has to do with DrChrono’s inability to support simple billing workflows. I’m not the person who’s in charge of that, so it’ll be hard for me to get into the weeds of exactly what’s not working well with billing, but we’re losing out on money because of that. DrChrono does some weird things. Certain things get overwritten and there’s no record of what was there originally. Sometimes the logic doesn’t perfectly match up, so it’s hard for us to even trace where things are going wrong.

On the patient payment side of things, we’re using Stripe as our payment processor, which is set up through DrChrono. We’re not able to actually issue a refund through Stripe. DrChrono was saying, “You can only issue a refund through Square.” So, now we have to go and see whether we can switch over to Square in order to be able to issue refunds through credit cards. So right now, we have to issue refunds via check.

There are just all these weird little things that DrChrono doesn’t support well. Their account management is non-existent, so they don’t really have people that are able to help you work through things. I mean, they have a support team that is able to very quickly respond to basic inquiries. Anything that’s a little more complex, or specific to us, there’s no one with any context about what we’re trying to do who’s able to help us. So, it just leads to us banging our head against the wall and talking to a bunch of different people over and over and over again. We’re losing money over this, and that is the line in the sand where we’ll have to move to something else if we’re not able to fix that problem.

On the task management side, what isn’t working for you?

Their UI for tasking is just super confusing. So, as we introduce more and more tasking workflows, I think it gets really difficult for our staff to keep up with what it is that they’re supposed to do. Then, there’s no automation of tasking in DrChrono. You can’t set up rules where, “if this happens, then this happens.”

So, we’ve been using Awell for setting up some of our tasking automation. As we understand it, there are other companies out there that integrate with DrChrono, where you can set up tasking rules more easily. So, that’s something that we’re definitely going to evaluate because we do eventually want to get to a point where tasks don’t need to be assigned manually all the time. Instead, it should be like “If a patient comes in and they have this insurance, then X, Y, and Z need to be assigned out to X, Y, and Z people.”

Is the issue with Awell and DrChrono the fact that there’s not a strong integration between the two of them?

Yeah. The issue isn’t really Awell. I mean, I think Awell is doing a good job of supporting DrChrono tasking. It’s more just having two separate systems for tasking, when we could just have one system where we manage everything, would be a lot easier. Maybe Awell ends up being that system, but there are things like Dock Health out there. Also, Awell’s really sort of a backend platform right now. So being able to use a platform that does both the front end and the back end of automation, as well as the actual UI for tasks and completing tasks, would be ideal for us in terms of maintenance.

You mentioned one other thing earlier, which was the multiple office locations. It sounds like scheduling is going to become more painful as you grow.

This is going to get a little in the weeds. In terms of claim submission, you can’t have multiple Tax IDs associated with a single office location. We have certain providers where, based on the insurance that we’re billing, we’ll have a different tax ID for someone’s Anthem contract compared to their out-of-network billing.

So, what we’ve ended up having to do is if there’s one office location, we’ll have one doctor that has three separate locations (for that office) based on all of their different insurance contracts. Then, other doctors that are at that same location as well, also have different office locations. So, we end up having seven or eight office locations for one physical office. That’s super confusing for our staff, in terms of knowing which office location to schedule patients at. As we add more providers to our specific locations, when it comes to things like rooming patients and figuring out exam room capacity, that’s going to be basically impossible since we’re going to have multiple locations within DrChrono linked to a single physical location. That is going to make it really hard for us to use DrChrono for scheduling as we continue to scale.

Because of that, we have about six providers and 30 plus locations in DrChrono, right now. And you’re also not able to limit which office locations show up for a particular provider. So if a provider has seven locations that we want them to schedule in, we can’t go in and say, “Oh, only show these seven locations for that provider.” We have to show the 35 or 40 locations.

So when our staff are scheduling, they’re picking from a list of 40 locations for a particular provider, rather than seven, which gets to be pretty annoying. If that’s where we’re with six providers, when we get to 30 providers, you’re going to be picking from a list of hundreds of locations, which is just not going to be sustainable.

Do you guys do any telehealth?

No. We don’t do any telehealth. That’s not a huge bridge that we’ve had to cross, yet. I’ve talked to folks that are on DrChrono that do a lot of telehealth. They’ve had a ton of issues with scheduling and scheduling across different time zones. So luckily, all of our providers are in the same time zone. I know that DrChrono does not do well with time zones. So, if we expand to another market in a different time zone, that’ll definitely be a big problem for us, as well.

Are there any features that you just don’t even use because they don’t work the way that you would need them to?

So, we have been using DrChrono’s Patient Portal for digital registration, or intake. That’s been working pretty fine, but there are a bunch of other features in the patient app that we’re not using - things like chat and viewing documents online with self scheduling.

The reason for a lot of that is because we’ve kind of built some of that stuff outside of the DrChrono Patient Portal. Our strategy, at least thus far, has been to try and keep patients from logging into an app and really communicate with them via the channels that they’re used to communicating on. So, we do a lot of email, a lot of texts. For us, our care is pretty episodic. It’s not like we’re necessarily managing a patient population over the course of years, where a patient would like an app that they can keep coming back to. Instead, we’re working with patients for 90-120 days. Then after a successful surgery, the check-ins are more periodic. As a result, we’ve stayed away from interfacing with patients over an app and really focused on email and SMS communication.

Have you been building on top of DrChrono and using the APIs?

We’ve been using their APIs and webhooks a ton. Their APIs are relatively robust. So, that was one of the reasons why we were okay to stay on DrChrono. We built on DrChrono in the past and knew that it supported a lot of our use cases. Their webhooks are really nice, the fact that they’ll kind of ping us when something gets updated, rather than us needing to constantly call the APIs. That’s gone pretty well.

On the other hand, they don’t provide much support. So as we’re troubleshooting or looking to solve issues, there’s an api@drchrono.com email that we can email. Typically, it’s a support person who then has to escalate it to somebody else. It always takes a lot of time for us to hear back from them, which is pretty similar to the account management issue that I was talking about earlier.

We reached out to DrChrono’s leadership multiple times and said, “Hey, look, we’re willing to pay you more if you can provide us with more white-glove service. If we could have someone on the engineering team and an actual account manager, who respond to us within 24 hours, we’d pay for that.” It seems like their account management and customer service arm is a bit of a mess. We would pay them a good amount of money. We’re a venture-backed start-up, and this is really important to us. Our tech stack really matters. So being able to build quickly, and to use DrChrono to its utmost capacity, is something that’s super valuable to us.

So, that hasn’t really worked out well on the API side. It’s less so now, but when we first started building on them, we ran into a lot of rate limit issues and struggled to kind of troubleshoot what was going wrong because they didn’t really respond. They’ve increased the rate limit a few times, and we’re in a good spot now, but there were definitely a bunch of hiccups early on.

Were there any other “gotchas” or things that made it challenging to build on top of?

I’d say those were the two main things. Another issue that we noticed with DrChrono… We’ve used a couple of tools that integrate with DrChrono independent of us, so they’re part of the DrChrono marketplace, and a lot of those integrations are really janky. As we’re trying to troubleshoot why something is not updating in a system that’s supposed to be integrated with DrChrono, we found that both the integration/technical teams at those vendors, as well as the technical teams at DrChrono, aren’t really able to help us. So, we’re powerless because it’s not our technology. We have these two systems that claim that they work together. When we reach out and we’re like, “Hey, this isn’t working.” It’s just, “We’ll get back to you,” or “We don’t know what’s going on.” So, that’s been pretty frustrating because you would hope that things in a marketplace that claim that they integrate with DrChrono would integrate seamlessly.

Yeah, can you tell me more about your integrations?

So, we integrated Front. That’s a totally separate tool. We built the integration between DrChrono and Front. I’d say that that’s gone pretty well. I mean, we’ve had a few hiccups, but that’s to be expected. Then, we’ve integrated Retool, where we’re building our native PRM with DrChrono, as well. Honestly, that integration has gone well. There was an issue, I don’t know, it was probably three weeks ago, where AWS went down on the East Coast for a little while.

Probably, part of that issue was just that we didn’t design the integration super well. We’re a super small team. We’re not necessarily always planning for the worst case scenario just because we’re trying to move really quickly. So we ran into an issue where data wasn’t updating because obviously AWS was down. Then, once it went back up, we had to reprocess a bunch of stuff. That ended up taking our engineers a couple of days, basically to make sure that everything was synced up and that all the actions that should have happened, that hadn’t, happened once AWS was back up. When there’s a problem, there’s a real problem. It takes us a while to figure out what’s going on. So, that’s been an issue. I’d say our native integrations of DrChrono have worked pretty well, as far as integrations go.

What’s been a nightmare is vendor integrations with DrChrono. One of the reasons why we want to move off of PatientPop and Zocdoc for scheduling is the amount of time that I just spend on the phone with Zocdoc and with PatientPop. Those integrations always stop working. We have multiple providers whose Zocdocs and PatientPops are integrated with DrChrono. There are always issues that we just haven’t been able to fix. Every Zocdoc appointment shows up on the schedule as a lead appointment. We have a Zocdoc profile, so we want them to show up as Zocdoc appointments. Yet, there’s just nothing that Zocdoc or DrChrono have been able to figure out in order to stop that from happening. I mean, that’s a small thing. It doesn’t matter that much in the long run. It kind of shows our lack of control and the inability for us to go to them and say, “Hey, there’s a problem,” and then they actually fix it. So, yeah. Spend a ton of time on the phone with Zocdoc and PatientPop because those integrations are always breaking.

We use Health Gorilla for a lot of labs and imaging. That’s worked relatively fine as an integration. We also used Collectly for patient collections. That integration was also a complete nightmare. There were always issues. We were always reconciling like, “Why are the payment records in Collectly different from what’s being recorded in DrChrono?” Long story, but we ended up cutting off ties with Collectly and just using DrChrono to collect patient payments, which has led to its own host of issues. At the very least, we’re not worrying about data being unreconciled. At least we have a source of truth, and we know what that is.

I’d say those are the major integrations that we have. Our own integrations have worked fine, but with vendor integrations, there are a ton of issues. A lot of times it’s spending a lot of time on the phone with people who are not able to help troubleshoot.

Were you pretty involved in the procurement decision?

I pushed pretty strongly for us to use DrChrono. We honestly didn’t have the bandwidth to do a massive Athena integration. I think it was the right decision. We’ve run into a lot of issues with DrChrono. Had we done an Athena implementation, I think it would’ve taken us a really long time. It would’ve been really confusing for our staff. As we get bigger now and have more resources that we could fully dedicate to an Athena implementation, I think we’ll consider going to Athena, or somebody else, at some point in the next year or two, but we’re not there yet.

Thinking through these two vendors, are you comparing them in any way? Are you looking at other potential products other than Athena?

So, when we originally looked at EHRs, we looked at Athena, we looked at Elation. I think we’d look at Elation again. Canvas was still pretty young. We did the evaluation a year and a half or two years ago. So, I think that there are probably some more headless EHR, kind of like API-forward EHRs, that are more mature now than two years ago. So, there are definitely other players that we could look at when we do another evaluation. Then, we looked at ModMed, Modernizing Medicine, which I thought for orthopedics was far and away the best EHR. Their APIs are just extremely limited. So, I think for just an independent ortho practice that doesn’t have a tech team, ModMed would be what I would’ve picked.

We’re a value-based care company. We’re trying to build our own technology that supports value-based care, in addition to our EHR, and that just made ModMed not the right decision for us. DrChrono is a lot simpler to use than Athena. Athena is a massive EHR that supports a ton of different specialties and a ton of different types of clinics and hospitals. There’s just a ton of configuration that goes into building out your Athena instance. It’s just a lot more complex than DrChrono, which ultimately I think is good in the long run. It means if you can be really thoughtful about how you want to configure it and you have really smart operations people in place who can help train staff and get everyone on the same page, then that works great. But for us, with our limited resources and the fact that we just have a couple of independent clinics that we were bringing in, DrChrono’s simplicity is super helpful. There’s not a ton that you can do in DrChrono. It’s pretty easy to navigate the UI and to know where things are, or where you need to go for certain things. That’s definitely a plus for DrChrono, especially when thinking about it as a shorter term solution.

How does everyone stack up for you on price and value?

DrChrono is so cheap. We pay per provider seat. I don’t even think it’s 1,000 bucks a month per provider. They don’t charge us a percentage of collections, so it’s just per seat. With Athena, they really try to charge you a percentage of collections. They basically made it impossible for us to not. If I remember correctly, there was no option where there wasn’t a percentage of collections. We’re a high-margin, specialty group. We’re billing surgeries that are $20,000 to $60,000. If Athena is collecting even 2-3% of that, that’s a lot of money. Even if we’re using our own independent billers, they still wanted to collect. So, DrChrono was way cheaper than Athena because of that, which made economic sense for us.

One thing that is really nice about Athena is you can pay for their API services package. I can’t remember exactly what it was called. Basically, we had access to their technical team. We had biweekly meetings. They would answer any questions that we had. They responded to emails really quickly. Yeah. I think it was the platform services fee - like $5,000 or $6,000 a month. For us, something like that is totally worth it if we have a direct line to their technical team as we’re building. With DrChrono we’re not paying anything. When there’s a problem, we struggle because we don’t have a direct line. So, I think that sort of tiered approach that Athena’s taken, in terms of supporting you as you build out Athena, is really nice.

So, what do you like most about DrChrono?

I like the simplicity of the UI and the workflows. As someone who’s non-clinical, I know where everything is, and it’s very easy for me to figure stuff out. I remember when we were doing the Athena implementation, it was just overwhelming. There was so much that I just didn’t understand. So, simplicity; very cost-effective. It’s cheap. The APIs are pretty robust. Thus far, we’ve been able to build on top of DrChrono everything that we wanted to build on top of them. The fact that they have webhooks also makes that even easier. For the size that we’re at right now, and for what we’ve built thus far, it’s been a pretty good partner.

What do you dislike about DrChrono?

The support is awful, their account management, their API support. I’ve spent so much time trying to track people down and trying to get questions answered. As we’ve onboarded new doctors to our instance of DrChrono, because we’re trying to get everyone on the same instance of DrChrono, that implementation process has been a total nightmare. Even though it’s so simple, they just don’t respond. There’s so many things that you, as a user, can’t configure for a new doctor, that DrChrono has to do themselves. It just takes them so long to do it. The ball gets dropped constantly.

In terms of any sort of data migration, that’s a total nightmare to manage, too. Even when we’re migrating data from one DrChrono instance to another DrChrono instance, I’ve had to act as the project manager for their team. They are unable to hit timelines and figure out pretty basic stuff about data migrations.

So support, awful. I think that it’s just not built to support a large practice. It’s built for small practices. As you have to bill out multiple tax IDs, as you have multiple providers that are at different office locations, it becomes a mess really quickly. We haven’t even had to deal with this, but once you’re dealing with virtual care like tele-health in different time zones, it becomes even more of a nightmare. So I think DrChrono, it’s a good tech solution for a practice that’s under 10 to 15 physicians, where everyone’s in the same market and billing is pretty simple. As you kind of scale beyond that, I find it hard to see us staying on DrChrono.

What’s the likelihood of you continuing to use the product in 18 to 24 months?

If we scale the way that we want to scale and add more physicians, and we’re able to bring in more clinical ops folks and more product engineering people, then we’ll definitely move off of DrChrono. Right now, our team’s just really small. If it continues to be small, doing any sort of migration off DrChrono onto another EHR would basically take up all of our bandwidth for, I don’t know, three to four months, which is probably time that we wouldn’t necessarily want to lose. So, the short answer is - I think if we scale the way we want to scale, we’re not going to be on DrChrono in 18 to 24 months.

Is there anything that could change about the product to get you to stay with it?

Honestly, no. We’ve interacted with leadership. We’ve interacted with their head of account management. I have very little faith in the people that are responsible for making decisions at DrChrono that they turn things around. So, I think barring some sort of acquisition, or a completely new leadership team coming in and saying, “You know what? We want to build out a customer-focused EHR that works with the people that are on the EHR.” Barring that, I can’t imagine we’d stay on DrChrono.

It’s too bad because we’d be willing to pay them more money. If they would work with us, we’d be willing to be a flagship customer. As we grow, they could tout how this venture backed start-up is building in DrChrono. I think if DrChrono wanted to invest in those relationships, they could be the tech-forward EHR that venture-backed start-ups are building on top of. They’ve kind of just shown no interest in leaning into that.

Is there anything that we haven’t mentioned that would be worth covering? Any advice for someone selecting this type of product, right now?

A couple of things that we did wrong were, one, we decided to go with Athena too early. I think it’s vital, if you’re going to acquire clinics or build out a clinic, that you have the folks that are actually going to be using the EHR involved in that decision. I think that’s such an obvious statement. We were just trying to move really quickly so we were evaluating EHRs early on. We were like, “This is going to be the base of our tech stack, and it’s important that we get the decision right.” We made the decision prior to when we should have made it. That’s why we went through a partial implementation with Athena, and then, ultimately, switched to DrChrono.

Another piece of advice is I think that it really makes sense to have an expert, either as a contractor or even someone in-house who really understands the EHR, who can help you implement and configure it. We have not had that, so I’ve ended up becoming the DrChrono expert. It just takes up a lot of my time. I should not be managing permissions and configuring a bunch of stuff for everybody. So having somebody, even if it’s someone who works at the clinic who just understands and can be the DrChrono champion, or the Athena champion, or whatever EHR you use, I think is something that will allow you to just move quicker.

As you’re evaluating an EHR, there are going to be probably three or four really important components to it. There’s the kind of patient relationship management or kind of scheduling piece. There’s the entire clinical piece, like “How quickly am I able to chart? Does the EHR support our charting needs?” Then, there’s the billing piece. There’s probably one or two other pieces that are important depending on the type of company that you’re building.

I think, making sure that as you’re evaluating the EHR, you have people in place that fully understand those workflows and can really evaluate them is going to be super important. One of the things that we didn’t have, even as we were evaluating DrChrono, was just billing expertise. We talked to a couple people and we’re like, “Oh, yeah. DrChrono’s billing will support our needs.” Technically, it’s supported by them, but we’ve run into so many issues. I think that if we had involved an RCM expert in those evaluations, we might have decided, “Hey, we’re going to use DrChrono, but we’re going to use a separate billing platform rather than trying to bill everything out of DrChrono.” We didn’t make that decision because we didn’t have that person in place.