為何要電子病歷 - 從資訊系統設計的角度

之前已經有提到Content與Context的差異性。接著從資訊系統設計的角度來看看，為什麼HIS不能算是電子病歷系統。就從下列這張圖開始說起吧。

左上角指的是Context與Content的差異。那是資料與資料結構的關係。
我們設計資訊系統當然不可能提供這樣子的表格給使用者使用。而是設計成User Friendly的介面給使用者。這個才是資訊系統的價值。
問題來了，一直說，電子病歷不是資訊系統，雖然他們都使用著相同的資料來源。抱歉，我必須不斷地強調再強調，也許我的觀念有人還是不能接受，這不就是我一直寫的理由嗎？哈～岔題了。
右上角這個是資訊系統介面。注意，其實他是由field加label之組合。標籤指引你，引發你的知識，知道要填什麼資料。但認知可能有差異，所以在資訊系統設計時，常常會有欄位檢核，來規範你應該輸入的內容。
例如日期類資訊來說，看到量測日期這個很直覺，就是執行此次臨床作業的日期。但是，資料是單純的，你不可能一下子存民國年，一下子又是西元年，電腦會瘋掉的。所以，我們有時候會提供Tip說，請輸入西元年，或者在輸入欄位上動檢核手腳。
問題大條來了。
有一些具備有Ontology（賣弄一下，我也不太懂，但很多人喜歡用）性質的欄位，這時候，不是單純一個數值或文字就可以解決的事情。簡單地說，是數學呢，還是物理呢？喔～當然是物理的問題，是需要帶單位的。
這下子就慘了。因為單位的不同，數值可能就會有差異。這時候，資訊系統的使用者介面是不是應該詳細說明這個欄位是什麼單位，這樣子使用者才能夠把正確的數值填上。
這下子又好玩了。如果，同一個資料來源，有兩個使用至介面，卻又由兩個不同的人開發。如果是先沒有講好，以血壓為例，一個喜歡用cmHg，一個喜歡mmHg，那在資料表的資料就會變成左方的結果。然後，套到不同介面時，發現這根本不是人的血壓了。

電子病歷能這樣子嗎？電子病歷是一個Result不是一個Process（真的！期望大家能接受呀）。頂多能夠作為串接Process的媒介。
一份完整的電子病歷絕對不會只對應於一個使用者介面。資訊系統的一個使用者介面，往往僅是一個事件的資料收集。而電子病歷是這個Process下的每一個事件所收集資料的整合。所有的人、時、地、事、物通通要明確表達之。所謂資料，不是單單只有數字或文字，該讓人一讀（或由電腦一讀）就能夠明白其意，要達到所見即所得之境界。（抱歉，與WYSWYG不太一樣啦)。

為何要電子病歷 - 資訊化過程差異

電子病歷並不是資訊系統，他是電子病歷系統所處理的對象。就像微軟的Word，他是應用程式，他處理的對象是Word檔。
因為，他不是資訊系統，所以除了強調呈現格式(人所看見之表象)之外，更要讓資訊呈現（人所理解之內涵）能夠保持一致性。
可惜，往往在資訊化過程中開始發生差異性。也就是說，從紙本轉換成電子的過程中，許多的資訊有可能會遺失，或者為了某些目的而增加非核心資訊。

上圖是一般資訊系統分析與設計會面臨的問題。

在資訊化的過程中，當然是為了解決真實世界中的需求（創新）或問題（改善）。

為了讓過程能夠順利，我們都喜歡採文件化過程。也就是把分析現況、確認需求等資訊寫成需求書。

需求書還是以一般人（終端使用者）所能理解的方式編寫。當然，其中有許多描述可能就會輕描淡寫（基本常識），有時候會比較抽象一點。

為了能夠讓系統發展者或者程式設計師能夠了解未來開發的系統應該如何進行，一般都會採用規格書來表達。程式設計師就可依此開始編寫程式碼。也正式進到電腦世界裡，開始由電腦來提供服務了。此時又回到終端使用者，由他們來操作系統。

中間的差異，到底是什麼呢？舉個例子吧。

我們玩撲克牌大老二時，在真實世界中我們關心的是輸贏問題。可是，電腦的世界他是計算的功能，他只能比大小。

但是，就大老二的規則而言，黑桃2卻是最大，紅心2是次大。這個叫規則，也就是規格書的內容。當程式設計時，就是得依據這個規則編寫判斷式。然後依據所收集到的資料，配合前項規則，就可以開始比大小，然後告知誰輸誰贏。

這時候，發生了一個問題：資料與規則是分開的。

也就是說，光有資料沒有意義，光有規則也無從比較。

所以，我們就開始想了，如果資料本身就帶有規則，能夠自我描述的話，也許就可以解決一些問題吧。

事實上，也沒有我們想像中這麼簡單地。