[MUSIC]
>> Hi, I'm Doug Seven,
Senior Director at Microsoft Health Next.
Welcome back to our video series on the Azure API for FHIR.
In this video, we'll be exploring how to
use the FHIR Tools for Anonymization
to deidentify health care data for the purpose of secondary use.
The HIPAA privacy rule specifies that
any data used for what is considered secondary use or not,
the primary care of a patient,
or the payment of their health care costs
go through a process of deidentification.
The HIPAA privacy rule specifies two forms of deidentification.
One is commonly referred to as safe harbor,
where the key identifiable attributes
are redacted from the health care record.
The other is referred to as expert determination,
where the data is either modified or
redacted such that an expert would
certify the data as safe for use in
a particular case where the data can't be reidentified.
The FHIR Tools for Anonymization is an open-source project
that enables you to control how you want to deidentify data.
We've also integrated the FHIR Tools for Anonymization into
the Azure API for FHIR in support of the export operations,
so you can export deidentified data.
We'll look at the FHIR Tools for Anonymization
and how you can use that tool as well as
how to use it within the export operation.
In an earlier video,
we looked at how to deploy
the FHIR server samples or
the FHIR sandbox into your own Azure subscription.
When we did that, we tackled a number of
resources that are deployed into your subscription.
One of the things that was in the diagram is
this export operation from
the Azure API for FHIR into a storage container.
It's this export operation that enables you
to do a deidentification process along the way.
Before we look at how to use the export operation,
let's look at how the FHIR Tools for Anonymization work.
The FHIR Tools for Anonymization is an open-source project.
You can find it at
github.com/Microsoft/fhir-tools-for-anonymization.
This is a project built by
the same team that builds the Azure API for FHIR.
As you read through the documentation
for the FHIR Tools for Anonymization,
you'll see how to quickly set this project up
and how to use it in a number of
different scenarios and what you can do with it.
There's a few key things that you need to look at.
One is there's a command line tool that
you can use in DevTest scenarios to see
how the FHIR Tools for Anonymization work
and modify how you want to do your deidentification.
There's a number of tutorials
as well as different ways in which you
can use the FHIR Tools for Anonymization.
As you scroll down, you'll see samples.
One of the key samples is
a sample configuration file for HIPAA safe harbor method.
The FHIR Tools for Anonymization are
based on a configuration file where
the deidentification happens based on what
you dictate through this configuration file.
Let's take a look at the R4 sample configuration file.
I've already opened it up in Visual Studio Code.
You can see here at the top it's FHIR version R4,
and then, there's a set of FHIR path rules.
These rules dictate how the data is deidentified.
As you can see, there's a half argument here
where we might call out a specific FHIR attribute,
in this case, Organization.identifier,
in which we've said the method to apply to this identifier is to
keep that versus anything that's of a node type extension.
We're going to redact, and that's because
we don't know what's in the extensions.
That could be PHI information in the extension,
so we'll just redact it completely.
As you scroll through,
you can see what the different options are.
You can see that a lot of information is redacted,
and that's because the safe harbor requirements
say that things like names,
dates, addresses, phone numbers,
all of that information gets redacted.
You can see there's a lot of information being redacted.
You can see here, we have an example of an age
where we perturb instead of redact
and we round that age to a number.
It's not the exact age but a rounded age.
As you scroll through,
you'll see as we get down towards the bottom,
we could pass all the redacting.
As you get to the bottom, we have
some examples of where we might do some other things.
For example, where we have a reference,
and a reference usually indicates
the identifier of another FHIR resource.
We've chose to use a crypto hash method on that,
meaning that we will hash all the identifiers.
That way, they'll be consistent,
you can still refer to a specific ID by its crypto hash.
You can also see that there's a number of node types,
that are date types,
where the method is not to redact but to date shift.
In this case, we are shifting the date
by a random value forward or backward,
usually within about 100 days.
We've defined the day shift scope as being at the resource level,
meaning all dates within this resource will be
shifted forward or backward by the same amount.
You can also choose to have this at
individual element level or at a folder level where
all resources that you deidentify at
the same time would be deshifted to the same amount.
You can see there's some other information in here.
For example, postal codes are one of those things
that have to be redacted if there's a small population,
and in particular postal codes,
here's a list of postal codes that have to be completely redacted.
Other postal codes would be rounded to the first three digits.
This configuration file dictates
how the FHIR Tools for Anonymization
command line tool will process the FHIR resources.
What I've got here is an example of a FHIR resource.
This is a patient, and you can see the patient has
an ID just like every FHIR resource.
If we go down past some of the extension data
and whatnot, down closer towards the bottom,
you can see we have things like
addresses in here. There's an address.
The address has an extension with latitude,
longitude, and then, there's key information about the address.
This is all part of information that's stored in this folder.
You can see here I've got my safe harbor JSON document.
That's the configuration file we were just looking at.
I've got a source folder where I have
those resources in this first resources,
that same resource we were just looking at.
I've got a deidentified folder that's currently
empty where I'm going to put the processed information.
I've already cloned the GitHub repo for
the FHIR Tools for Anonymization and I've used
Visual Studio to build the project globally.
I've got a command line project that I can run.
I'm going to go ahead and paste in my command.
Here, I've already created an environment variable that points
to the path of the command line tool that I built.
A FHIR anonymizer is just
an environment variable that I've set up.
It's pointing to a configuration file called safe-harbor.json,
which is the name of my configuration file in the folder.
I'm identifying the input as the source folder
and the output as the deidentified folder.
So we go ahead and run that command.
In this case, it's 11 JSON resources that are found in source.
It will process each one of those,
and you can see, it processed all of those
and completed with zero failures.
Now, we can see in the deidentified folder
that we've got a number of resources there.
So I'm going to go back into Visual Studio and we'll look into
the deidentified folder and
we're going to pull that same resource,
so the resource by the same identifier.
Here, we have the two resources,
the original resource and the deidentified resource.
Let me go and pop them into a second tab.
Okay. So we've opened the deidentified file in another tab,
so let me switch back to our original patient here.
We can see that the address and
location information is right around line 117 or so,
is where address starts.
In the deidentified patient,
you can see that it's a little bit shorter.
We've actually removed quite a bit of
information so the file is shorter,
so the address node shows up a little bit earlier.
Here, the address node is at line 81.
You can see what's been maintained and what's been changed.
Gender is not considered identifiable,
so that remains the same,
but birth date has been moved.
Instead of it being April 7th,
that's now February 25th.
It's been randomly shifted.
The extension that shows latitude and longitude for
the address has been removed because again
we've chosen to remove all extensions.
Then, the address information,
the street address has been removed,
and the city has been removed,
and we've chosen to maintain only state,
and then, postal code has been redacted
down to the first three digits.
So zero to one,
removing the last two digits.
That's an example of how the tools work.
Simply using the configuration file to define
how your identified data will be
transformed into deidentified data.
The command line tool is a great tool to use locally while you're
experimenting with how to build
your configuration file and what you want to do with it,
but using it in the export operation in
the Azure API for FHIR is really where the magic starts to happen.
As we look here at our Azure dashboard,
we've already deployed our FHIR server samples solution.
Make one slight modification,
which is if I look in the Storage Explorer
and I go into the blob containers,
I've already created a container called Anonymization.
Within that container for anonymization,
I simply uploaded my safe harbor JSON configuration file.
This is the same configuration file we were just using.
What I'm going to do is I'm going to use Postman
to fire off the export operations.
Here, I'm just going to do a get operation to call
the export command and I've specified two things.
One is the container where I want the results.
In this case, I've named the container DID results.
If I don't specify name,
an automatic name will be generated,
but this is much easier if I know where to go find my data,
and I know what containers have
identifiable data and what containers have deidentified data.
Then, I've specified the anonymization configuration file,
which is in that Anonymization folder.
That's the one requirement that we have here is that
the expert operation will look in
a container called Anonymization.
For this configuration files, we specify that.
Then all I have to do is invoke this.
Let me go ahead and send this API request.
Looking at my headers, I get back a location,
and this location is actually the status of the operations.
I'm going to go ahead and "Copy" that,
and I'm going to "Paste" it into another Postman window.
I'll go ahead and send that request to see what comes up.
It's still processing.
I don't have any information back,
so I can call this operation
until I get a result back and then, I know the operation is done.
In this case, the export operation
was called and the results were put into
the DID results container in a folder
called 20201216T174615 so on and so forth.
The good news here is, I didn't have
a DID results container
before so it'll be new, it'll be easy to find.
So if I refresh my containers,
there'll be a new container called DID results,
and in here will be the folder that we just talked about.
In that folder is an NDJSON document
for each resource that was exported.
In this case, we exported everything.
For example, I can look at patient to NDJSON document.
I can go ahead and just download it,
and we'll open it up in Visual Studio Code.
This is my NDJSON document.
An NDJSON document is just a new line
delimited JSON documents
and each line represents a record.
I had 11 patients in my sample repo,
and so 11 patients are exported here.
You can see their identifiers.
I'm going to scroll all the way to the right-hand side of
the document because most things are over here.
You can see what's been redacted and what's been changed.
We can see gender is all here.
In fact, we want to find
that same patient we were looking at before,
but we can see birthday has been modified from its original value.
Addresses have been redacted down to state,
and postal codes, so on and so forth.
In this case, we've just executed
the same safe harbor configuration file that we used before,
and the result is single file per resource,
where each new line in that file represents a new FHIR resource.
This can then be easily processed.
You can, for example, use this in a tool
like Databricks to query each of
these resources and build tabular structures
out of this data to use them in things like Machine Learning.
That was a quick tour of how
the FHIR Tools for Anonymization work.
You can clone the GitHub repo and build the project
locally and use it in
DevTest scenarios with the command line tool,
but you can also use the same capabilities in
the export operation as part of the Azure API for FHIR.
This enables you to export data from the Azure API for FHIR
while adhering to any rules,
you need to follow for the deidentification of data
such as the HIPAA safe harbor deidentification rules.
The export operation has a number of variables that you can use.
For example, you can choose to export
just an individual resource or
type of resource or you can do what I did,
which was export everything and deidentify it all.
I want to thank you for joining us on
this video and I look forward to seeing you in the next one.
[MUSIC]