AI SYNTHESIS / MAY CONTAIN ERRORS

1. 結論先行：這不是另一套 EMR，而是巡迴營運與法遵的整合層

AI 產品判讀：完整 PRD 的 150 項功能需求，不應被解讀為一次重做掛號、病歷、檢驗、影像、藥局與申報。較穩健的產品邊界，是讓平台負責計畫治理、規則驗證、跨資源排班、診前派遣、離線交易、同步監控、申報前檢核、公開時段與稽核證據；病人主索引、正式病歷、檢驗結果、影像與調劑紀錄仍由院所既有系統治理。

這個邊界可降低形成影子病歷系統的風險，也讓每家院所依既有 HIS／EMR、LIS、PACS、藥局與健保元件逐步整合。平台只保存現場作業所需的最小資料、尚未同步的交易、來源版本與可追溯索引；同步成功後，正式資料的主責來源必須清楚且可驗證。

AI 建議：MVP 以西醫醫療資源不足地區巡迴服務為主流程，但資料模型應預留 IDS、遠距、居家與跨專業服務的方案識別、費用來源及互斥規則，避免日後另建平行系統。

產品邊界與資料主責

FIGURE 01 / MATRIX
產品邊界與資料主責
項目主要責任主檔或正式證據不得越界
巡迴整合平台核准、排班、派遣、離線佇列、申報檢核、公開時段、稽核與 KPI計畫版本、診次狀態、同步證據、規則命中與例外核准不得成為未受院所病歷治理的第二套 EMR
HIS／EMR病人、掛號、正式就醫、診斷、醫囑、處方與簽章病歷病人主索引與正式病歷平台不得靜默覆寫或自行合併臨床主檔
健保正式元件與 VPN健保卡、虛擬卡、雲端查詢、申報與核付交換官方或院所正式交易結果不得假設或模擬未公開 API
LIS／PACS／藥局檢驗、影像、調劑、庫存與專業工作流各專業系統的結果與執行紀錄MVP 不複製完整影像或重做專業系統
這是本文依 PRD 與院所系統責任做出的產品切分；實際主檔與介接權責仍須由試辦院所確認。

2. 政策規則要能執行、版本化與回歸測試，不能只放在操作手冊

來源事實：115 年度西醫醫療資源不足地區改善方案，已把巡迴點、診次、人員、退場與公開資訊寫成具體限制。每一巡迴點每日最多一診次、每診次至少三小時、每週原則最多三診；單一診次最多兩個地點且每點至少一小時，服務時間須介於 07:00 至 21:00，實際醫療時間不含車程、用膳與休息。

來源事實：服務滿三個月後，平均每診未達五人次者須暫停，提出改善或變更巡迴點並經核准後才可恢復；每季累計休診達原申請總次數四分之一，可能終止該點服務。核准地點與時段亦須揭示並提供民眾查詢。IDS 另有逐次登錄及二十四小時內上傳健保卡資料的要求。

AI 產品判讀：這些條文不是表單提示，而是要在申請、排班、診前派遣、現場結案、申報前檢核與績效退場各階段重複執行。規則必須帶有方案、年度、生效日、嚴重度、例外角色、核准證據與測試案例；否則年度修訂後，歷史案件會無法重現，現行案件也容易套錯版本。

不確定性：正式上線前仍須核對當年度公告、分區業務組執行口徑、院所核准函與最新申報規格。本文列出的控制點是產品基線，不取代主管機關核定。

從方案條文到系統閘門

FIGURE 02 / MATRIX
從方案條文到系統閘門
項目系統控制必留證據失敗處置
每日一次、每週三診、至少三小時排班建立與結案時雙重驗證核准時段、實際到離時間、規則版本阻擋 Confirmed 或標記不可申報
最多兩點、每點至少一小時、07:00–21:00RouteStop 與時間窗檢核，車程另計停靠順序、GPS／到離時間、人工修正原因阻擋派遣或要求核准例外
三個月平均未達五人次按點位與方案口徑自動計算列計／排除明細、公式版本、改善計畫轉 Suspended，核准後才能恢復
季度休診達四分之一以核准診次為分母持續監測休診原因、通知、例外證明與版本啟動終止流程並停止新增正式診次
公開服務資訊與 IDS 二十四小時上傳核准狀態驅動發布；上傳倒數與升級告警發布版本、送達紀錄、卡片交易與重送軌跡撤回過期時段；逾期進事件與補送流程
左欄為官方方案中的核心限制；中、右欄是本文建議的系統化控制與證據。

3. 計畫、診次、就醫與申報要分成不同狀態機

AI 產品判讀：巡迴醫療同時存在行政核准、現場營運、臨床病歷與費用申報，不能用一個 status 欄位代表全部狀態。計畫被暫停，不代表已完成的病歷可以回滾；診次取消，也不代表已同步的就醫事件應被刪除；申報退件，更不能改寫原始臨床紀錄。

建議至少拆成四條可關聯但互不覆寫的生命週期：ServicePlan 管申請、審查、核准、暫停與終止；Session 管排班、驗證、派遣、開診、結案與同步；Encounter 管掛號、檢傷、看診、簽章與轉診；Claim 管待檢核、已申報、退件、重送、核付與對帳。

每次跨狀態移轉都應保存 actor、時間、來源規則、前後狀態、例外原因與證據附件。這樣才能回答稽核最常問的問題：當時依哪個核准版本執行、誰讓診次進入正式狀態、何時完成病歷與卡片上傳，以及退件後修了什麼。

巡迴服務端到端生命週期

FIGURE 03 / FLOW
計畫核准

核准人員、點位、時段、期間與規則版本

診次驗證

人員、場地、時數、衝突、設備與公開狀態

派遣與開診

下載最小離線資料包並完成出發前檢核

就醫與簽章

身分、臨床紀錄、處方、轉診與二十四小時簽章追蹤

同步與申報準備

冪等重送、衝突處理、卡片與資料完整性

申報、核付與改善

退件重送、對帳、低量與休診退場監測

圖中是跨狀態機的關聯節點；實作時仍應由計畫、診次、就醫與申報各自維持狀態與稽核軌跡。

4. Offline-first 是核心營運模式，不是斷線後才補做的備援功能

AI 產品判讀：偏鄉巡迴場域不能把穩定網路當作前提。現場端應在出發前下載經核准、加密且有期限的診次資料包；斷線後仍可完成最小身分核對、暫存掛號、生命徵象、臨床紀錄、處方與轉診，但所有需要中央或官方服務確認的結果都要標示為待驗證，不得在本機假裝成功。

同步設計要以交易佇列而非整份資料覆蓋為核心。每筆交易包含全域識別碼、來源裝置、版本、冪等鍵、建立時間、臨床時間與依賴順序；網路恢復後依序送出。重送不得重複建檔，雙端同時修改不得採最後寫入者自動覆蓋，必須保留來源並交由有權限的人處理。

裝置遺失是離線架構的必要驗收情境。平台應支援 MDM 或等效管理、資料與金鑰分離、短效離線授權、遠端撤銷、停止同步、事件影響清單與處置稽核。離線資料量應以該診次所需的最小集合為限。

離線資料包與同步佇列流程

FIGURE 04 / FLOW
診前封裝

只下載核准診次需要的最小資料、規則與憑證狀態

本機加密作業

掛號、量測、臨床紀錄與事件暫存均標示來源與待驗證狀態

交易佇列

依賴順序、冪等鍵、版本與失敗原因完整保存

連線恢復

先驗證裝置與授權，再分批重送並取得正式回應

衝突處理

同人異碼、雙端修改與卡片失敗進人工覆核

封存或撤銷

同步完成後移除最小資料；遺失裝置立即撤銷金鑰與同步權限

這是本文建議的 Offline-first 控制流程；卡片、申報與院所介接仍須依正式元件及實際契約實作。

5. 資料治理先定主責來源，再談跨院交換與分析

AI 產品判讀：平台需要 Canonical Data Model 統一方案、診次、病人參照、就醫、觀察值、處方、轉診、申報、事件與稽核的語意，但 Canonical 不等於把所有資料複製進中央資料湖。每個實體都要標示主責來源、允許暫存範圍、同步方向、衝突政策、保存期與可用目的。

Patient 應以院所 MPI 或受控識別參照為主；Encounter、Condition、Order、MedicationOrder 與電子簽章由院所 EMR 負責；Observation 依來源由 EMR、LIS 或 POCT 治理；Approval、Session、RouteStop、ChangeRequest 與規則命中紀錄由巡迴平台負責；Claim 與 Payment 則由申報及財務流程共同確認。

AI 建議：BI 只接收去識別或最小必要的營運、品質與申報資料，不直接複製完整病歷作一般分析。對外匯出、跨院交換與研究利用必須另外確認目的、法源或同意、接收者及欄位範圍。

核心資料的主責與同步原則

FIGURE 05 / MATRIX
核心資料的主責與同步原則
項目主責來源平台保存範圍衝突原則
Patient／MPI院所 HIS／MPI最小識別參照與診次所需人口學資料同人異碼不得自動合併，需授權覆核
Encounter／病歷／處方院所 EMR／藥局離線未同步交易、回寫狀態與稽核索引正式病歷版本優先；平台保留原始現場版本
Observation／檢驗EMR、LIS 或 POCT來源、時間、設備、待確認與結果參照不得省略來源與品管狀態
Approval／Session／Route巡迴平台完整主檔、版本、核准與執行證據只有核准且有效版本可進正式狀態
Claim／Payment申報與財務流程候選代碼、批次、退件、重送與對帳臨床紀錄不可因退件而被改寫
主責來源是建議基線；試辦院所應以資料治理會議確認實際系統與保存政策。

6. 介接先尊重官方元件與院所現況，再用 FHIR R4／TW Core 統一語意

來源事實：TW Core Implementation Guide 以 FHIR R4 為基礎，安全性指引建議搭配身分與授權、傳輸保護、稽核軌跡、同意與資料保護控制。AI 產品判讀：平台可以把 Patient、Encounter、Observation、Condition、MedicationRequest 等核心概念優先映射到 TW Core，但不應強迫所有既有系統一次改成 FHIR。

較可行的介接策略是「平台內部統一語意、邊界使用轉接器」。新系統優先採 FHIR R4／TW Core 與標準授權；舊 HIS、LIS、PACS、藥局及申報端則保留 HL7 v2、CDA、REST、DICOMweb、SFTP 或批次檔。每條介接都必須有資料契約、欄位對應、版本、追蹤識別碼、重試、死信佇列、冪等鍵與人工重送流程。

健保卡、虛擬卡、健保資訊雲端與申報交換只透過健保署正式元件或院所既有合法流程。PRD 的責任是定義必要情境、資料方向、錯誤處理與驗收條件，不應虛構即時 API、欄位或錯誤碼。

7. 遠距醫療是核准條件驅動的模組，不是單純開啟視訊

來源事實：通訊診察治療辦法要求醫療機構依適用情形提出實施計畫並取得核准；資訊系統須具身分確認與標準加密，執行時還要處理告知同意、病人身分、隱私、病歷製作與必要時改採其他診療方式。健保遠距醫療給付計畫的修訂，也已將醫療資源不足地區的巡迴服務地點納入相關適用場域。

AI 產品判讀：遠距功能的入口條件至少包含計畫核准、院所與醫師資格、服務地點、病人情境、同意版本、在場人員、設備測試與加密通道。任何一項不符，系統應阻擋開始或要求明確的急迫例外與事後補記。

遠距診次還要留下通訊方式、起訖時間、參與者、在地執行醫事人員、技術異常、醫囑執行與轉實體原因。醫師判定資訊不足、病情不適合或現場處置能力不足時，應一鍵建立實體轉診／轉送與病人指示，而不是讓視訊失敗停在技術工單。

8. 資安、個資與病人安全要直接成為流程閘門

來源事實：電子病歷管理規範要求身分與權限控制、完整操作軌跡、傳輸保護、備份與安全事故處理；電子病歷製作後原則上應於二十四小時內完成電子簽章，增刪與查閱紀錄也要完整保留。涉及雲端時，還須處理營運中斷、供應商監督、退出與資料在地等風險。

AI 產品判讀：這些要求不能只寫在資安章節。證照失效要阻擋排班與簽章；Break-glass 要有理由、時限、通知與事後覆核；病歷未簽章、卡片未上傳、異常結果未追蹤與轉診未閉環，都要進角色化待辦與升級通知。

個資與醫療資料的蒐集、使用與跨機構交換，應綁定目的、必要欄位、法源或同意、接收者及保存政策。清單、叫號、匯出與一般日誌預設遮罩；大量下載、異常地點、權限提升與遺失裝置要能即時告警。

不確定性：個資、電子病歷與資安規範會因院所類型、服務模式與修法生效狀態而不同。正式上線前必須由院所法遵、資安、病歷管理與臨床治理共同確認適用條文及內控時限。

高風險事件的控制、證據與停止條件

FIGURE 06 / MATRIX
高風險事件的控制、證據與停止條件
項目前置控制稽核證據停止或升級條件
病歷與簽章角色、照護關係、有效憑證與二十四小時倒數建立、查閱、修改、簽章與補簽軌跡逾時升級；不得以補簽覆蓋原始時間
離線裝置裝置註冊、加密、短效授權、最小資料與 MDM下載範圍、離線操作、同步與撤銷時間遺失、Root／越獄或授權失效立即停用
資料匯出與跨院交換目的、法源／同意、欄位最小化與接收者驗證申請、核准、範圍、水印與交付紀錄超範圍、無照護關係或大量異常即阻擋
臨床警示與轉診異常值、過敏、危急結果與紅旗規則警示呈現、覆核理由、聯絡與結果回覆高風險未處理不得正常結案
資安／個資事件監控、分級、隔離、備份與供應商通報契約時間線、影響範圍、通知、證據與改善達門檻即啟動主管機關與當事人通知流程
這是產品安全基線；事件分級與通報對象仍須依適用法規及院所政策核定。

9. 150 項需求應收斂成八個 MVP Epic，而不是一次開發 28 個畫面

AI 建議：PRD 的 150 項功能、28 個畫面與 12 類介接，可以先重組成八個可交付 Epic。每個 Epic 都要有可獨立驗收的營運結果，而不是以畫面完成率衡量。首批試辦應優先打通一個方案、一家主責院所、少量巡迴點與一套正式介接，先證明端到端閉環。

Phase 1 不宜同時追求全國多租戶、所有科別、完整遠距、PACS 影像複製、跨院 MPI 與全人資料湖。這些功能需要主管機關、院所聯盟、資料治理及供應商契約成熟後再擴充。

Definition of Done 應包含規則來源、正常與失敗路徑、稽核證據、介接重送、權限、離線行為、監控與營運手冊，而不只包含前端畫面與 API 回傳成功。

八個 MVP Epic 與退出閘門

FIGURE 07 / MATRIX
八個 MVP Epic 與退出閘門
項目MVP 交付結果退出閘門延後範圍
E1 方案、規則與核准年度方案、申請、補件、核准、異動與規則版本未核准資料無法排入正式診次跨主管機關全線上送件
E2 點位、人員與排班場地、證照、報備、衝突與多資源排班核心診次與人員規則可自動阻擋AI 路線最佳化
E3 派遣與離線現場診前包、出發檢核、掛號、量測與離線交易完全斷線仍可安全完成最小流程多作業系統全型號支援
E4 卡片、同步與病歷回寫正式元件串接、佇列、冪等與衝突工作台重送不重複、衝突不覆寫自建健保雲端服務
E5 臨床結案與轉診處方交接、結果、紅旗、轉診與閉環高風險未處理不得結案完整專科 CDS
E6 HIS／EMR 與周邊介接一套可觀測的院所轉接器與資料契約失敗可重送、版本可追溯一次支援所有院所
E7 申報、退件與核付分類、申報前檢核、批次、退件重送與對帳每筆費用回溯至核准與就醫證據未取得正式規格的即時 API
E8 安全、稽核、KPI 與公開資訊RBAC、事件、證據包、退場監測與時段發布異常可告警、撤銷時段不再公開全國資料湖與進階預測
Epic 是本文對完整 PRD 的產品重構；實際切分需依試辦院所、介接可得性與團隊容量調整。

10. UAT 先驗證高風險失敗路徑，再驗證一般 happy path

AI 測試建議：32 個關鍵 UAT 的價值，不在覆蓋每個按鈕，而在證明系統會在錯的時間停止。最優先情境包括：核准前不得 Confirmed、發布或申報；二點五小時診次被阻擋；同點同日第二診被擋；失效證照不能排班；同筆交易重送三次只建一筆；HIS 與現場衝突不能靜默覆寫。

現場與法遵情境還包括：IDS 資料接近二十四小時時升級告警、病歷二十三小時未簽通知醫師與主管、遺失平板能撤銷金鑰並阻止同步、重複公務預算在申報前被攔截、低量點自動進改善流程，以及已撤銷診次不能殘留在公開資料。

每個 P0 規則至少要有正向、邊界、逾界、例外核准、版本切換與歷史重現測試。對外介接另需契約測試、逾時、重送、亂序、重複、部分成功與回應格式變更測試。

11. 路線圖先凍結法遵與介接，再用試辦資料校準 KPI

AI 專案建議：可採四段式路線圖——先用六至八週完成流程訪談、法遵矩陣、現況介接與試辦點選定；再用十六至二十週建置 MVP；接著以八至十二週跑現場試辦與雙軌對帳；最後才擴充遠距、IDS、多院所及進階分析。這些週期是 PRD 的初步估算，不是官方工期或固定承諾。

KPI 要區分官方門檻與專案目標。每診至少三小時、低量五人門檻、休診四分之一、IDS 二十四小時上傳與次月二十日前申報屬外部規則；同步成功率、首次申報通過率、轉診閉環率、可用率與行政工時下降則是建議目標，應先蒐集至少一季基線再正式核定。

立項前最先決定三件事：第一，首批試辦只做西醫醫缺或同步 IDS；第二，院所現有健保卡、VPN、HIS／EMR 與測試環境到底能提供什麼；第三，現場裝置、網路與藥事交付模式。這三項會直接改變架構、估工、驗收與法遵範圍。

其餘高風險決策包括部署型態、病歷暫存邊界、跨院身分、通知管道、保存與刪除政策、原住民族語與文化適切需求，以及公開資料是否顯示醫師姓名與即時異動。

從 PRD 到試辦上線的建議路線

FIGURE 08 / FLOW
Phase 0｜發現與凍結

六至八週：流程、法遵、資料、介接、裝置與試辦範圍

Phase 1｜MVP 建置

十六至二十週：八個 Epic 的最小端到端閉環

Phase 2｜現場試辦

八至十二週：弱網、卡片、回寫、申報與營運雙軌驗證

Phase 3｜擴充

十二至十六週：遠距、IDS、全人照護與多院所

Phase 4｜規模化

以正式 KPI、事故復盤與政策版本持續優化

週期是本 PRD 的專案估算，應依院所採購、介接規格、法遵審查與試辦規模重新排程。

12. 最後的上線閘門：沒有正式介接與院所核准，就不能把 PRD 當成可直接申報的規格

不確定性：健保卡、VPN、申報檔、院所 HIS／EMR、藥局與支援報備的實際介接契約，必須由健保署正式文件、院所現況、供應商規格與測試環境共同確認。本文刻意不提供未驗證的 API、支付碼欄位或設備相容清單。

正式進入估工前，應完成一份可簽核的 Source-of-Truth Matrix、政策規則清冊、介接盤點、資料保護影響評估、臨床安全案例、試辦 RACI 與 UAT 資料集。任何規則若只有口頭說法，應標記為待主管機關或院所窗口確認，不得直接寫入 production 常數。

AI 建議：把這份網頁版藍圖當成評審與拆 Epic 的入口；完整 PRD 的 150 項 FR、36 項 BR、30 項 NFR、32 個 UAT、28 個畫面、12 類介接、16 項風險與 12 個待決策事項，仍應保留作為需求追溯與契約基線。