草案，未經院方核定。病人、角色與臨床數值皆為虛構；品項與代碼取自 B 目錄快照。 本文件不構成臨床建議，也不可用於真實病歷。

06 · HIS 整合對映

醫院 HIS 已有一套非 FHIR 的事件介面。本章定義 EMR 整合層如何把 FHIR 資源翻成這些事件，以及回應如何落回 FHIR。

臨床端永遠不碰本章的任何欄位。 這些欄位在 FHIR 資源上只以 Identifier 或 extension[hisTransmissionEvent] 形式出現。

6.1 事件總覽

6.2 PrescriptionCreated

送出對映

阻擋條件（送出前檢查）

阻擋一律在 $submit 回 422，醫囑維持已簽未送，不進入 sent。

回應落回

data.hisPrescriptionNumber        → MedicationRequest.identifier[system=…/his-prescription-number]
data.medications[].medicationRequestId → MedicationRequest.identifier[system=…/his-medication-request-id]
error / message / status          → extension[hisTransmissionEvent]

medicationRequestId 必須儲存，否則後續狀態回推與對帳無法配對。

回應的 medications[] 要與送出行逐行對帳：行數不符或有行對不上 → 標記 hisTransmissionStatus=unknown，產生人工處理 Task，不自動重送。

取消

PrescriptionCancelled:
  encounterNumber       ← Encounter.identifier
  hisPrescriptionNumber ← MedicationRequest.identifier[his-prescription-number]
  requester             ← 執行取消的醫師帳號（從權杖，非客戶端指定）

hisPrescriptionNumber 是整張 HIS 處方的號碼，不是 medicationRequestId。

送錯會取消到別張處方。整合層必須驗證這個 identifier 的 system 正確（BR-INT-007），不接受任意字串。

6.3 ServiceRequestCreated / Updated / Cancelled

送出對映

阻擋條件

修改的兩種語義

ServiceRequestUpdated 的 services[].serviceRequestNumber 決定行為：

orderNumber 必須填原需求單號，不得填詳細行碼（BR-INT-013）。這是兩個不同層級的識別碼：

• orderNumber = 整張需求單
• serviceRequestNumber = 單內的一行

取消

ipAddress 與 computerName 為取得＝C：由伺服器從連線取得，不接受客戶端提供，也不暴露權杖（BR-INT-014）。

6.4 MedicationChangeStatus（HIS → EMR）

這五個值沒有一個代表 eMAR 已給藥。

處理規則（BR-INT-004）：

1. 只寫入 MedicationRequest.extension[hisTransmissionEvent]，附 changeStatusTime。
2. 絕不建立或修改 MedicationAdministration。
3. 絕不改變 MedicationRequest.status（臨床狀態軸）。
4. 較舊的 changeStatusTime 不覆蓋較新的狀態（規格標【推論】，需 FPT 確認事件是否保證有序）。

6.5 檢驗結果回報（HIS → EMR）

HIS 送回報告時，整合層以 transaction Bundle 一次落地，確保報告與其逐項數值同時可見：

Bundle(transaction)
  ├─ Specimen        (upsert by TDL.1246 檢體編號)
  ├─ Observation ×N  (每個檢驗指標一筆)
  └─ DiagnosticReport(result → 上述 Observation)

落地規則：

最後一條來自原型原文：「來源未提供醫囑關聯，不按名稱猜測配對」。名稱相近就自動綁定會產生錯誤的醫囑－結果對應。

6.6 冪等與重試

冪等鍵

outbound_request.idempotency_key（取得＝C）由伺服器產生：

idempotency_key = sha256(encounterNumber ‖ resourceType ‖ resourceId ‖ versionId ‖ eventType)

• 同一資源同一版本重送 → 整合層回傳首次的結果，不重打 HIS。
• 資源版本改變 → 新的鍵，視為新事件。

重試

unknown 之後禁止自動重送（BR-ORD-007）。重送可能造成重複處方；必須由人確認 HIS 端的實際結果。

部分成功（Q-06）

ServiceRequestCreated 的回應是 data.services[] 陣列，但規格註明「未明確部分成功契約」。在 FPT 確認前，整合層採保守處理：

1. 逐行對帳；行數或行碼對不上即視為整體結果不確定。
2. 已取得 serviceRequestNumber 的行 → accepted。
3. 未取得的行 → unknown，不重送，產生人工處理 Task。
4. 不因為部分行成功就把整張標成成功。

6.7 整合層邊界

整合層是獨立元件，不是 FHIR server 的一部分：

• 對 FHIR server 用 system/ scope 的服務帳號。
• 所有寫入走標準 FHIR 互動（update ＋ If-Match），不繞過業務規則。
• 例外：HIS 唯讀資源（Patient、Encounter、DiagnosticReport…）只有整合服務帳號能寫；臨床使用者帳號仍被 READ-ONLY-SOURCE 擋下。
• 整合層的私有狀態（outbound_request、重試次數、原始 payload）存在自己的資料庫，不進 FHIR 資源。