<H3>Special Instructions</H3><p> <p> Patient Identity Sources and Document Registries which support the Patient Identity Feed HL7v3    option run this test. </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> </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 ITI-44 message to    inform the Registry of patient 'S' and patient 'N'. 'Patient Identity Source should    populate attributes in the message with the guidance for values listed in the table below. Other attributes 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="210" valign="top">       <p align="center"> <strong>Value</strong> </p>     </td>     <td width="301" valign="top">       <p align="center">        <strong>Notes</strong>      </p>     </td>     </tr>     <tr>      <td width="210" valign="top">       <p>Patient ID </p>     </td>     <td width="301" valign="top">       <p>Use proper assigning authority</p>     </td>     </tr>     <tr>      <td width="210" valign="top">       <p>The patient's name</p>     </td>     <td width="301" valign="top">       <p>See guidance on name above</p>     </td>     </tr>     <tr>      <td width="210" valign="top">       <p>Date/Time of Birth</p>     </td>     <td width="301" valign="top">       <p>'</p>     </td>     </tr>     <tr>      <td width="210" height="21" valign="top">       <p>Patient Address</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 attributes Patient.id, Person.name, Person.addr, Person, and birthTime . 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>An audit message is sent by the Patient Identity Source when it sends Patient Registry Record Added, Patient Registry Record Revised, or Patient Registry Duplicates Resolved 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 Patient Registry Record Added, Patient Registry Record Revised, or Patient Registry Duplicates Resolved messages from the Patient Identity Source.  The audit message is a 'Patient Record' event containing the Patient ID.</p>