系統架構與資安設計

本頁說明正式系統的設計；您正在看的是展示原型。兩者的差別只有一個：原型跑在公有雲上，所以它把所有檔案處理放在瀏覽器端，連檔案都不收。

兩套系統，以轉診識別碼相連

公開的衛教與評估站不含任何可識別個人資料；收件系統在院內網路邊界內，並以身分證字號對應轉診識別碼。個資只存在於院內這一側，從不流經公開站。

  外院轉診端                  本院 DMZ（資訊需求單申請範圍）          院內作業
  ───────────                ────────────────────────────          ────────
  cart.hematology.tw
  （公開站‧無個資）
  完成適應症評估
        │
        │ 取得 REF-26-XXXX
        ▼
  依連結進入 ─────────────▶  cartref 收件系統
  以已核可帳號登入             ‧ Google 帳號登入
  上傳原始檔案                 ‧ 手機簡訊二次驗證
                              ‧ 格式檢核 ＋ 病毒掃描
                              ‧ 依識別碼歸檔
                              ‧ 稽核紀錄
                                      │
                                      │ 個管師自院內主動下載
                                      ▼
                                                        ‧ 併入正式病歷
                                                        ‧ 特殊專案審查
                                                        ‧ CAR-T 個案登錄
                                      │
                                      ▼
                                檔案自本機刪除

規格摘要

出自 2026-09-15 送出之《資訊作業需求單》。

虛擬主機	4 vCPU ‧ 8 GB RAM ‧ 系統碟 100 GB ‧ 資料碟 300 GB（不收影像後可下修，見備註）
對外開放	僅 TCP 443（HTTPS）。TCP 80 僅供轉址與憑證更新
對內連線	無。不連 HIS、PACS、檢驗系統或任何院內核心網段
身分驗證	Google 帳號＋手機號碼驗證＋個管師核可；不要求證書或實名驗證
帳號權限	唯寫。只能對自己發出的識別碼上傳，不能瀏覽或下載任何資料
允許格式	PDF、JPEG、PNG、HEIC；以檔案內容判定，不看副檔名。不收 DICOM 與壓縮檔
醫學影像	不經本系統傳輸。原始影像請病人或家屬攜帶光碟到院，直接匯入 PACS
容量上限	單檔 50.0 MB ‧ 單案 300.0 MB
病毒掃描	每檔即時掃描，未過隔離並通知
靜態加密	資料磁碟加密（LUKS 或虛擬化平台層級）
稽核紀錄	帳號、時間、來源 IP、檔名、雜湊值、識別碼、掃描結果；保留 ≥ 1 年
保存政策	歸檔後 7 日刪除 ‧ 未成案 90 日刪除 ‧ 備份保留 ≤ 30 日
病人對應鍵	身分證字號／居留證號，對應轉診識別碼。畫面與稽核紀錄只顯示遮蔽值
個資範圍	身分證字號與報告內之姓名、病歷號僅存在於本系統；公開站永不收受

幾個「為什麼」

為什麼不直接讓公開站 cart.hematology.tw 收檔案？

公開站跑在境外雲端。一旦它收下一份含病人姓名的病歷，就成為醫院治理範圍之外的第三方平台在儲存病歷，保存年限、外洩通報、跨境儲存的義務全部跟著上身。兩種工作負載的法律性質不同，不該共用同一個桶子。

為什麼不用科內既有的 medsrv02？

它沒有公開 DNS、沒有對外連線、用的是內部自簽憑證。外院連不進來，而且要改造成對外服務，等於重做一台。

為什麼要另外開一台，而不是接在 HIS 上？

刻意不接。這台主機對院內核心系統零存取權，檔案由個管師從院內端主動下載。萬一它被攻陷，攻擊者拿到的是一個空的暫存區，不是通往 HIS 的跳板。

為什麼接受 Google 帳號，而且不做實名驗證？

轉診端是年 10–30 人次的零散使用者，而且實際填單的常常是專科護理師或個案管理師，不是醫師。若要求院方核發帳號或上傳證書，申請流程的摩擦會直接讓轉診退回傳真。判斷的關鍵在於這個帳號能做什麼：它只能對自己發出的識別碼上傳，不能瀏覽、不能下載任何資料。一個假帳號拿不到任何東西，最壞的情況是送進垃圾檔案，而檔案要過格式檢核與病毒掃描。所以申請只要 Google 帳號、可驗證的手機、服務單位、真實姓名與職稱——真正有效的確認是那支打得通的手機，它同時是個案討論的聯絡管道。

為什麼檔案要刪掉？

把這台定位成「傳輸暫存區」而非病歷保存系統，它就不構成《電子病歷製作及管理辦法》下的儲存系統，資安與法遵的負擔差很多。正式病歷的保存責任仍在院內既有系統。

原型與正式系統的差異

項目	展示原型（本站）	正式系統（院內 DMZ）
主機位置	公有雲	成大醫院 DMZ 虛擬主機
檔案內容	完全不離開瀏覽器，處理後丟棄	上傳至主機，加密儲存至歸檔
格式檢核與雜湊	瀏覽器端（同一份規則程式碼）	伺服器端
病毒掃描	不執行，僅標示位置	每檔即時掃描
登入	輸入示範帳號，驗證碼顯示在畫面上	Google OAuth ＋真實簡訊
收件與稽核紀錄	瀏覽器 localStorage	院內資料庫，保留 ≥ 1 年
資料	全部虛構	真實轉診案件