This page is part of the 電子病歷交換單張實作指引(EMR-IG) (v0.1.0: Releases) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

首頁

專案介紹

電子病歷交換中心（Electronic Medical Record Exchange Center,E.M.R.Exchange Center, EEC）由衛生福利部所建置，旨在讓病患能夠於任一家醫院或診所時，透過健保IC卡及醫師之醫事憑證IC卡，在病人同意及醫師授權之情形下，取得病人過去6個月之病歷資料，並期望透過電子病歷交換中心，促進院際病歷互通整合，減少病患重複檢驗、檢查及用藥，提升醫療資源運用效能，也逐步使其應用朝向更多元的發展與服務。電子病歷交換單張實作指引(Electronic Medical Record Exchange Implementation Guide以下簡稱EMR IG)，希望能將EMR之電子病歷表單透過HL7® FHIR® standard（Fast Healthcare Interoperability Resources）制定相關規範，增強電子病歷表單於各醫院的互通性。

電子病歷表單包含出院病摘、門診病歷、檢驗檢查、醫療影像及報告、電子處方箋以及調劑單張，基於臺灣核心實作指引（Taiwan Core Implementation Guide，簡稱TW core IG）實作，期望利用資通訊技術，透過醫療院所對病人的全方面服務，提升醫療品質、促進病人安全、減少醫療資源浪費、增進民眾健康自主管理與預防，並持續精進公共衛生，讓電子病歷推動的成果，能成為溫暖醫病關係、營造健康社會的重要基石。

臺灣核心實作指引（Taiwan Core Implementation Guide，簡稱TW core IG）實作採用HL7® FHIR® standard IG建置方法進行資料欄位選用。TW Core IG在FHIR R4.0.1及國際病人摘要(International Patient Summary，IPS)1.0.0-CI Build之標準基礎上，進一步定義適用於臺灣健康照護資料交換需求的Resources（類似資料表）、其中的資料項目（意即欄位）、基數（意即0..1、0..*、1..1或1..*）、資料類型（文字、日期時間、代碼等）、可綁定的代碼（及其綁定的強制程度）及查詢參數等，旨在提供健康照護資訊系統開發與實作者以TW Core IG為基礎，再進一步訂定其實務專案所需之資料交換格式以應用於專案中。

專案背景

民國94年12月進行「醫療院所病歷電子化現況調查」之結果顯示：國內醫院病歷電子化發展已相當普及，共計約有5成醫院病歷資料已進行電腦化，約3成醫院病歷電子化已進展至院內整合階段並逐漸邁向院際之分享與交換應用，顯示過去幾年推動病歷電子化之發展已具初步成效，應順勢大力推展。

為了延續「網路健康服務推動計畫（民國91至94年）」、「衛生局所網路便民服務計畫（民國92至95年）」等計畫之基礎，落實本部「全人健康照護」政策目標，推動「從出生前到老去健康資訊ｅ化流通」發展策略，民國93年10月開始規劃「國民健康資訊建設計畫（National Health Informatics Project，NHIP）」，並於民國94及95年提出計畫申請，於民國96年8月14日核定通過，由政府扮演推動角色，營造國家健康資訊發展環境，推動衛生醫療資訊之重要基礎建設，其中，「推動實施電子病歷」與「建立及營運醫事憑證管理中心 (Healthcare Certification Authority，HCA )」即為NHIP之兩大分項計畫。

「智慧醫療服務計畫」為行政院98年4月30日核定之「健康照護升值白金方案－加值產業」項下四大方案之一，該方案項下包含「推動遠距健康照護計畫」、「推動電子病歷及醫療影像傳輸計畫」、「健保IC卡改善計畫」、「醫院安全關懷RFID計畫」、「健康資料庫加值應用計畫」五大計畫。

後續，本部除繼續推動醫療院所實施電子病歷及互通外，並擬規劃台灣健康雲計畫，發展電子病歷雲端服務，增加國內醫療院所推動電子病歷之意願。

電子病歷交換單張之規範由衛生福利部2022年3月招標之「111年度智慧健康雲專案辦公室營運案專案」經費支應下建置。

如何閱讀這個實作指引(IG)

• 首頁：EMR IG介紹及背景說明。
• 視覺化邏輯模型：EMR IG邏輯模型架構視覺化圖。
  • 出院病摘 視覺化邏輯模型
  • 門診病歷 視覺化邏輯模型
  • 檢驗檢查 視覺化邏輯模型
  • 醫療影像及報告 視覺化邏輯模型
  • 電子處方箋 視覺化邏輯模型
  • 調劑單張 視覺化邏輯模型
• 規範文件
  • 能力聲明 ：應用EMR IG於建置業務目的使用的FHIR Server時，該FHIR Server必須及建議應該支援的資料存取功能。
  • 查詢參數與操作定義：查詢FHIR Server的Profiles時，針對各Profiles可使用的查詢參數及操作定義。
  • 邏輯模型 ：EMR IG的所有邏輯模型(Logical Models)，邏輯模型會定義相應情境下使用的所有資料欄位。為了便於實作者快速理解，資料欄位會使用易於理解的命名，實作者再透過邏輯模型中的功能頁籤「Mappings」瞭解各資料欄位實際使用本IG的哪個Profiles的哪個資料項目(element)。
  • FHIR Profiles及Extensions：
    • EMR IG的所有Profiles之定義與範例。
    • 各資料項目不同實作強制程度的Terminology。
  • 專門術語 ：EMR IG所使用的專門術語，包括代碼系統（Code Systems）及值集（Value Sets）。
• 範例檔：符合EMR IG所定義Profiles之範例檔。
  • 出院病摘 範例檔
  • 門診病歷 範例檔
  • 檢驗檢查 範例檔
  • 醫療影像及報告 範例檔
  • 電子處方箋 範例檔
  • 調劑單張 範例檔
• 結構定義與範例檔下載：實作者若不偏好使用FHIR RESTful API驗證資料是否符合Profiles，可直接下載所需的格式驗證檔，包括XML、JSON及Turtle三種格式，亦可於此下載完整範例檔。
• 安全性：主要說明採用EMR IG網站進行實作時，有關資料存取授權的作法。
• 其他必要資料交換規範：主要說明採用EMR IG網站進行上傳傳染病檢驗報告時上傳相關須知說明。
• 版本異動：若EMR IG網站的版本有所異動，皆可透過異動說明頁得以瞭解版本間的異動差異

專有名詞定義

本實作指引基於TW Core IG規則，敘述如下：

Profiles相關

英文名	中文名	說明
Name	名稱	resource的資料項目名稱(意即XML元素名稱；JSON或RDF屬性名稱)。有些名稱末端為[x]，圖示為，意即可以選擇適用的資料類型以因應對照的資料項目內容，故需依據資料來源類型填入適當的內容值，例如Patient.deceased[x]。 如原始資料謹紀錄病人存活或死亡，應選用Boolean類型，存活為0、死亡為1；如原始資料紀錄病人死亡時間，應選用dateTime類型，並填入時間，表示病人以死亡。
Flags	標記	一組有關影響實作者如何操作資料項目的資訊，範例如下。
		必須支援(MustSupport)，表示伺服器必須有能力接收這個資料項目。詳可參閱MustSupport。
		必須支援，表示此資料項目可能會完全修正或改變其他資料項目的意涵，需特別留意。詳可參閱Modifier。
		表示此資料項目為摘要的一部分，詳可參閱Summary searches。
		表示此資料項目受規範設定的限制(constraints)影響，例如：Patient.name的限制為「name.text(完整中文姓名)」或name.family(英文姓)或者兩者必須填寫」，詳可參閱Constraints。
Card.	基數	此資料項目允許出現在這個resource的最小至最大次數，意即例如某一資料項目的基數若為0..1，表示可不填寫或至多填入1筆；若為1..1，表示必須(只能)填入1筆；若為0..*，表示可不填寫或填入多筆(不限筆數)；若為1..*，表示至少要填入1筆或填入多筆(不限筆數)。
Type	資料型別	資料項目的資料型別(可超連結至該型別的定義)，例如：boolean、integer、dateTime等。
Description &Constraints	描述與限制	此資料項目的描述及詳細的限制，並說明原始CDM資料來源、是否需進行轉換、或依照CDM譯碼簿設計填入對應的說明/文字。並說明其編碼的資料項目可使用何種代碼填寫，如需綁定特定代碼，則以Binding陳述並連結到該值集。 如Patient.birthDate說明: 出生年月日。【TOTFA.d11/TOTFB.d6】，表示資料為出生年月日之資料，資料來源為TOTFA的d11欄位或是TOTFB的d6欄位陳述。

綁定值集(value set)的強度

英文名	中文名	說明
Required	要求使用	應填入代碼表中的其中一個代碼
Preferred	鼓勵使用	鼓勵使用代碼表中的代碼， 但不強制一定要使用此代碼表，你也可使用其他代碼表的代碼或單純以文字表示。
Example	範例	可參考代碼表，但此代碼表只是針對這個欄位的一個可能值的示例，不預期也不鼓勵使用者一定要使用此代碼表的代碼。
Extensible	可擴充	應填入代碼表中適合的代碼，確定無適合的代碼才可以使用其他代碼中的代碼來表示。

如下圖所示，telecom.system應使用ContactPointSystem代碼表(或稱代碼系統)中的其中一個代碼，telecom.use及gender也都有應該搭配使用的代碼表，否則以此IG驗證格式時會出現錯誤訊息。

其餘詳細規則請詳閱TW Core IG網站

作者(貢獻者)