Unknown: Hello, and welcome to The Machine Learning Podcast. The podcast about going from idea to delivery with machine
learning.
Unknown: Your host is Tobias Macy, and today I'm interviewing Ittai Dayan about using federated learning at Rhino Health to bring AI capabilities to the tightly regulated health care industry. So, Itay, can you start by introducing yourself?
Unknown: Hi.
Nice to meet you, I'm Tobias.
My name as you said is Itay Deyan.
I'm a physician scientist in background
and management consultant
and then turned AI development leader at Mass General Brigham.
In my current role I'm the co founder and CEO of Rhino Health, a company for distributed compute
driving
capabilities to the edge in healthcare,
along them among them, federated learning.
Unknown: And do you remember how you first got involved in the machine learning area?
Unknown: Well, when I was,
conducting clinical research,
over 5 years ago,
we were looking to quantify disease,
using the digital biomarker. And
it seemed like a very
attractive notion especially in neuropsychiatric
disorders, which are often how to,
really quantify
and be sure if treatment is helping the patient isn't helping the patient,
compelling treatments and such.
And that concept looked incredibly
attractive.
The difficulty we had then is getting enough patients, which is still a very challenging thing in many cases,
And being able to
capture,
record, validate these biomarkers and, you know, take them out
to the clinical world where others will be able to use them. And so I got really excited about the concept of not just, doing 1 study that, you know, might take 3, 4 years
then wait another 5 years to the biomarker is used by somebody and maybe another 5 years until it's actually propagated.
But actually
turbocharging
the entire process and making all of that happen much faster and with many more algorithms.
And that took me to Mass General Brigham
and later on to start my company Rhino Health,
as a ways to accelerate scientific creation
and translation.
Unknown: And in terms of what you're building at Rhino Health, can you give a bit more detail about kind of where your focus is and some of the story behind how it got started and why you decided that this was where you wanted to spend your time and energy?
Unknown: Sure. So a few years ago, I led an international
consortium called the exam consortium
20
many constitutions worldwide,
in order to retrain and validate an algorithm for predicting outcomes
of patients who appear to the emergency department with suspected COVID and the goal is to help physicians manage these patients by introducing another kind of score clinical score
or
kind of a COVID biomarker that can help predict whether these patients would need mechanical
ventilation and what the outcome of a patient is going to you know potentially be.
The reason we
used federated learning for that consortium
was due to the fact that getting
disseminating
algorithms in different institutions
takes a long time. You lose control over the algorithm.
So it isn't really a joint platform you can work on And on the other hand,
receiving data from institutions around the world was highly impractical.
You know, you have some institutions that are subject to GDPR,
some to HIPAA, some to
you know what and you know other regulations and
just too high barriers and too slow for process to centralize data. We ran the study. The study actually happened much faster than I would have imagined.
I think we got all sites signed up maybe 6 weeks and a few weeks later we already had an experiment running. Also due to our partners from NVIDIA we're using the
early
platform for federated learning called Clara
FL
and so
clearly we were very excited about it. We were even more excited when the results came in and we could see that the algorithm itself actually generalized much better
than any algorithm created in 1 institution
and demonstrated capabilities across the board. Meaning, wherever we took the global algorithm, whichever institution,
algorithm of algorithm at all using federated learning and that this was really a way to accelerate these kind of collaborations.
And so after this study, I went to,
NVIDIA and to others and said, you know guys maybe somebody should turn this into like a full blown
feature rich commercial platform.
And, you know, people telling me, yeah. You know, we like building SDKs
and chips and infrastructure, you know, stuff like that. But this sounds like a much more kind of like up up the stack solution. But we said maybe you should build it.
And so I thought, yeah, maybe I should. And that was
the early inception.
I've never been a deep tech CEO before. I wanted to work with somebody who's you know, done this before and somebody who understands
not just health care and life sciences
and research, which is areas which I'm I'm fairly knowledgeable about and not just, you know, development of AI, which is also an area I'm knowledgeable about, but it's actually built enterprise software and predictive analytics software.
And so I teamed up with my cofounder Yuval
was a group engineering manager at Google,
driving the development of a conversational
AI product at that time.
And we,
raised the seed round for vinyl. That was kind of how things came together. Very cool. And you mentioned that
Unknown: federated learning is 1 component of what you're building and that more broadly, you're looking to build out a distributed compute platform for the health care industry. And I'm wondering if you can kind of talk through some of that nuance, and then we'll dig into a bit more into kind of what federated learning is and how it's being applied here. Yeah. So so starting from kind of the smaller details of how exam consulting worked, we can see that federated learning is definitely
Unknown: a very cool technology that can help you do stuff.
But what you really need is a platform,
which you can do more things with. You can manage the data. You can harmonize the data. You can validate the data. You can pre process the data
and you can also federate learning with data.
But but not and can create an algorithm off. After that, you have an algorithm, you you wanna deploy the algorithm, you wanna monitor it, and so there's like a full end to end life cycle. And if you just solve
a small
critical but narrow problem of federated learning, you don't give users
sufficient
value. And so,
you know, it's kind of like people say, you know, data is garbage in garbage out and all that kind of stuff. So like you want to go much more upstream and you also want to go more downstream in order to make sure that the algorithms are
continuously
supported. And so that took us into developing a much broader platform than just federated learning which I I think you know, has people have attempted building federated learning platforms before
in the last few years. And I think that's very where we typically miss the mark. We decided in difference of that to having the full blown edge compute
platform
that takes you a new development journey end to end which also has
ultimately
felt like maybe the real name for something like this would be an edge cloud meaning taking all the capabilities of of a cloud computing and putting them on an intricate system of inch of inches
and that's what trineworld does.
We're a platform for builders
we're not a platform that is kind of like a no code or
you have to get your hands dirty in order to use it similar to how it was using AWS or GCP or Azure, you
know, up to to date. But we definitely
lower the learning curve required in building distributed systems
substantially to the level where if you have,
an algorithm
and you generally know what the pipeline should be and what, you know, what kind of data you need, you can,
convert the model into a federated learning framework and deploy it to Rhino,
run the right data for it and see results within
a day or 2 from beginning your project, which anyone who's ever actually done a federated learning project
if it actually went beyond 1 institution
and required to manage infrastructure in multiple places and kind of like do a lot of engineering work which is not germane
to the data scientist profession necessarily.
So that's actually a fairly complicated process,
which also runs the risk of it being non repeatable
and non sustainable.
And you know going a bit back to the exam consortium
while it was a very large achievement, it was not a sustainable achievement.
We finished the project, everybody folded up the stuff and, you know,
was a good project.
The data today can't be made readily available easily to our researchers
who want to validate algorithms
on a on a global rich data set. You know it was an ad hoc project like many science projects.
We we endeavor to change that
and also be able to turn some of these ad hoc consultants into something that actually propagates knowledge
and propagates data.
So we've you run at once and you keep an edge in your data center or on your workstation or wherever you, know, your data and compute line and you're able to tap into a vibrant ecosystem of
developers both
from industry as well as academia
as well as hospitals
and, you know, jointly
try the future
faster.
Unknown: And digging a bit into the terminology of edge compute, it's probably also worth kind of detailing
what that means in this context
of distributed compute for health care data, where, in some cases, edge compute means working on low power IoT style devices. In other cases, it's an edge where that edge is actually a full blown data center. I'm just wondering kind of what level of computational capability you're focused on targeting with Rhino Health for being able to push these capabilities out to these so called edge locations?
Unknown: Yeah. So we we benchmark the platform based on different model types and use cases. And today
we have configurations
from a MacBook
Pro to an Nvidia d g x server
to bigger,
capabilities on cloud. Will we fit whatever you have? The question is if if you want to train a convolutional
neural net on half a terabyte
of
imaging data, maybe your laptop won't be the best apparatus for that.
Unknown: And so now digging into the federated learning aspect of what you're offering, I'm wondering if you can just start by giving a baseline of what federated learning is and some of the trade offs that it introduces in terms of the types of ML algorithms that you can apply and the types of data that you're able to work with and some of the kind of constraints
and capabilities that it offers?
Unknown: So federated learning is,
I guess, a meta framework
to machine learning
frameworks.
It is a an iterative process in which you train algorithms locally.
You share the weights from these algorithms,
with a global orchestrator. The global orchestrator blends these weights using
averaging or other techniques,
Then it in turn updates
the algorithms
that are local. It runs an additional epoch or however you defined
until you reach an optimized model. That's in the simplest,
I guess, way for a technical audience. And maybe for nontechnical audience, it sits like an analysis
of different local algorithms that extracts the best most performant parts of them and creates a global model based on that.
Unknown: In the context of health care
and pharmacological
research, I'm wondering what are some of the
motivations for using federated learning and some of the unique opportunities that it offers to this very tightly regulated and controlled space.
Unknown: So first of all in order to when you
do federated learning you don't need to show data you only need to show data insights.
So that already alleviates a big part of the need to take liabilities
over to come from data sharing. In general, federated learning is very helpful when you have
very private data or very heavy data.
And so unsurprisingly, some of the early users of federated learning have been in autonomous vehicles and have been with cell phones. The cases where the data is heavy and you can't really stream it
quickly
to a cloud environment or when the data is private and, you know, you just don't wanna show whatever's on your phone.
Healthcare data has both of these properties. It's very heavy and it's also private.
And using federated learning opens new collaborations between different hospitals, between hospitals and industry, and between different industry partners.
And it was, you know, good examples for each 1 of these.
Between hospitals,
things like the exam study or
another project we're doing now, we're supporting now for the detection of pancreatic cancer
between different academic medical centers
Our prominent examples of that, another example is some projects that we do with pharma companies who wanna collaborate with AMC's
hospitals
etcetera in order to
create
biomarkers for disease prediction or detection.
And another example is
a pharma to pharma consortia,
with Melody being 1 of the early examples.
For it, Melody with 2 l's and 2 d's, if I'm not mistaken,
in Europe, whereas many other pharma companies are setting up similar capabilities
or
consults as a service
so to speak and we're supporting these efforts.
Unknown: And to the point of the data that you're working with, you also mentioned that some of the capabilities
you're offering are some of the data prep, data cleaning, data validation,
and
the federated learning aspects. You mentioned that you don't need to send any of the actual data back to the kind of core model,
which is 1 of the reasons that it empowers the health care industry.
And I'm curious, what are some of the challenges that you have had in
kind of building confidence with your customers, ensuring that all of the data that they're processing is being done so safely and according to whatever their local regulations are, as well as the fact that whatever data
is processed
and turned into
features or vectors within the model space
are properly de identified
and robust to any kind of reidentification
attacks or
ensuring that there isn't any sensitive information that is encoded within the model that can be extracted after the fact?
Unknown: Yeah. So federated learning is still fairly new technique. It was envisioned by Google in 2016.
So not too many years ago,
people need to still, you know,
understand
how to work with it. And, you know, similar to the general struggle that many have with AI in general and machine learning in general.
Parts of this was around getting people comfortable,
to
install an edge device
within their firewall
and make sure that no data leaks out that, you know, we'll save FirePoint
the data within the firewall,
which helps because, you know, because they still have full control over the data and full control over the compute environment.
Some of this but you you like the work question in the past.
I send model weights from 1 place to another. Can they be intercepted
in those technologies
to fill the safeguard that? Another question was what once I've taken away these model weights, can I use them,
to create a model that would then reproduce the data?
And there's been a lot of research on that topic as well. The vendors,
I guess, questions of how good is the data that was used to generate these weights, which is something that's kind of our part of our core platform offering is the ability to test the level of harmonization and quality of the data.
So that solves for that. And I'd say in terms of,
how what is the purpose the global model is going to be used for and what can it be used for? There's a question of,
transparency,
People knowing which models you're building for data,
you're using the data to build and based on that you can really assess risk much better. There's a question of where the model itself sits. Can it be
hacked into, I guess,
which is 1 of the reasons why our global orchestrator
is in a cloud environment,
which is encrypted and kind of like the most
state of the art security.
Ultimately, federated learning creates models. AI developers also create models. The same conditions and issues apply to both of these
groups.
There's definitely a certain element of educating the market about federated learning and getting people to really understand what it what it
is, what it isn't, and
trying it out for themselves
and seeing that how it can actually
solve for business problems so that it will then create new problems.
Unknown: And so in terms of what you're building at Rhino Health, can you give a bit of detail as to some of the kind of design of the platform, some of the user experience aspects that you focused on to
simplify the onboarding
of customers, to empower them to be able to start building some of these federated models and understand
what are the capabilities, what are the the limitations,
and just some of the overall kind of infrastructure that you've built up around this problem?
Unknown: Yeah. So, some of the design principles we have is, central
keep the data and compute.
And so it means that you never need to actually move your data
outside
your compute environment, which already gives the user much more confidence in working with us, and we don't persist any data outside the edge. So that's 1 design principle
we've used. In addition to that,
we've built up system fairly generic
kind of like using primitives.
So the purpose is ultimately not for us to create the Autoflight very,
you know, customized
end solutions, but rather
create tools that can be reusable and repurposed and, you know, relevant to a broad range of users. And
everything we do is both in the graphic user interface
and can be,
invoked by an SDK.
And so it gives usually
as your user experience, you'd start from using the GUI and get used to it, understand the workflow, etcetera.
And then often users would switch to a programmatic interface where they can really
have more power in, getting the system to work for them, optimize for experiments,
integrate with additional software, and stuff of that nature. Another
principle is we we use we ourselves are not open sourced, This is also, you know, safety and, privacy consideration,
but
we leverage a large host of open source software that can be used for building,
containers,
running
experiments, creating AI, and all that kind of stuff. So we don't typically require a user a huge learning curve in terms of,
learning a new framework. We use flare under the road for for the federated learning part and we use container orchestration
that you can run custom code and for all the rest.
And so you can bring your own experiments, you can bring your own code, your own software,
and use that on vinyl.
So, you know, like every every software with certain learning, but we don't require it to kind of, like, start using the Rhino proprietary
federated learning framework which is only going to be relevant to you if you use Rhino. And this is actually a good place to know for shout out for the NVIDIA team
who have been great partners to us in terms of responding
to needs, requests,
providing more examples,
supporting, you know, software bugs and issues over time.
And, you know, we've been part of our consideration in open sourcing flow because we recognize that the only way to really
scale a framework and achieve broad public adoption
is by having something where on 1 hand, you have a big player
supporting and pushing it. And on the other hand, the users can understand
the software well enough know when it doesn't work and iterate on it. So and and in general you know open source communities today
very powerful way in driving adoption and also in driving
progress in development.
Unknown: As far as the federated learning aspects, are there certain kind of baseline models that you are offering so that,
the different so so that your different customers are able to run those models on their locations and then contribute back to that core model so that everybody's able to benefit from the distributed
training and distributed learning that's happening?
Or is it a case of your customers are the ones driving the model development, and then once they build a certain model, then that gets pushed into Rhino Health, and it can then be applied to
other customers' use cases. And just wondering what are some of the kind of common
data types or data formats that you're,
focused on supporting.
Unknown: So,
we're we're pretty broad in terms of data
types. We're not we're not single. It's it I actually find it curious. People always ask me that question and what kind of data can you use on Databricks or on S3 bucket, so stuff like that. A lot of kinds of data. We have added some tooling which was more
medical imaging relevant like medical imaging fuel
also an open source software
in order to do that and today we actually allow you to deploy pretty much whatever kind of software you want as a data fuel. We have some stipulations but it needs to be
dockerized
and aligned with security principles of our system. In regards to your question about do we kind of drive
the development of foundational
models or models which show iterating that, we don't.
We live that to our users.
Do create tooling that makes that development easier. Like, we recently
supported a large language model
conversion into a federated model.
So we help with the aggregator
and the set of experiment and, you know, some of these toolings can be used across
different users for different users.
The actual model itself is proprietary,
and we try to not get into that space too much
because you don't wanna ultimately
be
come or be seen even as a competitor of your developers.
I'd also say in medical
the medical world
in scientific world is filled with collaborations and consortia and big dreams and big aspirations and all that. There's a lot of people who can build these models.
Our purpose is really to be the supporting platform for for that,
not to try and kind of, like,
be in the gold rush for
medical
AI intellectual property
of that nature,
if that makes sense.
Unknown: Yeah. And
in terms of your experience of going from idea to where you are today, I'm wondering what the overall
evolution has been in terms of the goals and design of the system?
Unknown: So,
we
started
focusing
on federated learning per se, and over time, we've expanded, as I think I said earlier, more upstream and downstream of that. And that's made us need to
have a bit to work with multiple
datasets at the same time, keep versioning of datasets,
transforming the datasets, and kind of, like, doing a lot of more
orchestration of that. We've also,
over time,
expanded our,
API capabilities
in order to support enterprise software where you really wanna use Rhino as a middleware
and you don't want to use contract Rhino end to end.
So that's also made our design more open and more
flexible to integrate with other solutions.
And recently we've also
started expanding our ability to do integrations
and data
ingestion,
locally.
Since ultimately
once the scale
of user final started to go up, people said, okay.
Actually, I would wanna not just get you the full curated data set but also
use the platform end to end to QA to that dataset. So integrations with DICOM servers,
SQL databases,
with different
routers using h27
and stuff of that nature. It's now been a
focus of ours,
recently and we'll continue pushing on that.
Unknown: And then as far as
getting onboarded
onto Rhino Health, sort of adopting it into the workflow of a given customer,
you mentioned that computationally,
you're very flexible and are able to operate on a broad set of runtime environments. But from a
organizational capacity and capability standpoint,
what are some of the
common skills or
team sizes or,
kind of just general technical knowledge that are necessary to be able to most effectively take advantage of what you're offering at Rhino?
Unknown: So for
the project the project lead perspective,
it's a data science and sometimes you need some support engineering like,
localizations
and
some integrations with the existing systems.
We offer that as well for,
you know, as an adjunct service. But
ultimately, some corporates would would like to do more of that on their own.
From a data contributor side, not really a lot. You need to be able to have like a Ubuntu
operating system and
be able to scale
your compute as much as needed for
the running of the workloads.
And in that regards, we have today
fairly high flexibility.
We have,
engines running on
Azure,
AWS,
GCP,
private class, some other
smaller clouds,
VMs on local hardware
and bare metal. So that's
you need to have something
And if you have nothing, then we can,
resell your server.
Unknown: And as far as the
kind of onboarding process where somebody says, okay. Rhino Health solves this problem for me. I'm going to start using it. I'm curious what the overall workflow looks like going from kind of idea to initial implementation and then the capabilities that you offer for
ongoing development and maintenance of the
particular kind of model development and training and just kind of the the ongoing support for being able to keep a project in motion?
Unknown: So,
that's a big question.
I don't know. We need to
liaise with the information security team
and clear the line of architecture with them. We need to work with your data center team if that exists in order to get the hardware
set up or with your cloud team if you need to get a cloud instance set up. Once we do install itself is 7 to 10 minutes. It's,
not a big deal. But once you have installed, you need to be trained on the system. How you
ingest data?
How you export data? What what does, you know, all these things mean?
We've had some users in in the beginning kind of like not understanding why they were trying to export data but we're not seeing it on the laptop.
And for example,
whereas we always keep the data in the same environment which we imported from we also export to. So
you can't really use this as like a host to pull data from 1 place to another. We actually keep data very local to where it it was received. The query itself is
I I would say is pretty
simple to understand. There's some questions about like, you know, the whole federated framework, federated
workflow where you import data or you import data from multiple users
and then how do you check it across? And how do you know where all the data has been imported from the different, you know,
contributors?
Stuff of that nature which sometimes, you know, users wanna understand it a bit more. But I'd say most users become pretty independent within a few weeks of use.
And so at that point some some of them get more creative and wanna say hey I'd like to integrate this solution to this or I'd like to try to do this or I'd like to change some models on different dockers or different this and that. And we usually support that. It's still, you know, we're still an early company so it's cool to us to learn
much more about our users and how we can,
you know, delight them in the best way and how we can push that envelope and expand the user for Rhino. We also have bigger customers which are less independent
just because they don't have to be. And they have sometimes bigger kind of bigger ambitions and kind of like set up a whole blown
consult here from the get go
and add all sorts of capabilities
and add more federated aggregators
to support more things or add more functions
in order to get kind of a better quality of life for the hands on user and when we also offer all of these things. And in general, if I've learned something from being an early stage deep tech CEO
is you need to be flexible. You need to
do what your customers need not what you want to do. And so, you know, we
we are very flexible and are very accommodating.
All of that comes with, you know, a certain price. We have to stay focused on things that are
not just
impactful but are also valuable
can be quantified by users. Having that said, a lot of things we do today is academic
collaboration support which are really
very cutting edge, very exciting research for, you know, eradicating cancer
or for identifying
patients at risk with an adverse outcome, stuff like that,
which I'd say we still do as a very
part of the benevolent mission and not as a way to make money quickly. Because if if we were just trying to do that, that would probably not be the right venue. But we are I don't know. Many of us are MDs,
academics,
and
still very excited, very, you know, mission driven. And so we continue doing that. Once in a while, we kind of need to remind ourselves, you know, we're also running
a early stage startup and have to do things beyond that, but it's still
in very much in the DNA of company.
Unknown: Given your
focus on health care and
that industry, wondering how much of the ethical and regulatory
burden falls on you as a company operating in this space and how much work you've had to do to be able to kind of be in compliance or ensure that you are considering some of the ethical ramifications of the capabilities that you're offering and how much of that is
the responsibility
of your customer as the owners and stewards of the actual data and the ones who are doing the actual processing and learning on that?
Unknown: So
we are
HIPAA compliant, GDPR
compliant. I don't know. We've complied with that. We're SOC 2 certified,
ISO certified,
and a bunch of other things certified. So it definitely had a lot of, that kind of burden.
We save a lot of other kinds of burden by the sheer fact that we don't move data anywhere. So
we don't actually need to maintain data on another environment outside the hospital.
That side that's solving the hospital ownership and privacy question. It's solving the company's ownership and privacy question. And it's enabling stuff that couldn't be done otherwise. Like, today, there's almost no collaborations
that involve data from the European Union and from the United States,
because of issues around GDPR
compliance in the states.
So that's a problem that we can
solve.
Same things with the PIPL
in China and
pretty much any region today has their own
regulatory schemes. And by being able to not move data, you solve a lot of that issue. Any other way customer would work same as they work on their own data.
We have to comply with whatever
practices
Unknown: required of them. And in your experience
of
building Rhino Health and working with your customers, you mentioned some of the ways that it's being applied that you have been personally excited about, wondering if there are any other
interesting or innovative or unexpected
applications
of your platform and technology that you've seen. That's a really good question.
Unknown: I think we expected a broad use of the technology
and there is a broad use of the technology.
We've seen that over time, a lot of our users have really been building applications
on top of a platform,
and using us as a way to
integrate data from multiple places,
but not as kind of like the only software at play.
So the American College of Radiology,
for example, built
distributed registries
for
mammography
studies
in order to promote research regarding women's health
and so we really
integrated us into the cloud environment
called DART
whereas they kind of control the workflow and
user experience.
They also integrated us with
a ACL connect software, which is a more of like a local data management
apparatus
behind hospitals firewall,
and then we could turn that into 1 coherent product.
It was called Verano sandwich.
I think that was pretty creative. I didn't
we didn't expect to become a sandwich so quickly.
So I guess that was
an example for that.
Unknown: And given the fact that, as you mentioned, you and a number of your colleagues actually have medical backgrounds,
I'm curious
how you see that as having empowered you or enabled you to be able to enter this particular industry
so rapidly and be able to build up the capabilities
that are useful to your target customers?
Unknown: I'd say as people generally
operated in a clinical and academic environment, we have a better appreciation for
what our
how it is working with medical data, how it is working in a clinical environment, what matters more and what matters less.
I've seen a lot of technologies and
tools people have tried to bring into health care,
which sometimes,
were an overkill
on some areas and then underwhelming in others. I consider it, like, for example, a lot of the blockchain
implementations
for health care, I felt were a bit premature and not really providing as much value
as the actors were,
looking for.
I've also seen some of the encryptions where you kind of like, hey. Move all my data to the cloud, but it's, like, super encrypted and you keep the key and stuff like that.
I've also seen it as a kind of a bit of an overkill in some ways, but also a bit not really what the users are looking for in regards to something that's understandable
by a user.
A a user can understand if a data stays well. He can't understand and fully analyze
the level of rigor that the system that's supposed to protect his data while outside his reaches. We also had the appreciation of the need to iterate and work with medical data in order to
certain the quality of it. Whereas some of the additional,
you know, things I've seen in the market kind of, like, assumed your data is, like, ultra curated and pristine.
And now, you know, do whatever we want with it, which is it's nice, but it doesn't really solve a problem of scaling up collaborations
between different
stakeholders. Like,
if I need to set up a consult here with a 100 health care providers
and I expect each and every 1 of them to,
clean, harmonize,
preprocess. I don't know. Do do whatever is needed for the data to reach point in which I'm gonna work on them. That is not a sustainable model. But if this if this talent pool doesn't exist,
you can't hire a 100 CROs or, I don't know, how many,
data processors in order to prepare the data. You need to have an ability to do much more of these things in a central in a centrally orchestrated, not in a centralized, but centrally orchestrated fashion.
And so I think just having the ability to have run projects like Exam
and before that, other earlier federated learning efforts and in general driving collaborations
between different sites, between different geographies and all that.
It gives myself and many people on the team
the understanding
of what would be a good, product with a good fit for the customers, I guess, I'd say in in summary.
Unknown: And in your experience
of building this business and working with these technologies and customers, what are some of the most interesting
or challenging or unexpected lessons that you've learned personally?
Unknown: So
I think a lesson we've learned is about
the need to
run the process end to end as much as we got to. I I think we realized we're gonna have to have, like, a compound product that solves a lot of problems. I don't think we realized how many problems
need to be solved with the product.
And I'd also say that
the idea of really working
on,
bespoke
hardware,
from different sites and our ability to actually,
be multi cloud and truly hybrid from the get go. Some people thought that's an unfeasible
option that's gonna take us back to to too much time. And I've actually been pleasantly surprised with a lot of medical institutions today and companies, of course, that
use virtual private clouds.
We've been able
to run and manage Kubernetes clusters on v edge, kind of like solve a lot of, you know, problems of
an unprecedented
scale in a hospital
environment
and the hospital.
IT and information security teams are actually have ramped up and are really geared to, meet these new, and emerging needs
for the use of health data and have also been a a good partner to learn from and work with.
Unknown: And for people who are interested
in these
distributed
training and distributed data
operations capabilities,
what are the instances where Rhino Health is the wrong choice?
Unknown: That's a good question.
If you wanna build your own aggregator,
ultra custom
code only for a very specific use you have.
You you you wanna academically
validate which the mesh it works but you don't have any aspirations on deploying it elsewhere
or actually scaling it to actual different users,
Rhino is probably an overkill.
You can just like build your own framework,
build your own aggregator,
you know, separate your data to a few different libraries,
folders on your computer or your workstation
and just do it.
No need to do all the rest of the stuff.
And we have, in fact, had some of, like, like,
the hospital
based
physicians
researchers or researchers who've worked with us have always been people who have, like, huge ambitions
in terms of deploying algorithms for diagnosis
elsewhere in terms of scaling innovation, collaborating
around the world, and kind of like really
changing the big health care, you know, system. Folks who have been much more on the kind of like
a seminal science
part and wanted to just like test out new methods, pull them out and stuff like that. At times benefited from working with us and at time I've said, yeah. This is like this this solves, like, I don't know, 25%
of my personal pain,
but maybe not enough for me to become kind of like a repeat customer.
Unknown: And as you continue to build and iterate on the product and platform
at Rhino Health, what are some of the things you have planned for the near to medium term or any particular projects or capabilities that you're excited to dig into?
Unknown: So,
I'll keep my road map for myself right now. But in terms of areas that we're interested in actively pursuing,
I'd say we are definitely interested in working more in the EU and working more in areas where
we can solve big,
regulatory
issues.
In in the North America and the Middle East, in APAC, we already have, like, a pretty substantial
presence.
We have some presence in the EU, but we're planning to go with it. And in terms of
solving problems, we started out working with much more with hospital based researchers because these were the guys who we had, you know, empathy and the most,
unmet needs. Our platform has grown a lot. Our user base has grown a lot, and we find ourselves working increasingly with the biopharma industry,
which is also great because these are the guys who are also ultimately going to take a lot of this innovation
and,
translate it into something that can scale and can affect patient care.
And so a lot of growth in the biopharma space and, you know, solid biopharma customer pains.
I'd say most of our work in biopharma has been around r and d. And so there's actually quite a bit of similarity between our earlier customers and biopharma customers.
But, definitely, as we continue to grow
and work with more commercial and with other, you know, groups, there'll be different challenges.
Many of them are around building,
business partnerships
and,
integrating with additional
sole systems for data,
in order to help really scale some of these collaborations
into the 100 and 1, 000 range.
Unknown: Are there any other aspects of the work that you're doing at Rhino Health or the specific applications
of distributed compute and federated learning for the health care industry that we didn't discuss yet that you'd like to cover before we close out the show?
Unknown: There's a lot of exciting new AI
and applications
of AI.
I think we're very excited about the use of AI as a way to detect rare diseases and kind of scan very large amounts of data often with kind of like patient by patient case, which most of the deployment of AI in hospital workflows has been to date. We're also excited about the the increased leverage of multimodal
relay data for modeled creation.
And that that really gives you the, you know, potential of bringing a true benefit to humans. So that would be something that can be almost as good as a human. It can really give you more data points
in making decisions.
And I think in general,
the whole impact of cloud compute on the health care system is also something that's very interesting and meaningful to us. And we do find ourselves much more as a metacloud that connects between different clouds
rather than just like the way to connect on prem and hardware. We also recognize that on prem hardware is not going away, and we need to continue
supporting that in the mid to even longer future.
Unknown: Alright. Well, for anybody who wants to get in touch with you and follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And as the final question, I'd like to get your perspective on what you see as being the biggest barrier to adoption for machine learning today.
Unknown: Validation
and understandability.
Not not just validating the actual algorithm, validating the impact of it on your
clinical
workflow or on your patient or, you know,
the outcomes of that patient
and commercial outcomes and all that. I I think
there's been a lot of really cool stuff going out to market. I think the
the actual,
ability to quantify
value of that is not
progressed as fast as the,
business.
And in a deeply regulated and deeply
deeply risky
area like health care, it's not enough to show a good,
fragmented nature of health care, it's also harder to prove that value. You change an algorithm on Amazon
Marketplace,
and you can see if most stuff is bought or isn't bought. You change an algorithm to predict the outcome with cancer patients or help you,
pick the right medication,
right intervention.
Getting to actually understand what what ultimately happened is
not trivial effort at all. It it it's not done. If if I look at some of the most impressive validation studies I've seen on AI prospectively with prospective data, it's been on a few dozens of cases in most in in most of, cases. And it's been with manual data curation.
So there's clearly, like, you
know, in terms of building
and integrated platforms and integrated capabilities in order to track that longitudinal view of a patient and of
different outcomes.
That's a long way to go. That's definitely been a thing in in terms of,
transparency
and explainability.
Many algorithms are still black box. You don't understand exactly why it made a certain prediction
and I I suspect it's it's part of the reason
why much of AI today is restricted for,
operational use. And I I I'd include patient trials as kind of like a semi operation vision
rather than, you know, an actual autonomous diagnostic,
or for administrative purposes per se in hospitals,
and is only now starting to scrape the
surface
of a true potential of AI in health care.
Unknown: Definitely. Very interesting. Thank you for that. And thank you for taking the time today to join me and share the work that you're doing at Rhino Health and some of the ways that your platform is being applied in the health care industry.
Definitely great to see folks helping to empower those capabilities and help to push that forward. So I appreciate all of the time and energy that you and your team are putting into that, and I hope you enjoy the rest of your day. Absolutely. Thank you so much for having me, Ovo.
Unknown: Thank you for listening. And don't forget to check out our other shows, the Data Engineering Podcast, which covers the latest in modern data management,
and podcast dot in it, which covers the Python language, its community, and the innovative ways it is being used. You can visit the site at the machine learning podcast.com
to subscribe to the show, sign up for the mailing list, and read the show notes. And if you've learned something or tried out a project from the show, then tell us about it. Email hosts at themachinelearningpodcast.com
with your story. To help other people find the show, please leave a review on Apple Podcasts and tell your friends and coworkers.