2014年5月26日星期一

Early Goal Directed Therapy 治療敗血性休克,真的沒有比標準治療好嗎?

敗血症 (sepsis),是指嚴重細菌感染造成的全身性發炎反應,會導致敗血性休克、多重器官衰竭...等等,有很高的死亡率,常需要加護醫療。這一直是內科和重症醫學當中,非常重要的一個主題,也是醫師養成過程必學的重點。
早期目標導向治療 (Early Goal Directed Therapy, 或簡稱 EGDT),從被提出並制定 Surviving Sepsis Campaign 治療指引發行之後,一直以來都是敗血症的標準治療方式。但因為全套的標準EGDT,操作繁複、耗費人力物力,並且需要一些侵入性的處置(例如中央靜脈導管置放和測量壓力),因此不免也受到一些質疑。
今年三月,在內科第一名的期刊 - 新英格蘭醫學雜誌(NEJM) 刊登了一篇挑戰傳統 EGDT 觀念的文章,名為 "A Randomized Trial of Protocol-Based Care for Early Septic Shock"。這篇文章報導了一個名為 ProCESS 的臨床試驗,結論是"使用 EGDT 治療早期敗血性休克,並未優於一般"標準療法"
這個聳動的結論一出來,馬上引起大家的熱烈討論。畢竟 EGDT 是我們行之有年,奉之為圭臬,積極執行的治療,當初發展出來時,研究也證實可顯著降低死亡率,但經過十年後,最新的實證醫學研究卻告訴我們,上全套EGDT,和使用一般標準治療結果居然沒差?難道做這麼多都是白忙一場嗎?既然內科第一名的期刊都這樣刊登了,難道這意味著以後敗血症病人,不需要再做 EGDT 治療了嗎
Randomized  Control Trial 當然是實證醫學很高的等級,但這樣看似無懈可擊的研究,並非沒有缺陷。 NEJM 這篇文章和隨機試驗的結論當然是對的,但是直接套用在我們的臨床情境,並不合適!魔鬼藏在細節裡,以下試著針對這篇研究,做進一步的分析:
這篇研究採用分三組的設計,實驗組是標準 EGDT 治療,對照組則是按照特定簡化 protocol 的標準治療 (standard treatment),和按照醫師自己判斷的一般簡單治療 (casual treatment)。
首先,要仔細看 ProCESS Trial 的 protocol,和它隨附的原始資料 Supplement,不難發現以下問題:
  • 在控制組,也就是沒有接受 EGDT 的一般治療組,病人 60 天死亡率只有 18%。可是根據 Rivers 等人 2001 年做的 EGDT 最早的研究 [1] 我們知道,敗血症沒有接受 EGDT,僅接受一般治療,死亡率會高達 > 50%。相較之下,在 ProCESS Trial 中,只接受一般治療者,60 天死亡率低得出奇。作者解釋這是因為近年醫療進步,所以標準治療的死亡率也降低很多,但這點是令人存疑的。原因如下:
    1. 本研究收案之初,就排除了大部分的病人,只留下相對輕症患者。其中心臟衰竭的患者和其他比較嚴重的狀況,都是研究的排除條件。但這些患者,卻是臨床常見的狀況,所以試驗的研究族群,和臨床加護病房的狀況,其實顯著不同。
    2. 本ProCESS研究收案對象,只有21-26%有呼吸衰竭,但當初 Rivers 的敗血症研究,有 53% 都需要使用呼吸器,這也就意味著,這個 Trial 收案的對象,相對原本 EGDT 的研究族群,明顯比較輕症 (呼吸衰竭少了一半)。
    3. 在 72 小時內,為了穩定患者血壓,原 2001 年 EGDT 研究累計平均每名患者給了 13358 ml 的 fluid resuscitation,而在 ProCESS Trial,每人平均只需要給 6633 ml,只需要一半的藥量,這再次意味著,本研究收案對象,相對原本 EGDT 的研究對象相比,"比較好治療"。 
    4. 綜合以上,不難發現,本研究收案對象,是比較好治療的族群,並不能代表大多數的敗血症患者。雖然研究有列出 APACHE II score 來表示患者嚴重度,但現有文獻都證實這不是很準確的嚴重度指標。作者並未提供 SOFA score 的資料。
  • 標準治療組,給予的其實不是"一般治療",而是 ProCESS 研究制定的一個很嚴格的 Protocol。在這個 Protocol 裡面,也需要給大量的 fluid challenge,也需要使用升壓劑,其實還是給了 EGDT 裡面大部分的東西,換湯不換藥,除了:
    1. 不強調 Central line,不強制建議打中央靜脈導管,但仔細看 Supplement 會發現,控制組仍然有高達 60% 其實是被放了中央靜脈導管,和 EGDT 組一樣。他只是 protocol 沒有建議要放,但大部分還是都有放。
    2. 沒有測量中央靜脈壓力,判斷是否需要繼續給水,單靠評估臨床反應和頸靜脈搏動。
    3. 中央靜脈壓,近年的研究本來就已經證實,是一個不準確的體液容積評估方法[2],可以想見,若做了 EGDT 大部分的東西,只是不測量中央靜脈壓,當然不會對死亡率造成顯著的影響。
    4. 這個根據固定 Protocol 的高品質標準治療,其實比一般臨床的治療還要嚴格得多,並非真的是醫生照自己意思隨便治療都會活。
綜合以上,這篇文章帶來的訊息,正確的解讀應該是「對於比較輕微的早期敗血性休克患者,若是沒有心臟衰竭、肺水腫、呼吸衰竭,或其他嚴重的問題,只要能給予高品質的標準治療,或許不需要打中央靜脈導管上全套的 EGDT,但是仍然需要很積極治療」
至於其他比較重症的患者,因為和研究收案對象不同,其實無法引用此篇結論。
實證醫學雖然是對的,但結論不能夠套在每個病人身上。若要以此篇文獻來宣稱敗血性休克不需要給予 EGDT,恐怕還言之過早!

以上為筆者研讀文獻之個人淺見,請內科同業先進,不吝賜教指正。

參考資料:

  1. Rivers E, Nguyen B, Havstad S, et al. Early goal-directed therapy in the treatment  of severe sepsis and septic shock. N Engl J Med 2001;345:1368-1377 
  2. Marik PE, Cavallazzi R. Does the central venous pressure predict fluid responsiveness? An updated meta-analysis and a plea for some common sense. CritCare Med. 2013 Jul;41(7):1774-81. doi: 10.1097/CCM.0b013e31828a25fd. PubMed PMID:23774337.

2014年1月12日星期日

交大 TEDx 演講:那些年,我們一起上的 BBS (2013-11-30)

發源自美國,風行全球的 TED 18 分鐘演講大家應該不陌生 (TED = Technology, Entertainment, and Design)。來自不同領域的講者,用短短的 18 分鐘,以說故事的方式 ,傳達理念給聽眾。而 TED 公司,也授權讓世界各地獨立的團體,以同樣的形式辦演講,稱作 TEDx (X 指 independent,就是獨立舉辦的意思)。
這股 TEDx 風潮,當然也來到了台灣,國內陸續有 TEDxTaipei 等類似活動。2013年11月,適逢交大領袖學程的學生們,將 TEDx 演講首次引進交大。在超過半年的籌備之後,自主在交大開辦第一屆的 TEDxNCTU 年會。真的辦得很棒!邀請的講者們來自不同領域,各有各的故事。我很榮幸,能有機會受邀成為其中一名講者,可以跟交大的朋友們一同分享想法。



其實當初會受到邀請還滿訝異的,後來一想,交大是以工程聞名的學校,長期為科技產業挹注了無數工程人才,學生中一定也有 BBS 宅宅鄉民愛好者。會對 BBS 軟體發展背後的故事有興趣,就顯得很合理了!
真的很感謝交大的同學們,給我這個寶貴的機會講 TEDxNCTU。對我來說,這也算是自己的一個突破和全新的嘗試。雖然過去在 COSCUP, 及其他自由軟體相關活動,有一些演講經驗,但之前真沒有嘗試過 TED 形式的 18 分鐘演講,也沒有講過和電腦技術無關的主題,幸好現場觀眾很捧場。在準備的時候,總覺得 18 分鐘太短,放不下我想講的東西,但真正在台上講的時候,卻覺得 18 分鐘太長了。要完全不靠投影片,講不能冷場的 18 分鐘,試過才知道真的不容易!中間在講的時候,我沒有照著稿子背,漏了一小段,所以講完只有 16 分鐘。不過,幸虧在台上臨場想到了新的哏,順利的銜接過去,似乎沒有觀眾發現呢!
 講 TEDx 是個很寶貴的經驗,雖然號稱講者,我覺得我反而學到很多。只是我口袋裡的哏暫時都用完了,下次又要想些新的了。希望大家喜歡這次的演說。

2013年9月26日星期四

新酷音輸入法 9/26 更新

下載連結:
https://docs.google.com/file/d/0B4BhmC8V2mivYnZkRUw2SnRVNlk/edit?usp=sharing

注意:Windows xp 使用者需要手動開啟「進階文字服務支援」,才能使用,不幸此項設定 xp 預設是關閉的,只能手動打開。請參考這篇「啟用進階文字服務」。
請不要在來信問為什麼 xp 底下不能用了,記得要開啟這個選項!

此次更新部份:
  1. 多螢幕下使用,選字視窗可以正確顯示在目前螢幕
  2. 修復選字時若滑鼠點擊輸入欄不能再輸入文字
  3. 修復造成其他 windows 內建的輸入法無法開啟內容選單
  4. 可自訂 ` 鍵快速輸入的符號表
  5. 修正有時不能打全形空白
  6. 修正應用程式快速鍵 Ctrl + C, Ctrl+V, ...等失效的問題
  7. 安裝程式改善,自動解安裝舊版
待解決:
  1. 全螢幕遊戲需要 UILess mode,要另外實做,之後有時間會設法支援,但前提是遊戲本身要先正確實作 Windows TSF 支援,才有辦法使用。這是已知問題,請不要再一直回報 bug 說遊戲不能用了。
  2. 使用者詞庫編輯部份,上游 libchewing 開發者還在改善這部份,未來可能會支援編輯或匯入,但是現階段因為輸入法引擎部份,開發團隊還沒改好,暫不提供。
我本來要測試有沒有辦法支援遊戲,但是現在的遊戲都太大了,隨便一個網路遊戲都要十幾 GB... 我硬碟裝不下了。請推薦裡面可打字的小遊戲給我,方便測試,我會想辦法支援。


2013年9月24日星期二

新酷音輸入法9/25修正

2013-09-25 更新,最新連結:
https://docs.google.com/file/d/0B4BhmC8V2mivYnZkRUw2SnRVNlk/edit?usp=sharing

注意:Windows xp 使用者需要手動開啟「進階文字服務支援」,才能使用,不幸此項設定 xp 預設是關閉的,只能手動打開。請參考這篇「啟用進階文字服務」。

此次更新部份:
  1. 修正 Windows xp 無法正確載入的問題
  2. 將輸入法設定獨立到自己的程式內,而不放在輸入法常駐 dll 內,減少資源耗用
  3. 選字視窗文字大小可自由設定
  4. 選字視窗預設改為每列 3 個字,每頁 9 個字,類似九宮格式的排列,如此視線移動較少的距離,就能看到所有候選字,且使用游標選字的話,平均移動距離會最短。(若使用不習慣者可自行更改設定)
  5. 新增打繁體輸出簡體的功能,要用時由輸入法選單裡面勾選開啟,或可直接設定為預設打繁出簡。
  6. 新增鍵盤對應:台灣華語羅馬拼音、注音二式
  7. 修正設定值沒有正確儲存的問題
待解決:
  1. 選字視窗在多螢幕下會跑錯螢幕,我還沒修正,因為手上只有單螢幕無法測試,回家有雙螢幕再來修正。
  2. 全螢幕遊戲需要 UILess mode,要另外實做,之後有時間會支援,但前提是遊戲本身要先正確實作 Windows TSF 支援,才有辦法使用。光靠輸入法作者努力是不夠的 orz

2013年9月23日星期一

進擊的新酷音



沒錯,新版又來了,這已經接近正式版了。
https://docs.google.com/file/d/0B4BhmC8V2mivYnZkRUw2SnRVNlk/edit?usp=sharing
大家一定覺得我很閒怎麼這麼有空,其實不是,我花掉了所有休息時間
所以正式版出了之後,還是要休息一下,做點正事,不能一直不務正業

使用上發生問題,請到這裡回報:
https://github.com/chewing/windows-chewing-tsf/issues
在 ptt 推文或是 blog 回文比較不好管理,修 bug 的時候容易漏掉
(而且回報上去其他 libchewing 的開發者才可以幫忙修 bug :p)

目前進度:
1. 支援用方向鍵移動游標選字 (可在設定內開關)
2. 修復 caps lock 英文大小寫忽大忽小問題
3. 修復用 ` 輸入特殊符號選字視窗關不掉
4. 修復部份設定值沒有正確套用
5. 改善輸入法開關切換有時會失效的問題
6. 換用最新 libchewing 引擎,czchen 修好了一些 bugs
7. 穩定性應該是不錯,目前幾乎沒有當機的災情

待改善:
1. 新的圖示有人在畫了,之後再更新這部份
2. 目前還沒支援 UI less mode,在全螢幕遊戲可能還無法使用,這部份可能要
   等到第一版釋出之後再來進行,希望有人可以推薦能支援中文輸入的免費小遊戲
   以方便測試。我現在可能不太方便裝太大型的遊戲來測試,請大家推薦

因為快接近可以釋出第一版了,希望可以增加測試的規模確保品質
拜託各位朋友,如果可以寫寫 blog 或用各種方式幫忙宣傳
謝謝!

2013年9月12日星期四

新酷音Windows版最新進度 - 支援 Windows 8 64-bit

雖然先前本來只打算支援 Windows 8 的 desktop mode,但是經過持續研究,
以及寄信請教 TSF aware blog 作者 Eric Brown,參考日文輸入法 corvus-skk,
加上對岸強大的開發者,小小輸入法的周永 (dgod) 指點,終於知道怎麼做了。
目前新酷音輸入法,初步可以部分支援 Windows 8 modern UI,
我在 Windows 8 試用版裡面測試,已經可在 metro app 裡面使用了!
值得一提的是,對岸高手周永 (dgod),就是我認識的那位 dgod
之前我們還一起開發過 Linux 桌面 LXDE 專案,實在也太巧,
我居然不知道他會寫 TSF 輸入法!! (我猜他應該也不知道我有在寫 XD)

先前從文件上看來,Windows 8 app 模式不能使用許多舊有功能,
很多輸入法必要的 API 竟都被標注為 desktop mode only,
所以我一直想不出來怎麼做。原來,在輸入法是特例,
雖然 dll 是載入到 app container 內,但是 desktop SDK 的 API 是允許使用的。
終於找到一份文件證實這點:
http://msdn.microsoft.com/en-us/library/windows/desktop/hh848069(v=vs.85).aspx
Quote:
When an IME is loaded into a Windows Store app, it is subject to the same app container restrictions as the app itself. This behavior ensures that IMEs are not able to violate Windows Store app security contracts, despite having access to the desktop SDK (because they are not distributed or certified by the Windows Store)
所以,輸入法雖然跑在 app 內,原 Win32 API 是允許的,但是存取的限制,
仍然受到 app container 安全規範,實地測試發現,可以使用 Registry 的 API
但是在 app 內嘗試讀寫系統登錄,都會造成錯誤。讀寫 app 以外的檔案也會權限不足。
故這些 API 雖然可以調用,但是只要存取到 app 不准許存取的資源,就會發生錯誤。

總結來說,目前已經可支援 Windows 8 store app,但還有許多限制沒有克服

  1. 使用者偏好設定,各個 app 內各自獨立,不能互相讀取,也不能讀取系統登錄,也不能存取 app 自己 package 以外的檔案,所以無法讀取設定檔,不能和 desktop mode 共用設定。微軟官方建議的方式是,建立一個 web service 來儲存這些設定。
  2. app 內儲存設定有自己的方式,新的 API 不相容舊版 Windows,所以可能還是需要額外幫 Windows 8 開發自己的版本
  3. 使用者辭庫無法在 app 內使用,因為 app 內讀不到外界的檔案,只有少數幾個許可的位置可讀取,很多更是無法寫入,但是各個 app 隨不同的 capability 又會不同。此問題目前無解。微軟官方建議的方式是,這些資料應該放在雲端。但是沒網路的時候就不能用了,Windows 8 的這種設計哲學在網路連不上的情況會很難實現。
  4. app mode 和 desktop mode 之間互相溝通預設不被允許,除非經過複雜的安全性設定,但是找不到如何設定的文件或範例。目前比較確定能用的,是透過 web service,只不過,為了交換少數資料,而需要架設 web server...真是殺雞焉用牛刀!
  5. Windows store app mode 下沒有語言列,無法顯示狀態,或存取其他功能。
也許,在 app 模式下關閉使用者辭庫功能是個可行的解法,
但是這仍然沒有解決 app 內和 desktop mode 設定要如何共用的問題。
該不會真的需要寫專用的 web server 吧....

TSF 和 32/64 位元支援都完成了,支援 Windows 8 metro app 有譜了,但還有很長的路要走。

2013年9月10日星期二

新酷音輸入法 Windows 版,重新出發!

過去曾經把 Linux 上優秀的輸入法「新酷音」移植到 Windows。
雖然後來實在沒時間再參與了,我自己一直還是有在用新酷音
直到現在,因為工作上需要長時間使用 Windows,難用的
微軟新注音,再次喚回我對新酷音輸入法的懷念。
到了 Windows 7 之後,因為系統架構的改變,
新酷音雖有網友做出支援 64 bit Windows,一直沒能運作得很好
因為 Windows 逐步拋棄舊 IME (imm32) 架構,
轉向採用 COM 技術的新 Text Service Framework (TSF)
複雜度呈直線幅度上升,使得許多舊有 IME 常出現難解的奇怪問題
又因 IME 的諸多限制,使舊的新酷音依賴許多 dirty hacks 在運作
最近 Windows 8 更是全面轉向 TSF,開始準備禁用 IME 架構,
以 TSF 全面重寫看來勢在必行了。
先前有網友陳昌倬 (czchen)的努力,用微軟提供的範例程式改造,
初步證實了 TSF 的可行性,在這個鼓舞之下,
我重啟了 Windows 版新酷音計劃
https://github.com/chewing/windows-chewing-tsf/

經過連日熬夜研究,全新 TSF 架構的 Windows 版新酷音終於快可以用了
基本的架構和 API 以及各種工具都完成了,連語言列按鈕和選單,都能正確運作了!
而因為原先微軟提供的範例,是以微軟自己的 MS-PL  (Microsoft Public License)授權,
雖然也算是自由軟體,但是該授權不相容 GPL,而且衍生著作必須沿用 MS-PL
為了避免這個問題,我只好 from scratch 重寫 TSF 支援。
因為 TSF 大量使用 COM (component object model),並且層層疊疊非常複雜,
對開發者並不友善,我將這部份封裝進 libIME 這個函式庫,
這樣未來的其他輸入法開發者,可以直接套用 libIME 封裝的現成架構,
而不需要了解 TSF 就可以快速寫出支援 Windows 的輸入法。

這裡針對 libIME 程式 API 架構寫了簡易說明文件
供有興趣參與開發的朋友參考,希望可以加速大家移植自己的輸入法

基本上透過 libIME 來實做輸入法是很簡單的
只需要碰觸到非常少 TSF,大部分細節和 COM 操作都被隱藏了
libIME 也提供了許多 Windows GUI programming 的工具 classes
Ime::Window, Ime::Dialog, Ime::PropertyDialog...等等,
幫助實做視窗界面和 config dialog

雖然目前進展很順利,大多數問題也克服了,
但是我接下來會需要忙好一陣子,沒時間改太多 code,
文字輸入的部分還有些問題,希望有其他朋友可以
就現有 code 和文件繼續改良,相信很快就能有可用的發行版

至於 Windows 8 store app 支援,看來是沒有指望了
我有 E-mail 給 TSF aware blog 的作者,他是 MS 員工
專精 TSF,經過他的回答,看來要能支援 win 8 app
基本上是需要整個用 win 8 專屬的新 API 重做,
而且設定和資料基本上需要放上 web 才行
因此雖然也是 TSF,但是等於也是要全部重寫另一個
GUI 也是要用新的架構重寫,舊 GUI code 完全不能用
因為限制實在太多,困難度更高,又需要跟 web 連接
我想這不是我們該支援的東西。
詳見微軟的:Guidelines and checklist for IME development (Windows Store apps)

照現有的狀況看,大部分現有軟體要移植到 win 8 metro
基本上是不可能的,除非全部砍掉重寫...
所以,我個人認為,這是一個沒有前途的平台...
把開發應用程式變得比 Linux 上更困難,只是自廢武功而已
集中精力來支援沒人在用的平台,實在不划算
因此,就這樣吧! 支援 desktop mode 就好了

敬請期待,重生的 Window 版本新酷音 TSF 輸入法!