<H3>Special Instructions</H3><p>  <p>     <em>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. </em> </p>  <p>ATNA audit log messages for all XDS tests should be pointed at the NIST Audit Log Relay.</p> <p>This is a difficult test because it requires the attention of three systems:</p> <ul>     <li>Document Source</li>     <li>Document Repository</li>     <li>Document Registry</li> </ul> <p>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.</p> <p>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.</p> <p>This test requires the Document Source to use a patient name that will allow the monitors to    more easily find the Source's documents in the Registries and Repositories. </p> </p>  <H3>Description</H3> <p>The<strong> XDS_Doc_Source_Stores_</strong>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.</p> <p>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.</p><p>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.</p>  <p>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 <em><a href=system_con_object.php>Objects Information</a>. .</em>  You'll be prompted for several values to provide.</p>  <p>If the connectathon monitor does not find the document referenced by the Submission Set    uniqueID, the test will fail.</p><p>If the connectathon monitor finds multiple instances of the Submission Set uniqueID in this    registry or other registries, the test will fail.</p><p>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.</p><p>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.</p>  <H3>Evaluation</H3>  <p>Evaluation is done in two phases. In the <b>first phase</b>, 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.</p>  <p><u>Logging Requirements (ITI TF-2:3.41.7 & 3.42.7)</u></p> <ul> <li>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)</li> <li>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)</li> <li>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).</li> <li>For ITI-41 (Register Doc), the Doc Repository will log an "Import" event containing the Patient ID in the document metadata (among other fields).</li> </ul>  <p>Once the security requirements are confirmed, the monitor will set the state to partially verified.</p>  <p>The <b>second part of the evaluation</b> 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://). </p><p>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).</p> 