<h3>Special Instructions</h3> This is a difficult test because it requires the attention of three systems:  <ul>   <li>Document Source</li>   <li>Document Repository</li>   <li>Document Registry</li>  </ul> 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 store information about the document that was stored in <a href=/europe2007/system_con_object.php>Connectathon Object</a>. Make sure that in the description of the object you enter all the information necessare for the document consumers to query the document. This will facilitate query operations by Document Consumers.  <p>This test requires the Document Source to create a new patient with a name that will allow the monitors to see the coupling to the Document Source. We also ask you to submit a second document for the well known patient: Farnsworth^Steve. This well known patient should have entries in the PIX and PDQ managers to make sure you can perform those translations if you need to link PIX or PDQ to your XDS submission.</p>  <h3>Description</h3> <p>The XDS_Doc_Source_Stores_Document test is a test of ITI transactions 15 and 14. A Document Source supplies at least one document and registers that document with 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 Transaction 15 is tightly coupled to ITI Transaction 14: 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 need to record the Submission Set uniqueID that was used to submit the document. Place this value in the chat data recorded by Kudu for this instance of the test. The connectathon monitor will query the registry for this document.</p>  <p>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.</p>  <p>You need to create unique Submission Set uniqueIDs for all submissions during the connectathon.</p>  <p>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.</p>  <h3>Evaluation</h3> <p>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.</p>  <p>Once the TLS logs are confirmed, the monitor will set the state to partially confirmed.</p>  <p>The second part of the evaluation will be a query run against the registry to determine if the Submission Set ID can be found and if there are multiple copies of that value. This will be followed by a retrieval of the registered document.  The URI must indicate TLS (https://).</p>  