2010年12月15日 星期三
2010年11月21日 星期日
HL7 EHR System Functional Model
出處：http://www.hl7.org/implement/standards/ehrphr.cfm
HL7 EHR System Functional Model 提供了一組建議在EHR-System中出現的功能列表(reference function list)。這個功能列表以使用者的角度來描述，希望能為EHR-System提供一個一致的功能性描述。EHR-S Model透過建立Functional Profile的方式，為使用者所尋找的系統功能，提供為大家所了解的標準化描述，如intensive care, cardiology, office practice in one country or primary care in another country 等。
EHR-S-Functional Model則定義了一連串PHR-System應有的功能，並提供不同PHR或EHR系統之間資料交換的Guideline。EHR-S-Functional Model於2008年發佈成一個DSTU Draft。在測試期間，PHR系統的客戶可以在選擇PHR系統時，要求廠商提供這些標準的功能，廠商也可以把這個Model定義的需求整合到其PHR產品中，並且用這個Model提供的Conformance criteria來驗證所提供的功能是否符合此Model的定義。一些單位如Certification Commission for Healthcare Information Technology (CCHIT)及Centers for Medicare and Medicaid Services已經開始使用PHR-S FM內定義的元件…
2010年7月1日 星期四
新版個資法大解密
引用自http://www.ithome.com.tw/privacylaw/article/61687
文/王宏仁 (記者) 2010-06-09
個資法什麼時候實施？管轄哪些行為？保護哪些個人資料？ 企業違反個資法時，老闆會被判刑嗎？不論老闆、員工都要不可不知的29條個資法常見問題
Q1 個資法什麼時候實施？
立法院於4月27日三讀通過個資法後，法務部會先用6～8個月完成施行細則，再呈報給行政院審核，審核時間約1～2個月。法務部預估在總統公布後1年內，完成施行細則的作業流程，再由行政院決定正式實施時間。
Q2 個資法管轄哪些行為？
個資法管轄個人資料的蒐集、處理和利用行為。
Q3 個資法保護哪些個人資料？
新版個資法規範了企業必須保護的個人資料類型，包括了個人的姓名、出生年月日、身分證統一編號、護照號碼、特徵、指紋、婚姻、家庭、教育、職業、病歷、醫療、基因、性生活、健康檢查、犯罪前科、聯絡方式、財務情況、社會活動，以及其他可以直接或間接識別出個人的資料都屬於個資法的保護範圍。
Q4 是不是只有5千筆以上的個資才會適用個資法？
不是，只要有1筆個資就會受到個資法規範。5千筆限制只是法案討論過程中，參考日本個資法的說法，後來未採納。
Q5 個資法是不是不管紙本上的個人資料？
不是，不論是電腦中的數位資料，或者是寫在紙張上的個人資料，全都適用個資法。
Q6 網路暱稱或Email屬於個資法規範的個人資料嗎？
由於網路暱稱不易識別出其代表的個人，所以，不會受到個資法規範。至於Email則有可能識別出個人，法務部會請主管機關NCC提供認定標準。
Q7 如果個人資料中部分內容模糊，例如身分證號中有4個數字模糊，是否還會受到個資法規範？
這類部分模糊的個人資料，由於一般人無法輕易識別，等同失去識別力，因此，這類資料就不適用個資法。但若和其他個資搭配後具有識別力，仍舊需要受到個資法規範。
Q8 是不是只有企業才需要遵守個資法？
不是，不論是自然人（也就是一般人），法人（企業）或其他團體都需要遵守個資法的規範。
Q9 其他團體如何定義？
任何3個人以上所組成的團體，或者團體可以有一位代表人或主席，就是一個團體。不論哪一種團體都要遵守個資法。換句話說，你和三五好友組成一個球隊，球隊所蒐集的個人保險資料、通訊資料，都要遵守個資法的規範。
Q10 在國外蒐集個資是否要遵守個資法？
不論在國內外，只要對中華民國的國民蒐集、處理或利用個資，都適用個資法。
Q11 個資法保障了哪些個人的個資權利？
每一個人對於他的個人資料可以請求閱覽或查詢、請求提供複製本、請求更正或補充、請求停止蒐集、停止處理或利用，最後還可以請求刪除。
Q12 企業是否可以拒絕個人提出的個資處理請求？
只有在三種情況下，企業可拒絕個人的請求，包括妨害國家重大利益、妨害公務機關執行法定職務、妨害蒐集機關或第三人重大利益時等。
Q13 企業必須多快回應個人提出的個資處理請求？
對於個人要求查詢、瀏覽或複製的請求，企業必須在15天內決定是否同意，若要拒絕得書面說明理由，最多可再延長15天。若是請求補充或更正，則可在30天內答覆，最多再延長30天。
Q14 若個人要求企業刪除個人資料，但另有法律規定要求企業保存，企業該如何處理？
若有其他法律規定，就可以拒絕個人的刪除請求。個資法規定，企業可依其他法律的規定或法定義務來蒐集、處理和利用個資。
Q15 個資法的主管機關為何？
每個行業的目的事業主管機關就是個資法主管機關，或者說，企業向哪個機關登記註冊，該機關就是個資法主管機關。若牽涉到多個主管機關或者主管機關不清楚時，則透過公務機關的協調聯繫機制決定如何共同執行或由誰主管監督，若無法決定則交由行政院決定。
Q16 企業可以任意自定蒐集或處理資料的目的嗎？
不行，法務部將會和各事業目的主管機關訂定新的特定目的項目，企業必須從中選擇其中一項或多項作為資料蒐集目的，就像是現行《電腦處理個人資料保護法》所訂定的101項特定目的。企業蒐集個資時不能踰越所選定的特定目的範圍，才能算是合法蒐集。
Q17 若有當事人投訴企業侵犯個資時，企業是否需要舉證，證明自己確實遵守個資法的規範？
是的，在個資法中規定由企業負擔舉證的責任，若有當事人投訴企業侵犯個資，企業必須證明自己盡到保護個人資料的義務，才能免責。
Q18 當事人合法公開在網路上的資料是否可以蒐集？
凡是當事人合法公開，或者是其他合法管道公開的資料，企業就能蒐集利用，但是企業必須確認這些資料來源的合法性。
Q19 個資法要求企業直接對當事人蒐集個資前，要先告知當事人，企業可以透過哪些方式告知？
告知形式不拘，電話通知、簡訊、電子郵件、書面通知等都可以，最重要的是，企業得保留記錄，事後才可以舉證已經盡到告知義務，通知方式則沒有限制。
Q20 直接對當事人蒐集個資時，有哪些情況不用告知？
對當事人蒐集個資時，下列情況就免告知，包括依法規定免告知、執行法定職務或法定義務時、告知時將妨礙公務、妨礙第三人重大利益，或者是當事人明確知道這些應告知的內容。最後一項例如當事人提供個資給仲介業者時，當事人已經知道房仲業者會將這些資料拿來建檔，作為提供房屋資訊的聯繫之用，此時房仲業者就不用再告知。
Q21 如果企業不是直接向當事人蒐集個資，仍舊需要告知當事人嗎？
即便不是向當事人蒐集個人資料，企業仍然要告知當事人，只有部分情況下才免告知。
Q22 什麼情況下企業取得個資時，不用告知當事人？
不用告知的情況例如法律規定免告知、執行法定職務或法定義務、告知將妨害第三人重大利益、當事人明知應告知內容、當事人自行公開、來自其他合法公開的個資、不能向當事人或法定代理人告知、為了公共利益或學術研究而資料經過處理無法識別個人時、或者是大眾傳播業者為了公共利益的蒐集時，這些情況就免告知當事人。
Q23書面同意可以透過電子文件方式進行嗎？
不行，法條中的書面同意是指必須取得當事人的紙本同意書，透過電子文件或者是透過電子簽章取得的同意書，則不符合個資法的書面同意。
Q24 企業現有個人資料是否需要遵守個資法？
企業在個資法施行前蒐集的個人資料庫，若非由當事人提供，就必須在個資法實施後1年內告知當事人，讓對方知道企業擁有他的個人資料。告知後才能繼續利用他的個人資料。
Q25 企業對現有顧客行銷時，需要提供拒絕管道嗎？
由於企業現有的行銷資料庫已經不是首次行銷，所以，不用提供拒絕接受行銷的方式。
Q26 若發生個資損害時，當事人求償的時效多久？
當事人必須在事件發生5年內提出求償，或者當事人知道損害事件後，在2年內要提出，超過時間就不能再請求賠償。
Q27 發生個資損害時，賠償金額有多少？
若損害金額不易估算時，每人每一件可賠償500～20,000元，最高2億元賠償。涉及利益超過2億時，就按實際利益計算。
Q28 個資法會處罰企業老闆嗎？
企業違反個資法第46、47和48條的行政罰鍰時，如果老闆無法證明自己努力盡到防止義務，就會被處以相同額度的罰鍰。行政罰鍰從2萬～50萬元不等。
Q29 企業違反個資法時，老闆會被判刑嗎？
若企業違反個資法而導致顧客損失時，企業主必須面對最高2年以下的有期徒刑。若老闆為了營利而違反個資法時，刑期還會加重到最高5年以下有期徒刑。
2010年6月24日 星期四
PWR_Schema_Design_Decision: 解決目前設計的Entity的RI問題
下圖是依照Entity繼承結構所產生的Physical Data Schema。經過詳細檢視後，發現這個設計會無法Insert資料。因為E_SupportingPerson和Organization的entityID是不同的值。這樣E_TeleComIndex的entityID值無法同時參照Organization及E_SupportingPerson的entityID。因此無法work。現在要考慮怎麼解決這個問題
2010年6月23日 星期三
PWR_Schema_Design_Decision: 將原本依照data type分開的Observation併回一個
下圖為原本規劃的Observation結構，此結構依照資料型態是Integer、Decimal、及String來將資料放在不同的表格中。這樣的設計方式會導致查詢及Insert資料時都變得很困難
以下說明在這樣的設計下，Query及Insert資料會有多複雜
1、查詢某個病人的血糖數據
Step1:取得符合檢驗數據的actID
SELECT A_Act.actID FROM A_Act,P_Particiaption_Subject,R_Patient,E_Person
WHERE E_Person.entityID = R_Patient.entityID AND
R_Patient.roleID = P_Participation_Subject.roleID AND
A_Act.actID = P_Participation_Subject.actID AND
A_Act.classCode = 'OBS'
Step2:由Observation類別取得實際檢驗值
SELECT resultValue,resultCaptureDatetime from A_ObservationInteger
WHERE resultTitle = 'BloodSugar' UNION
SELECT resultValue,resultCaptureDatetime from A_ObservationDecimal
WHERE resultTitle = 'BloodSugar' UNION
SELECT resultValue,resultCaptureDatetime from A_ObservationString
WHERE resultTitle = 'BloodSugar'
上述的Query並不假設BloodSugar存放在ObservationInteger或ObservationString表格中，這樣的查詢
也比較容易撰寫。
要注意的是，在Insert資料時，BloodSugar只能Insert到ObservationDecimal中，而何種檢驗數據要放在那個表格，可記錄在另一Meta_ObservationTile表格中
=============================================
2. Insert某病人的檢驗報告，內含10種檢驗數據
Step1: 建立一筆新資料到A_Act表格
INSERT INTO A_Act (actID,classCode,moodCode)
VALUES (<actID>,'OBS','EVN')
Step2: 查詢Meta_ObservationTitle表格，得到那些數據要放到那些表格
SELECT observationTitle, recordTable from Meta_ObservationTile
WHERE observationTitle in ('BloodSugar','BodyWeight','...')
Step3: 以一個While迴圈去iterate Step2的SQL回傳值。針對每一筆回傳值，將資料Insert到相對應表格，下面以BloodSugar為例，假設查詢結果顯示BloodSugar應該放在A_ObservationDecimal
INSERT INTO A_ObservationDecimal (obsTitle,obsValue,obsCaptureDatetime,actID,code,obsUnit)
VALUES ('BloodSugar',100.2,20100623110102,<actID>,'checkType','mg/dl')
Step4: 等迴圈處理完畢後，Commit
Step5: 在E_Person中，檢查entityID是否已存在，若不存在則Create新的一筆E_Person Record
Step6: 查詢該E_Person實體的entityID有沒有Play病人的Role，若沒有則Create新的一筆R_Patient實體
SELECT R_Role.roleID FROM E_Person,R_Patient,R_Role
WHERE E_Person.entityID = R_Patient.entityID AND
R_Patient.roleID = R_Role.roleID AND
R_Role.classCode = 'PAT'
Step7: 將actID與roleID更新到P_Participation_Subject中
INSERT INTO P_Participation_Subject (actID,roleID,typeCode)
VALUES (<actID>,<roleID>,'SBJ')
Step8: Commit
為了簡化Insert及Update的動作，與Liangzhou討論過後，決定要將原本依照不同資料型態而分成不同表格的Observation，合併成一個Observation table。合併後結果如下圖
Query及Insert資料的步驟如下
1、查詢某個病人的血糖數據
Step1:取得符合檢驗數據的actID
SELECT A_Act.actID FROM A_Act,P_Particiaption_Subject,R_Patient,E_Person
WHERE E_Person.entityID = R_Patient.entityID AND
R_Patient.roleID = P_Participation_Subject.roleID AND
A_Act.actID = P_Participation_Subject.actID AND
A_Act.classCode = 'OBS'
Step2:由Observation類別取得實際檢驗值
SELECT obsIntegerValue,obsDecimalValue,obsStringValue,resultCaptureDatetime from A_Observation
WHERE resultTitle = 'BloodSugar'
在回傳值中，obsIntegerValue,obsDecimalValue和obsStringValue應該只會有一個有值，程式必需進行判斷。
也可以建立一個Meta_ObservationTile表格，記錄什麼檢驗數據是什麼資料型態。然後程式先查詢該Meta table，得知要查詢Integer、Decimal還是String
2. Insert某病人的檢驗報告，內含10種檢驗數據
Step1: 建立一筆新資料到A_Act表格
INSERT INTO A_Act (actID,classCode,moodCode)
VALUES (<actID>,'OBS','EVN')
Step2: 查詢Meta_ObservationTitle表格，得到那些數據要放到那些表格
SELECT observationTitle, recordTable from Meta_ObservationTile
WHERE observationTitle in ('BloodSugar','BodyWeight','...')
Step3: 以一個While迴圈去iterate Step2的SQL回傳值。針對每一筆回傳值，將資料Insert到A_Observation的相對應欄位，下面以BloodSugar為例，假設查詢結果顯示BloodSugar應該放在obsDecimalValue欄位中
INSERT INTO A_Observation (obsTitle,obsDecimalValue,obsCaptureDatetime,actID,code,obsUnit)
VALUES ('BloodSugar',100.2,20100623110102,<actID>,'checkType','mg/dl')
Step4: 等迴圈處理完畢後，Commit
Step5: 在E_Person中，檢查entityID是否已存在，若不存在則Create新的一筆E_Person Record
Step6: 查詢該E_Person實體的entityID有沒有Play病人的Role，若沒有則Create新的一筆R_Patient實體
SELECT R_Role.roleID FROM E_Person,R_Patient,R_Role
WHERE E_Person.entityID = R_Patient.entityID AND
R_Patient.roleID = R_Role.roleID AND
R_Role.classCode = 'PAT'
Step7: 將actID與roleID更新到P_Participation_Subject中
INSERT INTO P_Participation_Subject (actID,roleID,typeCode)
VALUES (<actID>,<roleID>,'SBJ')
Step8: Commit
這樣的修改對於減化Query的幫助較大，而對於減化Insert的幫助較為有限。不過至少可以讓整個data model較容易了解
2010年6月22日 星期二
PWR_Schema_Design_Decision: 用兩個Participation來串接Patient與飲食的關係
typeCode=PRD,描述Supply與食物(material)的關係。
typeCode=RCT,描述Pateint與該Supply的關係。
利用這樣，可以用一個Act.id把飲食與Patient串起來
RIM Class間的關係
以下的敘述描述RIM六大class中的四大class之間的關係。
用一句話來說明就是 Entity 會 扮演Role；所扮演的Role會去Participate某個Act
[Entity] ---play--->[Role]--->[Participate]--->[Act]
PWR_Schema_Design_Decision: 儘量減少繼承關係至兩層
參考：PWR Schema Design Decision：盡量限制PWR的繼承關係至多為三層
二個禮拜前，覺得想要把繼承關係限制為三層，現在覺得應該直接限制成二層，目前正在測試這樣的架構有沒有問題
扁平他繼承關係的手段：
1.直接將子子類別繼承自父類別
這裡舉Act、Supply、Diet的關係為例子，下面第一個圖是依據RIM的結構，Act、Supply和Diet的關係。但是這樣的設計方式，會沒辦法塞資料。比方說，現在要塞diet的資料，它的classCode是”Diet”，若依照下面的設計，要塞Diet就一定要塞資料到Supply。但是Supply的classCode是SPLY，如果塞進去的話，就會違反RIM的設計。若把A_Diet接到A_Act下面，似乎就可以解決這樣的問題了
修改後的結構如下，若來源資料的classCode是SPLY，就將資料塞到A_Supply中；若classCode是A_Diet，就將資料塞到A_Diet中。注意因為A_Diet是繼承自A_Supply，所以要記得將原本A_Supply有的屬性也複製一份到A_Diet中
2.用association取代繼承
2010/06/22
2010年6月13日 星期日
PWR Schema Design Decision:整併Observation的子類別
依照儘量減少不需要的屬性以及分散繼承關係屬性的原則，決定將Observation類別的屬性做下列處置
 | value:移到子類別，因為這些值存放在子類別才能清楚表示其生物意義 interpretationCode:移到子類別，只有少數的Observation子型別需要判斷Observation結果的好壞 methodCode:移除，用以表示Observation的方式，依目前的Requirment不需要 targetSiteCode:移除，用以表示Observation的部位，依目前的Requirement不需要 |
經過屬性的修改後，發現Observation看起來像是一個多餘的類別，依照儘量減少繼承階層數目的原則。決定將Observation與其子類別進行整併。下圖為原始的類別關係圖
下圖為整併後的類別關係圖
得到這樣的關係圖後，接下來討論這些檢驗數據如何分類放置。目前因為不管如何進行分類都有其缺點。這裡先決定以撰寫資料輸入程式的方便性為較高的考量。依照這樣的概念，依實際的情境，將會一起出現的資料放在同一表格。然後再用view將同一個檢驗數值再結合起來呈現。比方說血糖資訊可能來自遠端監控，也可能來自醫院的檢驗。為了處理方便，就先將這兩個來源的資料放置在不同表格中。然後最後再用個view取得所有血糖的資料。這樣分類方式，需提供一個設計以確保未來extend時，資料的完整性
PWR Schema Design Decision:將Surgery與Procedure合併，另將SubstanceAdministration 直接連接至Act
參考：PWR Schema Design Decision:拆開或合併 有繼承關係Entity的決定因素
PWR Schema Design Decision：盡量限制PWR的繼承關係至多為三層
本篇文章顯示合併或分拆Entity取捨中，較為複雜的例子。 下圖為原始的Entity關係圖
因為在上圖中，Procedure只有Surgery及SubstanceAdministration兩個子Entity，該兩個Entity在PWR中會引用的概念上有比較大的差異。且Surgery與Procedure的概念上比較相近，因此決定將Surgery併到Procedure，然後SubstanceAdministration直接繼承自Act。經過修改後的Model如下
2010年6月12日 星期六
PWR Schema Design Decision:拆開或合併 有繼承關係Entity的決定因素
參考：PWR Schema Design Decision：盡量限制PWR的繼承關係至多為三層
將Entity拆成多個子Entity：
優點：擴充性較高，新增別種子型別的Entity時，對於父Entity的影響不大。
缺點：填入資料及查詢資料的程式較為複雜，且繼承關係愈長，UOW愈長，為了要檢查RI的完整性，可能會導致較多的Lock
將多個子Entity併回一個父Entity：
優點：填入資料及查詢資料的程式較為簡單，一個SQL即可完成交易，UOW較短
缺點：在新增別種子型別Entity時，擴充性較低
因為分拆與合併的優缺點是相互抵觸的，所以在這裡定下一個標準：只有針對PWR主要Focus且有彈性擴充需求相關資料，如Remote monitoring的資料，採用分拆的設計；其它次要的資料及較無彈性擴充需求的相關資料，如醫療記錄、生活史資料，則採用合併的設計
PWR Schema Design Decision: 使用Frequency meta-table存放頻率資訊
Act.repeatNumber的資料型態為IVL(Interval)；Act.effectiveTime資料型態為時間。將這兩個值併入Frequency meta-table即可表示頻率資訊。如下圖
不過因為effectiveTime的資料型態為TS，而Frequency所需要的時間是elapse Time，所以再將Frequency entity更改為下圖。用elapseTimeUnit來代表是elpase time的單位是年、周、月、日；然後用elapseTimeQty來表示elapse time的數目
PWR Schema Design Decision: 決定Act類別要保留的欄位
Reference：PWR Schema Design Decision：如何分散繼承關係中的屬性？
依照儘量減少不需要的屬性以及分散繼承關係屬性的原則，決定將Act類別的屬性做下列處置
 | classCode:保留以維持semantic，且此值會做為insert資料時，決定將資料填入那個子table的依據 moodCode:保留以維持semantic code：移除，依照此說明，Act.code是optional的欄位，只是作為specialize classCode之用 title：移到子類別，為非必需欄位，且將title值放置在子類別的欄位可以讓該值更有意義 text：移到子類別，為非必需欄位，與title一樣，text值移至此類別欄位，可讓該值更有意義 statusCode:移到子類別。為非必需欄位，只有特殊子類別才需要利用statusCode描述Act的狀態 effectiveTime:移到子類別。為非必需欄位，且將此值放置在子類別的欄位可以讓該值更有意義 activityTime:移到子類別。為非必需欄位，且將此值放置在子類別的欄位可以讓該值更有意義 availabilityTime:移到子類別。為非必需欄位，且將此值放置在子類別的欄位可以讓該值更有意義 priorityCode:移到子類別。只有少數子類別可能需要此值 confidentialityCode:保留，可用來決定是否可Query此Act的資料 repeatNumber: 移除。為非必需欄位，目前還沒想到有何用處 interruptibleInd:移除。為非必需欄位，目前還沒想到有何用處 levelCode: 移除。為非必需欄位，只是作為標示該Act子類別位於繼承關係的第幾層。且在新版RIM可能被移除 IndependentInd:移除。為非必需欄位。用來標示可否直接對該Act進行排序之類的操作。 uncertaintyCode:移到子類別。為非必需欄位。用來標示該Act所描述的事實的可信度。 reasonCode:移除。目前發現只有patientEncounter有需要使用到reason這個概念，但是目前沒有把它變成Code的需求，直接用純文件記錄即可 languageCode:移到子類別。用以描述Act.text所使用的語言 |
HL7 Datatypes 簡述
EncapsulatedData (ED): Data that is primarily intended for human interpretation or for further machine processing outside the scope of HL7.
ConceptDescriptor (CD):A reference to a concept defined in a code system
CodedSimpleValue (CS):Coded data in its simplest form, where only the code is not predetermined. The code system and code system version are fixed by the context in which CS value occurs. CS is used for coded attributes that have a single HL7-defined value set.
Interval (IVL):A set of consecutive values of an ordered base data type.
Boolean (BL): A binary value for use in boolean logic. A BL value can be either true or false, or, as any other value, MAY be NULL.
CNE(Code without Exception):取代CE這個Datatype，不可extent原本的coding
CWE(Code With Exception)：也是取代CE這個Datatype，可以extend原本的coding
PWR Schema Design Decision：如何處理來自CDA及Web UI來的同類型資訊
PWR的資料來源可能有CDA及Web UI兩大類，本文章探討如何設計Schema，以簡化處理這兩種資料的程式之設計
------------To Be Done----------
PWR Schema Design Decision：盡量限制PWR的繼承關係至多為三層
在此篇PWR Schema Design Decision：如何在有繼承關係的類別階層中Insert data文章中，討論到在Insert一筆資料到有繼承關係的表格時，為了要維持資料的Integrity，必需透過classCode，循著繼承關係，在一層一層的表格中填入資料，若階層關係很長，不但將來在撰寫資料Insert程式會很困難，也容易造成Commit的時間太長而導致Lock的情況發生。因此決定PWR將儘量限制其繼承關係為3層
移除的方法為詳細檢視該繼承之關係，檢討是否需要這麼多class，若實際上不需這麼多層的關係，可以將要刪除的class中的屬性移到其它繼承樹的其它class後，再將class刪除
PWR Schema Design Decision：如何在有繼承關係的類別階層中Insert data
下圖為一個繼承的Entity階層關係，表示Diet這個Entity是繼承自Supply；而Supply又是繼承自Act。也就是說Diet IsA Supply，且Supply IsA Act。因此，某一個Diet的Instance的actID值，必需在Supply及Act的actID欄位找得到。
為了確保這樣的資料一致性，在Insert資料時，應該依照下列順序進行：
Insert into Act，把需要的資料輸入完畢後，檢查classCode為何，若classCode為SPLY，則知道還要再在Supply表格上輸入相對應資料。若classCode為DIET，則知道還需要在Diet中輸入資料，輸入完之後，還要再Update Supply這個資料的表格內容。等到這些表格都更新完後，才能進行Commit
為了確保將來資料更新程式的正確性，應該要提供一個meta-table，來描述classCode與應更新的表格名稱之間的關係
2010年6月11日 星期五
PWR Schema Design Decision：移至子類別的屬性可否更名
依照此篇文章：PWR Schema Design Decision：如何分散繼承關係中的屬性？所探討，在處理RIM繼承的狀況時，儘量將父類別的屬性搬移到此類別，除非該屬性在父類別已具備完整的定義。那麼，在將父類別的屬性搬移至子類別後，能否將其更名呢？目前的想法是可以將其更名，原因如下：
- 閱讀此schema的開發人員並不一定了解HL7 RIM model，在將父類別屬性搬移至子類別時，單純地將名稱抄過去，可能無法讓閱讀此schema的開發人員很容易了解該屬性所代表的意思。
在更名完畢後，使用RDA在該更名過後屬性的Documentation一欄處，輸入它對應於那個父類別的那個屬性。如此一來，在產生DDL時，RDA會將此資訊加到產生的資料庫欄位的註解中，提供有興趣了解該欄位對應至那個HL7類別的屬性的人進行查找
PWR Schema Design Decision：如何分散繼承關係中的屬性？
本文章討論，在進行PWR設計時，在一個繼承的關係中，父類別中的屬性是要分散到子類別中，還是存放在父類別中
上圖所示的是一個RIM Model片斷的表示方式，在上圖的例子中，父類別擁有最多的屬性。這樣的設計其實並不恰當，應該儘量將屬性搬移至子類別，論點如下：
- RIM Model是採用UML的表示方式，父類別的屬性會被子類別進一步修飾。舉例來說，圖中Act這個父類別的activityTime在Observation這個子類別中，可能是表示檢驗發生的時間，而在Procedure這個子類別中，則表示排定的時間(Scheduled time)。單純地把所有的屬性都放置在父類別，對於閱讀此schema的開發人員，無法清楚地得知此屬性所代表的完整意含。
- RIM的繼承關係似乎與一般對於物件的繼承有些不同，一個繼承的關係，是基於語意的關係而建立。因此會發生父類別的某些屬性對於子類別並沒有意義(需再check HL7 RIM確認此statement的正確性)，藉由儘量將屬性搬移到子類別的動作，可以減少某些Act的instance，在某些屬性上為空值的狀況
修正後的結構類似下圖(p.s.為了簡化，下圖只是示意圖)
2010年6月7日 星期一
2010年6月5日 星期六
看準開放式平台 硬體商組軟體公司 2010 6月3日
看準開放式平台 硬體商組軟體公司
2010/06/03 17:41 中央社
（中央社記者周品均台北2010年6月3日電）開放式平台Android、，MeeGo作業系統在本次台北國際電腦展大放異彩，安謀 (ARM)、德州儀器 (TI)、IBM等公司今天宣布成立新軟體公司LINARO，預計將在11月推出軟體開發工具。
仔細觀看本屆國際電腦展，各大電腦廠除了展出搭載微軟 (Microsoft)作業系統外，也紛紛推出搭載Android作業系統的小筆電、平板產品，顯示開放式平台Linux的興起，雖然微軟仍在市占率上遠遠領先，Lunix卻也逐步進攻。
看準開放式平台Linux的後市，ARM、飛思卡爾(Freescale)、IBM、三星 (Samsung)、德州儀器、ST-Ericsson等6家硬體廠商今天宣布成立軟體公司LINARO，並由Tom Lantzsch出任執行長，未來將不以營利為目標。
Tom Lantzsch表示，以成立公司方式，投入經費研發鍵接系統晶片與作業系統的開發工具，而非選擇贊助Linux團體經費進行研發的原因在於，公司具有較好的執行力，研發時間與進度都較容易掌握。
實際上，LINARO更像是一個基金會，Tom Lantzsch表示，LINARO初期將由6家公司提供經費與研發人力，進行軟體研究、開發，同時將持續開放讓各廠商加入，是一不限制成員的組織。
ARM指出，硬體廠商要將諸如Android、MeeGo、LiMo等作業系統搭載在硬體裝置上時，仍要花費許多研發成本，因此，成立軟體公司，就是要聚集各家大廠的力量，減少重覆研發的資源浪費，未來公司成員也都可以受惠於研發結果。990603
2010年6月2日 星期三
如何讀RMIM
資料來源：http://emrstd.doh.gov.tw/emr/trainning/DocLib/6_RMIM.pptx
R-MIM是由D-MIM所挑出來用於某個特別情境的class的集合，其表示方式不是使用UML，而是使用其私有的獨特表達方式。以下簡單整理在RMIM這種獨特表達方式中所使用到的notation
Entry Point：
每個RMIM只會有一個Entry point來連繫到所要focus的焦點或主題，被指向的焦點對應到實際的XML文件中，它就是該XML文件的Root element。下圖為Entry Point notation的解讀方式
對應回CDA RMIM為例子，它的Entry Point的R-MIM/CMET Name就是 CDA R-MIM、R-MIM/CMET Identifier就是POCD_RM000040
Act及Entity Class標示方式：
如下圖所示，Class的顏色是有意義的，顏色代表該class是由那一個RIM的核心Class “clone”出來的。每個Clone出來的class都會有個Clone Name，也會有classCode、moodCode這些與RIM結構有關的attribute。依據HL7的wiki說明(連結)，Clone Name只是在由RIM “clone”出 class時，資料塑模人員給定的一個名字，它本身並沒有任何Semantic的功能。RIM的Semantic是保留在clone出來的class的 classCode、moodCode、typeCode…等結構性的attributes中。因此在作運算時，應該是拿classCode這類結構性的attribute來做，而不是clone name。不過資料塑模人員需要儘量取與classCode、moodCode這些attribute所代表的語意相近的名稱作為Clone Name，以便讀取該Model的人員，能很快地理解該class所代表意義，而不需去查classCode等這些attribute值的意義
Role的標示方式：
Role用來標示Entity和Entity之間的關係。所以它會連結到兩個Entity，與其中的一個Entity的連線為實線(Playing)，表示該Entity Play這個角色；與另一個Entity的連線為虛線(Scoping)，表示被連結的Entity知道、或被assign到該role。
Relationship class的標示方式：
其它的三個類別為Relationship相關的類別都是採用箭頭的方式來標示
Choice：
當在某個情況下，可以取用多個不同Class的選擇時，可以用Choice的標示方法，來表示有那些Class可供選擇使用
2010年6月1日 星期二
HL7 Clinical Document Architecture, Release 2 Paper
出處：http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1380194/
這篇文章對於CDA的設計有較整體性的介紹，以下摘錄個人認為比較有趣的地方
CDA是一個文件架構的標準，使用XML技術，將醫療資訊塑模至XML文件之中。塑模的過程中，CDA R2整份文件都採用了HL7 V3的RIM模型，以及HL7 V3的Data type(不像CDA R1只有針對Header的部分採用了RIM模型)。CDA的文件可分成Header及Body兩部分，其中Header的部分的功能是標示此文件的種類，並提供Authentication、Encounter、Patient及提供醫療服務的Provider的資訊。而Clinical Report的部分則都是放在Body的部分。放在Body中的資訊可以是Structured的資訊，也可以是Un-Structured的資訊。也因為如此，Body部分是CDA文件中，最具彈性，也最複雜的地方。
上圖為CDA RMIM擷取下來的片斷，若Body的部分放置結構化的資訊，則每種結構化的資訊都要放在Section這個元件之內。如上圖所示，除了一些結構化的屬性(如classCode及moodCode之外)，Section還有一些屬性可以用來描述每個Section元素內包含的內容為何。
Section.id: 為每個Section提供一個Unique的編碼
Section.code: 標示此要放在Section的臨床資料的種類，如Chief complaint(病患主訴)、allergy或adverse reaction…等。這些code的值就是一些編碼系統，如LONIC或SNOMED的編碼值
Section.title: 標示此Section的名稱，此名稱必需為Human readable
Section.text: 將narrative block形式的Clinical資訊(所謂narrative block即為human readable的格式)
在放置Section資料時，若要精準到Level3(computer computable)的層次的話，則在Section內還會再多一個Entry。因為包含的是computer computable資訊，所以每個item都需使用編碼。下圖為該paper舉的一個簡單的Observation範例
對於複雜的事實，有可能需要描述多個不同Act子物件的關係，此時就可以使用RIM的ActRelationship來詳加描述。下圖為paper舉的一個使用ActRelationship關係來描述病患家族史的例子
下表則為ActRelationship可能的relaiton type
2010年5月30日 星期日
HL7 V3 Vocabulary Domain規格主要架構
在HL7標準中大量地使用了許多的編碼來做為屬性的值，這些值多數都必需為來自許多的coding system所定義的編碼值，有些coding system是HL7內建提供的，有些則是HL7以外提供的，如LOINC編碼。在HL7的 Vocabulary規格書中，定義了這些所有可能會使用到的編碼，以及這些編碼所描述的概念(Coded concepts)。下圖展現出整個Vocabulary中，每個元件的關係。HL7 Vocabulary的網址為http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm#voc-sets
首先，Vocabulary domain是最抽象化的一層，它將所有相關的concepts做一個群組、歸類，每個domain的群組都有其唯一的name及description。
ValueSetContext則透過contextExpression提供一個方法來描述在某種VocabularyDomain中的某個情境下，可以使用那個ValueSet來描述該屬性值。因為一個Vocabulary domain可與多個ValueSet產生連結，此時就要使用ValueSetContext來描述在那個情境之下，適合使用那一組的ValueSet。
ValueSet是一組的CodedConcept，它透過definingExpress描述每個CodeSystem中，各有那些CodedConcept適合被納入該ValueSet。ValueSet也有name及description來描述該ValueSet的定義。一個ValueSet可以與多個VocabularyDomain結合；而一個VocabularyDomain也可與多個ValueSet結合，也就是說ValueSet與VocabularyDomain是多對多的關係
每個CodeSystem依照其所在領域，為該領域中所要描述的概念都做一個編碼，而形成一個個的CodedConcpet。CodeSystem在定義CodedConcept時，為這些concept給定一個編碼，即為conceptCode。而每一個CodedConcept也會有自己的conceptDesignation，也就是該Concept的名字。HL7允許一個CodedConcept有多個名字，這種情況主要是用來支援多國語言之用。
2010年5月27日 星期四
如何讀 CDA RMIM Model
HL7 Graphic Conventions for Derived Information Models
出處： http://wiki.hl7.org/index.php?title=Naming_Rules_For_HL7_Static_Information_Models
Although HL7's graphic conventions for representing derived models (RMIMs) are not strictly part of the naming rules, they reflect other rules imposed on the information model designers that do interact with the names to affect one's understanding of models. This section looks at the sub-set of those conventions that reflects class and association names.
The figure below represents a small "RMIM design" presented using HL7's graphic conventions with annotations (numbered boxes and colored arrows) added.
The diagram shows five regular (rectangular) classes from the backbone, two "arrow" classes" and one class from outside the backbone (deep blue). The conventions of interest are:
- All "non-arrow" classes have their class name as their primary label (annotations 1 & 2)
- The "arrow" classes have their association name (from the perspective of the starting class) as their primary label (annotation 1A)
- The class names of the "non-arrow" classes may be either their "formal name" (annotation 1) or a business name (annotation 2)
- Association names from any class to a "non-arrow" class are displayed adjacent to the class at the end of the association. This name must be the formal name which may be either the name of the ending class (annotation 3) or an alternate (annotation 4).
- Association names from any class to an "arrow" class are displayed as the primary label of the "arrow" class (annotation 1A).
For comparison, the following figure shows the same model diagramed using UML conventions.
In this circumstance, the figure shows the class name for all classes and associations, but it fails to illustrate:
- The associative function of the "arrow classes"
- The cardinality constraints imposed on attributes
- The appearance constraints (mandatory and required) imposed on attributes..
- Vocabulary domain constraints applied to classCode, typeCode and moodCode values which establish the essential semantic meaning of each class
- The coding strength constraint applied to coded attributes
HL7 Information Model 的 Naming Rule
出處：http://wiki.hl7.org/index.php?title=Naming_Rules_For_HL7_Static_Information_Models
命名的Style:
除了一個特例之外，在HL7 Information Model 中所有的名稱都必需Follow下面的Naming Rule
- 所有的Class名稱都必需採用UpperCamelCase的方式命名，即若Class名稱由多個字組成，每個字的第一個字元必需大寫，同時，Class名稱第一個字母也要大寫。例如 ClinicalDocument
- 所有的attribute名稱必需採用lowerCamelCase的方式命名，即若attribute名稱由多個字組成，每個字的第一個字元必需大寫，同時，attribute名稱的第一個字的字母需小寫。例如 manufacturerModelName
上面提到的特例為，當所指定的名稱是指向Common Message Element Types(CMETs)時，則第一個字是RIM Model裡面定義的Class，之後的字才是其它適合的Class名稱，而這兩個字必需用底線 “_”連接起來。這樣可以避免出現名稱的衝突
命名的Governing Principle
- 由RIM 核心類別clone出來的類別需由type code或class code來賦予唯一的定義(若為Act需再加上moodCode；而Entity則要再加determinerCode)。而HL7應該有一套方法，協助給予這些clone出來的class唯一的formal name
- 這些formal name應該要
- 針對由Act、Role及 Entity clone出來的class，formal name必需遵守classCode定義的constraint。而對於Act和Entity，則分別還要再用moodCode及determinerCode來進一步給予其定義
- 對於由ActRelationship、Participation及RoleLink所clone出來的class，formal name需遵守typeCode定義的constraint
- 對於由其它RIM class所clone出來的class，則需遵守該class的名稱constraint?
- 對於ActRelationship、Participation及RoleLink等類別(稱之為arrow classes)，clone name必需為該clone的formal name，透過另外加上字尾的方式，以避免語意不清
- 由ActRationship、Participation及RoleLink以外的class而clone出來的class，可以自訂其business name，只是這個business name並不具備語意上的意義，語意上的說明，必需是由classCode…等這些structural code來定義
2010年5月19日 星期三
Salseforce.com 被 M$ 告了
M$說Salseforce.com一共侵犯了9個patent
出處：
http://techcrunch.com/2010/05/18/microsoft-sues-salesforce-claims-infringement-on-nine-patents/
Microsoft has filed a lawsuit against Salesforce.com, alleging that the CRM company is infringing on nine of its patents. The move is somewhat surprising, as this is only the fourth time that Microsoft has sued another company for patent violations (though it has been the target of plenty of them). Here’s the statement from Horacio Gutierrez, Microsoft’s corporate vice president and deputy general counsel of Intellectual Property and Licensing:
“Microsoft has filed an action today, in the U.S. District Court for the Western District of Washington, against Salesforce.com for infringement of nine Microsoft patents by their CRM product.
Microsoft has been a leader and innovator in the software industry for decades and continues to invest billions of dollars each year in bringing great software products and services to market. We have a responsibility to our customers, partners, and shareholders to safeguard that investment, and therefore cannot stand idly by when others infringe our IP rights.”
The relevant patent names are:
- Method and system for mapping between logical data and physical data
- System and method for providing and displaying a web page having an embedded menu
- Method and System for staking toolbars in a computer display.
- Automated web site creation using template driven generation of active server page applications
- Aggregation of system settings into objects
- Timing and velocity control for displaying graphical information
- Method and system for identifying and obtaining computer software from a remote computer
- System and method for controlling access to data entities in a computer network
According to Cnet, in January Salesforce revealed in an SEC filing that “a large technology company” was accusing Salesforce of infringing on its patents. At the time, Salesforce was in discussions with the unnamed company and no litigation had been filed. Sounds like those negotiations didn’t work out. Salesforce declined to comment.
2010年4月9日 星期五
糖尿病管理工具介紹—FreeStyle Connect
TheraSense Inc.是一家血糖機的製造廠商，提供了FreeStyle Connect這個程式來協助追蹤血糖指數。現在這家公司已被Abbot買下，原本的FreeStyle Connect程式也不再提供，取而代之的是CoPilot™ Health Management System這套軟體。
CoPilot系統提供了下列12項報表
- Diary List
- Logbook
- Glucose Modal Day
- Lab & Exam Record
- Glucose Line
- Statistics
- Glucose Average
- Daily Combination
- Glucose Histogram
- Weekly Insulin Pump Summary Chart
- Glucose Pie
- HCP Group Analysis* (*Available only in HCP version.)
除了在自己的電腦上觀看之外，CoPilot還提供了將資料同步到遠端的Secure Internet Host Server上。使用者也可以選擇將自己的資料，與其它人分享
系統需求
- Personal Computer with 400 megahertz (MHz) or higher processor clock speed recommended (The software does not run on Apple® computers.)
- Internet connection or compact disc CD-ROM drive.
Random access memory (RAM) of 128 megabytes (MB) or more. - Available hard drive space of 30 MB.
Microsoft® Windows® 2000 or XP operating systems. - Monitor with 1024X768 or higher resolution.
- USB or Serial port, available 9-pin EIA-232 (also known as RD-232 or V.24) or appropriate adapter for a universal serial bus (USB) for glucose meter connection.
糖尿病管理工具介紹---ezManager Plus
Animas這間公司是一家製造血糖機及Insulin Pump的公司，並且提供可在PalmOS及Windows上執行的ezManager Plus diabetes management管理系統。它包含了整個FDA的Food資料庫，以及速食的營養資訊，並且可以讓使用者輸入自己的食譜。它提供了BG、insulin、運動及Note的管理。除此之外，也提供不錯的圖形顯示。
目前ezManager Plus已升級至 ezManager Max，以下為該軟體的資訊
(http://www.animascorp.com/animas-insulin-pumps/ezmanager-max-software)
ezManager Plus可以匯入Anima製造的血糖機及Insulin Pump的資訊，結合飲食(碳水化合物)、運動資訊，以達到最佳的血糖管理
主要Feature
- 由CalorieKing® food database中整合了500項食物的資訊，使用者也可擴充食物的資訊
- 可執行於Windows及 MacOS
- 可匯入Animas製造的血糖機及Pump的資訊
- 可以產生PDF、HTML 或 XLS 格式的報表資訊
- 隱私保護機制
- 繪製趨勢圖
系統需求
Desktop Application (Microsoft® Windows®)
- PC running Microsoft® Windows® 2000, Microsoft® Windows® XP or Microsoft® Vista®
- One available USB port
- 200 MB free hard disk space
- Minimum 256 MB RAM
- Animas® IR Accessory Kit for ezManager® Max Diabetes Management Software - Cables for your blood glucose meter(s) (necessary only if you plan to download or upload information from your blood glucose meter). Cables are available from the blood glucose meter manufacturer
Desktop Application (Mac OS®)
- Apple® computer running Mac OS® 10.5
- One available USB port - 200 MB free hard disk space
- Minimum 256 MB RAM
- Animas® IR Accessory Kit for ezManager Max Diabetes Management Software (necessary only if you plan to download or upload a pump). Animas® IR Accessory Kit sold separately
- Cables for your blood glucose meter(s) (necessary only if you plan to download information from your blood glucose meter). Cables are available from the blood glucose meter manufacture
2010年3月29日 星期一
轉載 經濟學人：台灣醫療開銷佔GDP6.6% 比重高
經濟學人：台灣醫療開銷佔GDP6.6% 比重高
2010/03/29 22:43 中央社
（中央社記者康世人新加坡2010年3月29日專電）經濟學人資訊社今天發表的「亞洲醫療照護面對的挑戰」白皮書中，台灣醫療開支佔國內生產毛額（GDP）比重最高，但健保的財務制度最終需要改革。
經濟學人資訊社（Economist Intelligence Unit，EIU）的這本白皮書，一共調查了中國、香港、印度、印尼、馬來西亞、菲律賓、新加坡、南韓、台灣、泰國和越南11個國家或地區。
白皮書顯示，台灣去年的醫療開銷佔GDP的6.6%，今年預估佔GDP的6.7%，都居這11個國家和地區之冠，而香港和南韓則緊追在後。
白皮書說，台灣人是亞洲最健康的，去年男性平均壽命是75.1歲，女性的平均壽命為81歲，平均歲數和南韓人一樣。
此外，白皮書指出，台灣人和韓國人是接受調查的11個亞洲國家或地區中最健康的，平均壽命領先其他亞洲國家或地區。
白皮書說，台灣去年每人的醫療開銷達1074美元，而台灣的國家收入花在醫療的支出上也逐年增加，其中又以藥品支出最高，每人每年高達220美元。
白皮書也談到，透過健保制度，大部分的台灣人雖然享有低廉的醫療照護，但也導致健保財務吃緊，因此健保的財務制度最終需要改革。
這11個亞洲國家或地區中，醫療開銷最少的印尼，去年和今年都只佔GDP的2.8%，其次是泰國3.3%、越南去年為3.7%今年是3.8%，菲律賓去年3.8%今年是3.9%，而新加坡的醫療開支佔GDP比重是倒數第5，去年和今年的比重都只有4.1%。
但白皮書表示，亞洲國家的醫療開銷佔GDP比重，都還是不如歐、美。其中，美國的醫療開銷在去年和今年分別佔GDP的16.3%和16%。
此外，白皮書顯示，台灣的醫院病床和醫生充足，每千人有1.5名醫生和6.4張病床，在11個亞洲國家或地區中，僅次於南韓的每千人有1.7名醫生和6.6張病床。
香港以每千人1.5名醫生、5張病床名列11國的第3名；中國大陸與新加坡則以每千人1.6名醫生和2.5張病床，並列第4。
在11個亞洲國家或地區中，病床和醫生最為匱乏的是印尼，平均每千人只有0.3名醫生和0.6張病床。
2010年3月20日 星期六
臨床路徑 (Clinical Paths)
臨床路徑 (Clinical Paths)
張慧朗 醫師長庚紀念醫院 泌尿科
一. 前言
為了避免醫療費用的浪費，並且能夠提昇照顧病人的品質，醫院 通常都會有很多組織及措施來達成醫院管理的目標。例如：整體品 質管理( total quality management )，各案管理( case management )，以 病人為中心的照護單位( patient-centered care units )，成果管理 ( outcomes management ) 和臨床路徑( clinical path )等，雖然各種組織 及措施各有不同的特色，但其目標卻是一致的，都是為了要做到減 少醫療費用的浪費，同時在照顧病人方面能夠維持一定的水準。 臨床路徑的施行就是在病人住院後依照臨床路徑的建議治療病人， 然後由專科護理師每天對照實際的治療程序和臨床路徑的差異，直 到病人出院。最後再由特定的組織人員分析及評估差異的原因，作 為以後修改臨床路徑的參考及避免不必要的醫療浪費。
二. 起源
早在1971年美國就巳成立SITO( The Services Interaction Targets for Opportunities ) 基金會， 致力於醫療品質的改善及醫療費用的控 制。 在1981年更通過以DRG ( diagnosis related group ) 為基礎的付 費方式，很明顯的降低了病人的住院日數。因此，減少醫療費用及 提高醫療品質就成為大家一齊努力的方向。
在1990年美國波斯頓( Boston )的New England Medical Center ( NEMC ) 就報告施行臨床路徑的經驗，她們是以護理部為發展中 心， 參加人員為臨床醫師及護理人員，當時稱為臨床要徑( Critical Path )， 用來代替護理計劃 ( nursing care plan )及作為護理人員照顧病人的參 考。
另一早期發展臨床路徑的醫院，為美國俄克拉荷馬州( Oklahoma ) 土耳沙市( Tulsa) 的Hillcrest Medical Center，她們也是以護理管理 為中心來發展。發展臨床路徑的委員會包括醫師、護理人員及各單 位的有關人員，其目的是用臨床路徑來做為照顧病人的指標。
林口長庚紀念醫院在早期就成立了醫療品質審議委員會，設有一 名主席、一名執行秘書及22 名成員，其中包括15位臨床醫師、1 位護理幹部、5位診斷部門人員及2位治療部門人員。在1995年1月 以後，醫院的管理部門又成立了臨床路徑發展小組 ( Clinical Path Development Team - CPDT ) 專門發展臨床路徑。成員共8名，包括1 名臨床醫師、2名管理中心人員和5名專科護理師。
1995年2月，林口長庚紀念醫院泌尿外科發展了經尿道前列腺切 除手術的臨床路徑，患有前列腺肥大的病人住院後，就依臨床路徑 的建議流程治療，至6月底一共有100位病人，依此模式治療而出 院。在本文後面將討論我們施行臨床路徑的經驗。
三. 臨床路徑的定義
Clinical Paths : Tools for Outcomes Management
臨床路徑是醫療管理者用來控制醫療成本及改善醫療品質的方法 之一 。 也是成果管理( outcomes management )的工具之一，所謂成 果管 理就是利用分析、評估及廣佈醫療成果，來改進整個醫 療體系的管理方式。
雖然控制醫療成本及改善醫療品質的方法有很多種， 但其目的都 是一樣的。主要是避免整個控制系統的失敗，在照顧病人上儘量減 少不必要的差異及促進醫療體系間人員的互相合作。
臨床路徑可以幫助醫師在照顧病人方面有較正確的思考方向。臨 床路徑提供的方法並不是絕對標準的治療方法，而是提供大部份病 人可以接受的治療方法。
詳細的說，臨床路徑是由組織內的一群成員，根據某種疾病或某 種手術方法製定了一種治療模式，讓病人由住院到出院都依此模式 來接受治療。路徑完成後，組織內的成員再根據臨床路徑的結果來 分析、評估及檢討每一個病人的差異，以避免下一個病人住院時發 生同樣的差異或錯誤，依此方式來控制整個醫療成本並維持或改進 醫療的品質。
所謂組織內的成員，就是包括管理決策者、醫師、護理人員及其 他醫療有關的人員。這些人組成了一個委員會，來發展推動及評估 臨床路徑。並定時開會檢討臨床路徑的實用性，使臨床路徑隨時更 新又能配合醫學的發展。
施行臨床路徑的目的，主要是想由病人治療的結果來分析及評估 治療的方法，希望藉著每天對於病人的觀察與記錄，找出一種最適 當的治療方法，而這種治療方法是可以減少醫療費用又可以維持或 改進醫療品質的治療模式，並且是大部份的病人可以接受的。
臨床路徑希望找出最有成本效益( cost-effective )的治療模式，而 達到過去一樣的治療效果，或甚至比過去更好的醫療品質。 所謂最 有成本效益的治療模式，就是最短的住院日數( length of hospital stay )，在一定時間內不會為了同一種疾病再次住院，而且是大部份 的醫師都可以接受的治療方法。
臨床路徑在早期有很多如下不同的名稱，但後來還是以稱呼 clinical paths 佔大多數。
Terminology: Clinical paths
Clinical pathways
Practice guidelines / parameters
Clinical guidelines
Clinical protocols / algorithms
Clinical benchmarking
四. 施行臨床路徑的準備工作 要施行臨床路徑，最主要的是要做好準備工作，然後按步就班的 去做。有些醫學中心施行臨床路徑失敗，主要的就是準備得不充足， 匆促施行所致。 下面幾點是在施行臨床路徑之前所必須 準備的工作：
1. 計劃 ( planning )
從開始施行臨床路徑至最後的差異( Variance )檢討，每一步驟的 流 程都必須列出來。 以臨床路徑為基礎的醫療體系是比發展臨床路 徑本身更重要的。
2. 多元性的組織 ( Multidisciplinary team )
施行臨床路徑常常會導致失敗，其主要原因是沒有達成各單位的 共識，因此常常遇到很大的阻力。所以邀集各有關單位組成臨床 路徑的推廣小組，定期開會討論是必要的。有些醫學中心就是以 護理人員為中心，沒有邀請資深臨床醫師加入而導致失敗。
3. 教育( Education )
當施行臨床路徑的領導小組確定了推行策略後，就要開始教育臨 床醫師、護理人員及相關的職員，同時要常開會說明施行臨床路 徑的用意及好處。
4. 設定目標 ( Setting goals )
設定明確的目標，選擇適合施行臨床路徑的疾病或手術方法，並 對有關人員說明施行的好處。
5. 醫師的參與 ( Physician involvement )
施行臨床路徑，醫師的加入是很重要的。 (1) 要教育臨床的主治醫師，包括施行臨床路徑有關或無關的 醫師。
(2) 要有領導階層的資深醫師加入，以利臨床路徑的推動。
(3) 臨床路徑的設計要有臨床醫師參與。
(4) 臨床路徑每日的施行要有臨床主治醫師的推動。
6. 專科護理師的參與 ( Nurse specialist involvement )
以林口長庚紀念醫院泌尿外科施行臨床路徑的經驗，專科護理師 是推動及施行臨床路徑最好的幫手。專科護理師負責照顧住院病 人，病人每天的治療流程都可由專科護理師來評估，很快的可以 發現治療的差異( Variance )，而馬上可以與主治醫師討論，修正 不 必要的差異。如果差異可以即時改過，就不會影響整個臨床路徑 的流程，也就不會造成醫療上不必要的浪費。
五. 臨床路徑的選擇
臨床路徑是控制醫療成本的一種工具( tool )，它可用來追蹤病人 由 住院到出院每天的治療過程，讓病人順著臨床路徑建議的治療方式進 行。同時臨床路徑也是一種系統( system )，它包括差異 管理 ( variance management ) 及品質改進( quality improvement )，而且也是醫 療系統 中各個組員間互相溝通的焦點。所以跟隨著臨床路徑， 可以 加強醫療 計劃的連續性，同時促進醫療體系間的合作性。 臨床路徑要選擇施行在病人多( high volume )的疾病或手術方 法， 且比較可弄成模型似的( paternable )樣式。所以約60-80% 的病人 可以 施行臨床路徑，其餘的20% 則須用個案管理 ( case management ) 來處 理。 而有些疾病是須要同時用臨床路徑及個案管理來探討的。 除了 這兩種方法以外，有很少部份的病人不適合用臨床路徑也不適合 用個 案管理，這些病人則須另外選擇管理途徑。
六. 臨床路徑的文件
為避免紙張的浪費，施行臨床路徑的文件不須要太多，但有以下幾種 是必須的。
1. 臨床路徑發展組織的說明文件
(1) 臨床路徑施行流程圖 ( Clinical Path implementation flowchart )
在對組織成員中之臨床醫師、護理人員及其他醫護人員的說 明 及教育時，都須用到此流程圖來解釋整個臨床路徑施行的方 法 及過程。
(2). 臨床要徑的展示圖 ( important path )
在臨床路徑中，有幾個步驟或幾天的治療程序對於整個路徑 影 響是很大的，如果這幾個步驟或治療程序有延誤，就會延長 整 個臨床路徑的日數，這些步驟或程序我們稱為臨床要徑。在 教 導實際治療病人的臨床醫師及專科護理師時，要特別強調臨 床 要徑的重要性。因臨床要徑是影響病人的住院日數及醫療費 用 最大的所在。
2. 疾病或手術方法的臨床路徑表 ( Clinical Path for a disease or operation )
臨床路徑表是為各種疾病或手術方法而設的，如果臨床路徑越多 此種表單就越多，所以最好是一種臨床路徑一張表單， 這樣 專科 護理師登記起來也比較方便。
3. 差異報表 ( variance reporting form )
施行臨床路徑後，要登記病人沒有按照臨床路徑治療的地方，並 探討原因，謀求改善或避免下一次犯同樣的錯誤，所以每一位病 人在出院後都須要填一份差異報表。
4. 差異號碼系統 ( variance coding system )
把每一種施行臨床路徑所發生的差異用號碼編排，以利電腦作 業 。 然後以此號碼系統與差異報表聯接，對於後來的臨床路徑 電 腦化是很有幫助的。
七. 臨床路徑的施行
臨床路徑的施行，最須要的是每天的記錄及查覺差異 ( variance )。 如果差異小，不影響整個臨床路徑，就只登記檢討。如果 差異是會影 響整個臨床路徑的結果，但是可以修正的，就馬上與臨床醫 師討論， 做必要的修正，使治療流程又回到臨床路徑上，不致於影響 到整個預 期的結果。如果差異不只影響到整個臨 床路徑，而且是不 可能修正 的，則須對整個差異的發生原因及過程做詳細的討論，以 避免下一個 病人再次發生，為了達到以上的施行方針有一些步驟是必須 的。
1. 詳細的記錄
從病人住院開始，臨床路徑表就附在病歷上，跟隨著病人的檢查 及治療措施，做每天詳細的記錄，一直到病人出院才將臨床路徑 表 收回。此種工作，由專科護理師來做最適當，登記完後在表上的 每 日欄位下簽名，以利後段的討論工作。
2. 查覺差異及隨時修正
由於每天都有記錄，如果病人的治療過程與臨床路徑不同，就可 以馬上發覺。以專科護理師的知識程度應足以與臨床醫師討論， 循 求修正之道。當然臨床路徑的施行不能去限制醫師的治療措施， 不 過時時提醒醫師注意自己的醫療行為，讓病人能得到最適當的照 顧卻是合理的。
3. 差異報表與預期成果的對照
病人出院後應針對每一個有差異的病人做詳細的討論，這種討論 會最好是由臨床醫師、專科護理師、病房護理人員、臨床路徑組 織 的成員及相關的醫護人員組成，找出差異報表與預期成果不同的 原因（如果這種差異是可以修正的，則討論出修正的辦法，避免 下 次再發生，如果大部份的病人有同樣的差異，則考慮修改臨床路 徑）。 雖然訂定臨床路徑相當費時，但臨床路徑一定要常提出來 討論、修正，使其成為最合適的治療方式。
4. 臨床路徑的成果報告
施行臨床路徑最後一定要將成果報告給臨床醫師及專科護理師知 道，如此可以讓臨床醫師及專科護理師自己注意臨床路徑的進 行，而達到自我監督及自我修正的目的。
5. 臨床路徑的散佈
成功的臨床路徑有必要讓大家知道，同時讓所有的人有共識，施 行臨床路徑不是要限制醫師的治療行為，而是要以一個平均大家 可 以接受的醫療行為模式來提醒醫師減少不必要的醫療浪費，同時 增 進醫療的品質。
6. 個案管理 ( case management )
個案管理主要是針對複雜而醫療費用高的個案做分析、評估及討 論，大約有百分之二十以下的病人是適合用個案管理來探討的， 所 以個案管理與臨床路徑有不可分的關係，對於病人數目少的疾病 不 適合用臨床路徑來分析，就改用個案管理。
八. 臨床路徑施行後的檢討
臨床路徑施行後，重要的是要檢討路徑的差異（variance）。 差異的發生，每天都有可能，所以專科護理師每天必須詳細的記錄各 種差異，隨時與負責的主治醫師討論或做修正。而最重要的是病人出 院後，要對病人住院當中所接受的治療與臨床路徑不同 的地方， 提出 討論，寫成差異報表（variance report ），召開差異討論會。
差異的種類通常分為六種:
1、病人的差異（patient variances ）
差異的發生常常來自病人，如手術後的併發症（post-operative complications ），病人對於臨床路徑建議的治療方式無效， 臨床 醫師必須改變治療計劃（ Unresponsive/change clinical regimen ）， 或是病人的心理問題，病人回家沒有安全感希望在醫 院多住幾天 （psycho/social delay）等。
2、醫師的差異（ physician variances ）
差異的發生有時候是醫師開立醫囑的延誤（physician ordering delay）， 或是專科護理師或病房護士執行醫囑的延誤（nurse delay）， 有時候也會因治療單位的失誤而延長了臨床路徑。
3、系統的差異（system variance）
有時候病人治療的延誤是因為醫院設備不足，如開刀房房間不足 或電腦斷層攝影檢查排程太長等等（equipment workload）。 有 時候則因為電腦當機或治療機器故障（如碎石機故障）等問題 （ equipment breakdown ）。 如果是因為這些問題造成的差異， 則須建議醫院加強設備的維修或增購醫療設備。
4. 住院前的差異（pre-admission variance）
有些病人因症狀加劇，臨時改由急診住院，緊急治療。有些病人 則轉到別的醫院看診。或有些病人因路途太遠，而改住附近的醫 院。更有的病人改變心意，不願意接受手術治療而拒絕住院。
5. 出院的差異（ discharge variance ）
病人出院後乏人照顧，或是家屬人力安排的問題而使病人須要多 住在醫院裡幾天。
6. 無差異（ no variance ）
病人由住院到出院，完全依照臨床路徑治療，或是病人不適合臨 床路徑的治療方式，而須改由個案管理或其他的醫療評估辦法， 都可能是無差異。
差異討論會後，必須將討論結果存檔並送報表給有關的臨床醫師、專 科護理師及設計臨床路徑的有關人員，必要時須修正臨床路徑表，使臨 床路徑提供的治療方式能隨著醫學的進步而改進。
九. 參考資料：
1. Fuszard, H., and others. Case Management : A Challenge for Nurses. Kansas City, MO : American Nurses' Association, 1988, P.1.
2. Zander, K. Managed care and nursing case management. In : G.G. Mayer, M.J. Maddin, and E. Lawrenz, editors. Patient Care Delivery Models. Rockville, MD : Aspen Publications, 1990, P.38.
3. Zander, K. Managed care : integrating "Q.A." in everyday practice. Definition 4(3):1-2, Summer 1989.
4. Mosher, C., Cronk, P., Kidd, A., McCormick, P., Stockton S., and Sulla, C. Upgrading practice with critical pathways. American Journal of Nursing, Jan. 1992, P.41-44.
5. Giuliano, K.K., and Poirier, C.E. Nursing case management : critical pathways to desirable outcomes. Nursing Management 22(3):52-55, Mar. 1991.
6. Olsen, C.A. Building critical pathways for a hospital-based home care program. Outreach 14(3):1,3, May-June 1993.
7. Coffey, R.J., Richards, J.S., Remmert, C.S., LeRoy, S.S., Schoville, R.RR., and Baldwin, P.S. An introduction to critical paths. Quality Management in Health Care 1(1):45-54, 1992.
8. Mangano, J. Clinical Pathways seen as opportunity to intetrate traditional QA with CQI. QI/TQM 2(4):49-51, Apr. 1992.
9. Spath, P.L. Critical paths : a tool for clinical process management. JAHIMA 64(3):48-58, Mar. 1993.
10. Wall, D. W., and Joseph, E. Analyzing critical pathways with statistics. Quality Management Update 3(6):8-10, June 1993.
11. King, J.O. The relovance of practical experience to Americal hospital (commentary). Froutiers of Health Services Management 10 (1):48-50, Fall 1993.
12. Falconer, J.A., Roth, E.J., Sutin, J.A., and others. The critical path method in stroke rehabilitation:lessons from an experiment in cost containment and outcome improvement. Quality Revies Bulletin 19(1):8-16, 1993.
13. Spath, P. Succeeding with Critical Pths. Forest Grove, OR:Brown- Spath & Associates, 1993, P.3.
14. Nash, D.B., and Markson, L.E. Emerging trends in outcomes management. Frontiers of Health Services Management 8(2):3-52, 1991.
15. Ellwood, P.M. Outcomes management : a technology of experience, New England Journal of Medicine 318(23):1549-56, 1988.
16. Jencks, S.F., and Wilensky, G. The health care quality improvement initiative : a new approach to quality assurance in medicare. JAMA 268(7):900-903, 1992.
十. 長庚醫院施行臨床路徑的經驗
從民國84年1月開始，長庚醫院組成了臨床路徑發展小組 （clinical path development team--CPDT ），成員包括醫院管理決策人員、 醫師及管理中心行政人員，經過一個月的收集資料，選擇臨床路徑，製 作臨床路徑文件及教育臨床醫師和專科護理師，於84年2月正式開始對 於患有前列腺肥大症，須住院做經尿道前列腺切除手術的病人，依照臨 床路徑的方式治療。
1、施行臨床路徑 （民國84年2月開始）
病人：患有前列腺肥大症的病人，須住院做經尿道前列腺切除手術。
專科護理師：每天依照臨床路徑的流程，詳實的記錄病人的治療經 過， 如果發現有差異，就與病人的主治醫師討論，隨時修正差 異， 使臨床路徑順利進行。並且每天在表上簽名，以便在日後 的差 異討論會上討論。
臨床主治醫師：幫助及監督專科護理師的工作，並配合修正病人的治 療方式，使其依照臨床路徑進行。 v 病人出院後，專科護理師須將臨床路徑表及差異報表完成，送交臨床 路徑發展小組。
2. 臨床路徑的差異討論會
病人出院後，臨床路徑發展小組人員、主治醫師及專科護理師，定期 開會討論病人住院治療時與臨床路徑差異的地方，同時必要時修正 治療方式或臨床路徑表。
3. 結果
從民國84年2月開始至6月底，有2位資深及3位年輕泌尿科主治 醫 師的病人，依照臨床路徑的治療模式進行，總共有100 位病人。 我們 並且以2月之前，同樣的主治醫師，同樣的病人數目來做比較：
（1）接受經尿道前列腺切除手術的病人，其住院至出院，有3個步驟 是 會影響整個臨床路徑的住院日數的，稱為臨床要徑 （critical paths）： ?手術前的準備（pre-operation preparation ） 在手術前一日，病人的各項檢查如果不能如期完成，則手術 必 須延後，因而影響整個臨床路徑完成的時間。 ?經尿道前列腺切除術（TURP） 手術如果不能照時完成，或改變手術的方法，或手術時發生 嚴 重的併發症，都會影響整個臨床路徑的住院日數。 ?術後導尿管放置的時間 接受經尿道前列腺切除手術的病人，術後都須放置一條導尿 管。導尿管拔除後，經過一天的觀察，如果病人解尿沒有問 題， 就可以出院。因此手術後導尿管放置的時間，常常是病人 能不 能出院的關鍵。
（2）我們評估的項目是：
LOS： Length of stay，病人的住院日數。
NPO： 病人手術後，禁食的日數。
B rest：Bed rest， 病人術後須臥床休息的日數。
NS ir： Normal saline irrigation，術後經由導尿管做連續性 生理食鹽水灌洗膀胱的日數。
Foley：導尿管放置的日數。
Antib：抗生素使用的日數。
Prost： 切除的前列腺重量（病理報告）
Charge：病人住院期間的醫療費用（NT$）
（3）結果:
LOS： 病人的住院日數由5.9日降為5日。
NPO： 術後禁食日數由0.1日降為0日，主要是改變治療模式， 大部份的病人術後不再禁食。
B rest：術後臥床休息日數由0.75日降為0.74日，因經尿道前列 腺切除的病人，術後須用寬膠布將導尿管固定在大腿上阻 血，故改善不多。
NS ir： 由0.89日降為0.79日，此項目減少，可以減少醫療費用。 Foley：導尿管放置時間由3.13日降為2.84日。此項減少可以縮 短 病人的住院日數。
Antib：抗生素使用日數與住院日數有關，由5.9日降為5日。 Prost： 前列腺切除的重量僅供差考用。
Charge：平均醫療費用由NT$ 43624元降為NT$ 36236元。
（5） 討論
施行臨床路徑，病人的住院日數（LOS），明顯的由5.9日降為 5 日（p <0.01 , t test），減少了百分之十五，此可以明顥的降低醫 療費用。其他改變主治醫師治療模式的有術後禁食日數由 0.1日 降 為0日，術後臥床休息由 0.75日降為 0.74日， 術後生理食鹽水 灌洗膀胱的日數由 0.89日降為0.79日，導尿管放置時間由 3.13 日降為 2.84日，除了導尿管放置時間會影響臨床路徑的住院日數 外，其他的對於住院日數並沒有影響，但可以改善醫療品質，讓 病 人覺得更輕鬆舒服，同時也可以減少醫療費用。至於導尿管放置 時 間則會影響整個臨床路徑的住院日數，所以病人住院日數的降低 與導尿管放置時間的長短息息相關。
抗生素的使用通常由手術前一日用到病人出院 ，所以病人住院日 數的降低與抗生素使用的多寡成正比。前列腺的重量則與臨床路 徑的施行無關，也與病人的住院日數及醫療費用無關。100位病 人 的住院平均醫療費用則由NT$ 43624元降為NT$ 36236元 ， 減 少了17% (p <0.01)。
由以上的資料，可以證明施行臨床路徑不但可以降低病人的醫療費 用，同時也可以改變醫療模式，改善醫療品質。
十一. 臨床路徑的未來展望
1、常規施行臨床路徑
雖然在施行臨床路徑時，專科護理師的角色很重要，但有些科別 或醫院並沒有專科護理師的編制，所以我們希望能將臨床路徑表 隨著病人的住院夾在病歷上，由病房的常規護士每天登記病人的 治 療結果及差異，當病人出院後再將臨床路徑表及差異報表由病歷 上拿下來， 與主治醫師及臨床路徑發展小組人員開會，討論差異 的原因及解決的辦法。
2、全面施行臨床路徑
由於臨床路徑的施行對於醫療費用的控制及醫療品質的改善確實 有其功效。所以現在國外有很多醫院已努力全面發展臨床路徑， 希 望能將龐大的醫療費用減低到最合理數目，同時又能維持或改善 醫療品質。我們希望長庚醫院初步的經驗，能作為以後大家全面 施 行臨床路徑的借鏡。
*感謝劉秀珍小姐在整理病人資料及打字的幫忙，同時感謝陳怡如小姐在 蒐集電腦資料的協助，使本文得以順利完成 。 一九九五年七月十五日 初稿，一九九六年五月十一日修稿。
作者：張慧朗 醫師
E-Mail:henryc@mail.tmu.edu.tw
2010年3月19日 星期五
廣達想投資的英國公司Toumaz
Revolutionary body monitoring for healthcare:
Wireless, Intelligent, Continuous, Low-Cost
The Toumaz Sensium™ provides the complete technology platform to allow healthcare providers to monitor the human body continuously, wirelessly, intelligently and at low-cost – with the robustness and medical compliance associated with considerably more expensive capital equipment.
Sensium enables the development of a new generation of non-intrusive body-worn wireless devices that can continuously monitor multiple vital signs in real-time, and feed back high-quality information to health professionals via PCs, PDAs and cell phones.
Sensium: end-to-end system for pro-active, personalised care
Gathering real-time information, not raw data
- On-chip signal processing to intelligently extract critical information from device sensors
- High-quality physiological and bio-chemical information for healthcare professionals
Ultra-low power, low device cost
- Patented AMx™ technology coupled with low power radio enables non-intrusive, continuous monitoring
- Ultra-low power and low voltage operation allows devices to be powered by thin, flexible batteries
End-to-end system
- Provides complete wireless infrastructure, including low power radio link from patient to telecommunications network
- Full integration with electronic patient records (EPR) and healthcare provider’s system
Connected freedom
- Lifestyle-compatible, non-intrusive form factors means improved quality of life for patients
- Delivers enhanced quality and efficiency of treatment through more pro-active, personalised care
======================================
新聞說廣達投資Toumaz這家公司，發展醫療雲端技術，所以稍微看了一下這家公司在做什麼。這家公司似乎是做與穿載式Sensor介接的device，Sensor與此device連接後，即可將資料向外傳輸，等於是一個RF傳輸的模組。希望透過這樣的分工，可以降低Sensor開發商的成本。猜測廣達可能是提供資料分析端的IT架構
林百里：為了創新 廣達除了做雲端電腦 更要做雲端運算產品 2010/03/19
林百里：為了創新 廣達除了做雲端電腦 更要做雲端運算產品
2010/03/19 23:31 鉅亨網
【鉅亨網記者蔡宗憲 台北】 廣達 (2382) 董事長林百里今(19)日出席「兩岸 高教新視野高峰會」，為了闡述創新理念，再次強調他最關心的雲端概念，並強調廣達將不只做雲端電腦，會 持續發展完整的雲端運算產品；而在人才創新上，廣達也將持續訓練員工創新能力，現有的廣達菁英學校與廣 達研究所未來都將成為引領廣達成長的動力火車頭。
林百里表示，台灣過去著重改良式的創新，但現在 應該要積極發展創新的概念，開發出全新的產品，並尋 找適合的商業模式販售，創造市場價值。
林百里說，廣達積極進入雲端運算就是創新的實踐 ，不過雲端運算牽涉到在地化的服務，因此廣達積極與 各地大學合作，包含MIT與北京大學，希望藉由大學對 在地文化的認知與其需求的優勢，提高雲端運算未來的 發展效率。
廣達為了搶攻雲端產品，因此在今年進行組織調整 ，在原有的NB代工事業以外，也新增3C事業群，成立 6 大事業部，底下分成健康事業部，手持裝置事業部，N B事業部，家庭事業部，辦公室事業部與城市事業部。
近期廣達也投資英國Toumaz，也是為了雲端醫療事 業做佈局，未來將持續推出各項雲端裝置；近來也傳出 行政院長吳敦義有意延攬林百里進入政府的雲端團隊。
林百里也指出，人才的創新能力也相當重要，廣達 現在設有「人才創新指標」，針對每位員工的創新能力 進行衡量，包含新進人員也必須進行創新的專業訓練，他強調，為了提升員工的專業與創新能力，廣達設有廣 達菁英學校與廣達研究所，林百里具信心地表示，未來 這 2 個學院，將成為引領廣達持續向上成長的動力火 車頭。
淺談雲端運算 (Cloud Computing) From 黃重憲教授
淺談雲端運算 (Cloud Computing)
作者：黃重憲 / 臺灣大學電機資訊學院資訊工程系「雲端運算」=「網路」=「網路運算」。「雲端運算」不是「新技術」或「技術」。「雲端運算」是一種概念，代表的是利用網路使電腦能夠彼此合作或使服務更無遠弗屆。在實現「概念」的過程中，產生出相應的「技術」。
隨著Google在去年初宣布於台灣啟動「「雲端運算」學術計畫」，「「雲端運算」」這個聽來帶點浪漫色彩的科技名詞立時席捲各大媒體版面。眾多網路公司以及「網格運算」服務都搶搭順風車，聲稱他們的服務也屬於「「雲端運算」」。但是，只怕很少人能夠聽明白他們口中的這朵「雲」代表著什麼玄機，以及它究竟要做什麼「運算」。
所謂「雲端」其實就是泛指「網路」，名稱來自工程師在繪製示意圖時，常以一朵雲來代表「網路」。因此，「「雲端運算」」用白話文講就是「網路運算」。舉凡運用網路溝通多台電腦的運算工作，或是透過網路連線取得由遠端主機提供的服務等，都可以算是一種「「雲端運算」」。
所以說，「雲端運算」其實不是新技術，更嚴格的說，甚至不能算是「技術」。「雲端運算」是一種概念，代表的是利用網路使電腦能夠彼此合作或使服務更無遠弗屆。而在實現「概念」的過程中，才會產生出相應的「技術」。
「雲端運算」的概念事實上也不算新，其本質大抵承襲自「分散式運算」(Distributed Computing)以及「「網格運算」」(Grid Computing)這兩位老前輩。在進一步窺探雲中的奧秘之前，先讓我們來認識其源頭。
所謂「分散式運算」，顧名思義，就是將大型工作區分成小塊後，分別交由眾多電腦各自進行運算再彙整結果，以完成單一電腦無力勝任的工作。最著名的例子莫過於 1999年啟動的「SETI@home計畫」。該計畫利用超過500萬名參與者的個人電腦的空閒時間進行分析無線電訊號的運算，以期能找出外星生物。
而「「網格運算」」則是分散式運算加以延伸的一支，其主要特點在於將各種不同平台、不同架構、不同等級的電腦透過分散式運算的方式做整合運用。所謂的「網格」指的則是以公開的基準處理分散各處的資料。
由此觀之，「雲端運算」與「網格運算」並沒有顯著的不同。的確，兩者都是分散式運算的延伸，唯獨「網格運算」著眼於整合眾多異構平台，而「雲端運算」則強調在本地端資源有限的情況下，利用網路取得遠方的運算資源。
問題來了，若說只要是透過網路線接上「雲端」並利用遠端資源就可以稱做「雲端運算」，那麼上Gmail收發信件與利用BitTorrent之類的P2P技術取得資料，豈不都可算是「雲端運算」？但是這兩者在本質上有著明顯的不同，究竟何者才能算是「正港」的「雲端運算」呢？
在「電腦世界」(Computer World)一篇標題為「雲端運算」的過度混淆」( Cloud computing hype spurs confusion) 的文章中，引述了知名分析公司Gartner的分類方式，將「雲端運算」區分為兩大類，分別為「雲端服務」(Cloud Computing Services)與「雲端科技」(Cloud Computing Technologies)。
Gartner 指出，「雲端服務」專注在於藉由網路連線從遠端取得服務。例如提供使用者安裝和使用各種不同作業系統的Amazon EC2服務。這類型的雲端計算可以視為「軟體即服務」(SaaS, Software as a Service)概念的後繼。利用這些服務，使用者甚至可以只靠一支手機做到許多過去只能在個人電腦上完成的工作。
而「雲端科技」則是著眼於利用虛擬化以及自動化等技術來創造和普及電腦中的各種運算資源。Gartner認為，這種類型可以視為傳統資料中心(Data Center)的延伸，且不需要經由第三方提供外部資源便可套用在整個公司的內部系統上。
所以說，根據Gartner的定義，Google所謂的「雲端運算」，包含「iGoogle」、「Google Calendar」等，雖然也有運用到「雲端科技」的部分，但是大抵上其模式則是屬於「雲端服務」的範疇。
不讓Google、Yahoo!等網路公司專美於前，趨勢科技於2008年11月全球首創使用「雲端運算」技術進行防毒。使用者不需要再像過去那樣，將更新過的病毒碼下載到個人電腦中，而是在網路上即時偵測惡意程式。藉由「雲端運算」，使用者便可節省更新病毒碼所需的硬碟空間，而且也能一併解決病毒碼批次更新速度比不上新病毒產生速度的問題。此外，這種更為主動且即時的防禦方式更能夠有效防禦自2007年起大量激增的惡意網頁。
當然，「雲端運算」的威力不僅僅是提供使用者更妥善的服務而已，對企業而言，「雲端運算」能夠有效的降低成本與風險。由於雲端服務不需要將程式安裝在用戶的電腦中，對服務商而言，降低了商業程式邏輯被破解的風險。此外，過去常見到台灣公司必須先將在本地收集的資料傳回美國，經過美國工程師處理後再傳回台灣作業的情況，如此一來則需耗費大量的網路傳輸費用以及時間。利用「雲端運算」，位在世界各地的開發人員便能夠透過同一套平台更即時且密切的合作。 iThome曾引述趨勢科技研究開發部專案經理楊覲寧的看法：「(「雲端運算」)不只是縮短資料傳輸時間，也加快了趨勢開發新產品的速度。」
然而，在熱情擁抱雲彩之前，先讓我們停下來想想在雲深不知處是否有什麼未見的隱憂。首先，將服務集中在雲端上便有「將雞蛋放在同一欄」的風險。比方說，在我用我個人電腦上的WORD程式寫這篇文章的過程中，假設WORD突然無法執行，我只要將文件檔案複製到其他裝有WORD的電腦上就可以繼續完成這篇文章。若我是利用雲端服務商提供的文字處理程式，一旦該供應商暫停服務，我能做的就只剩下潛心祈求我的檔案有被妥善保存並向客服人員抱怨。此外，使用者的行為、習慣、愛好等等，都將隨著雲端服務一同被服務商紀錄下來。換句話說，以往在個人電腦上被使用者視為隱私的部分，將會更直接地暴露在網路之上。
雖然「雲端運算」的發展態勢仍稍嫌模糊混沌，其在「網格運算」和分散式運算間的定位也是妾身未明。但無論如何，整合眾多電腦的資源使之通力合作以完成更龐大的作業，是未來發展的必然趨勢。正如趨勢科技董事長張明正所說：「下一個20年，資安業會怎麼走我不知道，但未來的3、5年，「雲端運算」勢必是重點技術！」
2010年2月3日 星期三
SCORE fulltext search 問題解決經歷
設定CM Library Manager Log Level：
使用 db2 update icmadmin.icmstsyscontrol set tracelevel = –15 SQL指令，可以Log到最多的資訊。取得需要的資訊後，記得將其設為零，才不會造成Log檔爆滿。預設CM Library Manager的Log存在於%CMProgramDir\log\ls\${DB_Name} 下的ICMSERVER.log中
設定 API Call Log Level：
每個要查詢Content Manager的server都會有裝CM Client，因此需到相對應的server上的 %CMProgramDir\cmgmt\connectors目錄下，編輯cmblogconfig.properties設定檔，設定 DKLogPriority = DEBUG。取得需要的Log後，記得將其設為DKLogPriority = ERROR，才不會造成API Log檔爆滿。預設API Call Log會存在 %CMProgramDir\log\connectors 下的 ${User_ID}.dklog.log中
Tables used by SCORE in Content Manager
SCORE系統的所有文件都是屬於 base_document這個 Item Type，Content Manager用 ICMUT01032001表格來儲存每筆Import進來的文件的相關資訊，若需要知道文件的詳細meta-data資訊，需Join ICMUT01028001 這個表格的資訊，以下為sample SQL:
SELECT b.*,a.attr0000001035,a.createts FROM ICMADMIN.ICMUT01028001 a, ICMUT01032001 b where a.itemid = b.itemid order by a.createts desc fetch first 1 rows only
ICMUT00301001 是CM base text 的表格，任何import進Content Manager的 text文件都會在此表格有一相對應的record。