XDS.b Document Source Stores Document

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

  2. 流程圖：

    pic

  3. 指示：
    Note 1: Document Source systems which do not produce their own documents (ie operate as middleware) must come to Connectathon prepared to create documents for specific patients as specified in all XDS tests.
    A Document Source system will be required to generate documents on demand using patients specified by the test instructions.
    ATNA audit log messages for all XDS tests should be pointed at the NIST Audit Log Relay.
    This is a difficult test because it requires the attention of three systems: 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.
    In the end, you have to demonstrate end to end operation.
    At the end of this test, we want you to update a common place in Kudu to store information about the document that was stored.
    This will facilitate query operations by Document Consumers.
    This test requires the Document Source to use a patient name that will allow the monitors to more easily find the Source documents in the Registries and Repositories.

  4. 描述：
    The XDS_Doc_Source_Stores_Document test is a test of ITI transactions 41 and 42. A Document Source supplies at least one document and submits that document to a Document Repository. This test covers a single submission set and a single document; options on the Document Source are covered in different tests.
    ITI-41 is tightly coupled to ITI-42: Register Document Set. When the Document Source has provided the original document, the Document Repository will then register that document with the Document Registry.
    You shall perform this test using TLS communication. That means you need to have TLS working at the beginning of the Connectathon. You are not required to demonstrate ATNA logging for this test, but you will need to use TLS communication.
    When you have completed this test, you must record reference information in the Kudu tool that will help Doc Consumers find your document under Connectathon Images/CDs/Objects. The link to that page is Objects Information. You'll be prompted for several values to provide.
    If the connectathon monitor does not find the document referenced by the Submission Set uniqueID, the test will fail.
    If the connectathon monitor finds multiple instances of the Submission Set uniqueID in this registry or other registries, the test will fail.
    You need to create unique Submission Set uniqueIDs for all submissions during the connectathon. The Monitor may ask for evidence/logs that you ran this test or ask you to run the test again in person.
    As you complete the test, you should record log information/evidence in the Kudu chat window for this instance of the test. That would allow you to quickly show the Monitor your log data.

  5. 驗證：
    Evaluation is done in two phases. In the first phase, one Connectathon monitor will visit the systems and examine the log files looking for evidence that the transactions were carried out using TLS. The Connectathon monitor may ask you to repeat the test.
    Logging Requirements (ITI TF-2:3.41.7 & 3.42.7)
    For ITI-42 (Provide & Register), the Doc Source will log an "Export" event containing the Patient ID and the submissionSet uniqueID from the document metadata (among other fields)
    For ITI-42 (Provide & Register), the Doc Repository will log an "Import" event containing the Patient ID and the submissionSet uniqueID from the document metadata (among other fields)
    For ITI-41 (Register Doc), the Doc Repository will log an "Export" event containing the Patient ID and the submissionSet uniqueID from the document metadata (among other fields).
    For ITI-41 (Register Doc), the Doc Repository will log an "Import" event containing the Patient ID in the document metadata (among other fields).
    Once the security requirements are confirmed, the monitor will set the state to partially verified.
    The second part of the evaluation will be a query run against the Registry to determine if the Submission Set IDs can be found and if there are multiple copies of that value. This will be followed by a retrieval of the registered documents. The URI must indicate TLS (https://).
    Finally, if the documents produced by the Document Source system do not conform to one of the IHE content profiles, the Connectathon monitor will verify that the documents produced by this system, comply with a published healthcare standard, including wrapping support of such generic electronic formats. Unstructured data, such as text files, proprietary document formats (eg RTF), or images, shall be encapsulated within a standard document format (Ref ITI TF-1: 10.4.2).