前言

前兩篇文章介紹了Observation以及血壓資料。

Observation可以記錄病人的體溫、血壓或檢驗結果，但這些資料通常不是憑空出現，而是在某次門診、急診或住院過程中產生。

例如，王小明到醫院家醫科看診，護理師替他量測血壓，醫師詢問症狀並開立檢驗醫令。這些資料都和「王小明的這一次門診」有關。

FHIR使用Encounter Resource表示病人與醫療服務提供者之間的一次就醫或照護互動。

今天不進行實際操作，而是透過一筆虛構的門診Encounter，認識它的重要欄位及與其他Resource的關係。

本文中的病人、醫師、醫院、時間及醫療資料均為虛構教學範例。

Encounter是什麼？

Encounter可以用來表示病人在醫療服務過程中的一次互動，例如：

• 門診
• 急診
• 住院
• 居家照護
• 遠距醫療
• 日間照護
• 其他醫療服務

它可能回答：

1. 這次就醫目前是什麼狀態？
2. 這是門診、急診還是住院？
3. 接受服務的病人是誰？
4. 哪些醫療人員參與？
5. 就醫從什麼時候開始及結束？
6. 病人因為什麼原因前來？
7. 這次就醫產生哪些診斷？
8. 在哪個地點接受服務？
9. 由哪個醫療機構提供服務？

Encounter是將Patient、Practitioner、Organization、Location、Condition及Observation等Resource串聯起來的重要核心。

Encounter不等於病人的完整病歷

Encounter主要表示一次就醫事件及其情境，不會直接保存所有臨床資料。

例如：

這些Resource可以透過Reference與Encounter建立關係。

一份門診Encounter範例

以下是一份簡化的FHIR R4 Encounter：

{
  "resourceType": "Encounter",
  "id": "encounter-001",
  "identifier": [
    {
      "system": "https://hospital.example.org/encounter-number",
      "value": "E20260903001"
    }
  ],
  "status": "finished",
  "class": {
    "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
    "code": "AMB",
    "display": "ambulatory"
  },
  "type": [
    {
      "text": "家醫科門診"
    }
  ],
  "subject": {
    "reference": "Patient/patient-001",
    "display": "王小明"
  },
  "participant": [
    {
      "individual": {
        "reference": "Practitioner/doctor-001",
        "display": "陳醫師"
      }
    }
  ],
  "period": {
    "start": "2026-09-03T09:00:00+08:00",
    "end": "2026-09-03T09:20:00+08:00"
  },
  "reasonCode": [
    {
      "text": "頭暈"
    }
  ],
  "diagnosis": [
    {
      "condition": {
        "reference": "Condition/condition-001",
        "display": "本次門診診斷"
      },
      "rank": 1
    }
  ],
  "location": [
    {
      "location": {
        "reference": "Location/room-101",
        "display": "家醫科第一診間"
      },
      "status": "completed"
    }
  ],
  "serviceProvider": {
    "reference": "Organization/hospital-001",
    "display": "範例醫院"
  }
}

這份Encounter表示：

王小明在2026年9月3日上午前往範例醫院家醫科門診，由陳醫師提供醫療服務，就醫原因為頭暈，目前這次Encounter已經結束。

接下來逐一拆解主要欄位。

resourceType與id

"resourceType": "Encounter",
"id": "encounter-001"

resourceType表示這是一筆Encounter Resource。

id是這筆Encounter在FHIR Server中的邏輯識別碼。

它的邏輯位置可能是：

Encounter/encounter-001

其他Resource可以透過Reference連回這次就醫，例如Observation：

"encounter": {
  "reference": "Encounter/encounter-001"
}

identifier：就醫事件的業務編號

"identifier": [
  {
    "system": "https://hospital.example.org/encounter-number",
    "value": "E20260903001"
  }
]

identifier可以表示醫療機構實務上使用的就醫編號。

可以和id比較：

不同醫院可能有自己的就醫編號規則，因此Identifier通常需要搭配system。

status：這次就醫進行到哪裡？

"status": "finished"

status是Encounter的重要必填欄位，用來表示這次就醫目前所處的狀態。

FHIR R4常見狀態包括：

門診過程可能經歷：

planned
   ↓
arrived
   ↓
in-progress
   ↓
finished

不過，不是每個醫療機構都一定經過完全相同的狀態流程。

finished不代表疾病已痊癒

"status": "finished"

只表示這次Encounter已結束。

它不代表：

• 病人已經痊癒
• 治療已經全部完成
• 所有檢驗結果都已發布
• 病人不需要回診
• Condition已經解除

例如，病人的門診在上午結束，但檢驗結果可能下午才完成；病人也可能需要下週再次回診。

Encounter狀態描述的是就醫流程，不是疾病狀態。

class：門診、急診還是住院？

"class": {
  "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
  "code": "AMB",
  "display": "ambulatory"
}

class用來表示Encounter的高階分類。

常見概念包括：

本文的家醫科門診使用：

AMB

class可以協助系統快速區分這次醫療服務的大類型。

class和type有什麼不同？

範例中還包含：

"type": [
  {
    "text": "家醫科門診"
  }
]

class和type都在描述Encounter，但詳細程度不同。

例如，多個Encounter的class都可能是AMB，但type可能分別是：

• 家醫科門診
• 心臟內科門診
• 精神科門診
• 復健治療
• 健康檢查

實際使用時，type應盡量使用Profile要求的標準代碼，而不是只放自由文字。

subject：接受醫療服務的是誰？

"subject": {
  "reference": "Patient/patient-001",
  "display": "王小明"
}

subject表示這次Encounter的主要對象。

在一般就醫情境中，通常會指向Patient。

其中：

Patient/patient-001

是實際Reference。

王小明

是方便人類閱讀的display。

display不能取代正式Reference，因為可能有多位病人使用相同姓名。

participant：誰參與了這次就醫？

"participant": [
  {
    "individual": {
      "reference": "Practitioner/doctor-001",
      "display": "陳醫師"
    }
  }
]

participant表示參與Encounter的人員。

可能包括：

• 主治醫師
• 住院醫師
• 護理師
• 治療師
• 其他醫療專業人員
• 陪同或參與照護的相關人員

因為一次就醫可能有多位參與者，所以participant使用Array。

participant.type：參與者扮演什麼角色？

Encounter可以進一步使用participant.type表示參與角色。

簡化範例如下：

"participant": [
  {
    "type": [
      {
        "text": "主治醫師"
      }
    ],
    "individual": {
      "reference": "Practitioner/doctor-001",
      "display": "陳醫師"
    }
  }
]

這段資料回答兩個問題：

• individual：參與者是誰？
• type：參與者在這次Encounter中扮演什麼角色？

同一位Practitioner在不同Encounter中可能具有不同角色，因此角色資訊適合放在Encounter的participant情境中。

participant.period：參與期間

participant也能記錄參與時間：

"period": {
  "start": "2026-09-03T09:00:00+08:00",
  "end": "2026-09-03T09:20:00+08:00"
}

在住院等較長的Encounter中，不同醫療人員可能只在部分期間參與照護。

因此，participant的期間不一定和整個Encounter的期間完全相同。

period：就醫開始及結束時間

"period": {
  "start": "2026-09-03T09:00:00+08:00",
  "end": "2026-09-03T09:20:00+08:00"
}

period表示這次Encounter的時間範圍。

其中：

• start：開始時間
• end：結束時間

如果Encounter仍在進行中，可能只有start，尚未出現end。

例如：

"period": {
  "start": "2026-09-03T09:00:00+08:00"
}

當Encounter完成後，才加入結束時間。

status和period需要互相對照

如果Encounter的狀態為：

"status": "finished"

通常會預期它具有合理的結束時間。

如果Encounter仍為：

"status": "in-progress"

沒有period.end可能是合理的。

因此，FHIR資料不只需要確認單一欄位格式，還要考慮不同欄位之間是否一致。

reasonCode：病人為什麼前來？

"reasonCode": [
  {
    "text": "頭暈"
  }
]

reasonCode表示此次Encounter發生的原因。

可能包括：

• 症狀
• 主訴
• 轉診原因
• 例行追蹤
• 預防性服務
• 健康檢查
• 其他就醫原因

需要注意：

就醫原因不一定等於最後診斷。

病人可能因頭暈前來，但醫師評估後得到另一項診斷。reasonCode描述的是就醫原因，診斷則會透過Condition及diagnosis建立關係。

reasonReference：以Resource表示就醫原因

除了reasonCode，Encounter也能透過reasonReference連結其他Resource。

例如：

"reasonReference": [
  {
    "reference": "Condition/condition-previous",
    "display": "既有健康問題追蹤"
  }
]

這可以表示本次就醫是為了追蹤某項既有Condition。

使用reasonCode還是reasonReference，取決於資料是否已被建立成獨立Resource，以及Profile的要求。

diagnosis：這次就醫涉及哪些診斷？

"diagnosis": [
  {
    "condition": {
      "reference": "Condition/condition-001",
      "display": "本次門診診斷"
    },
    "rank": 1
  }
]

Encounter的diagnosis不會直接把所有診斷細節塞進來，而是透過Reference連結Condition或相關Resource。

常見欄位包括：

rank: 1通常表示這筆診斷的排序為第一，但具體意義仍應依實作規則理解。

reasonCode和diagnosis的差異

例如：

就醫原因：頭暈
診斷：需要進一步評估的健康問題

兩者可能有關，但不必完全相同。

location：在哪裡接受服務？

"location": [
  {
    "location": {
      "reference": "Location/room-101",
      "display": "家醫科第一診間"
    },
    "status": "completed"
  }
]

location表示Encounter期間使用的地點。

可能包括：

• 診間
• 急診區域
• 病房
• 病床
• 手術室
• 檢查室
• 遠距服務的虛擬地點

一次Encounter可能經過多個Location，因此使用Array。

例如，住院病人可能先在急診、再進入病房，之後轉到其他病房。

Encounter.location.status

Encounter中的每一個Location紀錄都可以有自己的狀態。

常見值包括：

這個status描述病人在Encounter中使用該地點的狀態，不是Location Resource本身是否營業或啟用。

physicalType：Location的實體類型

Encounter.location還可以記錄：

"physicalType": {
  "text": "診間"
}

它用來說明地點的類型，例如：

• 建築物
• 病房
• 房間
• 病床
• 診間
• 虛擬地點

location.location回答「具體是哪個Location」，physicalType則描述地點的實體或功能類型。

serviceProvider：哪個機構提供服務？

"serviceProvider": {
  "reference": "Organization/hospital-001",
  "display": "範例醫院"
}

serviceProvider表示負責提供這次Encounter服務的Organization。

Organization Resource可以進一步記錄：

• 機構名稱
• 機構識別碼
• 機構類型
• 聯絡方式
• 地址
• 上級機構

Encounter透過Reference連到Organization，就不需要在每筆就醫紀錄中重複完整的醫院資料。

serviceType：提供哪一類服務？

Encounter還可以使用serviceType表示服務類型，例如：

"serviceType": {
  "text": "家庭醫學服務"
}

serviceProvider與serviceType可以比較：

Encounter如何連結Observation？

上一篇文章中的血壓Observation包含：

"encounter": {
  "reference": "Encounter/encounter-001"
}

這表示血壓是在這次門診中產生。

資料關係可以整理成：

Patient/patient-001
王小明
        │
        └── Encounter/encounter-001
            2026年9月3日門診
                    │
                    ├── Observation/blood-pressure-001
                    │   血壓
                    │
                    ├── Condition/condition-001
                    │   診斷
                    │
                    └── MedicationRequest/medication-001
                        用藥醫令

Encounter提供共同的就醫情境，讓不同臨床Resource知道自己與哪一次醫療服務有關。

Encounter和Appointment有什麼不同？

Appointment表示預約或排程，Encounter則表示實際的就醫或服務過程。

Appointment

可能記錄：

• 預約日期
• 預約時段
• 預約醫師
• 預約科別
• 參與者是否接受邀請
• 預約是否取消

Encounter

可能記錄：

• 病人是否到達
• 就醫是否正在進行
• 實際開始及結束時間
• 參與醫療人員
• 就醫地點
• 就醫原因及診斷

可以比較：

病人有Appointment不代表一定完成Encounter，因為可能取消預約或未到。

Encounter也不一定都有Appointment，例如未預約的急診就醫。

Encounter和Condition有什麼不同？

Encounter

表示一次就醫過程，例如：

2026年9月3日家醫科門診

Condition

表示病人的疾病、健康問題或診斷，例如：

高血壓

同一個Condition可能跨越多次Encounter持續存在。

例如，病人可能因高血壓在不同月份多次回診：

Condition：高血壓
├── Encounter：1月門診
├── Encounter：3月門診
├── Encounter：6月門診
└── Encounter：9月門診

因此，Condition不應被限制成只屬於單一Encounter，而Encounter則是特定時間的一次醫療互動。

Encounter和EpisodeOfCare有什麼不同？

EpisodeOfCare可以表示一段較長期、由醫療機構負責管理的照護期間。

例如：

• 一段孕期照護
• 長期慢性病管理
• 一段癌症治療
• 居家照護期間
• 一段精神醫療照護

一個EpisodeOfCare中可能包含多次Encounter。

EpisodeOfCare：長期慢性病照護
├── Encounter：第一次門診
├── Encounter：第二次門診
├── Encounter：電話追蹤
└── Encounter：第三次門診

可以比較：

住院Encounter還有哪些資訊？

門診Encounter通常較簡單，住院情境可能需要更多資料。

Encounter的hospitalization可以記錄：

• 住院前來源
• 入院方式
• 再入院資訊
• 特殊禮遇
• 飲食需求
• 出院安排
• 出院地點

簡化範例如下：

"hospitalization": {
  "admitSource": {
    "text": "由急診入院"
  },
  "dischargeDisposition": {
    "text": "返家"
  }
}

這些欄位主要用於住院相關Encounter，不是每筆門診都需要填寫。

Encounter狀態歷程

Encounter的狀態可能隨時間改變。

FHIR可以使用statusHistory記錄狀態期間：

"statusHistory": [
  {
    "status": "arrived",
    "period": {
      "start": "2026-09-03T08:50:00+08:00",
      "end": "2026-09-03T09:00:00+08:00"
    }
  },
  {
    "status": "in-progress",
    "period": {
      "start": "2026-09-03T09:00:00+08:00",
      "end": "2026-09-03T09:20:00+08:00"
    }
  },
  {
    "status": "finished",
    "period": {
      "start": "2026-09-03T09:20:00+08:00",
      "end": "2026-09-03T09:20:00+08:00"
    }
  }
]

statusHistory能保留Encounter曾經經過的狀態，而最外層status表示目前狀態。

實際系統是否完整記錄每次狀態變化，仍取決於Profile及業務需求。

Encounter資料涉及哪些隱私問題？

Encounter可能透露：

• 病人曾到哪家醫院
• 看診日期及時間
• 看診科別
• 參與醫療人員
• 就醫原因
• 診斷
• 住院或急診紀錄
• 病人所在病房或位置

即使Encounter本身沒有完整病歷內容，也可能透露敏感健康資訊。

因此，正式FHIR系統需要控制：

• 誰可以讀取Encounter
• 可以查看哪些病人的Encounter
• 是否具有合法照護關係
• Location資訊是否需要限制
• 是否留下查詢及操作Log
• 是否符合病人同意及法規
• 回傳資料是否符合最小必要原則

Encounter重要欄位整理

Encounter
├── identifier：就醫事件的業務編號
├── status：目前狀態
├── statusHistory：過去狀態
├── class：門診、急診或住院等高階分類
├── type：更具體的就醫類型
├── serviceType：服務類型
├── subject：病人
├── participant：參與人員
├── appointment：相關預約
├── period：開始及結束時間
├── reasonCode：就醫原因
├── reasonReference：與就醫原因相關的Resource
├── diagnosis：本次就醫涉及的診斷
├── hospitalization：住院相關資訊
├── location：服務地點
└── serviceProvider：提供服務的機構

實際Encounter不一定同時包含所有欄位，仍要依FHIR規範、Profile及醫療情境決定。

今日小結

今天認識了FHIR Encounter Resource。

Encounter用來表示病人與醫療服務提供者之間的一次就醫或照護互動，例如門診、急診、住院、居家照護及遠距醫療。

重要欄位包括：

• identifier
• status
• class
• type
• subject
• participant
• period
• reasonCode
• diagnosis
• location
• serviceProvider

今天最重要的觀念是：

Encounter記錄的是一次就醫情境，不是病人的完整病歷，也不是疾病本身。

Appointment代表預定服務，Encounter代表實際就醫互動，Condition則代表疾病或健康問題。

下一篇將繼續介紹Condition Resource，了解FHIR如何表示病人的疾病、健康問題及診斷，以及Condition與Observation有什麼差異。

明日預告

Day 23｜Condition：疾病與診斷如何表示？

參考資料

1. HL7 FHIR R4：Encounter
   https://hl7.org/fhir/R4/encounter.html

2. HL7 FHIR R4：Encounter Definitions
   https://hl7.org/fhir/R4/encounter-definitions.html

3. HL7 FHIR R4：Appointment
   https://hl7.org/fhir/R4/appointment.html

4. HL7 FHIR R4：EpisodeOfCare
   https://hl7.org/fhir/R4/episodeofcare.html

5. HL7 FHIR R4：Condition
   https://hl7.org/fhir/R4/condition.html

6. HL7 Terminology：ActCode
   https://terminology.hl7.org/CodeSystem-v3-ActCode.html