[MUSIC]
>> Hi, I'm Doug Seven,
Senior Director in Microsoft Health Next.
Welcome back to our video series on the Azure API for FHIR.
In the previous videos,
you saw how FHIR plays a role in modern health care systems
and how the ONC Final Rule is really advancing
the application of FHIR in the US health system.
In this video, we're going to talk about the Azure API for FHIR,
which is an Azure service that implements the FHIR specification.
As we discussed in the previous video,
FHIR is really the definition of a set
of data elements known as resources.
Some of the examples we discussed before,
where patient or condition or observation
as different resource definitions that can
be exchanged between systems using a set of APIs
compliant with what is defined in the FHIR specification.
This is important because it makes this data available on
a common and standard format
regardless of what system it's coming from.
As FHIR was maturing in its definition as a specification,
we really started to think about how should we
support FHIR in the healthcare industry
in the Microsoft Azure Cloud?
The Azure API for FHIR was designed to enable the potential of
health data in a hyper-scale Cloud environment
for things like Machine Learning,
advanced analytics, and Artificial Intelligence.
In this case, we designed the Azure API for FHIR to leverage
the existing health data standards for interoperability,
the HL7 FHIR specification.
That means that any system that can
exchange data according to the FHIR specification,
can exchange data with the Azure API for FHIR.
The Azure API for FHIR is designed to
securely manage protected health information or PHI,
in an environment that complies with all regulations
for PHI in whatever region we've deployed into.
We're currently deployed into regions all around the world
supporting compliance requirements in all of those regions.
The goal of creating the Azure API
for FHIR was really to accelerate
the outcomes that you can get from things like
Machine Learning and advanced analytics and AI workloads.
If you can bring data from disparate systems
into a common standardized format like FHIR,
and bringing it into a single common dataset
in the Azure API for FHIR,
then you can start to explore what you
can do with that data in different systems.
As we think about how to enable modern health solutions in Azure,
we really think about how we support
bringing data from a disparate set of systems that may
or may not have any ability to communicate or
not with one another today and enable
that data to be ingested and enriched and brought
into a FHIR base system in Azure.
The Azure API for FHIR becomes that common dataset
where data from all these disparate systems can be
unified according to the FHIR specification.
Regardless of whether it's
an electronic health record system or a PACS system,
a wearable device, or a CRM system,
the data coming from that system can be ingested and enriched
into the FHIR format and persisted in the Azure API for FHIR.
Once it's there, then you have the ability to look
into that data for what you're really trying to explore and do,
whether it's Machine Learning or analytics or AI,
the ability to query and provision cohorts of
that data and use that data for
meaningful workloads is really critical.
Through a variety of capabilities,
we have to ingest and enrich data,
we can bring data from a variety of
disparate systems that may have no ability to
interoperate today into a single dataset
based on the FHIR standard.
The ability to persist that all of that data
in one dataset means that we're making
new capabilities available in terms of what you can
do in systems of engagement and systems of intelligence.
You can query that data to find different cohorts
or subsets of that data you might use for different workloads.
You can apply that data into different systems of
intelligence for things like Machine Learning or analytics.
Or you can just expose that data through a set of
common FHIR APIs to new systems of engagement,
whether that be tools like Teams or
Dynamics or third-party applications or
custom-built applications or new applications
leveraging standards like Smart on FHIR.
The idea here is that data comes
from disparate systems and gets unified into
a single common dataset and then can be
exposed in whatever way you
need for the workload you're working on.
All of this is enabled by a set of
capabilities we built in the Azure Cloud.
At the center is the Azure API for FHIR,
which is an implementation of the FHIR specification.
The Azure API for FHIR implements
the FHIR specification without opinion.
In other words, we implement the specification as
it's written and stay true to the specification.
If we feel that there's changes that need to be made to
the specification rather than
deviating from the specification in our implementation,
we work with the HL7 FHIR community to see those changes through.
On the ingestion side,
we built new tools for the
ingestion of data to be able to bring data from
disparate systems and convert it into
the right format to be persisted in the Azure API for FHIR.
One of those tools is the IoT Connector for FHIR,
which enables you to use connected devices,
both real-time devices, and sampling devices,
to bring data into the Azure API for FHIR.
The connector will convert that data into
FHIR resources and persisted in the Azure API for FHIR,
along with data coming out of the EHR or PaaS system.
We've also built a tool called the FHIR Converter,
which enables you to use the $ convert-operation
in the FHIR specification to pass in data like
HL7v2 messages or CDA documents
and convert those into FHIR bundles
where they can be persistent with the rest of your data.
This is tremendously important if you have systems that
aren't yet on FHIR and you haven't implemented FHIR APIs,
you can pass in HL7v2 data or
CDA data and convert it to
FHIR and persist it with the rest of your data.
Once data is in the system,
you have the ability to query that data
and export that data to use in secondary use scenarios.
According to the HIPAA Privacy Rule,
any secondary use of data requires that it
be de-identified in the appropriate way.
The FHIR Tools for Anonymization is
an open-source project that we built to support
a variety of different techniques for the de-identification
and anonymization of protected health information.
The Azure API for FHIR implements an export operation
according to the FHIR specification using the $ export operator.
One of the options you have when using
the export operation is to apply
the FHIR Tools for Anonymization to
de-identify the data on export.
We've taken the same code that we've written
an open-source and we've implemented it into
the Azure API for FHIR as
an option for de-identifying data on export.
This is perfect for a variety of
secondary use cases where you want to export data,
but you also want to abide by
the HIPAA Privacy Rule for secondary use.
When you point the Power BI FHIR Connector at
a FHIR endpoint, we'll interrogate the capability statement.
Then, you can define the relationships between
the resources in the FHIR service that you
want to use within your Power BI environment,
such as a patient and a condition.
That data is then imported into
the PowerBI environment where you're able to
create lots of visualizations of
that data and do really powerful things.
The Azure API for FHIR implements
the FHIR APIs according to the specification.
That means a wide variety of systems of engagement
also have the ability to connect to
those FHIR APIs and use that data in meaningful ways.
This can be mobile apps,
web applications, Teams interfaces,
or even Dynamics applications.
It's tremendously powerful to be able to
use a set of standards to bring
disparate data together into a single dataset
and represent that data in a variety of different ways.
But also to expose that data to new systems
of intelligence and new systems of engagement.
In the next modules,
you'll start getting hands-on use with the Azure API for FHIR.
We'll deploy the Azure API for
FHIR sandbox using our open-source GitHub project,
and you'll be able to look at a variety of
use cases where we've applied FHIR in different scenarios.
We'll explore the different capabilities of the FHIR service,
including the FHIR Converter,
the IoT Connector, the tools for de-identification,
anonymization, as well as the Power BI Connector.
Thank you very much. We'll see you in the next video.
[MUSIC]