Track  #1  #2  #3  #4  #5  #6  #7


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



兩大要求: 「基本資料跨系統互通」以及「資安授權機制」
  • 三種使用情境(Scenarios)涵蓋個人健康管理系統(Personal Health Record, PHR)應用或院內系統 FHIR Patient Resources互通
  • 根據參加機構系統使用情境,需包含以下至少新增、刪除、修改、查詢四大功能
互通要求
  • 基本資料,包含: 身分證字號、中文姓名、住址和電話等資訊
  • PHR匿名病人資料互通
資安授權機制
  • 支援JWT機制
  • 支援權限控管機制
聯測要求:調閱資料後,測試系統要能將回傳的JSON文件使用自行定義的UI恰當呈現病人資料

Scenarios


  • Scenario 1(院內系統,2020)
    • 病人身分確認用 Patient ForIdentifier
    • 聯繫病人用 Patient ForContact
  • Scenario 2(院外系統,2020)
    • 個人健康管理系統 Patient ForPHR
  • Scenario 3(急救照護場域,2021 擬新增)
    • 救護紀錄表用 Patient ForEMS

Scenario 1 & 2


Scenario 1:院內系統


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

Scenario 2:院外系統

情境
  • 病人保有自己的PHR Patient ID,可透過PHR的授權機制授權醫護人員調用個人的健康資訊
範例
  • 病人就醫時提供個人的PHR Patient ID,並授權醫護人員可對此ID對應的PHR個案資料調用和操作
針對 Scenario 2 情境,測試系統要能使用 PHR Patient ID 串接其他三種 Resource 資料並適當呈現


Scenario 3


Scenario 3:FHIR Patient for EMS


  • 勤務中心收到救護派遣案件時,建立派遣單
  • 消防單位收到派遣單後,由 EMT / 救護人員依病患聯絡資訊前往救護
  • 救護完成後,填寫救護記錄表,完成派遣
  • 若患者明顯死亡,則直接進行死亡宣告後交由法醫相驗
  • 針對已死亡患者
    • 需要進行 PUT 更新 Patient 狀態
    • 新增 deceased 欄位

Fields and Operations (Checklist)

· R: Required
· O: Optional
· All SC: All Scenarios

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 不存在
2021 擬定變更項目

近期規劃

  • 徵求工作小組成員(制定與討論前述變更項目)
  • 徵求參測單位
  • 與其他 WG 共同發展應用情境
    • WG2 生理監測訊號資料之病人資料串接
    • WG3 用藥處方、用藥記錄與病人相關資料相關串接
    • WG6 病人之基因定序資料與生理檢查資料的整合分析
  • 邀請急救照護人員共同發展 Scenario 3 之應用情境
  • WG1 工作小組會議:隔週四 14:00 – 15:00