如何設計資料庫的資料元素、指標和指標束

透明化資料庫的設計來促進溝通及應用

〝資料字典〞的角色是將目前資料庫的架構及其內容文件化。資料字典不包含任何實際來自資料庫的資料,僅包含管理的資訊。 字典使終端使用者以這樣的方式溝通要求,資訊程序員能更容易設計相關資料庫或資料結構以符合那些要求。 資料字典常是一本手冊,但從未更新,也因此很少利用。現在資料字典常保存於線上,且主動維護,允許互動式查詢。 有效的資料字典讓使用者能在他們對於例行性的報表有問題時(或醫院評鑑委員詢問時),自己找到答案。

非程式設計師如何牽涉資料字典?

  1. 協助設計,儘可能將資料驗證一併建置入系統。當設計資料庫時,使用者是系統分析師重要的資訊來源。他們協助描述內容、格式及元素間的關係。
  2. 驗證
    利用區隔相關的資料元素,並追蹤錯誤的來源,來調查例行報告中的差異。
  3. 確保即時產出報告 (a) 使用者即時輸入資料 (b) 程式設計師自動化批次處理報告及日誌維護以掌握失敗的事件。
  4. 分析
    回答外部稽核者的問題。
  5. 問與答
    人員或部門以探求問題
  6. 作業辦法書面化
  7. 教育/訓練

資料字典

表格

數據字典是由表組成的數據集 (dataset)。這是由電子資料工作表的格式所組成。 表中的欄代表資料元素 (data element)。行代表其數據屬性(attributes)。每一行列出該欄(元素)的屬性值。

資料元素

資料元素是表中的一欄。 圖一提供表及其元素(欄)的視覺呈現。 舉例來說,資料元素可能向病人姓名、性別、生日、病歷號、診斷碼、血壓等。血壓可測量,病人姓名可以是任何內容;診斷碼及性別可能來自預先決定的特定值。 這些差異表示兩種不同的資料元素類型:

  1. 特定數值的元素:
    這類元素的數值是預先決定的,僅接受可接受的數值(例如:ICD-10-CM 診斷碼、醫院病房代號、受聘於醫院的員工代號)。
  2. 量性數值的元素:
    可以有任何數值的元素。資料字典可提供符合條件的選擇以這些元素的建議值(例如,溫度及血壓的有效範圍)。
圖一、資料庫中,表及其元素(欄)的示意圖

資料屬性

資料屬性是有彈性的─管理者能從系統中動態的增加/排除。最常見的屬性是〝名稱〞,代表所定義對象的名稱。其他屬性如〝定義〞、〝版本〞等。資料屬性有兩種型態:

  1. 簡單屬性
    每個這樣的屬性是名稱/數值配對。例如:〝姓名〞、〝定義〞、〝版本〞是簡單屬性的好例子。在定義一個資料元素時,重要的簡單屬性是:
    • 資料型態
      一般的型態包括內容、數值、日期/時間、列表、參照及獨一無二的辨識欄位。同時也確認是否使用小數點,及可接受的小數位數。
    • 最大長度/最小長度
      資料元素的最大/最小長度是位元或字元。舉例來說,如果一個元素最大長度為4,若有一個值〝hello〞則太長了。或如果一個元素的最小長度為5,若有一個值〝146〞則太短了。
    • 最大值/最小值
      只能用來資料元素是數值的資料型態,且限制元素為數值。若最大值為〝9〞,若有一個值〝9.55〞則表示太大了。
    • 欄位的預設值
    • 完整的限制資訊
      選擇性的/必要的 — 在可以儲存紀錄之前,指出是否屬性是必要的。
    • 決定每個使用者的權限與角色
    • 審核資訊,如誰進入或更改過內容。
    • 其他一般資料庫資訊
    雖然這些是資料字典的核心元素,但是記錄每個元素的額外資訊並不罕見,這些額外資訊可能包括資訊的來源、表或概念所涵蓋的屬性、連結到外部資料庫的定義。
  2. 複雜屬性
    複雜屬性是一系列名稱/數值的組合。每個這樣的組合稱為字段(欄位)。舉例來說,地址包含縣市、鄉鎮及街道。這些字段整合當作複雜屬性元素的每行。這些行所代表的是複雜屬性的值。當定義數據集、表格或元素時,重要的複雜屬性是:
    • 呈遞(設計)機構
      增加或改變資料元素定義的機構。強制明確化所有數據集、表格及元素定義。
    • 認證機構
      有權力註冊資料定義的機構。
表 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 此表最近被更改的日期時間
資訊監視將資料庫上所有活動記錄到名為“日誌文件”的特殊文件來管理。這常是由資料庫中的自動觸發函數所按時管理的。對於非電腦程序使用者,重要的是了解這個『紙跡』,且當進行醫院指標資料庫稽核或驗證時,保證要求依據改變跡象進行檢索。

檢驗室〝刪除〞資料的例子。

  1. 血液檢體被送到檢驗科以測量電解質,包含鉀。 他們使用當時的流程測得 8.5(正常範圍為 3.5~5.5)。檢驗科人員將這個結果呈現在病歷紀錄中。
  2. 醫師一看到這個結果就判斷病人有生命威脅,所以他開立緊急透析的醫囑。
  3. 檢驗科重新監測他們的結果,且隔天,將這個數值以新的數值取代。
  4. 結果:這個醫師被指控為浪費資源,且開立不當的血液透析醫囑危害到病人。

應該的情況危:
檢驗室不應該把原來的報告拿掉,因為其他人看著報告,導致採取行動。檢驗室應該在原來報告上增加註記(如,〝錯誤〞),以避免再度使用,且增加(不是取代)正確的數值。因此,兩個報告的順序可以為醫師的行為平反。
檢驗室應該修正其作業流程,確保檢驗結果經內部驗證後才紀錄於病人病歷中,並修正「更新錯誤」的方法。

 

表 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、資料庫架構圖
圖 2、資料庫架構圖

示意圖說明

  • 矩形形狀指示資料表的實體。
  • 連接資料表線表示兩者之間的關係。單個橫桿裝置強制連接;用圓圈三叉戟是指一個或多個元素是從該資料表參與。

資料驗證

  1. 原始資料收集的資料品質
    單一元素的原始資料應該收集到「資料元素」表,且所有的資料品質屬性應在存入資料庫中及後受到驗證。
  2. 遵循定義條件:指標的驗證(含合成元素)是聚焦於驗證是否遵守定義的納入及排除條件。 指標(含合成元素)並不會獨立收集原始資料。指標公式所有中間的步驟必須被存檔及驗證,以利佐證及稽核。
    • 使用已經驗證的單一元素計算合成元素。
    • 使用已經驗證的資料源溯計算指標(包含單一及指標集/束)。

一旦經過驗證,資料項目應該上鎖以避免更以後更改。

 

表 3、「資料」表的示範欄位(非「資料字典」)
項目 資料表 資料圖型
元素 單一資料元素的歷史值作為數據表。 I型圖、事件間隔管制圖、時間間隔管制圖
指標 單一指標的歷史值作為數據表。 管制圖、同儕比較圖
指標 在特別的時間特別的群體所有指標的值(〝快照〞) 在一個頁面呈現所有指標的迷你趨勢圖
快照實例:
醫策會某一個月收集P4P所有指標數值
醫院評鑑某一個月收集持續性監測所有指標數值
在特定監測封包中的所有指標(流程、結果、抵銷)應在圖形網頁中同時檢視;例如:手術部位感染案包含預防性抗生素(流程)、體溫控制(流程)、剃毛(流程)、部位感染(結果)、員工安全風氣(抵銷指標)。

 

交互式顯示資料字典平台

 

圖 3、某項目(元素或指標)的字典內容(截)

 

圖 4、單個元素(或指標)所有歷史數據。
圖 5、特定時段的指標集("快照")中的所有數值。

 

表 6、以 I-型圖顯示元素狀況
圖 7、g-型間隔圖之間的事件。
圖 8、t-型間隔圖之間的時間。

 

 

圖 9、管制圖用於指標
圖 10、迷你趨勢圖用於鳥瞰指標集史料。

 

圖11、與國家資料庫中的同儕組比較。

 

正規化說明

正規化是在資料庫中組織資料的程序。 其中包括建立資料表,以及在這些資料表之間根據規則建立關聯性,這些規則的設計目的是:透過刪除重複性和不一致的相依性,保護資料並讓資料庫更有彈性。 重複的資料會浪費磁碟空間,並產生維護方面的問題。 如果必須變更現有資料,並且該資料的位置超過一個以上,就必須在所有位置上以完全相同的方式進行變更。 資料庫正規化有一些規則。每條規則都稱為「正規形式」。如果遵守前三條規則,資料庫就被視為屬於「第三正規形式」。 雖然可能會有其他層級的正規形式,但第三正規形式被視為大部分應用程式所需的最高階正規形式。

你應該熟悉這些概念。使用關鍵詞如「數據庫標準化」進行搜索谷歌找其他作家,或許他們可以幫助您更深入的了解以下三個核心層面:

  1. 第一正規形式實際上只是常識。消除重複列,並確保某一列或組合的列標識它。
  2. 第二正規形式包括第一規形式,且更進一步。複數據應被刪除到另一個表中, ,並且解決同一筆資料不一致地輸入的問題。
  3. 第三正規形式包括第二正規形式,且 一個給定的表不應該包含任何信息與主鍵無關。

參考文獻: