最近醫療AI非常火熱，每家醫院紛紛的在研究醫療應用的人工智慧（Medical AI），而大部分的資料都是取擷於醫院的HIS資料，來進行資料訓練及研究分析。
但目前卻遇到一些瓶頸，因為HIS資料庫中有太多非結構化的資料、資料不齊全或者資料錯誤、醫療專用術語沒有編碼機制，同樣的病灶所描述方式各有不同，就算有些醫院有編碼機制，但各科卻有自己的編碼原則沒有統一，那就更不用說醫院與醫院之間的交換，在蒐集跨院區的病歷資料進行人工智慧資料訓練是一大挑戰，必須花費很多人力及時間去處理資料清洗（Data Cleaning）的前處理作業，導致人工智慧發展速度受到阻礙前進不了，更慘的是若是訓練的資料未能清洗乾淨，就會淪為「Garbage in, garbage out」的情況，而提供出錯誤的臨床決策建議。
[ 下載 2020-21 CIO大調查報告，掌握最新企業IT導入趨勢 ]
為了避免費時費力又徒勞無功，我們必須在第一時間做好資料結構化與標準格式化，以及訂定資料編碼原則，或者遵循一些國際編碼原則，才能讓HIS的資料變成資訊，進而變成有用知識，再昇華為智慧結晶。
醫療資料交換格式標準
談到醫療的標準格式不得不想起HL7健康資訊交換標準協會，最近幾年HL7協會發表了快速健康照護互通資源（FHIR）的國際標準。HL7在2.x的時候，強調的是區段（Segment），是透過不同意義的內容構成的消息（Message）來做傳遞，也就是說不同的系統可以透過HL7的消息互相來做溝通，這是2.x所表述的標準功能。
HL7到3.x的時候，它所強調的是文檔的概念，如台灣的電子病歷，就是遵循HL7的CDA R2架構，屬於文檔的架構。這個文檔是用XML來編排成CDA R2規範，再使用醫事人員卡（HCA）做電子簽章，形成不可否認的電子病歷。
但HL7版本3.x跟2.x都存在著一些問題，因為文檔架構太過於複雜，要形成文檔時，要規劃很多的資料。所以HL7才會發展FHIR新型醫療資訊標準。FHIR不再把資料單純用文檔來看待，裡面的資料可以分解很多的資料元素（Data Elements）與資料格式（Data Format），FHIR是一個定義跟整合資源的標準，同時也利用了很多新的網路標準，致力於整個系統建置應用，比起其他替代品更可以減少整個花費，所以是未來的醫療資訊交換標準的方向。
FHIR的資料格式則是採用NoSQL方式，它不是只有JSON，XML也都沒有問題，有這兩種資料格式的加持，等於是如虎添翼。再來就是FHIR也使用RESTful API，可以把2.x的消息交換功能，透過RESTful標準的API做資訊交換，所以可以更容易實作跟上手，可讀性還很高。
整個FHIR的初衷，本來是希望相容於不同的儀器設備，以JSON來說是首選，因為它是比較輕量級的交換格式。它可以用文字，也可以適用於各種程式語言，有高相容性，輕量化以及格式易於解讀的概念，整個維護跟傳輸優於XML格式。
衛福部目前也正在推廣FHIR標準來做API的核心架構，讓離島在地醫療機構、空中轉診審核中心、責任後送醫院，都能在資料透明且即時同步的前提下，讓三方醫師共享決策，也讓病人家屬能多方參與，進而提高醫病信任關係，建立更佳化的空中轉診後送機制。
[CIO都在讀： 醫療業關鍵基礎設施資安進入落實階段 ]
但FHIR資源的成熟度分六級，0是為草稿（Draft）最低，5是成熟度最高的規範（Normative）階段被視為最穩定的資源，根據HL7的官網所提供的資源，達到成熟度5的資源只占9%，如果日後要走FHIR，我的建議是，如果是FHIR有到成熟度5的，建議直接引用，就像病人的資源Patient，可以直接引用，但是對於尚未成熟，或者是它的資源型態（Resource Type）根本不符合台灣的習慣，建議不如我們自行定義資源型態，但是為了要確保可以與國際接軌，我們要遵循FHIR資源元素（Resource Elements）來制定。
資源元素的資料型態大概分成四類：
- 簡單/原始型態（Simple/Primitive Types），就有點像資料庫裡面有數字、字串、日期這種簡單的類型；
- 通用複合型態（General-purpose Types），就是說可能把一些常用的變成一個物件或者一個Element的概念；
- 元資料型態（Metadata Types），就是元資料的資源在一起組成一個類型；
- 特殊用途的資料型態（Special Purpose Data Types），可能在某一種特殊地方要用的一個特殊類別，我們可以透過這四種類型的資料型態，我們自己來定義，符合我們台灣本土化的一個資源型態。
如果以我們自己來設計，可能只會設計這個代碼的資料型態為string，這是非常不嚴謹，如果是以FHIR來講，會建議要去定義一個比較通用複雜類型，比如定義為Coding。這個Coding的資料型態，包括編訂代碼的系統機構（system）、版本（version）、代碼（code）以及顯示（display）等等。就以台灣的身份證號碼來說，其編碼規則為內政部發行的，則系統機構就會記錄為內政部機構代碼。這個代碼還有一個版次，這代碼是屬於哪一個版本的，這個才是真正記錄代碼的碼，如果說我們自己設計的，若只留一個string，所以這個是誰定的，什麼時候的版次，你都沒辦法知道。再來是顯示，就是指這個代碼秀出來的名稱是什麼，我們日後自己定的，我們就不要只定義string，而是遵循FHIR的資源元素來訂定。
一旦基本資料的型態是遵循資源元素的型態，假設FHIR的資源型態已經成熟了，比如說它的看診紀錄假設總共有50個欄位，一樣會透過資料類型定出很多的資源元素，台灣可能會制定自己的看診資源型態，要做國際交換時，只要把資源元素（Resource Elements）直接抓出來，就可以變成一個國際標準的資源型態（Resource Type）即可。如果剛開始沒有這樣做，只是定一個string，要轉成FHIR國際標準之前，就要做架構的轉換，這樣子就會很辛苦，因為要做二次工，所以應該是要遵循FHIR的資源元素基本型態，再自行去定義符合本土化資源型態。
不管在國際上還是台灣，FHIR都是未來發展的趨勢，只是整體FHIR仍未完全成熟，且與台灣就醫流程習慣不同，我們無法完全參照FHIR給予的資源，只能參考部分資源與遵循標準以訂定我們的資源模型，進而將FHIR的標準本土化，以建立適合台灣醫院資訊系統的資源模型。
醫療術語國際化標準編碼
在美國電子病歷系統發展的宗旨，是對臨床治療服務和計費支援外，更期望促進醫療服務品質和便利性、提升醫療診斷的精確性和醫療效果、增強醫療協作機制和病人的參與機制、降低醫療費用，最終提升民眾整體的健康狀況。
對於醫學專用術語的編碼標準化和電子化起著十分重要的作用。有些時侯在不同的醫師和衛生機構，指同一事務時，往往會採用不同的臨床術語。例如，對於心臟病學專科醫師來說，心臟病發作、心肌梗塞以及MI可能都是同一含義，但對電腦而言，三者之間則全然不同。因此，不同的醫院、健保機構、研究人員以及其他相關單位之間，需要有協調一致性的電子病歷交換機制。
[ 加入 CIO Taiwan 官方LINE，與全球CIO同步獲取精華見解 ]
因此，在推廣電子病歷與醫療資訊系統之間的交互操作性的提升，對於醫療術語標準的應用具有舉足輕重的作用。近年來歐美先進國家均投入鉅資發展。然而在臨床醫療辭彙標準中，最受各國青睞及普遍受台灣醫院採用的國際醫療術語編碼標準，有下列幾種：
- ICD（International Classification of Diseases）為國際疾病分類是世界衛生組織依據疾病的某些徵兆、症狀、異常、不適、社會環境與外傷，按照規則將疾病分門別類，並用編碼的方法來分類。
- DRG （Diagnosis Related Groups）是其主要的目的是降低醫療費用，改進醫療品質和降低醫療資源浪費，透過疾病診斷、手術或處置、年齡、性別、有無合併症或併發症及出院狀況等條件，將其分成不同的群組，同時考量各群組醫療資源使用之情形，於事前訂定各群組之給付價格。
- ACT（ Anatomical Therapeutic Chemical）為藥品的解剖學、治療學及化學分類系統，是世界衛生組織對藥品的官方分類系統。ATC的首寫字母是A代表解剖，即藥品作用的機體器官系統；T代表治療，即藥品的治療作用；C代表化學品，即其化學類。
- LOINC（Logical Observation Identifiers Names and Codes）是一個描述檢驗結果的標準，它提供了臨床檢驗結果的描述方式，定義了臨床檢驗結果的描述方式，並且提供一套獨一的唯一的編碼。
- SNOMED CT （Systematic Nomenclature of Medicine-Clioical Term）為臨床醫學術語系統，提供了一套全面統一的醫學術語系統，涵蓋大多數方面的臨床信息，如疾病、所見、操作、微生物、藥物等，可以協調一致地在不同的學科、專業和照護地點之間實現對於臨床數據的標引、存儲、檢索和聚合，便於計算機處理。同時，它還有助於組織病歷內容，減少臨床照護和科學研究工作中資料採集、編碼及使用方式的變異。
有了標準化的醫療術語或詞彙可以讓醫護人員之間相互溝通易懂，且可以具體清楚地描述醫療照護過程的術語或詞句，且讓不同國家地區、機構或科別的醫護人員，易於瞭解及溝通病人照護過程中所描述的觀察、問題、處置及成效之外，也可以有助於未來智慧醫療的發展，讓電子病歷具有系統性、標準互通性，能與其他醫療機構交換電子病歷資料，以達到知識管理與實證研究分析之目的。
統整HIS與EMR為一個資料庫
為何HIS與EMR的資料要個自儲存？因為目前HIS大部分是關聯式資料庫，以表格（Table）的方式儲存，就是把原本使用者所撰打的資料，再透過正規化方式，將資料打散到各個表格中儲存到HIS資料庫，已經失去原來使用者所撰打的樣貌。另外，若要在關聯式資料庫中，再做到電子簽章，以達到電子病歷不可否認性那就更難，更不用說日後還要JOIN好幾個表格，才可以找當初簽章的病歷資料，再行電子驗章是否與當初電子簽章的病歷吻合，所以關聯式資料庫的正規化，反而會讓資料不夠真實且複雜。也因此台灣在實施電子病歷時，並未考慮以表格方式儲存，而是採用較符合真實情境的文件（Document）的方式來儲存。而醫院大部分都是先有HIS資料庫，才有EMR資料庫，所以不得已，在HIS資料庫儲存完後，還要將HIS資料組成EMR文件化格式後電子簽章，再儲存到EMR資料庫，不但浪費資料庫資源，且無達到最後整體的一致性，若是兩個資料庫不同步時，就會造成不知HIS資料庫是對？還是EMR資料庫是對的？
我們希望未來的資料庫，不再是HIS有HIS的資料庫，EMR有EMR的資料庫，只要透過文件式的NoSQL資料庫，就可以把HIS的資料跟EMR的資料整合成一個資料庫，也就是說以前在儲存資料時，要存HIS也要存EMR，但日後只要存在NoSQL資料庫，確保HIS及EMR資料的一致性。以前HIS的表格有作索引，未來NoSQL的文檔一樣可以作索引，所以就不會因為沒有索引，查詢資料變得更慢，保有HIS與EMR的特性及優點，並且透過NoSQL的分散式架構，避免資料庫在服務量爆發時，導致資料庫產生瓶頸。
最後，透過醫療資料交換格式標準及醫療術語國際標準編碼的結合，再加上讓HIS與EMR的資料庫，兩者合而為一的儲存在同一個NoSQL資料庫上，那就是完完全全達到了「車同軌，書同文」資料統一最的高境界。這對於日後做大數據及人工智慧有非常大的助益，因為很多臨床病歷資料都已經變成結構化、標準化及國際化，讓資料更容易交換流通、更多元化、一致性及更有品質，能夠加速人工智慧的深度機器學習及分析，實際應用於精準醫療、預防保健、個人化醫療、風險預測等，促進整體智慧醫療及精準醫療產業發展。
（口述／孫培然 彙整／CIO編輯室）
- [ 以NoSQL重構HIS資料庫(上) ]
- [ 以NoSQL重構HIS資料庫(中) ]
