XDS.b 上傳文件與註冊索引

1. 參與角色： Document Source Document Repository Document Registry

2. 流程圖：

   

3. 指示：
   Document Source 系統不自己產生文件(操作作為中介軟體)，必須使用聯測在所有 XDS 測試針對特定病人而建立的文件。
   這是一個困難的測試，因為它要求到三個系統: Document Source
Document Repository
Document Registry
   We provide no guidance on whether you work first on the link that starts with the Document Source or the link that ends with the Document Registry.
   在結束時，你應該展示終端對終端的操作。
   在這個測試結束時，我們想要你更新一個共同地方在 Kudu 以儲存關於這份已被註冊文件的資訊。
   這將有助於 Document Consumer 的查詢操作。
   這個測試要求 Document Source 使用 patient name 使 monitor 可以更容易在 Registry 、 Repository 的找到文件。

4. 描述：
   這個 XDS_Doc_Source_Stores_Document 測試是一個 ITI 交易 41 和 42 的測試。
   Document Source 支援至少提交一份文件到 Document Repository 。
   這測試涵蓋一個單一交易集 、一個單一 文件； 在 Document Source 的選項被涵蓋在不同測試中。
   ITI-41 是與 ITI-42(Register Document Set) 耦合的。
   當 Document Source 已提供原始文件，那麼 Document Repository 將註冊 文件 至 Document Registry 。
   你應該執行 TLS 通訊在這測試中。
   意思是你必須從聯測開始就使用 TLS 工作。
   對於這次測試，你不會被要求展示 ATNA 記錄，但你必須使用 TLS 通訊。(ATNA 包含兩個議題: AT、NA)
   當你完成這個測試時，你必須記錄參考資訊在 Kudu 工具，這將幫助 Document Consumer 在 Connectathon Images/CDs/Objects 網頁下找到你的文件。
   你將被提示輸入幾個值。
   如果 Connectathon Monitor 沒有找到參考 Submission Set uniqueID 的文件，這個測試失敗。
   如果 Connectathon Monitor 在 Registry 或 Repository 找到多個 Submission Set uniqueID 的實例，這個測試失敗。
   你需要在聯測期間對於所有提交，建立唯一的 Submission Set uniqueID。
   Connectathon Monitor 可以詢問你執行這個測試的證據或記錄，或要求個人再次執行測試。
   當你完成這個測試，你必須對於這個測試實例記錄 "記錄資訊/證據" 在 Kudu 聊天室窗。以快速展示給 Connectathon Monitor 你的記錄資料。

5. 驗證： 兩階段完成評估：

   1. 第一階段，Connectathon monitor 將訪問系統以及檢視 "記錄檔"，查詢交易使用 TLS 進行的證據。Connectathon monitor 可要求你重複這個測試。

      記錄要求：

      • 針對 ITI-42 (Provide & Register)，Doc Source 將記錄一個 "匯出" 事件包含來自 文件metadata 的 Patient ID 和 submissionSet uniqueID。
      • 針對 ITI-42 (Provide & Register)，Doc Repository 將記錄一個 "匯入" 事件包含來自 文件metadata 的 Patient ID 和 submissionSet uniqueID。
      • 針對 ITI-41 (Provide & Register)，Doc Repository 將記錄一個 "匯出" 事件包含來自 文件metadata 的 Patient ID 和 submissionSet uniqueID。

      • 針對 ITI-41 (Provide & Register)，Doc Repository 將記錄一個 "匯入" 事件包含來自 文件metadata 的 Patient ID 。

        一旦安全性要求被確認，Monitor 將設定狀態為 部分驗證。

   2. 第二階段，針對 Registry 查詢以確認，如果 Submission Set IDs 可以被找到而且有多個拷貝值。之後可作為調閱的文件。URI 必須是 TLS (https://)。

   3. 最後，如果Document Source 產生不符合 IHE 規範的文件，Connectathon monitor 將檢驗由這個系統產生的文件。
      符合一個公布的健康照護標準，包含支援通用電子格式的包裝。
      非結構化資料(例如文本檔案、專有格式的文件(例 RTF)、或影像) 必須被封裝在一個標準化文件格式內(參考 ITI TF-1:10.4.2)