INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (446, 1, 0, '2009-11-24 10:53:17.144', 'epoiseau', '<H3>Special Instructions</H3><p></p><H3>Description</H3><p>This test of the PGP profile requires a DSS/Order Filler and an Acquisition Modality.</p><p>The DSS/Order Filler enters two SPS in the modality worklist. The Acquisition Modality groups the steps and then creates GSPS objects and MPPS messages for the GSPS objects to split the grouped procedure.</p><p>The DSS/Order Filler is required to have an integrated Image Dipslay to display the study with the split view. The purpose is that the DSS/Order Filler would use that split view for reporting. The link to reporting is not specified.</p><p>For evaluation, the Project Manager should observe the modality creating the grouped images with the split selection. The Project Manager should then observe the proper display on the DSS/Order Filler.</p><p>The DSS/Order Filler will need to retrieve images and GSPS objects from a cooperating Image Manager. This could be the Central Archive.</p> <p>Image Display please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find out what your peers have uploaded on the central archive </p> <H3>Evaluation</H3>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (447, 1, 0, '2009-11-24 10:53:17.146', 'epoiseau', '<H3>Special Instructions</H3> None. <H3>Description</H3> <p>This test of the PGP profile requires an Image Manager/Image Archive and an Acquisition Modality.</p> <p>A cooperating DSS/OF (RIS Mall) enters two SPS in the Modality Worklist for the Modality. The Acquisition Modality groups the steps and then creates GSPS objects and MPPS messages for the GSPS objects to split the grouped procedure.</p> <p>The IM/IA is required to have an integrated Image Dipslay to display the study with the split view. The purpose is that the IM/IA would use that split view for reporting. The link to reporting is not specified.</p> <H3>Evaluation</H3>  <p>For evaluation, the Project Manager should observe the modality creating the grouped images with the split selection. The Project Manager should then observe the proper display on the IM/IA.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (448, 1, 0, '2009-11-24 10:53:17.15', 'epoiseau', '<H3>Special Instructions</H3> Use the RIS MALL as an ADT and OP simulator to register patients and create orders for this test.   <H3>Description</H3> <p> This test verifies the ability of the DSS/Order Filler and Image Manager to reconcile patient information, specifically PIR Case 1 (RAD-TF-1: 4.4.1).  A (John Doe) Patient is registered, an Order is created and a Procedure is scheduled and performed.  Finally, the Doe patient is reconciled.  </p> <p> <strong>NOTE:</strong> The following transactions are tested in other test cases and are not verified in detail here, but you could check for the proper exchange of these messages. </p> <ul> <li>[RAD-1] ADT notifies OP and DSS/OF of patient registration. <li>[RAD-2] OP notifies DSS/OF of new order. <li>[RAD-3] OF informs OP about status of orders it is filling. <li>[RAD-4] DSS/OF notifies IM of new procedure scheduled. <li>[RAD-5] Acquisition modality queries DSS/OF for worklist. <li>[RAD-7] MPPS </ul> <H3>Evaluation</H3> <p> On the <strong>DSS/OF</strong> user interface or database, verify: <ul> <li>There is no entry for patient Doe^SYS_NAME. <li>There is a completed procedure for patient Merge^SYS_NAME.  </ul> <p> On the <strong>Image Manager</strong>, find the study for patient Merge^SYS_NAME.  Verify that: </p> <ul> <li>The images objects are successfully stored on the IM and they are associated with patient Merge^SYS_NAME. <li>There are no images for patient Doe^SYS_NAME. </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (449, 1, 0, '2009-11-24 10:53:17.152', 'epoiseau', '<H3>Special Instructions</H3> Use the RIS MALL as an ADT and OP simulator to register patients and create orders for this test.   <H3>Description</H3> <p> This test verifies the ability of the DSS/Order Filler and Report Manager to reconcile patient information, specifically PIR Case 1 (RAD-TF-1: 4.4.1).  A (John Doe) Patient is registered, an Order is created and a Procedure is scheduled and performed.  Finally, the Doe patient is reconciled.  </p> <H3>Evaluation</H3> <p> On the <strong>DSS/OF</strong> user interface or database, verify: <ul> <li>There is no entry for patient Doe^SYS_NAME. <li>There is a completed procedure for patient Merge^SYS_NAME.  </ul> <p> On the <strong>Report Manager</strong>, find the study for patient Merge^SYS_NAME.  Verify that: </p> <ul> <li>Reports are associated with patient Merge^SYS_NAME. <li>There are no reports for patient Doe^SYS_NAME. </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (450, 1, 0, '2009-11-24 10:53:17.154', 'epoiseau', '<H3>Special Instructions</H3> Ideally, use a real ADT and OP, but you may use the RIS MALL as an ADT and OP simulator to register and provide an order number during this test.  Note that if RIS Mall is used, it dones not support the ORR messages, so you will not be able to complete the later steps in the test. <H3>Description</H3> <p> This test verifies the case where the order is placed in the department and the patient is assigned a temporary Patient ID.  Later, after the patient is registered, the DSS/OF reconciles the patient internally and sends update messages to the OP and IM.   Specifically, this is PIR Case 4 (RAD-TF-1: 4.4.4).  </p> <p> <strong>NOTE:</strong>  The following transactions are tested in other test cases and are not verified in detail here, but you could check for the proper exchange of these messages. </p> <ul> <li>[RAD-5] Modality Worklist <li>[RAD-8] Image Storage <li>[RAD-10] Storage Commitment <li>[RAD-6] [RAD-7]  The ability of the PPS Manager to forward MPPS messages received. </ul> <H3>Evaluation</H3> <p> On the <strong>Image Manager</strong>, verify that the objects stored for this test contain: <ul> <li>Patient ID and Patient Name (OF_SYSTEM-IM_SYSTEM^C4-DOE-REALNAME) generated at the ADT (Received in RAD-12). <li>No objects exist for patient OF-SYSTEM^DOE_IN_DEPT. <li>If there are errors, check the message captured in [test-case-no]pat-upd-case4.txt. </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (451, 1, 0, '2009-11-24 10:53:17.156', 'epoiseau', '<H3>Special Instructions</H3>  This test also covers functionality in the Cardiology ECHO E5 use case. If you are an actor in the PIR and ECHO profiles, you should try to execute this test at least once with peers in the ECHO profile. <p> Use the RIS MALL as an ADT and OP simulator to register and provide an order number during this test.  </p> <p>This test does not work well using RIS Mall, since RIS Mall does not receive MPPS messages, and the manual reconciliation at step 220 is not possible. </p> <p> In this test, the Image Manager receives MPPS messages from the modality.  The IM is the PPS Manager and forwards MPPS messages to the OF. </p> <H3>Description</H3> <p> This test verifies the ability of the DSS/Order Filler to reconcile identifiers in the Unscheduled case.   Specifically, this is PIR Case 5 (RAD-TF-1: 4.4.5, also ECHO Case E5 CARD-TF-1: 4.3.5) - the images are acquired at the Modality but the Patient has not been registered, the Order was not created, and the Procedure was not scheduled. </p> <p> <strong>NOTE:</strong>  The following transactions are tested in other test cases and are not verified in detail here, but you could check for the proper exchange of these messages. </p> <ul> <li>[RAD-3] Filler Order Management - New & Update <li>[RAD-10] Storage Commitment <li>[RAD-7]  The ability of the PPS Manager to forward MPPS messages received. </ul> <H3>Evaluation</H3> View the captured PPS messages from the Modality.  Ensure that there is no Requested or Scheduled procedure information. <p> On the <strong>Image Manager</strong>, verify that the image objects stored for this test contain: </p> <ul> <li>The Patient ID and Patient Name (SYS_NAME^ACTUAL_UNSCHED_PAT) generated at the ADT (Received in RAD-12). <li>The Study Instance UID that was originally generated by the Modality (not a new one generated by the DSS/OF). </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (452, 1, 0, '2009-11-24 10:53:17.158', 'epoiseau', '<H3>Special Instructions</H3> This test is identical to the Cardiology CATH Case C6 Test.  If you are an actor in both PIR and CATH, you should try to execute this test at least once with peers in both profiles.  <H3>Description</H3> This test verifies that the Image Manger updates ALL image objects when a Patient Update message is received in the middle of a procedure.  That is, images which have already been received and images which have yet to be received must all be updated accurately.  This is PIR Case 6 (RAD-TF-2:4.4.6) and also CATH Use Case 6 (CARD-TF-1: 3.4.6), . It is recommended that Image Manager actors find another Image Manager partner and "swap" this test role with them, ie., run this test twice, alternating ''sending'' and ''receiving'' roles. <H3>Evaluation</H3> <p> On the <strong>Image Manager</strong>, verify that all of the image objects stored for this test contain the patient name IM-SYSTEM^POST-UPDATE. </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (453, 1, 0, '2009-11-24 10:53:17.161', 'epoiseau', '<H3>Special Instructions</H3> <p>Test requires that the IOC be turned off or power removed before beginning test sequence. The IOP and pump are available.  </p>   <H3>Description</H3> <p>For this test, Clinician uses a BCMA to initiate PCD-03 transactions consistent with the following steps. Vendors will document the pump is on, the IOP is available, and the IOC is not. </p>  <p>Clinician uses BCMA Programmer to enter patient and pump identification and to identify the drug, its concentration, and volume to be delivered. Pump is to deliver the same drug as in ____ test at half the flow rate; the concentration remains the same. Pump remains on its assigned patient, starting when user verifies command. </p>  <ol>  <li>Clinician verifies that IOP and pump were available.</li>  <li>IOP times out a t network level. Clinician does not receive confirmation message. If a message is provided to the clinician by the IOP this will be shown to the monitor. </li> <li>Clinician restores power to the IOC. IOP either retransmits exiting request(s) or clinician must initiate new request. </li>  </ol>  <H3>Evaluation</H3> <p>Monitor will observe that the network timed out, and an error message if any is displayed by the programmer. Monitor will observe sequence of events following restoration of power to the IOC. This includes transmission of the request to IOC and confirmation from the IOC received by the IOP. </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (454, 1, 0, '2009-11-24 10:53:17.163', 'epoiseau', '<H3>Special Instructions</H3>  <p>Developer prepares the BCMA Programmer to provide patient and pump identification and to identify the drug and the delivery parameters. Patient demographics are provided at the Kudu test page PCD_Patient_Demographics. Specific drug and parameters are given in the Kudu test page PIV_Parameter_Tables, http://ihe-kudu.wustl.edu/na2009/connectathon_test.php.  </p>    <p>This test, out of scope of the PIV profile, is provided to minimize the risk of a failure during a Showcase. The test is successful if no system fails, and it provides some information about the behavior of the IOP/IOC/Pump system if the IOP requests an infusion rate in excess of the amount the pump is capable of providing. </p>    <p>The test provides the steps required of both the IOP and IOC, playing partner roles. IOCs are responsible for coordinating with their partners in advance of the Connectathon to assure that the IOPs and IOCs will have the required number of systems needed for testing. It is necessary to determine that the partnering systems support at least several of the same parameters, with consistent coding. For this reason, PCD recommends (and will shortly require) that parameters be coded as defined by the Rosetta Terminology Mapping project. Consult the project manager to determine if this requirement applies. </p>    <H3>Description</H3> <p>The pump should run long enough to make it obvious that some fluid was delivered. If the IOP and IOC implement the DEC PCD-01 profile, that data may be used to help document what happened. An IOP receives pharmacy information or otherwise prepares to send a message (as described in the test steps provided below) to an IOC. Messages include multiple physiologic and/or operational parameters as appropriate for the IOC and pump channel(s) supported. </p>    <p>Parameters should be sent from actual devices (preferred), simulators or, if necessary from parameter tables provided by the Project Manager (least desirable). </p>    <u>Patient Demographics </u> <p>The patient list is developed using the rules in Kudu for test PCD_Patient_Demographics found at http://ihe-kudu.wustl.edu/na2009/connectathon_test.php.  For this test, the IOP will use any two patients from the list developed with this process. </p>    <H3>Evaluation</H3> <p>Request a monitor validate performance.  Be prepared to demonstrate that the record of performance matches the record of the performance requested: the IOC received and, with support of the clinician, programmed the right pump to deliver the right drug, right amount, at the right flow rate via the right site to the right patient. If the IOP and IOC are capable of supporting the PCD-01 transactions that data may be used to help document performance. </p>   ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (455, 1, 0, '2009-11-24 10:53:17.165', 'epoiseau', '<H3>Special Instructions</H3> <p>This test is provided to minimize the risk of a failure during a Showcase. The test is successful if no system fails, and it provides some information about the behavior of the IOP/IOC/Pump system under two conditions: </p> <ol>  <li>Loss of communication/power interruption at the pump</li> <li>Loss of communication/power interruption at the IOC</li>  </ol>  <p>This test is out of scope of the PIV profile, and therefore any behavior consistent with the design of the systems is acceptable as long as no system fails to operate following the loss of communications. </p>  For this test, Clinician uses a BCMA to initiate PCD-03 transactions consistent with the steps provided below. Vendors will document when the pump is off or on, when the IOC is available, and when it is not. </p>  Clinician uses the BCMA Programmer to enter patient and pump identification and to identify the drug, its concentration, and volume to be delivered. </p>  <H3>Description</H3>  <p>Developer prepares the BCMA Programmer to provide patient and pump identification and to identify the drug and the delivery parameters. Patient demographics are developed as described in the Kudu test page PCD_Patient_Demographics. Specific drug and parameters are given in the Kudu test page PIV_Parameter_Tables, http://ihe-kudu.wustl.edu/na2009/connectathon_test.php.  </p>    <p>The test includes these major components: </p> <ol>  <li>The pump is turned off or power is removed at the beginning of the test sequence. The IOP and IOC are available when the message is sent. If the clinician was to receive a confirmation message or error message that is documented. </li> <li>The pump is turned on/power is restored and the systems work as intended. If the system recognizes that the pump didn''t receive the requested instructions and these are sent again, this is documented. IOP either retransmits existing request(s) or clinician must initiate new request or clinician must take some other action. </li> <li>The IOC is then turned off and a message is sent. The IOP times out at the network level. If the clinician was to receive a confirmation message or error message that is documented. </li> <li>The IOC is turned on and the behavior is documented. If the system recognizes that the IOC didn''t receive the requested instructions and these are sent again, this is documented. IOP either retransmits existing request(s) or clinician must initiate new request or clinician must take some other action. </li> The complete system should function as designed with all components active. </li>  </ol>  <p>The pump should run long enough to make it obvious that some fluid was delivered. If the IOP and IOC implement the DEC PCD-01 profile, that data may be used to help document what happened. </p>  <p>Parameters should be sent from actual devices (preferred), simulators or, if necessary from parameter tables provided by the Project Manager (least desirable). </p>  <H3>Evaluation</H3> <p>Monitor will preferably observe the sequence of events, the resilience of the systems and the ability of the design and clinician actions that lead to successful delivery of the medication. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (456, 1, 0, '2009-11-24 10:53:17.169', 'epoiseau', '<H3>Special Instructions</H3> <p>For this test, Clinician uses a BCMA that supports multiple pumps and multiple patients to initiate PCD-03 transactions consistent with the steps described below. Vendors will document limitations if their BCMA does not support multiple pumps and multiple patients. </p>  <p>If capable of sending data over associated DOR to DOC transactions, these systems also test with multiple DOCs '' a DOC associated with the IOP if one is present, and a DOC that is not associated with the BCMA''s IOP. </p>  <p>Clinician uses BCMA Programmer to enter patient and pump identification and to identify the drug and the delivery parameters. Patient demographics are provided at the Kudu test page PCD_Patient_Demographics. Specific drug and parameters are given in the Kudu test page PIV_Parameter_Tables.  </p>  <H3>Description</H3> <p>Developer prepares the BCMA Programmer to provide patient and pump identification and to identify the drug and the delivery parameters. Patient demographics are provided at the Kudu test page PCD_Patient_Demographics. Specific drug and parameters are given in the Kudu test page PIV_Parameter_Tables, http://ihe-kudu.wustl.edu/na2009/connectathon_test.php.  </p>  <p>The pumps should run long enough to make it obvious that some fluid was delivered. If the IOP and IOC implement the DEC PCD-01 profile, that data may be used to help document what happened. </p>  <p>The IOP requests delivery of drugs for two patients on each of two or more IOCs. Only one pump is used for each patient. I.e., each IOC supports two or more patients, each with one pump. The DORs associated with the IOCs send messages to the DOC associated with the IOP and to at least one other DOC. </p>  <p>Parameters should be sent from actual devices (preferred), simulators or, if necessary from parameter tables provided by the Project Manager (least desirable). </p>  <H3>Evaluation</H3> <p>Request a monitor validate performance.  Be prepared to demonstrate that the record of performance matches the record of the performance requested: the IOC received and, with support of the clinician, programmed the right pump to deliver the right drug, right amount, at the right flow rate via the right site to the right patient. The DOCs'' pump data should support the performance record. </p>  <p>Project manager or monitor will observe the displays provided by the sending and receiving system(s) and the pumps. The patients'' names and/or medical record numbers (MRNs), physiologic and other parameters, their measurement values, and the time of parameter measurement/acquisition and receipt will be compared. </p>  <p>The type of display/documentation by the receiving system is not constrained, it need only be clinically useful. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (457, 1, 0, '2009-11-24 10:53:17.171', 'epoiseau', '<H2>Parameters for PCD PIV Connectathon Tests</H2>  <p>IOPs and IOCs at, or in advance of, the Connectathon will together select their identification from the lists below. I.e., each system will select a column (e.g., IOP #1, IOP #2, IOC #1, IOC #2). If there are more than six IOPs or IOCs then additional columns can be generated in a similar fashion, attempting to have unique parameter values.</p>  <p>PCD PIV Systems require certain parameters in addition to patient demographics. These are generated as follows: </p> <ul> <li>IOPs need drug dose and rate: the <strong>Dose Rate Table</strong> provides the numerical values for dose rate. The units for these values are provided in the <strong>Drug Table</strong> </li> <li>IOCs will obtain the patient demographics and pump identification from the IOC(s) they test with.</li> <li>IOCs need two pumps and two patients: IOC #n will be associated with pumps identified as PUMP #1 on IOC#n (a pump with piggyback capability or if not having piggyback capability, a second channel) and PUMP #2 on IOC#n.  <li>Patient demographics for PCD are developed by referring to the KUDU Connectathon test page <strong>PCD_Patient_Demographics</strong>. Each company should develop two patients using the process described there.</li></ul>  <H4>Drug Tables</H4>   <H4>DOSE RATE (units given below)</H4> <table border=''1''>   <tr>   <td width=''70'' valign=top>   <p align=''center''><strong> Drug #</strong></p>   </td> <td width=''60'' valign=top>   <p align=''center''><strong> IOP #1</strong></p>   </td> <td width=''60'' valign=top>   <p align=''center''><strong> IOP #2</strong></p>   </td> <td width=''60'' valign=top>   <p align=''center''><strong> IOP #3</strong></p>   </td> <td width=''60'' valign=top>   <p align=''center''><strong> IOP #4</strong></p>   </td> <td width=''60'' valign=top>   <p align=''center''><strong> IOP #5</strong></p>   </td> <td width=''60'' valign=top>   <p align=''center''><strong> IOP #6</strong></p> </td> </tr>  <tr>   <td width=''70'' valign=top>   <p align=''center''>Drug #1</p>  </td>  <td width=''60'' valign=top>   <p align=''center''>895</p> </td> <td width=''60'' valign=top>  <p align=''center''> 905</p>  </td> <td width=''60'' valign=top>   <p align=''center''> 915</p> </td> <td width=''60'' valign=top>   <p align=''center''> 925</p> </td> <td width=''60'' valign=top>   <p align=''center''> 935</p> </td> <td width=''60'' valign=top> <p align=''center''> 945</p> </td> </tr>  <tr>   <td width=''70'' valign=top>   <p align=''center''>Drug #2</p>  </td>  <td width=''60'' valign=top>   <p align=''center''>5</p> </td> <td width=''60'' valign=top>  <p align=''center''>6</p> </td>  <td width=''60'' valign=top>   <p align=''center''>7</p> </td> <td width=''60'' valign=top>   <p align=''center''>8</p> </td> <td width=''60'' valign=top>   <p align=''center''>9</p> </td> <td width=''60'' valign=top> <p align=''center''>10</p> </td> </tr>  <tr>   <td width=''70'' valign=top>   <p align=''center''>Drug #3</p>   </td> <td width=''60'' valign=top>   <p align=''center''>91</p> </td> <td width=''60'' valign=top>  <p align=''center''>93</p>  </td> <td width=''60'' valign=top>   <p align=''center''>95</p> </td> <td width=''60'' valign=top>   <p align=''center''>97</p> </td> <td width=''60'' valign=top>   <p align=''center''>99</p> </td> <td width=''60'' valign=top> <p align=''center''>101</p> </td> </tr>  <tr>   <td width=''70'' valign=top>   <p align=''center''>Drug #4</p>   </td> <td width=''60'' valign=top>   <p align=''center''>92</p> </td> <td width=''60'' valign=top>  <p align=''center''>94</p>  </td> <td width=''60'' valign=top>   <p align=''center''>96</p> </td> <td width=''60'' valign=top>   <p align=''center''>98</p> </td> <td width=''60'' valign=top>   <p align=''center''>100</p> </td> <td width=''60'' valign=top> <p align=''center''>102</p> </td> </tr>  <tr>   <td width=''70'' valign=top>   <p align=''center''>Drug #5</p>   </td> <td width=''60'' valign=top>   <p align=''center''>0.1</p> </td> <td width=''60'' valign=top>  <p align=''center''>0.2</p>  </td> <td width=''60'' valign=top>   <p align=''center''>0.3</p> </td> <td width=''60'' valign=top>   <p align=''center''>0.4</p> </td> <td width=''60'' valign=top>   <p align=''center''>0.5</p> </td> <td width=''60'' valign=top> <p align=''center''>0.6</p> </td> </tr>  <tr>   <td width=''70'' valign=top> <p align=''center''>Drug #6</p>  </td>  <td width=''60'' valign=top>   <p align=''center''>200</p> </td> <td width=''60'' valign=top>  <p align=''center''>210</p>  </td> <td width=''60'' valign=top>   <p align=''center''>220</p> </td> <td width=''60'' valign=top>   <p align=''center''>230</p> </td> <td width=''60'' valign=top>   <p align=''center''>240</p> </td> <td width=''60'' valign=top> <p align=''center''>250</p> </td> </tr> </table> <p></p> <p></p> <p>Conversion: (Solution in mL/Drug in mcg) x 60 minutes/hour x patient weight (in kgm) x Y (in mcg/kgm/minute) = mL/hour; where Y is the dose from the dose table</p> <p></p> <p></p>     <H4>DRUGS</H4>    <table border=''1''>     <tr>     <td width=''60'' valign=top><Strong>Drug #</Strong> </td> <td width=''60'' valign=top><Strong>Drug Name</Strong> </td>   <td width=''60'' valign=top><Strong>Drug ID</Strong> </td>   <td width=''80'' valign=top><Strong>Concentration/Volume   (optional) </Strong> </td>   <td width=''80'' valign=top><Strong>Dosing Unit</Strong> </td>   <td width=''60'' valign=top ><Strong>Volume to be Infused (mL) </Strong> </td> </tr>    <tr>     <td width=''60'' valign=top>Drug #1</td> <td width=''60'' valign=top>Dextrose 5%</td>   <td width=''60'' valign=top>1111</td>   <td width=''80'' valign=top>50gm/ 1000 mL</td>   <td width=''80'' valign=top>mL/hr</td>   <td width=''60'' valign=top >1000</td> </tr>    <tr>     <td width=''60'' valign=top>Drug #2</td> <td width=''60'' valign=top>Dopamine</td>   <td width=''60'' valign=top>2222</td>   <td width=''80'' valign=top>400 mg / 250 mL</td>   <td width=''80'' valign=top>mcg/kg/min</td>   <td width=''60'' valign=top >250</td> </tr>    <tr>     <td width=''60'' valign=top>Drug #3</td> <td width=''60'' valign=top>Heparin</td>   <td width=''60'' valign=top>3333</td>   <td width=''80'' valign=top>25,000 Units / 500 mL</td>   <td width=''80'' valign=top>Units/hr</td>   <td width=''60'' valign=top >500</td> </tr>    <tr>     <td width=''60'' valign=top>Drug #4</td> <td width=''60'' valign=top>Propofol</td>   <td width=''60'' valign=top>4444</td>   <td width=''80'' valign=top>1000 mg / 100 mL  </td>   <td width=''80'' valign=top>mcg/kg/min</td>   <td width=''60'' valign=top >100</td> </tr>    <tr>     <td width=''60'' valign=top>Drug #5</td> <td width=''60'' valign=top>Morphine</td>   <td width=''60'' valign=top>5555</td>   <td width=''80'' valign=top>100 mg / 100 mL</td>   <td width=''80'' valign=top>mg/hr</td>   <td width=''60'' valign=top >100</td> </tr>      <tr>     <td width=''60'' valign=top>Drug #6</td> <td width=''60'' valign=top>Vancomycin</td>   <td width=''60'' valign=top>6666</td>   <td width=''80'' valign=top>1000 mg / 250 mL</td>   <td width=''80'' valign=top>mL/hr</td>   <td width=''60'' valign=top >250</td> </tr> </table> <p></p> <p></p> <p></p>    <H4>IOC Pump Identification</H4>    <table border=''1''> <tr>     <td width=''60'' valign=top><Strong> IOC #1</Strong> </td> <td width=''60'' valign=top> <Strong> IOC #2</Strong> </td>   <td width=''60'' valign=top><Strong>  IOC #3</Strong> </td>   <td width=''80'' valign=top><Strong>  IOC #4</Strong> </td>   <td width=''80'' valign=top><Strong>  IOC #5</Strong> </td>   <td width=''60'' valign=top ><Strong>  IOC #6</Strong> </td> </tr>    <tr>     <td width=''60'' valign=top> PUMP #1 on IOC#1</td> <td width=''60'' valign=top> PUMP #1 on IOC#2</td>   <td width=''60'' valign=to > PUMP #1 on IOC#3</td>   <td width=''80'' valign=top> PUMP #1 on IOC#4</td>   <td width=''80'' valign=top> PUMP #1 on IOC#5</td>   <td width=''60'' valign=top> PUMP #1 on IOC#6 </td> </tr>    <tr> <td width=''60'' valign=top> PUMP #2 on IOC#1</td> <td width=''60'' valign=top> PUMP #2 on IOC#2</td>   <td width=''60'' valign=to > PUMP #2 on IOC#3</td>   <td width=''80'' valign=top> PUMP #2 on IOC#4</td>   <td width=''80'' valign=top> PUMP #2 on IOC#5</td>   <td width=''60'' valign=top> PUMP #2 on IOC#6 </td> </tr> </table> <p></p> <p>PUMP #1 on all IOCs is capable of piggyback operation (preferred); if that is not possible, it has a second channel (less desirable); and if that is not possible, another pump is used</p> <p></p> <p></p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (458, 1, 0, '2009-11-24 10:53:17.174', 'epoiseau', '<H3>Special Instructions</H3> <p>Test of pump off line requires that the pump be turned off before beginning test sequence. Both the IOP and IOC are available.  </p>   <H3>Description</H3> <p>For this test, Clinician uses a BCMA to initiate PCD-03 transactions consistent with the following steps. Vendors will document the pump is off and that the IOP and IOC are available. </p>  <p>Clinician uses BCMA Programmer to enter patient and pump identification and to identify the drug, its concentration, and volume to be delivered. Pump is to deliver the same drug as in ____ test at twice the concentration and flow rate (TBD) to its assigned patient, starting when user verifies command. In 3.3.5.2.4, RXG - Pharmacy/Treatment Give Segment: RXR-4 includes ''This field identifies whether the infusion is to be administered as an IV piggyback or secondary infusion.  When this is the case, the TF requires that this field be valued as IVPB.''</p>  <ol>  <li>Clinician verifies that IOP and IOC were available.</li>  <li>Clinician receives the appropriate error message.</li>  </ol>  <H3>Evaluation</H3> <p>Monitor will observe the error message received by the programmer. Error message can be provided in a log file or user interface.Error message should be _______________________</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (459, 1, 0, '2009-11-24 10:53:18.484', 'epoiseau', '<H3>Special Instructions</H3>  <p>For this test, Clinician uses a BCMA that supports multiple pumps and multiple patients to initiate PCD-03 transactions consistent with the following steps. Vendors will document limitations if their BCMA does not support multiple pumps and multiple patients. </p>  <p>Clinician uses the BCMA Programmer to enter patient and pump identification and to identify the drug and the delivery parameters. Patient demographics are provided at the Kudu test page PCD_Patient_Demographics. Specific drug and parameters are given in the Kudu test page PIV_Parameter_Tables. </p>   <p>One IOP/IOC/pump system will demonstrate piggyback operation. If the IOP is not able to set the  piggyback flag that must be documented. If the IOC or pump do not support piggyback operation, document receipt of the piggyback flag and operation of a second channel on the pump. If a second channel is not available, another pump is used. </p>  <p>For the piggyback test, the IOP sets the piggyback flag. In 3.3.5.2.4, RXG - Pharmacy/Treatment Give Segment: RXR-4 includes ''This field identifies whether the infusion is to be administered as an IV piggyback or secondary infusion. When this is the case, the TF requires that this field be valued as IVPB.'' </p>  <H3>Description</H3> <p>The pumps should run long enough to make it obvious that some fluid was delivered. If the IOP and IOC implement the DEC PCD-01 profile, that data may be used to help document what happened. An IOP receives pharmacy information or otherwise prepares to send a message (as described in the test steps provided below) to an IOC. Messages include multiple physiologic and/or operational parameters as appropriate for the IOC and pump channel(s) supported. </p>  <p>The test provides the steps required of both the IOP and IOC, playing partner roles. IOCs are responsible for coordinating with their partners in advance of the Connectathon to assure that the IOPs and IOCs will have the required number of systems needed for testing. It is necessary to determine that the partnering systems support at least several of the same parameters, with consistent coding. For this reason, PCD recommends (and will shortly require) that parameters be coded as defined by the Rosetta Terminology Mapping project. Consult the project manager to determine if this requirement applies. </p>  <p>The IOP requests delivery of a third drug on the same patient using another pump. </p>  <p>Parameters should be sent from actual devices (preferred), simulators or, if necessary from parameter tables provided by the Project Manager (least desirable). </p>  <u>Patient Demographics </u> <p>The patient list is developed using the rules in Kudu for test PCD_Patient_Demographics found at http://ihe-kudu.wustl.edu/na2009/connectathon_test.php.  For this test, the IOP will use any two patients from the list developed with this process. </p>  <H3>Evaluation</H3> <p>Request a monitor validate performance.  Be prepared to demonstrate that the record of performance matches the record of the performance requested: the IOC received and, with support of the clinician, programmed the right pump to deliver the right drug, right amount, at the right flow rate via the right site to the right patient. If the IOP and IOC are capable of supporting the PCD-01 transactions that data may be used to help document performance. </p>  <p>Project manager or monitor will observe the displays provided by the sending and receiving system(s) and the pumps. The patients'' names and/or medical record numbers (MRNs), physiologic and other parameters, their measurement values, and the time of parameter measurement/acquisition and receipt will be compared. The type of display/documentation by the receiving system is not constrained, it need only be clinically useful. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (460, 1, 0, '2009-11-24 10:53:18.579', 'epoiseau', '<H3>Special Instructions</H3> <H1> <i>DO test ATNA_Authentication_HL7_V2 instead.  Do not do this test!</i></H1> This test is only for PIX implementations that support ATNA  <H3>Description</H3> Repeat the PIX_CLIENT test using ATNA TLS communication and logging  <H3>Evaluation</H3> Connectation monitor will look for logs or real time evidence that TLS communication was used. Connectathon monitor will also look for audit messages; this is vague and should be replaced by the exact message expected.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (461, 1, 0, '2009-11-24 10:53:18.647', 'epoiseau', '<h3>Special Instructions</h3>
 Tests <b>PIX_Seed_Mgr</b> and <b>PIX_FEED</b> must be completed before running this test.  These tests ensure that the PIX Manager contains a Patient IDs for the well-known patient Steve Farnsworth:</p>
 <ul>
 <li>Patient ID 101 in the ''master'' affinity domain 1.3.6.1.4.1.21367.2009.1.2.700</li>
 <li>Patient IDs from other ''local'' Patient Identity Source actors, with the affinity domain value as assigned in <a href="http://spreadsheets.google.com/ccc?key=pWfKxFAQxm-xxIt8Oiyq-OA&hl=en">the spreadsheet of connectathon patients</a></b></li>
 </ul>
 
 <p>PIX is designed to use both a query mechanism and an optional push mechanism. This is a test of the query mechanism. </p>
 <h3>Description</h3>
 <p>ITI-9 involves a request by the Patient Identifier Cross-reference Consumer Actor for a
    list of patient identifiers that correspond to a patient identifier known by the consumer.
    The request is received by the Patient Identifier Cross-reference Manager which processes the request and returns a response in the form of a list of corresponding patient identifiers, if any.  </p>
 <p>
 For this part of the test, use the IDs for patient <b>Steve Farnsworth</b> previously created in test PIX_FEED.</p>
    
 <p>The patient Farnsworth should have a record in the PIX Manager with an appropriate
    global ID - 101 - (entered during the test PIX_Seed_Mgr). The same patient should have other
    records entered by Patient ID sources from the test PIX_FEED.</p>
 
 <p>As a PIX Client, you need to find one or more local IDs for the Farnsworth patient
    using the Assigning Authority value assigned to each Patient Identity Source at the connectathon.  See <a href="http://spreadsheets.google.com/ccc?key=pWfKxFAQxm-xxIt8Oiyq-OA&hl=en">the spreadsheet of connectathon patients</a>. You can then use one of the local IDs to form a PIX query to get
    the global ID (and/or other IDs) for that patient.</p>
 <h3>Evaluation</h3>
 <p>The Connectathon Monitor will observe the query and result for each query.
    Connectathon Monitor is looking for evidence that a query was made with a local ID
    and returned the global ID (101) for Farnsworth.  Other local IDs may also be returned, depending on what IDs for Farnsworth have been cross-referenced on the PIX Mgr.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (462, 1, 0, '2009-11-24 10:53:18.71', 'epoiseau', '<H3>Special Instructions</H3>  <p>Patient Identifier Cross-reference Consumer actors which support the <b>PIX Update Notification</b>    option must run one instance of this test.</p> <p>PIX Managers also run this test.</p> <p>Both the HIMSS Registration Tool and a vendor''s Patient Identity Source actor is needed to help with this test.  The Patient Identity Source is marked as ''optional'' in this test because it has no functionality which is evaluated; it is just helping with the test.</p>   <H3>Description</H3>  <p>This test ensures that the Patient Identifier Cross-reference Manager notifies the Patient    Identifier Cross-reference Consumer using ITI-10, when there is a change in a set of    cross-reference patient identifiers belonging to Patient Identifiers in the "Domains of    Interest" to the PIX Consumer.  This test is based on the scenario in ITI TF-2:3.10.4.1.2.</p>   <p>In order for this test to work, the PIX Manager must configure the "Domain of    Interest" to this PIX Consumer to be the value of the Assigning Authority for the    Patient Identity Source actor in this test as well as the Assigning Authority of the HIMSS Registration Tool.  The ability to do this configuration is    evaluated in test PIX_Mgr_Configuration.</p>  <H3>Evaluation</H3>  <p>The connectathon monitor should observe evidence that the PIX Consumer is receiving messages from the PIX Manager when patients are admitted or updated in the ''domains of interest'' configured for that Consumer on the PIX Manager.  This can be done by examining the messages in the chat window (if they were captured by the participants in this test).  The connectathon monitor may also ask to see a new patient registered and/or updates on either the Patient Identity Source or the HIMSS Registration Tool and watch the notifications come in real-time.  </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (463, 1, 0, '2009-11-24 10:53:18.788', 'epoiseau', '<H3>Special Instructions</H3> <p>Test <b>PIX_Seed_Mgr</b> must be run by the PIX Manager before this one can be done.</p> <p>The <b>Patient Identity Source</b> actor must demonstrate 3 capabilities.  In previous years, you may have passed this test with just the 1st item.  A customer reading an integration statement claiming support for this actor would expect to see more than one message within ITI-8 supported, so we will ask you to test:</p> <ol> <li>admit/register a patient with A01, A04, or A05</li> <li>update a patient with A08</li> <li>patient identity merge with A40</li> </ol> <p>Also, each Patient Identity Source needs to have an Assigning Authority assigned to that system for    identifying that source. That Assigning Authority will consist of a text label and an OID. This value is provided to you    by the Project Manager.  Do not    proceed with this test without that value.</p>  <p>Note:</p> <ul>     <li> <strong>Different IHE profiles treat the HL7 assigning authority (PID 3.4) differently. The Assigning Authority has 3 subcomponents</strong> </li>     <ol>      <li>Namespace ID (text string)   </li>      <li>Universal ID (OID)   </li>      <li>Universal ID type (the string <strong>ISO</strong> when you use an OID) </li>     </ol>     <li> <strong>PIX requirements for Connectathon</strong> </li>     <ol>      <li>Patient Identifier Source [ITI-8]</li>      <ul>       <li>You can send either Namespace ID, or   </li>       <li>Universal ID + Universal ID type, or   </li>       <li>All three subcomponents </li>      </ul>      <li>PIX Manager for PIX Profile (inbound feed)</li>      <ul>       <li>You will receive ADT feeds as described above   </li>       <li>You need to map these to the full assigning authority (3 components) which will be used in subsequent transactions. </li>      </ul>     </ol> </ul> </p> <H3>Description</H3> <p>The purpose of the test is to feed the Patient Identity Cross Reference (PIX) Manager with LOCAL patient    information from the Patient Identity Source.  The PIX Manager will cross-reference the information with that already   received for patients in test <b>PIX_Seed_Mgr</b> </p> <p> <strong>Each source of patient identifiers is required to have its own Assigning Authority.</strong>     Please contact the Project Manager if you do not have your own value. Using a common value (ie the ''master'' patient ID) will     defeat later tests.</p> <p>The Patient Identity Source will send its local patient identifier and Assigning Authority for three patients:</p> <ol>     <li>well-known patient FARNSWORTH^STEVE</li> <li> The 2nd patient is SINGLETON^MARION (this is a patient''s maiden name)</li>  <li>The 3nd patient has a last name matching the Patient Identity Source''s kudu system name, and a woman''s first name of MARY, eg.     patient "Ehrxyzmedical^MARY".    Use this patient with last name matching your system name, and generate your own patient ID. (This is the patient''s married name.)  Later, this patient''s first name is updated MARION.</li> </ol> <H3>Evaluation</H3> <p>The <b>Patient Identity Source</b> actor must demonstrate all 3 of these capabilities.  If a capability is missing, the test does not pass:</p> <ol> <li>admit/register a patient with A01 or A04 or A05</li> <li>update a patient with A08</li> <li>patient identity merge with A40</li> </ol> <p>In order to verify the test the Connectathon monitor will ask the following :</p><ul>     <li>One of the two actors will have to show the HL7 messages transmitted between the 2 actors</li>  <li>On the PIX Manager, patient FARNSWORTH, STEVE exists with the value of the local Assigning Authority assigned to the      Patient Identity Source system in this test.  It is cross-referenced to FARNSWORTH^STEVE with the ''global'' ID which previously existed (from the PIX_Seed_Mgr test).  This could be done by using a PIX Consumer to query for the Patient Identity Source''s local ID, and retrieve the global ID for Farnsworth (101).</li> <li>The patient SINGLETON^MARION was initially registered with the PIX Manager.  Now she has been merged with the patient whose last name matches the kudu system name of the Patient Identity Source actor in this test, eg "Ehrxyzmedical".  </li> <li>An update (A08) was sent when the patient first name was updated from Mary to Marion. There was no change in Patient ID.</li> <li>Observe the Patient ID''s that were recorded during the test.  Patient ID for Ehrxyzmedical^Marion survives.  Patient ID for SINGLETON^MARION has been subsumed. </li> <li>     </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (464, 1, 0, '2009-11-24 10:53:18.793', 'epoiseau', '<h3>Special Instructions</h3> Each Patient Identity Source needs to have an Assigning Authority assigned to that system for identifying that source. That Assigning Authority will consist of a text label and an OID. Do not proceed with this test without that value.  <H3>Description</H3>  <p>The purpose of the test is to feed the patient Identity Cross Reference Manager with patient information. Three patients will be identified. One patient will be the subject of PIX queries in later tests. The other two patients will be used to observe a merge operation.</p>  <p>We want to start with 3 patients. Two of the patients will be merged. This leaves one surviving patient from the merge and the last (original) patient. The orginal patient will be the subject of further tests.</p>  <p><b>Each source of patient identifiers is required to have their own assigning authority. Please contact the Project Manager if you do not have your own value. Using a common value will defeat later tests.</b> </p>  <p>We will use the Farnsworth patient for downstream query tests. After that patient is registered with the PIX manager, the operator of the Patient ID Source shall update the <a href="http://ihewiki.wustl.edu/wiki/index.php/Berlin-2007-Connectathon-PIX-Farnsworth"> Connectathon Wiki</a>  with details about the Patient ID and other information for Farnsworth. If the Patient Identity Source does not include a value for PID-3.4 (Assigning Authority),  then the Patient Identity Source system and the PIX Manager must agree that all messages from this source refer to a single Assigning Authority.  </p>  <p>Note : It is possible to perform the test simultaneously to an ADT_FILLER or an ADT_PLACER test if the ADT test supports also the actor Patient Information Source </p>   <h3>Evaluation</h3> <p>In order to verify the test the Connectathon monitor will  ask the following :</p> <ul>   <li>One of the two actors will have to show the HL7  message transmitted between the 2 actors</li>   <li>Show that the Patient Identity Cross Reference  Manager database content is taking into account the different messages from the  Source.     <ul>       <li>Patient FARNSWORTH,  STEVE exists with the value of Assigning Authority assigned to the Patient  Identity Source system in this test.</li>       <li>Patient TANNER,  CHARLES (not CHARLIE) exists with the value of Assigning Authority assigned to  the Patient Identy Source system in this test.</li>       <li>Patient  TANNER (not WALKER)  is the surviving patient after the merge. </li>     </ul>   </li> </ul> <p>''</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (465, 1, 0, '2009-11-24 10:53:18.798', 'epoiseau', '<H3>Special Instructions</H3> Run one instance of this test <H3>Description</H3> <p>PIX Consumers are intended to be integrated with other actors and not standalone actors. This is a visual test made by a Connectathon monitor to observe if such integration exists. The Connectathon monitors will fail systems that do not integrate the PIX Consumer with other applications.</p>  <p>Examples of PIX Consumers that would fail this test: <ul> <li>XDS Consumer that requires the user to cut/paste patient IDs to translate between the known ID and the ID used by the Document Registry </li> <li> An Image Display actor where the user types an ID in one window, performs a query, and then has to cut/paste the response in a window to make a DICOM query. </li> </ul> </p>  <H3>Evaluation</H3> The PIX Consumer shall demonstrate for the Connectathon monitor how the PIX Consumer is integrated with other actors in the system. The monitor will fail systems that do not exhibit software integration but rely on human operations (cut/paste, typing).');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (466, 1, 0, '2009-11-24 10:53:18.803', 'epoiseau', '<H3>Special Instructions</H3><p> <p>PIX Managers must run at least one instance of this test.  You must seek a Patient Identity Source system that can generate a merge message for you;    not all have that capability.</p>  <H3>Description</H3> <p>The purpose of the test is to feed the patient Identity Cross Reference Manager with patient    information. Two patients will be used to observe a patient update and a merge operation.</p>  <H3>Evaluation</H3> <p>In order to verify the test the Connectathon monitor will ask the following :</p> <ul>     <li>One of the two actors will have to show the HL7 messages transmitted between the 2 actors</li>     <li>Show that the Patient Identity Cross Reference Manager database content is taking into     account the different messages from the Source.</li> </ul> <ul>     <ul>      <li>Patient TANNER, ELIZABETH (not LIZ) exists with the value of Assigning Authority assigned      to the Patient Identity Source system in this test.</li>      <li>Patient TANNER (not WALKER) is the surviving patient after the merge.</li>     </ul> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (467, 1, 0, '2009-11-24 10:53:18.805', 'epoiseau', '<H3>Special Instructions</H3> <p>Run one instance of this test.</p>  <H3>Description</H3> <p>The Technical Framework identifies parameters which must be configurable on the Patient Identifier Cross-reference Manager.  In this test, the Connectathon Monitor observes that this configuration is supported.</p>  <H3>Evaluation</H3> <p>The PIX Manager shall demonstrate for the Connectathon  Monitor: </p>  <ul>    <li>How it configures the Patient Identity Source  for each Identification Domain it supports, eg this might be the value in the  Sending Application field MSH-3, or the IP addr of the Patient Identity Source.  (only one source per domain, but a single  source may service multiple domains)   (ITI TF-2:3.8.4.1.3.1)</li>     <li>How it configures the Identifier (Assigning  Authority) for each domain.  One of the  following:</li> </ul>  <ul>     <ul>      <li>The Patient Identity Source does not include a  value for Assigning Authority (PID-3.4).   In this case, the PIX Manager must configure a single Assigning  Authority value that it will use this value when storing the ID informatin and  performing its cross-referencing activities (ITI TF-2:3.8.4.1.3)</li>      <li>The Patient Identity Source sends the value for  Assigning Authority all three  sub-components  of PID-3.4 (ie a namespace ID, universal ID and universal ID type)</li>     </ul> </ul>  <ul>     <li>How it configures which PIX Consumers are  interested in receiving the PIX Update Notification Transactions [ITI-10] (ITI  TF-2:3.10.4.1.2)</li>     <li>How it configures the ''domains of interest'' for  each PIX Consumer, to support the [ITI-10] transaction (ITI TF-2:3.10.4.1.1)</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (468, 1, 0, '2009-11-24 10:53:18.809', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Patient Identity Source actors which support the Pediatric Demographics Option in the PIX or    PIXv3 profiles must run this ''test'' to ensure the proper pediatric demographics are in its    system in order to run subsequent tests on the Pediatric Demographics option. Ideally, this would    happen before arriving at the Connectathon. For the NA2009 Connectathon, they are located here:    http://ihewiki.wustl.edu/wiki/images/d/d3/Connectathon_TwinUseCases.xls</p> <p>PIX Managers must run this test before running test <i>PIX_PDO_Source_to_PIX_Mgr</i> or <i>PIXv3_PDO_Source_to_Pix_Mgr</i>.</p> </p><H3>Description</H3><p>This test is used to populate the PIX Patient Identity Source with demographics of "twins". The    data is a actual data with last names changed.</p><p></p><H3>Evaluation</H3><p>There is no formal evaluation for this test. If the set-up in this test is not done, subsequent    PIX_PDO tests will not work.</p><p>The Connectathon monitor will mark this test as verified when you say it is complete.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (469, 1, 0, '2009-11-24 10:53:18.812', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test is run by PIX Patient Identity Source and PIX Manager actors which support the Pediatric    Demographics option.  These actors are only required to run one instance of this test during the connectathon (rather than 3 tests with different partners); however, you may be asked to run this test with another system if we are short of partners to test this option.</p> <p>The Patient Identity Source must run test <i>PIX_PDO_Source_Loads_Twin_Data</i> first to ensure it is ready to send these patients to the PIX Manager.</p> <p>A PIX Consumer is identified as ''optional'' in this test because it does not need to execute this test for its own connectathon results, but a PIX Consumer is needed by the PIX Manager to help execute some queries.</p> </p><H3>Description</H3><p>Patient Identity Source actors which support the Pediatric Demographics option must support the    ITI-30 transaction and provide values, when available for these Pediatric Demographic fields:</p><ul>     <li>Mother''s Maiden Name</li>     <li>Patient Home Telephone</li>     <li>Patient Multiple Birth Indicator</li>     <li>Patient Birth Order</li>     <li>Last update Date/Time</li>     <li>Last Update Facililty</li> </ul><p>This test consists of three parts.  Each part is a pre-requisite for the next.  Eg. If the two systems are not successful with the first part, don''t proceed to the next parts unless the problem is fixed.</p><ol> <li> <b>Part one:</b> Patient Identity Source send two patients to the PIX Manager to ensure that all 6 pediatric demographic fields are supported by both the Patient Identity Source and PIX Manager systems.</li> <li> <b>Part two:</b>  Patient Identity Source sends the "twin" data to the PIX Manager.  For the NA2009 Connectathon, the spreadsheet containing this twin   demographic data is located here: <i>   http://ihewiki.wustl.edu/wiki/images/d/d3/Connectathon_TwinUseCases.xls</i> </li> <li> <b>Part three:</b>  PIX Consumer queries the PIX Manager for twin data.</li> </ol><p> <b>Part one details:</b>  The Patient Identity Source will first send information for these two patients to the PIX    Manager. The purpose of this portion of the test is to ensure that both systems support ITI-30 and can send /    store values for these fields.   If this is successful, then the ability of the PIX Manager to match based on these fields is     tested in the remaining test steps.</p><table width="700" border="3" cellspacing="0" cellpadding="0">     <tr>      <td>&nbsp;</td>     <td>&nbsp;</td>     <td>       <div align="center">        <strong>Patient 1 </strong>       </div>      </td>     <td>       <div align="center">        <strong>Patient 2 </strong>       </div>      </td>     </tr>     <tr>      <td>PID-3</td>     <td>Patient Identifier List </td>     <td>       <div align="center">as created by your system </div>      </td>     <td>       <div align="center">as created by your system </div>      </td>     </tr>     <tr>      <td>PID-5</td>     <td>Patient Name </td>     <td>       <div align="center">PDO-your-system^One^M <i>eg. PDO_PIX_MGR_ABC^One^M</i> </div>      </td>     <td>       <div align="center">PDO-your-system^Two^M <i>eg. PDO_PIX_MGR_ABC^Two^M</i> </div>      </td>     </tr>     <tr>      <td width="99">PID-6</td>     <td width="193">Mother''s Maiden Name </td>     <td width="186">       <div align="center">PDO-maiden^Mom</div>      </td>     <td width="208">       <div align="center">PDO-maiden^Mom</div>      </td>     </tr>     <tr>      <td>PID-13</td>     <td>Patient Home Telephone </td>     <td>       <div align="center">888-555-1212</div>      </td>     <td>       <div align="center">888-555-1212</div>      </td>     </tr>     <tr>      <td>PID-24</td>     <td>Patient Multiple Birth Indicator </td>     <td>       <div align="center">Y</div>      </td>     <td>       <div align="center">Y</div>      </td>     </tr>     <tr>      <td>PID-25</td>     <td>Patient Birth Order </td>     <td>       <div align="center">1</div>      </td>     <td>       <div align="center">2</div>      </td>     </tr>     <tr>      <td>PID-33</td>     <td>Last Update Date/Time </td>     <td>       <div align="center">as provided by Pat ID Source </div>      </td>     <td>       <div align="center">as provided by Pat ID Source </div>      </td>     </tr>     <tr>      <td>PID-34</td>     <td>Last Update Facility </td>     <td>       <div align="center">as provided by Pat ID Source </div>      </td>     <td>       <div align="center">as provided by Pat ID Source </div>      </td>     </tr> </table><H3>Evaluation</H3><p> <b>Verify PART ONE:  </b>On the <strong>PIX Manager</strong>, the Connectathon monitor will verify that the two patients    sent by the Patient Identity Source are stored. Refer to the values in the test description. This    may be verified by displaying these patients on a user interface on the PIX Manager, or by seeing    these values in the PIX Manager database.</p><p>The monitor may ask to see a copy of the ADT^A28 message received.</p><ul>     <li>PID-6 Mother''s Maiden Name</li>     <li>PID-13 Patient Home Telephone</li>     <li>PID-24 Patient Multiple Birth Indicator</li>     <li>PID-25 Patient Birth Order</li>     <li>PID-33 Last Update Date/Time</li>     <li>PID-34 Last Update Facililty</li> </ul><p>If the Patient Identity Source cannot send value for all of these fields, it does not pass this    test. </p><p>If the PIX Manager did not store values for all of these fields for both patients, it does not    pass this test.</p><p>There is no individual verification for PART TWO where twin demographics are sent to the PIX Manager.  If that is not done, PART THREE will not work. For the NA2009 Connectathon, the spreadsheet containing this twin    demographic data is located here: <i>     http://ihewiki.wustl.edu/wiki/images/d/d3/Connectathon_TwinUseCases.xls</i>   </p><p> <b>Verify PART THREE:  </b>The best method is to visit the PIX Consumer and re-execute several queries.  You may be able to evaluate the contents of queries and responses if they were captured in the chat window.  Note that the matching algorithm on the PIX Manager is not mandated by the profile.  However, the PIX Manager must demonstrate to the satisfaction of the Connectathon monitor that it has used the extra pediatric demographics to distinguish between twin records.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (470, 1, 0, '2009-11-24 10:53:18.815', 'epoiseau', '<H3>Special Instructions</H3><p>
 <p>PIX Managers run one instance of this test.   If you can load these patients into your PIX Manager prior to arriving at the Connectathon, you will be ahead of the game.    Refer to 
 <a href="http://spreadsheets.google.com/ccc?key=pWfKxFAQxm-xxIt8Oiyq-OA&hl=en">the spreadsheet of connectathon patients</a>.</p>
 </p>
 <H3>Description</H3>
 <p>The purpose of this test is to place well-known patients in each PIX Manager. These records
    each have a global patient ID with the master Assigning Authority used at the connectathon. </p>
 <p>Later tests will use these same demographics but ''local'' patient IDs with the value of the
    Assigning Authority being the OID given to each Patient Identity Source at the Connectathon.</p>
 <p>Load patient demographics provided in advance of the Connectathon Project Manager. These
    demographics include two ''well-known'' patients, FARNSWORTH^STEVE (for PIXv2 tests) and WALTERS^WILLIAM (for PIXv3 tests). It also includes one patient for
    each XDS Document Source and Patient Identity Source at the connectathon. These patients have a last name matching the
    Source''s kudu system name, and a woman''s first name, eg. patient "Ehrxyzmedical^Mary". </p>
 <p>The PIX Manager can use the RIS Mall or HIMSS Registration Tool to load these patients; locate these patients in the RIS Mall or HIMSS tool and have it send you patient registration messages. Or, load this by hand.</p>
 <H3>Evaluation</H3>
 <p>Evaluation will occur in later tests when PIX Clients query your PIX Manager. Ask the monitor
 
    to mark this test as verified when the demographics are loaded into your system.  There is no need to check logs.</p>
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (471, 1, 0, '2009-11-24 10:53:18.82', 'epoiseau', '<H3>Special Instructions</H3><p>
 <p>Tests <b>PIXv3_Seed_Mgr</b> and <b>PIXv3_FEED</b> must be completed before running this test.  These tests ensure that the PIX Manager contains a Patient IDs for the well-known patient William Walters:</p>
 <ul>
 <li>Patient ID 202 in the ''master'' affinity domain 1.3.6.1.4.1.21367.2009.1.2.700</li>
 <li>Patient IDs from other ''local'' Patient Identity Source actors, with the affinity domain value as assigned in <a href="http://spreadsheets.google.com/ccc?key=pWfKxFAQxm-xxIt8Oiyq-OA&hl=en">the spreadsheet of connectathon patients</a></b></li>
 </ul>
 
 <H3>Description</H3>
 <p>ITI-9 involves a request by the Patient Identifier Cross-reference Consumer Actor for a
    list of patient identifiers that correspond to a patient identifier known by the consumer.
    The request is received by the Patient Identifier Cross-reference Manager which processes the request and returns a response in the form of a list of corresponding patient identifiers, if any.  </p>
 <p>
 For this part of the test, use the IDs for patient <b>William Walters</b> previously created in test PIX_FEED.</p>
    
 <p>The patient Walters should have a record in the PIX Manager with an appropriate
    global ID - 202 - (entered during the test PIX_Seed_Mgr). The same patient should have other
    records entered by Patient ID sources from the test PIX_FEED.</p>
 
 <p>As a PIX Client, you need to find one or more local IDs for the Walters patient
    using the Assigning Authority value assigned to each Patient Identity Source at the connectathon.  See <a href="http://spreadsheets.google.com/ccc?key=pWfKxFAQxm-xxIt8Oiyq-OA&hl=en">the spreadsheet of connectathon patients</a></b>. You can then use one of the local IDs to form a PIX query to get
    the global ID (and/or other IDs) for that patient.</p>
 <H3>Evaluation</H3>
 <p>The Connectathon Monitor will observe the query and result for each query. Connectathon Monitor
    is looking for evidence that a query was made with a local ID and returned the global ID (202) for
    Walters.  Other local IDs may also be returned, depending on what IDs for Walters have been cross-referenced on the PIX Mgr.</p>
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (472, 1, 0, '2009-11-24 10:53:18.834', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Patient Identifier Cross-reference Consumer actors which support the <b>PIXV3 Update Notification</b>    option must run one instance of this test.</p> <p>PIX Managers also run this test.</p> <p>Both the HIMSS Registration Tool and a vendor''s Patient Identity Source actor is needed to help with this test.  The Patient Identity Source is marked as ''optional'' in this test because it has no functionality which is evaluated; it is just helping with the test.</p>   <H3>Description</H3> <p>This test ensures that the Patient Identifier Cross-reference Manager notifies the Patient    Identifier Cross-reference Consumer using ITI-46, when there is a change in a set of    cross-reference patient identifiers belonging to Patient Identifier in the ''Domains of    Interest'' to the PIX Consumer.  This test is based on the scenario in ITI TF-2:3.46.4.1.2.</p> <p>In order for this test to work, the PIX Manager must configure the ''Domain of    Interest'' to this PIX Consumer to be the value of the Assigning Authority for the    Patient Identity Source actor in this test.''  If there is no Patient Identity Source actor available, you could use the HIMSS Registration tool.</p> <H3>Evaluation</H3> <p>The PIX Manager will show the Connectathon Monitor how it configures the "Domain(s) of Interest" to each PIX Consumer it is configured to send Update Notification messages to.</p> <p>The connectathon monitor should observe evidence that the PIX Consumer is receiving messages from the PIX Manager when patients are admitted or updated in the ''domains of interest'' configured for that Consumer on the PIX Manager.  This can be done by examining the messages in the chat window (if they were captured by the participants in this test).  The connectathon monitor may also ask to see a new patient registered and/or updates and watch the notifications come in real-time.  </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (473, 1, 0, '2009-11-24 10:53:18.836', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Test <b>PIX_Seed_Mgr</b> must be run by the PIX Manager before this one can be done.</p> <p>The <b>Patient Identity Source</b> actor must demonstrate 3 capabilities.  In previous years, you may have passed this test with just the 1st item.  A customer reading an integration statement claiming support for this actor would expect to see more than one message within ITI-44 supported, so we will ask you to test:</p> <ol> <li>admit/register a patient with PRPA_IN201301UV02 - Patient Registry Record Added</li> <li>update a patient with PRPA_IN201302UV02 - Patient Registry Record Revised</li> <li>patient identity merge with PRPA_IN201304UV02 - Patient Registry Duplicates Resolved</li> </ol>  <p>Also, each Patient Identity Source needs to have an Assigning Authority assigned to that system for    identifying that source. That Assigning Authority will consist of a text label and an OID. This value is provided to you    by the Project Manager.  Do not    proceed with this test without that value.</p> </p>  <H3>Description</H3> <p>The purpose of the test is to feed the Patient Identity Cross Reference (PIX) Manager with LOCAL patient    information from the Patient Identity Source.  The PIX Manager will cross-reference the information with that already    received for patients in test <b>PIX_Seed_Mgr</b> </p> <p> <strong>Each source of patient identifiers is required to have its own Assigning Authority  (for IdentifiedPerson/id/@root (Assigning Authority)).</strong>    Please contact the Project Manager if you do not have your own value. Using a common value (ie the MASTER patient ID) will    defeat later tests.</p> <p>The Patient Identity Source will send its local patient identifier and Assigning Authority for three patients:</p> <ol>     <li>well-known patient WILLIAM WALTERS</li> <li> The 2nd patient is ALICE MAIDEN (this is a patient''s maiden name)</li> <li>The 3nd patient has a last name matching the Patient Identity Source''s kudu system name, and a woman''s first name of ALYSSA, eg.     patient "Ehrxyzmedical^ALYSSA".    Use this patient with last name matching your system name, and generate your own patient ID. (This is the patient''s married name.)  Later, this patient''s first name is updated ALICE.</li> </ol> <H3>Evaluation</H3> <p>The <b>Patient Identity Source</b> actor must demonstrate all 3 of these capabilities.  If a capability is missing, the test does not pass:</p> <ol> <li>admit/register a patient with PRPA_IN201301UV02 - Patient Registry Record Added</li> <li>update a patient with PRPA_IN201302UV02 - Patient Registry Record Revised</li> <li>patient identity merge with PRPA_IN201304UV02 - Patient Registry Duplicates Resolved</li> </ol> <p>In order to verify the test the Connectathon monitor will ask the following :</p><ul>     <li>One of the two actors will have to show the HL7 messages transmitted between the 2 actors</li>  <li>On the PIX Manager, patient WILLIAM WALTERS exists with the value of the local Assigning Authority assigned to the      Patient Identity Source system in this test.  It is cross-referenced to WILLIAM WALTERS with the ''global'' ID which previously existed (from the PIX_Seed_Mgr test).  This could be done by using a PIX Consumer to query for the Patient Identity Source''s local ID, and retrieve the global ID for WALTERS (202).</li> <li>The patient ALICE MAIDEN was initially registered with the PIX Manager.  Now she has been merged with the patient whose last name matches the kudu system name of the Patient Identity Source actor in this test, eg "Ehrxyzmedical".  </li> <li>An update (PRPA_IN201302UV02) was sent when the patient first name was updated from ALYSSA to ALICE. There was no change in Patient ID.</li> <li>Observe the Patient ID''s that were recorded during the test.  Patient ID for Ehrxyzmedical^ALICE survives.  Patient ID for ALICE MAIDEN has been subsumed. </li>     </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (474, 1, 0, '2009-11-24 10:53:18.838', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Run one instance of this test.</p> </p><H3>Description</H3><p>PIX Consumers are intended to be integrated with other actors and not standalone actors. This    is a visual test made by a Connectathon monitor to observe if such integration exists. The    Connectathon monitors will fail systems that do not integrate the PIX Consumer with other    applications. Examples of PIX Consumers that would fail this test:</p><ul>     <li>XDS Consumer that requires the user to cut/paste patient IDs to translate between the known     ID and the ID used by the Document Registry</li>     <li>An Image Display actor where the user types an ID in one window, performs a query, and then     has to cut/paste the response in a window to make a DICOM query.</li> </ul><H3>Evaluation</H3><p>The PIX Consumer shall demonstrate for the Connectathon monitor how the PIX Consumer is    integrated with other actors in the system. The monitor will fail systems that do not exhibit    software integration but rely on human operations (cut/paste, typing).</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (475, 1, 0, '2009-11-24 10:53:18.843', 'epoiseau', '<H3>Special Instructions</H3><p> <p>PIX Managers must run at least one instance of this test.  You must seek a Patient Identity Source system that can generate a HL7v3 merge message for you;    few will have that capability.  If you cannot do the merge, try the patient update message.   </p> </p><H3>Description</H3><p>The purpose of the test is to feed the patient Identity Cross Reference Manager with patient    information. Two patients will be used to observe a patient update and a merge operation.</p><H3>Evaluation</H3><p>In order to verify the test the Connectathon monitor will ask the following :</p><ul>     <li>One of the two actors will have to show the HL7v3 message, and the Acknowledgement,     transmitted between the 2 actors</li>     <li>Show that the Patient Identity Cross Reference Manager database content is taking into     account the different messages from the Source.</li> </ul><ul>     <ul>      <li>Patient REYNOLDS,ROBERTA (not BOBBIE) exists with the value of Assigning Authority assigned to      the Patient Identy Source system in this test..</li>      <li>Patient REYNOLDS (not REYNARD) is the surviving patient after the merge.</li>     </ul> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (476, 1, 0, '2009-11-24 10:53:18.845', 'epoiseau', 'empty description in Kudu');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (477, 1, 0, '2009-11-24 10:53:18.849', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test is run by PIXv3 Patient Identity Source and PIX Manager actors which support the    Pediatric Demographics option. These actors are only required to run one instance of this test    during the connectathon (rather than 3 tests with different partners); however, you may be asked    to run this test with another system if we are short of partners to test this option.</p> <p>The Patient Identity Source must run test <i>PIX_PDO_Source_Loads_Twin_Data</i> first to ensure    it is ready to send these patients to the PIX Manager.</p> <p>A PIX Consumer is identified as ''optional'' in this test because it does not need to execute    this test for its own connectathon results, but a PIX Consumer is needed by the PIX Manager to    help execute some queries.</p> </p><H3>Description</H3><p>Patient Identity Source actors which support the Pediatric Demographics option must support the    ITI-44 transaction and provide values, when available for these Pediatric Demographic fields:</p><ul>     <li>Mother''s Maiden Name - </li>     <li>Patient Home Telephone - Person.telecom </li>     <li>Patient Multiple Birth Indicator - Person.multipleBirthInd</li>     <li>Patient Birth Order - Person.multipleBirthOrderNumber</li>     <li>Last update Date/Time - N/A for PIXv3</li>     <li>Last Update Facililty - N/A for PIXv3</li> </ul><p>This test consists of three parts. Each part is a pre-requisite for the next. Eg. If the two    systems are not successful with the first part, don''t proceed to the next parts unless the    problem is fixed.</p><ol>     <li> <b>Part one:</b> Patient Identity Source send two patients to the PIX Manager to ensure that     all 6 pediatric demographic fields are supported by both the Patient Identity Source and PIX     Manager systems.</li>     <li> <b>Part two:</b> Patient Identity Source sends the "twin" data to the PIX Manager. For the     NA2009 Connectathon, the spreadsheet containing this twin demographic data is located here: <i>      http://ihewiki.wustl.edu/wiki/images/d/d3/Connectathon_TwinUseCases.xls</i> </li>     <li> <b>Part three:</b> PIX Consumer queries the PIX Manager for twin data.</li> </ol><p> <b>Part one details:</b> The Patient Identity Source will first send information for these two    patients to the PIX Manager. The purpose of this portion of the test is to ensure that both    systems support ITI-44 and can send / store values for these fields. If this is successful, then    the ability of the PIX Manager to match based on these fields is tested in the remaining test    steps.</p><table width="700" border="3" cellspacing="0" cellpadding="0">     <tr>      <td>&nbsp;</td>     <td>&nbsp;</td>     <td>       <div align="center">        <strong>Patient 1 </strong>       </div>      </td>     <td>       <div align="center">        <strong>Patient 2 </strong>       </div>      </td>     </tr>     <tr>      <td>Patient ID</td>     <td>Patient.id </td>     <td>       <div align="center">as created by your system </div>      </td>     <td>       <div align="center">as created by your system </div>      </td>     </tr>     <tr>      <td>Patient Name</td>     <td>Person.name </td>     <td>       <div align="center">PDO-your-system^One^M eg. PDO_PIX_MGR_ABC^One^M</div>      </td>     <td>       <div align="center">PDO-your-system^Two^M eg. PDO_PIX_MGR_ABC^Two^M</div>      </td>     </tr>     <tr>      <td width="99">Mother''s Maiden Name</td>     <td width="193"></td>     <td width="186">       <div align="center">PDO-maiden^Mom</div>      </td>     <td width="208">       <div align="center">PDO-maiden^Mom</div>      </td>     </tr>     <tr>      <td>Patient Home Telephone</td>     <td>Person.telecom</td>     <td>       <div align="center">888-555-1212</div>      </td>     <td>       <div align="center">888-555-1212</div>      </td>     </tr>     <tr>      <td>Patient Multiple Birth Indicator </td>     <td>Person.multipleBirthInd</td>     <td>       <div align="center">Y</div>      </td>     <td>       <div align="center">Y</div>      </td>     </tr>     <tr>      <td>Patient Birth Order</td>     <td>Person.multipleBirthOrderNumber</td>     <td>       <div align="center">1</div>      </td>     <td>       <div align="center">2</div>      </td>     </tr>     <tr>      <td>Last Update Date/Time </td>     <td>N/A</td>     <td>       <div align="center">no mapping provided in the TF</div>      </td>     <td>       <div align="center">no mapping provided in the TF</div>      </td>     </tr>     <tr>      <td>Last Update Facility</td>     <td>N/A</td>     <td>       <div align="center">no mapping provided in the TF </div>      </td>     <td>       <div align="center">no mapping provided in the TF</div>      </td>     </tr> </table><H3>Evaluation</H3><p> <b>Verify PART ONE: </b>On the <strong>PIX Manager</strong>, the Connectathon monitor will    verify that the two patients sent by the Patient Identity Source are stored. Refer to the values    in the test description. This may be verified by displaying these patients on a user interface on    the PIX Manager, or by seeing these values in the PIX Manager database.</p><p>The monitor may ask to see a copy of the PRPA_IN201301UV02 (Patient Registry Record Added) message received.</p><ul>     <li>Mother''s Maiden Name</li>     <li>Patient Home Telephone</li>     <li>Patient Multiple Birth Indicator</li>     <li>Patient Birth Order</li>     <li>Last Update Date/Time (N/A for PIXv3)</li>     <li>Last Update Facililty (N/A for PIXv3)</li> </ul><p>If the Patient Identity Source cannot send value for all of these fields, it does not pass this    test. </p><p>If the PIX Manager did not store values for all of these fields for both patients, it does not    pass this test.</p><p>There is no individual verification for PART TWO where twin demographics are sent to the PIX    Manager. If that is not done, PART THREE will not work. For the NA2009 Connectathon, the    spreadsheet containing this twin demographic data is located here: <i>     http://ihewiki.wustl.edu/wiki/images/d/d3/Connectathon_TwinUseCases.xls</i> </p><p> <b>Verify PART THREE: </b>The best method is to visit the PIX Consumer and re-execute several    queries. You may be able to evaluate the contents of queries and responses if they were captured    in the chat window. Note that the matching algorithm on the PIX Manager is not mandated by the    profile. However, the PIX Manager must demonstrate to the satisfaction of the Connectathon    monitor that it has used the extra pediatric demographics to distinguish between twin   records.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (478, 1, 0, '2009-11-24 10:53:18.852', 'epoiseau', '<H3>Special Instructions</H3><p> <p>The purpose of this test is to place a well-known patient in each PIX Manager. These records    will each have a global ID. Later tests will use the same demographics but local IDs.</p> </p><H3>Description</H3><p>The purpose of the test is to load the PIX Manager with a patient with these demographics:</p><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td width="232" valign="top"> <p>Name</p> </td>     <td width="406" valign="top"> <p>family = WALTERS''''''    given = WILLIAM</p> </td>     </tr>     <tr>      <td width="232" valign="top"> <p>Patient ID</p> </td>     <td width="406" valign="top"> <p>root    = IHENA&1.3.6.1.4.1.21367.2009.1.2.300</p>       <p>extension    = 202</p>       <p> assigningAuthorityName  = ISO</p> </td>     </tr>     <tr>      <td width="232" valign="top"> <p>AdministrativeSex</p> </td>     <td width="406" valign="top"> <p>M</p> </td>     </tr>     <tr>      <td width="232" valign="top"> <p>DOB</p> </td>     <td width="406" valign="top"> <p>19550505</p> </td>     </tr>     <tr>      <td width="232" valign="top"> <p>SSN (if applicable in your region)</p> </td>     <td width="406" valign="top"> <p>399-11-6788</p> </td>     </tr>     <tr>      <td width="232" valign="top"> <p>Address</p> </td>     <td width="406" valign="top"> <p>820 Jorie Blvd, Chicago     IL 60523</p> </td>     </tr> </table> <p>Load patient demographics provided in advance of the Connectathon Project Manager. These    demographics include one ''well-known'' patient, Walter Williams. It also includes one patient for    each XDS Document Source and Patient Identity Source at the connectathon. These patients have a last name matching the    Source''s kudu system name, and a woman''s first name, eg. patient "Ehrxyzmedical^Mary".   (For those PIX Mgrs who support both v2 and v3, Williams is for v3 tests; the other patients are the same whether you''re testing v2, v3, or both.</p> <p>The PIX Manager can use the HIMSS Registration Tool to load these patients; locate these patients in the HIMSS tool and have it send you HL7v3 patient registration messages. Or, load these by hand.</p>  <H3>Evaluation</H3> <p>Evaluation will occur in later tests when PIX Clients query your PIX Manager. Ask the monitor    to indicate this is done without checking logs.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (479, 1, 0, '2009-11-24 10:53:18.854', 'epoiseau', '<p>Two desktop applications produce records for three patients specifed below:</p> <ul>  <li>Fred Amic</li>  <li>Ann Fletcher</li>  <li>Alexander Washington</li> </ul>  <p>Both desktop applications are run from a single piece of hardware. </p> <p>Desktop application 1 is started and sets the context to patient 1.</p> <p>Desktop application 2 is started, and should follow the context to patient 1.</p> <p>Desktop application 2 requests changing the context to patient 2.</p> <p>Desktop application 1 follows the context change.</p> <p>Desktop application 1 requests a change to patient 3.</p> <p>Desktop application 2 chooses not to follow the context change.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (480, 1, 0, '2009-11-24 10:53:18.86', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p> </p><H3>Description</H3><p>The Post-Processing Manager (PPM) schedules a post-processing workitem. The Evidence Creator (EC) queries for this workitem. The EC should release the claim then requery and reclaim. Optionally, a double claim may be attempted with the aid of a second EC.  The EC then performs the workflow through completion. Optionally, an OF or IM that accepts Workstatus Update received messages may be included.  </p><H3>Evaluation</H3><p>Demonstrate transactions for Connectathon monitor.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (481, 1, 0, '2009-11-24 10:53:18.864', 'epoiseau', '<H3>Special Instructions</H3> None  <H3>Description</H3> <p>The PWPDNS test allows a PWP Consumer actor to locate a PWP Directory using DNS and to make a query of a PWP Directory using Anonymous or Simple Authentication. Each consumer will make two queries of a directory. The first query will return one or more records loaded from the common set of data (PWPLoad). The second query will return one record from the directory-specific data. </p> <p> Because consumer actors are not constrained, this test will not specify the query format.  </p> <p> This test is optional for PWP Consumers. It is required of PWP Directories, assuming PWP Consumers are available for testing. </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (482, 1, 0, '2009-11-24 10:53:18.866', 'epoiseau', '<H3>Special Instructions</H3> None.  <H3>Description</H3> <p>The PWPBind test allows a PWP Consumer actor to bind to a PWP Server using anonymous and simple authentication. To demonstrate a successful bind, the consumer will execute a query against the PWP Server.</p>  <p>For evaluation, the Connectathon monitor will need to observe the PWP Consumer going through all configuration/bind steps. It would be helpful (but not required) if the PWP Server has log records to indicate the authentication methods.</p>  <p>Because consumer actors are not constrained, this test will not specify the query format.</p>  <H3>Evaluation</H3> <p>Connectathon monitor should observe two queries in real time and evaluate response. If PWP Consumer can show configuration for Anonymous Authentication, that will be helpful. PWP Directory need only be consulted in the event of problems.</p>  <p>This test should be followed by the PWQuery test. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (483, 1, 0, '2009-11-24 10:53:18.868', 'epoiseau', '<H3>Description</H3> The PWPConsumerConfig test demonstrates the various ways a PWP Consumer is configured to locate a PWP server. This also tests the DNS to make certain it returns the proper record to locate a PWP server. <p>For evaluation, the Project Manager will need to observe the PWP Consumer going through all configuration steps.</p> <p> Because consumer actors are not constrained, this test will not specify the query format.</p>   <H3>Evaluation</H3> Connectathon monitor should observe all configuration modes and all queries in real time. There are probably no logs on the DNS Server to observe. If they do exist, the monitor should examine those. ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (484, 1, 0, '2009-11-24 10:53:18.881', 'epoiseau', '<H3>Special Instructions</H3> None. <H3>Description</H3> The purpose of the PWPLoad test is for each PWP Directory actor to load two sets of directory information. The first set is common information that will be loaded by all directory actors. This provides a common testing environment for all consumers. The second set of information is tailored to the particular directory actor to simplify identifying the source of a response.  <H3>Evaluation</H3> Connectathon monitor will accept the word of the operator that data are loaded. If data are not loaded, no subsequent tests will work.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (485, 1, 0, '2009-11-24 10:53:18.885', 'epoiseau', '<H3>Special Instructions</H3> None. <H3>Description</H3> <p>The PWPQuery test allows a PWP Consumer actor to make a query of a PWP Directory without specifying the authentication method. Each consumer will make three queries of a directory. The first query will return one or more records loaded from the common set of data (PWPLoad). The second query will return one record from the directory-specific data. The third query will return no records.</p>  <p>Because consumer actors are not constrained, this test will not specify the query format.</p>  <H3>Evaluation</H3>  <p>Connectathon monitor should observe query for Base DN and then three queries in real time and evaluate response. PWP Consumer should demonstrate configuration/logs indicating Simple Configuration.</p>  <p>PWP Directory should demonstration configuration/logs. This might happen before, during or after the queries are examined.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (486, 1, 0, '2009-11-24 10:53:18.886', 'epoiseau', '<H3>Special Instructions</H3> <p>NONE</p>  <h3>Description</h3>  <p>This is a test of consistent print rendering. Each Print Composer should select one test pattern (e.g. SMPTE pattern, DSI pattern or the like) and one medical image (or set of images) that could be considered typical for a hardcopy created by this Print Composer.</p> <p>The test pattern and the medical image(s) should then be printed to each Print Server and the resulting hardcopies submitted to the Project Manager.</p> <p>Please use the <em><a href=system_con_object.php target=OBJECT>Objects Information</a></em> page to find out what your peers have uploaded on the central archive </p><p>Extra copies for use by the Print Composer or Print Server may be created in addition to this.</p>  <h3>Evaluation</h3>  The Project Manager will examine the printouts, comparing them to each other as well as to the display on the Print Composer''s screen (if possible) to see if the test pattern and images are rendered consistently. <p>The print stream shall contain the Presentation LUT. </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (487, 1, 0, '2009-11-24 10:53:18.888', 'epoiseau', '<H3>Special Instructions</H3><p>  <p>QED_Preload is used by QED Clinical Data Sources to load known data into their systems.      This can be done in advance of the Connectathon event.</p>  <p>The source data is under construction and can be found on our wiki page:   <ul>    <li><a href="http://ihewiki.wustl.edu/wiki/index.php/QED_Preload">http://ihewiki.wustl.edu/wiki/index.php/QED_Preload</a></li>   </ul>  </p> <H3>Description</H3> <p>The purpose of QED_Preload is for the repository to load a set of pre-defined patients with      known data. This will allow the consumer actors to know which patients are in the system      and what data will be returned.</p><p>The preload test will list 5 patients below and the general use for each patient.      Then, we will provide the actual data for each patient.</p><p>If the data specified does not make sense or cannot be created, contact the Connectathon      Manager and negotiate for proper data. You know this domain better than we do, and we do not      want to put you through (too many) contortions.</p>    <ol>    <li>Qed, Zero:   This patient will be configured so that any query for different types of data        will return 0 items. The patient is known to the Clinical Data Source, but there are no       entries for that type of data for that patient.</li>    <li>Qed, One: This patient will be configured so that any query for different types of data        will normally return 1 item (1 medication1, 1 immunization, etc.)</li>    <li>Qed, Two: This patient will be configured so that any query for different types of data        will normally return 2 items (2 medications, 2 immunizations, etc.</li>    <li>Qed, Three: Placeholder</li>    <li>Qed, Four: The Consumer will query the Source for this patient, but you should not         have this patient in your system. The goal of using this patient is to have a consumer         send a query that should result in a specific error code. Do not enter this patient in         your system, but do not be surprised when you see a query.</li>    <li>Qed, Five: This will support an optional test by the consumer. We will ask if they can send        a query with a code value that is not recognized by the repository. The repository will return       the appropriate error code. For data, you could replicate the data from Qed, One.</li>   </ol>  <H3>Evaluation</H3>  <p>The monitor will accept your word that you have done this test. Find the monitor responsible       for QED testing and tell him/her you have finished this.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (488, 1, 0, '2009-11-24 10:53:18.89', 'epoiseau', '<H3>Special Instructions</H3><p> <p>The Clinical Data Source needs to complete the QED_Preload test before starting this test.      This test will tell you which diagnostic results should be stored for which patients. Follow the 	 instructions in that test and contact the PCC Project Manager if they are not clear. The goal 	 is a uniform set of diagnostic results to standardize the test process.</p> <p>The Clinical Data Consumer runs this test only if it supports the Query Diagnostic Results option      in the QED profile.</p> <p>The QED profile requires support for a specific query that returns all Imaging Results (DICAT). This      test will discuss the ability to send other queries that are not required by either the Consumer or 	 Repository. If you want to test those queries, you (both Consumer and Clinical Data Source) need to contact 	 each other in advance of the Connectathon and negotiate those other query parameters. 	 The Connectathon Manager will help you document this, but will not require optional queries.</p> <p>The QED profile makes no recommendiation on patient identifier. We will choose a patient identifier      from one Affinity Domain. This will likely involve some hand coding. If you need PIX, PDQ or ADT 	 help, discuss with the Connectathon Manager.</p> </p> <H3>Description</H3> <p>The purpose of QED_QueryDiagnosticResults is for the Clinical Data Consumer to execute several queries      with Clinical Data Source in real time in the presence of a monitor.</p> <p>The consumer shall request all Imaging Results using the value DICAT (PCC 2:3.1.4.5.2)</p> <p>The consumer and Clinical Data Source may negotiate and try other queries. This is not a requirement.</p> <p>The Clinical Data Source has pre-loaded data for defined patients. These queries are required.      The names refer to patients with identifiers that have been pre-loaded by the Clinical Data Source.</p> <ol>  <li>Qed, Zero: Should return zero diagnostic results.</li>  <li> Qed, One: Should return one defined diagnostic result.</li>  <li>Qed, Two: Should return two defined diagnostic results.</li>  <li>Qed, Four: Clinical Data Source does not know about patient and returns KEY204 detected issue alert.</li>  <li>Qed, Five: This is optional. If the Consumer can manage, send a query with a code that is        not recognized by the Clinical Data Source. The Clinical Data Source should respond with a CODE_INVALID 	   detected issue alert.</li> </ol>  <H3>Evaluation</H3><p>The monitor evaluates this test in real time by observing the queries sent by the Clinical Data      Consumer. Each query is listed in the Description above. You should observe each query in real 	 time and make sure the Consumer retrieves the diagnostic results as stated by the test and then 	 stores and/or displays them.</p> <p>There are no requirements on the Consumer for use of the data after the query. You could imagine      they will display in real time to a user. The Consumer might decide to store the data in a database      for later work. You have to be flexible and understand the application.</p> <p>The QED_Load test will tell you which Diagnostic Results are available for each patient.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (489, 1, 0, '2009-11-24 10:53:18.893', 'epoiseau', '<H3>Special Instructions</H3><p> <p>The Clinical Data Source needs to complete the QED_Preload test before starting this test.      This test will tell you which immunizations should be stored for which patients. Follow the 	 instructions in that test and contact the PCC Project Manager if they are not clear. The goal 	 is a uniform set of immunizations to standardize the test process.</p> <p>The Clinical Data Consumer runs this test only if it supports the Query Immunizations option      in the QED profile.</p> <p>The QED profile requires support for a specific query that returns all immunizations (IMMUCAT). This      test will discuss the ability to send other queries that are not required by either the Consumer or 	 Clinical Data Source. If you want to test those queries, you (both Consumer and Clinical Data Source) need to contact 	 each other in advance of the Connectathon and negotiate those other query parameters. 	 The Connectathon Manager will help you document this, but will not require optional queries.</p> <p>The QED profile makes no recommendiation on patient identifier. We will choose a patient identifier      from one Affinity Domain. This will likely involve some hand coding. If you need PIX, PDQ or ADT 	 help, discuss with the Connectathon Manager.</p> </p><H3>Description</H3><p>The purpose of QED_QueryImmunizations is for the Clinical Data Consumer to execute several queries      with a Clinical Data Source in real time in the presence of a monitor.</p><p>The consumer shall request all immunizations using the value IMMUCAT (PCC 2:4.5.2.2)</p><p>The consumer and Clinical Data Source may negotiate and try other queries. This is not a requirement.</p> <p>The Clinical Data Source has pre-loaded data for defined patients. These queries are required.      The names refer to patients with identifiers that have been pre-loaded by the Clinical Data Source.</p> <ol>  <li>Qed, Zero: Should return zero immunizations.</li>  <li> Qed, One: Should return one defined immunization.</li>  <li>Qed, Two: Should return two defined immunizations.</li>  <li>Qed, Four: Clinical Data Source does not know about patient and returns KEY204 detected issue alert.</li>  <li>Qed, Five: This is optional. If the Consumer can manage, send a query with a code that is        not recognized by the Clinical Data Source. The Clinical Data Source should respond with a CODE_INVALID 	   detected issue alert.</li> </ol>  <H3>Evaluation</H3><p>The monitor evaluates this test in real time by observing the queries sent by the Clinical Data      Consumer. Each query is listed in the Description above. You should observe each query in real 	 time and make sure the Consumer retrieves the immunizations as stated by the test and then 	 stores and/or displays them.</p><p>There are no requirements on the Consumer for use of the data after the query. You could imagine      they will display in real time to a user. The Consumer might decide to store the data in a database 	 for later work. You have to be flexible and understand the application.</p><p>The QED_Load test will tell you which immunizations are available for each patient.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (490, 1, 0, '2009-11-24 10:53:18.895', 'epoiseau', '<H3>Special Instructions</H3><p>  <p>The Clinical Data Source and Clinical Data Consumer run this test only if they support the Medications Option      in the QED profile.</p>  <p>The Clinical Data Source needs to complete the QED_Preload test before starting this test.      This test will tell you which medications should be stored for which patients. Follow the      instructions in that test and contact the PCC Project Manager if they are not clear. The goal      is a uniform set of medications to standardize the test process.</p>   <p>The QED profile makes no recommendiation on patient identifier. We will choose a patient identifier      from one Affinity Domain. This will likely involve some hand coding. If you need PIX, PDQ or ADT      help, discuss with the Connectathon Manager.</p>   <p>The data for the Sources is found in the QED_Preload test. We are using a wiki page to construct      the content. That gives you the opportunity to help us improve the test content. You can find the wiki      page at <a href="http://ihewiki.wustl.edu/wiki/index.php/QED_Preload">http://ihewiki.wustl.edu/wiki/index.php/QED_Preload</a>.  </p> <H3>Description</H3>  <p>The purpose of QED_QueryMedications is for the Clinical Data Consumer to execute several queries      with a Clinical Data Source in real time in the presence of a monitor. The required queries are listed below.      You are free to negotiate and try other queries, but these will not be evaluated.</p>  <p>The Clinical Data Consumer shall provide these query parameters in the query per PCC 2: Table 3.1-1   <ul>    <li>includeCarePlanAttachment</li>    <li>patientId</li>   </ul>   The Clinical Data Source shall use those parameters to formulate the response. If the Consumer provides   other optional parameters (see PCC 2: Table 3.1-1), the Source shall also use those parameters to formulate   the response. </p>  <p>The goal of this test is to query for all active medications. If consumers provide a value for <em>careProvisionCode</em>,        they should use the value CURMEDLIST. Acceptable but not encouraged values for this test are RXCAT, MEDLIST, and        HISTMEDLIST. For this test, do not use DISCHMEDLIST.  <p>The Clinical Data Source has pre-loaded data for defined patients. These queries are required.      The names refer to patients with identifiers that have been pre-loaded by the Clinical Data Source.</p>  <ol>   <li>PatientId 110: Qed, Zero: Source knows about patient, but returns zero medications.</li>   <li>PatientId 120: Qed, One: Should return one defined medication.</li>   <li>PatientId 130: Qed, Two: Should return two defined medications.</li>   <li>PatientId 140: Qed, Four: Source does not know about patient and returns KEY204 detected issue alert.</li>   <li>PatientId 150: Qed, Five: This is optional. If the Consumer can manage, send a query with a code that is        not recognized by the Source. The Clinical Data Source should respond with a CODE_INVALID        detected issue alert.</li>  </ol> <H3>Evaluation</H3>  <p>The monitor evaluates this test in real time by observing the queries sent by the Clinical Data      Consumer. Each query is listed in the Description above. You should observe each query in real      time and make sure the Consumer retrieves the medications as stated by the test and then      stores and/or displays them.</p>  <p>There are no requirements on the Consumer for use of the data after the query. You could imagine      they will display in real time to a user. The Consumer might decide to store the data in a database      for later work. You have to be flexible and understand the application.</p>  <p>The QED_Load test will tell you which medications are available for each patient.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (491, 1, 0, '2009-11-24 10:53:18.898', 'epoiseau', '<H3>Special Instructions</H3><p> <p>The Clinical Data Source needs to complete the QED_Preload test before starting this test.      This test will tell you which problems/allergies should be stored for which patients. Follow the 	 instructions in that test and contact the PCC Project Manager if they are not clear. The goal 	 is a uniform set of problems/allergies to standardize the test process.</p> <p>The Clinical Data Consumer runs this test only if it supports the Query Problems/Allergies option      in the QED profile.</p> <p>The QED profile allows the Consumer to select different coded values to request different data      from the Clinical Data Source. In the test instructions below, the Consumer is given the option of which 	 code (or codes) to use. The Consumer is constrained to those codes and cannot invent new ones. </p> <p>The QED profile makes no recommendiation on patient identifier. We will choose a patient identifier      from one Affinity Domain. This will likely involve some hand coding. If you need PIX, PDQ or ADT 	 help, discuss with the Connectathon Manager.</p> </p><H3>Description</H3> <p>The purpose of QED_QueryProblemsAllergies is for the Clinical Data Consumer to execute several queries      with a Clinical Data Source in real time in the presence of a monitor.</p> <p>The consumer and Clinical Data Source may negotiate and try other queries. This is not a requirement.</p> <p>The Clinical Data Source has pre-loaded data for defined patients. These queries are required.      The names refer to patients with identifiers that have been pre-loaded by the Clinical Data Source.</p> <p>The Consumer shall make the queries below using codes from the following list. The Consumer      needs to support at least one of the codes. The consumer may repeat the test with different 	 codes. That would be encouraged.</p>  <p>These Care Provision Codes are taken from PCC 2:3.1.4.5.2</p> <table>     <tr> <th>Code</th><th>Returns</th><th>Template Id</th> </tr>     <tr> <td>MEDCCAT</td><td>All problem entries</td><td>Problem Entry</td> </tr>  <tr> <td>CONDLIST</td><td>All Concern Entries</td><td>Concern Entry</td> </tr>  <tr> <td>PROBLIST</td><td>ALl Problem Concerns</td><td>Problem Concern</td> </tr>     <tr> <td>INTOLIST</td><td>All Allergy Concerns</td><td>Allergy and Intolerance Concern</td> </tr>     <tr> <td>RISKLIST</td><td>All Risks</td><td>Concern Entry</td> </tr> </table><ol>      <li>Qed, Zero: Clinical Data Source knows about the patient, but returns 0 problems/allergies.</li>  <li>Qed, One: Should return 1 defined problems/allergy.</li>  <li>Qed, Two: Should return two defined problems/allergies.</li>  <li>Qed, Four: Clinical Data Source does not know about patient and returns KEY204 detected issue alert.</li>  <li>Qed, Five: This is optional. If the Consumer can manage, send a query with a code that is        not recognized by the Clinical Data Source. The Clinical Data Source should respond with a CODE_INVALID       detected issue alert.</li> </ol> <H3>Evaluation</H3> <p>The monitor evaluates this test in real time by observing the queries sent by the Clinical Data      Consumer. Each query is listed in the Description above. You should observe each query in real 	 time and make sure the Consumer retrieves the problems/allergies as stated by the test and then 	 stores and/or displays them.</p> <p>There are no requirements on the Consumer for use of the data after the query. You could imagine      they will display in real time to a user. The Consumer might decide to store the data in a database      for later work. You have to be flexible and understand the application.</p> <p>The QED_Load test will tell you which problems/allergies are available for each patient.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (492, 1, 0, '2009-11-24 10:53:18.901', 'epoiseau', '<H3>Special Instructions</H3><p> <p>The Clinical Data Source needs to complete the QED_Preload test before starting this test.      This test will tell you which professional services should be stored for which patients. Follow the 	 instructions in that test and contact the PCC Project Manager if they are not clear. The goal 	 is a uniform set of diagnostic results to standardize the test process.</p> <p>The Clinical Data Consumer runs this test only if it supports the Query Professional Services option      in the QED profile.</p> <p>The QED profile requires support for a specific query that returns all Professional Services entries (PSVCCAT). This      test will discuss the ability to send other queries that are not required by either the Consumer or 	 Repository. If you want to test those queries, you (both Consumer and Clinical Data Source) need to contact 	 each other in advance of the Connectathon and negotiate those other query parameters. 	 The Connectathon Manager will help you document this, but will not require optional queries.</p> <p>The QED profile makes no recommendiation on patient identifier. We will choose a patient identifier      from one Affinity Domain. This will likely involve some hand coding. If you need PIX, PDQ or ADT 	 help, discuss with the Connectathon Manager.</p> </p> <H3>Description</H3> <p>The purpose of QED_QueryProfessionalServices is for the Clinical Data Consumer to execute several queries      with Clinical Data Source in real time in the presence of a monitor.</p> <p>The consumer shall request all Professional Services using the value PSVCCAT (PCC 2:3.1.4.5.2)</p> <p>The consumer and Clinical Data Source may negotiate and try other queries. This is not a requirement.</p> <p>The Clinical Data Source has pre-loaded data for defined patients. These queries are required.      The names refer to patients with identifiers that have been pre-loaded by the Clinical Data Source.</p> <ol>  <li>Qed, Zero: Should return zero professional services.</li>  <li> Qed, One: Should return one defined professional service entry.</li>  <li>Qed, Two: Should return two defined professional service entries.</li>  <li>Qed, Four: Clinical Data Source does not know about patient and returns KEY204 detected issue alert.</li>  <li>Qed, Five: This is optional. If the Consumer can manage, send a query with a code that is        not recognized by the Clinical Data Source. The Clinical Data Source should respond with a CODE_INVALID 	   detected issue alert.</li> </ol>  <H3>Evaluation</H3><p>The monitor evaluates this test in real time by observing the queries sent by the Clinical Data      Consumer. Each query is listed in the Description above. You should observe each query in real 	 time and make sure the Consumer retrieves the professional services entries as stated by the test and then 	 stores and/or displays them.</p> <p>There are no requirements on the Consumer for use of the data after the query. You could imagine      they will display in real time to a user. The Consumer might decide to store the data in a database      for later work. You have to be flexible and understand the application.</p> <p>The QED_Load test will tell you which Professional Services entries are available for each patient.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (493, 1, 0, '2009-11-24 10:53:18.903', 'epoiseau', '<H3>Special Instructions</H3><p> <p>The Clinical Data Source needs to complete the QED_Preload test before starting this test.      This test will tell you which vital signs should be stored for which patients. Follow the 	 instructions in that test and contact the PCC Project Manager if they are not clear. The goal 	 is a uniform set of vital signs to standardize the test process.</p> <p>The Clinical Data Consumer runs this test only if it supports the Query Vital Signs option      in the QED profile.</p> <p>The QED profile requires support for a specific query that returns all vital signs (COBSCAT). This      test will discuss the ability to send other queries that are not required by either the Consumer or 	 Repository. If you want to test those queries, you (both Consumer and Clinical Data Source) need to contact 	 each other in advance of the Connectathon and negotiate those other query parameters. 	 The Connectathon Manager will help you document this, but will not require optional queries.</p> <p>The QED profile makes no recommendiation on patient identifier. We will choose a patient identifier      from one Affinity Domain. This will likely involve some hand coding. If you need PIX, PDQ or ADT 	 help, discuss with the Connectathon Manager.</p> </p> <H3>Description</H3> <p>The purpose of QED_QueryVitalSigns is for the Clinical Data Consumer to execute several queries      with Clinical Data Source in real time in the presence of a monitor.</p> <p>The consumer shall request all vital signs using the value COBSCAT(PCC 2:3.1.4.5.2)</p> <p>The consumer and repository may negotiate and try other queries. This is not a requirement.</p> <p>The Clinical Data Source has pre-loaded data for defined patients. These queries are required.      The names refer to patients with identifiers that have been pre-loaded by the Clinical Data Source.</p> <ol>  <li>Qed, Zero: Should return zero vital signs.</li>  <li> Qed, One: Should return one defined vital sign.</li>  <li>Qed, Two: Should return two defined vital signs.</li>  <li>Qed, Four: Clinical Data Source does not know about patient and returns KEY204 detected issue alert.</li>  <li>Qed, Five: This is optional. If the Consumer can manage, send a query with a code that is        not recognized by the repository. The repository should respond with a CODE_INVALID 	   detected issue alert.</li> </ol>  <H3>Evaluation</H3><p>The monitor evaluates this test in real time by observing the queries sent by the Clinical Data      Consumer. Each query is listed in the Description above. You should observe each query in real 	 time and make sure the Consumer retrieves the vital signs sas stated by the test and then 	 stores and/or displays them.</p> <p>There are no requirements on the Consumer for use of the data after the query. You could imagine      they will display in real time to a user. The Consumer might decide to store the data in a database      for later work. You have to be flexible and understand the application.</p> <p>The QED_Load test will tell you which immunizations are available for each patient.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (494, 1, 0, '2009-11-24 10:53:18.906', 'epoiseau', 'empty description in Kudu');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (495, 1, 0, '2009-11-24 10:53:18.907', 'epoiseau', '<H3>Special Instructions</H3><p> <p>The Image Manager will have to complete one or more instances of test <b>REM_Store_Mod_IM</b>    so that its database contains multiple Radiation Dose SRs. The type of filtering done on the Dose    Information Consumer is implementation-specific. Several strategies are outlined in RAD    TF-2:4.64.1.2.1, but none is mandated in the REM profile.</p> </p><H3>Description</H3><p>This tests the interaction between the Dose Information Consumer and the Image Manager for    querying for and retrieving Radiation Dose SRs. </p><H3>Evaluation</H3><p>The Connectathon Monitor will ask the <strong>Dose Information Consumer</strong> to demonstrate    live its ability to query and retrieve Dose Reports from the Image Manager. It may have to delete    previous reports so they can be retrieved again.</p><p>The Dose Information Consumer should demonstrate how it filters many dose records using its    query capabilities. (No specific filtering mechanism is mandated by the Technical Framework.)</p><p>The Connectathon Monitor will verify that dose SRs are successfully retrieved.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (496, 1, 0, '2009-11-24 10:53:18.909', 'epoiseau', '<H3>Special Instructions</H3><p> <p>The Image Manager will have to complete one or more instances of test <b>REM_Store_Mod_IM</b> so that its database contains multiple Radiation Dose SRs.  The type of filtering done on the Dose Information Reporter is implementation-specific.  Several strategies are outlined in RAD TF-2:4.64.1.2.1, but none is mandated in the REM profile.</p> </p><H3>Description</H3><p>This tests the interaction between the Dose Information Reporter and the Image Manager for querying for and retrieving Radiation Dose SRs.  The Dose Information Reporter will be asked to demonstrate the type of report(s) it generates based on the retrieved report information.</p><H3>Evaluation</H3><p>The Connectathon Monitor will ask the <strong>Dose Information Reporter</strong> to demonstrate live its ability to query and retrieve Dose Reports from the Image Manager.   It may have to delete previous reports so they can be retrieved again.</p><p>The Dose Information Reporter should demonstrate how it filters many dose records using its query capabilities.  (No specific filtering mechanism is mandated by the Technical Framework.) </p><p>The Connectathon Monitor will verify that dose SRs are successfully retrieved.</p><p>The <b>Dose Information Reporter</b>  is required to be able to present some form of report to the user based on the retrieved dose information.  The format, contents and analysis of these reports is not defined by the Technical Framework, but if no report is presented, this test does not pass.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (497, 1, 0, '2009-11-24 10:53:18.913', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p> </p><H3>Description</H3><p>This tests an Acquisition Modality sending directly to a Dose Information Consumer. No Storage    Commitment is required.</p><H3>Evaluation</H3><p>The <strong>Dose Information Consumer</strong> will demonstrate for the Connectathon Monitor    that it received the Dose object(s). It is required to be able to process dose objects "according    to the features, configuration, and business logic of the...product." The Dose Information    Consumer will demostrate its capabilties for the Connectathon Monitor who will assess whether    they meet the ''spirit'' of the Technical Framework.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (498, 1, 0, '2009-11-24 10:53:18.915', 'epoiseau', '<H3>Special Instructions</H3><p> <p>The Dose Information Reporter is required to be able to process both TID 10001 (Project X-Ray    Radiation Dose Template) and TID 10011 (CT Radiation Dose Template). The Dose Information    Reporter should seek different partners so that it demonstrates this support during the    Connectathon.</p> </p><H3>Description</H3><p>This tests an Acquisition Modality sending directly to a Dose Information Reporter. No Storage    Commitment is required.</p><H3>Evaluation</H3><p>The <strong>Dose Information Reporter</strong> will demonstrate for the Connectathon Monitor    that it received the Dose object(s). </p><p>It is required to be able to process dose objects "according to the features, configuration,    and business logic of the...product." The Dose Information Reporter will demostrate its    capabilties for the Connectathon Monitor who will assess whether they meet the ''spirit'' of the    Technical Framework.</p><p>At a minimum, the Dose Information shall provide the capability to the review and do summary    analysis of the dose data. If it cannot demonstrate this functionality, it will not pass this    test.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (499, 1, 0, '2009-11-24 10:53:18.918', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p> </p><H3>Description</H3><p>This tests the interaction between an Acquisition Modality and Image Manager for storing    Radiation Dose SRs, including Storage Commitment.</p><H3>Evaluation</H3><p> <strong>Image Managers</strong> are required to provide Level 2 (Full) storage, ie all DICOM    Type 1, 2, and 3 attributes are stored:</p><ul>     <li>The Image Manager will demonstrate for the Connectathon Monitor that the object/s are stored.</li>     <li>The Connectathon Monitor may optionally perform a dump of the DICOM header of the object     stored and spot-check attributes to see if they are stored</li>     <li>The Image Manager has responded to the Storage Commitment request from the Modality.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (500, 1, 0, '2009-11-24 10:53:18.92', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Before running this test, the Dose Information Reporter should complete several instances of    tests <b>REM_Store_Dose_Reporter</b> and/or <b>REM_QR_Dose_Reporter_IM</b> to ensure that it has    adequate Radiation Dose SRs to submit to the Dose Register actor.</p> </p><H3>Description</H3><p>This tests the interaction between the Dose Information Reporter and the Dose Register for    submitting Dose SRs via secure FTP (using TLS). The ability of the Dose Information Reporter to    de-identify the Dose objects is also tested.</p><H3>Evaluation</H3><p>In general, the Connectathon Monitor will verify that the Dose object (DICOM SRs) formatted as DICOM Part 10 media files, are transferred successfully from the Dose Information Reporter to the Dose Register.  The Dose objects are to be encrypted.  The Dose objects may be transferred as</p><ul>     <li>individual files</li>     <li>a Zip Media File formatted per DICOM</li> </ul><p>On the <strong>Dose Information Reporter</strong>, the Connectathon Monitor will verify:</p><ul>     <li>The FTP transaction occurred with TLS.  This can be demostrated using log files.</li>     <li>The system can submit Dose object both via a <b>manual trigger</b>and at a <b>configurable interval</b>.    The system will demonstrate how it modifies the value for the <b>interval of submission</b> to the Dose    Register. </li> </ul><p>The Dose Info Reporter will demostrate how it is able to remove the following attributes or replace the value.  Connectathon Monitor will ask the Dose Info Reporter to demonstrate how to remove/replace attributes that follow; the Connectathon Monitor will select several attributes...all need not be demonstrated.  The Technical Framework requires that the <b>Dose Information Reporter</b> be configurable to    be able to either remove or replace all attributes in this list:</p><ul>     <li>(0008,0014) - Instance Creator UID</li>     <li>(0008,0018) - SOP Instance UID</li>     <li>(0008,0050) - Accession Number</li>     <li>(0008,0080) - Institution Name</li>     <li>(0008,0081) - Institution Address</li>     <li>(0008,0090) - Referring Physician''s Name</li>     <li>(0008,0092) - Referring Physician''s Address</li>     <li>(0008,0094) - Referring Physician''s Telephone Numbers</li>     <li>(0008,1010) - Station Name</li>     <li>(0008,1030) - Study Description</li>     <li>(0008,103E) - Series Description</li>     <li>(0008,1040) - Institutional Department Name</li>     <li>(0008,1048) - Physician(s) of Record</li>     <li>(0008,1050) - Performing Physicians'' Name</li>     <li>(0008,1060) - Name of Physician(s) Reading Study</li>     <li>(0008,1070) - Operators'' Name</li>     <li>(0008,1080) - Admitting Diagnoses Description</li>     <li>(0008,1155) - Referenced SOP Instance UID</li>     <li>(0010,0010) - Patient''s Name</li>     <li>(0010,0020) - Patient ID</li>     <li>(0010,0030) - Patient''s Birth Date</li>     <li>(0010,0032) - Patient''s Birth Time</li>     <li>(0010,0040) - Patient''s Sex</li>     <li>(0010,1000) - Other Patient IDs</li>     <li>(0010,1001) - Other Patient Names</li>     <li>(0010,1010) - Patient''s Age</li>     <li>(0010,1020) - Patient''s Size</li>     <li>(0010,1030) - Patient''s Weight</li>     <li>(0010,1090) - Medical Record Locator</li>     <li>(0010,2160) - Ethnic Group</li>     <li>(0010,2180) - Occupation</li>     <li>(0010,21B0) - Additional Patient''s History</li>     <li>(0010,4000) - Patient Comments</li>     <li>(0018,1000) - Device Serial Number</li>     <li>(0018,1030) - Protocol Name</li>     <li>(0020,000D) - Study Instance UID</li>     <li>(0020,000E) - Series Instance UID</li>     <li>(0020,0010) - Study ID</li>     <li>(0020,0052) - Frame of Reference UID</li>     <li>(0020,0200) - Synchronization Frame of Reference UID</li>     <li>(0020,4000) - Image Comments</li>     <li>(0040,0275) - Request Attributes Sequence</li>     <li>(0040,A124) - UID</li>     <li>(0040,A730) - Content Sequence</li>     <li>(0088,0140) - Storage Media File-set UID</li>     <li>(3006,0024) - Reference Frame of Reference UID</li>     <li>(3006,00C2) - Related Frame of Reference UID</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (501, 1, 0, '2009-11-24 10:53:18.923', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Acquisition Modality actors in the REM profile perform ONE instance of this test. <b>This     should be done on the first day of the Connectathon. </b> Note that the sample SRs could be    uploaded into kudu before arriving at the Connectathon.</p> <p>Your testing partners will benefit from testing with a wide variety of Dose objects.    For example, if your system is able to generate a Dose object at the end of both an irradiation event and also at the end of a procedure step (containing multiple irradiation events), you can submit multiple samples.</p> <p>The Modality system should arrive at the Connectathon with sample SRs for this test     <b>PRE-OBTAINED</b> and <b>PRE-LOADED</b> or you will waste a great deal of time! </p> </p><H3>Description</H3><p>This test gathers your sample SRs in a common repository so they are accessible by Image    Manager, Dose Information Reporter and Dose Information Consumer systems. SRs and screen shots    showing the SR content (if you can create this) are captured in gazelle under:    Connectathon-->Connectathon...Objects. You will upload sample DICOM Radiation Dose SR objects as    identified in the Special Instructions section. You will also enter a description of your    objects, including what type of modality you are, and the DICOM Template ID (TID 10001 or 10011)    used in your SR. Finally, please upload screen captures, if possible, so that we can use it for    comparison when your peers will store and render your objects.</p><p>Modalities could also find time to test directly sending their objects to their peer   actors.</p><H3>Evaluation</H3><p>There is no formal evaluation for this test. The purpose is to get sample objects into gazelle    for others'' testing.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (502, 1, 0, '2009-11-24 10:53:18.925', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p> </p><H3>Description</H3><p>In RFD, there are two mechanisms defined to get a form from a Form Filler to a Form Archiver:</p><ul>     <li>The submission action is pre-encoded in the &lt;xforms:submission&gt; element of the     retrieved XForm, which points to the Form Archiver.&nbsp; It may be necessary to modify the     value of this attribute to enable testing with different Form Archiver systems.</li>     <li>The Form Filler supports the Archive Form options and specifies the desired Form Archiver     destination by encoding the archiveURL parameter in its Retrieve Form request.&nbsp; When     the Form Manager receives this request, it returns an XForm that will perform the Archive Form     transaction upon submission by the Form Filler.</li> </ul><p>In this test, a Form Filler retrieves a form from the Form Manager using HTTP-GET.&nbsp;    Form Filler knows the formID of a form with the &lt;xforms:submission&gt; element encoded    with the Form Archiver under test.&nbsp; It fills out the form and submits it to the Form    Archiver.</p><p>Form Archivers must demonstrate that they can archive form instance data (ie the xml document)    for *all* available forms (ie with all of the different formIDs) used at the Connectathon.</p><H3>Evaluation</H3><p>The ability to retrieve and archive a form will be demonstrated &lsquo;real-time&rsquo;    for the Connectathon Monitor.</p><p>On the <strong>Form Filler</strong>, in all scenarios, verify: </p><ul>     <li>Is able to complete all available fields on the form.</li>     <li>A single submit action by the Form Filler user results in submission of the form to both the     Form Receiver and Form Archiver (no extra manual step required).</li> </ul><p>If the <strong>Form Filler</strong> supports the <strong>Archive Form option:</strong> </p><ul>     <li>The <strong>Form Filler </strong>will show the Connectathon Monitor how it selects the Form     Archiver location in is application.&nbsp; Eg, this may be a configuration parameter or an     item on the Form Filler user interface.</li>     <li>The <strong>Form Manager</strong> encodes the archive destination specified by the Form     Filler properly in the XForm returned.&nbsp; This should require no manual intervention on     the Form Manager.</li>     <li>All actors will demonstrate that changing the archive destination specified by the Form     Filler automatically results in the form being submitted to the correct archive    destination.</li> </ul><p>On the <strong>Form Receiver</strong>, verify: </p><ul>     <li>The completed form was received on the Form Receiver</li> </ul><p>The <strong>Form Archiver</strong> will demonstrate for the Connectathon Monitor that all forms    (the entire xml documents) are archived as part of the Form Archiver application, ie it is not    sufficient for the Form Archiver to merely respond to the Form Filler with an HTTP response code    of 200 (OK); the forms must be saved by the application.</p><p>The Connectathon Monitor will observe that the saved forms contain all the data as entered by    the Form Filler.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (503, 1, 0, '2009-11-24 10:53:18.929', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Actors which support the SOAP Transport option perform this test.</p> </p><H3>Description</H3><p>Systems perform the steps and evaluation in <strong>RFD_Archive_Form</strong> using SOAP transport    rather than HTTP.&nbsp; &nbsp;&nbsp;</p><p>In RFD, there are two mechanisms defined to get a form from a Form Filler to a Form Archiver:</p><ul>     <li>The submission action is pre-encoded in the &lt;xforms:submission&gt; element of the     retrieved XForm, which points to the Form Archiver.&nbsp; It may be necessary to modify the     value of this attribute to enable testing with different Form Archiver systems.</li>     <li>The Form Filler supports the Archive Form options and specifies the desired Form Archiver     destination by encoding the archiveURL parameter in its Retrieve Form request.&nbsp; When     the Form Manager receives this request, it returns an XForm that will perform the Archive Form     transaction upon submission by the Form Filler.</li> </ul><p>In this test, a Form Filler retrieves a form from the Form Manager using SOAP.&nbsp;    Form Filler knows the formID of a form with the &lt;xforms:submission&gt; element encoded    with the Form Archiver under test.&nbsp; It fills out the form and submits it to the Form    Archiver.</p><p>Form Archivers must demonstrate that they can archive form instance data (ie the xml document)    for *all* available forms (ie with all of the different formIDs) used at the Connectathon.</p><H3>Evaluation</H3><p>The ability to retrieve and archive a form will be demonstrated &lsquo;real-time&rsquo;    for the Connectathon Monitor.</p><p>On the <strong>Form Filler</strong>, in all scenarios, verify: </p><ul>     <li>Is able to complete all available fields on the form.</li>     <li>A single submit action by the Form Filler user results in submission of the form to both the     Form Receiver and Form Archiver (no extra manual step required).</li> </ul><p>If the <strong>Form Filler</strong> supports the <strong>Archive Form option:</strong> </p><ul>     <li>The <strong>Form Filler </strong>will show the Connectathon Monitor how it selects the Form     Archiver location in is application.&nbsp; Eg, this may be a configuration parameter or an     item on the Form Filler user interface.</li>     <li>The <strong>Form Manager</strong> encodes the archive destination specified by the Form     Filler properly in the XForm returned.&nbsp; This should require no manual intervention on     the Form Manager.</li>     <li>All actors will demonstrate that changing the archive destination specified by the Form     Filler automatically results in the form being submitted to the correct archive     destination.</li> </ul><p>On the <strong>Form Receiver</strong>, verify: </p><ul>     <li>The completed form was received on the Form Receiver</li> </ul><p>The <strong>Form Archiver</strong> will demonstrate for the Connectathon Monitor that all forms    (the entire xml documents) are archived as part of the Form Archiver application.</p><p>The Connectathon Monitor will observe that the saved forms contain all the data as entered by    the Form Filler.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (504, 1, 0, '2009-11-24 10:53:18.932', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Form Fillers which support the Data Clarifications option are required to run this test.</p> </p><H3>Description</H3>  <p>The purpose of this test is to the ability of a Form Filler to retrieve clarifications, based on an orgID, from a Form Manager and to submit updates for data that have been previously submitted.</p>  <H3>Evaluation</H3> <p>The Connectathon monitor should observe these transactions  real-time.</p> <p>The ability to test and evaluate the Data Clarifications functionality  is highly dependent on the contents of the forms, what data are submitted by the  Form Filler in the first submission, what triggers exist on the Form Manager to  recognize a situation where data clarification is needed, and the relationship  between the Form Manager and the Form Filler. ''</p> <p>The Connectathon Monitor will use his/her judgment to  evaluate whether the Form Manager has a reasonable implementation. ''</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (505, 1, 0, '2009-11-24 10:53:18.935', 'epoiseau', '<h3>Description</h3> <p>The purpose of this test is to demonstrate that a Form Filler can submit a form to a Form Archiver for long-term storage. Evaluation of the test will be by entering data into the form, submitting the form, by visual inspection of the data within the Form Archiver and by examination of log files.</p>  <h3>Evaluation</h3> <ol>  <li>Inspect the form displayed</li>  <li>Inspect log file generated by the Form Filler</li>  <li>Inspect log file generated by the Form Archiver</li> </ol>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (506, 1, 0, '2009-11-24 10:53:18.936', 'epoiseau', '<h3>Description</h3> <p>The purpose of this test is to demonstrate that a Form Filler can request and receive a form from a Form Manager for display using the RFD profile. Evaluation of the test will be by visual inspection of the form displayed and by examination of log files.</p>  <h3>Evaluation</h3> <ol>  <li>Inspect the form displayed</li>  <li>Inspect log file generated by the Form Manager</li>  <li>Inspect log file generated by the Form Filler.</li> </ol>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (507, 1, 0, '2009-11-24 10:53:18.939', 'epoiseau', '<h3>Description</h3> The purpose of this test is to demonstrate that a Form Filler can submit a form to a Form Receiver for processing. Evaluation of the test will be by entering data into the form, submitting the forn, by visual inspection of the data within the Form Manager and by examination of log files.  <h3>Evaluation</h3> <ol>  <li>Inspect the form displayed</li>  <li>Inspect log file generated by the Form Filler.</li>  <li>Inspect log file generated by the Form Receiver</li> </ol> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (508, 1, 0, '2009-11-24 10:53:18.942', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Form Managers run one instance of this test. The purpose is to ensure the Form Manager systems    are loaded with a set of known forms used in later tests.</p> </p><H3>Description</H3><p>The following forms will be used in RFD testing and are loaded on the Form Manager in this    test.</p><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td valign="top">      <strong>Scenario</strong>     </td>     <td valign="top">       <p align="center">        <strong>formID</strong>       </p>      </td>     <td valign="top">       <p align="center">        <strong>Description of Form</strong>       </p>      </td>     <td valign="top">       <p align="center">        <strong>Form Manager</strong>       </p>      </td>     </tr>     <tr>      <td valign="top">       <p class="style1">Drug Safety</p>      </td>     <td valign="top">       <p class="style1">TBD1, TBD2</p>      </td>     <td valign="top">       <p>&nbsp;</p>      </td>     <td valign="top">       <p>&nbsp;</p>      </td>     </tr>     <tr>      <td valign="top">       <p class="style1">Clinical Trial</p>      </td>     <td valign="top">       <p class="style1">TBD3, TBD4</p>      </td>     <td valign="top">       <p>&nbsp;</p>      </td>     <td valign="top">       <p>&nbsp;</p>      </td>     </tr>     <tr>      <td valign="top">       <p class="style1">Registry</p>      </td>     <td valign="top">       <p class="style1">TBD</p>      </td>     <td valign="top">       <p>&nbsp;</p>      </td>     <td valign="top">       <p>&nbsp;</p>      </td>     </tr>     <tr>      <td valign="top">       <p class="style1">Other</p>      </td>     <td valign="top">       <p>        <span class="style1"></span>       </p>      </td>     <td valign="top">       <p>&nbsp;</p>      </td>     <td valign="top">       <p>&nbsp;</p>      </td>     </tr> </table><H3>Evaluation</H3><p>There is no formal evaluation for this test.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (509, 1, 0, '2009-11-24 10:53:18.945', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Form Fillers must demonstrate that they can retrieve and enter data for all available forms    used at the Connectathon.</p> </p><H3>Description</H3><p>Form Filler retrieves a form from the Form Manager using HTTP-GET. Form Filler knows the    formID. Form submission is not tested in this test.</p><H3>Evaluation</H3><p>The ability to retrieve a form will be demonstrated &lsquo;real-time&rsquo; for the    Connectathon Monitor.</p><p>On the <strong>Form Filler</strong>, verify: </p><ul type="disc">     <li>The requested form is successfully retrieved and displayed on the Form Manager.&nbsp;     Form Filler is able to enter data into all available fields on the form.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (510, 1, 0, '2009-11-24 10:53:18.946', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Actors which support the SOAP Transport option perform this test.</p> </p><H3>Description</H3><p>Systems perform the steps and evaluation in <strong>RFD_Retrieve_Form</strong> using SOAP transport    rather than HTTP.&nbsp; &nbsp;&nbsp;</p><p>Form Filler retrieves a form from the Form Manager. Form Filler knows the    formID. Form submission is not tested in this test.</p><H3>Evaluation</H3><p>The ability to retrieve a form will be demonstrated &lsquo;real-time&rsquo; for the    Connectathon Monitor.</p><p>On the <strong>Form Filler</strong>, verify: </p><ul type="disc">     <li>The requested form is successfully retrieved and displayed on the Form Manager.&nbsp;     Form Filler is able to enter data into all available fields on the form.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (511, 1, 0, '2009-11-24 10:53:18.948', 'epoiseau', '<H3>Special Instructions</H3><p> <p>The Form Manager is marked as an optional actor because it is needed to help with the test, but    its actions are not evaluated in this test (ie a Form Manager is not required to pass 3 instances    of this test).</p> </p><H3>Description</H3><p>Form Filler retrieves a form from the Form Manager using HTTP-GET. Form Filler knows the    formID. RFD_Submit_Form tests submission of the form from the Form Filler to the Form Receiver    (in some cases, the Form Receiver will be grouped with another RFD actor).</p><H3>Evaluation</H3><p>The ability to submit/receive a form will be demonstrated &lsquo;real-time&rsquo; for the    Connectathon Monitor.</p><p>On the <strong>Form Receiver</strong>, verify: </p><ul type="disc">     <li>The completed form was received on the Form Receiver</li> </ul><p>The <strong>Form Receiver</strong> will demonstrate for the Connectathon Monitor that both    forms (the entire xml documents) are received on the Form Receiver application, ie although these    is no behavior mandated in the Technical Framework, it is not sufficient for the Form Receiver to    merely respond to the Form Filler with an HTTP response code of 200 (OK) and throw the contents    away; the forms should be handled/processed in some way by the Form Receiver.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (512, 1, 0, '2009-11-24 10:53:18.952', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Actors which support the SOAP Transport option perform this test.</p> </p><H3>Description</H3><p>Systems perform the steps and evaluation in <strong>RFD_Submit_Form</strong> using SOAP transport    rather than HTTP.&nbsp; &nbsp;&nbsp;</p><p>Form Filler retrieves a form from the Form Manager. Form Filler knows the    formID. RFD_Submit_Form tests submission of the form from the Form Filler to the Form Receiver    (in some cases, the Form Receiver will be grouped with another RFD actor).</p><H3>Evaluation</H3><p>The ability to submit/receive a form will be demonstrated &lsquo;real-time&rsquo; for    the Connectathon Monitor.</p><p>On the <strong>Form Receiver</strong>, verify: </p><ul type="disc">     <li>The completed form was received on the Form Receiver</li> </ul><p>The <strong>Form Receiver</strong> will demonstrate for the Connectathon Monitor that both    forms (the entire xml documents) are received on the Form Receiver application, ie although these    is no behavior mandated in the Technical Framework, it is not sufficient for the Form Receiver to    merely respond to the Form Filler''s request and throw the contents    away; the forms should be handled/processed in some way by the Form Receiver.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (513, 1, 0, '2009-11-24 10:53:18.955', 'epoiseau', '<H3>Special Instructions</H3> None. <H3>Description</H3> <p>A Display actor should provide a reasonable user interface to perform the queries defined in the RID profile. Specifically, to perform summary queries, the Display actor should allow the user a simple method to enter the patient ID and assigning authority. This does not include typing the RID query syntax in the address bar of your favorite web browser.</p>  <p>In this test, the Connectathon monitor will observe the Display performing queries and will determine if the Display supports a reasonable user interface or larger integrated system.</p>  <p>Examples of items that will cause the Display actor to fail this test: <ul> <li>User needs to type information in the address bar of a web browser</li> <li>Participant configures a web page by hand with the query information and uses that web page to show the query links</li> <li>Display requires user to use command line tools to retrieve a summary or document for later display</li> </ul> </p>  <p>Assigning authority in the patient ID could be a configuration option. That is, it may be something that your system configures statically, or it may be set for each query. Patient ID could be a field you enter in your system or could be taken from a pick list of patients.</p>  <H3>Evaluation</H3> Connectathon monitor is looking for an integrated system that has value added over a free or commercial web browser. Display actor implementation is expected to have performed some work that results in a reasonable product that one would market.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (514, 1, 0, '2009-11-24 10:53:18.956', 'epoiseau', '<H3>Special Instructions</H3><p></p> <p>Displays should use the  Connectathon Images/CDs/Objects page to find data on Information Source actors.  See:  <em><a href=system_con_object.php>Objects Information</a></em>.  <H3>Description</H3> <p>The RID_ListRequest test is used by the Display Actor to request a list of items from an Information Source. The Connectathon monitor will observe the Display actor requesting each of the List Request types listed in the ITI Technical Framework. Not all Information Sources will support all types. </p> <p>The test will use one or more patients known to the Information Source, possibly those loaded during the test RIDLoadInformationSource.</p> <p>Before the test starts the Display actor should be aware of one or more patients in Information Source with reports.</p>  <H3>Evaluation</H3> <p>The Connectathon monitor will observe the query and result for each list type.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (515, 1, 0, '2009-11-24 10:53:18.958', 'epoiseau', '<H3>Special Instructions</H3> <p>None</p>  <H3>Description</H3> <p>The <strong>RID_LoadInformationSource</strong> test is an initialization step for the Information Source to load initial data into its system. The Information Source can use the Patient Names and Patient IDs listed in this test or may choose other names and identifiers. The goal of the test is to have a known list of patients that are readily available for testing with Display actors.</p> <p>In order to make the Display actor aware of the information available on your system please fill out the <a href="system_con_object.php?highlight=8_3">Kudu Objects Information</a> page</p> <p>There is no formal evaluation required. Tell the Connectathon monitor you have completed this test when your system is properly loaded. You may find that you have to load new data later; do not report updated information.</p> <p>The suggested patient list is:</p>  <ul> <li>Michael Abell - 4030004</li> <li>Amy Johnson - 4020006</li> <li>Alexander Washington - 3012345</li> </ul>  <H3>Evaluation</H3> <p>The Connectathon monitor will observe the query and result for each list type.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (516, 1, 0, '2009-11-24 10:53:18.96', 'epoiseau', '<H3>Special Instructions</H3><p></p>  <p>Displays should use the  Connectathon Images/CDs/Objects page to find data on Information Source actors.  See:  <em><a href=system_con_object.php>Objects Information</a>.  <H3>Description</H3><p>The RID_RetrieveDocument test is used by the Display Actor to retrieve a specific document from an Information Source. The Connectathon monitor will observe the Display actor requesting the document and the display of the document.</p><p>The Technical Framework does not indicate how the Display Actor obtains the document reference. During the connectathon we will use the Objects Information page, for communicating the stored information. There will be some side work to accomplish this. Display Actors are not allowed to type in the identifier of the document. This is not an integrated system.</p><H3>Evaluation</H3><p>The Connectathon monitor will observe the query and result. The monitor is looking for an integrated system that allows the user to obtain the document ID in some automated fashion and use that to retrieve the document. For example, one could obtain the identifier using the XDS profile. We will not accept a Display Actor where the user types in the identifier.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (517, 1, 0, '2009-11-24 10:53:18.963', 'epoiseau', '<H3>Special Instructions</H3><p></p>  <p>Displays should use the  Connectathon Images/CDs/Objects page to find data on Information Source actors.  See:  <em><a href=system_con_object.php>Objects Information</a></em>.  <H3>Description</H3><p>The RID_SummaryRequest test is used by the Display Actor to request summary reports from an Information Source. The Connectathon monitor will observe the Display actor requesting each of the Summary Request types listed in the ITI Technical Framework. Not all Information Sources will support all summary types. The test will use one or more patients known to the Information Source, possibly those loaded during RID_LoadInformationSource.</p><H3>Evaluation</H3><p>For evaluation, the Connectathon monitor will observe the query and result for each summary type.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (518, 1, 0, '2009-11-24 10:53:18.965', 'epoiseau', '<h3>Special Instructions</h3> None.  <H3>Description</H3> <p>The Display Actor requests summary information for a patient whose identifier is not known to the Information Source actor. For example, try Patient ID 555. The Information Source is supposed to respond with an error code of 404.</p>  <H3>Evaluation</H3> <p>For evaluation, the Connectathon monitor will observe the results on the Display Actor. It will probably render a browser error with the error code 404 and nothing IHE specific. The Framework does not require the Display Actor to intercept the error code and format nicely for the user.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (519, 1, 0, '2009-11-24 10:53:18.967', 'epoiseau', '<H3>Special Instructions</H3> None.  <H3>Description</H3> <p>Report Creators send SR objects to Report Readers (possibly through a Report Repository). Report Reader and renders report. Images that are referenced should be retrieved and rendered. Report actors should attempt the following cases. Some may not apply because the actors may not support that feature.</p>  <ol>  <li>Simple text report with no image references.</li>  <li>Simple text report with single image reference.</li>  <li>Simple text report with several image references</li>  <li>Numeric report </li>  <li>Report amended by Report Creator </li>  </ol> <h3>Evaluation</h3>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (520, 1, 0, '2009-11-24 10:53:18.968', 'epoiseau', '<H3>Special Instructions</H3> None.  <H3>Description</H3>  <p>The Report Manager should export two final reports to the Enterprise Report Repository. One report should have no image references; the second report should have at least one image reference. </p>  <H3>Evaluation</H3>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (521, 1, 0, '2009-11-24 10:53:18.971', 'epoiseau', '<H3>Special Instructions</H3> None.  <H3>Description</H3>  <p>This test is mainly used for testing the storage between the report manager and the report repository actor.</p> This test makes sense if the report manager  and the report repository are not grouped on the same system.</p>  <H3>Evaluation</H3>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (522, 1, 0, '2009-11-24 10:53:18.974', 'epoiseau', '<H3>Special Instructions</H3> None.  <H3>Description</H3>  <p>Report Manager modifies and sends SR objects to Report Readers (possibly through a Report Repository). Report Reader and renders report. Images that are referenced should be retrieved and rendered. Report actors should attempt the following cases. Some may not apply because the actors may not support that feature.</p>  <ol>  <li>Simple text report with no image references.</li>  <li>Simple text report with single image reference.</li>  <li>Simple text report with several image references</li>  <li>Numeric report </li>  </ol>  <H3>Evaluation</H3> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (523, 1, 0, '2009-11-24 10:53:18.976', 'epoiseau', '<H3>Special Instructions</H3> None.  <H3>Description</H3> <p>Report Creators send SR objects to Report Manager. Report actors should attempt the following cases. Some may not apply because the actors may not support that feature.</p>  <ol>  <li>Simple text report with no image references.</li>  <li>Simple text report with single image reference.</li>  <li>Simple text report with several image references</li>  <li>Numeric report </li>  </ol>  <h3>Evaluation</h3> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (524, 1, 0, '2009-11-24 10:53:18.977', 'epoiseau', '<H3>Special Instructions</H3>
 <p>Please read Rad 2:4.11.4.1.2</p>
 
 <H3>Test Description</H3>
 <p>This is a test of Radiology Transaction 11. Specifically, the Report Manager is required to make a hierachical query
 at the Instance Level to determine the availability of images (see Rad 2:4.11.4.1.2).</p>
 
 <p>You will need to draft a modality or evidence creator to send images to the Image Manager and MPPS data to the
 Report Manager. After the images and MPPS data have been sent, the Report Manager shall query the Image Manager
 using Radiology Transaction 11.</p>
 
 <H3>Evaluation</H3>
 <p>The Report Manager and Image Manager must demonstrate this query to a monitor. This may involve examining
 logs or database entries. A hierarchical query must be demonstrated, or the test fails.</p>
 
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (525, 1, 0, '2009-11-24 10:53:18.979', 'epoiseau', '<H3>Special Instructions</H3> This test contains optional steps. You need at least a Report Creator and a Report Manager to run this test.   <H3>Description</H3> <ul> <li>The Report Manager (RM) schedules an interpretation workitem. </li> <li>The Report Creator (RC) queries for this workitem. </li> <li>The RM informs the RC about a workitem that is already claimed by another RC.  should release the claim then requery and reclaim. </p> <li>Optionally, a double claim may be attempted with the aid of a second RC.  </li> <li>The RC then performs the workflow through completion. Results may be stored on a friendly RRP</li> <li>Optionally, an PPSM linked to an OF or IM that accepts Workstatus Update (RAD-42) messages may be included. </li> </ul> <H3>Evaluation</H3> For the evaluation, the monitor will check that a claimed workitem can not be claimed a second time.  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (526, 1, 0, '2009-11-24 10:53:18.982', 'epoiseau', '<h3>Description</h3>
 
 <p>The goal of the Softcopy calibration tests is to demonstrate that the participant''''s image display output conforms to the GSDF.  Although the participant may use whatever procedure is appropriate to their product for calibrating the display, the managers will evaluate whether or not the output conforms to the GSDF by following the procedure outlined in Section 2.2  of <i>Display Consistency Test Plan for Image Displays</i>.  </p>
 
 <p>You will need to bring:
 <ol>
 <li>the means to calibrate your display, including a photometer,</li>
 <li>Image Display test cases, (available from web site),</li>
 <li>the means to provide the test cases to the Image Display,</li>
 <li><a href="/data/download/gsdf_lum_20000630.xls" alt=gsdf_lum.xls>gsdf_lum.xls</a>, (Excel spreadsheet),</li>
 <li>the means to run macros in spreadsheet (Windows 98/NT)</li>
 </ol>
 </p>
 
 <p>
 It is recommended that participants calibrate their displays on the first day of the connectathon.  Although the evaluation will be done after the ''''starting bell'''' of the connectathon, participants can do their initial calibration during system setup.
 </p>
 
 <h3>Evaluation</h3>
 
 <p>
 It is recommended that participants calibrate their displays on the first day of the connectathon.  Although the evaluation will be done after the ''''starting bell'''' of the connectathon, participants can do their initial calibration during system setup.
 </p>
 
 <h3>Evaluation</h3>
 
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (527, 1, 0, '2009-11-24 10:53:18.984', 'epoiseau', 'Not yet defined');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (528, 1, 0, '2009-11-24 10:53:18.985', 'epoiseau', '<H3>Special Instructions</H3> <p> <p>Actors perform ONE instance of this test. <strong>This should be done on the first day of the Connectathon</strong>.</p> <p>The ED/Evidence Creator or REM/Modality or SINR/ Report Creator system should arrive at the Connectathon with SRs for this test <strong>PRE-OBTAINED</strong> and <strong>PRE-LOADED</strong> or you will waste a great deal of time! </p> </p> <H3>Description</H3> <p>All systems capable of creating SRs in the Radiology REM, ED and SINR profiles should store SRs of all SOP classes and SR templates it is capable of generating to the Connectathon CENTRAL_ARCHIVE. This will enable Image Manager and Image Display actors to access these images for their testing.</p> <p>You must enter a description of your study in the <em><a href=system_con_object.php?selected=create_object>Objects Information</a></em>.  Please upload there a screen capture of the object so that we can use it for comparison when your peers will render your SRs.</p> <p>You could also find time to test directly sending their SRs to Image Manager actors.</p> <H3>Evaluation</H3><p>In order to validate the test, the connectathon monitor will check:</p> <ul> <li>that the objects are stored on the Central Archive,</li> <li>that there is a corresponding entry in the <em><a href=system_con_object.php?selected=create_object>Objects Information</a></em>  section of the kudu webtool, and </li> <li>that there is a screen capture of the objects uploaded in the <em><a href=system_con_object.php?selected=create_object>Objects Information</a></em> section of the kudu webtool, and</li> <li>that the printed output adequately describes the displayed image.</li> </ul> <p>Note that samples stored to the Central Archive are checked by a DICOM validator.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (529, 1, 0, '2009-11-24 10:53:18.988', 'epoiseau', '<H3>Special Instructions</H3><p> <p>When entering results for this test in Kudu, the Image Display should initiate an instance of this test <strong>when the results are complete</strong>.  This allows you to also give credit to the Acquisition Modality or Evidence Creator which supplied the waveforms/images/reports without locking that system out of other testing while the Image Display is working on the rendering.</p> <p>The Image Display may use the Connectathon CENTRAL_ARCHIVE as a source of different vendors'' waveforms, images and reports</p> <p>Image Display please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find out what your peers have uploaded on the central archive </p> </p>  <H3>Description</H3> <p>The test verifies that the Image Display can retrieve and display a variety of waveforms, image sets, DICOM SRs and Procedure Logs from various vendors.</p>  <H3>Evaluation</H3> <p>On the<strong> Image Display </strong> </p> <ul> <li>verify that waveforms and images from each Modality vendor can be accurately stored and displayed.  The Connectathon Monitor may ask a representative of the originating Modality to verify the accuracy of the rendering of its study on the Image Display.</li> <li>For waveform objects, verify: <ul> <li>Each waveform is labeled with the lead name.</li> <li>The following values must be displayed: <ul> <li>Voltage scale</li> <li>Time scale</li> <li>Frequency content</li> <li>Acquisition time</li> <li>Originality  eg.  Original (rhythm) or derived (representative beat)</li> <li>Protocol name</li> <li>Protocol stage</li> <li>Patient state</li> </ul> </li> </ul> </li> <li>Verify the ability to display DICOM Encapsulated PDF</li> <li>The Connectathon Monitor should observe its ability to interpret/render the objects (derived images, SRs, procedure logs, or measurements, ie Evidence Documents) from the Evidence Creator actors. The Connectathon Monitor may ask a representative of the originating Evidence Creator to verify the accuracy of the rendering of its data, or observe the originals at the Evidence Creator and spot-check that they are displayed correctly and completely. </li> <li>Verify the ability to display the value of <b>Series Description</b> for each series displayed (RAD-TF:4.16.4.2.3)</li> <li>Accuracy of the NM display is not verified here. It is verified within the scope of the Nuclear Medicine Image Profile Connectathon tests.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (530, 1, 0, '2009-11-24 10:53:18.991', 'epoiseau', '<H3>Special Instructions</H3> The Image Manager/Archive receive images from the ECG, Stress echo and NM-Cardiac modalities before this test can be run with the Image Display actor. <H3>Description</H3> The test verifies the ability of the Image Display and Image Manager actors for the [RAD-14] and [CARD-4] transactions. <H3>Evaluation</H3> <p><i> Evaluators and participants should note that this section contains all query keys documented in the Technical Framework.  At the North American Connectathon in Chicago, many Display vendors were surprised that these are requirements.  We are *not* failing systems this year if you do not support everything below.  However, the Connectathon Monitor will verify that you have a reasonable implementation that allows you to query the Image Manager using different parameters. </i></p> On the <b>Image Display </b> <ul> <li>The Connectathon Monitor will ask the operator to demonstrate its support for the DICOM Study Root Q/R Information Model and Hierarchical Search. <p>It will demonstrate on its User Interface the ability to offer its user the following attributes as selection criteria (ie  these required query keys for the Image Displays SCU (RAD TF-2 Table 4.14-1). Query the Image Manager for combinations of: <p> <p><b>STUDY LEVEL</b> Query Keys:</p> <ul> <li>Study Date (0008,0020) <li>Study Time (0008,0030) <li>Accession Number (0008,0050)  <li>Patient Name (0010,0010) <li>Study ID (0020,0010)  <li>Study Instance UID (0020,000D) <li>Modalities in Study (0008,0061) <li>Referring Physician''s Name (0008,0090) </ul> <p><b>SERIES LEVEL</b> Query Keys: <ul> <li>Modality (0008,0020) <li>Series Number (0020,0011)  <li>Series Instance UID (0020,000E) <li>Requested Procedure ID (0040,1001)  <li>Scheduled Procedure Step ID (0040,0009)   <li>PPS Start Date (0040,0244)  <li>PPS Start Time (0040,0245) </ul> <p><b>IMAGE LEVEL </b>Query Keys:</p> <ul> <li>Instance Number (0020,0013)  <li>SOP Instance UID (0008,0016) </ul> <p> </p> <li>Verify the ability to retrieve by study, by series and by image. <li>Verify that studies are fully retrieved.  (Correct rendering of the images is verified in a different test -- STRESS_DISPLAY). </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (531, 1, 0, '2009-11-24 10:53:18.993', 'epoiseau', '<H3>Special Instructions</H3> <b>This test should be run on the 1st or 2nd day of the Connectathon to enable Image Displays to do a follow-up test to Q/R these images and evidence objects.</b> <H3>Description</H3> The purpose of this test is to verify that an Image Manager can accept and store all real world vendor images and evidence objects which are available.  Q/R is tested in another test. <H3>Evaluation</H3> Verify that all images and evidence objects from all Acquisition Modality and Evidence Creator actors in the STRESS profile are received at IM under test. Verify the total number of SOP instances stored and total number of studies stored. Verify that the objects are stored as full-fidelity objects (ie., no DICOM data elements are deleted). <p> The ECHOCARDIOGRAPHY option is required; Image Managers must support all of the following SOP classes (CARD-TF-2:4.2.2):  </p> <ul> <li>1.2.840.10008.5.1.4.1.1.7 Secondary Capture Image Storage  <li>1.2.840.10008.5.1.4.1.1.6.1 Ultrasound Image Storage  <li>1.2.840.10008.5.1.4.1.1.3.1 Ultrasound Multi-frame Image Storage  <li>1.2.840.10008.5.1.4.1.1.88.59 Key Object Selection  <li>1.2.840.10008.5.1.4.1.1.88.11 Basic Text SR  <li>1.2.840.10008.5.1.4.1.1.88.22 Enhanced SR  <li>1.2.840.10008.5.1.4.1.1.88.33 Comprehensive SR  </ul> The STRESS ECG option is required; Image Managers must support all of the following SOP classes (CARD-TF-2:4.2.6):  <ul> <li>1.2.840.10008.5.1.4.1.1.9.1 12-Lead ECG Waveform Storage <li>1.2.840.10008.5.1.4.1.1.9.2 General ECG Waveform Storage <li>1.2.840.10008.5.1.4.1.1.88.22 Enhanced SR  <li>1.2.840.10008.5.1.4.1.1.88.33 Comprehensive SR  <li>1.2.840.10008.5.1.4.1.1.88.40 Procedure Log Storage  <li>1.2.840.10008.5.1.4.1.1.104.1 Encapsulated PDF </ul> The Nuclear Medicine Option is required; Image Managers must support both RAD-8 Modality Images Stored and RAD-18 Creator Images Stored (for storing NM result screens).');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (532, 1, 0, '2009-11-24 10:53:18.995', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Evidence Creator and Acquisition Modality actors perform ONE instance of this test.  <strong>This should be done on the first day of the Connectathon.</strong> </p> <p>The Modality system should arrive at the Connectathon with images for this test PRE-OBTAINED and PRE-LOADED or you will waste a great deal of time!</p> </p> <H3>Description</H3> <p>All Acquisition Modalities and Evidence Creators participating in the Cardiology profiles must store images of <strong>all SOP classes it is capable of generating</strong> to the Connectathon CENTRAL_ARCHIVE. This will enable Image Manager and Image Display actors to access these objects for their testing.</p> <p>You must enter a description of your study in the <em><a href=system_con_object.php?selected=create_object>Objects Information</a></em>.  Please upload there a screen capture of the object so that we can use it for comparison when your peers will render your images.</p> <p>Modalities and Evidence Creators could also find time to test directly sending their images and evidence objects to Image Manager actors. </p>  <H3>Evaluation</H3> <p>In order to validate the test, the connectathon monitor will check:</p> <ul> <li>that the objects are stored on the Central Archive,</li> <li>that there is a corresponding entry in the <em><a href=system_con_object.php?selected=create_object>Objects Information</a></em>  section of the kudu webtool, and </li> <li>that there is a screen capture of the objects uploaded in the <em><a href=system_con_object.php?selected=create_object>Objects Information</a></em> section of the kudu webtool, and</li> <li>that the printed output adequately describes the displayed image.</li> </ul> <p>Note that samples stored to the Central Archive are checked by a DICOM validator.</p> <p>For ECG Modalities, the <b>STRESS ECG option</b> is required; the Connectathon Monitor should access a sample study for the Modality on the CENTRAL_ARCHIVE.</p> <p>View the DICOM header and verify:</p> <ul> <li>The following attributes are required to have valid values:</li> </ul><title>Untitled Document</title><table border="1" cellspacing="0" cellpadding="0">      <tr>        <td width="277" valign="top"> <p> <strong>Attribute Name</strong> </p> </td>       <td width="96" valign="top"> <p align="center"> <strong>Tag</strong> </p> </td>       <td width="102" valign="top"> <p align="center"> <strong>Requirement</strong> </p> </td>      </tr>      <tr>        <td width="277" valign="top"> <p>Performed Procedure Step Description</p> </td>       <td width="96" valign="top"> <p align="center">(0040,0254)</p> </td>       <td width="102" valign="top"> <p align="center">R+</p> </td>      </tr>      <tr>        <td width="277" valign="top"> <p>Protocol Name</p> </td>       <td width="96" valign="top"> <p align="center">(0018,1030)</p> </td>       <td width="102" valign="top"> <p align="center">R+</p> </td>      </tr>      <tr>        <td width="277" valign="top"> <p>Performed Protocol Code Sequence</p> </td>       <td width="96" valign="top"> <p align="center">(0040,0260)</p> </td>       <td width="102" valign="top"> <p align="center">R+</p> </td>      </tr>      <tr>        <td width="277" valign="top"> <p>Acquisition Context Sequence</p> </td>       <td width="96" valign="top"> <p align="center">(0040,0555)</p> </td>       <td width="102" valign="top"> <p align="center">R+</p> </td>      </tr> </table><ul> <li>Performed Protocol Code Sequence (0040,0260) contain codes taken from:</li> </ul><table border="1" cellspacing="0" cellpadding="0"> <tr>      <td width="122" valign="top"> <p>Coding Scheme Designator<br>       (0008,0102) </p> </td>     <td width="122" valign="top"> <p>Code Value<br>       (0008,0100) </p> </td>     <td width="306" valign="top"> <p>Code Meaning <br>       (0008,0104) </p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT </p> </td>     <td width="122" valign="top"> <p align="center">P2-7131C</p> </td>     <td width="306" valign="top"> <p>Balke protocol</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">P2-7131A</p> </td>     <td width="306" valign="top"> <p>Bruce protocol</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">P2-7131D</p> </td>     <td width="306" valign="top"> <p>Ellestad    protocol</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">P2-7131B</p> </td>     <td width="306" valign="top"> <p>Modified Bruce    protocol</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">P2-713A1</p> </td>     <td width="306" valign="top"> <p>Modified    Naughton protocol</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">P2-713A0</p> </td>     <td width="306" valign="top"> <p>Naughton    protocol</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">P2-7131F</p> </td>     <td width="306" valign="top"> <p>Pepper protocol</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">P2-7131E</p> </td>     <td width="306" valign="top"> <p>Ramp protocol</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">P2-31102</p> </td>     <td width="306" valign="top"> <p>Bicycle    Ergometer Stress Test protocol</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">99IHE</p> </td>     <td width="122" valign="top"> <p align="center">PHARMSTRESS</p> </td>     <td width="306" valign="top"> <p>Pharmacologic    Stress protocol</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">99IHE</p> </td>     <td width="122" valign="top"> <p align="center">PERSANTINE</p> </td>     <td width="306" valign="top"> <p>Persantine    Stress protocol</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">99IHE</p> </td>     <td width="122" valign="top"> <p align="center">ADENOSINE</p> </td>     <td width="306" valign="top"> <p>Adenosine    Stress protocol</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">99IHE</p> </td>     <td width="122" valign="top"> <p align="center">DOBUTAMINE</p> </td>     <td width="306" valign="top"> <p>Dobutamine    Stress protocol</p> </td> </tr> </table><ul> <li>Acquisition Context Sequence (0040,0555) contains at least these 2 content items:</li> </ul><table border="0" cellspacing="0" cellpadding="0"> <tr>      <td width="55" valign="top"> <p> <strong>Value Type</strong> </p> </td>     <td width="212" valign="top"> <p> <strong>Concept Code</strong> </p> </td>     <td width="238" valign="top"> <p> <strong>Value</strong> </p> </td> </tr> <tr>      <td width="55" valign="top"> <p>CODE</p> </td>     <td width="212" valign="top"> <p>(109054, DCM, Patient State)</p> </td>     <td width="238" valign="top"> <p>See Table    4.2-14</p> </td> </tr> <tr>      <td width="55" valign="top"> <p>NUM</p> </td>     <td width="212" valign="top"> <p>(109055, DCM,    Protocol Stage)</p> </td>     <td width="238" valign="top"> <p>Numeric Value,    Units of Measurement is ({stage}, UCUM, stage)</p> </td> </tr> </table><ul> <li>Codes in the Acquisition Context Sequence (0040,0555) are taken from: </li> </ul><table border="1" cellspacing="0" cellpadding="0"> <tr>      <td width="122" valign="top"> <p>Coding Scheme Designator       (0008,0102) </p> </td>     <td width="122" valign="top"> <p>Code Value       (0008,0100) </p> </td>     <td width="306" valign="top"> <p>Code Meaning       (0008,0104) </p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">F-01604</p> </td>     <td width="306" valign="top"> <p>Resting state</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">F-01602</p> </td>     <td width="306" valign="top"> <p>Baseline state</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">F-01606</p> </td>     <td width="306" valign="top"> <p>Exercise state</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">F-01608</p> </td>     <td width="306" valign="top"> <p>Post-exercise    state</p> </td> </tr> </table><p>For Echo Modalities, the <b>STRESS ECHO option</b> is required; the Connectathon Monitor should access a sample study for the Modality on the CENTRAL_ARCHIVE.</p> <p>View the DICOM header and verify:</p><ul> <li>The following attributes are required to have valid values:</li> </ul> <table border="1" cellspacing="0" cellpadding="0"> <tr>      <td width="277" valign="top"> <p> <strong>Attribute Name</strong> </p> </td>     <td width="96" valign="top"> <p align="center"> <strong>Tag</strong> </p> </td>     <td width="102" valign="top"> <p align="center"> <strong>Requirement</strong> </p> </td> </tr> <tr>      <td width="277" valign="top"> <p>Performed Procedure Step Description</p> </td>     <td width="96" valign="top"> <p align="center">(0040,0254)</p> </td>     <td width="102" valign="top"> <p align="center">R+</p> </td> </tr> <tr>      <td width="277" valign="top"> <p>Protocol Name</p> </td>     <td width="96" valign="top"> <p align="center">(0018,1030)</p> </td>     <td width="102" valign="top"> <p align="center">R+</p> </td> </tr> <tr>      <td width="277" valign="top"> <p>Performed Protocol Code Sequence</p> </td>     <td width="96" valign="top"> <p align="center">(0040,0260)</p> </td>     <td width="102" valign="top"> <p align="center">R+</p> </td> </tr> <tr>      <td width="277" valign="top"> <p>Number of Stages</p> </td>     <td width="96" valign="top"> <p align="center">(0008,2124)</p> </td>     <td width="102" valign="top"> <p align="center">R+</p> </td> </tr> <tr>      <td width="277" valign="top"> <p>Number of Views in Stage</p> </td>     <td width="96" valign="top"> <p align="center">(0008,212A)</p> </td>     <td width="102" valign="top"> <p align="center">R+</p> </td> </tr> <tr>      <td width="277" valign="top"> <p>Stage Code Sequence</p> </td>     <td width="96" valign="top"> <p align="center">(0040,000A)</p> </td>     <td width="102" valign="top"> <p align="center">R+ <em>(note 2)</em> </p> </td> </tr> <tr>      <td width="277" valign="top"> <p>Stage Number</p> </td>     <td width="96" valign="top"> <p align="center">(0008,2122)</p> </td>     <td width="102" valign="top"> <p align="center">R+</p> </td> </tr> <tr>      <td width="277" valign="top"> <p>View Number</p> </td>     <td width="96" valign="top"> <p align="center">(0008,2128)</p> </td>     <td width="102" valign="top"> <p align="center">R+ <em>(note 1)</em> </p> </td> </tr> <tr>      <td width="277" valign="top"> <p>View Code Sequence</p> </td>     <td width="96" valign="top"> <p align="center">(0054,0220)</p> </td>     <td width="102" valign="top"> <p align="center">R+ <em>(note 2)</em> </p> </td> </tr> </table><p> Notes:  </p><ul> <ul> <li>Note 1: Extra-protocol images (i.e., images not associated with the stress echo exam protocol) shall have the View Number empty or omitted.</li> <li>Note 2: View Code Sequence uses a pre-coordinated code as specified in DICOM change proposal CP 476; this change proposal was formally adopted in January 2005.</li> </ul> </ul><ul> <li>Performed Protocol Code Sequence (0040,0260) contain codes taken from:</li> </ul><table border="1" cellspacing="0" cellpadding="0"> <tr>      <td width="122" valign="top"> <p>Coding Scheme Designator       (0008,0102) </p> </td>     <td width="122" valign="top"> <p>Code Value       (0008,0100) </p> </td>     <td width="306" valign="top"> <p>Code Meaning       (0008,0104) </p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT </p> </td>     <td width="122" valign="top"> <p align="center">P5-B3050 </p> </td>     <td width="306" valign="top"> <p>Exercise stress    echocardiography </p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">P5-B3051</p> </td>     <td width="306" valign="top"> <p>Maximal stress    echocardiography</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">P5-B3052</p> </td>     <td width="306" valign="top"> <p>Submaximal    stress echocardiography</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">P5-B3053</p> </td>     <td width="306" valign="top"> <p>Treadmill    exercise stress echocardiography</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">P5-B3054</p> </td>     <td width="306" valign="top"> <p>Bruce treadmill    stress echocardiography</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">P5-B3055</p> </td>     <td width="306" valign="top"> <p>Modified Bruce    treadmill stress echocardiography</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">P5-B3056</p> </td>     <td width="306" valign="top"> <p>Naughton    treadmill stress echocardiography</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">P5-B3058</p> </td>     <td width="306" valign="top"> <p>Bicycle    exercise stress echocardiography</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">P5-B3060</p> </td>     <td width="306" valign="top"> <p>Echocardiography    with administered drug stress</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">P5-B3061</p> </td>     <td width="306" valign="top"> <p>Dobutamine    stress echocardiography</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">P5-B3062</p> </td>     <td width="306" valign="top"> <p>High dose    dobutamine stress echocardiography</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">P5-B3063</p> </td>     <td width="306" valign="top"> <p>Low dose    dobutamine stress echocardiography</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">P5-B3065</p> </td>     <td width="306" valign="top"> <p>Arbutamine    stress echocardiography</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="122" valign="top"> <p align="center">P5-B3066</p> </td>     <td width="306" valign="top"> <p>Dipyridamole    stress echocardiography</p> </td> </tr> </table><ul> <li> Stage Code Sequence (0040,000A) contains codes taken from:</li> </ul><table border="1" cellspacing="0" cellpadding="0"> <tr>      <td width="122" valign="top"> <p>Coding Scheme Designator </p> </td>     <td width="98" valign="top"> <p>Code Value</p>     </td>     <td width="337" valign="top"> <p>Code Meaning      </p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-A19B</p> </td>     <td width="337" valign="top"> <p>Apical two chamber</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-A19C</p> </td>     <td width="337" valign="top"> <p>Apical    four chamber</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-0395</p> </td>     <td width="337" valign="top"> <p>Apical    long axis</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-0396</p> </td>     <td width="337" valign="top"> <p>Parasternal    long axis</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-0397</p> </td>     <td width="337" valign="top"> <p>Parasternal    short axis</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-0398</p> </td>     <td width="337" valign="top"> <p>Parasternal    short axis at the aortic valve level</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-0399</p> </td>     <td width="337" valign="top"> <p>Parasternal    short axis at the level of the mitral chords</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-039A</p> </td>     <td width="337" valign="top"> <p>Parasternal    short axis at the Mitral Valve level</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-039B</p> </td>     <td width="337" valign="top"> <p>Parasternal    short axis at the Papillary Muscle level</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-039C</p> </td>     <td width="337" valign="top"> <p>Right    Ventricular Inflow Tract View</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-039D</p> </td>     <td width="337" valign="top"> <p>Right    Ventricular Outflow Tract View</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-039E</p> </td>     <td width="337" valign="top"> <p>Subcostal    long axis</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-039F</p> </td>     <td width="337" valign="top"> <p>Subcostal    short axis</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-03A0</p> </td>     <td width="337" valign="top"> <p>Suprasternal    long axis</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-03A1</p> </td>     <td width="337" valign="top"> <p>Suprasternal    short axis</p> </td> </tr> </table><ul> <li>View Code Sequence (0054,0220) contains codes taken from:</li> </ul><table border="1" cellspacing="0" cellpadding="0"> <tr>      <td width="122" valign="top"> <p>Coding Scheme Designator </p> </td>     <td width="98" valign="top"> <p>Code Value     </p> </td>     <td width="337" valign="top"> <p>Code Meaning     </p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-A19B</p> </td>     <td width="337" valign="top"> <p>Apical two chamber</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-A19C</p> </td>     <td width="337" valign="top"> <p>Apical    four chamber</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-0395</p> </td>     <td width="337" valign="top"> <p>Apical    long axis</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-0396</p> </td>     <td width="337" valign="top"> <p>Parasternal    long axis</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-0397</p> </td>     <td width="337" valign="top"> <p>Parasternal    short axis</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-0398</p> </td>     <td width="337" valign="top"> <p>Parasternal    short axis at the aortic valve level</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-0399</p> </td>     <td width="337" valign="top"> <p>Parasternal    short axis at the level of the mitral chords</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-039A</p> </td>     <td width="337" valign="top"> <p>Parasternal    short axis at the Mitral Valve level</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-039B</p> </td>     <td width="337" valign="top"> <p>Parasternal    short axis at the Papillary Muscle level</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-039C</p> </td>     <td width="337" valign="top"> <p>Right    Ventricular Inflow Tract View</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-039D</p> </td>     <td width="337" valign="top"> <p>Right    Ventricular Outflow Tract View</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-039E</p> </td>     <td width="337" valign="top"> <p>Subcostal    long axis</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-039F</p> </td>     <td width="337" valign="top"> <p>Subcostal    short axis</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-03A0</p> </td>     <td width="337" valign="top"> <p>Suprasternal    long axis</p> </td> </tr> <tr>      <td width="122" valign="top"> <p align="center">SRT</p> </td>     <td width="98" valign="top"> <p align="center">G-03A1</p> </td>     <td width="337" valign="top"> <p>Suprasternal    short axis</p> </td> </tr> </table> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (533, 1, 0, '2009-11-24 10:53:18.999', 'epoiseau', '<H3>Special Instructions</H3> This test is equivalent to the Cardiology CATH_Modality_IM_Interface and ECHO_Modality_IM_Interface Connectathon Test Cases. For systems participating in more than one workflow profile, only 3 instances across this set of tests need to be run across profiles.  <p>Use the RIS Mall to register a patient and obtain a worklist entry for the Modality.  </p> <H3>Description</H3> The Modality and Image Manager test their interfaces for these actions: <ul> <li>Simple MPPS Case <li>MPPS Abandoned Case <li>Storage of Images <li>Storage Commitment </ul> <p> Note that the ability of the Image Manager to forward MPPS messages as a PPS Manager is not exercised in this test. </p> <H3>Evaluation</H3> Connectathon Monitor will ask the Image Manager to show evidence that: <ul> <li>The images for patient MOD^IM are successfully stored <li>The images received from the modality contain attributes received in the modality worklist, including the Study Instance UID (0020,000D), and RP and SPS info in the Requested Attributes Seq (0040,0275). <li>Storage Commitment was successful (N-EVENT-REPORT was sent). <li>It received MPPS Discontinued from the Modality in the Abandoned case.  </ul>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (534, 1, 0, '2009-11-24 10:53:19.003', 'epoiseau', '<H3>Special Instructions</H3> <ul> <li>More than one Acquisition Modality may participate in this test, eg an ECG and NM or ECHO modality. In this test, the term ''Modality'' refers to any acquisition device participating in the Stress procedure. <li>Use the RIS Mall to register a patient and create an order (Requested Procedure) for this test. <li>The Modality should be configured to send MPPS to the DSS/OF. <li>The Modality will C-STORE objects (images/waveforms) in this test, but storage to an Image Manager is not part of the evaluation.  If there is not an available Image Manager to C-STORE to, the Modality should be configured to send its objects to the Connectathon CENTRAL_ARCHIVE. </ul> <H3>Description</H3> This test assumes that at least two modalities will acquire data for a procedure: <ul> <li>ECG acquisition system <li>Image modality (Stress Echo or NM) <li>Potentially an analysis or measurement system </ul> One or more of these systems may participate in this test.  If there is only one modality available, the <b>DSS/OF will still assume that it will be creating SPSs for the other types of systems </b> <p> In this test, the Modality(ies) and DSS/OF test their interfaces for these actions:  </p> <ul> <li>Modality Worklist <li>Multi-modality procedure update by the DSS/OF (CARD TF-1:B.2 and TF-2:4.1.1) <li>The Unscheduled Case (RAD TF-2:4.6.4.1.2.3.2 and Table A.1-2) </ul> Note that the ability of the DSS/OF to forward MPPS messages as a PPS Manager is not exercised in this test.  <H3>Evaluation</H3> Connectathon Monitor will ask the <b>Acquistion Modality</b> to show evidence that:  <ul> <li>it supports Broad MWL queries.  The Modality operator should demonstrate on its user interface the ability to query by combination of SPS Start Date, Modality type, Scheduled AE title. <li>In the Unscheduled Case, the MPPS message sent by the Modality (captured on the DSS/OF) contains: <ul>  <li>(0010,0010) Temporary Patient ID created by the Modality (Patient ID reconciliation is not evaluated in this test) <li>(0020,000D) Study Instance UID created by the Modality. (See characteristics of UIDs below.) <li>(0008, 1032) Procedure Code Sequence is empty <li>In (0040,0270) - Scheduled Step Attributes Sequence, the following attributes are empty (zero-length):  <ul> <li> (0008,1110) Referenced Study Sequence <li> (0008,0050) Accession Number <li> (0032,1060) RP Description <li> (0040,1001) Requested Procedure ID  <li> (0040, 0007) SPS Description <li> (0040,0008) Scheduled Procedure Code Sequence <li> (0040,0009) SPS ID </ul> </ul> </ul> Connectathon Monitor will ask the <b>DSS/OF</b> to show evidence that: <ul> <li>It properly supports MULTI-MODALITY PROCEDURE UPDATE.  After it received the first PPS In Progress Message, it creates SPSs for each modality in the procedure.  The MWL provided to all modalities participating in the Stress procedure contain the SAME Study Instance UID.   <p> In the first Scheduled Case, it is the Study Instance UID generated by the DSS/OF</p> <p>In the Unscheduled Case, it is the Study Instance UID generated by the Modality whiich started the procedure.</p> <li>It creates valid DICOM Study Instance UIDs (0020,000D): <ul> <li>UIDs should not be longer than 64 chars, <li>should not contain leading zeroes in a non-zero component,  <li>should not end with a "." or a space character (no space padding for UIDs!)  <li>in general should start with "1.2", "1.3" or "2.16" (other roots are theoretically possible but very unlikely to be legal). </ul> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (535, 1, 0, '2009-11-24 10:53:19.005', 'epoiseau', '<H3>Special Instructions</H3> This test is identical to the Radiology SWF_ORDERS, and Cardiology CATH_ORDERS and ECHO_ORDERS Connectathon Test Cases, but uses Stress orders. Only 3 instances of this test need to be run across profiles.  <p> Use the RIS MALL as an ADT simulator to register patients for this test.  </p> <H3>Description</H3> This test verifies the ability of the Order Placer and DSS/Order Filler to exchange order and status information (RAD-TF-1: 3.3.3 and RAD-TF-2: 4.3.4) '' patients are registered; orders are created and cancelled at both the OP and DSS/OF.  <p> <b>NOTE: </b>The following transactions are tested in other test cases and are not verified in detail here, but you could check for the proper exchange of these messages : </p> <ul> <li>[RAD-1] ADT notifies OP and DSS/OF of new patient registration.  </ul> <H3>Evaluation</H3> On the <b>OP</b> user interface or database, verify that:  <ul> <li>Orders STRESS-7131C and STRESS-7131E are cancelled.  <li>There is an order STR-DOBUTAMINE  for patient SYS_NAME^ORDERS2.  </ul> <p> On the <b>DSS/OF</b> user interface or database, verify that:  </p> <ul> <li>There is no order STRESS-7131C waiting to be scheduled for patient SYS_NAME^ORDERS1.  <li>There is a scheduled item DOBUTAMINE for patient SYS_NAME^ORDERS2.  <li>A copy of the ORR message from the OP (transaction RAD-3) has been captured, eg in [test-case-no]-orr-msg.txt. ORC-2 should contain the Placer Order number recorded at the OP for Order STRESS-7131C for patient SYS_NAME^ORDERS2.  </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (536, 1, 0, '2009-11-24 10:53:19.007', 'epoiseau', '<H3>Special Instructions</H3> This test case is used for Full Workflow testing with as complete a complement of actors in the STRESS profile as possible.  If necessary, use the RIS Mall for ADT, OP and/or OF functionality.  Typically, this test may be run on the last day of the Connectathon, after the previous tests have been successfully completed.  It is run under the supervision of a Connectathon Monitor who checks the results of the transactions as the test is executed. <p> NM and Echo modalities registered for the STRESS profile may have already executed a full workflow test as part of their testing in the SWF or ECHO profiles.   <p>Ideally, there would be an ECG modality and either a Stress Echo or NM modality available for this test; however, that may not be the case. If there is no imaging modality is available, execute with only a single ECG system. In the real world, this is analogous to the imaging modality system being non-IHE compliant.  </p> <p>In the test steps to follow, the patient first name, SYS_NAME, should be a combination of both the Image Manager and one of the Modality systems under test, for example IM_ABC-MOD_XYZ_ECG.  </p> <H3>Description</H3> This test verifies the ability of the actors in the STRESS profile in the full scheduled workflow, specifically STRESS Use Case S2 (CARD-TF-1: 8.4.2). This test corresponds with Radiology Scheduled Workflow Simple Case (RAD-TF-2: 4.6.4.1.2.3.1 and Table A.1-1). A Patient is registered, an Order is created and a Procedure is scheduled and performed. Finally, the Patient Name is updated.  <p> Modalities and Evidence Creators should send PPS messages to the DSS/OF.  There is no PPS Manager in this test. </p> </p> <p>The test itself is contained in <a href=http://ihewiki.wustl.edu/wiki/index.php/Image:STRESS_workflow.doc>this document</a> which connectathon monitors will use as they guide the test systems through the workflow. </p> <H3>Evaluation</H3> The Connectathon Monitor will check the results of each transaction as the test is executed.  A specific area of focus is the patient reconciliation which occurs after the merge: <p> On the <b>DSS/OF</b>, verify:  <ul> <li>There is no entry for patient Workflow^SYS_NAME (it was updated to be with patient Merge^SYS_NAME).  <li>Verify that the PPS is associated with the original Requested Procedure from the OP and provided in the MWL:  </ul> <ul> <li>(0040,0001) Requested Procedure ID  </ul> On the <b>Image Display</b> (or Image Manager if there is no Display), find the study for patient Merge^SYS_NAME. Verify that:  <ul> <li>The images objects are successfully received/rendered on the Display. Check that the following fields match what was provided in the MWL:  <ul> <li>(0008,0050) Accession Number  <li>(0020,000D) Study Instance UID  </ul> <li>There are no images for patient Doe^SYS_NAME.  </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (537, 1, 0, '2009-11-24 10:53:19.01', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This is the first "test" for the SVS profile. It is run once by Value Set Repositories to load    those systems with codes (value sets) for use in the connectathon. These codes are provided by the    connecthon Project Managers, and are in XML format per the SVS profile.</p> <p>This test should be run on the first day of the connectathon (or prior to arriving), to ensure that these value sets    are available on the Value Set Repository systems for further testing.</p> </p><H3>Description</H3><p>In this test, the Value Set Repository takes the XML value sets provided by the Connectathon    Project Managers and loads them on its system.</p><H3>Evaluation</H3><p>There is no connectathon monitor evaluation for this test. If the value sets are not loaded, no    subsequent SVS tests will work.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (538, 1, 0, '2009-11-24 10:53:19.014', 'epoiseau', '<H3>Special Instructions</H3><p> <p>The Value Set Repository must complete test <i>SVS_Load_Repository</i> before this test can be    run.</p> <p>This test is run by Value Set Consumers which support the <i>HTTP binding</i> option. If your    Consumer only supports HTTP binding, you should run test <i>Retrieve Value Sets - SOAP</i>.</p> <p>The connectathon Project Manager will publish a list of Value Set OIDs and their associated    codes (in English). Each value set will have at least 2 versions and one non-English translation    to enable testing of the optional retrieve parameters.. </p> <p>The Value Set Consumer should identify at least one code set that is applicable to its system.    For example, if you are an XDS Document Source, you could retrieve the Value Set containing    Confidentiality Codes used in XDS metadata; if you are a Order Filler, you could retrieve the    connectathon Scheduled Procedure codes.</p> </p><H3>Description</H3><p>The Value Set Consumer retrieves one or more value set (by OID) using an HTTP binding.</p><H3>Evaluation</H3><ol>     <li>      <p>The Connectathon Monitor will ask the <b>Value Set Consumer</b> to demonstrate the mechanism      it uses to retrieve the codes from the Value Set Repository and import them for use in its      system. The Value Set Consumer may be able to display the contents of the value set (ie codes)      within its application, but this display capability is not required by the SVS profile.</p>      <p>On the <strong>Value Set Consumer</strong>, the Connectathon monitor will verify that new      codes have been successfully retrieved. Each of the value sets created for use in the      connectathon contain a code as follows. Looking for this code will help the Connectathon      Monitor ensure that the value set was retrieved, and not pre-loaded on the Consumer system.</p>      <ul>       <li> code="1.3.6.1.4.1.21367.2009.9.999" displayName="SVS Connectathon Code"       codeSystem="this_will_vary_per_value_set"</li>      </ul>     </li>     <li>If the Consumer supports retrieving by the ''version'' parameter, verify that the ''older''     version of the codes was imported. You will find code: code="1.3.6.1.4.1.21367.2009.9.998"     displayName="SVS Connectathon Code - Older version" codeSystem="this_will_vary_per_value_set</li>     <li>If the Consumer supports retrieving by the ''lang'' parameter, verify that the French values of     the codes was imported.</li> </ol> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (539, 1, 0, '2009-11-24 10:53:19.016', 'epoiseau', '<H3>Special Instructions</H3><p> <p>The Value Set Repository must complete test <i>SVS_Load_Repository</i> before this test can be    run.</p> <p>This test is run by Value Set Consumers which support the <i>SOAP binding</i> option. If your    Consumer only supports HTTP binding, you should run test <i>Retrieve Value Sets - HTTP</i>.</p> <p>The connectathon Project Manager will publish a list of Value Set OIDs and their associated    codes (in English). Each value set will have at least 2 versions and one non-English translation    to enable testing of the optional retrieve parameters.</p> <p>The Value Set Consumer should identify at least one code set that is applicable to its system.    For example, if you are an XDS Document Source, you could retrieve the Value Set containing    Confidentiality Codes used in XDS metadata; if you are a Order Filler, you could retrieve the    connectathon Scheduled Procedure codes.</p> </p><H3>Description</H3><p>The Value Set Consumer retrieves one or more value set (by OID) using a SOAP binding.</p><H3>Evaluation</H3><ol>     <li>      <p>The Connectathon Monitor will ask the <b>Value Set Consumer</b> to demonstrate the mechanism      it uses to retrieve the codes from the Value Set Repository and import them for use in its      system. The Value Set Consumer may be able to display the contents of the value set (ie codes)      within its application, but this display capability is not required by the SVS profile.</p>      <p>On the <strong>Value Set Consumer</strong>, the Connectathon monitor will verify that new      codes have been successfully retrieved. Each of the value sets created for use in the      connectathon contain a code as follows. Looking for this code will help the Connectathon      Monitor ensure that the value set was retrieved, and not pre-loaded on the Consumer system.</p>      <ul>       <li> code="1.3.6.1.4.1.21367.2009.9.999" displayName="SVS Connectathon Code"       codeSystem="this_will_vary_per_value_set"</li>      </ul>     </li>     <li>If the Consumer supports retrieving by the ''version'' parameter, verify that the ''older''     version of the codes was imported. You will find code: code="1.3.6.1.4.1.21367.2009.9.998"     displayName="SVS Connectathon Code - Older version" codeSystem="this_will_vary_per_value_set</li>     <li>If the Consumer supports retrieving by the ''lang'' parameter, verify that the French values of     the codes was imported.</li> </ol> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (540, 1, 0, '2009-11-24 10:53:19.019', 'epoiseau', '<h3>Special Instructions</h3> None <H3>Description</H3> Typically, this test may be run on the last day of the Connectathon, after the previous tests have been successfully completed.  It is run under the supervision of a Connectathon Monitor who checks the results of the transactions as the test is executed. <p>  Walk through SWF/PIR scenarios with as complete a complement of actors in the SWF profile as possible.  (ADT, Placer, Filler, Image Mgr, Modality, Image Display). </p> <p>The test itself is contained in <a href=http://ihewiki.wustl.edu/wiki/index.php/Image:SWFPIR_workflow.doc>this document</a> which connectathon monitors will use as they guide the test systems through the workflow:   </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 (541, 1, 0, '2009-11-24 10:53:19.02', 'epoiseau', '<H3>Description</H3> Typically, this test may be run on the last day of the Connectathon, after the previous tests have been successfully completed.  It is run under the supervision of a Connectathon Monitor who checks the results of the transactions as the test is executed. <p>  Walk through SWF/PIR scenarios with as complete a complement of actors in the SWF profile as possible.  (ADT, Placer, Filler, Image Mgr, Modality, Image Display). </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (542, 1, 0, '2009-11-24 10:53:19.022', 'epoiseau', 'empty description in Kudu');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (543, 1, 0, '2009-11-24 10:53:19.024', 'epoiseau', '<H3>Special Instructions</H3> Evidence Creators should test <strong>all SOP classes it is capable of generating</strong>.  If the Evidence Creator supports the Result Screen Export Option, create Secondary Capture and/or Multi-frame Secondary capture IODs. <H3>Description</H3> This tests Scheduled Workflow transactions between an Evidence Creator, an Image Manager/Image Archive and an Image Display.  The Evidence Creator creates images and/or GSPS objects and sends them to the Image Manager. The Evidence Creator should also perform Storage Commitment (required) and PPS (optional for Radiology SWF profile; required for Cardiology CATH & ECHO profiles). <H3>Evaluation</H3> On the <strong>Image Manager</strong>: <ul> <li>Verify that all created images were successfully stored. <li>View a copy of the PPS and Storage Commitment message from the Evidence Creator, captured on the IM. </ul> <p> On the <strong>Image Display</strong> The Connectathon monitor should observe the Image Display and its ability to interpret/render the images from the Evidence Creator.  </p> <ul> <li>The Connectathon monitor should observe the original images at the  the Evidence Creator, or another Image Display and spot-check Images are displayed correctly and completely.    <li>Verify that the derived images were created in a new series, and not extended from the series containing the source images. </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (544, 1, 0, '2009-11-24 10:53:19.026', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This is an interoperability test between Image Displays and Acquisition Modalities to ensure that the Display can accurately render the Modality''s images. <strong>The Acquisition Modality must identify a good, representative study to use for this test</strong> (eg a CT study with one series / one image is not a good study).</p> <p>When this test begins, the Modality actor can either send the images directly to the Display, or identify the patient name so that the Image Display actor can query/retrieve the appropriate study from the <strong>CENTRAL_ARCHIVE</strong>. </p> <p>Image Display please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find out what your peers have uploaded on the Central Archive </p> <p>The Image Display <strong>should not</strong> just retrieve random studies from the Connectathon <strong>CENTRAL_ARCHIVE</strong>; some studies may not be appropriate for this specific display test. </p> </p><H3>Description</H3><p>The test verifies that the Image Display can display a variety of image sets and evidence objects from various vendors. </p><H3>Evaluation</H3><p>On the <strong>Image Display</strong>:</p><ul> <li>ensure that the Image Display system has obtained a good sample for you to evaluate, ie one or two images or reports is not enough.</li> <li>verify that images and reports from each Modality vendor can be accurately stored and displayed.  The Connectathon Monitor may ask a representative of the originating Modality to verify the accuracy of the rendering of its study on the Image Display.</li> <li>The Connectathon Monitor should observe its ability to interpret/render the objects (derived images, SRs, or measurements, ie Evidence Documents) from the Evidence Creator actors. The Connectathon Monitor may ask a representative of the originating Evidence Creator to verify the accuracy of the rendering of its data, or observe the originals at the Evidence Creator and spot-check that they are displayed correctly and completely. </li> <li>Verify the ability to display the value of <b>Series Description for</b> each series displayed (RAD-TF:4.16.4.2.3)</li> </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (545, 1, 0, '2009-11-24 10:53:19.028', 'epoiseau', '<H3>Special Instructions</H3> Evidence Creators should test <b>all SOP classes it is capable of generating. </b> <H3>Description</H3> This tests workflow transactions between an Evidence Creator and an Image Manager/Archive.  The Evidence Creator creates evidence objects and sends them to the Image Manager. The Evidence Creator will also perform Storage Commitment, and MPPS (required for Cardiology STRESS, CATH & ECHO profiles; optional for Radiology SWF, not required for NMI profile).  The Q/R and display capabilities are tested in test SWF_ID_IM. <H3>Evaluation</H3> On the <b>Image Manager</b>:  <li>Verify that all created objects/images were successfully stored.  <li>If applicable, verify that the derived objects were created in a new series, and not extended from the series containing the source images. <li>View a copy of the PPS (optional) and Storage Commitment message from the Evidence Creator, captured on the IM. </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (546, 1, 0, '2009-11-24 10:53:19.031', 'epoiseau', '<H3>Special Instructions</H3><p> <p>The Evidence Creator actor should drive this test.   </p> <p>     <i><b>     This tests the compatibility between Image Displays and Evidence Creators.  The Image Display may obtain structured reports, secondary captures, etc directly from the Evidence Creator, or from the Central Archive.  You must obtain a good sample so the Connectathon Monitor will be able to adequately evaluate your Image Display application.    </b></i> </p> <p>    The Image Display can use the Connectathon <b>CENTRAL_ARCHIVE</b> as a source of different vendors'' images.   </p> <p>Image Display please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find out what your peers have uploaded on the central archive </p> </p><H3>Description</H3><p>The test verifies that the Image Display can retrieve and display a variety of evidence objects from various vendors.</p><H3>Evaluation</H3><p>On the <strong>Image Display</strong>, the Connectathon monitor will verify:</p><ul>     <li>ensure that the Image Display system has obtained a good variety of samples for you to evaluate, ie one or two evidence objects is not enough.</li>           <li>The Connectathon Monitor should observe the Display''s ability to interpret/render the objects (derived images, SRs, or measurements, ie Evidence Documents) from the Evidence Creator actors. The Connectathon Monitor may ask a representative of the originating Evidence Creator to verify the accuracy of the rendering of its data, or observe the originals at the Evidence Creator and spot-check that they are displayed correctly and completely. </li>       </ul>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (547, 1, 0, '2009-11-24 10:53:19.033', 'epoiseau', '<H3>Special Instructions</H3> <p>The Image Display actor should drive this test. </p> <p> <i><b> This tests the compatibility between Image Displays and Modalities.  The Image Display may obtain images directly from the Modality, or from the Central Archive.  You must obtain a good sample so the Connectathon Monitor will be able to adequately evaluate your Image Display application. </b></i> </p>  <p> The Image Display can use the Connectathon <b>CENTRAL_ARCHIVE</b> as a source of different vendors'' images. </p> <H3>Description</H3> The test verifies that the Image Display can retrieve and display a variety of image sets and evidence objects from various vendors. <H3>Evaluation</H3> On the <b>Image Display </b>: <ul> <li>ensure that the Image Display system has obtained a good variety of samples for you to evaluate, ie one or two images or reports is not enough. <li>verify that images and possibly reports from each Modality vendor can be accurately stored and displayed.  The Connectathon Monitor may ask a representative of the originating Modality to verify the accuracy of the rendering of its study on the Image Display. <li>Verify the ability to display the value of <b>Series Description for</b> each series displayed (RAD-TF:4.16.4.2.3) </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (548, 1, 0, '2009-11-24 10:53:19.035', 'epoiseau', '<H3>Special Instructions</H3> <b><i>This test should be run on the 1st or 2nd day of the Connectathon to enable Image Displays to do a follow-up test to Q/R these images and evidence objects.</b></i> <H3>Description</H3> The purpose of this test is to verify that an Image Manager can accept and store real world vendor images and evidence objects which are available.  Q/R is tested in another test <H3>Evaluation</H3> Verify that all images and evidence objects from several Acquisition Modality and Evidence Creator actors in the SWF profile are received at IM under test. Verify the total number of SOP instances stored and total number of studies stored. Verify that the objects are stored as full-fidelity objects (ie., no DICOM data elements are deleted). <p> Image Managers must support storage of multiple SOP classes (RAD TF-2:4.8.4.1.3.1):  </p> <pre> SOP Class UID 	SOP Class Name  1.2.840.10008.5.1.4.1.1.1  Computed Radiography Image Storage  1.2.840.10008.5.1.4.1.1.2  CT Image Storage  1.2.840.10008.5.1.4.1.1.4 MR Image Storage  1.2.840.10008.5.1.4.1.1.20 Nuclear Medicine Image Storage  1.2.840.10008.5.1.4.1.1.128 Positron Emission Tomography Image Storage  1.2.840.10008.5.1.4.1.1.481.1 RT Image Storage  1.2.840.10008.5.1.4.1.1.7 Secondary Capture Image Storage  1.2.840.10008.5.1.4.1.1.6.1 Ultrasound Image Storage  1.2.840.10008.5.1.4.1.1.3.1 Ultrasound Multi-frame Image Storage  1.2.840.10008.5.1.4.1.1.12.1 X-Ray Angiographic Image Storage  1.2.840.10008.5.1.4.1.1.12.2 X-Ray Radiofluoroscopic Image Storage  1.2.840.10008.5.1.4.1.1.1.1 Digital X-Ray Image Storage '' For Presentation  1.2.840.10008.5.1.4.1.1.1.1.1 Digital X-Ray Image Storage '' For Processing  1.2.840.10008.5.1.4.1.1.1.2 Digital Mammography Image Storage '' For Presentation  1.2.840.10008.5.1.4.1.1.1.2.1 Digital Mammography Image Storage '' For Processing  1.2.840.10008.5.1.4.1.1.1.3 Digital Intra-oral X-Ray Image Storage '' For Presentation  1.2.840.10008.5.1.4.1.1.1.3.1 Digital Intra-oral X-Ray Image Storage '' For Processing  1.2.840.10008.5.1.4.1.1.77.1.1 VL Endoscopic Image Storage  1.2.840.10008.5.1.4.1.1.77.1.2 VL Microscopic Image Storage  1.2.840.10008.5.1.4.1.1.77.1.3 	VL Slide-Coordinates Microscopic Image Storage  1.2.840.10008.5.1.4.1.1.77.1.4 	VL Photographic Image Storage  </pre>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (549, 1, 0, '2009-11-24 10:53:19.037', 'epoiseau', '<H3>Special Instructions</H3> <p> This test requires an Modality and Image Manager.  If a DSS/Order Filler actor is available, run test case SWF_SPS_PPS_CASES. <p> In the descriptions to follow, the patient last name, SYS_NAME, should be a combination of both the Image Manager and Modality systems under test, for example: IM_ABC-MOD_XYZ.   </p> <p> Use the RIS Mall as an ADT, OP  and DSS/OF simulator to register patients and create and schedule orders. The Modality system should take responsibility for creating the patients and orders for the test.   </p> <p> If there is an idle ADT or OP actor that wants to collaborate, you are free to use that system; that ADT or OP system will not be recognized in the test results. </p> <H3>Description</H3> <p>This is a sequence of four tests which test the various relationships between Scheduled and Requested Procedure information.  See RAD-TF-1: 4.6.1.2.3.  It verifies the ability of the Acquisition Modality and Image Manager to handle these Scheduled Workflow cases: </p> <ul> <li><strong>Simple Case</strong> (RAD-TF-2: 4.6.4.1.2.3.1 and Table A.1-1) - single PPS per SPS <li><strong>Unscheduled Case</strong> (CATH Case 3 - CARD-TF-1: 3.4.3  and RAD-TF-2: 4.6.4.1.2.3.2 and Table A.1-2)   - the images are acquired at the Modality but the Patient has not been registered, the Order was not created, and the Procedure was not scheduled. <li><strong>Append-to-Normal Case</strong> (RAD-TF-2: 4.6.4.1.2.3.3 and Table A.1-3) '' a Patient is registered, an Order is created and a Procedure is scheduled.  Additional PPSs are performed on the Modality that were not scheduled at the DSS/OF. <li><strong>Abandoned Case</strong> (RAD-TF-2: 4.6.4.1.2.3.5) '' a Patient is registered, an Order is created and a Procedure is scheduled, started, then discontinued.  </ul> <p> The Group Case is tested in a separate test. </p> <p>Storage Commitment is also tested.  There is no PPS Manager in this test case. </p> <p> <strong>NOTE:</strong>  The following transactions are tested in other test cases and are not verified in detail here, but you could check for the proper exchange of these messages. </p> <ul> <li>[RAD-1] ADT notifies OP and DSS/OF of patient registration. <li>[RAD-2] OP notifies DSS/OF of new order. <li>[RAD-4] DSS/OF notifies IM of new procedure scheduled. <li>[RAD-5] Acquisition modality queries DSS/OF for worklist. </ul> <H3>Evaluation</H3> <p> On the <strong>Image Manager</strong> user interface or database verify that all of the images in the study have been successfully stored. </p> <p>View a copy of the captured SC N-EVENT-REPORT on the <strong>Acquisition Modality</strong> or in Kudu.  All of the following attributes shall be verified in the Storage Commit message from the Modality: </p> <ul> <li>(0008, 1199) Referenced SOP Sequence <ul>  <li>> (0008, 1150) Reference SOP Class  <li>> (0008, 1155 Referenced SOP Instance UID  </ul> </ul> <p>For the <strong> SIMPLE CASE</strong>, on the <strong>Image Manager</strong>, find the study for SYS_NAME^SIMPLE.  Verify that: </p> <ul> <li>The images objects are successfully stored on the IM.  Check that the following fields match what was provided in the MWL: <ul> <li>(0008,0050) Accession Number  <li>(0020,000D) Study Instance UID </ul> </ul> <p> For the <strong>UNSCHEDULED CASE</strong>, on the <strong>Image Manager</strong>, verify that: </p> <ul> <li>The image objects stored for this test contain: <ul> <li>Patient ID and Patient Name (SYS_NAME^ACTUAL_UNSCHED_PAT) generated at the ADT (received in RAD-12) <li>(0008,0050) Accession Number '' must be zero-length <li>(0020,000D) Study Instance UID originally generated by the Modality (not a new one generated by the DSS/OF). </ul> <li>A copy of the MPPS message to the IM (transaction RAD-6 and RAD-7) has been captured, eg in [test-case-no]-unsched-pps-complete.txt.  Check that:  <ul> <li>MPPS message contains no Requested Procedure or Scheduled Procedure details. </ul> </ul> <p> For the <strong>APPEND CASE</strong>, on the <strong>IM</strong>, find the study for MOD-SYSTEM^APPEND.  Verify that: </p> <ul> <li>(0040,0244) Performed Procedure Step ID is different for the two procedure steps performed on the modality (original and appended steps). <li>The values in the following fields are the same in the IODs from the original PPS, and in those appended.  Check the Study Instance UID for the first and last image in the study. <ul> <li>Study Instance UID (0020,000D) <li> Also Study Date, Study Time and Study Description attributes are the same in image IODs for the original PPS, and those appended.  </ul> </ul> For the <strong>ABANDONED CASE</strong>, on the <strong>Image Manager</strong>, find the study for SYS_NAME^ABANDON.  Verify that: <ul> <li>The images objects are successfully stored on the IM.     </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (550, 1, 0, '2009-11-24 10:53:19.042', 'epoiseau', '<H3>Special Instructions</H3> Evidence Creator and Acquisition Modality actors perform ONE instance of this test.  <b>This should be done on the first day of the Connectathon.</b> <p> The Modality system should arrive at the Connectathon with images for this test PRE-OBTAINED and PRE-LOADED or you will waste a great deal of time!  Please bring representative samples for your Modality; eg Image Display actors benefit from testing with studies containing multiple series with multiple images. </p> <H3>Description</H3> All Acquisition Modalities and Evidence Creators participating in the SWF profile should store images of all SOP classes it is capable of generating to the Connectathon CENTRAL_ARCHIVE.  This will enable Image Manager and Image Display actors to access these images for their testing. <p> Modalities and Evidence Creators could also find time to test directly sending their images to Image Manager actors. </p> <H3>Evaluation</H3> There is no formal evaluation for this test.  The purpose is to provide images to the CENTRAL_ARCHIVE for others'' testing.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (551, 1, 0, '2009-11-24 10:53:19.044', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Evidence Creator and Acquisition Modality actors perform ONE instance of this test. <strong>This should be done on the first day of the Connectathon</strong>.</p> <p>The Modality system should arrive at the Connectathon with images for this test <strong>PRE-OBTAINED</strong> and <strong>PRE-LOADED</strong> or you will waste a great deal of time! </p> </p><H3>Description</H3><p>All Acquisition Modalities and Evidence Creators participating in the SWF profile should store images of all SOP classes it is capable of generating to the Connectathon CENTRAL_ARCHIVE. This will enable Image Manager and Image Display actors to access these images for their testing.</p> <p>You must enter a description of your study in the <em><a href=system_con_object.php?selected=create_object>Objects Information</a></em>.  Please upload there a screen capture of the object so that we can use it for comparison when your peers will render your images.</p> <p>Modalities and Evidence Creators could also find time to test directly sending their images to Image Manager actors.</p> <h3>Evaluation</h3> <p>In order to validate the test, the connectathon monitor will check:</p> <ul> <li>that the objects are stored on the Central Archive,</li> <li>that there is a corresponding entry in the <em><a href=system_con_object.php?selected=create_object>Objects Information</a></em>  section of the kudu webtool, and </li> <li>that there is a screen capture of the objects uploaded in the <em><a href=system_con_object.php?selected=create_object>Objects Information</a></em> section of the kudu webtool, and</li> <li>that the printed output adequately describes the displayed image.</li> </ul> <p>Note that samples stored to the Central Archive are checked by a DICOM validator.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (552, 1, 0, '2009-11-24 10:53:19.046', 'epoiseau', '<H3>Special Instructions</H3> <p> In this test, you will be asked to create patient names where the last name will contain the name of the modality system under-test, eg. MOD-SYSTEM-A^TOMORROW.   </p> <p> Please use the suggested patient name format; it helps make the later test evaluation much more efficient.    </p> <H3>Description</H3> <p> This test verifies the ability of the DSS/Order Filler and Acquisition Modality to exchange patient and procedure information using Modality Worklist Query, and the ability of the Modality to constrain the worklist it requests (RAD-TF-2: 4.5.1). </p> <p> In the Patient Based Query, a Modality should support all combinations of:  Patient Name (0010,0010), Patient ID (0010,0020), Accession Number (0008,0050), Requested Procedure ID (0040,1001). </p> <p> In the Broad Query, a Modality should support all combinations of: SPS Start Date (0040,0002), Modality (0008,0060), Scheduled Station AE Title (0040,0001). </p> <p> NOTE:  The following transactions are tested in other test cases and are not verified in detail here, but you could check for the proper exchange of these messages. </p> <ul> <li>	[RAD-1] ADT notifies OP and DSS/OF of new patient registration. <li>[RAD-2] OP notifies DSS/OF of new order. <li>[RAD-4] DSS/OF notifies IM of new procedure scheduled. </ul> <H3>Evaluation</H3> <p> The modality must demonstrate <strong> some  method for constraining worklist</strong>.    The results below assume that worklists are constrained according to the Technical Framework. </p> <p> On the <strong>Modality</strong>, there are <strong>3 captured files </strong>to examine: <ul> <li>In <strong>[test-case-no]-todaymwl.txt</strong>, the worklist should contain: <ul> <li>Four worklist items. <li>Patient MOD-SYSTEM-A^TOMORROW should not appear.  <li>(If the query also constrained by modality type, MOD-SYSTEM-E^NOT-ON-MWL would also not appear.) </ul> <li>In <strong>[test-case-no]-accnomwl.txt</strong>, the worklist should contain one worklist item for patient MOD-SYSTEM-C^MWL-ACC-NO. <li>In <strong>[test-case-no]-patnamemwl.txt</strong>, the worklist should contain: <ul> <li>Five worklist items.  <li>(If the query also constrained by modality type, MOD-SYSTEM-E^NOT-ON-MWL would also not appear.) </ul> </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (553, 1, 0, '2009-11-24 10:53:19.048', 'epoiseau', '<H3>Special Instructions</H3> None <H3>Description</H3> The Modality and Image Manager test their interfaces for these actions: <ul> <li><b>Append-to-Normal Case</b> (RAD-TF-2: 4.6.4.1.2.3.3 and Table A.1-3) '' a Patient is registered, an Order is created and a Procedure is scheduled. Additional PPSs are performed on the Modality that were not scheduled at the DSS/OF.  <li><b>Abandoned Case</b> (RAD-TF-2: 4.6.4.1.2.3.5) '' a Patient is registered, an Order is created and a Procedure is scheduled, started, then discontinued.  <li><b>Storage Commitment</b> </ul> <p> Note that the ability of the Image Manager to forward MPPS messages as a PPS Manager is not exercised in this test. </p> <H3>Evaluation</H3> For the <b>APPEND CASE</b>, the Connectathon Monitor will ask the Image Manager to show evidence that:  <ul> <li>The images for patient MOD-IM^APPEND are successfully stored <li>The images received from the modality contain attributes received in the modality worklist, including the Study Instance UID (0020,000D), and RP and SPS info in the Requested Attributes Seq (0040,0275). <li> (0040,0253) Performed Procedure Step ID is different for the two procedure steps performed on the modality (original and appended steps).  <li>The values in the following fields are the same in the IODs from the original PPS, and in those appended. Check the Study Instance UID for the first and last image in the study.  <ul> <li>Study Instance UID (0020,000D) should be that received from the DSS/OF (RIS Mall). <li>Also Study Date, Study Time and Study Description attributes are the same in image IODs for the original PPS, and those appended.  </ul> <li>Storage Commitment was successful (N-EVENT-REPORT was sent). Check: <ul> <li>(0008, 1199) Referenced SOP Sequence <ul>  <li>> (0008, 1150) Reference SOP Class  <li>> (0008, 1155 Referenced SOP Instance UID  </ul> </ul>  <p> For the<b> ABANDONED CASE</b>, the Connectathon Monitor will ask the Image Manager to show evidence that:  </p> <ul> <li>It received MPPS Discontinued from the Modality in the Abandoned case. </ul>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (554, 1, 0, '2009-11-24 10:53:19.052', 'epoiseau', '<H3>Special Instructions</H3> This test exercises the exchange of HL7 messages between DSS/OF and IM actors.  <p> If you are able to use an Order Placer (not RIS Mall), you should do that </p> <p> It also tests the ability of these actors to act as a PPS Manager.  <b>During the Connectathon, each DSS/OF and Image Manager must execute at least one instance of this test where it assumes the role of PPS Manager and successfully forwards PPS messages to its partner</b>.  </p> A Modality actor is needed to assist with the first part of this test.  It will generate PPS Messages to be sent to whichever system is the PPS Manager.  (No Modality functionality is evaluated in this test; any Modality may be used; contents of PPS messages and Modality C-STORE are evaluated elsewhere.) <H3>Description</H3> This test verifies interoperability between DSS/OF and Image Manager/Archive actors, specifically for these transactions: <ul> <li>[RAD-6] (or [CARD-1]) PPS In Progress (forwarding this message) <li>[RAD-7] PPS Completed (forwarding this message) <li>[RAD-12] Patient Update (name change) <li>[RAD-4] Procedure Scheduled <li>[RAD-13] Procedure Updated  </ul> <H3>Evaluation</H3> Verify that the system performing the role of <b>PPS Manager</b>:  <ul> <li>Properly forwarded both PPS In Progress and PPS Complete to its partner.  These messages should be captured on the receiving (non-PPS-Mgr) system. </ul> On the <b>Image Manager</b> verify:  <ul> <li>It received an ADT^A08 message with a patient name change from OF_XYZ-IM_ABC^OLD-NAME to OF_XYZ-IM_ABC^NEW-NAME <li>The images stored on the Image Manager are updated with this new name. <li>It received an ORM to indicate a procedure was scheduled.  In the ORM: <ul> <li>ORC-1 is ''NW'' <li>ORC-2 contains a Placer Order number from RIS Mall <li>ORC-3 contains a Filler Order number generated by the DSS/OF <li>ORC-5 is ''SC'' <li>ORC-7 contains a value for the Date/Time of the SPS (in the 4th component) <li>OBR-18 contains accession number <li>OBR-19 contains RP ID <li>OBR-20 contains SPS ID <li>OBR-24 contains the DICOM Modality (defined terms) <li>ZDS-1 contains Study Instance UID of the form: <UIDvalue>^<ApplID value>^Application^DICOM </ul> <li>It received an ORM to indicate the procedure was cancelled.  The ORM contains: <ul>  <li>a value of ''CA'' in ORC-1 and ORC-5 </ul> <li> the ORC and OBR elements are unchanged from the previous Procedure Scheduled message, especially: <ul>  <li>OBR-2 and ORC-2 Placer Order Number (RIS Mall value) <li>OBR-3 and ORC-3 Filler Order Number <li>ORC-4 Placer Group Number <li>ZDS-1 Study Instance UID </ul> </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (555, 1, 0, '2009-11-24 10:53:19.054', 'epoiseau', '<H3>Special Instructions</H3> <ul> <li>Use the RIS Mall to register a patient and create an order (Requested Procedure) for this test. <li>The Modality should be configured to send MPPS to the DSS/OF. <li>The Modality will C-STORE images in this test, but storage to an Image Manager is not part of the evaluation.  If there is not an available Image Manager to C-STORE to, the Modality should be configured to send its objects to the Connectathon CENTRAL_ARCHIVE </ul> <H3>Description</H3> In this test, the Modality and DSS/OF test their interfaces for these actions: <ul> <li>Modality Worklist <li>The Unscheduled Case  </ul> Note that the ability of the DSS/OF to forward MPPS messages as a PPS Manager is not exercised in this test.  <H3>Evaluation</H3> Connectathon Monitor will ask the <b>Acquistion Modality</b> to show evidence that:  <ul> <li>it supports either Broad or Patient-Based MWL queries. (It may support both.)   <p><b>Broad Worklist</b>: The Modality operator should demonstrate on its user interface the ability to query by combination of SPS Start Date, Modality type, Scheduled AE title. </p> <p><b>Patient-Based Worklist</b>: The Modality operator should demonstrate on its user interface the ability to query by combination of Patient Name, Patient ID, Accession Number, Requested Procedure ID. </p> <li>In the Unscheduled Case, the MPPS message sent by the Modality (captured on the DSS/OF) contains: <ul> <li>(0010,0010) Temporary Patient ID created by the Modality (Patient ID reconciliation is not evaluated in this test)  <li>(0008, 1032) Procedure Code Sequence is empty <li>In  (0040,0270)  the Scheduled Step Attribute Sequence:</li> <ul> <li>(0020,000D) Study Instance UID as created by the Modality</li> </ul> <li>In (0040,0270) '' Scheduled Step Attributes Sequence, the following attributes are empty (zero-length): <ul> <li> (0008,1110) Referenced Study Sequence <li> (0008,0050) Accession Number   <li>(0032,1060) RP Description <li> (0040,1001) Requested Procedure ID  <li>(0040, 0007) SPS Description <li> (0040,0008) Scheduled Procedure Code Sequence <li>(0040,0009) SPS ID </ul> </ul> </ul> <p> Connectathon Monitor will ask the <b>DSS/OF </b>to show evidence that: </p> <ul> <li>It creates valid DICOM Study Instance UIDs (0020,000D): <ul> <li>UIDs should not be longer than 64 chars, <li>should not contain leading zeroes in a non-zero component,  <li>should not end with a "." or a space character (no space padding for UIDs!)  <li>in general should start with "1.2", "1.3" or "2.16" (other roots are theoretically possible but very unlikely to be legal). </ul> <li>a RP/SPS has been created for this procedure using the modality-provided Study Instance UID received in the MPPS. </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (556, 1, 0, '2009-11-24 10:53:19.057', 'epoiseau', '<H3>Special Instructions</H3> None. <H3>Description</H3> Appointment Notification [RAD-48] is an optional transaction used by DSS/OF actors to notify an OP of new appointments, rescheduled SPSs and cancellations (RAD-TF-2:4.48). <H3>Evaluation</H3> On the <strong>Order Placer</strong> user interface or database, verify: <ul> <li>In the captured SIU message, AIS-3 contains an identifier for the first SPS scheduled on the DSS/OF. <li>AIS-4 contains the scheduled start date/time. <li> The second order placed has a status of ''cancelled''. </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (557, 1, 0, '2009-11-24 10:53:19.059', 'epoiseau', '<H3>Special Instructions</H3> This test is identical to the Radiology CATH_ORDERS, ECHO_ORDERS and STRESS_ORDERS Connectathon Test Cases, but uses radiology orders. For systems participating in multiple profiles, only 3 instances of this test need to be run across profiles.  <p> Use the RIS MALL as an ADT simulator to register patients for this test.  If there is an idle ADT actor that wants to collaborate, you are free to use that system; that ADT system will not be recognized in the test results.  </p> <H3>Description</H3> This test verifies the ability of the Order Placer and DSS/Order Filler to exchange order and status information (RAD-TF-1: 3.3.3 and RAD-TF-2: 4.3.4) '' patients are registered; orders are created and cancelled at both the OP and DSS/OF.  <p> <strong>NOTE:</strong>  The following transactions are tested in other test cases and are not verified in detail here, but you could check for the proper exchange of these messages </p> <ul> <li>[RAD-1] ADT notifies OP and DSS/OF of new patient registration. <li>[RAD-12] ADT notifies OP and DSS/OF patient update or merge. </ul> <H3>Evaluation</H3> <p> On the <strong>OP</strong> user interface or database, verify that: </p> <ul> <li>Orders 11050 or 12110 are cancelled.  <li>There is an order 12150 (Radiological Examination: Right Wrist) for patient SYS_NAME^ORDERS2.  </ul> <p> On the <strong>DSS/OF</strong> user interface or database, verify that: </p> <ul> <li>There is no order 11050 waiting to be scheduled for patient SYS_NAME^SWF-ORDERS1 (it was cancelled). <li>There is a scheduled item 912150 for patient SYS_NAME^ORDERS2.  <li>A copy of the ORR message from the OP (transaction RAD-3) has been captured, eg in [test-case-no]-orr-msg.txt. ORC-2 should contain the Placer Order number recorded at the OP for Order 12150 for patient SYS_NAME^ORDERS2.  </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (558, 1, 0, '2009-11-24 10:53:19.063', 'epoiseau', '<H3>Special Instructions</H3> This test is a subset of the SWF_ORDERS test case; it only exercises the transactions between an Order Filler and Image Manager.  To exercise the Order Placer transactions as well, run SWF_ORDERS. <p> <strong>Use the RIS Mall as an OP simulator to register patients. If there is an idle OP actor that wants to collaborate, you are free to use that system; that OP system will not be recognized in the test results.</strong> </p> <H3>Description</H3> This test verifies the ability of the DSS/Order Filler and Image Manager to exchange order and status information (RAD-TF-1: 3.3.3 and RAD-TF-2: 4.3.4) '' patients are registered; orders are created and cancelled at the DSS/OF.  <p> <strong>NOTE:</strong>  The following transactions are tested in other test cases and are not verified in detail here, but you could check for the proper exchange of these messages </p> <ul> <li>[RAD-1] ADT notifies DSS/OF of new patient registration. </ul> <H3>Evaluation</H3> <p> On the <strong>DSS/OF</strong> user interface or database, verify that: </p> <ul> <li>There is a scheduled order for patient SYS_NAME^SWF-ORDERS1 (it was cancelled). <li>There is a new procedure for patient SYS_NAME^SWF-ORDERS2. </ul> On the <strong>Image Manager</strong> user interface or database, verify that: <ul> <li>There is a scheduled procedure for patient SYS_NAME^SWF-ORDERS1. <li>There is a cancelled procedure for SYS_NAME^SWF-ORDERS2. <li>There is an entry for a new scheduled procedure for SYS_NAME^SWF-ORDERS2 (note that there are no images acquired for this patient in this test). <li>A copy of the ORM message from the DSS/OF (transaction RAD-4) has been captured, eg in [test-case-no]-sched-msg.txt.  Check the following fields: </ul> <ul> <li> ORC-5 should contain ''SC'' <li>OBR-18 should contain the Accession Number from the DSS/OF <li>ZDS-1 should contain the Study Instance UID. </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (559, 1, 0, '2009-11-24 10:53:19.064', 'epoiseau', '<H3>Special Instructions</H3> This test is similar to the SWF_ORDERS test case, but only exercises the transactions between an Order Placer and Order Filler.  To exercise the Image Manager transactions, run SWF_ORDERS. <p> Use the RIS Mall as an ADT simulator to register patients. If there is an idle ADT actor that wants to collaborate, you are free to use that system; that ADT system will not be recognized in the test results. </p> <H3>Description</H3> This test verifies the ability of the Order Placer and DSS/Order Filler to exchange order and status information (RAD-TF-1: 3.3.3 and RAD-TF-2: 4.3.4) '' patients are registered; orders are created and cancelled at both the OP and DSS/OF.  <p> <strong>NOTE:</strong>  The following transactions are tested in other test cases and are not verified in detail here, but you could check for the proper exchange of these messages </p> <ul> <li>[RAD-1] ADT notifies OP and DSS/OF of new patient registration. <li>[RAD-12] ADT notifies OP and DSS/OF patient update or merge. </ul> <H3>Evaluation</H3> <p> On the <strong>OP</strong> user interface or database, verify that: </p> <ul> <li>The order for SYS_NAME^SWF-ORDERS1 is cancelled (order number was recorded in the Kudu chat window). <li>There is new order/procedure for patient SYS_NAME^SWF-ORDERS2. </ul> <p> On the <strong>DSS/OF</strong> user interface or database, verify that: </p> <ul> <li>There is no order waiting to be scheduled for patient SYS_NAME^SWF-ORDERS1 (it was cancelled). <li>There is a new procedure for patient SYS_NAME^SWF-ORDERS2. <li>A copy of the ORR message from the OP (transaction RAD-3) has been captured, eg in [test-case-no]-orr-msg.txt.  ORC-2 should contain the Placer Order number recorded at the OP for patient SYS_NAME^SWF-ORDERS2 . </ul>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (560, 1, 0, '2009-11-24 10:53:19.066', 'epoiseau', '<H3>Special Instructions</H3> <p> This test requires an Order Filler, Modality and Image Manager.  To run these use cases with only a Modality and Image Manager, run test case SWF_MOD_IM. <p> In the descriptions to follow, the patient last name, SYS_NAME, should be a combination of both the Image Manager and Modality systems under test, for example: IM_ABC-MOD_XYZ.   </p> <p> Use the RIS Mall as an ADT and OP simulator to register patients and create orders. The Modality system should take responsibility for creating the patients and orders for the test.   </p> <p> If there is an idle ADT or OP actor that wants to collaborate, you are free to use that system; that ADT or OP system will not be recognized in the test results. </p> <H3>Description</H3> <p>This is a sequence of four tests which test the various relationships between Scheduled and Requested Procedure information.  See RAD-TF-1: 4.6.1.2.3.  It verifies the ability of the DSS/Order Filler, Acquisition Modality & Image Manager to handle these Scheduled Workflow cases: </p> <ul> <li><strong>Simple Case</strong> (RAD-TF-2: 4.6.4.1.2.3.1 and Table A.1-1) - single PPS per SPS <li><strong>Unscheduled Case</strong> (CATH Case 3 - CARD-TF-1: 3.4.3  and RAD-TF-2: 4.6.4.1.2.3.2 and Table A.1-2)   - the images are acquired at the Modality but the Patient has not been registered, the Order was not created, and the Procedure was not scheduled. <li><strong>Append-to-Normal Case</strong> (RAD-TF-2: 4.6.4.1.2.3.3 and Table A.1-3) '' a Patient is registered, an Order is created and a Procedure is scheduled.  Additional PPSs are performed on the Modality that were not scheduled at the DSS/OF. <li><strong>Abandoned Case</strong> (RAD-TF-2: 4.6.4.1.2.3.5) '' a Patient is registered, an Order is created and a Procedure is scheduled, started, then discontinued.  </ul> <p> The Group Case is tested in a separate test. </p> <p>The Image Manager is the PPS Manager this test case.  The ability of the Image Manager to forward PPS messages is tested in the SIMPLE case. </p> <p> <strong>NOTE:</strong>  The following transactions are tested in other test cases and are not verified in detail here, but you could check for the proper exchange of these messages. </p> <ul> <li>[RAD-1] ADT notifies OP and DSS/OF of patient registration. <li>[RAD-2] OP notifies DSS/OF of new order. <li>[RAD-4] DSS/OF notifies IM of new procedure scheduled. <li>[RAD-5] Acquisition modality queries DSS/OF for worklist. <li>[RAD-10] Storage Commitment </ul> <H3>Evaluation</H3> <p>For the <strong>SIMPLE CASE</strong>, on the <strong>DSS/OF</strong>, verify:</p> <ul> <li>A copy of the N-CREATE PPS forwarded from the IM to the DSS/OF (transaction RAD-6) has been captured, eg in [test-case-no]-simple-pps-IP.txt.  Check that the following fields match what was provided in the MWL: <ul> <li>(0008,0050) Accession Number  <li>(0020,000D) Study Instance UID </ul> <li>Verify that the PPS is associated with the original Requested Procedure (OBR-19) from the OP and provided in the MWL:   <ul> <li>(0040,0001) Requested Procedure ID </ul> </ul> <p> For the <strong> SIMPLE CASE</strong>, on the <strong>Image Manager</strong>, find the study for SYS_NAME^SIMPLE.  Verify that: </p> <ul> <li>The images objects are successfully stored on the IM.  Check that the following fields match what was provided in the MWL: <ul> <li>(0008,0050) Accession Number  <li>(0020,000D) Study Instance UID </ul> </ul> <p> For the <strong>UNSCHEDULED CASE</strong>, on the <strong>Image Manager</strong>, verify that: </p> <ul> <li>In the image objects stored for this test: <ul> <li>(0008,0050) Accession Number '' must be zero-length <li>(0020,000D) Study Instance UID originally generated by the Modality (not a new one generated by the DSS/OF). </ul> <li>A copy of the MPPS message to the IM (transaction RAD-6 and RAD-7) has been captured, eg in [test-case-no]-unsched-pps-complete.txt.  Check that:  <ul> <li>MPPS message contains no Requested Procedure or Scheduled Procedure details. </ul> </ul> <p> For the <strong>APPEND CASE</strong>, on the <strong>IM</strong>, find the study for MOD-SYSTEM^APPEND.  Verify that: </p> <ul> <li>(0040,0244) Performed Procedure Step ID is different for the two procedure steps performed on the modality (original and appended steps). <li>The values in the following fields are the same in the IODs from the original PPS, and in those appended.  Check the Study Instance UID for the first and last image in the study. <ul> <li>Study Instance UID (0020,000D) <li> Also Study Date, Study Time and Study Description attributes are the same in image IODs for the original PPS, and those appended.  </ul> </ul> For the <strong>ABANDONED CASE</strong>, on the <strong>DSS/OF</strong>, verify: <ul> <li>A copy of the N-SET PPS to the DSS/OF (transaction RAD-6) has been captured, eg in [test-case-no]-pps-IP.txt.  Check that: <ul> <li>The value for SPS Status is DISCONTINUED </ul> </ul> For the <strong>ABANDONED CASE</strong>, on the <strong>Image Manager</strong>, find the study for SYS_NAME^ABANDON.  Verify that: <ul> <li>The images objects are successfully stored on the IM.     </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (561, 1, 0, '2009-11-24 10:53:19.072', 'epoiseau', 'See pre-requisite tests. No additional constraints.			  Notes:  JCF 011309 - Need to add prerequisite test: Required: ATNA_Authentication, ATNA_Inquisition (Questionaire section 2), ATNA_Fully_Secured_Node (Test 20)			 JCF 011409 - Added prerequisite test: Required: ATNA_Authentication, ATNA_Inquisition (Questionaire section 2), ATNA_Fully_Secured_Node (Test 20)			 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (562, 1, 0, '2009-11-24 10:53:19.073', 'epoiseau', 'The T81 Test Tool is designed to be used by HIT developers and implementers during the development of software that implements the URL-based implementation of the Conext-aware Information Retrieval (infobutton) standard. These tools can be used for self-testing to determine if a URL is correct with respect to the specifications identified within the following HITSP constructs. <br> <H1>Special Instructions</h1>  For complete information go to http://xreg2.nist.gov:8080/t81/index.html, from this site you can also navigate to example files and other useful information.<br><br>  The test is performed by doing a post to http://xreg2.nist.gov:8080/t81/process.jsp  <H1>Evaluation</H3> This test will require the presence of the monitor who will check that the test has completed without error. ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (563, 1, 0, '2009-11-24 10:53:19.076', 'epoiseau', '<h3>Special Instructions</h3>
 None
 <h3>Description</h3>
 <p>
 TCE_Export tests the entire teaching file /clinical trial export chain from Export Selector to Receiver.
 </p>
 <p>
 The <b>Export Selector</b> should choose three set of objects that will be exported in three separate transactions:
 <ul>
 <li>At least one of those sets of objects should span multiple studies, if the workstation allows it.  
 <li>If selection from multiple studies is not allowed, then at least one set should include objects from multiple series, if the workstation allows it.   
 <li>Also at least one of the sets should include non-image objects (e.g. reports, GSPS objects) in addition to image objects, if such other objects are available.  The set with non-image objects may be the set that includes objects from multiple studies.  </ul>
 The <b>Export Selector</b> should be configured to allow the tester to select or enter a different observer name and a different description for each of the exported sets of objects.  The observers for the three sets of objects shall be:
 <ol>
 <li>Fine^Larry</li>
 <li>Howard^Curly</li>
 <li>Howard^Moe</li>
 </ol>
 The description for the three sets of objects shall be:
 <ol>
 <li>Departmental Cases</li>
 <li>Research Cases</li>
 <li>Personal Cases</li>
 </ol>
 The manifest for the second set of objects (the ones with Curly as the observer with the description "Research Cases" should have the title (TCE002, IHERADTF, ''For Clinical Trial Export'').  At least one of the other two cases should have the title (TCE001, IHERADTF, ''For Teaching File Export'').
 <p>
 If an <b>Export Manager</b> is available for the test, the Export Selector shall route the objects and manifest to the Export Manager.  If no Export Manager is available, then the Export Selector will send the images directly to the Export Receivers.
 </p>
 <p>
 The <b>Export Manager</b>, if present: 
 <ul>
 <li>will be configured to route the set of objects to three different destinations.  
 <li>It will select which destination to send the objects to based on the observer and/or the description in the manifest.  
 <li>The Export Manager will de-identify the objects for Larry and Curly prior to fowarding them.   
 <li>If the Export Selector supports the <i>De-identify Pixel Data Option</i>, this will be demonstrated for the Connectathon Monitor.
 <li>The Export Manager will be configured to not de-identify the object for Moe.
 </ul>
 </p>
 <p>
 Up to three Receivers can participate in this test.  Each receiver will be a different destination configured in the export manager.  If three Receivers are not available, then the routing in the Export Manager will be configured to send to as many receivers as are available, with some receivers doing double or possibly triple duty.
 </p>
 
 <h3>Evaluation</h3>
 <p>
 The Connectathon Monitor will check:
 <ul>
 <li>that each set of objects arrives at the appropriate Receiver, based on the observer and/or description</li>
 <li>each manifest contains instances from only a single patient
 <li>for the RAD-52 transaction (additional objects added to set 1), the Document title is TCE0006 IHERADTF, ''Additional Teaching File Information''
 <li>that the objects (for Larry and Curly, but not Moe) were properly de-identified</li>
 <li>If the Export Receiver does not support all SOP classes referenced in the manifest, then the transfer will partially or completely fail
 </ul>
 </p>
 
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (564, 1, 0, '2009-11-24 10:53:19.079', 'epoiseau', '<p>The purpose of this test is to verify that you system is correctly synchronized with a time server :</p> <p>This test is to be used both by time client and time server</p> <ul> <li> If your system implements the actor <b>Time Client</b> then you need to show the project manager that your system time is within 1 second from the reference local time</li> <li>If your system implements the actor <b>Time Server</b> then you need to show that someone can get the time from you server </li> </ul></p>  <p>In order to validate the test the project manager will ask you to open the following <a href=http://172.30.0.2/europe2005/time_check.php>URL</a>  </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (565, 1, 0, '2009-11-24 10:53:19.081', 'epoiseau', 'See pre-requisite tests. No additional constraints.			  Notes: JCF 011309 - Need to add prerequisite test: Conditional (per KUDU Test): QED_QueryDiagnosticResults, QED_QueryImmunizations, QED_QueryMedications, QED_QueryProblemsAllergies, QED_QueryProfessionalServices, QED_QueryVitalSigns			 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (566, 1, 0, '2009-11-24 10:53:19.082', 'epoiseau', 'Conditional (per KUDU Test): QED_QueryDiagnosticResults, ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (567, 1, 0, '2009-11-24 10:53:19.084', 'epoiseau', 'See pre-requisite tests. No additional constraints.			  Notes: JCF 011309 - Need to add prerequisite test: QED_Preload 			 JCF 011409 - Added prerequisite test: QED_Preload ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (568, 1, 0, '2009-11-24 10:53:19.086', 'epoiseau', 'This test case exercises the typical cath workflow as used in many European hospitals. A patient is directly registered in the cardiology department''s DSS/OF, a worklist is generated for the cathlab, and the diagnostic or interventional procedure starts. Later the patient''s demographics are entered into the ADT system and broadcast through ADT messages. The DSS/OF then reconciles the local patient with the official patient ID and sends a merge (A40) message to the PACS to make sure that the images are also assigned to the correct patient. The DSS/OF then performs HL7 order management with the Order Placer and the Image Manager. Finally the image display retrieves the images and displays them, with the final patient demographics.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (569, 1, 0, '2009-11-24 10:53:19.088', 'epoiseau', '<i>This test case is identical to WORKFLOW_CATH_01, but uses two modalities (cath and hemodynamics) instead of one.</i>  This test case exercises the typical cath workflow as used in many European hospitals. A patient is directly registered in the cardiology department''s DSS/OF, a worklist is generated for the cathlab and hemodynamics, and the diagnostic or interventional procedure starts. Later the patient''s demographics are entered into the ADT system and broadcast through ADT messages. The DSS/OF then reconciles the local patient with the official patient ID and sends a merge (A40) message to the PACS to make sure that the images are also assigned to the correct patient. The DSS/OF then performs HL7 order management with the Order Placer and the Image Manager. Finally the image display retrieves the images and displays them, with the final patient demographics.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (570, 1, 0, '2009-11-24 10:53:19.092', 'epoiseau', 'This test exercises the main demo scenario for DRK 2007: In Virtual Hospital 1,  a patient is admitted, an order placed and filled, and images are created and  archived. The images are then written to a PDI CD. In Virtual Hospital 2, the  same patient arrives later with his/her CD, is admitted (with a different  patient ID), and an order for CD import is placed and filled. The CD is then  imported (IRWF) and reviewed at an Image Display.  <i>For these tests, the modality and IRWF importers always send MPPS messages to the PPS Manager of the Image Manager, which forwards to the Order Filler.</i> The test steps  are<ul> <li><b>Virtual Hospital 1</b> <ul> <li>ADT creates new inpatient <li>Order Placer creates order <li>Order Filler fills order <li>Modality retrieves worklist, acquires images, performs MPPS, Storage and Storage Commitment <li>PMC retrieves and displays images, then creates a PDI CD with these images </ul> <li><b>Virtual Hospital 2</b> <ul> <li>ADT creates new outpatient <li>Order Filler locally creates order for CD import <li>Order Filler performs filler order management (not with RIS Mall as OP) <li>IRWF importer retrieves worklist, imports and reconciles PDI CD <li>IRWF importer stores images, performs MPPS and Storage Commitment <li>Image Display retrieves images from Image Manager and displays them  </ul> </ul><br>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (571, 1, 0, '2009-11-24 10:53:19.094', 'epoiseau', 'This workflow test combines the Displayable Reports integration profile with the intra-departmental access to ECGs (based on the ECG profile), images (optional, based on CATH or ECHO) and evidence documents (optional, CATH, ECHO or ED-CARD). The report creator first creates an unverified report and submits it to the report manager, which verifies/signs the report and forwards the signed version to the report repository. The RRD then retrieves the report from the repository and displays it. In this test case we assume that the RRD is grouped with an ECG Display and possibly a CATH/ECHO Image Display and uses these actors to access and display additional information.  This grouping is not required by the IHE TF but happens to be true for all RRD systems at the European Connectathon 2006. This test also assumes that the report creator is grouped with some other actor that has access to valid patient demographics - this could be an Image Display as indicated in the optional step, but also anything else that provides access to valid Patient IDs. For the purposes of this test case it is not necessary that all objects shown at the RRD (report, ECG, images) are really for the same patient.  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (572, 1, 0, '2009-11-24 10:53:19.095', 'epoiseau', 'This workflow test exercises a standard workflow where the patient is first registered at ADT, the order is placed at Order Placer and filled at DSS/OF. Images are generated on the modality and stored to the IM/IA (includingStorage Commitment). MPPS goes to the Order Filler which operates the PPS Manager and forwards to the IM/IA. Then a patient update is performed (change of patient name, birthdate etc.) at ADT and forwarded to all systems affected. Finally, the images are queried/retrieved and displayed at an Image Display.  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (573, 1, 0, '2009-11-24 10:53:19.097', 'epoiseau', '<i>This workflow test is identical to WORKFLOW_ECHO_01 but uses stress echo (E6) and does not contain a patient update.</i>  This test exercises a standard workflow where the patient is first registered at ADT, the order is placed at Order Placer and filled at DSS/OF. Stress Echo Images are generated on the modality and stored to the IM/IA (includingStorage Commitment). MPPS goes to the Order Filler which operates the PPS Manager and forwards to the IM/IA. Finally, the images are queried/retrieved and displayed at an Image Display.  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (574, 1, 0, '2009-11-24 10:53:19.099', 'epoiseau', 'This test exercises a typical workflow for a mobile Ultrasound modality that is only intermittently connected to the network. The patient is first registered at ADT, but no order is placed. The modality (which is assumed to be off the network at the patient''s bed) directly creates images. The patient ID is entered manually at the modality. When the modality is connected to the network, it starts sending images, MPPS and Storage Commitment to the IM/OF. The IM/OF operates te PPS Manager and forwards to the DSS/OF. Then a local patient reconciliation is performed at the DSS/OF. Filler management is performed at the DSS/OF and an update message is sent to the IM/IA to correct the patient demographics for the patient. Finally, the images are queried/retrieved and displayed at an Image Display.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (575, 1, 0, '2009-11-24 10:53:19.101', 'epoiseau', 'empty description in Kudu');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (576, 1, 0, '2009-11-24 10:53:19.103', 'epoiseau', 'empty description in Kudu');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (577, 1, 0, '2009-11-24 10:53:19.104', 'epoiseau', '<H3>Special Instructions</H3><p>
 <p>This is a complex test to set up.   Do the "XCA_Simple_" Query and Retrieve tests before trying this one.  Initiating Gateways which are grouped with an XDS.b Document Consumer run one instance of this
    test.</p>
 <p>
 <u><strong>Systems needed to run this test:</strong></u>
 </p>
 <p>In the "local/initiating" community (it is permissible choose a systems from the same vendor as the Initiating Gateway):
 <ul>
 <li>Initiating Gateway</li>
 <li>XDS.b. Document Consumer (helping with the test)</li>
 <li>XDS.b Document Registry (helping)</li>
 <li>XDS.b Document Repository (helping)</li>
  </ul>
 <p>In the "remote/responding" community (it is permissible choose Registry/Repository/Source systems from the same vendor as the Responding Gateway):</p>
 <ul>  
 <li>Responding Gateway</li>
 <li>XDS.b Document Source (helping)</li>
 <li>XDS.b Document Registry (helping)</li>
 <li>XDS.b Document Repository (helping)</li>
 </ul>
 
 <p>
    
 <strong>
     <u>Test Configuration:</u>
    </strong>
 </p>
 <ul>
    
 <li>There are 2 communities:'' the ''remote'' and
     ''local'' communities are both XDS.b Affinity Domains.'' The
     ''local'' community contains a Document Consumer, Document Registry and
     Document Repository.'' The Document Consumer configures the Initiating Gateway as its
     Registry/Repository.</li>
    
 <li>The Initiating Gateway''s grouped ''Document Consumer'' must configure its
     local Reg/Rep as a query/retrieve destination.</li>
    
 <li>The Assigning Authority is the same for the Patient IDs in the
     ''remote'' and ''local'' communities.</li>
    
 <li>The HIMSS Registration tool is used to create Patient IDs</li>
 
 </ul>
 <p>
    
 <strong>
     <u>Pre-Test Setup:</u></p>
 <p>(you want documents for one patient in both the local and remote communities):</u>
    </strong>
 <p>
    
 <li>ITI-8 or ITI-44 - Patient Identity Source (HIMSS Registration Tool) sends ID for Patient XCA, Andrew PatID=WIEN5009 to the
     Registry in both the "local" and ''remote'' communities</li>
 <li>Document Sources use PIX or PDQ Query to get Master Patient ID for patient XCA,
     Andrew PatID=WIEN5009</li>
    
 <li>ITI-41 Document Source creates a document for patient XCA^Andrew and sends it to the Repository (Provide & Reg
     Doc Set)</li>
    
 <li>ITI-42 Document Repository registers the document with the Document Registry</li>
    
 <li>Repeat previous 2 steps to have a total of 3 documents available in each remote community for XCA^Andrew.</li>
 </ul>
 </p><H3>Description</H3><p>This test verifies that an Initiating Gateway which is grouped with an XDS.b Document Consumer
    queries and retrieves in its local affinity domain as well as initiating a Cross-Gateway Query
    and Cross-Gateway Retrieve</p><H3>Evaluation</H3><p>On the <strong>Document Consumer </strong>in the Initiating Gateway''s community,
    verify: </p><ul>
    
 <li>The Initiating Gateway returned the requested documents from both its local and the remote
     community.</li>
 </ul>
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (578, 1, 0, '2009-11-24 10:53:19.106', 'epoiseau', '<H3>Special Instructions</H3><p>
 <p>This is a complex test to set up.   Do the "XCA_Simple_" Query and Retrieve tests before trying this one.  Then, you can just add an additional "remote/responding" community to what you already got working in the previous test.</p>
 <p> Each Initiating Gateway should run this test just once. </p>
 <p>
 <u><strong>Systems needed to run this test:</strong></u>
 </p>
 <p>In the "local/initiating" community (it is permissible choose a Consumer system from the same vendor as the Initiating Gateway):
 <ul>
 
 <li>XDS.b. Document Consumer (helping with the test)</li>
    
 <li>Initiating Gateway</li>
  </ul>
 <p>There are two "remote/responding" communities (it is permissible choose Registry/Repository/Source systems from the same vendor as the Responding Gateway):</p>
 <ul>  
 <li>Responding Gateway (2)</li>
 <li>XDS.b Document Source (2) (helping)</li>
 <li>XDS.b Document Registry (2) (helping)</li>
 <li>XDS.b Document Repository (2) (helping)</li>
 </ul>
 <p>
 <p>
    
 <strong>
     <u>Test Configuration:</u>
    </strong>
 </p>
 <ul>
    
 <li>There are 3 communities:'' one ''local/initiating'' and two
     ''remote/responding'' communities, all of which are XDS.b Affinity Domains. The
     ''local'' community only needs a Document Consumer in this test.'' The
     Document Consumer configures the Initiating Gateway as its Registry/Repository.</li>
 <li>To simplify testing, the Assigning Authority is the same for the Patient IDs in the 
     ''remote'' and ''local'' communities.  Use the ''Master'' assigning authority value identified in kudu under Configuration-->XDS Codes/OIDs.</li>
 <li>The HIMSS Registration Tool is used to send the Patient ID for the XCA test patient to the Registries in the ''remote'' community.  Several test patients with last name "XCA" have been created for you in the HIMSS Registration tool.   Refer to <a href="http://ihewiki.wustl.edu/wiki/index.php/Europe_2009#References_.26_Preparation_for_Connectathon_week">the spreadsheet of connectathon patients</a>.</li>
   <li>The XCA profile does not define how the Gateways learn of the Patient IDs.  The Gateways may use the HIMSS Registration Tool to receive an HL7v2 or v3 feed, or do this by some other means.
 </li>
 <li>Two pairs of XDS.b Registries and Repositories are needed to help with this test (and
     the next retrieve test) '' one Registry and Repository will be in the Affinity Domain
     of each of the remote communities.</li>
 </ul>
 
 <p>
    
 <strong>
     <u>Pre-Test Setup:</u>
    </strong>
 
 </p>
 <p>The Gateways ensure they have been configured to know about the XCA test patients.</p>
 <p>In both "remote/responding" communities, set up documents that can be queried:</p>
 <ul>
    
 <li>ITI-8 or ITI-44 - Patient Identity Source (HIMSS Registration Tool)  in ''remote
     community'' sends ID for Patient XCA, Amy PatID=WIEN5008 to the
     Registry in both of the ''remote'' communitiets</li>
 <li>Document Source in remote community uses PIX or PDQ Query to get Master Patient ID for patient XCA,
     Amy PatID=WIEN5008</li>
    
 <li>ITI-41 Document Source creates a document for patient XCA^Amy and sends it to the Repository (Provide & Reg
     Doc Set)</li>
    
 <li>ITI-42 Document Repository registers the document with the Document Registry</li>
    
 <li>Repeat previous 2 steps to have a total of 3 documents available in each remote community for XCA^Amy.</li>
 </ul>
 
 
 
 <H3>Description</H3>
 <p>This tests the ability of the Initiating Gateway to respond to a query request from a Document
    Consumer in its XDS.b affinity domain and to translate the query into a Cross-Gateway Query to
    more than one Reponding Gateway.'' </p>
 <p>This tests the ability of the Responding Gateway respond to an incoming Cross-Gateway Retrieve
    by sending a query request its local Registry and returning the response to the Initiating
    Gateway.</p>
 <p>This tests the ability of the Initiating Gateway to return the query results received from all
    of the Responding Gateways to the Document Consumer it its community.</p>
 <H3>Evaluation</H3>
 <p>On the <strong>Document Consumer </strong>in the Initiating Gateway''s community,
    verify: </p>
 <ul>
    
 <li>A consolidated list of the documents registered in both of the remote Registries for Patient
     ID WIEN5008 displayed</li>
 </ul>
 <p>Ideally, you would have a Doc Consumer query each remote registry separately, showing the individual community''s documents for that patient, and then you query the Initiating Gateway and see a consolidated list.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (579, 1, 0, '2009-11-24 10:53:19.109', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Run test <strong>XCA_Multi_Query_XDS_Option</strong> immediately before running this test.</p> <p> <u><strong>Systems needed to run this test:</strong></u> </p> <ul>     <li>XDS.b. Document Consumer (helping with the test)</li>     <li>Initiating Gateway</li>     <li>Responding Gateway (2)</li>     <li>XDS.b Document Repository (2)</li> </ul> </p><H3>Description</H3><p>This tests the ability of the Initiating Gateway to respond to a retrieve request from a    Document Consumer in its XDS.b affinity domain and to translate the retrieve into a Cross-Gateway    Retrieve to two Responding Gateways.&nbsp; </p><p>This tests the ability of the Responding Gateway respond to an incoming Cross-Gateway Retrieve    by sending a retrieve request its local Repository and returning the response to the Initiating    Gateway.</p><p>This tests the ability of the Initiating Gateway to return the query results received from the    Responding Gateway(s) to the Document Consumer it its community.</p><H3>Evaluation</H3><p>In the first scenario, on the <strong>Document Consumer </strong>in the Initiating    Gateway&rsquo;s community, verify: </p><ul>     <li>The Initiating Gateway returned the requested document from the remote community.&nbsp;     It did NOT request a retrieve from both Responding Gateways.</li> </ul><p>In the second scenario, on the <strong>Document Consumer </strong>in the Initiating    Gateway&rsquo;s community, verify: </p><ul>     <li>The Initiating Gateway returned the requested documents from both communities.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (580, 1, 0, '2009-11-24 10:53:19.111', 'epoiseau', '<H3>Special Instructions</H3> <p>You must successfully test synchronous web services with a testing partner (the XCA_Simple Query and Retrieve tests) before attempting testing asynchronous web services with that partner. The synchronous test must be graded and approved before starting asynchronous tests.</p> <p>Responding Gateways must run this test.  Initiating Gateways which support the Async option must run this test.</p> <H3>Description</H3> <p>This tests Cross-Gateway Query and Retrieve using Asynchronous Web Services.</p> <ol> <li>Test though NIST proxy to allow evaluation of SOAP header attributes necessary for async web services. A NIST proxy (technically a reverse proxy) is running in front of each vendor actor that can accept an asynchronous web service transaction.   Configuration information is available from Bill Majurski.</li> <ul> <li>Configure the sending system (Initiating Gateway) to use the proxy.  This means the message will be sent to nist1:xxxx (where xxxx is the port assigned by NIST) but the HTTP header and the WS:To header will indicate the full target vendor actor endpoint.</li> <li>Confirm your configuration and the readiness of the NIST proxy with Bill Majurski of NIST before initiating the test.</li> <li>Evaluation of your WS: Headers will be done from the proxy console.</li> </ul> <li>Test directly with partner to show proper exchange of data.</li> </ol>  <H3>Evaluation</H3> <ul> <li>Be prepared to show system logs that allow verification of asynchronous nature of exchange.</li> <li>Be prepared to show proper actor operation.</li> </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (581, 1, 0, '2009-11-24 10:53:19.113', 'epoiseau', '<H3>Special Instructions</H3> <p>Each XCA Initiating and Responding Gateway is required to run one instance of this test.  </p> <p>TLS is not used with this test.</p> <H3>Description<H3>   <H3>Evaluation</H3> <p>The NIST tools will run an evaluation on the content of your transactions.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (582, 1, 0, '2009-11-24 10:53:19.115', 'epoiseau', '<H3>Special Instructions</H3><p>
 <p>
 <u><strong>Systems needed to run this test:</strong></u>
 </p>
 <p>In the "local/initiating" community (it is permissible choose a Consumer system from the same vendor as the Initiating Gateway):
 <ul>
 
 <li>XDS.b. Document Consumer (helping with the test)</li>
    
 <li>Initiating Gateway</li>
  </ul>
 <p>In the "remote/responding" community (it is permissible choose Registry/Repository/Source systems from the same vendor as the Responding Gateway):</p>
 <ul>  
 <li>Responding Gateway</li>
 <li>XDS.b Document Source (helping)</li>
 <li>XDS.b Document Registry (helping)</li>
 <li>XDS.b Document Repository (helping)</li>
 </ul>
 <p>
    
 <strong>
     <u>Test Configuration:</u>
    </strong>
 </p>
 <ul>
    
 <li>There are 2 communities:'' the
     ''local/initiating'' and "remote/responding" communities are both XDS.b Affinity Domains.'' The
     ''local'' community only needs a Document Consumer in this test.'' The
     Document Consumer configures the Initiating Gateway as its Registry/Repository.'' The
     ''remote'' community''s Responding Gateway will be configured to query the
     Document Registry and retrieve from the Document Repository in its community.'' In the
     ''remote'' community, a Document Source is needed to submit documents to be
     retrieved.</li>
    
 <li>To simplify testing, the Assigning Authority is the same for the Patient IDs in both the 
     ''remote'' and ''local'' communities.  Use the ''Master'' assigning authority value identified in kudu under Configuration-->XDS Codes/OIDs.</li>
    
 <li>The HIMSS Registration Tool is used to send the Patient ID for the XCA test patient to the Registry in the ''remote'' community.  Several test patients with last name "XCA" have been created for you in the HIMSS Registration tool.   Refer to <a href="http://ihewiki.wustl.edu/wiki/index.php/Europe_2009#References_.26_Preparation_for_Connectathon_week">the spreadsheet of connectathon patients</a>.</li>
   <li>The XCA profile does not define how the Gateways learn of the Patient IDs.  The Gateways may use the HIMSS Registration Tool to receive an HL7v2 or v3 feed, or do this by some other means.
 </li>
    
 
    
 <li>The NIST Registry may serve as the XDS.b Document Registry in the
     ''remote'' community</li>
 </ul>
 <p>
    
 <strong>
     <u>Pre-Test Setup:</u>
    </strong>
 </p>
 <p>The Gateways need to know <a href="http://ihewiki.wustl.edu/wiki/index.php/Vienna2009-XDS_homeCommunityId_OIDs#Vienna_2009_Connectathon:_homeCommunityId_OID_values_for_XCA_Gateways"> the value of their own homeCommunityId OID</a>. 
 <p>The Gateways ensure they have been configured to know about the XCA test patients.</p>
 <p>In the "remote/responding" community, set up documents that can be queried:</p>
 <ul>
    
 <li>ITI-8 or ITI-44 - Patient Identity Source (HIMSS Registration Tool)'' in ''remote
     community'' sends ID for Patient XCA, Alexander PatID=WIEN5007 to the
     Registry in the ''remote community''</li>
 <li>Document Source in remote community uses PIX or PDQ Query to get Master Patient ID for patient XCA,
     Alexander PatID=WIEN5007</li>
    
 <li>ITI-41 Document Source creates a document for patietn XCA^Alexander and sends it to the Repository (Provide & Reg
     Doc Set)</li>
    
 <li>ITI-42 Document Repository registers the document with the Document Registry</li>
    
 <li>Repeat previous 2 steps to send a total of 3 documents.</li>
 </ul>
 </p>
 <H3>Description</H3>
 <p>This tests the ability of the Initiating Gateway to respond to a query from a Document Consumer
    in its XDS.b affinity domain, recognize the Patient ID, and to translate the query into a Cross-Gateway Query to a
    single Reponding Gateway.'' </p>
 <p>This tests the ability of the Responding Gateway respond to an incoming Cross-Gateway Query by
    querying its local Registry and returning the response to the Initiating Gateway.</p>
 <p>This tests the ability of the Initiating Gateway to return the query results received from the
    Responding Gateway to the Document Consumer it its community</p>
 <H3>Evaluation</H3>
 <p>On the <strong>Document Consumer </strong>in the Initiating Gateway''s community,
    verify (you should witness the query/response real-time): </p><ul>
    
 <li>A list of the documents registered in the remote Registry for Patient ID WIEN5007 
 (XUA^Alexander is
    displayed</li>
 </ul>
 <p>Verify:</p>
 <ul>
    
 <li>When the Initiating Gateway responds to a query for a patient it does not know about, it
     responds with a list of no matching documents, but not an error.</li>
 </ul>
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (583, 1, 0, '2009-11-24 10:53:19.118', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Run test <b>XCA_Simple_Query_XDS_Option</b> immediately before running this test.</p> <p> <u><strong>Systems needed to run this test:</strong></u> </p> <ul>     <li>XDS.b. Document Consumer (helping with the test)</li>     <li>Initiating Gateway</li>     <li>Responding Gateway</li>     <li>XDS.b Document Repository (helping)</li> </ul> </p><H3>Description</H3><p>This tests the ability of the Initiating Gateway to respond to a retrieve request from a    Document Consumer in its XDS.b affinity domain and to translate the retrieve into a Cross-Gateway    Retrieve to a single Responding Gateway.&nbsp; </p><p>This tests the ability of the Responding Gateway respond to an incoming Cross-Gateway Retrieve    by sending a retrieve request to its local Repository and returning the response to the    Initiating Gateway.</p><p>This tests the ability of the Initiating Gateway to return the retrieve results received from    the Responding Gateway to the Document Consumer in its community.</p><H3>Evaluation</H3><p>On the <strong>Document Consumer </strong>in the Initiating Gateway&rsquo;s community,    verify: </p><ul>     <li>The Initiating Gateway returned the requested document(s).</li>     <li>Verify the retrieve of both 1 document and of 2 or more.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (584, 1, 0, '2009-11-24 10:53:19.119', 'epoiseau', '<h3>Special Instructions</h3> None. <h3>Description</h3> <p>One assigned Connectathon Monitor will be assigned to  scrutinize XDLAB 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 XDLAB_Load test. <br />   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.<br />   This test needs to be completed by Day 2 at 12:00, and is better completed the afternoon of  Day 1 if possible. This will give downstream Content Consumers better 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>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 (585, 1, 0, '2009-11-24 10:53:19.121', '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 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^XDLAB. Use the RIS Mall or HIMSS Registration Tool to register this  patient and obtain a patient identifier.<br />   Create the appropriate document for the XDLAB 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 XDLAB document. We recognize that not  all renderings will be the same.</li>   <li>Name  the document XDLAB_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 XDLAB document. </li> </ol> <h3>Evaluation</h3> <p>This will be evaluated with the XDLAB_Document_Scrutiny and  XDLAB_Process_XDLAB tests.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (586, 1, 0, '2009-11-24 10:53:19.123', 'epoiseau', 'empty description in Kudu');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (587, 1, 0, '2009-11-24 10:53:19.125', '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 XDLAB  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 3: 3.3</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 XDLAB Integration Profile.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (588, 1, 0, '2009-11-24 10:53:19.127', 'epoiseau', 'empty description in Kudu');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (589, 1, 0, '2009-11-24 10:53:19.128', 'epoiseau', '<H3>Special Instructions</H3> You can test with any Audit Record Repository.  Please note your partner in the chat window for this test. <H3>Description</H3> This tests the Portable Media Creator''s ability to audit the export of PHI. <H3>Evaluation</H3> The Connectathon Monitory will verify that the Audit Record Repository received an audit record for the export event by viewing the received message..  <p>If the media exported contained submission sets for more than one patient, there should be one audit record per patient. </p> <p>Monitors and PMC systems should note the following from ITI TF-2:3.32.4.1.5:  "It is easy to build a partial implementation in the XDM profile that lacks the auditing capability.  For example, a person can manually create media that comply with the requirements of the XDM media.  It is possible that the manual process omits the generation of audit records for their activity.  This would not be a compliant or complete implementation of the actors, but it is easy to make this kind of mistake."</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (590, 1, 0, '2009-11-24 10:53:19.13', 'epoiseau', '<H3>Special Instructions</H3> You can test with any Audit Record Repository.  Please note your partner in the chat window for this test. <H3>Description</H3> This tests the Portable Media Importer''s ability to audit the import of PHI. <H3>Evaluation</H3> The Connectathon Monitory will verify that the Audit Record Repository received an audit record for the export event by viewing the received message..   <p> If the media imported contained submission sets for more than one patient, there should be one audit record per patient. </p> <p>Monitors and PMC systems should note the following from ITI TF-2:3.32.4.1.5:  "It is easy to build a partial implementation in the XDM profile that lacks the auditing capability.  For example, a person can manually create media that comply with the requirements of the XDM media.  It is possible that the manual process omits the generation of audit records for their activity.  This would not be a compliant or complete implementation of the actors, but it is easy to make this kind of mistake."</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (591, 1, 0, '2009-11-24 10:53:19.132', 'epoiseau', '<H3>Special Instructions</H3> Portable Media Creators who support the CD-R option run one instance of this test. <p>You may want to run test <b>XDM_Audit_Export</b> at the same time. </p> <H3>Description</H3> This test case is used to create XDM-formatted media.  It will be used by Portable Media Importers in test <b>XDM_CD-R_Import</b>. <H3>Evaluation</H3> The Connectathon Monitor will ask you: <ul> <li>which IHE content profiles you support as a creator  <li>whether you can create multi-part documents in your submission sets  <li>whether you can include more than one submission set per media <li>whether you support the Web Content option of the PDI profile </ul> <p> The Connectathon Monitor will then examine your media sample for the following characteristics: </p> <ul> <li>The media may not be CD-RW <li>The media is 120mm CD-R <li>There is no autorun or equivalent file in the root directory of the media <li>README.TXT is present at the root level of the media.   The README.TXT will contain <ul> <li>Contact info on the institution that created the media <li>Information regarding the application that created the media <li>Contact information of the vendor of the application that created the media <li>General information about the overall organization of the media  <li>(optionally, if a Media Viewer is contained) OS supported; name of the product application and software version; contact information of the vendor that provided the Media Viewer; disclaimer about the intended usage of the application; list of minimum requirements  </ul> <li>INDEX.HTM is present at the root level and contains properly formatted XHTML.  This file will contain: <ul> <li>Patient ID and demographics (submission sets on the media may belong to one or more patients) <li>Source Facility information </ul> <li>The root directory contains a folder IHE_XDM.  <li>IHE_XDM folder contains one or more subfolders for the contents of the submission sets.  <li>The subfolder(s) each contain the file METADATA.XML  <li>The subfolder(s) may contain  <p>- one or more files  that are the single-part document(s) referenced by the METADATA.XML </p> <p>- one or more sub-directory for each multi-part document</p> <li>File names are restricted to eight characters with a three-character extension, upper case letters, numbers and underscore; maximum depth of directories is eight. <li>The submission set(s) contain one or more samples of each IHE content profile the Portable Media Creator system supports. </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (592, 1, 0, '2009-11-24 10:53:19.134', 'epoiseau', '<H3>Special Instructions</H3> This test is only for systems which support the CD-R Option in the XDM profile. <p>A spreadsheet illustrates the options supported by XDM Portable Media Creator and Portable Media Importer systems in the Feb 09 NA Connectathon, as well as the IHE Content profiles supported by the PMC actors who are creating XDM media.</p>  Access the <a  href=http://ihewiki.wustl.edu/wiki/index.php/North_America_2009#Feb_23-27.2C_2009:_Connectathon_Week_Survival >''partners'' spreadsheet</a>.   <p> The Importer system must find a Portable Media Creator who supports content that you support, and is required to  demonstrate some form of ''processing of medical data'' in the types of documents  it is designed to support.</p>  You may want to run test <b>XDM_Audit_Import</b> at the same time. <H3>Description</H3> This test case is used to import XDM-formatted media created by Portable Media Creators in test <b>XDM_CD-R_Creation</b>.  Connectathon Monitors have collected sample media from Portable Media Creators.   <p> </p> <H3>Evaluation</H3> The Connectathon Monitor verifies that: <ul> <li>Supported documents are successfully imported into the system.  The operator of the Importer system may demonstrate this by various means, eg displaying the imported document (after the media has been removed from the system); displaying contents from the imported file(s) in the system''s database <li>The Importer system can demonstrate some form of ''processing of medical data'' in the types of documents it is designed to support.  Ie it is not sufficient to just write the imported document to the Importer system''s hard disk. <li>Referring to the spreadsheet in the ''Special Instructions'' section, the Portable Media Importer must demonstrate successful import and processing for each supported document type. <li>The Importer has a method for verifying the integrity of the media by comparing the size and hash values of the entries in METADATA.XML to the relevant submission set directory(ies).   ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (593, 1, 0, '2009-11-24 10:53:19.136', 'epoiseau', '<H3>Special Instructions</H3> Portable Media Creators who support the <b>USB option</b> run one instance of this test. <p>You may want to run test XDM_Audit_Export at the same time. </p> <H3>Description</H3> This test case is used to create XDM-formatted media.  It will be used by Portable Media Importers in test <b>XDM_USB_Import</b>. <H3>Evaluation</H3> The Connectathon Monitor will ask you: <ul> <li>which IHE content profiles you support as a creator  <li>whether you can create multi-part documents in your submission sets  <li>whether you can include more than one submission set per media <li>whether you support the Web Content option of the PDI profile </ul> <p> The Connectathon Monitor will then examine your media sample for the following characteristics: </p> <ul> <li>There is no autorun or equivalent file in the root directory of the media <li>README.TXT is present at the root level of the media.   The README.TXT will contain <ul> <li>Contact info on the institution that created the media <li>Information regarding the application that created the media <li>Contact information of the vendor of the application that created the media <li>General information about the overall organization of the media  <li>(optionally, if a Media Viewer is contained) OS supported; name of the product application and software version; contact information of the vendor that provided the Media Viewer; disclaimer about the intended usage of the application; list of minimum requirements  </ul> <li>INDEX.HTM is present at the root level and contains properly formatted XHTML.  This file will contain: <ul> <li>Patient ID and demographics (submission sets on the media may belong to one or more patients) <li>Source Facility information </ul> <li>The root directory contains a folder IHE_XDM.  <li>IHE_XDM folder contains one or more subfolders for the contents of the submission sets.  <li>The subfolder(s) each contain the file METADATA.XML  <li>The subfolder(s) may contain  <p>- one or more files  that are the single-part document(s) referenced by the METADATA.XML  </p> <p>- one or more sub-directory for each multi-part document </p> <li>File names are restricted to eight characters with a three-character extension, upper case letters, numbers and underscore; maximum depth of directories is eight. <li>The submission set(s) contain one or more samples of each IHE content profile the Portable Media Creator system supports. </ul> <p> If your system supports the Web Content option of the PDI profile, the Connectathon Monitor will examine the INDEX.HTM file to ensure it contains: </p> <ul> <li>an informative header with:  identification of the institution that contained the interchange media, and (optionally) a privacy/security disclaimer <li>a link to an entry point for accessing the web content of the IHE_PDI directory <li>a link to the README.TXT file <li>a link to  additional non-restricted data (if it exists) <li>a manifest which lists the data that can  be imported by a Portable Media Importer (ie all DICOM content on the media) <li>a manifest which lists any patient-related data contained on the CD that cannot be imported <li>a link to a launch point for a DICOM Viewer (if present) </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (594, 1, 0, '2009-11-24 10:53:19.139', 'epoiseau', '<H3>Special Instructions</H3> This test is only for systems which support the USB Option in the XDM profile. <p>A spreadsheet illustrates the options supported by XDM Portable Media Creator and Portable Media Importer systems in the Feb 09 NA Connectathon, as well as the IHE Content profiles supported by the PMC actors who are creating XDM media.</p>  Access the <a  href=http://ihewiki.wustl.edu/wiki/index.php/North_America_2009#Feb_23-27.2C_2009:_Connectathon_Week_Survival >''partners'' spreadsheet</a>.   <p> The Importer system must find a Portable Media Creator who supports content that you support, and is required to  demonstrate some form of ''processing of medical data'' in the types of documents  it is designed to support.</p>   <p> You may want to run test <b>XDM_Audit_Import</b> at the same time. </p> <H3>Description</H3> This test case is used to import XDM-formatted media created by Portable Media Creators in test <b>XDM_USB_Creation</b>.  Connectathon Monitors have collected sample media from Portable Media Creators.   <p> </p> <H3>Evaluation</H3> The Connectathon Monitor verifies that: <ul> <li>Supported documents are successfully imported into the system.  The operator of the Importer system may demonstrate this by various means, eg displaying the imported document (after the media has been removed from the system); displaying contents from the imported file(s) in the system''s database <li>The Importer system can demonstrate some form of ''processing of medical data'' in the types of documents it is designed to support.  Ie it is not sufficient to just write the imported document to the Importer system''s hard disk. <li>Referring to the spreadsheet in the ''Special Instructions'' section, the Portable Media Importer must demonstrate successful import and processing for each supported document type. <li>The Importer has a method for verifying the integrity of the media by comparing the size and hash values of the entries in METADATA.XML to the relevant submission set directory(ies).   ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (595, 1, 0, '2009-11-24 10:53:19.141', 'epoiseau', '<H3>Special Instructions</H3> This test is only for systems which support the <b>Zip over Email</b> Option in the XDM profile. <p>For the purpose of XDM testing at the connectathon, the Portable Media Importer will create an email account and share the email address with the Portable Media Creator. This can be a gmail account, for example. If the systems support the <g>Zip over Email Response</b> option, the PMC would need to have an email account as well.</p> <p>A spreadsheet illustrates the options supported by XDM Portable Media Creator and Portable Media Importer systems in the Feb 09 NA Connectathon, as well as the IHE Content profiles supported by the PMC actors who are creating XDM media.</p>  Access the <a  href=http://ihewiki.wustl.edu/wiki/index.php/North_America_2009#Feb_23-27.2C_2009:_Connectathon_Week_Survival >''partners'' spreadsheet</a>.   <p> The Importer system must find a Portable Media Creator who supports content that you support, and is required to  demonstrate some form of ''processing of medical data'' in the types of documents  it is designed to support.</p>   <p> You may want to run tests <b>XDM_Audit_Export</b> and <b>XDM_Audit_Import</b> at the same time. </p> <H3>Description</H3> This test case is used to create XDM-formatted media in a ZIP file and send if via secure email per the XDM profile. <H3>Evaluation</H3> <p>The Connectathon monitor will visit the <b>Portable Media Creator</b> system and watch it create a zip file.  Before it is sent via email, verify:</p>  <ol> <li>README.TXT is present at the root level in the ZIP file.   The README.TXT will contain <ul> <li>Contact info on the institution that created the media <li>Information regarding the application that created the media <li>Contact information of the vendor of the application that created the media <li>General information about the overall organization of the media  <li>(optionally, if a Media Viewer is contained) OS supported; name of the product application and software version; contact information of the vendor that provided the Media Viewer; disclaimer about the intended usage of the application; list of minimum requirements  </ul> <li>INDEX.HTM is present at the root level and contains properly formatted XHTML.  This file will contain: <ul> <li>Patient ID and demographics (submission sets on the media may belong to one or more patients) <li>Source Facility information </ul> <li>The root directory contains a folder IHE_XDM.  <li>IHE_XDM folder contains one or more subfolders for the contents of the submission sets.  <li>The subfolder(s) each contain the file METADATA.XML  <li>The subfolder(s) may contain  <p>- one or more files  that are the single-part document(s) referenced by the METADATA.XML  </p> <p>- one or more sub-directory for each multi-part document </p> <li>File names are restricted to eight characters with a three-character extension, upper case letters, numbers and underscore; maximum depth of directories is eight. <li>The submission set(s) contain one or more samples of each IHE content profile the Portable Media Creator system supports. </ul> </ol> <p>Then the connectathon monitor will observe the zip file being sent as an email attachment to the PMI.  You can verify the secure email settings in the email set up on the PMC.</p> <p>Verify that the email:</p> <ol> <li>is secured by S/MIME</li> <li>is encrypted using AES</li> <li>is digitally signed by the PMC system</li> </ol>   The Connectathon Monitor will then visit the <b>Portable Media Importer</b> system to verify that: <ol> <li>The email is received.  The subject line of the email must contain <b>"XDM/1.0/DDM"</b>. <li>It is able to successfully retrieve the email and open the zip file attachment. <li>Supported documents are successfully imported into the system.  The operator of the Importer system may demonstrate this by various means, eg displaying the imported document (after the media has been removed from the system); displaying contents from the imported file(s) in the system''s database <li>The Importer system can demonstrate some form of ''processing of medical data'' in the types of documents it is designed to support.  Ie it is not sufficient to just write the imported document to the Importer system''s hard disk. <li>Referring to the spreadsheet in the ''Special Instructions'' section, the Portable Media Importer must demonstrate successful import and processing for each supported document type. <li>The Importer has a method for verifying the integrity of the media by comparing the size and hash values of the entries in METADATA.XML to the relevant submission set directory(ies).   </ol>  <p> Finallly, if both systems support the <b>Zip over Email Response</b>, the connectathon monitor will verify on the PMC that it received an acknowledgement email indicating success.  The error case is not tested here.</p>    ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (596, 1, 0, '2009-11-24 10:53:19.143', 'epoiseau', '<h3>Special Instructions</h3> <p>None</p> <h3>Description</h3> <p>This is a test of the ITI-41 transaction directly between a Document Source and Document Recipient.   A Document Source supplies at least one document and submits  that document to a Document Recipient. This test covers a single submission set  and a single document.</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>   <h3>Evaluation</h3> <p>The Connectathon monitor will visit the Document Recipient  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>The monitor should examine the XDS meta-data that was  transmitted as part of the document.</p>  <p>The monitor will ask the Document Recipient to show  evidence the document was received and processed.</p> <p>The Connectathon monitor will ask the Doc Source if it support sending multiple documents in one submission set.  If so, ask the Doc Source to demonstrate this functionality and ensure they''re received on the Document Recipient system.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (597, 1, 0, '2009-11-24 10:53:19.146', 'epoiseau', '<h3>Special Instructions</h3> <p>If you do not support Offline mode, do not perform this  test.</p> <h3>Description</h3> <p>The XDR_Offline_Transmission test is a test of ITI  transaction 15 using the offline transmission option (SMTP). A Document Source  supplies at least one document and submits that document to a Document Recipient.  This test covers a single submission set and a single document; options on the  Document Source are covered in different tests.</p>  <p>This test shall be run over an unsecured network using the  email system of your choice. Plagiarizing from the ITI TF: <ul>   <li>This test will use the cyphersuite:  S/MIME_RSA_WITH_AES_128_CBC_SHA</li>   <li>The email shall be digitally signed by the  sender, by&nbsp; one level detached signature,  applied BEFORE the encryption. This digitla signature shall be interpreted to  mean that the sender is attesting to their authorization to disclose the  information to the intended recipient(s).</li>   <li>As explained in S/MIME, the sender will generate  a unique session key, encrypt the payload of the message using the symmetrical  AES algorithm, encrypt the key using the RSA asymmetrical algorithm with each  one of the receiver(s) public key and attach the result to the message. Each  one of the receiver(s) will decrypt this result using its private key, revealing  the session key, and decrypt the payload of the message.</li> </ul> </p>  <h3>Evaluation</h3> <p>The Connectathon monitor will visit the Document Recipient  and examine log files looking for evidence that the document was successfully transmitted  and extracted. The monitor should ask the Recipient to show the email interface  with the received mail and look for these items:  <ul>   <li>From: e-mail address (no specific value)</li>   <li>To: e-mail address (no specific value)</li>   <li>Date: reasonable value</li>   <li>Subject: Must start with XDS/1.0/PnR. Shall not  contain PHI</li>  </ul> </p> <p>Monitor should also ask Document Recipient to show evidence  that the transmitted document was properly signed and the proper cyphersuite  was used.</p> <p>The monitor should examine the XDS meta-data that was  transmitted as part of the document.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (598, 1, 0, '2009-11-24 10:53:19.148', 'epoiseau', '<h3>Special Instructions</h3> <p>If you do not support Online mode (HTTP/SOAP), do not perform this  test.</p> <h3>Description</h3> <p>The XDR_Online_Transmission test is a test of ITI  transaction 15. A Document Source supplies at least one document and submits  that document to a Document Recipient. 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>  <h3>Evaluation</h3> <p>The Connectathon monitor will visit the Document Recipient  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>The monitor should examine the XDS meta-data that was  transmitted as part of the document.</p>  <p>The monitor will ask the Document Recipient to show  evidence the document was received and processed.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (599, 1, 0, '2009-11-24 10:53:19.149', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You shall run this test using TLS communication.</p> <p>Document Consumers should use the  Connectathon Images/CDs/Objects page to find documents registered by Doc Sources.  See:  <em><a href=system_con_object.php>Objects Information</a>. .</em></p> <p>ATNA audit logs for all XDS tests should be pointed at the NIST Audit Log Relay</p> </p><H3>Description</H3><p>The <strong>XDS_Consumer_Query_Retrieve</strong> test exercises the XDS profile from the    viewpoint of the XDS Document 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><p>The Document Consumer that is tested is required to make at least one query of the Document    Registry. The format of that query is not specified. The Technical Framework defines many    options. </p><p>For evaluation, the Connectathon monitor should observe the query and retrieve process at the    Document Consumer actor. The Document Registry or Repository will only be examined in the event    of anomalies.</p><H3>Evaluation</H3><p>On the <strong>Document Consumer</strong>, the Connectathon monitor will observe query and    retrieve in real time and observe logs or other evidence that both transactions took place using    TLS communcation. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (600, 1, 0, '2009-11-24 10:53:19.151', 'epoiseau', '<H3>Special Instructions</H3><p>
 <p>
    
 <em>Note 1:'' Document Source systems which do not produce their own documents (ie
     operate as middleware) must come to Connectathon prepared to create documents for specific
     patients as specified in all XDS tests. A Document Source system will be required to generate
     documents on demand using patients specified by the test instructions. </em>
 </p>
 
 <p>ATNA audit logs for all XDS tests should be pointed at the NIST Audit Log Relay</p>
 <p>This is a difficult test because it requires the attention of three systems:</p>
 <ul>
    
 <li>Document Source</li>
    
 <li>Document Repository</li>
    
 <li>Document Registry</li>
 </ul>
 <p>We provide no guidance on whether you work first on the link that starts with the Document
    Source or the link that ends with the Document Registry. In the end, you have to demonstrate end
    to end operation.</p>
 <p>At the end of this test, we want you to update a common place in Kudu to store information
    about the document that was stored. This will facilitate query operations by Document Consumers.</p>
 <p>This test requires the Document Source to use a patient name that will allow the monitors to
    more easily find the Source''s documents in the Registries and Repositories. </p>
 </p>
 <H3>Description</H3>
 <p>The<strong> XDS_Doc_Source_Stores_</strong>Document test is a test of ITI transactions 15 and
    14. A Document Source supplies at least one document and submits that document to a Document
    Repository. This test covers a single submission set and a single document; options on the
    Document Source are covered in different tests.</p><p>ITI-15 is tightly coupled to ITI-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 must record reference information in the Kudu tool that will help Doc Consumers find your document under Connectathon Images/CDs/Objects.
 The link to that page is <em><a href=system_con_object.php>Objects Information</a>. .</em>  You''ll be prompted for several values to provide.</p>
 
 
 <p>If the connectathon monitor does not find the document referenced by the Submission Set
    uniqueID, the test will fail.</p><p>If the connectathon monitor finds multiple instances of the Submission Set uniqueID in this
    registry or other registries, the test will fail.</p><p>You need to create unique Submission Set uniqueIDs for all submissions during the connectathon.
    The Monitor may ask for evidence/logs that you ran this test or ask you to run the test again in
    person.</p><p>As you complete the test, you should record log information/evidence in the Kudu chat window
    for this instance of the test. That would allow you to quickly show the Monitor your log
   data.</p>
 
 <H3>Evaluation</H3>
 
 <p>Evaluation is done in two phases. In the <b>first phase</b>, one Connectathon monitor will visit the
    systems and examine the log files looking for evidence that the transactions were carried out
    using TLS. The Connectathon monitor may ask you to repeat the test.</p>
  <p><u>Logging Requirements (ITI TF-2:3.14.5.2 & 3.15.6.1)</u></p>
 <ul>
 <li>For ITI-15 (Provide & Register), the Doc Source will log an "Export" event containing the Patient ID and the submissionSet uniqueID from the document metadata (among other fields)</li>
 <li>For ITI-15 (Provide & Register), the Doc Repository will log an "Import" event containing the Patient ID and the submissionSet uniqueID from the document metadata (among other fields)</li>
 <li>For ITI-14 (Register Doc), the Doc Repository will log an "Export" event containing the Patient ID and the submissionSet uniqueID from the document metadata (among other fields).</li>
 <li>For ITI-14 (Register Doc), the Doc Repository will log an "Import" event containing the Patient ID in the document metadata (among other fields).</li>
 </ul>
 
 <p>Once the security requirements are confirmed, the monitor will set the state to partially verified.</p>
 
 <p>The <b>second part of the evaluation</b> 
  will be a query run against the Registry to determine if the
    Submission Set IDs can be found and if there are multiple copies of that value. This will be
    followed by a retrieval of the registered documents.'' The URL must indicate TLS
    (https://). </p><p>Finally, if the documents produced by the Document Source system do not conform to one of the
    IHE content profiles, the Connectathon monitor will verify that the documents produced by this
    system, ''comply with a published healthcare standard, including wrapping support of
    such generic electronic formats.'' Unstructured data, such as text files, proprietary
    document formats (eg RTF), or images, shall be encapsulated within a standard document
    format'''' (Ref ITI TF-1: 10.4.2).</p>
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (601, 1, 0, '2009-11-24 10:53:19.155', 'epoiseau', '<H3>Special Instructions</H3><p>
 <p>The Document  Registry and Document Repository systems should complete test  <b>XDS_Doc_Source_Stores_Document</b> before doing this test.</p>
 <p>Document Registry and Document Repository systems should do <b><u>one instance</u></b> of this test.  Document Sources are identified as an optional actor because they have a helping role in this test.</p>
 </p><H3>Description</H3
 ><p>This tests errors  reported for ITI-14 Register Document Set.   The Registry actor and Repository actor are required to report errors  using a defined set of codes in <b>ITI TF-2: 4.1.13  </b></p>
 <p>This tests a small  subset of the error conditions, but Connectathon monitors will be watching for  other error conditions which occur during the course of Connectathon testing  and may check error codes for those cases as well.  Success or failure to properly report errors  in any of those conditions are part of this test.</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>The Connectathon  monitor will evaluation two error conditions:</p>
 <p>1. The Document Source submitted a document for a  patient that was not known to the Registry.</p>
 <p>
    The error reported by the Registry should look like this <em>(the value for errorCode must match, but the contents of codeContext is  not mandated by the Technical Framework and may be implementation-specific;  this contains a sample of a possible value)</em>:  </p><strong>
 <p><RegistryResponse 
         xmlns="urn:oasis:names:tc:ebxml-regrep:registry:xsd:2.1" 
         status="Failure"></p>
 <p>    <RegistryErrorList></p>
 <p>    <RegistryError </p>
 <p>         errorCode="XdsUnknownPatientId" </p>
 <p>        codeContext="Patient ID is not  known to the registry"</p>
 <p>        location="" </p>
 <p>        severity="Error"/></p>
 </strong><p> </p><p>2. (optional steps) The Document Repository failed to connect to the  Document Registry.</p><p>The error reported by the Repository should look like this <em>(the value for errorCode must match, but the contents of codeContext is  not mandated by the Technical Framework and may be implementation-specific;  this contains a sample of a possible value)</em>:  </p><strong>
 <p>  <RegistryResponse </p>
 <p>     xmlns="urn:oasis:names:tc:ebxml-regrep:registry:xsd:2.1" 
        status="Failure"></p>
 <p>    <RegistryErrorList></p>
 <p>    <RegistryError </p>
 <p>        errorCode="XdsRegistryNotAvailable" </p>
 <p>        codeContext="Unable to connect to  the Registry to register document"</p>
 <p>        location="" </p>
 <p>        severity="Error"/></p>
 </strong>
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (602, 1, 0, '2009-11-24 10:53:19.159', 'epoiseau', '<H3>Special Instructions</H3> <p>XDS.a Document Registries must **pass** test <b>XDS.a_Registry_Folder_Handling</b> with the NIST Toolkit before it runs this test. </p> <p>A Document Repository is identified as an optional actor in this test because it is needed to help, but has no functionality which is evaluated in this test.</p> <p>ATNA audit logs for all XDS tests should be pointed at the NIST Audit Log Relay</p>  <H3>Description</H3> <p>XDS Document Repository actors are  required to support Folder Management. This is optional for Document Source and  Integrated Document Source/Repository actors. In this test, we use a Document  Source that supports this option.</p> <p>In the test steps below, we will use one patient created  in the HIMSS Registration Tool or by a Patient Identity Source. The patient name is a  composite of the Document Registry and Document Repository (or  Registry/Repository) actors'' kudu system name using the following convention:</p>  <ul> <li>REGISTRY^REPOSITORY^FOLDER; first name of FOLDER stands for Folder Management</li> </ul> <H3>Evaluation</H3> <p>Connectathon monitor will examine log files and database entries of the Document Repository and Document Registry to look for evidence of documents in folders. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (603, 1, 0, '2009-11-24 10:53:19.161', 'epoiseau', '<H3>Special Instructions</H3><p> <p>What was previously known as the &ldquo;Document Lifecycle option&rdquo; for XDS Document Source actors and    Integrated Document Source/Repository actors is now split into separate options: &ldquo;Document    Replace&rdquo;, &ldquo;Document Addendum&rdquo; and &ldquo;Document Transformation&rdquo;. </p> <p>We also test the Folder Management option.</p> <p>In this test, we use an Integrated Document Source/Repository that supports one or more these    options. If no such system is available, the Document Registry and Document Repository should use    a test tool (eg. NIST) designed to test specifically for these features.</p> </p><H3>Description</H3><p>A system that groups a Document Registry and Document Repository must execute this test with a    Document Repository from a different vendor. 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 created from the    kudu system name of the Integrated Source/Repository using the following convention:</p><ul>     <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><p>It is likely that a Connectathon monitor will be assigned to find participants who support    these options, visit these system to run the tests, and record pass/fail on a spreadsheet. </p><p>Connectathon monitor will examine log files and database entries of the Integrated    Source/Repository and Document Registry to look for evidence of documents. Alternatively, use a    Document Consumer to retrieve the documents.</p><ul>     <li>For the first document, in the append and transform case, the status of the original document     remains unchanged (approved).</li>     <li>For the second document, in the replacement case, the status of original document, and the     addendum and replacement, should be deprecated.&nbsp; The replacement version of the     document is approved, and is returned in response to a retrieve.</li> </ul><p>If Folder Management is supported, the Connectathon monitor will examine log files and database    entries of the Integrated Document Source/Repository and Document Registry to look for evidence    of documents in folders. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (604, 1, 0, '2009-11-24 10:53:19.164', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test should be driven by the Integrated Document Source/Repository actor. You should know    which documents you have loaded into your system and where they are registered. 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>ATNA audit logs for all XDS tests should be pointed at the NIST Audit Log Relay.</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 the Integrated    Document Source/Repository.</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> </p><H3>Description</H3><p>An Integrated Document Source/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 Integrated Document Source/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><p>Connectathon monitor will observe the Document Consumer while it queries for and retrieves a    document from the Integrated Document Source/ Repository. Monitor will observe logs or other    information indicating the communication takes place using ATNA TLS communication.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (605, 1, 0, '2009-11-24 10:53:19.166', 'epoiseau', '<H3>Special Instructions</H3><p> <p>ATNA audit log messages for all XDS tests should be pointed at the NIST Audit Log Relay.</p> </p><H3>Description</H3><p>The XDS_ Integrated Source_Repository_Registers_Document  test is a test of ITI transaction 14. ''An    Integrated Source/Repository supplies  at least one document and registers that document with a Document Regist ry.  This test covers a single submission set and a single document; options on the  Integrated Document Source/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>  <p>When you have completed this test, you must record reference information in the Kudu tool that will help Doc Consumers find your document under Connectathon Images/CDs/Objects. The link to that page is <em><a href=system_con_object.php>Objects Information</a>. .</em>  You''ll be prompted for several values to provide.</p>   <p>If the connectathon monitor does not find the document  referenced by the Submission Set uniqueID, the test will fail.</p><p>If the connectathon monitor finds multiple instances of  the Submission Set uniqueID in this registry or other registries, the test will  fail.</p><p>You need to create unique Submission Set uniqueIDs for all  submissions during the connectathon.</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 verified.</p><p>The second part of the evaluation will be a query run against the Registry to determine if the    Submission Set IDs can be found and if there are multiple copies of that value. This will be    followed by a retrieval of the registered documents.'' The URI must indicate TLS    (https://). </p><p>Finally, if the documents produced by the Integrated Source/Repository system do not conform to one of the    IHE content profiles, the Connectathon monitor will verify that the documents produced by this    system, ''comply with a published healthcare standard, including wrapping support of    such generic electronic formats.'' Unstructured data, such as text files, proprietary    document formats (eg RTF), or images, shall be encapsulated within a standard document    format'''' (Ref ITI TF-1: 10.4.2).</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (606, 1, 0, '2009-11-24 10:53:19.169', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test shall be run using TLS.</p> <p>The connectathon monitor will also look for evidence of logging.  You should use the NIST ARR.</p> </p>  <H3>Description</H3> <p>The <strong>XDS_Patient_Feed</strong> test is used to load patient identifiers in the XDS    Registry and to test the Registry''s response to a merge.</p><p>Each Patient Identity Source should create new patients of the form:</p>  <table border="1" cellpadding="0">     <tr>      <td>       <p align="center">        <strong>North America</strong>       <strong> </strong>       </p>      </td>     <td>       <p align="center">        <strong>Europe</strong>       <strong> </strong>       </p>      </td>     <td>       <p align="center">        <strong>Japan</strong>       <strong> </strong>       </p>      </td>     </tr>     <tr>      <td>       <p>IDENTITY^REGISTRY^S</p>      </td>     <td>       <p>IDENTITY^REGISTRY^S''</p>      </td>     <td>       <p>''</p>      </td>     </tr>     <tr>      <td>       <p>IDENTITY^REGISTRY^N</p>      </td>     <td>       <p>IDENTITY^REGISTRY^N''</p>      </td>     <td>       <p>''</p>      </td>     </tr> </table>  <ul>     <li>IDENTITY is the name of the Patient Identity Source in the Kudu system, or a 3-4 letter     abbreviation.'' REGISTRY is the name of the Document Registry in the Kudu system, or a     3-4 letter abbreviation.</li>     <li> <strong>S</strong> stands for Surviving patient and<strong> N </strong>stands for     Non-Surviving Patient (used to test marge).</li> </ul><p>''''''''''''''''''''''''''''''''''''''''    For example: <strong>Sms^Agfa^S</strong> </p><p>The Patient Identity Source should send one ADT A01 ''or ADT A04 message (ITI-8) to    inform the Registry of patient ''S'' and patient ''N''. ''Patient Identity Source should    populate the PID fields listed in the table below. Other fields may be populated if desired, but    the Connectathon monitor will look for data in these fields:</p>   <table border="1" cellspacing="0" cellpadding="0">     <tr>      <td width="127" valign="top">      <strong>PID Seq</strong>     </td>     <td width="210" valign="top">       <p align="center">        <strong>Element Name</strong>       </p>      </td>     <td width="301" valign="top">       <p align="center">        <strong>Notes</strong>       </p>      </td>     </tr>     <tr>      <td width="127" valign="top">       <p>3</p>      </td>     <td width="210" valign="top">       <p>Patient Identifier List</p>      </td>     <td width="301" valign="top">       <p>User proper assigning authority</p>      </td>     </tr>     <tr>      <td width="127" valign="top">       <p>5</p>      </td>     <td width="210" valign="top">       <p>Patient Name</p>      </td>     <td width="301" valign="top">       <p>See above</p>      </td>     </tr>     <tr>      <td width="127" valign="top">       <p>7</p>      </td>     <td width="210" valign="top">       <p>Date/Time of Birth</p>      </td>     <td width="301" valign="top">       <p>''</p>      </td>     </tr>     <tr>      <td width="127" valign="top">       <p>11</p>      </td>     <td width="210" valign="top">       <p>Patient Address (this is R2, and a value may not be available)</</p>      </td>     <td width="301" valign="top">       <p>Use Connectathon address if possible</p>      </td>     </tr> </table>  <H3>Evaluation</H3> <p>1. <u>TLS verification:</u></p> <p>The Connectathon monitor will examine logs that show a successful TLS handshake.</p>  <p>2. <u>Patient Identity Feed:</u> </p><p> Connectathon monitor should examine log files or database entries at the Document Registry    indicating the patients have been registered. The Document Registry is not expected to have a    formal GUI to demonstrate this data, but it will need to maintain the data in some persistent    manner.</p><ul>     <li>For patient IDENTITY^REGISTRY^S, the Connectathon monitor is looking for data in PID-3,     PID-5,  and PID-7.   PID-11 is R2 in the Technical Framework, so it may be empty. Other fields can be populated and ignored. </li> </ul><p>Also verify that patient IDENTITY^REGISTRY^N and IDENTITY^REGISTRY^S were registered (before    the merge). </p><p></p> <p>3. <u>Merge functionality</u>:</p><p>Connectathon monitor needs to know what records were available for both patients before the    merge occurs. The monitor should then examine the database of the Document Registry or dragoon a    Document Consumer into service to perform queries of the Document Registry. </p><p>The Connectathon monitor will verify that the Registry rejected a document submission for the    Non-Surviving patient.</p> <p>4. <u>Audit Logging</u>:</p> <p>See specifics of audit requirements in ITI TF-2:3.8.5</p> <p>An audit message is sent by the Patient Identity Source when it sends A01, A04, A05, A08 and/or A40 messages to the Registry.  The audit message is a ''Patient Record'' event containing the Patient ID. </p> <p>An audit message is sent by the Document Registry when it receives A01, A05, A05, A08 and/or A40 messages from the Patient Identity Source.  The audit message is a ''Patient Record'' event containing the Patient ID.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (607, 1, 0, '2009-11-24 10:53:19.172', 'epoiseau', '<H3>Special Instructions</H3> <p>When you are ready to exercise your Registry''s folder-handling functionality, mark this test ''Ready to be Verified''.  This will trigger Bill Majurski to run a set of tests from the NIST tool set against your Registry.</p> <p>To run the XDS.a_Registry_Folder_Handling or XDS.b_Registry_Folder_Handling tests, make sure your registry will accept submissions for patient ids: F1000, F1001, and F1002. Then mark the test as ''Completed''. As part of the validation, Bill will run the folder tests from my toolkit. If successful Bill will mark the test ''Verified''.</p>  <p>After you run this test, Doc Registries should find a Document Source that support the Folder Management option and move on to test XDS.a_Folder_Management.</p>  <H3>Description</H3> <p>You must run the following tests from the NIST XDS toolkit:</p>  <ul> <li>11879	Accept Create Folder</li> <li>11880	Accept Create Folder with Initial Document</li> <li>11881	Add new document to existing folder</li> <li>12325	Add Existing document to existing folder</li> <li>11882	Reject Add Document to Folder - Patient ID does not match</li> <li>12324	Accept Document Replace, Document in Folder</li> <li>12322	Folder lastUpdateTime</li> </ul> <H3>Evaluation</H3> <p>Bill Majurski is the Monitor who will evaluate this test.<p> <p>If your NIST tests pass, you will pass this connectathon test.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (608, 1, 0, '2009-11-24 10:53:19.173', 'epoiseau', '<H3>Special Instructions</H3>  <p>What was previously known as the ''Document Lifecycle option'' for XDS Document Source actors and    Integrated Document Source/Repository actors is now split into separate options: ''Document    Replace'', ''Document Addendum'' and ''Document Transformation''. </p> <p>In this test, we use a Document Source that supports one or more these options.  The Repository is an optional actor in this test because it is needed to help with the test, but no Repository function is evaluated.</p>  <p>ATNA audit log messages for all XDS tests should be pointed at the NIST Audit Log Relay.</p> <H3>Description</H3> <p> In the test steps below, we will use one patient    created in the HIMSS Registration Tool or by a Patient Identity Source. The patient name is a composite of the    Document Source and Document Repository actors using the following convention:</p><ul>     <li>SOURCE^REPOSITORY^L: L stands for Document Life Cycle Management</li> </ul> <H3>Evaluation</H3> <p>It is likely that a Connectathon monitor will be assigned to find participants who support    these options, visit these system to run the tests, and record pass/fail on a spreadsheet. </p> <p>Results will depend on which options the Doc Source supports.</p> <p>Connectathon monitor will examine log files and database entries of the Document Repository and    Document Registry to look for evidence of documents.   Alternatively, use a Document Consumer to    retrieve the documents.  Monitor may ask the Doc Source to exercise the options again, real-time. </p> <ul>     <li>For the first document, in the append and transform case, the status of the original document     remains unchanged (approved).</li>     <li>For the second document, in the replacement case, the status of original document, and the     addendum and replacement, should be deprecated.'' The replacement version of the     document is approved, and is returned in response to a retrieve.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (609, 1, 0, '2009-11-24 10:53:19.176', '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.a_Workflow_PDQ </strong>is a test of the entire XDS workflow, including all of the    actors in the profile and actors from the PDQ profile. This test traces the Patient Identity from    an Identity Source to a Patient Demographic Supplier. XDS actors get the Patient ID through a    direct feed or by a PDQ 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>The PDQ Patient Demographics Source actor 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 (610, 1, 0, '2009-11-24 10:53:19.178', '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.a. 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 (611, 1, 0, '2009-11-24 10:53:19.181', 'epoiseau', '<H3>Special Instructions</H3>
 <p>This is a no-peer test to run once against the NIST toolkit.</p>
 <p>This tests the Doc Consumer''s handling of homeCommunityID (see ITI TF-2:3.18.4.1.2.3.8 (for Stored Query) and 2.43.4.1.2 (for Retrieve Doc Set-b)).
 
 <H3>Description</H3>
 <p>You will test against two specific endpoints.  You can use either TLS or non-TLS for this test:</p>
 <ul>
 <li><b>Stored Query</b> 	</li>
 <ul>
 <li>http://nist1.ihe-europe.net:9080/tf5/services/xcaregistry</li>
 <li> 	https://nist1.ihe-europe.net:9085/tf5/services/xcaregistry </li>
 </ul> 
 <li><b>Retrieve Document Set </b></li>
 <ul>
 <li> 	http://nist1.ihe-europe.net:9080/tf5/services/xcarepository</li>
 <li>https://nist1.ihe-europe.net:9085/tf5/services/xcarepository</li>
 </ul>
  </ul>
 <p>Test with this patient ID: <b>d05ddc2efd5241f^^^&1.3.6.1.4.1.21367.2005.3.7&ISO
 </b></p>
  
 <H3>Evaluation</H3>
  
 For test evidence, we will check 
  
 nist1 Test Log event ID for: 
 <ul> 
 <li>Primary Stored Query -- includes Patient ID as parameters, one of: FindDocuments, FindSubmissionSets, FindFolders) </li>
 <li>Secondary Stored Query (other Stored Query that does not have Patient  
 ID as a parameter) -- includes homeCommunityID as a parameter</li>
 <li>Retrieve Document Set request includes homeCommunityId  </li>
 </ul>
  
 
 
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (612, 1, 0, '2009-11-24 10:53:19.183', 'epoiseau', '<H3>Special Instructions</H3> <ul> <li>You must successfully test synchronous web services with a testing partner (XDS.b_Consumer_Query_Retrieve) before attempting testing asynchronous web services with that partner. The synchronous test must be graded and approved before starting asynchronous tests.</li> <li>To get credit for testing asynchronous web services for your actor, you must successfully test all transactions required of your actor over asynchronous web services. This requirement is described in detail in section 10.2.4 Asynchronous Web Services Exchange Option in the Async WS Exchange supplement dated 10/10/2008. </li> </ul> <H3>Description</H3> <p>This tests the query & retrieval of a document using Asynchronous Web Services:  Doc Consumer-->Doc Registry then Doc Consumer-->Doc Repository.</p> <ol> <li>Test though NIST proxy to allow evaluation of SOAP header attributes necessary for async web services. A NIST proxy (technically a reverse proxy) is running in front of each vendor actor that can accept an asynchronous web service transaction.   Configuration information is available from Bill Majurski.</li> <ul> <li>Configure the sending system (Consumer) to use the proxy.  This means the message will be sent to nist1:xxxx (where xxxx is the port assigned by NIST) but the HTTP header and the WS:To header will indicate the full target vendor actor endpoint.</li> <li>Confirm your configuration and the readiness of the NIST proxy with Bill Majurski of NIST before initiating the test.</li> <li>Evaluation of your WS: Headers will be done from the proxy console.</li> </ul> <li>Test directly with partner to show proper exchange of data.</li> </ol>  <H3>Evaluation</H3> <ul> <li>Be prepared to show system logs that allow verification of asynchronous nature of exchange.</li> <li>Be prepared to show proper actor operation.</li> </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (613, 1, 0, '2009-11-24 10:53:19.185', 'epoiseau', '<H3>Special Instructions</H3> <p>Each XDS.b Document Consumer, Registry and Repository is required to run one instance of this test.  Registries and Repositories may have to run it more than once to help out multiple Doc Consumers.</p> <p>TLS is not used with this test.</p> <H3>Description<H3>   <H3>Evaluation</H3> <p>The NIST tools will run an evaluation on the content of your transactions.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (614, 1, 0, '2009-11-24 10:53:19.188', 'epoiseau', '<H3>Special Instructions</H3><p>   <p>You shall run this test using TLS communication</p> <p>Document Consumers should use the  Connectathon Images/CDs/Objects page to find documents registered by Doc Sources.  See:  <em><a href=system_con_object.php>Objects Information</a>. </em></p> <p>ATNA audit log messages for all XDS tests should be pointed at the NIST Audit Log Relay.</p> <H3>Description</H3><p>The <strong>XDS_Consumer_Query_Retrieve</strong> test exercises the XDS profile from the    viewpoint of the XDS Document 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><p>The Document Consumer that is tested is required to make at least one query of the Document    Registry. The format of that query is not specified. The Technical Framework defines many    options. </p><p>For evaluation, the Connectathon monitor should observe the query and retrieve process at the    Document Consumer actor. The Document Registry or Repository will only be examined in the event    of anomalies.</p><H3>Evaluation</H3><p>On the <strong>Document Consumer</strong>, the Connectathon monitor will observe query and    retrieve in real time and observe logs or other evidence that both transactions took place using    TLS communcation. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (615, 1, 0, '2009-11-24 10:53:19.19', 'epoiseau', '<H3>Special Instructions</H3> <ul> <li>You must successfully test synchronous web services with a testing partner (XDS.b_Doc_Source_Stores_Document) before attempting testing asynchronous web services with that partner. The synchronous test must be graded and approved before starting asynchronous tests.</li> <li>To get credit for testing asynchronous web services for your actor, you must successfully test all transactions required of your actor over asynchronous web services. This requirement is described in detail in section 10.2.4 Asynchronous Web Services Exchange Option in the Async WS Exchange supplement dated 10/10/2008. </li> </ul> <H3>Description</H3> <p>This tests the submission of a document using Asynchronous Web Services:  Doc Source-->Doc Repository-->Doc Registry.</p> <ol> <li>Test though NIST proxy to allow evaluation of SOAP header attributes necessary for async web services. A NIST proxy (technically a reverse proxy) is running in front of each vendor actor that can accept an asynchronous web service transaction.   Configuration information is available from Bill Majurski.</li> <ul> <li>Configure the sending systems (Source, Repository) to use the proxy.  This means the message will be sent to nist1:xxxx (where xxxx is the port assigned by NIST) but the HTTP header and the WS:To header will indicate the full target vendor actor endpoint.</li> <li>Confirm your configuration and the readiness of the NIST proxy with Bill Majurski of NIST before initiating the test.</li> <li>Evaluation of your WS: Headers will be done from the proxy console.</li> </ul> <li>Test directly with partner to show proper exchange of data.</li> </ol>  <H3>Evaluation</H3> <ul> <li>Be prepared to show system logs that allow verification of asynchronous nature of exchange.</li> <li>Be prepared to show proper actor operation.</li> </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (616, 1, 0, '2009-11-24 10:53:19.192', 'epoiseau', '<H3>Special Instructions</H3><p>  <p>     <em>Note 1:'' Document Source systems which do not produce their own documents (ie     operate as middleware) must come to Connectathon prepared to create documents for specific     patients as specified in all XDS tests. A Document Source system will be required to generate     documents on demand using patients specified by the test instructions. </em> </p>  <p>ATNA audit log messages for all XDS tests should be pointed at the NIST Audit Log Relay.</p> <p>This is a difficult test because it requires the attention of three systems:</p> <ul>     <li>Document Source</li>     <li>Document Repository</li>     <li>Document Registry</li> </ul> <p>We provide no guidance on whether you work first on the link that starts with the Document    Source or the link that ends with the Document Registry. In the end, you have to demonstrate end    to end operation.</p> <p>At the end of this test, we want you to update a common place in Kudu to store information    about the document that was stored. This will facilitate query operations by Document Consumers.</p> <p>This test requires the Document Source to use a patient name that will allow the monitors to    more easily find the Source''s documents in the Registries and Repositories. </p> </p>  <H3>Description</H3> <p>The<strong> XDS_Doc_Source_Stores_</strong>Document test is a test of ITI transactions 41 and    42. A Document Source supplies at least one document and submits that document to a Document    Repository. This test covers a single submission set and a single document; options on the    Document Source are covered in different tests.</p> <p>ITI-41 is tightly coupled to ITI-42: Register Document Set. When the Document Source has    provided the original document, the Document Repository will then register that document with the    Document Registry.</p><p>You shall perform this test using TLS communication. That means you need to have TLS working at    the beginning of the Connectathon. You are not required to demonstrate ATNA logging for this    test, but you will need to use TLS communication.</p>  <p>When you have completed this test, you must record reference information in the Kudu tool that will help Doc Consumers find your document under Connectathon Images/CDs/Objects. The link to that page is <em><a href=system_con_object.php>Objects Information</a>. .</em>  You''ll be prompted for several values to provide.</p>  <p>If the connectathon monitor does not find the document referenced by the Submission Set    uniqueID, the test will fail.</p><p>If the connectathon monitor finds multiple instances of the Submission Set uniqueID in this    registry or other registries, the test will fail.</p><p>You need to create unique Submission Set uniqueIDs for all submissions during the connectathon.    The Monitor may ask for evidence/logs that you ran this test or ask you to run the test again in    person.</p><p>As you complete the test, you should record log information/evidence in the Kudu chat window    for this instance of the test. That would allow you to quickly show the Monitor your log   data.</p>  <H3>Evaluation</H3>  <p>Evaluation is done in two phases. In the <b>first phase</b>, one Connectathon monitor will visit the    systems and examine the log files looking for evidence that the transactions were carried out    using TLS. The Connectathon monitor may ask you to repeat the test.</p>  <p><u>Logging Requirements (ITI TF-2:3.41.7 & 3.42.7)</u></p> <ul> <li>For ITI-42 (Provide & Register), the Doc Source will log an "Export" event containing the Patient ID and the submissionSet uniqueID from the document metadata (among other fields)</li> <li>For ITI-42 (Provide & Register), the Doc Repository will log an "Import" event containing the Patient ID and the submissionSet uniqueID from the document metadata (among other fields)</li> <li>For ITI-41 (Register Doc), the Doc Repository will log an "Export" event containing the Patient ID and the submissionSet uniqueID from the document metadata (among other fields).</li> <li>For ITI-41 (Register Doc), the Doc Repository will log an "Import" event containing the Patient ID in the document metadata (among other fields).</li> </ul>  <p>Once the security requirements are confirmed, the monitor will set the state to partially verified.</p>  <p>The <b>second part of the evaluation</b> will be a query run against the Registry to determine if the    Submission Set IDs can be found and if there are multiple copies of that value. This will be    followed by a retrieval of the registered documents.'' The URI must indicate TLS    (https://). </p><p>Finally, if the documents produced by the Document Source system do not conform to one of the    IHE content profiles, the Connectathon monitor will verify that the documents produced by this    system, ''comply with a published healthcare standard, including wrapping support of    such generic electronic formats.'' Unstructured data, such as text files, proprietary    document formats (eg RTF), or images, shall be encapsulated within a standard document    format'''' (Ref ITI TF-1: 10.4.2).</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (617, 1, 0, '2009-11-24 10:53:19.194', 'epoiseau', '<H3>Special Instructions</H3> <p>Each XDS.b Document Source, Registry and Repository is required to run one instance of this test.  Registries and Repositories may have to run it more than once to help out multiple Doc Sources.</p> <p>TLS is not used with this test.</p> <H3>Description<H3>   <H3>Evaluation</H3> <p>The NIST tools will run an evaluation on the content of your transactions.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (618, 1, 0, '2009-11-24 10:53:19.197', 'epoiseau', '<H3>Special Instructions</H3><p>
 <p>The Document  Registry and Document Repository systems should complete test  <b>XDS_Doc_Source_Stores_Document</b> before doing this test.</p>
 <p>Document Registry and Document Repository systems should do <b><u>one instance</u></b> of this test.  Document Sources are identified as an optional actor because they have a helping role in this test.</p>
 </p><H3>Description</H3><p>This tests errors  reported for ITI-42 Register Document Set-b.   The Registry actor and Repository actor are required to report errors  using a defined set of codes in <b>ITI TF-2: 4.1.13 </b> </p><p>This tests a small  subset of the error conditions, but Connectathon monitors will be watching for  other error conditions which occur during the course of Connectathon testing  and may check error codes for those cases as well.  Success or failure to properly report errors  in any of those conditions are part of this test.</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>The Connectathon  monitor will evaluation two error conditions:</p><p>1. The Document Source submitted a document for a  patient that was not known to the Registry.</p><p>
    The error reported by the Registry should look like this <em>(the value for errorCode must match, but the contents of codeContext is  not mandated by the Technical Framework and may be implementation-specific;  this contains a sample of a possible value)</em>:  </p><strong>
 <p><RegistryResponse 
         xmlns="urn:oasis:names:tc:ebxml-regrep:registry:xsd:2.1" 
         status="Failure"></p>
 <p>    <RegistryErrorList></p>
 <p>    <RegistryError </p>
 <p>         errorCode="XdsUnknownPatientId" </p>
 <p>        codeContext="Patient ID is not  known to the registry"</p>
 <p>        location="" </p>
 <p>        severity="Error"/></p>
 </strong><p> </p><p>2. (optional steps) The Document Repository failed to connect to the  Document Registry.</p><p>The error reported by the Repository should look like this <em>(the value for errorCode must match, but the contents of codeContext is  not mandated by the Technical Framework and may be implementation-specific;  this contains a sample of a possible value)</em>:  </p><strong>
 <p>  <RegistryResponse </p>
 <p>     xmlns="urn:oasis:names:tc:ebxml-regrep:registry:xsd:2.1" 
        status="Failure"></p>
 <p>    <RegistryErrorList></p>
 <p>    <RegistryError </p>
 <p>        errorCode="XdsRegistryNotAvailable" </p>
 <p>        codeContext="Unable to connect to  the Registry to register document"</p>
 <p>        location="" </p>
 <p>        severity="Error"/></p>
 </strong>
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (619, 1, 0, '2009-11-24 10:53:19.199', 'epoiseau', '<H3>Special Instructions</H3> <p>XDS.b Document Registries must **pass** test <b>XDS.b_Registry_Folder_Handling</b> with the NIST Toolkit before it runs this test. </p> <p>A Document Repository is identified as an optional actor in this test because it is needed to help, but has no functionality which is evaluated in this test.</p> <p>ATNA audit log messages for all XDS tests should be pointed at the NIST Audit Log Relay.</p> <H3>Description</H3> <p>XDS Document Repository are required to support Folder Management. This is optional for Document Source and  Integrated Document Source/Repository actors. In this test, we use a Document  Source that supports this option.</p> <p>In the test steps below, we will use one patient created  in the HIMSS Registration Tool or by a Patient Identity Source. The patient name is a  composite of the Document Registry and Document Repository (or  Registry/Repository) actors'' kudu system name using the following convention:</p>  <ul> <li>REGISTRY^REPOSITORY^FOLDER; first name of FOLDER stands for Folder Management</li> </ul> <H3>Evaluation</H3> <p>Connectathon monitor will examine log files and database entries of the Document Repository and Document Registry to look for evidence of documents in folders. </p>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (620, 1, 0, '2009-11-24 10:53:19.201', 'epoiseau', '<H3>Special Instructions</H3><p> <p>What was previously known as the &ldquo;Document Lifecycle option&rdquo; for XDS Document Source actors and    Integrated Document Source/Repository actors is now split into separate options: &ldquo;Document    Replace&rdquo;, &ldquo;Document Addendum&rdquo; and &ldquo;Document Transformation&rdquo;. </p> <p>We also test the Folder Management option.</p> <p>In this test, we use an Integrated Document Source/Repository that supports one or more these options. If no such    system is available, the Document Registry and Document Repository should use a test tool (eg.    NIST) designed to test specifically for these features.</p> </p><H3>Description</H3><p>A system that groups a Document Registry and Document Repository must execute this test with a    Document Repository from a different vendor. 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 created from the    kudu system name of the Integrated Source/Repository using the following convention:</p><ul>     <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><p>It is likely that a Connectathon monitor will be assigned to find participants who support    these options, visit these system to run the tests, and record pass/fail on a spreadsheet. </p><p>Connectathon monitor will examine log files and database entries of the Integrated    Source/Repository and Document Registry to look for evidence of documents. Alternatively, use a    Document Consumer to retrieve the documents.</p><ul>     <li>For the first document, in the append and transform case, the status of the original document     remains unchanged (approved).</li>     <li>For the second document, in the replacement case, the status of original document, and the     addendum and replacement, should be deprecated.&nbsp; The replacement version of the     document is approved, and is returned in response to a retrieve.</li> </ul><p>If Folder Management is supported, the Connectathon monitor will examine log files and database    entries of the Integrated Document Source/Repository and Document Registry to look for evidence of documents in    folders. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (621, 1, 0, '2009-11-24 10:53:19.205', 'epoiseau', '<H3>Special Instructions</H3> <p>You shall run this test using TLS communication</p> <p>ATNA audit log messages for all XDS tests should be pointed at the NIST Audit Log Relay.</p> <p>Document Consumers should use the  Connectathon Images/CDs/Objects page to find documents registered by Doc Sources.  See:  <em><a href=system_con_object.php>Objects Information</a>. </em></p>  <p>This test should be driven by the Integrated Document Source/Repository actor. You should know    which documents you have loaded into your system and where they are registered. 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 the Integrated    Document Source/Repository.</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 Integrated Document Source/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 Integrated Document Source/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><p>Connectathon monitor will observe the Document Consumer while it queries for and retrieves a    document from the Integrated Document Source/ Repository. Monitor will observe logs or other    information indicating the communication takes place using ATNA TLS communication.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (622, 1, 0, '2009-11-24 10:53:19.207', 'epoiseau', '<H3>Special Instructions</H3><p> <p>ATNA audit log messages for all XDS tests should be pointed at the NIST Audit Log Relay.</p> </p>  <H3>Description</H3> <p>The XDS_ Integrated Source_Repository_Registers_Document  test is a test of ITI transaction 42.  An  Integrated Source/Repository supplies  at least one document and registers that document with a Document Registry.  This test covers a single submission set and a single document; options on the  Integrated Document Source/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>  <p>When you have completed this test, you must record reference information in the Kudu tool that will help Doc Consumers find your document under Connectathon Images/CDs/Objects. The link to that page is <em><a href=system_con_object.php>Objects Information</a>. .</em>  You''ll be prompted for several values to provide.</p>    <p>If the connectathon monitor does not find the document  referenced by the Submission Set uniqueID, the test will fail.</p>  <p>If the connectathon monitor finds multiple instances of  the Submission Set uniqueID in this registry or other registries, the test will  fail.</p> <p>You need to create unique Submission Set uniqueIDs for all  submissions during the connectathon.</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 verified.</p> <p>The second part of the evaluation will be a query run against the Registry to determine if the    Submission Set IDs can be found and if there are multiple copies of that value. This will be    followed by a retrieval of the registered documents.  The URI must indicate TLS    (https://). </p><p>Finally, if the documents produced by the Integrated Source/Repository system do not conform to one of the    IHE content profiles, the Connectathon monitor will verify that the documents produced by this    system, "comply with a published healthcare standard, including wrapping support of    such generic electronic formats.  Unstructured data, such as text files, proprietary    document formats (eg RTF), or images, shall be encapsulated within a standard document    format" (Ref ITI TF-1: 10.4.2).</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (623, 1, 0, '2009-11-24 10:53:19.21', 'epoiseau', '<H3>Special Instructions</H3><p> <p> Patient Identity Sources and Document Registries which support the Patient Identity Feed    option (HL7v2) run this test. </p> <p>This test shall be run using TLS.</p> <p>The connectathon monitor will also look for evidence of logging.  You should use the NIST ARR.</</p> </p>  <H3>Description</H3>  <p>The <strong>XDS_Patient_Feed</strong> test is used to load patient identifiers in the XDS    Registry and to test the Registry''s response to a merge.</p><p>Each Patient Identity Source should create new patients of the form:</p>  <table border="1" cellpadding="0">     <tr>      <td>       <p align="center">        <strong>North America</strong>       <strong> </strong>       </p>      </td>     <td>       <p align="center">        <strong>Europe</strong>       <strong> </strong>       </p>      </td>     <td>       <p align="center">        <strong>Japan</strong>       <strong> </strong>       </p>      </td>     </tr>     <tr>      <td>       <p>IDENTITY^REGISTRY^S</p>      </td>     <td>       <p>IDENTITY^REGISTRY^S''</p>      </td>     <td>       <p> </p>      </td>     </tr>     <tr>      <td>       <p>IDENTITY^REGISTRY^N</p>      </td>     <td>       <p>IDENTITY^REGISTRY^N''</p>      </td>     <td>       <p> </p>      </td>     </tr> </table>   <ul>     <li>IDENTITY is the name of the Patient Identity Source in the Kudu system, or a 3-4 letter     abbreviation.'' REGISTRY is the name of the Document Registry in the Kudu system, or a     3-4 letter abbreviation.</li>     <li> <strong>S</strong> stands for Surviving patient and<strong> N </strong>stands for     Non-Surviving Patient (used to test marge).</li> </ul><p>''''''''''''''''''''''''''''''''''''''''    For example: <strong>Sms^Agfa^S</strong> </p><p>The Patient Identity Source should send one ADT A01 ''or ADT A04 message (ITI-8) to    inform the Registry of patient ''S'' and patient ''N''. ''Patient Identity Source should    populate the PID fields listed in the table below. Other fields may be populated if desired, but    the Connectathon monitor will look for data in these fields:</p>   <table border="1" cellspacing="0" cellpadding="0">     <tr>      <td width="127" valign="top">      <strong>PID Seq</strong>     </td>     <td width="210" valign="top">       <p align="center">        <strong>Element Name</strong>       </p>      </td>     <td width="301" valign="top">       <p align="center">        <strong>Notes</strong>       </p>      </td>     </tr>     <tr>      <td width="127" valign="top">       <p>3</p>      </td>     <td width="210" valign="top">       <p>Patient Identifier List</p>      </td>     <td width="301" valign="top">       <p>User proper assigning authority</p>      </td>     </tr>     <tr>      <td width="127" valign="top">       <p>5</p>      </td>     <td width="210" valign="top">       <p>Patient Name</p>      </td>     <td width="301" valign="top">       <p>See above</p>      </td>     </tr>     <tr>      <td width="127" valign="top">       <p>7</p>      </td>     <td width="210" valign="top">       <p>Date/Time of Birth</p>      </td>     <td width="301" valign="top">       <p> </p>      </td>     </tr>     <tr>      <td width="127" valign="top">       <p>11</p>      </td>     <td width="210" valign="top">       <p>Patient Address (this is R2, and a value may not be available)</p>      </td>     <td width="301" valign="top">       <p>Use Connectathon address if possible</p>      </td>     </tr> </table>   <H3>Evaluation</H3> <p>1. <u>TLS verification:</u></p> <p>The Connectathon monitor will examine logs that show a successful TLS handshake.</p>  <p>2. <u>Patient Identity Feed:</u> </p> <p> Connectathon monitor should examine log files or database entries at the Document Registry    indicating the patients have been registered. The Document Registry is not expected to have a    formal GUI to demonstrate this data, but it will need to maintain the data in some persistent    manner.</p><ul>     <li>For patient IDENTITY^REGISTRY^S, the Connectathon monitor is looking for data in PID-3,     PID-5,  and PID-7. PID-11 is R2 in the Technical Framework, so it may be empty.  Other fields can be populated and ignored. </li> </ul><p>Also verify that patient IDENTITY^REGISTRY^N and IDENTITY^REGISTRY^S were registered (before    the merge). </p><p></p>  <p>3. <u>Merge functionality</u>:</p> <p>Connectathon monitor needs to know what records were available for both patients before the    merge occurs. The monitor should then examine the database of the Document Registry or dragoon a    Document Consumer into service to perform queries of the Document Registry. </p><p>The Connectathon monitor will verify that the Registry rejected a document submission for the    Non-Surviving patient.</p> <p>4. <u>Audit Logging</u>:</p> <p>See specifics of audit requirements in ITI TF-2:3.8.5</p> <p>An audit message is sent by the Patient Identity Source when it sends A01, A04, A05, A08 and/or A40 messages to the Registry.  The audit message is a ''Patient Record'' event containing the Patient ID. </p> <p>An audit message is sent by the Document Registry when it receives A01, A05, A05, A08 and/or A40 messages from the Patient Identity Source.  The audit message is a ''Patient Record'' event containing the Patient ID.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (624, 1, 0, '2009-11-24 10:53:19.214', 'epoiseau', '<H3>Special Instructions</H3><p> <p> Patient Identity Sources and Document Registries which support the Patient Identity Feed HL7v3    option run this test. </p> <p>This test shall be run using TLS.</p> <p>The connectathon monitor will also look for evidence of logging.  You should use the NIST ARR.</ </p> </p> </p><H3>Description</H3><p>The <strong>XDS_Patient_Feed</strong> test is used to load patient identifiers in the XDS    Registry and to test the Registry''s response to a merge.</p><p>Each Patient Identity Source should create new patients of the form:</p><table border="1" cellpadding="0">     <tr>      <td>       <p align="center">        <strong>North America</strong>       <strong> </strong>       </p>      </td>     <td>       <p align="center">        <strong>Europe</strong>       <strong> </strong>       </p>      </td>     <td>       <p align="center">        <strong>Japan</strong>       <strong> </strong>       </p>      </td>     </tr>     <tr>      <td>       <p>IDENTITY^REGISTRY^S</p>      </td>     <td>       <p>IDENTITY^REGISTRY^S''</p>      </td>     <td>       <p>''</p>      </td>     </tr>     <tr>      <td>       <p>IDENTITY^REGISTRY^N</p>      </td>     <td>       <p>IDENTITY^REGISTRY^N''</p>      </td>     <td>       <p>''</p>      </td>     </tr> </table><ul>     <li>IDENTITY is the name of the Patient Identity Source in the Kudu system, or a 3-4 letter     abbreviation.'' REGISTRY is the name of the Document Registry in the Kudu system, or a     3-4 letter abbreviation.</li>     <li> <strong>S</strong> stands for Surviving patient and<strong> N </strong>stands for     Non-Surviving Patient (used to test marge).</li> </ul><p>''''''''''''''''''''''''''''''''''''''''    For example: <strong>Sms^Agfa^S</strong> </p><p>The Patient Identity Source should send one ITI-44 message to    inform the Registry of patient ''S'' and patient ''N''. ''Patient Identity Source should    populate attributes in the message with the guidance for values listed in the table below. Other attributes may be populated if desired, but    the Connectathon monitor will look for data in these fields:</p><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td width="210" valign="top">       <p align="center"> <strong>Value</strong> </p>     </td>     <td width="301" valign="top">       <p align="center">        <strong>Notes</strong>      </p>     </td>     </tr>     <tr>      <td width="210" valign="top">       <p>Patient ID </p>     </td>     <td width="301" valign="top">       <p>Use proper assigning authority</p>     </td>     </tr>     <tr>      <td width="210" valign="top">       <p>The patient''s name</p>     </td>     <td width="301" valign="top">       <p>See guidance on name above</p>     </td>     </tr>     <tr>      <td width="210" valign="top">       <p>Date/Time of Birth</p>     </td>     <td width="301" valign="top">       <p>''</p>     </td>     </tr>     <tr>      <td width="210" height="21" valign="top">       <p>Patient Address</p>     </td>     <td width="301" valign="top">       <p>Use Connectathon address if possible</p>     </td>     </tr> </table><H3>Evaluation</H3> <p>1. <u>TLS verification:</u></p> <p>The Connectathon monitor will examine logs that show a successful TLS handshake.</p>  <p>2. <u>Patient Identity Feed:</u> </p><p> Connectathon monitor should examine log files or database entries at the Document Registry    indicating the patients have been registered. The Document Registry is not expected to have a    formal GUI to demonstrate this data, but it will need to maintain the data in some persistent    manner.</p><ul>     <li>For patient IDENTITY^REGISTRY^S, the Connectathon monitor is looking for data in attributes Patient.id, Person.name, Person.addr, Person, and birthTime . Other fields can be populated and ignored. </li> </ul><p>Also verify that patient IDENTITY^REGISTRY^N and IDENTITY^REGISTRY^S were registered (before the merge). </p><p></p>  <p>3. <u>Merge functionality</u>:</p> <p>Connectathon monitor needs to know what records were available for both patients before the    merge occurs. The monitor should then examine the database of the Document Registry or dragoon a    Document Consumer into service to perform queries of the Document Registry. </p><p>The Connectathon monitor will verify that the Registry rejected a document submission for the    Non-Surviving patient.</p> <p>4. <u>Audit Logging</u>:</p>  <p>An audit message is sent by the Patient Identity Source when it sends Patient Registry Record Added, Patient Registry Record Revised, or Patient Registry Duplicates Resolved messages to the Registry.  The audit message is a ''Patient Record'' event containing the Patient ID. </p> <p>An audit message is sent by the Document Registry when it receives Patient Registry Record Added, Patient Registry Record Revised, or Patient Registry Duplicates Resolved messages from the Patient Identity Source.  The audit message is a ''Patient Record'' event containing the Patient ID.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (625, 1, 0, '2009-11-24 10:53:19.216', 'epoiseau', '<H3>Special Instructions</H3> <p>When you are ready to exercise your Registry''s folder-handling functionality, mark this test ''Ready to be Verified''.  This will trigger Bill Majurski to run a set of tests from the NIST tool set against your Registry.</p> <p>To run the XDS.a_Registry_Folder_Handling or XDS.b_Registry_Folder_Handling tests, make sure your registry will accept submissions for patient ids: F1000, F1001, and F1002. Then mark the test as ''Completed''. As part of the validation, Bill will run the folder tests from my toolkit. If successful Bill will mark the test ''Verified''.</p> <p>After you run this test, Doc Registries should find a Document Source that support the Folder Management option and move on to test XDS.b_Folder_Management.</p>  <H3>Description</H3> <p>You must pass the following tests from the NIST XDS toolkit:</p>  <ul> <li>11999	Accept Create Folder</li> <li>12000	Accept Create Folder with Initial Document</li> <li>12001	Add new document to existing folder</li> <li>12326	Add Existing document to existing folder</li> <li>12002	Reject Add Document to Folder - Patient ID does not match</li> <li>12327	Accept Document Replace, Document in Folder</li> <li>12323	Folder lastUpdateTime</li> </ul> <H3>Evaluation</H3> <p>Bill Majurski is the Monitor who will evaluate this test.<p> <p>If your NIST tests pass, you will pass this connectathon test.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (626, 1, 0, '2009-11-24 10:53:19.218', 'epoiseau', '<H3>Special Instructions</H3><p> <p>What was previously known as the ''Document Lifecycle option'' for XDS Document Source actors and    Integrated Document Source/Repository actors is now split into separate options: ''Document    Replace'', ''Document Addendum'' and ''Document Transformation''. </p> <p>In this test, we use a Document Source that supports one or more these options.  The Repository is an optional actor in this test because it is needed to help with the test, but no Repository function is evaluated.</p>  </p> <H3>Description</H3> <p> In the test steps below, we will use one patient    created in the HIMSS Registration Tool or by a Patient Identity Source. The patient name is a composite of the    Document Source and Document Repository actors using the following convention:</p><ul>     <li>SOURCE^REPOSITORY^L: L stands for Document Life Cycle Management</li> </ul> <H3>Evaluation</H3> <p>It is likely that a Connectathon monitor will be assigned to find participants who support    these options, visit these system to run the tests, and record pass/fail on a spreadsheet. </p> <p>Results will depend on which options the Doc Source supports.</p> <p>Connectathon monitor will examine log files and database entries of the Document Repository and    Document Registry to look for evidence of documents. Alternatively, use a Document Consumer to    retrieve the documents.  Monitor may ask the Doc Source to exercise the options again, real-time. </p> <ul>     <li>For the first document, in the append and transform case, the status of the original document     remains unchanged (approved).</li>     <li>For the second document, in the replacement case, the status of original document, and the     addendum and replacement, should be deprecated.'' The replacement version of the     document is approved, and is returned in response to a retrieve.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (627, 1, 0, '2009-11-24 10:53:19.221', '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 transac    tions 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.b_Workflow_PDQ </strong>is a test of the entire XDS workflow, including all of the    actors in the profile and actors from the PDQ profile. This test traces the Patient Identity from    an Identity Source to a Patient Demographic Supplier. XDS actors get the Patient ID through a    direct feed or by a PDQ 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>The PDQ Patient Demographics Source actor 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> ');
