如何設計資料庫的資料元素、指標和指標束
透明化資料庫的設計來促進溝通及應用
〝資料字典〞的角色是將目前資料庫的架構及其內容文件化。資料字典不包含任何實際來自資料庫的資料,僅包含管理的資訊。
字典使終端使用者以這樣的方式溝通要求,資訊程序員能更容易設計相關資料庫或資料結構以符合那些要求。
資料字典常是一本手冊,但從未更新,也因此很少利用。現在資料字典常保存於線上,且主動維護,允許互動式查詢。
有效的資料字典讓使用者能在他們對於例行性的報表有問題時(或醫院評鑑委員詢問時),自己找到答案。
非程式設計師如何牽涉資料字典?
-
協助設計,儘可能將資料驗證一併建置入系統。當設計資料庫時,使用者是系統分析師重要的資訊來源。他們協助描述內容、格式及元素間的關係。
-
驗證
利用區隔相關的資料元素,並追蹤錯誤的來源,來調查例行報告中的差異。
-
確保即時產出報告 (a) 使用者即時輸入資料 (b) 程式設計師自動化批次處理報告及日誌維護以掌握失敗的事件。
-
分析
回答外部稽核者的問題。
-
問與答
人員或部門以探求問題
-
作業辦法書面化
-
教育/訓練
表格
數據字典是由表組成的數據集 (dataset)。這是由電子資料工作表的格式所組成。
表中的欄代表資料元素 (data element)。行代表其數據屬性(attributes)。每一行列出該欄(元素)的屬性值。
資料元素
資料元素是表中的一欄。
圖一提供表及其元素(欄)的視覺呈現。
舉例來說,資料元素可能向病人姓名、性別、生日、病歷號、診斷碼、血壓等。血壓可測量,病人姓名可以是任何內容;診斷碼及性別可能來自預先決定的特定值。
這些差異表示兩種不同的資料元素類型:
-
特定數值的元素:
這類元素的數值是預先決定的,僅接受可接受的數值(例如:ICD-10-CM 診斷碼、醫院病房代號、受聘於醫院的員工代號)。
-
量性數值的元素:
可以有任何數值的元素。資料字典可提供符合條件的選擇以這些元素的建議值(例如,溫度及血壓的有效範圍)。
圖一、資料庫中,表及其元素(欄)的示意圖
資料屬性
資料屬性是有彈性的─管理者能從系統中動態的增加/排除。最常見的屬性是〝名稱〞,代表所定義對象的名稱。其他屬性如〝定義〞、〝版本〞等。資料屬性有兩種型態:
-
簡單屬性
每個這樣的屬性是名稱/數值配對。例如:〝姓名〞、〝定義〞、〝版本〞是簡單屬性的好例子。在定義一個資料元素時,重要的簡單屬性是:
-
資料型態
一般的型態包括內容、數值、日期/時間、列表、參照及獨一無二的辨識欄位。同時也確認是否使用小數點,及可接受的小數位數。
-
最大長度/最小長度
資料元素的最大/最小長度是位元或字元。舉例來說,如果一個元素最大長度為4,若有一個值〝hello〞則太長了。或如果一個元素的最小長度為5,若有一個值〝146〞則太短了。
-
最大值/最小值
只能用來資料元素是數值的資料型態,且限制元素為數值。若最大值為〝9〞,若有一個值〝9.55〞則表示太大了。
-
欄位的預設值
-
完整的限制資訊
選擇性的/必要的 — 在可以儲存紀錄之前,指出是否屬性是必要的。
-
決定每個使用者的權限與角色
-
審核資訊,如誰進入或更改過內容。
-
其他一般資料庫資訊
雖然這些是資料字典的核心元素,但是記錄每個元素的額外資訊並不罕見,這些額外資訊可能包括資訊的來源、表或概念所涵蓋的屬性、連結到外部資料庫的定義。
-
複雜屬性
複雜屬性是一系列名稱/數值的組合。每個這樣的組合稱為字段(欄位)。舉例來說,地址包含縣市、鄉鎮及街道。這些字段整合當作複雜屬性元素的每行。這些行所代表的是複雜屬性的值。當定義數據集、表格或元素時,重要的複雜屬性是:
-
呈遞(設計)機構
增加或改變資料元素定義的機構。強制明確化所有數據集、表格及元素定義。
-
認證機構
有權力註冊資料定義的機構。
表 1、資料字典「資料元素」表的示範欄位
項目ID |
項目名稱 |
資料類型 |
數值精度 |
欄位長短 |
預設值 |
註解 |
主鍵
|
{項目}_ID
|
主鍵
|
INTEGER |
Y |
LONG |
NOT NULL |
自動序列號
|
最好的方法是利用系統產生自動序號,以確保有獨一無二的主鍵。
不用利用主鍵進行編碼,因為後續會造成難以修正錯誤,例如,大陸的身份證號碼包含生日、性別、居住地及其他部分,共18位元。如果原始資料輸入錯誤,就無法進行修正,或如果他們被修正了,會造成持續監測失敗的問題,例如,身分證字號又被當作醫療照護持續性的佐證。
在醫界,不要在主鍵中使用縮寫呈現諸如職業的數據(如:在員工代號中,以〝N〞表示〝護理人員〞,如〝N12345〞)。這類資訊在資料元素中應個別儲存,以利於更新改變。類似的,以縮寫來定義資料來源,如〝I〞代表〝住院〞、〝O〞代表〝門診〞、〝E〞代表〝急診〞、或〝M〞代表〝總院〞、〝B〞代表〝分院〞,這些不應該當作主鍵的一部分,但在資料元素中是獨立的欄位。
有些主鍵是幾個欄位的合成,例如,〝病歷號〞識別病人,但必須〝病歷號+入院日期時間〞的組合用來分別病人每次入院的事件。這個整合的欄位可以當作主鍵,或系統同上自動產生序號為主鍵,且〝病歷號+入院日期時間〞的組合是個替代主鍵,適用於快速資料檢索索引。
在品質改善方面,主鍵常整合〝元素 ID〞及〝收集期間〞。若果是一個基於月報的監視系統,這使用〝元素 ID+西元年月〞為主鍵以分別時間序列的個別資料。
如果資料庫用於跨醫院(和分院),但是具有集中的資訊系統框架,則必須做出關於結構的決定: • 每個醫院都設有自己的、獨立的資料庫(但每個數據集包含相同的表) • 或,來自所有醫院的資料彙總在單個資料庫中,但是每個表將需要另一個欄位作為主鍵的一部分,以識別醫院之間相同的數據元素。
|
核心數據屬性節
|
ITEM_NAME |
{項目名稱}
|
VARCHAR2 |
- |
{取決於情況}
|
NOT NULL |
{多種語言}
|
這個欄位需要呈現在報告中。
他也許需要擴大到多個欄位,表的欄位的標題使用短的項目名稱(如:〝間隔〞),且完整的內容呈現在報告中(如,〝住院病人跌倒間隔天數〞)。
在一家醫院的單一資料庫中,欄位能以當地語言的屬性命名(如:〝病歷〞)。
然而,在推動〝國際醫療〞的醫院,有需要呈現超過一種語言;即使在台灣,雖然當地使用繁體中文,但為了大陸〝顧客〞,也需要簡體中文(病人及受訓學員)。
如果需要多種語言,屬性應連結到具有 {ITEM_ID + LANGUAGE_REQUIRED} 主鍵的個別對照表,且欄位像 SHORT_NAME 及 FULL_NAME 須以目的語言呈現。
|
DESCRIPTION |
{項目說明}
|
VARCHAR2 |
- |
{取決於情況}
|
NOT NULL |
此項目的意向
|
解釋為何這個項目是需要的。個別的欄位也許用來連結負責設計的外部來源(例如:台灣醫策會及P4P指標)。
|
DATATYPE |
- |
- |
- |
- |
|
{取決於情況}
|
將資料型態(字串、數值、邏輯、日期時間等)及啟動條件建置入資料庫中(ORACLE, INFORMIX, SQLSERVER, MYSQL etc)以執行在資料輸入時的資料驗證,避免存入無效的資料,並當輸入者輸入有問題的資料時立即警示。特別的是,避免使用日期(如,〝年=[中華民國] 105〞取代〝年=2016〞,否則就能存無效的月份及日期,並造成後續計算上的錯誤。在〝資料品質〞的網頁可了解更多。 →
資料品質屬性
|
資料收集條件節
|
CRITERIA |
收集條件
|
VARCHAR2 |
- |
{盡長}
|
|
數據收集條件
|
EXCLUDE |
排除條件
|
VARCHAR2 |
- |
{盡長}
|
|
數據排除條件
|
DEFAULTS |
預設值
|
VARCHAR2 |
- |
- |
{取決於情況}
|
預設值
|
資料收集:前端(客戶端)節
|
FRONT_DEPT |
前段負責部門
|
INTEGER |
0 |
LONG |
- |
前段負責部門代號
|
WHEN_START |
有效日期
|
DATETIME |
- |
- |
- |
開始收集資料的日期
|
WHEN_COLLECT |
資料收集日期
|
INTEGER |
0 |
2 |
- |
開始收集資料的日期
|
資料收集:後端(伺服器)節
|
BACK_DEPT |
後段負責人
|
INTEGER |
0 |
LONG |
- |
後段負責資訊人員
|
WHEN_BATCH |
批次完成
|
INTEGER |
0 |
2 |
- |
批次處理程序完成的日期
|
資料收集的後端(伺服器)仰賴自動化。負責批次處理程序的資訊人員必須監測運行程序是否成功或失敗。若有失敗的狀況,系統應該重試幾次,若仍然無法成功,應該通知相關的人員。
主要的對象應該通知資訊人員,但依醫院的狀況,品管中心也許也應該被通知。這有助於他們在進行資料驗證時調查所缺的資料。
為了避免日常幕後程式影響到臨床工作,這些指令應該以預存程序(封包、程序、函數功能)及預存程序反覆執行的時間管理器,已確保在非尖峰時段順暢的運作。不必仰賴每次資訊人員手工執行程序。這會造成執行上的失物、不即時及資料變異的問題。
|
資料分析節
|
STATISTICS |
統計需求
|
VARCHAR2 |
- |
- |
- |
統計需求說明
|
CHARTING |
製圖
|
VARCHAR2 |
- |
- |
- |
適當的圖表
|
PEER_GROUP |
同儕比較
|
VARCHAR2 |
- |
- |
- |
同儕比較說明
|
TARGET |
目標值
|
DOUBLE |
- |
- |
- |
今年的目標值
|
統計也許需要驗證資料的可靠性; 例如,極端值可能代表資料錯誤,Krippendorff 在不同觀察者間變異的評估,或滿意度調查結果的信賴區間。
這個欄位應該也解釋需要什麼資料分析(例如,決定是否資料為常態分配)以及該進行什麼檢測才適當,如管制圖。應該明確屬性是〝罕見事件〞,以及相對應的適當的統計分析。
如果有相關全國或國際資料進行同儕比較,應該在這裡指出,且指出哪個次群組有適合比較的同儕資料。
一個可選的欄位,但常被醫院評鑑委員所要求,是〝目標值〞。這應該年度檢視,且呈現在資料分析圖上。
|
行政節
|
DELETE_FLAG |
作廢標誌
|
BOOLEAN |
- |
1 |
NULL |
TRUE=刪除此項目
|
為了符合醫療法律規定,應嚴格的保護作業紀錄,所謂的『紙跡』。所以,一般而言,資料庫項目需要〝刪除〞的時候,並不是實際從資料庫移除,而是標記為該項目已不再使用。然而,仍然可以透過稽核及資料驗證找得到。
檢驗室〝刪除〞資料的例子。
此欄位的資料類型是邏輯標記〝BOOLEAN〞(TRUE代表刪除),但隨者醫院安裝的資料庫軟體可能使用不同類型。這也許需要編為〝字串〞(VARCHAR2 長度等於1, "Y"代表刪除)或〝數字〞 (整數的長度等於1,〝1〞代表刪除)。
|
WHO_CHANGE |
異動人員
|
VARCHAR2 |
- |
10 |
NOT NULL |
最近更改此表的人
|
WHEN_CHANGE |
異動時間
|
DATETIME |
- |
7 |
SYSDATE |
此表最近被更改的日期時間
|
資訊監視將資料庫上所有活動記錄到名為“日誌文件”的特殊文件來管理。這常是由資料庫中的自動觸發函數所按時管理的。對於非電腦程序使用者,重要的是了解這個『紙跡』,且當進行醫院指標資料庫稽核或驗證時,保證要求依據改變跡象進行檢索。
|
檢驗室〝刪除〞資料的例子。
-
血液檢體被送到檢驗科以測量電解質,包含鉀。 他們使用當時的流程測得 8.5(正常範圍為 3.5~5.5)。檢驗科人員將這個結果呈現在病歷紀錄中。
-
醫師一看到這個結果就判斷病人有生命威脅,所以他開立緊急透析的醫囑。
-
檢驗科重新監測他們的結果,且隔天,將這個數值以新的數值取代。
-
結果:這個醫師被指控為浪費資源,且開立不當的血液透析醫囑危害到病人。
應該的情況危:
檢驗室不應該把原來的報告拿掉,因為其他人看著報告,導致採取行動。檢驗室應該在原來報告上增加註記(如,〝錯誤〞),以避免再度使用,且增加(不是取代)正確的數值。因此,兩個報告的順序可以為醫師的行為平反。
檢驗室應該修正其作業流程,確保檢驗結果經內部驗證後才紀錄於病人病歷中,並修正「更新錯誤」的方法。
表 2、資料字典「資料指標」表的示範欄位
項目ID |
項目名稱 |
資料類型 |
數值精度 |
欄位長短 |
預設值 |
註解 |
主鍵
|
QI-SERIES |
指標系列
|
VARCHAR2 |
- |
- |
- |
指標系列縮寫
|
QI-ITEM |
指標編號
|
VARCHAR2 |
- |
- |
- |
單項指標編碼
|
指標系統通常不要求自動產生序號做為主鍵。合成主鍵由指標系列的名稱 (QI-SERIES) 及系列中的個別指標 (QI-ITEM-KEY)所組成。
|
核心數據屬性節
|
NAME |
指標名稱
|
VARCHAR2 |
- |
- |
- |
指標名稱
|
QIDESC |
指標意向
|
VARCHAR2 |
- |
- |
- |
指標理由說明
|
HI_LO_GOAL |
目標
|
VARCHAR2 |
- |
- |
- |
指標目標值
|
IND_TYP |
類型
|
VARCHAR2 |
- |
- |
- |
指標類型
|
LIST_SEQ |
序列
|
VARCHAR2 |
- |
- |
- |
顯示列表中的位置
|
HI_LO_GOAL 指出指標改善的方向,是增加是改善的徵兆或降低。指標類形是「結構」、「過程」、或「結果」之一,但也需也被分類為「計數」(沒有分母)或「抵銷」指標(監測同步改變的相關指標)。抵銷指標 (balancing measures) 也非正式的稱為「翹翹板」指標。
|
資料收集條件節
|
VERSION |
版本
|
VARCHAR2 |
- |
- |
- |
指標系列版本
|
CRITERIA |
收集條件
|
VARCHAR2 |
- |
- |
- |
數據收集條件
|
EXCLUDE |
排除條件
|
VARCHAR2 |
- |
- |
- |
數據排除條件
|
FORMULA |
計算公式
|
VARCHAR2 |
- |
- |
- |
指標計算公式
|
DENOMINATOR |
分母
|
VARCHAR2 |
- |
- |
- |
指標分母計數
|
NUMERATOR |
分子
|
VARCHAR2 |
- |
- |
- |
{元素或指標}分子計數
|
UNIT |
指標單位
|
VARCHAR2 |
- |
- |
- |
指標計算的單位如‰
|
DECIMAL |
小數後位數
|
VARCHAR2 |
- |
- |
- |
小數後位數
|
資料收集:前端(客戶端)節
|
資料收集:後端(伺服器)節
|
資料分析節
|
行政節
|
上面的四個部分在這裡被省略,但是與[資料元素]表相同,並且也應該是[資料指標]表的一部分。
|
持有數據的表模板
這些表並不是「資料字典」的一部分,但適當的連結到,以檢查及確認定義及資料收集、驗證、分析的流程。
表 3、「資料」表的示範欄位(非「資料字典」)
項目ID |
項目名稱 |
資料類型 |
數值精度 |
欄位長短 |
預設值 |
註解 |
主鍵
|
{item}ID |
{項目}主鍵
|
INTEGER |
0 |
Long |
NOT NULL |
{元素或指標}主鍵
|
PERIOD |
收集期
|
DATETIME |
- |
7 |
NOT NULL |
收集/報告的時段期
|
為了識別每個時段收集的資料,(非字典)的數據表主鍵為合成主鍵,從項目(元素或指標)主鍵和收集期間(通常每月)的組合創建。兩個重點於下方說明:
•
即使收集期間以字串的方式呈現在報告中,如〝YYYY-MM〞,資料型態應該是 DATETIME (日期和時間組合在單個數據欄位中)以利資料庫內定的驗證函數控制數據是否允許儲存(避免輸入無效日期,且促進聚合時間間隔統計,如季、半年、及整年)。
•
即使可以在產出報告時動態的計算結果,但也不應該動態的進行:(a)因為會造成程序緩慢,並影響其他系統使用者(尤其是門診及急診室)(b)中間結果需要儲存在資料庫中以用於驗證、穩定性(一致性)和透明化。
如果結果動態產生,不同的時期也許會產生不同的結果。因為中間的結果並未被儲存,會造成無法驗證資料或分析變異發生的原因。
|
Collected Data
|
NUMERATOR |
分子
|
INTEGER |
0 |
Long |
- |
{元素或指標}分子計數
|
DENOMINATOR |
分母
|
INTEGER |
0 |
Long |
- |
指標分母計數
|
CALCVALUE |
計算值
|
FLOAT |
2 |
Decimal |
- |
分子除以分母的計算值
|
在「元素」表中,不需要〝分母〞及〝運算值〞欄位。在「指標」表中,〝運算值〞在按資料字典定義的轉換為〝分子〞除以〝分母〞再乘以適當的因子(如 100 為百分比或 1000 為千分比)。這是因為大多數的醫療品質指標為計數的(當然,更複雜的指標涉及到時間及日期將有不同的資料型態)。即使傳統的數據庫設計將動態地計算數值,但對於醫院的作業,它必須被計算、儲存、驗證及保留以避免以後更改。
|
圖 2、資料庫架構圖
示意圖說明
-
矩形形狀指示資料表的實體。
-
連接資料表線表示兩者之間的關係。單個橫桿裝置強制連接;用圓圈三叉戟是指一個或多個元素是從該資料表參與。
資料驗證
-
原始資料收集的資料品質
單一元素的原始資料應該收集到「資料元素」表,且所有的資料品質屬性應在存入資料庫中及後受到驗證。
-
遵循定義條件:指標的驗證(含合成元素)是聚焦於驗證是否遵守定義的納入及排除條件。 指標(含合成元素)並不會獨立收集原始資料。指標公式所有中間的步驟必須被存檔及驗證,以利佐證及稽核。
-
使用已經驗證的單一元素計算合成元素。
-
使用已經驗證的資料源溯計算指標(包含單一及指標集/束)。
一旦經過驗證,資料項目應該上鎖以避免更以後更改。
表 3、「資料」表的示範欄位(非「資料字典」)
項目 |
資料表 |
資料圖型 |
元素
|
單一資料元素的歷史值作為數據表。
|
I型圖、事件間隔管制圖、時間間隔管制圖
|
指標
|
單一指標的歷史值作為數據表。
|
管制圖、同儕比較圖
|
指標
|
在特別的時間特別的群體所有指標的值(〝快照〞)
|
在一個頁面呈現所有指標的迷你趨勢圖
|
快照實例:
•
醫策會某一個月收集P4P所有指標數值
•
醫院評鑑某一個月收集持續性監測所有指標數值
•
在特定監測封包中的所有指標(流程、結果、抵銷)應在圖形網頁中同時檢視;例如:手術部位感染案包含預防性抗生素(流程)、體溫控制(流程)、剃毛(流程)、部位感染(結果)、員工安全風氣(抵銷指標)。
|
圖 3、某項目(元素或指標)的字典內容(截)
圖 4、單個元素(或指標)所有歷史數據。
圖 5、特定時段的指標集("快照")中的所有數值。
表 6、以 I-型圖顯示元素狀況
圖 8、t-型間隔圖之間的時間。
圖 9、管制圖用於指標
圖 10、迷你趨勢圖用於鳥瞰指標集史料。
圖11、與國家資料庫中的同儕組比較。
正規化是在資料庫中組織資料的程序。
其中包括建立資料表,以及在這些資料表之間根據規則建立關聯性,這些規則的設計目的是:透過刪除重複性和不一致的相依性,保護資料並讓資料庫更有彈性。
重複的資料會浪費磁碟空間,並產生維護方面的問題。
如果必須變更現有資料,並且該資料的位置超過一個以上,就必須在所有位置上以完全相同的方式進行變更。
資料庫正規化有一些規則。每條規則都稱為「正規形式」。如果遵守前三條規則,資料庫就被視為屬於「第三正規形式」。
雖然可能會有其他層級的正規形式,但第三正規形式被視為大部分應用程式所需的最高階正規形式。
你應該熟悉這些概念。使用關鍵詞如「數據庫標準化」進行搜索谷歌找其他作家,或許他們可以幫助您更深入的了解以下三個核心層面:
-
第一正規形式實際上只是常識。消除重複列,並確保某一列或組合的列標識它。
-
第二正規形式包括第一規形式,且更進一步。複數據應被刪除到另一個表中, ,並且解決同一筆資料不一致地輸入的問題。
-
第三正規形式包括第二正規形式,且 一個給定的表不應該包含任何信息與主鍵無關。