DEATH表

已在最新版本中棄用-->

自O(shè)MOP CDM v6.0起这难,DEATH表已被棄用遭殉,有利于在CONDITION_OCCURRENCE表中存儲死因,任何與死亡相關(guān)的觀察結(jié)果都存儲在OBSERVATION表,以及唯一的死亡日期將被并存儲在PERSON表。

“死亡”域包含有關(guān)人員死亡的方式和時間的臨床事件七扰。人員可以在源系統(tǒng)中包含有關(guān)死亡證據(jù)的信息,例如:

  • 索賠中的條件代碼或索賠的詳細(xì)信息
  • 入選健康計劃的狀況
  • EHR數(shù)據(jù)中的顯式記錄

As of OMOP CDM v6.0, the DEATH table has been deprecated in favor of storing the cause of death in the CONDITION_OCCURRENCE table, any observations relating to death stored in the OBSERVATION table, and a singular death date will be chosen and stored in the PERSON table.

The 'Death' domain contains the clinical events surrounding how and when a Person dies. A Person can have information in the source system containing evidence about the Death, such as:

  • Condition Code in the Header or Detail information of claims
  • Status of enrollment into a health plan
  • Explicit record in EHR data

共識

No. Convention Description 共識
1 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 活體患者不應(yīng)該在PERSON.DEATH_DATETIME中有價值陪白,也不應(yīng)該在CONDITION_OCCURRENCE或OBSERVATION表中有任何與死亡有關(guān)的記錄
2 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 (THEMIS issue #6). 每個人只能使用一個死亡日期颈走。如果患者在死亡超過60天后有臨床活動(例如處方藥,實(shí)驗(yàn)室等)咱士,您可能希望丟失死亡記錄立由,因?yàn)樗赡鼙诲e誤報告。如果多天存在多個死亡記錄司致,您可以選擇您認(rèn)為最可靠的死亡(例如出院時死亡)或選擇最新死亡日期(THEMIS問題#6)拆吆。
3 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 (THEMIS issue #5). 如果發(fā)生多個死亡記錄聋迎,則日期和人必須相同脂矫,但原因可能不同。也可以由不同的來源報告(THEMIS問題#5)霉晕。
4 If PERSON.DEATH_DATETIME cannot be precisely determined from the data, the best approximation should be used. 如果無法從數(shù)據(jù)中精確確定PERSON.DEATH_DATETIME庭再,則應(yīng)使用最佳近似值。
5 Any cause of death should be stored in the CONDITION_OCCURRENCE table, using the CONDITION_TYPE vocabulary with the DEATH_TYPE concept class. 任何死因都應(yīng)存儲在CONDITION_OCCURRENCE表中牺堰,使用帶有DEATH_TYPE概念類的CONDITION_TYPE詞匯表拄轻。
6 All observations relating to death should be stored in the OBSERVATION table, including the concept 4306655. 與死亡有關(guān)的所有觀察都應(yīng)存儲在觀察表中,包括概念4306655伟葫。
7 The DEATH_DATETIME in the PERSON table should not be used as the way to find all deathsselect * from PERSON where death_datetime is not null should not be the practiceRather, 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 不應(yīng)將PERSON表中的DEATH_DATETIME用作查找所有死亡的方法select * from PERSON where death_datetime is not null 不應(yīng)該是這種做法相反恨搓,應(yīng)通過OBSERVATION表找到死亡,PERSON表僅用于確定分析中應(yīng)使用哪個死亡日期

本系列在介紹目前世界上最適用于臨床科研+衛(wèi)生經(jīng)濟(jì)學(xué)的標(biāo)準(zhǔn)醫(yī)療大數(shù)據(jù)格式(未經(jīng)嚴(yán)謹(jǐn)考證筏养,但有相關(guān)研究發(fā)表在專業(yè)期刊上)斧抱,儼然是真實(shí)世界研究方案里面最接進(jìn)成熟的基礎(chǔ)建設(shè)方案。感興趣的介紹請移步B站觀看視頻渐溶。

OHDSI——觀察性健康醫(yī)療數(shù)據(jù)科學(xué)與信息學(xué)辉浦,是一個世界性的公益型非盈利研究聯(lián)盟,主要研究全方位醫(yī)學(xué)大數(shù)據(jù)分析的開源解決方案,旨在通過大規(guī)模數(shù)據(jù)分析和挖掘來提升臨床醫(yī)學(xué)數(shù)據(jù)價值,實(shí)現(xiàn)跨學(xué)科刽肠、跨行業(yè)的多方合作攒射。目前筒主,目前振劳,已有來自美國署驻、加拿大驾霜、澳大利亞丐黄、英國等幾十個國家地區(qū)的上百個組織機(jī)構(gòu)斋配,高校,醫(yī)院和公司企業(yè)參與了OHDSI全球協(xié)作網(wǎng)絡(luò)灌闺,如斯坦福艰争、哈佛、杜克大學(xué)醫(yī)學(xué)院桂对,強(qiáng)生甩卓、諾華、甲骨文蕉斜、IBM公司逾柿,擁有超過6億人口的臨床數(shù)據(jù)規(guī)模,累計協(xié)作研究發(fā)表了上百篇論文宅此。

我們在這里邀請國內(nèi)對相關(guān)工作感興趣机错、愿共同學(xué)習(xí)的好學(xué)人士參與到中文興趣小組,互通有無父腕,一起彌補(bǔ)跨行業(yè)弱匪、跨學(xué)科的知識積累。前期主要以對OHDSI在github上的開源工作進(jìn)行翻譯璧亮、交流萧诫、學(xué)習(xí)為主,并會對醫(yī)療大數(shù)據(jù)枝嘶、醫(yī)學(xué)統(tǒng)計學(xué)帘饶、生物信息學(xué)等學(xué)科知識建立學(xué)習(xí)互助、互督的機(jī)制群扶。有興趣的請看文檔及刻,微信群二維碼在內(nèi):OHDSI中文興趣小組共識&OHDSI介紹

OHDSI秉持開源、開放的宗旨竞阐,加快全球醫(yī)學(xué)數(shù)據(jù)研究的步伐缴饭,本文內(nèi)容原創(chuàng)來自Github(https://github.com/OHDSI/CommonDataModel/wiki),若有利益沖突馁菜,請在本頁面留言茴扁,真-侵刪。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末汪疮,一起剝皮案震驚了整個濱河市峭火,隨后出現(xiàn)的幾起案子毁习,更是在濱河造成了極大的恐慌,老刑警劉巖卖丸,帶你破解...
    沈念sama閱讀 216,470評論 6 501
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件纺且,死亡現(xiàn)場離奇詭異,居然都是意外死亡稍浆,警方通過查閱死者的電腦和手機(jī)载碌,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,393評論 3 392
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來衅枫,“玉大人嫁艇,你說我怎么就攤上這事∠伊茫” “怎么了步咪?”我有些...
    開封第一講書人閱讀 162,577評論 0 353
  • 文/不壞的土叔 我叫張陵,是天一觀的道長益楼。 經(jīng)常有香客問我猾漫,道長,這世上最難降的妖魔是什么感凤? 我笑而不...
    開封第一講書人閱讀 58,176評論 1 292
  • 正文 為了忘掉前任悯周,我火速辦了婚禮,結(jié)果婚禮上陪竿,老公的妹妹穿的比我還像新娘禽翼。我一直安慰自己,他們只是感情好萨惑,可當(dāng)我...
    茶點(diǎn)故事閱讀 67,189評論 6 388
  • 文/花漫 我一把揭開白布捐康。 她就那樣靜靜地躺著仇矾,像睡著了一般庸蔼。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上贮匕,一...
    開封第一講書人閱讀 51,155評論 1 299
  • 那天姐仅,我揣著相機(jī)與錄音,去河邊找鬼刻盐。 笑死掏膏,一個胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的敦锌。 我是一名探鬼主播馒疹,決...
    沈念sama閱讀 40,041評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼乙墙!你這毒婦竟也來了颖变?” 一聲冷哼從身側(cè)響起生均,我...
    開封第一講書人閱讀 38,903評論 0 274
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎腥刹,沒想到半個月后马胧,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 45,319評論 1 310
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡衔峰,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,539評論 2 332
  • 正文 我和宋清朗相戀三年佩脊,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片垫卤。...
    茶點(diǎn)故事閱讀 39,703評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡威彰,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出穴肘,到底是詐尸還是另有隱情抱冷,我是刑警寧澤,帶...
    沈念sama閱讀 35,417評論 5 343
  • 正文 年R本政府宣布梢褐,位于F島的核電站旺遮,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏盈咳。R本人自食惡果不足惜耿眉,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,013評論 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望鱼响。 院中可真熱鬧鸣剪,春花似錦、人聲如沸丈积。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,664評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽江滨。三九已至铛纬,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間唬滑,已是汗流浹背告唆。 一陣腳步聲響...
    開封第一講書人閱讀 32,818評論 1 269
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留晶密,地道東北人擒悬。 一個月前我還...
    沈念sama閱讀 47,711評論 2 368
  • 正文 我出身青樓,卻偏偏與公主長得像稻艰,于是被迫代替她去往敵國和親懂牧。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 44,601評論 2 353