INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (628, 1, 0, '2009-11-24 10:53:19.224', 'epoiseau', '<H3>Special Instructions</H3><p> <h4>Background information </h4> <p>Experience has shown that Connectathon tests are run most efficiently if 2, or at most 3,    systems are involved in a test. Thus, most tests exercise an exchange of transactions between 2    actors.</p> <p>Later in the week, Connectathon systems are assigned to groups to test an end-to-end workflow    for all actors in profiles such as Radiology SWF, Cardiology CATH, ECHO & STRESS, and the    ITI XDS.a and XDS.b profiles. Workflow tests are executed step-by-step during an assigned 2-hour    time slot under the supervision of a Connectathon monitor who helps facilitate the process and    checks for results as transactions are exchanged between systems. </p> <p>This document outlines an XDS test and offers advice for Connectathon monitors and systems    involved in the test to help ensure the test run as smoothly as possible. There are 4 group tests    for XDS: <strong>XDS.a_Workflow_PDQ, </strong><strong>XDS.b_Workflow_PDQ,</strong>    <strong>XDS.a_Workflow_PIX,</strong> and <strong>XDS.b_Workflow_PIX</strong>. </p> <h4>Responsibilities of the Connectathon monitor</h4> <ul>     <li>Read the test and understand the steps</li>     <li>Gather the participants; explain the scenario; answer questions </li>     <li>Facilitate solving configuration issues </li>     <li>Spend the two hour test period walking participants through the test steps and helping     participants solve interoperability issues encountered</li>     <li>Debrief test participants after the test is over</li>     <li>Record notes on test results in kudu </li> </ul> <h4>Responsibililites of the workflow test participants</h4> <ul>     <li>Read the test and understand the steps</li>     <li>Attend the pre-test meeting with the Connectathon monitor </li>     <li>Configure your system to talk to your partners in the group test</li>     <li>If time, do preliminary point-to-point test with your partners</li>     <li>Follow the Connectathon monitor''s instructions</li>     <li>During the workflow tests, there may be times when your system is not involved. You may     continue with other peer-to-peer tests you need to complete, but the workflow test takes top     priority if the Connectathon monitor comes back to you </li> </ul> <h4> Workflow test preparation</h4> <table width="700" border="3" cellspacing="0" cellpadding="0">     <tr>      <td width="99">       <div align="center">        <strong>Who</strong>       </div>      </td>     <td width="209">       <div align="center">        <strong>Task</strong>       </div>      </td>     <td width="380">       <div align="center">        <strong>Notes</strong>       </div>      </td>     </tr>     <tr>      <td>Connectathon manager </td>     <td>Create groups of systems for the workflow tests. </td>     <td>       <p>This is a non-trivial task. Factors to consider include grouping systems according to their       support for XDS.a, XDS.b, PIX, PDQ (HL7 v2.x or v3), ensuring a mix of vendors is represented       in the group, whether systems are actually working well, and potentially whether the systems       will be working together in a demonstration. A sample group assignment worksheet from a       previous Connectathon is <a href="ftp://ftp.ihe.net/Connectathon/Reference_Material/group_tests_berlin.v3.xls">here</a>.      </p>      </td>     </tr>     <tr>      <td>Connectathon manager </td>     <td>Complete checklist of parameters to be used on the test </td>     <td>Located on Connectathon wiki; includes assigning authority, list of participants and their      roles, local ID to be used...</td>     </tr>     <tr>      <td>Connectathon manager </td>     <td>Gather the group; present test details: actor assignments, configuration needs (URLs,      assigning authority, patient for test), test steps, start time</td>     <td>Ideally complete a half a day before the start of the workflow tests. This enables systems      to test individual interoperability prior to the test and avoid delays during the test.</td>     </tr>     <tr>      <td>Workflow participants </td>     <td>Create patients for the test in RIS Mall </td>     <td>Complete prior to the start of all tests. </td>     </tr>     <tr>      <td>Connectathon manager </td>     <td>Gather workflow participants; present scenario </td>     <td>''</td>     </tr>     <tr>      <td>Workflow test participants </td>     <td>Configure your systems; try point-to-point tests </td>     <td>Ensure you can talk to your test partners; if time, try a transaction or two </td>     </tr> </table> </p><H3>Description</H3><p> <strong>XDS_Workflow_PIX </strong>is a test of the entire XDS workflow, including all of the    actors in the profile and actors from the PIX profile. This test traces the Patient Identity from    an Identity Source to a PIX Manager. XDS actors get the Patient ID through a direct feed, or a    PIX query. If test participants successfully complete one workflow    (submit/register/query/retrieve document) and time allows, they are encouraged proceed to the    optional steps at the end of the tests. </p><p>This test is applicable to actors in XDS.b. The PIX actors will support either    HL7 v2.x or HL7 v3. Actors will be assigned to groups according to their profile support. </p> </p> <p>The test itself is contained in <a href=http://ihewiki.wustl.edu/wiki/index.php/Image:XDS_workflow.doc>this document</a> which connectathon monitors will use as they guide the test systems through the workflow   </p> <H3>Evaluation</H3> <p>This is a group test involving multiple systems. The Connectathon monitor will run the test in    real time and visit each system at the appropriate time, looking for the arrival of requested    data.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (629, 1, 0, '2009-11-24 10:53:19.227', 'epoiseau', '<p>The XDSConsumerQuery test exercises the XDS profile from the viewpoint of the XDS Consumer. It queries a specific XDS Registry by Patient ID to get a list of documents. The XDS Consumer then retrieves documents and displays them for the Project Manager. </p> <p> For evaluation, the Project Manager should observe the query and retrieve process at the Document Consumer actor. The Document Registry and Document Repository will only be examined in the event of anomalies. </p> <p> Before starting the test you need to identify Patient ID for one or more patients in the test.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (630, 1, 0, '2009-11-24 10:53:19.23', 'epoiseau', '<H3>Special Instructions</H3> This test is in the context of the XDS-I Set of DICOM Instances option. An Imaging Document Source should perform one or more of the XDSI load tests, depending on which options from Rad TF-1: 18.2 are supported. Do not perform this test if you do not support this content.  <H3>Description</H3> <p>One option for an Imaging Document Source is to register a DICOM manifest that references DICOM instances (Rad TF-1: 18.2.1). This test is used to allow each Imaging Document Source to register one sample manifest in a well known registry/repository for later retrieval.</p>  <p>Use the RIS Mall or other central Patient ID source to create a patient with the name: SYSTEM_NAME^Manifest where SYSTEM_NAME is the name of your system in the Kudu web tool. Use the Patient ID generated during this step to create the DICOM manifest of images.</p>  <p>Store the document in a repository that will register the manifest with a well-known registry.  </p>  <p>Record in the chat window for this test information about:</p> <ul> <li>patient name and Patient ID</li> <li>the manifest stored</li> <li>registry/repository pair used</li> </ul>  <p>There is no formal evaluation in this test. These documents will be evaluated in later tests when Document Consumers will attempt to retrieve, render, import and process the documents.</p>  <H3>Evaluation</H3> There is no formal evaluation of this test. These will be evaluated during the Document Consumer tests.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (631, 1, 0, '2009-11-24 10:53:19.232', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This is an optional test for 2009. Imaging Document Source actors who want to get early    experience with XDS-I using XDS.b transactions may run this test. Although you may pass this    test, there is no ''success'' credit awarded for successful testing of XDS-I on XDS.b for 2009    connectathons. </p> </p><H3>Description</H3><p>An Imaging Document Source submits a DICOM Manifest to the Document Repository using an updated    version of RAD-54 with Provide and Register Document Set-b transaction semantics (ITI-41).</p><p>Use the RIS Mall or other central Patient ID Source to create a patient with the name:    SYSTEM_NAME^Manifest.b where SYSTEM_NAME is the name of your system in the connectathon web tool.    Use the Patient ID generated during this step to create the DICOM manifest of images.</p><p>Store the document in a repository that will register the manifest with a well-known registry.</p><p>Record in the chat window for this test information about:</p><ul>     <li>patient name and Patient ID</li>     <li>the manifest stored</li>     <li>registry/repository pair used</li> </ul><p>There is no formal evaluation in this test. These documents will be evaluated in later tests    when Imaging Document Document Consumers will attempt to retrieve, render, import and process the    documents.</p><H3>Evaluation</H3><p>There is no formal evaluation of this test. These will be evaluated during the Imaging Document    Consumer tests. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (632, 1, 0, '2009-11-24 10:53:19.234', 'epoiseau', '<H3>Special Instructions</H3> This test is in the context of the XDS-I Multipart Text/PDF Report option. An Imaging Document Source should perform one or more of the XDSI load tests, depending on which options from Rad TF 3:18.2 are supported. Do not perform this test if you do not support this content.  <H3>Description</H3> <p>One option for an Imaging Document Source is to register a multipart text/PDF report (Rad TF 3:18.2.4). This test is used to allow each Imaging Document Source to register one sample multipart report in a well known registry/repository for later retrieval.</p>  <p>Use the RIS Mall or other central Patient ID source to create a patient with the name: SYSTEM_NAME^Multipart where SYSTEM_NAME is the name of your system in the Kudu web tool. Use the Patient ID generated during this step to create the report.</p>  <p>Store the document in a repository that will register the manifest with a well known registry.</p>  <p>Record in the chat window for this test information about:</p> <ul> <li>patient name and Patient ID</li> <li>the document stored</li> <li>registry/repository pair used</li> </ul>  <p>There is no formal evaluation in this test. These documents will be evaluated in later tests when Document Consumers will attempt to retrieve, render, import and process the documents.</p>  <H3>Evaluation</H3> There is no formal evaluation of this test. These will be evaluated during the Document Consumer tests.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (633, 1, 0, '2009-11-24 10:53:19.236', 'epoiseau', '<H3>Special Instructions</H3> This test is in the context of the XDS-I PDF Report option. An Imaging Document Source should perform one or more of the XDSI load tests, depending on which options from Rad TF-1: 18.2 are supported. Do not perform this test if you do not support this content.  <H3>Description</H3> <p>One option for an Imaging Document Source is to register a PDF report (Rad TF-1: 18.2.2). This test is used to allow each Imaging Document Source to register one sample PDF report in a well known registry/repository for later retrieval.</p>  <p>Use the RIS Mall or other central Patient ID source to create a patient with the name: SYSTEM_NAME^PDF where SYSTEM_NAME is the name of your system in the Kudu web tool. Use the Patient ID generated during this step to create the PDF report.</p>  <p>Store the document in a repository that will register the manifest with a well known registry.</p>  <p>Record in the chat window for this test information about:</p> <ul> <li>patient name and Patient ID</li> <li>the document stored</li> <li>registry/repository pair used</li> </ul>  <p>There is no formal evaluation in this test. These documents will be evaluated in later tests when Document Consumers will attempt to retrieve, render, import and process the documents.</p>  <H3>Evaluation</H3> There is no formal evaluation of this test. These will be evaluated during the Document Consumer tests.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (634, 1, 0, '2009-11-24 10:53:19.239', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This is an optional test for 2009. Imaging Document Source actors who want to get early    experience with XDS-I using XDS.b transactions may run this test. Although you may pass this    test, there is no ''success'' credit awarded for successful testing of XDS-I on XDS.b for 2009    connectathons. </p> </p><H3>Description</H3><p>An Imaging Document Source submits a PDF Report to the Document Repository using an updated    version of RAD-54 with Provide and Register Document Set-b transaction semantics (ITI-41).</p><p>Use the RIS Mall or other central Patient ID Source to create a patient with the name:    SYSTEM_NAME^PDF.b where SYSTEM_NAME is the name of your system in the connectathon web tool. Use    the Patient ID generated during this step to create the PDF Report.</p><p>Store the document in a repository that will register the manifest with a well-known registry.</p><p>Record in the chat window for this test information about:</p><ul>     <li>patient name and Patient ID</li>     <li>the PDF document stored</li>     <li>registry/repository pair used</li> </ul><p>There is no formal evaluation in this test. These documents will be evaluated in later tests    when Imaging Document Consumers will attempt to retrieve, render, import and process the documents.</p><H3>Evaluation</H3><p>There is no formal evaluation of this test. These will be evaluated during the Imaging Document    Consumer tests. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (635, 1, 0, '2009-11-24 10:53:19.241', 'epoiseau', '<H3>Special Instructions</H3> This test is in the context of the XDS-I Text Report option. An Imaging Document Source should perform one or more of the XDSI load tests, depending on which options from Rad TF-1: 18.2 are supported. Do not perform this test if you do not support this content.  <H3>Description</H3> <p>One option for an Imaging Document Source is to register a text report (Rad TF-1: 18.2.3). This test is used to allow each Imaging Document Source to register one sample text report in a well known registry/repository for later retrieval.</p>  <p>Use the RIS Mall or other central Patient ID source to create a patient with the name: SYSTEM_NAME^Textreport where SYSTEM_NAME is the name of your system in the Kudu web tool. Use the Patient ID generated during this step to create the text report.</p>  <p>Store the document in a repository that will register the manifest with a well known registry.</p>  <p>Record in the chat window for this test information about:</p> <ul> <li>patient name and Patient ID</li> <li>the document stored</li> <li>registry/repository pair used</li> </ul>  <p>There is no formal evaluation in this test. These documents will be evaluated in later tests when Document Consumers will attempt to retrieve, render, import and process the documents.</p>  <H3>Evaluation</H3> There is no formal evaluation of this test. These will be evaluated during the Document Consumer tests.  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (636, 1, 0, '2009-11-24 10:53:19.243', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This is an optional test for 2009. Imaging Document Source actors    who want to get early experience with XDS-I using XDS.b transactions may run this test. Although you may pass this test, there is    no ''success'' credit awarded for successful testing of XDS-I on XDS.b for 2009 connectathons. </p> </p><H3>Description</H3><p>An Imaging Document Source submits a Text Report to the Document Repository using  an updated version of RAD-54 with Provide and Register Document Set-b transaction semantics (ITI-41).</p><p>Use the RIS Mall or other central Patient ID Source to create a patient with the name:    SYSTEM_NAME^Text.b where SYSTEM_NAME is the name of your system in the connectathon web tool. Use the    Patient ID generated during this step to create the Text Report.</p><p>Store the document in a repository that will register the Text Report with a well-known registry.</p><p>Record in the chat window for this test information about:</p><ul>     <li>patient name and Patient ID</li>     <li>the Text document stored</li>     <li>registry/repository pair used</li> </ul><p>There is no formal evaluation in this test. These documents will be evaluated in later tests    when Imaging Document Consumers will attempt to retrieve, render, import and process the documents.</p><H3>Evaluation</H3><p>There is no formal evaluation of this test. These will be evaluated during the Imaging Document Document    Consumer tests. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (637, 1, 0, '2009-11-24 10:53:19.247', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This is an optional test for 2009. Imaging Document Source and Imaging Document Consumer actors    who want to get early experience with XDS-I using XDS.b transactions may run this test. Although    you may pass this test, there is no ''success'' credit awarded for successful testing of XDS-I on    XDS.b for 2009 connectathons. </p> </p><H3>Description</H3><p>An Imaging Document Source has loaded one or more samples of a DICOM manifest in a well-known    repository/registry pair. The purpose of this test is to have an Imaging Document Consumer    retrieve the manifest using ITI-43 (Retrieve Document Set-b) and then retrieve the referenced SOP    instances using either DICOM C-Move or WADO.</p><H3>Evaluation</H3><p>In real time, the Connectathon monitor should observe the entire process of querying the    registry and retrieving (Retrieve Document Set-b) the manifest. The Imaging Document Consumer    should then show how the manifest is processed and how the DICOM composite objects are retrieved    (C-Move or WADO) and displayed. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (638, 1, 0, '2009-11-24 10:53:19.248', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This is an optional test for 2009. Imaging Document Source and Imaging Document Consumer actors    who want to get early experience with XDS-I using XDS.b transactions may run this test. Although    you may pass this test, there is no ''success'' credit awarded for successful testing of XDS-I on    XDS.b for 2009 connectathons. </p> </p><H3>Description</H3><p>An Imaging Document Source has submitted a PDF Report in a well-known repository/registry pair.    The purpose of this test is to have an Imaging Document Consumer retrieve the document using    ITI-43 (Retrieve Document Set-b).</p><H3>Evaluation</H3><p>In real time, the Connectathon monitor should observe the entire process of querying the    registry and retrieving the manifest (Retrieve Document Set-b). The Imaging Document Consumer    should then show how the PDF Report is retrieved and displayed. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (639, 1, 0, '2009-11-24 10:53:19.25', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This is an optional test for 2009. Imaging Document Source and Imaging Document Consumer actors    who want to get early experience with XDS-I using XDS.b transactions may run this test. Although    you may pass this test, there is no ''success'' credit awarded for successful testing of XDS-I on    XDS.b for 2009 connectathons. </p> </p><H3>Description</H3><p>An Imaging Document Source has submitted a Text Report in a well-known repository/registry    pair. The purpose of this test is to have an Imaging Document Consumer retrieve the document    using ITI-43 (Retrieve Document Set-b).</p><H3>Evaluation</H3><p>In real time, the Connectathon monitor should observe the entire process of querying the    registry and retrieving the manifest (Retrieve Document Set-b). The Imaging Document Consumer    should then show how the Text Report is retrieved and displayed. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (640, 1, 0, '2009-11-24 10:53:19.252', 'epoiseau', '<H3>Special Instructions</H3> This test is in the context of the XDS-I Manifest option. This is explicitly a test of the C-Move method to retrieve DICOM instances from the Imaging Document Source. Use of this test will depend on which optional retrieve transaction is supported by the Imaging Document Consumer. <p>This test shall be run using ATNA TLS communication.</p> <H3>Description</H3> <p>An Imaging Document Source has loaded one or more samples of a DICOM manifest in a well known repository/registry pair. The purpose of this test is to have an Imaging Document Consumer retrieve the manifest using the ITI retrieve document transaction and then retrieve the referenced SOP instances using DICOM C-Move commands (Rad 16, 17, 27, 31, 45).</p>  <H3>Evaluation</H3> In real time, the Connectathon monitor should observe the entire process of querying the registry and retrieving the manifest. The Imaging Document Source should then show how the manifest is processed and how the DICOM composite objects are retrieved and displayed.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (641, 1, 0, '2009-11-24 10:53:19.255', 'epoiseau', '<H3>Special Instructions</H3> This test is in the context of the XDS-I Manifest option. This is explicitly a test of the WADO method to retrieve DICOM instances from the Imaging Document Source. Use of this test will depend on which optional retrieve transaction is supported by the Imaging Document Consumer. <p>This test shall be run using ATNA TLS communication.</p> <H3>Description</H3> <p>An Imaging Document Source has loaded one or more samples of a DICOM manifest in a well known repository/registry pair. The purpose of this test is to have an Imaging Document Consumer retrieve the manifest using the ITI retrieve document transaction and then retrieve the referenced SOP instances using DICOM WADO (Rad 55).</p>  <H3>Evaluation</H3> In real time, the Connectathon monitor should observe the entire process of querying the registry and retrieving the manifest. The Imaging Document Source should then show how the manifest is processed and how the DICOM composite objects are retrieved and displayed. ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (642, 1, 0, '2009-11-24 10:53:19.257', 'epoiseau', '<H3>Special Instructions</H3> This test is in the context of the XDS-I Multipart Report option. <p>This test shall be run using ATNA TLS communication.</p> <H3>Description</H3> <p>An Imaging Document Source has loaded one or more samples of a multipart report in a well known repository/registry pair. The purpose of this test is to have an Imaging Document Consumer retrieve the multipart report using the ITI Retrieve Document transaction.</p>  <p>This becomes a test of both the Source and Consumer. If the Consumer is able to retrieve and display the PDF report, we conclude that both systems are performing as expected. If this does not work properly, then further investigation is required.</p>  <H3>Evaluation</H3> In real time, the Connectathon monitor should observe the entire process of querying the registry and retrieving the multipart report.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (643, 1, 0, '2009-11-24 10:53:19.259', 'epoiseau', '<H3>Special Instructions</H3> This test is in the context of the XDS-I PDF Report option. <p>This test shall be run using ATNA TLS communication.</p> <H3>Description</H3> <p>An Imaging Document Source has loaded one or more samples of a PDF report in a well known repository/registry pair. The purpose of this test is to have an Imaging Document Consumer retrieve the PDF report using the ITI Retrieve Document transaction.</p>  <p>This becomes a test of both the Source and Consumer. If the Consumer is able to retrieve and display the PDF report, we conclude that both systems are performing as expected. If this does not work properly, then further investigation is required.</p>  <H3>Evaluation</H3> In real time, the Connectathon monitor should observe the entire process of querying the registry and retrieving the PDF report.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (644, 1, 0, '2009-11-24 10:53:19.261', 'epoiseau', '<H3>Special Instructions</H3> This test is in the context of the XDS-I Text Report option. <p>This test shall be run using ATNA TLS communication.</p> <H3>Description </H3> <p>An Imaging Document Source has loaded one or more samples of a text report in a well known repository/registry pair. The purpose of this test is to have an Imaging Document Consumer retrieve the text report using the ITI Retrieve Document transaction.</p>  <p>This becomes a test of both the Source and Consumer. If the Consumer is able to retrieve and display the PDF report, we conclude that both systems are performing as expected. If this does not work properly, then further investigation is required.</p>  <H3>Evaluation</H3> In real time, the Connectathon monitor should observe the entire process of querying the registry and retrieving the text report.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (645, 1, 0, '2009-11-24 10:53:19.264', 'epoiseau', '<H3>Special Instructions</H3> None. <H3>Description</H3> <p>An XDS-MS Document Source is required to support at least one of two options: Discharge Summary Option, Referral Option. The Document Source shall create/register two patients in the proper affinity domain: SYSTEM_NAME^Discharge and SYSTEM_NAME^Referral. Use the RIS Mall to register these patients and obtain patient identifiers.</p>  <p>Create the appropriate document for the Discharge and Referral patients. If your system does not support one of the options, create a document that indicates that this is an unsupported option.</p>  <p>For any of the coded values (allergies, medications, etc.) use only coded values found in the MESA/Connectathon Code Tables document. That document should list between 3 and 5 legal coded values. Do not invent codes or import other codes. If you find that document lacking, inform the Connectathon monitor about appropriate coded values for inclusion.</p>  <p>Store the documents in a repository that will register with a well known registry.</p>  <p>Inform the Connectathon monitor of the two patients with their Patient IDs and appropriate documents. Tell the Connectathon monitor which registry/repository pair is used so this can be documented for other users.</p>  <H3>Evaluation</H3>  <p>There is no formal evaluation in this test. These documents will be evaluated in later tests when Document Consumers will attempt to retrieve, render, import and process the documents.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (646, 1, 0, '2009-11-24 10:53:19.265', 'epoiseau', '<H3>Special Instructions</H3> None.  <H3>Description</H3>  <p> An XDS-MS Document Source is required to support Discharge Summary or Referral documents or both.  </p> <p> An XDS-MS Document Consumer is required to support both  Discharge Summary and Referral documents for one or more of the  four processing options defined for the Document Consumer: <ul> <li>View</li> <li>Document Import</li> <li>Section Import</li> <li>Discrete Data Import</li> </ul> </p>  <p> Some of those options may not be supported for both Discharge Summary and Referral documents </p>  <p>In this test, the Document Consumer locates two documents produced by a single Document Source. The Document Consumer demonstrates which of the 4 processing options are supported for each documment.</p>  <p>When examining the processing of the document, the Connectathon Monitor should evaluate the document with at least these items in mind: </ul> <li>Sections in the document are appropriate per the definitions in PCC TF 3: 3.3</li> <li>A default style sheet is provided by the Document Source. The Document Consumer is required to render the document with the default style sheet. As an option, the Document Consumer can render with a different style sheet.</li> </ul> </p>  <H3>Evaluation</H3>  In the evaluation, the Connectathon Monitor is looking for evidence that the Document Consumer can interpret the document produced by the Document Source. That is a test of both actors. The Connetathon Monitor is then looking for evidence that the Consumer processes at least one of the options as specified in the XMS-MS Integration Profile. ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (647, 1, 0, '2009-11-24 10:53:19.267', 'epoiseau', '<H3>Special Instructions</H3> None.  <H3>Description</H3> <p>One assigned Connectathon Monitor will be assigned to scrutinize XDS-MS documents. The purpose of this test is to have a single person with domain knowledge examine one example of each document. The Connectathon Monitor is looking for proper document structure, proper use of coded values and any other CDA or IHE specific requirements defined in PCC TF 3.</p>  <p>The Document Source should use the same documents produced in the XDSMSDocumentLoad test (or similar documents if those cannot easily be exported). Export the files using the following naming convention: SYSTEM_NAME_Referral.xml and SYSTEM_NAME_Discharge.xml (e.g., EMR_RENNES_Referral.xml). Collect those files in a single zip file and present to the assigned Connectathon Monitor (CD, USB drive, email as attachment).</p>  <p>The Connectathon Monitor will take the files offline and perform evaluation. The monitor will document any deficiencies and ask the Document Source to correct during the Connectathon.</p>  <p>This test needs to be completed by Tuesday at 12:00, and is better completed Monday afternoon if possible. This will give downstream Document Consumers better test documents.</p>  <H3>Evaluation</H3> In the evaluation, the Connectathon Monitor is looking for features that are specified in PCC TF 3: 3.3, the section headings. The monitor is also looking for proper use of coded values.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (648, 1, 0, '2009-11-24 10:53:19.269', 'epoiseau', '<H3>Special Instructions</H3> This is a duplicate of XDSMS_Document_Process with an Embedded Repository serving as the source of the document. <H3>Description</H3> <p> An XDS-MS Document Consumer is required to support Discharge Summary and Referral documents. There are four processing options defined for the Document Consumer: <ul> <li>View</li> <li>Document Import</li> <li>Section Import</li> <li>Discrete Data Import</li> </ul> </p>  <p>In this test, the Document Consumer locates two documents produced by a single Document Source. The Document Consumer demonstrates which of the 4 processing options are supported for each documment.</p>  <p>When examining the processing of the document, the Connectathon Monitor should evaluate the document with at least these items in mind: </ul> <li>Sections in the document are appropriate per the definitions in PCC TF 3: 3.3</li> <li>A default style sheet is provided by the Document Source. The Document Consumer is required to render the document with the default style sheet. As an option, the Document Consumer can render with a different style sheet.</li> </ul> </p>  <H3>Evaluation</H3>  In the evaluation, the Connectathon Monitor is looking for evidence that the Document Consumer can interpret the document produced by the Document Source. That is a test of both actors. The Connetathon Monitor is then looking for evidence that the Consumer processes at least one of the options as specified in the XMS-MS Integration Profile. ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (649, 1, 0, '2009-11-24 10:53:19.302', 'epoiseau', '<h3>Special Instructions</h3> <p>If your Content Creator does not support the XDS-MS  Discharge option, go to the appropriate (<a href=http://kudu/europe2007/system_con_object.php?highlight=8_8> Connectathon Object Publication/rendering page</a> and enter a one  line note to remind the monitors and other participants not to expect this  data.<br />   If you do support this option, you need to complete this  test by Day 2 at 12:00. We would prefer that you complete by Day 1 ''at 17:00 if possible. If you complete after Day  2 at 12:00, you increase your risk that Content Consumers will ignore your  document, and you will be marked incomplete.</p> <h3>Description</h3> <p>The Content Creator shall create/register one patient in  the proper affinity domain: SYSTEM_NAME^Discharge. Use the RIS Mall to register  this patient and obtain a patient identifier.<br />   Create the appropriate document for the Discharge patient.<br />   For any of the coded values (allergies, medications, etc.)  use only coded values found in the MESA/Connectathon Code Tables document. That  document should list between 3 and 5 legal coded values. Do not invent codes or  import other codes. If you find that document lacking, inform the Connectathon  monitor about appropriate coded values for inclusion.</p> <ol>   <li>Enter the Patient ID,  Patient Name, company name, your name, and your Kudu system name into the description of the <a href=/europe2007/system_con_object.php?highlight=8_8>Objects information</a>.</li>   <li>Create a screen capture of a rendering of the Discharge  document. We recognize that not all renderings will be the same.</li>   <li>Name the document XDSMS_Discharge_kudu.xml where <strong><em>kudu</em></strong> is your Kudu system name.</li>   <li>Upload information, snapshot and xml files in the <a href=/europe2007/system_con_object.php?highlight=8_8>Objects information</a> section of Kudu.</li>   <li> Upload your 2 documents according to the instructions on that  page. Update the  <a href=http://kudu/europe2007/system_con_object.php?highlight=8_8> Connectathon Object Publication/rendering page</a> page to list your document/zip file.</li>   <li>If you support XDS, complete  XDS_Doc_Source_Stores_Document or XDS_Embedded_Repository_Registers_Document  using the Discharge document. </li> </ol> <p>These items describe the minimum content that must be  present in the Discharge document. Additional content is acceptable, but the  document must contain the following information:</p> <table border="1" cellspacing="0" cellpadding="0">   <tr>     <td width="319" valign="top"><p>11450-4: PROBLEM LIST</p></td>     <td width="319" valign="top"><p>80% blockage of the left anterior descending coronary    artery, treated with CABG.</p></td>   </tr>   <tr>     <td width="319" valign="top"><p>11348-0: HISTORY OF PAST ILLNESS</p></td>     <td width="319" valign="top"><p>Patient has no history of cardiac illnes.</p></td>   </tr>   <tr>     <td width="319" valign="top"><p>11450-4: PROBLEM LIST</p></td>     <td width="319" valign="top"><p>Stress fracture, right foot (healed) , date 1-Aug-2002</p></td>   </tr>   <tr>     <td width="319" valign="top"><p>11535-2: HOSPITAL DISCHARGE DX</p></td>     <td width="319" valign="top"><p>80% blockage of the left anterior descending coronary    artery, treated with CABG.<br />       Patient should monitor area of incision and inform    physician immediately if any signs of infection appear.</p></td>   </tr>   <tr>     <td width="319" valign="top"><p>46241-6: HOSPITAL ADMISSION DX</p></td>     <td width="319" valign="top"><p>Stress test was inconclusive; cardiac cath test    indicated 80% blockage of LAD. Admission with recommendation for surgery.</p></td>   </tr>   <tr>     <td width="319" valign="top"><p>10183-2: HOSPITAL DISCHARGE MEDICATIONS</p></td>     <td width="319" valign="top"><p>One week post surgery, begin treatment with Warfarin.<br />       Warfarain (5 mg tab) / 1 time per day / oral </p></td>   </tr>   <tr>     <td width="319" valign="top"><p>10155-0: HISTORY OF ALLERGIES</p></td>     <td width="319" valign="top"><p>Allergen: Iodinated contrast<br />       Reaction: laryngeal oedema<br />       Comments: Reaction occurs within 10 minutes</p></td>   </tr>   <tr>     <td width="319" valign="top"><p>8648-8: HOSPITAL COURSE</p></td>     <td width="319" valign="top"><p>Patient was evaluated in for chest pain.<br />       A standard stress test was administered; results were    inconclusive.<br />       A Cardiac Catheterization procedure was performed,    indicating 80% blockage of the LAD.<br />       Dr. Darrow peformed a successful CABG. <br />       Patient was returned to ICU for three days of    observation and was then discharged</p></td>   </tr>   <tr>     <td width="319" valign="top"><p>18776-5: PLAN OF CARE</p></td>     <td width="319" valign="top"><p>Patient should continue with bed rest for 1 day    following discharge.<br />       On second day, patient should slowly resume normal    activities.</p></td>   </tr> </table> <h3>Evaluation</h3> <p>This will be evaluated with the XDSMS_Document_Scrutiny  and XDSMS_Process_Discharge tests.</p>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (650, 1, 0, '2009-11-24 10:53:19.305', 'epoiseau', '<h3>Special Instructions</h3> <p>If your Content Creator does not support the XDS-MS  Referral option, then you do not have to run this test. Go to the <a href=/europe2007/system_con_object.php?highlight=8_8>Objects information</a> section of Kudu  and create an object with a description stating that you do not support Referral to remind the monitors and other participants not to expect this  data.</p>  <p> If you do support this option, you need to complete this test by Day 2 at 12:00.  We would prefer that you complete by Day 1 at 17:00 if possible.  If you complete after Day 2 at 12:00, you increase your risk that  Content Consumers will ignore your document, and you will be marked incomplete.</p> <h3>Description</h3> <p>The Content Creator shall create/register one patient in  the proper affinity domain: SYSTEM_NAME^Referral. Use the RIS Mall to register this  patient and obtain a patient identifier.</p>  <p>Create the appropriate document for the Referral patient.</p>  <p>For any of the coded values (allergies, medications, etc.)  use only coded values found in the MESA/Connectathon Code Tables document. That  document should list between 3 and 5 legal coded values. Do not invent codes or  import other codes. If you find that document lacking, inform the Connectathon  monitor about appropriate coded values for inclusion.</p> <ol>   <li>Create a readme.txt file that lists the Patient ID,  Patient Name, company name, your name, and your Kudu system name.</li>   <li>Create a screen capture of a rendering of the Referral  document. We recognize that not all renderings will be the same.</li>   <li>Name the document XDSMS_Referral_kudu.xml where <strong><em>kudu</em></strong> is your Kudu system name.</li>   <li>Upload information, snapshot and xml files in the <a href=/europe2007/system_con_object.php?highlight=8_8>Objects information</a> section of Kudu.</li>   <li>If you support XDS, complete  XDS_Doc_Source_Stores_Document or XDS_Embedded_Repository_Registers_Document  using the Referral document. </li> </ol> <p>These items describe the minimum content that must be  present in the Referral document. Additional content is acceptable, but the  document must contain the following information:</p> <table border="1" cellspacing="0" cellpadding="0">   <tr>     <td><p>42349-1: REASON FOR REFERRAL</p></td>     <td><p>Patient is otherwise healthy and is exhibiting chest    pain.</p></td>   </tr>   <tr>     <td><p>10164-2: HISTORY OF PRESENT ILLNESS</p></td>     <td><p>Patient has no history of cardiac illnes.</p></td>   </tr>   <tr>     <td><p>11450-4: PROBLEM LIST</p></td>     <td><p>Stress fracture, right foot (healed) , date 1-Aug-2002<br />       Ear infection, active, date 1-Oct-2006</p></td>   </tr>   <tr>     <td><p>10160-0: HISTORY OF MEDICATION USE</p></td>     <td><p>Amoxicillin (250 mg tabs) / 3 times per day / oral / 1-Oct-2006 '' 10-Oct-2006</p></td>   </tr>   <tr>     <td><p>10155-0: HISTORY OF ALLERGIES</p></td>     <td><p>Allergen: Iodinated contrast<br />       Reaction: laryngeal oedema<br />       Comments: Reaction occurs within 10 minutes</p></td>   </tr> </table> <h3>Evaluation</h3> <p>This will be evaluated with the XDSMS_Document_Scrutiny  and XDSMS_Process_Referral tests.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (651, 1, 0, '2009-11-24 10:53:19.308', 'epoiseau', '<H3>Special Instructions</H3> <p>If your Content Consumer does not support the XDS-MS Dicharge option, ignore this test and complete the XDSMS_Process_Discharge test.</p> <p>Content Consumers please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) your peers have submitted. </p>  <H3>Description</H3> <p>There are four processing options defined for the Content  Consumer:</p><ul> <li>View</li> <li>Document Import</li> <li>Section Import</li> <li>Discrete Data Import</li> </ul> <p>In this test, the Content Consumer locates the Discharge document produced by a single Content Creator. The Content Consumer demonstrates which of the 4 processing options are supported for the documment.<br>   When examining the processing of the document, the Connectathon Monitor should evaluate the document with at least these items in mind:</p> <ul> <li>Sections in the document are appropriate per the definitions in PCC TF</li> <li>A default style sheet is provided by the Content Creator. The Content Consumer is required to render the document with the  default style sheet. As an option, the Content Consumer can render with a  different style sheet.</li> </ul>  <H3>Evaluation</H3> <p>In the evaluation, the Connectathon Monitor is looking for evidence that the Content Consumer can interpret the document produced by the Content Creator. That is a test of both actors. The Connetathon Monitor is then looking for evidence that the Consumer processes at least one of the options as specified in the XDS-MS Integration Profile.<br>   The monitor shall check for these values in the document.  If the Content Consumer supports the view option, this data shall be rendered for display. Other options may not include processing each entry, so evaluation will require some judgment.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (652, 1, 0, '2009-11-24 10:53:19.309', 'epoiseau', '<H3>Special Instructions</H3> <p>If your Content Consumer does not support the XDS-MS Referral option, ignore this test and complete the XDSMS_Process_Discharge test.</p> <p>Content Consumers please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) your peers have submitted. </p>  <H3>Description</H3> <p>There are four processing options defined for the Content  Consumer:</p> <ul> <li>View</li> <li>Document Import</li> <li>Section Import</li> <li>Discrete Data Import</li> </ul> <p>In this test, the Content Consumer locates the Referral document produced by a single Content Creator. The Content Consumer demonstrates which of the 4 processing options are supported for the documment.<br>   When examining the processing of the document, the Connectathon Monitor should evaluate the document with at least these items in mind:</p> <ul> <li>Sections in the document are appropriate per the definitions in PCC TF</li> <li>A default style sheet is provided by the Content Creator. The Content Consumer is required to render the document with the  default style sheet. As an option, the Content Consumer can render with a  different style sheet.</li> </ul>  <H3>Evaluation</H3> <p>In the evaluation, the Connectathon Monitor is looking for evidence that the Content Consumer can interpret the document produced by the Content Creator. That is a test of both actors. The Connetathon Monitor is then looking for evidence that the Consumer processes at least one of the options as specified in the XDS-MS Integration Profile.<br>   The monitor shall check for these values in the document.  If the Content Consumer supports the view option, this data shall be rendered for display. Other options may not include processing each entry, so evaluation will require some judgment.</p>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (653, 1, 0, '2009-11-24 10:53:19.311', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> <p>The goal of this test is to create one valid XDSMS Discharge note and publish it in a location to make it easy for other participants to locate.</p> </p><H3>Description</H3><p>Each Content Creator has been assigned one well known patient (see test Content_Creator_Demographics) with a Patient ID in the proper domain. Create a document that uses the demographics for this patient and patient ID (if possible).</p><p>For any of the coded values (allergies, medications, etc.)  use only coded values found in the MESA/Connectathon Code Tables document. That  document should list between 3 and 5 legal coded values. Do not invent codes or  import other codes. If you find that document lacking, inform the Connectathon  monitor about appropriate coded values for inclusion.</p><ol> <li>These next steps refer to storing the document and reference information in the Kudu tool. You will find the page in the Kudu tool by selecting Connectathon and then Connectathon Images/CDs/Objects. The link to that page is <em><a href=system_con_object.php>Objects Information</a></em> </li>  <li>Enter the Patient ID,  Patient Name, company name, your name, and your Kudu system name into the description of the <em>Connectathon Images/CDAs/Objects</em>.</li> <li>Create a screen capture of a rendering of the XDSMS Discharge Note. We recognize that not all renderings will be the same.</li> <li>Name the document XDSMS_Discharge_kudu.xml where <strong><em>kudu</em></strong> is your Kudu system name.</li> <li>Upload information, snapshot and xml files in the <em>Connectathon Images/CDAs/Objects</em> section of Kudu.</li> <li> Upload your 2 documents according to the instructions on that  page. Update the <em> Connectathon Images/CDAs/Objects Publication/rendering page</em> page to list your document/zip file.</li> <li>Find the Connectathon monitor or monitors responsible for Document Scrutiny. Make sure they are aware your document has been placed into the Kudu tool.</li> <li>If you support XDS, complete XDS test that requires you to store and register your document with a repository/registry. You do not need to complete that XDS store step in order to complete this test. In fact, once you have uploaded the proper documentation into Kudu, mark this test complete.</li> </ol><p>These items describe the minimum content that must be  present in the Discharge document. Additional content is acceptable, but the  document must contain the following information:</p><p>The content of various modules is defined at http://ihewiki.wustl.edu/wiki/index.php/PCC_Connectathon_Content_Test_Requirements. Use the wiki page to find the right content and incorporate into your document.</p><p>As defined in the PCC TF, you must include the following content modules. Optional modules are allowed. <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td> Active Problems</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.6</td></tr>  <tr><td> Resolved Problems</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.8</td></tr>  <tr><td> Discharge Diagnosis</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.7</td></tr>  <tr><td> Admitting Diagnosis</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.3</td></tr>  <tr><td> Discharge Meds</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.22</td></tr>  <tr><td> Allergies</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.13</td></tr>  <tr><td> Hospital Course</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.5</td></tr>  <tr><td> Plan of Care</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.31</td></tr>  </table> </p><H3>Evaluation</H3> <p>This will be evaluated with the XDSMS_Scrutiny_Discharge and XDSMS_Process_Discharge tests.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (654, 1, 0, '2009-11-24 10:53:19.314', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> <p>The goal of this test is to create one valid XDSMS Referral note and publish it in a location to make it easy for other participants to locate.</p> </p><H3>Description</H3><p>Each Content Creator has been assigned one well known patient (see test Content_Creator_Demographics) with a Patient ID in the proper domain. Create a document that uses the demographics for this patient and patient ID (if possible).</p><p>For any of the coded values (allergies, medications, etc.)  use only coded values found in the MESA/Connectathon Code Tables document. That  document should list between 3 and 5 legal coded values. Do not invent codes or  import other codes. If you find that document lacking, inform the Connectathon  monitor about appropriate coded values for inclusion.</p><ol> <li>These next steps refer to storing the document and reference information in the Kudu tool. You will find the page in the Kudu tool by selecting Connectathon and then Connectathon Images/CDs/Objects. The link to that page is <em><a href=system_con_object.php>Objects Information</a></em> </li> <li>Enter the Patient ID,  Patient Name, company name, your name, and your Kudu system name into the description of the <em>Connectathon Images/CDAs/Objects</em>.</li> <li>Create a screen capture of a rendering of the XDSMS Referral note. We recognize that not all renderings will be the same.</li> <li>Name the document XDSMS_Referral_kudu.xml where <strong><em>kudu</em></strong> is your Kudu system name.</li> <li>Upload information, snapshot and xml files in the <em>Connectathon Images/CDAs/Objects</em> section of Kudu.</li> <li> Upload your 2 documents according to the instructions on that  page. Update the <em> Connectathon Images/CDAs/Objects Publication/rendering page</em> page to list your document/zip file.</li> <li>Find the Connectathon monitor or monitors responsible for Document Scrutiny. Make sure they are aware your document has been placed into the Kudu tool.</li> <li>If you support XDS, complete XDS test that requires you to store and register your document with a repository/registry. You do not need to complete that XDS store step in order to complete this test. In fact, once you have uploaded the proper documentation into Kudu, mark this test complete.</li> </ol><p>These items describe the minimum content that must be  present in the Referral document. Additional content is acceptable, but the  document must contain the following information:</p><p>The content of various modules is defined at http://ihewiki.wustl.edu/wiki/index.php/PCC_Connectathon_Content_Test_Requirements. Use the wiki page to find the right content and incorporate into your document.</p><p>As defined in the PCC TF, you must include the following content modules. Optional modules are allowed. <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td> Reason for Referral</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.1</td></tr>  <tr><td> History Present Illness</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.4</td></tr>  <tr><td> Active Problems</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.6</td></tr>  <tr><td> Current Meds</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.19</td></tr>  <tr><td> Allergies</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.13</td></tr> </table> </p><H3>Evaluation</H3><p>This will be evaluated with the XDSMS_Scrutiny_Referral and XDSMS_Process_Referral tests.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (655, 1, 0, '2009-11-24 10:53:19.316', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> <p>The monitor in charge of PCC documents will scrutinize your CDA content. He/she might not finish that work on Day 1. You need to publish the document and mark this test done to trigger the monitor to review your document.</p> <p> <em>You need to be able to produce legal content at the start of the event.</em> </p> </p> <H3>Description</H3> <p>One Connectathon Monitor will be assigned to scrutinize XDS-MS documents.      The purpose of this test is to have a single person with domain knowledge examine one      example of each document.      The Connectathon Monitor is looking for proper document structure, proper use of coded values      and content that was specified in the Publish test.</p> <p>The Content Creator should use the same documents produced and stored in the Kudu tool in the APR_Publish_Discharge test.</p> <p>The Connectathon Monitor will take the files offline and perform evaluation.      The monitor will document any deficiencies and ask the Content Creator to correct      during the Connectathon.</p>  <H3>Evaluation</H3> <p>Monitors please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) the Content Creators have submitted. </p>  <p>The NIST Evaluation tools are found at <a href="http://xreg2.nist.gov/cda-validation/index.html">http://xreg2.nist.gov/cda-validation/index.html</a> .      For documents not supported by the NIST tool, use the schematron file found at IHESCHEMATRON.   </p><p>In the evaluation, the Connectathon Monitor will follow these steps:    <ol>      <li>Use CDA validation tool to make sure document is legal CDA document</li>      <li>Use Schematron test tool to see that document passes schematron tests for XDS-MS Discharge Summary</li>  <li>Examine XDS-MS Discharge document by hand (possibly with style sheet) and examine for XDS-MS specific content         in these sections.         Values are found on the         <a href="http://ihewiki.wustl.edu/wiki/index.php/PCC_Connectathon_Content_Test_Requirements">Connectathon wiki: PCC Content Test Requirements</a>         The list of modules that are required and should be examined are:  <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td> Active Problems</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.6</td></tr>  <tr><td> Resolved Problems</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.8</td></tr>  <tr><td> Discharge Diagnosis</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.7</td></tr>  <tr><td> Admitting Diagnosis</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.3</td></tr>  <tr><td> Discharge Meds</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.22</td></tr>  <tr><td> Allergies</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.13</td></tr>  <tr><td> Hospital Course</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.5</td></tr>  <tr><td> Plan of Care</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.31</td></tr>  </table>   </li> <li>NB: We are ignoring modules that are designated with optionality of O or R2.</li>     </ol> </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (656, 1, 0, '2009-11-24 10:53:19.318', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> <p>The monitor in charge of PCC documents will scrutinize your CDA content. He/she might not finish that work on Day 1. You need to publish the document and mark this test done to trigger the monitor to review your document.</p> <p> <em>You need to be able to produce legal content at the start of the event.</em> </p> </p> <H3>Description</H3> <p>One Connectathon Monitor will be assigned to scrutinize XDS-MS documents.      The purpose of this test is to have a single person with domain knowledge examine one      example of each document.      The Connectathon Monitor is looking for proper document structure, proper use of coded values      and content that was specified in the Publish test.</p> <p>The Content Creator should use the same documents produced and stored in the Kudu tool in the XDSMS_Publish_Referral test.</p> <p>The Connectathon Monitor will take the files offline and perform evaluation.      The monitor will document any deficiencies and ask the Content Creator to correct      during the Connectathon.</p>  <H3>Evaluation</H3> <p>Monitors please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) the Content Creators have submitted. </p>  <p>The NIST Evaluation tools are found at <a href="http://xreg2.nist.gov/cda-validation/index.html">http://xreg2.nist.gov/cda-validation/index.html</a> .      For documents not supported by the NIST tool, use the schematron file found at IHESCHEMATRON.   </p><p>In the evaluation, the Connectathon Monitor will follow these steps:    <ol>      <li>Use CDA validation tool to make sure document is legal CDA document</li>      <li>Use Schematron test tool to see that document passes schematron tests for XDS-MS Referral</li>  <li>Examine XDS-MS Referral document by hand (possibly with style sheet) and examine for XDS-MS specific content         in these sections.         Values are found on the         <a href="http://ihewiki.wustl.edu/wiki/index.php/PCC_Connectathon_Content_Test_Requirements">Connectathon wiki: PCC Content Test Requirements</a>         The list of modules that are required and should be examined are:  <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td> Reason for Referral</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.1</td></tr>  <tr><td> History Present Illness</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.4</td></tr>  <tr><td> Active Problems</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.6</td></tr>  <tr><td> Current Meds</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.19</td></tr>  <tr><td> Allergies</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.13</td></tr> </table>   </li> <li>NB: We are ignoring modules that are designated with optionality of O or R2.</li>     </ol> </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (657, 1, 0, '2009-11-24 10:53:19.32', 'epoiseau', '<p>The XDSNewDocument test allows a Document Producer (Document Source) to produce and register new documents with a Repository and Registry. </p>   <p>In the test description, one of the steps is to produce multiple documents at one time; that step might not be supported by all Document Producers.</p>  <p>For evaluation, the Project Manager will inspect logs and database entries at the Repository and Registry actors. The Project Manager will also find a Document Consumer and ask that actor to retrieve the documents.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (658, 1, 0, '2009-11-24 10:53:19.322', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Document Sources and Document Repositories which support the Off-line transaction mode option must run this test.</p> <p>This may take special setup, as Document Sources must know the email address of the Document Repository in order to provide-and-register a document set. </p> </p>  <H3>Description</H3> <p>The XDSNewDocumentOffline test allows a Document Source to produce and register new documents with a Repository and Registry using SMTP (rather than one-line mode using Soap with Attacments). </p>  <H3>Evaluation</H3> <p>For evaluation, the Project Manager will inspect logs and database entries at the Repository and Registry actors. The Project Manager will also find a Document Consumer and ask that actor to retrieve the documents.</p>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (659, 1, 0, '2009-11-24 10:53:19.324', 'epoiseau', '<H3>Special Instructions</H3> <p> <p>Special Instructions Note that you need to perform tests XDSSD_Load_PDF and XDSSD_Load_Text</p> </p>  <H3>Description</H3> <p>One specific Connectathon Monitor will be assigned to scrutinize XDS-SD documents. The purpose of this test is to have a single person examine one example of each document. The Connectathon Monitor is looking for proper document structure, proper use of coded values and any other CDA or IHE specific requirements defined in XDS-SD Profile. The Content Creator should use the same documents produced and stored in the Connectathon Wiki in the XDSSD_Load test. </p>  <p>The Connectathon Monitor will take the files offline and perform evaluation. The schematron you ran for MESA tests will be used here as well. The Monitor will document any deficiencies and ask the Content Creator to correct during the Connectathon. </p>  <p>This test needs to be completed by Tuesday at 12:00, and is better completed Monday afternoon if possible. This will give downstream Content Consumers better access to test documents. </p>  <H3>Evaluation</H3> <p>Monitors please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) the Content Creators have submitted. </p> <p>The Connectathon Monitor will take the files offline and  perform evaluation.  Evaluation consists  of two components:<a name="#creator_14110"></a> </p>  <ol> <li>The HL7 CSA R2 header has a format defined in the  profile.  This is tested using Schematron  in the MESA <em><u>Test Case 14110: XDS-SD - Verify Wrapper  Format - HL7 CDA R2</u></em><em><u>.</u></em>  The MESA Tools will be running at the  Connectathon.  The Connectathon Monitor  will take the Content Creator’s sample and run MESA test 14110 (documented in the Content  Creator test plan and duplicated here:</li> </ol>  <p>To run this test, follow these steps using a DOS  window or terminal emulator:</p><ul> <li>Set the current directory to <em>$MESA_TARGET/mesa_tests/iti/actors/ccrt</em>. </li> <li>Create an scanned document document; this should  be an CDA-wrapped document (XML file) as defined in the XDS-XD Integration  Profile. </li> <li>Run the evaluation script on your XML file  (FILE) as described below: </li> </ul>  <pre>perl  14110/eval_14110.pl log_level FILE</pre> <ul> <li>The result file is found in 14110/grade_14110.txt</li> </ul> <p>If the result file shows errors,  the Connectathon will report these to the Content Creator so they can be  repaired.    <u>A result file with no  errors is required to pass this Connectathon test.<br> </u> </p>  <ul> <li>The Connectathon Monitor may also choose to  examine the document against the  requirements in the XDS-SD Supplement, Sections 7.1.8.2 – 7.1.8.2.9.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (660, 1, 0, '2009-11-24 10:53:19.326', 'epoiseau', '<H3>Special Instructions</H3>  <p>Content Creators run one instance of this test. You need to complete this test by Tuesday at 12:00. We would prefer that you complete by Monday at 17:00 if possible. If you complete after Tuesday at 12:00, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete. </p>   <H3>Description</H3> <p>In this test, the Content Creator creates a sample scanned  plain PDF/A documents which will be used in another test by Content  Consumers.  If you only create scanned  plain text documents, run XDSSD_Load_Text instead.</p>  <p>The Content Creator shall create/register one patient in  the proper Affinity Domain: SYSTEM_NAME^XDSSD_PDF. Use the RIS Mall or HIMSS Registration Tool to register  the patient and obtain a patient identifier.</p>  <p>Create the appropriate document for the XDSSD patient.</p>  <p>Store the document and reference information in the Kudu tool. You will find the page in the Kudu tool by selecting Connectathon and then Connectathon Images/CDs/Objects. The link to that page is <em><a href=system_con_object.php>Objects Information</a></em> </p>   <p>For any of the coded values, use only coded values found  in the MESA/Connectathon Code Tables document. Do not invent codes or import  other codes. If you find that document lacking, inform the Connectathon Monitor  about appropriate coded values for inclusion.</p> <p>These items describe the minimum content that must be  present in the XDS-SD document. Additional content is acceptable, but the  document <u>must contain</u> the following information:</p>  <table border="1" cellspacing="0" cellpadding="0"> <tr>      <td width="375" valign="top"> <p>ClinicalDocument/typeId</p> </td>     <td width="263" valign="top"> <p> <typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"></typeId> </p> </td> </tr> <tr>      <td width="375" valign="top"> <p>ClinicalDocument/id</p> </td>     <td width="263" valign="top"> <p>Computed value; each document has its own id</p> </td> </tr> <tr>      <td width="375" valign="top"> <p>ClinicalDocument/title</p> </td>     <td width="263" valign="top"> <p>“Connectathon Scanned PDF Document”</p> </td> </tr> <tr>      <td width="375" valign="top"> <p>ClinicalDocument/confidentialityCode</p> </td>     <td width="263" valign="top"> <p>Req’d code value may have been provided; otherwise the Content Creator used its own value</p> </td> </tr> <tr>      <td width="375" valign="top"> <p>ClinicalDocuent/effective Time</p> </td>     <td width="263" valign="top"> <p>Computed</p> </td> </tr> <tr>      <td width="375" valign="top"> <p>ClinicalDocuent/languageCode</p> </td>     <td width="263" valign="top"> <p>en-US</p> </td> </tr> <tr>      <td width="375" valign="top"> <p>ClinicalDocument/recordTarget/patientRole/       patient/id</p> </td>     <td width="263" valign="top"> <p>extension = Patient ID value from RIS Mall patient    registration</p> </td> </tr> <tr>      <td width="375" valign="top"> <p>ClinicalDocument/recordTarget/patientRole/       patient/name</p> </td>     <td width="263" valign="top"> <p> <given>XDSSD_PDF</given>        <family> <em>your    Kudu system name </em> </family> </p> </td> </tr> <tr>      <td width="375" valign="top"> <p>ClinicalDocument/recordTarget/patientRole/       patient/birthTime</p> </td>     <td width="263" valign="top"> <p>1960</p> </td> </tr> <tr>      <td width="375" valign="top"> <p>ClinicalDocment/author/assignedAuthor/id</p> </td>     <td width="263" valign="top"> <p>Root oid of the scanning device; use your assigned oid</p> </td> </tr> <tr>      <td width="375" valign="top"> <p>ClinicalDocument /author/assignedAuthor / assignedAuthoringDevice/manufacturerModelName</p> </td>     <td width="263" valign="top"> <p>Your product name and model number</p> </td> </tr> <tr>      <td width="375" valign="top"> <p>ClinicalDocument /author/assignedAuthor/ assignedAuthoringDevice    /softwareName</p> </td>     <td width="263" valign="top"> <p>Your scanning software name and version number</p> </td> </tr> <tr>      <td width="375" valign="top"> <p>ClinicalDocument/component/nonXMLBody</p> </td>     <td width="263" valign="top"> <p>Scanned/B64-encoded content</p> </td> </tr> </table>  <H3>Evaluation</H3> <p>There is no evaluation for this test.</p> <p>It is marked "Complete" when the sample is created and placed in the object section (both snapshot and xml file) Your content will be evaluated with tests XDSSD_Document_Scrutiny and XDSSD_Process_PDF.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (661, 1, 0, '2009-11-24 10:53:19.328', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Content Creators run one instance of this test.</p> <p>    You need to complete this test by Tuesday at 12:00. We would prefer that you complete by Monday at 17:00 if possible. If you complete after Tuesday at 12:00, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.   </p> </p>  <H3>Description</H3> <p>In this test, the Content Creator creates a sample scanned plain text documents which will be used in another test by Content Consumers.  If you only create scanned PDF/A documents, run XDSSD_Load_PDF instead.</p> <p>    The Content Creator shall create/register one patient in the proper Affinity Domain: SYSTEM_NAME^XDSSD_TEXT. Use the RIS Mall or HIMSS Registration Tool to register the patient and obtain a patient identifier.</p>  <p>     Create the appropriate document for the XDSSD patient.</p>  <p>Store the document and reference information in the Kudu tool. You will find the page in the Kudu tool by selecting Connectathon and then Connectathon Images/CDs/Objects. The link to that page is <em><a href=system_con_object.php>Objects Information</a></em> </p>  <p>      For any of the coded values use only coded values found in the MESA/Connectathon Code Tables document. Do not invent codes or import other codes. If you find that document lacking, inform the Connectathon Monitor about appropriate coded values for inclusion.</p> <p>       These items describe the minimum content that must be present in the XDS-SD document. Additional content is acceptable, but the document <b>must contain</b> the following information:      </p><table border="1" cellspacing="0" cellpadding="0">        <tr>         <td width="375" valign="top"> <p>ClinicalDocument/typeId</p> </td>        <td width="263" valign="top"> <p> <typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"></typeId> </p> </td>        </tr>        <tr>         <td width="375" valign="top"> <p>ClinicalDocument/id</p> </td>        <td width="263" valign="top"> <p>Computed value; each document has its own id</p> </td>        </tr>        <tr>         <td width="375" valign="top"> <p>ClinicalDocument/title</p> </td>        <td width="263" valign="top"> <p>“Connectathon Scanned Text Document”</p> </td>        </tr>        <tr>         <td width="375" valign="top"> <p>ClinicalDocument/confidentialityCode</p> </td>        <td width="263" valign="top"> <p>Req’d code value may have been provided; otherwise the Content Creator used its own value</p> </td>        </tr>        <tr>         <td width="375" valign="top"> <p>ClinicalDocuent/effective Time</p> </td>        <td width="263" valign="top"> <p>Computed</p> </td>        </tr>        <tr>         <td width="375" valign="top"> <p>ClinicalDocuent/languageCode</p> </td>        <td width="263" valign="top"> <p>en-US</p> </td>        </tr>        <tr>         <td width="375" valign="top"> <p>ClinicalDocument/recordTarget/patientRole/<br>         patient/id</p> </td>        <td width="263" valign="top"> <p>extension = Patient ID value from RIS Mall patient    registration</p> </td>        </tr>        <tr>         <td width="375" valign="top"> <p>ClinicalDocument/recordTarget/patientRole/<br>         patient/name</p> </td>        <td width="263" valign="top"> <p> <given>XDSSD_TEXT</given> <br>          <family> <em>your    Kudu system name </em> </family> </p> </td>        </tr>        <tr>         <td width="375" valign="top"> <p>ClinicalDocument/recordTarget/patientRole/<br>         patient/birthTime</p> </td>        <td width="263" valign="top"> <p>1960</p> </td>        </tr>        <tr>         <td width="375" valign="top"> <p>ClinicalDocment/author/assignedAuthor/id</p> </td>        <td width="263" valign="top"> <p>Root oid of the scanning device; use your assigned oid</p> </td>        </tr>        <tr>         <td width="375" valign="top"> <p>ClinicalDocument /author/assignedAuthor / assignedAuthoringDevice/manufacturerModelName</p> </td>        <td width="263" valign="top"> <p>Your product name and model number</p> </td>        </tr>        <tr>         <td width="375" valign="top"> <p>ClinicalDocument /author/assignedAuthor/ assignedAuthoringDevice    /softwareName</p> </td>        <td width="263" valign="top"> <p>Your scanning software name and version number</p> </td>        </tr>        <tr>         <td width="375" valign="top"> <p>ClinicalDocument/component/nonXMLBody</p> </td>        <td width="263" valign="top"> <p>Scanned/B64-encoded content</p> </td>        </tr>       </table>  <H3>Evaluation</H3> <p>There is no evaluation for this test.  It is marked “Complete” when the sample is on the Wiki.</p> <p>    Your content will be evaluated with tests XDSSD_Document_Scrutiny and XDSSD_Process_Text.   </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (662, 1, 0, '2009-11-24 10:53:19.33', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Content Consumers please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) your peers have submitted. </p> </p>  <H3>Description</H3> <p>In this test, the Content Consumer locates the XDS-SD PDF/A document produced by a single Content Creator. </p> <p>    If the Content Creator also produces wrapped plain text you can run test XDSSD_Process_Text in parallel.   </p> <p>    The Content Consumer renders the document or performs some other useful function with the document.   </p>  <H3>Evaluation</H3> <p>In the evaluation, the Connectathon Monitor is looking for  evidence that the Content Consumer can retrieve/process the document produced  by the Content Creator. That is a test of both actors.     The Connectathon Monitor may check for some values that  were encoded in the CDA header: </p><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td width="375" valign="top"> <p>ClinicalDocument/title</p> </td>     <td width="263" valign="top"> <p>Connectathon Scanned PDF Document</p> </td>     </tr>     <tr>      <td width="375" valign="top"> <p>ClinicalDocument/confidentialityCode</p> </td>     <td width="263" valign="top"> <p>Reqd code value may be  provided; otherwise use your own </p> </td>     </tr>     <tr>      <td width="375" valign="top"> <p>ClinicalDocuent/effective Time</p> </td>     <td width="263" valign="top"> <p>Computed</p> </td>     </tr>     <tr>      <td width="375" valign="top"> <p>ClinicalDocument/recordTarget/patientRole/      patient/id</p> </td>     <td width="263" valign="top"> <p>extension = Patient ID value from RIS Mall patient registration</p> </td>     </tr>     <tr>      <td width="375" valign="top"> <p>ClinicalDocument/recordTarget/patientRole/      patient/name</p> </td>     <td width="263" valign="top"> <p> <given>XDSSD_PDF</given>       <family> <em>your Kudu system name </em> </family> </p> </td>     </tr>     <tr>      <td width="375" valign="top"> <p>ClinicalDocument/recordTarget/patientRole/      patient/birthTime</p> </td>     <td width="263" valign="top"> <p>1960</p> </td>     </tr>     <tr>      <td width="375" valign="top"> <p>ClinicalDocment/author/assignedAuthor/id</p> </td>     <td width="263" valign="top"> <p>Root oid of the scanning device; use your assigned oid</p> </td>     </tr>     <tr>      <td width="375" valign="top"> <p>ClinicalDocument /author/assignedAuthor / assignedAuthoringDevice/manufacturerModelName</p> </td>     <td width="263" valign="top"> <p>Scanner''s product name and model number</p> </td>     </tr>     <tr>      <td width="375" valign="top"> <p>ClinicalDocument /author/assignedAuthor/ assignedAuthoringDevice    /softwareName</p> </td>     <td width="263" valign="top"> <p>Scanner''s scanning software name and version number</p> </td>     </tr>     <tr>      <td width="375" valign="top"> <p>ClinicalDocument/component/nonXMLBody</p> </td>     <td width="263" valign="top"> <p>That the content of the scanned document itself is processed/displayed on the Consumer.</p> </td>     </tr> </table> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (663, 1, 0, '2009-11-24 10:53:19.332', 'epoiseau', '<H3>Special Instructions</H3> <p> <p>Content Consumers please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) your peers have submitted. </p> </p>  <H3>Description</H3> <p>In this test, the Content Consumer locates the XDS-SD plain text document produced by a single Content Creator.</p> <p>    If the Content Creator also produces wrapped PDF/A, you can run test XDSSD_Process_PDF in parallel.   </p> <p>    The Content Consumer renders the document or performs some other useful function with the document.  Note that this is not a test of the transport between the Doc Source and Doc Consumer.   </p>  <H3>Evaluation</H3> <p>In the evaluation, the Connectathon Monitor is looking for  evidence that the Content Consumer can retrieve/process the document produced  by the Content Creator. That is a test of both actors.     The Connectathon Monitor may check for some values that  were encoded in the CDA header: </p><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td width="375" valign="top"> <p>ClinicalDocument/title</p> </td>     <td width="263" valign="top"> <p>Connectathon Scanned Text Document</p> </td>     </tr>     <tr>      <td width="375" valign="top"> <p>ClinicalDocument/confidentialityCode</p> </td>     <td width="263" valign="top"> <p>Reqd code value will be   provided </p> </td>     </tr>     <tr>      <td width="375" valign="top"> <p>ClinicalDocuent/effective Time</p> </td>     <td width="263" valign="top"> <p>Computed</p> </td>     </tr>     <tr>      <td width="375" valign="top"> <p>ClinicalDocument/recordTarget/patientRole/      patient/id</p> </td>     <td width="263" valign="top"> <p>extension = Patient ID value from RIS Mall patient  registration</p> </td>     </tr>     <tr>      <td width="375" valign="top"> <p>ClinicalDocument/recordTarget/patientRole/      patient/name</p> </td>     <td width="263" valign="top"> <p> <given>XDSSD_TEXT</given>       <family> <em>your  Kudu system name </em> </family> </p> </td>     </tr>     <tr>      <td width="375" valign="top"> <p>ClinicalDocument/recordTarget/patientRole/      patient/birthTime</p> </td>     <td width="263" valign="top"> <p>1960</p> </td>     </tr>     <tr>      <td width="375" valign="top"> <p>ClinicalDocment/author/assignedAuthor/id</p> </td>     <td width="263" valign="top"> <p>Root oid of the scanning device; use your assigned oid</p> </td>     </tr>     <tr>      <td width="375" valign="top"> <p>ClinicalDocument /author/assignedAuthor / assignedAuthoringDevice/manufacturerModelName</p> </td>     <td width="263" valign="top"> <p>Scanner''s product name and model number</p> </td>     </tr>     <tr>      <td width="375" valign="top"> <p>ClinicalDocument /author/assignedAuthor/ assignedAuthoringDevice    /softwareName</p> </td>     <td width="263" valign="top"> <p>Scanner''s scanning software name and version number</p> </td>     </tr>     <tr>      <td width="375" valign="top"> <p>ClinicalDocument/component/nonXMLBody</p> </td>     <td width="263" valign="top"> <p>That the content of the scanned document itself is  processed/displayed on the Consumer.</p> </td>     </tr> </table> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (664, 1, 0, '2009-11-24 10:53:19.334', 'epoiseau', '<H3>Special Instructions</H3> You shall run this test using ATNA TLS communication.  <H3>Description</H3> The XDS_Consumer_Query test exercises the XDS profile from the viewpoint of the XDS Consumer. It queries a specific XDS Registry by Patient ID to get a list of documents. The XDS Consumer then retrieves documents and displays them for the Connectathon monitor.  <p>The Document Consumer that is testing is required to make at least one query of the Document Registry that is not specified.</p>  <p>For evaluation, the Connectathon monitor should observe the query  process at the Document Consumer actor. The Document Registry and Document Repository will only be examined in the event of anomalies.</p>  <H3>Evaluation</H3>  Connectathon monitor should observe query to registry in real time and observe logs or other evidence that the query took place using TLS communcation.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (665, 1, 0, '2009-11-24 10:53:19.336', 'epoiseau', '<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>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (666, 1, 0, '2009-11-24 10:53:19.338', 'epoiseau', '<H3>Special Instructions</H3> This test is intended for an Embedded Repository  actor and not a Document Source. There is a separate test for a Document Source.  <H3>Description</H3> <p>XDS_Embedded_Content_Wraped_PDF is intended to test the ability of a Document Source/Repository to enter a PDF document that is wrapped in CDA and the ability of a Document Consumer to retrieve and render that document. If your system does not support this content, do not execute this test.</p>  <p>This test uses a Document Registry in order to facilitate communication. Find these actors as helpers, but they are not part of the test process. This is a test of document content production and rendering.</p>  <p>The Document Consumer retrieves the PDF document from the Document Repository and renders the document. If the retrieve and render steps are successful, this indicates successful document creation, wrapping, unwrapping and rendering.</p>  <H3>Evaluation</H3> Connectathon monitor will observe the Document Consumer while it retrieves the PDF document, unwraps and renders it. The monitor is looking for a system that presents a reasonable user interface to the end user for the purpose of retrieving the document. The monitor should also be shown the document as it is retrieved. It is allowable that the document is imported into the Document Consumer system for later rendering, but that rendering should be exhibited.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (667, 1, 0, '2009-11-24 10:53:19.343', 'epoiseau', '<H3>Description</H3> XDS Document Sources (Embedded Repositories) have a number of options listed in ITI TF 1: 10.2. This set of tests is designed to test those options. The Document Source is not required to support any specific option or any of the options. Only test those options that are pertinent to the Document Source.  <p>For evaluation, the Connectathon monitor will inspect logs and database entries at the Repository and Registry actors. The Connectathon monitor will also find a Document Consumer and ask that actor to retrieve the documents.</p>  <p>In the test steps below, we will use four patients that are created in the RIS Mall or by a Patient Identity Source. The patient name is a composite of the Document Source and Document Repository actors using the following convention: <ul> <li>SOURCE^REPOSITORY^O: O stands for Off-Line Transaction Mode</li> <li>SOURCE^REPOSITORY^M: M stands for Multiple Document Submission</li> <li>SOURCE^REPOSITORY^L: L stands for Document Life Cycle Management</li> <li>SOURCE^REPOSITORY^F; F stands for Folder Management</li> </ul> </p>  <H3>Evaluation</H3>  This is an engineering test that will not be evaluated.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (668, 1, 0, '2009-11-24 10:53:19.345', 'epoiseau', '<H3>Special Instructions</H3> This test is designed for Embedded Repositories which consist of a combined Document Source and Document Repository that do not communicate with other Document Source and Document Repository actors. That is, this system only registers documents with a Document Registry and responds to Document Retrieve requests by Document Consumers.  <H3>Description</H3> The XDS_Embedded_Repository test is a test of ITI transaction 14. An Embedded Repository creates at least one document and registers that document with the Document Registry participating in this test. <H3>Evaluation</H3> Connectathon monitory will examine log files and database entries of Document Repository and Document Regitry to look for evidence of documents. Connectathon monitor will also enlist the help of a Document Consumer to query for and display documents.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (669, 1, 0, '2009-11-24 10:53:19.347', 'epoiseau', '<h3>Special Instructions</h3> <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 Embedded Repository. 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_Embedded_Repository_Registers_Document test is a test of ITI transaction 14. An Embedded Repository 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 Embedded Repository are covered in different tests.</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>  When you have completed this test, you need to record the Submission Set uniqueID that was used for 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>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.</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 uniqueID can be found and if there are multiple copies of that value.</p>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (670, 1, 0, '2009-11-24 10:53:19.349', 'epoiseau', '<H3>Special Instructions</H3> <p>This test should be driven by the Embedded Repository actor. You should know which documents you have loaded into your system. Make an effort to find Document Consumers and ask them to retrieve a document from your system.</p>  <p>This test can be grouped with other XDS tests and completed by a set of cooperating systems. It is broken out separately to provide flexibility.</p>  <p>This test shall be run using ATNA TLS communication.</p>  <p>This test uses two different patients for retrieving documents. The first patient is to be determined by the systems involved; find a patient that has been registered by a Document Source. This is a good test of different Document Source actors.</p>  <p>The second patient is a specific patient. Use the patient FARNSWORTH^STEVE. The Document Consumer actor can tie this in with PIX and PDQ to create a longer workflow.</p> <H3>Description</H3> <p>An Embedded Repository is a server that does not have a user driving the retrieve process; in fact, the retrieve is by definition initiated by a different system. In this test, the Document Repository is expected to actively seek out Document Consumers to make sure that Consumers retrieve documents. If the Repository is not pro-active, it is possible that the system will be ignored.</p>  <p>This test shall be run using ATNA TLS communication.</p>  <H3>Evaluation</H3> Connectathon monitor will observe the Document Consumer while it queries for and retrieves a document from the Document Repository. Monitor will observe logs or other information indicating the communication takes place using ATNA TLS communication.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (671, 1, 0, '2009-11-24 10:53:19.351', 'epoiseau', '<H3>Special Instructions</H3> <p>One of the configuration issues in an XDS Affinity Domain is the Assigning Authority used in Patient identifiers. In testing at a Connectathon, it is easiest for the Document Registry and Document Repository actors to use a single Assigning Authority. This test and other connectathon tests will require each Identity Source to use the same Assigning Authority but will ask that each Identity Source use a different numeric range for the identifiers.</p>  <H3>Description</H3> The XDS_Patient_Feed test is used to load patient identifiers in the XDS Registry. These are the same identifiers that will be used to submit documents in other tests. Each Identity Source should create two new patients of the form <table border="1"> <tr><th>North America</th><th>Europe</th><th>Japan</th></tr> <tr><td>IDENTITY^REGISTRY^S</td><td>IDENTITY^REGISTRY^Së</td><td></td></tr> <tr><td>IDENTITY^REGISTRY^N</td><td>IDENTITY^REGISTRY^Në</td><td></td></tr> </table> <ul> <li>IDENTITY is the name of the Identity Source in the Kudu system, or a 3-4 letter abbreviation</li> <li>REGISTRY is the name of the Document Registry in the Kudu system, or a 3-4 letter abbreviation</li> <li>S stands for Surviving patient and N stands for Non-Surviving Patient (used in later tests).</li> </ul> For example: <b>Sms^Agfa^S</b> <p>The Identity Source should send one ADT A01 message (ITI-8) to inform the Registry of patient ''S''. The Identity Source should send one ADT A04 message (ITI-8) to inform the Registry of patient ''N''. When the ITI committee determines what it means to merge patients in XDS, this test will be modified to also examine A08 update and A40 merge messages.</p> <p>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: <table border="1"> <tr><th>PID Seq</th><th>Element Name</th><th>Notes</th></tr> <tr><td>3</td><td>Patient Identifier List</td><td>Use proper assigning authority</td></tr> <tr><td>5</td><td>Patient Name</td><td>See above</td></tr> <tr><td>7</td><td>Date/Time of Birth</td><td>Use same for both patients</td></tr> <tr><td>11</td><td>Patient Address</td><td>Use Connectathon address if possible</td></tr> </table>  <H3>Evaluation</H3> <p>Connectathon monitor should examine log files or database entries at the Document Registry indicating the two 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> <p>Connectathon monitor is looking for data in PID-3, PID-5, PID-7, PID-11. Other fields can be populated and ignored.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (672, 1, 0, '2009-11-24 10:53:19.353', 'epoiseau', '<H3>Special Instructions</H3> <b>This test will not be run at the Jan 2006 Connectathon. There are still profile issues to be resolved.</b> <p> This test needs to be run later in the week after several documents have been accumulated for the Non-Suriving patient that was created in XDS_Patient_Feed. </p> <H3>Description</H3> In this test, the Identity Source merges two patients and sends the appropriate merge message to the XDS Registry actor. The patients that are merged were created in the XDS_Patient_Feed test. There should be some documents accumulated for the Non-Surviving patient. This patient is merged so that only the Surviving patient remains. After the merge, the Registry actor is queried by Patient ID to see if records remain for the Non-Surviving patient and/or if all of the documents are now available with the Surviving patient. <H3>Evaluation</H3> 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.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (673, 1, 0, '2009-11-24 10:53:19.355', 'epoiseau', '<H3>Special Instructions</H3> <p> Was previously XDSNewDocument.</p>  <p>This test should be attempted only after passing an instance of XDS_Register_Document run against the public registry. </p>  <H3>Description</H3> The XDS_Provide_and_Register test is a test of ITI transaction 15. 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>ITI Transaction 15 is tightly coupled to ITI Transaction 14: Register Document Set. When the two actors run this test, it is assumed the Document Repository will register the document with a Document Registry. This will be the subject of a separate test, but can be accomplished in one series of transactions.</p> <p>When this test has been completed, log the following information in the <i>Comments</i> section: <ul> <li>Registry the Repository was configured to forward the metadata to </li> <li>Patient ID </li> <li>XDSSubmissionSet.uniqueId</li> </ul>  <H3>Evaluation</H3> Connectathon monitor will examine log files and database entries of Document Repository. If the Document Repository runs the parallel test XDS_Register_Document, the Connectathon monitor can observe the log or database information in the Document Registry or enlist the help of a Document Consumer to query the Document Registry and retrieve the document. <p>The monitor will examine the public registry as well as relevant logs on the Document Repository.</p> <p>The monitor can optionally use a NIST evaluation tool to examine the contents of the Document Registry</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (674, 1, 0, '2009-11-24 10:53:19.357', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You can run this test and use Kudu to track progress. Do NOT set the state to completed. Connectathon Monitors will not evaluate this test, and we do not want it marked complete in the system.</p> </p><H3>Description</H3><p>This is a test of all of the queries that are required to be supported by an XDS Document Registry. A Document Consumer is allowed to pick and choose from the menu and implement those queries that aid the Document Consumer.</p><p>In the test steps below, each instance of transaction ITI-18 represents one of the queries listed in ITI TF-2: 3.18.4.1.2. Each query is named using the title from the ITI Technical Framework.</p><H3>Evaluation</H3><p>If self-graded, please check off the boxes accurately, indicating which queries were successful. If you attempt a query and it fails, just mark as if the query was not attempted. We have no status of attempted/failed.</p><p>Registries are required to support all queries in this test, and all parameters for each query.  Document Consumers are required to support one or more queries to support the use case it implements.</p><p>This is an engineering test that will not be evaluated by a monitor.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (675, 1, 0, '2009-11-24 10:53:19.359', 'epoiseau', '<h3>Special Instructions</h3> Only run this test if you support BPPC. Otherwise, ignore this test.  <h3>Description</h3> <p>This needs to be filled in. In this test, the Document  Consumer queries for documents for two patients:</p> <ul>   <li>BPPC^Normal</li>   <li>BPPC^VIP</li> </ul> <p>After the query, the Document Consumer should display  documents to the user.<br />   The Normal patient should  have a confidentiality code of  1.3.6.1.4.1.21367.2006.7.108:  Normal Sharing Plus Research Use.<br />   The VIP patient should have a confidentiality code of  1.3.6.1.4.1.21367.2006.7.109: Restricted VIP Sharing.<br />   The Document Consumer should show documents for the Normal patient and NO documents for the VIP patient.</p> <h3>Evaluation</h3> <p>The monitor should observe the Document Consumer in real  time performing the query and retrieving documents. The monitor should observe  documents displayed for the Normal patient. If  any documents are displayed for the VIP patient, that is a failure.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (676, 1, 0, '2009-11-24 10:53:19.361', 'epoiseau', '<h3>Special Instructions</h3> Only run this test if you support BPPC. Otherwise, ignore this test.  <h3>Description</h3> <p>The Document Source registers documents for two patients:</p> <ul>   <li>BPPC^Normal</li>   <li>BPPC^VIP</li> </ul> <p> You will find these patients in the RIS Mall.</p> <p>The documents for Normal  will have the confidentiality policy specified by the OID 1.3.6.1.4.1.21367.2006.7.108  (Normal Sharing Plus Research Use).<br />   The documents for VIP will have the confidentiality policy  specified by the OID 1.3.6.1.4.1.21367.2006.7.109 (Restricted VIP Sharing).</p> <h3>Evaluation</h3> <p>The monitor will ask the Registry/Repositry to show the  confidentiality codes for the two patients. Or, the monitor will query the Registry/Repository with a tool to examine the codes.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (677, 1, 0, '2009-11-24 10:53:19.364', 'epoiseau', '<h3>Special Instructions</h3> This test requires the attention of two systems:  <ul>   <li>Document Source</li>   <li>Combined Registry/Repository</li>  </ul> In the end, you have to demonstrate end to end operation. <p> At the end of this test, we want you to update a Wiki 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 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_REG_REP_Doc_Source_Stores_Document test is a test of ITI transactions 15. A Document Source supplies at least one document and registers that document with a Registry/Repository. This test covers a single submission set and a single document; options on the Document Source are covered in different tests.</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>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (678, 1, 0, '2009-11-24 10:53:19.366', 'epoiseau', '<H3>Special Instructions</H3> <p>One of the configuration issues in an XDS Affinity Domain is the Assigning Authority used in Patient identifiers. In testing at a Connectathon, it is easiest for the Registry/Repository actors to use a single Assigning Authority. This test and other connectathon tests will require each Identity Source to use the same Assigning Authority but will ask that each Identity Source use a different numeric range for the identifiers.</p>  <H3>Description</H3> The XDS_REG_REP_Patient_Feed test is used to load patient identifiers in a XDS Combined Registry/Repository. These are the same identifiers that will be used to submit documents in other tests. Each Identity Source should create two new patients of the form <table border="1"> <tr><th>North America</th><th>Europe</th><th>Japan</th></tr> <tr><td>IDENTITY^REGISTRY^S</td><td>IDENTITY^REGISTRY^Së</td><td> </td></tr> <tr><td>IDENTITY^REGISTRY^N</td><td>IDENTITY^REGISTRY^Në</td><td> </td></tr> </table> <ul> <li>IDENTITY is the name of the Identity Source in the Kudu system, or a 3-4 letter abbreviation</li> <li>REGISTRY is the name of the Registry/Repository actor in the Kudu system, or a 3-4 letter abbreviation</li> <li>S stands for Surviving patient and N stands for Non-Surviving Patient (used in later tests).</li> </ul> For example: <b>Sms^Agfa^S</b> <p>The Identity Source should send one ADT A01 message (ITI-8) to inform the Registry/Repository of patient ''S''. The Identity Source should send one ADT A04 message (ITI-8) to inform the Registry/Repository of patient ''N''. When the ITI committee determines what it means to merge patients in XDS, this test will be modified to also examine A08 update and A40 merge messages.</p> <p>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: <table border="1"> <tr><th>PID Seq</th><th>Element Name</th><th>Notes</th></tr> <tr><td>3</td><td>Patient Identifier List</td><td>Use proper assigning authority</td></tr> <tr><td>5</td><td>Patient Name</td><td>See above</td></tr> <tr><td>7</td><td>Date/Time of Birth</td><td>Use same for both patients</td></tr> <tr><td>11</td><td>Patient Address</td><td>Use Connectathon address if possible</td></tr> </table>  <H3>Evaluation</H3> <p>Connectathon monitor should examine log files or database entries at the Registry/Repository indicating the two patients have been registered. The Document Registry/Repository 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> <p>Connectathon monitor is looking for data in PID-3, PID-5, PID-7, PID-11. Other fields can be populated and ignored.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (679, 1, 0, '2009-11-24 10:53:19.369', 'epoiseau', '<H3>Special Instructions</H3> This test should be driven by the Combined Registry/Repository actor. You should know which documents have been stored in your system. Make an effort to find Document Consumers and ask them to retrieve a document from your system. This test can be grouped with other XDS tests and completed by a set of cooperating systems. It is broken out separately to provide flexibility. <p>You will need to seek out one or more Document Source actors to load your Registry/Repository with documents to be retrieved.</p>  <p>This test shall be run using ATNA TLS communication.</p>  <H3>Description</H3> <p>A Document Repository is a server that does not have a user driving the retrieve process; in fact, the retrieve is by definition initiated by a different system. In this test, the Document Repository is expected to actively seek out Document Consumers to make sure that Consumers retrieve documents. If the Repository is not pro-active, it is possible that the system will be ignored.</p>  <p>This test uses two different patients for retrieving documents. The first patient is to be determined by the systems involved; find a patient that has been registered by a Document Source. This is a good test of different Document Source actors.</p>  <p>The second patient is a specific patient. Use the patient FARNSWORTH^STEVE. The Document Consumer actor can tie this in with PIX and PDQ to create a longer workflow.</p>   <H3>Evaluation</H3> Connectathon monitor will observe the Document Consumer while it queries for and retrieves a document from the Document Repository. Monitor will observe logs or other information indicating the communication takes place using ATNA TLS communication.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (680, 1, 0, '2009-11-24 10:53:19.372', 'epoiseau', '<H3>Special Instructions</H3> This test is designed to be run in parallel with XDS_Provide_and_Register. Use the Kudu tool to run XDS_Provide_and_Register with a Document Source and Document Repository. Assuming you have enlisted a Document Registry to run that test, use the Kudu tool to start/stop that test. Ask the Connectathon monitor to evaluate both tests at the same time.  <H3>Description</H3> The XDS_Register_Document test is a test of ITI transaction 14. A Document Source supplies at least one document and submits it to a Document Repository. The Document Repository then registers that document with the Document Registry participating in this test. <p> To run this test, locate a Document Source that can cooperate and provide a document. Have that source provide the document to the Document Repository; the Document Repository then registers the document with a Document Registry.</p>  <p>When this test has been completed, log the following information in the <i>Comments</i> section: <ul> <li>Patient ID </li> <li>XDSSubmissionSet.uniqueId</li> </ul>  <H3>Evaluation</H3> The Connectathon monitor can observe the log or database information in the Document Registry or enlist the help of a Document Consumer to query the Document Registry and retrieve the document.  <p>Note that the transaction ITI-14 between the Registry and the Repository is optional when the actors are combined.</p>  <p>The monitor can optionally use a NIST evaluation tool to examine the contents of the Document Registry</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (681, 1, 0, '2009-11-24 10:53:19.375', 'epoiseau', '<h3>Description</h3> <p>XDS Document Repository, Document Registry and Combined Registry/Repository actors are required to support Folder Managment. This is considered optional for Document Source actors but is required  for Document Repository and Document Registry actors.</p>  <p>In this test, we use a Document Source that supports these options or a test tool designed to test specifically for these features.</p>  <p>In the test steps below, we will use one patient created in the RIS Mall or by a Patient Identity Source. The patient name is a composite of the Document Source and Document Repository (or Registry/Repository) actors using the following convention:  <ul>   <li>REGISTRY^REPOSITORY^F; F stands for Folder Management</li>  </ul> </p>  <h3>Evaluation</h3> Connectathon monitor will examine log files and database entries of Combined Registry/Repository, or Document Repository and Document Registry to look for evidence of documents.  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (682, 1, 0, '2009-11-24 10:53:19.377', 'epoiseau', '<h3>Special Instructions</h3> None.  <h3>Description</h3> <pPXDS Document Repository and Document Registry actors are required to support Document Life Cycle Managment. This is considered optional for Document Source actors but is required for Document Repository and Document Registry actors.</p>  <p>In this test, we use a Document Source that supports these options or a test tool designed to test specifically for these features.</p>  <p>In the test steps below, we will use one patient created in the RIS Mall or by a Patient Identity Source. The patient name is a composite of the Document Source and Document Repository (or Registry/Repository) actors using the following convention: <ul>  <li>REGISTRY^REPOSITORY^L: L stands for Document Life Cycle Management</li> </ul> </p>  <h3>Evaluation</h3> <p>Connectathon monitor will examine log files and database entries of Combined Regisitry/Repository, or Document Repository and Document Registry to look for evidence of documents.  </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (683, 1, 0, '2009-11-24 10:53:19.378', 'epoiseau', '<>h3>Special Instructions</h3> None.  <h3>Description</h3> <p>XDS Document Repository, Document Registry and Combined Registry/Repository actors are required to support Multiple Document Submission. This is considered optional for Document Source actors.</p>  <p>In this test, we use a Document Source that supports these options or a test tool designed to test specifically for these features.</p>  <p>In the test steps below, we will use one patient created in the RIS Mall or by a Patient Identity Source. The patient name is a composite of the Document Source and Document Repository (or Combined Registry/Repository) actors using the following convention:  <ul>   <li>REGISTRY^REPOSITORY^M: M stands for Multiple Document Submission</li>  </ul> </p>  <h3>Evaluation</h3> <p>Connectathon monitor will examine log files and database entries of Combined Registry/Repository, Document Repository and Document Registry  to look for evidence of documents.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (684, 1, 0, '2009-11-24 10:53:19.381', 'epoiseau', '<H3>Description</H3> <p>XDS Document Repository and Document Registry actors are required to support a number of different mechanisms for managing documents. These mechanisms are considered options for Document Source actors but are requirements for Document Repository and Document Registry actors.</p>  <p>In this test, we use a Document Source that supports these options or a test tool designed to test specifically for these features.</p>  <p>For evaluation, the Connectathon monitor will inspect logs and database entries at the Repository and Registry actors. The Connectathon monitor will also find a Document Consumer and ask that actor to retrieve the documents.</p>  <p>In the test steps below, we will use four patients that are created in the RIS Mall or by a Patient Identity Source. The patient name is a composite of the Document Source and Document Repository actors using the following convention: <ul> <li>REGISTRY^REPOSITORY^M: M stands for Multiple Document Submission</li> <li>REGISTRY^REPOSITORY^L: L stands for Document Life Cycle Management</li> <li>REGISTRY^REPOSITORY^F; F stands for Folder Management</li> </ul> </p>  <H3>Evaluation</H3> Connectathon monitor will examine log files and database entries of Document Repository and Document Registry to look for evidence of documents. Connectathon monitor will also enlist the help of a Document Consumer to query for and display documents. <p> Note that if Registry and Repository are combined, the transaction ITI-14 is optional. Do not fail the test in that case.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (685, 1, 0, '2009-11-24 10:53:19.383', 'epoiseau', '<H3>Special Instructions</H3> This test should be driven by the Document Repository actor. You should know which documents have been stored in your system. Make an effort to find Document Consumers and ask them to retrieve a document from your system. This test can be grouped with other XDS tests and completed by a set of cooperating systems. It is broken out separately to provide flexibility. <p>You will need to seek out one or more Document Source actors to load your Document Repository with documents to be retrieved.</p>  <p>This test shall be run using ATNA TLS communication.</p>  <H3>Description</H3> <p>A Document Repository is a server that does not have a user driving the retrieve process; in fact, the retrieve is by definition initiated by a different system. In this test, the Document Repository is expected to actively seek out Document Consumers to make sure that Consumers retrieve documents. If the Repository is not pro-active, it is possible that the system will be ignored.</p>  <p>This test uses two different patients for retrieving documents. The first patient is to be determined by the systems involved; find a patient that has been registered by a Document Source. This is a good test of different Document Source actors.</p>  <p>The second patient is a specific patient. Use the patient FARNSWORTH^STEVE. The Document Consumer actor can tie this in with PIX and PDQ to create a longer workflow.</p>   <H3>Evaluation</H3> Connectathon monitor will observe the Document Consumer while it queries for and retrieves a document from the Document Repository. Monitor will observe logs or other information indicating the communication takes place using ATNA TLS communication.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (686, 1, 0, '2009-11-24 10:53:19.385', 'epoiseau', '<H3>Special Instructions</H3> This test is intended for a Document Source actor and not an Embedded Document Repository. There is a separate test for an Embedded Repository.  <H3>Description</H3> <p>XDS_Source_Content_Wraped_PDF is intended to test the ability of a Document Source to enter a PDF document that is wrapped in CDA and the ability of a Document Consumer to retrieve and render that document. If your system does not support this content, do not execute this test.</p>  <p>This test uses a Document Repository and a Document Registry in order to facilitate communication. Find these actors as helpers, but they are not part of the test process. This is a test of document content production and rendering.</p>  <p>The Document Consumer retrieves the PDF document from the Document Repository and renders the document. If the retrieve and render steps are successful, this indicates successful document creation, wrapping, unwrapping and rendering.</p>  <H3>Evaluation</H3> Connectathon monitor will observe the Document Consumer while it retrieves the PDF document, unwraps and renders it. The monitor is looking for a system that presents a reasonable user interface to the end user for the purpose of retrieving the document. The monitor should also be shown the document as it is retrieved. It is allowable that the document is imported into the Document Consumer system for later rendering, but that rendering should be exhibited.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (687, 1, 0, '2009-11-24 10:53:19.39', 'epoiseau', '<h3>Special Instructions</h3> You can run this test and use Kudu to track progress. Do NOT set the state to completed. Connectathon Monitors will not evaluate this test, and we do not want it marked complete in the system.  <H3>Description</H3>  XDS Document Sources have a number of options listed in ITI TF 1: 10.2. This set of tests is designed to test those options. The Document Source is not required to support any specific option or any of the options. Only test those options that are pertinent to the Document Source. <p>For evaluation, the Connectathon monitor will inspect logs and database entries at the Repository and Registry actors. The Connectathon monitor will also find a Document Consumer and ask that actor to retrieve the documents.</p>  <p>In the test steps below, we will use four patients that are created in the RIS Mall or by a Patient Identity Source. The patient name is a composite of the Document Source and Document Repository actors using the following convention: <ul> <li>SOURCE^REPOSITORY^O: O stands for Off-Line Transaction Mode</li> <li>SOURCE^REPOSITORY^M: M stands for Multiple Document Submission</li> <li>SOURCE^REPOSITORY^L: L stands for Document Life Cycle Management</li> <li>SOURCE^REPOSITORY^F; F stands for Folder Management</li> </ul>  <H3>Evaluation</H3> This is an engineering test that will not be evaluated. ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (688, 1, 0, '2009-11-24 10:53:19.392', 'epoiseau', '<H3>Description</H3> XDS_Workflow is a test of the entire XDS workflow, including all of the actors in the profile and actors from the PIX and PDQ profiles. This test traces the Patient  Identity from an Identity Source to both a PIX Manager and a Patient Demographic Supplier. XDS actors get the Patient ID through a direct feed, or by PIX or PDQ queries.  <H3>Evaluation</H3> This is a group test involving multiple systems. The Connectathon monitor will run the test in real time and visit each system at the appropriate time, looking for the arrival of requested data.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (689, 1, 0, '2009-11-24 10:53:19.393', 'epoiseau', '<H3>Description</H3> <p>XDS_Workflow_ATNA_Enabled is a test of the entire XDS workflow with ATNA enabled, including all of the actors in the profile and actors from the PIX and PDQ profiles. This test traces the Patient Identity from an Identity Source to both a PIX Manager and a Patient Demographic Supplier. XDS actors get the Patient ID through a direct feed, or by PIX or PDQ queries.</p>  <p>Actors in this test are required to use TLS communication when establishing connections and exchanging messages/documents.</p>  <H3>Evaluation</H3> This is a group test involving multiple systems. The Connectathon monitor will run the test in real time and visit each system at the appropriate time, looking for the arrival of requested data.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (690, 1, 0, '2009-11-24 10:53:19.395', 'epoiseau', '<h3>Description</h3> <p>One assigned Connectathon Monitor will be assigned to  scrutinize XPHR documents. The purpose of this test is to have a single person  with domain knowledge examine one example of each document. The Connectathon  Monitor is looking for proper document structure, proper use of coded values  and any other CDA or IHE specific requirements defined in PCC TF 3.<br />   The Content Creator should use the same documents produced  and stored in the Connectathon Wiki in the XPHR_Load_Extract test. <br />   The Connectathon Monitor will take the files offline and  perform evaluation. The monitor will document any deficiencies and ask the PHR  Manager/PHR Reviewer to correct during the Connectathon.<br />   This test needs to be completed by Tuesday at 12:00, and is better completed Monday  afternoon if possible. This will give downstream actors better test documents.</p> <h3>Evaluation</h3> <p>In the evaluation, the Connectathon Monitor is looking for  features that are specified in PCC TF 3: 3.3, the section headings. The monitor  is also looking for proper use of coded values.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (691, 1, 0, '2009-11-24 10:53:19.398', 'epoiseau', '<h3>Special Instructions</h3> <p>You need to complete this test by Day 2 at 12:00. We would  prefer that you complete by Day 1 at 17:00 if possible. If you complete after Day  2 at 12:00, you increase your risk that PHR Reviewers will ignore your  document, and you will be marked incomplete.</p> <h3>Description</h3> <p>The PHR Manager shall create/register one patient in the  proper affinity domain: SYSTEM_NAME^PHR_Extract. Use the RIS Mall to register this  patient and obtain a patient identifier.<br />   Create the appropriate document for the PHR_Extract  patient.<br />   For any of the coded values (allergies, medications, etc.)  use only coded values found in the MESA/Connectathon Code Tables document. That  document should list between 3 and 5 legal coded values. Do not invent codes or  import other codes. If you find that document lacking, inform the Connectathon  monitor about appropriate coded values for inclusion.</p> <ol>   <li>Create a readme.txt file that lists the Patient ID,  Patient Name, company name, your name, and your Kudu system name.</li>   <li>Create a screen capture of a rendering of the PHR  Extract document. We recognize that not all renderings will be the same.</li>   <li>Name the document PHR_Extract_kudu.xml where <strong><em>kudu</em></strong> is your Kudu system name.</li>   <li>Create a zip file named PHR_Extract_kudu.zip that  contains the three documents listed above.</li>   <li>Find the Connectathon Wiki page that references PHR  Extract documents. Upload your document according to the instructions on that  page. Update the Wiki page to list your document/zip file.</li>   <li>If you support XDS, complete  XDS_Doc_Source_Stores_Document or XDS_Embedded_Repository_Registers_Document  using the PHR Extract document. </li> </ol> <p>These items describe the minimum content that must be  present in the PHR Extract document. Additional content is acceptable, but the  document must contain the following information:</p> <p>&nbsp;</p> <table border="1" cellspacing="0" cellpadding="0">   <tr>     <td width="319" valign="top"><p>11450-4: PROBLEM LIST</p></td>     <td width="319" valign="top"><p>Ear infection, active, date 1-Oct-2006</p></td>   </tr>   <tr>     <td width="319" valign="top"><p>10160-0: HISTORY OF MEDICATION USE</p></td>     <td width="319" valign="top"><p>Amoxicillin (250 mg tabs) / 3 times per day / oral / 1-Oct-2006 &ndash; 10-Oct-2006</p></td>   </tr>   <tr>     <td width="319" valign="top"><p>10155-0: HISTORY OF ALLERGIES</p></td>     <td width="319" valign="top"><p>Allergen: Iodinated contrast<br />       Reaction: laryngeal oedema<br />       Comments: Reaction occurs within 10 minutes</p></td>   </tr>   <tr>     <td width="319" valign="top"><p>8716-3: VITAL SIGNS</p></td>     <td width="319" valign="top"><p>Height / 1778 / mm<br />       Weight / 82 / kg</p></td>   </tr> </table> <p>These sections are optional. If included, they should  contain the following information.</p> <table border="1" cellspacing="0" cellpadding="0">   <tr>     <td width="319" valign="top"><p>11369-6: HISTORY OF IMMUNIZATIONS</p></td>     <td width="319" valign="top"><p>Influenza / 8-Nov-2005</p></td>   </tr>   <tr>     <td width="319" valign="top"><p>11336-5: HISTORY OF HOSPITALIZATIONS+ HISTORY OF    OUTPATIENT VISITS</p></td>     <td width="319" valign="top"><p>Bicycle accident 14-Aug-2004. Head      CT was negative. Determined that subject was    allergic to iodinated contrast during the procedure.</p></td>   </tr>   <tr>     <td width="319" valign="top"><p>46264-8: HISTORY OF MEDICAL DEVICE USE</p></td>     <td width="319" valign="top"><p>None</p></td>   </tr>   <tr>     <td width="319" valign="top"><p>10157-6: HISTORY OF FAMILY MEMBER DISEASES</p></td>     <td width="319" valign="top"><p>Father died of lung cancer at age 55</p></td>   </tr> </table> <h3>Evaluation</h3> <p>This will be evaluated with the XPHR_Document_Scrutiny and  XPHR_Process_Extract tests.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (692, 1, 0, '2009-11-24 10:53:19.40', 'epoiseau', '<h3>Special Instructions</h3> <p>You need to complete this test by Day 2 at 12:00. We would prefer that you  complete by Day 1 at 17:00  if possible. If you complete after Day 2 at 12:00, you increase your risk that PHR Reviewers will  ignore your document, and you will be marked incomplete.</p> <h3>Description</h3> <p>Incomplete for Jan 2007 Connectathon. No registered  systems produce this document.</p> <h3>Evaluation</h3> <p>This will be evaluated with the XPHR_Document_Scrutiny and  XPHR_Process_Update tests.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (693, 1, 0, '2009-11-24 10:53:19.404', 'epoiseau', '<H3>Special Instructions</H3>  <p>Content Consumers please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) your peers have submitted. </p>  <H3>Description</H3> <p>There are four processing options defined for the Content  Consumer:</p> <ul> <li>View</li> <li>Document Import</li> <li>Section Import</li> <li>Discrete Data Import</li> </ul>  <p>In this test, the Content Consumer locates the XPHR Extract document produced by a single Content Creator. The Content Consumer demonstrates which of the 4 processing options are supported for the documment.<br>   When examining the processing of the document, the Connectathon Monitor should evaluate the document with at least these items in mind:</p> <ul> <li>Sections in the document are appropriate per the definitions in PCC TF</li> <li>A default style sheet is provided by the Content Creator. The Content Consumer is required to render the document with the  default style sheet. As an option, the Content Consumer can render with a  different style sheet.</li> </ul>  <H3>Evaluation</H3/> <p>In the evaluation, the Connectathon Monitor is looking for evidence that the Content Consumer can interpret the document produced by the Content Creator. That is a test of both actors. The Connetathon Monitor is then looking for evidence that the Consumer processes at least one of the options as specified in the XPHR Integration Profile.</p>  <p> The monitor shall check for these values in the document.  If the Content Consumer supports the view option, this data shall be rendered for display. Other options may not include processing each entry, so evaluation will require some judgment.</p>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (694, 1, 0, '2009-11-24 10:53:19.406', 'epoiseau', '<H3>Special Instructions</H3>  <p>Content Consumers please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) your peers have submitted. </p>  <H3>Description</H3> <p>There are four processing options defined for the Content  Consumer:</p> <ul> <li>View</li> <li>Document Import</li> <li>Section Import</li> <li>Discrete Data Import</li> </ul>  <p>In this test, the Content Consumer locates the XPHR Update document produced by a single Content Creator. The Content Consumer demonstrates which of the 4 processing options are supported for the documment.<br>   When examining the processing of the document, the Connectathon Monitor should evaluate the document with at least these items in mind:</p>  <ul> <li>Sections in the document are appropriate per the definitions in PCC TF</li> <li>A default style sheet is provided by the Content Creator. The Content Consumer is required to render the document with the  default style sheet. As an option, the Content Consumer can render with a  different style sheet.</li> </ul>  <H3>Evaluation</H3> <p>In the evaluation, the Connectathon Monitor is looking for evidence that the Content Consumer can interpret the document produced by the Content Creator. That is a test of both actors. The Connetathon Monitor is then looking for evidence that the Consumer processes at least one of the options as specified in the XPHR Integration Profile.</p>  <p>   The monitor shall check for these values in the document.  If the Content Consumer supports the view option, this data shall be rendered for display. Other options may not include processing each entry, so evaluation will require some judgment.</p>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (695, 1, 0, '2009-11-24 10:53:19.408', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> </p><H3>Description</H3><p>Each Content Creator has been assigned one well known patient (see test Content_Creator_Demographics) with a Patient ID in the proper domain. Create a document that uses the demographics for this patient and patient ID (if possible).</p><p>For any of the coded values (allergies, medications, etc.)  use only coded values found in the MESA/Connectathon Code Tables document. That  document should list between 3 and 5 legal coded values. Do not invent codes or  import other codes. If you find that document lacking, inform the Connectathon  monitor about appropriate coded values for inclusion.</p><ol> <li>These next steps refer to storing the document and reference information in the Kudu tool. You will find the page in the Kudu tool by selecting Connectathon and then Connectathon Images/CDs/Objects. The link to that page is <em><a href=system_con_object.php>Objects Information</a></em> </li> <li>Enter the Patient ID,  Patient Name, company name, your name, and your Kudu system name into the description of the <em>Connectathon Images/CDAs/Objects</em>.</li> <li>Create a screen capture of a rendering of the XPHR Extract. We recognize that not all renderings will be the same.</li> <li>Name the document XPHR_Extract_kudu.xml where <strong><em>kudu</em></strong> is your Kudu system name.</li> <li>Upload information, snapshot and xml files in the <em>Connectathon Images/CDAs/Objects</em> section of Kudu.</li> <li> Upload your 2 documents according to the instructions on that  page. Update the <em> Connectathon Images/CDAs/Objects Publication/rendering page</em> page to list your document/zip file.</li> <li>Find the Connectathon monitor or monitors responsible for Document Scrutiny. Make sure they are aware your document has been placed into the Kudu tool.</li> <li>If you support XDS, complete XDS test that requires you to store and register your document with a repository/registry. You do not need to complete that XDS store step in order to complete this test. In fact, once you have uploaded the proper documentation into Kudu, mark this test complete.</li> </ol><p>These items describe the minimum content that must be  present in the XPHR Extract document. Additional content is acceptable, but the  document must contain the following information:</p><p>The content of various modules is defined at http://ihewiki.wustl.edu/wiki/index.php/PCC_Connectathon_Content_Test_Requirements. Use the wiki page to find the right content and incorporate into your document.</p><p>As defined in the PCC TF, you must include the following content modules. Optional modules are allowed. <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td> Healthcare Providers</td><td> 1.3.6.1.4.1.19376.1.5.3.1.2.3</td></tr>  <tr><td> Allergies and Drug Sensitivies</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.13</td></tr>  <tr><td> Conditions</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.8</td></tr>  <tr><td> Conditions (cont)</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.6</td></tr>  <tr><td> Medications - Prescription and non-Prescription</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.19</td></tr>  </table> </p> <H3>Evaluation</H3> <p>This will be evaluated with the XPHR_Scrutinize_Extract and XPHR_Process_Extract tests.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (696, 1, 0, '2009-11-24 10:53:19.413', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> </p><H3>Description</H3><p>Each Content Creator has been assigned one well known patient (see test Content_Creator_Demographics) with a Patient ID in the proper domain. Create a document that uses the demographics for this patient and patient ID (if possible).</p><p>For any of the coded values (allergies, medications, etc.)  use only coded values found in the MESA/Connectathon Code Tables document. That  document should list between 3 and 5 legal coded values. Do not invent codes or  import other codes. If you find that document lacking, inform the Connectathon  monitor about appropriate coded values for inclusion.</p><ol> <li>These next steps refer to storing the document and reference information in the Kudu tool. You will find the page in the Kudu tool by selecting Connectathon and then Connectathon Images/CDs/Objects. The link to that page depends on the Connectathon. The link for IHE NA 2008 is <a href="http://ihe-kudu.wustl.edu/na2008/system_con_object.php?highligh=8_8"> Connectathon Images/CDAs/Objects</a> </li> <li>Enter the Patient ID,  Patient Name, company name, your name, and your Kudu system name into the description of the <em>Connectathon Images/CDAs/Objects</em>.</li> <li>Create a screen capture of a rendering of the XPHR Update. We recognize that not all renderings will be the same.</li> <li>Name the document XPHR_Update_kudu.xml where <strong><em>kudu</em></strong> is your Kudu system name.</li> <li>Upload information, snapshot and xml files in the <em>Connectathon Images/CDAs/Objects</em> section of Kudu.</li> <li> Upload your 2 documents according to the instructions on that  page. Update the  <em>Connectathon Images/CDAs/Objects </em>Publication/rendering page to list your document/zip file.</li> <li>Find the Connectathon monitor or monitors responsible for Document Scrutiny. Make sure they are aware your document has been placed into the Kudu tool.</li> <li>If you support XDS, complete XDS test that requires you to store and register your document with a repository/registry. You do not need to complete that XDS store step in order to complete this test. In fact, once you have uploaded the proper documentation into Kudu, mark this test complete.</li> </ol><p>The XPHR Update Document consists of modules taken from the Extract definition. However, the modules in the Update are optional, reflecting changes in the PHR. When you publish an update, choose at least one of the modules listed below. Additional content is acceptable</p><p>The content of various modules is defined at http://ihewiki.wustl.edu/wiki/index.php/PCC_Connectathon_Content_Test_Requirements. Use the wiki page to find the right content and incorporate into your document.</p> <table> <tr><th>Module</th><th>Template ID</th></tr> <tr><td>Languages Spoken</td><td> 1.3.6.1.4.1.19376.1.5.3.1.2.1</td></tr> <tr><td>Patient Contacts</td><td>1.3.6.1.4.1.19376.1.5.3.1.2.4</td></tr> <tr><td>Healthcare Providers</td><td> 1.3.6.1.4.1.19376.1.5.3.1.2.3</td></tr> <tr><td>Insurance Providers</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.7</td></tr> <tr><td>Pharmacy</td><td> 1.3.6.1.4.1.19376.1.5.3.1.2.3</td></tr> <tr><td>Legal Documents and Medical Directives</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.34</td></tr> <tr><td>Allergies and Drug Sensitivities</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.13</td></tr> <tr><td>Conditions</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.8</td></tr> <tr><td>Conditions (cont)</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.6</td></tr> <tr><td>Surgeries</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.12</td></tr> <tr><td>Medications - Prescription and Non-Prescription</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.19</td></tr> <tr><td>Immunizations</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.23</td></tr> <tr><td>Medical Devices</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.5</td></tr> </table> <H3>Evaluation</H3> <p>This will be evaluated with the XPHR_Scrutiny_Update and XPHR_Process_Update tests.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (697, 1, 0, '2009-11-24 10:53:19.416', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> <p>The monitor in charge of PCC documents will scrutinize your CDA content. He/she might not finish that work on Day 1. You need to publish the document and mark this test done to trigger the monitor to review your document.</p> <p> <em>You need to be able to produce legal content at the start of the event.</em> </p> </p> <H3>Description</H3> <p>One Connectathon Monitor will be assigned to scrutinize XPHR documents.      The purpose of this test is to have a single person with domain knowledge examine one      example of each document.      The Connectathon Monitor is looking for proper document structure, proper use of coded values      and content that was specified in the Publish test.</p> <p>The Content Creator should use the same documents produced and stored in the Kudu tool in the XPHR_Publish_Extract test.</p> <p>The Connectathon Monitor will take the files offline and perform evaluation.      The monitor will document any deficiencies and ask the Content Creator to correct      during the Connectathon.</p>  <H3>Evaluation</H3> <p>Monitors please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) the Content Creators have submitted. </p>  <p>The NIST Evaluation tools are found at <a href="http://xreg2.nist.gov/cda-validation/index.html">http://xreg2.nist.gov/cda-validation/index.html</a> .      For documents not supported by the NIST tool, use the schematron file found at IHESCHEMATRON.   </p><p>In the evaluation, the Connectathon Monitor will follow these steps:    <ol>      <li>Use CDA validation tool to make sure document is legal CDA document</li>      <li>Use Schematron test tool to see that document passes schematron tests for XPHR Extract</li>  <li>Examine XPHR Extract document by hand (possibly with style sheet) and examine for XPHR specific content         in these sections.         Values are found on the         <a href="http://ihewiki.wustl.edu/wiki/index.php/PCC_Connectathon_Content_Test_Requirements">Connectathon wiki: PCC Content Test Requirements</a>         The list of modules that are required and should be examined are:  <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td> Healthcare Providers</td><td> 1.3.6.1.4.1.19376.1.5.3.1.2.3</td></tr>  <tr><td> Allergies and Drug Sensitivies</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.13</td></tr>  <tr><td> Conditions</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.8</td></tr>  <tr><td> Conditions (cont)</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.6</td></tr>  <tr><td> Medications - Prescription and non-Prescription</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.19</td></tr>  </table>   </li> <li>NB: We are ignoring modules that are designated with optionality of O or R2.</li>     </ol> </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (698, 1, 0, '2009-11-24 10:53:19.418', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> <p>The monitor in charge of PCC documents will scrutinize your CDA content. He/she might not finish that work on Day 1. You need to publish the document and mark this test done to trigger the monitor to review your document.</p> <p> <em>You need to be able to produce legal content at the start of the event.</em> </p> </p> <H3>Description</H3> <p>One Connectathon Monitor will be assigned to scrutinize XPHR documents.      The purpose of this test is to have a single person with domain knowledge examine one      example of each document.      The Connectathon Monitor is looking for proper document structure, proper use of coded values      and content that was specified in the Publish test.</p> <p>The Content Creator should use the same documents produced and stored in the Kudu tool in the XPHR_Publish_Update test.</p> <p>The Connectathon Monitor will take the files offline and perform evaluation.      The monitor will document any deficiencies and ask the Content Creator to correct      during the Connectathon.</p>  <H3>Evaluation</H3> <p>Monitors please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) the Content Creators have submitted. </p>  <p>The NIST Evaluation tools are found at <a href="http://xreg2.nist.gov/cda-validation/index.html">http://xreg2.nist.gov/cda-validation/index.html</a> .      For documents not supported by the NIST tool, use the schematron file found at IHESCHEMATRON.   </p><p>In the evaluation, the Connectathon Monitor will follow these steps:    <ol>      <li>Use CDA validation tool to make sure document is legal CDA document</li>      <li>Use Schematron test tool to see that document passes schematron tests for XPHR Update</li>  <li>Examine XPHR Update document by hand (possibly with style sheet) and examine for XPHR specific content         in these sections.         Values are found on the         <a href="http://ihewiki.wustl.edu/wiki/index.php/PCC_Connectathon_Content_Test_Requirements">Connectathon wiki: PCC Content Test Requirements</a>         There are no required modules, so check to see if one module from the XPHR specification is included as an update.</li> <li>NB: We are ignoring modules that are designated with optionality of O or R2.</li>     </ol> </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (699, 1, 0, '2009-11-24 10:53:19.42', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p> </p><H3>Description</H3><p>Report Reader retrieves and renders one or more SR objects from External Report Repository.</p><H3>Evaluation</H3><p>Connectathon monitor will observe retrieve and rendering of SR(s). </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (700, 1, 0, '2009-11-24 10:53:19.422', 'epoiseau', '<H3>Special Instructions</H3><p>
 <p>This is not a real test; its purpose is to explain the structure of the connectathon tests you
    will perform for the XUA profile and to describe items to set up prior to starting testing. </p>
 </p>
 <H3>Description</H3>
 <p>Actors in the XUA profile can be grouped with actors in any profile with web services
    transactions (XDS.b, XDR, PDQv3, PIXv3, QED, RFD, XCA). Thus, you will be testing the exchange of XUA
    assertions in conjunction with transactions from another profile. This means you not only need to
    find your XUA test partners, you also have to find a partner which supports a web services
    transaction you support; a spreadsheet is created for each connectathon to help you with this. </p>
 <p>Here is the sequence of activities you must do to accomplish your XUA connectathon testing:</p>
 <ol>
    
 <li>Access the <a  href=http://ihewiki.wustl.edu/wiki/index.php/Europe_2009#Reference_Documents_for_Connectathon_week>''partners'' spreadsheet</a>.  On the XUA tab, find partners who support a web services
     profile that you also support. 
      </li>
    
 <li>The XUA profile allows X-Service User actors to get their assertions from an external
     assertion provider (the Tiani-Spirit system will provide this service at the connectathon), or generate
     their own. You need to talk to your test partners about how your system works in this regard.</li>
    
 <li>There are 3 ''flavors'' of XUA tests for each web-services-based profile:</li>
    
 <ul>
     
 <li>The ''success'' case (tests XUA_Doc_Source_ProvideandRegister, XUA_Stored_Query,
      XUA_Retrieve_Doc, XUA_RFD_Retrieve_Submit, XUA_PIXv3_Query, and XUA_PDQv3_Query). Your system
      can run any combination of 3 of these, eg one PIX test and 2 XDS tests. </li>
     
 <li>The ''fail'' case (XUA_*_Restrict_Access tests). Again, run any 3 of these.</li>
     
 <li>A test where the X-Service_Provider does not trust the Assertion Provider
      (XUA_*_Policy_Test). Each X-Service_Provider runs just <b>one</b> of these tests.</li>
     
    
 </ul>
    
 <li>XUA tests use TLS and include ATNA logging.</li>
    
 <li>Before any of these tests can be run, each X-Service Provider actor must run one instance of
     test <b>XUA_X-Service_Provider_Setup</b>. Do that now.</li>
 </ol>
 
 <p><strong>These notes apply to testing of the XUA  profile at the Connectathon:</strong></p>
 <ol>
   <li>The method that the X-Service  User uses to get the SAML Identity Assertion is not constrained by the  profile.'' Test cases for this profile cover  two methods:</li>
 </ol>
 <ul>
   <ul>
     <li><span dir="ltr"><u>Self-assertion</u> '' TheX-Service_User  does not rely on an external assertion provider; rather, it generates its own  valid SAML assertions</span></li>
     <li><span dir="ltr"><u>SAML Assertion Provider</u> '' The  X-Service_User will authenticate against an identity provide (XUA X-Assertion  Provider).'' <br />
       For Connectathon testing, we will provide an Security Token Service '' STS - (X-Assertion  Provider) from which X-Service_Users can (optionally) request assertions, and  against which X-Service_Providers can validate assertions received from  Document Consumers.  This is provided by the IBM and Tiani-Spirit STS systems.<br />
     </span></li>
   </ul>
 </ul>
 <ol>
   <li value="2"><span dir="ltr">XUA X-Service Providers need to be able to ''trust'' assertions provided  by a mix of X-Service_Users who either</span>
     <ul>
       <li><span dir="ltr">do self-assertion</span></li>
       <li><span dir="ltr">or, send an assertion which  originated at an external STS (X-Assertion Provider.  This is the more common case.</span></li>
     </ul>
   </li>
 
   <li><span dir="ltr">X-Service Providers need to be able to be configured to ''not trust''  assertions from a selected assertion provider.'' </span></li>
   <li><span dir="ltr">(This test has been deferred for this year):'' X-Service Providers need to be able to be  configured to ''not trust'' assertions containing certain parameters.'' For example, for the Connectathon, we will  define a ''policy'' that assertions containing an authentication method of  ''InternetProtocol'' in its AuthnStatment should fail validation.'' </span></li>
   <li><span dir="ltr">The XUA Profile constrains only a subset of the possible parameters  that can be included in a SAML assertion.''  The proper use of these specific parameters are tested; it is valid to  include other parameters in the assertion, but these are not tested.'' Other parameters will not affect the validity  of the assertion.'' The XUA X-Service  Provider must accept all valid SAML assertions and process attributes profiled  in ITI-40.</span></li>
   <li><span dir="ltr">In these tests XDS.b Document Registry and Document Repository actors  which are also XUA X-Service Providers do not need to support a scenario where  some Document Consumers ''in the Affinity  Domain support XUA, and some do not.'' This  will not be a required test in the connectathon, although vendors are welcome  to test this scenario for ''extra credit''.</span></li>
   <li><span dir="ltr">All transactions, including those with the X-Assertion Provider, will  be done using TLS.</span></li>
   <li><span dir="ltr">Auditing will be tested:</span>
     <ul>
       <li><span dir="ltr">The XUA profile requires that the  X-Service Provider generate an ATNA audit event for ''Authentication Failure''  whenever its validation of the assertion fails.''  Eg. The Document Consumer must send an audit message when it initiates a  Registry Stored Query.'' These audit events  are tested in these tests. </span></li>
       <li><span dir="ltr">The XUA profile requires that </span>"Any ATNA Audit  Messages recorded by Actor grouped with the X-Service Provider Actor, shall  have the user identity recorded according to the XUA specific ATNA encoding  rules" (See 3.40.4.2 ATNA Audit encoding). For example: when the XDS.b Document  Consumer Actor records the Stored Query event, this event record will include  the identity provided in the XUA Identity Assertion. This assures that the  X-Service User and X-Service Provider ATNA Audit messages can be correlated at  the ATNA Audit Repository." This will be tested in the XUA tests. </li>
     </ul>
   </li>
   <li><span dir="ltr">Authorization is out-of-scope for XUA, ie there are no tests that allow  or restrict a user''s access to a document based on who a user (prinicpal) is,  nor are there tests that allow a user to see a subset of a patient''s document  based on the contents of the assertion.''  Either the validation succeeds at the X-Service Provider, and all of a  patient''s record is returned to the X-Service User, or validation fails, and  the X-Service User receives nothing.</span></li>
 </ol>
 
 <b>Configuration Items: </b><br />
 <ol><li><span dir="ltr">For X-Service Users who will request assertions from the Connectathon (IBM or Tiani)  STS, three configuration items have been identified.'' The X-Service User needs to provide the  X-Assertion Provider with:<br />
 (a). </span><span dir="ltr">A user name<br />
 (b). </span><span dir="ltr">A valid password<br />
   (c). </span><span dir="ltr">The ''<b>AudienceRestriction</b>'' of the X-Service Provider<br />
     </span>
       </li>
 </ol>
 <blockquote>
   <p><span dir="ltr">For item (c.) at the Connectathon, to ease configuration, we will apply the  same URL to all X-Service Providers, ie all Registries and Repositories.'' (Note that this URL is **not** the URL the  Document Consumer will use to query the Registry or retrieve documents from the  Repository).'''' This same, general URL  used as the value of ''<strong>AudienceRestriction</strong>''  for all service providers will simplify the STS configuration and will ensure  that users can'' access any  Registry/Repository with the SAML token obtained from the STS.<br />
     <br />
     The required URL is :<br />
     <br />
   ''  '' <b><i>http://ihe.connecthaton.XUA/X-ServiceProvider-IHE-Connectathon</b></i>
 
 <ol start="2">
   <li>The  XUA profile requires that all assertions contain a <strong>Subject (principal</strong>).'' The  following table identifies pre-defined prinicipals we will use in XUA  Connectathon testing .'' (The  ''Subject'''' in the assertion could be a  user; could be an ''application''.)'' <br />
     <br />
     These principals are defined to have different combinations of assertions for  the <em>XUA "success" </em> tests   and <em>XUA_*Restrict_Access_*</em> tests, as  follows.''<br />
   <br />
   </li>
   <li><span dir="ltr">ITI-40 profiles the SAML 2.0 Assertion in ITI TF-2:3.40.4.1.2.'''''' The green column headings in the table  below represent the parameters profiled for the assertion.'' Each row in the table represents the  requirements for the contents of one assertion that will belong to a unique  Subject.'' Yellow cells identify  parameters in the assertion intended to cause the test to ''fail''.'''' We assume that ''external'' X-Assertion  Providers provided for use at the connectathon will be able to generate  assertions with the failure conditions contained in the following tables.'' We expect that X-Service Users that are  generating their own assertions will have less flexibility. </span></li>
 </ol>
 <table border="1" cellspacing="0" cellpadding="0">
   <tr>
     <td width="117" valign="top"><p><strong>''</strong></p></td>
     <td width="226" valign="top"><p><strong>''</strong></p></td>
     <td width="281" colspan="4" valign="top"><p align="center"><strong>Conditions</strong></p></td>
     <td width="146" valign="top"><p><strong>''</strong></p></td>
     <td width="80" valign="top"><p><strong>''</strong></p></td>
     <td width="136" valign="top"><p>''</p></td>
     <td width="63" valign="top"><p><strong>''</strong></p></td>
   </tr>
   <tr>
     <td width="117" valign="top" bgcolor="#99FFFF"><p><strong>Username / password</strong></p>
         <p><strong>Will be included in:</strong><br />
             <strong>Subject <br />
     (ie principal) </strong></p></td>
     <td width="226" valign="top" bgcolor="#99FFFF"><p><strong>Subject/SubjectConfirmation</strong></p></td>
     <td width="281" valign="top" bgcolor="#99FFFF"><p><strong>Not Before</strong></p></td>
     <td width="78" valign="top" bgcolor="#99FFFF"><p><strong>NotOnOrAfter</strong></p></td>
     <td width="121" valign="top" bgcolor="#99FFFF"><p><strong>Audience</strong><br />
             <strong>Restriction</strong></p></td>
     <td width="16" valign="top" bgcolor="#99FFFF"><p><strong>''</strong></p></td>
     <td width="146" valign="top" bgcolor="#99FFFF"><p><strong>Authn</strong><br />
             <strong>Statement -></strong><br />
             <strong>AuthnContext</strong><br />
             <strong>Class Ref</strong><br />
       Or<br />
       <strong>AuthContext</strong><br />
     <strong>DeclRef</strong></p></td>
     <td width="80" valign="top" bgcolor="#99FFFF"><p><strong>Other Characteristic</strong></p></td>
     <td width="136" valign="top" bgcolor="#99FFFF"><p><strong>Used in Test</strong></p></td>
     <td width="63" valign="top" bgcolor="#99FFFF"><p><strong>Expected Result</strong></p></td>
   </tr>
   <tr>
     <td width="117" valign="top"><p class="style1">Xuagood^User /<br />
       ''xua</p></td>
     <td width="226" valign="top"><p>Method="urn:oasis:names:<br />
       tc:SAML:2.0:cm:bearer"</p></td>
     <td width="281" valign="top"><p>Issue'' instant <br />
       of the assertion</p></td>
     <td width="78" valign="top"><p>Unexpired date</p></td>
     <td width="121" valign="top"><p>URI of <br />
       X-Service_Provider</p></td>
     <td width="16" valign="top"><p>''</p></td>
     <td width="146" valign="top"><p>See Note A.</p></td>
     <td width="80" valign="top"><p>n/a</p></td>
     <td width="136" valign="top"><p>variety of XUA "success" tests </p></td>
     <td width="63" valign="top"><p>Return results</p></td>
   </tr>
   <tr>
     <td width="117" valign="top"><p class="style1"><em>Xuabaduri^User / xua</em></p></td>
     <td width="226" valign="top"><p>Method="urn:oasis:names:<br />
       tc:SAML:2.0:cm:bearer"</p></td>
     <td width="281" valign="top"><p>Issue'' instant <br />
       of the assertion</p></td>
     <td width="78" valign="top"><p>Unexpired date</p></td>
     <td width="121" valign="top" bgcolor="#FFFF00"><p>URI of ''unknown'' <br />
     X-Service_Provider</p></td>
     <td width="16" valign="top"><p>''</p></td>
     <td width="146" valign="top"><p>See Note A.</p></td>
     <td width="80" valign="top"><p>n/a</p></td>
     <td width="136" valign="top"><p>XUA_*Restrict_<br />
       Access</p></td>
     <td width="63" valign="top"><p>Deny access</p></td>
   </tr>
   <tr>
     <td width="117" valign="top"><p class="style1"><em>Xuanotyetvalid / xua</em></p></td>
     <td width="226" valign="top"><p>Method="urn:oasis:names:<br />
       tc:SAML:2.0:cm:bearer"</p></td>
     <td width="281" valign="top"><p>Issue'' instant <br />
       of the assertion</p></td>
     <td width="78" valign="top" bgcolor="#FFFF00"><p>Vaue indicating that the    assertion is not yet valid</p></td>
     <td width="121" valign="top"><p>URI of <br />
       X-Service_Provider</p></td>
     <td width="16" valign="top"><p>''</p></td>
     <td width="146" valign="top"><p>See Note A.</p></td>
     <td width="80" valign="top"><p>n/a</p></td>
     <td width="136" valign="top"><p>XUA_*Restrict_<br />
       Access</p></td>
     <td width="63" valign="top"><p>Deny access</p></td>
   </tr>
   <tr>
     <td width="117" valign="top"><p class="style1"><em>Xuaexpired^User / xua</em></p></td>
     <td width="226" valign="top"><p>Method="urn:oasis:names:<br />
       tc:SAML:2.0:cm:bearer"</p></td>
     <td width="281" valign="top"><p>Issue'' instant <br />
       of the assertion</p></td>
     <td width="78" valign="top" bgcolor="#FFFF00"><p>Value indicating expired    assertion</p></td>
     <td width="121" valign="top"><p>URI of <br />
       X-Service_Provider</p></td>
     <td width="16" valign="top"><p>''</p></td>
     <td width="146" valign="top"><p>See Note A.</p></td>
     <td width="80" valign="top"><p>n/a</p></td>
     <td width="136" valign="top"><p>XUA_*Restrict_<br />
       Access</p></td>
     <td width="63" valign="top"><p>Deny access</p></td>
   </tr>
   <tr>
     <td width="117" valign="top"><p class="style1"><em>Xuaunsined^user / xua</em></p></td>
     <td width="226" valign="top"><p>Method="urn:oasis:names:<br />
       tc:SAML:2.0:cm:bearer"</p></td>
     <td width="281" valign="top"><p>Issue'' instant <br />
       of the assertion</p></td>
     <td width="78" valign="top"><p>Unexpired date</p></td>
     <td width="121" valign="top"><p>URI of <br />
       X-Service_Provider</p></td>
     <td width="16" valign="top"><p>''</p></td>
     <td width="146" valign="top"><p>See Note A.</p></td>
     <td width="80" valign="top" bgcolor="#FFFF00"><p>Unsigned assertion</p></td>
     <td width="136" valign="top"><p>XUA_*Restrict_<br />
       Access</p></td>
     <td width="63" valign="top"><p>Deny access</p></td>
   </tr>
   <tr>
     <td width="117" valign="top"><p class="style1">N/A this year</p></td>
     <td width="226" valign="top"><p>Method="urn:oasis:names:<br />
       tc:SAML:2.0:cm:bearer"</p></td>
     <td width="281" valign="top"><p>Issue'' instant <br />
       of the assertion</p></td>
     <td width="78" valign="top"><p>Unexpired date</p></td>
     <td width="121" valign="top"><p>URI of <br />
       X-Service_Provider</p></td>
     <td width="16" valign="top"><p>''</p></td>
     <td width="146" valign="top" bgcolor="#FFFF00"><p class="style1">Invalid    AuthenStatement parameters</p></td>
     <td width="80" valign="top"><p>n/a</p></td>
     <td width="136" valign="top"><p>XUA_*Restrict_<br />
       Access</p></td>
     <td width="63" valign="top"><p>Test deferred for this year </p></td>
   </tr>
   <tr>
     <td width="117" valign="top"><p class="style1">N/A this year</p></td>
     <td width="226" valign="top"><p>Method="urn:oasis:names:<br />
       tc:SAML:2.0:cm:bearer"</p></td>
     <td width="281" valign="top"><p>Issue'' instant <br />
       of the assertion</p></td>
     <td width="78" valign="top"><p>Unexpired date</p></td>
     <td width="121" valign="top"><p>URI of <br />
       X-Service_Provider</p></td>
     <td width="16" valign="top"><p>''</p></td>
     <td width="146" valign="top" bgcolor="#FFFF00"><p class="style1">AuthnConextClassRef    is ''InternetProtocol'' which ''policy'' says is an unacceptable authentication    method</p></td>
     <td width="80" valign="top"><p>n/a</p></td>
     <td width="136" valign="top"><p>XUA_*Policy_Test</p></td>
     <td width="63" valign="top"><p>Test deferred for this year </p></td>
   </tr>
   <tr>
     <td valign="top"><p class="style1">N/A this year </p></td>
     <td valign="top"><p>Method="urn:oasis:names:<br />
       tc:SAML:2.0:cm:bearer"</p></td>
     <td valign="top"><p>Issue'' instant <br />
       of the assertion</p></td>
     <td valign="top"><p>Unexpired date</p></td>
     <td valign="top"><p>URI of <br />
       X-Service_Provider</p></td>
     <td valign="top"><p>''</p></td>
     <td valign="top"><p>See Note A.</p></td>
     <td valign="top" bgcolor="#FFFF00"><p>Contains other assertions    not profiled in XUA</p></td>
     <td valign="top"><p>XUA_Stored_Query<br />
       XUA_Retrieve_Doc</p></td>
     <td valign="top"><p>Return results / <br />
       Test deferred for this year </p></td>
   </tr>
 </table>
 <p>Note  A.'' Many options are possible for the  AuthnStatement parameter.'' For the Connectathon,  the assertions provided to the X-Service Users by the X-Assertion Providers  will encode a timestamp representing when the authentication occurred and that  the password class was used, eg:<br />
     <br />
   ''<br />
   <saml:AuthnStatement  AuthnInstant="2007-10-08T14:49:14Z"> <br />
   '' '' ''  '' <saml:AuthnContext> <br />
   '' '' ''  '' '' '' '' ''  <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef> <br />
   '' '' ''  '' </saml:AuthnContext> <br />
   </saml:AuthnStatement> </p>
 
 <H3>Evaluation</H3>
 <p>There is no evaluation for this informational ''test''. </p>
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (701, 1, 0, '2009-11-24 10:53:19.427', 'epoiseau', '<H3>Special Instructions</H3><p> <p>XDR Document Recipient and XDS Repository actors must complete test <b>     XUA_X-Service_Provider_Setup</b> before running this test.</p> </p><H3>Description</H3><p>This tests XUA with XDS or XDR when a Document Source actor submits a document with ITI-41 to    either an XDR Doc Recipient or XDS Doc Repository actor.</p><p>In this test, an XDR Document Recipient or XDS Doc Repository (X-Service Provider) verifies a    principal&rsquo;s assertions before accepting a    document submitted by a Document Source (X-Service User) .&nbsp; &nbsp;The Document    Recipient may optionally use an external X-Assertion Provider to validate the contents of the    assertion.</p><p>This test assumes the Document Source gets the assertion when the user logs in to the system    and then uses that one for the session (or until the assertion expires).</p><p>This tests the &lsquo;success&rsquo; case.&nbsp;&nbsp; Denial of access based    on assertions is tested in a different test -    <strong>XUA_Document_Recipient_Restrict_Access</strong>.</p><H3>Evaluation</H3><p>The <strong>X-Service User (Document Source);</strong> </p><ul>     <li>Will demonstrate that it was able to successfully submit the document.</li>     <li>Will demonstrate that it audited the document export event.&nbsp; This may need to be     checked on the Audit Record Repository.&nbsp; The audit event record will include the     identity provided in the XUA Identity Assertion. &nbsp;The ATNA Audit message      <strong>EventID</strong> element is "Export" and the <strong>UserName </strong>element shall     record the X-User Assertion using the following encoding: </li>     <ul>      <li>alias"&lt;"user"@"issuer"&gt;"      &nbsp;&nbsp;where: </li>      <li> <strong>alias </strong>is the optional string within the SAML Assertion''s Subject element      SPProvidedID attribute </li>      <li> <strong>user </strong>is the required content of the SAML Assertion''s Subject element </li>      <li> <strong>issuer </strong>is the X-Assertion Provider entity ID contained with the content of      SAML Assertion''s Issuer element </li>     </ul> </ul><p>The <strong>X-Service Provider (Doc Recipient or Repository):</strong> </p><ul>     <li>Will demonstrate for the Connectathon Monitor, through log files or other means, that the     SAML assertion was received from the Document Source and that its contents were verified prior     to accepting the document from the Document Source system.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (702, 1, 0, '2009-11-24 10:53:19.429', 'epoiseau', '<H3>Special Instructions</H3><p> <p>PDQv3 Suppliers must complete test <b> XUA_X-Service_Provider_Setup</b> before running this    test.</p> </p><H3>Description</H3><p>In this test, a PDQv3 Supplier (X-Service Provider) verifies a principal&rsquo;s assertions    before responding to a PDQ Query from a PDQv3 Consumer (X-Service User) .&nbsp; &nbsp;The    PDQ Supplier may optionally use an external X-Assertion Provider to validate the contents of the    assertion.</p><p>This test assumes the PDQ Consumer gets the assertion when the user logs in to the system and    then uses that one for the session (or until the assertion expires).</p><p>This tests the &lsquo;success&rsquo; case.&nbsp;&nbsp; Denial of access based    on assertions is tested in a different test -   <strong>XUA_PDQ_Supplier_Restrict_Access</strong>.</p><H3>Evaluation</H3><p>The <strong>X-Service User (PDQ Consumer);</strong> </p><ul>     <li>Will demonstrate that it received a response from the PDQ Supplier &ndash; matches for     patient XUA, Xavier, in response to the queries.</li>     <li>Will demonstrate that it audited the query event.&nbsp; This may need to be checked on     the Audit Record Repository.&nbsp; The audit event record will include the identity provided     in the XUA Identity Assertion. &nbsp;the ATNA Audit message <strong>EventID</strong> element     is "Query" and the <strong>UserName </strong>element shall record the X-User Assertion using the     following encoding: </li>     <ul>      <li>alias"&lt;"user"@"issuer"&gt;"      &nbsp;&nbsp;where: </li>      <li> <strong>alias </strong>is the optional string within the SAML Assertion''s Subject element      SPProvidedID attribute </li>      <li> <strong>user </strong>is the required content of the SAML Assertion''s Subject element </li>      <li> <strong>issuer </strong>is the X-Assertion Provider entity ID contained with the content of      SAML Assertion''s Issuer element </li>     </ul> </ul><p>The <strong>X-Service Provider (PDQ Supplier):</strong> </p><ul>     <li>Will demonstrate for the Connectathon Monitor, through log files or other means, that the     SAML assertion was received from the PDQ Consumer Consumer and that its contents were verified     prior to responding to the PDQ Query request.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (703, 1, 0, '2009-11-24 10:53:19.431', 'epoiseau', '<H3>Special Instructions</H3><p> <p>PDQv3 Suppliers (X-Service Providers) run one instance of this test.</p> <p>Before the test:</p> <ul>     <li>The X-Service Provider (PDQ Supplier) must configure its system to not trust the assertion     provider (this is either the external X-Assertion Provider used by the PDQ Consumer, or the PDQ     Consumer itself if it is generating its own SAML assertions). The PDQ Supplier will receive the     assertion via the PDQ Consumer when the Consumer sends its query.</li>     <li>(this part of the test is deferred for XUA testing this year): The X-Service Provider (PDQ     Supplier) must configure its system to reject assertions received where the authentication     method used is ''InternetProtocol''. , eg it contains: </li> </ul> <p>     <i><saml:AuthnStatement AuthnInstant="2007-10-08T14:49:14Z">     '' '' '' '' <saml:AuthnContext> ''     '' '' '' '' '' '' ''     <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol</saml:AuthnContextClassRef>     '' '' '' '' </saml:AuthnContext>     </saml:AuthnStatement> </i> </p> </p><H3>Description</H3><p>This tests the X-Service Provider''s (PDQ Supplier''s) ability to deny access    in two cases:</p><ul>     <li>Valid assertion received from an assertion provider not trusted by the PDQ Supplier</li>     <li>(this part of the test is deferred for XUA testing this year) The ''Connectathon     Policy'' states that ''InternetProtocol'' is an invalid     authentication method in our instituion.'' A SAML assertion is received, and the     authentication method -- ''InternetProtocol'' '' is included in the     AuthnStatement of the assertion</li> </ul><H3>Evaluation</H3><p>The Connectathon Monitor may ask you to run these steps real-time. Verify that the PDQ Consumer    did not receive a query response because validation of the assertion failed. The PDQ Consumer has    no indication that the transaction failed because of the validation failure.</p> <p>If possible, verify that the X-Service-Provide (PDQ Supplier) send an Authentication Failure    ATNA audit message to the Audit Record Repository.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (704, 1, 0, '2009-11-24 10:53:19.433', 'epoiseau', '<H3>Special Instructions</H3><p> <p>PDQ Supplier actors should run test <strong>XUA_PDQv3_Query</strong> before running this test,    to ensure the &lsquo;success&rsquo; case works first.</p> </p><H3>Description</H3><p>This test verifies that a X-Service Provider (PDQ_Supplier) will not respond to query requests    from a X-Service User (PDQ Consumer) when the assertions indicate that PDQ Supplier should not    grant access.</p><H3>Evaluation</H3><p>Verify that the PDQ Consumer was unsuccessful receiving responses to its queries because    validation of the assertion failed.&nbsp; The PDQ Consumer has no indication that the query    failed because of the validation failure.</p><p>On the <strong>Audit Record Repository</strong>, verify: </p><ul>     <li>An Authentication Failure event was logged by the PDQ Supplier for each assertion validation     failure. </li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (705, 1, 0, '2009-11-24 10:53:19.435', 'epoiseau', '<H3>Special Instructions</H3><p> <p>PIXv3 Managers (X-Service Providers) run one instance of this test.</p> <p>Before the test:</p> <ul>     <li>The X-Service Provider (PIX Manager) must configure its system to not trust the assertion     provider (this is either the external X-Assertion Provider used by the PIX Consumer, or the PIX     Consumer itself if it is generating its own SAML assertions). The PIX Manager will receive the     assertion via the PIX Consumer when the Consumer sends its query.</li>     <li>(this part of the test is deferred for XUA testing this year): The X-Service Provider (PIX     Manager) must configure its system to reject assertions received where the authentication method     used is &ldquo;InternetProtocol&rdquo;. , eg it contains: </li> </ul> <p>     <i>&lt;saml:AuthnStatement AuthnInstant="2007-10-08T14:49:14Z"&gt;     &nbsp; &nbsp; &nbsp; &nbsp; &lt;saml:AuthnContext&gt; &nbsp;     &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;     &lt;saml:AuthnContextClassRef&gt;urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol&lt;/saml:AuthnContextClassRef&gt;     &nbsp; &nbsp; &nbsp; &nbsp; &lt;/saml:AuthnContext&gt;     &lt;/saml:AuthnStatement&gt; </i> </p> </p><H3>Description</H3><p>This tests the X-Service Provider&rsquo;s (PIX Manager&rsquo;s) ability to deny access    in two cases:</p><ul>     <li>Valid assertion received from an assertion provider not trusted by the PIX Manager</li>     <li>(this part of the test is deferred for XUA testing this year) The &ldquo;Connectathon     Policy&rdquo; states that &ldquo;InternetProtocol&rdquo; is an invalid     authentication method in our instituion.&nbsp; A SAML assertion is received, and the     authentication method -- &ldquo;InternetProtocol&rdquo; &ndash; is included in the     AuthnStatement of the assertion</li> </ul><H3>Evaluation</H3><p>The Connectathon Monitor may ask you to run these steps real-time. Verify that the PIX Consumer    did not receive a query response because validation of the assertion failed. The PIX Consumer has    no indication that the transaction failed because of the validation failure.</p><p>If possible, verify that the X-Service-Provide (PIX Manager) send an Authentication Failure    ATNA audit message to the Audit Record Repository.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (706, 1, 0, '2009-11-24 10:53:19.437', 'epoiseau', '<H3>Special Instructions</H3><p> <p>PIXv3  Manager actors should run test <strong>XUA_PIXv3_Query</strong> before running this test, to ensure the    &lsquo;success&rsquo; case works first.</p> </p><H3>Description</H3><p>This test verifies that a X-Service Provider (PIXv3 Manager) will not respond to a query from a X-Service User (PIX Consumer) when the assertions indicate that    PIX Mgr should not grant access.</p><H3>Evaluation</H3><p>Verify that the PIX Consumer was unsuccessful receiving responses to its queries because    validation of the assertion failed.&nbsp; The PIX Consumer has no indication that the    query failed because of the validation failure.</p><p>On the <strong>Audit Record Repository</strong>, verify: </p><ul>     <li>An Authentication Failure event was logged by the PIX Manager for each assertion     validation failure. </li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (707, 1, 0, '2009-11-24 10:53:19.439', 'epoiseau', '<H3>Special Instructions</H3><p> <p>PIXv3 Managers must complete test <b> XUA_X-Service_Provider_Setup</b> before running this    test.</p> </p><H3>Description</H3><p>In this test, a PIXv3 Manager (X-Service Provider) verifies a principal&rsquo;s assertions     before responding to a PIX Query from a PIXv3 Consumer    (X-Service User) .&nbsp; &nbsp;The PIX Manager may optionally use an external X-Assertion    Provider to validate the contents of the assertion.</p><p>This test assumes the PIX Consumer gets the assertion when the user logs in to the system and    then uses that one for the session (or until the assertion expires).</p><p>This tests the &lsquo;success&rsquo; case.&nbsp;&nbsp; Denial of access based    on assertions is tested in a different test - <strong>XUA_PIX_Mgr_Restrict_Access</strong>.</p><H3>Evaluation</H3><p>The <strong>X-Service User (PIX Consumer);</strong> </p><ul>     <li>Will demonstrate that it received a response from the PIX Manager &ndash; matches for the     Patient ID in the query.</li>     <li>Will demonstrate that it audited the query event.&nbsp; This may need to be checked on     the Audit Record Repository.&nbsp; The audit event record will include the identity provided     in the XUA Identity Assertion. &nbsp;the ATNA Audit message <strong>EventID</strong> element     is "Query" and the <strong>UserName </strong>element shall record the X-User Assertion using the     following encoding: </li>     <ul>      <li>alias"&lt;"user"@"issuer"&gt;"      &nbsp;&nbsp;where: </li>      <li> <strong>alias </strong>is the optional string within the SAML Assertion''s Subject element      SPProvidedID attribute </li>      <li> <strong>user </strong>is the required content of the SAML Assertion''s Subject element </li>      <li> <strong>issuer </strong>is the X-Assertion Provider entity ID contained with the content of      SAML Assertion''s Issuer element </li>     </ul> </ul><p>The <strong>X-Service Provider (PIX Manager):</strong> </p><ul>     <li>Will demonstrate for the Connectathon Monitor, through log files or other means, that the     SAML assertion was received from the PIX Consumer and that its contents were verified prior to     responding to the PIX Query request.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (708, 1, 0, '2009-11-24 10:53:19.441', 'epoiseau', '<H3>Special Instructions</H3><p> <p>QED Clinical Data Source actors must complete test <b> XUA_X-Service_Provider_Setup</b> before running this    test.</p> </p> <H3>Description</H3> <p>In this test, a QED Clinical Data Source (X-Service Provider) verifies a principal''s assertions    before responding to a query from a QED Clinical Data Consumer (X-Service User) .   The   QED Clinical Data Source may optionally use an external X-Assertion Provider to validate the contents of the    assertion.</p> <p>This test assumes the QED Clinical Data Consumer gets the assertion when the user logs in to the system and    then uses that one for the session (or until the assertion expires).</p> <p>This tests the ''success'' case.   Denial of access based    on assertions is tested in a different test -   <strong>XUA_QED_Source_Restrict_Access</strong>.</p> <H3>Evaluation</H3> <p>The <strong>X-Service User (QED Clinical Data Consumer);</strong> </p> <ul>     <li>Will demonstrate that it received a response from the QED Source '' matches for     patient XUA, Xavier, in response to the queries.</li>     <li>Will demonstrate that it audited the query event.  This may need to be checked on     the Audit Record Repository.  The audit event record will include the identity provided     in the XUA Identity Assertion.  the ATNA Audit message <strong>EventID</strong> element     is "Query" and the <strong>UserName </strong>element shall record the X-User Assertion using the     following encoding: </li>     <ul>      <li>alias"<"user"@"issuer">"        where: </li>      <li> <strong>alias </strong>is the optional string within the SAML Assertion''s Subject element      SPProvidedID attribute </li>      <li> <strong>user </strong>is the required content of the SAML Assertion''s Subject element </li>      <li> <strong>issuer </strong>is the X-Assertion Provider entity ID contained with the content of      SAML Assertion''s Issuer element </li>     </ul> </ul><p>The <strong>X-Service Provider (QED Clinical Data Source):</strong> </p><ul>     <li>Will demonstrate for the Connectathon Monitor, through log files or other means, that the     SAML assertion was received from the QED Consumer and that its contents were verified     prior to responding to the QED query.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (709, 1, 0, '2009-11-24 10:53:19.443', 'epoiseau', '<H3>Special Instructions</H3> <p> <p>QED Clinical Data Source actors should run test <strong>XUA_QED_Query</strong> before running this test,    to ensure the ''success'' case works first.</p> </p> <H3>Description</H3> <p>This test verifies that a X-Service Provider (QED Clinical Data Source) will not respond to query requests from a X-Service User (QED Clinical Data Consumer) when the assertions indicate that QED Source should not grant access.</p> <H3>Evaluation</H3> <p>Verify that the PDQ Consumer was unsuccessful receiving responses to its queries because    validation of the assertion failed.  The PDQ Consumer has no indication that the query    failed because of the validation failure.</p> <p>On the <strong>Audit Record Repository</strong>, verify: </p> <ul>     <li>An Authentication Failure event was logged by the QED Source for each assertion validation     failure. </li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (710, 1, 0, '2009-11-24 10:53:19.447', 'epoiseau', '<H3>Special Instructions</H3><p> <p>QED Clinical Data Source (X-Service Providers) run one instance of this test.</p> <p>Before the test:</p> <ul>     <li>The X-Service Provider (QED Source) must configure its system to not trust the assertion     provider (this is either the external X-Assertion Provider used by the QED Consumer, or the QED     Consumer itself if it is generating its own SAML assertions). The QED Clinical Data Source will receive the assertion via the QED Consumer when the Consumer sends its query.</li>     <li>(this part of the test is deferred for XUA testing this year): The X-Service Provider (QED Source) must configure its system to reject assertions received where the authentication     method used is ''InternetProtocol''. , eg it contains: </li> </ul> <p>     <i><saml:AuthnStatement AuthnInstant="2007-10-08T14:49:14Z">             <saml:AuthnContext>                         <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol</saml:AuthnContextClassRef>             </saml:AuthnContext>     </saml:AuthnStatement> </i> </p> </p> <H3>Description</H3> <p>This tests the X-Service Provider''s (QED Source''s) ability to deny access    in two cases:</p><ul>     <li>Valid assertion received from an assertion provider not trusted by the Clinical Data Source</li>     <li>(this part of the test is deferred for XUA testing this year) The ''Connectathon     Policy'' states that ''InternetProtocol'' is an invalid     authentication method in our institution.  A SAML assertion is received, and the     authentication method -- ''InternetProtocol'' '' is included in the     AuthnStatement of the assertion</li> </ul> <H3>Evaluation</H3> <p>The Connectathon Monitor may ask you to run these steps real-time. Verify that the QED Consumer did not receive a query response because validation of the assertion failed. The QED Consumer has no indication that the transaction failed because of the validation failure.</p> <p>An Authentication Failure event was logged by the Clinical Data Source for each assertion     validation failure.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (711, 1, 0, '2009-11-24 10:53:19.449', 'epoiseau', '<H3>Special Instructions</H3><p> <p>RFD Form Managers (X-Service Providers) run one instance of this test.</p> <p>Before the test:</p> <ul>     <li>The X-Service Provider (Form Manager) must configure its system to not trust the assertion     provider (this is either the external X-Assertion Provider used by the Form Filler, or the Form     Filler itself if it is generating its own SAML assertions). The Form Manager will receive the     assertion via the Form Filler when the Form Filler makes its Retrieve Form request.</li>     <li>(this part of the test is deferred for XUA testing this year): The X-Service Provider (Form     Manager) must configure its system to reject assertions received where the authentication method     used is ''InternetProtocol''. , eg it contains: </li> </ul> <p>     <i><saml:AuthnStatement AuthnInstant="2007-10-08T14:49:14Z">     '' '' '' '' <saml:AuthnContext> ''     '' '' '' '' '' '' ''     <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol</saml:AuthnContextClassRef>     '' '' '' '' </saml:AuthnContext>     </saml:AuthnStatement> </i> </p> </p><H3>Description</H3><p>This tests the X-Service Provider''s (Form Managers''s) ability to deny    access in two cases:</p><ul>     <li>Valid assertion received from an assertion provider not trusted by the Form Mgr</li>     <li>(this part of the test is deferred for XUA testing in year 1) The ''Connectathon     Policy'' states that ''InternetProtocol'' is an invalid     authentication method in our instituion.'' A SAML assertion is received, and the     authentication method -- ''InternetProtocol'' '' is included in the     AuthnStatement of the assertion</li> </ul><H3>Evaluation</H3><p>The Connectathon Monitor may ask you to run these steps real-time. Verify that the Form Filler    received no responses to any of the requests because validation of the assertion failed. The Form    Filler has no indication that the transaction failed because of the validation failure.</p> <p>An Authentication Failure event was logged by the Form Manager for each assertion     validation failure. </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (712, 1, 0, '2009-11-24 10:53:19.451', 'epoiseau', '<H3>Special Instructions</H3><p> <p>RFD Form Manager actors should run test <strong>XUA_RFD_Retrieve_Submit</strong> before running this test, to ensure the    ''success'' case works first.</p> </p><H3>Description</H3><p>This test verifies that a X-Service Provider (Form Manager) will not respond to requests for forms from a X-Service User (Form Filler) when the assertions indicate that    Form Filler should not grant access.</p><H3>Evaluation</H3><p>Verify that the Form Filler was unsuccessful receiving responses to its requests for forms because    validation of the assertion failed.'' The Form Filler has no indication that the    query failed because of the validation failure.</p><p>On the <strong>Audit Record Repository</strong>, verify: </p><ul>     <li>An Authentication Failure event was logged by the Form Manager for each assertion     validation failure. </li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (713, 1, 0, '2009-11-24 10:53:19.453', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Form Managers must complete test <b> XUA_X-Service_Provider_Setup</b> before running this   test.</p> </p><H3>Description</H3><p>In this test, an RFD Form Manager (X-Service Provider) verifies a principal&rsquo;s    assertions before exchanging form data with a Form    Filler (X-Service User) .&nbsp; &nbsp;The Form Manager may optionally use an external    X-Assertion Provider to validate the contents of the assertion.</p><p>This test assumes the Form Filler gets the assertion when the user logs in to the system and    then uses that one for the session (or until the assertion expires).</p><p>This tests the &lsquo;success&rsquo; case.&nbsp;&nbsp; Denial of access based    on assertions is tested in a different test - <strong>XUA_Form_Mgr_Restrict_Access</strong>.</p><H3>Evaluation</H3><p>The <strong>X-Service User (Form Filler);</strong> </p><ul>     <li>Will demonstrate that it received a response from the Form Manager &ndash; and that it     was able to successfully submit the completed form.</li>     <li>Will demonstrate that it audited the export event (submit transaction).&nbsp; This may     need to be checked on the Audit Record Repository.&nbsp; The audit event record will include     the identity provided in the XUA Identity Assertion. &nbsp;the ATNA Audit message      <strong>EventID</strong> element is "Export" and the <strong>UserName </strong>element shall     record the X-User Assertion using the following encoding: </li>     <ul>      <li>alias"&lt;"user"@"issuer"&gt;"      &nbsp;&nbsp;where: </li>      <li> <strong>alias </strong>is the optional string within the SAML Assertion''s Subject element      SPProvidedID attribute </li>      <li> <strong>user </strong>is the required content of the SAML Assertion''s Subject element </li>      <li> <strong>issuer </strong>is the X-Assertion Provider entity ID contained with the content of      SAML Assertion''s Issuer element </li>     </ul> </ul><p>The <strong>X-Service Provider (Form Manager):</strong> </p><ul>     <li>Will demonstrate for the Connectathon Monitor, through log files or other means, that the     SAML assertion was received from the Form Filler and that its contents were verified prior to     responding to the Form Filler''s requests.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (714, 1, 0, '2009-11-24 10:53:19.455', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Document Registries (X-Service Providers) run one instance of this test.</p> <p>Before the test:</p> <ul>     <li>The X-Service Provider (Document Registry) must configure its system to not trust the     assertion provider (this is either the external     X-Assertion Provider used by the Document Consumer, or the Document Consumer itself if it is     generating its own SAML assertions).  The Registry will receive the assertion via the Document Consumer when the Consumer makes its query request.</li>     <li>(this part of the test is deferred this year): The X-Service Provider     (Document Registry) must configure its system to reject assertions received where the     authentication method used is ''InternetProtocol''. , eg it contains: </li> </ul> <p> <i><saml:AuthnStatement AuthnInstant="2007-10-08T14:49:14Z">             <saml:AuthnContext>                         <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol</saml:AuthnContextClassRef>             </saml:AuthnContext>     </saml:AuthnStatement> </i> </p> </p><H3>Description</H3><p>This tests the X-Service Provider''s (Document Registry''s) ability to deny    access in two cases:</p><ul>     <li>Valid assertion received from an assertion provider not trusted by the Registry</li>     <li>(this part of the test is deferred for XUA testing this year) The ''Connectathon     Policy'' states that ''InternetProtoco'' is an invalid authentication     method in our instituion.'' A SAML assertion is received, and the authentication method     -- ''InternetProtocol'' '' is included in the AuthnStatement of the     assertion</li> </ul><H3>Evaluation</H3><p>The Connectathon Monitor may ask you to run these queries real-time. Verify that the Document    Consumer received no responses to any of the queries because validation of the assertion failed.    The Document Consumer has no indication that the query failed because of the validation failure.</p> <p>An Authentication Failure event was logged by the Doc Registry for each assertion     validation failure.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (715, 1, 0, '2009-11-24 10:53:19.457', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Run test <strong>XUA_Stored_Query</strong> before running this test, to ensure the    ''success'' case works first. </p> <p>To save time, you may want to run test <strong>XUA_Repository_Restrict_Access</strong> in    parallel with this one.</p> </p><H3>Description</H3><p>This test verifies that a X-Service Provider (XDS Document Registry) will not provide a query    response to a X-Service User (XDS Document Consumer) when validation of the assertion fails.</p><H3>Evaluation</H3><p>Verify that the Document Consumer received no responses to any of the queries because    validation of the assertion failed.'' The Document Consumer has no indication that the    query failed because of the validation failure.</p>  <p>Also, on the <strong>Audit Record Repository</strong>, verify: </p><ul>     <li>An Authentication Failure event was logged by the Document Registry for each assertion     validation failure.'' This may need to be checked on the Audit Record Repository.  The audit event record will include the     identity provided in the XUA Identity Assertion.  The ATNA Audit message      <strong>UserName </strong>element records the X-User Assertion using the following     encoding: </li>     <ul>      <li><strong>alias</strong> <"user"@"issuer">"        where: </li>      <li> <strong>alias </strong>is the optional string within the SAML Assertion''s Subject element      SPProvidedID attribute </li>      <li> <strong>user </strong>is the required content of the SAML Assertion''s Subject element </li>      <li> <strong>issuer </strong>is the X-Assertion Provider entity ID contained with the content of      SAML Assertion''s Issuer element </li>     </ul>  </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (716, 1, 0, '2009-11-24 10:53:19.459', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Document Repositories (X-Service Providers) run one instance of this test.</p> <p>Before the test:</p> <ul>     <li>The X-Service Provider (Document Repository) must configure its system to not trust the     assertion provider (this is either the external     X-Assertion Provider used by the Document Consumer, or the Document Consumer itself if it is     generating its own SAML assertions).  The Repository will receive the assertion via the Document Consumer when the Consumer makes its retrieve request.</li>     <li>(this part of the test is not run this year): The X-Service Provider     (Document Repository) must configure its system to reject assertions received where the     authentication method used is ''InternetProtocol''. , eg it contains: </li> </ul> <p>     <i><saml:AuthnStatement AuthnInstant="2007-10-08T14:49:14Z">     '' '' '' '' <saml:AuthnContext> ''     '' '' '' '' '' '' ''     <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol</saml:AuthnContextClassRef>     '' '' '' '' </saml:AuthnContext>     </saml:AuthnStatement> </i> </p> </p><H3>Description</H3><p>This tests the X-Service Provider''s (Document Repository''s) ability to deny    access in two cases:</p><ul>     <li>Valid assertion received from an assertion provider not trusted by the Repository</li>     <li>(this part of the test is deferred for XUA testing this year) The ''Connectathon     Policy'' states that ''InternetProtocol'' is an invalid     authentication method in our instituion.'' A SAML assertion is received, and the     authentication method -- ''InternetProtocol'' '' is included in the     AuthnStatement of the assertion</li> </ul><H3>Evaluation</H3><p>The Connectathon Monitor may ask you to run these retrieves real-time. Verify that the Document    Consumer received no responses to any of the requests because validation of the assertion failed.    The Document Consumer has no indication that the transaction failed because of the validation    failure.</p> <p>An Authentication Failure event was logged by the Doc Repository for each assertion     validation failure.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (717, 1, 0, '2009-11-24 10:53:19.461', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Run test <strong>XUA_Retrieve_Doc</strong> before running this test, to ensure the ''success'' case works first for patient  XUA, Xavier before running this test.</p> <p>To  save time, you may want to run test <strong>XUA_Registry_Restrict_Access</strong> in parallel with this one.</p> </p><H3>Description</H3><p>This test verifies that a X-Service Provider (XDS Document Repository) will not retrieve a document for a X-Service User (XDS Document Consumer) when the assertions indicate that Repository should not grant the user access to requested documents.</p>  <H3>Evaluation</H3> <p>Verify that the Document Consumer received no responses to  any retrieve request because validation of the assertion failed.'' The Document Consumer has no indication that  the retrieve failed because of the validation failure.</p>  <p>Also, on the <strong>Audit Record  Repository</strong>, verify: </p><ul>     <li>An Authentication Failure event was logged by the Document Repository for each assertion validation failure.   This may need to be checked on the Audit Record Repository.  The audit event record will include the     identity provided in the XUA Identity Assertion.  The ATNA Audit message      <strong>UserName </strong>element records the X-User Assertion using the following     encoding: </li>     <ul>      <li><strong>alias</strong> <"user"@"issuer">"        where: </li>      <li> <strong>alias </strong>is the optional string within the SAML Assertion''s Subject element      SPProvidedID attribute </li>      <li> <strong>user </strong>is the required content of the SAML Assertion''s Subject element </li>      <li> <strong>issuer </strong>is the X-Assertion Provider entity ID contained with the content of      SAML Assertion''s Issuer element </li>     </ul>  </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (718, 1, 0, '2009-11-24 10:53:19.464', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Systems must complete tests <strong>XUA_X-Service_Provider_Setup</strong> and     <strong>XUA_Stored_Query</strong> before running this test.</p> </p><H3>Description</H3><p>In this test, an XDS Document Repository (X-Service Provider) verifies a principal''s    assertions before reponding to a retrieve document    request from a Document Consumer (X-Service User) .'' </p><p>This test assumes the Document Consumer gets the assertion when the user logs in to the system    and then use that one for the session (or until the assertion    expires).'''''''' </p><p>This tests the ''success'' case.'''' Denial of access based    on assertions is tested in a different test -   <strong>XUA_Repository_Restrict_Access</strong>.</p><H3>Evaluation</H3><p>The <strong>X-Service User (Document Consumer)</strong>;</p><ul>     <li>Will demonstrate that it received 3 documents for patient XUA, Xavier in response to the     retrieve request(s).</li>       </ul><p>The <strong>X-Service Provider (Document Repository):</strong> </p><ul>     <li>Will demonstrate for the Connectathon Monitor, through log files or other means, that the     SAML assertion was received from the Document Consumer and that its contents were verified prior     to responding to the document retrieve request.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (719, 1, 0, '2009-11-24 10:53:19.466', 'epoiseau', '<H3>Special Instructions</H3> <p>Registries must complete test <b> XUA_X-Service_Provider_Setup</b> before running this   test.</p>  <H3>Description</H3> <p>In this test, a XDS Document Registry (X-Service Provider) verifies a principal''s    assertions before responding to a Stored Query from a    XDS Document Consumer (X-Service User) .   The Registry may optionally use an    external X-Assertion Provider to validate the contents of the assertion.</p> <p>This test assumes the Document Consumer gets the assertion when the user logs in to the system    and then uses that one for the session (or until the assertion expires).</p> <p>This tests the ''success'' case.   Denial of access based    on assertions is tested in a different test - <strong>XUA_Registry_Restrict_Access</strong>.</p>  <H3>Evaluation</H3  p>The <strong>X-Service User (Document Consumer);</strong> </p>  <ul>     <li>Will demonstrate that it received a response from the Registry -- 3 documents for     patient XUA, Xavier, in response to the queries.</li>     <li>Will demonstrate that it audited the query event.  This may need to be     checked on the Audit Record Repository.  The audit event record will include the     identity provided in the XUA Identity Assertion.  The ATNA Audit message      <strong>EventID</strong> element is "Query" and the <strong>UserName </strong>element records the X-User Assertion using the following     encoding: </li>     <ul>      <li><strong>alias</strong>"<"user"@"issuer">"        where: </li>      <li> <strong>alias </strong>is the optional string within the SAML Assertion''s Subject element      SPProvidedID attribute </li>      <li> <strong>user </strong>is the required content of the SAML Assertion''s Subject element </li>      <li> <strong>issuer </strong>is the X-Assertion Provider entity ID contained with the content of      SAML Assertion''s Issuer element </li>     </ul> </ul>  <p>The <strong>X-Service Provider (Document Registry):</strong> </p>  <ul>     <li>Will demonstrate for the Connectathon Monitor, through log files or other means, that the     SAML assertion was received from the Document Consumer and that its contents were verified prior     to responding to the Stored Query request.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (720, 1, 0, '2009-11-24 10:53:19.469', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test specifies the set-up steps on the X-Service-Provider system to ensure the other XUA tests work.</p> <p>X-Service Providers (XDS.b Doc Registries and Repositories, XDR Doc Recipients, PIXv3 Managers, PDQv3 Suppliers, and RFD Form Managers) run one instance of this "test".    There is no evaluation done by Connectathon monitors.</p> </p>  <H3>Description</H3> <ol> <li>In this test <b>each X-Service Provider</b> must be configured to accept the Connecthon X-Assertion Provider as a trustable STS.   Some X-Service Users may provide their own SAML assertions, ie do not rely on an external STS.  The X-Service Provider must be configured these systems as ''trustable STSs''  as well.  </li> <li>X-Service Providers which are a <b>PDQv3 Supplier</b> must contain a patient it its database named <b>XUA, Xavier  patient ID= TBDxxxxxxx</b>.  </li>  <li>X-Service Providers which are an <b>XDS Document Registry or Respository</b> must be seeded with 3 documents for patient <b>XUA, Xavier  patient ID= TBDxxxxxxx</b>.</li>     <ul>    <li>Register the test patient in a PIX Manager</li>    <li>Register the test patient in all Registries which support XUA</li>    <li>Find a Document Consumer to help you.  Submit 2 or 3 test documents patient <b>XUA, Xavier</b> to the Repositories which support XUA</li>   </ul> </ol> <H3>Evaluation</H3> <p>The Connectathon monitor has no evaluation to perform.  This test can immediately be marked ''verified''.    If the setup steps are not done properly, other tests will not work.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (721, 1, 0, '2009-11-24 10:53:19.471', 'epoiseau', '<H3>Special Instructions</H3><p> <p>XDR Document Recipient (X-Service Providers) run one instance of this test.</p> <p>Before the test:</p> <ul>     <li>The X-Service Provider (Doc Recipient) must configure its system to not trust the assertion     provider (this is either the external X-Assertion Provider used by the Document Source, or the     Doc Source itself if it is generating its own SAML assertions). The Document Recipient will     receive the assertion via the Doc Source when the Doc Source Provice-and-Registers its document.</li>     <li>(this part of the test is deferred for XUA testing this year): The X-Service Provider (Doc     Recipient) must configure its system to reject assertions received where the authentication     method used is ''InternetProtocol''. , eg it contains: </li> </ul> <p>     <i><saml:AuthnStatement AuthnInstant="2007-10-08T14:49:14Z">     '' '' '' '' <saml:AuthnContext> ''     '' '' '' '' '' '' ''     <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol</saml:AuthnContextClassRef>     '' '' '' '' </saml:AuthnContext>     </saml:AuthnStatement> </i> </p> </p><H3>Description</H3><p>This tests the X-Service Provider''s (Document Recipient''s) ability to deny    access in two cases:</p><ul>     <li>Valid assertion received from an assertion provider not trusted by the Doc Recipient</li>     <li>(this part of the test is deferred for XUA testing this year) The ''Connectathon     Policy'' states that ''InternetProtocol'' is an invalid     authentication method in our instituion.'' A SAML assertion is received, and the     authentication method -- ''InternetProtocol'' '' is included in the     AuthnStatement of the assertion</li> </ul><H3>Evaluation</H3><p>The Connectathon Monitor may ask you to run these steps real-time. Verify that the Document    Source was not allowed to submit a document because validation of the assertion failed. The    Document Source has no indication that the transaction failed because of the validation failure.</p> <p>An Authentication Failure event was logged by the Doc Recipient for each assertion     validation failure.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (722, 1, 0, '2009-11-24 10:53:19.473', 'epoiseau', '<H3>Special Instructions</H3><p> <p>XDR Document Recipients should run test <strong>XUA_Doc_Source_ProvideandRegister</strong>    before running this test, to ensure the &lsquo;success&rsquo; case works first.</p> </p><H3>Description</H3><p>This test verifies that a X-Service Provider (XDR Document Recipient) will not accept a    document from a X-Service User (XDR Document Source) when the assertions indicate that Doc    Recipient should not grant access.</p><H3>Evaluation</H3><p>Verify that the Document Source was unsuccessful submitting the document because validation of    the assertion failed.&nbsp; The Document Source has no indication that the submit failed    because of the validation failure.</p><p>On the <strong>Audit Record Repository</strong>, verify: </p><ul>     <li>An Authentication Failure event was logged by the Document Recipient for each assertion     validation failure. </li> </ul> ');


--
--

