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 不存在

Track #2 - 生理量測數據互通(mHealth-plug-athon)


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
















2022年聯測-Waveform Data

  • Observation of ECG annotation
  • Long Term ECG Waveform data: wearable ECG、ICU、開刀房等
  • 睡眠中心的各種生理量測訊號
  • 呼吸器
  • 血液透析

Track #3 - 用藥及疫苗接種紀錄


近期規劃

  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 #4 - 影像與AI結果互通


  • 此項目採用互通性聯測機制,同一情境測試項目需滿足IHE聯測規範,即需三家不同公司或是機構進行交互驗證方可通過聯測
  • 目的在於測試影像與標記跨系統間的查詢與調閱,能符合DICOM以及FHIR標準

聯測項目與規格

  • 查詢影像與標記 (Query)
    • DICOMWeb: QIDO階層式查詢 – Studies-Series-Instances
    • DICOM Query: C-FIND
    • FHIR ImagingStudy
    • FHIR Observation SVG annotation
  • 調閱影像與標記 (Retrieve)
    • DICOMWeb: WADO-RS、 WADO-URI
    • DICOM Retrieve C-MOVE
    • FHIR Observation SVG annotation
  • 影像與標記顯示一致性
    • 顯示標準格式標記跨系統之間呈現確保影像與標記呈現一致性
    • 標記格式包含: RTSS, GSPS, OVerlay, DICOM SR等
  • 資安授權機制 (DICOMWeb/FHIR)
    • 支援JWT機制
    • 支援權限控管機制

聯測規劃情境

  • 測試情境1: 傳統DICOM Q/R
    • 使用傳統DICOM Network查詢與調閱影像與標記
    • 無法在Pre-Connectathon進行
    • 參考IHE Integration Profile
      • Scheduled Workflow (SWF.b)
  • 測試情境2: Web Access
    • 使用DICOMWeb階層式查詢方式查詢DICOMWeb主機,並依照DICOM階層式架構回傳結果
    • 調閱使用WADO-URI或WADO-RS
    • 參考IHE Integration Profile
      • Invoke Image Display (IID)
      • IHE Web-based Image Access (WIA)
  • 測試情境3: Integration with FHIR
    • 查詢FHIR ImagingStudy Resources
    • 使用WADO-URI或WADO-RS調閱影像以及標記
    • 或使用FHIR REST API調閱FHIR Observation SVG annotation

測試情境1: DICOM Q/R

測試說明
  • DICOM PS3.4: Query/Retrieve Service Class
  • 影像顯示(Image Display)與影像管理(Image Manager)之間使用 C-FIND查詢關鍵字與回傳值之測試

測試情境2: Web Access

測試情境2-1: Image Study Query
  • QIDO_RS Query [RAD-129] for Study Metadata
  • Client應用使用病歷號Patient 12345,並使用QIDO-RS study查詢

測試情境2-1: Image Study Retrieves
  • WADO-RS Retrieve [RAD-107] DICOM Study
  • Client取得Study Level WADO-RS URL後,

測試情境2-2: Image Study Query
  • QIDO_RS Query [RAD-129] for Study-Series-Instance Metadata
    • Client應用使用病歷號Patient 12345,並使用QIDO-RS study查詢
    • 從QIDOForStudies中找到StudyInstanceUID後組合成QIDOForSeries查詢
    • 從QIDOForSeries中找到SeriesInstanceUID後組合成QIDOForInstance查詢
    • 組合StudyInstanceUID, SeriesInstanceUID, SOPInstanceUID成WADO_URI

測試情境2-2-1: Image Study DICOM Retrieve
  • WADO_URI Retrieve
  • Client透過QIDO_RS Study-Series-Instance階層式查詢後,取得每個Instance的StudyUID, SeriesUID, InstanceUID後,組合成WADO_URI,逐筆將影像以GET的方方式下載
  • 將HTTP Request Parameter加入 contentType=application%2Fdicom

測試情境2-2-2: Image Study JPEG Retrieve
  • WADO_URI Retrieve
  • Client透過QIDO_RS Study-Series-Instance階層式查詢後,取得每個Instance的StudyUID, SeriesUID, InstanceUID後,組合成WADO_URI,逐筆將影像以GET的方方式下載
  • 將HTTP Request Parameter加入 contentType=image%2Fjpeg

測試情境3: Integration with FHIR

3-2: Integration with FHIR
  • Query for FHIR ImagingStudy Metadata
    • Client應用使用病歷號Patient 12345,並使用QIDO-RS study查詢
    • 使用ImagingStudy.endpoint調閱影像: WADO-RS或 WADO-URIs

3-3 With FHIR Observation


Track #5 - 病理影像


  • 說明:
    此賽道主要目的在於測試病理影像儲存管理主機(Source)以及顯示端(Consumer)能依照DICOMWeb標準查詢與調閱,超大尺寸數位病理影像,並能正確顯示。在影像標記註解部分,透過影像與標記標準化,用來解決全幅(Whole Slide)數位病理影像互通性的問題。標註格式可能是影像分割形式的點陣圖型、透過座標定義輪廓之向量圖型等,本賽道主要針對註解標示影像的關注區(regions of interest, ROIs)的標準化進行驗證。亦希望參加者能提供簡單的標記,作為標準化病理影像的示範案例,提供異質性系統互通,作為加速數位病理影像標準化。
  • 預期效益:
    隨著人工智慧與機器學習(AI/ML)的快速發展,需要加快標準化的醫學影像分析工作流程的軟體開發流程(SDLC),以及採取更加敏捷的開發方法。參加單位可使用實際或是產品雛型參加此賽道,由於這需要大量的前期開發工作,因此參加者需要具備較高的技術門檻。這也鼓勵參加單位早期投資,希望此標準足夠成熟,進而早期布局,以證明投資的合理性。早日切入數位病理影像市場。為了簡化標準化開發流程並鼓勵產業早期實施和測試。MISAT鼓勵醫學影像分析專家、軟體工程師、開源工作者參加,並投入開發開源試驗,建立提供數位病理影像標準化系統的產品概念驗證(Proof ofConcept)

測試情境(Scenarios)

  • 病理影像
    • 針對DICOM數位病理影像(DICOM Whole Slide Imaging - Supplement 145)存取調閱、並能正確顯示
    • 產生DICOM數位病理影像並透過DICOM標準協定上傳至PACS Servers
  • 標記註解
    • 對現有上述標準化DICOM數位病理影像進行分析,產生標記註解
    • 產生TID 1500結構化報告作為標記註解格式
    • 可使用JavaScript以及Python作為影像顯示與影像分析
    • 參考DICOM Supplement 222: Whole Slide Microscopy Bulk Annotations Storage SOP Class
    • 結合2021 DICOM WSI annotation online Hackathon (預計6月~8月)s

  • https://github.com/cylab-tw/mitw/blob/main/Track-Pathology.md

聯測範圍

  • 顯示系統(Display systems)
    • 畫標記
    • 將標記轉換成結構化報告格式(DICOM SR)
    • 解析DICOM SEG並呈現在影像上
    • 傳輸(Store)、查詢與調閱(Query/Retrieve)影像與標記

  • 分析系統(Analysis systems)
    • 解析標記用分析
    • 將分析結果(AI Results)儲存成結構化報告格式(DICOM SR)
    • 傳輸(Store)、查詢與調閱(Query/Retrieve)影像與標記



  • 查詢影像與標記 (Query)
    • DICOMWeb: QIDO階層式查詢 – Studies-Series-Instances
      • FHIR ImagingStudy
      • FHIR Observation SVG annotation
  • 調閱影像與標記 (Retrieve)
    • DICOMWeb: WADO-RS
    • DICOMWeb: WADO-URI
    • FHIR Observation SVG annotation
    • 影像與標記顯示一致性
      • 顯示標準格式標記跨系統之間呈現確保影像與標記呈現一致性
情境1 病理影像調閱與檢視
  • 使用DICOMWeb階層式查詢方式查詢DICOMWeb主機,並依照DICOM階層式架構回傳結果
  • 調閱使用WADO-URI或WADO-RS

情境2 標記調閱與檢視
  • 使用DICOMWeb階層式查詢方式查詢DICOMWeb主機,並依照DICOM階層式架構回傳結果
  • 調閱使用WADO-URI或WADO-RS
    • 參考DICOM Supplement 222: Whole Slide Microscopy Bulk Annotations Storage SOP Class
    • 結合2021 DICOM WSI annotation online Hackathon (預計6月~8月)

參考標準

  1. DICOM Whole Slide Imaging (WSI)
  2. DICOM Suuplement 222: Whole Slide Microscopy Bulk Annotations Storage SOP Class: PDF/ PPT/ Word - 徵求公開意見中
  3. DICOMWeb
  4. FHIR Observation

Track #6 - Genomic





基因檢測紀錄


FHIR Resource

MolecularSequece resource
  • Raw data describing a biological sequence
  • A sequence which contains the alignment sequencing test result and multiple variations
Observation-genetics profile on Observation
  • Variant related data
    • Gene、DNARegionName、Discrete genetic variant、Genomic DNA change、Genomic source class (Germline / Somatic)、Amino acid / Genomic DNA change、Amino acid / Genomic DNA change Type、Cytogenetic (chromosome) location、etc

MolecularSeq


Observation


聯測項目

  • Support the sending of the MolecularSequence resource and Genetics profiles
  • Support the receiving and processing of the MolecularSequence resource and Genetics profiles
資安授權機制
  • 支援JWT機制
  • 支援權限控管機制

聯測 情境一

Create a New MolecularSequence and Observation
  • Create a sequence instance and a genetic-profile-based observation instance to represent genetics data and interpretations
    • DNA variant
Roles
  • MolecularSequence and Genetics profile Creator

聯測 情境二

Retrieve Clinical Sequencing - Germline Testing
  • Search target genetic-profile-based observation with given patient ID
Roles
  • MolecularSequence and Genetics profile Consumer

Track #7 - 影像檢查流程(Scheduled Workflow)


目的

  • 提供場域針對DICOM相關的醫療儀器與HIS、PACS互通之應用驗證。
    • 例如: 國內廠商自行研發超音波儀器,但苦於現有PACS與HIS廠商進行驗證,每次需要都需要在個別的醫院進行介接測試,此track域提供一個良好的技術交流場域,讓國內外多家廠商聯合測試,已證明產品符合國際醫學資訊標準規範
  • 主要測試IHE Scheduled Worflow.b,作為明年IHE-Taiwan聯測準備演練
  • 此Track主要與Track 4結合,主要針對HIS以及儀器製造商進行互通驗證

參與角色

  • HIS
    • 針對HIS開立影像檢查單,以標準化的方式(HL7),提供造影工作清單(Worklist)上的造影檢查單之新增、刪除、修改等功能。
    • 針對影像調閱至門診或是HIS系統,以DICOMWeb方式調閱影像並呈現在HIS系統。
    • 如果HIS廠商參加此Track,則亦可參加 #Track 4 之影像調閱情境。
  • PACS/RIS
    • 針對PACS產品包含: Modality Worklist, Image Manager, Image Archive, Image Display等功能進行驗證,與醫療儀器廠商針對影像上傳,例如: C-STORE, STOW, 等方式進行介接測試驗證
  • 影像AI公司 (Evidence Creator)
    • 針對AI影像軟體業者產生的標準化之DICOM AI結果,例如: PS, RTSS, SEG等,上傳至Image Archive,並提供影像檢視之驗證
    • 驗證包含: 格式驗證以及傳輸協定驗證(請參考 儀器製造商章節說明)
  • 儀器製造商
    • 參加對象以國內外醫療儀器製造商在台灣銷售為主,包含: 超音波、心電圖、X光機、內視鏡等。
    • 主要驗證儀器是否符合DICOM以下規格
      • 影像格式驗證: 針對儀器製造商提供之符合性宣稱(Conformance Statement),針對儀器端產生之DICOM物件進行格式驗證,以符合DICOM PS 3.3 SOP Class UID定義的格式規範。
      • 例如:產生的超音波影像是否符合DICOM格式、具備必要欄位、儲存的數值符合欄位規範、OID與UID之正確性等。
      • 傳輸協定驗證:針對儀器製造商提供之符合性宣稱(Conformance Statement),驗證傳輸功能是否符合DICOM規範,例如: C-STORE, Storage Commitment, MPPS, C-FIND-MWL等功能。

參考規格

  • 開單作業(ADT)
  • Query Modality Worklist [RAD-5]
  • Modality Images Stored [RAD-8]
  • 其他