Qure4u

So today we’re chatting about Qure4u and how it’s used at your company. Before we jump into that, could you give a brief overview of the company and your role there?

We’re an early stage primary care company. Our goal is to provide high-quality care without any judgment or stigma, particularly for people with chronic conditions such as diabetes and obesity.

I was brought on board as the first technology hire. The company initially started with one clinic and plans to expand by opening more clinics nationwide, but they understand the importance of the patient experience and recognized the need for various technological tools to optimize and automate certain tasks. So they brought me in to handle the technology side of things.

What was the initial business problem that you were looking to solve with a product like Qure4u?

We had a couple of problems we wanted to solve. First, we wanted to facilitate virtual visits in a patient app. Athena also has a telehealth product bundled with their services, but we didn’t end up using it. We needed automated data collection of our lengthy intake questionnaires, which are custom to our group. Athena couldn’t handle custom questionnaires through their portal, so our Athena project manager recommended Qure4u, since they knew they could handle it. Qure4u bundles their services, including questionnaires, the patient app, appointment reminder emails, and telemedicine functionality. And we were also looking to Qure4u for remote patient monitoring. We needed a vendor, since Athena didn’t have this capability. And since telehealth was part of Qure4u’s services, it made sense to use them for that too. The self-check-in functionality of Athena is evolving to address the questionnaire issue, but it won’t be available for at least a year. Therefore, at the time of implementation, Qure4u was a quick solution for us.

Were there any core requirements you were looking for in evaluating vendors?

There were a few core requirements and a few nice-to-haves. We really wanted a solution that could facilitate both remote patient monitoring and the issue of custom questionnaires. However, we didn’t fully understand our needs when we were evaluating options because we weren’t live yet, and therefore didn’t fully understand Athena’s limitations. Our main objective was to set up the clinic quickly, so we relied heavily on Athena’s recommendation to consider Qure4u. Initially, it appeared that Qure4u could fulfill all our requirements, so we made the decision without conducting thorough comparisons or evaluations of other options.

Do you know if any other vendors were considered at that point?

We looked at a few options (like Carium) but we didn’t find a lot of options that could deliver a patient-facing app, RPM, and custom questionnaires.

Do you know how the pricing compared between Qure4u and Athena’s stock tools?

It’s actually incremental pricing. We already have to pay for the Athena native tools, including Athena’s Communicator, which is their patient-engagement offering. Communicator is a combination of various components, and in order to use the APIs that make Qure4u’s app function, we need to have Communicator. Essentially, we’re already paying for it. The real question is whether we should also pay for Qure4u to address the shortcomings in Athena’s portal.

How was the onboarding for Qure4u?

The onboarding process was very manual. Spreadsheets were sent via email, and they handled all the configuration for us. Unfortunately, there’s no self-service capability, so it wasn’t the most efficient way to handle things. In fact, we found ourselves doing a lot of repetitive work that we had already done in Athena. If they were to rebuild their product from scratch, they could easily pull almost all the information they need straight from Athena, without having to ask us for anything. This would also ensure that any changes we make would stay in sync, instead of us having to manually update them on their end. This was the main reason the implementation process took about a month.

During the implementation, we had to provide information on appointment types, which appointments should not have reminders sent out, and which questionnaires needed to be sent out for each situation. There were also some configuration errors on their part when it came to the data flow into Athena. As a result, we ended up with data entries that were just answers to some questions without the actual questions attached to them. This is because the questions didn’t exist in Athena’s system. If they had integrated the information directly from Athena, these broken data flow issues wouldn’t have occurred.

What specific use cases are you powering with Qure4u today, and specifically, what features of Qure4u are you leveraging in relation to Athena’s Communicator?

Currently, we’re not using Athena’s portal or appointment reminders. Qure4u has taken over these functions because they own the patient app. Qure4u’s app has a list of tasks on the clinician side, but we don’t use it. They also have a messaging feature that replaces Athena’s Secure Messaging. The interface is simple, but getting the messages into the chart is clunky. Qure4u and Athena messaging are separate, which causes confusion for patients who happen to find the Athena portal.

Qure4u is a Chrome extension that sits alongside Athena but lacks single sign-on and seamless patient contacts. We mainly use Qure4u for messaging and virtual visits, although they also offer self-scheduling and payments. As for the virtual visits, somewhere around 20% of them disconnect in the middle of the visit, causing frustration for our providers and patients. And some of the questionnaires sent through Qure4u come in as PDFs instead of discrete data. Remote patient monitoring data is not transparent for patients, and RPM billing is not handled effectively by Qure4u. We have to manually track patients’ valid readings for billing purposes, as there is no indicator in the dashboard.

What would you say are the relative strengths and weaknesses of Qure4u?

In my opinion, the relative strength of this company lies in their affordability and quick setup due to their existing marketplace relationship with Athena. They have established connectivity.

As far as weaknesses, the product itself is not great compared to other vendors who have better connectivity with Athena. Based on my experience working at Athena, their APIs are very robust and could easily be utilized for better results. It seems like this company doesn’t invest enough in research and development. Although the people we’ve worked with have been nice, the product itself is lacking. Additionally, the platform is unreliable, particularly regarding the virtual visit feature. If the virtual visits drop 20% of the time, it is not a reliable service and should not be offered.

Are there any other reliability issues, beyond the virtual visit functionality?

We haven’t experienced any major downtime problems with the Chrome extension or patients being unable to access the app. The main issue we face regarding stability is the telehealth feature. Other than that, it’s just a matter of functionality limitations.

Do you know how the patient experience is with Qure4u?

Confused. It’s not very logical or intuitive. Once our patients learn how it works, they can understand it, but it’s not easy to grasp initially. One issue we encountered was when a patient informed us that we had directed them to the wrong address. Upon checking, we found that the “get directions” link in the appointment was pointing to a different address than our clinic’s. This discrepancy is because Qure4u has a separate configuration for the latitude and longitude it should point to, which is an odd implementation decision. If I were designing the product, I would have simply pulled the address from the appointment to direct people accurately.

How well does Qure4u integrate with Athena?

Scheduled appointments go through to Athena automatically, but there seems to be a delay in their refresh rate, perhaps occurring only once every hour. Messages from patients are eventually documented in the patient’s chart, once the doctor responds. However, instead of organizing them as a threaded conversation, each message is recorded as a separate entry. So, if we, for instance, engage in a back-and-forth conversation as doctor and patient, it would be displayed in the chart as two separate patient cases rather than one case with the complete exchange. Each provider or clinician has their own message inbox, so the patient would send messages to different providers, and they can’t see each other’s messages.

How was the integration process?

Getting up and running was simple as an Athena marketplace partner. We just had to provide an electronic release allowing Qure4u to connect and retrieve our data, and then Athena and Qure4u handled the actual connection. However, the configuration process for Qure4u was not as smooth as expected. Instead of manually providing them with spreadsheets of information, it would have been easier if Qure4u could access all the necessary data through the appropriate sequence of APIs. This would have prevented errors and kept everything in sync.

How do you feel about support and account management?

They’re responsive. They’re really nice. I think they’re trying really hard. But the product they’re trying to support is just not very good.

Do you think you made the right decision in moving forward with Qure4u?

Probably not. If we had taken the time to search, we could have found a better vendor offering similar services to Qure4u. We were in a rush and relied too heavily on the project manager’s recommendation.

What is your long-term strategy?

In the long term, our plan is to adopt a similar approach to Qure4u for the most part. However, we have no intention of developing our own RPM data intake. The technology behind RPM involves patients using cellular-connected devices, such as scales or blood pressure cuffs, which then transmit the data through a cell tower to the vendor’s remote patient monitoring platform. We don’t want to handle any of that ourselves, including shipping these devices or managing the cell connectivity required to collect the data. Instead, we are searching for a vendor who can handle this specific aspect for us.

Regarding the patient app, communication with providers, and appointment scheduling, we’ll make use of Athena’s service offerings. We plan to incorporate their telehealth product into our own app and utilize their API platform to facilitate the exchange of data. Essentially, we’ll focus on optimizing the front-end patient experience while leveraging Athena’s existing capabilities.

What key requirements are you prioritizing in the short term for those specific product categories?

We know exactly what we’re looking for with the RPM clinician experience this time. We know what data we want to immediately see and how it should be integrated into the patient’s chart. We also want the system to automatically filter out invalid values. We have learned from our current pain points and now know what we don’t want next time. Athena’s capabilities could have helped us avoid some of these issues if we had utilized them from the start. The APIs provided by Athena are pretty straightforward, so we want to ensure that the RPM is using the appropriate APIs to place the data in the right location.

Do you have any advice for folks looking to purchase in similar categories?

There are four key factors I’d recommend. First, determine if they offer something not already available through Athena. Keep in mind that Athena constantly adds new services, such as their telehealth offering during the Covid-19 pandemic. In the past, you might have needed a separate vendor like Qure4u, but now it’s integrated into the EHR and practice management system. Since you’re likely already paying for it through Athena’s bundled services, it may not be necessary to explore external options anymore.

Second, assess whether the data integrates smoothly with your existing Athena setup. Consider how it aligns with your current workflow and where the information appears in the patient’s chart. It’s important to avoid creating an additional place where providers have to check for data. Ideally, the integration should seamlessly fit into your established processes.

Third, ensure that the vendor’s solution is reliable and stable. It should perform all the expected functions without any issues. Dependability is crucial for smooth operations.

Last, check if the vendor requires manual configuration of settings that you have already set up in Athena. If this is the case, it could create problems in the long run, as the configurations may become out of sync over time.