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 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