HIS系統是什麼？醫療資訊系統的範圍、法規紅線與客製判斷

作者｜瞻新資訊　張安邦執行長（台大醫工背景・十年以上IT服務公司創辦人）

做過各行各業的系統之後，我們發現醫療業有一件事跟別的產業很不一樣：它的系統規格書，有相當一部分不是院方寫的，是法規寫的。

一般企業的系統，功能怎麼設計、資料留多久、誰能看，多半是老闆或部門主管說了算。醫療系統不是。病歷要保存幾年、簽章要在多久內完成、資料要用什麼等級的加密傳輸、出事幾小時內要通報——這些在你開第一次需求會議之前，就已經被寫死在法規裡了。

搞不清楚這件事，最常見的後果是：規格談得很開心，開發到一半才發現有些做法根本不能用，整段重來。所以這篇文章不從「有哪些廠商」談起，而是先把 HIS 的範圍、法規邊界與客製判斷講清楚。

HIS 是什麼？先把它跟 EMR、EHR、PHR 分清楚

HIS 是 Hospital Information System 或 Health Information System 的縮寫，中文通稱醫院資訊系統或醫療資訊系統。它指的是醫療院所用來處理日常營運與臨床作業的整體系統，範圍涵蓋掛號、看診、檢驗、藥局、住院、批價、健保申報等流程。

實務上最容易混淆的，是 HIS 跟另外三個名詞的關係：

名詞	全稱	指的是什麼	範圍
HIS	Hospital / Health Information System	醫療院所的整體營運與臨床系統	最大，是「容器」
EMR	Electronic Medical Record	電子病歷，單一機構內的病歷數位化	HIS 底下的核心模組
EHR	Electronic Health Record	電子健康紀錄，強調跨機構交換與共享	跨出單一機構
PHR	Personal Health Record	個人健康紀錄，由病人自己持有與管理	以病人為中心

用一句話記：HIS 是整間醫院的作業系統，EMR 是裡面那份病歷檔案，EHR 是這份檔案能不能被別家醫院讀到，PHR 是病人自己手上那一份。

這個區分不是學術分類，它會直接影響專案範圍。客戶說「我想做電子病歷」，可能只是要 EMR 模組；也可能實際上需要整套 HIS，因為病歷資料得從掛號、醫令、檢驗結果一路串過來。兩者的規模差距可以是十倍。

一套 HIS 通常包含哪些模組

不同規模的院所差異很大，但大致可以分成四塊。先看懂這四塊各自的性質，比背功能清單有用得多：

• 前台流程：掛號、報到、候診叫號、批價收費、預約管理。這是病人看得到的部分。
• 臨床作業：門診／住院病歷、醫令開立、檢驗檢查申請與報告、用藥紀錄、護理紀錄。這是 EMR 的核心地帶，也是法規要求最密集的一塊。
• 後勤支援：藥品與衛材庫存、排班、財會、設備管理。這部分跟一般企業的ERP邏輯比較接近。
• 對外介接：健保申報、電子病歷交換、檢驗所或影像中心的資料交換、政府通報。

醫療系統跟一般企業系統，差在哪三件事

這一節是全篇最該慢慢看的部分。以下三件事都不是「最佳實務建議」，是法規要求——做不到不是系統比較弱，是不合規。

第一，病歷保存年限是七年起跳

依《醫療法》第 70 條規定，醫療機構的病歷應指定適當場所及人員保管，並至少保存七年；未成年者的病歷，至少應保存至其成年後七年；人體試驗的病歷則應永久保存。逾保存期限要銷毀時，銷毀方式必須確保病歷內容無洩漏之虞。

這對系統設計的影響很直接：你不能用「資料留著就好」的心態設計儲存架構。七年、成年後七年、永久，是三種不同的生命週期，資料庫的歸檔策略、備份保留政策、以及到期後的銷毀流程，都要能分別處理。這也是為什麼醫療系統的資料庫設計，在一開始就要把「這筆資料屬於哪一種保存期別」當成欄位而不是事後補。

第二，很多技術細節是法規指定的，不是你選的

《醫療機構電子病歷製作及管理辦法》把不少實作細節寫得相當具體。以下幾條是開發時一定會碰到的：

條文	規定內容	對系統的影響
第 3 條第 1 項第 5 款	網路傳輸電子病歷，使用國際標準組織通用之加密機制	加密方式不能自己發明
第 3 條第 2 項	各項管理機制應製作紀錄，妥善保存至少五年	稽核日誌本身也有保存年限
第 5 條	發生安全事故應通知當事人，並於知悉起 72 小時內通報主管機關	系統要有偵測與通報流程
第 11 條第 1 項第 1 款	輸入識別碼或其他識別方式，經電腦系統確認身分及權限相符後始得進行	權限控管是法定必要，不是加分項
第 11 條第 1 項第 4 款	病歷製作後應於 24 小時內完成電子簽章	簽章時效要有機制追蹤
第 15 條	儲存媒體無法完全移除或可事後還原資料者，應進行實體破壞	硬碟退役有法定程序

看到「24 小時內完成電子簽章」這種規定，就知道醫療系統為什麼不能直接套用一般企業系統的做法。這不是效能或體驗問題，是系統要主動追蹤未簽章的病歷、提醒、並在醫事人員無法及時簽章時改由機構憑證簽章代替。這整套機制，一般的簽核流程做不到。

第三，委外不等於責任外包

同一部辦法第 6 條規定，醫療機構可以委託大專校院或依法登記的法人機構建置與管理電子病歷系統，但醫療機構仍負最終責任，並應訂定書面契約。第 7 條第 10 款則規定，受託機構原則上不得再委託第三人，經同意並於契約載明者才例外。

這一條對雙方都很重要。對院方來說，找廠商不等於把責任交出去，資安事故發生時要面對主管機關的還是醫療機構自己。對開發方來說，「再委外」這件事必須在契約裡講清楚，不能把某個模組默默轉包出去。想更完整了解委外的模式與責任分界，我們另外寫過一篇IT 委外的三種模式可以參考。

一條最容易踩到的界線：你做的是資訊系統，還是醫療器材？

這是我們認為醫療系統專案裡最容易被忽略、但誤判代價最高的一件事。

依食藥署《醫用軟體分類分級參考指引》的說明：「醫用軟體」泛指蒐集、儲存、分析、顯示、轉換人體健康狀態、生理參數、醫療相關紀錄的處理軟體；而其中被判定屬醫療器材管理的，才稱為「醫療器材軟體」，需要依《醫療器材管理法》走查驗登記等相關程序。

判定原則不是看技術有多複雜，而是綜合評估產品的功能、用途、使用方法與工作原理，包括：是否符合醫療器材的法定定義、是否列在《醫療器材分類分級管理辦法》的品項附表、是否宣稱具診斷或治療功能或協助診斷治療、對疾病診斷的貢獻度與參考價值，以及對人類生命健康可能產生的危害程度。

實務上的意思是這樣：

• 「把檢驗數值存起來、依時間排序顯示給醫師看」——這通常是資訊系統的範圍。
• 「自動判讀檢驗數值並提示可能的疾病」——這就開始靠近醫療器材軟體的界線了。

互通性：先想好資料怎麼交換，比功能清單重要

台灣的醫療資訊正在往標準化走，這件事會直接影響新系統該怎麼設計。

衛生福利部建置的電子病歷交換中心（EEC），讓病人在任一家醫院或診所就診時，於病人同意及醫師授權的情形下，透過健保 IC 卡與醫事人員憑證，取得過去一段期間的病歷資料。目前提供醫療影像及報告、血液檢驗、出院病摘、門診病歷等類別的交換服務。

更關鍵的是標準：衛福部的次世代醫療平台計畫，正在推動導入 FHIR（Fast Healthcare Interoperability Resources）作為電子病歷的資料記錄格式，並搭配 LOINC（檢驗數據）、SNOMED CT（臨床術語）、RxNorm（藥品處方編碼）三套國際標準。

對開發專案來說，這代表一件事：「這些資料未來要怎麼跟外面交換」應該在設計初期就進來，不是上線後再說。資料模型如果一開始就往標準格式靠，日後接交換平台是加一層轉換；如果一開始各欄位自己定義，日後要做的是整個資料結構的重整，成本差距非常大。

買現成、客製，還是混合？

醫療系統市場上有成熟的套裝產品，也有客製開發，實務上更常見的是混合。

	套裝系統	客製開發	混合（套裝＋客製模組）
導入速度	快	慢	中等
前期成本	較低	高	中等
合規基礎	廠商已處理多數法規要求	要自己從頭做到位	核心沿用、新模組自理
流程貼合度	要遷就系統既有流程	完全貼合	主流程遷就、特殊需求貼合
後續彈性	受原廠版本與排程限制	完全自主	介接處是主要風險點
適合誰	流程接近同業標準的院所	有明確特殊作業模式	多數中型院所的實際選擇

判斷的重點不在「哪個比較好」，而在你有沒有一段流程是真的跟別人不一樣、而且改不動。如果有，那段就是該客製的地方；如果沒有，套裝系統通常划算得多，因為它已經替你處理掉大量的法規細節。

混合方案要特別留意介接點。新模組要跟原有套裝系統交換資料時，得先確認原廠是否提供介接方式、資料格式是否文件化、原廠改版時介接會不會斷。這個問題如果沒有先問清楚，很容易做出一個「原廠一升級就壞掉」的模組。要找廠商評估這類介接工作時，怎麼判斷系統整合商那篇有比較完整的判斷標準。

診所跟醫院的需求不一樣，別套同一份規格

這是實務上很常見的誤會。診所與醫院都叫醫療院所，但系統需求的差距非常大。

診所端的重點通常是：掛號報到與候診管理、看診紀錄、健保申報、藥局作業、簡單的財務報表。使用者人數少、角色單純，權限結構相對簡單，很多診所的實際痛點其實是「櫃檯與診間的流程順不順」，而不是系統功能夠不夠多。

醫院端則會涉及跨科部的醫令流轉、住院管理、多層級的權限與代理、檢驗檢查與影像系統介接、大量的報表與品質指標。光是「誰可以看哪一份病歷」這一題，在醫院就足以構成一個獨立的模組。

開規格之前，先確認這五件事

在跟任何廠商談功能之前，這五題先有答案，後面會順很多：

1. 範圍到底是 EMR 還是整套 HIS？ 這一題決定專案規模的量級，前面已經提過，這裡再強調一次。
2. 有沒有任何功能會碰到「判讀」或「建議」？ 有的話，先確認法規屬性再談開發，不要留到後面。
3. 現有資料在哪、格式是什麼、要不要移轉？ 舊系統的資料能不能拿得出來，常常是專案最大的變數。拿不出來的話，移轉方案本身就是一個子專案。
4. 哪些流程是真的不能改的？ 區分「習慣這樣做」跟「法規要求這樣做」——前者可以配合系統調整，後者不行，把兩者分清楚會省下大量爭執。
5. 上線後誰負責維護與法規更新？ 醫療法規會修訂，系統要跟著調整。這件事要在合約階段就講清楚由誰負責、怎麼計費。

醫療系統跟一般企業系統最大的差別，說到底就是可以自由決定的部分比較少。這聽起來像限制，實際上反而讓專案有個明確的起點：先把不能動的框架釐清，剩下的才是真正需要討論的設計空間。

十多年下來我們接觸過四十多種產業的系統需求，共同的起手式都一樣——先把模糊的想法拆解清楚，弄明白真正要解決的問題是什麼，再決定用什麼技術與架構來做。醫療領域只是把「不能動的部分」寫得比其他產業更明確而已。有相關的系統需求在評估，歡迎聊聊你目前的情況。

常見問題