MIMIC 多参数ICU医疗数据集表结构_valueuom-程序员宅基地

技术标签：电子病历 MIMIC数据集

MIMICIII数据表信息

部分表格中字段解释为空，是因为该字段在其他表格中也存在，没有进行重复解释。如发现错误，可留言。

表1：admission

表来源：医院数据库。

表内容：病人的住院情况。

表行数：58976。

表间联系：通过subject_id与patients表相关。

SUBJECT_ID可能重复，重复说明该病人有多次入院。

Name	Postgres data type	Description
ROW_ID	INT	行号
SUBJECT_ID	INT	每位病人的标识
HADM_ID	INT	每行一个，代表病人入住医院记录
ADMITTIME	TIMESTAMP(0)	入院时间
DISCHTIME	TIMESTAMP(0)	出院时间
DEATHTIME	TIMESTAMP(0)	住院期间死亡的才有值，通常=DISCHTIME
ADMISSION_TYPE	VARCHAR(50)	住院类型 ‘ELECTIVE’:计划好的入院 ‘URGENT’和‘EMERGENCY’:意料之外的入院 ‘NEWBORN’:新生儿
ADMISSION_LOCATION	VARCHAR(50)	入院前病人的位置信息(9个取值) EMERGENCY ROOM ADMIT TRANSFER FROM HOSP/EXTRAM TRANSFER FROM OTHER HEALT CLINIC REFERRAL/PREMATURE INFO NOT AVAILABLE TRANSFER FROM SKILLED NUR TRSF WITHIN THIS FACILITY HMO REFERRAL/SICK PHYS REFERRAL/NORMAL DELI
DISCHARGE_LOCATION	VARCHAR(50)	出院位置
INSURANCE	VARCHAR(255)	保险，人口统计信息
LANGUAGE	VARCHAR(10)	语言，人口统计信息
RELIGION	VARCHAR(50)	宗教信仰，人口统计信息
MARITAL_STATUS	VARCHAR(50)	婚姻状态，人口统计信息
ETHNICITY	VARCHAR(200)	种族，人口统计信息
EDREGTIME	TIMESTAMP(0)	进入急诊部的时间
EDOUTTIME	TIMESTAMP(0)	搬离急诊部的时间
DIAGNOSIS	VARCHAR(300)	诊断，自由文本，最终会议ICD形式在Diagnoses表中给出
HOSPITAL_EXPIRE_FLAG	TINYINT	医院专家标志？
HAS_CHARTEVENTS_DATA	TINYINT	是否有图表(chartevent)数据。

表2：callout

表来源：医院数据库。

表内容：提供病人准备从ICU转出或者已经从ICU转出时相关信息。

表行数：34499。

表间联系：通过subject_id与patients表相关；

通过hadm_id与admissions表相关。

Name	Postgres data type	Description
ROW_ID	INT	行号
SUBJECT_ID	INT	每位病人标志符
HADM_ID	INT	入院记录标志符
SUBMIT_WARDID	INT	提交出院申请的病房ID
SUBMIT_CAREUNIT	VARCHAR(15)	SUBMIT_WARDID是否与ICU费用中心相对应，如果是的话，是什么类型的ICU费用中心
CURR_WARDID	INT	病人callout时所在的病房ID
CURR_CAREUNIT	VARCHAR(15)	CURR_WARDID对应哪个ICU费用中心
CALLOUT_WARDID	INT	病人从哪个病房出院 =0代表‘Home’ =1代表‘First available ward’
CALLOUT_SERVICE	VARCHAR(10)	病人出院的服务
REQUEST_TELE	SMALLINT	值为二进制，表示病人是否要求了某种预防措施
REQUEST_RESP	SMALLINT	同上
REQUEST_CDIFF	SMALLINT	同上
REQUEST_MRSA	SMALLINT	同上
REQUEST_VRE	SMALLINT	同上
CALLOUT_STATUS	VARCHAR(20)	呼叫状态
CALLOUT_OUTCOME	VARCHAR(20)	病人最终是否出院 ‘Discharged’ or ‘Cancelled’
DISCHARGE_WARDID	INT	病人出院的病房号。0代表home
ACKNOWLEDGE_STATUS	VARCHAR(20)	对callout请求的处理 ‘Acknowledged’‘Revised’‘Unacknowledged‘Reactivated’.
CREATETIME	TIMESTAMP(0)	callout请求发起时间
UPDATETIME	TIMESTAMP(0)	callout请求变更时间
ACKNOWLEDGETIME	TIMESTAMP(0)	callout请求首次应答时间
OUTCOMETIME	TIMESTAMP(0)	记录CALLOUT_OUTCOME的时间
FIRSTRESERVATIONTIME	TIMESTAMP(0)	病房预定信息
CURRENTRESERVATIONTIME	TIMESTAMP(0)	病房预定信息

表3：caregivers

数据来源：Carevue 与Metavision数据库。

数据表内容：记录医护人员信息。

数据行数：7567。

表间联系：通过cgid与chartevents表相关。

Name	Postgres data type	Description
ROW_ID	INT
CGID	INT	医护人员ID
LABEL	VARCHAR(15)	定义了医护人员的类型，例如 RN，MD，PharmD等
DESCRIPTION	VARCHAR(30)	医护人员的附加信息

表4：chartevents

表来源：Carevue 与Metavision数据库。

表内容：记录所有病人的图表数据。

表行数：330,712,483。

表间联系：

通过 SUBJECT_ID与PATIENTS表相关

通过HADM_ID与ADMISSIONS相关

通过ICUSTAY_ID与ICUSTAYS相关

通过ITEMID与D_ITEMS相关

通过 CGID与CAREGIVERS 相关

简介：chartevent包含了所有可供患者使用的图表数据。在他们的ICU停留期间，病人信息的主要存储库是他们的电子图表。电子图表显示病人的日常生命体征和与他们的护理有关的任何额外信息：呼吸机设置、实验室值、代码状态、精神状态等等。因此，关于病人住院的大部分信息都包含在chartevent中。此外，即使在其他地方捕获了实验室值（labevent），它们也经常在chartevent中重复。这是因为在病人的电子图上显示实验室值是可取的，因此这些值是从存储实验室值的数据库复制到存储chartevent的数据库中。当labevent中的值与chartevent中的值不同时，以labevent中的值为准。

Name	Postgres data type	In CareVue	In Metavision	字段含义
ROW_ID	INT	Y	Y	行号
SUBJECT_ID	NUMBER(7,0)	Y	Y	每个病人都不一样，病人标识
HADM_ID	NUMBER(7,0)	Y	Y	每次住院都不一样，住院标识
ICUSTAY_ID	NUMBER(7,0)	Y	Y	每次住ICU都不一样，ICU入住标识
ITEMID	NUMBER(7,0)	Y	Y	测量类型标志符
CHARTTIME	DATE	Y	Y	观测进行的时间
STORETIME	DATE	Y	Y	记录值被人工验证输入系统的时间
CGID	NUMBER(7,0)	Y	Y	医护人员标识
VALUE	VARCHAR2(200 BYTE)	Y	Y	ITEMID标识的项目测量的值。如果这个值是数字，那么VALUENUM以数字格式包含相同的数据。如果这个数据不是数字，那么VALUENUM就是null
VALUENUM	NUMBER	Y	Y	在某些情况下（例如格拉斯哥昏迷量表、里士满镇静激动量表和代码状态），VALUENUM包含分数和值，其中包含分数和文本，描述了分数的含义。
VALUEUOM	VARCHAR2(20 BYTE)	Y	Y	是value的度量单位
WARNING	NUMBER(1,0)		Y	警告和错误是Metaversion特定的列，提出某些值增高了记录在警告中
ERROR	NUMBER(1,0)		Y	在测量过程中发生了错误
RESULTSTATUS	VARCHAR2(20 BYTE)	Y		CareVue特定的列，指定测量的类型（结果状态是手动的或自动的）
STOPPED	VARCHAR2(20 BYTE)	Y		CareVue特定的列，是否停止了测量

表5：cptevents （current procedural terminology）

表来源：医院数据库。

表内容：包含当前的程序（CPT）代码，它有助于为病人的程序进行计费。

行数：573146。

表间联系：通过subject_id与patients关联；

通过hadm_id与admissions关联。

简介：cptevent表包含了一个列表，列出了当前的程序术语代码，供哪些患者使用。每个代码表示在ICU停留期间对患者执行的不同过程。

Name	Postgres data type	Description
ROW_ID	INT
SUBJECT_ID	INT
HADM_ID	INT
COSTCENTER	VARCHAR(10)	为相应的CPT代码收费的成本中心。有两种可能的成本中心：'ICU'和'Resp'。 “Resp”代码对应于机械或非侵入性通气，由呼吸治疗师收费。 “ICU”代码对应于ICU计费的程序
CHARTDATE	TIMESTAMP(0)	治疗发生的时间
CPT_CD	VARCHAR(10)	CPT_Code,治疗代码
CPT_NUMBER	INT	CPT_CD列的数字形式，方便查询时进行范围比较。CPT_CD并非都是数字都是
CPT_SUFFIX	VARCHAR(5)	当CPT_CD包含非数字字符时，CPT_SUFFIX列包含文本后缀
TICKET_ID_SEQ	INT	CPT_CD顺序
SECTIONHEADER	VARCHAR(50)	标题，标志CPT类别，是使用D_CPT表分配
SUBSECTIONHEADER	VARCHAR(300)	子标题，标志CPT类别，是使用D_CPT表分配
DESCRIPTION	VARCHAR(200)	有对应的呼吸成本中心的CPT代码时，该列解释代码意义，否则为空

表6：d_cpt

表来源：在线定义。

表内容：当前程序术语（CPT）代码的高级定义。

行数：134。

表关联：CPT_CD上的CPTEVENTS介于MINCODEINSUBSECTION和MAXCODEINSUBSECTION之间。

简介：这个表给出了关于当前程序术语（CPT）代码的一些高级信息。提供了程序(procedure)的目的，并在某些情况下提供了治疗程序的正文。但对于单个代码的详细信息是不可用的。注意：与所有其他表不同，D_CPT与CPTEVENTS中的CPT_CD并没有并没有一个一对一的映射，而D_CPT的每一行都映射到CPT_CD的范围内。？？？

Name	Postgres data type	Description
ROW_ID	INT
CATEGORY	SMALLINT	数字，定义CPT_Code的类别
SECTIONRANGE	VARCHAR(100)	给定部分的代码范围
SECTIONHEADER	VARCHAR(50)	对给定部分的描述，有8个可能的部分 Evaluation and management Surgery Radiology Anesthesia 麻醉 Emerging technology Pathology and laboratory Performance measurement Medicine
SUBSECTIONRANGE	VARCHAR(100)	对给定子部分的代码范围
SUBSECTIONHEADER	VARCHAR(300)	对给定子部分的描述
CODESUFFIX	VARCHAR(5)	当CPT_CD包含非数字字符时，CPT_SUFFIX列包含文本后缀
MINCODEINSUBSECTION	INT	SUBSECTIONRANGE中的最小值
MAXCODEINSUBSECTION	INT	SUBSECTIONRANGE中的最大值

表7：prescriptions

表来源：医院供货商订单输入数据库。
表内容：包含药物相关的订单条目，即处方。
行数：4,156,450

表关联：通过subject_id与patients关联

通过hadm_id与admissions关联

通过icustay_id与icustays关联

表简介：如果订单之后作为MIMICIII V1.0取消时，表中不会指出。

Name	Postgres data type	Description
ROW_ID	INT
SUBJECT_ID	INT
HADM_ID	INT
ICUSTAY_ID	INT
STARTDATE	TIMESTAMP(0)	与ENDDATE一起制定处方有效的日期
ENDDATE	TIMESTAMP(0)	与STARTDATE一起制定处方有效的日期
DRUG_TYPE	VARCHAR(100)	药品的类型
DRUG	VARCHAR(100)	药品名称
DRUG_NAME_POE	VARCHAR(100)	药品名称
DRUG_NAME_GENERIC	VARCHAR(100)	药品名称
FORMULARY_DRUG_CD	VARCHAR(120)	标准药品编码，字符形式
GSN	VARCHAR(200)	通用序列号（也是药品编码），数字形式
NDC	VARCHAR(120)	国家（美国）药品编码，数字形式
PROD_STRENGTH	VARCHAR(120)
DOSE_VAL_RX	VARCHAR(120)	剂量值
DOSE_UNIT_RX	VARCHAR(120)	剂量单位（片/ml..）
FORM_VAL_DISP	VARCHAR(120)	同上，剂量值
FORM_UNIT_DISP	VARCHAR(120)	剂量单位
ROUTE	VARCHAR(120)	给药途径（口服PO/静脉注射IV/肌肉注射IM/静脉滴注IV DRIP/皮下注射SC）

表8：inputevents_cv

注：input是进入病人体内的流体，output是从病人体内排出或抽取的体液。

表来源：CareVue ICU数据库。
表内容：患者输入数据。
行数：17,527,935。

表关联：通过SUBJECT_ID与PATIENTS关联

通过HADM_ID与ADMISSIONS关联

通过ICUSTAY_ID与ICUSTAYS关联

通过ITEMID与D_ITEMS 关联

通过CGID与CAREGIVERS 关联

Name	Postgres data type	Description
ROW_ID	INT
SUBJECT_ID	INT
HADM_ID	INT
ICUSTAY_ID	INT
CHARTTIME	TIMESTAMP(0)	表示测量图表的时间 - 即记录在床边的临床信息系统。对于收到的数量（通常是交易量），CHARTTIME表示收到该交易量的时间。也就是说，它可以被认为是“结束时间”，即通过该CHARTTIME向患者施用X毫升溶液。对于速率，CHARTTIME表示设定该速率的时间。也就是说，它可以被认为是“开始时间”，即患者现在在该CHARTTIME接受X mcg / kg / min的药物。
ITEMID	INT	数据库中单个测量类型的标识符。与一个ITEMID（例如212）相关联的每一行对应于相同测量的实例化（例如，心率）。 Metavision ITEMID值均高于220000.CareVue数据中常用药物的子集的ITEMID值介于30000-39999之间。剩余的输入/输出ITEMID值介于40000-49999之间
AMOUNT	DOUBLE PRECISION	AMOUNT和AMOUNTUOM列出在STARTTIME和ENDTIME之间（如果两者都可用）或在ENDTIME（当确切的开始时间未知，但通常最多一小时之前）给予患者的药物或物质的量
AMOUNTUOM	VARCHAR(30)
RATE	DOUBLE PRECISION	RATE和RATEUOM列出了药物或物质在STARTTIME和ENDTIME之间（如果两者都可用）给予患者的速率，或者列出了药物目前在ENDTIME给药的速率
RATEUOM	VARCHAR(30)
STORETIME	TIMESTAMP(0)	记录手动输入观察或由临床人员手动验证的时间
CGID	BIGINT
ORDERID	BIGINT	ORDERID将同一解决方案中包含的多个项目链接在一起。例如，当给予去甲肾上腺素和生理盐水的溶液时，去甲肾上腺素和生理盐水都出现在不同的行上但具有相同的ORDERID
LINKORDERID	BIGINT	LINKORDERID在多个实例中链接相同的顺序：例如，如果更改了使用去甲肾上腺素和生理盐水的解决方案的速率，将生成两个共享相同新ORDERID的新行，但LINKORDERID将是相同的。
STOPPED	VARCHAR(30)	表示输液是否已断开或继续
NEWBOTTLE	INT	表示是否在床边悬挂了新的溶液制剂
ORIGINALAMOUNT	DOUBLE PRECISION
ORIGINALAMOUNTUOM	VARCHAR(30)
ORIGINALROUTE	VARCHAR(30)
ORIGINALRATE	DOUBLE PRECISION
ORIGINALRATEUOM	VARCHAR(30)
ORIGINALSITE	VARCHAR(30)

表9：inputeevents_mv

表来源：Metavision ICU数据库。
表目的：患者输入数据。
行数：3,618,991。

表关联：通过SUBJECT_ID与PATIENTS关联

通过HADM_ID与ADMISSIONS关联

通过ICUSTAY_ID与ICUSTAYS关联

通过ITEMID与D_ITEMS 关联

通过CGID与CAREGIVERS 关联

Name	Postgres data type	Description
ROW_ID	INT	同inputevent_cv
SUBJECT_ID	INT
HADM_ID	INT
ICUSTAY_ID	INT
STARTTIME	TIMESTAMP(0)
ENDTIME	TIMESTAMP(0)
ITEMID	INT
AMOUNT	DOUBLE PRECISION
AMOUNTUOM	VARCHAR(30)
RATE	DOUBLE PRECISION
RATEUOM	VARCHAR(30)
STORETIME	TIMESTAMP(0)
CGID	BIGINT
ORDERID	BIGINT
LINKORDERID	BIGINT
ORDERCATEGORYNAME	VARCHAR(100)	管理类型？
SECONDARYORDERCATEGORYNAME	VARCHAR(100)	二级管理类型
ORDERCOMPONENTTYPEDESCRIPTION	VARCHAR(200)	描述药物成分在治疗方案中的作用
ORDERCATEGORYDESCRIPTION	VARCHAR(50)	描述药物类别在治疗方案中的作用
PATIENTWEIGHT	DOUBLE PRECISION	病人体重
TOTALAMOUNT	DOUBLE PRECISION	通常通过在床边悬挂一袋液体实现在一段时间内连续输注来进行静脉给药。 TOTALAMOUNT和TOTALAMOUNTUOM列出了包含溶液的袋中的流体总量
TOTALAMOUNTUOM	VARCHAR(50)
ISOPENBAG	SMALLINT
CONTINUEINNEXTDEPT	SMALLINT	是否进入下一个部门
CANCELREASON	SMALLINT	（治疗）命令取消的原因
STATUSDESCRIPTION	VARCHAR(30)	输液停止的原因。6种状态
COMMENTS_STATUS	VARCHAR(30)	（治疗）命令是否已编辑或取消
COMMENTS_TITLE	VARCHAR(100)	取消或编辑订单的人的职位
COMMENTS_DATE	TIMESTAMP(0)	取消或编辑订单的人的日期
ORIGINALAMOUNT	DOUBLE PRECISION	药物的剩余量
ORIGINALRATE	DOUBLE PRECISION	原始输液速率

表10：outputevent

表来源：CareVue和Metavision ICU数据库。
表目的：患者的输出数据。
行数：4,349,218。

表关联：通过SUBJECT_ID与PATIENTS关联

通过HADM_ID与ADMISSIONS关联

通过ICUSTAY_ID与ICUSTAYS关联

通过ITEMID与D_ITEMS 关联

通过CGID与CAREGIVERS 关联

Name	Postgres data type	Description
ROW_ID	INT
SUBJECT_ID	INT
HADM_ID	INT
ICUSTAY_ID	INT
CHARTTIME	TIMESTAMP(0)	输出时间
ITEMID	INT
VALUE	DOUBLE PRECISION	VALUE和VALUEUOM列出CHARTTIME中物质（）的数量（当确切的开始时间未知时，通常最多一个小时）。
VALUEUOM	VARCHAR(30)
STORETIME	TIMESTAMP(0)	医护人员手动验证和输入数据的时间
CGID	BIGINT
STOPPED	VARCHAR(30)	(治疗)命令是否被中止
NEWBOTTLE	INT	是否有新药
ISERROR	SMALLINT	Metavision复选框，护理人员可以指定观察是一个错误

表11：labevents

表来源：医院数据库。
表目的：包含给定患者的所有实验室测量值，包括患者数据。
行数：27,854,055。

表间关联：通过SUBJECT_ID与PATIENTS

通过HADM_ID与ADMISSIONS

通过ITEMID与D_LABITEMS

注：labevents和chartevents表之间有些项目相同。如果测量结果之间存在分歧，则应将labevent作为基本事实。

Name	Postgres data type	Description
ROW_ID	INT
SUBJECT_ID	INT
HADM_ID	INT
ITEMID	INT	测量类型标志符
CHARTTIME	TIMESTAMP(0)	记录观察图表的时间。由于数据直接来自实验室数据库，因此未经ICU临床工作人员验证，因此没有相关的STORETIME
VALUE	VARCHAR(200)	VALUE包含为ITEMID标识的概念测量的值。如果此值为数字，则VALUENUM以数字格式包含相同的数据。如果此数据不是数字，则VALUENUM为空。在某些情况下（例如格拉斯哥昏迷量表，里士满镇静激动量表和代码状态等分数），VALUENUM包含分数，VALUE包含分数和描述分数含义的文本
VALUENUM	DOUBLE PRECISION
VALUEUOM	VARCHAR(20)	VALUE的单位
FLAG	VARCHAR(20)	采用预定阈值指示实验室值是否正常

表12:d_icd_diagnoses

表来源：在线资源。
表目的：ICD诊断的定义表。
行数：14,567。

表间关联：通过ICD9_CODE与DIAGNOSES关联。

简介:该表定义了DIAGNOSES的ICD-9代码。这些代码在病人住院的最后时间点给出，用来对住院期间给与的医疗服务计费。

Name	Postgres data type	Description
ROW_ID	INT
ICD9_CODE	VARCHAR(10)	ICD9_CODE，每个Code代表一个诊断
SHORT_TITLE	VARCHAR(50)	对给定代码的简单描述
LONG_TITLE	VARCHAR(300)	同上

表13：d_icd_procedures

表来源：在线资源。
表目的：ICD程序的定义表。
行数：3,882。
表间关联：通过ICD9_CODE与PROCEDURES_ICD关联。

简介:该表定义了PROCEDURES的ICD-9代码。这些代码在病人住院的最后时间点给出，用来对住院期间给与的医疗服务计费。还可用来观测执行了哪些治疗程序。

Name	Postgres data type	Description
ROW_ID	INT
ICD9_CODE	VARCHAR(10)	ICD9_CODE，每个Code代表一个procedure
SHORT_TITLE	VARCHAR(50)	对给定代码的简单描述
LONG_TITLE	VARCHAR(300)	同上

表14：d_items

表来源：CareVue和Metavision ICU数据库。
表目的：ICU数据库中所有项目的定义表。
行数：12,487
表间关联：
通过ITEMID与CHARTEVENTS关联

     通过ITEMID与DATETIMEEVENTS关联
     通过ITEMID与INPUTEVENTS_CV关联
     通过ITEMID与INPUTEVENTS_MV关联
     通过SPEC_ITEMID，ORG_ITEMID或AB_ITEMID与MICROBIOLOGYEVENTS （例如，使用d_items.ITEMID = microbiologyevents.SPEC_ITEMID）
     通过ITEMID与OUTPUTEVENTS关联
     通过ITEMID与PROCEDUREEVENTS_MV关联

简介：D_ITEMS来自两个不同的ICU数据库。每个概念都有重复的ITEMID。

例如：心率被可以为211的ITEMID（CareVue）和220045的ITEMID（Metavision）。 ITEMID重复的另一个原因是CareVue中数据输入的自由文本，单个概念的拼写错误或同义描述，可能导致出现多个相同ITEMID。

每个ICU数据库系统都有自己的ITEMID集来表示单一概念。

所有Mentavision的ITEMNID>220000。

ITEMID列是此表的备用主键：每一行的ITEMID都是唯一的。

如果LINKSTO列为null，则数据当前不可用，但计划用于未来的版本。

Name	Postgres data type	Description
ROW_ID	INT
ITEMID	INT	表d_item的备用主键
LABEL	VARCHAR(200)	表明ITEMID代表的值
ABBREVIATION	VARCHAR(100)	Metavision特有，LABEL的缩写
DBSOURCE	VARCHAR(20)	表明数据库是Metavision还是Carevue
LINKSTO	VARCHAR(50)	数据链接到的表名
CATEGORY	VARCHAR(100)	ITEMID对应的数据类型，如‘IV Medication’表示药物通过静脉注射
UNITNAME	VARCHAR(100)	ITEMID表示的测量方法的单位
PARAM_TYPE	VARCHAR(30)	描述记录的数据类型：日期，数字或文本字段。
CONCEPTID	INT	未知，数据表中该列全为空

表15：d_labitems

表来源：医院数据库。
表目的：所有实验室测量的定义表。
行数：753
表间联系：通过ITEMID与LABEVENTS关联

简介：包含了所有与实验室检测相关的ITEMID。表LABEVENTS中的所有数据都链接到D_LABITEMS表。医院数据库中每个唯一的LABEL都在此表中分配了一个ITEMID，使用此ITEMID可以有效地存储和查询数据。实验室项目是分开的，大多数项目定义都包含在D_ITEMS表中。

Name	Postgres data type	Description
ROW_ID	INT
ITEMID	INT	实验室检测项目的ITEMID
LABEL	VARCHAR(100)	ITEMID代表的意思
FLUID	VARCHAR(100)	描述检测的液体是什么，血液/尿液/...
CATEGORY	VARCHAR(100)	ITEMID对应的数据类型,“ABG”类别表示测量是动脉血气
LOINC_CODE	VARCHAR(100)	LOINC_CODE包含与给定ITEMID关联的LOINC代码。 LOINC是一种本体，最初指定了实验室测量，但后来扩展到涵盖了广泛的临床相关概念。 LOINC公开提供一个表，其中包含有关每个LOINC代码的大量详细信息。该表可在线免费获取，也可由数据库的监护人提供。???

表16：datetimeevents

表来源：CareVue和Metavision ICU数据库。
表目的：包含所有日期格式的数据。
行数：4,485,937
表间联系：
通过SUBJECT_ID与PATIENTS关联
通过HADM_ID与ADMISSIONS关联

     通过ICUSTAY_ID与ICUSTAYS关联
     通过ITEMID与D_ITEMS关联
     通过CGID与CAREGIVERS关联

Name	Postgres data type	Description
ROW_ID	INT
SUBJECT_ID	INT
HADM_ID	INT
ICUSTAY_ID	INT
ITEMID	INT	项目ID
CHARTTIME	TIMESTAMP(0)	记录进行检测的时间
STORETIME	TIMESTAMP(0)	由医护人员人工验证数据记录到系统的时间
CGID	INT	医护人员ID
VALUE	TIMESTAMP(0)
VALUEUOM	VARCHAR(50)
WARNING	SMALLINT
ERROR	SMALLINT
RESULTSTATUS	VARCHAR(50)
STOPPED	VARCHAR(50)

表17：diagnoses_icd

表来源：医院数据库。
表目的：包含患者的ICD诊断，最明显的是ICD-9诊断。
行数：651,047
表间联系：
     通过SUBJECT_ID与PATIENTS关联
     通过HADM_ID与ADMISSIONS关联
     通过ICD9_CODE与D_ICD_DIAGNOSES关联

Name	PostgreSQL data type	Modifiers	Description
ROW_ID	INT	not null
SUBJECT_ID	INT	not null
HADM_ID	INT	not null
SEQ_NUM	INT		SEQ_NUM提供ICD诊断与患者相关的顺序。 ICD诊断按优先级排序
ICD9_CODE	VARCHAR(10)		与给定用户相关联的诊断代码

表18：drgcodes

表来源：医院数据库。
表目的：包含患者的诊断相关组（DRG）代码。
行数：125,557
表间联系：
通过SUBJECT_ID与PATIENTS关联
通过HADM_ID与ADMISSIONS关联

简介：HCFA-DRG代码具有多个描述，因为它们随时间而变化。有时这些描述是相似的，但有时它们是完全不同的诊断。用户需要使用代码和描述来选择行。

Name	PostgreSQL data type	Description
ROW_ID	INT
SUBJECT_ID	INT
HADM_ID	INT
DRG_TYPE	VARCHAR(20)	提供DRG代码的类型。数据库中有两种类型的DRG代码，具有重叠的范围，'HCFA'（Health Care Financing Administration）和'APR'（All Payers Registry）。
DRG_CODE	VARCHAR(20)	诊断代码
DESCRIPTION	VARCHAR(300)	对给定的DRG_CODE进行自然语言的简述
DRG_SEVERITY	SMALLINT	DRG_SEVERITY和DRG_MORTALITY为“APR”DRG类型中的DRG代码提供了额外的粒度。诊断更严重时，严重性和死亡率允许更高的计费成本，反之亦然。
DRG_MORTALITY	SMALLINT

表19：icustays

表来源：医院数据库。
表目的：定义数据库中的每个ICUSTAY_ID，即定义单个ICU停留。
行数：61,532。
表间关联：
SUBJECT_ID与PATIENTS
HADM_ID与ADMISSIONS

简介：ICUSTAY_ID是生成的标识符，不基于任何原始的数据标识符。ICUSTAYS表来自TRANSFERS表。根据ICUSTAY_ID对TRANSFERS表进行分组，并排除不存在ICUSTAY_ID的行。

Name	PostgreSQL data type	Description
ROW_ID	INT
SUBJECT_ID	INT
HADM_ID	INT
ICUSTAY_ID	INT	ICUSTAY_ID将所有ICU入院时间间隔24小时
DBSOURCE	VARCHAR(20)	数据库来源,Metavision(2008-2012) or Carevue(2001-2008)
FIRST_CAREUNIT	VARCHAR(20)	患者被给予的第一种护理
LAST_CAREUNIT	VARCHAR(20)	患者被给予的最后一种护理
FIRST_WARDID	SMALLINT	患者第一次入住的ICU单元
LAST_WARDID	SMALLINT	患者最后一次入住的ICU单元
INTIME	TIMESTAMP(0)	患者入住ICU的时间
OUTTIME	TIMESTAMP(0)	患者转出ICU的时间
LOS	DOUBLE	入住ICU的时长

表20：microbiologyevents

表来源：医院数据库。
表目的：包含微生物学信息，包括进行的测试和敏感性。
行数：631,726。
表间联系：
     通过SUBJECT_ID与PATIENTS关联
     通过HADM_ID上与ADMISSIONS关联
     通过SPEC_ITEMID与D_ITEMS关联
     通过ORG_ITEMID与D_ITEMS关联
     通过AB_ITEMID与D_ITEMS关联

Name	Postgres data type	Description
ROW_ID	INT
SUBJECT_ID	INT
HADM_ID	INT
CHARTDATE	TIMESTAMP(0)	记录检测的时间
CHARTTIME	TIMESTAMP(0)	同CHARTDATE
SPEC_ITEMID	INT	细菌生长的标本ID
SPEC_TYPE_DESC	VARCHAR(100)	描述标本类型
ORG_ITEMID	INT	生物体ID 如果有生物体的话，在测试时生长。没有生物体生长（即阴性培养物）为NULL
ORG_NAME	VARCHAR(100)	生物体名称
ISOLATE_NUM	SMALLINT	为了测试抗生素，分离的菌落（整数;从1开始）
AB_ITEMID	INT	如果对给定生物进行了抗生素针敏感性测试，该列列出其ITEMID
AB_NAME	VARCHAR(30)	如果对给定生物进行了抗生素针敏感性测试，该列列出其名称
DILUTION_TEXT	VARCHAR(10)
DILUTION_COMPARISON	VARCHAR(20)
DILUTION_VALUE	DOUBLE PRECISION	测试抗生素敏感性时的稀释值
INTERPRETATION	VARCHAR(5)	解释抗生素的敏感性，并指出试验结果。 “S”:敏感的， “R”:抗性的， “I”:中间的， “P”:待定的

表21：noteevents

表来源：医院数据库。
表目的：包含患者的所有注释。
行数：2,083,180
表间联系：
通过SUBJECT_ID与PATIENTS关联
通过HADM_ID与ADMISSIONS关联

通过CGID与CAREGIVERS关联

Name	Postgres data type	Description
ROW_ID	INT
SUBJECT_ID	INT
HADM_ID	INT
CHARTDATE	TIMESTAMP(0)	记录note的时间
CATEGORY	VARCHAR(50)	note类别，如：‘Discharge’代表是discharge note
DESCRIPTION	VARCHAR(300)	对note类别的描述
CGID	INT	医护人员ID
ISERROR	CHAR(1)	值为“1”，表明医护人员认为该note有错
TEXT	TEXT	note text

表22：patients

表来源：CareVue和Metavision ICU数据库。
表目的：包含所有患者的所有的charted（图表？）数据。
行数：46,520
链接到：
通过SUBJECT_ID与ADMISSIONS关联
通过SUBJECT_ID与ICUSTAYS关联

Name	Postgres data type	Description
ROW_ID	INT
SUBJECT_ID	INT
GENDER	VARCHAR(5)	性别
DOB	TIMESTAMP(0)	出生日期。数据库中超过89岁的患者的出生日期会发生改变，以模糊他们的年龄并遵守HIPAA。转变过程：确定患者首次入院时的年龄。然后将出生日期定为第一次入院前的300年
DOD	TIMESTAMP(0)	死亡日期
DOD_HOSP	TIMESTAMP(0)	医院数据库中记录的死亡日期
DOD_SSN	TIMESTAMP(0)	社会保障数据库记录的死亡日期
EXPIRE_FLAG	VARCHAR(5)	EXPIRE_FLAG是一个二进制标志，指示患者是否死亡，即DOD是否为空。这些死亡包括医院内的死亡（DOD_HOSP）和通过将患者与社会安全主死亡指数（DOD_SSN）匹配而确定的死亡

表23：procedureevents_mv

表来源：Metavision ICU数据库。
表目的：包含患者的（治疗）程序
行数：258,066
表间关联：
     通过SUBJECT_ID与PATIENTS关联
     通过HADM_ID与ADMISSIONS关联
     通过ICUSTAY_ID与ICUSTAYS关联

通过ITEMID与D_ITEMS关联

Name	Postgres data type
ROW_ID	INT NOT NULL
SUBJECT_ID	INT NOT NULL
HADM_ID	INT NOT NULL
ICUSTAY_ID	INT
STARTTIME	TIMESTAMP(0)
ENDTIME	TIMESTAMP(0)
ITEMID	INT
VALUE	DOUBLE PRECISION
VALUEUOM	VARCHAR(30)
LOCATION	VARCHAR(30)
LOCATIONCATEGORY	VARCHAR(30)
STORETIME	TIMESTAMP(0)
CGID	INT
ORDERID	INT
LINKORDERID	INT
ORDERCATEGORYNAME	VARCHAR(100)
SECONDARYORDERCATEGORYNAME	VARCHAR(100)
ORDERCATEGORYDESCRIPTION	VARCHAR(50)
ISOPENBAG	SMALLINT
CONTINUEINNEXTDEPT	SMALLINT
CANCELREASON	SMALLINT
STATUSDESCRIPTION	VARCHAR(30)
COMMENTS_EDITEDBY	VARCHAR(30)
COMMENTS_CANCELEDBY	VARCHAR(30)
COMMENTS_DATE	TIMESTAMP(0)

表24：procedures_icd

表来源：医院数据库。
表目的：包含患者的ICD程序，最值得注意的是ICD-9程序。
行数：240,095。
表间关联：
     通过SUBJECT_ID与PATIENTS关联
     通过HADM_ID与ADMISSION关联
     通过ICD9_CODE与D_ICD_PROCEDURES关联

简介：ICD代码是在住院结束时生成用于计费目的的。
在MIMIC-III中记录所有患者住院的ICD代码。

Name	PostgreSQL data type	Modifiers	Description
ROW_ID	INT	not null
SUBJECT_ID	INT	not null
HADM_ID	INT	not null
SEQ_NUM	INT		procedure执行顺序
ICD9_CODE	VARCHAR(10)		给定procedure对应的ICD-9代码

表25：services

表来源：医院数据库。
表目的：列出患者被接纳/转移的服务。
行数：73,343
表间联系：
通过SUBJECT_ID与PATIENTS关联
通过HADM_ID与ADMISSIONS关联

简介：服务表描述了患者接受的服务。虽然患者可以在物理上位于特定的ICU类型（例如MICU），但是他们不一定受到MICU工作人员的照顾。这可能是由于多种原因造成的，包括床位不足。如果想要确定患者在医院接受的服务类型，则应使用“服务”表。例如，如果对识别手术患者感兴趣，推荐的方法是搜索在外科手术服务下入院的患者。
每个服务在表中都采用缩写，对应说明如下：

Service	Description
CMED	Cardiac Medical - for non-surgical cardiac related admissions
CSURG	Cardiac Surgery - for surgical cardiac admissions
DENT	Dental - for dental/jaw related admissions
ENT	Ear, nose, and throat - conditions primarily affecting these areas
GU	Genitourinary - reproductive organs/urinary system
GYN	Gynecological - female reproductive systems and breasts
MED	Medical - general service for internal medicine
NB	Newborn - infants born at the hospital
NBB	Newborn baby - infants born at the hospital
NMED	Neurologic Medical - non-surgical, relating to the brain
NSURG	Neurologic Surgical - surgical, relating to the brain
OBS	Obstetrics - conerned with childbirth and the care of women giving birth
ORTHO	Orthopaedic - surgical, relating to the musculoskeletal system
OMED	Orthopaedic medicine - non-surgical, relating to musculoskeletal system
PSURG	Plastic - restortation/reconstruction of the human body (including cosmetic or aesthetic)
PSYCH	Psychiatric - mental disorders relating to mood, behaviour, cognition, or perceptions
SURG	Surgical - general surgical service not classified elsewhere
TRAUM	Trauma - injury or damage caused by physical harm from an external source
TSURG	Thoracic Surgical - surgery on the thorax, located between the neck and the abdomen
VSURG	Vascular Surgical - surgery relating to the circulatory system

Name	Postgres data type	Description
ROW_ID	INT
SUBJECT_ID	INT
HADM_ID	INT
TRANSFERTIME	TIMESTAMP(0)	从PREV_SERVICE转到CURR_SERVICE的时间
PREV_SERVICE	VARCHAR(20)	患者之前接受的服务
CURR_SERVICE	VARCHAR(20)	患者现在接受的服务

表26：transfers

表来源：医院数据库。
表目的：患者整个住院期间的物理位置。
行数：261,897。
表间关联：
     SUBJECT_ID与PATIENTS关联
     HADM_ID与ADMISSIONS关联
     ICUSTAYS与ICUSTAY_ID关联

简介：   ICUSTAYS表来自此表。
     护理单元基于与ICU成本中心相关联的WARDID来定义。
     Beth Israel的ICU多年来一直在移动，因此相同的WARDID可被视为患者A的ICU，而不是患者B的ICU。

Name	Postgres data type	Description
ROW_ID	INT
SUBJECT_ID	INT
HADM_ID	INT
ICUSTAY_ID	INT
DBSOURCE	VARCHAR(20)	数据库来源
EVENTTYPE	VARCHAR(20)	描述了发生了什么转移事件：“admit”:入院，“transfer”：转院，“discharge”：出院
PREV_CAREUNIT	VARCHAR(20)	患者之前住的护理单元
CURR_CAREUNIT	VARCHAR(20)	患者现在住的护理单元护理单元基于病房定义：如果病房是ICU成本中心，则护理单元定义为ICU的类型。如果病房不是ICU，那么在大多数情况下，护理单位为空。例外：NWARD是新生儿的病房。
PREV_WARDID	SMALLINT	患者住的前一个病房
CURR_WARDID	SMALLINT	患者住的当前病房医院数据库中的物理位置分组称为病房。虽然在实践中ICU不被称为病房，但医院数据库在技术上将ICU跟踪为“具有ICU成本中心的病房”。结果，每个ICU与WARDID相关联，但并非每个WARDID都是IC
INTIME	TIMESTAMP(0)	CURR_CAREUNIT的入住时间
OUTTIME	TIMESTAMP(0)	CURR_CAREUNIT的转出时间
LOS	INT	给定病房的住院时间，不一定是ICU，可能是普通病房

Care units 包括:

Care unit	Description
CCU	Coronary care unit
CSRU	Cardiac surgery recovery unit
MICU	Medical intensive care unit
NICU	Neonatal intensive care unit
NWARD	Neonatal ward
SICU	Surgical intensive care unit
TSICU	Trauma/surgical intensive care unit

本文链接：https://blog.csdn.net/sz891016/article/details/83537524

原作者删帖不实内容删帖广告或垃圾文章投诉

智能推荐

c# 调用c++ lib静态库_c#调用lib-程序员宅基地

文章浏览阅读2w次，点赞7次，收藏51次。四个步骤1.创建C++ Win32项目动态库dll 2.在Win32项目动态库中添加外部依赖项 lib头文件和lib库3.导出C接口4.c#调用c++动态库开始你的表演...①创建一个空白的解决方案，在解决方案中添加 Visual C++ , Win32 项目空白解决方案的创建：添加Visual C++ , Win32 项目这......_c#调用lib

deepin/ubuntu安装苹方字体-程序员宅基地

文章浏览阅读4.6k次。苹方字体是苹果系统上的黑体，挺好看的。注重颜值的网站都会使用，例如知乎：font-family: -apple-system, BlinkMacSystemFont, Helvetica Neue, PingFang SC, Microsoft YaHei, Source Han Sans SC, Noto Sans CJK SC, W..._ubuntu pingfang

html表单常见操作汇总_html表单的处理程序有那些-程序员宅基地

文章浏览阅读159次。表单表单概述表单标签表单域按钮控件demo表单标签表单标签基本语法结构<form action="处理数据程序的url地址“ method=”get|post“ name="表单名称”></form><!--method将表单中的数据传送给服务器处理，get方式直接显示在url地址中，数据可以被缓存，且长度有限制；而post方式数据隐藏传输，_html表单的处理程序有那些

PHP设置谷歌验证器（Google Authenticator）实现操作二步验证_php otp 验证器-程序员宅基地

文章浏览阅读1.2k次。使用说明:开启Google的登陆二步验证（即Google Authenticator服务）后用户登陆时需要输入额外由手机客户端生成的一次性密码。实现Google Authenticator功能需要服务器端和客户端的支持。服务器端负责密钥的生成、验证一次性密码是否正确。客户端记录密钥后生成一次性密码。下载谷歌验证类库文件放到项目合适位置(我这边放在项目Vender下面)https://github.com/PHPGangsta/GoogleAuthenticatorPHP代码示例://引入谷_php otp 验证器

【Python】matplotlib.plot画图横坐标混乱及间隔处理_matplotlib更改横轴间距-程序员宅基地

文章浏览阅读4.3k次，点赞5次，收藏11次。matplotlib.plot画图横坐标混乱及间隔处理_matplotlib更改横轴间距

docker — 容器存储_docker 保存容器-程序员宅基地

文章浏览阅读2.2k次。①Storage driver 处理各镜像层及容器层的处理细节，实现了多层数据的堆叠，为用户提供了多层数据合并后的统一视图②所有 Storage driver 都使用可堆叠图像层和写时复制（CoW）策略③docker info 命令可查看当系统上的 storage driver主要用于测试目的，不建议用于生成环境。_docker 保存容器

随便推点

网络拓扑结构_网络拓扑csdn-程序员宅基地

文章浏览阅读834次，点赞27次，收藏13次。网络拓扑结构是指计算机网络中各组件（如计算机、服务器、打印机、路由器、交换机等设备）及其连接线路在物理布局或逻辑构型上的排列形式。这种布局不仅描述了设备间的实际物理连接方式，也决定了数据在网络中流动的路径和方式。不同的网络拓扑结构影响着网络的性能、可靠性、可扩展性及管理维护的难易程度。_网络拓扑csdn

JS重写Date函数，兼容IOS系统_date.prototype 将所有 ios-程序员宅基地

文章浏览阅读1.8k次，点赞5次，收藏8次。IOS系统Date的坑要创建一个指定时间的new Date对象时，通常的做法是：new Date("2020-09-21 11:11:00")这行代码在 PC 端和安卓端都是正常的，而在 iOS 端则会提示 Invalid Date 无效日期。在IOS年月日中间的横岗许换成斜杠，也就是new Date("2020/09/21 11:11:00")通常为了兼容IOS的这个坑，需要做一些额外的特殊处理，笔者在开发的时候经常会忘了兼容IOS系统。所以就想试着重写Date函数，一劳永逸，避免每次ne_date.prototype 将所有 ios