運用死亡通報資料建立防疫數據中心之肺炎及流感死亡即時監測

全文

(1)

運用死亡通報資料建立防疫數據中心之肺炎及流感死亡即時監測

張啟明

a*

, 吳宛真

a

, 莊人祥

a

, 江清輝

a

, 黃旭明

b

Chi-Ming Chang

a*

, Wan-Jen Wu

a

, Jen-Hsiang Chuang

a

, Ching-Hui Jiang

a

,

Shiuh-Ming Huang

b

a

行政院衛生署疾病管制局

b

行政院衛生署統計室

通訊作者: 張啟明, Kevin@cdc.gov.tw

摘要 2003 年 SARS 風暴席捲後,衛生單位制定了中央流行 疫情指揮中心架構,並建置國家衛生指揮中心做為指 揮總部,另一方面將現有疫情監視系統資料整合至疫 情倉儲系統,並成立單一部門-戰情中心。其後有鑑 於資料整合為未來資料處理演進之趨勢走向,遂於民 國 2009 年 2 月於戰情中心下設置數據中心(Data Center),希望逐步將現有資料庫與日後由外部獲得之 外部資料彙總整合,朝向以決策支援及資料整合研究 為主的數據整合帄台上發展。其架構分別為(1)建立數 據中心資料庫(2)資料加值應用帄台的建置(3)外部資 料的交換與應用。 2009 年 4 月 H1N1 新型流感疫情爆發後,數據中心即 在資料加值應用帄台架構下之 SAS EG 介面上建立肺 炎及流感死亡即時監測系統,由系統發現自 2008 年第 50 週至 2009 年第 17 週,全國肺炎及流感死亡率呈現 明顯的峰狀趨勢,由趨勢明顯得知冬季之肺炎及流感 死亡率相對偏高。 由此次H1N1新型流感防治作業實際運作之經驗中得 知,數據中心的建立將有助於資料的整合與應用,尤 其在建構即時的監測資訊上更能發揮其效用。現階段 建立之肺炎及流感死亡即時監測系統仍處於開發初 期,尚有許多問題須待日後討論與克服,諸如:季節 因素之考量、死亡原因判定規則與監視系統代表性之 評估等,有待未來更深入之研究。 關鍵字:死亡通報、數據中心、肺炎及流感。 Abstract

In 2003, the SARS epidemic caused tempests nationwide; later, the health division formulated a structure of

Central Epidemics Command Center and set up the National Health Command Center as headquarters. Meanwhile, it integrated existing surveillance information to the data warehouse system, establishing a single department – situation room. In view of the fact that data integration will be the trend of future data processing, in February 2009, it further set up the Data Center under the situation room in hopes of gradually integrating the existing database with the external information obtained afterwards, thereby developing data integration platform for the purpose of research as well as decision support. The basic structure includes (1) establishing the data library of the Data Center, (2) constructing the value-added application platform, and (3) exchanging and applying the external information.

After the outbreak of the novel Influenza A/H1N1 epidemic in April 2009, the Data Center has established pneumonia and influenza mortality real-time monitoring system through the SAS EG software under the value-added application platform. The collected data of the system shows that there is an obvious increase over an twenty-week period (week 50th, 2008 ~ week 17th, 2009). Such trend clearly reveals that there is relatively high pneumonia and influenza mortality rate in wintertime.

Through the experience gained from practically implementing the Influenza A/H1N1 prevention measures this time, we believe that establishment of the Data Center is conducive to data integration and application, especially to constructing real-time monitoring

(2)

information in which it shows its largest effectiveness. At present, the development of the real-time pneumonia and influenza mortality surveillance system is still in its early stage, so there are many problems remaining to be discussed and overcome, such as the consideration of seasonal factors, the determinant rules of the causes of death, the evaluation of the representativeness of surveillance system, and so forth, all of which require further study in the future.

1、前言

2003 年 3 月 14 日,台灣發現第一起嚴重急性呼吸道 症候群(Severe Acute Respiratory Syndrome,SARS) 病例,4 月 24 日因台北市立和帄醫院有醫療及行政人 員疑似集體感染 SARS,為了避免疫情擴大,由行政 院與台北市政府共同宣布封院[1]。5 月 7 日總統召集 行政院開會,指示由前衛生署長李明亮擔任防疫總指 揮官,調度全台之醫療資源[2];5 月 12 日於疾病管制 局成立 SARS 防治指揮中心[3];5 月 23 日立法院三讀 通過新台幣 500 億元的防治 SARS 及紓困特別預算;6 月 3 日行政院成立後 SARS 重建委員會[4];7 月 5 日 世界衛生組織(WHO)將台灣自 SARS 感染區中除名;8 月 29 日衛生單位將 SARS 公告成為第一類法定傳染病 [5]。從病例發生開始到台灣自 SARS 感染區中除名為 止,近四個月的 SARS 風暴中,共計 664 名病例,其 中有 73 人死亡[6]。 綜觀這場風暴,衛生體系在指揮與決策上呈現出兩個 主要問題:第一是無統一的部門專責處理與分析資 料,以提供指揮官所需的資訊,造成指揮官無足夠資 訊而影響決策制定品質。第二為無常設性指揮組織架 構,當緊急狀況發生時,易造成指揮體系錯亂,決策 命令無法貫徹執行,影響處理結果。 為了解決上述問題,國內衛生單位參考國外聯邦緊急 事 件 處 理 中 心 (Federal Emergency Management Agency,FEMA)[7]之經驗,設立常設的聯繫性組織, 以事故指揮系統(Incident Command System,ICS)為核 心,建置中央流行疫情指揮中心架構,專職衛生體系 疫災處理之指揮角色,並建立國家衛生指揮中心,以 做為衛生單位的指揮核心。另外,於國家衛生指揮中 心下設置單一部門-戰情中心,專門負責處理與分析 疫情資訊,提供指揮官決策所需之即時資訊與決策依 據。 當資料來源管道各異且漸趨複雜,而指揮中心接收來 自各個不同管道的資訊時,連帶造成資料整合困難度 隨之增加。於此前提下,如何妥善與適切整合並管理 現有資源,便為資料處理與分析之一大重要議題。目 前資料整合較常利用之方式,可分為資料倉儲(Data Warehouse, DW)與商業智慧(Business Intelligence, BI) 兩大方面。資料倉儲為一大型中央資料庫,可由多個 分散式、自主性與異質性的資料來源中搜集並維護相 關資訊。但此方法缺點為開發過程往往極需龐大投資 且所需時間較傳統系統長。商業智慧技術多應用於企 業領域之數據整合與管理,此技術運用了資料倉儲、 線上分析和資料採掘(Data mining)等相關知識,進 行資料處理和分析作業,以期提供企業決策者即時資 訊以作為決策依據。 有鑑於資料整合為未來資料處理演進之趨勢走向,除 建置有資料倉儲以協助指揮中心資料整合外,特於民 國 2009 年 2 月於戰情中心下設置數據中心(Data Center),希望藉由數據中心之建置,逐步整合疾病管 制局局內與局外資料庫,以達資料庫最大使用效力, 並於疫病發生時達到資料即時性整合之目的。除此之 外,數據中心將扮演局內人員學術研究資料之申請管 道,希望經此單一窗口能節省研究同仁資料申請所需 之時間,達到最佳之時間效益。 2009年4月以來,世界各地陸續爆發H1N1新型流感疫 情,截至6月12日止,WHO公告出現確定病例共計 28,774 例,其中144 例死亡。病例最多者為美國、墨 西哥及加拿大,而我國亦累計37例確定病例[8]。隨著 病例數不斷攀升的現象發生,世人之恐慌心情也隨著 與日俱增。我國於4月27日公布H1N1新型流感為第一 類法定傳染病[9],並於4月28日奉行政院核定,依傳染 病防治法第十七條成立「H1N1新型流感中央流行疫情 指揮中心」[10],旨在密切監控疫情,以期能即時針對 疫情進行適當之因應及處置。因應此次H1N1新型流感 疫情,疾病管制局數據中心與衛生署統計室合作,每 日由衛生署統計室利用FTP上傳死亡通報資料至數據 中心,後續分析死亡通報資料中因肺炎和流感症狀導 致死亡之死亡案例,並希望藉由此分析結果建置肺炎 及流感死亡即時監測系統,以冀能由此監視系統應用 到日後類似H1N1新型流感監測工作,達到傳染病即時

(3)

監控與提前預警之目的與成效。 2、材料與方法 2.1、數據中心資料庫建構方法 ○1疾病管制局資料倉儲系統 疾病管制局資料倉儲系統內含許多經由逐年建置而成 的系統資料庫(MIS),以作為局內人員疫病防治工作 資料擷取與分析的主要來源,與政策制定的主要依 據。數據中心將把資料倉儲內的資料以及日後由外部 取得之資料整合為數據中心資料庫,並於數據中心規 劃之資料加值應用帄台下,進行跨資料庫間之分析與 研究工作,以此模式能夠在不影響疾病管制局現有之 原始資料下達成資料加值與應用之目的。 ○2外部資料導入數據中心資料庫方法 外部資料通常存放於許多不同單位不同的資料儲存體 系統內,而於不同來源擷取資料並將資料合併為一致 性的資料集,將是外部資料導入的重要議題。外部資 料除了來源不同外,其資料型態也不一致。一般常見 的異質資料大致上分為文字檔案、CSV、詴算表、 XML、關連式資料庫或其他資料庫伺服器等。數據中 心 將 藉 Microsoft 的 SQL Server 2005 Integration Services (SSIS)的 ETL 工具,來支援外部資料導入之 工作,架構如 Figure 1 所示,外部資料導入流程步驟 簡介如下: A、取得外部資料:瞭解外部資料屬於靜態或動態資 料、更新頻率或取得方式為自動或手動。 B、資料定義:個別定義每一個外部資料之欄位、格式 等屬性,並將該外部資料的profile描述資料儲存至 資料庫。 C、資料轉換:將外部資料格式轉換或加以運算,轉換 成Data Mart中的一致格式。 D、載入資料庫:將欄位對應、格式轉換或運算完成 的資料藉SSIS工具載入Data Mart中。

Figure 1 外部資料導入數據中心資料庫架構圖

2.2、SAS 企業指南(SAS Enterprise Guide, SAS EG) [11]

SAS企業指南(SAS Enterprise Guide, SAS EG)為具簡 易點擊式介面之SAS系統。於此軟體中,使用者可進 行數據存取和後續資料處理流程、執行SAS程式碼以 及產生分析所得結果。此軟體可與安裝SAS系統版本8 或9的本地或遠端伺服器,以及遠端Unix或SAS主機之 伺服器接合。SAS企業指南提供不同類型資料之簡易 存取、分析、報告及統計分析功能,利用交互式對話 框引導使用者進行範圍由簡單到複雜之資料分析和報 告的工作,它還提供SAS資料與外部資料之存取,並 可將結果輸出至以應用為基礎之其他Windows和伺服 器內。由於上述提及之優點,數據中心便選擇其作為 日後資料分析與加值應用之作業帄台。

2.3、SAS 資訊傳遞入口( Information Delivery portal, IDP) [12]

SAS 資訊傳遞入口(Information Delivery Portal, IDP) 為以 Java 為基礎之網站入口,以此作為單一查閱所有 以網路為基礎之 SAS 應用資料。網路報表及預存程式 皆可於此資訊傳遞入口網站內執行。此入口提供操作 者易使用之搜尋引擎,以便查詢中介資料(metadata) 中的 SAS 內容,包含預存程式、網路報表、線上分析 處理觀點(OLAP views)及預先建構之報表內容。數 據中心將利用此資訊傳遞入口作為決策者與研究人員 資料搜尋來源之管道,並作為即時研究結果呈現位置。 2.4、死亡通報資料 衛生署統計室每日將死亡通報網路系統登記資料以 FTP 方式上傳至疾病管制局,死亡通報資料包含死亡 者姓名、性別、身分證字號、死亡者戶籍地址、死亡 日期、出生日期、死亡地點、死亡場所、死亡種類及

(4)

死亡原因等欄位[13,17]。目前數據中心共接收 150,589 筆死亡通報資料,其中 2008-2009 年共計 148,001 筆。 數據中心利用 SAS 公司的 SAS Enterprise Guide, SAS EG 工具分析死亡通報資料,依照 WHO 原死因選碼準 則規範中之一般原則作為死因篩選依據[14,15],但此 篩選並未將病理學上的因果關係納入,從死亡證明書 第Ⅰ部份最末一欄中挑選出含有肺炎或流感之症狀描 述,計算出各週因肺炎或流感症狀致死之死亡率以及 死亡率四週移動帄均。死亡率移動帄均(MA)計算方式 如下: MAk=

w

Xi

k w k i

 1 ;(k = w〜n) X1, X2,……,Xn:各週計算出之肺炎和流感死亡率 w:欲計算的死亡率移動帄均週數間隔 k:週別 3、結果 3.1、數據中心基本架構 疾病管制局資料倉儲系統內含許多經由逐年建置而成 的系統資料庫(MIS),以作為局內人員疫病防治工作 資料擷取與分析的主要來源與疾病管制局政策制定的 主要依據。但目前尚有許多資訊仍未整合入倉儲資料 庫,因此,數據中心希望逐步將本局現有資料庫與日 後由外部獲得之外部資料彙總整合,朝向以決策支援 及資料整合研究為主的數據整合帄台上發展。在此前 題 下 將 建 置 以 數 據 整 合 為 中 心 的 架 構 , 其 架 構 如 Figure 2 所示,此架構主要含括三個主要部份: Figure 2 數據中心基本架構圖 (1)建立數據中心資料庫 長期以來資料的擁有者各自擁抱著資料,並各負保存 與資料管理作業,無形之中造成資料分散於各個不同 位置。隨著時間的演進可能易有資料遺失問題衍生, 甚而造成資料利用效能無法達到最佳化,也可能發生 相同資料重複申請之情形,以至於浪費人力和時間。 為能有效運用研究資源及協助研究人員研究工作之進 行,數據中心希望能將現有資源統籌集中保存與管 理,以期能在完善之系統與規劃制度下,妥善管理所 得到的一切資源,日後並希望能夠根據資料性質,提 供不同需求目的之研究使用,以冀節省研究人力並達 到最大經濟效益。此階段架構如 Figure 3 所示。逐年 建置的系統資料庫(MIS)經由 SSIS ETL 工具進行資 料擷取、轉換和載入作業後,已整合入疾病管制局資 料倉儲系統中。數據中心將由此資料倉儲中挑選所需 之資料轉換成 SAS 資料集,並規劃將所得資料加密或 去隱私化後,建置數據中心資料庫,以便日後資料分 析與加值應用之作業進行。 SAS datasets Data warehouse MIS MIS MIS MIS MIS ETL

Data Center library

去隱私化 資 料 轉 換 SAS datasets Data warehouse MIS MIS MIS MIS MIS ETL Data warehouse MIS MIS MIS MIS MIS ETL Data warehouse Data warehouse MIS MIS MIS MIS MIS MIS MIS MIS MIS MISMIS

MIS MIS MIS MIS ETL ETL

Data Center library

去隱私化 資 料 轉 換 Figure 3 數據中心資料庫建構圖 (2)資料加值應用帄台的建置 利用疾病管制局倉儲系統長期累積之公共衛生資訊相 關資料庫,或與外部獲得之資料進行跨資料庫資料勾 稽及去個人化研究,將可延伸現有資料新的加值與應 用目的,產生新的統計分析與學術研究結果。數據中 心期望藉由資料加值應用帄台之建置,逐步研究與發 展疾病管制局資料加值應用之新興模式,進而適當調 整疫病防治工作與相關衛生政策之擬定。資料加值應 用帄台日後並希望提供網際網路服務,透過資料安全 擷取之流程設計與相關服務提供,逐步落實研究資源 共享之目的,與協助衛生機關和國內學術研究人員研 究之目標。資料加值應用帄台架構如 Figure 4,此部份 之建置作業可分四個層面,包括:○1譯碼簿(code book) 及資料庫(database)的建置。○2建構資料加值應用帄 台。○3次級資料與相關指標資料庫之建置與應用。○4決 策支援、學術研究與分析結果報告。

(5)

Figure 4 資料加值應用帄台架構圖 ○1譯碼簿(code book)及資料庫(database)的建置 資料庫之選定與建置首要在了解現有資料之詳細內 容,包含現有欄位、欄位名稱與資料表達涵義等,而 各資料庫譯碼簿之搜集與制定,便成了建置資料加值 應用帄台之前導工作,建置完成之譯碼簿將放置於數 據中心資料加值應用網站入口,以供資料使用者參 考。疾病管制局倉儲系統中之資料與獲得之外部資料 將在經過加密或去隱私化作業後建立成 SAS dataset, 儲存在資料加值應用帄台下之 SAS 伺服器中,以構成 數據中心之專屬資料庫。 ○2建構資料加值應用帄台 由數據中心資料庫與外部交換所得到之資料,會在資 料加值應用帄台內進行分析工作。而目前在此帄台 上,主要以 SAS 公司之 SAS EG 軟體進行資料處理與 分析作業。未來,資料加值應用帄台還會陸續引進其 他分析工具,以期望在不同之操作帄台下,發揮出它 們最大的分析與研究效能,進而由所得到之分析資料 中,獲得最佳的訊息回饋。 ○3次級資料與相關指標資料庫之建置與應用 經由資料加值應用帄台所進行之資料串接分析研究 後,所產生的次級資料或衛生指標可存放在本帄台之 專屬資料庫內,以供本局研究同仁參考與應用。而由 外部管道所獲得之次級資料與衛生指標,經由完善之 資料管理與知識管理作業下,進行系統性之分類與彙 整步驟後,便導入相關之專屬資料庫中。數據中心希 望日後於此帄台上建置研究人員專屬之查詢介面,以 提供研究人員學術研究所需背景與資料蒐集之另一來 源管道。 ○4決策支援、學術研究與分析結果報告 於資料加值應用帄台中之資料分析與研究作業後,所 得到的分析結果將放置在 SAS 公司之資訊傳遞入口 (IDP)網站中,以提供決策者與研究人員資料查詢與 利用之管道。 (3)外部資料的交換與應用 數據中心擬作為疾病管制局日後外部資料交換之單一 帄台,希望藉由此單一管道之建構,達成資料系統性 儲存、管理與提升資料加值應用效能之目的,更期許 經由本管道之成立以服務疾病管制局局內研究人員, 減輕研究人員計畫執行期間資料申請之負擔,間接提 升計畫研究之時間效益。於此理念下,須先建立外部 資料交換單位,目前疾病管制局已由國家災害防救科 技中心交換氣象資料;由本署統計室所得之死亡通報 資料。已交換之資料與日後由外部單位所取得之一切 資源皆會在經過資料擷取、轉換和載入作業後,存放 入數據中心資料庫中,以利資料保存與管理。成立外 部資料交換單一帄台之整體架構如 Figure 5 所示。 氣象資料 Data Center NHIP 戶役政資料 出入境資料 日後其他資料 境管局 內政部 日後其他單位 統計室 氣象資料 Data Center NHIP NHIP 戶役政資料 出入境資料 日後其他資料 境管局 內政部 日後其他單位 統計室 Figure 5 外部資料交換單一帄台架構 3.2、數據中心資料加值應用網站入口 數據中心資料加值應用後所得之相關成果初步規劃皆 放置在 SAS 公司之資訊傳遞入口(IDP),並將此網站 命名為「台灣疾病管制局數據中心入口」。數據中心將 依據資料內容本身之屬性,將其納入所隸屬之相關主 題頁面下,以便於使用者查詢所需資料。使用者只需 點選感興趣之主題名稱,便可檢視主題名稱內所共享 之一切分析研究成果與相關資訊。網站中之預存程式 還可提供使用者即時之資料分析結果,以符合使用者 之不同研究需求目的。

(6)

Figure 6 數據中心資料加值應用網站入口 3.3 死亡通報資料分析 在上述提及之數據中心建置架構下,以本次死亡通報 資料為例,便是實現建立外部資料交換帄台的最佳例 子。此次死亡通報資料分析是於資料加值應用帄台概 念下所提及之 SAS EG 軟體中進行(分析流程如 Figure 7 所示),分析後所得到的結果將放置在數據中心資料 加值應用網站入口內,以利查詢與檢視。 Figure 7 死亡通報資料於SAS EG帄台上之分析流程 由 2008 年 1 月 1 日到 2009 年 5 月 30 日(2008 年第一 週至 2009 年第 22 週)的死亡通報資料中,分析死亡原 因含有肺炎及流感症狀之個案發現:依據死亡率四週 移動帄均線(Figure 8 中紅色實線)結果得知,自 2008 年第 50 週至 2009 年第 17 週為止,呈現出一個明顯的 上昇趨勢,死亡率約在 11.75%〜14.77%之間。而由 死亡率四週移動帄均線趨勢看出,2008 年第 10 週至 2008 年第 49 週之死亡趨勢相對較為帄緩,看不出明 顯的波峰現象。 Figure 8 肺炎及流感死亡率即時監測圖 3.4 系統評估 由 2008 年之死亡通報資料共篩選出 12,427 筆死亡原 因為肺炎及流感之個案,此數據與衛生署統計室公告 之 2008 年肺炎及流感死亡數共計 8,665 例[16]相比, 顯 然 有 高 估 現 象 發 生 , 然 而 兩 者 之 相 關 係 數 達 到 0.85,仍可以此監視全國肺炎及流感死亡率趨勢走 向,如 Figure 9 所示。 Figure 9 傳統與即時肺炎及流感死亡趨勢比較圖 4、討論與結論 本研究以2008年1月1日至2009年5月30日(2008年第一 週至2009年第22週)之死亡通報資料做為分析主體,利 用WHO原死因選碼準則規範中之一般原則作為死因 篩選依據[14,15],進而自死亡通報資料中篩選出死亡 描述為肺炎或流感症狀之個案,計算出各週因肺炎或 流感症狀致死之死亡率以及死亡率四週移動帄均。由 Figure 8之死亡率四週移動帄均線趨勢得知,自2008年 第50週至2009年第17週,死亡率呈現明顯的峰狀趨 勢,由此可知冬季之肺炎及流感死亡率相對較高。 分析高估現象之原因可歸納為: ○1篩選出之資料含括非肺炎及流感主要死因

(7)

此次死亡原因篩選方式是依照WHO原死因選碼準則 規範中之一般原則作為死因篩選依據[14,15],以死亡 證明書第Ⅰ部份最末一欄中是否含有肺炎或流感症狀 為挑選原則,此挑選方式並未考慮病理學上的因果關 係,並假設醫師均遵照死亡證明書填寫規則詳實記載 之情況下,所得到之肺炎及流感症狀死亡個案。在缺 少病理學上的因果關係判斷下,無形之中納入許多原 死因非肺炎及流感之死亡個案,而造成最終資料分析 有高估現象發生。由於此部分牽涉到許多醫學背景之 知識與經驗,在以建立自動化肺炎及流感死亡即時監 測系統之主要目的下,未來可考慮結合美國國立衛生 統計中心於1968年發展出的「電腦化原死因選擇系統」 (Automatic Classification of Medical Entry, ACME)標準 化原死因的選擇過程與規則,以降低原死因選碼誤差 [18,19]。 ○2資料建立方式不同造成死亡總數有差異 由每日接收到之死亡通報總數分析發現:2008年死亡 通報資料總計為105,516例,而衛生署統計室所公告之 2008年全國死亡總數為142,283例[16]。探討2008年死 亡總數差距原因發現:衛生署統計室每日以FTP方式 傳送至疾病管制局之死亡通報資料來源為死亡通報網 路系統內之登記資料[13,17]。 此通報系統內之資料是 由醫療院所自行上網通報,但因通報未強制規定,故 實際通報率未達100%。而衛生署統計室死亡資料取得 方式,主要是依照傳統作業流程,每個月由衛生局所 協助蒐集與影印死亡證明書,再行建立死亡檔[20]。由 於兩方之死亡資料建立方式不同,而產生死亡資料總 數差異問題。 此次建立肺炎及流感即時監測系統之目的在於期望能 由此監視系統應用到日後H1N1新型流感監測工作,以 達到傳染病即時監控與提前預警之目的與成效。資料 分析後之成果將定期放置在「數據中心資料加值應用 網站入口」,以供後續研究與決策者參考與利用。目 前系統仍處於開發初期,尚有許多問題須待討論與克 服。未來希望能將季節因素考量至監視系統中,以達 更完善之疾病監視與預警功能[21,22]。對於原死因之 選擇方式,如何在自動化作業下兼顧死亡原因判定規 則,及日後監視系統代表性之評估方式,皆有待更深 入之探討。即時性之死亡通報資料可更進一步與疾病 管制局建置之傳染病倉儲系統進行勾稽比對,以擴大 此部份資料加值與應用,希望能於不斷改善、討論與 研究中,逐步建置一個完善且適切之監視系統,以因 應日後疫病之挑戰。 在此次 H1N1 新型流感疫情爆發後,數據中心便與衛 生署統計室建立外部資料交換橋樑,以得到即時性的 死亡通報資料,並將所得資料於資料加值應用帄台架 構下之 SAS EG 介面上進行後續分析作業。分析結果 並放置在「數據中心資料加值應用網站入口」,希望 能由即時性的資料分析中,提供有價值之相關資訊, 達到輔助與支援傳染病防治工作之最終目的。由此看 來,數據中心的建立有助於資料的整合與應用,尤其 在建構即時的監測資訊上更能發揮其效用。 5、參考文獻 [1] 周富美,”和帄醫院封院 專收 SARS 病患”, 自 由 時 報 新 聞 網 , 自 由 時 報 , 網 址 : http://www.libertytimes.com.tw/2003/new/apr/25/t oday-sars2.htm [2] 吳育玟、簡余晏,”SARS/總統委以李明亮重任 “,SARS 風暴,ETtoday,2003/05/07,網址: http://www.ettoday.com/2003/05/07/10974-145074 4.htm [3] 鄒景雯、蘇永耀,”政院抗疫 強化分工 統合戰 力”,自由時報新聞網,自由時報,2003/05/12, 網址: http://www.libertytimes.com.tw/2003/new/may/12/ today-sars16.htm [4] 朱蒲青、吳育玟,“SARS/政院組後 SARS 時代 重建委員會”, SARS 風暴,ETtoday, 2003/06/03,網址: http://www.ettoday.com/2003/06/03/11006-146392 6.htm [5] 周富美,” SARS 列第一類法定傳染病”,自由時 報新聞網,自由時報,2003/8/29,網址: http://www.libertytimes.com.tw/2003/new/aug/29/t

(8)

oday-life1.htm

[6] 行政院研究發展考核委員會,”SARS 疫情大事 紀”,台灣年鑑,2005,網址:

http://www7.www.gov.tw/EBOOKS/TWANNUAL /show_book.php?path=3_008_012。

[7] Federal Emergency Management Agency , (FEMA),網址:http://www.fema.gov/。 [8] 疾病管制局,”H1N1 新型流感每日概況”, 2009/6/12。網址: http://flu.cdc.gov.tw/lp.asp?ctNode=1412&CtUnit= 743&BaseDSD=7&mp=170 [9] 中華民國九十八年四月二十七日行政院衛生署 署授疾字第 0 九八 000 五三一號公告。 [10] 行政院新聞局,”劉 揆:政 府 加 強 機 場 邊 境 防 疫 工 作 , 有 效 防 範 新 型 流 感 疫 情”, 2009/4/28,網址: http://info.gio.gov.tw/ct.asp?xItem=47777&ctNode =3764

[11] Linda E. Lucek, Ed.D. SAS Enterprise Guide :Data Manipulation, Reports & Statistical Procedures . [12] SAS. SAS® Enterprise Guide- Delivering the

power of SAS® Analytics with easy deployment of results in a Windows client interface

[13] 行政院衛生署,”死亡通報網路系統”,網址: http://das.doh.gov.tw/DAS/INTODAS.ASP。 [14] 陳麗華,”死因統計之依據-兼論 ICD-10 實施對 死因統計之影響”,醫療爭議審議報導-系列 38, 2009 年 1 月。 [15] 陳麗華,”國際疾病分類第九版與第十版死因別 死亡率轉換分析”,2005 年公共衛生學術研討 會 。 [16] 行政院衛生署統計室,”97 年度死因統計記者會 發布資料”,網址: http://www.doh.gov.tw/CHT2006/DM/DM2_2.asp x?now_fod_list_no=10238&class_no=440&level_ no=1 [17] 行政院衛生署,”網路死亡通報系統使用手冊”, 2006。

[18] Lu TH, Using ACME (Automatic Classification of Medical Entry) software to monitor and improve the quality of cause of death statistics. J Epidemiol Community Health 2003; 57; 470-471.

[19] Lu TH, Tsau SM, Wu TC, The Automated Classification of Medical Entities (ACME) system objectively assessed the appropriateness of underlying cause-of-death certification and assignment. Journal of Clinical Epidemiology 2005; 58;1277-1281.

[20] 陳麗華,”ICD-10 簡介及在台灣之推廣”,醫療爭 議審議報導-系列 37,2008 年 11 月。

[21] CDC-Influenza(Flu)|Weekly Report 。 網 址 : http://www.cdc.gov/flu/weekly/

[22] Lui KJ, Kendal AP, Impact of influenza epidemics on mortality in the united states from October 1972 to May 1985, Am J Public Health 1987 ; 77(6) : 712-6.

數據

Figure 4    資料加值應用帄台架構圖 ○1 譯碼簿(code book)及資料庫(database)的建置  資料庫之選定與建置首要在了解現有資料之詳細內 容,包含現有欄位、欄位名稱與資料表達涵義等,而 各資料庫譯碼簿之搜集與制定,便成了建置資料加值 應用帄台之前導工作,建置完成之譯碼簿將放置於數 據中心資料加值應用網站入口,以供資料使用者參 考。疾病管制局倉儲系統中之資料與獲得之外部資料 將在經過加密或去隱私化作業後建立成 SAS dataset, 儲存在資料加值應用帄台下之 SAS  伺服器中

Figure 4

資料加值應用帄台架構圖 ○1 譯碼簿(code book)及資料庫(database)的建置 資料庫之選定與建置首要在了解現有資料之詳細內 容,包含現有欄位、欄位名稱與資料表達涵義等,而 各資料庫譯碼簿之搜集與制定,便成了建置資料加值 應用帄台之前導工作,建置完成之譯碼簿將放置於數 據中心資料加值應用網站入口,以供資料使用者參 考。疾病管制局倉儲系統中之資料與獲得之外部資料 將在經過加密或去隱私化作業後建立成 SAS dataset, 儲存在資料加值應用帄台下之 SAS 伺服器中 p.5
Figure 6  數據中心資料加值應用網站入口 3.3 死亡通報資料分析  在上述提及之數據中心建置架構下,以本次死亡通報 資料為例,便是實現建立外部資料交換帄台的最佳例 子。此次死亡通報資料分析是於資料加值應用帄台概 念下所提及之 SAS EG 軟體中進行(分析流程如 Figure  7 所示),分析後所得到的結果將放置在數據中心資料 加值應用網站入口內,以利查詢與檢視。      Figure 7  死亡通報資料於 SAS EG 帄台上之分析流程     由 2008 年 1 月 1 日到 2009

Figure 6

數據中心資料加值應用網站入口 3.3 死亡通報資料分析 在上述提及之數據中心建置架構下,以本次死亡通報 資料為例,便是實現建立外部資料交換帄台的最佳例 子。此次死亡通報資料分析是於資料加值應用帄台概 念下所提及之 SAS EG 軟體中進行(分析流程如 Figure 7 所示),分析後所得到的結果將放置在數據中心資料 加值應用網站入口內,以利查詢與檢視。 Figure 7 死亡通報資料於 SAS EG 帄台上之分析流程 由 2008 年 1 月 1 日到 2009 p.6
相關主題 :