Assessing the buy vs. build decision

Recently, Cameron Kerber of Monogram Health sat down with our Rhapsody health solutions team to discuss how he and his team weighed out the decision to buy vs. build when scaling their patient matching infrastructure. He discussed how they made the decision to invest in a best of breed enterprise master person index (EMPI), their Rhapsody partnership, how it’s going and tips for assessing the buy vs build decision as your company grows.  

You can watch the on-demand webinar Buy vs. Build: Scale to Meet Your Growth Goals with Proven EMPI. We’ve also provided a summary of the Q&A from the webinar below, edited for brevity and clarity. 

Webinar participants included: 

• Cameron Kerber, VP, application development, Monogram Health  
• Lori Lauritzen, engagement manager, Rhapsody 
• Michelle Blackmer, chief marketing officer, Rhapsody 

Skip to:  

• Overview of Monogram Health  
• The Monogram Health and Rhapsody partnership 
• Assessing the buy vs build decision  
• Using Rhapsody for both integration and identity solutions  
• The need for an EMPI 
• Considerations for buying a Master Person Index  
• Choosing a vendor  
• Integrations that accelerate EMPI implementation 
• Stakeholder perspectives on choosing Rhapsody  
• Use of Envoy iPaaS 
• Approaches to creating a manageable project  
• What’s next for Monogram Health?  

Michelle Blackmer: Tell us a little bit about Monogram Health, your role, and what your team does?  

Cameron Kerber: At Monogram Health our mission is to transform the way healthcare is delivered for people with kidney disease so they can lead healthier, happier, and more fulfilling lives. We’re a leading value-based provider of in-home evidence-based care and care management services for patients living with poly chronic conditions, with a focus on patients with chronic kidney and end stage kidney disease. We have a unique integrated provider service approach — a mix of software and people — that allows us to treat complex chronic conditions emphasizing conservative and palliative care options while improving access to affordable care in the communities we serve. 

We have a large interdisciplinary clinical team — a mix of care managers, social workers, nurse practitioners, specialists, and medical directors — that allows us to be responsive to the needs of our patients. The application development team at Monogram Health is composed of developers, administrators and analysts, and focuses primarily on any of the applications our end users (clinical providers) interact with. If they are charting about our patients or utilizing data to know when to intervene with patients, we develop the applications for them to interact with.  

MB: Lori, can you discuss how Rhapsody works with the Monogram team?

Lori Lauritzen: As engagement manager, it’s my role to manage the partnership between Monogram and Rhapsody. That means that I pretty much take care of everything Cameron needs, whether it’s managing the various projects that he has going on, or making sure that we resource things appropriately. Our team consists of a variety of implementation architects for both Envoy iPaaS and Rhapsody EMPI. 

MB: As you scale your business how do you think about making the buying or building software decision? 

CK: I try to keep it fairly simple. We build where we really want to differentiate as an organization. So [that’s] primarily with our patient experience, our clinical workflows and our data insights — which allow us to personalize the experience both for the patient, and the clinician that is working with these patients — by providing the right insights to our providers at the right time. That’s where we want to differentiate, so we will build solutions to support that.   

We look to buy wherever we can accelerate features to market, utilize expertise we do not have or that provides a solution to scaling that might take us too long to get there ourselves. 

MB: How did you know integration and identity management are two problems Monogram Health needs to solve? 

CK: With any kind of IT strategy, there’s going to be some type of integration required, and nobody’s building an integration strategy from scratch. You can either utilize services from the major cloud providers — that will get you some of the basic infrastructure for implementing a lot of the integrations, or you can move up the stack into thorough software solutions or managed services. Given our size and how much we wanted to develop ourselves versus offloading, our company looked at an offering that could augment both the hosting of the integration environments and the development of those integrations.  

Rhapsody has the experience and expertise, and we knew we’d be able to scale quickly and be able to accomplish multiple integrations faster — with less duplicative work — if we leveraged that expertise and experience. 

Rhapsody has the experience and expertise, and we knew we’d be able to scale quickly and be able to accomplish multiple integrations faster — with less duplicative work — if we leveraged that expertise and experience.

– Cameron Kerber, VP, application development, Monogram Health 

Integration is always a core to our strategy. Ever since I was an engineer working right out of college 20 years ago, we were doing some sort of integration — we were managing the software, we were writing the integrations. As we grew as an organization, technology matured, and the healthcare industry matured, there wasn’t a lot of value in us having ownership of that portion. It was better to utilize the leverage of an organization like Rhapsody to scale that. 

MB: What led you to pursue a master person index? 

CK: Monogram Health was founded in 2019. Now we are really investing in a solution from Rhapsody, but until recently, we had built our own solution. For a smaller company, there’s less chance of duplication. With a startup, everybody’s wearing lots of hats and you’re working through your processes and figuring that out.  

As we started to scale and have new areas that we wanted to invest in — we had to ask, do we really want to continue to maintain our internal software for doing that mastering of patients? Or support all the downstream processes that have to be supported to then be reconciled? We really wanted to reduce all of those risks, and wanted to remove the ownership of the maintenance around that code and as well as enhance it.  

We wanted to have better tooling that supports who’s potentially duplicative as a patient, and we wanted to really reduce any of those patients, making it to our operational systems where there’s the largest amount of overhead because that’s the last place where it goes. That’s really why we wanted to make that investment as we’ve really started to scale and grow our business. 

MB: What kind of considerations did you give for buying a master person index, beyond reducing clinician burden?  

CK: The responsibility for the time to build, maintain or upgrade any of the infrastructure, or the level of troubleshooting that one has to do associated with these costs. That’s something our IT team could take on, but it’s probably not the best use of our time when we really want to differentiate the patient experience or those clinical workflows — that’s where we want our team members spending the majority of their time.  

When we talk about that return on investment, you have more of the operational costs to maintain your own environment or infrastructure to support that. There’s also the opportunity costs that are lost, because you’re not spending your time really advancing the business or your mission.  

MB: How did you select a vendor?  

CK: In this case, for EMPI, we had already been utilizing Rhapsody as our vendor for integration. We had that working relationship, which was working out very well. We knew the individuals like Lori and her team that we’ve been dealing with on a day-to-day basis. So we knew that they were committed to us, that we’d have the success that we want, and that the capabilities were there for the EMPI. We were looking for something that provided probabilistic and referential data matching.  

We looked at four or five different vendors in the space. As we started looking at it based on capabilities, price and that known quantity factor, we quickly landed on the Rhapsody team. 

MB: You were interested in augmenting your data with third party data and then being able to maintain that in the data model, that was important to you, right?  

CK:That was really in our capability list. That was a differentiating thing that we wanted. Being able to augment our patient information with additional data attributes associated with our patients so that we could utilize that for better insights or potential outreach to our patients was really helpful. That, coupled with the solution made it much more appealing and helped with the ROI for our business case. 

MB: Lori, how has having an existing relationship made it easier for the Rhapsody team to support Monogram?  

LL: We had the relationship doing integration with Envoy early on and learned quickly how Monogram operates as far as how they run their projects, how many projects they like to run at the same time, and what their needs are. We watched the pipeline really closely, so we already had established that relationship when EMPI came into the picture. So really it was just adding another meeting to the calendar, bringing in some other subject matter experts — our architects on the identity side and then just rolled with it. It’s just another project in Cameron’s portfolio. So, we saved a lot of time on the start up. 

MB: What types of integrations are you doing, and has that helped the EMPI implementation accelerate?  

CK: We’re doing a lot of integrations. We primarily have two, maybe three, facets. Either externally with vendors — so other data partnerships that we might be looking to achieve externally with other customers. Then internally, where we might be exchanging information between our different internal clinical systems. When we initially launched, we focused a lot internally. We primarily utilize Athena’s EMR, Salesforce, and some other systems, but we really wanted to improve the efficiency between those two. We spent the first few months of working together around that — looking for quick wins and then finding the best way to improve clinical workflow. We really wanted to leverage the expertise from the Rhapsody team and drive towards improving some of the data flow with our external customers.

Admission feeds (ADT) for example — knowing when our patients are in the hospital as early as possible — is very important to us. The more real time we can make that notification between our customers really helps our patients. Adding Rhapsody into the mix added another tool to the toolbox in our relationship with our customers, because then instead of either flat file ingestion or other types of ingestion, we can now add real time HL7 integration, and start to leverage that with other additional data sources.  

Sticking with the ADT example, now we can have easy relationships with different health information exchanges — with different state HIEs — being able to ascertain notifications as patients are going in and out of the hospital. We’re able to reuse that kind of base integration for admissions, but then have it pointed to other different customers or different vendors or partnerships for layering that. 

Has it accelerated the time from when they agree to be a customer or partner until you go live?  

CK: From a customer standpoint, you need options when talking to customers because there are a lot of different ways that you’re going to end up trying to work and onboard a customer. Having another option that is very seamless, provides quick to market ability. Our clinicians definitely have noticed that it provides more of that real time data feed versus something that might take a day or two because of a different interoperability pattern that has more hops to getting the information into our systems. It’s definitely advantageous for us. 

MB: I’m thinking if it’s all going well and the integration and identity are working together, the clinician shouldn’t even realize. It’s just a good experience for them. 

CK: That’s right. From a clinician perspective, you only hear about the integrations in the EMPI when things are going wrong. Having Rhapsody as our existing integration partner, made it really easy to onboard our EMPI because that was the mechanism, or the tool that we could use to drive how we get our member patient data from our systems, to being able to be shared with that EMPI and then that information being shared back. With that in place — it’s really seamless and just has that single team that we need to pull it all together.

MB: Were there additional stakeholders you needed to include in the buying decision? Do you have any best practices you can share with the audience? 

CK: With the integration strategy, it was a little more straightforward. Integration is like a standard capability that you need at some level in your application stack for almost any IT shop — it’s the behind-the-scenes glue that makes everything occur.  

With EMPI, my team as the application development team, it was more of the downstream system, but we could see the challenges and the opportunity of why EMPI would be a good solution. We’re responsible for those clinical systems or call center systems. Being downstream, if there was a duplicate patient that made it to that system, then we’re hearing the complaints — we’re getting the calls. We knew we wanted to better that process, but a lot of the responsibility of identifying patients fell with our data teams. We agreed that this is a problem and a space that we can improve upon.  

We had the initial conversations around, ‘let’s set up the problem and what we could do to address it’. And then started having the discussions with potential vendors and seeing and reaffirming that the capabilities that these different vendors have really outshine what we could build and where we really want to spend our time.  

Bringing the different stakeholders along as part of that change management process and bringing them in early was really important because if we went off on our own as our application development team and tried to contract and bring this in-house and then said at the last hour — okay, data team, now you got to send your data here and this is why — it would’ve been a more difficult conversation, difficult to get the buy-in and then difficult to get the outcomes that you’re looking for. My advice here, as obvious as it might seem, is just to bring in your change agents or stakeholders early and often. 

MB: What’s your experience with Envoy iPaaS?  

CK: It’s been great. The Rhapsody team has been really committed and responsive. We’ve had the same team since we started with this group almost a year ago, which is very meaningful. Sometimes you work with vendors and you get a lot of churn and you have to re-explain so there’s knowledge loss that occurs. 

There’s also just been the commitment. We work with the Rhapsody team on almost a daily basis — we always have something else we’re trying to improve or engage upon. Having that high level of commitment is the other portion. Sometimes when you move something to a managed service, you might be concerned about the responsiveness — like, ‘let me slot you in for two months from now when I can get to it with my team’. But we haven’t experienced any of that. They’ve always been responsive and found a way to make our needs work amongst all their other customers. 

MB: Lori, what’s your philosophy and approach? What’s really setting Rhapsody and the Envoy team apart? 

LL: I think it’s the level of expertise that our team brings to the table. Our architects have a ton of knowledge, and they have different knowledge from different backgrounds, which provides this really rich base of knowledge. There’s that level of commitment and it’s one team — really what we want to be is one team — not your team and our team, but one team. 

This is a partnership and it’s our responsibility to help make them successful. Whether it’s helping build out the applications or having our integration experts in calls early on, we do what we need to do.  

The other thing that’s wonderful about working with Monogram is that Cameron comes to the table with each of his initiatives with a clear use case, a clearly defined business problem that they’re trying to solve, and subject matter experts from both the clinical and clinically the technology side to solve those problems. It makes working through all of those projects really nice, because they get things done and it’s really wonderful to see that success. 

MB: It sounds like you and your team are really purposeful in thinking about how you break the problem into a manageable project to move forward. Is that your personal philosophy for approaching projects? 

CK: Yeah, absolutely. Almost any project that I work on, we’ve tried to figure out exactly how you mentioned breaking that problem space down, to how we can get early feedback and early value for our business. That also allows us as a technology team to be able to discover those technology hurdles quicker, and follow that agile mindset. So one of our internal applications that we integrate with has their own validation process for when we’re doing a new integration. By breaking that problem space down, we were able to go through that validation process quickly, which was important. We learned more about that validation process and how long it takes and then therefore when we go through the next one we can account for that or find ways to optimize it. So, I think it’s always important both from the business perspective of how you can deliver value quicker as well as from a technology perspective, because you’ll always find a lot of the hurdles in the last hour trying to get something to production. And so, the faster you can uncover those, the less risk you take on. 

MB: What’s next for Monogram Health? 

CK: We have a lot of growth. We have a lot of new customers, so we’re actively adding tens of thousands of patients to our service to manage, which is great. Also, we’re really leaning into our focus on patients with polychronic conditions and ensuring we have specialists that can really round out that interdisciplinary team and make sure patients know Monogram can support them.  

Patients do not have to have all these different referrals for different healthcare providers and feel like there’s gaps in care. We can envelope patients and provide that service. What that entails for our application development team are a lot more data integrations and finding other ways to use data to drive insights, which provides new customers and new integrations in that space. We’re spending a lot of time continuing to optimize the clinical and patient experience.

Interested in learning more? Contact us today.