1311 lines
50 KiB
HTML
1311 lines
50 KiB
HTML
<!DOCTYPE html>
|
||
|
||
<html>
|
||
|
||
<head>
|
||
|
||
<meta charset="utf-8" />
|
||
<meta name="generator" content="pandoc" />
|
||
<meta http-equiv="X-UA-Compatible" content="IE=EDGE" />
|
||
|
||
|
||
|
||
|
||
<title>dataModelConventions.knit</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="dataModelConventions.html">General Conventions</a>
|
||
</li>
|
||
<li>
|
||
<a href="ehrObsPeriods.html">Observation Periods for EHR Data</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 Proposals
|
||
|
||
<span class="caret"></span>
|
||
</a>
|
||
<ul class="dropdown-menu" role="menu">
|
||
<li>
|
||
<a href="cdmRequestProcess.html">How to Propose Changes to the CDM</a>
|
||
</li>
|
||
<li>
|
||
<a href="https://github.com/OHDSI/CommonDataModel/issues?q=is%3Aopen+is%3Aissue+label%3AProposal">Under Review</a>
|
||
</li>
|
||
<li class="dropdown-submenu">
|
||
<a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" data-bs-toggle="dropdown" aria-expanded="false">Accepted</a>
|
||
<ul class="dropdown-menu" role="menu">
|
||
<li>
|
||
<a href="https://github.com/OHDSI/CommonDataModel/issues/252">Region_concept_id</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">
|
||
|
||
|
||
|
||
|
||
</div>
|
||
|
||
|
||
<div id="data-model-conventions" class="section level1">
|
||
<h1><strong>Data Model Conventions</strong></h1>
|
||
<p>There are a number of implicit and explicit conventions that have
|
||
been adopted in the CDM. Developers of methods that run against the CDM
|
||
need to understand these conventions.</p>
|
||
<div id="general" class="section level2">
|
||
<h2><strong>General</strong></h2>
|
||
<p>The OMOP CDM is platform-independent. Data types are defined
|
||
generically using ANSI SQL data types (VARCHAR, INTEGER, FLOAT, DATE,
|
||
DATETIME, CLOB). Precision is provided only for VARCHAR. It reflects the
|
||
minimal required string length and can be expanded within a CDM
|
||
instantiation. The CDM does not prescribe the date and datetime format.
|
||
Standard queries against CDM may vary for local instantiations and
|
||
date/datetime configurations.</p>
|
||
<div id="tables" class="section level3">
|
||
<h3>Tables</h3>
|
||
<p>For the tables of the main domains of the CDM it is imperative that
|
||
concepts used are strictly limited to the domain. For example, the
|
||
CONDITION_OCCURRENCE table contains only information about conditions
|
||
(diagnoses, signs, symptoms), but no information about procedures. Not
|
||
all source coding schemes adhere to such rules. For example, ICD-9-CM
|
||
codes, which contain mostly diagnoses of human disease, also contain
|
||
information about the status of patients having received a procedure.
|
||
The ICD-9-CM code V20.3 ‘Newborn health supervision’ defines a
|
||
continuous procedure and is therefore stored in the PROCEDURE_OCCURRENCE
|
||
table.</p>
|
||
</div>
|
||
<div id="fields" class="section level3">
|
||
<h3>Fields</h3>
|
||
<p>Variable names across all tables follow one convention:</p>
|
||
<table>
|
||
<colgroup>
|
||
<col width="29%" />
|
||
<col width="70%" />
|
||
</colgroup>
|
||
<thead>
|
||
<tr class="header">
|
||
<th>Notation</th>
|
||
<th>Description</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr class="odd">
|
||
<td><entity>_SOURCE_VALUE</td>
|
||
<td>Verbatim information from the source data, typically used in ETL to
|
||
map to CONCEPT_ID, and not to be used by any standard analytics. For
|
||
example, CONDITION_SOURCE_VALUE = ‘787.02’ was the ICD-9 code captured
|
||
as a diagnosis from the administrative claim.</td>
|
||
</tr>
|
||
<tr class="even">
|
||
<td><entity>_ID</td>
|
||
<td>Unique identifiers for key entities, which can serve as foreign keys
|
||
to establish relationships across entities. For example, PERSON_ID
|
||
uniquely identifies each individual. VISIT_OCCURRENCE_ID uniquely
|
||
identifies a PERSON encounter at a point of care.</td>
|
||
</tr>
|
||
<tr class="odd">
|
||
<td><entity>_CONCEPT_ID</td>
|
||
<td>Foreign key into the Standardized Vocabularies (i.e. the
|
||
standard_concept attribute for the corresponding term is true), which
|
||
serves as the primary basis for all standardized analytics. For example,
|
||
CONDITION_CONCEPT_ID = <a
|
||
href="http://athena.ohdsi.org/search-terms/terms/31967">31967</a>
|
||
contains the reference value for the SNOMED concept of ‘Nausea’</td>
|
||
</tr>
|
||
<tr class="even">
|
||
<td><entity>_SOURCE_CONCEPT_ID</td>
|
||
<td>Foreign key into the Standardized Vocabularies representing the
|
||
concept and terminology used in the source data, when applicable. For
|
||
example, CONDITION_SOURCE_CONCEPT_ID = <a
|
||
href="http://athena.ohdsi.org/search-terms/terms/45431665">45431665</a>
|
||
denotes the concept of ‘Nausea’ in the Read terminology; the analogous
|
||
CONDITION_CONCEPT_ID might be 31967, since SNOMED-CT is the Standardized
|
||
Vocabulary for most clinical diagnoses and findings.</td>
|
||
</tr>
|
||
<tr class="odd">
|
||
<td><entity>_TYPE_CONCEPT_ID</td>
|
||
<td>Delineates the origin of the source information, standardized within
|
||
the Standardized Vocabularies. For example, DRUG_TYPE_CONCEPT_ID can
|
||
allow analysts to discriminate between ‘Pharmacy dispensing’ and
|
||
‘Prescription written’</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
</div>
|
||
<div id="vocabulary" class="section level2">
|
||
<h2><strong>Vocabulary</strong></h2>
|
||
<div id="concepts" class="section level3">
|
||
<h3>Concepts</h3>
|
||
<p>Concepts in the Common Data Model are derived from a number of public
|
||
or proprietary terminologies such as SNOMED-CT and RxNorm, or custom
|
||
generated to standardize aspects of observational data. Both types of
|
||
Concepts are integrated based on the following rules:</p>
|
||
<ul>
|
||
<li>All Concepts are maintained centrally by the CDM and Vocabularies
|
||
Working Group. Additional concepts can be added, as needed, upon request
|
||
by creating a <a
|
||
href="https://github.com/OHDSI/Vocabulary-v5.0/issues">Github
|
||
issue</a>.</li>
|
||
<li>For all Concepts, whether they are custom generated or adopted from
|
||
published terminologies, a unique numeric identifier concept_id is
|
||
assigned and used as the key to link all observational data to the
|
||
corresponding Concept reference data.</li>
|
||
<li>The concept_id of a Concept is persistent, i.e. stays the same for
|
||
the same Concept between releases of the Standardized Vocabularies.</li>
|
||
<li>A descriptive name for each Concept is stored as the Concept Name as
|
||
part of the CONCEPT table. Additional names and descriptions for the
|
||
Concept are stored as Synonyms in the <a
|
||
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_synonym">CONCEPT_SYNONYM</a>
|
||
table.</li>
|
||
<li>Each Concept is assigned to a Domain. For Standard Concepts, there
|
||
is always a single Domain. Source Concepts can be composite or
|
||
coordinated entities, and therefore can belong to more than one Domain.
|
||
The domain_id field of the record contains the abbreviation of the
|
||
Domain, or Domain combination. Please refer to the Standardized
|
||
Vocabularies specification for details of the Domain Assignment.</li>
|
||
<li>Concept Class designations are attributes of Concepts. Each
|
||
Vocabulary has its own set of permissible Concept Classes, although the
|
||
same Concept Class can be used by more than one Vocabulary. Depending on
|
||
the Vocabulary, the Concept Class may categorize Concepts vertically
|
||
(parallel) or horizontally (hierarchically). See the specification of
|
||
each vocabulary for details.</li>
|
||
<li>Concept Class attributes should not be confused with Classification
|
||
Concepts. These are separate Concepts that have a hierarchical
|
||
relationship to Standard Concepts or each other, while Concept Classes
|
||
are unique Vocabulary-specific attributes for each Concept.</li>
|
||
<li>For Concepts inherited from published terminologies, the source code
|
||
is retained in the concept_code field and can be used to reference the
|
||
source vocabulary.</li>
|
||
<li>Standard Concepts (designated as ‘S’ in the standard_concept field)
|
||
may appear in CDM tables in all *_concept_id fields, whereas
|
||
Classification Concepts (‘C’) should not appear in the CDM data, but
|
||
participate in the construction of the CONCEPT_ANCESTOR table and can be
|
||
used to identify Descendants that may appear in the data. See
|
||
CONCEPT_ANCESTOR table. Non-standard Concepts can only appear in
|
||
*_source_concept_id fields and are not used in <a
|
||
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor">CONCEPT_ANCESTOR</a>
|
||
table. Please refer to the Standardized Vocabularies specifications for
|
||
details of the Standard Concept designation.</li>
|
||
<li>The lifespan of a Concept is recorded through its valid_start_date,
|
||
valid_end_date and the invalid_ reason fields. This allows Concepts to
|
||
correctly reflect at which point in time were defined. Usually, Concepts
|
||
get deprecated if their meaning was deemed ambiguous, a duplication of
|
||
another Concept, or needed revision for scientific reason. For example,
|
||
drug ingredients get updated when different salt or isomer variants
|
||
enter the market. Usually, drugs taken off the market do not cause a
|
||
deprecation by the terminology vendor. Since observational data are
|
||
valid with respect to the time they are recorded, it is key for the
|
||
Standardized Vocabularies to provide even obsolete codes and maintain
|
||
their relationships to other current Concepts .</li>
|
||
<li>Concepts without a known instantiated date are assigned
|
||
valid_start_date of ‘1-Jan-1970’.</li>
|
||
<li>Concepts that are not invalid are assigned valid_end_date of
|
||
‘31-Dec-2099’.</li>
|
||
<li>Deprecated Concepts (with a valid_end_date before the release date
|
||
of the Standardized Vocabularies) will have a value of ‘D’ (deprecated
|
||
without successor) or ‘U’ (updated). The updated Concepts have a record
|
||
in the CONCEPT_RELATIONSHIP table indicating their active replacement
|
||
Concept.</li>
|
||
<li>Values for concept_ids generated as part of Standardized
|
||
Vocabularies will be reserved from 0 to 2,000,000,000. Above this range,
|
||
concept_ids are available for local use and are guaranteed not to clash
|
||
with future releases of the Standardized Vocabularies.</li>
|
||
</ul>
|
||
</div>
|
||
<div id="vocabularies" class="section level3">
|
||
<h3>Vocabularies</h3>
|
||
<ul>
|
||
<li>There is one record for each Vocabulary. One Vocabulary source or
|
||
vendor can issue several Vocabularies, each of them creating their own
|
||
record in the VOCABULARY table. However, the choice of whether a
|
||
Vocabulary contains Concepts of different Concept Classes, or when these
|
||
different classes constitute separate Vocabularies cannot precisely be
|
||
decided based on the definition of what constitutes a Vocabulary. For
|
||
example, the ICD-9 Volume 1 and 2 codes (ICD9CM, containing
|
||
predominantly conditions and some procedures and observations) and the
|
||
ICD-9 Volume 3 codes (ICD9Proc, containing predominantly procedures) are
|
||
realized as two different Vocabularies. On the other hand, SNOMED-CT
|
||
codes of the class Condition and those of the class Procedure are part
|
||
of one and the same Vocabulary. Please refer to the Standardized
|
||
Vocabularies specifications for details of each Vocabulary.</li>
|
||
<li>The vocabulary_id field contains an alphanumerical identifier, that
|
||
can also be used as the abbreviation of the Vocabulary name.</li>
|
||
<li>The record with vocabulary_id = ‘None’ is reserved to contain
|
||
information regarding the current version of the Entire Standardized
|
||
Vocabularies.</li>
|
||
<li>The vocabulary_name field contains the full official name of the
|
||
Vocabulary, as well as the source or vendor in parenthesis.</li>
|
||
<li>Each Vocabulary has an entry in the CONCEPT table, which is recorded
|
||
in the vocabulary_concept_id field. This is for purposes of creating a
|
||
closed Information Model, where all entities in the OMOP CDM are covered
|
||
by a unique Concept.</li>
|
||
</ul>
|
||
</div>
|
||
<div id="domains" class="section level3">
|
||
<h3>Domains</h3>
|
||
<ul>
|
||
<li>There is one record for each Domain. The domains are defined by the
|
||
tables and fields in the OMOP CDM that can contain Concepts describing
|
||
all the various aspects of the healthcare experience of a patient.</li>
|
||
<li>The domain_id field contains an alphanumerical identifier, that can
|
||
also be used as the abbreviation of the Domain.</li>
|
||
<li>The domain_name field contains the unabbreviated names of the
|
||
Domain.</li>
|
||
<li>Each Domain also has an entry in the Concept table, which is
|
||
recorded in the domain_concept_id field. This is for purposes of
|
||
creating a closed Information Model, where all entities in the OMOP CDM
|
||
are covered by unique Concept.</li>
|
||
<li>Versions prior to v5.0.0 of the OMOP CDM did not support the notion
|
||
of a Domain.</li>
|
||
</ul>
|
||
</div>
|
||
<div id="concept-classes" class="section level3">
|
||
<h3>Concept Classes</h3>
|
||
<ul>
|
||
<li>There is one record for each Concept Class. Concept Classes are used
|
||
to create additional structure to the Concepts within each Vocabulary.
|
||
Some Concept Classes are unique to a Vocabulary (for example “Clinical
|
||
Finding” in SNOMED), but others can be used across different
|
||
Vocabularies. The separation of Concepts through Concept Classes can be
|
||
semantically horizontal (each Class subsumes Concepts of the same
|
||
hierarchical level, akin to sub-Vocabularies within a Vocabulary) or
|
||
vertical (each Class subsumes Concepts of a certain kind, going across
|
||
hierarchical levels). For example, Concept Classes in SNOMED are
|
||
vertical: The classes “Procedure” and “Clinical Finding” define very
|
||
granular to very generic Concepts. On the other hand, “Clinical Drug”
|
||
and “Ingredient” Concept Classes define horizontal layers or strata in
|
||
the RxNorm vocabulary, which all belong to the same concept of a
|
||
Drug.</li>
|
||
<li>The concept_class_id field contains an alphanumerical identifier,
|
||
that can also be used as the abbreviation of the Concept Class.</li>
|
||
<li>The concept_class_name field contains the unabbreviated names of the
|
||
Concept Class.</li>
|
||
<li>Each Concept Class also has an entry in the Concept table, which is
|
||
recorded in the concept_ class_concept_id field. This is for purposes of
|
||
creating a closed Information Model, where all entities in the OMOP CDM
|
||
are covered by unique Concepts.</li>
|
||
</ul>
|
||
</div>
|
||
<div id="concept-relationships" class="section level3">
|
||
<h3>Concept Relationships</h3>
|
||
<ul>
|
||
<li>Relationships can generally be classified as hierarchical
|
||
(parent-child) or non-hierarchical (lateral).</li>
|
||
<li>All Relationships are directional, and each Concept Relationship is
|
||
represented twice symmetrically within the CONCEPT_RELATIONSHIP table.
|
||
For example, the two SNOMED concepts of ‘Acute myocardial infarction of
|
||
the anterior wall’ and ‘Acute myocardial infarction’ have two Concept
|
||
Relationships:
|
||
<ul>
|
||
<li>‘Acute myocardial infarction of the anterior wall’ ‘Is a’ ‘Acute
|
||
myocardial infarction’, and</li>
|
||
<li>‘Acute myocardial infarction’ ‘Subsumes’ ‘Acute myocardial
|
||
infarction of the anterior wall’.</li>
|
||
</ul></li>
|
||
<li>There is one record for each Concept Relationship connecting the
|
||
same Concepts with the same relationship_id.</li>
|
||
<li>Since all Concept Relationships exist with their mirror image
|
||
(concept_id_1 and concept_id_2 swapped, and the relationship_id replaced
|
||
by the reverse_relationship_id from the RELATIONSHIP table), it is not
|
||
necessary to query for the existence of a relationship both in the
|
||
concept_id_1 and concept_id_2 fields.</li>
|
||
<li>Concept Relationships define direct relationships between Concepts.
|
||
Indirect relationships through 3rd Concepts are not captured in this
|
||
table. However, the <a
|
||
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor">CONCEPT_ANCESTOR</a>
|
||
table does this for hierarchical relationships over several
|
||
“generations” of direct relationships.</li>
|
||
<li>In previous versions of the CDM, the relationship_id used to be a
|
||
numerical identifier. See the <a
|
||
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#relationship">RELATIONSHIP</a>
|
||
table.</li>
|
||
</ul>
|
||
</div>
|
||
<div id="relationship-table" class="section level3">
|
||
<h3>Relationship Table</h3>
|
||
<ul>
|
||
<li>There is one record for each Relationship.</li>
|
||
<li>Relationships are classified as hierarchical (parent-child) or
|
||
non-hierarchical (lateral)</li>
|
||
<li>They are used to determine which concept relationship records should
|
||
be included in the computation of the CONCEPT_ANCESTOR table.</li>
|
||
<li>The relationship_id field contains an alphanumerical identifier,
|
||
that can also be used as the abbreviation of the Relationship.</li>
|
||
<li>The relationship_name field contains the unabbreviated names of the
|
||
Relationship.</li>
|
||
<li>Relationships all exist symmetrically, i.e. in both direction. The
|
||
relationship_id of the opposite Relationship is provided in the
|
||
reverse_relationship_id field.</li>
|
||
<li>Each Relationship also has an equivalent entry in the Concept table,
|
||
which is recorded in the relationship_ concept_id field. This is for
|
||
purposes of creating a closed Information Model, where all entities in
|
||
the OMOP CDM are covered by unique Concepts.</li>
|
||
<li>Hierarchical Relationships are used to build a hierarchical tree out
|
||
of the Concepts, which is recorded in the <a
|
||
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor">CONCEPT_ANCESTOR</a>
|
||
table. For example, “has_ingredient” is a Relationship between Concept
|
||
of the Concept Class ‘Clinical Drug’ and those of ‘Ingredient’, and all
|
||
Ingredients can be classified as the “parental” hierarchical Concepts
|
||
for the drug products they are part of. All ‘Is a’ Relationships are
|
||
hierarchical.</li>
|
||
<li>Relationships, also hierarchical, can be between Concepts within the
|
||
same Vocabulary or those adopted from different Vocabulary sources.</li>
|
||
</ul>
|
||
</div>
|
||
<div id="concept-synonyms" class="section level3">
|
||
<h3>Concept Synonyms</h3>
|
||
<ul>
|
||
<li>The concept_synonym_name field contains a valid Synonym of a
|
||
concept, including the description in the concept_name itself. I.e. each
|
||
Concept has at least one Synonym in the <a
|
||
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_synonym">CONCEPT_SYNONYM</a>
|
||
table. As an example, for a SNOMED-CT Concept, if the fully specified
|
||
name is stored as the concept_name of the <a
|
||
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept">CONCEPT</a>
|
||
table, then the Preferred Term and Synonyms associated with the Concept
|
||
are stored in the <a
|
||
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_synonym">CONCEPT_SYNONYM</a>
|
||
table.</li>
|
||
<li>Only Synonyms that are active and current are stored in the <a
|
||
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_synonym">CONCEPT_SYNONYM</a>
|
||
table. Tracking synonym/description history and mapping of obsolete
|
||
synonyms to current Concepts/Synonyms is out of scope for the Standard
|
||
Vocabularies.</li>
|
||
<li>Currently, only English Synonyms are included.</li>
|
||
</ul>
|
||
</div>
|
||
<div id="concept-ancestor" class="section level3">
|
||
<h3>Concept Ancestor</h3>
|
||
<ul>
|
||
<li>Each concept is also recorded as an ancestor of itself.</li>
|
||
<li>Only valid and Standard Concepts participate in the <a
|
||
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor">CONCEPT_ANCESTOR</a>
|
||
table. It is not possible to find ancestors or descendants of deprecated
|
||
or Source Concepts.</li>
|
||
<li>Usually, only Concepts of the same Domain are connected through
|
||
records of the <a
|
||
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor">CONCEPT_ANCESTOR</a>
|
||
table, but there might be exceptions.</li>
|
||
</ul>
|
||
</div>
|
||
<div id="source-to-concept-map" class="section level3">
|
||
<h3>Source to Concept Map</h3>
|
||
<ul>
|
||
<li>This table is no longer used to distribute mapping information
|
||
between source codes and Standard Concepts for the Standard
|
||
Vocabularies. Instead, the CONCEPT_RELATIONSHIP table is used for this
|
||
purpose, using the relationship_id=‘Maps to’.</li>
|
||
<li>However, this table can still be used for the translation of local
|
||
source codes into Standard Concepts.</li>
|
||
<li><strong>Note:</strong> This table should not be used to translate
|
||
source codes to Source Concepts. The source code of a Source Concept is
|
||
captured in its concept_code field. If the source codes used in a given
|
||
database do not follow correct formatting the ETL will have to perform
|
||
this translation. For example, if ICD-9-CM codes are recorded without a
|
||
dot the ETL will have to perform a lookup function that allows
|
||
identifying the correct ICD-9-CM Source Concept (with the dot in the
|
||
concept_code field).</li>
|
||
<li>The source_concept_id, or the combination of the fields source_code
|
||
and the source_vocabulary_id uniquely identifies the source information.
|
||
It is the equivalent to the concept_id_1 field in the
|
||
CONCEPT_RELATIONSHIP table.</li>
|
||
<li>If there is no source_concept_id available because the source codes
|
||
are local and not supported by the Standard Vocabulary, the content of
|
||
the field is 0 (zero, not null) encoding an undefined concept. However,
|
||
local Source Concepts are established (concept_id values above
|
||
2,000,000,000).</li>
|
||
<li>The source_code_description contains an optional description of the
|
||
source code.</li>
|
||
<li>The target_concept_id contains the Concept the source code is mapped
|
||
to. It is equivalent to the concept_id_2 in the CONCEPT_RELATIONSHIP
|
||
table</li>
|
||
<li>The target_vocabulary_id field contains the vocabulary_id of the
|
||
target concept. It is a duplication of the same information in the
|
||
CONCEPT record of the Target Concept.</li>
|
||
<li>The fields valid_start_date, valid_end_date and invalid_reason are
|
||
used to define the life cycle of the mapping information. Invalid
|
||
mapping records should not be used for mapping information.</li>
|
||
</ul>
|
||
</div>
|
||
<div id="drug-strength" class="section level3">
|
||
<h3>Drug Strength</h3>
|
||
<ul>
|
||
<li>The DRUG_STRENGTH table contains information for each active
|
||
(non-deprecated) Standard Drug Concept.</li>
|
||
<li>A drug which contains multiple active Ingredients will result in
|
||
multiple DRUG_STRENGTH records, one for each active ingredient.</li>
|
||
<li>Ingredient strength information is provided either as absolute
|
||
amount (usually for solid formulations) or as concentration (usually for
|
||
liquid formulations).</li>
|
||
<li>If the absolute amount is provided (for example, ‘Acetaminophen 5 MG
|
||
Tablet’) the amount_value and amount_unit_concept_id are used to define
|
||
this content (in this case 5 and ‘MG’).</li>
|
||
<li>If the concentration is provided (for example ‘Acetaminophen 48
|
||
MG/ML Oral Solution’) the numerator_ value in combination with the
|
||
numerator_unit_concept_id and denominator_unit_concept_id are used to
|
||
define this content (in this case 48, ‘MG’ and ‘ML’).</li>
|
||
<li>In case of Quantified Clinical or Branded Drugs the
|
||
denominator_value contains the total amount of the solution (not the
|
||
amount of the ingredient). In all other drug concept classes the
|
||
denominator amount is NULL because the concentration is always
|
||
normalized to the unit of the denominator. So, a product containing 960
|
||
mg in 20 mL is provided as 48 mg/mL in the Clinical Drug and Clinical
|
||
Drug Component, while as a Quantified Clinical Drug it is written as 960
|
||
mg/20 mL.</li>
|
||
<li>If the strength is provided in % (volume or mass-percent are not
|
||
distinguished) it is stored in the
|
||
numerator_value/numerator_unit_concept_id field combination, with both
|
||
the denominator_value and denominator_unit_concept_id set to NULL. If it
|
||
is a Quantified Drug the total amount of drug is provided in the
|
||
denominator_value/denominator_unit_concept_id pair. E.g., the 30 G
|
||
Isoconazole 2% Topical Cream is provided as 2% / in Clinical Drug and
|
||
Clinical Drug Component, and as 2% /30 G.</li>
|
||
<li>Sometimes, one Ingredient is listed with different units within the
|
||
same drug. This is very rare, and usually this happens if there are more
|
||
than one Precise Ingredient. For example, ‘Penicillin G, 30 Benzathine
|
||
150000 UNT/ML / Penicillin G, Procaine 150000 MEQ/ML Injectable
|
||
Suspension’ contains Penicillin G in two different forms.</li>
|
||
<li>Sometimes, different ingredients in liquid drugs are listed with
|
||
different units in the denominator_ unit_concept_id. This is usually the
|
||
case if the ingredients are liquids themselves (concentration provided
|
||
as mL/mL) or solid substances (mg/mg). In these cases, the general
|
||
assumptions is made that the density of the drug is that of water, and
|
||
one can assume 1 g = 1 mL.</li>
|
||
<li>All Drug vocabularies containing Standard Concepts have entries in
|
||
the DRUG_STRENGTH table.</li>
|
||
<li>There is now a Concept Class for supplier information whose
|
||
relationships can be found in CONCEPT_ RELATIONSHIP with a
|
||
relationship_id of ‘Has supplier’ and ‘Supplier of’</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
<div id="mapping" class="section level2">
|
||
<h2><strong>Mapping</strong></h2>
|
||
<div id="representing-content-as-concepts" class="section level3">
|
||
<h3>Representing content as Concepts</h3>
|
||
<p>In CDM data tables the meaning of the content of each record is
|
||
represented using Concepts. Concepts are stored with their CONCEPT_ID as
|
||
foreign keys to the CONCEPT table in the Standardized Vocabularies,
|
||
which contains Concepts necessary to describe the healthcare experience
|
||
of a patient. If a Standard Concept does not exist or cannot be
|
||
identified, the Concept with the CONCEPT_ID 0 is used, representing a
|
||
non-existing or un-mappable concept.</p>
|
||
<p>Records in the CONCEPT table contain all the detailed information
|
||
about it (name, domain, class etc.). Concepts, Concept Relationships and
|
||
other information relating to Concepts is contained in the tables of the
|
||
Standardized Vocabularies.</p>
|
||
</div>
|
||
<div id="concept-ids-and-source-values" class="section level3">
|
||
<h3>Concept IDs and Source Values</h3>
|
||
<p>Many tables contain equivalent information multiple times: As a
|
||
Source Value, a Source Concept and as a Standard Concept.</p>
|
||
<ul>
|
||
<li>Source Values contain the codes from public code systems such as
|
||
ICD-9-CM, NDC, CPT-4 etc. or locally controlled vocabularies (such as F
|
||
for female and M for male) copied from the source data. Source Values
|
||
are stored in the *_SOURCE_VALUE fields in the data tables.</li>
|
||
<li>Concepts are CDM-specific entities that represent the meaning of a
|
||
clinical fact. Most concepts are based on code systems used in
|
||
healthcare (called Source Concepts), while others were created de-novo
|
||
(CONCEPT_CODE = ‘OMOP generated’). Concepts have unique IDs across all
|
||
domains.</li>
|
||
<li>Source Concepts are the concepts that represent the code used in the
|
||
source. Source Concepts are only used for common healthcare code
|
||
systems, not for OMOP-generated Concepts. Source Concepts are stored in
|
||
the *_SOURCE_CONCEPT_ID field in the data tables.</li>
|
||
<li>Standard Concepts are those concepts that are used to define the
|
||
unique meaning of a clinical entity. For each entity there is one
|
||
Standard Concept. Standard Concepts are typically drawn from existing
|
||
public vocabulary sources. Concepts that have the equivalent meaning to
|
||
a Standard Concept are mapped to the Standard Concept. Standard Concepts
|
||
are referred to in the <entity>_CONCEPT_ID field of the data
|
||
tables.</li>
|
||
</ul>
|
||
<p>Source Values are only provided for convenience and quality assurance
|
||
(QA) purposes. Source Values and Source Concepts are optional, while
|
||
Standard Concepts are mandatory. Source Values may contain information
|
||
that is only meaningful in the context of a specific data source.</p>
|
||
</div>
|
||
<div id="type-concepts" class="section level3">
|
||
<h3>Type Concepts</h3>
|
||
<p><em>By Mik Kallfelz and Dmitry Dymshyts</em></p>
|
||
<p>Type Concepts (ending in _TYPE_CONCEPT_ID) are present in many
|
||
tables. They are special Concepts with the purpose of indicating from
|
||
where the data are derived in the source. For example, the Type Concept
|
||
field can be used to distinguish a DRUG_EXPOSURE record that is derived
|
||
from a pharmacy-dispensing claim from one indicative of a prescription
|
||
written in an electronic health record (EHR).</p>
|
||
<ul>
|
||
<li>Type concepts help determining the provenance of a record in the
|
||
OMOP CDM. Many tables hold a specific _type_concept_id field for which
|
||
<a
|
||
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=">valid
|
||
concepts</a> can be used to indicate a particular source of that record.
|
||
For a condition it can be helpful to know, if it was derived from an EHR
|
||
system or insurance claims. For a drug exposure it should be very useful
|
||
to distinguish between prescriptions and actual administrations.</li>
|
||
<li>In respect to the target table, matching type concepts should be
|
||
chosen during the ETL step while processing sources. There are various
|
||
representations in the list of type concepts of which some are quite
|
||
specific for one table and others can be applied for many tables /
|
||
domains, as they are quite generic. There is however no plausibility
|
||
check or dependency between type concepts and tables which means they
|
||
have to be chosen correctly.</li>
|
||
<li>There is now one specific <a
|
||
href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary</a>
|
||
for type concepts which replaced a number of previously existing tables.
|
||
For example, where previously there was a dedicated vocabulary for Drug
|
||
Type Concepts, now we would choose the respective ones from the overall
|
||
vocabulary (and ignore some of the old ones):</li>
|
||
</ul>
|
||
<table>
|
||
<colgroup>
|
||
<col width="64%" />
|
||
<col width="35%" />
|
||
</colgroup>
|
||
<thead>
|
||
<tr class="header">
|
||
<th>Drug Type</th>
|
||
<th>Type Concept</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr class="odd">
|
||
<td>Inpatient administration</td>
|
||
<td>EHR administration record</td>
|
||
</tr>
|
||
<tr class="even">
|
||
<td>Physician administered drug (identified from EHR problem list)</td>
|
||
<td>EHR administration record</td>
|
||
</tr>
|
||
<tr class="odd">
|
||
<td>Physician administered drug (identified from referral record)</td>
|
||
<td>EHR administration record</td>
|
||
</tr>
|
||
<tr class="even">
|
||
<td>Physician administered drug (identified from EHR observation)</td>
|
||
<td>EHR administration record</td>
|
||
</tr>
|
||
<tr class="odd">
|
||
<td>Physician administered drug (identified from EHR order)</td>
|
||
<td>EHR administration record</td>
|
||
</tr>
|
||
<tr class="even">
|
||
<td>Prescription dispensed in pharmacy</td>
|
||
<td>EHR dispensing record</td>
|
||
</tr>
|
||
<tr class="odd">
|
||
<td>Dispensed in Outpatient office</td>
|
||
<td>EHR dispensing record</td>
|
||
</tr>
|
||
<tr class="even">
|
||
<td>Medication list entry</td>
|
||
<td>EHR medication list</td>
|
||
</tr>
|
||
<tr class="odd">
|
||
<td>Prescription written</td>
|
||
<td>EHR prescription</td>
|
||
</tr>
|
||
<tr class="even">
|
||
<td></td>
|
||
<td>EHR prescription issue record</td>
|
||
</tr>
|
||
<tr class="odd">
|
||
<td>Prescription dispensed through mail order</td>
|
||
<td>Mail order record</td>
|
||
</tr>
|
||
<tr class="even">
|
||
<td>NLP derived</td>
|
||
<td>NLP</td>
|
||
</tr>
|
||
<tr class="odd">
|
||
<td>Patient Self-Reported Medication</td>
|
||
<td>Patient self-report</td>
|
||
</tr>
|
||
<tr class="even">
|
||
<td>Physician administered drug (identified as procedure)</td>
|
||
<td>Pharmacy claim</td>
|
||
</tr>
|
||
<tr class="odd">
|
||
<td>Drug era - 0 days persistence window</td>
|
||
<td></td>
|
||
</tr>
|
||
<tr class="even">
|
||
<td>Drug era - 30 days persistence window</td>
|
||
<td></td>
|
||
</tr>
|
||
<tr class="odd">
|
||
<td>Randomized Drug</td>
|
||
<td></td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<div id="time-span-of-available-data" class="section level3">
|
||
<h3>Time span of available data</h3>
|
||
<p>Data tables for clinical data contain a datetime stamp (ending in
|
||
_DATETIME, _START_DATETIME or _END_DATETIME), indicating when that
|
||
clinical event occurred. As a rule, no record can be outside of a valid
|
||
OBSERVATION_PERIOD time period. Clinical information that relates to
|
||
events that happened prior to the first OBSERVATION_PERIOD will be
|
||
captured as a record in the OBSERVATION table as ‘Medical history’
|
||
(CONCEPT_ID = 43054928), with the OBSERVATION_DATETIME set to the first
|
||
OBSERVATION_PERIOD_START_DATE of that patient, and the
|
||
VALUE_AS_CONCEPT_ID set to the corresponding CONCEPT_ID for the
|
||
condition/drug/procedure that occurred in the past. No data occurring
|
||
after the last OBSERVATION_PERIOD_END_DATE can be valid records in the
|
||
CDM. * When mapping source data to the CDM, if time is unknown the
|
||
default time of 00:00:00 should be chosen.</p>
|
||
</div>
|
||
<div id="source-values-source-concept-ids-and-standard-concept-ids"
|
||
class="section level3">
|
||
<h3>Source Values, Source Concept Ids, and Standard Concept Ids</h3>
|
||
<p>Each table contains fields for Source Values, Source Concept Ids, and
|
||
Standard Concept Ids.</p>
|
||
<ul>
|
||
<li>Source Values are fields to maintain the verbatim information from
|
||
the source database, stored as unstructured text, and are generally not
|
||
to be used by any standardized analytics. There is no standardization
|
||
for these fields and these columns can be used as the local CDM builders
|
||
see fit. A typical example would be an ICD-9 code without the decimal
|
||
from an administrative claim as condition_source_value = ‘78702’ which
|
||
is how it appeared in the source.</li>
|
||
<li>Source Concept Ids provide a repeatable representation of the source
|
||
concept, when the source data are drawn from a commonly-used,
|
||
internationally-recognized vocabulary that has been distributed with the
|
||
OMOP Common Data Model. Specific use cases where source
|
||
vocabulary-specific analytics are required can be accommodated by the
|
||
use of the *_SOURCE_CONCEPT_ID fields, but these are generally not
|
||
applicable across disparate data sources. The standard *_CONCEPT_ID
|
||
fields are <strong>strongly suggested</strong> to be used in all
|
||
standardized analytics, as specific vocabularies have been established
|
||
within each data domain to facilitate standardization of both structure
|
||
and content within the OMOP Common Data Model.</li>
|
||
</ul>
|
||
<p>The following provide conventions for processing source data using
|
||
these three fields in each domain:</p>
|
||
<p>When processing data where the source value is either free text or a
|
||
reference to a coding scheme that is not contained within the
|
||
Standardized Vocabularies:</p>
|
||
<ul>
|
||
<li>Map all Source Values to the corresponding Standard CONCEPT_IDs.
|
||
Store the CONCEPT_IDs in the TARGET_CONCEPT_ID field of the
|
||
SOURCE_TO_CONCEPT_MAP table.
|
||
<ul>
|
||
<li>If a CONCEPT_ID is not available for the source code, the
|
||
TARGET_CONCEPT_ID field is set to 0.</li>
|
||
</ul></li>
|
||
</ul>
|
||
<p>When processing your data where Source Value is a reference to a
|
||
coding scheme contained within the Standardized Vocabularies:</p>
|
||
<ul>
|
||
<li>Find all CONCEPT_IDs in the Source Vocabulary that correspond to
|
||
your Source Values. Store the result in the SOURCE_CONCEPT_ID field.
|
||
<ul>
|
||
<li>If the source code follows the same formatting as the distributed
|
||
vocabulary, the mapping can be directly obtained from the CONCEPT table
|
||
using the CONCEPT_CODE field.</li>
|
||
<li>If the source code uses alternative formatting (ex. format has
|
||
removed decimal point from ICD-9 codes), you will need to perform the
|
||
formatting transformation within the ETL. In this case, you may wish to
|
||
store the mappings from original codes to SOURCE_CONCEPT_IDs in the
|
||
SOURCE_TO_CONCEPT_MAP table.</li>
|
||
<li>If the source code is not found in a vocabulary, the
|
||
SOURCE_CONCEPT_ID field is set to 0</li>
|
||
</ul></li>
|
||
<li>Use the CONCEPT_RELATIONSHIP table to identify the Standard
|
||
CONCEPT_ID that corresponds to the SOURCE_CONCEPT_ID in the domain.
|
||
<ul>
|
||
<li>Each SOURCE_CONCEPT_ID can have 1 or more Standard CONCEPT_IDs
|
||
mapped to it. Each Standard CONCEPT_ID belongs to only one primary
|
||
domain but when a source CONCEPT_ID maps to multiple Standard
|
||
CONCEPT_IDs, it is possible for that SOURCE_CONCEPT_ID to result in
|
||
records being produced across multiple domains. For example, ICD-10-CM
|
||
code Z34.00 ‘Encounter for supervision of normal first pregnancy,
|
||
unspecified trimester’ will be mapped to the SNOMED concept ‘Routine
|
||
antenatal care’ in the procedure domain and the concept in the condition
|
||
domain ‘Primagravida’. It is also possible for one SOURCE_CONCEPT_ID to
|
||
map to multiple Standard CONCEPT_IDs within the same domain. For
|
||
example, ICD-9-CM code 070.43 ‘Hepatitis E with hepatic coma’ maps to
|
||
the SNOMED concept for ‘Acute hepatitis E’ and a second SNOMED concept
|
||
for ‘Hepatic coma’, in which case multiple CONDITION_OCCURRENCE records
|
||
will be generated for the one source value record.</li>
|
||
<li>If the SOURCE_CONCEPT_ID is not mappable to any Standard CONCEPT_ID,
|
||
the <entity>_CONCEPT_ID field is set to 0.</li>
|
||
</ul></li>
|
||
<li>Write the data record into the table(s) corresponding to the domain
|
||
of the Standard CONCEPT_ID(s).
|
||
<ul>
|
||
<li>If the Source Value has a SOURCE_CONCEPT_ID but the
|
||
SOURCE_CONCEPT_ID is not mapped to a Standard CONCEPT_ID, then the
|
||
domain for the data record, and hence it’s table location, is determined
|
||
by the DOMAIN_ID field of the CONCEPT record the SOURCE_CONCEPT_ID
|
||
refers to. The Standard <entity>_CONCEPT_ID is set to 0.</li>
|
||
<li>If the Source Value cannot be mapped to a SOURCE_CONCEPT_ID or
|
||
Standard CONCEPT_ID, then direct the data record to the most appropriate
|
||
CDM domain based on your local knowledge of the intent of the source
|
||
data and associated value. For example, if the un-mappable Source Value
|
||
came from a ‘diagnosis’ table then, in the absence of other information,
|
||
you may choose to record that fact in the CONDITION_OCCURRENCE
|
||
table.</li>
|
||
</ul></li>
|
||
</ul>
|
||
<p>Each Standard CONCEPT_ID field has a set of allowable CONCEPT_ID
|
||
values. The allowable values are defined by the domain of the concepts.
|
||
For example, there is a domain concept of ‘Gender’, for which there are
|
||
only two allowable standard concepts of practical use (8507 - ‘Male’,
|
||
8532- ‘Female’) and one allowable generic concept to represent a
|
||
standard notion of ‘no information’ (concept_id = 0). This ‘no
|
||
information’ concept should be used when there is no mapping to a
|
||
standard concept available or if there is no information available for
|
||
that field. The exceptions are MEASUREMENT.VALUE_AS_CONCEPT_ID,
|
||
OBSERVATION.VALUE_AS_CONCEPT_ID, MEASUREMENT.UNIT_CONCEPT_ID,
|
||
OBSERVATION.UNIT_CONCEPT_ID, MEASUREMENT.OPERATOR_CONCEPT_ID, and
|
||
OBSERVATION.MODIFIER_CONCEPT_ID, which can be NULL if the data do not
|
||
contain the information (<a
|
||
href="https://github.com/OHDSI/Themis/issues/11">THEMIS issue
|
||
#11</a>).</p>
|
||
<p>There is no constraint on allowed CONCEPT_IDs within the
|
||
SOURCE_CONCEPT_ID fields.</p>
|
||
</div>
|
||
<div id="custom-source_to_concept_map" class="section level3">
|
||
<h3>Custom SOURCE_TO_CONCEPT_MAP</h3>
|
||
<p>When the source data uses coding systems that are not currently in
|
||
the Standardized Vocabularies (e.g. ICPC codes for diagnoses), the
|
||
convention is to store the mapping of such source codes to Standard
|
||
Concepts in the SOURCE_TO_CONCEPT_MAP table. The codes used in the data
|
||
source can be recorded in the SOURCE_VALUE fields, but no
|
||
SOURCE_CONCEPT_ID will be available.</p>
|
||
<p>Custom source codes are not allowed to map to Standard Concepts that
|
||
are marked as invalid.</p>
|
||
</div>
|
||
</div>
|
||
</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>
|