[MUSIC]
>> Hi, my name is Marc Kuperstein
and thank you for joining me today,
where we're going to talk about the Azure API for
FHIR and we're going to focus on our health platform architecture.
With the final ruling of the ONC's Cures Act,
FHIR has become the preferred standard for exchanging
electronic health information and more
importantly, enabling the management of PHI data in the Cloud.
As part of our commitment,
make sure that health data is easily accessible,
Microsoft focuses and it has delivered
an open-source project for FHIR as well the Azure API for FHIR,
a fully-managed, enterprise-grade service.
Recently, the Health Human Services release a Cures Act,
which mandates the use of FHIR in
healthcare applications along with some other requirements.
We're seeing more and more customers
demanding the use of FHIR and moving in this direction.
What I want to do today is spend a little bit of
time talking about architecture.
Not so much about our feature perspective,
but thinking about FHIR as a system,
as a solution to help solve your problems.
The architecture is going to span from
ingestion all the way to use.
Now let's save a little bit of time and dive in.
What you're going to see over
the next several charts or slides is a concept,
so we're using conceptual architecture.
It's important to remember that the concept of architecture
does not represent exact physical deployment.
It's about an idea.
It's about a notion to help you get an idea of what's going on,
but it's all in a very positive way and make a ton of sense.
Let's look at the architecture really, really simply.
When you think about Azure API for FHIR,
it's really about user interfaces and data sources.
It's about normalizing the data.
Once I have this data in a normal form,
how do I query and search it?
How do I use it in analytics?
How can we use it for Machine Learning and doing models?
Along the way, how do I enrich and
transform the data into something that's important to me,
something I want to use?
How can they notify other people when changes occur in the data?
From a very simplistic point of view,
this is our system,
making sure we can bring data in
and let you use it for all the things you want to use it for.
But let's break it down a little bit.
When we think about the architecture at a conceptual level,
we have inputs on the left-hand side.
The Internet of Medical things,
our electronic health records,
imaging, data from our billing systems,
our contact management, third-party,
or even social determinants of health,
there's a plethora of sources of data that come in.
It is not so much that they go into the Azure API
for FHIR specifically as a server,
but they are part of a solution that people want to build.
On the right-hand side,
we see the potential possible clients
who may want to present the data,
Power BI, our reporting tool,
or maybe you want to write data back to an EHR.
You have mobile devices,
web or smart on FHIR apps,
or maybe you're using Microsoft Teams
or Microsoft Dynamics, or better yet,
what happens if you haven't computed
a risk score and want to put the data back into FHIR?
But the architecture is broken down into pillar,
and this is really important notion.
The first pillar is about ingesting and enriching the data.
How can you pull a large volume of data of
any variety and velocity into health care system.
This is an important facet,
bringing that data in and adjusting it into the solution.
Then, how do we persist it?
How do we create that unified record,
that unified longitudinal health record that tells me about my data,
stores my data, and I can
track its lineage back to where it came from.
Then, once I have this data persisted,
how do I actually query it?
How do I explore it? How do I operationalize it?
How do I use it for something meaningful?
Of course, once you go far enough,
how do I learn new insights?
Can I build AI models?
How do I treat my data as the source of amazingly rich data,
then feed my application?
Of course, all of this has to be built so I can scale.
If you think about these pillars and a systems,
the inputs and the outputs, we have
to have scale for this all to work.
Of course, we have to have trust.
Entire thing has to be secure, compliant, and operational.
Now, if you think about it from
a conceptual architecture point of view,
behind the scenes, you can't build
a system like this just on nothing.
Behind the scenes, you bring Azure to bear.
Azure Cloud has a ton of services that people use today,
well, okay not a ton,
but several hundred services that you put to
use today. How do you use them?
How will you use them?
We make use of a number of services and we suggest that you,
if you deploy our solution,
will want to use services too.
For example, Key Vault for managing your secrets,
Azure Policy for controlling what somebody can
do your subscription or not do more importantly,
Azure Active Directory, maintaining your users who
has a permission and identity to use your systems, and more.
Let's take it down another level.
Again, conceptually, remember those pillars.
Well now, you put processes into these pillars.
When you bring the data in,
you have to persist it.
Is it going to persist an API for FHIR,
or is it data that doesn't really
fit in the FHIR server but yet really
belongs in the FHIR ecosystem
and we might put it in Cloud Storage?
As I had this data persisted,
I want to be able to create cohorts.
Not one, but many.
Because cohorts are designed to meet needs,
should it be for research or for applications.
How do I treat this data,
how to use this data properly and control it,
to a who has access and who
specifically doesn't have access to data they don't need?
I might want to do intelligence searching over the data or in fact
do analytics or modeling over those data as well.
Once I've done that modeling,
I may want to run it through data science
ML clusters as you can see under
intelligence or use our cognitive AI services or in fact bots.
Of course, everything feeds into the applications.
You have a variety of applications and all are be able
to consume the data for different purposes.
You might have somebody doing
contact management with the patients following up on surgery
or you might have the doctor or medical assistant
who has point-of-care capturing observations.
All are valid application,
but they only need the data they need.
They shouldn't have more than they need.
Talking about implementation, let's add another layer here.
When we think about this now,
now we're starting to just components.
For example, IoMT.
There's an orchestration piece and knows how to take
IoMT data from the devices telemetry.
Bring it in, map it to patients,
and store the data in FHIR.
You've also heard recently another presentation about our HL7v2.
How you could do that from your current systems
for EMRs or EHRs, and we can convert it to
FHIR bundles and throw them in FHIR directly,
a way of collecting data as it's happening.
As new records to be entered into customers EMR,
how can you pull that data into FHIR to aggregate
together and pull together to a population view, for example.
Of course, there's a number of other stores we've
talked about earlier and how do we ingest those.
There's some type of data factory that
knows how to do data orchestration.
Of course, we're bringing it all onto FHIR as I said
into persist or into the Cloud Storage.
Now, once you have it there, what you want to do with it?
Why? We talked early about bringing up
a query and analytics or for intelligence.
But in many scenarios,
the data needs to be anonymized.
A researcher, for example,
does not need to see PII data.
What they do need to see is
a really vital data they need for doing their data analytics.
We have an anonymization tool which you've heard about in
other videos that will let you just bring data into your cohort,
into your datastore, and then, you can search over it.
You can do Databricks for analytics or use
our new Synapse Analytics engine.
Of course, all gets delivered to your applications.
In fact, it's even possible that
these applications are read directly from the API for FHIR.
All in all, the architectures are
pretty straightforward beast, if you will.
It's a series of pillars about ingesting, persisting,
creating analytics and intelligence all
designed to help you build really rich applications,
of course, that are compliant and secure.
In subjects a little bit and spend
the next few minutes talking about thing called
reference architectures and solutions.
Now, some examples just by way of discussion.
We talked early about ingesting HL7 messages.
How would you actually put that together?
You can pull it from your EMR,
making sure it gets guaranteed delivery to Azure when it's
run through the FHIR Converter and stored into FHIR.
How do you put those pieces together?
Our architecture shows you how to do that.
Or about collecting IoMT patient telemetry.
How do you bring that data into a system or multiple devices?
How do you map the patient to the device,
and how do you store the data in FHIR?
Another example.
For the researcher, how do you extract
a cohort from the Azure API for FHIR?
How do you anonymize it?
How do you insert a data lake?
Then how do you process it in Databricks or
Jupiter notebooks or HDInsight?
You choose the tool.
Of course, we have some really complex scenarios.
How do you enable clinical decision support using FHIR?
These are all very rich and complicated
solutions and problems that have to be solved,
but many of you want to do this.
What we offer you is a buffet if you will,
a place to go to and find new solution.
If you don't see one, let us know and we'll look at it
and figure out how we could recommend how to do it.
We update this regularly.
If you want to read about it,
we suggest you check
out aka.ms/healtharchitecture, going to take
you right to the GitHub site.
I hope you gained some benefit from this. Thank you.
[MUSIC]