3S Market 探討報導
醫院為什麼需要 Access Control 平台？全球與台灣的實際應用探討
Audience Target｜ 醫院安全管理、工務、資訊、總務與營運主管；Access Control、弱電、系統整合、智慧醫療與安全平台業者；希望進一步理解醫療場域 Access Control 市場發展的中高階經營者。
Highlights
- 醫院真正複雜的不是「門很多」，而是醫師、護理師、病患、家屬、訪客、承攬商與物流人員的身份、時間與權限不停變動。
- Access Control 平台的核心已不只是 Card → Reader → Controller → Door，而是 Identity → Authorization → Policy → Access → Activity → Response → Traceability。
- 全球醫院案例顯示，平台已逐步整合門禁、電梯、停車、緊急求救、對講、承攬商管理、Lockdown、警報與安全事件處理。
- 台灣大型醫院並非沒有平台化案例，但公開資料呈現出明顯差異：從單純門禁、中央管理、人事系統介接，到跨系統整合平台都有；因此，「醫院有沒有門禁」已不是問題，「Access 管理走到哪一層」才值得探討。
醫院不是一棟有很多門的建築，而是一個權限不停變動的場域
醫院可能是所有大型建築中，進出關係最複雜的場域之一。
一般企業的主要進出者，大致可以分為員工、訪客與承攬商；醫院卻同時存在醫師、護理人員、行政人員、研究人員、實習醫師、病患、陪病者、探病者、藥商、物流、餐飲、清潔、設備維修、工程承攬商，甚至警消與其他緊急應變人員。
更麻煩的是，這些人的「身份」並不是固定不變的。
一位醫師今天在哪一個院區？屬於哪一個科別？是不是值班？有沒有手術？一名研究人員現在是否仍屬於某個計畫？外包維修人員今天被允許進入哪一間機房？病患轉病房後，家屬原來的陪病權限是否仍然有效？
因此醫院真正面對的，不只是：這張卡能不能開這扇門？
而是：
這個人是誰？以什麼身份來到這裡？現在為什麼可以進去？可以進到哪裡？可以停留多久？情況改變以後，原來的權限是不是仍然有效？
這就是醫院需要 Access Control 平台，而不只是大量 Reader、Controller 與電子鎖的根本原因。
從「控制一扇門」，走向「管理一次 Access」
傳統門禁系統的邏輯很清楚：Credential → Reader → Controller → Door
卡片合法，門打開；卡片不合法，拒絕通行。
這套架構沒有錯，而且仍然是 Access Control 的基本骨架。但是到了大型醫院，只做到這一層就不夠。
真正的平台應該進一步處理：
Entity → Identity → Authenticator → Access Request → Authentication → Authorization → Policy / Permission → Access → Activity → Continuous Evaluation → Traceability / Response
換成比較生活化的說法：
一個人先被確認「你是誰」，再確認「你現在以什麼身份來」，接著判斷「你現在是否有權進入這個地方」，進入之後還必須留下活動紀錄，發生異常時則能立即處理並追溯。
因此醫院 Access Control 的管理對象，表面上是 Door，真正的平台管理核心其實是：Identity、Authority、Boundary、Activity。
這也是 Access Control 從設備系統走向治理平台的重要分水嶺。
同一家醫院，不同區域其實存在完全不同的安全要求
醫院裡的公共門診大廳、一般行政辦公室、病房、ICU、NICU、手術室、藥庫、管制藥品室、研究實驗室、資料中心與設備機房，不可能使用完全相同的 Access Policy。
例如公共門診的重點，是讓大量就醫民眾順利進出；一般病房則可能有探病時間與陪病身份限制；藥庫除了限定工作人員外，還可能需要更精細的時間、職務與紀錄要求；研究實驗室、資料中心等高敏感區域，甚至可能需要雙重驗證。
荷蘭 Haaglanden Medical Center 的案例，就是很清楚的例子。院方過去分別操作影像與 Access Control 系統，之後導入 Genetec Security Center，將 Access Control、入侵偵測、通訊、警報等整合在同一環境；實驗室及 Server Room 等高風險區域則採雙重驗證，授權人員除了卡片之外，還需要 PIN 或指紋認證。
換句話說，平台真正需要管理的是：
不同的人 × 不同區域 × 不同時間 × 不同情境 × 不同安全等級。
這不是增加更多 Reader 就能解決的事情。
醫院需要怎樣的 Access Control 平台？
如果從醫院的實際營運需求來看，一套真正的平台至少應該具有以下能力。
平台能力 | 醫院實際要處理的問題 |
Identity Lifecycle | 新進、調職、輪調、離職、實習、研究人員、外包人員的身份與權限變動 |
Role / Policy Management | 不只是「某人可以進某門」，而是依職務、單位、班別、時間及區域授權 |
Multi-zone Security | 公共區、病房、高敏感醫療區、藥庫、實驗室、機房採不同安全政策 |
Visitor / Patient Access | 病患、陪病、探病、訪客與臨時人員的短期身份及通行權限 |
Elevator / Parking Access | 把水平的門與垂直樓層、停車區域納入同一 Access Policy |
Event Integration | Door Forced Open、Door Held Open、Duress、Alarm 等事件自動進入處理流程 |
Emergency / Lockdown | 緊急事件時可以快速改變區域權限與封鎖策略 |
Audit / Traceability | 可以回答誰、何時、以什麼身份、經過何種授權進入哪裡，以及異常如何處理 |
其中最容易被忽略的，其實是第一項：Identity Lifecycle。
醫院最大的 Access 管理問題之一，往往不是「沒有裝門禁」，而是權限建立之後，身份已經改變，Access Permission 卻沒有同步改變。
員工離職了，卡片是否立即停權？醫師轉調其他單位，舊區域權限是否取消？研究助理計畫結束，實驗室權限是否同步收回？外包人員工作只到星期五，他的卡星期六還能不能使用？
只要這些仍需要管理員逐筆記得修改，就表示 Access Control 還沒有真正和 Identity Lifecycle 建立關係。
HR、HIS 開始成為 Access Control 的重要資料來源
這也是醫院平台化非常重要的一步。
Access Control 平台本身不一定知道：「這位醫師今天是不是還在這個科別？」但是 HR、人事系統知道。
Access Control 不一定知道：「這名病患今天住在哪一個病房？」但是 HIS 或相關醫療資訊系統知道。
因此未來真正重要的，不一定是把所有資料搬進 Access Control，而是讓 Access Policy 可以根據其他系統所掌握的身份與情境進行判斷。
這可以形成：
HR / HIS / Visitor / Contractor System → Identity & Context → Access Policy → Authorization → Door / Elevator / Parking / Restricted Area
台灣其實已經出現這類案例。
中山醫學大學附設醫院的公開系統整合實績顯示，其網路型門禁管理系統已介接院內相關人事系統，並利用系統進行分層管控。這件事的意義不只是「門禁電腦和人事電腦連在一起」，而是 Access Permission 開始有機會跟著組織身份改變。
這正是由「設備管理」走向「身份管理」的重要一步。
Patient Identity 也可能成為 Access 的一部分
更值得觀察的是，醫院 Access 的 Identity Source 不會只有員工 HR。
奇美醫院的「奇醫管家」就是另一種值得注意的發展。病患在就醫當日可以取得個人條碼，除了用於繳費、抽血與檢查報到，也可以使用在急診門禁管制刷碼進出。
這件事非常有意思。
因為產生這個 Access Credential 的起點，不是安全室發給一張卡，而是：
Patient Identity → 今日就醫關係 → Credential → Access。
也就是說，醫療資訊流程本身開始參與實體 Access。
這不代表 HIS 要取代 Access Control，更不是說所有醫院都應該拿 HIS 直接控制門；真正值得觀察的是，醫院未來的 Access Policy 很可能愈來愈需要從醫療、排班、人事、訪客與營運系統取得「Context」。
Access Control 平台因此也不應該再是一座獨立孤島。
醫院的 Boundary，也不只是「門」
另一個常見誤解，是看到 Access Control 就想到門。
但是醫院人員的移動具有高度立體性。
某位醫師可以進 A 棟，但是否能到八樓？某位訪客可以進病房，但是不是能前往其他病房樓層？物流人員可以進地下卸貨區，但是不是可以搭乘同一部電梯進入醫療區？
因此醫院的 Access Boundary 可能包括：
門、電梯、停車場、車道、樓層、藥品櫃、特定設備，甚至某些臨時施工或感染管制區。
國軍桃園總醫院新建醫療大樓的公開案例就反映了這種思考。系統依醫護人員、病患、訪客與後勤單位設定不同權限，涵蓋急診、加護病房、手術及 Hybrid Room、藥庫、醫療檔案室與探病管制區；同時把電梯樓層控制納入門禁架構，使醫護人員依職責通行指定樓層，而病患與訪客依探病與診療範圍限制移動。
這才是 Access Control 平台真正的價值：
不是多管理幾扇門，而是管理整個場域的 Boundary。
全球有哪些值得觀察的醫院 Access Control 平台？
全球市場上可以處理大型 Healthcare Access Control 的系統很多；如果我們不是比較產品規格，而是觀察「平台化」如何在醫院發生，以下幾個案例特別具有代表性。
平台 | 代表醫療案例 | 值得觀察的能力 |
Genetec Security Center / Synergis | Haaglanden Medical Center、Lee Health | Unified Security、Access、Intercom、Duress、Parking、多院區中央管理 |
Software House C•CURE 9000 | University of Iowa Hospitals and Clinics | Enterprise Access、HR Database、Emergency Lockdown、跨院區中央管理 |
LenelS2 OnGuard | Sharp Healthcare | Enterprise Access、第三方系統整合、Intercom / Intrusion Integration |
Gallagher Command Centre | Waikato、King Chulalongkorn Memorial Hospital | Access、Duress、Lockdown、Contractor、Parking、Audit |
Avigilon Unity Access / Motorola Solutions | SSM Health | Rules-based Access、Video、Alarm、Radio Communication 整合 |
這裡真正值得看的，不是哪一家平台「功能最多」，而是它們正在解決什麼樣的醫院問題。
Genetec：從不同系統，走向一個 Security Operation Environment
Lee Health 是很典型的平台化案例。
這個醫療體系擁有超過 100 個據點，包括四所綜合醫院、兩所專科醫院及大量非急性醫療設施。過去不同據點存在不同的老舊影像及 Access Control 系統，操作人員需要在多個系統之間尋找資訊。
導入 Genetec Security Center 後，操作人員可以在中央介面處理 Door Alarm、Access Control、車牌辨識、Intercom、Panic Button 等資訊；員工也可以使用一張卡在不同醫療設施通行。
這個案例說明的是：
大型醫療集團的 Access Control 問題，已經不是一棟建築，而是 Multi-site Identity 與 Security Operations。
Haaglanden Medical Center 更進一步把 Access Control、Intrusion、Duress、Intercom 與其他安全事件放在同一個操作平台，讓 Emergency Department 的緊急求救可以直接進到控制中心的事件處理流程。
這就是從「Access Management」再往「Security Orchestration」移動。
C‧CURE 9000：Access 開始和 HR、Emergency Response 串在一起
University of Iowa Hospitals and Clinics 同樣具有代表性。
其主院區每天約有 16,000 名訪客進出，另外還有大量院外據點。院方使用 C‧CURE 9000 建立中央安全管理環境，而且透過 SQL Interface 存取醫院 HR Database。
更重要的是，它把 Emergency Lockdown 做進平台介面。
當發生緊急事件時，使用者可以快速讓特定部門進入 Lockdown；這項能力也延伸到部分院外診所。
這件事再次說明：
平常的 Access Control 是「誰能進」。
真正的平台在事件發生時必須回答：
現在整個 Access Policy 是否要立即改變？
Gallagher：醫院的 Access，其實和人員安全、承攬商、藥品與稽核都有關
Gallagher 在 Waikato District Health Board 的案例尤其值得注意。
該醫療體系有超過 730 道 Access Controlled Doors，平台除了管理一般 Access，還處理 Lockdown、Duress Notification、Contractor Sign-on / Sign-off、Car Park 及受監控的 Refrigerator / Freezer 等項目。
這已經完全超越「門禁管理」。
King Chulalongkorn Memorial Hospital 則有超過 10,000 名 Cardholders、655 個 Readers，Gallagher Command Centre 進一步整合 Fire Alarm、Video Management、Building Automation 與 Car Park Management。
這也是大型醫院最值得思考的地方：
Access Control 平台究竟要停在 Access，還是逐步成為醫院安全管理的其中一個 Core Platform？
台灣醫院現在的 Access Control 平台走到哪裡？
這個問題反而比列出台灣醫院用了哪一個品牌更重要。
從目前能取得的公開資料來看，不能簡單說「台灣醫院已經普遍平台化」，但同樣也不能說「台灣仍然只有單機門禁」。
比較接近實際市場的描述是：台灣醫院目前同時存在不同發展階段。
階段 | 主要特徵 | 台灣公開案例可以看到的現象 |
Access Device | Reader、Controller、Door 各區域管理 | 大量既有醫院設備仍具此特性 |
Centralized Access | 中央建立卡片、權限、Alarm、紀錄 | 大型醫院普遍已具備不同程度中央管理 |
Identity Integration | HR 等系統與 Access Permission 連結 | 中山附醫人事系統介接案例 |
Unified Platform | Access 與其他安全系統在同一操作環境 | 高雄市立鳳山醫院 Genetec 案例 |
Context-driven Access | 病患、就醫、排班等資料形成動態 Access | 奇美急診條碼已呈現這類發展方向 |
Security Orchestration | Identity、Event、Policy、Response 跨系統聯動 | 公開資料仍較少，值得持續追蹤 |
這張表很重要，因為「有中央 Server」不能直接等於 Platform，「可以統一設定很多門」也不一定就是我們這篇所談的 Access Control Platform。
真正的分水嶺是：
它有沒有開始處理 Identity、Policy、Context、Event 與 Response？
台大醫院：已經可以看到中央門禁管理的基本輪廓
台大醫院公開的門禁管理辦法提供了很好的觀察樣本。
院方對新進人員、約聘人員、研究員、代訓醫師、實習醫師、研究助理等不同身份，都有正式申請程序；申請經主管核可後，由管理人員登錄「門禁安全管制系統」啟用權限。
院方另一份門禁管制說明也指出，行政辦公室、財產倉庫、重要儀器設備室、檢查室、血庫、共同研究室等均設有刷卡管制；系統會記錄門禁狀態及進出時間、人員姓名，發生不當進出警報時，值班人員可以從監控系統定位後派員處理。
從這些公開資訊可以確定：這已經不是零散的「門上裝一台讀卡機」。
但公開資料並不足以進一步確認所有 Identity Source、自動化權限流程與其他院內系統的整合深度。
這也恰好反映台灣市場研究的困難：醫院公開的是管理規定與採購項目，真正的平台架構通常不會完整公開。
中山附醫：值得注意的是「人事系統介接」
中山醫學大學附設醫院的案例，相對能看到更進一步的平台概念。
系統整合商公開資料指出，其網路型門禁管理系統介接院內相關人事系統，並透過分層管控降低管理負擔。
如果人事身份建立、調動或失效能進一步驅動 Access Permission，這就是大型醫院非常重要的管理能力。
它解決的已經不只是：如何新增一張卡？
而是：如何避免身份已經變了，權限卻還留著？
鳳山醫院：台灣已經存在 Unified Security Platform 案例
高雄市立鳳山醫院則提供另一種發展方向。
公開實績顯示，院方使用 Genetec Security Center 管理視訊、門禁、緊急求救與對講。
這已經符合典型的 Unified Security Platform 架構：
Access Event 不再只是 Access System 自己知道。
例如一個緊急求救、一個門被強制開啟或另一個異常事件，都有機會在同一安全操作環境內被處理。
值得注意的是，同一份公開實績中，桃園長庚、林口長庚等院區也可看到 Genetec Security Center 的相關部署，但公開內容主要描述視訊、緊急求救、廣播或對講，不能因此直接推論其 Access Control 也全部納入同一平台。
這個區別很重要。
使用同一個品牌的平台，不等於所有 Security Subsystem 都已經完成整合。
醫院 Access Control 平台真正要解決的，是「誰知道、誰判斷、誰處理？」
回到醫院每天真正發生的事情。
一張卡在凌晨進入藥庫。
傳統門禁系統可以告訴你：卡片有效，門已開啟。
但醫院真正需要知道的是：
這是誰？今天是否值班？他的職務是否具有這項權限？現在這個時間是否正常？是否需要另一位人員共同在場？進入後發生什麼事情？如果異常，是由誰判斷？誰被通知？有沒有留下事件處理紀錄？
同樣的邏輯可以套到 ICU、NICU、手術室、實驗室、醫療廢棄物區、資料中心、高價醫材倉儲甚至病房。
所以平台真正應該回答的是：誰知道？誰判斷？誰處理？處理了什麼？最後能不能追溯？
做到這一步，Access Control 才真正開始從「設備」進入「治理」。
台灣醫院下一步，未必是把既有門禁全部換掉
這也是產業端很容易誤解的地方。
談 Platform，不代表醫院一定要一次拆掉所有 Controller、Reader、Credential，重新建一套龐大的系統。
大型醫院本來就具有大量既有投資，而且醫療環境不能因為 Security System 升級而任意中斷運作。
因此比較現實的發展路徑，很可能是：
既有 Access Device 繼續使用，但上層逐步開始建立中央 Identity、Policy、Alarm、Workflow 與 Integration。
先從最需要的平台能力開始。
例如員工身份與 HR 連動；再加入承攬商與 Visitor；接著把電梯、停車、高安全區域以及 Emergency Lockdown 納入；最後才逐漸形成跨院區的 Access Governance。
國際醫院的實際案例其實也是如此。University of Iowa、Lee Health 等案例都不是因為「Reader 不夠先進」才開始平台化，而是既有系統愈來愈多、院區愈來愈大、事件處理愈來愈複雜之後，原來分散的系統已經無法有效支撐營運。
因此真正的商機，不一定從「換門禁」開始。
反而可能從：
Integration、Identity、Policy、Workflow、Event Management 與 Operation 開始。
結語：醫院真正要管理的從來不是「門」
醫院每天都有數量龐大而且身份不同的人進出。
一方面它必須保持開放，讓病患能夠迅速取得醫療服務；另一方面卻又存在 ICU、手術室、藥庫、研究實驗室、資料中心等高度敏感區域。
它不能像工廠一樣，把所有陌生人擋在大門外。
所以醫院 Access Control 最困難的地方從來不是：如何把門鎖得更緊。
而是：
如何讓應該進去的人，在應該進去的時間與情況下順利進去；不應該進去的人則被適當阻擋，而且整個過程可以被管理、應變與追溯。
這也是 Access Control Platform 和傳統門禁系統最大的差別。
今天的台灣醫院，從公開案例已經可以看到中央門禁、人事系統介接、病患條碼 Access、門禁與電梯整合，以及 Unified Security Platform 等不同發展。
因此真正值得產業持續追蹤的問題，已經不是：「台灣醫院有沒有使用 Access Control？」而應該改成：「醫院目前把 Access 管到什麼程度？」
當 Access Control 開始把 Entity、Identity、Authority、Boundary、Activity、Event 與 Response 串在一起，它管理的就不再只是「一扇門」。
它開始成為醫院安全治理的一部分。
而這，也可能是 Access Control 產業下一階段真正具有價值的市場。
0 comments:
張貼留言