Track  #1  #2  #3  #4  #5  #6  #7  #8  #9  #10


TRACK#1 - 病人基本資料互通

  • Scenario 1 病人身分確認用
    • 執行各項護理技術、檢查、治療、手術等醫療處置前對病人做身分確認
    • 例如：在診療前，醫護人員請病人提供基本資訊如姓名、生日用以核對病人身分是否正確
  • Scenario 2 聯繫病人用
    • 聯絡方式如手機、email…用以聯絡病人
    • 通訊地址如住家地址、工作地址
  • 兩種用途的病人資料將共用相同的識別碼如身分證、護照、居留證、病歷號

Scenario 3：院外系統

情境
  • Patient ID 串接其他兩種 Resource 資料並適當呈現
  • 病人保有自己的PHR Patient ID，可透過PHR的授權機制授權醫護人員調用個人的健康資訊
範例
  • 病人就醫時提供個人的PHR Patient ID，並授權醫護人員可對此ID對應的PHR個案資料調用和操作
注意
  • 參加 SC3 聯測時，產品必須同時通過 Track Observation(WG2) 或 Track Medication(WG3) 才算通過
  • 範例：通過 WG1/SC3 + WG2 任一 SC、或 WG1/SC3 + WG3 任一 SC
Roles
  • Patient Creator
    • 病人基本資料建檔單位系統，可包含：醫療照護機構、藥局、消防局、第三方健康照護應用等
    • 檢核基準：成功新增資料後，測試系統要能正確回傳 id 及病人資料
  • Patient Consumer
    • 病人基本資料使用單位系統，可包含：醫療照護機構、藥局、消防局、第三方健康照護應用、個人等
    • 檢核基準
      • 調閱資料後，測試系統要能將回傳的病人資料以自行定義的 UI、或以 JSON / XML 等原始文件格式正確呈現
      • 編輯資料後，測試系統要能將回傳的病人資料及 History ID 以自行定義的 UI、或以 JSON / XML 等原始文件格式正確呈現
System Roles
  • FHIR Client
    • 發起處理請求，並能夠執行 Patient Resource 的新增、查詢、修改、刪除操作 (CRUD Operations)
    • 必須使用 FHIR 定義的 REST API 來進行上述操作
    • 必須能針對 FHIR 定義的 Patient Search Parameters 進行搜尋
    • 必須能使用 FHIR 定義的 history 參數進行歷史記錄調閱
  • FHIR Server
    • 實作或提供一個儲存機制 (repository storage)，並正確處理所接收的處理請求
    • 接收處理請求，並能夠執行 Patient Resource 的新增、查詢、修改、刪除操作 (CRUD Operations)
    • 必須能夠支援 FHIR Client 使用 FHIR 定義的 REST API 來進行上述操作
    • 必須能夠支援 FHIR Client 使用 FHIR 定義的 Patient Search Parameters 進行搜尋
    • 必須能夠支援 FHIR Client使用 FHIR 定義的 history 參數進行歷史記錄調閱
Levels and Bonus Points (Level 1 & 1+)
  • 本次聯測比照國際 FHIR Connectathon 26，將測試項目劃分為若干 Level，並新增 Bonus Point
  • Level 1
    • 能正確設定 Gazelle，並以 Gazelle 作為檢核依據
    • 測試系統完成各 Scenario 要求之項目
    • 能順利完成 Create、Read、Update、Delete 等動作
    • 能順利以 Search Parameters 搜尋指定的 Record
  • Level 1+
    • 完成 Level 1 之檢核項目
    • 測試系統能以 history 參數調閱單筆 Record 的指定歷史記錄
    • Bonus Point: 測試系統能正確顯示單筆 Record 的歷史記錄清單，並能自由調閱歷史記錄
    • Bonus Point: 測試系統搜尋指定 Record 時，能同時以多項 Search Parameters 進行多條件搜索
Levels and Bonus Points (Level 2)
  • Level 2
    • 測試系統新增 Patient 時，符合以下所有條件
      • HTTP Method 必須為 PUT
      • HTTP Header Accept 必須為 ‘application/fhir+json’
      • HTTP Header Content-Type 必須為 ‘application/fhir+json’
    • 測試系統編輯 Patient 時，符合以下所有條件
      • HTTP Method 必須為 PUT
      • HTTP Header Accept 必須為 ‘application/fhir+json’
      • HTTP Header Content-Type 必須為 ‘application/fhir+json’
    • 測試系統調閱 Patient 時，符合以下所有條件
      • HTTP Method 必須為 GET
      • HTTP Header Accept 必須為 ‘application/fhir+json’
      • HTTP Header Content-Type 必須為 ‘application/fhir+json’
    • 測試系統調閱 Patient Record 的歷史資料時，符合以下所有條件
      • HTTP Method 必須為 GET
      • HTTP Header Accept 必須為 ‘application/fhir+json’
      • HTTP Header Content-Type 不存在
Levels and Bonus Points (Level 2)
  • Level 2
    • 測試系統以 Search Parameters 調閱 Patient 時，符合以下所有條件
      • HTTP Method 必須為 GET
      • HTTP Header Accept 必須為 ‘application/fhir+json’
      • HTTP Header Content-Type 不存在
    • 測試系統刪除 Patient 時，符合以下所有條件
      • HTTP Method 必須為 DELETE
      • HTTP Header Accept 必須為 ‘application/fhir+json’
      • HTTP Header Content-Type 不存在



TRACK#2 - 生理量測數據


WG2_VitalSigns Code System.xlsx

Track 2 聯測情境

  • Scenario 1：
    General Vital-Signs Create/Retrieve
  • Scenario 2：
    Vital-Signs With Medication Create/Retrieve
  • Scenario 3：
    Bone Mineral Density Test Create/Retrieve
  • Scenario 4：
    12 Lead ECG Test Create/Retrieve
  • Scenario 5：
    Vital-Signs in EMS Create/Retrieve

















TRACK#3 - 處方用藥及文件打包


MI-TW 醫資標準及連測公開說明會議
【主題】MI-TW 2022 Track#3 處方用藥與文件打包 規格說明與討論 https://drive.google.com/file/d/1nhSX5aH2Wab1xQAc7NzHASi5K6ylW6sF/view?usp=sharing
  • Scenario1: 建立處方 Create MedicationRequest
  • Scenario2: 取得處方 Retrieve MedicationRequest
  • Scenario3: 建立用藥記錄 Create MedicationAdministration
  • Scenario4: 取得用藥記錄 Retrieve MedicationAdministration
  • Scenario5: 建立電子病歷文件打包 Create Document Bundle
  • Scenario6: 取得電子病歷文件打包 Retrieve Document Bundle
  • Scenario7: 建立電子病歷檢驗報告打包 Create Document Bundle (Laboratory Report)
  • Scenario8: 取得電子病歷檢驗報告打包 Retrieve Document Bundle (Laboratory Report)
【時間】2022/09/30(五)10:00-11:30
【視訊連結】https://meet.google.com/cks-fjgw-szd
近期規劃
  1. 徵求工作小組成員(制訂討論profile)
  2. 徵求參測單位
  3. 徵求新的應用情境
    • 急診醫囑用藥
    • 疫苗施打與追蹤
    • 其他
  • WG3 工作小組會議：隔週三 14:00~15:00
    • 3/31、4/14、4/28、5/12

FHIR Resource For Medication Plan

  • 建立用藥計畫:依序建立用藥處方、配藥資訊、用藥紀錄，以上都會參照藥品資訊
  • MedicationRequest:用藥處方含病人的用藥指示與用藥管理
  • MedicationDispense:藥局配藥含用藥指示、配藥人員…等配藥資訊
  • MedicationAdministration:病人用藥或疫苗的管理
  • MedicationStatement:病人過去或當前的用藥紀錄，不一定與處方相關的用藥
   ＊備註:著色部分為此次聯測資源

MedicationRequest


藥品資訊呈現方式


衛福部食藥署核准上市藥物許可證https://www.fda.gov.tw/mlms/HList.aspx
衛福部健保署健保給付藥品https://www1.nhi.gov.tw/QueryN/Query1.aspx



補充：門診病歷交換欄位與格式之標準規範-處方內容


https://emr.mohw.gov.tw/emr/news.aspx

數據格式要求
常用藥物，詳見參考範例

測試情境
  • PHR 藥物處方及用藥紀錄互通
    • 藥物處方釋出到 PHR 伺服器，個人健康紀錄系統查詢處方
    • 上傳居家用藥紀錄到 PHR 伺服器，醫護人員查詢用藥紀錄
互通要求
  • 藥物處方藥品、劑量、及頻次可跨系統互通處理
  • 處方與用藥紀錄可在醫護系統洽當呈現

資安授權機制
  • 支援JWT機制
  • 支援權限控管機制

聯測角色說明-Medication

  • MedicationRequest Creator
    • 處方開立單位系統，通常為醫師所屬之醫療機構。
  • MedicationRequest Consumer
    • 處方使用單位系統，可包含: 醫療照護機構、藥局、第三方健康照護應用、個人等。
  • MedicationAdministration Creator
    • 用藥記錄建檔單位系統，可包含: 醫療照護機構、第三方健康照護應用、個人等。
  • MedicationAdministration Consumer
    • 用藥記錄使用單位系統，可包含: 醫療照護機構、藥局、第三方健康照護應用、個人等。
情境1 Create MedicationRequest (Source)
  • medicationReference
  • medicationCodeableConcept
  • update MedicationRequest
情境2 Retrieve MedicationRequest (Consumer)
  • Get all MedicationRequest by patient id
  • Get MedicationRequest by patient id and status
  • Get MedicationRequest by patient id and medication code
  • Get MedicationRequest by patient id and organization
情境3 Create MedicationAdministration (Source)
  • Create MedicationAdministration
情境4 Retrieve MedicationAdministration (Consumer)
  • Get all MedicationAdministration by patient id
  • Get MedicationAdministration by patient id and request
  • Get MedicationAdministration by patient id and effectivePeriod
  • Get MedicationAdministration by patient id and practitioner’s organization

WG3藥物處方及用藥紀錄2020聯測松結果


新增疫苗應用情境

Scenario 1:建立門診病人用藥處方(Observation)
Scenario 2:病人或醫療單位存取有效處方資訊
Scenario 3:病人或醫療單位建立某筆處方之用藥紀錄
Scenario 4:病人或醫療單位存取某筆處方之用藥紀錄
Scenario 5:疫苗施打與追蹤(待訂)

聯測角色說明-Immunization

  • ImmunizationRecommendation:
    疫苗接種建議，通常為醫護人員的建議。
  • ImmunizationEvaluation:
    疫苗接種評估，為醫護人員評估疫苗之紀錄。
  • Immunization Creator:
    疫苗接種紀錄，通常為施打疫苗之醫療機構或衛生所。

Scenario 5：疫苗施打與追蹤流程


TRACK#6 - 基因體標記

TRACK#7 - 緊急醫療救護


  • 說明:
    本賽道主要目的在於測試緊急醫療救護情境中，跨系統間的資料交換。生理量測儀器可透過此賽道規範的情境回傳標準化的資料至急救端系統、救護車或責任醫院系統，透過將救護紀錄表及四大急重症表單標準化以解決急救資料互通性的問題。本賽道主要針對上述救護紀錄表與四大急重症表單／病摘使用的 Resource 進行驗證，並確保未來與電子病歷（TW Core IG）進行資料互通的能力。
  • 預期效益:
    隨著智慧醫療的快速發展，及緊急醫療救護業務的規模增長，需要加快以標準化方式進行各系統與儀器間資料交換，縮短急救反應時間，以提升整體緊急照護醫療品質。參加單位可使用實際或是產品雛形參加此賽道，由於這是較新的賽道，並需要跨多個 Resource 進行資料交換，因此參加者須要具備較高的技術門檻。MISAT 鼓勵急救場域相關工作者（醫院急診單位、急重症醫師、EMT）、軟體工程師、開源工作者、儀器開發廠商、系統整合廠商參加，透過早期布局方式建構場域實證以完善本標準，並建立急救照護場域的產品概念驗證（Proof of Concept）與服務驗證（Proof of Service）。
  • 近期規劃:
      1.徵求工作小組成員（討論與制定 Profile、撰寫實作指引
      2.徵求督察員
      3.徵求參測單位
  • 目標:
      資料互通機制：整合現行急就照護情境中，包含消防局、醫院、醫療救護體系中的各單位，建立到院前的資料互通機制。
      跨單位系統介接：基於上述互通機制，介接各單位系統，達成資料互通。
      資料交換與整合：項目包括現場傷病患生命徵象與其他相關量測資料，並具備與電子病歷（臺灣核心規範，TW Core IG）進行資料互通的能力。
      資料安全：因應存取傷病患個人資料，需要一個標準化認證授權機制，確保資料交換安全性（Security）。
      院內外連線遠距醫療：若情況允許的話，支援現場與醫院連線實施遠距醫療。
    `

    測試情境(Scenarios)

  • Scenario 1：核心資料交換(Core Resource)
    救護紀錄表 FHIR 標準化，並整合核心救護流程
  • Scenario 2：重大傷病資料交換
    四大急重症表單 FHIR 標準化（OHCA、Trauma、CVA、ACS）
  • Scenario 3：生理量測資料交換
    救護車上儀器的生理量測資料

聯測範圍

Scenario 1：核心資料交換
說明：本情境參照內政部消防機關救護紀錄表欄位進行定義，可與 SC2、SC3 等應用情境進行連結，並保留對 TW Core IG 的相容性。
  • 調閱傷病患資料與派遣任務，並顯示於畫面上
  • 新增救護紀錄表（以 Composition 表示），其中各 Resource 必須分別上傳至 FHIR Server 後，以 Reference 進行聯結，救護紀錄表須包含以下各部資料（R 為必填、O 為選擇性）：
    • R: 派遣資料（Encounter)
      • R: 各流程時間
      • O: 送往醫院或地點
    • R: 傷病患資料（Patient)
      • 可引用 Track#1 SC3 建立的 Patient 資料，惟須補上本情境要求的 Patient 必填欄位
    • R: 現場狀況 (Condition)
    • O: 傷病患主訴（QuestionnaireResponse）
    • R: 過去病史（Condition）
    • R: 過敏史（AllergyIntolerance）
    • O: 處置項目（Procedure）
    • O: ALS 處置（Procedure）
    • O: 給藥（MedicationAdministration）
    • R: 生命跡象（Observation）
    • 急重症登錄
      • R: 心肺功能停止登錄（Observation）
      • O: OHCA 事故地點型態（Observation）
      • O: 疑似心肌梗塞登錄（Observation）
      • O: 符合疑似腦中風指標（Observation）
    • O: 補述（Narrative）
    • R: 檢傷分級（RiskAssessment）
    • O: 簽名（Consent & Provenance）2022 不定義
      • 僅記錄救護紀錄表填寫人員（Practitioner.name）
  • 調閱救護紀錄表，並顯示於畫面上
    • 以傷病患名稱（Patient.name）或唯一識別碼（Patient.Identifier）調閱
    • 以救護紀錄表唯一識別碼（Composition.id）調閱
    • Scenario 2：重大傷病資料交換
    說明：本情境今年度以 OHCA 及 Trauma 資料交換為主，參考衛福部公告的重大創傷病摘與到院前心跳停止病摘欄位定義聯測項目。其餘 ACS 與 CVA/Stroke 兩項待標準公告後納入聯測項目。病摘定義的是到院後針對四大急重症的資料交換，並保留對 TW Core IG 的相容性。參測單位須在 SC1 建立救護紀錄表後，方可在本情境單獨進行生理量測資料交換。若參測單位單獨參加本項情境者，也可以使用大會事先建立的範例救護紀錄表進行聯結。
    • 調閱救護紀錄表，並顯示於畫面上
      • 有參測 SC1 的單位，須先在 SC1 新增救護紀錄表後調閱該筆資料
      • 沒有參測 SC1 的單位，須調閱大會事先建立的範例救護紀錄表資料
    • 新增重大傷病資料病摘（Composition），其中各 Resource 必須分別上傳至 FHIR Server 後以 Reference 進行聯結，下列至少須完成一項：
      • 到院前心跳停止病摘（OHCA）
      • 重大創傷病摘（Trauma）
    • 調閱重大傷病資料表單，並顯示於畫面上
      • 以傷病患名稱（Patient.name）或唯一識別碼（Patient.Identifier）調閱
      • 以表單 id 調閱
    Scenario 3：生理量測資料交換
    說明：本情境適用於儀器／設備廠商，主要針對救護車上的生理量測數據定義聯測項目。儀器經完成量測後直接上傳至 FHIR Server 並與派遣案件（救護紀錄表）聯結，後續可應用於與 EEC 進行資料交換的情境。參測單位須在 SC1 建立救護紀錄表後，方可在本情境單獨進行生理量測資料交換。若參測單位單獨參加本項情境者，也可以使用大會事先建立的範例救護紀錄表進行聯結。
    • 調閱救護紀錄表，並顯示於畫面上
      • 有參測 SC1 的單位，須先在 SC1 新增救護紀錄表後調閱該筆資料
      • 沒有參測 SC1 的單位，須調閱大會事先建立的範例救護紀錄表資料
    • 新增生理量測資料（Observation），並至少須要完成以下其中一項：
      • 12 Leads ECG
      • Body Temperature
      • Respiratory Rate
      • Oxygen saturation in Arterial blood by Pulse oximetry
      • Capillary refill[Time] of Nail bed
      • Glucose [Mass/volume] in Blood
      • Heart rate by Pulse oximetry
      • Blood Pressure Panel
    • 調閱傷病患在單一救護紀錄表上的所有量測資料，並顯示於畫面上
      • 以傷病患名稱（Patient.name）或唯一識別碼（Patient.Identifier）調閱
      • 以表單 id 調閱

    賽道通過基準

  • 本賽道各情境（Scenario）的通過基準為獨立判斷，參測單位完成所有標記為 R（必須）的聯測步驟時，才算完成該情境。
  • 參測單位通過一情境時，將會於核發的通過證明上註記通過的情境。
  • 僅完成部分項目者，核發的通過證明將註記「部分通過」與其通過項目，並於官網聯測松結果（Matrix）公告通過的項目。
    • 例如 A 廠商通過 SC1（所有交換項目）、SC3（僅有 12 Leads ECG），核發的通過證明將會如下註記：
    • 參測單位： A 廠商
    • 參測賽道： Track #7 緊急醫療救護情境賽道
    • 通過項目：
      • Scenario 1（完全通過）：通過所有流程，及所有資料交換項目。
      Scenario 3（部分通過）：通過所有流程，及以下資料交換項目：
      12 Leads ECG