前言

在Day 20中，我們認識了Observation Resource。

Observation適合記錄單一或一組相關的觀察結果，例如：

• 體溫
• 血壓
• 血糖
• 血紅素
• 白血球數量
• 其他檢驗結果

但是，醫院提供的檢驗或檢查報告通常不只有一項數值。

例如，一份血液檢驗報告可能同時包含：

• 白血球
• 紅血球
• 血紅素
• 血小板
• 多項檢驗結果
• 報告結論
• 檢體資訊
• 報告發布時間

FHIR可以使用DiagnosticReport Resource將多筆Observation、檢體及報告內容組合起來。

今天不進行實際操作，而是透過一份虛構的檢驗報告，認識DiagnosticReport的重要欄位及它和Observation之間的關係。

本文中的病人、檢驗項目、數值、時間及報告結論皆為虛構教學資料，不能用來進行健康判斷或醫療診斷。

DiagnosticReport是什麼？

DiagnosticReport用來表示診斷性檢驗、檢查或其他評估所產生的報告。

它可能應用於：

• 實驗室檢驗報告
• 病理報告
• 影像檢查報告
• 心電圖報告
• 內視鏡報告
• 基因檢測報告
• 其他診斷性檢查結果

DiagnosticReport可以回答：

1. 這是哪一種報告？
2. 報告目前處於什麼狀態？
3. 報告屬於哪位病人？
4. 與哪次就醫有關？
5. 使用了哪些檢體？
6. 包含哪些Observation結果？
7. 由誰執行或判讀？
8. 檢查在什麼時間發生？
9. 報告何時發布？
10. 報告結論是什麼？
11. 是否有PDF、影像或其他附件？

為什麼需要DiagnosticReport？

假設一份檢驗包含三個項目：

白血球結果
血紅素結果
血小板結果

每個項目都可以建立成獨立Observation。

但是，系統還需要知道：

• 這三筆結果是否屬於同一份報告？
• 使用的是哪個檢體？
• 報告是否已經完成審核？
• 由哪個單位發布？
• 是否有整體結論？
• 是否存在一份可供閱讀的PDF？

DiagnosticReport提供報告層級的資訊，再透過Reference連結各項Observation。

可以將它想成：

DiagnosticReport：整份報告
├── Observation：檢驗項目A
├── Observation：檢驗項目B
├── Observation：檢驗項目C
└── Specimen：使用的檢體

一份DiagnosticReport範例

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

{
  "resourceType": "DiagnosticReport",
  "id": "diagnostic-report-001",
  "identifier": [
    {
      "system": "https://hospital.example.org/report-number",
      "value": "RPT20260903001"
    }
  ],
  "status": "final",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/v2-0074",
          "code": "LAB",
          "display": "Laboratory"
        }
      ],
      "text": "實驗室檢驗"
    }
  ],
  "code": {
    "coding": [
      {
        "system": "https://hospital.example.org/CodeSystem/report-type",
        "code": "LAB-PANEL-001",
        "display": "範例血液檢驗報告"
      }
    ],
    "text": "範例血液檢驗報告"
  },
  "subject": {
    "reference": "Patient/patient-001",
    "display": "王小明"
  },
  "encounter": {
    "reference": "Encounter/encounter-001",
    "display": "2026年9月3日門診"
  },
  "effectiveDateTime": "2026-09-03T09:30:00+08:00",
  "issued": "2026-09-03T11:00:00+08:00",
  "performer": [
    {
      "reference": "Organization/laboratory-001",
      "display": "範例醫院檢驗部門"
    }
  ],
  "resultsInterpreter": [
    {
      "reference": "Practitioner/practitioner-002",
      "display": "範例判讀人員"
    }
  ],
  "specimen": [
    {
      "reference": "Specimen/specimen-001",
      "display": "血液檢體"
    }
  ],
  "result": [
    {
      "reference": "Observation/lab-result-001",
      "display": "範例檢驗項目A"
    },
    {
      "reference": "Observation/lab-result-002",
      "display": "範例檢驗項目B"
    },
    {
      "reference": "Observation/lab-result-003",
      "display": "範例檢驗項目C"
    }
  ],
  "conclusion": "範例報告結論，僅供FHIR資料結構說明。",
  "presentedForm": [
    {
      "contentType": "application/pdf",
      "language": "zh-TW",
      "title": "範例血液檢驗報告PDF",
      "url": "https://hospital.example.org/reports/report-001.pdf"
    }
  ]
}

這份DiagnosticReport表示：

王小明在2026年9月3日門診中接受一項虛構血液檢驗。報告狀態為final，使用一份血液Specimen，並連結三筆Observation結果。

resourceType與id

"resourceType": "DiagnosticReport",
"id": "diagnostic-report-001"

resourceType表示這是一筆DiagnosticReport。

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

它的邏輯位置可能是：

DiagnosticReport/diagnostic-report-001

identifier：報告編號

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

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

可以和id比較：

不同醫療機構可能使用相同格式的報告編號，因此Identifier通常要搭配system。

basedOn：報告是依據哪項要求產生？

DiagnosticReport可以使用basedOn連結產生這份報告的要求。

例如：

"basedOn": [
  {
    "reference": "ServiceRequest/service-request-001",
    "display": "血液檢驗醫令"
  }
]

這可以表示：

這份報告是依據某一筆ServiceRequest產生。

ServiceRequest可能代表：

• 檢驗醫令
• 影像檢查要求
• 其他診斷服務要求

basedOn不是報告結果，而是報告所依據的上游要求。

status：報告目前的狀態

"status": "final"

status是DiagnosticReport的重要必填欄位。

FHIR R4常見狀態包括：

preliminary和final的差異

preliminary

表示報告仍是初步內容，後續可能修改。

final

表示報告已完成並正式發布。

不過，final之後仍可能出現：

• amended
• corrected
• appended

因此，系統不能因為曾經取得一次final報告，就永遠忽略後續版本。

corrected和appended有什麼不同？

corrected

表示原報告內容有錯誤，後續已經更正。

appended

表示在原報告後增加補充內容，不一定代表原本內容錯誤。

如果報告被更正，醫療系統需要避免繼續使用舊版錯誤內容，也要保留適當的版本及稽核紀錄。

category：報告屬於哪一大類？

"category": [
  {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/v2-0074",
        "code": "LAB",
        "display": "Laboratory"
      }
    ],
    "text": "實驗室檢驗"
  }
]

category用來表示DiagnosticReport的高階分類，例如：

• 實驗室檢驗
• 放射影像
• 心臟相關檢查
• 病理
• 其他診斷服務

範例中的：

LAB

表示實驗室類別。

category只提供較大的分類，要知道具體是哪一種報告，還要查看code。

code：這是哪一種報告？

"code": {
  "coding": [
    {
      "system": "https://hospital.example.org/CodeSystem/report-type",
      "code": "LAB-PANEL-001",
      "display": "範例血液檢驗報告"
    }
  ],
  "text": "範例血液檢驗報告"
}

code表示DiagnosticReport實際代表的報告類型。

例如，可能是：

• 完整血球計數報告
• 生化檢驗報告
• 尿液檢驗報告
• 胸部X光報告
• 心電圖報告
• 病理報告

本文使用的是虛構院內代碼。正式資料應依照Profile及醫療機構規範使用適當的標準代碼。

category和code比較

多份不同血液報告可能都屬於LAB category，但各自使用不同的code。

subject：報告屬於誰？

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

subject表示DiagnosticReport的對象。

通常可能指向：

• Patient
• Group
• Device
• Location

一般病人檢驗及檢查報告通常會指向Patient。

報告必須連結到正確病人，只依靠display中的姓名並不足夠，因為可能有同名病人。

encounter：報告與哪次就醫有關？

"encounter": {
  "reference": "Encounter/encounter-001",
  "display": "2026年9月3日門診"
}

encounter表示這份報告與哪次門診、急診或住院有關。

不過，報告可能在Encounter結束後才發布。

例如：

09:00 病人看診
09:30 採集檢體
09:40 門診Encounter結束
11:00 報告發布

所以Encounter已經finished，不代表所有DiagnosticReport都已經完成。

effective[x]：檢查或檢驗發生的時間

範例使用：

"effectiveDateTime": "2026-09-03T09:30:00+08:00"

effective[x]表示DiagnosticReport在臨床上有效或與檢查相關的時間。

它可以使用：

• effectiveDateTime
• effectivePeriod

如果檢查發生於某一時間點，可以使用effectiveDateTime。

如果檢查持續一段時間，可以使用：

"effectivePeriod": {
  "start": "2026-09-03T09:00:00+08:00",
  "end": "2026-09-03T09:30:00+08:00"
}

不能直接將欄位名稱寫成effective[x]，而要依照實際型別選擇完整名稱。

issued：報告何時發布？

"issued": "2026-09-03T11:00:00+08:00"

issued表示這份DiagnosticReport被正式發布或提供的時間。

可以比較：

檢查發生時間和報告發布時間可能相隔幾分鐘、數小時甚至更久。

performer：誰負責執行？

"performer": [
  {
    "reference": "Organization/laboratory-001",
    "display": "範例醫院檢驗部門"
  }
]

performer表示負責這項診斷服務的角色或機構。

可能指向：

• Practitioner
• PractitionerRole
• Organization
• CareTeam

例如，實驗室報告可能由檢驗部門負責，影像檢查則可能由放射部門及相關人員執行。

resultsInterpreter：誰負責判讀？

"resultsInterpreter": [
  {
    "reference": "Practitioner/practitioner-002",
    "display": "範例判讀人員"
  }
]

resultsInterpreter表示負責解讀或確認結果的醫療人員或角色。

可以比較：

兩者可能是同一個人，也可能不同。

specimen：使用哪一份檢體？

"specimen": [
  {
    "reference": "Specimen/specimen-001",
    "display": "血液檢體"
  }
]

specimen用來連結檢驗所使用的Specimen Resource。

Specimen可能記錄：

• 檢體類型
• 採集時間
• 採集部位
• 採集方法
• 容器
• 檢體狀態
• 檢體處理方式

例如，「血糖」可能來自不同檢體，資料意義及參考範圍也可能不同。因此，保留Specimen資訊有助於正確理解結果。

result：連結Observation結果

"result": [
  {
    "reference": "Observation/lab-result-001",
    "display": "範例檢驗項目A"
  },
  {
    "reference": "Observation/lab-result-002",
    "display": "範例檢驗項目B"
  },
  {
    "reference": "Observation/lab-result-003",
    "display": "範例檢驗項目C"
  }
]

result是DiagnosticReport非常重要的欄位，用來連結構成報告的Observation。

因為一份報告可能包含多項結果，所以result使用Array。

DiagnosticReport不需要把每個檢驗數值全部重新複製一遍，而是透過Reference連到各筆Observation。

DiagnosticReport和Observation如何分工？

假設一份報告包含三個檢驗結果：

DiagnosticReport/diagnostic-report-001
├── Observation/lab-result-001
├── Observation/lab-result-002
└── Observation/lab-result-003

DiagnosticReport負責

• 報告類型
• 報告狀態
• 病人
• 就醫事件
• 檢體
• 發布時間
• 判讀人員
• 報告結論
• 報告附件

Observation負責

• 檢驗項目
• 檢驗數值
• 單位
• 結果狀態
• 參考範圍
• 高低或異常標示
• 測量時間

因此，DiagnosticReport提供整份報告的情境，Observation提供各項結構化結果。

Observation狀態和DiagnosticReport狀態可能不同嗎？

可能。

例如，一份報告包含三筆Observation：

整份DiagnosticReport可能仍然是：

partial

或：

preliminary

等到所有必要結果完成並審核後，DiagnosticReport才可能變成：

final

因此，不能只看DiagnosticReport的status，也不能只看其中一筆Observation的status。

imagingStudy：連結影像檢查

如果DiagnosticReport屬於影像檢查，可以使用imagingStudy連結ImagingStudy Resource：

"imagingStudy": [
  {
    "reference": "ImagingStudy/imaging-study-001",
    "display": "範例影像檢查"
  }
]

ImagingStudy可以描述：

• 影像檢查內容
• Series
• Instance
• 使用的影像技術
• 檢查時間
• 影像端點

DiagnosticReport則記錄報告及判讀內容。

可以簡化成：

ImagingStudy：影像檢查資料
DiagnosticReport：影像檢查報告及結論

media：報告中的影像或媒體

DiagnosticReport可以使用media連結與報告相關的Media。

例如：

"media": [
  {
    "comment": "範例代表性影像",
    "link": {
      "reference": "Media/media-001"
    }
  }
]

這可能用於報告中的代表性圖片、圖表或其他媒體內容。

完整影像檢查資料通常仍會由ImagingStudy或專門的影像系統管理。

conclusion：報告結論

"conclusion": "範例報告結論，僅供FHIR資料結構說明。"

conclusion提供報告的文字結論或判讀摘要。

例如，影像報告可能具有放射科醫師的文字結論，病理報告也可能包含診斷性描述。

conclusion適合人類閱讀，但如果結論中包含重要的結構化診斷，也可以進一步使用conclusionCode。

conclusionCode：代碼化的結論

"conclusionCode": [
  {
    "coding": [
      {
        "system": "https://hospital.example.org/CodeSystem/report-conclusion",
        "code": "EXAMPLE-001",
        "display": "範例結論代碼"
      }
    ],
    "text": "範例結論"
  }
]

conclusionCode使用CodeableConcept，可以將報告結論以標準或院內代碼表示。

可以比較：

兩者可以同時存在，但必須避免內容互相矛盾。

presentedForm：完整報告附件

"presentedForm": [
  {
    "contentType": "application/pdf",
    "language": "zh-TW",
    "title": "範例血液檢驗報告PDF",
    "url": "https://hospital.example.org/reports/report-001.pdf"
  }
]

presentedForm可以保存或連結完整報告，例如：

• PDF
• 文字文件
• 圖片
• 其他格式

它使用Attachment資料型別，常見欄位包括：

結構化資料和PDF有什麼不同？

一份PDF報告方便醫療人員閱讀，也能保留原始版面。

但是，如果所有結果都只存在PDF中，系統可能不容易：

• 單獨搜尋某項檢驗
• 繪製數值趨勢
• 自動比對參考範圍
• 提供臨床提醒
• 進行統計分析
• 將單項結果交換給其他系統

因此，DiagnosticReport可以同時提供：

• result：結構化Observation
• conclusion：文字結論
• presentedForm：完整報告附件

三者不是互相取代，而是滿足不同用途。

DiagnosticReport和DocumentReference的差異

DocumentReference主要用來索引及描述一份文件，例如：

• 掃描病歷
• PDF報告
• 轉診文件
• 外院文件
• 影像或其他附件

DiagnosticReport則專門表示診斷性檢驗或檢查報告，並能連結結構化Observation結果。

可以簡化比較：

一份DiagnosticReport的PDF也可能在特定架構中透過DocumentReference管理，但兩者用途仍不同。

DiagnosticReport和Composition的差異

Composition用來定義FHIR文件的結構，例如：

• 文件標題
• 作者
• 文件狀態
• 不同章節
• 章節內引用的Resource

如果FHIR Bundle的type是document，第一筆Entry通常需要是Composition。

DiagnosticReport則專門描述某項診斷性檢驗或檢查的報告。

DiagnosticReport可以成為FHIR文件中的其中一項內容，但不等於Composition。

一份報告如何串聯多個Resource？

一份DiagnosticReport可能連結：

ServiceRequest
檢驗或檢查醫令
        │
        ▼
DiagnosticReport
整份檢驗或檢查報告
        │
        ├── Patient
        │   報告所屬病人
        │
        ├── Encounter
        │   相關就醫事件
        │
        ├── Specimen
        │   使用的檢體
        │
        ├── Observation A
        │   第一項結果
        │
        ├── Observation B
        │   第二項結果
        │
        └── Observation C
            第三項結果

各Resource分別處理自己的資料，再透過Reference組成完整報告。

DiagnosticReport中的資訊安全

DiagnosticReport可能包含高度敏感的醫療資訊，例如：

• 檢驗結果
• 影像判讀
• 病理診斷
• 基因檢測
• 傳染病檢驗
• 報告PDF
• 醫療人員資訊
• 就醫時間及機構

正式FHIR系統需要控制：

• 誰可以讀取報告
• 是否與病人具有合法照護關係
• 是否能開啟presentedForm
• 附件網址是否需要授權
• 報告修訂後如何通知使用者
• 是否保留版本及稽核紀錄
• 被連結的Observation是否也符合權限
• 是否只提供工作所需的資料

即使Client有權查看DiagnosticReport，也不一定代表能取得所有附件或相關Resource。

DiagnosticReport結構整理

DiagnosticReport
├── identifier：報告編號
├── basedOn：相關醫令或要求
├── status：報告狀態
├── category：報告大類
├── code：具體報告類型
├── subject：病人或其他對象
├── encounter：相關就醫事件
├── effective[x]：檢查或檢驗時間
├── issued：報告發布時間
├── performer：執行者
├── resultsInterpreter：判讀者
├── specimen：使用的檢體
├── result：Observation結果
├── imagingStudy：相關影像檢查
├── media：代表性影像或媒體
├── conclusion：文字結論
├── conclusionCode：代碼化結論
└── presentedForm：完整報告附件

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

今日小結

今天認識了FHIR DiagnosticReport Resource。

DiagnosticReport可以將多筆Observation、Specimen、報告狀態、判讀人員、文字結論及附件組合成一份完整的檢驗或檢查報告。

其中最重要的分工是：

• Observation記錄單項或一組相關的檢驗及觀察結果。
• DiagnosticReport提供整份報告的情境與結論。
• Specimen記錄檢體。
• ServiceRequest記錄上游的檢驗或檢查要求。
• presentedForm提供PDF等完整報告附件。

今天最重要的觀念是：

DiagnosticReport不需要重複保存每一項檢驗數值，而是透過result Reference連結相關Observation。

下一篇將進一步認識FHIR的Profile與Extension，了解為什麼使用相同的Patient或Observation Resource，不同國家及使用情境仍然需要訂定更明確的規則。

明日預告

Day 26｜Profile與Extension：FHIR為什麼還需要在地規則？

參考資料

1. HL7 FHIR R4：DiagnosticReport
   https://hl7.org/fhir/R4/diagnosticreport.html

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

3. HL7 FHIR R4：Observation
   https://hl7.org/fhir/R4/observation.html

4. HL7 FHIR R4：Specimen
   https://hl7.org/fhir/R4/specimen.html

5. HL7 FHIR R4：ServiceRequest
   https://hl7.org/fhir/R4/servicerequest.html

6. HL7 FHIR R4：DocumentReference
   https://hl7.org/fhir/R4/documentreference.html

7. HL7 FHIR R4：Composition
   https://hl7.org/fhir/R4/composition.html