前言

在上一篇文章中，我們認識了Reference，了解Patient、Encounter及Observation等不同Resource如何互相連結。

但是，系統知道一筆Observation屬於哪位病人，仍然不代表它能理解Observation記錄的是什麼。

例如：

{
  "code": {
    "text": "血糖"
  },
  "valueQuantity": {
    "value": 95,
    "unit": "mg/dL"
  }
}

人類看到「血糖」兩個字，大概可以理解這是一筆血糖檢驗結果。

但對電腦來說，仍然可能存在許多問題：

• 這是空腹血糖、飯後血糖還是隨機血糖？
• 檢體是血液、血清還是血漿？
• 其他醫院是否使用相同名稱？
• 英文系統要如何辨認「血糖」？
• 系統要如何找出所有相同檢驗項目？

為了讓不同系統對醫療資料有更一致的理解，我們需要使用標準化的醫療代碼。

只用文字記錄會有什麼問題？

假設三家醫院都在記錄高血壓診斷：

人類可以判斷這些文字可能在描述相同或相近的疾病，但電腦不一定知道。

系統如果只使用文字比對：

高血壓 = Hypertension = HTN

就必須另外建立大量對照規則。

除此之外，自由文字還可能受到以下因素影響：

• 使用不同語言
• 簡稱不同
• 同義詞不同
• 拼字錯誤
• 全形與半形差異
• 標點符號不同
• 輸入習慣不同
• 醫療概念的詳細程度不同

例如：

第二型糖尿病

第2型糖尿病

Type 2 diabetes

T2DM

如果只依靠文字，系統可能把這些內容當成不同疾病。

代碼可以看成醫療概念的共同編號

標準代碼的作用，是替特定醫療概念提供較一致的識別方式。

例如，在特定ICD-10分類中，原發性高血壓可以使用：

I10

系統除了記錄代碼，也可以保留方便人類閱讀的文字：

{
  "system": "http://hl7.org/fhir/sid/icd-10",
  "code": "I10",
  "display": "Essential (primary) hypertension"
}

其中：

• system說明代碼來自哪一套代碼系統。
• code是電腦主要使用的代碼。
• display是適合人類閱讀的名稱。

這樣即使不同系統顯示「高血壓」、「Hypertension」或其他語言，仍然可以透過相同的system及code辨認概念。

不過，ICD有不同版本及各國修訂版本，實際使用時必須確認採用的版本與規則，不能只看到代碼相同就直接認定意義完全一致。

為什麼不能只有code？

假設收到：

{
  "code": "12345"
}

這個代碼代表什麼？

它可能是：

• 疾病代碼
• 檢驗代碼
• 藥品代碼
• 醫院院內代碼
• 檢體編號
• 醫令編號

不同代碼系統可能出現相同的字母或數字，因此不能只看code。

FHIR中的Coding通常會搭配system：

{
  "system": "https://hospital.example.org/CodeSystem/local-test",
  "code": "12345",
  "display": "範例檢驗項目"
}

system就像代碼所屬的字典，code則像字典中的編號。

可以將兩者一起看成：

代碼系統＋代碼＝較明確的醫療概念

常見醫療代碼系統

醫療領域有許多不同代碼系統，因為疾病、檢驗、臨床術語及藥品的用途並不相同。

今天先認識幾種常見名稱。

ICD：疾病與健康問題分類

ICD的全名是：

International Classification of Diseases

中文通常稱為「國際疾病分類」。

ICD由世界衛生組織WHO維護，主要用於疾病、健康問題及死亡原因的分類、記錄、統計與報告。

常見版本包括：

• ICD-10
• ICD-11
• 不同國家依需求發展的臨床修訂版本

ICD可以應用於：

• 診斷分類
• 疾病統計
• 公共衛生分析
• 死因統計
• 醫療行政及申報相關作業

ICD的重要價值之一，是讓不同醫院、地區及國家能以較一致的方式記錄及比較疾病資料。

不過，ICD主要是一套分類系統，不等於完整描述所有臨床細節的醫療術語系統。

LOINC：檢驗與臨床觀察項目

LOINC的全名是：

Logical Observation Identifiers Names and Codes

LOINC主要用來識別健康觀察、測量、檢驗項目及醫療文件。

可能使用LOINC的資料包括：

• 血糖檢驗
• 血紅素
• 血壓
• 體溫
• 身高
• 體重
• 問卷及評估量表
• 醫療文件類型

例如，體溫可以使用LOINC代碼：

8310-5

在FHIR Observation中，可以這樣表示：

"code": {
  "coding": [
    {
      "system": "http://loinc.org",
      "code": "8310-5",
      "display": "Body temperature"
    }
  ],
  "text": "體溫"
}

這表示這筆Observation的測量項目是體溫。

需要注意，LOINC主要識別「測量的是什麼」，而測量結果的數值及單位會放在其他欄位。

例如：

"valueQuantity": {
  "value": 37.2,
  "unit": "°C",
  "system": "http://unitsofmeasure.org",
  "code": "Cel"
}

組合後才能完整表達：

測量項目是體溫，測量結果是37.2°C。

SNOMED CT：臨床醫療術語

SNOMED CT是一套內容廣泛的臨床醫療術語系統。

它可以表達許多臨床概念，例如：

• 疾病
• 症狀
• 身體構造
• 臨床發現
• 醫療處置
• 微生物
• 藥物相關概念
• 社會及照護情境

SNOMED CT的目的不只是將疾病分成統計類別，也能較細緻地描述臨床照護中的概念。

因此，ICD與SNOMED CT雖然都可能描述疾病，但用途並不完全相同：

實務上可能需要將SNOMED CT概念對應到ICD分類，但對應並不一定永遠是一對一，也需要依照版本及使用目的處理。

藥品也需要標準化

相同藥物可能同時具有：

• 商品名
• 學名
• 不同劑型
• 不同含量
• 不同包裝
• 不同廠牌
• 醫院院內藥品代碼
• 國家藥品許可或健保相關代碼

假設只記錄：

某某錠

接收方可能無法確定：

• 藥物成分是什麼？
• 每錠含量是多少？
• 是錠劑、膠囊還是注射劑？
• 使用的是哪個代碼系統？

因此，交換藥物資料時，也需要清楚表示代碼系統、藥品代碼、顯示名稱、劑型及劑量等資訊。

本系列後續介紹MedicationRequest時，會再回到用藥資料的表達方式。

院內代碼有什麼問題？

醫院可以依照自己的作業需要建立院內代碼。

例如，A醫院將體溫設定為：

TEMP001

B醫院則使用：

VITAL-T

這些代碼在院內可能運作得很好，但傳到其他醫院後，對方不一定知道它們代表體溫。

因此，系統可能需要建立對應關係：

這個將本地代碼連結到標準代碼的過程，通常稱為Mapping。

Mapping不是單純將名稱翻譯成英文，而是要確認兩個代碼代表的概念是否真的相同。

FHIR中的Coding

在Day 10中曾經介紹過Coding資料型別。

完整一點的Coding可能包含：

{
  "system": "http://loinc.org",
  "version": "範例版本",
  "code": "8310-5",
  "display": "Body temperature",
  "userSelected": true
}

常見欄位包括：

system

"system": "http://loinc.org"

表示這個代碼來自LOINC。

code

"code": "8310-5"

是電腦用來辨認概念的代碼。

display

"display": "Body temperature"

提供方便人類閱讀的文字。

display可能因語言或顯示需求不同而改變，但不能任意改變code原本代表的概念。

FHIR中的CodeableConcept

CodeableConcept可以包含一個或多個Coding，也可以包含自由文字text。

例如：

"code": {
  "coding": [
    {
      "system": "http://loinc.org",
      "code": "8310-5",
      "display": "Body temperature"
    }
  ],
  "text": "體溫"
}

這裡可以拆成：

• coding提供標準代碼。
• text提供目前情境下適合人類閱讀的文字。

CodeableConcept的結構是：

CodeableConcept
├── coding
│   ├── system
│   ├── code
│   └── display
└── text

為什麼coding是Array？

因為同一個醫療概念可能同時使用多套代碼表示。

例如：

"code": {
  "coding": [
    {
      "system": "http://loinc.org",
      "code": "8310-5",
      "display": "Body temperature"
    },
    {
      "system": "https://hospital.example.org/CodeSystem/local-observation",
      "code": "TEMP001",
      "display": "體溫"
    }
  ],
  "text": "體溫"
}

這表示同一項體溫測量同時具有：

• LOINC標準代碼
• 醫院院內代碼

如此一來，院內系統可以繼續使用原有代碼，對外交換時也能提供標準代碼。

Coding和CodeableConcept的差異

Coding範例：

{
  "system": "http://loinc.org",
  "code": "8310-5",
  "display": "Body temperature"
}

CodeableConcept範例：

{
  "coding": [
    {
      "system": "http://loinc.org",
      "code": "8310-5",
      "display": "Body temperature"
    }
  ],
  "text": "體溫"
}

可以將CodeableConcept想成一個盒子，裡面能放入一組或多組Coding，另外再附上一段文字說明。

CodeSystem是什麼？

CodeSystem用來定義一套代碼以及每個代碼的意義。

例如，一套簡單的就醫類型代碼可能包含：

CodeSystem會回答：

這套代碼中有哪些代碼？每個代碼代表什麼？

在FHIR中，CodeSystem本身也是一種Resource，可以描述：

• 代碼系統名稱
• 代碼系統網址
• 版本
• 發布者
• 代碼是否區分大小寫
• 系統中定義的概念

ValueSet是什麼？

ValueSet則是針對特定使用情境，選出允許或適合使用的一組代碼。

它可以：

• 選取某個CodeSystem中的全部代碼
• 只選取其中一部分代碼
• 從多個CodeSystem選取代碼
• 排除不適用的代碼

例如，假設某個CodeSystem共有很多醫療服務代碼，但「就醫類型」欄位只允許：

• 門診
• 急診
• 住院

就可以建立一個ValueSet，只收錄這三個代碼。

可以用字典和選單來比喻：

• CodeSystem像一本完整字典
• ValueSet像從字典中挑出來的一份選單

CodeSystem定義代碼，ValueSet則決定特定情境可以選哪些代碼。

欄位如何和ValueSet連結？

FHIR會將某些code、Coding或CodeableConcept欄位綁定到ValueSet，這個關係稱為Terminology Binding。

不同欄位對ValueSet的要求程度可能不同，FHIR R4常見的Binding Strength包括：

因此，看到FHIR欄位資料型別是code，還不能立刻知道可以填入哪些值，仍然要查看該欄位綁定的ValueSet及強度。

一筆完整的體溫Observation

將前面學過的Reference、CodeableConcept、dateTime及Quantity組合，可以得到：

{
  "resourceType": "Observation",
  "id": "temperature-001",
  "status": "final",
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "8310-5",
        "display": "Body temperature"
      }
    ],
    "text": "體溫"
  },
  "subject": {
    "reference": "Patient/patient-001",
    "display": "王小明"
  },
  "effectiveDateTime": "2026-09-03T09:30:00+08:00",
  "valueQuantity": {
    "value": 37.2,
    "unit": "°C",
    "system": "http://unitsofmeasure.org",
    "code": "Cel"
  }
}

可以拆成：

這筆資料同時使用標準檢驗或觀察代碼及標準單位，讓接收方不只看到「37.2」，也能知道它代表體溫37.2°C。

顯示文字相同，不代表代碼相同

假設兩筆資料都顯示「血糖」，但實際代碼不同。

這可能是因為：

• 一筆測量血液中的葡萄糖
• 一筆測量血清或血漿中的葡萄糖
• 一筆是空腹檢驗
• 一筆是特定時間後的檢驗
• 一筆使用院內代碼
• 一筆使用標準代碼

因此，不能只看display或text相同，就直接判定兩筆資料完全相同。

選擇代碼時需要確認實際的檢體、方法、時間及臨床意義。

使用標準代碼的好處

1. 跨系統交換

不同系統可以透過共同的system及code辨認資料。

2. 支援多語言

介面可以顯示中文或英文，但仍保留相同代碼。

3. 資料查詢

系統可以依照代碼搜尋特定疾病或檢驗項目。

4. 統計分析

標準化資料較容易進行跨院或跨地區比較。

5. 臨床決策支援

系統能利用代碼辨認特定診斷、過敏或檢驗結果，進一步提供提醒。

6. 降低文字差異

避免因簡稱、拼字、語言及輸入方式不同而無法比對。

使用標準代碼仍會遇到哪些問題？

標準代碼不能自動解決所有問題，實際使用時仍要注意：

• 使用的是哪一個版本？
• 代碼是否已停用？
• 院內代碼如何對應標準代碼？
• 兩個概念是否真的完全相同？
• 該國家或機構要求使用哪套系統？
• 使用代碼是否涉及授權或使用條款？
• 顯示文字是否符合語言需求？
• Profile指定了哪個ValueSet？

因此，醫療代碼的Mapping及維護通常需要醫療、資訊及編碼專業人員共同處理，不能只依靠名稱相似就自動對應。

今日練習

請觀察以下CodeableConcept：

{
  "coding": [
    {
      "system": "http://loinc.org",
      "code": "8310-5",
      "display": "Body temperature"
    },
    {
      "system": "https://hospital.example.org/CodeSystem/local-observation",
      "code": "TEMP001",
      "display": "體溫"
    }
  ],
  "text": "病人體溫"
}

可以找出：

1. 這是一個CodeableConcept。
2. coding中有兩組Coding。
3. 第一組使用LOINC。
4. 第二組使用虛構的院內代碼系統。
5. 兩組Coding都在描述體溫。
6. text提供目前情境下的人類可讀文字。

今日小結

今天認識了醫療代碼的重要性。

自由文字適合人類閱讀，但可能受到語言、縮寫、同義詞及拼字差異影響。標準代碼則能透過system與code，讓不同系統更準確地辨認醫療概念。

今天也認識了：

• ICD：疾病及健康問題分類
• LOINC：檢驗、測量、觀察及文件代碼
• SNOMED CT：內容廣泛的臨床醫療術語
• Coding：表示一組代碼
• CodeableConcept：包含一組或多組Coding及文字
• CodeSystem：定義一套代碼及其意義
• ValueSet：選出特定情境可使用的代碼集合

我認為今天最重要的觀念是：

代碼不能只看code，還要一起確認system、版本及使用情境。

完成FHIR資料結構的基礎介紹後，下一篇將開始進入API的世界，先用生活化的方式理解Client、Server、Request、Response及Endpoint。

明日預告

Day 13｜REST API是什麼？用餐廳點餐來理解

參考資料

1. World Health Organization：International Classification of Diseases
   https://www.who.int/standards/classifications/classification-of-diseases

2. LOINC：About LOINC
   https://loinc.org/about/

3. SNOMED International：SNOMED CT
   https://www.snomed.org/

4. HL7 FHIR R4：Terminologies
   https://hl7.org/fhir/R4/terminologies.html

5. HL7 FHIR R4：Data Types－Coding及CodeableConcept
   https://hl7.org/fhir/R4/datatypes.html#Coding

6. HL7 FHIR R4：CodeSystem
   https://hl7.org/fhir/R4/codesystem.html

7. HL7 FHIR R4：ValueSet
   https://hl7.org/fhir/R4/valueset.html