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)

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 - 生理量測數據互通

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

藥品資訊呈現方式

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

數據格式要求

測試情境

• 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 - DICOMWeb查詢與調閱

• 此項目採用互通性聯測機制，同一情境測試項目需滿足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 - DICOM數位全幅病理顯微鏡影像查詢與調閱

• 說明:
  此賽道主要目的在於測試病理影像儲存管理主機(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 - 基因定序標記

基因檢測紀錄

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 - 影像檢查流程

目的

• 提供場域針對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]
• 其他