<H3>Special Instructions</H3><p> <p>This test shall be run using TLS.</p> <p>The connectathon monitor will also look for evidence of logging.  You should use the NIST ARR.</p> </p>  <H3>Description</H3> <p>The <strong>XDS_Patient_Feed</strong> test is used to load patient identifiers in the XDS    Registry and to test the Registry's response to a merge.</p><p>Each Patient Identity Source should create new patients of the form:</p>  <table border="1" cellpadding="0">     <tr>      <td>       <p align="center">        <strong>North America</strong>       <strong> </strong>       </p>      </td>     <td>       <p align="center">        <strong>Europe</strong>       <strong> </strong>       </p>      </td>     <td>       <p align="center">        <strong>Japan</strong>       <strong> </strong>       </p>      </td>     </tr>     <tr>      <td>       <p>IDENTITY^REGISTRY^S</p>      </td>     <td>       <p>IDENTITY^REGISTRY^S'</p>      </td>     <td>       <p>'</p>      </td>     </tr>     <tr>      <td>       <p>IDENTITY^REGISTRY^N</p>      </td>     <td>       <p>IDENTITY^REGISTRY^N'</p>      </td>     <td>       <p>'</p>      </td>     </tr> </table>  <ul>     <li>IDENTITY is the name of the Patient Identity Source in the Kudu system, or a 3-4 letter     abbreviation.' REGISTRY is the name of the Document Registry in the Kudu system, or a     3-4 letter abbreviation.</li>     <li> <strong>S</strong> stands for Surviving patient and<strong> N </strong>stands for     Non-Surviving Patient (used to test marge).</li> </ul><p>''''''''''''''''''''    For example: <strong>Sms^Agfa^S</strong> </p><p>The Patient Identity Source should send one ADT A01 'or ADT A04 message (ITI-8) to    inform the Registry of patient 'S' and patient 'N'. 'Patient Identity Source should    populate the PID fields listed in the table below. Other fields may be populated if desired, but    the Connectathon monitor will look for data in these fields:</p>   <table border="1" cellspacing="0" cellpadding="0">     <tr>      <td width="127" valign="top">      <strong>PID Seq</strong>     </td>     <td width="210" valign="top">       <p align="center">        <strong>Element Name</strong>       </p>      </td>     <td width="301" valign="top">       <p align="center">        <strong>Notes</strong>       </p>      </td>     </tr>     <tr>      <td width="127" valign="top">       <p>3</p>      </td>     <td width="210" valign="top">       <p>Patient Identifier List</p>      </td>     <td width="301" valign="top">       <p>User proper assigning authority</p>      </td>     </tr>     <tr>      <td width="127" valign="top">       <p>5</p>      </td>     <td width="210" valign="top">       <p>Patient Name</p>      </td>     <td width="301" valign="top">       <p>See above</p>      </td>     </tr>     <tr>      <td width="127" valign="top">       <p>7</p>      </td>     <td width="210" valign="top">       <p>Date/Time of Birth</p>      </td>     <td width="301" valign="top">       <p>'</p>      </td>     </tr>     <tr>      <td width="127" valign="top">       <p>11</p>      </td>     <td width="210" valign="top">       <p>Patient Address (this is R2, and a value may not be available)</</p>      </td>     <td width="301" valign="top">       <p>Use Connectathon address if possible</p>      </td>     </tr> </table>  <H3>Evaluation</H3> <p>1. <u>TLS verification:</u></p> <p>The Connectathon monitor will examine logs that show a successful TLS handshake.</p>  <p>2. <u>Patient Identity Feed:</u> </p><p> Connectathon monitor should examine log files or database entries at the Document Registry    indicating the patients have been registered. The Document Registry is not expected to have a    formal GUI to demonstrate this data, but it will need to maintain the data in some persistent    manner.</p><ul>     <li>For patient IDENTITY^REGISTRY^S, the Connectathon monitor is looking for data in PID-3,     PID-5,  and PID-7.   PID-11 is R2 in the Technical Framework, so it may be empty. Other fields can be populated and ignored. </li> </ul><p>Also verify that patient IDENTITY^REGISTRY^N and IDENTITY^REGISTRY^S were registered (before    the merge). </p><p></p> <p>3. <u>Merge functionality</u>:</p><p>Connectathon monitor needs to know what records were available for both patients before the    merge occurs. The monitor should then examine the database of the Document Registry or dragoon a    Document Consumer into service to perform queries of the Document Registry. </p><p>The Connectathon monitor will verify that the Registry rejected a document submission for the    Non-Surviving patient.</p> <p>4. <u>Audit Logging</u>:</p> <p>See specifics of audit requirements in ITI TF-2:3.8.5</p> <p>An audit message is sent by the Patient Identity Source when it sends A01, A04, A05, A08 and/or A40 messages to the Registry.  The audit message is a 'Patient Record' event containing the Patient ID. </p> <p>An audit message is sent by the Document Registry when it receives A01, A05, A05, A08 and/or A40 messages from the Patient Identity Source.  The audit message is a 'Patient Record' event containing the Patient ID.</p>