如何設計資料庫的資料元素、指標和指標束
透明化資料庫的設計來促進溝通及應用
〝資料字典〞的角色是將目前資料庫的架構及其內容文件化。資料字典不包含任何實際來自資料庫的資料，僅包含管理的資訊。
字典使終端使用者以這樣的方式溝通要求，資訊程序員能更容易設計相關資料庫或資料結構以符合那些要求。
資料字典常是一本手冊，但從未更新，也因此很少利用。現在資料字典常保存於線上，且主動維護，允許互動式查詢。
有效的資料字典讓使用者能在他們對於例行性的報表有問題時（或醫院評鑑委員詢問時），自己找到答案。
非程式設計師如何牽涉資料字典？
-
協助設計，儘可能將資料驗證一併建置入系統。當設計資料庫時，使用者是系統分析師重要的資訊來源。他們協助描述內容、格式及元素間的關係。
-
驗證
利用區隔相關的資料元素，並追蹤錯誤的來源，來調查例行報告中的差異。
-
確保即時產出報告 (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 長度等於１, "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、與國家資料庫中的同儕組比較。
正規化是在資料庫中組織資料的程序。
其中包括建立資料表，以及在這些資料表之間根據規則建立關聯性，這些規則的設計目的是：透過刪除重複性和不一致的相依性，保護資料並讓資料庫更有彈性。
重複的資料會浪費磁碟空間，並產生維護方面的問題。
如果必須變更現有資料，並且該資料的位置超過一個以上，就必須在所有位置上以完全相同的方式進行變更。
資料庫正規化有一些規則。每條規則都稱為「正規形式」。如果遵守前三條規則，資料庫就被視為屬於「第三正規形式」。
雖然可能會有其他層級的正規形式，但第三正規形式被視為大部分應用程式所需的最高階正規形式。
你應該熟悉這些概念。使用關鍵詞如「數據庫標準化」進行搜索谷歌找其他作家，或許他們可以幫助您更深入的了解以下三個核心層面：
-
第一正規形式實際上只是常識。消除重複列，並確保某一列或組合的列標識它。
-
第二正規形式包括第一規形式，且更進一步。複數據應被刪除到另一個表中， ，並且解決同一筆資料不一致地輸入的問題。
-
第三正規形式包括第二正規形式，且 一個給定的表不應該包含任何信息與主鍵無關。