前面的文章分別介紹了 Patient、Encounter、Condition、Observation、MedicationRequest 與 DiagnosticReport。

單獨閱讀每一種 Resource 時，可能會覺得它們只是不同種類的資料表格。但在真實的醫療情境中，病人基本資料、就醫紀錄、診斷、檢驗結果與藥物處方並不是互相獨立的。

它們通常共同描述一段完整的醫療過程。

今天將透過一次虛構的門診情境，把前面學過的 Resource 串在一起，理解 FHIR 如何利用 Reference 建立資料之間的關係。

本文中的人物、病情與醫療資料均為虛構內容，只用於說明 FHIR 資料結構，不構成任何醫療建議。

從一次門診情境開始

假設有一位虛構病人「王小明」，因為最近經常感到口渴、疲倦，到醫院家醫科門診就醫。

門診過程大致如下：

1. 病人完成掛號。
2. 醫師進行問診。
3. 醫師記錄初步診斷。
4. 醫師開立血糖檢驗。
5. 檢驗室完成檢驗。
6. 系統產生檢驗結果與報告。
7. 醫師根據病情開立藥物。
8. 病人完成此次門診。

如果使用傳統方式描述，可能會把全部內容放進一份很大的病歷文件中。

FHIR 的做法則不太一樣。它會將不同種類的醫療資訊分成多個 Resource，再透過 Reference 將它們連結起來。

這次門診需要哪些 Resource？

在這個虛構情境中，可能出現以下 Resource：

這些 Resource 各自負責描述一類資料。

如果只看到其中一筆 Observation，可能知道某次血糖檢驗的結果，卻不知道這筆結果屬於哪一位病人、發生在哪次門診，也不知道相關報告與診斷是什麼。

Reference 的作用，就是建立這些背景關係。

Patient：所有資料共同指向的病人

Patient Resource 用來記錄病人的基本資料，例如：

• 病人識別碼
• 姓名
• 性別
• 出生日期
• 地址
• 聯絡方式

在這次情境中，Patient 代表王小明本人。

Encounter、Condition、Observation、MedicationRequest 與 DiagnosticReport 等臨床資料，通常都會透過 subject 等欄位連結到 Patient。

這樣系統才能知道：

• 這次門診屬於誰
• 這項診斷屬於誰
• 這筆檢驗結果屬於誰
• 這張藥物處方開給誰

Patient 可以視為整個病人資料網絡中的核心對象，但它不會直接把所有臨床紀錄放進自己的內容裡。

Encounter：把同一次就醫資料放在共同情境中

Encounter 代表一次病人與醫療體系之間的互動，例如門診、急診、住院或遠距診療。

在這個案例中，Encounter 代表：

王小明在某一天前往家醫科接受門診服務。

Encounter 可能包含：

• 就醫狀態
• 就醫類型
• 門診科別
• 就醫起訖時間
• 參與照護的醫療人員
• 提供服務的醫療機構
• 病人身分

Encounter 會透過 subject 連結到 Patient，也可以透過 participant 連結到參與這次就醫的 Practitioner。

其他臨床 Resource 則可以連回同一筆 Encounter，表示它們是在這次門診中產生的資料。

因此，Encounter 很像這次門診的共同資料夾，協助系統將同一次就醫產生的診斷、檢驗及處方串在一起。

Practitioner：這筆資料與哪位醫療人員有關？

Practitioner Resource 用來描述醫師、護理師、藥師、醫檢師等醫療專業人員。

在一次門診中，醫療人員可能以不同角色出現在不同 Resource：

• Encounter 的參與醫師
• Condition 的記錄者
• Observation 的執行者
• DiagnosticReport 的報告負責人
• MedicationRequest 的開立者

這些角色不一定全部由同一個人擔任。

例如，門診醫師負責問診與開立檢驗，但實際執行檢驗的可能是醫檢師，確認檢驗報告的也可能是另一位專業人員。

FHIR 透過不同欄位連結 Practitioner，能更清楚表達每位人員在醫療過程中的責任。

Organization：醫療服務由哪個機構提供？

Organization Resource 可以表示醫院、診所、檢驗機構、藥局或其他組織。

在這個虛構案例中，Organization 可以代表王小明就診的醫院。

Encounter 可以連結到提供此次醫療服務的機構；DiagnosticReport 也可能包含負責出具報告的單位。

如果檢體被送到院外檢驗機構，門診醫院與檢驗機構甚至可能是不同的 Organization。

所以，Organization 可以協助回答：

• 這次門診在哪間醫院發生？
• 哪個單位提供醫療服務？
• 檢驗由哪個機構完成？
• 報告由哪個單位出具？

Condition：這次門診記錄了什麼健康問題？

Condition Resource 用來表示病人的疾病、診斷或健康問題。

在這個案例中，醫師可能根據病人的症狀及現有資料記錄一項健康問題。若診斷尚未完全確定，也可以透過臨床狀態與確認狀態表達目前的判斷程度。

Condition 通常會連結：

• subject：這項健康問題屬於哪位病人
• encounter：這項問題與哪次就醫有關
• recorder：由誰記錄
• asserter：由誰判斷或主張這項狀況

同一位病人可能有很多筆 Condition，但只有其中一部分與本次門診直接相關。

透過 Encounter 的連結，系統才能區分這次門診新記錄的問題，以及病人過去已存在的疾病史。

Observation：記錄實際觀察或測量結果

Observation Resource 用來記錄檢驗結果、生命徵象及其他可觀察到的資料。

在這次門診中，Observation 可能代表：

• 血糖檢驗結果
• 血壓
• 體溫
• 身高
• 體重
• 其他檢驗數值

假設王小明接受血糖檢驗，Observation 會說明：

• 檢驗項目是什麼
• 結果數值是多少
• 使用什麼單位
• 何時進行檢驗
• 結果狀態
• 檢驗對象是誰
• 與哪次門診有關

Observation 可以透過 subject 連結 Patient，並透過 encounter 連結這次門診。

如此一來，系統不只知道檢驗數值，也知道它的病人與就醫背景。

DiagnosticReport：把多筆檢驗結果整理成報告

一次檢驗報告可能包含不只一個檢驗項目。

例如，一份血液檢驗報告可能包含血糖、肝功能、腎功能及其他數值。每一個檢驗項目可以分別使用 Observation 表達，而 DiagnosticReport 則負責描述整份報告。

DiagnosticReport 可能包含：

• 報告類型
• 報告狀態
• 病人
• 相關門診
• 檢驗時間
• 報告時間
• 報告結論
• 多筆檢驗結果

其中，result 可以連結到一筆或多筆 Observation。

因此，DiagnosticReport 與 Observation 的關係可以理解為：

• Observation：單一檢驗項目或測量結果
• DiagnosticReport：將相關結果組成一份完整報告

需要注意的是，DiagnosticReport 並不是取代 Observation。兩者負責的層次不同，通常會互相配合。

MedicationRequest：醫師開立了什麼藥物？

MedicationRequest Resource 用來表示醫師對藥物使用提出的請求或醫囑。

在這次門診中，如果醫師決定開立藥物，MedicationRequest 可能記錄：

• 藥品
• 病人
• 開立者
• 開立時間
• 使用方式
• 劑量
• 頻率
• 用藥天數
• 開立原因
• 相關門診

MedicationRequest 可以透過：

• subject 連結 Patient
• encounter 連結本次門診
• requester 連結開立處方的 Practitioner
• reasonReference 連結相關的 Condition 或 Observation

這讓系統可以知道藥物是開給誰、在哪一次門診開立，以及可能與哪項健康問題或檢查結果有關。

不過，MedicationRequest 表達的是「用藥請求或醫囑」，不等於藥品已經完成調劑，也不代表病人實際服用了藥物。不同階段可能需要其他 Resource 表達。

把整段門診關係串起來

這次虛構門診中的主要連結可以整理如下：

透過這些 Reference，分散的 Resource 便能共同描述完整的門診過程。

Reference 為什麼比重複填寫更好？

假設每一筆 Observation 都重新寫入病人的完整姓名、生日、地址及電話，可能產生幾個問題。

第一，如果病人的地址變更，就必須修改很多筆資料。

第二，如果不同資料中的姓名或生日不一致，系統就難以判斷哪一筆才正確。

第三，大量重複內容會增加資料儲存與維護負擔。

FHIR 透過 Reference 連結 Patient，使其他 Resource 不需要重複保存全部病人基本資料。

這種設計具有幾個優點：

• 減少重複資料
• 降低內容不一致
• 保留各 Resource 的明確責任
• 方便系統沿著關聯取得資料
• 讓相同 Resource 可以被不同情境引用

Reference 並不是把資料複製一份，而是告訴系統應該到哪一筆 Resource 尋找相關內容。

為什麼同時需要 Patient 與 Encounter？

可能有人會疑惑：既然所有資料都已經連結到 Patient，為什麼還需要 Encounter？

因為 Patient 只能說明資料屬於哪個人，Encounter 則能說明資料發生在哪一次就醫。

假設王小明一年內看了五次門診，也做過多次血糖檢驗。所有 Observation 都會連到同一位 Patient，但可以連到不同的 Encounter。

這樣系統才能區分：

• 哪次門診開立了哪項檢驗
• 哪筆結果屬於哪次就醫
• 某張處方在哪次門診產生
• 某項診斷是何時記錄的

Patient 提供人物身分，Encounter 提供醫療事件的情境，兩者不能互相取代。

Resource 之間不一定只有一種連結方式

FHIR 的資料關係不一定都是單向或一對一。

例如：

• 一位 Patient 可以有多筆 Encounter
• 一次 Encounter 可以產生多筆 Observation
• 一份 DiagnosticReport 可以連結多筆 Observation
• 一次 Encounter 可以有多筆 MedicationRequest
• 一位 Practitioner 可以參與多次 Encounter
• 一個 Organization 可以提供多次醫療服務

此外，某些關係可以從不同方向查找。

Observation 可能直接記錄自己所屬的 Encounter，但 Encounter 不一定會列出該次門診產生的每一筆 Observation。系統可以透過 Observation 中的 Reference 與查詢條件找出相關資料。

所以閱讀 FHIR 時，不能只看某個 Resource 裡是否「包含」另一筆資料，還要觀察 Reference 指向哪裡。

Bundle 在這個情境中扮演什麼角色？

如果系統需要一次傳送與門診相關的多筆 Resource，可以使用 Bundle 將它們集合起來，例如：

• 一筆 Patient
• 一筆 Encounter
• 一筆 Condition
• 多筆 Observation
• 一筆 DiagnosticReport
• 一筆或多筆 MedicationRequest

但 Bundle 只是把多筆 Resource 放在同一個交換單位中，不會自動建立它們的臨床關係。

真正表示「這筆 Observation 屬於哪位病人、與哪次門診有關」的，仍然是 Resource 裡面的 Reference。

因此：

• Bundle 負責集合及傳送多筆 Resource
• Reference 負責表達 Resource 之間的關係

即使這些 Resource 沒有放在同一個 Bundle 裡，只要 Reference 可以被正確解析，它們仍然能維持彼此的關聯。

讀懂一組 FHIR 資料的方法

面對多筆互相連結的 FHIR Resource 時，可以先從幾個問題開始理解。

1. 這組資料在描述誰？

先找出 Patient，確認其他臨床資料的 subject 是否指向同一位病人。

2. 資料發生在哪一次就醫？

找出 Encounter，再確認 Condition、Observation、DiagnosticReport 與 MedicationRequest 是否與該次 Encounter 有關。

3. 有哪些健康問題？

查看 Condition，了解此次就醫記錄了哪些疾病、診斷或健康問題。

4. 做了哪些觀察或檢驗？

查看 Observation，了解檢驗項目、結果、單位及時間。

5. 哪些結果組成同一份報告？

查看 DiagnosticReport 的 result，找出報告所包含的 Observation。

6. 開立了哪些藥物？

查看 MedicationRequest，確認藥物、開立者、用法及相關原因。

7. 哪些人與機構參與其中？

沿著 Reference 找出 Practitioner 與 Organization，理解醫療服務的參與者。

透過這個順序，就能從多筆看似分散的 Resource，慢慢還原完整的醫療情境。

資料互相連結後，就一定正確嗎？

不一定。

Resource 可以互相連結，只代表資料之間建立了關係，不代表內容一定正確或完整。

系統仍需確認：

• Reference 指向的 Resource 是否存在
• 病人身分是否一致
• Encounter 時間是否合理
• 診斷與檢驗資料是否屬於同一次就醫
• 代碼與單位是否符合規範
• Resource 是否符合指定 Profile
• 使用者是否具有存取這些資料的權限

如果 Observation 連到錯誤的 Patient，即使格式完全符合 FHIR，也可能造成嚴重的病人安全問題。

因此，FHIR 資料交換除了結構正確，還必須重視資料品質、身分比對、臨床合理性與資訊安全。

今日小結

一次門診不會只產生一筆資料，而是由病人、就醫、診斷、檢驗、報告、藥物、醫療人員與醫療機構等多種資訊共同組成。

FHIR 將這些內容拆分成不同 Resource，再透過 Reference 建立彼此的關係：

• Patient 表示資料屬於哪位病人
• Encounter 表示資料發生在哪次就醫
• Condition 表示疾病、診斷或健康問題
• Observation 表示單一觀察或檢驗結果
• DiagnosticReport 將多筆結果組成報告
• MedicationRequest 表示開立的用藥請求
• Practitioner 與 Organization 表示參與的人員和機構
• Bundle 可以集合多筆 Resource，但真正的資料關係仍由 Reference 表達

理解這些連結之後，FHIR 就不再只是許多獨立的 JSON 欄位，而是一張能呈現完整醫療過程的資料網絡。

下一篇將來到系列最後一篇：Day 30｜完賽回顧：30天後，我真的看懂 FHIR 了嗎？，回顧這30天學過的觀念，以及醫資學生可以如何繼續認識醫療資料交換。

參考資料

1. HL7 FHIR R4—References
2. HL7 FHIR R4—Patient
3. HL7 FHIR R4—Encounter
4. HL7 FHIR R4—Condition
5. HL7 FHIR R4—Observation
6. HL7 FHIR R4—DiagnosticReport
7. HL7 FHIR R4—MedicationRequest
8. HL7 FHIR R4—Bundle