前言
在過去的篇章中，我們完成了病患識別、體徵採集、醫囑給藥與合規驗證的完整鏈路。然而，在真實的醫療生態系中，單一院所的病歷不能成為孤島。當病患需要轉診至醫學中心、申請商業保險理賠，或是配合衛福部次世代數位醫療平台進行電子病歷調閱（EMR Exchange）時，系統必須具備將病患在單次住院期間的所有重要臨床紀錄，打包成標準化封包的能力。

在 HL7 FHIR 的世界裡，這個封包的核心載體就是 Bundle。

今天我們將完成模組三的收官之作：設計並實作跨系統醫療資料匯出引擎，將單一就醫歷程（Encounter）下的病患個資、當班體徵趨勢（Observation）與給藥履歷（MedicationAdministration）聚合並封裝成合規的 Document / Collection Bundle，並提供標準 RESTful 匯出端點！

一、認識 FHIR Bundle 的四種主流型態
Bundle 是 FHIR 中專門用來包裝多個 Resources 的容器資源。依據使用場景不同，其 type 屬性具有嚴格的語意定義：
FHIR Bundle 核心類型

在跨院交換或提供第三方衛生機關調閱時，最常用的是 document（結構化臨床病歷文件）或自給自足的 collection（歷史資料匯總包）。

二、臨床匯總封包結構設計
本次實作匯出的目標是提供外部調閱端一個完整且獨立的病歷快照（Snapshot）。一個合規的住院摘要封包應包含：
1.Composition：文件的總目錄，宣告文件標題、作者（醫護人員）、產出時間與章節劃分（Section）。
2.Patient：病患基本識別（身分證號、病歷號、姓名、性別）。
3.Encounter：當次住院歷程（入院時間、主治醫師、床號）。
4.Observation[]：當次住院期間的所有生命徵象時序數據。
5.MedicationAdministration[]：當次住院的所有用藥施打紀錄。

Document Bundle
entry[0]: Composition (文件綱要與章節索引)
entry[1]: Patient (病患基本資料)
entry[2]: Encounter (住院就醫歷程)
entry[3..N]: Observation (體溫、心跳、血壓等時序量測)
entry[N+1..M]: MedicationAdministration (給藥執行履歷)

三、實作 Bundle 匯出組裝服務
建立 src/services/clinical-export.service.ts。該服務由 PostgreSQL 撈出關聯資料後，依序調用前幾天寫好的各個 Adapter，組裝出合規的標準 Document Bundle：
四、Express 匯出端點實作
建立 API 路由：GET /api/v1/clinical/export/encounter/:id/bundle。
在回傳標頭中，必須明確指定 Content-Type: application/fhir+json，並設定 Content-Disposition 支援外部系統直接下載檔案：

五、實機驗證（cURL 測試與驗證檢核）
使用 cURL 發送匯出請求並將結果存檔：

檢查回傳之 exported-bundle.json 結構核心指標：
1.根屬性驗證： resourceType 必須為 "Bundle"，且 type 必須為 "document"。
2.首位資源驗證： entry[0].resource.resourceType 必須為 "Composition"。
3.內部引用閉合（Referential Integrity）： 檢視 Composition.section[0].entry 中所引用的 urn:uuid:... 是否都能在後續的 entry[].fullUrl 中精確找到對應實體。

模組三全篇回顧
至此，模組三：後端 API 開發與 FHIR 整合實戰（Day 14–21） 正式圓滿完結！

回顧過去 8 天，我們從零打造了完整的後端核心：

Day 14： 建置 Express 路由骨幹、擴充 TypeScript 型別與醫護 JWT/RBAC 身分防衛體系。

Day 15： 實作 Adapter Pattern，將內部關聯式資料無失真轉換為 Patient 與 Bundle。

Day 16： 建立生命徵象批次上傳 API，結合 PostgreSQL ACID 交易 與 LOINC Observation 封裝。

Day 17： 打造臨床早期預警引擎，落地 NEWS 2 評分演算法 與 WebSocket 零時差警示。

Day 18： 實作 SBAR 結構化護理交接班，聚合 8 小時時序體徵極端值。

Day 19： 實作給藥核對 API，運用 FOR UPDATE 行級鎖 確保三讀五對與防重複施打。

Day 20： 整合 HAPI FHIR $validate，在 CI/CD 階段杜絕非標準格式資料。

Day 21： 封裝跨系統標準 Document Bundle，打通電子病歷跨院調閱的最後一哩路。

明天 Day 22，我們將正式跨入最後的精華階段——模組四：前端呈現、安全防護與部署上線，首先登場的是：行動端/RWD 介面整合——打造護理床邊生命徵象即時輸入卡片！