還記得我們昨天建立出來的 FHIR 資料嗎？如下：

{
  "resourceType": "Observation",
  "id": "TEM-001",
  "status": "final",
  "subject": {
    "reference": "Patient/P-001"
  },
  "valueQuantity": {
    "value": 37.2,
    "unit": "°C",
    "system": "http://unitsofmeasure.org",
    "code": "Cel"
  },
  "device": {
    "reference": "Device/DEV-001"
  }
}

在這份 FHIR 資料當中，我們使用了 resource 跟 reference，把量測對象、體溫還有體溫計連在一起。

接下來，我們希望讓系統可以理解這個紀錄，所以我們還要將幾個地方補起來。還少了什麼？在每一次量測的記錄中，量測發生的時間以及量測的項目也需要被記錄下來。

補上量測項目與時間

依據上面的格式，我們加入量測的部位以及量測時間：

{
  "resourceType": "Observation",
  "id": "TEM-001",
  "status": "final",
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "8310-5",
        "display": "Body temperature"
      }
    ]
  },
  "subject": {
    "reference": "Patient/P-001"
  },
  "effectiveDateTime": "2026-10-01T08:00:00+08:00",
  "valueQuantity": {
    "value": 37.2,
    "unit": "°C",
    "system": "http://unitsofmeasure.org",
    "code": "Cel"
  },
  "device": {
    "reference": "Device/DEV-001"
  }
}

1. resourceType：表示指定的資源種類
2. id：這筆 Observation 資源的識別碼，不是病人的識別碼
3. status：final，這筆觀察結果已完成，沒有待完成的處理；不代表上傳完成或數值正常，FHIR 狀態定義。
4. code ：量測項目
   1. system：指定代碼系統：LOINC
   2. code：在 LOINC 代碼中，體溫為 8310-5
   3. display：提供我們可以對外顯示的名稱
5. effectiveDateTime：量測的時間
6. valueQuantity：量測的數值以及單位，在這邊就是我們量測的體溫，包含：
   1. value：數值
   2. unit：給人看的單位文字，本例為 °C
      1. 單位使用 UCUM Cel，與 HL7 FHIR R4 體溫範例一致。
   3. system：單位代碼系統 UCUM（Unified Code for Units of Measure）
   4. code：該系統中的單位代碼，與外層的 code 意義不同。

還差什麼？

目前已有量測對象、項目、時間、結果、單位與狀態。要符合 R4 生命徵象／體溫 Profile，還缺必要的 category，標示這筆資料屬於生命徵象。HL7 官方要求

可在 status 後加入：

"category": [
  {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/observation-category",
        "code": "vital-signs",
        "display": "Vital Signs"
      }
    ]
  }
],

兩個欄位的分工：

• category：資料分類，本例為「生命徵象」。
• code：具體量測項目，本例為「體溫」。

示範案例的完整 FHIR 內容：

{
  "resourceType": "Observation",
  "id": "TEM-001",
  "status": "final",
  "category": [
  {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/observation-category",
        "code": "vital-signs",
        "display": "Vital Signs"
      }
    ]
  }
],
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "8310-5",
        "display": "Body temperature"
      }
    ]
  },
  "subject": {
    "reference": "Patient/P-001"
  },
  "effectiveDateTime": "2026-10-01T08:00:00+08:00",
  "valueQuantity": {
    "value": 37.2,
    "unit": "°C",
    "system": "http://unitsofmeasure.org",
    "code": "Cel"
  },
  "device": {
    "reference": "Device/DEV-001"
  }
}

有 JSON 後，就能交換了嗎？

談到這裡，我們已經把量測對象、量測項目、時間、結果、單位、裝置，以及紀錄狀態與分類組合起來，讓這筆體溫紀錄有了明確的結構與意義。

不過，JSON 格式正確，只是第一步。實際與其他系統交換時，雙方還需要確認採用的 FHIR 版本，以及交換時遵循的實作指引與 Profile。Profile 可以先理解成：針對特定用途，進一步規定哪些欄位必須提供，以及可以使用哪些代碼。資料也需要依這些規則驗證，並確認參照的病人與裝置能被接收方正確識別。

小結

這兩天的文章，我們談到了如何組成一個完整的 FHIR 格式。我們知道 FHIR 不只約定資料怎麼寫，也讓不同系統有共同依據，理解這筆資料在說什麼。使用共同的 FHIR 版本可以讓醫療軟體的資料能在不同系統間有效的傳遞。