# MIMIC- (OLD)

###### tags: `急診數據松`


**MIMIC-III 數據資料**

**患者人口學資料及院內運轉資料**
* 這張表用主要記錄患者的入院情況,用的比較多的可能有患者的人口統計學信息
* 入院時間對我們採集特定時間窗口的患者信息是比較重要的,大多數研究都會用到.
* 死亡時間在對應看患者結局是會用到.
* ICUSTAY表中入科出科的時間戳也很重要;住院時長即在ICU中待的時間的長度.
* PATIENTS表中記錄著患者的信息,可以與ADMISSONS綜合起來使用.比如這裡的死亡日期可以對前面的表做一個補充;通過入院時間和出生日期可以計算出患者的年齡.
* SERVICES和TRANSFERS可能在做一些資源配置的研究中會用到,做生理指標方面的研究時用得較少.

**患者在急診室住院期間採集的各類資料**
* CAREGIVERS用的相對較少
* CHARTEVENTS是最重要的一張表,記錄的大部分是患者生命體徵的數據,如心率,血壓,體溫等等.該表是通過患者編號\病案號和ICU編號作為聯合主鍵確定患者．項目標誌符也就是item_id,比如心率這個項目所對應的項目標識符可以在d_labitems字典中查到.記錄時間和存儲時間是對應該項的存儲時間.記錄時間可以用於篩選特定的時間窗口(比如說進入ICU24小時內的數據).要用到前面的ICUSTAYS的入科時間以及當前測量的時間做差值,從而確定研究隊列.
* DATETIMEEVENTS表中主要是患者操作信息,使用相對較少.
* 兩張INPUTEVENTS應組合起來使用.提供比如說患者給藥的速率(如葡萄糖輸入的速率),給藥途徑,給藥部位.基於這兩個表可以做一些關於給藥,藥物干預方面的研究
* NOTEEVENTS大部分是患者的醫囑,如患者的既往史和現病史等,再比如患者體溫波動的情況等,都是通過文本形式給出的.
* OUTPUTEVENTS主要記錄了患者的出量信息,比如說患者的尿量等信息,可以作為患者生命情況的表示.
* PROCEDUREEVENTS記錄諸如手術開始時間,結束時間,手術操作等信息

**醫院紀錄系統採集的各類數據**
* DIAGNOSES_ICD表中記錄了患者的ICD-9診斷編碼,比如說想做一些疾病診斷或疾病預測的研究時會用到.一個患者可能會對應多個診斷,所以是一個序列格式的表.可能會認為第一個是患者的主病.
* DRGCODES表中記錄了患者的診斷類別和診斷編碼
* LABEVENTS表中是患者的化驗項目,有比如像白細胞,紅細胞這種指標值.LABEVENTS,CHARTEVENTS和OUTPUTSEVENTS表合起來基本上可以代表患者進入ICU後生理指標的大部分特徵.
* PRESCRIPTIONS中是患者的用藥記錄,和前面的INPUTEVENTS綜合起來可以作為用藥干預的研究
* PROCEDURE_ICD表記錄的是病人的手術記錄.

**字典資料**
前面提到抽取患者的數據比如說生命體徵,心率等,實驗室指標(如白細胞紅細胞等)等,就需要在相應的字典中找到相應的item,即項目標識符,再對應查找某一個患者對應指標下的數據.心率,血壓等指標在D_ITEMS中查找索引

**數據表中的基本信息**

**MIMIC-III代碼庫**
網址:https://github.com/MIT-LCP/mimic-code
https://github.com/MIT-LCP/mimic-iii-paper/
* 比較常用到的有concepts文件夾中的,記錄著大部分可以獲得患者生命指標的SQL代碼.durations是患者出入量的信息.firstday是封裝好了的獲取患者第一天(即前24h)的生理指標的數據.

**研究主題**
在此主要是對三屆Datathon的研究題目進行總結

相關題目

**總結的分類任務的基本流程**
在具體的研究工作中,通常花費最多時間的還是在數據收集和預處理的過程中,模型通常還是比較現成的.
首先是研究主題的確定,比如研究患者的死亡風險預測,那麼需要選擇患者結局(是否死亡,什麼時間死亡等指標)等,可以通過看相關論文以及和相關醫生作溝通來選擇預測指標;指標確定之後,就是研究隊列及指標納入標準的確定,比如說針對膿毒症的患者,那麼研究隊列是膿毒症的患者;一般來說會選擇不同入院(hadm_id)中的第一次進入ICU的數據;患者的某個指標的數據缺失率也應被考慮在納入指標當中(通過設定一個缺失率閾值來判斷是否使用某個指標);通常選用前24h的指標.
區間值轉比如說白細胞有記錄是less than 5,就可以轉換成2.5或採用當作缺失值的方法. 單位轉換比如說INPUTEVENTS_CV和INPUT_MV中可能存在單位不一致的情況,需要按照臨床上一些標准進行單位轉換


## :memo: Where do I start?

### Step 1: MIMIC-III學習範例連結

- [MIMIC-III 資料庫中患者住院次數分佈](https://www.itread01.com/content/1545379590.html)
- [MIMIC-III 如何利用重症醫學資料庫MIMIC開展研究](http://www.ifuun.com/a2018062614216205/)
- [跟著mimic-code探索MIMIC數據之筆記本CRRT（1）](https://github.com/JackieMium/my_blog/issues/26/)
- [跟著mimic-code探索MIMIC數據之筆記本CRRT（2）](https://github.com/JackieMium/my_blog/issues/25/)
- [跟著mimic-code探索MIMIC數據之筆記本CRRT（3）](https://jiangjun.netlify.app/post/mimic-code-notebooks-crrt3/)
- [基於MIMIC-III數據庫對ICU患者結局預測的研究](http://cs.china-cmd.org/zgylsb/fileup/HTML/2019-12-92.shtml)
- [MIMIC-III数据集介绍](https://blog.csdn.net/qq_43787862/article/details/105028846)

### Step 2: 欄位說明
- **subject_id** 代表了每一個患者，在資料庫中，一個subject_id就收入了一個患者。
- **hadm_id** 相當於國內醫院的住院號，每一次的住院就會自動給你生成一個住院號，一個患者可能會擁有多個住院號。
- **icustay_id** 一個患者一次住院可以有多次進入ICU。但是同時也存在這一個ICU轉入另一個ICU單元時，icustay_id不變的情況
- **資料庫患者住院次數的分佈** 在這裡，我們主要使用SQL查詢語句進行查詢。想要知道“每個患者在這個資料庫中住了多少次醫院？”，我們只需要知道，“每個患者到底有多少個hamd_id”，也就是說，“在以hadm_id，作為唯一識別符號的ADMISSIONS表中，查看出現了多少次的subject_id”就行
- **使用聚合函式進行查詢**
COUNT：計算表中的記錄數目
SUM：計算表中數值列中資料的合計值
AVG：計算表中數值列中資料的平均值
MAX：計算表中數值列中資料的最大值
MIN：計算表中數值列中資料的最小值

### Step 3: MIMIC-III PostgreSQL範例
我們所需要的是COUNT函式來計算出現多少次的subject_id。當然，僅僅使用COUNT函式，回報的就是這個表有多少行。比如：

SELECT COUNT(*)
FROM mimiciii.admissions

執行結果為：

count
------
58976

所以，我們還需要使用GROUP BY語句進行分組，查詢如下：

SELECT subject_id,count(*) as admissiontimes
FROM mimiciii.admissions
GROUP BY subject_id

這樣，我們就可以得到每個subject_id出現了多少次了。
那麼，如果我們想要得到僅僅只住了一次醫院的病人怎麼辦？
我們可以使用HAVING子句在分組中選擇住院一次的患者：

SELECT subject_id,COUNT(*) as admissiontimes
FROM mimiciii.admissions
GROUP BY subject_id
HAVING COUNT(*) =1

至於，HAVING和WHERE子句的區別，這裡主要簡單的提一點。
WHERE子句是指定行所對應的條件，而HAVING子句指定組所對應的條件。

### Step 4: MIMIC III 資料庫的結構
MIMIC III 資料庫共包含了26個CSV格式的表格，這些表格詳細記錄了患者在ICU治療期間的幾乎所有的數據，比如實驗室檢查數據、人口學特徵、微生物學檢查結果、住院期間的流轉、治療過程、液體進出量等。表格主要分為兩種，一種是以D開頭的，表示該表格為字典，比如d_labitems，表示實驗室檢查字典，內含每個實驗室檢查結果的說明；沒有以D打頭的表格則是記錄患者信息的表格，比如labevents則表示患者住院期間的所有實驗室檢查結果

**關於MIMIC III 的資料庫結構，需要特別注意的幾點是：**

1. MIMIC IIII 資料庫中用於識別患者身份的欄位共有3個：subjects_id，hadm_id和icustay_id。其中subjects_id是患者身份的唯一標識，即一個subject_id只對應一名患者，一名患者也只有一個subject_id。hadm_id是患者每次住院的身份識別號，一個患者可能多次住院，因此一個subjects_id會對應多個hadm_id，但一個hadm_id只能對應一個subject_id。icustay_id表示患者在進入ICU的編號，因為患者一次住院可以多次進入不同的ICU，因此一個icustay_id只能對應一個hadm_id，當然也只能對應一個subject_id，但一個hadm_id可以對應多個icustay_id。在利用 MIMIC III 資料庫進行研究時，往往需要運用sql語言對多個資料庫進行連接，連接的基礎一般就是這三個欄位。

2. 患者的臨床資料不一定是住ICU期間的臨床資料，也可能是住普通病房時的資料。記錄患者入院時間的表格為admission，內含三個時間點：admittime，表示患者入院時間；dischartime，表示患者出院時間；deathtime，表示患者院內死亡的時間。如果deathtime為空(null)，則表示患者住院期間未死亡。記錄患者進入和離開ICU的表格為icustays，這個表格中有兩個時間較為重要，分別是intime和outtime，前者表示進入ICU的時間，後者表示離開ICU的時間。當然，如果患者在ICU死亡，那麼dischartime、outtime和deathtime理論上就是同一個時間，但實際上會稍微有些出入，估計是由於錄入不及時造成的；

3. MIMIC III 中的數據來自於兩套數據採集系統：carevue和metavision。在icustays表格中，有一個欄位叫dbsource，用於標識數據是來源於carevue還是metavision。CareVue記錄的是2001至2008年入院的患者資料，Metavision則是2008至2012年期間入院的患者資料。在Metavision中，病人的隨訪時間最少為90天，在CareVue中，病人的隨訪時間則至少為4年。換而言之，在進行預後研究時，如果將數據來源限定為CareVue，則可以將隨訪時間假定為4年，對於4年以後死亡的患者，可以將其在出院後第4年生存狀況定義為「存活」。當然，如果患者的死亡狀況(DOD_SSN)為空格(null)，也同樣可以表明患者在出院後4年仍然存活。

### Step 5: MIMIC III 資料提取
在寫sql代碼時，最好先執行「set search_path to mimiciii」，隨後的所有操作均不需要指明表格的位置；否則，任何操作都應該在表格名前面加前綴mimiciii；
github上有很多現成的代碼包可以直接使用，連接網址為：https://github.com/MIT-LCP/mimic-code
這些代碼包主要是計算一些患者的特徵或者定義某一類患者，比如一些重症評分(如APS III、SIRS評分等)、共病指數、定義嚴重膿毒症、急性腎損傷人群等。對於計算機編程基礎較為薄弱的同行而言，充分利用這些腳本可以少走彎路；

利用github上的腳本可以生成一些新的物化視圖，這些物化視圖保存在materialized view目錄下；

### Step 6: 如何利用 MIMIC III 資料庫
#### 開展研究示例
MIMIC III 資料庫為普通醫生，特別是重症醫學科醫生開展臨床研究提供了極大的便利，因為該數據不僅資料詳細，而且包括隨訪資料。其隨訪終點包括：住院期間死亡、ICU內死亡和出院後的全因死亡。如何利用該資料庫開展臨床科研視個人專業情況而定。筆者結合自己利用 MIMIC III 資料庫開展臨床研究的經歷，談一些簡單的研究方法和套路。

對影響重症病人預後的因素進行探討具有極為重要的價值，因為疾病預後在很大程度上可以影響治療措施的制定。筆者的主要研究方向之一就是實驗室標誌物與重症患者預後的關係。

#### 這一類研究的主要套路就是
1. 利用diagnoses_icd中的診斷和順序(seq_num)從所有重症病人中篩選出一類自己感興趣的疾病的患者，得到患者的subject_id、hadm_id和icustay_id；

2. 從d_labitems和labevents中找到自己感興趣的實驗室標誌物：採用group、row_number等語句限定患者入院(或進入ICU)的第一次檢查結果或特定時間內的檢查結果；

3. 從patients中提取出患者的基本特徵，包括死亡時間(dod_ssn)或是否發生院內死亡；

4. 從icustays中找到患者的出院時間 (dischtime)，結合患者的死亡時間(dod_ssn)計算出隨訪時間。注意：來源於carevue的病例隨訪時間最短為4年，來源於metavision中的數據最短隨訪時間為90天；

5. 從github上找到計算各種嚴重程度評分的腳本，然後在本地電腦中運行得出各個患者每次住院的疾病評分(比如SOFA、SAPS II、APS III等)，並將這些嚴重評分納入最終的統計學分析。

6. 這類研究整體的思路就是：首先展示研究對象的基本特徵，包括人口學特徵、實驗室檢查結果、嚴重程度評分結果、院內死亡率等。然後分析待研究的實驗室指標個患者臨床特徵的關係(這部分研究有時也可以省略)，最後採用Kaplan-Meier曲線和Cox風險比例模型分析實驗室標誌物與疾病預後的關係。

7. 如果研究的終點是院內死亡，則可以用受試者工作特徵曲線(ROC)曲線和多元logistic回歸方程對實驗室標誌物的預後價值進行研究。筆者曾利用 MIMIC II 資料庫研究過紅細胞體積分布寬度(RDW)與進入ICU治療的急性胰腺炎患者預後的關係[4]、研究RDW、中性粒細胞/淋巴細胞比值(NLR)與蛛網膜下腔出血患者遠期預後的關係[5]、研究紅細胞平均血紅蛋白濃度、鉀離子與急性心肌梗死患者預後的關係[6]。

8. 此外，國外學者也曾研究過RDW、NLR與所有重症患者(不考慮其進入ICU的最初診斷)預後的關係[7,8]。利用 MIMIC III 開展的研究都是觀察性研究，在設計上遵循一般觀察性研究的套路，一般就是先進行單變數的分析，比如ROC分析、Kaplan-Meier曲線等，然後再進行混雜因素的校正。

9. 經典的校正混雜因素的方法是多元logistic回歸、Cox風險比例模型，近年來一些新的校正混雜因素的方法也越來越普及，比如傾向匹配分析、工具變數分析等。此外，有時需要證明某一實驗室標誌物可以提供其它臨床資料所不能提供的預後信息，此時，就需要用c-statistic、凈重分層指數(NRI)和綜合改良區指數(IDI)等方法了。

10. 除了研究預後外，筆者還曾利用 MIMIC III 資料庫中重症患者的鈣離子檢測結果開展過關於鈣離子危機值的研究。眾所周知，外周血鈣離子可以分為離子鈣和結合鈣，其中發揮生理作用的是離子鈣。但離子鈣只能在血氣分析儀上檢測，總鈣(離子鈣加上結合鈣)卻可以在生化儀上檢測，因此總鈣的檢測在臨床上更為多見。
>> 臨床實驗室制定的危急值包括總鈣危急值和離子鈣危急值，嚴格來講，只有離子鈣危急了才能算真正的危機值，也就是說：離子鈣才是金標準，畢竟血液中真正發揮作用的是離子鈣。臨床上，總鈣危急值的設置是否合理，是否能準確地預測出真正的鈣危急值(離子鈣危急值)尚不明確。

>>造成這種困局的主要原因就是：臨床上很少有病人會同時檢測離子鈣和總鈣。MIMIC III 資料庫中的病人都是重症患者，離子鈣和總鈣檢測結果較多，這就為筆者評價和探討總鈣危急值的設定提供了可性能。筆者首先從資料庫中提取了所有的離子鈣檢測結果，然後尋找同時檢測了總鈣、白蛋白，且總鈣、白蛋白檢測時間和離子鈣檢測時間相隔不超過1小時的患者資料。

>>這樣就會形成多個「總鈣-離子鈣-白蛋白」組合，筆者以國際公認的離子鈣危急值設定範圍來確定患者是否屬於高鈣血症或低鈣血症的「危急值」，隨後筆者採用受試者工作特徵(ROC)曲線法分析了總鈣預測離子鈣危急值的能力，最終發現總鈣預測低鈣血症危急值的準確性較差，但預測高鈣血症危急值的準確性較高。該文目前已被Journal of Clinical and Laboratory Analysis接受。