DEATH表
已在最新版本中弃用-->
自OMOP CDM v6.0起，DEATH表已被弃用，有利于在CONDITION_OCCURRENCE表中存储死因，任何与死亡相关的观察结果都存储在OBSERVATION表，以及唯一的死亡日期将被并存储在PERSON表。
“死亡”域包含有关人员死亡的方式和时间的临床事件。人员可以在源系统中包含有关死亡证据的信息，例如：
- 索赔中的条件代码或索赔的详细信息
- 入选健康计划的状况
- EHR数据中的显式记录
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 | 活体患者不应该在PERSON.DEATH_DATETIME中有价值，也不应该在CONDITION_OCCURRENCE或OBSERVATION表中有任何与死亡有关的记录 |
| 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天后有临床活动（例如处方药，实验室等），您可能希望丢失死亡记录，因为它可能被错误报告。如果多天存在多个死亡记录，您可以选择您认为最可靠的死亡（例如出院时死亡）或选择最新死亡日期（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). | 如果发生多个死亡记录，则日期和人必须相同，但原因可能不同。也可以由不同的来源报告（THEMIS问题＃5）。 |
| 4 | If PERSON.DEATH_DATETIME cannot be precisely determined from the data, the best approximation should be used. | 如果无法从数据中精确确定PERSON.DEATH_DATETIME，则应使用最佳近似值。 |
| 5 | Any cause of death should be stored in the CONDITION_OCCURRENCE table, using the CONDITION_TYPE vocabulary with the DEATH_TYPE concept class. | 任何死因都应存储在CONDITION_OCCURRENCE表中，使用带有DEATH_TYPE概念类的CONDITION_TYPE词汇表。 |
| 6 | All observations relating to death should be stored in the OBSERVATION table, including the concept 4306655. | 与死亡有关的所有观察都应存储在观察表中，包括概念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 | 不应将PERSON表中的DEATH_DATETIME用作查找所有死亡的方法select * from PERSON where death_datetime is not null 不应该是这种做法相反，应通过OBSERVATION表找到死亡，PERSON表仅用于确定分析中应使用哪个死亡日期 |
本系列在介绍目前世界上最适用于临床科研+卫生经济学的标准医疗大数据格式（未经严谨考证，但有相关研究发表在专业期刊上），俨然是真实世界研究方案里面最接进成熟的基础建设方案。感兴趣的介绍请移步B站观看视频。
OHDSI——观察性健康医疗数据科学与信息学，是一个世界性的公益型非盈利研究联盟，主要研究全方位医学大数据分析的开源解决方案，旨在通过大规模数据分析和挖掘来提升临床医学数据价值，实现跨学科、跨行业的多方合作。目前，目前，已有来自美国、加拿大、澳大利亚、英国等几十个国家地区的上百个组织机构，高校，医院和公司企业参与了OHDSI全球协作网络，如斯坦福、哈佛、杜克大学医学院，强生、诺华、甲骨文、IBM公司，拥有超过6亿人口的临床数据规模，累计协作研究发表了上百篇论文。
我们在这里邀请国内对相关工作感兴趣、愿共同学习的好学人士参与到中文兴趣小组，互通有无，一起弥补跨行业、跨学科的知识积累。前期主要以对OHDSI在github上的开源工作进行翻译、交流、学习为主，并会对医疗大数据、医学统计学、生物信息学等学科知识建立学习互助、互督的机制。有兴趣的请看文档，微信群二维码在内：OHDSI中文兴趣小组共识&OHDSI介绍
OHDSI秉持开源、开放的宗旨，加快全球医学数据研究的步伐，本文内容原创来自Github（https://github.com/OHDSI/CommonDataModel/wiki），若有利益冲突，请在本页面留言，真-侵删。
