[MUSIC]
>> Welcome to our series of videos on the Azure API for FHIR.
We'll talk about interoperability,
health systems, architectures, and all things FHIR.
Hi, I'm Marc Kuperstein,
Senior Director for Microsoft Health Next.
With this video we continue our journey
of exploring the Azure API for FHIR and in this video,
we'll talk about ingesting data into FHIR from your EMR,
Electronic Medical Record system.
Let's take a look.
We think about the Azure API for FHIR,
and we think about the important things that we do.
In the middle of this diagram here really
represents this FHIR system or FHIR ecosystem.
Why do I say ecosystem?
Because we recognize that sometimes
there's more than one persistent store.
For example, we have our FHIR Server.
Now, we also now have our medical-imaging server for DICOM.
Two different stores be they're very related.
Well, when you think about how we ingest
data and how do you bring your data from the EMR in,
we need to really look at different ways you may ingest data.
One of them is batch.
Maybe dated from your EMR via batch or
your lab system or perhaps social determiners of health,
or you're using Text Analytics for Health,
any one of a number of ways of bringing data
into your solution, into FHIR.
Why would you use batch?
Typically you use batch for bulk ingestion.
I want to grab what I have today and bring it into FHIR or
because of the way I'm reading my data from
the EMR there's no point in doing real-time.
I should do batch. A good example is APIC provides a warehouse,
sort of a clarity which is written to on a scheduled basis,
well, you don't need to do real-time
because clarity is not updated in real-time.
You're going to process data in batch mode as an example.
The other way to do ingestion is real-time.
Now real-time is super important for how would you
bring data in as it's actually changing in environment.
Why is this important?
Imagining of scenarios where you actually
want to react to data as it's changing.
You want to react as data comes in so
that you can do things like clinical decision support.
You can look at the data and make decisions.
Do I need to notify
a care team or anyone of the number of possibilities?
In another video, my colleague [inaudible] talked about
HL7 and CCDs and how would you ingest those,
well, that's designed to a real-time.
I'd take HL7 V2,
for example, and convert it to FHIR to ingest it.
We'll talk a little bit more by what I mean by ingestion pipeline.
Just for purposes of this picture,
understand what we're saying is once you have
the data in your FHIR system,
there's really three ways to get it out.
There's transactional, the classic way,
if you need data about Mark or whomever.
Another is real-time.
As data is changing,
I want to process it,
I care about what happens.
We did have a risk assessments,
clinical decision support, maybe perhaps
either reaction to medical things.
As devices pick up data,
as the care team care about threshold
being gradually getting somebody's blood pressure or glucose.
Also, when we think about Microsoft Cloud for Health,
we use a real-time connection to feed the data to Dynamics.
That way as she's occurring FHIR the reflected
almost immediately in the Dynamics subsystem.
Of course, the last way to pull data out is bulk or batch.
What we call research,
I'm pulling data out.
I'm creating a data set or a cohort,
of which I want to do analytics
over or I want to process the data,
perhaps I want to de-identify it, perhaps I don't.
You have anyone of a number of choices.
But as a model,
this picture really represents
the high-level architecture of our system.
When we think about ingesting from an EMR,
we really need to think about the various ways we
might want to pull data in and the various places we pull from.
Perhaps I'd said earlier we get FHIR data or
maybe as an HIE or we want HL7,
a good example is the ADT message,
the admission, discharge, and transfer.
Or perhaps you have a comma-separated or you have relational.
Putting this picture as a block diagram of
our reference architecture that we talked about in a prior video,
is how does this data going to be processed and
how do you ingest it into the system and process it?
I'd like to say this is a magic pill you can take,
the red pill and suddenly you had adjusted your EMR.
But the reality is there's always a little bit of work to
do because every system,
like I said earlier, does it a little bit differently.
Consider, for example, this is
a reference architecture for data ingestion.
We see the various ways that we may bring data into FHIR.
Perhaps it's via a relay.
We call MLLP, the minimum lower
layer protocol or I'm listening for
HL7 V2 messages as they occur in the hospital network,
although over a VPN or directly to a network,
how do I pull that data?
How do I bring it up into
Azure and process it and guarantee that it
gets delivered in a meaningful way to
FHIR so you don't have lost records?
Of course, there's workflow,
how we do conversion?
What is converted?
How do you write it to FHIR?
You can see the list.
We have both batch and real-time feeds.
We recognize as I said earlier,
that there's a lot of data you want to pull in.
Finally, just because we don't have a tool
specifically for your storage format,
doesn't mean we can't do it.
We use tools like our Azure Data Factory shown at the bottom.
Bring data into the Azure environment and
convert it to a FHIR and then publish it.
One of the things you'll notice in this picture is we talk about
enrichment as being the last step before gets written.
Enrichment is a very important process for you to consider when
bringing data from your EMR into FHIR.
Data has all kinds of quality questions.
Is your data really clinging to your EMR?
Have your patient IDs all been neuralized?
Do you need EMPI?
Do you want to do de-duplication?
Do you want to apply terminology services for example?
Do you want to do quality checks?
Do you want to do Bhopal validation?
Does any one of a number of paths you want
and take a look at the data and how would you do that?
One of the things we show you in our examples and we provide is
tools to help you put these pieces together,
to get your data from your EMR or
your lab system or one-directional systems and get it into FHIR.
Is this a simple answer?
No. I wish it was.
But by having a road map for how you do this,
where we find that we can help customers pretty quickly,
bringing their data from various on-premise systems to FHIR,
where data can be normalized and checked for quality.
Then of course use downstream,
as we talked about for clinical decisions of quarter
perhaps hydrodynamics or perhaps
more around machine learning so you can do risk scoring.
Anyone of number of opportunities once your data gets into FHIR.
With that, I'll leave you here.
Hope this has helped.
Thank you for your time
and we'll see you in the next video.
[MUSIC]