國立臺北護理健康大學資訊管理研究所碩士論文

(1)

I

國立臺北護理健康大學資訊管理研究所碩士論文 National Taipei University of Nursing and Health Sciences

Graduate Institute of Information Management

指導教授：黃衍文博士 Advisor: Ean-Wen Huang Ph.D.

以簡易臨床文件架構的標準為基礎建置電子病歷驗證服務平台之研究

A study of Developing an Electronic Medical Records Validation Service Platform Based on the Green Clinical Document Architecture Standard

研究生：王姿涵撰 Name: Zu-Han Wang

中華民國一○三年七月

July, 2014

(2)

I

(3)

II

誌謝

在研究所這求學的兩年中，終於如期順利完成碩士論文，感謝在這兩年出現在我生命中的重要貴人，有你們的支持與協助，讓我所面對的瓶頸與困難都能迎刃而解。

首先，由衷感謝我的指導老師黃衍文教授的細心指導與教誨，除了讓學生能夠在醫療領域上的專業更加精進，也從教授身上學到堅毅、上進並認真努力追求卓越的精神與態度，感謝王大維教授、劉德明教授、邱瑞科教授及張啟明教授在學生口試時給予寶貴的意見與肯定，讓學生的論文能更臻完善。

我要感謝研究所的學長建羽、明睿及丁安給了我很多論文的意見及研究所課程的引領，感謝研究所的同學相漢、家賢、治中、佩怡、欣妤及曉婷在求學過程中的課業幫忙、支持與鼓勵，感謝研究室的學妹皓怡在我口試最忙的時候協助處理很多事情，在各方面互相分享著彼此的經驗，感謝學弟弘河在無數次忙碌之際，伸出援手協助度過難關，有你們的出現，讓我這兩年的人生增添的許多美好回憶。

最後，感謝我的家人在我最忙碌與難過的時候，給我很大的支持與鼓勵，

讓我能在這求學的過程中堅持下去，謝謝親愛的家人。

王姿涵謹誌於

2014

年

7

月國立臺北護理健康大學資訊管理研究所

(4)

III

國立臺北護理健康大學資訊管理所碩士論文計畫書摘要

研究所組別：資訊管理研究所

論文名稱：以簡易臨床文件架構的標準為基礎建置電子病歷驗證服務平台之研究

指導教授：黃衍文教授研究生：王姿涵

時間：民國

103

年

7

月論文摘要

衛生福利部積極推動電子病歷交換，進行患者病歷的資料交換，以利醫療資訊的流通。

臨床文件架構 (Clinical Document Architecture, CDA) 由健康資訊交換第七層協定協會

(Health Level Seven, HL7)

提出，CDA是臨床文件交換為目的的標準架構，且於美國國家標

準協會(American National Standards Institute, ANSI)獲得認證，結構完整、複雜且龐大。本研究收集行政院衛生福利部所公告之電子病歷交換標準規範書中所制定各單張之欄位，建置出一套符合簡易臨床文件架構規範之簡易臨床文件，提供本土化、輕量級、簡潔易懂的資料交換格式。然而，如何能在以上兩種格式間順利轉換，且確保轉出的文件為標準且正確的文件，

驗證檢核即為重要把關機制。根據衛生福利部所公告之電子病歷交換標準規範書中各單張欄位之驗證規則，將所使用的相關代碼進行整合，並建置為簡易臨床文件架構之檢核邏輯資料庫。撰寫程式依據檢核邏輯及相關代碼資料庫自動產生

XML Schema

的驗證規則，我們也提供方法，讓使用者修改驗證規則。本驗證服務平台，讓使用者可直接上傳符合簡易臨床文件架構之文件進行驗證，藉由驗證機制，提供轉換及交換前的驗證門檻，經過文件欄位結構及內容的檢核後，該文件即為標準交換文件，希望藉此有助於提高臨床文件的完整性與正確性。

關鍵字: 電子病歷、臨床文件架構、簡易臨床文件架構、檢核邏輯

(5)

IV

Abstract

The Ministry of Health and Welfare of Taiwan actively promotes the exchange of data thru electronic medical records (EMR). This promotion is conducive to patient records data exchange, and also facilitates the flow of medical information. This study collected fields in the EMR exchange standards which were announced by the Ministry of Health and Welfare that compose a set for a simplified clinical document, which is in line with the Green Clinical Document Architecture (GCDA) standard. The document is an exchange format that provides features of 'localization' and being 'easy to read'. According to the fields of the EMR exchange standards, we arranged the validation rules of each individual field and integrated the relevant code to build a validation logic database for the GCDA. The validation contains the format and the effective value of the field. We wrote programs based on the validation logic database to automatically generate rules for an XML schema. We also provided a method for users to make modifications of validation rules. The validation service platform allows users to directly upload the GCDA documents for verification and hopefully improves the completeness and correctness of the document.

Keywords: Electronic Medical Records (EMR), Clinical Document Architecture (CDA), Green Clinical Document Architecture (GCDA), Validation

(6)

V

碩士學位考試委員會審定書 ... I 誌謝 ... II 論文摘要 ... III

Abstract ... IV

目錄 ... V 圖目錄 ... VI 縮寫對照表 ... VII

第一章緒論 ... 1

第一節研究背景 ... 1

第二節研究動機 ... 3

第三節研究目的 ... 4

第四節論文架構 ... 6

第二章文獻探討 ... 7

第一節電子病歷 ... 7

第二節臨床文件架構 ... 11

第三節簡易臨床文件架構 ... 14

第四節標記語言 ... 16

壹 XML ... 16

貳 XML Schema ... 18

第三章研究方法 ... 20

第一節研究步驟 ... 20

壹研究流程 ... 20

貳系統建置流程 ... 22

第二節系統需求分析與設計 ... 25

壹需求分析與系統架構 ... 25

貳系統分析與設計 ... 30

第三節相關技術及開發工具 ... 41

第四章研究結果與討論 ... 42

第五章結論與建議 ... 46

參考文獻 ... 48

附錄一門診病歷單張CDA範例 ... 53

附錄二門診病歷單張GCDA ... 65

附錄三門診病歷單張GCDA範例 ... 66

附錄四門診病歷單張GCDA驗證XSD ... 68

附錄五論文發表 ... 73

(7)

VI

圖目錄

圖1：研究流程架構圖 ... 21

圖2：門診病歷欄位列表、CDA和DCDA對照表 ... 26

圖3：檢核邏輯資料庫內之欄位資料表 ... 27

圖4：檢核邏輯資料庫內之藥品代碼表 ... 27

圖5：type撰寫之程式區段 ... 31

圖6：欄位階層表 ... 32

圖7：XSD檔案中type的定義 ... 32

圖8：匯入資料庫中欄位驗證資料程式片段 ... 34

圖9：XSD檔案中列出所有藥品代碼的可能選項 ... 35

圖10：系統活動圖 ... 37

圖11：驗證服務子系統流程圖 ... 38

圖12：資料庫規則增修子系統流程圖 ... 39

圖13：GCDA文件驗證系統畫面 ... 44

圖14：XSD於XMLSpy的使用 ... 45

(8)

VII

縮寫對照表

英文縮寫原文中文名稱

ANSI American National Standards Institute

美國國家標準協會

CDA Clinical Document Architecture

臨床文件架構

DTD Document Type Definition

文檔類型定義

EMR Electronic Medical Record

電子病歷

GCDA Green Clinical Document Architecture

簡易臨床文件架構

GML Generalized Markup Language

通用標記語言

HL7 Health Level Seven

健康資訊交換第七層

HTML Hyper Text Markup Language

超文字標記語言

RIM Reference Information Model

參考資訊模型

RMIM Refined Message Information Model

精確訊息資訊模型

SGML Standard Generalized Markup Language

標準通用標記語言

W3C World Wide Web Consortium

全球資訊網協會

XML eXtensible Markup Language

可擴展標記語言

XSD XML Schema Definition XML Schema

定義

(9)

1

第一章緒論

第一節研究背景

醫療資訊電子化已經成為全球的趨勢，對於醫療相關照護品質也已有相對的提升，同時也使醫療相關的資訊管理更為方便。近年來，隨著科技的高度發展，與以前紙本病歷相比較，醫療資訊處理與管理電子化後，更多了精準、正確、清楚且便於取得的各種特性。同時，電子化的醫療相關資訊，也能運用網路傳輸於各醫療院所及衛生機關之間，可立即取得患者位於各處的就醫與用藥等各種資訊，使治療不至於中斷，也可達到醫療成本降低的目的。因醫療資訊的電子化具備多項優點，許多先進國家如日本、英國、美國等，都逐漸以技術、

制度及相關法令規範等方面努力推動及運用[1]。

依據行政院衛生署（2005）於民國九十四年度醫療院所病歷電子化現況調查指出，大部分醫院的病歷電子化相關程度已經有相當大進展，將近 84.2%的醫學中心與 60%的區域醫院[2]，已經將電子病歷與其醫院的資訊系統進行整合，並由此可知國內醫院對於未來電子病歷相關發展已有相當的成就。

衛生福利部積極推動電子病歷交換[3]，使用台灣健康資訊交換第七層協定

(10)

2

協會

(Health Level Seven, HL7)

所制定臨床文件架構

(Clinical Document

Architecture, CDA)為標準，使醫療院所及衛生機關之間能藉由此規範，進行資

料交換，以利病歷資訊交流的目的，如此能提升醫療品質與醫療安全，也可望能降低醫療成本。但因臨床文件架構階層較多，文件相對較為繁複，使用門檻因而較高，因此英國於

2006

年實驗簡化

CDA

文件而產生簡易臨床文件架構

(Green Clinical Document Architecture, GCDA)的概念[4]，GCDA

文件除了降低

CDA

文件的複雜度，同時可提供本土化標籤的撰寫，提供更高之閱讀性，可望能提高使用者接受度，及使用範疇之廣度。

(11)

3

第二節研究動機

簡易臨床文件的基本條件中提出臨床文件及簡易臨床文件之間必須能完整轉換[5]，如此才可將該文件稱為簡易臨床文件，然而，在轉換前，驗證即為一重要把關，驗證檢核內容包含欄位的結構及欄位內容，經過檢核邏輯後的文件方可為標準單張，確認為無誤標準單張之後，進行文件轉換，提高交換文件正確性。

驗證機制為電子病歷交換時之重要把關，為確保交換之電子病歷單張為正確且可用之單張，進而訂定驗證檢核規則，然而

CDA

文件完整，因而規模龐大，

在驗證規則的規劃也屬結構化，先定義完整

CDA

文件之文件架構後，再於不同驗證檔案內定義此架構內的屬性質等等，之後再依據不同單張內欄位內容值，

定義各單張之欄位內容驗證檔。如此結構化的階層驗證，階層由外而內定義

CDA

文件驗證之驗證規範，但如在單張增加欄位等等，則需另行再定義一張欄位內容驗證檔案，因此缺乏驗證彈性，然而若能於

GCDA

文件中靈活提升驗證規範的增修，增強檢核機制的廣度，則可望提升

GCDA

文件的使用意願，同時確保

GCDA

文件的正確性。

(12)

4

第三節研究目的

本研究深入了解臨床文件架構，並以簡易臨床文件架構為基礎，將衛生福利部所公告五類交換單張，提出本土化、簡潔易懂的簡易臨床文件架構，並以系統實際開發的方式，實作簡易臨床文件架構的驗證分析，希望將來可以推廣使用。

簡易臨床文件的基本條件中，提到臨床文件及簡易臨床文件之間必須能完整轉換，才可稱該文件文簡易臨床文件[5]，然而驗證系統能夠提供文件轉換前的檢核閘門，在文件轉換前進行文件正確性的檢核，以利爾後文件的轉換和交換。

其研究目的在於建立一套以簡易臨床文件架構為基礎的驗證服務平台，透過經研究整理後的檢核邏輯資料庫及驗證服務平台，可以協助使用者檢核文件正確性和完整性，同時也能提供使用者編輯與增修驗證規則

XML Schema

，提高文件可驗證性及驗證彈性。

(13)

5

本研究之具體目的如下列所述：

1.

收集行政院衛生福利部所公告之電子病歷交換標準規範書中所制定各單張之欄位，制定出一套符合簡易臨床文件架構規範之簡易臨床文件格式。

2.

根據衛生福利部所公告之電子病歷交換標準規範書中各單張欄位之驗證規則，將所使用的相關代碼進行整合，並建置為簡易臨床文件架構之檢核邏輯資料庫。

3.

撰寫程式依據檢核邏輯及相關代碼資料庫自動產生

XML Schema

的驗證規則，如使用者發現驗證規則不能滿足需求時，可進行規則增修，提供高度彈性的驗證規則。

4.

建置文件檢核服務平台，讓使用者可直接上傳符合簡易臨床文件架構之標準文件進行驗證，將有助於提高文件完整及正確性。

(14)

6

第四節論文架構

本研究論文的內容描述如下：首先在第一章節中，敘述了這篇論文的相關背景、動機與目的。在第二章節中，有四個部份的文獻探討，分別為電子病歷的、臨床文件架構的規範、簡易臨床文件的探討與研究，最後是標記語言，然而在標記語言中，又包含

eXtensible Markup Language (XML)

與

XML Schema。

然而在第三章節中，則描述了研究步驟、系統架構、系統需求分析與設計及相關技術與開發工具。在第四章節中，描述了整個研究的結果與評估的部分，包括各子系統的驗證畫面及擴充使用方法，並針對該研究進行討論與研究限制的說明。在第五章節中，描述了本研究結論與未來的努力方向提出部分建議。

(15)

7

第二章文獻探討

本章節將依據研究目的，依序探討電子病歷、臨床文件架構

(Clinical Document Architecture，CDA)、簡易臨床文件架構(Green Clinical Document Architecture，GCDA)及標記語言。

由於本研究以簡易臨床文件架構建構驗證平台，因此會探討

XML Schema

定義(XML Schema Definition，XSD)等相關研究。

第一節電子病歷

電子病歷為當前醫療資訊上的趨勢，相較於紙本病歷，電子病歷使醫師能更有利的提升醫療服務品質[6]。科技資訊技術被視為能改善病人安全和醫療品質的重要工具[7]。更有研究提出，目前所使用的所有資訊科技，又屬於電子病歷擁有最廣泛的能力與最有潛力能提高醫療服務品質[6]，研究也證明了電子病歷的效益，以及電子病歷額外的一些效益，包含看診、處方和照護管理提醒等等[8, 9]。電子病歷擁有品質提升這樣的潛力，較少醫師使用電子病歷，

(16)

8

但有大量的醫師對電子病歷抱持高度興趣[10, 11]。在一項國外調查

1200

個樣本當中，大多為個人或是小型醫師團體，少於

13%的受訪者說明他們的行為模

式中有使用電子病歷，而

32%的受訪者則表示他們對電子病歷有興趣，且有一

半以上表示是非常有興趣的[12]。由此可知，電子病歷在醫療照護上越來越具重要性。

在許多國家，醫療照護產業正面臨著前所未有變化的時期[13]。與過去相比，醫療照護體系中，供給與需求之間有著前所未見的強烈人口趨勢，以加拿大為例：2041年，加拿大

65

歲以上的人口，將佔加拿大總人口數的

22%，與

2001

年相比成長

13%[14]

，使得醫療照護需求愈加強烈，然而不斷增加醫療需求的原因，不僅僅只是人口老化，因此醫療照護需求不會只是暫時的[15]。

日益擴大的醫療照護供需缺口，採取醫療資訊系統被大部分國家認為是減輕缺口問題的方法[16, 17]。因而電子病歷的採用率也呈現上升的趨勢[18]。大部分醫療院所認為，健康照護電子化，包含醫療資訊系統及電子病歷的應用可

(17)

9

提高患者的安全性、提供醫師的治療及決策效率[16, 19]、降低人力成本，實現效率最大化[19]，並且已經被證明，可協助醫師及相關醫護專業人員減少醫療行為的失誤[20, 21]。根據分析，實施的重要性和這些電子化的重要性是一樣的[15]。

基於電子病歷和臨床決策支援系統，電子病歷可以檢查藥物的相互作用，

以減少處方錯誤，並監測藥物副作用，安全的醫療服務，同時也可以對病人的治療信息之誤用和濫用，落實管理、技術和物理措施，加強個人資訊保護。

在一項研究中指出，挪威的

72

間醫療院所當中，已有

53

間於

2001

年通過電子病歷系統的認證，同時系統也覆蓋醫院中

77%的病床[22]。

法國的

Grenoble

醫院則是經由網路，管理個人健康紀錄，使患者和醫院

之間能共享醫療相關資訊，予以改善糖尿病病患的照護醫療品質，同時病患也得以隨時掌握自己的健康狀況[23]。

韓國也同樣在積極推動電子病歷交換的機制，提供個人化治療訊息，他們

(18)

10

認為電子病歷可以增加病人的知情權，不分時間和地點，提高個人疾病管理能力，並減輕醫務人員和病人之間的資訊不對稱[24]。

患者不會只限制於一家醫療院所看診，很可能在各地的醫院診所都具備有就診相關紀錄，假如發現健康相關疑慮時，因沒有完整就診及用藥等資訊，病患也沒辦法準確描述自身健康情形時，輕則可能導致醫療成本的浪費，重則可能導致無法挽回的決策疏失。因此如能經由電子病歷，使醫院得以取得患者過往於各醫療院所就診之相關紀錄，就能避免醫療浪費及可能錯誤的決策，能有效降低醫療風險和成本。

(19)

11

第二節臨床文件架構

臨床文件架構 (Clinical Document Architecture, CDA) 由健康資訊交換第七層協定協會 (Health Level Seven, HL7) 提出，CDA 是臨床文件交換為目的的標準架構，且於美國國家標準協會

(American National Standards Institute,

ANSI)獲得認證。 CDA

文件持續發展的目標，是希望能夠提供患者更高品質的

醫療照護，並能依據符合成本考量之下，推廣至醫療院所及衛生單位，使各層級的使用者都能妥善且廣泛運用於病歷資訊的交換，同時保持治療的連續性，

降低醫療錯誤[25]。因此在

2005

年發表

CDA R2

正式版本，由

Header

和

Body

所組成，其中定義完整的訊息內容，包含圖片、文字和影像等等多媒體相關內容，並使用可擴展標記語言(XML)對文件進行描述[26]。

CDA

文件使醫療院所及各衛生機關透過各層面不同的醫療訊息，可有效的提供更即時的醫療資訊和決策支援，保持一致性的患者臨床健康資訊，提高醫療品質、安全及醫療服務效率。然而，在採納上仍有一些障礙，例如：溝通、

(20)

12

通信、標準化和互通性等等，這些也都會相對影響到醫療院所之間臨床資料交換的實施[27]。雖然已經有制定出標準，例如：HL7 CDA 這樣的文件交換標準，但仍然需要本地化的標準，予以適應特定國家或是地區的需要[28-30]。

CDA

是

XML

格式的文件，因此文件格式及內容必須遵循

Schema

檔案的規範，透過

CDA RMIM

所產生的

XML Schema

為

POCD_MT000040.xsd，其

中包含

Header

和

Body

需遵守的格式，同時

CDA

文件還需遵循

HL7 RIM

模

型，因此

POCD_MT000040.xsd

引用

4

個依據

RIM

所制定的

XML Schema

，分別為

datatypes-base.xsd、datatypes.xsd、NarrativeBlock.xsd

和

voc.xsd。其中

datatypes-base.xsd

定義基礎資料型態，如定義”bl”為布林(Boolean)值的命

名，而其資料型態的值為”True”或”False”；另外，datatypes.xsd則訂定複合式的資料型態，亦可稱為組合資料型態[31]；而

NarrativeBlock.xsd

則用於文字敘述型的元素，雖然為敘述型資料，但可藉由此綱要將資料格式化；最後，

voc.xsd

則是主要規範各元素內可使用的詞彙代碼，也就是所有元素內可能出

(21)

13

現的屬性值。這些綱要可於

CDA

中包含了標頭、目的、問題、

(23)

15

過程、遺傳史、醫療費用付款單位、預立醫囑、疫苗、生命跡象、照護計畫與過程[33]，有東歐的研究指出他們醫院部門與醫師在醫療資訊系統中採用

CCD

標準，醫師會將所需的資料種類需求告訴醫院部門，醫院部門則將資訊以

CCD

的格式提供給醫師[34]。另外在相關的研究上指出，採用

GCDA

可降低文件的複雜度，並且減少開發與維護上所需要的時間與成本[35]，而系統設計方面，

同樣可以

GCDA

文件的方式來簡化呈現臨床資訊，以便於作業人員進行編輯與審核，提升臨床文件製作與配置的效率[36]。

(24)

16

第四節標記語言

壹 XML

可擴展標記語言

(Extensible Markup Language, XML)

描述了一類稱為

XML

文件的資料物件，並部分描述了執行電腦程序行為的這些程序。XML是一種根據

SGML (Standard Generalized Markup Language, SGML)

所定義的應用規範文件或限制形式，SGML 是標準通用標記語言[ISO8879]，是經由

IBM

自從

1960

年就開始發展

GML (Generalized Markup Language, GML)

標準化後的名詞[37]。

GML

需在檔案中，清楚的將標示和內容分開編寫，而且所編寫的全部檔案、標示及使用方法需符合一致性原則。然而，也因為

SGML

的檔案描述法較為嚴謹，造成檔案較大且複雜度高，以至於不易於理解及學習，導致影響相關推廣及應用。W3C同時也發現，關於

HTML

的一些問題，其中在易讀性及靈活度的彈性較差，且無法支援所有資料型態，檔案必須完整才能執行。為

(25)

17

了解決上述問題，專家精簡化了

SGML

，並且再依據

HTML

相關發展的經驗，

產生出

XML，這是在使用上具備相當嚴格的規範，但卻能夠簡潔並輕易描述

的資料語言。

根據定義，XML文件符合

SGML

文件格式和結構綱要的語言中，較被廣泛使用的主要為文檔類型定義(Document Type Definition, DTD)、Schematron 及

W3C XSD (XML Schema Definition)[38]。

DTD

及

XSD

均是為了限制

XML

文件的結構。其中限制包含元素及其屬性的定義，也限制了元素的順序，同時也可限制元素的重複性，並也定義了元素和屬性的資料值型態和值域。

XML DTD

是

SGML DTD

的一個子集，是過去和現在

XML

綱要模式語言

的標準，相較於其他綱要語言，

DTD

的能力有所限制，只支援

10

種資料型態，

DTD

的主體區塊是由元素和屬性所組成，是使用分層元件架構的典型代表。

Schematron

是一種簡單卻強大的結構化模式語言。由

Rick Jelliffe

所創建

的，它著重於使用模式，而不是定義架構驗證模式。它的架構定義非常簡潔，

簡單到足夠定義一個簡單的頁面，通過

XPath

提供了非常強大的約束規範[39]。

(27)

19

XML Schema

是

W3C

不斷努力想輔助甚至取代

DTD

的綱要語言，XML

Schema

的目標是比

DTD

更富有彈性和更廣泛的應用，它具有許多新的機制，

如繼承屬性和元素，使用者可定義資料類型[40]，例如<住家電話>元素，欄位內容必須符合((0)([1-9])([0-9]{4})[-]([0-9]{4}))格式，此型態定義為此欄位內容值格式須符合範例：(02)2325-1234，因此一個

XML Schema

可以提供一個元素和屬性的列表，定義元素及其值的內容格式，並約束元素該出現之順序與位置。

(28)

20

第三章研究方法

本章節依序說明研究步驟、系統需求分析與設計、相關技術應用及開發環境與工具。

第一節研究步驟

本研究首先對於簡易臨床文件架構進行了解，並探討臨床文件架構與簡易臨床文件架構的差異後，根據簡易臨床文件架構的定義及規範，編寫簡易臨床文件，並設計一個以簡易臨床文件架構為基礎架構的文件檢核邏輯，檢核邏輯資料庫為整個驗證平台之核心。本研究參考衛生福利部電子病歷交換中心所公告的電子病歷交換標準書，並實作此平台。研究流程從研究背景、動機及目的、

文獻探討、研究方法、研究結果、研究結論、結論與建議如圖

1

所示。

壹研究流程

(29)

21

圖

1：研究流程架構圖

(30)

22

貳系統建置流程

(1)

研究電子病歷交換標準書欄位及格式標準規範

本研究依據行政院衛生福利部電子病歷推動專區所公告之電子病歷單張交換標準書作為參考範本，並分析文件架構中所制定的欄位與格式規範。HL7

CDA R2

為電子病歷之基礎，使用

XML

描述文件。

(2)

研究台灣健康資訊交換第七層協定協會對於簡易臨床文件架構之定義本研究以簡易臨床文件架構為基礎，研究台灣健康資訊交換第七層協定協會對簡易臨床文件架構的定義，並根據其定義及規範，分析其應有的欄位階層與格式。

(3)

建置檢核邏輯資料庫

收集簡易臨床文件架構之檢核邏輯中可能使用到的代碼，並分析代碼與欄位之間的對應關係，同時根據欄位的格式規則，將代碼分門別類，並將詞彙代碼進行一致化的定義，避免形成驗證時比對上的混淆與錯誤，將代碼及欄位格式整合建置為檢核邏輯資料庫。

(31)

23

(4)

系統需求及系統設計

本系統主要分為兩項功能，首先對文件進行解析；其次根據解析後單張內容和資料庫內的驗證邏輯進行文件檢核；最後將檢核結果回傳系統告知使用者，另外如使用者認為該驗證

Xml Schema

無法滿足驗證文件需求時，提供驗

證

Xml Schema

的驗證規則增修功能，增修之規則將進而修改至檢核邏輯資料

庫中進行更新，因此須根據前述之電子病歷單張標準格式參考範例，分析研究每張標準書所需要的欄位驗證規範，建置為資料庫，進而完成本研究系統之核心。

(5)

子系統開發

本系統包含兩個子系統，驗證服務子系統及資料庫規則增修子系統，其中主要功能為文件解析、文件檢核、檢核邏輯資料庫管理等，將逐步完成各部份子系統功能之研究設計。

(6)

系統及資料庫串接整合與測試

完成各項功能建置後，與資料庫進行串接整合與測試，觀察欄位驗證規則與邏輯與標準書的欄位要求及對應情況是否符合文件中所制定的格式規範。

(32)

24

(7)

研究成果撰寫

本研究將撰寫系統平台建置的操作說明與結果，及討論實作過程中所遇到的挑戰及其研究之限制，提供研究者後續參考。

(33)

25

第二節系統需求分析與設計

本章節先進行系統需求分析及系統架構，再依其規劃系統之功能，以建置出符合研究之系統。

壹需求分析與系統架構

本研究在建置一套簡易臨床文件的驗證平台，系統將電子病歷交換標準規範所需的欄位格式與欄位內容所需要的詞彙代碼進行整理與對應關係建立，讓使用者可以了解各欄位的欄位格式和欄位內容代碼，主要是為了促進醫療資訊的正確性及一致性。本系統會把使用者上傳的文件剖析後顯示於畫面上，同時依據檢核邏輯和相關代碼自檢核邏輯資料庫自動產生

XML

綱要(Schema)的

驗證規則

XSD(XML Schema Definition)

，此資料庫內容包含各單張欄位列表、

欄位格式整理並整合林建羽等人建置的電子病歷醫學詞彙代碼資料庫[41]，讓使用者了解文件內容中欄位規則與欄位內容代碼的對應關係。

(34)

26

(a)

區塊

描述欄位名稱醫事

機構

醫事機構代碼醫事機構名稱病人

基本資料

身分證號病歷號碼姓名

……

門診

日期門診日期科別科別

診斷

國際疾病分類代碼 ICD Code

國際疾病分類名稱 ICD Name

註記病情

摘要

主觀描述客觀描述評估

處置項目

項次處置代碼處置名稱頻率數量

……

處方內容

……

藥品代碼藥品商品名稱學名

劑型劑量劑量單位頻率給藥途徑給藥日數

……

醫師

姓名醫師姓名

<?xml version="1.0" standalone="no"?>

...

<code code="19146-0" codeSystem="2.16.840.1.113883.6.1"

codeSystemName="LOINC" displayName="Reference lab test results" />

...

codeSystemName="LOINC" displayName=" Rh" />

<text>

</text>

...

<code code="19009C " codeSystem="2.16.886.101.20003.20014"

codeSystemName="全民健保檢驗項目代碼" displayName="腹部超音波，追蹤性"/>

<targetSiteCode code="C " codeSystem="2.16.886.101.20003.20014"

codeSystemName="中央健康保險署檢查部位" displayName="上腹部"/>

codeSystemName="LOINC" displayName="Visit frequency"/>

<text>一次性處置</text>

</criterion>

</precondition>

</procedure >

</entry>

<entry>

<procedure classCode="PROC" moodCode="RQO"

negationInd="false">

...

<routeCode code="PO" codeSystem="2.16.886.101.20003.20014"

codeSystemName="全民健保藥品使用途徑代碼" displayName="口服"/>

<!--17. 劑量, 18. 劑量單位 (每次一錠)

若為"適量"，則使用<doseQuantity value="1" unit="適量"/>

-->

<administrationUnitCode code="TAB" codeSystem="2.16.840.1.113883.5.85"

codeSystemName="orderableDrugForm" displayName="Tablet" />

<name>TINTEN TAB 500MG</name>

</manufacturedLabeledDrug>

</manufacturedProduct>

</consumable>

<?xml version="1.0" standalone="no"?>

<門診病歷>

<醫事機構代碼>0401190010</醫事機構代碼>

<醫事機構名稱>臺大醫院</醫事機構名稱>

<病人基本資料>

<身分證號>Z123456789</身分證號>

<病歷號碼>123456</病歷號碼>

<姓名>趙錢孫</姓名>

...

</病人基本資料>

<門診日期>20100810</門診日期>

<科別>家醫科</科別>

<診斷>

<國際疾病分類代碼>011</國際疾病分類代碼>

<國際疾病分類名稱>Tuberculosis 肺結核</國際

疾病分類名稱>

<註記>註記1</註記>

</診斷>

<診斷>

<國際疾病分類代碼>487</國際疾病分類代碼>

<國際疾病分類名稱>Influenza 流行性感冒</國

際疾病分類名稱>

<註記>註記2</註記>

</診斷>

<病情摘要>

<主觀描述>stable now and no complaint，report normal home BP；</主觀描述>

<客觀描述>BP：148/70 mmHg， HR：66/min</

客觀描述>

<評估>HCVD</評估>

</病情摘要>

<處方內容>

<項次>1</項次>

<處方箋種類註記>General(一般處方)</處方箋種類註記>

<藥品代碼>A040130100</藥品代碼>

<藥品商品名稱>TINTEN TAB 500MG</藥品商品名稱>

<學名>ACETAMINOPHEN TAB 500MG (FOIL)</學名>

<劑型>Tablet</劑型>

<劑量>1</劑量>

<劑量單位>{TABLET}</劑量單位>

<頻率>TIDPC</頻率>

<給藥途徑>口服</給藥途徑>

<給藥日數>4</給藥日數>

<給藥總量>12</給藥總量>

<給藥總量單位>{TABLET}</給藥總量單位>

<實際給藥總量>12</實際給藥總量>

<實際給藥總量單位>{TABLET}</實際給藥總量單位>

<磨粉註記>N</磨粉註記>

<註記>力停疼錠500公絲</註記>

</處方內容>

<醫師姓名>賴一施</醫師姓名>

</門診病歷>

(c)

(b)

圖

2：門診病歷欄位列表、CDA

和

GCDA

對照表

(A)為門診病歷欄位列表；(B)為部分 CDA

文件，包括：處置部位、頻率、藥品和給藥途徑；

(C)為 GCDA

對應的部分文件。

為對於欄位內容代碼的整合，欄位內容的代碼，必須和資料庫中的代碼相符合，當驗證出欄位格式錯誤、代碼不完整或錯誤時，系統會根據檢核邏輯資料庫中對於該欄位的內容格式提示。代碼對應舉例如下：醫院代碼須符合衛生福利部中央健康保險署所制定之健保特約醫療院所代碼、醫院名稱須符合衛生福利部中央健康保險署所制定之健保特約醫療院所名冊、國家須符合

HL7

(37)

29

Vocabulary Domain Value

之國家代碼、受刑人矯正機關須符合衛生福利部中央

健康保險署所公告訂定之矯正機關代碼、疫苗接種別須符合衛生福利部中央健康保險署所制定之疫苗代碼、症狀須符合衛生福利部疾病管制署所制定之症狀代碼等等。

(38)

30

貳系統分析與設計

系統的主要功能是將簡易臨床文件架構為基礎的文件，進行文件的驗證，

所示。當該欄位階層為下一個欄位階層值”-1”

時，則表示該欄位包含子階層欄位，則於

XSD

檔案定義該欄位

type

之命名，

此段程式碼如圖

5

所示，並同時匯出其子階層中的所有欄位，XSD 檔案內容

(39)

31

XmlSchemaComplexType tablenameComplexType = new XmlSchemaComplexType();

schema.Items.Add(tablenameComplexType);

tablenameComplexType.Name = tablename + "type";

ArrayList checktypehade = new ArrayList();

for (int j = 0; j < (int)arrayFieldName.Count; j++) {

if (j + 1 < (int)arrayFieldName.Count) {

if ((int)arrayHierarchy[j] + 1 == (int)arrayHierarchy[j + 1]) {

typecount = 1;

} else {

typecount = 0;

} }

if ((typecount == 1) && ((int)arrayHierarchy[j] == 1) && checkswtype == 0) {

//寫一個 type

// <xs:element ref="thing1"/>

XmlSchemaElement elementTablenames = new XmlSchemaElement();

sequencetablename.Items.Add(elementTablenames);

elementTablenames.Name = arrayFieldName[j] + "";

elementTablenames.SchemaTypeName

= new XmlQualifiedName(arrayFieldName[j] + "type");

checktypehade.Add(arrayFieldName[j]);

} }

如圖

7

所示。

圖

5：type

撰寫之程式區段

(40)

32

<xs:complexType name="門診病歷 type">

<xs:sequence>

<xs:element name="病人基本資料" type="病人基本資料 type" />

<xs:element name="診斷" type="診斷 type" />

<xs:element name="病情摘要" type="病情摘要 type" />

<xs:element name="處置項目" type="處置項目 type" />

<xs:element name="處方內容" type="處方內容 type" />

</xs:sequence>

</xs:complexType>

‧‧‧

<xs:complexType name="處方內容 type">

<xs:sequence>

‧‧‧

<xs:element name="藥品代碼" type="藥品代碼 tbl" />

<xs:element name="藥品商品名稱" type="藥品商品名稱 tbl" />

‧‧‧

<xs:element name="給藥途徑" type="給藥途徑 tbl" />

<xs:element name="註記" type="xs:string" />

</xs:sequence>

</xs:complexType>

圖

6：欄位階層表

圖

7：XSD

檔案中

type

的定義

(41)

33

主" + arrayFieldName[i].ToString() + "tbl") || String.Equals(matchdata,

arrayFieldName[i].ToString() + "狀況" + "tbl")) && checkswtype2 == 0) {

Debug.WriteLine("check in:" + matchdata);

XmlSchemaSimpleType SizeType = new XmlSchemaSimpleType();

SizeType.Name = matchdata;

XmlSchemaSimpleTypeRestriction restriction = new XmlSchemaSimpleTypeRestriction();

restriction.BaseTypeName = new XmlQualifiedName("string", "http://www.w3.org/2001/XMLSchema");

SizeType.Content = restriction;

schema.Items.Add(SizeType);

Debug.WriteLine("matchdata + " " + arrayFieldName[i].ToString() + " " + tbl_select(matchdata, arrayFieldName[i].ToString()).Count);

ArrayList tbldataa = new ArrayList();

tbldataa = tbl_select(matchdata, arrayFieldName[i].ToString());

for (int x = 0; x < (int)tbldataa.Count; x++) {

checkswtype2 = 0;

checktypebodytable.Add(arrayFieldName[i]);

XmlSchemaEnumerationFacet enumerationSmall = new XmlSchemaEnumerationFacet();

enumerationSmall.Value = tbldataa[x].ToString();

restriction.Facets.Add(enumerationSmall);

} }

if ((int)checktypebodytable.Count == 0) {

Debug.WriteLine("ii bodytable check");

checktypebodytable.Add(arrayFieldName[i]);

checkswtype = 0;

}

‧‧‧

圖

8：匯入資料庫中欄位驗證資料程式片段

(43)

35

<xs:simpleType name="給藥途徑 tbl " >

<xs:restriction base="xs:string">

<xs:enumeration value="右耳" />

<xs:enumeration value="左耳" />

<xs:enumeration value="每耳" />

<xs:enumeration value="氣切內" />

<xs:enumeration value="外用" />

<xs:enumeration value="漱口用" />

<xs:enumeration value="動脈注射" />

<xs:enumeration value="皮內注射" />

<xs:enumeration value="腦室注射" />

………

</xs:restriction>

</xs:simpleType>

圖

9：XSD

檔案中列出所有藥品代碼的可能選項

(2)

驗證平台

本研究之驗證服務平台分為兩個子系統，驗證子系統及資料庫規則增修子系統。圖

10

為系統流程圖。首先，使用者上傳驗證單張至驗證子系統，系統會將驗證單張的內容進行讀取，再根據內容於檢核邏輯資料庫產出驗證單張相對應的驗證檔，並與單張進行格式與代碼的驗證，驗證結果將顯示於瀏覽器提示使用者，如使用者發現驗證規則需修正，或認為驗證規範需修改，以合乎驗證文件需求時，於資料庫規則修改子系統中，提供目前

XML Schema

的解析，

並提供使用者對於

XML Schema

增刪改的功能，同時這些功能均以檢核邏輯資料庫為核心，提供

XML Schema

增修功能將有助於提高檢核邏輯資料庫的可用性與當前驗證規則的新增靈活性，因此系統將提供更臻完善、活用且具互

(44)

36

動性的驗證平台。

本驗證功能提供醫療院所將文件透過此驗證平台進行資料檢驗處理，期望

GCDA

文件未來能更廣泛被利用，同時藉由這樣的驗證機制，提升其資料交換的正確性和資料可用性，能在交換前發現資料欄位的值、型態或格式的錯誤，

避免錯誤資料交換一連串的發生，由此證明，資料交換前的資料驗證機制，確實有其存在的必要。

(45)

37

圖

10：系統活動圖

驗證服務平台分為兩個子系統，驗證子系統及資料庫規則增修子系統。

(46)

38

(3)

驗證服務子系統

驗證服務子系統主要提供使用者電子病歷的解析及單張之驗證，子系統架構如圖

11

所示，由於單張會因各交換單張不同而有不同欄位及其格式，因此會由文件剖析，了解單張格式內容後，再根據欄位與資料庫進行對應關係建立後，

產生對應於單張文件的檢核

XML Schema，爾後將產出的 XML Schema

與文件欄位內容進行驗證。透過驗證服務子系統動態產出驗證文件的檢核

XML Schema，可提高並擴展檢核靈活度及範圍。

上傳使用者

Green CDA 電子病歷文件

瀏覽器正確、錯誤訊息回覆

驗證服務子系統

驗證文件解析

XSD對應產出

文件驗證檢核邏輯

資料庫

對應

圖

11：驗證服務子系統流程圖

使用者於瀏覽器上傳欲驗證之

XML

文件，系統會擷取文件內欄位，和檢核邏輯資料庫中的欄位資料表進行對應，自動產出屬於該文件的驗證檔，再使用此驗證檔對該文件進行欄位內容值的驗證。

(47)

39

(4)

資料庫規則增修子系統

資料庫規則增修子系統主要提供驗證規則

XML Schema

的增修，子系統架構如圖

12

所示。當文件經過驗證服務子系統，系統解析欲驗證文件，並對應產出驗證規則

XML Schema

後，顯示於畫面上，當使用者發現

XML Schema

無法符合文件需求時，便可經由此子系統提供驗證規則的增修，此子系統的增修核心為檢核邏輯資料庫，增修後也可同步修改至資料庫，提供使用者彈性靈活的

驗證規則

XML Schema

編輯。

資料庫規則增修子系統 XSD 解析 XSD 增修驗證服務子系統

驗證綱要上傳傳送

訊息回復、文件下載

結果回傳檢核邏輯

資料庫

對應

圖

12：資料庫規則增修子系統流程圖

當使用者上傳文件中，有欄位並不存在於資料庫中時，亦或是當自動產出的驗證檔並不能滿足使用者期待時，可使用此子系統，增修驗證檔及資料庫。

(48)

40

本研究在建置一套簡易臨床文件的驗證平台，驗證規範系統根據使用者所匯入的單張產生相對應的

XML Schema，產出的 XML Schema

須根據檢核邏輯資料庫中欄位內容的代碼整理及各交換單張欄位格式的定義。

XML Schema

中會先根據單張定義數個

type，再以每個 type

定義其中的欄位項目。以門診病歷單張為例，如匯入驗證的為門診病歷單張的簡易臨床文件，系統將根據檢核邏輯資料庫，產出符合此驗證單張的

XML Schema，其中包含欄位格式的定義，如：

欄位順序、欄位內容格式等等。除了欄位格式，Schema 同時也包含單張中欄位對應的代碼，如：門診病歷單張中，欄位「給藥途徑」內容描述須符合檢核邏輯資料庫中對給藥途徑代碼資料表所列之給藥途徑等等，系統將根據匯入驗證的單張及資料庫內所定義單張的欄位格式與代碼，產出符合此單張需求的

Schema。此方法將提升資料驗證之擴充性，未來如發展更多交換標準單張時，

仍可根據這種對應動態產出的方式，解決驗證規則

Schema

定義的議題。

(49)

41

第三節相關技術及開發工具

本研究準備使用的開發環境、開發工具、開發程式語言及資料庫如下：



文件驗證系統，以資料庫為核心，建置欄位對應，

並動態根據欄位及欄位架構產出文件驗證檔，可使

GCDA

文件只需一張驗證檔，便可完成文件架構及內容的驗證，如：欄位順序、欄位格式及欄位內容等等，其中欄位內容的驗證，當匯入的單張欄位包含如：給藥途徑等等欄位時，

需對應至該欄位相對應的資料表，如：給藥途徑資料表中，因給藥途徑此欄位的內容須符合給藥途徑該資料表中對途徑的描述，因此系統會自動將給藥途徑資料表中的中文描述，全數提取並匯入至驗證檔中，驗證時，若欄位內容不包含於這些匯入的選項時，即驗證為無效內容。同時此驗證檔，也將進行儲存，

爾後相同單張匯入驗證時，將先行使用原有驗證檔進行檢核，若使用者欲增修時，資料會修正進資料庫，同時儲存為一個新版單張驗證檔。

而驗證系統的部分，首先，使用者開啟驗證系統，點選”選擇檔案”的按鈕，將欲驗證之

GCDA

文件經由檔案選擇器匯入系統，點選”上傳”，系統會將該

XML

文件完整解析並顯示於系統頁面上，確認為該欲驗證檔案後，點選”

驗證”按鈕，系統會根據該欲驗證文件自動動態產出

XSD

驗證檔，即為將文件

(51)

43

欄位對應檢核資料庫中之欄位規則及代碼，自動產生符合文件之驗證檔，利用本系統進行文件驗證，如比對出欄位內的值和

XSD

所要求的欄位格式不一致時，系統則會在錯誤該行下方直接做出欄位值格式錯誤的提示，如圖

13

所示。

然而驗證檔，也可供使用者自行驗證使用，將驗證檔匯入使用者習慣使用的軟

體如

XMLSpy

或

Dreamweaver

等，亦能提供驗證及撰寫提示，如圖

14

所示。

本驗證功能提供醫療院所將文件透過此驗證平台進行資料檢驗處理，與以往

CDA

文件的驗證程序相較下，CDA文件需要透過由

HL7

所制定的

XSD，以

及額外採用

Schematron

來進行驗證，如此的驗證模式是較複雜的，然而本研究根據

GCDA

文件的規範，將臨床文件驗證程序只需經由

XSD

來進行，並提供使用者在不同的需求時，可採取驗證規則的修改，以動態產生

XSD

檔案的模式，

達到驗證需求的彈性，同時藉由這樣的驗證機制，提升其資料交換的正確性和資料可用性，能在交換前就能發現資料欄位的值、型態或格式的錯誤，避免錯誤資料到處交換，擴散並一發不可收拾，造成之後一連串的錯誤發生，由此證明，資料交換前的驗證機制，確實有其存在的必要，期望在本研究的應用下，

GCDA

文件未來能更廣泛被利用。

(52)

44

圖

13：GCDA

文件驗證系統畫面

(a)使用者開啟驗證系統，點選選擇檔案的按鈕，將欲驗證之 GCDA

文件經由檔案選擇器匯入

系統，點選上傳，系統會將該

XML

文件完整解析並顯示於系統頁面上。(b) 如

GCDA

文件檢核出錯誤，也會直接在錯誤該行下方呈現。

(53)

45

圖

14：XSD

於

XMLSpy

的使用

(a)傳染病通報驗證檔，(b)

驗證檔可供使用者自行驗證使用，將驗證檔匯入使用者習慣使用

的軟體如

XMLSpy

或

Dreamweaver

等，亦能提供驗證及撰寫提示。

(54)

46

第五章結論與建議

本研究設計出一個簡易臨床文件架構為基礎的電子病歷文件驗證系統平台，以行政院衛生福利部公告的電子病歷單張交換標準，建立符合單張之欄位格式，同時整理單張中代碼與欄位之間的對應，並依據對欄位的格式需求，訂立各欄位的驗證規則，包含資料型態、格式和必填欄位空值等等的檢驗，並整理成檢核邏輯資料庫，此系統將收集到電子病歷標準書中的欄位代碼對應資料庫，建置一個驗證本土化簡易臨床文架構電子病歷的系統平台，以資料庫的形式為驗證的核心，提供自動化產出驗證檔的功能。

過往

CDA

文件驗證方法為，提供一個基本驗證

XSD，再根據各單張需求，

提供不同的驗證

Schematron，檢核時除了 XSD

之外，同時也須依據各單張所定

義的

Schematron

同時進行驗證，才能提供使用者認為完整的檢核邏輯，然而，

若使用者發現檢核邏輯無法滿足需求，則無法達到即時的驗證檔增修。因此本研究提供彈性驗證的空間，使用者可動態定義驗證文件的格式、順序、規範等，

只需要一張

XSD

即可達到驗證，驗證內容包含欄位順序、格式外，同時也包含欄位內容的正確性，例如：門診病歷單張中的給藥途徑欄位，別必須符合資料

(55)

47

庫中給藥途徑資料表中定義所有的途徑項目，這些驗證均可在一張

Schema

中完成，且經修正後的檢核內容，會同時增修至資料庫，提供一致性的檢核資料庫，

爾後使用者在產出新的驗證檔時，或在更新驗證檔內容時，也會包含過去使用者曾修過的內容，檢核資料庫也能藉由此機會不斷的進行優化。

不只在增修驗證檔時，能達到即時且快速可使用的效果，同時，在新增驗證單張時，也能快速根據新單張內的欄位架構，提供動態驗證檔的產出，並提供使用者定義欄位的格式內容，會須對應的代碼檔等等。提供一個模組化的驗證架構，同時不斷優化檢核邏輯資料庫。

加入此驗證機制，除了能提高簡易臨床文件的可用性，也可在通報之前先進行通報資料內容的正確性，在驗證資料正確後再進行通報，如此能大幅提升通報資料的可用性，同時協助使用者在編輯簡易臨床文件時使用，以達到電子病歷進行資料交換時的正確及完整性，期望在建立此系統平台後，作為電子病歷文件進行編輯時的參考，對未來在電子病歷交換有所助益。

(56)

48

參考文獻

[1]

簡文山、徐翊娜、溫信財、楊哲銘，以國際法規趨勢審視台灣電子病歷之法律環境，醫療資訊雜誌，17(1)：31-40，2008。

[2]

黃興進、呂卓勳、蕭如玲、陳瑞甫，影響電子病歷交換效益關鍵因素之研究：醫師觀點，電子商務學報，11(1)：95-118，2009。

[3]

衛生福利部, "衛生福利部電子病歷推動專區,"

http://emr.doh.gov.tw/news.aspx, 2013.

[4] CDA Forum,

http://www.networks.nhs.uk/nhs-networks/cda-implementation-forum/docume nts/CDA%20Forum%20-%20Introduction%20to%20Green%20CDA_v3.pdf/v iew, 2013.

[5] Alschuler, L., Dolin, B., Beebe, C., Boon, K., Hamilton, K., McIlvenna, S., Wood, L., "greenCDA and greenCCD," HL7.Inernational, 2011.

[6] Miller, R. H., Sim, I., "Physicians’ Use Of Electronic Medical Records:

Barriers And Solutions," Health Affairs, vol. 23, pp. 116-126, 2004.

[7] Committee on Quality of Health Care in America, Crossing the Quality Chasm:

A New Health System for the Twenty-first Century, Washington, D.C., National Academy Press, pp.23-38, 2001.

[8] Balas, E. A., "The Clinical Value of Computerized Information Services: A Review of Ninety-eight Randomized Clinical Trials," Archives of Family Medicine, vol. 5, pp. 271-278, 1996.

[9] Hunt, D. L., "Effects of Computer-Based Clinical Decision Support Systems on Physician Performance and Patient Outcomes," Journal of the

AmericanMedical Association, vol. 280, pp. 1339-1346, 1998.

[10] Lynam, K. B., Karlan, V. J., "ElectronicMedical Record Systems: Trends in Large Group Practices," Group Practice Journal, vol. 51, pp. 18-24, 2002.

[11] Interactive, H., "eHealth’s Influence Continues toGrow asUsage of the Internet by Physicians and Patients Increases," Health Care News, vol. 3, pp. 1-7, 2003.

國立臺北護理健康大學資訊管理研究所碩士論文