-
Notifications
You must be signed in to change notification settings - Fork 439
/
faq.html
985 lines (884 loc) · 36.4 KB
/
faq.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="generator" content="pandoc" />
<meta http-equiv="X-UA-Compatible" content="IE=EDGE" />
<title>OMOP CDM Frequently Asked Questions</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 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">OMOP CDM Frequently Asked Questions</h1>
</div>
<p><strong>1. I understand that the common data model (CDM) is a way of
organizing disparate data sources into the same relational database
design, but how can it be effective since many databases use different
coding schemes?</strong></p>
<p>During the extract, transform, load (ETL) process of converting a
data source into the OMOP common data model, we standardize the
structure (e.g. tables, fields, data types), conventions (e.g. rules
that govern how source data should be represented), and content
(e.g. what common vocabularies are used to speak the same language
across clinical domains). The common data model preserves all source
data, including the original source vocabulary codes, but adds the
standardized vocabularies to allow for network research across the
entire OHDSI research community.</p>
<p><strong>2. How does my data get transformed into the common data
model?</strong></p>
<p>You or someone in your organization will need to create a process to
build your CDM. Don’t worry though, you are not alone! The open nature
of the community means that much of the code that other participants
have written to transform their own data is available for you to use. If
you have a data license for a large administrative claims database like
IBM MarketScan® or Optum’s Clinformatics® Extended Data Mart, chances
are that someone has already done the legwork. Here is one example of a
full builder freely available on <a
href="https://github.com/OHDSI/ETL-CDMBuilder">github</a> that has been
written for a variety of data sources.</p>
<p>The <a href="http://forums.ohdsi.org/">community forums</a> are also
a great place to ask questions if you are stuck or need guidance on how
to represent your data in the common data model. Members are usually
very responsive!</p>
<p><strong>3. Are any tables or fields optional?</strong></p>
<p>It is expected that all tables will be present in a CDM though it is
not a requirement that they are all populated. The three mandatory
tables are:</p>
<ul>
<li><a
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#person">Person</a>:
Contains records that uniquely identify each patient in the source data
who is at-risk to have clinical observations recorded within the source
systems.</li>
<li><a
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#observation_period">Observation_period</a>:
Contains records which uniquely define the spans of time for which a
Person is at-risk to have clinical events recorded within the source
systems.</li>
<li><a
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#cdm_source">CDM_Source</a>:
Contains information on the CDM instance including the vocabulary
version used, the date the native data were released and the date the
CDM was released.</li>
</ul>
<p>It is then up to you which tables to populate, though the core event
tables are generally agreed upon to be <a
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#CONDITION_OCCURRENCE">Condition_occurrence</a>,
<a
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#PROCEDURE_OCCURRENCE">Procedure_occurrence</a>,
<a
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#DRUG_EXPOSURE">Drug_exposure</a>,
<a
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#MEASUREMENT">Measurement</a>,
and <a
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#OBSERVATION">Observation</a>.
Each table has certain required fields, a full list of which can be
found on the Common Data Model <a
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#">wiki
page</a>.</p>
<p><strong>4. Does the data model include any derived information? Which
tables or values are derived?</strong></p>
<p>The common data model stores verbatim data from the source across
various clinical domains, such as records for conditions, drugs,
procedures, and measurements. In addition, to assist the analyst, the
common data model also provides some derived tables, based on commonly
used analytic procedures. For example, the <a
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#CONDITION_ERA">Condition_era</a>
table is derived from the <a
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#CONDITION_OCCURENCE">Condition_occurrence</a>
table and both the <a
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#DRUG_ERA">Drug_era</a>
and <a
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#DOSE_ERA">Dose_era</a>
tables are derived from the <a
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#DRUG_EXPOSURE">Drug_exposure</a>
table. An era is defined as a span of time when a patient is assumed to
have a given condition or exposure to a particular active ingredient.
Members of the community have written code to create these tables and it
is out on the <a
href="https://github.com/OHDSI/CommonDataModel/tree/master/CodeExcerpts/DerivedTables">github</a>
if you choose to use it in your CDM build. It is important to reinforce,
the analyst has the opportunity, but not the obligation, to use any of
the derived tables and all of the source data is still available for
direct use if the analysis calls for different assumptions.</p>
<p><strong>5. How is age captured in the model?</strong></p>
<p>Year_of_birth, month_of_birth, day_of_birth and birth_datetime are
all fields in the Person table designed to capture some form of date of
birth. While only year_of_birth is required, these fields allow for
maximum flexibility over a wide range of data sources.</p>
<p><strong>6. How are gender, race, and ethnicity captured in the model?
Are they coded using values a human reader can understand?</strong></p>
<p>Standard Concepts are used to denote all clinical entities throughout
the OMOP common data model, including gender, race, and ethnicity.
Source values are mapped to Standard Concepts during the extract,
transform, load (ETL) process of converting a database to the OMOP
Common Data Model. These are then stored in the Gender_concept_id,
Race_concept_id and Ethnicity_concept_id fields in the Person table.
Because the standard concepts span across all clinical domains, and in
keeping with Cimino’s ‘Desiderata for Controlled Medical Vocabularies in
the Twenty-First Century’, the identifiers are unique, persistent
nonsematic identifiers. Gender, for example, is stored as either 8532
(female) or 8507 (male) in gender_concept_id while the original value
from the source is stored in gender_source_value (M, male, F, etc).</p>
<p><strong>7. Are there conditions/procedures/drugs or other domains
that should be masked or hidden in the CDM?</strong></p>
<p>The masking of information related to a person is dependent on the
organization’s privacy policies and may vary by data asset (<a
href="https://github.com/OHDSI/Themis/issues/21">THEMIS issue
#21</a>).</p>
<p><strong>8. How is time-varying patient information such as location
of residence addressed in the model?</strong></p>
<p>The OMOP common data model has been pragmatically defined based on
the desired analytic use cases of the community, as well as the
available types of data that community members have access to. Prior to
CDM v6.0, each person record had associated demographic attributes which
are assumed to be constant for the patient throughout the course of
their periods of observation, like location and primary care provider.
With the release of CDM v6.0, the Location_History table is now
available to track the movements of people, care sites, and providers
over time. Only the most recent location_id should be stored in the
Person table to eliminate duplication, while the person’s movements are
stored in Location_History.</p>
<p>Something like marital status is a little different as it is
considered to be an observation rather than a demographic attribute.
This means that it is housed in the Observation table rather than the
Person table, giving the opportunity to store each change in status as a
unique record.</p>
<p>If someone in the community had a use case for time-varying location
of residence and also had source data that contains this information,
we’d welcome participation in the CDM workgroup to evolve the model
further.</p>
<p><strong>9. How does the model denote the time period during which a
Person’s information is valid?</strong></p>
<p>The OMOP Common Data Model uses something called observation periods
(stored in the <a
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#observation_period">Observation_period</a>
table) as a way to define the time span during which a patient is
at-risk to have a clinical event recorded. In administrative claims
databases, for example, these observation periods are often analogous to
the notion of ‘enrollment’.</p>
<p><strong>10. How does the model capture start and stop dates for
insurance coverage? What if a person’s coverage changes?</strong></p>
<p>The <a
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#payer_plan_period">Payer_plan_period</a>
table captures details of the period of time that a Person is
continuously enrolled under a specific health Plan benefit structure
from a given Payer. Payer plan periods, as opposed to observation
periods, can overlap so as to denote the time when a Person is enrolled
in multiple plans at the same time such as Medicare Part A and Medicare
Part D.</p>
<p><strong>11. What if I have EHR data? How would I create observation
periods?</strong></p>
<p>An observation period is considered as the time at which a patient is
at-risk to have a clinical event recorded in the source system.
Determining the appropriate observation period for each source data can
vary, depending on what information the source contains. If a source
does not provide information about a patient’s entry or exit from a
system, then reasonable heuristics need to be developed and applied
within the ETL.</p>
<div id="vocabulary-mapping" class="section level2">
<h2>Vocabulary Mapping</h2>
<p><strong>12. Do I have to map my source codes to Standard Concepts
myself? Are there vocabulary mappings that already exist for me to
leverage?</strong></p>
<p>If your data use any of the 55 source vocabularies that are currently
supported, the mappings have been done for you. The full list is
available from the open-source <a
href="http://athena.ohdsi.org/search-terms/terms">ATHENA</a> tool under
the download tab (see below). You can choose to download the ten <a
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#Standardized-Vocabularies">vocabulary
tables</a> from there as well – you will need a copy in your environment
if you plan on building a CDM.</p>
<p><img src="images/Athena_download_box.png" /></p>
<p>The <a href="http://athena.ohdsi.org/search-terms/terms">ATHENA</a>
tool also allows you to explore the vocabulary before downloading it if
you are curious about the mappings or if you have a specific code in
mind and would like to know which standard concept it is associated
with; just click on the search tab and type in a keyword to begin
searching.</p>
<p><strong>13. If I want to apply the mappings myself, can I do so? Are
they transparent to all users?</strong></p>
<p>Yes, all mappings are available in the <a
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#CONCEPT_RELATIONSHIP">Concept_relationship</a>
table (which can be downloaded from <a
href="http://athena.ohdsi.org/search-terms/terms">ATHENA</a>). Each
value in a supported source terminology is assigned a Concept_id (which
is considered non-standard). Each Source_concept_id will have a mapping
to a Standard_concept_id. For example:</p>
<p><img src="images/Sepsis_to_SNOMED.png" /></p>
<p>In this case the standard SNOMED concept 201826 for type 2 diabetes
mellitus would be stored in the Condition_occurrence table as the
Condition_concept_id and the ICD10CM concept 1567956 for type 2 diabetes
mellitus would be stored as the Condition_source_concept_id.</p>
<p><strong>14. Can RXNorm codes be stored in the model? Can I store
multiple levels if I so choose? What if one collaborator uses a
different level of RXNorm than I use when transforming their
database?</strong></p>
<p>In the OMOP Common Data Model RXNorm is considered the standard
vocabulary for representing drug exposures. One of the great things
about the Standardized Vocabulary is that the hierarchical nature of
RXNorm is preserved to enable efficient querying. It is agreed upon best
practice to store the lowest level RXNorm available and then use the
Vocabulary to explore any pertinent relationships. Drug ingredients are
the highest-level ancestors so a query for the descendants of an
ingredient should turn up all drug products (Clinical Drug or Branded
Drug) containing that ingredient. A query designed in this way will find
drugs of interest in any CDM regardless of the level of RXNorm used.</p>
<p><strong>15. What if the vocabulary has a mapping I don’t agree with?
Can it be changed?</strong></p>
<p>Yes, that is the beauty of the community! If you find a mapping in
the vocabulary that doesn’t seem to belong or that you think could be
better, feel free to write a note on the <a
href="https://forums.ohdsi.org/">forums</a> or on the <a
href="https://github.com/OHDSI/Vocabulary-v5.0/issues">vocabulary
github</a>. If the community agrees with your assessment it will be
addressed in the next vocabulary version.</p>
<p><strong>16. What if I have source codes that are specific to my site?
How would these be mapped?</strong></p>
<p>In the OMOP Vocabulary there is an empty table called the
Source_to_concept_map. It is a simple table structure that allows you to
establish mapping(s) for each source code with a standard concept in the
OMOP Vocabulary (TARGET_CONCEPT_ID). This work can be facilitated by the
OHDSI tool <a href="https://github.com/OHDSI/Usagi">Usagi</a> (pictured
below) which searches for text similarity between your source code
descriptions and the OMOP Vocabulary and exports mappings in a
SOURCE_TO_CONCEPT_MAP table structure. Example Source_to_concept_map
files can be found <a
href="https://github.com/OHDSI/ETL-CDMBuilder/tree/master/man/VOCABULARY_ADDITIONS">here</a>.
These generated Source_to_concept_map files are then loaded into the
OMOP Vocabulary’s empty Source_to_concept_map prior to processing the
native data into the CDM so that the CDM builder can use them in a
build.</p>
<p><img src="images/Usagi.png" /></p>
<p>If an source code is not supported by the OMOP Vocabulary, one can
create a new records in the CONCEPT table, however the CONCEPT_IDs
should start >2000000000 so that it is easy to tell between the OMOP
Vocabulary concepts and the site specific concepts. Once those concepts
exist CONCEPT_RELATIONSHIPS can be generated to assign them to a
standard terminologies, USAGI can facilitate this process as well (<a
href="https://github.com/OHDSI/Themis/issues/22">THEMIS issue
#22</a>).</p>
<p><strong>17. How are one-to-many mappings applied?</strong></p>
<p>If one source code maps to two Standard Concepts then two rows are
stored in the corresponding clinical event table.</p>
<p><strong>18. What if I want to keep my original data as well as the
mapped values? Is there a way for me to do that?</strong></p>
<p>Yes! Source values and Source Concepts are fully maintained within
the OMOP Common Data Model. A Source Concept represents the code in the
source data. Each Source Concept is mapped to one or more Standard
Concepts during the ETL process and both are stored in the corresponding
clinical event table. If no mapping is available, the Standard Concept
with the concept_id = 0 is written into the *_concept_id field
(Condition_concept_id, Procedure_concept_id, etc.) so as to preserve the
record from the native data.</p>
</div>
<div id="common-data-model-versioning" class="section level2">
<h2>Common Data Model Versioning</h2>
<p><strong>19. Who decides when and how to change the data
model?</strong></p>
<p>The community! There is a <a
href="https://docs.google.com/document/d/144e_fc7dyuinfJfbYW5MsJeSijVSzsNE7GMY6KRX10g/edit?usp=sharing">working
group</a> designed around updating the model and everything is done by
consensus. Members submit proposed changes to the <a
href="https://github.com/OHDSI/CommonDataModel">github</a> in the form
of <a href="https://github.com/OHDSI/CommonDataModel/issues">issues</a>
and the group meets once a month to discuss and vote on the changes. Any
ratified proposals are then added to the queue for a future version of
the Common Data Model.</p>
<p><strong>20. Are changes to the model backwards
compatible?</strong></p>
<p>Generally point version changes (5.1 -> 5.2) are backwards
compatible and major version changes (4.0 -> 5.0) may not be. All
updates to the model are listed in the release notes for each version
and anything that could potentially affect backwards compatibility is
clearly labeled.</p>
<p><strong>21. How frequently does the model change?</strong></p>
<p>The current schedule is for major versions to be released every year
and point versions to be release every quarter though that is subject to
the needs of the community.</p>
<p><strong>22. What is the dissemination plan for changes?</strong></p>
<p>Changes are first listed in the release notes on the <a
href="https://github.com/OHDSI/CommonDataModel/">github</a> and in the
<a href="https://github.com/OHDSI/CommonDataModel/wiki">common data
model wiki</a>. New versions are also announced on the weekly community
calls and on the <a href="https://forums.ohdsi.org">community
forums</a>.</p>
</div>
<div id="ohdsi-tools" class="section level2">
<h2>OHDSI Tools</h2>
<p><strong>23. What are the currently available analytic
tools?</strong></p>
<p>While there are a variety of tools freely available from the
community, these are the most widely used:</p>
<ul>
<li><a href="http://www.github.com/ohdsi/achilles">ACHILLES</a> – a
stand-alone tool for database characterization</li>
<li><a href="http://www.ohdsi.org/web/atlas/#/home">ATLAS</a> - an
integrated platform for vocabulary exploration, cohort definition, case
review, clinical characterization, incidence estimation,
population-level effect estimation design, and patient-level prediction
design (<a href="http://www.github.com/ohdsi/atlas">link to
github</a>)</li>
<li><a href="https://github.com/OHDSI/ArachneUI">ARACHNE</a> – a tool to
facilitate distributed network analyses</li>
<li><a href="https://github.com/OHDSI/whiterabbit">WhiteRabbit</a> - an
application that can be used to analyse the structure and contents of a
database as preparation for designing an ETL</li>
<li><a href="https://github.com/OHDSI/whiterabbit">RabbitInAHat</a> - an
application for interactive design of an ETL to the OMOP Common Data
Model with the help of the the scan report generated by White
Rabbit</li>
<li><a href="https://github.com/OHDSI/usagi">Usagi</a> - an application
to help create mappings between coding systems and the Vocabulary
standard concepts.</li>
</ul>
<p><strong>24. Who is responsible for updating the tools to account for
data model changes, bugs, and errors?</strong></p>
<p>The community! All the tools are open source meaning that anyone can
submit an issue they have found, offer suggestions, and write code to
fix the problem.</p>
<p><strong>25. Do the current tools allow a user to define a treatment
gap (persistence window) of any value when creating treatment
episodes?</strong></p>
<p>Yes – the ATLAS tool allows you to specify a persistence window
between drug exposures when defining a cohort (see image below).</p>
<p><img src="images/ATLAS_Persistence_Window.png" /></p>
<p><strong>26. Can the current tools identify medication use during
pregnancy?</strong></p>
<p>Yes, you can identify pregnancy markers from various clinical
domains, including conditions and procedures, for example ‘live birth’,
and then define temporal logic to look for drug exposure records in some
interval prior to the pregnancy end. In addition, members of the
community have built an advanced logic to define pregnancy episodes with
all pregnancy outcomes represented, which can be useful for this type of
research.</p>
<p><strong>27. Do the current tools execute against the mapped values or
source values?</strong></p>
<p>The tools can execute against both source and mapped values, though
mapped values are strongly encouraged. Since one of the aims of OHDSI is
to create a distributed data network across the world on which to run
research studies, the use of source values fails to take advantage of
the benefits of the Common Data Model.</p>
</div>
<div id="network-research-studies" class="section level2">
<h2>Network Research Studies</h2>
<p><strong>28. Who can generate requests?</strong></p>
<p>Anyone in the community! Any question that gains enough interest and
participation can be a network research study.</p>
<p><strong>29. Who will develop the queries to distribute to the
network?</strong></p>
<p>Typically a principal investigator leads the development of a
protocol. The PI may also lead the development of the analysis procedure
corresponding to the protocol. If the PI does not have the technical
skills required to write the analysis procedure that implements the
protocol, someone in the community can help them put it together.</p>
<p><strong>30. What language are the queries written in?</strong></p>
<p>Queries are written in R and SQL. The <a
href="https://github.com/OHDSI/sqlrender">SqlRender</a> package can
translate any query written in a templated SQL Server-like dialect to
any of the supported RDBMS environments, including Postgresql, Oracle,
Redshift, Parallel Data Warehouse, Hadoop Impala, Google BigQuery, and
Netezza.</p>
<p><strong>31. How do the queries get to the data partners and how are
they run once there?</strong></p>
<p>OHDSI runs as a distributed data network. All analyses are publicly
available and can be downloaded to run at each site. The packages can be
run locally and, at the data partner’s discretion, aggregate results can
be shared with the study coordinator.</p>
<p>Data partners can also make use of one of OHDSI’s open-source tools
called <a href="https://github.com/OHDSI/arachne">ARACHNE</a>, a tool to
facilitate distributed network analytics against the OMOP CDM.</p>
</div>
<div id="recommended-system-requirements" class="section level2">
<h2>Recommended System Requirements</h2>
<p>It is difficult to recommend what technical capabilities a site needs
to set up an ETL because it is heavily dependent on the amount of data
they have and how they plan to use it. Here are some examples of options
that have worked well for small to medium organizations and large
organizations:</p>
<p><strong>Small-to-Medium Organization</strong></p>
<ul>
<li>CDM size is 100MB to several GBs</li>
<li>Vocab ~20GB</li>
<li>Results < 500 MB</li>
<li>Recommend
<ul>
<li>Server class machine disk >= 250GB (SSD preferred), >= 4
cores, >= 32GB RAM</li>
</ul></li>
</ul>
<p><strong>Large Organization</strong></p>
<ul>
<li>CDM size is 12GB to several TBs</li>
<li>Vocab ~20GB</li>
<li>Results < 500 MB</li>
<li>Recommend
<ul>
<li>Cloud-based infrastructure like multiple AWS Redshift clusters, for
example:</li>
<li><img src="images/AWS_clusters.png" /></li>
</ul></li>
</ul>
</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,h4,h5",
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>