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


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




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

Scenario 1 ~ 3


Scenario 1 & 2：院內系統


  • 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

Scenario 4


Scenario 4：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 不存在