以下 14 件是我近期主導的專案，分成兩組：前 8 件是臨床與醫療系統——護理白板、個管平台、手術室、電子病歷、簽章與 NIS；後 6 件是技術、基礎架構與自動化。每一件我都同時扮演兩個角色： 對院方是專案經理——負責需求訪談、規格制定、時程與驗收； 對系統是實作者——架構、程式、測試、文件都在我手上完成。 我把 AI 建成自己的開發與交付流水線，因此一個人也能撐起過去需要一組團隊的產出量， 而且每一份交付都經過自動化測試或視覺驗證才出手。
護理站要掌握的資訊分散在多個系統：床位與病人在 HIS、護理措施在 NIS、班表則有護理、醫師、支援人力三套來源且格式不一。更麻煩的是白板是掛在牆上的公開螢幕，病人姓名與病歷號不能直接顯示；而常駐大螢幕如果用輪詢更新，畫面會延遲、也吃系統資源。
規格拆成 48 項建置項目、共 2,680 人時。班表三來源正規化被我列為本案最高風險子類，優先處理；警示以 11 類 ICON 呈現並可由圖控台管理；去識別化訂出明確規則（姓名保留姓氏與末字、病歷號遮蔽中段）；更新機制採 WebSocket 推播而非輪詢。四類病區各有客製首頁，含依透析作業流程設計的透析病區版本，並開放單位自行維護顯示欄位。
交付完整規格與分階段報價（第一年建置＋第二三年訂閱）。同時明確標示三項風險：班表整合為最高風險子類、NIS 部分欄位未結構化屬外部相依、常駐大螢幕必須推播不可輪詢——把風險寫在規格裡，而不是等上線才發現。
院內個管業務被切成好幾個計畫各自為政：888、六癌篩、DM、CKD、Pre-ESRD 各有名冊、各有追蹤表、各有通報格式。但實際上同一位病人可能同時是 DM 個案又是六癌篩對象，個管師得在不同系統間反覆查同一個人，也難以看出整體照護是否連續。
把資料流的主軸從「計畫」改成「病人」，設計六條貫穿全平台的病人維度資料流：收案與名單、追蹤排程、檢驗與指標、衛教與介入、回診與轉介、通報與統計。整體規劃為 13 項建置項目、2,852 人時，另有 35 項加值功能 1,148 人時；並依 116–118 分年報價、分三階段施作，讓院方預算與導入節奏對得上。
技術架構採 Vue 3 ＋ ASP.NET Core 8 ＋ SQL Server，介面包含「個案 360°」單人視圖與全院總覽。分階段設計讓第一階段先把核心個管與追蹤流程上線，不必等整個平台做完才有價值。
醫院有大量外勤與非固定地點工作的同仁（居家護理、社區長照據點），實體打卡鐘不敷使用。但行動打卡有兩個實務地雷：一是 GPS 剛開啟時座標會飄，直接判定會把明明站在門口的人判成「不在範圍內」；二是 iPhone Safari 上事件委派處理不當，會導致整個導覽列點不動——功能寫得再好，使用者連進都進不去。
後端以 ASP.NET Core 8 ＋ Oracle（Dapper）實作，新增打卡 GPS 欄位、打卡點主檔與 GPS 稽核 log 三張表；距離用 haversine 計算並取最近打卡點，且不用單點座標判定，而是以 ±精度的不確定範圍判定，避免誤判。前端以 watchPosition 等待精度收斂到 ±30 公尺或逾時才送出，並用 Nominatim 反地理編碼顯示地址。管理端用 Leaflet 互動地圖圈選打卡點與容許半徑，搭配地圖搜尋協同定位。整包做成 PWA，加到主畫面即可用，不必上架商店。
含 iOS Safari click delegation 修正（實機驗證），以及推播排程處理忘打卡與異常提醒。延伸議題上，我也完成 HIS⇄MIS 員工身分整合評估：釐清 HIS 員編僅 6 碼（涉 863 張表、3,111 個欄位）與 MIS 8 碼工號規則的衝突，建議採「對照欄位」方案而非修改部門代碼，避開影響 9 張表約 7 萬筆排班資料、且「不報錯卻算錯」的風險。
開刀房是全院紙本最密集的地方：術前核對、麻醉紀錄、器械清點都靠紙。同時器械與植入物的 UDI 追溯要求越來越嚴，但條碼掃了之後若沒有回寫到 HIS 與護理記錄，追溯等於斷在半路。加上家屬與院內人員都需要知道手術進度，資訊卻只在開刀房裡。
把範圍拆成三個子系統：表單電子化（術前核對／麻醉／器械清點／醫療安全紀錄）、病人動態顯示（手術動態幕）、手術護理白板，三者共用同一份手術資料。UDI 部分規劃 12 項介接 API，含回寫 HIS 與回寫護理記錄兩條關鍵路徑；並補入術中照片整合紀錄。硬體（大螢幕 TV 與主機）也納入本案報價範圍。
產出規格暨報價單與測試規劃書 V1.0，共 ORS-01 ~ ORS-20 驗收案例，全部寫成實際可執行的情境（例如器械清點不符時系統應阻擋、UDI 回寫失敗應可重試），避免驗收時出現無法執行的案例。
傷口照片原本存在護理人員的手機裡，與病歷脫鉤：交班時只能口述、想比較癒合進度要翻相簿、照片也不算正式病歷紀錄。而且拍完事後歸檔很容易漏、甚至歸錯病人。
關鍵設計是「拍照當下就歸戶」——掃碼確認病人身分、標記傷口部位後才拍攝，同一病人多處傷口分別追蹤。影像連結寫入當次 NIS 護理紀錄、術後傷口與手術紀錄關聯、影像本體則存入 PACS DICOM 沿用院內既有影像管理，不另建一套。行動端整合進醫護協作 APP，並須通過 MAS 行動應用資安自主檢測。
導入分六階段：需求訪談 → 環境建置 → 整合 NIS 與醫護協作 APP（本案工期最長段）→ 教育訓練 → UAT → 上線。使用端可看到同部位歷次影像的癒合歷程時間軸，交班、會診與照護品質統計都直接看圖，不必再靠口述。
系統汰換最怕的不是新系統功能少，而是流程中間斷掉。EMR 牽涉醫師、護理與病歷室三端，病歷從產生、簽核到歸檔是一條完整的路；換系統期間舊系統還在跑，歷史病歷也必須隨時調得到。同時院方正在導入行動電子簽章，兩件事必須合在一起規劃，否則醫師會變成兩套系統各簽一次。
先把「病歷從產生到歸檔」整條流程畫清楚，確認每個交接點：HIS 就醫資料如何帶入、表單樣板如何對應、待簽核清單如何依醫師與科別派送、簽核狀態如何回寫、病歷室歸檔與調閱權限如何控管。再把行動電子簽章接進待簽流程，讓醫師在手機上就能批次簽核，簽畢即回寫 EMR 與 HIS。
2024/01 至 2024/09 完成汰換上線。導入作業包含舊資料承接（歷史病歷調閱不中斷）、新舊平行測試比對、依醫師／護理／病歷室分眾設計的教育訓練，以及上線期間現場陪跑至問題歸零。
同一套憑證機制要服務兩種完全不同的使用情境：病人簽同意書是一次性、現場、且有嚴格的簽署順序（醫師說明後病人才簽、家屬與見證人各有位置）；醫師簽病歷則是高頻、批次、要能在手機上快速完成。加上要跨本院與六家分院一致部署，還得先完成 HCA 文件申請與資安自評表送審。
同意書端由 HIS 帶出病人與術式資料，支援現場平板簽名與 QR 掃碼以自己手機簽名（iPhone／iPad／Android 皆可），並以系統控管簽名順序、每一筆附時戳存證。簽章端提供行動待簽清單，依科別與病歷類型分類，支援全選與全簽，簽核狀態即時回寫 EMR 與 HIS。憑證則透過 HCA 憑證管理平台處理申請、綁定與生命週期。
行動簽章依規格書整理為 15 項建置項目，並訂出明確驗收基準：測試案例 100% 執行、A 類缺失歸零、B 類缺失複測通過、文件審查通過。行動應用須取得 MAS 資安自主檢測合格證書方可上線，此為排程上的硬約束，因此前置作業與系統建置並行推進。
護理流程用講的講不清楚。需求訪談時護理長描述的流程，和實際站在護理站操作的手感常常是兩回事；等系統做完才發現欄位不對、步數太多，改起來成本極高。而 NIS 又是護理白板、傷口照護、智慧手術室與醫護協作 APP 的共同資料來源，一旦它的欄位沒結構化，下游整合全部卡住。
三個角色併行。導入端負責全院系統建置、系統設定與護理人員操作教學，上線期間駐點陪跑現場解題；規格端負責需求訪談、規格撰寫、廠商協調與時程驗收；而在需求未定案前，我會先做出可操作的雛型（Prototype）讓臨床實際點過再定案——把「異常值要不要自動通報」「量測時段能不能單位自訂」這類問題，在寫規格前就問出來。
NIS 的定位被明確界定為下游系統的共同資料來源，並在規劃階段就標示出已知課題：部分護理欄位（如氧氣使用細項）未結構化會影響下游整合、班表來源不一致是與白板整合時的最高風險項、護理人員的操作步數直接決定採用率。這些課題被寫進規格而非留到上線後處理。
院方標案涵蓋數據中台／FHIR、醫病臨床效率、智慧手術室、醫護協作 APP 四大構面，但需求多停留在概念層級，缺乏可執行的系統邊界與驗收基準；同時行動應用須通過 MAS 資安自主檢測，時程壓縮。
主導構面三的三個子系統（智慧手術室、傷口照護拍照、行動憑證暨行動簽章），以同一套格式產出 Kickoff 簡報、建置時程與驗收測試規劃書；並向外延伸規劃 10 項子系統藍圖，把每一項都寫到「作業內容／介接系統／備註」的層級，避免需求訪談後才發現範圍認知落差。
產出跨 10 系統、共 87 項規格明細的正式規格暨報價單，符合院方驗收文件要求；三個子系統的時程從需求訪談、系統建置、UAT、教育訓練到上線各有明確里程碑，測試規劃書只寫實際可執行的案例，避免驗收時無法交差。
深耕計畫全案 18 項、總額逾 1.2 億元，其中 9 項重點項目（合計 7,690 萬）需要一份院方看得懂、業務拿得出手的產品介紹文件。內容橫跨九套系統，來源分散在報價單、規格書、測試規劃書與產品簡報中，且每次改版都要重排版。
不用手工排版，而是建立產製流水線：Python 產生器讀入內容資料，搭配自製 SVG 架構圖 helper 輸出 HTML，再以 Playwright Chromium 轉成 A4 PDF；Word 版本則以 Node 重建原生結構（標題樣式、可編輯表格、bullet、頁碼），而非 PDF 硬轉。介面圖以 HTML 畫版面後逐元素截圖成 2× retina PNG，其中四項改用去識別化的真實產品畫面。
交付 V1 到 V4 四個版本共 39 頁，每項固定七段式結構（建置目的／現行作業問題／導入效益／架構示意圖／建置項目表／介面畫面／KPI 與預算）。同時附上交接包，含產生器原始碼與重出步驟，任何人都能重跑一次產出最新版。
醫院機房同時存在 Linux 與 Windows 主機，既有工具要嘛只支援單一平台，要嘛依賴外部 CDN 載入圖表函式庫——但院內網段連不到外網，裝上去就是一片空白。另外，遠端主機無法隨時提供給開發測試使用。
以 Flask 建置單一平台，Linux 端用 paramiko 走 SSH、Windows 端走 WinRM，統一收斂成每台 12 項指標與可設定的告警門檻；自製 LiteChart 內嵌繪圖引擎取代 CDN 相依；歷史資料存 SQLite，不需額外資料庫授權；並自建 Mock SSH Server，讓整套測試可以離線跑。
測試套件 243/243 全數通過才交付。介面採 Apple 風格三大數字監控卡（CPU／記憶體／磁碟），支援淺深主題、字級與版面配置調整，RWD 三段斷點；另交付 Word 與 HTML 雙格式操作手冊，以及內建 AI 助理協助解讀異常指標。
中小型醫院多半沒有專職 DBA。換機、搬遷或重建資料庫時，Oracle 安裝參數繁瑣，而 DMP／EXPDP 匯入過程一旦跳出 ORA- 或 IMP- 錯誤，現場人員無從判斷該修、該跳過還是該重建，往往卡住整個上線時程。
建立一條龍工具：環境檢查與靜默安裝腳本、RMAN 跨主機還原、DMP／EXPDP 匯入，並針對 IMP-00008／IMP-00034 設計三策略修復引擎——補建相依物件後重試、隔離問題物件保全整體進度、取出定義改寫重建——由程式自動判讀錯誤碼決定策略並記錄處理歷程。
最終測試套件 51/51 全數通過。工具內建 AI DBA 助理面板協助解讀錯誤訊息，並附 12 章安裝手冊，讓院方 IT 能自行重現整個部署流程。
衛生局要同時掌握屏東市、潮州、恆春三處診所試辦計畫的進度，但各據點資料不能互相看見；局端需要跨據點總覽視角；而且基於資料落地要求，系統必須部署在地端，不能用雲端 SaaS。
以 Flask 建置多租戶架構，14 個 SQLAlchemy 資料模型涵蓋專案、里程碑、任務、議題、文件與使用者；JWT 驗證搭配 7 種角色 RBAC，查詢層強制帶入租戶條件確保隔離；交付為可部署 ZIP，含 install.sh／uninstall.sh，院所 IT 可自行安裝與移除。
Playwright E2E 測試 24 項全數通過後才交付，並附 docx／PDF／獨立 HTML 三格式操作手冊。後續擴充項目（排程通知、Oracle schema）已列入下一階段規劃，界線清楚不影響本期驗收。
Nessus 初測掃出 49 台主機共 437 筆弱點（嚴重 15／高 74／中 310／低 38）。醫院系統不能停機慢慢試，而弱掃報告只給埠號不給歸屬程序——貿然關閉一個埠，可能直接打掉健保署簽章元件或院內服務。
先做風險分級與網段角色對照，辨識最高風險項（PHP 8.1.x CVE-2024-4577、EOL Oracle、TNS 毒化、SMB 匿名共用）；再逐台查出每個埠位的實際擁有程序（IIS HTTP.sys、健保署簽章元件、RDP、SMB、遠端桌面工具），確認哪些只綁 loopback、哪些真的對外，才決定修補動作。
交付完整修補套件：執行順序文件、Windows／Linux 加固腳本、SCHANNEL 與 SMB 登錄檔及對應回滾檔、驗證腳本。每一項變更都可完全還原，修補後逐台驗證弱式協定已收斂且院內服務照常運作。
