OMOP/docs/cdmPrivacy.html

918 lines
33 KiB
HTML
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="generator" content="pandoc" />
<meta http-equiv="X-UA-Compatible" content="IE=EDGE" />
<title>Preserving Privacy in an OMOP CDM Implementation</title>
<script src="site_libs/header-attrs-2.25/header-attrs.js"></script>
<script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
<meta name="viewport" content="width=device-width, initial-scale=1" />
<link href="site_libs/bootstrap-3.3.5/css/cosmo.min.css" rel="stylesheet" />
<script src="site_libs/bootstrap-3.3.5/js/bootstrap.min.js"></script>
<script src="site_libs/bootstrap-3.3.5/shim/html5shiv.min.js"></script>
<script src="site_libs/bootstrap-3.3.5/shim/respond.min.js"></script>
<style>h1 {font-size: 34px;}
h1.title {font-size: 38px;}
h2 {font-size: 30px;}
h3 {font-size: 24px;}
h4 {font-size: 18px;}
h5 {font-size: 16px;}
h6 {font-size: 12px;}
code {color: inherit; background-color: rgba(0, 0, 0, 0.04);}
pre:not([class]) { background-color: white }</style>
<script src="site_libs/jqueryui-1.13.2/jquery-ui.min.js"></script>
<link href="site_libs/tocify-1.9.1/jquery.tocify.css" rel="stylesheet" />
<script src="site_libs/tocify-1.9.1/jquery.tocify.js"></script>
<script src="site_libs/navigation-1.1/tabsets.js"></script>
<link href="site_libs/highlightjs-9.12.0/default.css" rel="stylesheet" />
<script src="site_libs/highlightjs-9.12.0/highlight.js"></script>
<link href="site_libs/font-awesome-6.4.2/css/all.min.css" rel="stylesheet" />
<link href="site_libs/font-awesome-6.4.2/css/v4-shims.min.css" rel="stylesheet" />
<link rel='shortcut icon' type='image/x-icon' href='favicon.ico' />
<style type="text/css">
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
span.underline{text-decoration: underline;}
div.column{display: inline-block; vertical-align: top; width: 50%;}
div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;}
ul.task-list{list-style: none;}
</style>
<style type="text/css">code{white-space: pre;}</style>
<script type="text/javascript">
if (window.hljs) {
hljs.configure({languages: []});
hljs.initHighlightingOnLoad();
if (document.readyState && document.readyState === "complete") {
window.setTimeout(function() { hljs.initHighlighting(); }, 0);
}
}
</script>
<link rel="stylesheet" href="style.css" type="text/css" />
<style type = "text/css">
.main-container {
max-width: 940px;
margin-left: auto;
margin-right: auto;
}
img {
max-width:100%;
}
.tabbed-pane {
padding-top: 12px;
}
.html-widget {
margin-bottom: 20px;
}
button.code-folding-btn:focus {
outline: none;
}
summary {
display: list-item;
}
details > summary > p:only-child {
display: inline;
}
pre code {
padding: 0;
}
</style>
<style type="text/css">
.dropdown-submenu {
position: relative;
}
.dropdown-submenu>.dropdown-menu {
top: 0;
left: 100%;
margin-top: -6px;
margin-left: -1px;
border-radius: 0 6px 6px 6px;
}
.dropdown-submenu:hover>.dropdown-menu {
display: block;
}
.dropdown-submenu>a:after {
display: block;
content: " ";
float: right;
width: 0;
height: 0;
border-color: transparent;
border-style: solid;
border-width: 5px 0 5px 5px;
border-left-color: #cccccc;
margin-top: 5px;
margin-right: -10px;
}
.dropdown-submenu:hover>a:after {
border-left-color: #adb5bd;
}
.dropdown-submenu.pull-left {
float: none;
}
.dropdown-submenu.pull-left>.dropdown-menu {
left: -100%;
margin-left: 10px;
border-radius: 6px 0 6px 6px;
}
</style>
<script type="text/javascript">
// manage active state of menu based on current page
$(document).ready(function () {
// active menu anchor
href = window.location.pathname
href = href.substr(href.lastIndexOf('/') + 1)
if (href === "")
href = "index.html";
var menuAnchor = $('a[href="' + href + '"]');
// mark the anchor link active (and if it's in a dropdown, also mark that active)
var dropdown = menuAnchor.closest('li.dropdown');
if (window.bootstrap) { // Bootstrap 4+
menuAnchor.addClass('active');
dropdown.find('> .dropdown-toggle').addClass('active');
} else { // Bootstrap 3
menuAnchor.parent().addClass('active');
dropdown.addClass('active');
}
// Navbar adjustments
var navHeight = $(".navbar").first().height() + 15;
var style = document.createElement('style');
var pt = "padding-top: " + navHeight + "px; ";
var mt = "margin-top: -" + navHeight + "px; ";
var css = "";
// offset scroll position for anchor links (for fixed navbar)
for (var i = 1; i <= 6; i++) {
css += ".section h" + i + "{ " + pt + mt + "}\n";
}
style.innerHTML = "body {" + pt + "padding-bottom: 40px; }\n" + css;
document.head.appendChild(style);
});
</script>
<!-- tabsets -->
<style type="text/css">
.tabset-dropdown > .nav-tabs {
display: inline-table;
max-height: 500px;
min-height: 44px;
overflow-y: auto;
border: 1px solid #ddd;
border-radius: 4px;
}
.tabset-dropdown > .nav-tabs > li.active:before, .tabset-dropdown > .nav-tabs.nav-tabs-open:before {
content: "\e259";
font-family: 'Glyphicons Halflings';
display: inline-block;
padding: 10px;
border-right: 1px solid #ddd;
}
.tabset-dropdown > .nav-tabs.nav-tabs-open > li.active:before {
content: "\e258";
font-family: 'Glyphicons Halflings';
border: none;
}
.tabset-dropdown > .nav-tabs > li.active {
display: block;
}
.tabset-dropdown > .nav-tabs > li > a,
.tabset-dropdown > .nav-tabs > li > a:focus,
.tabset-dropdown > .nav-tabs > li > a:hover {
border: none;
display: inline-block;
border-radius: 4px;
background-color: transparent;
}
.tabset-dropdown > .nav-tabs.nav-tabs-open > li {
display: block;
float: none;
}
.tabset-dropdown > .nav-tabs > li {
display: none;
}
</style>
<!-- code folding -->
<style type="text/css">
#TOC {
margin: 25px 0px 20px 0px;
}
@media (max-width: 768px) {
#TOC {
position: relative;
width: 100%;
}
}
@media print {
.toc-content {
/* see https://github.com/w3c/csswg-drafts/issues/4434 */
float: right;
}
}
.toc-content {
padding-left: 30px;
padding-right: 40px;
}
div.main-container {
max-width: 1200px;
}
div.tocify {
width: 20%;
max-width: 260px;
max-height: 85%;
}
@media (min-width: 768px) and (max-width: 991px) {
div.tocify {
width: 25%;
}
}
@media (max-width: 767px) {
div.tocify {
width: 100%;
max-width: none;
}
}
.tocify ul, .tocify li {
line-height: 20px;
}
.tocify-subheader .tocify-item {
font-size: 0.90em;
}
.tocify .list-group-item {
border-radius: 0px;
}
</style>
</head>
<body>
<div class="container-fluid main-container">
<!-- setup 3col/9col grid for toc_float and main content -->
<div class="row">
<div class="col-xs-12 col-sm-4 col-md-3">
<div id="TOC" class="tocify">
</div>
</div>
<div class="toc-content col-xs-12 col-sm-8 col-md-9">
<div class="navbar navbar-default navbar-fixed-top" role="navigation">
<div class="container">
<div class="navbar-header">
<button type="button" class="navbar-toggle collapsed" data-toggle="collapse" data-bs-toggle="collapse" data-target="#navbar" data-bs-target="#navbar">
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand" href="index.html"><div><img src="ohdsi16x16.png"></img> OMOP Common Data Model </div></a>
</div>
<div id="navbar" class="navbar-collapse collapse">
<ul class="nav navbar-nav">
<li>
<a href="index.html">
<span class="fa fa-house"></span>
</a>
</li>
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" data-bs-toggle="dropdown" aria-expanded="false">
<span class="fa fa-landmark"></span>
Background
<span class="caret"></span>
</a>
<ul class="dropdown-menu" role="menu">
<li>
<a href="background.html">Model Background</a>
</li>
<li>
<a href="cdmRefreshProcess.html">CDM Refresh Process</a>
</li>
<li>
<a href="vocabulary.html">How the Vocabulary is Built</a>
</li>
</ul>
</li>
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" data-bs-toggle="dropdown" aria-expanded="false">
<span class="fa fa-list-alt"></span>
Conventions
<span class="caret"></span>
</a>
<ul class="dropdown-menu" role="menu">
<li>
<a href="https://ohdsi.github.io/Themis">THEMIS Convention Library</a>
</li>
<li>
<a href="dataModelConventions.html">General Conventions</a>
</li>
<li>
<a href="cdmPrivacy.html">Patient Privacy and OMOP</a>
</li>
<li>
<a href="customConcepts.html">Custom Concepts</a>
</li>
</ul>
</li>
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" data-bs-toggle="dropdown" aria-expanded="false">
<span class="fa fa-history"></span>
CDM Versions
<span class="caret"></span>
</a>
<ul class="dropdown-menu" role="menu">
<li>
<a href="cdm30.html">CDM v3.0</a>
</li>
<li>
<a href="cdm53.html">CDM v5.3</a>
</li>
<li class="dropdown-submenu">
<a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" data-bs-toggle="dropdown" aria-expanded="false">CDM v5.4</a>
<ul class="dropdown-menu" role="menu">
<li>
<a href="cdm54.html">CDM v5.4</a>
</li>
<li>
<a href="cdm54Changes.html">Changes from CDM v5.3</a>
</li>
<li>
<a href="cdm54erd.html">Entity Relationships</a>
</li>
<li>
<a href="cdm54ToolingSupport.html">Detailed tooling support per CDM field</a>
</li>
</ul>
</li>
</ul>
</li>
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" data-bs-toggle="dropdown" aria-expanded="false">
<span class="fa fa-plus-square"></span>
CDM Additions
<span class="caret"></span>
</a>
<ul class="dropdown-menu" role="menu">
<li>
<a href="typesOfAdditions.html">Types of CDM Additions</a>
</li>
<li>
<a href="cdmRequestProcess.html">How to Propose Changes to the CDM</a>
</li>
<li class="dropdown-submenu">
<a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" data-bs-toggle="dropdown" aria-expanded="false">Accepted Changes</a>
<ul class="dropdown-menu" role="menu">
<li>
<a href="https://github.com/OHDSI/CommonDataModel/tree/develop">CDM version in development</a>
</li>
</ul>
</li>
</ul>
</li>
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" data-bs-toggle="dropdown" aria-expanded="false">
<span class="fa fa-question"></span>
How to
<span class="caret"></span>
</a>
<ul class="dropdown-menu" role="menu">
<li>
<a href="download.html">Download the DDL</a>
</li>
<li>
<a href="cdmRPackage.html">Use the CDM R Package</a>
</li>
<li>
<a href="drug_dose.html">Calculate Drug Dose</a>
</li>
</ul>
</li>
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" data-bs-toggle="dropdown" aria-expanded="false">
<span class="fa fa-life-ring"></span>
Support
<span class="caret"></span>
</a>
<ul class="dropdown-menu" role="menu">
<li>
<a href="cdmDecisionTree.html">Help! My Data Doesn't Fit!</a>
</li>
<li>
<a href="faq.html">FAQ</a>
</li>
<li>
<a href="sqlScripts.html">SQL Scripts</a>
</li>
<li>
<a href="contribute.html">Ask a Question</a>
</li>
</ul>
</li>
</ul>
<ul class="nav navbar-nav navbar-right">
<li>
<a href="https://github.com/OHDSI/CommonDataModel">
<span class="fa fa-github"></span>
</a>
</li>
</ul>
</div><!--/.nav-collapse -->
</div><!--/.container -->
</div><!--/.navbar -->
<div id="header">
<h1 class="title toc-ignore"><strong>Preserving Privacy in an OMOP CDM
Implementation</strong></h1>
</div>
<p><em>By Kristin Kostka</em></p>
<div id="background" class="section level1">
<h1>Background</h1>
<p>The OMOP CDM is a person-centric model. Being person-centric means
the model can retain attributes that may be considered personal
identified information (PII) or protected health information (PHI).
There are many different ways a site may treat their OMOP CDM to uphold
their privacy protocols. In this article we provide guidance on overall
process and the potential fields that should be monitored to adhere to
these various privacy preserving protocols.</p>
<div id="defining-pii-and-phi" class="section level3">
<h3>Defining PII and PHI</h3>
<ul>
<li>PII is defined as any representation of information that permits the
identity of an individual to whom the information applies to be
reasonably inferred to either direct or indirect means [1].</li>
<li>The United States Department of Health &amp; Human Services´ Office
for Civil Rights has defined PHI as any Personal Identifying Information
(PII) that individually or combined could potentially identify a
specific individual, their past, present or future healthcare, or the
method of payment. There are eighteen unique identifiers considered to
be PHI: 1) names, 2) geographic data, 3) all elements of dates, 4)
telephone numbers, 5) FAX numbers, 6) email addresses, 7) Social
Security numbers (SSN), 8) medical record numbers (MRN), 9) health plan
beneficiary numbers, 10) account numbers, 11) certificate/license
numbers, 12) vehicle identifiers and serial numbers including license
places, 13) device identifiers and serial numbers, 14) web URLs, 15)
internet protocol addresses, 16) biometric identifiers (i.e. retinal
scan, fingerprints), 17) full face photos and comparable images, and 18)
any unique identifying number, characteristic or code. PHI is no longer
considered PHI when it de-identified of these unique attributes. PHI is
commonly referred to in relation to the Health Insurance Portability and
Accountability Act (HIPAA) and associated legislation such as the Health
Information Technology for Economic and Clinical Health Act (HITECH)
[2].</li>
</ul>
</div>
</div>
<div id="the-data-holders-responsibility" class="section level1">
<h1>The Data Holders Responsibility</h1>
<p>In OHDSI, it is the responsibility of each data holder to know,
understand and follow local data governance processes related to use of
the OMOP CDM. In the United States, these processes will follow your
organizations local interpretation for maintaining compliance to PII
and PHI protection. In OMOP CDM implementations containing European
Union citizen data, local governance processes will include measures to
comply with General Data Protection Regulation (GDPR) [3]. As a
community, the OHDSI data network covers more than 330 databases from 34
countries. There is extensive community knowledge on the interpretation
of rule sets and exemplar IRB and local governance workflows that can be
made available to institutions navigating these processes for the first
time. If your organization does not have an established data governance
process, please reach out on the <a href="forums.ohdsi.org">OHDSI
Forums</a> under “Implementers” and the community can respond with
shared guidance from their own deployments. As a community, we aim to
conduct research that keeps patient-level data local and share only
aggregate results.</p>
</div>
<div id="complying-with-privacy-preservation" class="section level1">
<h1>Complying with Privacy Preservation</h1>
<p>Complying with local governance processes depends on the rule set
being used. There may be allowable times when data use agreements and
data transfer agreements exist between collaborating institutions to
facilitate sharing of PII and PHI. In this section we will discuss
common rule sets that organizations adhere to.</p>
<div id="limited-data-sets" class="section level2">
<h2>Limited Data Sets</h2>
<p>A limited data set (LDS) is defined as protected health information
that excludes certain direct identifiers of an individual or of
relatives, employers or household members of the individual — but may
include city, state, ZIP code and elements of dates. A LDS can be
disclosed only for purposes of research, public health or health care
operations. LDS requirements are dictated by the HIPAA Privacy Rule.</p>
</div>
<div id="de-identified-data-sets" class="section level2">
<h2>De-identified Data Sets</h2>
<p>A de-identified data, as defined by Section 164.514(a) of the HIPAA
Privacy rule, is health information that does not identify an individual
and with respect to which there is no reasonable basis to believe that
the information can be used to identify an individual is not
individually identifiable health information. There are two methods for
achieving de-identification in accordance with HIPAA [4].</p>
<ol style="list-style-type: decimal">
<li>Expert Determination (§164.514(a))- Implementation specifications:
requirements for de-identification of protected health information. A
covered entity may determine that health information is not individually
identifiable health information only if:</li>
</ol>
<ol style="list-style-type: decimal">
<li>A person with appropriate knowledge of and experience with generally
accepted statistical and scientific principles and methods for rendering
information not individually identifiable:</li>
</ol>
<ol style="list-style-type: lower-roman">
<li>Applying such principles and methods, determines that the risk is
very small that the information could be used, alone or in combination
with other reasonably available information, by an anticipated recipient
to identify an individual who is a subject of the information; and</li>
<li>Documents the methods and results of the analysis that justify such
determination.</li>
</ol>
<ol start="2" style="list-style-type: decimal">
<li>Safe Harbor (§164.514(b)) The eighteen unique identifiers are
obfuscated. This includes processes such as:</li>
</ol>
<ol style="list-style-type: upper-alpha">
<li>Dates of service are algorithmically shifted to protect patient
privacy.</li>
<li>Patient ZIP codes are truncated to the first three digits or removed
entirely if the ZIP code represents fewer than 20,000 individuals.</li>
<li>Removing and, when necessary, replacing unique identifiers AND The
entity does not have actual knowledge that the information could be used
alone or in combination with other information to identify an individual
who is a subject of the information.</li>
</ol>
</div>
<div id="field-level-implications-of-de-identification-processes"
class="section level2">
<h2>Field-level Implications of De-identification Processes</h2>
<div id="person-table-attributes" class="section level3">
<h3>PERSON Table Attributes</h3>
<p>In the OMOP CDM, the PERSON table serves as the central identity
management for all Persons in the database. It contains records that
uniquely identify each person or patient, and some demographic
information. It is a table that has a number of field-level implications
for privacy preserving protocols.</p>
<p>Considerations include: - PERSON.person_id should never contain
Medical Record Number, Social Security Number or similar uniquely
identifiable number. This should be a number that is essentially
meaningless but has the ability to be a primary key across tables. -
PERSON.year_of_birth, PERSON.month_of_birth and PERSON.date_of_birth,
PERSON.birth_datetime may require some redaction or modification
depending on interpretation of rule set. Consult local guidance on the
need to modify these fields when creating compliant views of
de-identified data. - PERSON.person_source_value may contain sensitive
information used to generate the person_id field. It is advised to
practice caution when creating views of these data. It would be wise to
obfuscate or redact this field if you are not sure what is contained in
the raw information being extracted, transformed and loaded into the
CDM.</p>
</div>
</div>
<div id="date-fields-across-domains" class="section level2">
<h2>Date Fields Across Domains</h2>
<p>Date fields are used across many OMOP domains including:
OBSERVATION_PERIOD, VISIT_OCCURRENCE, VISIT_DETAIL,
CONDITION_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE,
DEVICE_EXPOSURE, MEASUREMENT, OBSERVATION, DEATH, NOTE, NOTE_NLP,
SPECIMEN, PAYER_PLAN_PERIOD, DRUG_ERA, DOSE_ERA, and CONDITION_ERA.</p>
<p>As discussed previously, some rule sets may require algorithmically
shifting dates. It is advised that when date shifting is applied, it is
done holistically. This means that when shifting dates, you should not
treat each record independently. Instead, a robust date shifting
algorithm will link off the <em>.person_id (where </em> is the domain
name such as CONDITION_OCCURRENCE, etc) and apply the same offset to all
events. This allows researchers to have the ability to understand the
sequence of events while preserving patient privacy.</p>
<p>The implications of not holistically shifting all events together by
the same offset means that information may be out of sequence or
illogical. An example would be a death record that happens prior to
other event records (conditions, drugs, procedures, etc). When applying
an algorithmic shift of dates, it is important to educate your OMOP CDM
user group of the known offset. This is especially important in temporal
studies which may be looking to make statements about disease history
relative to the time when an event is observed.</p>
<p>Some rule sets do not require algorithmic shifting of dates, such as
Limited Data Sets. In these situations, a user of a LDS OMOP CDM would
not be expecting dates to the shifted. If a shift is applied, it should
be disclosed and the offset amount (e.g. +/- 7 days, +/- 30 days, etc)
should be made available to those who have received permission to use a
LDS dataset. Otherwise, these data are not upholding the assumptions of
the rule set applied.</p>
</div>
<div id="location-table-attributes" class="section level2">
<h2>LOCATION Table Attributes</h2>
<p>The LOCATION table represents a generic way to capture physical
location or address information of Persons and Care Sites. When applying
privacy preserving procedures, this table should be reviewed and
scrubbed relative to the rule set. The LOCATION.zip field should be
redacted relative to the type of process applied (e.g. 3-digit zip for
de-identified data). The LOCATION.location_source_value should be
reviewed for potential PII/PHI. It would be wise to obfuscate or redact
this field if you are not sure what is contained in the raw information
being extracted, transformed and loaded into the CDM.</p>
</div>
<div id="provider-table-attributes" class="section level2">
<h2>PROVIDER Table Attributes</h2>
<p>The PROVIDER table contains a list of uniquely identified healthcare
providers. These are individuals providing hands-on healthcare to
patients, such as physicians, nurses, midwives, physical therapists etc.
In some privacy preserving processes, the PROVIDER.npi and PROVIDER.dea
fields may be redacted. Please review this field and confirm that you
are adhering to privacy rule sets. The PROVIDER.year_of_birth field is
an optional field that may also require treatment in certain rule
sets.</p>
</div>
<div id="observation-table-attributes" class="section level2">
<h2>OBSERVATION Table Attributes</h2>
<p>The OBSERVATION table captures clinical facts about a Person obtained
in the context of examination, questioning or a procedure. Any data that
cannot be represented by any other domains, such as social and lifestyle
facts, medical history, family history, etc. are recorded here.</p>
<p>We strongly caution ETL teams to review the OBSERVATION table for
potential PII/PHI. In some source systems, there can be information
coming in these vocabularies that are not laboratory or clinical
observations but instead are patient identifiers. If you search in
ATHENA, you will find there are a number of standard terms in the SNOMED
and LOINC vocabularies that can represent phone numbers, emails, and
other PII information.</p>
<p>It is difficult to create an exhaustive list of terms because these
ontologies do not maintain or publish lists of terms that may contain
patient identifiers. It is, therefore, up to data holders to perform a
review of this domain with an eye for these potential privacy issues.
The National COVID Cohort Collaborative, a NIH consortium which uses the
OMOP CDM, has published a resource for sites needing assistance with
identifying these potentially problematic records. A “live” version of
this table that will track updates over time is hosted at <a
href="https://github.com/data2health/next-gen-data-sharing/blob/master/CodesWithPPIPotential.csv"
class="uri">https://github.com/data2health/next-gen-data-sharing/blob/master/CodesWithPPIPotential.csv</a>.
We welcome additions to this list from the community.</p>
</div>
<div id="scrutinizing-_source_value" class="section level2">
<h2>Scrutinizing *_source_value</h2>
<p>The *_source_value (where * is the domain name such as
CONDITION_OCCURRENCE, etc) fields present an opportunity for sites to
carry forward potential PII/PHI in ETL processes. Because the convention
of the OMOP CDM has minimal boundaries on what are retained in these
fields, it is important to treat all source_value fields as potentially
containing PII/PHI. We highly advise all data holders to scrutinize
these fields when applying privacy preserving processes. It is not
uncommon for fields to be overloaded and contain potential patient
identifiers. Please use caution when transmitting or making views of
these fields available to users.</p>
</div>
<div id="scrutinizing-string-fields" class="section level2">
<h2>Scrutinizing String Fields</h2>
<p>Across OMOP Domains, there are many fields which permit the use of
strings (e.g. DRUG_EXPOSURE.sig, MEASUREMENT.value_as_string,
OBSERVATION.value_as_string, Weve discussed some of these in prior
sections. It is advised that fields with strings often have the
potential to contain unintentional PII/PHI. Targeted regular expressions
can be built into ETL processes in order to “sniff” out any additional
PII (or potential PII)such as any data in the format of a phone number,
or a person or place name. (E.g., the regular expression “Mr.|Mrs.|Dr.|,
M.?D.?” will find any string with an English name prefix.) Depending on
risk tolerance, the expressions could err toward sensitivity or
specificity, and could be tweaked over time to meet different rule
sets.</p>
<p>Extensive regular expression matching during ETL may add significant
processing time and should therefore not be relied upon as a sole
solution, but rather an extra protection against edge cases. Other
algorithmic rules may also prove useful, such as automatically
quarantining records with lengthy string values (which could signal the
presence of free text). If these approaches are implemented, records
that match the regular expressions or rules can be quarantined in a
separate table or staging area to be manually reviewed by a data broker.
Thus, in addition to adding another layer of PII protection, another
advantage of these approaches is the potential to uncover ways that
underlying vocabularies may be contributing to unintentional sharing of
PII and create awareness for future privacy preserving processes shared
across the community.</p>
</div>
<div id="note-and-note_nlp-table-attributes" class="section level2">
<h2>NOTE and NOTE_NLP Table Attributes</h2>
<p>The NOTE table captures unstructured information that was recorded by
a provider about a patient in free text (in ASCII, or preferably in UTF8
format) notes on a given date. The NOTE_NLP table encodes all output of
NLP on clinical notes. Each row represents a single extracted term from
a note. There is a high potential these tables may retain information
that is considered PII/PHI. In addition to overall string searching,
these tables are likely to be dropped altogether to adhere to the most
stringent rule sets.</p>
<p>It is highly advised that if you are conducting a study with NOTE and
NOTE_NLP table information, please consult with your local governance
and privacy officers to ensure compliance with local rule sets.</p>
</div>
<div id="conclusion" class="section level2">
<h2>Conclusion</h2>
<p>Privacy preserving processes are not one-size fits all. There are
many different rule sets that can be applied to datasets. Data holders
are recommended to consult with their local privacy officer(s) to ensure
all processes applied to a database are compliant with local
interpretation of the selected rule set.</p>
</div>
</div>
<div id="references" class="section level1">
<h1>References</h1>
<ol style="list-style-type: decimal">
<li>BibText version: <span
class="citation">@MISC</span>{noauthor_undated-mg, title = “Guidance on
the Protection of Personal Identifiable Information”, abstract =
“Personal Identifiable Information (PII) is defined as:”, howpublished =
“”, note = “Accessed: 2021-8-18” }</li>
</ol>
<p>Regular citation: Guidance on the Protection of Personal Identifiable
Information. [cited 18 Aug 2021]. Available: <a
href="https://www.dol.gov/general/ppii"
class="uri">https://www.dol.gov/general/ppii</a></p>
<ol start="2" style="list-style-type: decimal">
<li>BibText version: <span
class="citation">@MISC</span>{HIPAA_Journal2017-yo, title = “What Does
{PHI} Stand For?”, author = “{HIPAA Journal}”, abstract = “PHI is a term
used in connection with health data, but what does PHI stand for? What
information is included in the definition of PHI.”, month = dec, year =
2017, howpublished = “”, note = “Accessed: 2021-8-18”, language = “en”
}</li>
</ol>
<p>Regular citation: HIPAA Journal. What Does PHI Stand For? 23 Dec 2017
[cited 18 Aug 2021]. Available: <a
href="https://www.hipaajournal.com/what-does-phi-stand-for/"
class="uri">https://www.hipaajournal.com/what-does-phi-stand-for/</a></p>
<ol start="3" style="list-style-type: decimal">
<li>BibText version:</li>
</ol>
<p><span class="citation">@MISC</span>{noauthor_2018-mt, title =
“General Data Protection Regulation ({GDPR}) Compliance Guidelines”,
abstract = “The EU General Data Protection Regulation went into effect
on May 25, 2018, replacing the Data Protection Directive 95/46/EC.
Designed to increase data privacy for EU citizens, the regulation levies
steep fines on organizations that dont follow the law.”, month = jun,
year = 2018, howpublished = “”, note = “Accessed: 2021-8-18”, language =
“en” }</p>
<p>Regular citation: General Data Protection Regulation (GDPR)
Compliance Guidelines. 18 Jun 2018 [cited 18 Aug 2021]. Available: <a
href="https://gdpr.eu/" class="uri">https://gdpr.eu/</a></p>
<ol start="4" style="list-style-type: decimal">
<li>BibText version:</li>
</ol>
<p><span
class="citation">@MISC</span>{Office_for_Civil_Rights_OCR_undated-zy,
title = “Methods for De-identification of {PHI}”, author = “{Office for
Civil Rights (OCR)}”, abstract = “Guidance about methods and approaches
to achieve de-identification in accordance with the Health Insurance
Portability and Accountability Act of 1996.”, howpublished = “”, note =
“Accessed: 2021-8-19” }</p>
<p>Regular citation: Office for Civil Rights (OCR). Methods for
De-identification of PHI. [cited 19 Aug 2021]. Available: <a
href="https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html"
class="uri">https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html</a></p>
</div>
</div>
</div>
</div>
<script>
// add bootstrap table styles to pandoc tables
function bootstrapStylePandocTables() {
$('tr.odd').parent('tbody').parent('table').addClass('table table-condensed');
}
$(document).ready(function () {
bootstrapStylePandocTables();
});
</script>
<!-- tabsets -->
<script>
$(document).ready(function () {
window.buildTabsets("TOC");
});
$(document).ready(function () {
$('.tabset-dropdown > .nav-tabs > li').click(function () {
$(this).parent().toggleClass('nav-tabs-open');
});
});
</script>
<!-- code folding -->
<script>
$(document).ready(function () {
// temporarily add toc-ignore selector to headers for the consistency with Pandoc
$('.unlisted.unnumbered').addClass('toc-ignore')
// move toc-ignore selectors from section div to header
$('div.section.toc-ignore')
.removeClass('toc-ignore')
.children('h1,h2,h3,h4,h5').addClass('toc-ignore');
// establish options
var options = {
selectors: "h1,h2,h3",
theme: "bootstrap3",
context: '.toc-content',
hashGenerator: function (text) {
return text.replace(/[.\\/?&!#<>]/g, '').replace(/\s/g, '_');
},
ignoreSelector: ".toc-ignore",
scrollTo: 0
};
options.showAndHide = true;
options.smoothScroll = true;
// tocify
var toc = $("#TOC").tocify(options).data("toc-tocify");
});
</script>
<!-- dynamically load mathjax for compatibility with self-contained -->
<script>
(function () {
var script = document.createElement("script");
script.type = "text/javascript";
script.src = "https://mathjax.rstudio.com/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML";
document.getElementsByTagName("head")[0].appendChild(script);
})();
</script>
</body>
</html>