Azure API for FHIR (Fast Healthcare Interoperability Resources) | Azure Friday

Azure API for FHIR (Fast Healthcare Interoperability Resources) | Azure Friday


>>Hey friends, did you know that
there is a new standard from the Health Level Seven
International Community for sharing healthcare data? It’s called Fast Healthcare
Interoperability Resources or FHIR. You can use the managed to
FHIR Service in Azure to accelerate development of
your FHIR applications. Michael Hanson is here
to give us a tour of the new Azure API for FHIR
today on Azure Friday. [MUSIC]>>Hey friends, I’m
Scott Hanselman and it’s another episode of Azure Friday.
How are you Michael Hanson?>>Very good, like to be here.>>I am very excited
to hear about this. This is like the intersection
of everything that I like, healthcare, data, standards in Azure. So talk to me about FHIR.>>So FHIR is a new standard for
sharing healthcare information. If you’ve ever gone to the doctor in America or anywhere in
the digitized world, you’ll know that we’ve
gotten very good to put everybody’s records
into electronic form, doctors always busy typing. But then if you’ve tried to move
from one doctor to another, you’ll notice that that’s
hard or if you try and get access to your own
healthcare information, you’ll know that that’s hard. So within the Standards Community, there is been a big effort
to make that better and they come up with
this new standard called FHIR. The idea is really to have
modern rest APIs that you can pull and interact
with healthcare data with. So this standard is
defined in the community, you can find all about
the standard here HL7.org/fhir. So this is an open standard. It’s not something that we’re participating in the development
of the standard at Microsoft, but it’s really a community effort. With the standard, everything
that you can think about in the health care system is modeled as what we call a resource. So think of it as an object with some properties on patient
would be a resource, condition is a resource, encounter as a resource, and so on. Then we have this rest API that
we can use to search this data, update data, retrieved
the data, and so on. So that’s really what we’re busy implementing stuff to enable
customers to work with in the Cloud.>>I’ve actually tried
as a point of context. I’d been a Type 1 diabetic
for 25 years, and I’d been collecting
data about myself. Over the years, it’s gone from
CSV files to MongoDB databases. Now it currently runs in
an Azure App Service. But when I go to my doctor, my doctor uses
proprietary systems with third-party companies that
we have to interact with.>>Yeah.>>I would love a world
where we can really interoperate and share my data with my doctor in a safe and secure way.>>Yes. The idea is
really that regardless of what proprietary system
your doctor uses behind the scene, what electronic medical
records system they use? This should be a FHIR API. We’ll use a patient can go and
get access to your data or maybe another provider
that you need care from can access
your records, and so on. So a to enable customers to work
with the standard in Azure, we are developing
first-party components that can be building blocks in
these solutions that you build. The first thing that we’re
building really as a FHIR Server. This is an open-source project. So there is really true outlets of this work that we’re
doing on our Team. One is, this open-source project which is a FHIR Server
that you can go grab off GitHub here and deploy yourself into your own
Azure subscription. It’s basically a front-end API, and then there is a backend database. In the open-source,
here we have other Cosmos DB backend or
SQL Server based backend. In the open-source, we
also support a couple of different versions
of the standards are fairly new evolving standard. So STU 3 was the previous
version released, four is what’s the latest
version we support both of those in
the open-source project here. But you can take this code, you deploy it into
your own Azure subscription and then you have a FHIR Server. So it’s really just an API, where the database behind it. But of course not all
customers will want to grad the open-source code,
run it themselves. So the other option
that we have here is for us on our Team to run
this on behalf of customers. So we have a managed service for
this now in Azure where you can quickly go and spin up a
FHIR API and be up and running.>>So FHIR as a Service, but I might have
existing data like I do, actually I’ve got three years of data not just encounters and
conditions but are ongoing data. I have blood sugar data, every five minutes
for 24 hours a day, for three to five years, and I would want to feed that into the FHIR Server
and make it available. Is that too much? Do I have to build an adapter?>>Well, depending on
the format of your data, may well be some be restructuring
of the data that goes on. But I’ll show you in
a second few ways that you can get data
into the service fairly quickly but using
other components that we have in Azure like
functions, and so on. But, just quickly, if you
wanted to get a FHIR Server, you can see I already
have a demo environment running here that I’ll
get to in a second, but let’s say you just
wanted to FHIR Service. We now have this as
the first party service. So I can just go here in
the Azure Portal and type of a FHIR. Then there is actually
the Azure API for FHIR, which you can see as a preview
service here and I will simply say, create the few details you
would need to fill in. I probably need a resource group
for this here Azure Friday, I should say and I would
also need to give it a name. Here we go. There’s an additional details around who has access
to it and so on, we use Azure Active Directory, is the identity source
for this managed service.>>All right.>>But once you’ve
filled in these details, you simply say Review and Create, and then a few minutes later you have a FHIR API up and
running and ready to go.>>Awesome.>>So that makes it easy
for people like yourselves, that want, I want to place
for my on FHIR data the land.>>Yeah.>>You can be quickly up
and running with this, but also partners that we work with that are
building applications on top of the file standard, but they’re not necessarily in the business of making a FHIR server, but they need this as a component
where they can securely store their data and have
somebody who run that for them.>>Exactly.>>That’s the service that
we have available here.>>Yes, if I feel like I’m qualified to store my data
and worry about my data, but I rather not run a FHIR Server?>>Yeah.>>I’d rather you run it for me.>>Yes, you would like to
have somebody else where the pager in middle of
the night, that’s what we do. So but of course this is just a FHIR Server and an API is not super exciting
to play with on its own. So if you want to get your feet wet and play
with this a little bit, we’ve actually created
a little buddy repository here which is called
FHIR Service samples, where you can go in and spin up a small scenario that shows
not just the FHIR API, but also a number of
client applications accessing this. So it’s available on GitHub as well, our team maintains this, so we keep it up-to-date with the latest developments that
we have in the FHIR API.>>Cool.>>So few diagrams that
you can find here, but this is basically this scenario
we’re deploying here, there’s of course
the FHIR API itself. Then we have a couple of different dashboards and now I’ll show them, but different flavors of applications that you can
play with take apart. Then we have something called
SMART on FHIR application. So SMART on FHIR is a framework that’s built on
top of the FHIR standard. It describes that you should exchange healthcare
data in the FHIR form, and using the FHIR API, but also how a third party
application may go and access a FHIR API in
terms of authentication, getting a token, and so
on, and that whole flow. That’s something that’s
very common among with electronic medical
records as well. Third parties can develop SMART on FHIR applications that can go
to the FHIR Server and say, how do I authenticate? Go through the whole flow, get a token and then access the FHIR data, and I’ll show a couple
of examples of that. Then in this scenario, to enable
input and output of the data, we have an Azure
Function here that can grab patient data from
blob storage pull it in. Then we also have a Data Factory
that could pull it out again in the Bolt FHIR Format
and the FHIR community, and hopefully we’ll have
a chance to look at that too. So what I’ve done here is,
I’ve already spun this up, it takes about five minutes
to stand up this environment. There are some
instructions here on how you do it and how you configure it, the different flavors
of this environment. We’ll skip over this here
in the interest of time, but it’s pretty straightforward, we have some automation to do this. I’ve spun up one of
these environments all here, and this is all the resources
that get plopped in here. It looks a little bit overwhelming, but I’ll walk through what
some of these things are. So first of all, there is
an Azure API for FHIR here, which is the central part
of our environment. Then because what we do when we
spin up this demo environment, we also create a dummy users and
various identities and stuff, so that you can play with
this environment for a little bit, and restore the details for those users in this key vault
that’s available here, so that you can go and
grab these various things. So for instance, you
can see here there’s an administrative user here
and he has a password. I’m going to grab this password
here from the Key Vault. Then there are a number of Web Apps in their number
of App Service apps, where we host some basic code that we’ve created
ourselves for demo, but also what we host some
smart on fire applications, that we don’t actually
write ourselves, but we pull them in from external
repositories to show that we can have third party applications
work against our service. So I’m going to grab one
of these dashboards here. This is a JavaScript one in
this particular case here, and I’m just waiting
here for the URL to show up for this which
will hopefully do. Here we go, I’m going to open
this up in a private window here, so that I can sign
in with a dummy user that I created or that
the environment created.>>All right.>>So this is-.>>It’s a quite your->>Yeah, this is
a test tenant that we have, I didn’t want to create
all the test users here. But now we can see what I’m
going through the flow here, and it’s asking for
permission to access my healthcare API in the background.>>Okay.>>So this app is
now going to pop up, and I had no patients
in this environment. So I’m going to see
an empty list of patients here, and I’m going to go ahead in a second and import
some patients into it. But what do you do have available
in this test dashboard is a little about me link here where you can see what FHIR API
I’m connected to here. Also actually grab a token
for this if you wanted to put that over into post man and
just play with your API. Of course, it’s not
something you would do in a production app, but here for-.>>Of course.>>For a sandbox,
this is quite handy. So if we go back to all the resources here
in our demo environment. One of the things that we have
deployed here is an Azure function, and this function listens
to a storage account. Once we dump some patient data
into the storage account, it will get ingested
into this service, this particular function here. So we don’t actually use the URL
endpoint here of the function, but you can just check that it’s up and running and make sure
that everything is working. What we’re going to import into
this here is a synthetic data. So we can’t of course put
we’ll live patient data into this as we’re playing around,
but there’s actually, you can just see actually there’s
a little message here saying that the healthcare API that we
just deploy it was in fact done. But, what we’re doing is we’re generating synthetic data that we’re pulling into this environment. I’ll get back to what
does this in a second, but there’s a little import folder here that you can go
into and just say, “I want to import some patients”. What we’re importing is what we
in FHIR called bundles of data. So each of these files here represent a bundle of data that is everything that’s connected
to a specific patient. The way that this data was generated was with
a project called Cynthia, which is actually
an open source project that has been developed very
much in this community as well. What this is really like
a patient simulator. A patient gets born, they go to the pediatrician, they get weigh, they get measured, they have healthcare events, they may have a symptom, and then there’s somebody
roles are biased, they may sim City, but it also works the FHIR lifecycle. So it basically takes
people through their lives, and as they go through
their lives they interact with the healthcare system in
various points in time.>>That’s cool.>>Generating
observations, medications, encounters, all these things that
happen in health care system.>>That’s cool.>>So if you work with
health care data, this is super useful because
you get a very realistic, it’s not real but it realistic.>>Yeah, realistic but not real.>>Yeah. So what
this little function does is, it grabs these bundles of data that contain all this information
and then just make sure all the internal
references are correct and then pushes it all into the FHIR API. So if I now flip over to
my demo application and refresher, I should see that I now
have some patients in here.>>In [inaudible]>>In my patient dashboard. I could see in this case
I imported 11 patients. In this little dashboard, you can then, if you’re not
familiar with the FHIR standard, this is neat for just browsing around seeing
what FHIR actually is, so hopefully I can take a look at those patients
see what our data looks like.>>Okay.>>I’ve Just.>>[inaudible] infection.>>Yeah. I was just not
being patient enough, I’ll grab this patient
here, for instance.>>There is the API itself.>>So this is of course
again you would not have this in a production app, but this is useful for getting
familiar with the standard, I can go in here and grab
this patient here in this case. See there was a bunch
of different things, encounters and so on going
on with this patient here. I go back to my list of patient, I had another one up here, and again he has
sinus infection and so on. I can grab these. Look at what the different FHIR
resources actually looked like. Of course, there are
many other resources than these particular ones
that we’re looking at. We just got some conditions, encounters of like
four observations down here. For instance, you can see
an observation would be things like, body weight, or hemoglobin of the things that get
measured on these patients. But of course there
are many other things that happen to a patient. There’s billing information. All of this is also in the FHIR API. So you can go in and play with the applications and
modify these things. But there was then these third-party applications that you can use with your FHIR API. Once your data is in FHIR form, there’s this ecosystem
or applications out there that adhere to
this SMART on FHIR standard. So what we’ve done here
in the environment, I could just pull
the diagram up here again. So remind everybody, we have to FHIR API and we’re looking at
the data in this dashboard. From this dashboard, I can still
run this other application, it’s actually hosted
by somebody else, but pointed to my FHIR servers
and say grab data from here, and it will initiate
the authentication flow and so on. So I could grab this patient here, which is a child in this case
and then I could pull up a growth chart for this patient. So the growth chart application is one of the more famous examples, in the SMART on FHIR community
it’s shown a lot. But it was developed as an example of something where you have something visual to look at, the pull and number of different
measurements from a patient. That’s also something that
if you have a child yourself or have ever taken a child
to the pediatrician, you’ll know that this
is something that the physician typically pulls up.>>This might be a silly question, but is that effectively
a stateless application? Because it didn’t pull
the data and make a copy and then squirrel it away. It it pulled the data it needed to make the chart, it made the chart, then I read that and then I close the app and that data
just remains in FHIR.>>In fact, in this case,
it’s a pure JavaScript app. Nothing ever goes back to the server. I just happened to have
taken it out of the SMART on FHIR GitHub repository and
put it into a web app, because I had to stick it somewhere. So it’s a single-page JavaScript app. It initiates and then it goes to model FHIR server and says “How
do I authenticate myself?” It discovers that the endpoints, it initiates the flow. I’m already logged in this case, and then it’s able to
pull all the information out and then display this. So this now creates this ecosystem
where somebody else can say, “I want to develop this really
cool app that can show me my blood sugar or how I
might track various things.” Then I just focus on the app because there is the standard
that I’m building on top of.>>That’s fantastic.>>Then the data can be
hosted in Azure as well. So if we go back and
look at our scenario, we’ve taken some data, we’ve taken from from
Blob storage, imported it in, and now it’s in
our FHIR Servers and we can drive all these
client applications. There are of course also
customers that want to work with this data
more in a analytic way. The REST API is not always
the right tool for that. Typically, they want to pull it into something like Databricks
or something else. So in this little scenario here, we’ve actually set up a Data Factory. By the way, here where we
imported all the data, if I refresh here now, we can see all these files
are gone because they actually got imported in. But if I go back to
my resource group here, I have a Data Factory
that we’ve configured. We’ve actually configured
it in a way that this would work pretty
much with any FHIR Server. So there are different
export capabilities that a FHIR API can or cannot implement. In this case, we’re doing
something very simple, where we’re just
interacting directly with the REST API to pull
the data out to stage it. But the format that we end up
putting into is the format that the community call [inaudible]
around in terms of bulk export, which is a new line
delimited JSON format, so every line in the FHIR
would be a new resource, and you could generate
these giant JSON files that you can then for instance do stuff with in
something like Databricks. So the template here
that we have the deploy this stuff sets up export pipelines
for various resources. So here’s for
instance patient and we’ll just go in here and
initiate the export. It’s actually a two-stage
process in this case, but we’ll be just using
some basic functionality in Data Factory to
interact with our API. It goes into Blob storage and
we format it a little bit. You see the first stage is done
here and in a couple of seconds, the second stage should
be done as well. So now we’ve actually exported
all of our patient data, and I could just for completeness here we
export a little bit more. So I’m taking out
all my observations as well.>>Then in the interest of time, once you’ve worked
through that process, now a data scientist
could go to town?>>Yeah, exactly. So we’ve actually
put into this repository here a little IPython Notebook that you could import into
Databricks just as an example. Shows how you could connect to the storage account that’s
associated with this Data Factory. Create temporary tables pulling
out various observations, some from demographic information, some that’s actual weight
and height information, do various queries
across it and joints, and so on, and do
more population scale analytics on the data that you might
have in your FHIR API.>>Fantastic.>>So go try it out.>>So this is in preview right now?>>Yeah.>>Folks that are interested in
this can get involved on GitHub. They can look at the server.
They can as you said go into Azure dashboard and make
one of these themselves.>>Yeah.>>As you’ve pointed
out, there’s more than enough synthetic sample data
for you to play with.>>Yeah.>>I know I’m going to play with
this with my own personal data.>>Yeah.>>Fantastic. I am learning all
about the Azure API for FHIR, and all the great new
things happening in health care on Azure
today on Azure Friday. [MUSIC]

Daniel Yohans

1 thought on “Azure API for FHIR (Fast Healthcare Interoperability Resources) | Azure Friday

  1. Ronald Marrero says:

    I'm learning about FHIR now for a Health Informatics course and came across this video. I must say, this Azure API is nice.

Leave a Reply

Your email address will not be published. Required fields are marked *