前幾天介紹了 Patient、Observation、Encounter、Condition、MedicationRequest 與 DiagnosticReport 等常見的 FHIR Resource。
看到這裡，可能會產生一個疑問：
既然 FHIR 已經定義好資料格式，為什麼不同國家、醫院或專案還需要制定自己的規則？
原因是 FHIR 是一套提供全球使用的標準，必須保留足夠的彈性，才能因應不同地區的醫療制度。然而，彈性太大也可能造成另一個問題：即使大家都使用 FHIR，實際建立出來的資料仍然可能不一致。
因此，FHIR 提供了 Profile 與 Extension，讓各地能在共同標準上制定更明確的使用規則。
世界各國的醫療環境並不相同，例如：
以 Patient Resource 為例，FHIR 提供了病歷號、姓名、性別、生日、地址及聯絡方式等欄位。
但是，FHIR 不可能直接規定全世界都必須使用同一種身分證號碼，也無法要求每個國家的地址都使用相同格式。
所以，FHIR 的基本規格比較像是一套共同語言，先定義大家都能理解的資料架構，再由不同地區根據實際需求補充規則。
假設兩間醫院都使用 Patient Resource 記錄病人資料。
甲醫院可能只填寫：
乙醫院可能填寫：
兩邊的資料都可能符合基本的 FHIR 規格，但當系統需要交換資料時，仍然會遇到問題。
例如，接收端可能需要使用身分證字號確認病人身分，但傳送端沒有提供這項資料。又或者兩邊雖然都有填寫識別碼，卻使用不同的代碼或表示方式。
這表示：
使用同一套 FHIR Resource，不一定代表資料可以直接互通。
FHIR 解決了基本結構的問題，而 Profile 則進一步解決「這個情境應該如何使用該結構」的問題。
Profile 可以翻譯成「規範設定」或「實作規範中的資料限制」。
它是在原本的 FHIR Resource 上增加更明確的使用規則，例如：
Profile 並不是創造一種全新的 Resource，而是針對既有的 Resource 加上限制或說明。
可以把它想像成填寫表單。
FHIR Resource 是一張通用表單，上面準備了許多可能使用的欄位；Profile 則是某個單位針對特定用途制定的填寫規則，告訴使用者哪些欄位必填、應該填什麼，以及資料要用什麼格式呈現。
FHIR Resource 中的欄位通常會標示基數，也就是一個欄位最少與最多可以出現幾次。
常見的表示方式如下：
| 基數 | 意義 |
|---|---|
0..1 |
可以不出現，最多出現一次 |
1..1 |
必須出現，而且只能出現一次 |
0..* |
可以不出現，也可以出現多次 |
1..* |
至少出現一次，也可以出現多次 |
假設原始的 Patient Resource 規定某個欄位是 0..*，代表它不是必填，而且可以重複出現。
某個 Profile 可以根據實際需求，將它限制成 1..1，表示在這項應用中，該欄位必須填寫，而且只能提供一筆。
不過，Profile 通常只能讓規則變得更嚴格，不能違反原始 Resource 的基本定義。例如，原始規格最多只允許一筆資料，Profile 就不能把它改成可以出現多筆。
假設某個地區要制定一套病人基本資料交換規範，可能會在 Patient Profile 中要求：
原本的 Patient Resource 提供通用架構，Profile 則把這些欄位縮小到特定地區真正需要的範圍。
因此，當不同醫療機構都遵循同一個 Profile 時，接收資料的一方會更容易預測資料內容，也能降低雙方各自解讀的情況。
Profile 的功能不只有決定欄位是否必填，也可以限制資料所使用的代碼。
例如 Observation Resource 的 code 用來表示觀察或檢驗項目。原始 FHIR 規格允許使用不同代碼系統，但某個 Profile 可以進一步規定：
這類規則可以減少「名稱看起來相同，但系統無法確定是不是同一件事」的問題。
Profile 也能限制 Reference 的連結對象。例如，某個欄位雖然原本可以連結多種 Resource，但在特定 Profile 中，可以規定只能連結到符合指定 Profile 的 Patient 或 Organization。
即使 FHIR 已經提供許多欄位，仍然不可能預先涵蓋所有國家、醫院及專案的特殊需求。
當標準 Resource 沒有適合的欄位時，就可能使用 Extension，也就是「擴充欄位」。
Extension 的目的，是在不直接修改 FHIR 核心規格的情況下，補充特定情境需要的資料。
例如，某個地區可能需要記錄一項具有在地制度特色的資訊，但 Patient Resource 中沒有對應欄位。這時就可以透過 Extension 表達，而不需要另外發明一種與 FHIR 不相容的資料格式。
Extension 雖然代表擴充，卻不是讓使用者任意放入資料。
一個正式的 Extension 通常需要清楚定義：
其中，Extension 的網址非常重要。它不只是一般的網頁連結，也扮演識別這項定義的角色。
接收端看到這個網址後，才能知道該 Extension 代表什麼概念，而不是只看到一個無法理解的自訂欄位名稱。
兩者經常一起出現，但用途並不相同。
| 項目 | Profile | Extension |
|---|---|---|
| 主要用途 | 限制既有 Resource 的使用方式 | 補充原始 Resource 沒有的資料 |
| 是否建立新欄位 | 通常不會 | 會增加擴充內容 |
| 可以做什麼 | 規定必填欄位、出現次數、代碼與 Reference | 表達特殊或在地化資訊 |
| 使用目的 | 提高資料一致性 | 保留 FHIR 的擴充能力 |
| 兩者關係 | 可以規定應使用哪些 Extension | Extension 可被納入 Profile |
簡單來說：
Profile 是替既有格式制定更明確的規則；Extension 是在既有格式不足時補充新的資料內容。
並不是遇到任何新需求都要立刻建立 Extension。
在考慮擴充之前，通常應該先確認：
如果每間醫院都自行建立意思相近、定義不同的 Extension，反而會再次造成資料無法互通。
因此，能使用既有標準欄位時，通常應優先使用標準欄位；確實沒有合適方式時，再考慮採用已公開定義的 Extension。
Profile 與 Extension 通常不會單獨存在，而是被整理在 Implementation Guide，簡稱 IG，也就是「實作指南」中。
一份 FHIR Implementation Guide 可能包含：
Profile 告訴我們單一 Resource 應該如何調整，Implementation Guide 則從整體應用情境說明一套 FHIR 規範應該如何使用。
因此，當一個專案表示自己「使用 FHIR」時，還需要繼續確認它使用的是哪個版本、遵循哪一份 Implementation Guide，以及套用了哪些 Profile。
FHIR 希望建立跨系統、跨機構甚至跨國家的醫療資料交換基礎，但醫療制度本身具有高度在地性。
例如，台灣可能有自己的：
如果只使用原始 FHIR Resource，可能不足以清楚規定這些資料要如何呈現。
在地 Profile 的作用，就是在不脫離國際標準的前提下，讓 FHIR 能配合當地的醫療制度。
可以將三者的關係理解成：
不一定。
Profile 能提升特定情境中的一致性，但如果不同單位各自制定大量彼此不相容的 Profile，仍然可能形成新的資料差異。
因此，制定 Profile 時需要在兩件事之間取得平衡：
一份好的 Profile，不是把所有欄位都設成必填，也不是加入大量自訂 Extension，而是清楚定義完成資料交換真正需要的內容。
同時，如果已經有國家級或產業共同採用的實作指南，優先使用共同規範通常比各醫院自行制定規則更有利於互通。
FHIR 的基本規格需要適用於全球，因此保留了相當大的彈性。但不同系統若以不同方式使用這些欄位，即使都宣稱採用 FHIR，資料仍然可能無法順利交換。
Profile 可以限制既有 Resource 的使用方式，例如規定必填欄位、出現次數、代碼系統及 Reference 對象；Extension 則用來表達原始 Resource 沒有提供的特殊資訊。
這些定義通常會被整理在 Implementation Guide 中，形成特定國家、地區或應用情境共同遵循的規則。
了解 Profile 與 Extension 之後，就能發現 FHIR 的互通性不只來自共同的資料格式，也來自大家是否遵循同一套實作規範。
下一篇將介紹 Day 27｜TW Core IG：台灣如何制定自己的 FHIR 規範？，進一步認識 FHIR 在台灣醫療環境中的在地化方式。
iThome鐵人賽
看影片追技術