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

02 · 資源對照

2.1 總覽

左欄是規格物件（29 份 S／N 規格的 物件.欄位）與 icu-vue 原型的 store 實體，右欄是本 API 採用的 FHIR R4 資源。

order_execution_link 在 FHIR 不需要獨立資源：MedicationAdministration.request 與 Procedure.basedOn 就是這條連結，版本鎖定靠帶版本的 reference（MedicationRequest/xxx/_history/2）。

2.2 病人、就醫與照護關係

Patient（唯讀）

view.age_at_view 標註「出生日期於檢視時點計算；不落地」——API 不回傳年齡欄位，由客戶端從 birthDate 算。

Encounter / Location（唯讀）

床位由 HIS 主導，EMR 唯讀顯示——原型的病人總覽已經這樣標註。

EpisodeOfCare（ICU 照護段）

icu_episode.id → EpisodeOfCare，status=active、type=ICU、patient、managingOrganization、period。ICU 照護段與 Encounter 是多對一：一次住院可能有多段 ICU。原型的 ICU-A 就是這個。

CareTeam（本班照護名單）

原型的「確認照護名單」對應 care_assignment.confirmed_at（取得＝M）。

CareTeam
  status        : active
  subject       : Patient/…
  encounter     : Encounter/…
  participant[] : { member: PractitionerRole/…, role: 主責醫師|主護|照會醫師, period }
  extension[assignmentSource] : "示範院方預先分派"

「確認」這個動作本身記在 Provenance（activity = …/provenance-activity#roster-confirm，target = CareTeam/…），而不是 CareTeam 上的一個時間欄位。理由：同一份名單可以被不同班別、不同人各自確認一次，每次都要留人與時間。

照會醫師不進 CareTeam。 照會關係由 ServiceRequest(category=consultation) 的 performer 表達；照會醫師能看到病人資料，但不是照護團隊成員，也不能開立醫囑（見 04 BR-AUTH-003）。

2.3 藥物醫囑

MedicationRequest

三個必須人工選、不可推定的欄位（規格原文）：

• medication_code：必須來自已同步目錄，不以顯示品名送出。
• route：須與 HIS 藥品目錄一致，不能用本地 PO/IV 假定等值。
• rate_value：需單位與濃度，不把 mg/kg/min 直接當 mL/h。

API 對這三欄一律要求 coding.system ＋ coding.code 齊全，只給 text 會被拒（BR-MED-001）。

MedicationAdministration（eMAR 給藥執行）

status 對應：

「實際劑量」預填自醫囑但必須由執行者確認——API 不會因為 dosage.dose 等於醫囑值就跳過驗證，BR-MED-004 要求差異時填 note。

2.4 檢驗、檢查與照護醫令

ServiceRequest

priority 值域衝突（Q-05）。 規格原文：「修改 priority 無值域；建立 severity 為 1 正常／2 急／3 特急；不能直接互換」。因此：

• EMR 內部以 FHIR priority（routine / urgent / stat）儲存。
• 送 HIS 時由整合層對映到建立用的 severity 1/2/3。
• 修改（ServiceRequestUpdated）時不送 priority，因為 HIS 該介面無值域。
• 對映表未經 FPT 確認前，整合層以 routine→1 / urgent→2 / stat→3 暫行，並在 outbound_request 留下所用對映版本。

Procedure（照護與處置執行）

N07 照護空間 的規格物件就是 procedure。照護醫令（原型的 kind=care）以 ServiceRequest 開立、以 Procedure 記錄執行：

Procedure
  status      : completed | not-done | on-hold
  basedOn     : ServiceRequest/…（帶版本）
  subject     : Patient/…
  encounter   : Encounter/…
  performedDateTime
  performer[] : { actor: PractitionerRole/… }
  statusReason: 未執行／延遲原因

procedure_performer.phau_thuat_vien_thu_thuat_vien／bac_si_gay_me_vo_cam → Procedure.performer[].function 區分術者與麻醉。手術紀錄在 Phase 1 為唯讀接收，EMR 不提供編修（原型的手術紀錄分頁已如此）。

2.5 檢驗檢查結果與判讀

DiagnosticReport ＋ Observation（皆為 HIS 唯讀）

一份報告拆成兩層：

DiagnosticReport (status=final)
  ├─ identifier      : HIS order_number
  ├─ basedOn         : ServiceRequest/…
  ├─ specimen        : Specimen/…
  ├─ issued          : TDL 結果時點
  ├─ conclusion      : 文字結論
  └─ result[]        : → Observation（每個檢驗指標一筆）

Observation (status=final)
  ├─ code            : 指標字典【Q-02 未定】
  ├─ valueQuantity   : 數值 ＋ 單位 (TDL.1258)
  ├─ interpretation  : 來源旗標。無旗標則省略
  └─ derivedFrom / partOf : DiagnosticReport

每個指標必須是獨立 Observation，不可塞進 DiagnosticReport.conclusion 的文字。 原型的趨勢圖需要逐指標時間序列，只有這種結構撐得住。

Specimen 欄位齊備（TDL.1246–1254：檢體編號、採檢人員／時間、接收人員／時間、種類、品質），全部為 H，唯讀落地。

已閱與判讀 → Provenance

result_review.seen_at / processed_at 是 M（醫護手動），但 DiagnosticReport 是 HIS 唯讀資源。因此不改報告，改記 Provenance：

「已閱」是真正的讀取動作，用 HL7 標準碼 http://terminology.hl7.org/CodeSystem/v3-DataOperation#READ。

「判讀」「核對」「交班接收」「名單確認」是臨床業務動作，不是資料操作——v3-DataOperation 沒有對應碼（該系統只有 OPERATE／CREATE／READ／UPDATE／DELETE／APPEND／MODIFYSTATUS 等），因此改用本地 CodeSystem（見 2.12），不硬套語義不符的標準碼。

已閱、判讀、工作結案是三件獨立的事（原型原文：「某一項已回／已處理不清除其他待回」）。結案由 Task 表達，且 BR-TASK-002 要求來源報告必須已回報且已有判讀紀錄才能結案。

2.6 生理量測

Observation（一般項目）

Observation.code 一律帶兩個 coding：LOINC（若已確認）＋ 院內／TDL 碼。未確認 LOINC 的項目只帶院內碼，不硬湊。

血壓（component 結構）

規格的 observation_component.value_num 對應 TDL.0094／TDL.0095，是同一次量測的兩個子項——這正是 FHIR 的 component 模式：

Observation
  code      : 85354-9 (Blood pressure panel)
  effectiveDateTime : 一次量測時間（兩子項共用）
  component[0] : code 8480-6 (Systolic)  + valueQuantity mmHg  + coding TDL.0094
  component[1] : code 8462-4 (Diastolic) + valueQuantity mmHg  + coding TDL.0095

不可拆成兩筆獨立 Observation，否則收縮／舒張壓會在時間軸上失去配對。原型的 store.dispatch('measureBP') 已經強制兩子項同時填寫，API 沿用（BR-OBS-002）。

輸注速率觀察

infusion_check → Observation：

Observation
  code       : 輸注流速（TDL.0399）
  valueQuantity : 速率 ＋ 單位（mL/h…）
  partOf     : MedicationAdministration/…
  note       : 觀察與差異說明（必填）
  extension[notCountedAsIntake] : true

原型明訂「輸注觀察不計為實際 I/O；無幫浦綁定、自動讀值或治療門檻」。notCountedAsIntake 擴充讓下游彙總不會誤把它算進入量。設備來源（取得＝D）時填 Observation.device。

2.7 病歷文件

所有病歷型文件都是 Composition。

Progress Note 的 SOAP

Composition
  status   : preliminary（草稿）| final（已簽）| amended（更正後）
  type     : 11506-3
  date     : 病程時間 TDL.0347
  author   : PractitionerRole/…
  section[0] : { code: S, text.div }
  section[1] : { code: O, text.div, entry[] → Observation/DiagnosticReport }
  section[2] : { code: A, text.div, entry[] → Condition }
  section[3] : { code: P, text.div }

composition_section.content（TDL.0348 病情進展）→ section.text.div；composition_reference.source_version → section.entry，必須是帶版本的 Reference，這樣「引用當時看到的數值」不會被後來的更正改掉。

版本與更正

更正流程見 01 §1.4。

出院準備衛教

原型把衛教內容放在 Progress Note 的「出院準備」分頁（sections.educationAudience/educationContent/educationTeachBack）。對映為 Composition.section[code=discharge-education] 的三個子欄位，並以 extension[educationTemplate] 記錄所用的衛教組套 id（EDU-SET-*）——組套來源必須保留，這樣才看得出哪些字是模板、哪些是醫師改寫的。

2.8 臨床工作與交班

Task

狀態對映：

交班（SBAR）

交班版本 = Composition，接收 = Provenance：

Composition (SBAR 交班)
  status    : final
  type      : 【Q-04】
  author    : 交出者
  extension[handoverReceiver] : 接班者 PractitionerRole
  relatesTo[replaces]         : 前一版（若為更正）
  section[]                   : S / B / A / R
  section[tasks].entry[]      : → Task（交出當下的未結工作快照）

Provenance (接收)
  target   : Composition/…（該版本）
  activity : …/provenance-activity#handover-receive
  agent    : 接班者
  recorded : 接收時間

接收的副作用是 Task.owner 轉移，這由伺服器在同一個 transaction 內完成（BR-HO-004）。

2.9 照會與必要溝通

照會

規格 S15 的物件列的是 composition / clinical_task，本設計加上 ServiceRequest 讓「請求」有獨立生命週期（狀態 active → completed），與待辦分離。

必要溝通

Communication：category（家屬溝通／同意拒絕討論／藥事會診聯繫）、recipient → RelatedPerson、payload[0].contentString、sender。

這不是實際發送。 Communication.status 一律 completed（表示「已記錄這次溝通發生過」），API 不觸發任何通知。

2.10 同意書與電子簽章

S16 有 110 個欄位，consent 物件本身有 11 個。結構：

• Consent：status、scope=patient-privacy|treatment、category、patient、dateTime、performer（簽署人）、provision（同意／拒絕的範圍）。
• RelatedPerson：related_person 的 30 個欄位（承諾人姓名、身分證號、發證日期／地點、地址、電話、與病人關係…）。
• Composition：同意書表單全文與版面（form_definition.form_code → Composition.type）。
• Provenance.signature：

Provenance
  target    : Composition/…（被簽的那一版）
  recorded  : signature.signed_time
  agent     : { who: PractitionerRole/… , type: signer_role }
  signature : {
      type       : 1.2.840.10065.1.12.1.1 (Author's Signature)
      when       : 簽署時間
      who        : 簽署人
      targetFormat : application/fhir+json
      sigFormat  : application/jose | application/pkcs7-signature
      data       : base64（signature_blob）
  }

signature.signature_hash 與驗證服務輸出屬於取得＝C，由伺服器產生與驗證，客戶端不可送。

2.11 本地擴充清單

全部掛在 http://icu.emr.local/StructureDefinition/ 下。

catalogSnapshot 很重要：原型的 clinical.snapshot() 會連 catalogVersion 與來源檔 sha256 一起存下。目錄之後改版時，已開立的醫囑仍看得到當初的品項內容——這是稽核可辯護性的基礎。

copyTrace 對應原型的「快速複製前一日病程」：記錄複製來源與哪些 SOAP 段落被改過，因為「複製不視為已核對」。

2.12 編碼系統

B 目錄品項的中文譯名未核定。 coding.display 一律填來源原文（越文／英文），中文譯名放 coding.extension[reviewTranslation]，避免未核定譯名被當成正式名稱往下游傳。

停用品項（active=false）不得用於新開立，但既有醫囑仍要能讀回——BR-CAT-001。