Zus Health

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

R1: I’m the chief product officer at a small specialty care, value-based care company. We emphasize providing long-term care, and our main goal is to reduce all-cause admissions. So it’s important that we know a patient’s medical history, as it helps us properly assess their risks. I led the vendor analysis for our interoperability vendor at the end of 2022.

R2: And I’m a senior product engineer. My current focus is on data engineering. Basically, my role involves ensuring that our various systems are working together correctly within our data lake and infrastructure. We want to make sure that we’re delivering data to the right people at the right time to drive decision-making. Specifically, I’m working on building up our data lake on AWS, which is the main platform we use for our stack. We’re also integrating with Healthie and Zus to effectively handle and distribute the data where it needs to be.

What was the need that drove you to look for a clinical data interoperability product?

R1: The main issue we were facing was the need to obtain the medical history of our patients. Our patients are often dealing with multiple chronic conditions, often five or six comorbidities. In order for us to make informed treatment decisions, having that context is crucial. Initially, we collected this information through a patient-led assessment, where we asked them questions. However, this assessment was quite lengthy and not very enjoyable for the patients. Additionally, there was a concern about the reliability of self-reported data, whether through failure to disclose or inaccurately reporting conditions and medications. To ensure that we could accurately determine the appropriate interventions, we decided to seek out a vendor who could assist us with interoperability. This vendor would help us access and gather the patients’ health records and medical history as much as possible.

What were the requirements you used in making your decision?

R1: We decided against direct integration because we work with health plans that have multiple providers using different EHR systems. Instead, we wanted a solution that would allow us to access as many records as possible without having to go through a separate integration process every time. This led us to Carequality and CommonWell.

Initially, our main focus was on accessing data from Carequality and CommonWell as well as pharmacy data and ADT feeds. The ADT feeds were particularly important for us because we needed to be alerted when a patient was sent to the hospital. We have a time-sensitive post-acute discharge pathway, so receiving these alerts allowed us to intervene quickly after admission.

R2: We had two main goals in mind. First, we wanted to obtain a patient’s history upon enrollment in order to properly stratify them based on risk and engagement levels. This involved gathering all their data to get to know them better. Second, we wanted to continually monitor ADT data for ongoing visits. However, we were mostly interested in events such as emergency room visits or hospital admissions, rather than routine visits.

Once a patient is established in our system, we focus on managing them from a clinical perspective. This involves adjusting our approach based on any ADT-related events that may occur. We want to ensure that we take into account these events and adapt our behavior accordingly.

Initially, we weren’t looking at integrating with Healthie as a priority. However, we realized that application switching would be a major challenge for our health coaches. During their sessions with patients, they had multiple different tasks they needed to do. Bouncing back and forth between different applications, such as Healthie and Zus, was a hassle. The coaches wanted medications, encounters, and conditions to be easily accessible within Healthie. The Healthie integration not only helped us pull the data, but also allowed us to visually embed certain UI elements that Zus has built. It was a helpful addition that we didn’t even know we needed at the time.

R1: One major requirement we had was their ability to deduplicate records and extract relevant information. Balancing this can be challenging because we didn’t want them to interpret the data, but we also didn’t want our coaches to have to scan through lengthy documents. So, finding a solution that makes it easy for humans to quickly scan through the documents was crucial.

_We also considered the quality of their self-service portals and end-user interfaces. Initially, with Zus, we only had access to their Snowflake instance. However, they have since been working on developing their own interface for viewing records. They have even integrated a module into Healthie for that purpose. Nevertheless, Health Gorilla has an advantage in this area as they have a more extensive built-in interface. In terms of labs data integration, we understand that Health Gorilla tends to excel here, but we _didn’t evaluate quality or penetration of labs data since we don’t use it ourselves.

And I believe Health Gorilla also offers a patient interface. This means that if a record is shared through Health Gorilla, the patient can log in and access it. Zus doesn’t have any consumer-related features.

What other products did you evaluate, and how did they compare to Zus?

R1: Basically, we began with the intention of incorporating Carequality and CommonWell into our system. We mapped out all the data we needed, including the source and the method for obtaining it. We assessed various providers, such as Health Gorilla, Redox, Particle Health, Zus, Ellkay, and 1upHealth. But 1upHealth didn’t access Carequality or CommonWell, as it is a patient-mediated product.

R2: Health Gorilla was the closest competitor, but they were more expensive.

R1: The biggest differentiator was the platform fee, which was significantly higher with Health Gorilla, ParticleHealth, Ellkay, and Redox. After Zus, HealthGorilla was the most cost-effective option for us and would have been our backup choice if Zus didn’t meet our scaling needs. They both used Carequality and CommonWell, so it was the same data. Zus previously used Collective Medical for their ADT, but now they added Bamboo, which has expanded their coverage. I also spoke to Connective Health at a later point, who are trying to do things a bit differently to gain access to the big health information exchanges, but Zus is working for us right now.

How did pricing compare between the products?

R2: The lack of an up-front fee was the main reason we decided to rule out some of the bigger options, at least for now. It’s just not practical to pay a huge amount before knowing if the integration will actually work for our use cases. So that was our primary concern at the beginning—finding a solution that could scale with us without a hefty up-front cost. Additionally, the fact that the pricing was based on a per-patient model, rather than having a minimum requirement, made it more manageable for us. Some of the other options we looked at still had a high baseline monthly payment, which didn’t make sense for our situation. So those were the two main factors we considered when making our decision.

R1: I believe Zus initially offered us a discounted price as early adopters to make it more enticing for us to say yes. When it comes to accessing Carequality and CommonWell, the quality of basic information shouldn’t be drastically different. The additional features like interpretation and browsable interfaces are what make the difference in how we handle the information. We didn’t compromise on the quality of the information itself, as that is pretty much standardized. Our decision to choose Zus was based on the fact that they were significantly cheaper for us as a smaller company. Eventually, there may come a point where other companies offer better services or their pricing becomes more favorable once we reach a certain volume. However, Zus can keep our business by continuously developing their roadmap in tandem with us.

How was their sales process?

R1: What I liked about Zus’s sales process was that it didn’t feel too “salesy.” It was collaborative, and they genuinely listened to our needs and offered solutions tailored to meet our goals. They didn’t try to push unnecessary features on us, instead focusing on what we actually needed. They were really good at understanding and addressing our specific requirements. They were really listening to us as potential customers, which makes sense considering they were just starting out.

In comparison, I wasn’t a fan of Ellkay’s sales process. It felt overly salesy, with pitches, decks, and a heavy focus on upselling. On the other hand, Particle Health and Health Gorilla were very responsive, and their team impressed us. Ultimately, our decision came down to Zus versus Health Gorilla in terms of pricing and their sales teams. If we had to do direct integration or if we thought it was necessary, Redox would have been our top choice. They are the best in that area, although they charge accordingly.

How would you characterize the onboarding and setup process?

R1: The contracting process was straightforward. We had a pricing sheet that we reviewed, and once it was approved on our end, we set it into the contract pricing. During the setup process, we gave them our NPI, they were able to complete our setup, and we were able to pull the records quickly. After that, they provisioned Snowflake licenses for us so we could see that data before it was imported into Healthie.

Since we have been working with both Zus and Healthie for a while, I am unsure how long it would take for Zus to activate the module in Healthie that connects a Zus master account to a company master account. I assume it would be a quick process. In general, Zus has been very fast in guiding us through each step, with most delays coming from figuring out processes on our end.

What are some of the use cases that you’re using Zus for right now?

R2: First, we have the “up front” phase, where we gather the patient’s medical history data to determine their risk level for program placement and medical background. For example, if someone has been hospitalized recently, they are classified as the highest risk level for post-acute care. If they’ve been hospitalized within the past 12 months, then they may fall into another risk level, etc. This allows us to determine which initial category to place them in and personalize their program accordingly.

The other phase is ongoing, where we receive new data through ADT events that indicate if the patient has been hospitalized or visits the ED. When this happens, it triggers a workflow to check on their well-being. We may adjust their scheduling or automatically include them in the post-acute program and raise their risk level. Essentially, we monitor for any significant changes through ongoing data and take appropriate actions. These are our two main use cases: the initial data gathering to get to know the patient and their medical history and the continuous monitoring for any important changes.

What are some of the strengths and weaknesses you see with Zus?

R2: In terms of strengths, the initial patient history pull is pretty quick. When we create a member and subscribe them to the service, some information comes back within hours, but usually within 24 hours. I think that turnaround is also based on the limitations of CommonWell and Carequality, so likely similar across vendors, but overall that turnaround has been quick and seamless.

Another great feature is Zus’s ability to take their component and integrate it into Healthie’s UI, while still securely sharing information. It works really well.

One challenge we’re facing is deduplication. Sometimes we receive duplicate records from different providers or systems. It would be ideal to have a single, consolidated record, but due to the number of providers and systems involved, that isn’t automatic. To deduplicate, we sometimes have to remove certain data and make educated assumptions. This is an area where Zus could improve or where other companies may be further along.

If we compare Zus to Health Gorilla, Zus’s strength lies in being smaller and more nimble. They are less formal and more willing to let us see what they’re working on. Health Gorilla and other bigger companies have more built-out features but lack the flexibility and adaptability of Zus. In our case, since we’re still building and evolving our own company, the strengths of Zus being smaller and more responsive outweigh the weaknesses.

How is its Zus’s stability?

R2: Overall, it’s been pretty bug free. There were a couple of instances where there were stability issues, but the team was prompt in their response and kept us informed. Currently, our clinical team is using the system every day. Whenever we have new members enrolling, we are subscribed to ADT notifications. This allows us to receive ADT events in real time. So each week we usually have some events that we’re actively monitoring.

How would you characterize the documentation and developer experience?

R2: The documentation is not bad. I found Health Gorilla’s to be more comprehensive, but Zus’s is decent. It provides the basic features needed. They do offer some Postman playgrounds to help with the authentication process and example calls, which is usually the most annoying part when using any new system. However, once you have that figured out, it becomes fairly straightforward. In our case, we were extracting a lot of data from Snowflake. The data we were working with is in the FHIR format, so there’s a need for regularizing or transforming the data externally. They do provide some support for that, but we still have to do additional work to organize the data from nested objects into more flattened tables.

What features do you use?

R2: We have a few different ways that we’re integrating the data. One way is through the React component embedded in Healthie, which was integrated by the Zus team with our feedback. On our side, we have two areas for pulling data. We have a data lake on AWS where we pull data from our Snowflake instance and theirs. They have already flattened the data into different tables like patients and conditions. We join this data with our own ID to link patient identities with their conditions and other data. This is mainly for reporting purposes, to determine a patient’s conditions, medications, encounters, and ADT events. We can also use dashboards to analyze aggregated data, to, for example, see total hospitalizations over a month.

In terms of enrolling patients in Zus, we have a process where our internal database identity management system regularly runs a bulk job to subscribe new members to Zus. Zus then automatically initiates the first call for their patient history within 24 hours of enrollment. We no longer need to manually pull data, as Zus now refreshes automatically each month, and the data is pulled into the data lake when it becomes available.

Currently, we aren’t using webhooks for ADT events, but it’s something we plan to implement in the near future.

Do you have any advice for folks that might want to build on Zus?

R2: I believe the issue of deduplication is something that will always be a challenge. It’s a challenging task, with two aspects that need attention. First, you need to determine if the results you’re getting back are what you are actually looking for. Second, you need to identify whether there are multiple instances of the same thing, or if there should only be one.

For example, we were receiving ADT events every day for the same person, making it seem like they were being hospitalized every day. However, it turned out that these events were actually home healthcare visits still being coded like hospitalizations. We needed to ensure that we thoroughly examine the incoming data and apply necessary processing and don’t simply assume its accuracy.

The second challenge revolves around avoiding the duplication of events. It’s important to avoid mistakenly counting two separate hospitalizations when there was only one event. This could occur when different providers saw the patient during the same hospitalization episode. These are the challenges and roadblocks we are currently addressing, which I believe anyone using similar services would also have to tackle.

R1: Yeah, and this is a situation where we wouldn’t want Zus to make that call because it’s so specific and case-dependent. We needed to have our clinical team look at those results and figure out what happened, and we rely on Zus to act as a middleman and not make those blanket rules. However, sometimes the amount of data that comes back overwhelms our coaches and we need a way to filter. If you don’t have clear guidelines on how to provide them with less or summarized data, you potentially expose yourself to risk.

How would you characterize their account management and support teams?

R2: We have an account manager or key point person for our team who is the go-to person if we have any questions. The nice thing is that there’s a shared Slack channel that their developers and other team members can access, too. So not everything has to go through him. He’s more like the coordinator or orchestrator. We do have a biweekly meeting set up now, but it used to be weekly when we first started out and were integrating and working together. We changed it to biweekly because we don’t have as much to discuss now that things are more stable.

Having one person initially to answer our questions and track down answers was great. We knew we could rely on him. And the communication has been great, thanks to the shared Slack channel. It’s much better than using email and other tools, and it was helpful in setting up the integration between the teams. We might not use it as much now, but it was definitely helpful in the beginning.

R1: I’ve been really impressed with how responsive their team has been. They’ve been proactive in their communication. During an outage, there was a period where records weren’t being pulled. However, they proactively communicated the issue and even gave us credit for it. That level of openness and transparency really impressed us. Additionally, they invited us to do product and user testing, which has resulted in actual product improvements. Their team’s responsiveness is one of the key factors that make us want to continue working with Zus, not just because of their pricing. If Zus wanted to renew today, I would definitely renew. They have been more than a service provider; they have been a great partner as we continue to grow.

Do you feel like you made the correct assessment overall when going with Zus?

R2: Yes. Given our situation back then and where we’re at now, I still believe we would choose them again, based on the same factors and costs and our growth trajectory. Of course, we’ll keep evaluating, but overall, I think we definitely made the right call out of the available vendors.

Do you foresee any additional major areas of growth for Zus?

R2: Yeah, I think they’re focusing more on the ADT side and adding more real-time workflows. They’re also expanding on lab results, which we may look at as well when we think about incorporating different tests or measurements that are relevant to our condition, rather than just relying on the visit notes.

Do you have any advice for buyers who are thinking through their clinical data interoperability story now?

R2: It’s important to have clear use cases in mind for how you’ll use the data in your clinical practice. Although it may seem obvious, when we got down into it, there were a few specific cases where we truly needed that data. We knew that having the medical history of every patient is essential, but what we really needed to determine was which program to put them in and how to analyze their risks in order to establish relevant goals or interventions right from the start. Additionally, we needed to continuously evaluate if any changes had occurred that deviated from the initial plan. This involved creating the plan with the patient initially and then making any necessary course corrections along the way. These two use cases became more evident once we had the data and started working with it.