2108 lines
1.9 MiB
HTML
2108 lines
1.9 MiB
HTML
|
<!DOCTYPE html>
|
|||
|
|
|
|||
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|||
|
|
|
|||
|
|
<head>
|
|||
|
|
|
|||
|
|
<meta charset="utf-8" />
|
|||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|||
|
|
<meta name="generator" content="pandoc" />
|
|||
|
|
|
|||
|
|
|
|||
|
|
<meta name="author" content="Christian Reich, Patrick Ryan, Rimma Belenkaya, Karthik Natarajan and Clair Blacketer" />
|
|||
|
|
|
|||
|
|
<meta name="date" content="2019-02-06" />
|
|||
|
|
|
|||
|
|
<title>OMOP Common Data Model Specifications</title>
|
|||
|
|
|
|||
|
|
<script src="data:application/x-javascript;base64,LyohIGpRdWVyeSB2MS4xMS4zIHwgKGMpIDIwMDUsIDIwMTUgalF1ZXJ5IEZvdW5kYXRpb24sIEluYy4gfCBqcXVlcnkub3JnL2xpY2Vuc2UgKi8KIWZ1bmN0aW9uKGEsYil7Im9iamVjdCI9PXR5cGVvZiBtb2R1bGUmJiJvYmplY3QiPT10eXBlb2YgbW9kdWxlLmV4cG9ydHM/bW9kdWxlLmV4cG9ydHM9YS5kb2N1bWVudD9iKGEsITApOmZ1bmN0aW9uKGEpe2lmKCFhLmRvY3VtZW50KXRocm93IG5ldyBFcnJvcigialF1ZXJ5IHJlcXVpcmVzIGEgd2luZG93IHdpdGggYSBkb2N1bWVudCIpO3JldHVybiBiKGEpfTpiKGEpfSgidW5kZWZpbmVkIiE9dHlwZW9mIHdpbmRvdz93aW5kb3c6dGhpcyxmdW5jdGlvbihhLGIpe3ZhciBjPVtdLGQ9Yy5zbGljZSxlPWMuY29uY2F0LGY9Yy5wdXNoLGc9Yy5pbmRleE9mLGg9e30saT1oLnRvU3RyaW5nLGo9aC5oYXNPd25Qcm9wZXJ0eSxrPXt9LGw9IjEuMTEuMyIsbT1mdW5jdGlvbihhLGIpe3JldHVybiBuZXcgbS5mbi5pbml0KGEsYil9LG49L15bXHNcdUZFRkZceEEwXSt8W1xzXHVGRUZGXHhBMF0rJC9nLG89L14tbXMtLyxwPS8tKFtcZGEtel0pL2dpLHE9ZnVuY3Rpb24oYSxiKXtyZXR1cm4gYi50b1VwcGVyQ2FzZSgpfTttLmZuPW0ucHJvdG90eXBlPXtqcXVlcnk6bCxjb25zdHJ1Y3RvcjptLHNlbGVjdG9yOiIiLGxlbmd0aDowLHRvQXJyYXk6ZnVuY3Rpb24oKXtyZXR1cm4gZC5jYWxsKHRoaXMpfSxnZXQ6ZnVuY3Rpb24oYSl7cmV0dXJuIG51bGwhPWE/MD5hP3RoaXNbYSt0aGlzLmxlbmd0aF06dGhpc1thXTpkLmNhbGwodGhpcyl9LHB1c2hTdGFjazpmdW5jdGlvbihhKXt2YXIgYj1tLm1lcmdlKHRoaXMuY29uc3RydWN0b3IoKSxhKTtyZXR1cm4gYi5wcmV2T2JqZWN0PXRoaXMsYi5jb250ZXh0PXRoaXMuY29udGV4dCxifSxlYWNoOmZ1bmN0aW9uKGEsYil7cmV0dXJuIG0uZWFjaCh0aGlzLGEsYil9LG1hcDpmdW5jdGlvbihhKXtyZXR1cm4gdGhpcy5wdXNoU3RhY2sobS5tYXAodGhpcyxmdW5jdGlvbihiLGMpe3JldHVybiBhLmNhbGwoYixjLGIpfSkpfSxzbGljZTpmdW5jdGlvbigpe3JldHVybiB0aGlzLnB1c2hTdGFjayhkLmFwcGx5KHRoaXMsYXJndW1lbnRzKSl9LGZpcnN0OmZ1bmN0aW9uKCl7cmV0dXJuIHRoaXMuZXEoMCl9LGxhc3Q6ZnVuY3Rpb24oKXtyZXR1cm4gdGhpcy5lcSgtMSl9LGVxOmZ1bmN0aW9uKGEpe3ZhciBiPXRoaXMubGVuZ3RoLGM9K2ErKDA+YT9iOjApO3JldHVybiB0aGlzLnB1c2hTdGFjayhjPj0wJiZiPmM/W3RoaXNbY11dOltdKX0sZW5kOmZ1bmN0aW9uKCl7cmV0dXJuIHRoaXMucHJldk9iamVjdHx8dGhpcy5jb25zdHJ1Y3RvcihudWxsKX0scHVzaDpmLHNvcnQ6Yy5zb3J0LHNwbGljZTpjLnNwbGljZX0sbS5leHRlbmQ9bS5mbi5leHRlbmQ9ZnVuY3Rpb24oKXt2YXIgYSxiLGMsZCxlLGYsZz1hcmd1bWVudHNbMF18fHt9LGg9MSxpPWFyZ3VtZW50cy5sZW5ndGgsaj0hMTtmb3IoImJvb2xlYW4iPT10eXBlb2YgZyYmKGo9ZyxnPWFyZ3VtZW50c1toXXx8e30saCsrKSwib2JqZWN0Ij09dHlwZW9mIGd8fG0uaXNGdW5jdGlvbihnKXx8KGc9e30pLGg9PT1pJiYoZz10aGlzLGgtLSk7aT5oO2grKylpZihudWxsIT0oZT1hcmd1bWVudHNbaF0pKWZvcihkIGluIGUpYT1nW2RdLGM9ZVtkXSxnIT09YyYmKGomJmMmJihtLmlzUGxhaW5PYmplY3QoYyl8fChiPW0uaXNBcnJheShjKSkpPyhiPyhiPSExLGY9YSYmbS5pc0FycmF5KGEpP2E6W10pOmY9YSYmbS5pc1BsYWluT2JqZWN0KGEpP2E6e30sZ1tkXT1tLmV4dGVuZChqLGYsYykpOnZvaWQgMCE9PWMmJihnW2RdPWMpKTtyZXR1cm4gZ30sbS5leHRlbmQoe2V4cGFuZG86ImpRdWVyeSIrKGwrTWF0aC5yYW5kb20oKSkucmVwbGFjZSgvXEQvZywiIiksaXNSZWFkeTohMCxlcnJvcjpmdW5jdGlvbihhKXt0aHJvdyBuZXcgRXJyb3IoYSl9LG5vb3A6ZnVuY3Rpb24oKXt9LGlzRnVuY3Rpb246ZnVuY3Rpb24oYSl7cmV0dXJuImZ1bmN0aW9uIj09PW0udHlwZShhKX0saXNBcnJheTpBcnJheS5pc0FycmF5fHxmdW5jdGlvbihhKXtyZXR1cm4iYXJyYXkiPT09bS50eXBlKGEpfSxpc1dpbmRvdzpmdW5jdGlvbihhKXtyZXR1cm4gbnVsbCE9YSYmYT09YS53aW5kb3d9LGlzTnVtZXJpYzpmdW5jdGlvbihhKXtyZXR1cm4hbS5pc0FycmF5KGEpJiZhLXBhcnNlRmxvYXQoYSkrMT49MH0saXNFbXB0eU9iamVjdDpmdW5jdGlvbihhKXt2YXIgYjtmb3IoYiBpbiBhKXJldHVybiExO3JldHVybiEwfSxpc1BsYWluT2JqZWN0OmZ1bmN0aW9uKGEpe3ZhciBiO2lmKCFhfHwib2JqZWN0IiE9PW0udHlwZShhKXx8YS5ub2RlVHlwZXx8bS5pc1dpbmRvdyhhKSlyZXR1cm4hMTt0cnl7aWYoYS5jb25zdHJ1Y3RvciYmIWouY2FsbChhLCJjb25zdHJ1Y3RvciIpJiYhai5jYWxsKGEuY29uc3RydWN0b3IucHJvdG90eXBlLCJpc1Byb3RvdHlwZU9mIikpcmV0dXJuITF9Y2F0Y2goYyl7cmV0dXJuITF9aWYoay5vd25MYXN0KWZvcihiIGluIGEpcmV0dXJuIGouY2FsbChhLGIpO2ZvcihiIGluIGEpO3JldHVybiB2b2lkIDA9PT1ifHxqLmNhbGwoYSxiKX0sdHlwZTpmdW5jdGlvbihhKXtyZXR1cm4gbnVsbD09YT9hKyIiOiJvYmplY3QiPT10eXBlb2YgYXx8ImZ1bmN0aW9uIj09dHlwZW9mIGE/aFtpLmNhbGwoYSldfHwib2JqZWN0Ijp0eXBlb2YgYX0sZ2xvYmFsRXZhbDpmdW5jdGlvbihiKXtiJiZtLnRyaW0oYikmJihhLmV4ZWNTY3JpcHR8fGZ1bmN0aW9uKGIpe2EuZXZhbC5jYWxsKGEsYil9KShiKX0sY2FtZWxDYXNlOmZ1bmN0aW9uKGEpe3JldHVybiBhLnJlcGxhY2UobywibXMtIikucmVwbGFjZShwLHEpfSxub2RlTmFtZTpmdW5jdGlvbihhLGIpe3JldHVybiBhLm5vZGVOYW1lJiZhLm5vZGVOYW1lLnRvTG93ZXJDYXNlKCk9PT1iLnRvTG93ZXJDYXNlKCl9LGVhY2g6ZnVuY3Rpb24oYSxiLGMpe3ZhciBkLGU9MCxmPWEubGVuZ3RoLGc9cihhKTtpZihjKXtpZihnKXtmb3IoO2Y+ZTtlKyspaWYoZD1iLmFwcGx5KGFbZV0sYyksZD09PSExKWJyZWFrfWVsc2UgZm9yKGUgaW4gYSlpZihkPWIuYXBwbHkoYVtlXSxjKSxkPT09ITEpYnJlYWt9ZWxzZSBpZ
|
|||
|
|
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
|||
|
|
<link href="data:text/css;charset=utf-8,html%7Bfont%2Dfamily%3Asans%2Dserif%3B%2Dwebkit%2Dtext%2Dsize%2Dadjust%3A100%25%3B%2Dms%2Dtext%2Dsize%2Dadjust%3A100%25%7Dbody%7Bmargin%3A0%7Darticle%2Caside%2Cdetails%2Cfigcaption%2Cfigure%2Cfooter%2Cheader%2Chgroup%2Cmain%2Cmenu%2Cnav%2Csection%2Csummary%7Bdisplay%3Ablock%7Daudio%2Ccanvas%2Cprogress%2Cvideo%7Bdisplay%3Ainline%2Dblock%3Bvertical%2Dalign%3Abaseline%7Daudio%3Anot%28%5Bcontrols%5D%29%7Bdisplay%3Anone%3Bheight%3A0%7D%5Bhidden%5D%2Ctemplate%7Bdisplay%3Anone%7Da%7Bbackground%2Dcolor%3Atransparent%7Da%3Aactive%2Ca%3Ahover%7Boutline%3A0%7Dabbr%5Btitle%5D%7Bborder%2Dbottom%3A1px%20dotted%7Db%2Cstrong%7Bfont%2Dweight%3A700%7Ddfn%7Bfont%2Dstyle%3Aitalic%7Dh1%7Bmargin%3A%2E67em%200%3Bfont%2Dsize%3A2em%7Dmark%7Bcolor%3A%23000%3Bbackground%3A%23ff0%7Dsmall%7Bfont%2Dsize%3A80%25%7Dsub%2Csup%7Bposition%3Arelative%3Bfont%2Dsize%3A75%25%3Bline%2Dheight%3A0%3Bvertical%2Dalign%3Abaseline%7Dsup%7Btop%3A%2D%2E5em%7Dsub%7Bbottom%3A%2D%2E25em%7Dimg%7Bborder%3A0%7Dsvg%3Anot%28%3Aroot%29%7Boverflow%3Ahidden%7Dfigure%7Bmargin%3A1em%2040px%7Dhr%7Bheight%3A0%3B%2Dwebkit%2Dbox%2Dsizing%3Acontent%2Dbox%3B%2Dmoz%2Dbox%2Dsizing%3Acontent%2Dbox%3Bbox%2Dsizing%3Acontent%2Dbox%7Dpre%7Boverflow%3Aauto%7Dcode%2Ckbd%2Cpre%2Csamp%7Bfont%2Dfamily%3Amonospace%2Cmonospace%3Bfont%2Dsize%3A1em%7Dbutton%2Cinput%2Coptgroup%2Cselect%2Ctextarea%7Bmargin%3A0%3Bfont%3Ainherit%3Bcolor%3Ainherit%7Dbutton%7Boverflow%3Avisible%7Dbutton%2Cselect%7Btext%2Dtransform%3Anone%7Dbutton%2Chtml%20input%5Btype%3Dbutton%5D%2Cinput%5Btype%3Dreset%5D%2Cinput%5Btype%3Dsubmit%5D%7B%2Dwebkit%2Dappearance%3Abutton%3Bcursor%3Apointer%7Dbutton%5Bdisabled%5D%2Chtml%20input%5Bdisabled%5D%7Bcursor%3Adefault%7Dbutton%3A%3A%2Dmoz%2Dfocus%2Dinner%2Cinput%3A%3A%2Dmoz%2Dfocus%2Dinner%7Bpadding%3A0%3Bborder%3A0%7Dinput%7Bline%2Dheight%3Anormal%7Dinput%5Btype%3Dcheckbox%5D%2Cinput%5Btype%3Dradio%5D%7B%2Dwebkit%2Dbox%2Dsizing%3Aborder%2Dbox%3B%2Dmoz%2Dbox%2Dsizing%3Aborder%2Dbox%3Bbox%2Dsizing%3Aborder%2Dbox%3Bpadding%3A0%7Dinput%5Btype%3Dnumber%5D%3A%3A%2Dwebkit%2Dinner%2Dspin%2Dbutton%2Cinput%5Btype%3Dnumber%5D%3A%3A%2Dwebkit%2Douter%2Dspin%2Dbutton%7Bheight%3Aauto%7Dinput%5Btype%3Dsearch%5D%7B%2Dwebkit%2Dbox%2Dsizing%3Acontent%2Dbox%3B%2Dmoz%2Dbox%2Dsizing%3Acontent%2Dbox%3Bbox%2Dsizing%3Acontent%2Dbox%3B%2Dwebkit%2Dappearance%3Atextfield%7Dinput%5Btype%3Dsearch%5D%3A%3A%2Dwebkit%2Dsearch%2Dcancel%2Dbutton%2Cinput%5Btype%3Dsearch%5D%3A%3A%2Dwebkit%2Dsearch%2Ddecoration%7B%2Dwebkit%2Dappearance%3Anone%7Dfieldset%7Bpadding%3A%2E35em%20%2E625em%20%2E75em%3Bmargin%3A0%202px%3Bborder%3A1px%20solid%20silver%7Dlegend%7Bpadding%3A0%3Bborder%3A0%7Dtextarea%7Boverflow%3Aauto%7Doptgroup%7Bfont%2Dweight%3A700%7Dtable%7Bborder%2Dspacing%3A0%3Bborder%2Dcollapse%3Acollapse%7Dtd%2Cth%7Bpadding%3A0%7D%40media%20print%7B%2A%2C%3Aafter%2C%3Abefore%7Bcolor%3A%23000%21important%3Btext%2Dshadow%3Anone%21important%3Bbackground%3A0%200%21important%3B%2Dwebkit%2Dbox%2Dshadow%3Anone%21important%3Bbox%2Dshadow%3Anone%21important%7Da%2Ca%3Avisited%7Btext%2Ddecoration%3Aunderline%7Da%5Bhref%5D%3Aafter%7Bcontent%3A%22%20%28%22%20attr%28href%29%20%22%29%22%7Dabbr%5Btitle%5D%3Aafter%7Bcontent%3A%22%20%28%22%20attr%28title%29%20%22%29%22%7Da%5Bhref%5E%3D%22javascript%3A%22%5D%3Aafter%2Ca%5Bhref%5E%3D%22%23%22%5D%3Aafter%7Bcontent%3A%22%22%7Dblockquote%2Cpre%7Bborder%3A1px%20solid%20%23999%3Bpage%2Dbreak%2Dinside%3Aavoid%7Dthead%7Bdisplay%3Atable%2Dheader%2Dgroup%7Dimg%2Ctr%7Bpage%2Dbreak%2Dinside%3Aavoid%7Dimg%7Bmax%2Dwidth%3A100%25%21important%7Dh2%2Ch3%2Cp%7Borphans%3A3%3Bwidows%3A3%7Dh2%2Ch3%7Bpage%2Dbreak%2Dafter%3Aavoid%7D%2Enavbar%7Bdisplay%3Anone%7D%2Ebtn%3E%2Ecaret%2C%2Edropup%3E%2Ebtn%3E%2Ecaret%7Bborder%2Dtop%2Dcolor%3A%23000%21important%7D%2Elabel%7Bborder%3A1px%20solid%20%23000%7D%2Etable%7Bborder%2Dcollapse%3Acollapse%21important%7D%2Etable%20td%2C%2Etable%20th%7Bbackground%2Dcolor%3A%23fff%21important%7D%2Etable%2Dbordered%20td%2C%2Etable%2Dbordered%20th%7Bborder%3A1px%20solid%20%23ddd%21important%7D%7D%40font%2Dface%7Bfont%2Dfamily%3A%27Glyphicons%20Halflings%2
|
|||
|
|
<script src="data:application/x-javascript;base64,LyohCiAqIEJvb3RzdHJhcCB2My4zLjUgKGh0dHA6Ly9nZXRib290c3RyYXAuY29tKQogKiBDb3B5cmlnaHQgMjAxMS0yMDE1IFR3aXR0ZXIsIEluYy4KICogTGljZW5zZWQgdW5kZXIgdGhlIE1JVCBsaWNlbnNlCiAqLwppZigidW5kZWZpbmVkIj09dHlwZW9mIGpRdWVyeSl0aHJvdyBuZXcgRXJyb3IoIkJvb3RzdHJhcCdzIEphdmFTY3JpcHQgcmVxdWlyZXMgalF1ZXJ5Iik7K2Z1bmN0aW9uKGEpeyJ1c2Ugc3RyaWN0Ijt2YXIgYj1hLmZuLmpxdWVyeS5zcGxpdCgiICIpWzBdLnNwbGl0KCIuIik7aWYoYlswXTwyJiZiWzFdPDl8fDE9PWJbMF0mJjk9PWJbMV0mJmJbMl08MSl0aHJvdyBuZXcgRXJyb3IoIkJvb3RzdHJhcCdzIEphdmFTY3JpcHQgcmVxdWlyZXMgalF1ZXJ5IHZlcnNpb24gMS45LjEgb3IgaGlnaGVyIil9KGpRdWVyeSksK2Z1bmN0aW9uKGEpeyJ1c2Ugc3RyaWN0IjtmdW5jdGlvbiBiKCl7dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgiYm9vdHN0cmFwIiksYj17V2Via2l0VHJhbnNpdGlvbjoid2Via2l0VHJhbnNpdGlvbkVuZCIsTW96VHJhbnNpdGlvbjoidHJhbnNpdGlvbmVuZCIsT1RyYW5zaXRpb246Im9UcmFuc2l0aW9uRW5kIG90cmFuc2l0aW9uZW5kIix0cmFuc2l0aW9uOiJ0cmFuc2l0aW9uZW5kIn07Zm9yKHZhciBjIGluIGIpaWYodm9pZCAwIT09YS5zdHlsZVtjXSlyZXR1cm57ZW5kOmJbY119O3JldHVybiExfWEuZm4uZW11bGF0ZVRyYW5zaXRpb25FbmQ9ZnVuY3Rpb24oYil7dmFyIGM9ITEsZD10aGlzO2EodGhpcykub25lKCJic1RyYW5zaXRpb25FbmQiLGZ1bmN0aW9uKCl7Yz0hMH0pO3ZhciBlPWZ1bmN0aW9uKCl7Y3x8YShkKS50cmlnZ2VyKGEuc3VwcG9ydC50cmFuc2l0aW9uLmVuZCl9O3JldHVybiBzZXRUaW1lb3V0KGUsYiksdGhpc30sYShmdW5jdGlvbigpe2Euc3VwcG9ydC50cmFuc2l0aW9uPWIoKSxhLnN1cHBvcnQudHJhbnNpdGlvbiYmKGEuZXZlbnQuc3BlY2lhbC5ic1RyYW5zaXRpb25FbmQ9e2JpbmRUeXBlOmEuc3VwcG9ydC50cmFuc2l0aW9uLmVuZCxkZWxlZ2F0ZVR5cGU6YS5zdXBwb3J0LnRyYW5zaXRpb24uZW5kLGhhbmRsZTpmdW5jdGlvbihiKXtyZXR1cm4gYShiLnRhcmdldCkuaXModGhpcyk/Yi5oYW5kbGVPYmouaGFuZGxlci5hcHBseSh0aGlzLGFyZ3VtZW50cyk6dm9pZCAwfX0pfSl9KGpRdWVyeSksK2Z1bmN0aW9uKGEpeyJ1c2Ugc3RyaWN0IjtmdW5jdGlvbiBiKGIpe3JldHVybiB0aGlzLmVhY2goZnVuY3Rpb24oKXt2YXIgYz1hKHRoaXMpLGU9Yy5kYXRhKCJicy5hbGVydCIpO2V8fGMuZGF0YSgiYnMuYWxlcnQiLGU9bmV3IGQodGhpcykpLCJzdHJpbmciPT10eXBlb2YgYiYmZVtiXS5jYWxsKGMpfSl9dmFyIGM9J1tkYXRhLWRpc21pc3M9ImFsZXJ0Il0nLGQ9ZnVuY3Rpb24oYil7YShiKS5vbigiY2xpY2siLGMsdGhpcy5jbG9zZSl9O2QuVkVSU0lPTj0iMy4zLjUiLGQuVFJBTlNJVElPTl9EVVJBVElPTj0xNTAsZC5wcm90b3R5cGUuY2xvc2U9ZnVuY3Rpb24oYil7ZnVuY3Rpb24gYygpe2cuZGV0YWNoKCkudHJpZ2dlcigiY2xvc2VkLmJzLmFsZXJ0IikucmVtb3ZlKCl9dmFyIGU9YSh0aGlzKSxmPWUuYXR0cigiZGF0YS10YXJnZXQiKTtmfHwoZj1lLmF0dHIoImhyZWYiKSxmPWYmJmYucmVwbGFjZSgvLiooPz0jW15cc10qJCkvLCIiKSk7dmFyIGc9YShmKTtiJiZiLnByZXZlbnREZWZhdWx0KCksZy5sZW5ndGh8fChnPWUuY2xvc2VzdCgiLmFsZXJ0IikpLGcudHJpZ2dlcihiPWEuRXZlbnQoImNsb3NlLmJzLmFsZXJ0IikpLGIuaXNEZWZhdWx0UHJldmVudGVkKCl8fChnLnJlbW92ZUNsYXNzKCJpbiIpLGEuc3VwcG9ydC50cmFuc2l0aW9uJiZnLmhhc0NsYXNzKCJmYWRlIik/Zy5vbmUoImJzVHJhbnNpdGlvbkVuZCIsYykuZW11bGF0ZVRyYW5zaXRpb25FbmQoZC5UUkFOU0lUSU9OX0RVUkFUSU9OKTpjKCkpfTt2YXIgZT1hLmZuLmFsZXJ0O2EuZm4uYWxlcnQ9YixhLmZuLmFsZXJ0LkNvbnN0cnVjdG9yPWQsYS5mbi5hbGVydC5ub0NvbmZsaWN0PWZ1bmN0aW9uKCl7cmV0dXJuIGEuZm4uYWxlcnQ9ZSx0aGlzfSxhKGRvY3VtZW50KS5vbigiY2xpY2suYnMuYWxlcnQuZGF0YS1hcGkiLGMsZC5wcm90b3R5cGUuY2xvc2UpfShqUXVlcnkpLCtmdW5jdGlvbihhKXsidXNlIHN0cmljdCI7ZnVuY3Rpb24gYihiKXtyZXR1cm4gdGhpcy5lYWNoKGZ1bmN0aW9uKCl7dmFyIGQ9YSh0aGlzKSxlPWQuZGF0YSgiYnMuYnV0dG9uIiksZj0ib2JqZWN0Ij09dHlwZW9mIGImJmI7ZXx8ZC5kYXRhKCJicy5idXR0b24iLGU9bmV3IGModGhpcyxmKSksInRvZ2dsZSI9PWI/ZS50b2dnbGUoKTpiJiZlLnNldFN0YXRlKGIpfSl9dmFyIGM9ZnVuY3Rpb24oYixkKXt0aGlzLiRlbGVtZW50PWEoYiksdGhpcy5vcHRpb25zPWEuZXh0ZW5kKHt9LGMuREVGQVVMVFMsZCksdGhpcy5pc0xvYWRpbmc9ITF9O2MuVkVSU0lPTj0iMy4zLjUiLGMuREVGQVVMVFM9e2xvYWRpbmdUZXh0OiJsb2FkaW5nLi4uIn0sYy5wcm90b3R5cGUuc2V0U3RhdGU9ZnVuY3Rpb24oYil7dmFyIGM9ImRpc2FibGVkIixkPXRoaXMuJGVsZW1lbnQsZT1kLmlzKCJpbnB1dCIpPyJ2YWwiOiJodG1sIixmPWQuZGF0YSgpO2IrPSJUZXh0IixudWxsPT1mLnJlc2V0VGV4dCYmZC5kYXRhKCJyZXNldFRleHQiLGRbZV0oKSksc2V0VGltZW91dChhLnByb3h5KGZ1bmN0aW9uKCl7ZFtlXShudWxsPT1mW2JdP3RoaXMub3B0aW9uc1tiXTpmW2JdKSwibG9hZGluZ1RleHQiPT1iPyh0aGlzLmlzTG9hZGluZz0hMCxkLmFkZENsYXNzKGMpLmF0dHIoYyxjKSk6dGhpcy5pc0xvYWRpbmcmJih0aGlzLmlzTG9hZGluZz0hMSxkLnJlbW92ZUNsYXNzKGMpLnJlbW92ZUF0dHIoYykpfSx0aGlzKSwwKX0sYy5wcm90b3R5cGUudG9nZ2xlPWZ1bmN0aW9uKCl7dmFyIGE9ITAsYj10aGlzLiRlbGVtZW50LmNsb3Nlc3QoJ1tkYXRhLXRvZ2dsZT0iYnV0dG9ucyJdJyk7aWYoYi5sZW5ndGgpe3ZhciBjPXRoaXMuJGVsZW1lbnQuZmluZCgiaW5wdXQiKTsicmFkaW8iPT1jLnByb3AoInR5cGUiKT8oYy5wcm9wKCJjaGVja2VkIikmJihhPSExKSxiLmZpbmQoI
|
|||
|
|
<script src="data:application/x-javascript;base64,LyoqCiogQHByZXNlcnZlIEhUTUw1IFNoaXYgMy43LjIgfCBAYWZhcmthcyBAamRhbHRvbiBAam9uX25lYWwgQHJlbSB8IE1JVC9HUEwyIExpY2Vuc2VkCiovCi8vIE9ubHkgcnVuIHRoaXMgY29kZSBpbiBJRSA4CmlmICghIXdpbmRvdy5uYXZpZ2F0b3IudXNlckFnZW50Lm1hdGNoKCJNU0lFIDgiKSkgewohZnVuY3Rpb24oYSxiKXtmdW5jdGlvbiBjKGEsYil7dmFyIGM9YS5jcmVhdGVFbGVtZW50KCJwIiksZD1hLmdldEVsZW1lbnRzQnlUYWdOYW1lKCJoZWFkIilbMF18fGEuZG9jdW1lbnRFbGVtZW50O3JldHVybiBjLmlubmVySFRNTD0ieDxzdHlsZT4iK2IrIjwvc3R5bGU+IixkLmluc2VydEJlZm9yZShjLmxhc3RDaGlsZCxkLmZpcnN0Q2hpbGQpfWZ1bmN0aW9uIGQoKXt2YXIgYT10LmVsZW1lbnRzO3JldHVybiJzdHJpbmciPT10eXBlb2YgYT9hLnNwbGl0KCIgIik6YX1mdW5jdGlvbiBlKGEsYil7dmFyIGM9dC5lbGVtZW50czsic3RyaW5nIiE9dHlwZW9mIGMmJihjPWMuam9pbigiICIpKSwic3RyaW5nIiE9dHlwZW9mIGEmJihhPWEuam9pbigiICIpKSx0LmVsZW1lbnRzPWMrIiAiK2EsaihiKX1mdW5jdGlvbiBmKGEpe3ZhciBiPXNbYVtxXV07cmV0dXJuIGJ8fChiPXt9LHIrKyxhW3FdPXIsc1tyXT1iKSxifWZ1bmN0aW9uIGcoYSxjLGQpe2lmKGN8fChjPWIpLGwpcmV0dXJuIGMuY3JlYXRlRWxlbWVudChhKTtkfHwoZD1mKGMpKTt2YXIgZTtyZXR1cm4gZT1kLmNhY2hlW2FdP2QuY2FjaGVbYV0uY2xvbmVOb2RlKCk6cC50ZXN0KGEpPyhkLmNhY2hlW2FdPWQuY3JlYXRlRWxlbShhKSkuY2xvbmVOb2RlKCk6ZC5jcmVhdGVFbGVtKGEpLCFlLmNhbkhhdmVDaGlsZHJlbnx8by50ZXN0KGEpfHxlLnRhZ1Vybj9lOmQuZnJhZy5hcHBlbmRDaGlsZChlKX1mdW5jdGlvbiBoKGEsYyl7aWYoYXx8KGE9YiksbClyZXR1cm4gYS5jcmVhdGVEb2N1bWVudEZyYWdtZW50KCk7Yz1jfHxmKGEpO2Zvcih2YXIgZT1jLmZyYWcuY2xvbmVOb2RlKCksZz0wLGg9ZCgpLGk9aC5sZW5ndGg7aT5nO2crKyllLmNyZWF0ZUVsZW1lbnQoaFtnXSk7cmV0dXJuIGV9ZnVuY3Rpb24gaShhLGIpe2IuY2FjaGV8fChiLmNhY2hlPXt9LGIuY3JlYXRlRWxlbT1hLmNyZWF0ZUVsZW1lbnQsYi5jcmVhdGVGcmFnPWEuY3JlYXRlRG9jdW1lbnRGcmFnbWVudCxiLmZyYWc9Yi5jcmVhdGVGcmFnKCkpLGEuY3JlYXRlRWxlbWVudD1mdW5jdGlvbihjKXtyZXR1cm4gdC5zaGl2TWV0aG9kcz9nKGMsYSxiKTpiLmNyZWF0ZUVsZW0oYyl9LGEuY3JlYXRlRG9jdW1lbnRGcmFnbWVudD1GdW5jdGlvbigiaCxmIiwicmV0dXJuIGZ1bmN0aW9uKCl7dmFyIG49Zi5jbG9uZU5vZGUoKSxjPW4uY3JlYXRlRWxlbWVudDtoLnNoaXZNZXRob2RzJiYoIitkKCkuam9pbigpLnJlcGxhY2UoL1tcd1wtOl0rL2csZnVuY3Rpb24oYSl7cmV0dXJuIGIuY3JlYXRlRWxlbShhKSxiLmZyYWcuY3JlYXRlRWxlbWVudChhKSwnYygiJythKyciKSd9KSsiKTtyZXR1cm4gbn0iKSh0LGIuZnJhZyl9ZnVuY3Rpb24gaihhKXthfHwoYT1iKTt2YXIgZD1mKGEpO3JldHVybiF0LnNoaXZDU1N8fGt8fGQuaGFzQ1NTfHwoZC5oYXNDU1M9ISFjKGEsImFydGljbGUsYXNpZGUsZGlhbG9nLGZpZ2NhcHRpb24sZmlndXJlLGZvb3RlcixoZWFkZXIsaGdyb3VwLG1haW4sbmF2LHNlY3Rpb257ZGlzcGxheTpibG9ja31tYXJre2JhY2tncm91bmQ6I0ZGMDtjb2xvcjojMDAwfXRlbXBsYXRle2Rpc3BsYXk6bm9uZX0iKSksbHx8aShhLGQpLGF9dmFyIGssbCxtPSIzLjcuMiIsbj1hLmh0bWw1fHx7fSxvPS9ePHxeKD86YnV0dG9ufG1hcHxzZWxlY3R8dGV4dGFyZWF8b2JqZWN0fGlmcmFtZXxvcHRpb258b3B0Z3JvdXApJC9pLHA9L14oPzphfGJ8Y29kZXxkaXZ8ZmllbGRzZXR8aDF8aDJ8aDN8aDR8aDV8aDZ8aXxsYWJlbHxsaXxvbHxwfHF8c3BhbnxzdHJvbmd8c3R5bGV8dGFibGV8dGJvZHl8dGR8dGh8dHJ8dWwpJC9pLHE9Il9odG1sNXNoaXYiLHI9MCxzPXt9OyFmdW5jdGlvbigpe3RyeXt2YXIgYT1iLmNyZWF0ZUVsZW1lbnQoImEiKTthLmlubmVySFRNTD0iPHh5ej48L3h5ej4iLGs9ImhpZGRlbiJpbiBhLGw9MT09YS5jaGlsZE5vZGVzLmxlbmd0aHx8ZnVuY3Rpb24oKXtiLmNyZWF0ZUVsZW1lbnQoImEiKTt2YXIgYT1iLmNyZWF0ZURvY3VtZW50RnJhZ21lbnQoKTtyZXR1cm4idW5kZWZpbmVkIj09dHlwZW9mIGEuY2xvbmVOb2RlfHwidW5kZWZpbmVkIj09dHlwZW9mIGEuY3JlYXRlRG9jdW1lbnRGcmFnbWVudHx8InVuZGVmaW5lZCI9PXR5cGVvZiBhLmNyZWF0ZUVsZW1lbnR9KCl9Y2F0Y2goYyl7az0hMCxsPSEwfX0oKTt2YXIgdD17ZWxlbWVudHM6bi5lbGVtZW50c3x8ImFiYnIgYXJ0aWNsZSBhc2lkZSBhdWRpbyBiZGkgY2FudmFzIGRhdGEgZGF0YWxpc3QgZGV0YWlscyBkaWFsb2cgZmlnY2FwdGlvbiBmaWd1cmUgZm9vdGVyIGhlYWRlciBoZ3JvdXAgbWFpbiBtYXJrIG1ldGVyIG5hdiBvdXRwdXQgcGljdHVyZSBwcm9ncmVzcyBzZWN0aW9uIHN1bW1hcnkgdGVtcGxhdGUgdGltZSB2aWRlbyIsdmVyc2lvbjptLHNoaXZDU1M6bi5zaGl2Q1NTIT09ITEsc3VwcG9ydHNVbmtub3duRWxlbWVudHM6bCxzaGl2TWV0aG9kczpuLnNoaXZNZXRob2RzIT09ITEsdHlwZToiZGVmYXVsdCIsc2hpdkRvY3VtZW50OmosY3JlYXRlRWxlbWVudDpnLGNyZWF0ZURvY3VtZW50RnJhZ21lbnQ6aCxhZGRFbGVtZW50czplfTthLmh0bWw1PXQsaihiKX0odGhpcyxkb2N1bWVudCk7Cn07Cg=="></script>
|
|||
|
|
<script src="data:application/x-javascript;base64,LyohIFJlc3BvbmQuanMgdjEuNC4yOiBtaW4vbWF4LXdpZHRoIG1lZGlhIHF1ZXJ5IHBvbHlmaWxsICogQ29weXJpZ2h0IDIwMTMgU2NvdHQgSmVobAogKiBMaWNlbnNlZCB1bmRlciBodHRwczovL2dpdGh1Yi5jb20vc2NvdHRqZWhsL1Jlc3BvbmQvYmxvYi9tYXN0ZXIvTElDRU5TRS1NSVQKICogICovCgovLyBPbmx5IHJ1biB0aGlzIGNvZGUgaW4gSUUgOAppZiAoISF3aW5kb3cubmF2aWdhdG9yLnVzZXJBZ2VudC5tYXRjaCgiTVNJRSA4IikpIHsKIWZ1bmN0aW9uKGEpeyJ1c2Ugc3RyaWN0IjthLm1hdGNoTWVkaWE9YS5tYXRjaE1lZGlhfHxmdW5jdGlvbihhKXt2YXIgYixjPWEuZG9jdW1lbnRFbGVtZW50LGQ9Yy5maXJzdEVsZW1lbnRDaGlsZHx8Yy5maXJzdENoaWxkLGU9YS5jcmVhdGVFbGVtZW50KCJib2R5IiksZj1hLmNyZWF0ZUVsZW1lbnQoImRpdiIpO3JldHVybiBmLmlkPSJtcS10ZXN0LTEiLGYuc3R5bGUuY3NzVGV4dD0icG9zaXRpb246YWJzb2x1dGU7dG9wOi0xMDBlbSIsZS5zdHlsZS5iYWNrZ3JvdW5kPSJub25lIixlLmFwcGVuZENoaWxkKGYpLGZ1bmN0aW9uKGEpe3JldHVybiBmLmlubmVySFRNTD0nJnNoeTs8c3R5bGUgbWVkaWE9IicrYSsnIj4gI21xLXRlc3QtMSB7IHdpZHRoOiA0MnB4OyB9PC9zdHlsZT4nLGMuaW5zZXJ0QmVmb3JlKGUsZCksYj00Mj09PWYub2Zmc2V0V2lkdGgsYy5yZW1vdmVDaGlsZChlKSx7bWF0Y2hlczpiLG1lZGlhOmF9fX0oYS5kb2N1bWVudCl9KHRoaXMpLGZ1bmN0aW9uKGEpeyJ1c2Ugc3RyaWN0IjtmdW5jdGlvbiBiKCl7dSghMCl9dmFyIGM9e307YS5yZXNwb25kPWMsYy51cGRhdGU9ZnVuY3Rpb24oKXt9O3ZhciBkPVtdLGU9ZnVuY3Rpb24oKXt2YXIgYj0hMTt0cnl7Yj1uZXcgYS5YTUxIdHRwUmVxdWVzdH1jYXRjaChjKXtiPW5ldyBhLkFjdGl2ZVhPYmplY3QoIk1pY3Jvc29mdC5YTUxIVFRQIil9cmV0dXJuIGZ1bmN0aW9uKCl7cmV0dXJuIGJ9fSgpLGY9ZnVuY3Rpb24oYSxiKXt2YXIgYz1lKCk7YyYmKGMub3BlbigiR0VUIixhLCEwKSxjLm9ucmVhZHlzdGF0ZWNoYW5nZT1mdW5jdGlvbigpezQhPT1jLnJlYWR5U3RhdGV8fDIwMCE9PWMuc3RhdHVzJiYzMDQhPT1jLnN0YXR1c3x8YihjLnJlc3BvbnNlVGV4dCl9LDQhPT1jLnJlYWR5U3RhdGUmJmMuc2VuZChudWxsKSl9O2lmKGMuYWpheD1mLGMucXVldWU9ZCxjLnJlZ2V4PXttZWRpYTovQG1lZGlhW15ce10rXHsoW15ce1x9XSpce1teXH1ce10qXH0pKy9naSxrZXlmcmFtZXM6L0AoPzpcLSg/Om98bW96fHdlYmtpdClcLSk/a2V5ZnJhbWVzW15ce10rXHsoPzpbXlx7XH1dKlx7W15cfVx7XSpcfSkrW15cfV0qXH0vZ2ksdXJsczovKHVybFwoKVsnIl0/KFteXC9cKSciXVteOlwpJyJdKylbJyJdPyhcKSkvZyxmaW5kU3R5bGVzOi9AbWVkaWEgKihbXlx7XSspXHsoW1xTXHNdKz8pJC8sb25seTovKG9ubHlccyspPyhbYS16QS1aXSspXHM/LyxtaW53Oi9cKFtcc10qbWluXC13aWR0aFxzKjpbXHNdKihbXHNdKlswLTlcLl0rKShweHxlbSlbXHNdKlwpLyxtYXh3Oi9cKFtcc10qbWF4XC13aWR0aFxzKjpbXHNdKihbXHNdKlswLTlcLl0rKShweHxlbSlbXHNdKlwpL30sYy5tZWRpYVF1ZXJpZXNTdXBwb3J0ZWQ9YS5tYXRjaE1lZGlhJiZudWxsIT09YS5tYXRjaE1lZGlhKCJvbmx5IGFsbCIpJiZhLm1hdGNoTWVkaWEoIm9ubHkgYWxsIikubWF0Y2hlcywhYy5tZWRpYVF1ZXJpZXNTdXBwb3J0ZWQpe3ZhciBnLGgsaSxqPWEuZG9jdW1lbnQsaz1qLmRvY3VtZW50RWxlbWVudCxsPVtdLG09W10sbj1bXSxvPXt9LHA9MzAscT1qLmdldEVsZW1lbnRzQnlUYWdOYW1lKCJoZWFkIilbMF18fGsscj1qLmdldEVsZW1lbnRzQnlUYWdOYW1lKCJiYXNlIilbMF0scz1xLmdldEVsZW1lbnRzQnlUYWdOYW1lKCJsaW5rIiksdD1mdW5jdGlvbigpe3ZhciBhLGI9ai5jcmVhdGVFbGVtZW50KCJkaXYiKSxjPWouYm9keSxkPWsuc3R5bGUuZm9udFNpemUsZT1jJiZjLnN0eWxlLmZvbnRTaXplLGY9ITE7cmV0dXJuIGIuc3R5bGUuY3NzVGV4dD0icG9zaXRpb246YWJzb2x1dGU7Zm9udC1zaXplOjFlbTt3aWR0aDoxZW0iLGN8fChjPWY9ai5jcmVhdGVFbGVtZW50KCJib2R5IiksYy5zdHlsZS5iYWNrZ3JvdW5kPSJub25lIiksay5zdHlsZS5mb250U2l6ZT0iMTAwJSIsYy5zdHlsZS5mb250U2l6ZT0iMTAwJSIsYy5hcHBlbmRDaGlsZChiKSxmJiZrLmluc2VydEJlZm9yZShjLGsuZmlyc3RDaGlsZCksYT1iLm9mZnNldFdpZHRoLGY/ay5yZW1vdmVDaGlsZChjKTpjLnJlbW92ZUNoaWxkKGIpLGsuc3R5bGUuZm9udFNpemU9ZCxlJiYoYy5zdHlsZS5mb250U2l6ZT1lKSxhPWk9cGFyc2VGbG9hdChhKX0sdT1mdW5jdGlvbihiKXt2YXIgYz0iY2xpZW50V2lkdGgiLGQ9a1tjXSxlPSJDU1MxQ29tcGF0Ij09PWouY29tcGF0TW9kZSYmZHx8ai5ib2R5W2NdfHxkLGY9e30sbz1zW3MubGVuZ3RoLTFdLHI9KG5ldyBEYXRlKS5nZXRUaW1lKCk7aWYoYiYmZyYmcD5yLWcpcmV0dXJuIGEuY2xlYXJUaW1lb3V0KGgpLGg9YS5zZXRUaW1lb3V0KHUscCksdm9pZCAwO2c9cjtmb3IodmFyIHYgaW4gbClpZihsLmhhc093blByb3BlcnR5KHYpKXt2YXIgdz1sW3ZdLHg9dy5taW53LHk9dy5tYXh3LHo9bnVsbD09PXgsQT1udWxsPT09eSxCPSJlbSI7eCYmKHg9cGFyc2VGbG9hdCh4KSooeC5pbmRleE9mKEIpPi0xP2l8fHQoKToxKSkseSYmKHk9cGFyc2VGbG9hdCh5KSooeS5pbmRleE9mKEIpPi0xP2l8fHQoKToxKSksdy5oYXNxdWVyeSYmKHomJkF8fCEoenx8ZT49eCl8fCEoQXx8eT49ZSkpfHwoZlt3Lm1lZGlhXXx8KGZbdy5tZWRpYV09W10pLGZbdy5tZWRpYV0ucHVzaChtW3cucnVsZXNdKSl9Zm9yKHZhciBDIGluIG4pbi5oYXNPd25Qcm9wZXJ0eShDKSYmbltDXSYmbltDXS5wYXJlbnROb2RlPT09cSYmcS5yZW1vdmVDaGlsZChuW0NdKTtuLmxlbmd0aD0wO2Zvcih2YXIgRCBpbiBmKWlmKGYuaGFzT3duUHJvcGVydHkoRCkpe3ZhciBFPWouY3JlYXRlRWxlbWVudCgic3R5bGUiKSxGPWZbRF0uam9pbigiXG4iKTtFLnR5cGU9InRleHQvY3NzIixFLm1lZGlhPUQscS5pbnNlc
|
|||
|
|
<script src="data:application/x-javascript;base64,CgovKioKICogalF1ZXJ5IFBsdWdpbjogU3RpY2t5IFRhYnMKICoKICogQGF1dGhvciBBaWRhbiBMaXN0ZXIgPGFpZGFuQHBocC5uZXQ+CiAqIGFkYXB0ZWQgYnkgUnViZW4gQXJzbGFuIHRvIGFjdGl2YXRlIHBhcmVudCB0YWJzIHRvbwogKiBodHRwOi8vd3d3LmFpZGFubGlzdGVyLmNvbS8yMDE0LzAzL3BlcnNpc3RpbmctdGhlLXRhYi1zdGF0ZS1pbi1ib290c3RyYXAvCiAqLwooZnVuY3Rpb24oJCkgewogICJ1c2Ugc3RyaWN0IjsKICAkLmZuLnJtYXJrZG93blN0aWNreVRhYnMgPSBmdW5jdGlvbigpIHsKICAgIHZhciBjb250ZXh0ID0gdGhpczsKICAgIC8vIFNob3cgdGhlIHRhYiBjb3JyZXNwb25kaW5nIHdpdGggdGhlIGhhc2ggaW4gdGhlIFVSTCwgb3IgdGhlIGZpcnN0IHRhYgogICAgdmFyIHNob3dTdHVmZkZyb21IYXNoID0gZnVuY3Rpb24oKSB7CiAgICAgIHZhciBoYXNoID0gd2luZG93LmxvY2F0aW9uLmhhc2g7CiAgICAgIHZhciBzZWxlY3RvciA9IGhhc2ggPyAnYVtocmVmPSInICsgaGFzaCArICciXScgOiAnbGkuYWN0aXZlID4gYSc7CiAgICAgIHZhciAkc2VsZWN0b3IgPSAkKHNlbGVjdG9yLCBjb250ZXh0KTsKICAgICAgaWYoJHNlbGVjdG9yLmRhdGEoJ3RvZ2dsZScpID09PSAidGFiIikgewogICAgICAgICRzZWxlY3Rvci50YWIoJ3Nob3cnKTsKICAgICAgICAvLyB3YWxrIHVwIHRoZSBhbmNlc3RvcnMgb2YgdGhpcyBlbGVtZW50LCBzaG93IGFueSBoaWRkZW4gdGFicwogICAgICAgICRzZWxlY3Rvci5wYXJlbnRzKCcuc2VjdGlvbi50YWJzZXQnKS5lYWNoKGZ1bmN0aW9uKGksIGVsbSkgewogICAgICAgICAgdmFyIGxpbmsgPSAkKCdhW2hyZWY9IiMnICsgJChlbG0pLmF0dHIoJ2lkJykgKyAnIl0nKTsKICAgICAgICAgIGlmKGxpbmsuZGF0YSgndG9nZ2xlJykgPT09ICJ0YWIiKSB7CiAgICAgICAgICAgIGxpbmsudGFiKCJzaG93Iik7CiAgICAgICAgICB9CiAgICAgICAgfSk7CiAgICAgIH0KICAgIH07CgoKICAgIC8vIFNldCB0aGUgY29ycmVjdCB0YWIgd2hlbiB0aGUgcGFnZSBsb2FkcwogICAgc2hvd1N0dWZmRnJvbUhhc2goY29udGV4dCk7CgogICAgLy8gU2V0IHRoZSBjb3JyZWN0IHRhYiB3aGVuIGEgdXNlciB1c2VzIHRoZWlyIGJhY2svZm9yd2FyZCBidXR0b24KICAgICQod2luZG93KS5vbignaGFzaGNoYW5nZScsIGZ1bmN0aW9uKCkgewogICAgICBzaG93U3R1ZmZGcm9tSGFzaChjb250ZXh0KTsKICAgIH0pOwoKICAgIC8vIENoYW5nZSB0aGUgVVJMIHdoZW4gdGFicyBhcmUgY2xpY2tlZAogICAgJCgnYScsIGNvbnRleHQpLm9uKCdjbGljaycsIGZ1bmN0aW9uKGUpIHsKICAgICAgaGlzdG9yeS5wdXNoU3RhdGUobnVsbCwgbnVsbCwgdGhpcy5ocmVmKTsKICAgICAgc2hvd1N0dWZmRnJvbUhhc2goY29udGV4dCk7CiAgICB9KTsKCiAgICByZXR1cm4gdGhpczsKICB9Owp9KGpRdWVyeSkpOwoKd2luZG93LmJ1aWxkVGFic2V0cyA9IGZ1bmN0aW9uKHRvY0lEKSB7CgogIC8vIGJ1aWxkIGEgdGFic2V0IGZyb20gYSBzZWN0aW9uIGRpdiB3aXRoIHRoZSAudGFic2V0IGNsYXNzCiAgZnVuY3Rpb24gYnVpbGRUYWJzZXQodGFic2V0KSB7CgogICAgLy8gY2hlY2sgZm9yIGZhZGUgYW5kIHBpbGxzIG9wdGlvbnMKICAgIHZhciBmYWRlID0gdGFic2V0Lmhhc0NsYXNzKCJ0YWJzZXQtZmFkZSIpOwogICAgdmFyIHBpbGxzID0gdGFic2V0Lmhhc0NsYXNzKCJ0YWJzZXQtcGlsbHMiKTsKICAgIHZhciBuYXZDbGFzcyA9IHBpbGxzID8gIm5hdi1waWxscyIgOiAibmF2LXRhYnMiOwoKICAgIC8vIGRldGVybWluZSB0aGUgaGVhZGluZyBsZXZlbCBvZiB0aGUgdGFic2V0IGFuZCB0YWJzCiAgICB2YXIgbWF0Y2ggPSB0YWJzZXQuYXR0cignY2xhc3MnKS5tYXRjaCgvbGV2ZWwoXGQpIC8pOwogICAgaWYgKG1hdGNoID09PSBudWxsKQogICAgICByZXR1cm47CiAgICB2YXIgdGFic2V0TGV2ZWwgPSBOdW1iZXIobWF0Y2hbMV0pOwogICAgdmFyIHRhYkxldmVsID0gdGFic2V0TGV2ZWwgKyAxOwoKICAgIC8vIGZpbmQgYWxsIHN1YmhlYWRpbmdzIGltbWVkaWF0ZWx5IGJlbG93CiAgICB2YXIgdGFicyA9IHRhYnNldC5maW5kKCJkaXYuc2VjdGlvbi5sZXZlbCIgKyB0YWJMZXZlbCk7CiAgICBpZiAoIXRhYnMubGVuZ3RoKQogICAgICByZXR1cm47CgogICAgLy8gY3JlYXRlIHRhYmxpc3QgYW5kIHRhYi1jb250ZW50IGVsZW1lbnRzCiAgICB2YXIgdGFiTGlzdCA9ICQoJzx1bCBjbGFzcz0ibmF2ICcgKyBuYXZDbGFzcyArICciIHJvbGU9InRhYmxpc3QiPjwvdWw+Jyk7CiAgICAkKHRhYnNbMF0pLmJlZm9yZSh0YWJMaXN0KTsKICAgIHZhciB0YWJDb250ZW50ID0gJCgnPGRpdiBjbGFzcz0idGFiLWNvbnRlbnQiPjwvZGl2PicpOwogICAgJCh0YWJzWzBdKS5iZWZvcmUodGFiQ29udGVudCk7CgogICAgLy8gYnVpbGQgdGhlIHRhYnNldAogICAgdmFyIGFjdGl2ZVRhYiA9IDA7CiAgICB0YWJzLmVhY2goZnVuY3Rpb24oaSkgewoKICAgICAgLy8gZ2V0IHRoZSB0YWIgZGl2CiAgICAgIHZhciB0YWIgPSAkKHRhYnNbaV0pOwoKICAgICAgLy8gZ2V0IHRoZSBpZCB0aGVuIHNhbml0aXplIGl0IGZvciB1c2Ugd2l0aCBib290c3RyYXAgdGFicwogICAgICB2YXIgaWQgPSB0YWIuYXR0cignaWQnKTsKCiAgICAgIC8vIHNlZSBpZiB0aGlzIGlzIG1hcmtlZCBhcyB0aGUgYWN0aXZlIHRhYgogICAgICBpZiAodGFiLmhhc0NsYXNzKCdhY3RpdmUnKSkKICAgICAgICBhY3RpdmVUYWIgPSBpOwoKICAgICAgLy8gcmVtb3ZlIGFueSB0YWJsZSBvZiBjb250ZW50cyBlbnRyaWVzIGFzc29jaWF0ZWQgd2l0aAogICAgICAvLyB0aGlzIElEIChzaW5jZSB3ZSdsbCBiZSByZW1vdmluZyB0aGUgaGVhZGluZyBlbGVtZW50KQogICAgICAkKCJkaXYjIiArIHRvY0lEICsgIiBsaSBhW2hyZWY9JyMiICsgaWQgKyAiJ10iKS5wYXJlbnQoKS5yZW1vdmUoKTsKCiAgICAgIC8vIHNhbml0aXplIHRoZSBpZCBmb3IgdXNlIHdpdGggYm9vdHN0cmFwIHRhYnMKICAgICAgaWQgPSBpZC5yZXBsYWNlKC9bLlwvPyYhIzw+XS9nLCAnJykucmVwbGFjZSgvXHMvZywgJ
|
|||
|
|
<link href="data:text/css;charset=utf-8,%2Ehljs%2Dliteral%20%7B%0Acolor%3A%20%23990073%3B%0A%7D%0A%2Ehljs%2Dnumber%20%7B%0Acolor%3A%20%23099%3B%0A%7D%0A%2Ehljs%2Dcomment%20%7B%0Acolor%3A%20%23998%3B%0Afont%2Dstyle%3A%20italic%3B%0A%7D%0A%2Ehljs%2Dkeyword%20%7B%0Acolor%3A%20%23900%3B%0Afont%2Dweight%3A%20bold%3B%0A%7D%0A%2Ehljs%2Dstring%20%7B%0Acolor%3A%20%23d14%3B%0A%7D%0A" rel="stylesheet" />
|
|||
|
|
<script src="data:application/x-javascript;base64,LyohIGhpZ2hsaWdodC5qcyB2OS4xMi4wIHwgQlNEMyBMaWNlbnNlIHwgZ2l0LmlvL2hsanNsaWNlbnNlICovCiFmdW5jdGlvbihlKXt2YXIgbj0ib2JqZWN0Ij09dHlwZW9mIHdpbmRvdyYmd2luZG93fHwib2JqZWN0Ij09dHlwZW9mIHNlbGYmJnNlbGY7InVuZGVmaW5lZCIhPXR5cGVvZiBleHBvcnRzP2UoZXhwb3J0cyk6biYmKG4uaGxqcz1lKHt9KSwiZnVuY3Rpb24iPT10eXBlb2YgZGVmaW5lJiZkZWZpbmUuYW1kJiZkZWZpbmUoW10sZnVuY3Rpb24oKXtyZXR1cm4gbi5obGpzfSkpfShmdW5jdGlvbihlKXtmdW5jdGlvbiBuKGUpe3JldHVybiBlLnJlcGxhY2UoLyYvZywiJmFtcDsiKS5yZXBsYWNlKC88L2csIiZsdDsiKS5yZXBsYWNlKC8+L2csIiZndDsiKX1mdW5jdGlvbiB0KGUpe3JldHVybiBlLm5vZGVOYW1lLnRvTG93ZXJDYXNlKCl9ZnVuY3Rpb24gcihlLG4pe3ZhciB0PWUmJmUuZXhlYyhuKTtyZXR1cm4gdCYmMD09PXQuaW5kZXh9ZnVuY3Rpb24gYShlKXtyZXR1cm4gay50ZXN0KGUpfWZ1bmN0aW9uIGkoZSl7dmFyIG4sdCxyLGksbz1lLmNsYXNzTmFtZSsiICI7aWYobys9ZS5wYXJlbnROb2RlP2UucGFyZW50Tm9kZS5jbGFzc05hbWU6IiIsdD1CLmV4ZWMobykpcmV0dXJuIHcodFsxXSk/dFsxXToibm8taGlnaGxpZ2h0Ijtmb3Iobz1vLnNwbGl0KC9ccysvKSxuPTAscj1vLmxlbmd0aDtyPm47bisrKWlmKGk9b1tuXSxhKGkpfHx3KGkpKXJldHVybiBpfWZ1bmN0aW9uIG8oZSl7dmFyIG4sdD17fSxyPUFycmF5LnByb3RvdHlwZS5zbGljZS5jYWxsKGFyZ3VtZW50cywxKTtmb3IobiBpbiBlKXRbbl09ZVtuXTtyZXR1cm4gci5mb3JFYWNoKGZ1bmN0aW9uKGUpe2ZvcihuIGluIGUpdFtuXT1lW25dfSksdH1mdW5jdGlvbiB1KGUpe3ZhciBuPVtdO3JldHVybiBmdW5jdGlvbiByKGUsYSl7Zm9yKHZhciBpPWUuZmlyc3RDaGlsZDtpO2k9aS5uZXh0U2libGluZykzPT09aS5ub2RlVHlwZT9hKz1pLm5vZGVWYWx1ZS5sZW5ndGg6MT09PWkubm9kZVR5cGUmJihuLnB1c2goe2V2ZW50OiJzdGFydCIsb2Zmc2V0OmEsbm9kZTppfSksYT1yKGksYSksdChpKS5tYXRjaCgvYnJ8aHJ8aW1nfGlucHV0Lyl8fG4ucHVzaCh7ZXZlbnQ6InN0b3AiLG9mZnNldDphLG5vZGU6aX0pKTtyZXR1cm4gYX0oZSwwKSxufWZ1bmN0aW9uIGMoZSxyLGEpe2Z1bmN0aW9uIGkoKXtyZXR1cm4gZS5sZW5ndGgmJnIubGVuZ3RoP2VbMF0ub2Zmc2V0IT09clswXS5vZmZzZXQ/ZVswXS5vZmZzZXQ8clswXS5vZmZzZXQ/ZTpyOiJzdGFydCI9PT1yWzBdLmV2ZW50P2U6cjplLmxlbmd0aD9lOnJ9ZnVuY3Rpb24gbyhlKXtmdW5jdGlvbiByKGUpe3JldHVybiIgIitlLm5vZGVOYW1lKyc9IicrbihlLnZhbHVlKS5yZXBsYWNlKCciJywiJnF1b3Q7IikrJyInfXMrPSI8Iit0KGUpK0UubWFwLmNhbGwoZS5hdHRyaWJ1dGVzLHIpLmpvaW4oIiIpKyI+In1mdW5jdGlvbiB1KGUpe3MrPSI8LyIrdChlKSsiPiJ9ZnVuY3Rpb24gYyhlKXsoInN0YXJ0Ij09PWUuZXZlbnQ/bzp1KShlLm5vZGUpfWZvcih2YXIgbD0wLHM9IiIsZj1bXTtlLmxlbmd0aHx8ci5sZW5ndGg7KXt2YXIgZz1pKCk7aWYocys9bihhLnN1YnN0cmluZyhsLGdbMF0ub2Zmc2V0KSksbD1nWzBdLm9mZnNldCxnPT09ZSl7Zi5yZXZlcnNlKCkuZm9yRWFjaCh1KTtkbyBjKGcuc3BsaWNlKDAsMSlbMF0pLGc9aSgpO3doaWxlKGc9PT1lJiZnLmxlbmd0aCYmZ1swXS5vZmZzZXQ9PT1sKTtmLnJldmVyc2UoKS5mb3JFYWNoKG8pfWVsc2Uic3RhcnQiPT09Z1swXS5ldmVudD9mLnB1c2goZ1swXS5ub2RlKTpmLnBvcCgpLGMoZy5zcGxpY2UoMCwxKVswXSl9cmV0dXJuIHMrbihhLnN1YnN0cihsKSl9ZnVuY3Rpb24gbChlKXtyZXR1cm4gZS52JiYhZS5jYWNoZWRfdmFyaWFudHMmJihlLmNhY2hlZF92YXJpYW50cz1lLnYubWFwKGZ1bmN0aW9uKG4pe3JldHVybiBvKGUse3Y6bnVsbH0sbil9KSksZS5jYWNoZWRfdmFyaWFudHN8fGUuZVcmJltvKGUpXXx8W2VdfWZ1bmN0aW9uIHMoZSl7ZnVuY3Rpb24gbihlKXtyZXR1cm4gZSYmZS5zb3VyY2V8fGV9ZnVuY3Rpb24gdCh0LHIpe3JldHVybiBuZXcgUmVnRXhwKG4odCksIm0iKyhlLmNJPyJpIjoiIikrKHI/ImciOiIiKSl9ZnVuY3Rpb24gcihhLGkpe2lmKCFhLmNvbXBpbGVkKXtpZihhLmNvbXBpbGVkPSEwLGEuaz1hLmt8fGEuYkssYS5rKXt2YXIgbz17fSx1PWZ1bmN0aW9uKG4sdCl7ZS5jSSYmKHQ9dC50b0xvd2VyQ2FzZSgpKSx0LnNwbGl0KCIgIikuZm9yRWFjaChmdW5jdGlvbihlKXt2YXIgdD1lLnNwbGl0KCJ8Iik7b1t0WzBdXT1bbix0WzFdP051bWJlcih0WzFdKToxXX0pfTsic3RyaW5nIj09dHlwZW9mIGEuaz91KCJrZXl3b3JkIixhLmspOngoYS5rKS5mb3JFYWNoKGZ1bmN0aW9uKGUpe3UoZSxhLmtbZV0pfSksYS5rPW99YS5sUj10KGEubHx8L1x3Ky8sITApLGkmJihhLmJLJiYoYS5iPSJcXGIoIithLmJLLnNwbGl0KCIgIikuam9pbigifCIpKyIpXFxiIiksYS5ifHwoYS5iPS9cQnxcYi8pLGEuYlI9dChhLmIpLGEuZXx8YS5lV3x8KGEuZT0vXEJ8XGIvKSxhLmUmJihhLmVSPXQoYS5lKSksYS50RT1uKGEuZSl8fCIiLGEuZVcmJmkudEUmJihhLnRFKz0oYS5lPyJ8IjoiIikraS50RSkpLGEuaSYmKGEuaVI9dChhLmkpKSxudWxsPT1hLnImJihhLnI9MSksYS5jfHwoYS5jPVtdKSxhLmM9QXJyYXkucHJvdG90eXBlLmNvbmNhdC5hcHBseShbXSxhLmMubWFwKGZ1bmN0aW9uKGUpe3JldHVybiBsKCJzZWxmIj09PWU/YTplKX0pKSxhLmMuZm9yRWFjaChmdW5jdGlvbihlKXtyKGUsYSl9KSxhLnN0YXJ0cyYmcihhLnN0YXJ0cyxpKTt2YXIgYz1hLmMubWFwKGZ1bmN0aW9uKGUpe3JldHVybiBlLmJLPyJcXC4/KCIrZS5iKyIpXFwuPyI6ZS5ifSkuY29uY2F0KFthLnRFLGEuaV0pLm1hcChuKS5maWx0ZXIoQm9vbGVhbik7YS50PWMubGVuZ3RoP3QoYy5qb2luKCJ8IiksITApOntleGVjOmZ1bmN0aW9uKCl7cmV0dXJuIG51bGx9fX19cihlKX1mdW5jdGlvbiBmKGUsdCxhLGkpe2Z1bmN0aW9uIG8oZSxuKXt2YXIgdCxhO2Zvcih0PTAsYT1uLmMubGVuZ3RoO2E+dDt0K
|
|||
|
|
<link href="data:text/css;charset=utf-8,%2Epagedtable%20%7B%0Aoverflow%3A%20auto%3B%0Apadding%2Dleft%3A%208px%3B%0Apadding%2Dright%3A%208px%3B%0A%7D%0A%2Epagedtable%2Dwrapper%20%7B%0Aborder%3A%201px%20solid%20%23ccc%3B%0Aborder%2Dradius%3A%204px%3B%0Amargin%2Dbottom%3A%2010px%3B%0A%7D%0A%2Epagedtable%20table%20%7B%0Awidth%3A%20100%25%3B%0Amax%2Dwidth%3A%20100%25%3B%0Amargin%3A%200%3B%0A%7D%0A%2Epagedtable%20th%20%7B%0Apadding%3A%200%205px%200%205px%3B%0Aborder%3A%20none%3B%0Aborder%2Dbottom%3A%202px%20solid%20%23dddddd%3B%0Amin%2Dwidth%3A%2045px%3B%0A%7D%0A%2Epagedtable%2Dempty%20th%20%7B%0Adisplay%3A%20none%3B%0A%7D%0A%2Epagedtable%20td%20%7B%0Apadding%3A%200%204px%200%204px%3B%0A%7D%0A%2Epagedtable%20%2Eeven%20%7B%0Abackground%2Dcolor%3A%20%23fcfcfc%3B%0A%7D%0A%2Epagedtable%2Dpadding%2Dcol%20%7B%0Adisplay%3A%20none%3B%0A%7D%0A%2Epagedtable%20a%20%7B%0A%2Dwebkit%2Dtouch%2Dcallout%3A%20none%3B%0A%2Dwebkit%2Duser%2Dselect%3A%20none%3B%0A%2Dkhtml%2Duser%2Dselect%3A%20none%3B%0A%2Dmoz%2Duser%2Dselect%3A%20none%3B%0A%2Dms%2Duser%2Dselect%3A%20none%3B%0Auser%2Dselect%3A%20none%3B%0A%7D%0A%2Epagedtable%2Dindex%2Dnav%20%7B%0Acursor%3A%20pointer%3B%0Apadding%3A%200%205px%200%205px%3B%0Afloat%3A%20right%3B%0Aborder%3A%200%3B%0A%7D%0A%2Epagedtable%2Dindex%2Dnav%2Ddisabled%20%7B%0Acursor%3A%20default%3B%0Atext%2Ddecoration%3A%20none%3B%0Acolor%3A%20%23999%3B%0A%7D%0Aa%2Epagedtable%2Dindex%2Dnav%2Ddisabled%3Ahover%20%7B%0Atext%2Ddecoration%3A%20none%3B%0Acolor%3A%20%23999%3B%0A%7D%0A%2Epagedtable%2Dindexes%20%7B%0Acursor%3A%20pointer%3B%0Afloat%3A%20right%3B%0Aborder%3A%200%3B%0A%7D%0A%2Epagedtable%2Dindex%2Dcurrent%20%7B%0Acursor%3A%20default%3B%0Atext%2Ddecoration%3A%20none%3B%0Afont%2Dweight%3A%20bold%3B%0Acolor%3A%20%23333%3B%0Aborder%3A%200%3B%0A%7D%0Aa%2Epagedtable%2Dindex%2Dcurrent%3Ahover%20%7B%0Atext%2Ddecoration%3A%20none%3B%0Afont%2Dweight%3A%20bold%3B%0Acolor%3A%20%23333%3B%0A%7D%0A%2Epagedtable%2Dindex%20%7B%0Awidth%3A%2030px%3B%0Adisplay%3A%20inline%2Dblock%3B%0Atext%2Dalign%3A%20center%3B%0Aborder%3A%200%3B%0A%7D%0A%2Epagedtable%2Dindex%2Dseparator%2Dleft%20%7B%0Adisplay%3A%20inline%2Dblock%3B%0Acolor%3A%20%23333%3B%0Afont%2Dsize%3A%209px%3B%0Apadding%3A%200%200%200%200%3B%0Acursor%3A%20default%3B%0A%7D%0A%2Epagedtable%2Dindex%2Dseparator%2Dright%20%7B%0Adisplay%3A%20inline%2Dblock%3B%0Acolor%3A%20%23333%3B%0Afont%2Dsize%3A%209px%3B%0Apadding%3A%200%204px%200%200%3B%0Acursor%3A%20default%3B%0A%7D%0A%2Epagedtable%2Dfooter%20%7B%0Apadding%2Dtop%3A%204px%3B%0Apadding%2Dbottom%3A%205px%3B%0A%7D%0A%2Epagedtable%2Dnot%2Dempty%20%2Epagedtable%2Dfooter%20%7B%0Aborder%2Dtop%3A%202px%20solid%20%23dddddd%3B%0A%7D%0A%2Epagedtable%2Dinfo%20%7B%0Aoverflow%3A%20hidden%3B%0Acolor%3A%20%23999%3B%0Awhite%2Dspace%3A%20nowrap%3B%0Atext%2Doverflow%3A%20ellipsis%3B%0A%7D%0A%2Epagedtable%2Dheader%2Dname%20%7B%0Aoverflow%3A%20hidden%3B%0Atext%2Doverflow%3A%20ellipsis%3B%0A%7D%0A%2Epagedtable%2Dheader%2Dtype%20%7B%0Acolor%3A%20%23999%3B%0Afont%2Dweight%3A%20400%3B%0A%7D%0A%2Epagedtable%2Dna%2Dcell%20%7B%0Afont%2Dstyle%3A%20italic%3B%0Aopacity%3A%200%2E3%3B%0A%7D%0A" rel="stylesheet" />
|
|||
|
|
<script src="data:application/x-javascript;base64,Ly8gUHJvZHVjdGlvbiBzdGVwcyBvZiBFQ01BLTI2MiwgRWRpdGlvbiA1LCAxNS40LjQuMTgKLy8gUmVmZXJlbmNlOiBodHRwOi8vZXM1LmdpdGh1Yi5pby8jeDE1LjQuNC4xOAppZiAoIUFycmF5LnByb3RvdHlwZS5mb3JFYWNoKSB7CgogIEFycmF5LnByb3RvdHlwZS5mb3JFYWNoID0gZnVuY3Rpb24oY2FsbGJhY2ssIHRoaXNBcmcpIHsKCiAgICB2YXIgVCwgazsKCiAgICBpZiAodGhpcyA9PT0gbnVsbCkgewogICAgICB0aHJvdyBuZXcgVHlwZUVycm9yKCcgdGhpcyBpcyBudWxsIG9yIG5vdCBkZWZpbmVkJyk7CiAgICB9CgogICAgLy8gMS4gTGV0IE8gYmUgdGhlIHJlc3VsdCBvZiBjYWxsaW5nIHRvT2JqZWN0KCkgcGFzc2luZyB0aGUKICAgIC8vIHx0aGlzfCB2YWx1ZSBhcyB0aGUgYXJndW1lbnQuCiAgICB2YXIgTyA9IE9iamVjdCh0aGlzKTsKCiAgICAvLyAyLiBMZXQgbGVuVmFsdWUgYmUgdGhlIHJlc3VsdCBvZiBjYWxsaW5nIHRoZSBHZXQoKSBpbnRlcm5hbAogICAgLy8gbWV0aG9kIG9mIE8gd2l0aCB0aGUgYXJndW1lbnQgImxlbmd0aCIuCiAgICAvLyAzLiBMZXQgbGVuIGJlIHRvVWludDMyKGxlblZhbHVlKS4KICAgIHZhciBsZW4gPSBPLmxlbmd0aCA+Pj4gMDsKCiAgICAvLyA0LiBJZiBpc0NhbGxhYmxlKGNhbGxiYWNrKSBpcyBmYWxzZSwgdGhyb3cgYSBUeXBlRXJyb3IgZXhjZXB0aW9uLgogICAgLy8gU2VlOiBodHRwOi8vZXM1LmdpdGh1Yi5jb20vI3g5LjExCiAgICBpZiAodHlwZW9mIGNhbGxiYWNrICE9PSAiZnVuY3Rpb24iKSB7CiAgICAgIHRocm93IG5ldyBUeXBlRXJyb3IoY2FsbGJhY2sgKyAnIGlzIG5vdCBhIGZ1bmN0aW9uJyk7CiAgICB9CgogICAgLy8gNS4gSWYgdGhpc0FyZyB3YXMgc3VwcGxpZWQsIGxldCBUIGJlIHRoaXNBcmc7IGVsc2UgbGV0CiAgICAvLyBUIGJlIHVuZGVmaW5lZC4KICAgIGlmIChhcmd1bWVudHMubGVuZ3RoID4gMSkgewogICAgICBUID0gdGhpc0FyZzsKICAgIH0KCiAgICAvLyA2LiBMZXQgayBiZSAwCiAgICBrID0gMDsKCiAgICAvLyA3LiBSZXBlYXQsIHdoaWxlIGsgPCBsZW4KICAgIHdoaWxlIChrIDwgbGVuKSB7CgogICAgICB2YXIga1ZhbHVlOwoKICAgICAgLy8gYS4gTGV0IFBrIGJlIFRvU3RyaW5nKGspLgogICAgICAvLyAgICBUaGlzIGlzIGltcGxpY2l0IGZvciBMSFMgb3BlcmFuZHMgb2YgdGhlIGluIG9wZXJhdG9yCiAgICAgIC8vIGIuIExldCBrUHJlc2VudCBiZSB0aGUgcmVzdWx0IG9mIGNhbGxpbmcgdGhlIEhhc1Byb3BlcnR5CiAgICAgIC8vICAgIGludGVybmFsIG1ldGhvZCBvZiBPIHdpdGggYXJndW1lbnQgUGsuCiAgICAgIC8vICAgIFRoaXMgc3RlcCBjYW4gYmUgY29tYmluZWQgd2l0aCBjCiAgICAgIC8vIGMuIElmIGtQcmVzZW50IGlzIHRydWUsIHRoZW4KICAgICAgaWYgKGsgaW4gTykgewoKICAgICAgICAvLyBpLiBMZXQga1ZhbHVlIGJlIHRoZSByZXN1bHQgb2YgY2FsbGluZyB0aGUgR2V0IGludGVybmFsCiAgICAgICAgLy8gbWV0aG9kIG9mIE8gd2l0aCBhcmd1bWVudCBQay4KICAgICAgICBrVmFsdWUgPSBPW2tdOwoKICAgICAgICAvLyBpaS4gQ2FsbCB0aGUgQ2FsbCBpbnRlcm5hbCBtZXRob2Qgb2YgY2FsbGJhY2sgd2l0aCBUIGFzCiAgICAgICAgLy8gdGhlIHRoaXMgdmFsdWUgYW5kIGFyZ3VtZW50IGxpc3QgY29udGFpbmluZyBrVmFsdWUsIGssIGFuZCBPLgogICAgICAgIGNhbGxiYWNrLmNhbGwoVCwga1ZhbHVlLCBrLCBPKTsKICAgICAgfQogICAgICAvLyBkLiBJbmNyZWFzZSBrIGJ5IDEuCiAgICAgIGsrKzsKICAgIH0KICAgIC8vIDguIHJldHVybiB1bmRlZmluZWQKICB9Owp9CgovLyBQcm9kdWN0aW9uIHN0ZXBzIG9mIEVDTUEtMjYyLCBFZGl0aW9uIDUsIDE1LjQuNC4xOQovLyBSZWZlcmVuY2U6IGh0dHA6Ly9lczUuZ2l0aHViLmlvLyN4MTUuNC40LjE5CmlmICghQXJyYXkucHJvdG90eXBlLm1hcCkgewoKICBBcnJheS5wcm90b3R5cGUubWFwID0gZnVuY3Rpb24oY2FsbGJhY2ssIHRoaXNBcmcpIHsKCiAgICB2YXIgVCwgQSwgazsKCiAgICBpZiAodGhpcyA9PSBudWxsKSB7CiAgICAgIHRocm93IG5ldyBUeXBlRXJyb3IoJyB0aGlzIGlzIG51bGwgb3Igbm90IGRlZmluZWQnKTsKICAgIH0KCiAgICAvLyAxLiBMZXQgTyBiZSB0aGUgcmVzdWx0IG9mIGNhbGxpbmcgVG9PYmplY3QgcGFzc2luZyB0aGUgfHRoaXN8CiAgICAvLyAgICB2YWx1ZSBhcyB0aGUgYXJndW1lbnQuCiAgICB2YXIgTyA9IE9iamVjdCh0aGlzKTsKCiAgICAvLyAyLiBMZXQgbGVuVmFsdWUgYmUgdGhlIHJlc3VsdCBvZiBjYWxsaW5nIHRoZSBHZXQgaW50ZXJuYWwKICAgIC8vICAgIG1ldGhvZCBvZiBPIHdpdGggdGhlIGFyZ3VtZW50ICJsZW5ndGgiLgogICAgLy8gMy4gTGV0IGxlbiBiZSBUb1VpbnQzMihsZW5WYWx1ZSkuCiAgICB2YXIgbGVuID0gTy5sZW5ndGggPj4+IDA7CgogICAgLy8gNC4gSWYgSXNDYWxsYWJsZShjYWxsYmFjaykgaXMgZmFsc2UsIHRocm93IGEgVHlwZUVycm9yIGV4Y2VwdGlvbi4KICAgIC8vIFNlZTogaHR0cDovL2VzNS5naXRodWIuY29tLyN4OS4xMQogICAgaWYgKHR5cGVvZiBjYWxsYmFjayAhPT0gJ2Z1bmN0aW9uJykgewogICAgICB0aHJvdyBuZXcgVHlwZUVycm9yKGNhbGxiYWNrICsgJyBpcyBub3QgYSBmdW5jdGlvbicpOwogICAgfQoKICAgIC8vIDUuIElmIHRoaXNBcmcgd2FzIHN1cHBsaWVkLCBsZXQgVCBiZSB0aGlzQXJnOyBlbHNlIGxldCBUIGJlIHVuZGVmaW5lZC4KICAgIGlmIChhcmd1bWVudHMubGVuZ3RoID4gMSkgewogICAgICBUID0gdGhpc0FyZzsKICAgIH0KCiAgICAvLyA2LiBMZXQgQSBiZSBhIG5ldyBhcnJheSBjcmVhdGVkIGFzIGlmIGJ5IHRoZSBleHByZXNzaW9uIG5ldyBBcnJheShsZW4pCiAgICAvLyAgICB3aGVyZSBBcnJheSBpcyB0aGUgc3RhbmRhcmQgYnVpbHQtaW4gY29uc3RydWN0b3Igd2l0aCB0aGF0IG5hbWUgYW5kCiAgICAvLyAgICBsZW4gaXMgdGhlIHZhbHVlIG9mIGxlbi4KICAgIEEgPSBuZXcgQXJyYXkobGVuKTsKCiAgICAvLyA3LiBMZXQgayBiZSAwCiAgICBrID0gMDsKCiAgICAvLyA4L
|
|||
|
|
|
|||
|
|
<style type="text/css">code{white-space: pre;}</style>
|
|||
|
|
<style type="text/css">
|
|||
|
|
pre:not([class]) {
|
|||
|
|
background-color: white;
|
|||
|
|
}
|
|||
|
|
</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>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
<style type="text/css">
|
|||
|
|
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;
|
|||
|
|
}
|
|||
|
|
.table th:not([align]) {
|
|||
|
|
text-align: left;
|
|||
|
|
}
|
|||
|
|
</style>
|
|||
|
|
|
|||
|
|
|
|||
|
|
</head>
|
|||
|
|
|
|||
|
|
<body>
|
|||
|
|
|
|||
|
|
<style type="text/css">
|
|||
|
|
.main-container {
|
|||
|
|
max-width: 940px;
|
|||
|
|
margin-left: auto;
|
|||
|
|
margin-right: auto;
|
|||
|
|
}
|
|||
|
|
code {
|
|||
|
|
color: inherit;
|
|||
|
|
background-color: rgba(0, 0, 0, 0.04);
|
|||
|
|
}
|
|||
|
|
img {
|
|||
|
|
max-width:100%;
|
|||
|
|
height: auto;
|
|||
|
|
}
|
|||
|
|
.tabbed-pane {
|
|||
|
|
padding-top: 12px;
|
|||
|
|
}
|
|||
|
|
button.code-folding-btn:focus {
|
|||
|
|
outline: none;
|
|||
|
|
}
|
|||
|
|
</style>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
<div class="container-fluid main-container">
|
|||
|
|
|
|||
|
|
<!-- tabsets -->
|
|||
|
|
<script>
|
|||
|
|
$(document).ready(function () {
|
|||
|
|
window.buildTabsets("TOC");
|
|||
|
|
});
|
|||
|
|
</script>
|
|||
|
|
|
|||
|
|
<!-- code folding -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
<div class="fluid-row" id="header">
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
<h1 class="title toc-ignore">OMOP Common Data Model Specifications</h1>
|
|||
|
|
<h4 class="author"><em>Christian Reich, Patrick Ryan, Rimma Belenkaya, Karthik Natarajan and Clair Blacketer</em></h4>
|
|||
|
|
<h4 class="date"><em>2019-02-06</em></h4>
|
|||
|
|
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
<div id="TOC">
|
|||
|
|
<ul>
|
|||
|
|
<li><a href="#license">License</a></li>
|
|||
|
|
<li><a href="#background">Background</a><ul>
|
|||
|
|
<li><a href="#the-role-of-the-common-data-model">The Role of the Common Data Model</a></li>
|
|||
|
|
<li><a href="#design-principles">Design Principles</a></li>
|
|||
|
|
<li><a href="#data-model-conventions">Data Model Conventions</a><ul>
|
|||
|
|
<li><a href="#general-conventions-of-schemas">General conventions of schemas</a></li>
|
|||
|
|
<li><a href="#general-conventions-of-data-tables">General conventions of data tables</a></li>
|
|||
|
|
<li><a href="#general-conventions-of-fields">General conventions of fields</a></li>
|
|||
|
|
<li><a href="#representation-of-content-through-concepts">Representation of content through Concepts</a></li>
|
|||
|
|
<li><a href="#difference-between-concept-ids-and-source-values">Difference between Concept IDs and Source Values</a></li>
|
|||
|
|
<li><a href="#difference-between-general-concepts-and-type-concepts">Difference between general Concepts and Type Concepts</a></li>
|
|||
|
|
<li><a href="#time-span-of-available-data">Time span of available data</a></li>
|
|||
|
|
<li><a href="#content-of-each-table">Content of each table</a></li>
|
|||
|
|
<li><a href="#differentiating-between-source-values-source-concept-ids-and-standard-concept-ids">Differentiating between Source Values, Source Concept Ids, and Standard Concept Ids</a></li>
|
|||
|
|
<li><a href="#custom-source_to_concept_maps">Custom SOURCE_TO_CONCEPT_MAPs</a></li>
|
|||
|
|
</ul></li>
|
|||
|
|
</ul></li>
|
|||
|
|
<li><a href="#glossary-of-terms">Glossary of Terms</a></li>
|
|||
|
|
<li><a href="#standardized-vocabularies">Standardized Vocabularies</a><ul>
|
|||
|
|
<li><a href="#concept">CONCEPT</a><ul>
|
|||
|
|
<li><a href="#conventions">Conventions</a></li>
|
|||
|
|
</ul></li>
|
|||
|
|
<li><a href="#vocabulary">VOCABULARY</a><ul>
|
|||
|
|
<li><a href="#conventions-1">Conventions</a></li>
|
|||
|
|
</ul></li>
|
|||
|
|
<li><a href="#domain">DOMAIN</a><ul>
|
|||
|
|
<li><a href="#conventions-2">Conventions</a></li>
|
|||
|
|
</ul></li>
|
|||
|
|
<li><a href="#concept_class">CONCEPT_CLASS</a><ul>
|
|||
|
|
<li><a href="#conventions-3">Conventions</a></li>
|
|||
|
|
</ul></li>
|
|||
|
|
<li><a href="#concept_relationship">CONCEPT_RELATIONSHIP</a><ul>
|
|||
|
|
<li><a href="#conventions-4">Conventions</a></li>
|
|||
|
|
</ul></li>
|
|||
|
|
<li><a href="#relationship">RELATIONSHIP</a><ul>
|
|||
|
|
<li><a href="#conventions-5">Conventions</a></li>
|
|||
|
|
</ul></li>
|
|||
|
|
<li><a href="#concept_synonym">CONCEPT_SYNONYM</a><ul>
|
|||
|
|
<li><a href="#conventions-6">Conventions</a></li>
|
|||
|
|
</ul></li>
|
|||
|
|
<li><a href="#concept_ancestor">CONCEPT_ANCESTOR</a><ul>
|
|||
|
|
<li><a href="#conventions-7">Conventions</a></li>
|
|||
|
|
</ul></li>
|
|||
|
|
<li><a href="#source_to_concept_map">SOURCE_TO_CONCEPT_MAP</a><ul>
|
|||
|
|
<li><a href="#conventions-8">Conventions</a></li>
|
|||
|
|
</ul></li>
|
|||
|
|
<li><a href="#drug_strength">DRUG_STRENGTH</a><ul>
|
|||
|
|
<li><a href="#conventions-9">Conventions</a></li>
|
|||
|
|
</ul></li>
|
|||
|
|
</ul></li>
|
|||
|
|
<li><a href="#standardized-metadata">Standardized Metadata</a><ul>
|
|||
|
|
<li><a href="#cdm_source">CDM_SOURCE</a><ul>
|
|||
|
|
<li><a href="#conventions-10">Conventions</a></li>
|
|||
|
|
</ul></li>
|
|||
|
|
<li><a href="#metadata">METADATA</a><ul>
|
|||
|
|
<li><a href="#conventions-11">Conventions</a></li>
|
|||
|
|
</ul></li>
|
|||
|
|
</ul></li>
|
|||
|
|
<li><a href="#standardized-clinical-data-tables">Standardized Clinical Data Tables</a><ul>
|
|||
|
|
<li><a href="#person">PERSON</a><ul>
|
|||
|
|
<li><a href="#conventions-12">Conventions</a></li>
|
|||
|
|
</ul></li>
|
|||
|
|
</ul></li>
|
|||
|
|
</ul>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
<div id="license" class="section level1">
|
|||
|
|
<h1>License</h1>
|
|||
|
|
<p>© 2014 Observational Health Data Sciences and Informatics</p>
|
|||
|
|
<p>This work is based on work by the Observational Medical Outcomes Partnership (OMOP) and used under license from the FNIH at <a href="http://omop.fnih.org/publiclicense" class="uri">http://omop.fnih.org/publiclicense</a>.</p>
|
|||
|
|
<p>All derivative work after the OMOP CDM v4 specification is dedicated to the public domain. Observational Health Data Sciences and Informatics (OHDSI) has waived all copyright and related or neighboring rights to the extent allowed by law.</p>
|
|||
|
|
<p><a href="http://creativecommons.org/publicdomain/zero/1.0/"><embed src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAFgAAAAfCAMAAABUFvrSAAADAFBMVEUvLy/v7+/Pz88fHx8PDw/6+fdfX1+Pj4/f39+fn59vb29PT0+vr6/5+fne3t5lZWXq6ur9/f3n5+fl5eX39/fx8fExMTH7+/uOjo7Nzc3Z2dnz8/OEhIT+/v7k5OT29fPp6Og+Pj6QkJDd3d3q6efFxcWLi4vS0tLm5ub09PRBQUHi4uLV1dXs7Oy+vr4sLCzLy8vq6ueenp7Ozs74+Pjy8vJ6enr19fX5+Pa6uroKCwnT09OXl5e3t7fW1tbh4eGNjY329vZTU1MZGRlNTU1tbW2Kiop/f3/Kysro5+W/v78/Pz/t6uH///8AAAD////MzDP/zDMA/zMz/zNm/zOZ/zPM/zP//zMAAGYzAGZmAGaZAGbMAGb/AGYAM2YzM2ZmM2aZM2bMM2b/M2YAZmYzZmZmZmaZZmbMZmb/ZmYAmWYzmWZmmWaZmWbMmWb/mWYAzGYzzGZmzGaZzGbMzGb/zGYA/2Yz/2Zm/2aZ/2bM/2b//2YAAJkzAJlmAJmZAJnMAJn/AJkAM5kzM5lmM5mZM5nMM5n/M5kAZpkzZplmZpmZZpnMZpn/ZpkAmZkzmZlmmZmZmZnMmZn/mZkAzJkzzJlmzJmZzJnMzJn/zJkA/5kz/5lm/5mZ/5nM/5n//5kAAMwzAMxmAMyZAMzMAMz/AMwAM8wzM8xmM8yZM8zMM8z/M8wAZswzZsxmZsyZZszMZsz/ZswAmcwzmcxmmcyZmczMmcz/mcwAzMwzzMxmzMyZzMzMzMz/zMwA/8wz/8xm/8yZ/8zM/8z//8wAAP8zAP9mAP+ZAP/MAP//AP8AM/8zM/9mM/+ZM//MM///M/8AZv8zZv9mZv+ZZv/MZv//Zv8Amf8zmf9mmf+Zmf/Mmf//mf8AzP8zzP9mzP+ZzP/MzP//zP8A//8z//9m//+Z///M//////8AuP8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAIArWAAACuElEQVR4nLWWh3LbMAyGOVSRGnbsZs/uvfduutmCBd//cQqQkmInUu/i2LizLcnQR/DXD1ICw0oCRfi7kggi4EpiHmyBQi4bbEud5NFOTkcPnlxQ5A7sZi5mO18n42opYCnouCoUoio8Hf44ProjlgBmrlCtKMBnm+N372OGd87lpI/mj6YTkiyP83NUQl7EQobAOWXwrwJgvCQZfk4+HMQMh2DRefSBPh6VQggQ3U/yGbQSe0WL4JpkYF4c27MtqOZPR7sigUOQ0IF9ULIDaxokAzMI1iFraJHMFsnCtc3x6wR2BRYdmKLowB7L/2msQihifgglwyGZZG9yq5ECiqwDl75GcQKmaovBimlULrhiCKtRcskh7OyPtxopKA+BiQwGBtNDZI2trMpYUS/Yx9ljFoKFVgvSJd9YX+vAcU4m/WXinJDBwtKEsyGwoJs5Ma5JnquL9fvR5bWZzMz3AwbszuDQgYugIz+KfAp8zpivWIcaGim6inNamBwVWwHUIgighJIdpvlLQC6AFIEzdc9rTAdwonECkysUGcejNVJqz93EPUK9QXd4dgY/0zPtN++KYLkJ2RWSXLGx3rqC/FATpoqYWiODraUbE1gNgFUcPvmYuEElH9/YH4cGXKFnCaJzFTpqfbqUW5XABut+cH/n+dGjgxZsCNxOnOZT0ygFKok6XqH/BsCNrmmtqGRa7R6/vLuVwNTSlhYp5SLJk1wAGZ0aNAms5QCYhWUer262WUXL7c2PMYNdUdDm4iyqip9/CZkxHghVF9EVgmzS64pE0tCuxzVh8umbh99PJ58n2h2EpyIMSAmGt778cDS5fxHuzJ4307BZfbj96tuFuDO7tHTNLi2MxOnG3vPrt38tHF/m3ytk914xvbf+effp74XjBYG3L/XE2yvy2dU/i8fNsMJ3txXFPwrIzuqhQm/LAAAAAElFTkSuQmCC"></embed></a></p>
|
|||
|
|
</div>
|
|||
|
|
<div id="background" class="section level1">
|
|||
|
|
<h1>Background</h1>
|
|||
|
|
<p><a href="https://github.com/OHDSI/CommonDataModel/wiki/The-Role-of-the-Common-Data-Model">The Role of the Common Data Model</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/Design-Principles">Design Principles</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/Data-Model-Conventions">Data Model Conventions</a></p>
|
|||
|
|
<p>The Observational Medical Outcomes Partnership (OMOP) was a public-private partnership established to inform the appropriate use of observational healthcare databases for studying the effects of medical products. Over the course of the 5-year project and through its community of researchers from industry, government, and academia, OMOP successfully achieved its aims to:</p>
|
|||
|
|
<ul>
|
|||
|
|
<li>Conduct methodological research to empirically evaluate the performance of various analytical methods on their ability to identify true associations and avoid false findings</li>
|
|||
|
|
<li>Develop tools and capabilities for transforming, characterizing, and analysing disparate data sources across the health care delivery spectrum</li>
|
|||
|
|
<li>Establish a shared resource so that the broader research community can collaboratively advance the science</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>The results of OMOP’s research has been widely published and presented at scientific conferences, including <a href="https://www.ohdsi.org/events/2018-ohdsi-symposium/">annual symposia</a>.</p>
|
|||
|
|
<p>The OMOP Legacy continues…</p>
|
|||
|
|
<p>The community is actively using the OMOP Common Data Model for their various research purposes. Those tools will continue to be maintained and supported, and information about this work is available in the public domain.</p>
|
|||
|
|
<p>The Observational Health Data Sciences and Informatics (OHDSI) has been established as a multi-stakeholder, interdisciplinary collaborative to create open-source solutions that bring out the value of observational health data through large-scale analytics. The OHDSI collaborative includes all of the original OMOP research investigators, and will develop its tools using the OMOP Common Data Model. Learn more at <a href="http://ohdsi.org">ohdsi.org</a>.</p>
|
|||
|
|
<p>The OMOP Common Data Model will continue to be an open-source community standard for observational healthcare data. The model specifications and associated work products will be placed in the public domain, and the entire research community is encouraged to use these tools to support everybody’s own research activities.</p>
|
|||
|
|
<div id="the-role-of-the-common-data-model" class="section level2">
|
|||
|
|
<h2>The Role of the Common Data Model</h2>
|
|||
|
|
<p>No single observational data source provides a comprehensive view of the clinical data a patient accumulates while receiving healthcare, and therefore none can be sufficient to meet all expected outcome analysis needs. This explains the need for assessing and analyzing multiple data sources concurrently using a common data standard. This standard is provided by the OMOP Common Data Model (CDM).</p>
|
|||
|
|
<p>The CDM is designed to support the conduct of research to identify and evaluate associations between interventions (drug exposure, procedures, healthcare policy changes etc.) and outcomes caused by these interventions (condition occurrences, procedures, drug exposure etc.). Outcomes can be efficacious (benefit) or adverse (safety risk). Often times, specific patient cohorts (e.g., those taking a certain drug or suffering from a certain disease) may be defined for treatments or outcomes, using clinical events (diagnoses, observations, procedures, etc.) that occur in predefined temporal relationships to each other. The CDM, combined with its standardized content (via the Standardized Vocabularies), will ensure that research methods can be systematically applied to produce meaningfully comparable and reproducible results.</p>
|
|||
|
|
</div>
|
|||
|
|
<div id="design-principles" class="section level2">
|
|||
|
|
<h2>Design Principles</h2>
|
|||
|
|
<p>The CDM is designed to include all observational health data elements (experiences of the patient receiving health care) that are relevant for analysis use cases to support the generation of reliable scientific evidence about disease natural history, healthcare delivery, effects of medical interventions, the identification of demographic information, health care interventions and outcomes.</p>
|
|||
|
|
<p>Therefore, the CDM is designed to store observational data to allow for research, under the following principles:</p>
|
|||
|
|
<ul>
|
|||
|
|
<li><strong>Suitability for purpose:</strong> The CDM aims to provide data organized in a way optimal for analysis, rather than for the purpose of addressing the operational needs of health care providers or payers.</li>
|
|||
|
|
<li><strong>Data protection:</strong> All data that might jeopardize the identity and protection of patients, such as names, precise birthdays etc. are limited. Exceptions are possible where the research expressly requires more detailed information, such as precise birth dates for the study of infants.</li>
|
|||
|
|
<li><strong>Design of domains:</strong> The domains are modeled in a person-centric relational data model, where for each record the identity of the person and a date is captured as a minimum.</li>
|
|||
|
|
<li><strong>Rationale for domains:</strong> Domains are identified and separately defined in an entity-relationship model if they have an analysis use case and the domain has specific attributes that are not otherwise applicable. All other data can be preserved as an observation in an entity-attribute-value structure.</li>
|
|||
|
|
<li><strong>Standardized Vocabularies:</strong> To standardize the content of those records, the CDM relies on the Standardized Vocabularies containing all necessary and appropriate corresponding standard healthcare concepts.</li>
|
|||
|
|
<li><strong>Reuse of existing vocabularies:</strong> If possible, these concepts are leveraged from national or industry standardization or vocabulary definition organizations or initiatives, such as the National Library of Medicine, the Department of Veterans’ Affairs, the Center of Disease Control and Prevention, etc.</li>
|
|||
|
|
<li><strong>Maintaining source codes:</strong> Even though all codes are mapped to the Standardized Vocabularies, the model also stores the original source code to ensure no information is lost.</li>
|
|||
|
|
<li><strong>Technology neutrality:</strong> The CDM does not require a specific technology. It can be realized in any relational database, such as Oracle, SQL Server etc., or as SAS analytical datasets.</li>
|
|||
|
|
<li><strong>Scalability:</strong> The CDM is optimized for data processing and computational analysis to accommodate data sources that vary in size, including databases with up to hundreds of millions of persons and billions of clinical observations.</li>
|
|||
|
|
<li><strong>Backwards compatibility:</strong> All changes from previous CDMs are clearly delineated in the <a href="https://github.com/OHDSI/CommonDataModel">github repository</a>. Older versions of the CDM can be easily created from the CDMv5, and no information is lost that was present previously.</li>
|
|||
|
|
</ul>
|
|||
|
|
</div>
|
|||
|
|
<div id="data-model-conventions" class="section level2">
|
|||
|
|
<h2>Data Model Conventions</h2>
|
|||
|
|
<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-conventions-of-schemas" class="section level3">
|
|||
|
|
<h3>General conventions of schemas</h3>
|
|||
|
|
<p>New to CDM v6.0 is the concept of schemas. This allows for more separation between read-only and writeable tables. The clinical data, event, and vocabulary tables are in the ‘CDM’ schema and tables that need to be manipulated by web-based tools or end users have moved to the ‘Results’ schema. Currently the only two tables in the ‘Results’ schema are COHORT and COHORT_DEFINITON, though likely more will be added over the course of v6.0 point releases.</p>
|
|||
|
|
</div>
|
|||
|
|
<div id="general-conventions-of-data-tables" class="section level3">
|
|||
|
|
<h3>General conventions of data tables</h3>
|
|||
|
|
<p>The 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>
|
|||
|
|
<p>In most cases, the first field in each table ends in ’_ID’, containing a record identifier that can be used as a foreign key in another table.</p>
|
|||
|
|
</div>
|
|||
|
|
<div id="general-conventions-of-fields" class="section level3">
|
|||
|
|
<h3>General conventions of fields</h3>
|
|||
|
|
<p>Variable names across all tables follow one convention:</p>
|
|||
|
|
<table>
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="30%"></col>
|
|||
|
|
<col width="69%"></col>
|
|||
|
|
</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 id="representation-of-content-through-concepts" class="section level3">
|
|||
|
|
<h3>Representation of content through 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="difference-between-concept-ids-and-source-values" class="section level3">
|
|||
|
|
<h3>Difference between 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="difference-between-general-concepts-and-type-concepts" class="section level3">
|
|||
|
|
<h3>Difference between general Concepts and Type Concepts</h3>
|
|||
|
|
<p>Type Concepts (ending in _TYPE_CONCEPT_ID) and general Concepts (ending in _CONCEPT_ID) are part of many tables. The former are special Concepts with the purpose of indicating where the data are derived from 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>
|
|||
|
|
</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. If a time of 00:00:00 is given in the source data it should be shifted to 00:00:01 (<a href="https://github.com/OHDSI/Themis/issues/10">THEMIS issue #10</a>).</p>
|
|||
|
|
</div>
|
|||
|
|
<div id="content-of-each-table" class="section level3">
|
|||
|
|
<h3>Content of each table</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="differentiating-between-source-values-source-concept-ids-and-standard-concept-ids" class="section level3">
|
|||
|
|
<h3>Differentiating between 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 (<a href="https://github.com/OHDSI/Themis/issues/15">THEMIS issue #15</a>).</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_maps" class="section level3">
|
|||
|
|
<h3>Custom SOURCE_TO_CONCEPT_MAPs</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 id="glossary-of-terms" class="section level1">
|
|||
|
|
<h1>Glossary of Terms</h1>
|
|||
|
|
<p>Glossary of Terms</p>
|
|||
|
|
<table>
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="35%"></col>
|
|||
|
|
<col width="7%"></col>
|
|||
|
|
<col width="56%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th>Term</th>
|
|||
|
|
<th>Abbr.</th>
|
|||
|
|
<th>Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td>Ancestor</td>
|
|||
|
|
<td></td>
|
|||
|
|
<td>The higher level Concept in a hierarchical relationship. Note that ancestors and descendants can be many levels apart from each other.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td>Average Wholesale Price</td>
|
|||
|
|
<td>AWP</td>
|
|||
|
|
<td>The price manufacturers set for prescription drugs to be purchased at the wholesale level to pharmacies and healthcare provider.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td>Centers for Disease Control and Prevention</td>
|
|||
|
|
<td>CDC</td>
|
|||
|
|
<td>The Centers for Disease Control and Prevention is a United States federal agency under the Department of Health and Human Services. It works to protect public health and safety by providing information to enhance health decisions.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td>Common Data Model</td>
|
|||
|
|
<td>CDM</td>
|
|||
|
|
<td>The CDM intends to facilitate observational analyses of disparate healthcare databases. The CDM defines table structures for each of the data entities (e.g., Persons, Visit Occurrence, Drug Exposure, Condition Occurrence, Observation, Procedure Occurrence, etc.). It includes observational data elements that are relevant to identifying exposure to various treatments and defining condition occurrence. The CDM includes both the Standardized Vocabularies of terms and the entity domain tables.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td>Concept</td>
|
|||
|
|
<td></td>
|
|||
|
|
<td>A concept is the basic unit of information. Concepts may be grouped into a given domain. A concept is a unique term that has a unique and static identifier/name, belongs to a domain, and may exist in relation to other concepts. The vertical relationships consist of “is a” statements that form a logical hierarchy. In general, concepts above a given concept are referred to as ancestors and those below as descendants.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td>Conceptual Data Model</td>
|
|||
|
|
<td></td>
|
|||
|
|
<td>A conceptual data model is a map of concepts and their relationships. This describes the semantics of an organization and represents a series of assertions about its nature. Specifically, it describes the things of significance to an organization (entity classes), about which it is inclined to collect information, and characteristics of (attributes) and associations between pairs of those things of significance (relationships).</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td>Data mapping</td>
|
|||
|
|
<td></td>
|
|||
|
|
<td>It is the data element mappings between two distinct data models, terminologies, or concepts. Data mapping is the process of creating data element mappings between two distinct data models. Data mapping is used as a first step for a wide variety of data integration tasks.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td>Demographics</td>
|
|||
|
|
<td></td>
|
|||
|
|
<td>Demographics refer to selected characteristics of persons. Demographics may include data such as race, age, sex, date of birth, location, etc.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td>Descendant</td>
|
|||
|
|
<td></td>
|
|||
|
|
<td>The lower level Concept in a hierarchical relationship. Note that ancestors and descendants can be many levels apart from each other.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td>Design Principle</td>
|
|||
|
|
<td></td>
|
|||
|
|
<td>An organized arrangement of one or more elements or principles for a purpose. It identifies core principles and best practices to assist developers to produce software. Thoroughly understanding the goals of stakeholders and designing systems with those goals in mind are the best approaches to successfully deliver results.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td>Electronic Health Record</td>
|
|||
|
|
<td>EHR</td>
|
|||
|
|
<td>Electronic health record refers to an individual person’s medical record in digital format. It may be made up of electronic medical records from many locations and/or sources. The EHR is a longitudinal electronic record of person health information generated by one or more encounters in any care delivery setting. Included in this information are person demographics, progress notes, problems, medications, vital signs, past medical history, immunizations, laboratory data and radiology reports.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td>Electronic Medical Record</td>
|
|||
|
|
<td>EMR</td>
|
|||
|
|
<td>An electronic medical record is a computerized medical record created in an organization that delivers care, such as a hospital or outpatient setting. Electronic medical records tend to be a part of a local stand-alone health information system that allows storage, retrieval and manipulation of records. This document will reference EHR moving forward even if specific data source might internally use EMR definition.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td>Extract Transform Load</td>
|
|||
|
|
<td>ETL</td>
|
|||
|
|
<td>Process of getting data out of one data store (Extract), modifying it (Transform), and inserting it into a different data store (Load).</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td>Health Insurance Portability and Accountability Act</td>
|
|||
|
|
<td>HIPAA</td>
|
|||
|
|
<td>A federal law that was designed to allow portability of health insurance between jobs. In addition, it required the creation of a federal law to protect personally identifiable health information; if that did not occur by a specific date (which it did not), HIPAA directed the Department of Health and Human Services (DHHS) to issue federal regulations with the same purpose. DHHS has issued HIPAA privacy regulations (the HIPAA Privacy Rule) as well as other regulations under HIPAA.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td>Logical Data Model</td>
|
|||
|
|
<td></td>
|
|||
|
|
<td>Logical data models are graphical representation of the business requirements. They describe the things of importance to an organization and how they relate to one another, as well as business definitions and examples. The logical data model can be validated and approved by a business representative, and can be the basis of physical database design.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td>Primary Care Provider</td>
|
|||
|
|
<td>PCP</td>
|
|||
|
|
<td>A health care provider designated as responsible to provide general medical care to a patient, including evaluation and treatment as well as referral to specialists.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td>Protected Health Information</td>
|
|||
|
|
<td>PHI</td>
|
|||
|
|
<td>Protected health information under HIPAA includes any individually identifiable health information. Identifiable refers not only to data that is explicitly linked to a particular individual (that’s identified information). It also includes health information with data items which reasonably could be expected to allow individual identification. De-identified information is that from which all potentially identifying information has been removed.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td>Terminology</td>
|
|||
|
|
<td></td>
|
|||
|
|
<td>Technical or special terms used in a business or special subject area.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td>Vocabulary</td>
|
|||
|
|
<td></td>
|
|||
|
|
<td>A computerized list (as of items of data or words) used for reference (as for information retrieval or word processing).</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
<div id="standardized-vocabularies" class="section level1">
|
|||
|
|
<h1>Standardized Vocabularies</h1>
|
|||
|
|
<p><a href="https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT">CONCEPT</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/VOCABULARY">VOCABULARY</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/DOMAIN">DOMAIN</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_CLASS">CONCEPT_CLASS</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_RELATIONSHIP">CONCEPT_RELATIONSHIP</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/RELATIONSHIP">RELATIONSHIP</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_SYNONYM">CONCEPT_SYNONYM</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_ANCESTOR">CONCEPT_ANCESTOR</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/SOURCE_TO_CONCEPT_MAP">SOURCE_TO_CONCEPT_MAP</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/DRUG_STRENGTH">DRUG_STRENGTH</a></p>
|
|||
|
|
<p>These tables contain detailed information about the Concepts used in all of the CDM fact tables. The content of the Standardized Vocabularies tables is not generated anew by each CDM implementation. Instead, it is maintained centrally as a service to the community.</p>
|
|||
|
|
<p>A number of assumptions were made for the design of the Standardized Vocabularies tables:</p>
|
|||
|
|
<ul>
|
|||
|
|
<li>There is one design which will accommodate all different source terminologies and classifications.</li>
|
|||
|
|
<li>All terminologies are loaded into the CONCEPT table.</li>
|
|||
|
|
<li>The key is a newly created concept_id, not the original code of the terminology, because source codes are not unique identifiers across terminologies.</li>
|
|||
|
|
<li>Some Concepts are declared Standard Concepts, i.e. they are used to represent a certain clinical entity in the data. All Concepts may be Source Concepts; they represent how the entity was coded in the source. Standard Concepts are identified through the standard_concept field in the CONCEPT table.</li>
|
|||
|
|
<li>Records in the CONCEPT_RELATIONSHIP table define semantic relationships between Concepts. Such relationships can be hierarchical or lateral.</li>
|
|||
|
|
<li>Records in the CONCEPT_RELATIONSHIP table are used to map Source codes to Standard Concepts, replacing the mechanism of the SOURCE_TO_CONCEPT_MAP table used in prior Standardized Vocabularies versions. The SOURCE_TO_CONCEPT_MAP table is retained as an optional aid to bookkeeping codes not found in the Standardized Vocabularies.</li>
|
|||
|
|
<li>Chains of hierarchical relationships are recorded in the CONCEPT_ANCESTOR table. Ancestry relationships are only recorded between Standard Concepts that are valid (not deprecated) and are connected through valid and hierarchical relationships in the RELATIONSHIP table (flag DEFINES_ANCESTRY).</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>The advantage of this approach lies in the preservation of codes and relationships between them without adherence to the multiple different source data structures, a simple design for standardized access, and the optimization of performance for analysis. Navigation among Standard Concepts does not require knowledge of the source vocabulary. Finally, the approach is scalable and future vocabularies can be integrated easily. On the other hand, extensive transformation of source data to the Vocabulary is required and not every source data structure and original source hierarchy can be retained.</p>
|
|||
|
|
<p>Below is an entity-relationship diagram highlighting the tables within the Vocabulary portion of the OMOP Common Data Model:</p>
|
|||
|
|
<div class="figure">
|
|||
|
|
<embed src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA5IAAALWCAIAAAC7rTuLAAAACXBIWXMAAAsSAAALEgHS3X78AADJ7klEQVR42uy9C5gU1Z3/3dlsYnzQjVmVGSAiKrLICKIIhvYWzW4MuppVNJc1/5gxUPvPZlffbGLeR30SSbKb1VeBdhOdNV5A141ZIroyWjojg4KsI4EZbmFgaG4zg6BLRhlGJShQb126qk6dS1V1TXX1qerv5zkPVJ+q+tXv9Ex3f+b0qXNyGgAAAAAAANKTq3YCAAAAAAAABANtBQAAAAAAKQDaCkD6+WjAKrmchoKCEq04r6NSAQDIB7QVgPRjOyv9uYuCghK60K8gAIB8QFsBSD8fHTA/cQ+goKAMpXheRwAA+YC2ApB64Kyhyua78zkXpZmtnFbYbFdOv7tInmg/LM6d5hydn7s28EL5uU8Xpuco8rMa+Rf1HDWt0GzUuFcRpiG4hKAJKGHNFQAgH9BWANKN8Sl7eBAluGy5Jz/9nqKzbZgrW9moUkcSD4vzpuXc+vWF2cQxbnlG0Y1zi709+xn+1QMvWqppVKbb0QLTEF2CGxxFXEqvKQCAfEBbAUg30NYo2uo89FTqxumjraSP+hQ7iM/Vw1zUqWluzFnuG5gGtBXaCkDWgbYCkG6grRG11fJFslIXRGs7WHD9ijrb/J7e6Wf1d0ryouTX/MQV9YBux7BPGkx3co4KWPUfQUqK9Zp66KGHqv3iBgDQQFsBSDfmR+x7KMGlZHVOja6tN6uk3jl7qSM9vqjXbCiNJfVEY0rzzba8MjHDXJSsIRPwSYO6BNuEqv8IUlKs19RDJtV+fQMAPEBbAUg36G2N2NtKdV46Y0wPhxskEKrzlRgwwO1t9bmot6Y4b5oyLygNDBKIu7cV5gqAbEBbAUg36G2N1Nuqy19OafZWGv2jN6ulvboalk40boEyO03te6F8+y/1elEPK3fbuahPb6udsHV1YRroba1Abyu0FQCpgLYCkG6grWVoKzm91BaOzxlGaO3ifo9fOsCeZGreBt6FNhDTUbnu6+OUpYs238NMgOV1TV1w7Yf8NKCt0FYAsg60FYB0Y3zEHnkPBQUlrmK9pqCtAEgItBWAdGN+xL6PUqXyrELP9P+5wtaqZ4UypGK9pqCtAEgItBWAdANtRUGJt0BbAZAWaCsA6cb8iP0ABQUlrmK9pqCtAEgItBWAdGMuob7fKvo2CgpKtEK+jh4iqPZLHADgAm0FIN04H7c5vJoBGALkSwnaCoCc4IMOgHRT+qwlODLY99brcyc2ttRdp07+dqu+rddUO00AUoD1aoK2AiAt0FYA0k3p+00b3VAPdM4fcX3r8JlLR92wdORXlunbeg1rru2/zPmXarcMgCpgvaCgrQDICT6ZAEg3pLO++/aOnuX31c9sPaNx9fAZC4ZNuKluxsLxsztP+Wrbzlfv1fc6RwY6K0dbi1qeGAioqJzKQtGuzGtF8kT7YbHgHpwviFulEoMOFTsMe655dTcOdV0qiDdVI1vVU6M3qJCnxzvSSRJBVO4TAtIPtBUAaYG2ApBuSG19f+fSumuXjPrmurOU9WO//uJJl9/f8K2Wz31/68R/2HL2za37Nr/kHGlY6f5bREWorY4UmsZmiBpTqWpCbTW8k6gvKMQx5HUKJYm0UBVjmzpXsYTSjKzkObrMCUJlReWpEvHZI7lncZ8QkH6grQBIC7QVgHRDauuh3rbh1zU3fLf74tt7rvxJ3xU/3nnVT/uu/ue9l97RO2lWW393i3Okpa1uxypvm74SV0a9lYqvtipOd6wvhTznMPpc8uqq3SNLXJcTxF9bneS1SNoaeBZID9BWAKQF2gpAuiG1dWfnkunfebnuhldHfW3F6L99zSmnfWPl529dtr3jOefIofa2mig5bxem02EZQnCFOF22vpemrq4q3q5fURByAIA3JU9vbjRtJcUXpBloKwDSAm0FIN2Q2npwsP/ltk2P/XxS68KLV/zXjPZnb1j59DVt/3nFE/dObWnbpO91joxTW0kR5B7JaGtpCClXDbnKGKSt9CVCBuEmr0Fbax1oKwDSAm0FIN2w07V2bNUev/3jXU+e8OGqC4qL6vVtvYYiBm1lTVH0JTt3kIBYDbljCfwGCVgVBU0puA85QYIGCQTXU3sxSCCjQFsBkBZoKwDphrvKwMqNWnvTMF1b1zx6or7NMnRtVdhbslT3LijSGo3v3xV7I8QX8eXekkVW5sgv/cu6JStMPbWX+4SA9ANtBUBaoK0ApBtKWwff/3DXnoOLlx9e+9hnArW17Fuygua6smTR2CX4/j3kBFjkYdwJsNzpt6gZrwTXEk6AVa62iifACnO3GUgF0FYApAXaCkC6obS1Z8/g3Y9uaV/YsH3xmMNrLoyztxWA2gDaCoC04JMJgHRDaeuG7v75tzWsWjD2rZaGo52X+GirJEtkKd4eUNm6LSVPD1QCaCsA0gJtBSDdUNq6rXdgzoOb31g4vrd5nK6tGxdNWd4xUO0cAUgT0FYApAXaCkC6YW/J2t47cNcDXe0LxncvGn3nL7buevNAtXMEIE1AWwGQFmgrAOkmhxcxALECbQVAWvCJB0C6YbX1yGDfW6/PndjYUnedOvnbrfq2XlPtNAFIDdBWAKQF2gpAuqG0VTfUA53zR1zfOnzm0lE3LB35lWX6tl7Dmqs8d2UBIBXQVgCkBZ9MAKQbUlvffXtHz/L76me2ntG4eviMBcMm3FQ3Y+H42Z2nfLVt56v36nudIwOd1X/eVmvKUnfiVe9qVZ6ZWUWzvbJTqOZ407IKJkl1TqFyUPL0jf/C2WHVgKlhSyeKW0pHCGqU6qxq65+euNVYziAZoK0ASAu0FYB0Q2rrmxtfmNT40sgbV5357Y4RVzxwsPeVz854cMotm876u/X57y7tWdfsHBlx3lbvAlG6I1KLDlBrWRUUz/qr7gKw/gtWmYfRCwoITmFz0LTgdVbLXYiL39KyVuFSQ60Qxn2eOU8LqCTQVgCkBdoKQLohtfVQb9uJX15y+qxN593aPfUfOxsal134T+suv3PX1O/vaGh8ub+7xTkyFm0tqnY/pV2vsNOaMiugBmurxvM20SlMDpoW7IWFPGf6VTp5K4jgKpwIQY1SHM2Npq1hTgRxAG0FQFqgrQCkG88gga0tZ35DHTtr3bm3dF1021anTP1/Nk/7zrK9v3d76qIs7qpxdEpVzP4/0vBEp2hEjyP1fTrvXFpwxad4cmAvym0F0VGqiU9Rcm4fKt1SbgRxozxduZG1lXRfUDGgrQBIC7QVgHRDauvu7vbLv/nzL876l2tvuff6782/4fu/vOGf7r/u1nl//Z3/76++9XN9r3NkPL2tmldYCccqDeK0Dc81OSoOG9mGo62iU1hpDtRWf70mcwhqqV8EbtsD09OgrVUG2gqAtEBbAUg31EwC/Qe0R144uvpXx/Y8U/fhqgv2PH/qmoePe7j5cL93zYEot2RpfJ0qFjSlwBskQBke2UMZ4yABJgd+fC9KrsxBAv4tDdmowHrf5znUiSAOoK0ASAu0FYB0w87bqhvqY+rRNQ8fr2vr+sdP1rf7meVdY+ttNVHs3kTOV+HMrfdhxrYqoW/JYnPQtGC9K/eWLH5Ly7olK0x9iOcZt2QlALQVAGmBtgKQbrirZK3cqLU3DdO1dc2jJ+rbLFHGtlITM5HiRdwmz5kAizjS2kvNDMXWsPNk8SfAEuQQpleSzJM7ARbtzb4tFU6AFUFbxa0uoKM1EaCtAEgLtBWAdENpa8emfT9STn/oh8fvVccFamvZva0A1ADQVgCkBZ9MAKQbSlt79gze/eiW9oUN2xePObzmQmirZn2zT/WDytRtKXl6NQi0FQBpyc4nEwC1CaWtG7r759/WsGrB2LdaGo52XuKjrVjZFQAu0FYApAUfTgCkG0pbt/UOzHlw8xsLx/c2j9O1deOiKcs7BiKGBqAmgbYCIC3QVgDSDXtL1vbegbse6GpfML570eg7f7F115sHosQFoFaBtgIgLdBWANJNDi9iAGIF2gqAtOATD4B0A20FIF6grQBICz7xA
|
|||
|
|
<p class="caption">Vocabulary entity-relationship diagram</p>
|
|||
|
|
</div>
|
|||
|
|
<div id="concept" class="section level2">
|
|||
|
|
<h2>CONCEPT</h2>
|
|||
|
|
<p>The Standardized Vocabularies contains records, or Concepts, that uniquely identify each fundamental unit of meaning used to express clinical information in all domain tables of the CDM. Concepts are derived from vocabularies, which represent clinical information across a domain (e.g. conditions, drugs, procedures) through the use of codes and associated descriptions. Some Concepts are designated Standard Concepts, meaning these Concepts can be used as normative expressions of a clinical entity within the OMOP Common Data Model and within standardized analytics. Each Standard Concept belongs to one domain, which defines the location where the Concept would be expected to occur within data tables of the CDM.</p>
|
|||
|
|
<p>Concepts can represent broad categories (like ‘Cardiovascular disease’), detailed clinical elements (‘Myocardial infarction of the anterolateral wall’) or modifying characteristics and attributes that define Concepts at various levels of detail (severity of a disease, associated morphology, etc.).</p>
|
|||
|
|
<p>Records in the Standardized Vocabularies tables are derived from national or international vocabularies such as SNOMED-CT, RxNorm, and LOINC, or custom Concepts defined to cover various aspects of observational data analysis. For a detailed description of these vocabularies, their use in the OMOP CDM and their relationships to each other please refer to the <a href="http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary">specifications</a>.</p>
|
|||
|
|
<table>
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="23%"></col>
|
|||
|
|
<col width="13%"></col>
|
|||
|
|
<col width="19%"></col>
|
|||
|
|
<col width="43%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">Field</th>
|
|||
|
|
<th align="left">Required</th>
|
|||
|
|
<th align="left">Type</th>
|
|||
|
|
<th align="left">Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">concept_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A unique identifier for each Concept across all domains.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">concept_name</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(255)</td>
|
|||
|
|
<td align="left">An unambiguous, meaningful and descriptive name for the Concept.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">domain_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(20)</td>
|
|||
|
|
<td align="left">A foreign key to the <a href="https://github.com/OHDSI/CommonDataModel/wiki/DOMAIN">DOMAIN</a> table the Concept belongs to.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">vocabulary_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(20)</td>
|
|||
|
|
<td align="left">A foreign key to the <a href="https://github.com/OHDSI/CommonDataModel/wiki/VOCABULARY">VOCABULARY</a> table indicating from which source the Concept has been adapted.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">concept_class_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(20)</td>
|
|||
|
|
<td align="left">The attribute or concept class of the Concept. Examples are ‘Clinical Drug’, ‘Ingredient’, ‘Clinical Finding’ etc.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">standard_concept</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">varchar(1)</td>
|
|||
|
|
<td align="left">This flag determines where a Concept is a Standard Concept, i.e. is used in the data, a Classification Concept, or a non-standard Source Concept. The allowables values are ‘S’ (Standard Concept) and ‘C’ (Classification Concept), otherwise the content is NULL.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">concept_code</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(50)</td>
|
|||
|
|
<td align="left">The concept code represents the identifier of the Concept in the source vocabulary, such as SNOMED-CT concept IDs, RxNorm RXCUIs etc. Note that concept codes are not unique across vocabularies.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">valid_start_date</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">date</td>
|
|||
|
|
<td align="left">The date when the Concept was first recorded. The default value is 1-Jan-1970, meaning, the Concept has no (known) date of inception.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">valid_end_date</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">date</td>
|
|||
|
|
<td align="left">The date when the Concept became invalid because it was deleted or superseded (updated) by a new concept. The default value is 31-Dec-2099, meaning, the Concept is valid until it becomes deprecated.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">invalid_reason</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">varchar(1)</td>
|
|||
|
|
<td align="left">Reason the Concept was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<div id="conventions" class="section level3">
|
|||
|
|
<h3>Conventions</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>
|
|||
|
|
<table style="width:67%;">
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="13%"></col>
|
|||
|
|
<col width="52%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">No.</th>
|
|||
|
|
<th align="left">Convention Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">1</td>
|
|||
|
|
<td align="left">All Concepts are maintained centrally by the CDM and Vocabularies Working Group. Additional concepts can be added, as needed, upon request.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">2</td>
|
|||
|
|
<td align="left">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.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">3</td>
|
|||
|
|
<td align="left">The concept_id of a Concept is persistent, i.e. stays the same for the same Concept between releases of the Standardized Vocabularies.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">4</td>
|
|||
|
|
<td align="left">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://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_SYNONYM">CONCEPT_SYNONYM</a> table.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">5</td>
|
|||
|
|
<td align="left">Each Concept is assigned to a Domain. For Standard Concepts, these 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 <a href="http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary">specification</a> for details of the Domain Assignment.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">6</td>
|
|||
|
|
<td align="left">For details of the Vocabularies adopted for use in the OMOP CDM refer to the Standardized Vocabularies specification.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">7</td>
|
|||
|
|
<td align="left">Concept Class designation 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.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">8</td>
|
|||
|
|
<td align="left">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.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">9</td>
|
|||
|
|
<td align="left">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.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">10</td>
|
|||
|
|
<td align="left">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 <a href="https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_ANCESTOR">CONCEPT_ANCESTOR</a> table and can be used to identify Descendants that may appear in the data. See <a href="https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_ANCESTOR">CONCEPT_ANCESTOR</a> table. Non-standard Concepts can only appear in *_source_concept_id fields and are not used in CONCEPT_ANCESTOR table. Please refer to the Standardized Vocabularies <a href="http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:standard_classification_and_source_concepts">specifications</a> for details of the Standard Concept designation.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">11</td>
|
|||
|
|
<td align="left">All logical data elements associated with the various CDM tables (usually in the <domain>_type_concept_id field) are called Type Concepts, including defining characteristics, qualifying attributes etc. They are also stored as Concepts in the CONCEPT table. Since they are generated by OMOP, their is no meaningful concept_code.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">12</td>
|
|||
|
|
<td align="left">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.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">13</td>
|
|||
|
|
<td align="left">Concepts without a known instantiated date are assigned valid_start_date of ‘1-Jan-1970’.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">14</td>
|
|||
|
|
<td align="left">Concepts that are not invalid are assigned valid_end_date of ‘31-Dec-2099’.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">15</td>
|
|||
|
|
<td align="left">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 <a href="https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_RELATIONSHIP">CONCEPT_RELATIONSHIP</a> table indicating their active replacement Concept.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">16</td>
|
|||
|
|
<td align="left">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.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<div id="vocabulary" class="section level2">
|
|||
|
|
<h2>VOCABULARY</h2>
|
|||
|
|
<p>The VOCABULARY table includes a list of the Vocabularies collected from various sources or created de novo by the OMOP community. This reference table is populated with a single record for each Vocabulary source and includes a descriptive name and other associated attributes for the Vocabulary.</p>
|
|||
|
|
<table>
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="26%"></col>
|
|||
|
|
<col width="10%"></col>
|
|||
|
|
<col width="16%"></col>
|
|||
|
|
<col width="46%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">Field</th>
|
|||
|
|
<th align="left">Required</th>
|
|||
|
|
<th align="left">Type</th>
|
|||
|
|
<th align="left">Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">vocabulary_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(20)</td>
|
|||
|
|
<td align="left">A unique identifier for each Vocabulary, such as ICD9CM, SNOMED, Visit.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">vocabulary_name</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(255)</td>
|
|||
|
|
<td align="left">The name describing the vocabulary, for example “International Classification of Diseases, Ninth Revision, Clinical Modification, Volume 1 and 2 (NCHS)” etc.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">vocabulary_reference</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(255)</td>
|
|||
|
|
<td align="left">External reference to documentation or available download of the about the vocabulary.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">vocabulary_version</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">varchar(255)</td>
|
|||
|
|
<td align="left">Version of the Vocabulary as indicated in the source.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">vocabulary_concept_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key that refers to a standard concept identifier in the CONCEPT table for the Vocabulary the VOCABULARY record belongs to.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<div id="conventions-1" class="section level3">
|
|||
|
|
<h3>Conventions</h3>
|
|||
|
|
<table style="width:67%;">
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="13%"></col>
|
|||
|
|
<col width="52%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">No.</th>
|
|||
|
|
<th align="left">Convention Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">1</td>
|
|||
|
|
<td align="left">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 <a href="http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary">specifications</a> for details of each Vocabulary.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">2</td>
|
|||
|
|
<td align="left">The VOCABULARY_ID field contains an alphanumerical identifier, that can also be used as the abbreviation of the Vocabulary name.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">3</td>
|
|||
|
|
<td align="left">The record with VOCABULARY_ID = ‘None’ is reserved to contain information regarding the current version of the Entire Standardized Vocabularies.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">4</td>
|
|||
|
|
<td align="left">The VOCABULARY_NAME field contains the full official name of the Vocabulary, as well as the source or vendor in parenthesis.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">5</td>
|
|||
|
|
<td align="left">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.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<div id="domain" class="section level2">
|
|||
|
|
<h2>DOMAIN</h2>
|
|||
|
|
<p>The DOMAIN table includes a list of OMOP-defined Domains the Concepts of the Standardized Vocabularies can belong to. A Domain defines the set of allowable Concepts for the standardized fields in the CDM tables. For example, the “Condition” Domain contains Concepts that describe a condition of a patient, and these Concepts can only be stored in the condition_concept_id field of the <a href="https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_OCCURRENCE">CONDITION_OCCURRENCE</a> and <a href="https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_ERA">CONDITION_ERA</a> tables. This reference table is populated with a single record for each Domain and includes a descriptive name for the Domain.</p>
|
|||
|
|
<table>
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="25%"></col>
|
|||
|
|
<col width="12%"></col>
|
|||
|
|
<col width="17%"></col>
|
|||
|
|
<col width="44%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">Field</th>
|
|||
|
|
<th align="left">Required</th>
|
|||
|
|
<th align="left">Type</th>
|
|||
|
|
<th align="left">Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">domain_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(20)</td>
|
|||
|
|
<td align="left">A unique key for each domain.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">domain_name</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(255)</td>
|
|||
|
|
<td align="left">The name describing the Domain, e.g. “Condition”, “Procedure”, “Measurement” etc.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">domain_concept_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key that refers to an identifier in the <a href="https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT">CONCEPT</a> table for the unique Domain Concept the Domain record belongs to.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<div id="conventions-2" class="section level3">
|
|||
|
|
<h3>Conventions</h3>
|
|||
|
|
<table style="width:67%;">
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="13%"></col>
|
|||
|
|
<col width="52%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">No.</th>
|
|||
|
|
<th align="left">Convention Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">1</td>
|
|||
|
|
<td align="left">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.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">2</td>
|
|||
|
|
<td align="left">The DOMAIN_ID field contains an alphanumerical identifier, that can also be used as the abbreviation of the Domain.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">3</td>
|
|||
|
|
<td align="left">The DOMAIN_NAME field contains the unabbreviated names of the Domain.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">4</td>
|
|||
|
|
<td align="left">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 Concepts.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">5</td>
|
|||
|
|
<td align="left">Versions prior to v5.0.0 of the OMOP CDM did not support the notion of a Domain.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<div id="concept_class" class="section level2">
|
|||
|
|
<h2>CONCEPT_CLASS</h2>
|
|||
|
|
<p>The CONCEPT_CLASS table is a reference table, which includes a list of the classifications used to differentiate Concepts within a given Vocabulary. This reference table is populated with a single record for each Concept Class:</p>
|
|||
|
|
<table>
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="29%"></col>
|
|||
|
|
<col width="11%"></col>
|
|||
|
|
<col width="13%"></col>
|
|||
|
|
<col width="46%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">Field</th>
|
|||
|
|
<th align="left">Required</th>
|
|||
|
|
<th align="left">Type</th>
|
|||
|
|
<th align="left">Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">concept_class_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(20)</td>
|
|||
|
|
<td align="left">A unique key for each class.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">concept_class_name</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(255)</td>
|
|||
|
|
<td align="left">The name describing the Concept Class, e.g. “Clinical Finding”, “Ingredient”, etc.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">concept_class_concept_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key that refers to an identifier in the <a href="https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT">CONCEPT</a> table for the unique Concept Class the record belongs to.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<div id="conventions-3" class="section level3">
|
|||
|
|
<h3>Conventions</h3>
|
|||
|
|
<table style="width:67%;">
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="13%"></col>
|
|||
|
|
<col width="52%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">No.</th>
|
|||
|
|
<th align="left">Convention Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">1</td>
|
|||
|
|
<td align="left">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.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">2</td>
|
|||
|
|
<td align="left">The CONCEPT_CLASS_ID field contains an alphanumerical identifier, that can also be used as the abbreviation of the Concept Class.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">3</td>
|
|||
|
|
<td align="left">The CONCEPT_CLASS_NAME field contains the unabbreviated names of the Concept Class.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">4</td>
|
|||
|
|
<td align="left">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.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<div id="concept_relationship" class="section level2">
|
|||
|
|
<h2>CONCEPT_RELATIONSHIP</h2>
|
|||
|
|
<p>The CONCEPT_RELATIONSHIP table contains records that define direct relationships between any two Concepts and the nature or type of the relationship. Each type of a relationship is defined in the <a href="https://github.com/OHDSI/CommonDataModel/wiki/RELATIONSHIP">RELATIONSHIP</a> table.</p>
|
|||
|
|
<table style="width:100%;">
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="24%"></col>
|
|||
|
|
<col width="11%"></col>
|
|||
|
|
<col width="14%"></col>
|
|||
|
|
<col width="48%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">Field</th>
|
|||
|
|
<th align="left">Required</th>
|
|||
|
|
<th align="left">Type</th>
|
|||
|
|
<th align="left">Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">concept_id_1</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key to a Concept in the <a href="https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT">CONCEPT</a> table associated with the relationship. Relationships are directional, and this field represents the source concept designation.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">concept_id_2</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key to a Concept in the <a href="https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT">CONCEPT</a> table associated with the relationship. Relationships are directional, and this field represents the destination concept designation.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">relationship_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(20)</td>
|
|||
|
|
<td align="left">A unique identifier to the type or nature of the Relationship as defined in the <a href="https://github.com/OHDSI/CommonDataModel/wiki/RELATIONSHIP">RELATIONSHIP</a> table.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">valid_start_date</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">date</td>
|
|||
|
|
<td align="left">The date when the instance of the Concept Relationship is first recorded.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">valid_end_date</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">date</td>
|
|||
|
|
<td align="left">The date when the Concept Relationship became invalid because it was deleted or superseded (updated) by a new relationship. Default value is 31-Dec-2099.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">invalid_reason</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">varchar(1)</td>
|
|||
|
|
<td align="left">Reason the relationship was invalidated. Possible values are ‘D’ (deleted), ‘U’ (replaced with an update) or NULL when valid_end_date has the default value.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<div id="conventions-4" class="section level3">
|
|||
|
|
<h3>Conventions</h3>
|
|||
|
|
<table style="width:67%;">
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="13%"></col>
|
|||
|
|
<col width="52%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">No.</th>
|
|||
|
|
<th align="left">Convention Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">1</td>
|
|||
|
|
<td align="left">Relationships can generally be classified as hierarchical (parent-child) or non-hierarchical (lateral).</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">2</td>
|
|||
|
|
<td align="left">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: 1- ‘Acute myocardial infarction of the anterior wall’ ‘Is a’ ‘Acute myocardial infarction’, and 2- ‘Acute myocardial infarction’ ‘Subsumes’ ‘Acute myocardial infarction of the anterior wall’.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">3</td>
|
|||
|
|
<td align="left">There is one record for each Concept Relationship connecting the same Concepts with the same RELATIONSHIP_ID.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">4</td>
|
|||
|
|
<td align="left">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 <a href="https://github.com/OHDSI/CommonDataModel/wiki/RELATIONSHIP">RELATIONSHIP</a> table), it is not necessary to query for the existence of a relationship both in the concept_id_1 and concept_id_2 fields.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">5</td>
|
|||
|
|
<td align="left">Concept Relationships define direct relationships between Concepts. Indirect relationships through 3rd Concepts are not captured in this table. However, the <a href="https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_ANCESTOR">CONCEPT_ANCESTOR</a> table does this for hierachical relationships over several “generations” of direct relationships.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<div id="relationship" class="section level2">
|
|||
|
|
<h2>RELATIONSHIP</h2>
|
|||
|
|
<p>The RELATIONSHIP table provides a reference list of all types of relationships that can be used to associate any two concepts in the CONCEPT_RELATIONSHP table.</p>
|
|||
|
|
<table>
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="27%"></col>
|
|||
|
|
<col width="10%"></col>
|
|||
|
|
<col width="15%"></col>
|
|||
|
|
<col width="46%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">Field</th>
|
|||
|
|
<th align="left">Required</th>
|
|||
|
|
<th align="left">Type</th>
|
|||
|
|
<th align="left">Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">relationship_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(20)</td>
|
|||
|
|
<td align="left">The type of relationship captured by the relationship record.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">relationship_name</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(255)</td>
|
|||
|
|
<td align="left">The text that describes the relationship type.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">is_hierarchical</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(1)</td>
|
|||
|
|
<td align="left">Defines whether a relationship defines concepts into classes or hierarchies. Values are 1 for hierarchical relationship or 0 if not.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">defines_ancestry</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(1)</td>
|
|||
|
|
<td align="left">Defines whether a hierarchical relationship contributes to the concept_ancestor table. These are subsets of the hierarchical relationships. Valid values are 1 or 0.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">reverse_relationship_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(20)</td>
|
|||
|
|
<td align="left">The identifier for the relationship used to define the reverse relationship between two concepts.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">relationship_concept_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key that refers to an identifier in the CONCEPT table for the unique relationship concept.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<div id="conventions-5" class="section level3">
|
|||
|
|
<h3>Conventions</h3>
|
|||
|
|
<table style="width:67%;">
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="13%"></col>
|
|||
|
|
<col width="52%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">No.</th>
|
|||
|
|
<th align="left">Convention Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">1</td>
|
|||
|
|
<td align="left">There is one record for each Relationship.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">2</td>
|
|||
|
|
<td align="left">Relationships are classified as hierarchical (parent-child) or non-hierarchical (lateral)</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">3</td>
|
|||
|
|
<td align="left">They are used to determine which concept relationship records should be included in the computation of the CONCEPT_ANCESTOR table.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">4</td>
|
|||
|
|
<td align="left">The RELATIONSHIP_ID field contains an alphanumerical identifier, that can also be used as the abbreviation of the Relationship.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">5</td>
|
|||
|
|
<td align="left">The RELATIONSHIP_NAME field contains the unabbreviated names of the Relationship.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">6</td>
|
|||
|
|
<td align="left">Relationships all exist symmetrically, i.e. in both direction. The RELATIONSHIP_ID of the opposite Relationship is provided in the REVERSE_RELATIONSHIP_ID field.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">7</td>
|
|||
|
|
<td align="left">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.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">8</td>
|
|||
|
|
<td align="left">Hierarchical Relationships are used to build a hierarchical tree out of the Concepts, which is recorded in the CONCEPT_ANCESTOR 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.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">9</td>
|
|||
|
|
<td align="left">Relationships, also hierarchical, can be between Concepts within the same Vocabulary or those adopted from different Vocabulary sources.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<div id="concept_synonym" class="section level2">
|
|||
|
|
<h2>CONCEPT_SYNONYM</h2>
|
|||
|
|
<p>The CONCEPT_SYNONYM table is used to store alternate names and descriptions for Concepts.</p>
|
|||
|
|
<table>
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="31%"></col>
|
|||
|
|
<col width="14%"></col>
|
|||
|
|
<col width="18%"></col>
|
|||
|
|
<col width="35%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">Field</th>
|
|||
|
|
<th align="left">Required</th>
|
|||
|
|
<th align="left">Type</th>
|
|||
|
|
<th align="left">Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">concept_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">Integer</td>
|
|||
|
|
<td align="left">A foreign key to the Concept in the CONCEPT table.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">concept_synonym_name</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(1000)</td>
|
|||
|
|
<td align="left">The alternative name for the Concept.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">language_concept_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key to a Concept representing the language.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<div id="conventions-6" class="section level3">
|
|||
|
|
<h3>Conventions</h3>
|
|||
|
|
<table style="width:67%;">
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="13%"></col>
|
|||
|
|
<col width="52%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">No.</th>
|
|||
|
|
<th align="left">Convention Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">1</td>
|
|||
|
|
<td align="left">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 CONCEPT_SYNONYM table. As an example, for a SNOMED-CT Concept, if the fully specified name is stored as the concept_name of the CONCEPT table, then the Preferred Term and Synonyms associated with the Concept are stored in the CONCEPT_SYNONYM table.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">2</td>
|
|||
|
|
<td align="left">Only Synonyms that are active and current are stored in the CONCEPT_SYNONYM table. Tracking synonym/description history and mapping of obsolete synonyms to current Concepts/Synonyms is out of scope for the Standard Vocabularies.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">3</td>
|
|||
|
|
<td align="left">Currently, only English Synonyms are included.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<div id="concept_ancestor" class="section level2">
|
|||
|
|
<h2>CONCEPT_ANCESTOR</h2>
|
|||
|
|
<p>The CONCEPT_ANCESTOR table is designed to simplify observational analysis by providing the complete hierarchical relationships between Concepts. Only direct parent-child relationships between Concepts are stored in the CONCEPT_RELATIONSHIP table. To determine higher level ancestry connections, all individual direct relationships would have to be navigated at analysis time. The CONCEPT_ANCESTOR table includes records for all parent-child relationships, as well as grandparent-grandchild relationships and those of any other level of lineage. Using the CONCEPT_ANCESTOR table allows for querying for all descendants of a hierarchical concept. For example, drug ingredients and drug products are all descendants of a drug class ancestor.</p>
|
|||
|
|
<p>This table is entirely derived from the CONCEPT, CONCEPT_RELATIONSHIP and RELATIONSHIP tables.</p>
|
|||
|
|
<table>
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="30%"></col>
|
|||
|
|
<col width="10%"></col>
|
|||
|
|
<col width="14%"></col>
|
|||
|
|
<col width="43%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">Field</th>
|
|||
|
|
<th align="left">Required</th>
|
|||
|
|
<th align="left">Type</th>
|
|||
|
|
<th align="left">Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">ancestor_concept_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key to the concept in the concept table for the higher-level concept that forms the ancestor in the relationship.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">descendant_concept_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key to the concept in the concept table for the lower-level concept that forms the descendant in the relationship.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">min_levels_of_separation</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">The minimum separation in number of levels of hierarchy between ancestor and descendant concepts. This is an attribute that is used to simplify hierarchic analysis.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">max_levels_of_separation</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">The maximum separation in number of levels of hierarchy between ancestor and descendant concepts. This is an attribute that is used to simplify hierarchic analysis.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<div id="conventions-7" class="section level3">
|
|||
|
|
<h3>Conventions</h3>
|
|||
|
|
<table style="width:67%;">
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="13%"></col>
|
|||
|
|
<col width="52%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">No.</th>
|
|||
|
|
<th align="left">Convention Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">1</td>
|
|||
|
|
<td align="left">Each concept is also recorded as an ancestor of itself.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">2</td>
|
|||
|
|
<td align="left">Only valid and Standard Concepts participate in the CONCEPT_ANCESTOR table. It is not possible to find ancestors or descendants of deprecated or Source Concepts.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">3</td>
|
|||
|
|
<td align="left">Usually, only Concepts of the same Domain are connected through records of the CONCEPT_ANCESTOR table, but there might be exceptions.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<div id="source_to_concept_map" class="section level2">
|
|||
|
|
<h2>SOURCE_TO_CONCEPT_MAP</h2>
|
|||
|
|
<p>The source to concept map table is a legacy data structure within the OMOP Common Data Model, recommended for use in ETL processes to maintain local source codes which are not available as Concepts in the Standardized Vocabularies, and to establish mappings for each source code into a Standard Concept as target_concept_ids that can be used to populate the Common Data Model tables. The SOURCE_TO_CONCEPT_MAP table is no longer populated with content within the Standardized Vocabularies published to the OMOP community.</p>
|
|||
|
|
<table>
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="33%"></col>
|
|||
|
|
<col width="12%"></col>
|
|||
|
|
<col width="17%"></col>
|
|||
|
|
<col width="37%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">Field</th>
|
|||
|
|
<th align="left">Required</th>
|
|||
|
|
<th align="left">Type</th>
|
|||
|
|
<th align="left">Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">source_code</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(50)</td>
|
|||
|
|
<td align="left">The source code being translated into a Standard Concept.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">source_concept_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key to the Source Concept that is being translated into a Standard Concept.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">source_vocabulary_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(20)</td>
|
|||
|
|
<td align="left">A foreign key to the VOCABULARY table defining the vocabulary of the source code that is being translated to a Standard Concept.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">source_code_description</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">varchar(255)</td>
|
|||
|
|
<td align="left">An optional description for the source code. This is included as a convenience to compare the description of the source code to the name of the concept.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">target_concept_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key to the target Concept to which the source code is being mapped.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">target_vocabulary_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(20)</td>
|
|||
|
|
<td align="left">A foreign key to the VOCABULARY table defining the vocabulary of the target Concept.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">valid_start_date</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">date</td>
|
|||
|
|
<td align="left">The date when the mapping instance was first recorded.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">valid_end_date</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">date</td>
|
|||
|
|
<td align="left">The date when the mapping instance became invalid because it was deleted or superseded (updated) by a new relationship. Default value is 31-Dec-2099.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">invalid_reason</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">varchar(1)</td>
|
|||
|
|
<td align="left">Reason the mapping instance was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<div id="conventions-8" class="section level3">
|
|||
|
|
<h3>Conventions</h3>
|
|||
|
|
<table style="width:67%;">
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="13%"></col>
|
|||
|
|
<col width="52%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">No.</th>
|
|||
|
|
<th align="left">Convention Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">1</td>
|
|||
|
|
<td align="left">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’.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">2</td>
|
|||
|
|
<td align="left">However, this table can still be used for the translation of local source codes into Standard Concepts.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">4</td>
|
|||
|
|
<td align="left"><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).</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">5</td>
|
|||
|
|
<td align="left">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.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">6</td>
|
|||
|
|
<td align="left">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).</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">7</td>
|
|||
|
|
<td align="left">The SOURCE_CODE_DESCRIPTION contains an optional description of the source code.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">8</td>
|
|||
|
|
<td align="left">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</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">9</td>
|
|||
|
|
<td align="left">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.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">10</td>
|
|||
|
|
<td align="left">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.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<div id="drug_strength" class="section level2">
|
|||
|
|
<h2>DRUG_STRENGTH</h2>
|
|||
|
|
<p>The DRUG_STRENGTH table contains structured content about the amount or concentration and associated units of a specific ingredient contained within a particular drug product. This table is supplemental information to support standardized analysis of drug utilization.</p>
|
|||
|
|
<table>
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="31%"></col>
|
|||
|
|
<col width="10%"></col>
|
|||
|
|
<col width="14%"></col>
|
|||
|
|
<col width="43%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">Field</th>
|
|||
|
|
<th align="left">Required</th>
|
|||
|
|
<th align="left">Type</th>
|
|||
|
|
<th align="left">Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">drug_concept_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key to the Concept in the CONCEPT table representing the identifier for Branded Drug or Clinical Drug Concept.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">ingredient_concept_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key to the Concept in the CONCEPT table, representing the identifier for drug Ingredient Concept contained within the drug product.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">amount_value</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">float</td>
|
|||
|
|
<td align="left">The numeric value associated with the amount of active ingredient contained within the product.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">amount_unit_concept_id</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key to the Concept in the CONCEPT table representing the identifier for the Unit for the absolute amount of active ingredient.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">numerator_value</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">float</td>
|
|||
|
|
<td align="left">The numeric value associated with the concentration of the active ingredient contained in the product</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">numerator_unit_concept_id</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key to the Concept in the CONCEPT table representing the identifier for the numerator Unit for the concentration of active ingredient.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">denominator_value</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">float</td>
|
|||
|
|
<td align="left">The amount of total liquid (or other divisible product, such as ointment, gel, spray, etc.).</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">denominator_unit_concept_id</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key to the Concept in the CONCEPT table representing the identifier for the denominator Unit for the concentration of active ingredient.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">box_size</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">The number of units of Clinical of Branded Drug, or Quantified Clinical or Branded Drug contained in a box as dispensed to the patient</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">valid_start_date</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">date</td>
|
|||
|
|
<td align="left">The date when the Concept was first recorded. The default value is 1-Jan-1970.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">valid_end_date</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">date</td>
|
|||
|
|
<td align="left">The date when the concept became invalid because it was deleted or superseded (updated) by a new Concept. The default value is 31-Dec-2099.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">invalid_reason</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">varchar(1)</td>
|
|||
|
|
<td align="left">Reason the concept was invalidated. Possible values are ‘D’ (deleted), ‘U’ (replaced with an update) or NULL when valid_end_date has the default value.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<div id="conventions-9" class="section level3">
|
|||
|
|
<h3>Conventions</h3>
|
|||
|
|
<table style="width:67%;">
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="13%"></col>
|
|||
|
|
<col width="52%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">No.</th>
|
|||
|
|
<th align="left">Convention Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">1</td>
|
|||
|
|
<td align="left">The DRUG_STRENGTH table contains information for each active (non-deprecated) standard drug concept.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">2</td>
|
|||
|
|
<td align="left">A drug which contains multiple active Ingredients will result in multiple DRUG_STRENGTH records, one for each active ingredient.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">3</td>
|
|||
|
|
<td align="left">Ingredient strength information is provided either as absolute amount (usually for solid formulations) or as concentration (usually for liquid formulations).</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">4</td>
|
|||
|
|
<td align="left">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’).</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">5</td>
|
|||
|
|
<td align="left">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’).</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">6</td>
|
|||
|
|
<td align="left">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.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">7</td>
|
|||
|
|
<td align="left">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.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">8</td>
|
|||
|
|
<td align="left">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, Benzathine 150000 UNT/ML / Penicillin G, Procaine 150000 MEQ/ML Injectable Suspension’ contains Penicillin G in two different forms.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">9</td>
|
|||
|
|
<td align="left">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.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">10</td>
|
|||
|
|
<td align="left">All Drug vocabularies containing Standard Concepts have entries in the DRUG_STRENGTH table.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">11</td>
|
|||
|
|
<td align="left">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’</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<div id="standardized-metadata" class="section level1">
|
|||
|
|
<h1>Standardized Metadata</h1>
|
|||
|
|
<p><a href="https://github.com/OHDSI/CommonDataModel/wiki/CDM_SOURCE">CDM_SOURCE</a> <a href="https://github.com/OHDSI/CommonDataModel/wiki/METADATA">METADATA</a></p>
|
|||
|
|
<p>All metadata about the data should be derived from the data themselves.</p>
|
|||
|
|
<div id="cdm_source" class="section level2">
|
|||
|
|
<h2>CDM_SOURCE</h2>
|
|||
|
|
<p>The CDM_SOURCE table contains detail about the source database and the process used to transform the data into the OMOP Common Data Model.</p>
|
|||
|
|
<table>
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="32%"></col>
|
|||
|
|
<col width="10%"></col>
|
|||
|
|
<col width="14%"></col>
|
|||
|
|
<col width="43%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">Field</th>
|
|||
|
|
<th align="left">Required</th>
|
|||
|
|
<th align="left">Type</th>
|
|||
|
|
<th align="left">Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">cdm_source_name</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(255)</td>
|
|||
|
|
<td align="left">The full name of the source</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">cdm_source_abbreviation</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">varchar(25)</td>
|
|||
|
|
<td align="left">An abbreviation of the name</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">cdm_holder</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">varchar(255)</td>
|
|||
|
|
<td align="left">The name of the organization responsible for the development of the CDM instance</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">source_description</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">CLOB</td>
|
|||
|
|
<td align="left">A description of the source data origin and purpose for collection. The description may contain a summary of the period of time that is expected to be covered by this dataset.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">source_documentation_reference</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">varchar(255)</td>
|
|||
|
|
<td align="left">URL or other external reference to location of source documentation</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">cdm_etl_reference</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">varchar(255)</td>
|
|||
|
|
<td align="left">URL or other external reference to location of ETL specification documentation and ETL source code</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">source_release_date</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">date</td>
|
|||
|
|
<td align="left">The date for which the source data are most current, such as the last day of data capture</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">cdm_release_date</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">date</td>
|
|||
|
|
<td align="left">The date when the CDM was instantiated</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">cdm_version</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">varchar(10)</td>
|
|||
|
|
<td align="left">The version of CDM used</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">vocabulary_version</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">varchar(20)</td>
|
|||
|
|
<td align="left">The version of the vocabulary used</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<div id="conventions-10" class="section level3">
|
|||
|
|
<h3>Conventions</h3>
|
|||
|
|
<table style="width:67%;">
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="13%"></col>
|
|||
|
|
<col width="52%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">No.</th>
|
|||
|
|
<th align="left">Convention Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">1</td>
|
|||
|
|
<td align="left">If a source database is derived from multiple data feeds, the integration of those disparate sources is expected to be documented in the ETL specifications. The source information on each of the databases can be represented as separate records in the CDM_SOURCE table.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">2</td>
|
|||
|
|
<td align="left">Currently, there is no mechanism to link individual records in the CDM tables to their source record in the CDM_SOURCE table.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">3</td>
|
|||
|
|
<td align="left">The version of the vocabulary can be obtained from the vocabulary_name field in the VOCABULARY table for the record where vocabulary_id=‘None’.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<div id="metadata" class="section level2">
|
|||
|
|
<h2>METADATA</h2>
|
|||
|
|
<p>The METADATA table contains metadata information about a dataset that has been transformed to the OMOP Common Data Model.</p>
|
|||
|
|
<table>
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="32%"></col>
|
|||
|
|
<col width="10%"></col>
|
|||
|
|
<col width="14%"></col>
|
|||
|
|
<col width="43%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">Field</th>
|
|||
|
|
<th align="left">Required</th>
|
|||
|
|
<th align="left">Type</th>
|
|||
|
|
<th align="left">Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">metadata_concept_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key that refers to a Standard Metadata Concept identifier in the Standardized Vocabularies.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">metadata_type_concept_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key that refers to a Standard Type Concept identifier in the Standardized Vocabularies.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">name</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">varchar(250)</td>
|
|||
|
|
<td align="left">The name of the Concept stored in metadata_concept_id or a description of the data being stored.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">value_as_string</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">nvarchar</td>
|
|||
|
|
<td align="left">The metadata value stored as a string.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">value_as_concept_id</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key to a metadata value stored as a Concept ID.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">metadata date</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">date</td>
|
|||
|
|
<td align="left">The date associated with the metadata</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">metadata_datetime</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">datetime</td>
|
|||
|
|
<td align="left">The date and time associated with the metadata</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<div id="conventions-11" class="section level3">
|
|||
|
|
<h3>Conventions</h3>
|
|||
|
|
<table style="width:67%;">
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="13%"></col>
|
|||
|
|
<col width="52%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">No.</th>
|
|||
|
|
<th align="left">Convention Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">1</td>
|
|||
|
|
<td align="left">One record in the Metadata table is pre-populated in the DDL indicating the CDM version of the database.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<div id="standardized-clinical-data-tables" class="section level1">
|
|||
|
|
<h1>Standardized Clinical Data Tables</h1>
|
|||
|
|
<p><a href="https://github.com/OHDSI/CommonDataModel/wiki/PERSON">PERSON</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/OBSERVATION_PERIOD">OBSERVATION_PERIOD</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/DEATH">DEATH</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/VISIT_OCCURRENCE">VISIT_OCCURRENCE</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/VISIT_DETAIL">VISIT_DETAIL</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_OCCURRENCE">CONDITION_OCCURRENCE</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/DRUG_EXPOSURE">DRUG_EXPOSURE</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/PROCEDURE_OCCURRENCE">PROCEDURE_OCCURRENCE</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/DEVICE_EXPOSURE">DEVICE_EXPOSURE</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/MEASUREMENT">MEASUREMENT</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/NOTE">NOTE</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/NOTE_NLP">NOTE_NLP</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/SURVEY_CONDUCT">SURVEY_CONDUCT</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/OBSERVATION">OBSERVATION</a> <a href="https://github.com/OHDSI/CommonDataModel/wiki/SPECIMEN">SPECIMEN</a><br />
|
|||
|
|
<a href="https://github.com/OHDSI/CommonDataModel/wiki/FACT_RELATIONSHIP">FACT_RELATIONSHIP</a></p>
|
|||
|
|
<p>These tables contain the core information about the clinical events that occurred longitudinally during valid Observation Periods for each Person, as well as demographic information for the Person. Below provides an entity-relationship diagram highlighting the tables within the Standardized Clinical Data portion of the OMOP Common Data Model:</p>
|
|||
|
|
<div class="figure">
|
|||
|
|
<embed src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAABPMAAAZmCAYAAAG6U9HhAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAAFxEAABcRAcom8z8AAP+lSURBVHhe7P13VBTL/u8P3/9+fz3rd9ez1rPWveveb/6euPc+5+y9z845qFvd5pwRUTAhSQEJEkQwgqKoCIIIioiIBJGcs+Scc84Mk8P76VCg6ADDzDAM2i9W0dVVPV3V0+/5VFV3hf+hBVo4x7l5Oq0BstUH6LxwTr+dVtH6CTVAL/ICHUOSfS/hxPcGScdMiSwWlt7iEmZLkn0v4cT3BroSX0/hS2ZLkn0v4cT3BvMV32BrAm74JuBBcQeKuntI6Nxw4tPyDWe+zUWCZEFjOMunO7QuvmdbtiH+kIlOnTZvYtLxE1AUlTBuPCt5yq9t11tYqNV8L0W0Lr6M0/bMl6prSBY0hhafLCOLcdnPf2S20adPwcXEAU7791P72ciKypw6Rl3Xk5en1XwvRXQqvqvmXmjKuY/+5mxcsD4JC+tTEEIKB7dHEFDxz+sHMCyRQThcg6fZLfA864zu5lQEXPVEetBFWB47wZ5ICSQLGpN03BTy/MIZnaLgpdLw+bqevHyt5nspolPxzUaEuxPxqQfJgsaoWudLuZuOk8fukr35w9X5FkB8mUu92FUivs6BcYxLpKhp68GoWI6hwSEMdfZjeHCcHDF/OPEthOWzd5iq1xTlOE6r52jiJpLTwUtOeytc0dml1ZvItXZ1x4KK74rZfzFbr6thiH2SitOnrmE48i5CjhvhsekB+Ow1xUhCCoQJ0RhLCIOz82203nGBKCkQJU/iIE0NxmBCMqTUOe5cvIezHoFT5550uhBfjIs1Tv1gjIObWKvOF/XD4V465Wtg9ovHG8BnfKrDiW8hxPcOFrsLASc+HYnP0cmMshzfY//5OPRU3MeVtQeZcIFChDE549UYkgWNUSa+FYZncCOzEUnXTzH7JeGucFn3O3748lOMCuUwvBSBX37biEi3o0z8s7JBdFVEQCYoxQ8rt8DAJYQJlwpYwdFw4tOR+CIb6Qcp01nxw4/Epx1IFjRmLstnZedMfCxhTtOv1+yE8sdBVmbmxMfCiU9H4tMFJAsao0qxOz7Gh1wqJHvqwYlPR+ILqeYjpFYIqx9M0VUWhNNfG8Luy92w/8IAZRWVGO2MwpW4Jng+b8bFiGqUlZXD/bcDzGcbhvPQKmW8s0KyoDHKxBftdBL7riTitOEWZn+PaQA6mtPhfi6A2VcHTnyc5XsLrsGhO3QiPv4ED+O8cYjlCtB/cpkYwvEJCMZ4GOGLmWOGJArYfLoJwxMiZn++kCxojDLx+R47hh3rHLFn2XfMPm352hqfwmTV9zj9zUHktJVj248rmDhV4cSnI/HdSMjHINUqHBbLIZPLIJ7ohXikHV21LSgsaoFCoYBEOo7x7goUFDaST80PkgWN4Syf7tCJ+HQByYLGaEN8ZxwjMNxehhDS3UsZnPh0JL5reUO4WTyBw79aoa/6AZyX7YDt5waw/WwrPvvoE4x1J2KYPwG3b/bgs79+iHPf7YJz0Et8+eMP5AxzQ7KgMcrEx+vvwzBluUd7WtDV3YuD+w6iuq4dbX0jUMh4KC2rgVQ4iv4JKaypRlRrfRlEglE0N7STM7wNJz7O8r3FIhS7/5NN+f1DL8TH688ivtlQkK1ySBY0Rpn4Yl2sYfP9IRhtsGH2n562ws2cXlS8uE7tCWF7Kgh3C4dQzAf6JsZQyatijiufpe30huX7d7J9Ha3eG31EJ+LbcdAAoXUCXEhuxfhwC16GnETRzf1w+ckY2/f5QDhcD+uoRlgEF+J5Yz86y+9i3c+/oUcOrP/1dzx82Y7iftIqLglktm9CsqAxetTg4MQ3H+gv810sdlcfcoVvbgtSb56m9qS4ftEHvtm9bKSacOLTkfgOut/CRF8peL0VaC65j/byEFjuP8kUpMFPE7D25EN8u9wVY2MDOPPlVzD5gH7vK4Xfg1jm86pAsqAxc1m+Y5a0ADWHE5+OxDcT8bFvi6u1iK0v5dSoPgaWhmRBY7hiV3csqvi0CcmCxigTH/1ud/f5OFjv38rsWx/YBZ9DbPcqdeHEpyPx2Uc141ImD33DHVRhKgRfMQHe7I3XeUOyoDGc5dMdOhGfLiBZ0Bhl4ttveh53y7phbmoP28dVKBxvRE97NhM3JAJOeSUhtHEAu35fDYFwkAkPKhtA5dvdGKfgxKcj8fl4O8PJ7QwS2sZQVJWIdZbHYOSXyzQ4hJBppTczyYLGcJZPd+hEfOENyk3Ark2biU9zSBY0Rlviq+eJUMFZvlnRifh0AcmCxigTX3V+HuSUnQ69aYPCuib0dAwho3MCw/39yC8ogogy4YN8GQZaa5GZX4Tu/mEMCWQQzGLROfHpSHye93xQGncXtXn3mH2brw6hr+4RbuX042ZGN2z/sRzXE1pwJbYREZFREI2nUC6NOVZVSBY0hit2dYdOxKcLSBY0Rpn4Ip1OwunHfbjiYArH7/bh0BZb8Khwa9N78M3tYw+aJ5z4dCg+hVyGhhx/xm/9hSH1nw+pVIqBtqeUn+5kOksFSQVIFjSGs3y6Qyfii0koROq9QIgmhpn9gtgctAmlCAoOxsREJxUiR1BQEBOnLiQLGqNMfBejEpDeN4j4OgE8tqzH3u9+QG1lHNKvXULd+Ai8TK3guPo3PMjvwk3j87B3fEI+OTOc+P7H/xghW61Af5nvYrE7SXnkbeKbCdU7G7wT4mOuYJEhWZlRfC6J3biSPYp9qxwwUBcBj7UbmZ7M1v9cix//9jF4valwjKimGhxNsPYvgoRfynwu2n47zoQWoE0GrNm+nQmbCZIFjVEuPioDShDwJcQ3f94Z8bUmJjEXshg0v4ifU3y6gGRBY5SLrxHPa9tRNyDBZkN7HLG9iurESzh5lB23e9z+GrOdD++t+ORt9AxLr8FvIp75o2vxZfrdJ77pkCxoDNfgmAf0Bahj+QIOO6C9Phm9DXHUXgNaqBIk7dZlBNylZ9tk30+qgiri23HMDMG1AliHV2K0vxqp1w8i4/xm2H+5H+angiEcLcaxjTvx24ZduBJZi5Z+tjvVnm0HsP/8M1xbvRdFbV24s2UjEl0NmLgNG/Yy20lIFjRGmfhuHD6CzZtcYLRuObOff/sk7L85gG2bnDHWyj6PtH9Wi7BjR2H9jTHyVfj63mvx5T1WvaPmbLwfxa72eWfE1546v7cB2kQV8e21PgPxaB0zVqOp+D5ay0Jw8JAL07HgRkA6trrF4sxXe1AcfgRnzzpBLupFddojuAUV4px/LkZU6HhAsqAxCpkMCqkuHDsBDUlWGUtDfK2JiVMzddaFOyPad8u02TvncnIlYao6TSyf18WLxDedkAx2xs/5QLLwLrH0xEe7/KcPmW3tkzg0BlzEif37IUrPgvcuU9zYeRQWh0wgSb3HHPPw0FG0puRO+/x83LtW7OoRS1N8qjpRarrS8Pm4N8WnCvM4VGXYHLxTLBXx6cdzPhV5F4WyECx18XXjPz/4GEE1QogxAbNPD2C8g33v6P7VenSr/4B+CjXEx6Ea76bla2pqJj7N4cS3YLyb4tMmnPgWjKUtPpFEjpLHF/D9V59CogCs/rYRlh/twyd//DMUw1HkKMBjsxEgL0Zinxxff/DfVEgb4obomGHcqp69bH7XxEcuS+eQ5F/n3bZ80dHRxKcMMSp75p6i9l0Tn1yiwuzjCwBJ/nXebfFpg/dVfMUto8y2MfNVx9ETJseIb/6Q5F9naYtPThW1efdcsGfLagip79Tiw5U49reDWPbR3yFrf8AcIyq7gYDNa9GCMaT3AQW37WC16zhKHjkhkS9Cd9kDtJcHIKRpgDn+anILDv5zE+OneV/F9zClGSUtQ6jPvI+S2jYM8iS4cCcS911uwutOHkITq1H10Bm+x5yRW8j2T5wNkvzrLG3xzYW7uzvqk6gvL4ItfuvTIpjtm/D6K5ntxXPnmO3rcMWudiDJv867LT5t8C6KT5aWwbj2F+5T/oV0NCT511na4
|
|||
|
|
|
|||
|
|
</div>
|
|||
|
|
<div id="person" class="section level2">
|
|||
|
|
<h2>PERSON</h2>
|
|||
|
|
<p>The Person Domain contains records that uniquely identify each patient in the source data who is time at-risk to have clinical observations recorded within the source systems.</p>
|
|||
|
|
<table>
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="28%"></col>
|
|||
|
|
<col width="9%"></col>
|
|||
|
|
<col width="13%"></col>
|
|||
|
|
<col width="48%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">Field</th>
|
|||
|
|
<th align="left">Required</th>
|
|||
|
|
<th align="left">Type</th>
|
|||
|
|
<th align="left">Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">person_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A unique identifier for each person.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">gender_concept_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key that refers to an identifier in the CONCEPT table for the unique gender of the person.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">year_of_birth</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">The year of birth of the person. For data sources with date of birth, the year is extracted. For data sources where the year of birth is not available, the approximate year of birth is derived based on any age group categorization available.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">month_of_birth</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">The month of birth of the person. For data sources that provide the precise date of birth, the month is extracted and stored in this field.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">day_of_birth</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">The day of the month of birth of the person. For data sources that provide the precise date of birth, the day is extracted and stored in this field.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">birth_datetime</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">datetime</td>
|
|||
|
|
<td align="left">The date and time of birth of the person.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">death_datetime</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">datetime</td>
|
|||
|
|
<td align="left">The date and time of death of the person.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">race_concept_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key that refers to an identifier in the CONCEPT table for the unique race of the person, belonging to the ‘Race’ vocabulary.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">ethnicity_concept_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key that refers to the standard concept identifier in the Standardized Vocabularies for the ethnicity of the person, belonging to the ‘Ethnicity’ vocabulary.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">location_id</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key to the place of residency for the person in the location table, where the detailed address information is stored.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">provider_id</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key to the primary care provider the person is seeing in the provider table.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">care_site_id</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">integer</td>
|
|||
|
|
<td align="left">A foreign key to the site of primary care in the care_site table, where the details of the care site are stored.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">person_source_value</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">varchar(50)</td>
|
|||
|
|
<td align="left">An (encrypted) key derived from the person identifier in the source data. This is necessary when a use case requires a link back to the person data at the source dataset.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">gender_source_value</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">varchar(50)</td>
|
|||
|
|
<td align="left">The source code for the gender of the person as it appears in the source data. The person’s gender is mapped to a standard gender concept in the Standardized Vocabularies; the original value is stored here for reference.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">gender_source_concept_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">Integer</td>
|
|||
|
|
<td align="left">A foreign key to the gender concept that refers to the code used in the source.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">race_source_value</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">varchar(50)</td>
|
|||
|
|
<td align="left">The source code for the race of the person as it appears in the source data. The person race is mapped to a standard race concept in the Standardized Vocabularies and the original value is stored here for reference.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">race_source_concept_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">Integer</td>
|
|||
|
|
<td align="left">A foreign key to the race concept that refers to the code used in the source.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">ethnicity_source_value</td>
|
|||
|
|
<td align="left">No</td>
|
|||
|
|
<td align="left">varchar(50)</td>
|
|||
|
|
<td align="left">The source code for the ethnicity of the person as it appears in the source data. The person ethnicity is mapped to a standard ethnicity concept in the Standardized Vocabularies and the original code is, stored here for reference.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">ethnicity_source_concept_id</td>
|
|||
|
|
<td align="left">Yes</td>
|
|||
|
|
<td align="left">Integer</td>
|
|||
|
|
<td align="left">A foreign key to the ethnicity concept that refers to the code used in the source.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<div id="conventions-12" class="section level3">
|
|||
|
|
<h3>Conventions</h3>
|
|||
|
|
<table>
|
|||
|
|
<colgroup>
|
|||
|
|
<col width="9%"></col>
|
|||
|
|
<col width="90%"></col>
|
|||
|
|
</colgroup>
|
|||
|
|
<thead>
|
|||
|
|
<tr class="header">
|
|||
|
|
<th align="left">No.</th>
|
|||
|
|
<th align="left">Convention Description</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">1</td>
|
|||
|
|
<td align="left">All tables representing patient-related Domains have a foreign-key reference to the person_id field in the PERSON table.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">2</td>
|
|||
|
|
<td align="left">Each person record has associated demographic attributes which are assumed to be constant for the patient throughout the course of their periods of observation. For example, the location or gender is expected to have a unique value per person, even though in life these data may change over time.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">3</td>
|
|||
|
|
<td align="left">The GENDER_CONCEPT_ID should store what is believed to be the biological or sex assigned at birth. If the data set does have gender identification information, this should be stored in the OBSERVATION table (using the gender concepts 8532-Female or 8507-Male in OBSERVATION_CONCEPT_ID (<a href="https://github.com/OHDSI/Themis/issues/32">THEMIS issue #32</a>).</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">4</td>
|
|||
|
|
<td align="left">If we do not know the month or day of birth, we do not guess. A person can exist without a month or day of birth. If a person lacks a birth year that person should be dropped (<a href="https://github.com/OHDSI/Themis/issues/30">THEMIS issue #30</a>).</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">5</td>
|
|||
|
|
<td align="left">Living patients should not have a value in PERSON.DEATH_DATETIME, nor should they have any records relating to death either in the CONDITION_OCCURRENCE or OBSERVATION tables.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">6</td>
|
|||
|
|
<td align="left">Only one death date per individual can be used. If a patient has clinical activity (e.g. prescriptions filled, labs performed, etc) more than 60+ days after death you may want to drop the death record as it may have been falsely reported. If multiple records of death exist on multiple days you may select the death that you deem most reliable (e.g. death at discharge) or select the latest death date.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">7</td>
|
|||
|
|
<td align="left">If multiple death records occur, the date and the person have to be the same, but the cause can be different. Can be reported by different sources as well.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">8</td>
|
|||
|
|
<td align="left">If PERSON.DEATH_DATETIME cannot be precisely determined from the data, the best approximation should be used.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">9</td>
|
|||
|
|
<td align="left">The DEATH_DATETIME in the PERSON table should not be used as the way to find all deaths • <code>select * from PERSON where death_datetime is not null</code> should not be the practice • Rather, deaths should be found through the OBSERVATION table and the PERSON table is only used to determine which death date should be used in analysis.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">10</td>
|
|||
|
|
<td align="left">Valid Gender, Race and Ethnicity Concepts each belong to their own Domain.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">11</td>
|
|||
|
|
<td align="left">Ethnicity in the OMOP CDM follows the OMB Standards for Data on Race and Ethnicity: Only distinctions between Hispanics and Non-Hispanics are made.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">12</td>
|
|||
|
|
<td align="left">Additional information is stored through references to other tables, such as the home address (location_id) or the primary care provider.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">13</td>
|
|||
|
|
<td align="left">The Provider refers to the primary care provider (General Practitioner). When the primary provider is unknown for a person then leave the PROVIDER_ID blank (<a href="https://github.com/OHDSI/Themis/issues/36">THEMIS issue #36</a>).</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="even">
|
|||
|
|
<td align="left">14</td>
|
|||
|
|
<td align="left">The Care Site refers to where the Provider typically provides the primary care. When care site for the primary provider is unknown then leave the CARE_SITE_ID blank.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr class="odd">
|
|||
|
|
<td align="left">15</td>
|
|||
|
|
<td align="left">It is not required that all subjects from the raw data be carried over to the CDM, in fact removing people that are not of high enough quality may help researchers using the CDM. Example scenarios to remove subjects include: a person’s year of birth or age are unreasonable (e.g. born in year 0, 1800, 2999 or just lacking a year of birth), person lacks health benefits in claims database (i.e. thus you do not have a complete picture of their record), or raw data states that the person may not be of high research quality (e.g. CPRD will actually suggest which people not to use within research). Removal of a patient is not required and should be made in consideration of the raw data source. Reasons for removal of persons should be documented in the ETL documentation and METADATA table (insert row in METADATA where metadata.name=‘count of removed persons’ and metada.value_as_string=‘xyz’ where xyz is a number (e.g., 12). <br> An ETL should not delete persons who contribute time however have no health care utilization (e.g. an individual enrolled in insurance but does not visit a doctor or pharmacy). This individual will contribute to analysis however as a healthy / non-care seeking individual (<a href="https://github.com/OHDSI/Themis/issues/9">THEMIS issue #9</a>).</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<!-- ## OBSERVATION_PERIOD -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedclinicalDataTables/OBSERVATION_PERIOD.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## VISIT_OCCURRENCE -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedclinicalDataTables/VISIT_OCCURRENCE.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## VISIT_DETAIL -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedclinicalDataTables/VISIT_DETAIL.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## CONDITION_OCCURRENCE -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedclinicalDataTables/CONDITION_OCCURRENCE.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## DEATH -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedclinicalDataTables/DEATH.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## DRUG_EXPOSURE -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedclinicalDataTables/DRUG_EXPOSURE.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## PROCEDURE_OCCURRENCE -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedclinicalDataTables/PROCEDURE_OCCURRENCE.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## DEVICE_EXPOSURE -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedclinicalDataTables/DEVICE_EXPOSURE.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## MEASUREMENT -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedclinicalDataTables/MEASUREMENT.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## NOTE -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedclinicalDataTables/NOTE.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## NOTE_NLP -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedclinicalDataTables/NOTE_NLP.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## SURVEY_CONDUCT -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedclinicalDataTables/SURVEY_CONDUCT.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## OBSERVATION -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedclinicalDataTables/OBSERVATION.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## SPECIMEN -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedclinicalDataTables/SPECIMEN.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## FACT_RELATIONSHIP -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedclinicalDataTables/FACT_RELATIONSHIP.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- # Standardized Health System Data Tables -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedHealthSystemDataTables/Standardized-Health-System-Data-Tables.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## LOCATION -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedHealthSystemDataTables/LOCATION.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## LOCATION_HISTORY -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedHealthSystemDataTables/LOCATION_HISTORY.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## CARE_SITE -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedHealthSystemDataTables/CARE_SITE.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## PROVIDER -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedHealthSystemDataTables/PROVIDER.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- # Standardized Health Economics Data Tables -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedHealthEconomicsDataTables/Standardized-Health-Economics-Data-Tables.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## PAYER_PLAN_PERIOD -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedHealthEconomicsDataTables/PAYER_PLAN_PERIOD.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## COST -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedHealthEconomicsDataTables/COST.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- # Standardized Derived Elements -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedDerivedElements/Standardized-Derived-Elements.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## DRUG_ERA -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedDerivedElements/DRUG_ERA.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## DOSE_ERA -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedDerivedElements/DOSE_ERA.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## CONDITION_ERA -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/StandardizedDerivedElements/CONDITION_ERA.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- # Results Schema -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/ResultsSchema/Results-Schema.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## COHORT -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/ResultsSchema/COHORT.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
<!-- ## COHORT_DEFINITION -->
|
|||
|
|
<!-- ```{r child = paste0(mdFilesLocation,'/ResultsSchema/COHORT_DEFINITION.md')} -->
|
|||
|
|
<!-- ``` -->
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
<script>
|
|||
|
|
|
|||
|
|
// add bootstrap table styles to pandoc tables
|
|||
|
|
function bootstrapStylePandocTables() {
|
|||
|
|
$('tr.header').parent('thead').parent('table').addClass('table table-condensed');
|
|||
|
|
}
|
|||
|
|
$(document).ready(function () {
|
|||
|
|
bootstrapStylePandocTables();
|
|||
|
|
});
|
|||
|
|
|
|||
|
|
|
|||
|
|
</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>
|