Ep#119 Healthcare interoperability using FHIR Data Lake

Host: Jon

Hi everybody. My name's Jon Myer. Today's topic is Healthcare Interoperability, B2B SaaS Application with FHIR Data Lake. Our guest today is Pascal Odk, CTO and co-founder of WellBeam. You know Pascal is an entrepreneur software engineer with a passion for solving problems in healthcare with a focus on continuing care and the post-acute space. You know, his interest in healthcare interoperability landscape developments with HHL seven FHIR. All right, please join me. Welcome Pascal ti, to the show. Pascal, thanks for joining me.

Guest: Pascal

Thank you. Jon

Host: Jon

Pascal, I got a couple of questions for you, but I want to understand your background a little bit and where you come from, and why well-being.

Guest: Pascal

Thank you, Jon. I grew up in Kenya and came to the US for college in California, after which I joined GoFundMe as a software engineer my goal was really to be a doctor but coming to the US realizing I needed to do postgraduate school to become a doctor, I switched to software engineering, but healthcare remained at the core. So my passion was to develop a company that helped patients recover faster.

Host: Jon

I think it's pretty cool. You were a developer for GoFundMe and I have to go look at that. Is your code still there?

Guest: Pascal

Yes, my code is still there. I didn't leave too long ago. Hopefully, they haven't deleted it, but I think it was good enough.

Host: Jon

Well, thank you so much. So Pascal, let's talk about WellBeam. What is WellBeam and why?

Guest: Pascal

Yeah, certainly so. WellBeam is a company that helps enable seamless communication between healthcare providers within a health system, hospitals, and the post-acute care space. So think about home health, home infusion, or a nurse who can come to your home, help get help, take care of your wounds, or a physical therapist coming to your home, to help you regain full range of physical motion. Any care that's not needed within the health system is always referred to your home setting and nurses come and take care of that. We help bridge that communication gap that exists today. If an order is required for your medication, it has to go through facts. If there are complications with your wound, the nurses don't have an easy way of reaching the provider. So WellBeam is that platform that connects the doctors in the hospital to act fast compared to what exists today to make sure that you get better even while you are at home.

Host: Jon

So WellBeam. Is the healthcare communication or translation between the provider and the actual people doing the services or how does that work?

Guest: Pascal

Certainly two big things. One is that if you get discharged from the hospital today, your doctor who discharges you still needs to follow your care at home, and that includes them signing off on any medication that you need to receive or even just the plan of care that a home health agency might have for you. So that's the first part of it. The second part is sometimes complications happen after a patient is back home. A wound from surgery can get infected. The progress with physical therapy may not be what was planned or the patient might get worse. Today it's really hard for doctors to hear about what's going on there and WellBeam helps the nurses keep the doctors up to date on their patient's conditions.

Host: Jon

Nice. Well, today we're talking about AWS Health Lake and FHIR. And before we get to that, I think we have to understand WellBeam's architecture as it was before the integration and the help from Ibexlabs with FHIR. Pascal, what did WellBeam's architecture look like before?

Guest: Pascal

Certainly Jon? So based on my previous experience through college, what I learned, and working as a full stack software engineer at GoFundMe, the experience I had was building platforms based on REST APIs, and JSON based, as well as building the storage layer on relational databases. We used MySQL before switching things to FHIR. So we chose this primarily because we already had experience and it would be easier to get other engineers to join our project and build right from day one.

Host: Jon

So Pascal, help me understand what is FHIR.

Guest: Pascal

FHIR is a new language for storing healthcare data and this was a project that started in 2012. There were a lot of healthcare companies coming up at that point and there was a strong push within the healthcare industry for patient data to be shared between hospitals, between different phases of care, so acute, post-acute, and any other. And the standards that existed were a little bit outdated and fragmented. So FHIR was developed because one, it used a more modern architecture, it is rest based, which is what a lot of the internet is built on and a lot of developers already know this sort of language. So it would be easy to get new players like us to get in and fill in the gaps within healthcare.

Host: Jon

Okay. What about AWS Health Lake?

Guest: Pascal

Yeah, so about nine years after FHIR started being developed, AWS announced that they have AWS Health Lake and this was an FHIR-based data lake. Sure, its development of it happened a few years before, but in 2021 it became public or generally available. And for us, having been within AWS originally, we were excited about this new availability and our goal was to be able to get our data converted from the MySQL database into this health lake.

Host: Jon

So utilizing AWS Health Lake, the underlying communication is a format of FHIR and your beam architecture communicated had a different format why can't you just convert it to FHIR or redo everything to FHIR, and then you would be done with it? You didn't have to do any translation.

Guest: Pascal

Yeah, we were already life at this point stopping all our operations. We have customers who have high requirements for availability. We basically can't turn this thing off and then turn it back on after a couple of months. So we took two approaches to it, which was one, we would use our internal team, get the engineers trained on FHIR, have them architect a data pipeline, and get the migration to happen from the MySQL database. This is a huge undertaking. The second option we had was to use a company that has done this over and over before within AWS and is recognized by the AWS Partner Network as one of the amazing people who can do it. And we went with the second option, which was looking for a vendor who could help us do this much faster than we could.

Host: Jon

All right, before we get to the vendor that's doing it, build it there is a certain value of having it in-house, right? You've kind of built your platform, and you and your developers understand it and work on it, but isn't there a lot of costs to it or the time and effort to implement it while you have other focuses? I think sometimes it might be beneficial to build it in-house versus going outside, but I think one of the things with FHIR is that you have to understand and rewrite everything to it. You have to educate your developers on the technology, the conversion, and the translation.

Guest: Pascal

You hit really good points there, Jon. So I would love for my team to go to build everything in-house. The reality is, like you say, for new technologies like FHIR, it takes a while to get up to speed on it. And don't get me wrong, I still want our engineering team to be able to get up to speed on it and know what's going on there. We have a lot of other items in our product roadmap and those are not things I wanted to pause on. And working with a vendor who knows FHIR already would want to make sure we have things going in parallel, but to make sure we get it done well.

Host: Jon

So the priorities of some of your projects, you had more pressing ones than then than actually rebuilding or building it and getting up the speed on it. You decided to go with a well-known vendor or partner to get this done. How did you approach that?

Guest: Pascal

Yeah, suddenly, so the first step we took was going through our architecture, knowing where we are today, and then comparing that to where we need to be, which is being FHIR capable. We identified a scope of work that needed to be done. So the first part was mapping our existing database into FHIR resources. That was one of the initial needs that we had and it was going to be big, it needed someone who knew F. The second need we had was for this to be within aws. We had our infrastructure there already and we would want to keep it that way. We also needed this process to be automated. We didn't want someone sitting on a computer pressing a button to convert every single data into FHIR. And the way this was built, we required it to be easily repeatable. This is what's called infrastructure as a service. So the whole architecture they built would need to be able to be transferred from one environment to the other. And last but not least, it needed to fit within our budget. So the cost of developing this new architecture as well as the cost of having it running needed to be done in a way that we could afford. And that's the scope of work we had. But yeah, back to you Jon.

Host: Jon

You identified several cases, several things for the scope of work, budget was one of them, that's always a constraint at the top of the list, you needed a vendor who had the experience and the knowledge in healthcare, competencies also dealing with AWS. How did you identify the partner to help you with the scope of work?

Guest: Pascal

Yeah, the account manager we had within AWS was knowledgeable and had worked with other AWS partner network members. So working closely with them after telling them what our needs were, we came up with a short list of four vendors, and out of all those four, we chose Ibexlabs.

Host: Jon

All right. Why Ibexlabs? I mean out of the four Ibexlabs stood out to you, correct?

Guest: Pascal

Yeah, IBEX stood out. One of the biggest things we loved was that they are part of the healthcare competency certification from AWS. We are in healthcare, there's a lot of need to operate within the healthcare IT industry. There's compliance and there are these new language models that you need to be aware of. So that in itself was big. They are also part of the AWS transfer family and after reviewing their customer case reviews, we were happy with what they'd done with other customers before us and that gave us a big amount of trust that they were able to deliver what we wanted.

Host: Jon

Pascal, the customer case studies, how valuable are they to you and WellBeam on deciding Ibexlabs?

Guest: Pascal

Yeah, I mean we like to take people's word but also have them prove that what they say was done. So they referred us to some of the companies they had worked with before and hearing how that went, the process they took, and they've done complex projects before with healthcare companies, so hearing this from their actual previous customers was a really big deal for us. That meant we could trust them.

Host: Jon

Some of the other things that you identified for Ibexlabs is even before signing on with them, were there any type of programs that they were able to come up with or find valuable to you to help you with this process and the scope of work?

Guest: Pascal

Yes, that was a big deal for us. Ibexlabs told us about the AWS Jumpstart program, and when I say it's huge, it's huge. There's 50% cost coverage that we were able to get, and for our company our size, we don't have the flexibility of spending money anyhow, and this was an important project for us. We were ready to get it ongoing, but the added benefit that 50% of it would be covered was like Christmas come early for us.

Host: Jon

That's pretty good. So wait for a second. You identified Ibex Labs through the scope of work. You had two types of outcomes you could do for this. You could either build it in-house or go with a partner and the cost savings, the budget, and the experience of going with Ibexlabs, oh, by the way, 50% covered for this project, which means that you could get more done, do more with Ibexlabs and the ongoing partnership with AWS was huge.

Guest: Pascal

Absolutely. That's one of the things we've loved about working with AWS and with their partner network through programs like this. A huge win for us for sure.

Host: Jon

I think a lot of the AW S partner programs that are out there aren't known to many, but you have to find the right partner who knows about these programs to help everybody out, the ones who truly care and that our customers obsess are the partners and AWS to help you complete these tasks at hands. Pascal, help me understand what was your relationship or experience working with it S labs throughout this entire scope of work.

Guest: Pascal

I would say it was amazing, and that's an understatement. One of the first things that happened after we signed on with them was they wanted to come in where we operate, and that's Slack. A lot of tech companies do that and being able to share set up a shared channel with them enabled us to communicate much more seamlessly. So having that channel of being able to talk to the engineers directly, and their product managers, as well as setting up a weekly standup check-in with them where we checked on progress in any blockers that were being experienced by the developers in addition to any ad hoc meetings that were necessary. So random days they'd come to us and tell us, Hey, this and this went well. We're happy to move on. We are ahead of schedule, or we hit a blocker here and we love your insights or how your team jumps on a call with us to help solve that. So all of that facilitation and being available was helpful. We also learned that they know the AWS ecosystem well. It wasn't a surprise, but I was just pleased to see it in action.

Host: Jon

I think understanding the AWS ecosystem and how to navigate it is usually one of those hidden benefits for a lot of partners and companies because they can identify those programs. Were there any challenges that WellBeam and IBEX ran into along the way and how did you overcome them?

Guest: Pascal

Certainly. I recall one of the bigger challenges we faced was, that the pipeline they built was supposed to run on a batch process, and sometimes not everything works well Ibexlabs was able to flag it to us that in case one of the conversions failed, that's converting our data from our relational database into FHIR resources if anything failed. There was no way of us knowing that it failed and going back to redo it. So they reached out to us and we set up a meeting where they shared their proposed solution, which was for us to add flags within our master database to show that a particular row item had not exported successfully into FHIR. So they worked closely with our engineering team to put this in place and even today after production, we can confirm that sometimes hiccups are hit, but the process can identify them and fix them right away. So it was a challenge, but they helped us overcome it and we can see the fruits of that today.

Host: Jon

Pascal, before I dive into the challenge of overcoming those error constraints, everybody we're talking with Pascal Odek, the CTO and co-founder of WellBeam, and our topic today is healthcare interoperability, B2B SaaS application with FHIR Data Lake. Now, WellBeam is working directly with Ibexlabs in partnerships, Ibexlabs is building that connection for FHIR to translate the data to and from. And yes, WellBeam can receive that data in the FHIR format, but they also can send it in the FHIR format to AWS Health Lake. Now Pascal, we're talking about one of the challenges in error conversions that happen, walk me through this, the error happens, and it gets flagged. Are those individual ones that have to be evaluated, and how are they handled throughout the entire process?

Guest: Pascal

Certainly Jon. So whenever an error happens, the first line of correction is an automated retry and that's because maybe it was a network issue or something that just needed a retry to make it happen. If that fails and it's flagged for a second time, then we'll have an engineer hop in there to look, Hey, what's causing this to fail? And these are all steps that Ibex helped us put in place.

Host: Jon

Ibexlabs put in some of the places to automatically retry the error so you didn't have to have a human interaction throughout the process. But then after the retry failed, what is it like once or twice you have human interaction, to evaluate the error?

Guest: Pascal

Yes, so I don't know the correct number, but twice. Twice, if it still fails, an engineer is jumping in to see what's causing these issues.

Host: Jon

Okay. Can you walk me through from the time of identifying this challenge that came up when the error conversion to the time of completion or resolution to it, how long did it take IBEX to come up with a solution and implement it?

Guest: Pascal

This was fast when say within a week or less as I say, they set up a cadence of meetings, which was once a week and we kept it also open to them. If there was any problem that came up, we were happy to jump on a call. And for this particular case, they came on the call very ready for it. One of the things we don't like is meetings that people are not prepared for. So they came there, they were able to identify the problem in addition to that, proposed different solutions to it and one of the ones they proposed is what we end up going with. So in a span of less than a week, there was a way forward and the engineers were back to getting this off the ground.

Host: Jon

Nice. Pascal, and going off the timing of things, I want to know from the time that you engaged with IBEX to the implementation of FHIR and working directly with them, how long did this project take?

Guest: Pascal

This project took between two to three months and that's from beginning to end. It took a shorter time than we thought you would take, and I attribute that to the availability of Ibexlabs to make sure any blockers are cleared right away and also to share progress on a very frequent basis. The project management and the team there were amazing to help get this off the ground sooner than we had planned.

Host: Jon

Pascal. What was the outcome now that this is implemented, how is it helping WellBeam? How is it helping the customers or how is it helping potential people integrate with your system?

Guest: Pascal

Yeah, we are excited. I think as of a month or a few weeks ago, we are living with this in production. This means WellBeam data is available in FHIR format for any of our partners to consume. So our healthcare systems, our customers, and any other third-party vendors with whom we deliver our service can send us data as well. We can send it back to them and using AWS tools, SageMaker, and other analytic tools, we're able to analyze this patient data to help suggest to our provider's actionable courses they can take for their patients. At the end of the day, remember Jon, that we want the patient to get better sooner. Being able to run such kinds of queries on this data can help them get to recovery much faster.

Host: Jon

Pascal, were you able to do this before the FHIR set up and did it take longer to do it or were you not able to do it because you weren't integrated or able to utilize FHIR?

Guest: Pascal

We were able to do some of it in a somewhat painful manner, but now that we have this data in FHIR format, and this is what the healthcare industry has embraced and there are a lot of models within AWS to be able to run Intel on this data, it's being able to leverage what other people have done and where the industry is today. It makes our job much easier than it was before.

Host: Jon

Okay. So without FHIR, how much time would it take you to handle this communication with a customer healthcare provider?

Guest: Pascal

This would take, there are different complexities to it. I could attach a time, but I could explain what it looks like. So there's the contractual process where you have to convince your customer that you're able to share data with them or get data with them through other protocols that, as I mentioned before, are a bit outdated and takes a lot of time to get set up through their IT teams with FHIR. This is more modern architecture. It is rest based, it is JSON objects. This is what the internet thrives on today. So it's much easier to get off the ground and if you share this with a health system leadership, they know it's not going to take as long as other previous projects have taken. So contracting is reduced and when it gets to it and they also hear the type of infrastructure you have in place, it makes them be at ease in okaying your project. So it's helped reduce the time from, let's say a couple of months, six plus to maybe two to three months. And we hope to get it shorter as we explore further what FHIR capability can offer us.

Host: Jon

Nice. Pascal, it seems like your progress and the partnership with Ibexlabs in a w s has really kind of elevated your company to help customers and patients get better in the long run. That's your whole goal. You said that you came from Kenya and now you wanted to be a doctor, but you went and been a developer for GoFundMe and now you're back to healthcare. I think that what comes full circle is your passion to continue helping people.

Guest: Pascal

Yes. That's been my passion since childhood. I think aside from it being my passion, just seeing my mom get diagnosed with cancer about five years ago and just seeing how the whole, thank you, seeing how the whole healthcare industry operated, I was able to see a lot of gaps, especially within the post-acute industry where someone who has gone through surgery, radiotherapy, chemotherapy and so on, goes back home and still needs a lot of care, still needs to get their doctor's attention. Yet it's not easy to do that with today's processes. That's still core to my drive to try to Mel, make healthcare better.

Host: Jon

Pascal, you built a solution for a problem that you experienced firsthand. That is a true passion, that has true, trying to figure out the best outcome that others who are having the same issue. Pascal, I want to thank you for joining me. This has been very informative to understand WellBeam the integration and collaboration with Ibexlabs and the partnership with AWS. I'll tell you what, I didn't know so much about healthcare and still, I started talking to you about FHIR AWS Health Lake and understanding the transfer, the data that needs to happen between to expedite and cut this process down to 50% communication.

Guest: Pascal

Yes, Jon, it is a huge space in healthcare, it spans multiple domains and for us, we're still learning as well. That's why we find it helpful to engage with partners who have done this over and over and understand much deeper than we do.

Host: Jon

Nice. Pascal, I want to thank you for joining me.

Guest: Pascal

Thank you, Jon, for hosting me as well.

Host: Jon

Ah, this has been awesome. Everybody. Pascal Odek, CTO, and Co-founder of WellBeam. Today's topic was Healthcare Interoperability, B2B SaaS Application with FHIR Data Lake. My name's Jon Myer. Thanks for watching the Jon Myer podcast. Don't forget to hit that, like subscribe and notify because guess what, we're out of here.