INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (114, 1, 0, '2009-11-24 10:53:16.345', 'epoiseau', '<h3>Special Instructions</h3> <p>DEC_Ventilator is defined in the context of DOR/DOC pairs where the DOR is a Ventilator. If your DOR is not a Ventilator, do not perform this test.</p>  <h3>Description</h3> <p>DORs will send messages with reasonable physiologic values for supported parameters. Each message shall contain the required number of parameters that the receiving DOC can process and display or document, and may send any number of additional parameters. DORs are responsible for coordinating with their DOC partners <em>in advance of the Connectathon</em> to assure that the DOCs are able to receive at least the minimum three parameters required for a given test. Parameter values should be realistic for a patient in a cardiac ICU bed or on an OR table.</p>  <p>At least four parameters will be be sent for each patient; at least three of which can be processed by the receiving DOC. Minimum parameters are selected from this list:  <ul>   <li>Ventilation Rate</li>   <li>Peak Inspiratory Pressure</li>   <li>Positive End Expiratory Pressure</li>   <li>Inspired O2 Concentration</li>   <li>Inspired CO2 Concentration</li>  </ul> </p>  <h3>Evaluation</h3> <p>Project manager or monitor will observe the displays provided by the DOR and partner DOC. The physiologic parameters and their measurement values, including the time of parameter measurement will be compared. The type of display/documentation by the DOC is not constrained, it need only be clinically useful.</p>  <p>If the minimum number of parameters, measurements and time of measurement sent by the DOR matches those received by the DOC that will indicate the step in the test has been successful. NOTE: At least one message sent by the DOR for both patients will not have been received by the DOC (Communication Link Interrupted And Resumed) and the time recorded by the DOR for the interruption will be compared to the missing data point(s). Note also that the data must match the patient.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (115, 1, 0, '2009-11-24 10:53:16.347', 'epoiseau', '<H3>Special Instructions</H3><p> <p>DEC_Vital_Signs_Monitor_RC is defined in the context of  DOR/DOC pairs (for DOFs &ndash; see below) where the DOR and DOC do not support any  other type of system during this test. If the DOR also supports another type of  system, that system should perform the DEC_One_to_One_Communication test  instead. A VSM is a monitor that sends messages for a patient or patients only  once or intermittently, in contrast to devices such as bedside monitors. If  your DOR or DOC does not support Vital Signs Monitor data this test does not  apply.</p> <p>There are two variations of this test; be sure you select  the right one(s):</p> <ul>     <li>DEC_Vital_Signs_Monitor_RC </li>     <ul>      <li>DOR and a DOC</li>      <li>DOR with DOF in the same system, testing the DOR  function and not the DOF; the DOC does not use the query function to filter  data</li>     </ul>     <li>DEC_Vital_Signs_Monitor_RF </li>     <ul>      <li>Standalone DOF, testing the input side as if it  were a DOC, will need a DOR as partner</li>     </ul> </ul> <p>NOTE: If the  system is a DOF independent of a DOR, then the DOF must test as if it were a  DOC with a DOR (using DEC_ Vital_Signs_Monitor _RF). I.e., the DOF must receive  messages from a DOR. Tests of its ability to respond to subscriptions from a  DOC are provided elsewhere. </p> <p>NOTE: Test names for this test are the same for DORs and  DOCs. They play partner roles and DORs are responsible for coordinating with  their partners <em>in advance of the</em> <em>Connectathon</em> to assure that the  required number of receiving systems needed are able to receive the messages  they will send.</p> <p>RELATED TESTS:</p> <p>This test may be combined with: </p> <ul type="disc">     <li>PAM       tests</li>     <li>PDQ       tests</li>     <li>DEC_Validated_Parameters_RC       &nbsp;(would follow this test)</li> </ul> <p>If the DOR supports either or both of the PAM and PDQ  options in the Patient Identity Binding (PIB) option, the DOR may elect to test  either or both of these tests at this time by using the PIB option to obtain  the patient&rsquo;s demographics.</p> <p>If the DOR supports both caregiver validated and unvalidated  messages, that test may also be conducted if the partner remains available.</p> </p><H3>Description</H3><p>The test follows:</p><ol>     <li>A  VSM will acquire data for two or more patients, each separated at least minute  apart in time. The data will contain reasonable physiologic values for at least  four supported parameters. The VSM will make a single connection to the DOR to  transfer data for these patients. An actual VSM is preferred, but simulators are  acceptable, or, if necessary data from parameter tables provided by the Project  Manager (least desirable) may be used.</li>     <li>The  DOR transmits the data to a DOC. If the DOR supports both validated and  unvalidated data, this test is performed with unvalidated data. </li> </ol><p>PATIENT IDENTIFICATION:</p><p>For systems NOT using PAM or PDQ to obtain patient  demographics, the patients for this test in January 2008 are given below. </p><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td>      <strong>System</strong> </td>     <td> <p> <strong>MRN</strong> </p> </td>     <td> <p> <strong>First</strong> </p> </td>     <td> <p> <strong>Last</strong> </p> </td>     <td> <p> <strong>Location</strong> </p> </td>     <td> <p> <strong>Mother Maiden Name</strong> </p> </td>     <td> <p> <strong>DOB</strong> </p> </td>     </tr>     <tr>      <td> <p>Welch Allyn</p> </td>     <td> <p>WA2008001</p> </td>     <td> <p>Andrea</p> </td>     <td> <p>Brooks</p> </td>     <td> <p>3 West ICU &ndash; 36-1</p> </td>     <td> <p>Coburn</p> </td>     <td> <p>1/1/66</p> </td>     </tr>     <tr>      <td> <p>Welch Allyn</p> </td>     <td> <p>WA2008002</p> </td>     <td> <p>Camille</p> </td>     <td> <p>Darwin</p> </td>     <td> <p>4 West ICU &ndash; 32-1</p> </td>     <td> <p>Emerine</p> </td>     <td> <p>1/1/66</p> </td>     </tr> </table><H3>Evaluation</H3><p>Project manager or monitor will observe the displays  provided by the DOR and partner DOC. The physiologic parameters and their  measurement values, including the time of parameter measurement will be  compared. The type of display/documentation by the DOC is not constrained, it  need only be clinically useful.</p><p>Success: If the patients, the minimum number of parameters,  measurements and time of measurement sent by the DOR matches those received by  the DOC that will indicate the test has been successful.</p><p>NOTE: If PAM and/or PDQ tests are conducted at this time  they will evaluated as described for those tests and the evaluation will be  recorded for those tests.</p><p> NOTE: If the DOR is capable of sending both validated and  unvalidated messages that test may be conducted and evaluated at this time. For  that test the DOR must partner with a DOC that can distinguish the two types of  messages. That evaluation will be recorded for that test. That test need be  accomplished only once.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (116, 1, 0, '2009-11-24 10:53:16.349', 'epoiseau', '<H3>Special Instructions</H3><p> <p>DEC_Vital_Signs_Monitor_RF is defined in the context of DOR/DOF  pairs, where the DOR and DOF do not support any other type of system during  this test. If the DOR also supports another type of system, that system should  perform the DEC_One_to_One_Communication test instead. A VSM is a monitor that  sends messages for a patient or patients only once or intermittently, in  contrast to devices such as bedside monitors. If your DOR or DOF does not  support Vital Signs Monitor data this test does not apply.</p> <p>There are two variations of this test; be sure you select  the right one(s):</p> <ul>     <li>DEC_Vital_Signs_Monitor_RC </li>     <ul>      <li>DOR and a DOC</li>      <li>DOR with DOF in the same system, testing the DOR  function and not the DOF; the DOC does not use the query function to filter  data</li>     </ul>     <li>DEC_Vital_Signs_Monitor_RF</li>     <ul>      <li>Standalone DOF, testing the input side as if it  were a DOC, will need a DOR as partner</li>     </ul> </ul> <p>NOTE:<strong> </strong>If the  system is a DOF independent of a DOR, then the DOF must test as if it were a  DOC with a DOR (using DEC_ Vital_Signs_Monitor _RF). I.e., the DOF must receive  messages from a DOR. Tests of its ability to respond to subscriptions from a  DOC are provided elsewhere. </p> <p>NOTE: Test names for this test are the same for DORs and DOFs.  They play partner roles and DORs are responsible for coordinating with their  partners <em>in advance of the</em> <em>Connectathon</em> to assure that the  required number of receiving systems needed are able to receive the messages  they will send.</p> <p>RELATED TESTS:</p> <p>This test may be combined with: </p> <ul type="disc">     <li>PAM       tests</li>     <li>PDQ       tests</li>     <li>DEC_Validated_Parameters_RC       &nbsp;(would follow this test)</li> </ul> <p>If the DOR supports either or both of the PAM and PDQ  options in the Patient Identity Binding (PIB) option, the DOR may elect to test  either or both of these tests at this time by using the PIB option to obtain  the patient&rsquo;s demographics.</p> <p>If the DOR supports both caregiver validated and unvalidated  messages, that test may also be conducted if the partner remains available.</p> </p><H3>Description</H3><p>The test follows:</p><ol>         <li>A  VSM will acquire data for two or more patients, each separated at least minute  apart in time. The data will contain reasonable physiologic values for at least  four supported parameters. The VSM will make a single connection to the DOR to  transfer data for these patients. An actual VSM is preferred, but simulators are  acceptable, or, if necessary data from parameter tables provided by the Project  Manager (least desirable) may be used.</li>     <li>The  DOR transmits the data to a DOF. If the DOR supports both validated and  unvalidated data, this test is performed with unvalidated data. </li> </ol><p>PATIENT IDENTIFICATION:</p><p>For systems NOT using PAM or PDQ to obtain patient demographics, the patients for this test in    January 2008 are given below. </p><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td>      <strong>System</strong>     </td>     <td>       <p>        <strong>MRN</strong>       </p>      </td>     <td>       <p>        <strong>First</strong>       </p>      </td>     <td>       <p>        <strong>Last</strong>       </p>      </td>     <td>       <p>        <strong>Location</strong>       </p>      </td>     <td>       <p>        <strong>Mother Maiden Name</strong>       </p>      </td>     <td>       <p>        <strong>DOB</strong>       </p>      </td>     </tr>     <tr>      <td>       <p>Welch Allyn</p>      </td>     <td>       <p>WA2008001</p>      </td>     <td>       <p>Andrea</p>      </td>     <td>       <p>Brooks</p>      </td>     <td>       <p>3 West ICU &ndash; 36-1</p>      </td>     <td>       <p>Coburn</p>      </td>     <td>       <p>1/1/66</p>      </td>     </tr>     <tr>      <td>       <p>Welch Allyn</p>      </td>     <td>       <p>WA2008002</p>      </td>     <td>       <p>Camille</p>      </td>     <td>       <p>Darwin</p>      </td>     <td>       <p>4 West ICU &ndash; 32-1</p>      </td>     <td>       <p>Emerine</p>      </td>     <td>       <p>1/1/66</p>      </td>     </tr> </table><H3>Evaluation</H3><p>Project manager or monitor will observe the displays  provided by the DOR and partner DOF. The physiologic parameters and their  measurement values, including the time of parameter measurement will be  compared. The type of display/documentation by the DOF is not constrained, and it  need <strong>not</strong> be clinically useful.</p><p>Success: If the patients, the minimum number of parameters,  measurements and time of measurement sent by the DOR matches those received by  the DOF that will indicate the test has been successful.</p><p>NOTE: If DEC_Interrupted_Communication, DEC_PIB_PAM,  DEC_PIB_PDQ, and/or DEC_Validated_Parameters tests &nbsp;are  conducted with, or following this test, they will evaluated as described for  those tests and the evaluation will be recorded for those tests.</p><p>NOTE: If the DOR is capable of  sending both validated and unvalidated messages that test may be conducted and  evaluated at this time. For that test the DOR must partner with a DOC that can  distinguish the two types of messages. That evaluation will be recorded for  that test. That test need be accomplished only once.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (117, 1, 0, '2009-11-24 10:53:16.352', 'epoiseau', '<H3>Special Instructions</H3>  <p>This test addresses the ability of a DOR (or DOF) to integrate patient demographic information from an ADT system with physiologic data. This test provides data for two patients. If the system only supports one patient, document this. If the system does not utilize the PIB option, do not conduct this test. </p>  <p>If both PAM and PDQ options are supported, this test will be accomplished with one patient identified via the system''s database of prior PAM transmissions and the other via a query. If the DOR supports only PAM or PDQ, both patients will be identified using the only appropriate option. PAM or PDQ qualifying tests, if any, should be performed first. </p>  <p>The user selects or validates the patient identification obtained and the sending system incorporates the patient identity into the messages transmitted to a DOC. </p>  <p>This test applies to a</p> <ul> <li>DOR and a DOC</li> <li>DOF within the same system as a DOR and a DOC </li> <li>Standalone DOF when it needs ADT support, and a DOC</li> </li> </ul>   <p><u>Related Tests: </u> Developers may efficiently integrate this test with DEC_PIB_Unsuccessful_Identification and the appropriate one to one test: </p> <ul> <li>DEC_DOR_DOC_One_to_One_Communication_Periodic_Data</li> <li>DEC_DOR_DOC_One_to_One_Communication_Infrequent_Data  (data such as infusion pumps, NIBP devices or channels and beds) </li> </li> </ul>   <p>NOTE: While these test names include DOR and DOC, they apply to DOFs as well. </p>  <H3>Description</H3> <p>DORs (and DOFs) will send, and DOCs (and standalone DOFs) will receive physiologic and/or operational  parameters for two patients. If your system does not support multiple patients you need to make this known to your test partners and the project manager. </p>  <p>Read the appropriate one-to-one test before proceeding. If this test is combined with that one, please follow the requirements for that test where those requirements differ from the following. </p>  <p>Sending systems will send at least three messages for each patient with reasonable values for four parameters assuming the patient is in an ICU or OR.  </p> <ul> <li>If the system only supports infrequent data (e.g., Vital Signs Monitor (VSM) or Non-Invasive Blood Pressure (NIBP) data then it will send two messages for at least two patients, with some change in parameter values in the second set of messages for each patient. </li> <li>If infrequent data is included with other data, the VSM or NIBP monitor need only send one message with one or more patients'' data. </li> <li>If the DOR supports both validated and unvalidated data, this test is performed with unvalidated data. </li>  </li> </ul>   <p>The sequence of messages is not important if this test is not combined with a one-to-one test. </p>  <p>Parameter values should be realistic for a patient in a cardiac ICU bed or on an OR table. </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>Refer to the PCD_Patient_Demographics table and select two appropriate patients. </p>  <p>Developers are responsible for coordinating with their partners in advance of the Connectathon to assure that they will have the required number of partner systems that support the same physiologic or other parameters, with consistent coding. </p>  <H3>Evaluation</H3> <p>Project manager or monitor will observe the displays provided by the sending and receiving system(s). The patients'' names and/or medical record numbers (MRNs), physiologic and other parameters, their measurement values, and the time of parameter measurement/acquisition will be compared. The type of display/documentation by the receiving system is not constrained, it need only be clinically useful. </p>  <p>NOTE: If other tests are conducted with this test, they will evaluated as described for those tests and the evaluation will be recorded for those tests. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (118, 1, 0, '2009-11-24 10:53:16.355', 'epoiseau', 'The purpose of the DNSLoad test is for each PWP Server actor to load the information describing each PWP Directory.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (119, 1, 0, '2009-11-24 10:53:16.357', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Enterprise Report Repository actors which support the <strong>By-Reference Reports option</strong> must run  this test.</p> <p>    A Report Creator is needed to help with this test by  submitting a report, but is specified as an optional actor in (ie it is not  required to complete 3 instances of this test).</p> </p><H3>Description</H3><p>This test verifies the interaction between the Report Manager and Enterprise Report Repository for submitting references to reports.</p><H3>Evaluation</H3><ol start="1" type="1">     <li>The       Enterprise Report Repository shall demonstrate for the Connectathon       Monitor that the reference to the report for patient <em>RM-kudu-system-name^EntRptRep-kudu-system</em>-<em>name</em> is stored on its system.&nbsp;       This may be done by viewing a database entry, displaying the report       (using the reference), or some other means.</li>     <li>The       Enterprise Report Repository shall demonstrate how its application makes       the report available (via its reference) to other systems in the       enterprise.&nbsp; Making the report       available is a requirement in the Technical Framework; however, the DRPT       profile does not specify how the Enterprise Report Repository must       accomplish this.&nbsp; The Connectathon       Monitor will have to exercise some judgment when assessing this       functionality, but an Enterprise Report Repository which just stores the       report reference (URL) in its database would not pass this test.</li>     <li>Verify       that when the report is accessed, the UPDATED version of the report is       presented.</li>     <li>View a       copy of the MDM^T09 (update) message.&nbsp;       Verify the following:</li> </ol><ol start="1" type="1">     <ul type="disc">      <li>MSH        Segment &ndash; required fields:</li>      <ul type="square">       <li>MSH-9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Message Type.&nbsp;&nbsp; Value:&nbsp; MDM^T09</li>      </ul>      <li>TXA        Segment &ndash; required fields:</li>      <ul type="square">       <li>TXA-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Set ID</li>       <li>TXA-2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Document Type</li>       <li>TXA-12&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Unique Document Number</li>       <li>TXA-16&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; includes the URL to access the         stored report document on the Report Manager (grouped with a RID         Information Source) </li>      </ul>      <li>There        are no OBX segments in an MDM^T09 message     </li>     </ul> </ol><p> 5. Each  updated version of a document must have its own unique document number.&nbsp; Verify that the value for TXA-12 is different  in the two MDM messages. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (120, 1, 0, '2009-11-24 10:53:16.359', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Enterprise Report Repository actors which support the <strong>Encapsulated Reports option</strong> must run  this test.</p> <p>    The Report Creator is needed to help with this test by  submitting a report, but is specified as an optional actor in (ie it is not  required to complete 3 instances of this test).</p> </p><H3>Description</H3><p>This test verifies the interation between the Report Manager and Enterprise Report Repository for submitting encapsulated reports.</p><H3>Evaluation</H3><ol start="1" type="1">     <li>The       Enterprise Report Repository shall demonstrate for the Connectathon       Monitor that the report for patient <em>RM-kudu-system-name^EntRptRep-kudu-system</em>-<em>name</em> is stored on its system.&nbsp; This may be done by viewing a database       entry, and displaying the PDF report.</li>     <li>The       Enterprise Report Repository shall demonstrate (or explain) for the       Connectathon Monitor how its application makes the report available to       other systems in the enterprise.&nbsp;       Making the report available is a requirement in the Technical       Framework; however, the DRPT profile does not specify how the Enterprise       Report Repository must accomplish this.&nbsp;       The Connectathon Monitor will have to exercise some judgment when       assessing this functionality, but an Enterprise Report Repository which       just stores the report in its database would not pass this test.</li> </ol> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (121, 1, 0, '2009-11-24 10:53:16.361', 'epoiseau', '<p>This use case tests a simple send of an Unverified (R) report from a Report Creator to a Report Manager, using Transaction CARD-7.   At the Report MANAGER, the report status is then changed from Unverified (R) to Preliminary (P), or Final (F) or Corrected (C), and signed.</p> <H3> Evaluation: </H3> <p> Verify the following elements at the Report Manager via the database, log files, or some other means provided by the vendor. Verify that both reports are completely readable/viewable at the Report Manager.  Verify that only the second report is signed. </p> <pre> For the first report (CARD-7), verify specific data elements: &#61607;	OBR25 = R  (first report)  For OBX w/ Study Instance UID, verify: &#61607;	OBX3= ''113014^DICOM Study^DCM'' &#61607;	OBX5 = valid format for SIU &#61607;	OBX11 = ''O'' For OBX w/ PDF report, verify: &#61607;	OBX3 = a (any) Report Title, e.g., a Report Title from Vol 2 Appendix D &#61607;	OBX 5 Source Application ID = a valid ISO OID &#61607;	OBX5 Type of Data = ''Application'' &#61607;	OBX5 Data Subtype = ''PDF'' &#61607;	OBX11= R  (matches OBR25) At the Report Manager, view the report and verify that the following data items are easily readable on the second PDF report: &#61607;	Identity of signing clinician (legal signature) The following items are recommended, but not required (please note which are included): &#61607;	Patient name &#61607;	Patient ID &#61607;	Date of Procedure &#61607;	Type of Procedure &#61607;	Date of Report &#61607;	Status of Report </pre> <p> The Report Manager must clearly prove that the different reports with different report statuses are available for the same Order Filler Number/Accession Number and Report Title. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (122, 1, 0, '2009-11-24 10:53:16.363', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p> </p><H3>Description</H3><p>This test  verifies the interoperability between Report Creators and Report Managers for  submitting new reports and updates to reports already submitted.</p><p>    Note:&nbsp; the correct formatting by the Report Creators  of MDM messages is verified in test<em> DRPT_RC_Submission_Scrutiny.&nbsp;</em>  </p><H3>Evaluation</H3><ol>     <li>The  Report Manager must clearly demonstrate that the different reports with  different report statuses have been received via the database, log files, or  some other means provided by the vendor.</li>     <li>Each  updated version of a document must have its own unique document number.&nbsp; Verify that the value for TXA-12 is different  in the two MDM messages. </li>     <li>Verify  that both reports are completely readable.</li>     <li>At the Report Manager, view the report and verify       that the following data items are easily readable on the PDF report:     <ul>       <li>Patient name</li>       <li>Patient ID</li>       <li>Date of Procedure</li>       <li>Date of Report</li>       <li>Status of Report</li>       <li>Identity of signing  clinician </li>      </ul>     </li> </ol> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (123, 1, 0, '2009-11-24 10:53:16.365', 'epoiseau', '<H3>Description</H3> <p>This use case tests a simple send of an Unverified (R) report from a Report Creator to a Report Manager, using Transaction CARD-7.   At the Report CREATOR, the report status is then changed from Unverified (R) to Preliminary (P), or Final (F), or Corrected (C), and again sent to the Report Manager.    </p> <H3> Evaluation: </H3> <p>  Verify the following elements at the Report Manager via the database, log files, or some other means provided by the vendor. Verify that both reports are completely readable. </p> <pre> Verify specific data elements: -	OBR25 = R  (first report) or P|F|C (second report) For OBX w/ Study Instance UID, verify: -	OBX3= "113014^DICOM Study^DCM" -	OBX5 = valid format for SIU -	OBX11 = "O" For OBX w/ PDF report, verify: -	OBX3 = a (any) Report Title, e.g., a Report Title from Vol 2 Appendix D -	OBX 5 Source Application ID = a valid ISO OID -	OBX5 Type of Data = "Application" -	OBX5 Data Subtype = "PDF" -	OBX11= R or P|F|C and matches OBR25 At the Report Manager, view the report and verify that the following data items are easily readable on the PDF report: -	Identity of signing clinician (legal signature) The following items are recommended, but not required (please note which are included): -	Patient name -	Patient ID -	Date of Procedure -	Type of Procedure -	Date of Report -	Status of Report </pre> <p> The Report Manager must clearly prove that the different reports with different report statuses are available for the same Order Filler Number/Accession Number and Report Title. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (124, 1, 0, '2009-11-24 10:53:16.368', 'epoiseau', '<p>This use case tests a simple send of at least two Final (F) or Corrected (C) reports from a Report Creator to a Report Manager, using Transaction CARD-7.   These reports should have the same Order Filler Number, but different titles.  A common example of this is a single Requested Procedure which results in a Diagnostic Cath Report and an Interventional Cath Report.</p> <H3> Evaluation: </H3> <p> Verify the following elements at the Report Manager via the database, log files, or some other means provided by the vendor. Verify that both reports are completely readable/viewable at the Report Manager.  <pre> Verify specific data elements: &#61607;	OBR3 = note Order Filler Number &#61607;	OBR25 = F|C  (in message from Report Creator)  For OBX w/ Study Instance UID, verify: &#61607;	OBX5 = note the SIU For OBX w/ PDF report, verify: &#61607;	OBX3 = a (any) Report Title, e.g., a Report Title from Vol 2 Appendix D; note two different report titles &#61607;	OBX 5 Source Application ID = a valid ISO OID </pre> <p> The Report Manager must clearly prove that the different reports with different report titles are available for the same Order Number. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (125, 1, 0, '2009-11-24 10:53:16.369', 'epoiseau', '<p>This use case tests a simple send of a signed Final (F) or Corrected (C) report from a Report Creator to a Report Manager, using Transaction CARD-7.   At the Report MANAGER, the report status is noted as Final (F) or Corrected (C) and the report has been signed.</p> <H3> Evaluation: </H3> <p> Verify the following elements at the Report Manager via the database, log files, or some other means provided by the vendor. Verify that both reports are completely readable/viewable at the Report Manager. Verify that only the second report is signed. </p> <pre> For the report (CARD-7), verify specific data elements: &#61607;	OBR25 = F|C  (in message from Report Creator)  For OBX w/ Study Instance UID, verify: &#61607;	OBX3= ''113014^DICOM Study^DCM'' &#61607;	OBX5 = valid format for SIU &#61607;	OBX11 = ''O'' For OBX w/ PDF report, verify: &#61607;	OBX3 = a (any) Report Title, e.g., a Report Title from Vol 2 Appendix D &#61607;	OBX 5 Source Application ID = a valid ISO OID &#61607;	OBX5 Type of Data = ''Application'' &#61607;	OBX5 Data Subtype = ''PDF'' &#61607;	OBX11= F|C and matches OBR25 At the Report Manager, view the report and verify that the following data items are easily readable on the received PDF report: &#61607;	Identity of signing clinician (legal signature) If the Report Manager also places the report through a signature cycle, verify that the following data items are easily readable on the re-signed PDF report: &#61607;	Identity of signing clinician (legal signature) The following items are recommended, but not required (please note which are included): &#61607;	Patient name &#61607;	Patient ID &#61607;	Date of Procedure &#61607;	Type of Procedure &#61607;	Date of Report &#61607;	Status of Report </pre> <p> The Report Manager must clearly prove that the different reports with different report statuses are available for the same Order Filler Number/Accession Number and Report Title. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (126, 1, 0, '2009-11-24 10:53:16.372', 'epoiseau', ' <H3>Special Instructions</H3>  <p>Report Creators run one instance of this test.</p>    <p>This test should be done on the first day of the Connectathon. This test in included due to the absence of new MESA tests in the 2007-08 testing season.</p>   <H3>Description</H3> <p>This test verifies that the Report Creator is creating valid PDF/A documents encapsulated in a properly-formatted MDM message.</p>   <H3>Evaluation</H3> <p>The next two items should have been captured by the Report Creator in the kudu chat window. </p>    <p>Verify:</p>  <ol start="1" type="1">   <li>The values for Unique Document Number in TXA-12 is different in the three MDM messages</li>    <li>In the 3nd MDM message for the updated report, TXA-13, Parent Document Number contains the Unique Document Number of the document being replaced (ie the value of TXA-12 in the second (previous message).</li>    </ol>  <p>   The Connectathon Monitor will also manually inspect the MDM messages submitted by the Report Creator.         Patient names should be    <em><RC''s-kudu-system-name>^SCRUTINY</em>    and    <em><RC''s-kudu-system-name>^FINAL-CORRECT.</em>         For one message, do the complete verification:    </p> <ol start="3" type="1">   <li>The encapsulated document is valid PDF/A (tool needed).</li>    <li>MSH Segment - required fields:</li>  <ul type="disc">   <li>MSH-1            Field Separator</li>    <li>MSH-2            Encoding Characters</li>    <li>MSH-3            Sending Application</li>    <li>MSH-4            Sending Facility</li>    <li>MSH-5            Receiving Application</li>    <li>MSH-6            Receiving Facility</li>    <li>MSH-9            Message Type.</li>  <ul>   <li>Value:  MDM^T02 for patient <RC''s-kudu-system-name>^PRELIMINARY</li>    >    <li>Value:  MDM^T10 for the update to final for patient <RC''s-kudu-system-name>^FINAL-CORRECT</li>    </ul>   <li>MSH-10          Message Control</li>    <li>MSH-11          Processing ID</li>    <li>MSH-12          Version ID</li>    </ul>   <li>EVN Segment - required fields:</li>  <ul type="disc">   <li>EVN-2            Recorded Date/Time</li>    </ul>   <li>PID Segment - required fields:</li>  <ul type="disc">   <li>PID-3              Patient Identifier List</li>    <li>PID-5              Patient Name</li>    </ul>   <li>EVN Segment - required fields:</li>  <ul type="disc">   <li>PV1-2              Patient Class</li>    </ul>   <li>ORC Segment - required fields:</li>  <ul type="disc">   <li>ORC-1                        Order Control</li>    <li>ORC-2                        Placer Order Number (note that the Assigning Authority sub-component must also be specified; if the Report Creator does not have these identifiers from the actual Placer and Filler systems, it must fill the fields with an identifier that it creates, and identify the assigning authority as itself. )</li>    <li>ORC-3                        Filler Order Number (note that the Assigning Authority sub-component must also be specified; if the Report Creator does not have these identifiers from the actual Placer and Filler systems, it must fill the fields with an identifier that it creates, and identify the assigning authority as itself. )</li>    </ul>   <li>OBR Segment - required fields:</li>  <ul type="disc">   <li>OBR-1                        Set ID</li>    <li>OBR-4                        Universal Service ID</li>    <li>OBR-7                        Observation Date/Time</li>    <li>OBR-25          Result Status.   Value must be one of:  R  P   F  or  C</li>    </ul>   <li>TXA Segment - required fields:</li>  <ul type="disc">   <li>TXA-1             Set ID</li>    <li>TXA-2             Document Type</li>    <li>TXA-12           Unique Document Number – formatted as an OID (64 char limit)</li>  <li>   TXA-13                                                           Parent Document    <em>(this field only exists for the update message for patient</em>    <RC''s-kudu-system-name>^FINAL-CORRECT. It contains the value of TXA-12 for this patient''s preliminary report.    </li>   <li>TXA-17           Document Completion Status.  Value must be one of:  PA, AU, LA</li>    <li>TXA-22           Authentication Person (TXA-22.2 and/or TXA-22.3 shall be valued),  and Time Stamp (TXA-22.15 shall be valued)</li>    </ul>   <li>OBX Segment for Study Instance UID (included if the report is created for a Requested Procedure managed by a DSS/OF) - required fields:</li>  <ul type="disc">   <li>OBX-1          Set ID</li>    <li>OBX-2          Value Type = HD</li>    <li>OBX-3          Observation Identifier.  Value is 113014^DICOM Study^DCM</li>    <li>OBX-5          Observation Value.  Value shall include the Study Instance UID as an ISO OID</li>    <li>OBX-11          Observation Result Status.  Value must be ''O''</li>    </ul>   <li>OBX Segment for the Encapsulated Report - required fields:</li>  <ul type="disc">   <li>OBX-1        Set ID</li>    <li>OBX-2         Value Type = ED</li>    <li>OBX-3         Observation Identifier.  Shall contain the report title.</li>    <li>OBX-5.2         Type of Data.  Value is ''Application''</li>    <li>OBX-5.3         Subtype.  Value is ''PDF''.</li>    <li>OBX-5.4         Encoding.  Value is ''Base64''.</li>    <li>OBX 5.5         Data.  Value is the Base 64-encoded PDF (in PDF/A format)</li>    <li>OBX-11          Observation Result Status.  Value must be one of:  R  P   F  or  C</li>    </ul>   </ol> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (127, 1, 0, '2009-11-24 10:53:16.374', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Report  Managers who support the <strong>DICOM Storage</strong> option run one instance of this test.</p> <p>  You must run test DRPT_RM_Scrutiny before running this test. You should re-use here the report from that  test for patient RM''s-kudu-system-name^SCRUTINY.</p> </p><H3>Description</H3><p>This test verifies the Report Manager&rsquo;s ability to correctly encode the DICOM Encapsulated PDF object, mapping values from the MDM message as required in the CARD-9 transaction.</p><H3>Evaluation</H3><p>It will  be more efficient if you do the evaluation of test <strong>DRPT_RM_Submission_Scrutiny</strong> and <strong>DRPT_RM_Mapping_DICOM_Option</strong> at the same time for one Report  Manager system.&nbsp; </p><p> <br>    The  Connectathon Monitor finds on the Connectathon CENTRAL_ARCHIVE the DICOM object  for patient <em>RM''s kudu-system-name.</em>&nbsp;&nbsp; Dump the DICOM header and verify the values  for the attributes in the table below.&nbsp; </p><p> <br>    Column  4 in this table contains values required by the CARD-9 transaction to be mapped  into these DICOM attributes from the MDM message received in CARD-7.</p><p> <br>    If  Column 4 says &ldquo;Type 1&rdquo;, this indicates that the Enscapsulated PDF object is  required to have a value in this attribute, but the CARD-9 transaction does not  specify a required mapping.</p><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td valign="top"> <p align="center"> <strong>DICOM tag</strong> </p> </td>     <td valign="top"> <p align="center"> <strong>Attribute Name</strong> </p> </td>     <td valign="top"> <p align="center"> <strong>Mapped from</strong> </p> </td>     <td valign="top"> <p align="center"> <strong>Value</strong> </p> </td>     </tr>     <tr>      <td valign="top"> <p>(0008,0016)</p> </td>     <td valign="top"> <p>SOP    Class UID</p> </td>     <td valign="top"> <p>&nbsp;</p> </td>     <td valign="top"> <p>1.2.840.10008.5.1.4.1.1.104.1</p> </td>     </tr>     <tr>      <td valign="top"> <p>(0008,0018)</p> </td>     <td valign="top"> <p>SOP    Instance UID</p> </td>     <td valign="top"> <p>TXA-12</p> </td>     <td valign="top"> <p>Tbd    from MDM msg</p> </td>     </tr>     <tr>      <td valign="top"> <p>(0008,002A)</p> </td>     <td valign="top"> <p>Acquisition    Datetime</p> </td>     <td valign="top"> <p>OBR-7</p> </td>     <td valign="top"> <p>Tbd    from MDM msg</p> </td>     </tr>     <tr>      <td valign="top"> <p>(0008,0060)</p> </td>     <td valign="top"> <p>Modality</p> </td>     <td valign="top"> <p>&nbsp;</p> </td>     <td valign="top"> <p>Defaults    to &ldquo;OT&rdquo; if RM does not know the value.</p> </td>     </tr>     <tr>      <td valign="top"> <p>(0008,0064)</p> </td>     <td valign="top"> <p>Conversion    Type</p> </td>     <td valign="top"> <p>&nbsp;</p> </td>     <td valign="top"> <p>Type    1</p> </td>     </tr>     <tr>      <td valign="top"> <p>(0010,0010)</p> </td>     <td valign="top"> <p>Patient    Name</p> </td>     <td valign="top"> <p>PID-5</p> </td>     <td valign="top"> <p>Tbd    from MDM msg</p> </td>     </tr>     <tr>      <td valign="top"> <p>(0010,0020)</p> </td>     <td valign="top"> <p>Patient    ID</p> </td>     <td valign="top"> <p>PID-3</p> </td>     <td valign="top"> <p>Tbd    from MDM msg</p> </td>     </tr>     <tr>      <td valign="top"> <p>(0020,000D)</p> </td>     <td valign="top"> <p>Study    Instance UID</p> </td>     <td valign="top"> <p>OBX-5</p> </td>     <td valign="top"> <p>Tbd    from MDM msg</p> </td>     </tr>     <tr>      <td valign="top"> <p>(0020,000E)</p> </td>     <td valign="top"> <p>Series    Instance UID</p> </td>     <td valign="top"> <p>&nbsp;</p> </td>     <td valign="top"> <p>Type    1 &ndash; RM generates</p> </td>     </tr>     <tr>      <td valign="top"> <p>(0020,0011)</p> </td>     <td valign="top"> <p>Series    Number</p> </td>     <td valign="top"> <p>&nbsp;</p> </td>     <td valign="top"> <p>Type    1 &ndash; RM generates</p> </td>     </tr>     <tr>      <td valign="top"> <p>(0020,0013)</p> </td>     <td valign="top"> <p>Instance    Number</p> </td>     <td valign="top"> <p>&nbsp;</p> </td>     <td valign="top"> <p>Type    1 &ndash; RM generates</p> </td>     </tr>     <tr>      <td valign="top"> <p>(0028,0301)</p> </td>     <td valign="top"> <p>Burned    in Annotation</p> </td>     <td valign="top"> <p>&nbsp;</p> </td>     <td valign="top"> <p>Value    shall be &lsquo;YES&rsquo;</p> </td>     </tr>     <tr>      <td valign="top"> <p>(0040,0A43)</p> </td>     <td valign="top"> <p>Name    Code Seq</p> </td>     <td valign="top"> <p>OBX-3</p> </td>     <td valign="top"> <p>Tbd    from MDM msg</p> </td>     </tr>     <tr>      <td valign="top"> <p>(0040,A493)</p> </td>     <td valign="top"> <p>Verification    Flag</p> </td>     <td valign="top"> <p>OBX-11</p> </td>     <td valign="top"> <p>Value    shall be &lsquo;VERIFIED&rsquo;</p> </td>     </tr>     <tr>      <td valign="top"> <p>(0042,0010)</p> </td>     <td valign="top"> <p>Document    Title</p> </td>     <td valign="top"> <p>OBX-3</p> </td>     <td valign="top"> <p>Tbd    from MDM msg</p> </td>     </tr>     <tr>      <td valign="top"> <p>(0042,0011)</p> </td>     <td valign="top"> <p>Encapsulated    Document</p> </td>     <td valign="top"> <p>OBX-5.5</p> </td>     <td valign="top"> <p>This    is the PDF/A report itself &ndash; unencoded from base64 to PDF binary.</p> </td>     </tr>     <tr>      <td valign="top"> <p>(0042,0012)</p> </td>     <td valign="top"> <p>MIME    Type</p> </td>     <td valign="top"> <p>&nbsp;</p> </td>     <td valign="top"> <p>Value    shall be "application/pdf"</p> </td>     </tr> </table> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (128, 1, 0, '2009-11-24 10:53:16.378', 'epoiseau', '<H3>Special Instructions</H3><p> <p>A Report Creator is needed to help with this test by submitting a report, but is specified as an optional actor in (ie it is not required to complete 3 instances of this test).</p> </p><H3>Description</H3><p>This tests the ability of the Report Manager to notify a DSS/OF of a report.</p><H3>Evaluation</H3><ol start="1" type="1">     <li>The       DSS/OF shall demonstrate for the Connectathon Monitor that the reference       to the report, and the update, for patient <em>RM-kudu-system-name^OF-kudu-system</em>-<em>name</em> has been received by its system</li>     <li>The       DSS/OF shall demonstrate how its application uses receipt of the report       notification message.&nbsp; The DRPT       profile does not require specific functionality, but the DSS/OF may use       receipt of a final report to mark an order as Complete.</li> </ol> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (129, 1, 0, '2009-11-24 10:53:16.38', 'epoiseau', '<p>This use case tests the creation and content of an DICOM message with an encapsulated PDF report.   This tests the CARD-9 Transaction. This test case is only valid when the Report Manager is NOT grouped with the Report Repository, that is, this test case is only valid if the Report Manager DOES support the DICOM OPTION. </p> <H3> Evaluation: </H3> <p> <pre> At the Report Manager, via the database, log files, or some other means provided by the vendor, note the following information: &#61607;	OBR3 = note Order Filler Number &#61607;	OBR25 = note the status: R/P/F/C For OBX w/ Study Instance UID: &#61607;	OBX5 = note the SIU For OBX w/ PDF report reference: &#61607;	OBX3 = note the Report Title Please note all information in the PID segment. At the Report Repository, via the database, log files, or some other means provided by the vendor, note the following information and compare to Report Manager information: Patient Name (0010, 0010) Patient ID (0010, 0020) Order Filler Number  (0040, 2017) Study Instance UID (0020, 000D) is from OBX5  Document Title (0042, 0010) is from OBX3    Report Status (0040, A493) translated from OBX11 to Verified or Unverified correctly Verify Storage Commitment for the SOP Instance UID of this report. </pre> </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (130, 1, 0, '2009-11-24 10:53:16.382', 'epoiseau', '<H3>Special Instructions</H3><p> <p> <strong>DRPT_RM_RRepos_Submit_Report</strong> is only run by Report Managers  which support the DICOM Storage option, ie which ARE NOT grouped with a Report  Repository.&nbsp; If your system groups these  actors, you are not required to run this test.</p> <p>    A Report Creator is needed to help with this test by  submitting a report, but is specified as an optional actor in (ie it is not  required to complete 3 instances of this test).</p> </p><H3>Description</H3><p>This use case tests a simple send of an Unverified (R) report from a Report Creator to a Report Manager. At the Report MANAGER, the report status is then changed from Unverified (R) to Preliminary (P), or Final (F), or Corrected (C), signed and stored (CARD-9 and RAD-10) to the Report Repository.</p><H3>Evaluation</H3><ol>     <li>The  Report Repository will demonstrate for the Connectathon Monitor how it  configures the web service access point of the Report Repository as the target  of the Retrieve Document for Display [ITI-12] transaction.&nbsp; </li>     <li>The  Report Repository must clearly demonstrate that the different reports with  different report statuses have been received via the database, log files, or  some other means provided by the vendor.</li>     <li>Verify  that both reports are completely readable.</li>     <li>At the Report Repository, view the report and       verify that the following data items are easily readable on the PDF       report:</li> </ol><ul>     <ul>      <li>Patient name</li>      <li>Patient ID</li>      <li>Date of Procedure</li>      <li>Date of Report</li>      <li>Status of Report</li>      <li>Identity of  signing clinician</li>     </ul> </ul><p>5. The  Connectathon monitor should also observe logs in the Report Repository that  demonstrate the Storage Commitment transaction.&nbsp;  All of the following attributes shall be verified in the Storage Commit  N-ACTION msg from the Report Manager:</p><p>Referenced SOP  Sequence (0008, 1199)</p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;Reference  SOP Class (0008, 1150)</p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;Referenced  SOP Instance UID (0008, 1155)</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (131, 1, 0, '2009-11-24 10:53:16.384', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Report Manager actors run one instance of this test.</p> <p>    The Report Manager will need to obtain several reports  from Report Creators before it is ready to have the Connectathon Monitor perform  the evaluation for this test.</p> </p> <H3>Description</H3> <p>The DRPT profile specifies several functional requirements for the Report Manager actor.  These are evaluated in this no-peer test.</p> <H3>Evaluation</H3> <p>On the <strong>Report Manager</strong>,  verify: </p> <ol start="1" type="1">     <li>The       Report Manager will demonstrate for the Connectathon Monitor the ability       edit the PDF content, at minimum by adding a “cover page” with the report       status, and identity of signing clinician<em>.  </em><em>. </em>The Technical       Framework does not specify how this is accomplished, but the Connectathon       Monitor should be able to see a report created at a Report Creator without       such a cover page, and then see an updated version of the report with the       modifications by going to a Report Reader and retrieving the updated       report from the Report Manager under test, or by viewing the PDF at the       Report Manager.</li>     <li>The       Report Manager will demonstrate for the Connectathon Monitor the method it       uses to determine when the report is to be released, or made available, to       the enterprise.  The Technical       Framework does not specify how this is accomplished, so the Monitor may       have to apply some judgment.  If the       Report Manager immediately passes through all reports received from Report       Creators, it will fail this test.</li>     <li>The       Report Manager will demonstrate for the Connectathon Monitor its ability       to change the status of a report.        This can be done by soliciting the help of a Report Reader which       can display a Preliminary and Final report sent by the Report Manager       during this evaluation</li>     <li>This       evaluation step will require a pre-prepared dataset.  The Report Manager will obtain the       reports for patient DRPT^Multiple-Reports from the Connectathon wiki (or       other source).  This patient has       multiple reports with different titles for the same Order.  One report is titled  “Cardiac Cath Diagnostic Report” and the       second report is titled “Cardiac Cath Intervention Report”.  One report is preliminary and the other       is final.</li> </ol> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (132, 1, 0, '2009-11-24 10:53:16.387', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Report Managers run one instance of this test.</p> <p>In this test you will capture sample messages you will create for the Monitor to evaluate.  Report Manager will upload a sample MDM, and a copy of the PDF, into kudu under <b>Connectathon --> Connectathon...Objects</b> <p>The Report Manager must solicit the help of a Report Creator  to submit one report to the Report Manager.</p> <p>    This test should be done on the first day of the  Connectathon.  This test in included due  to the absence of new MESA  tests in the 2007-08 testing season.</p> <p>    If your Report Manager supports the DICOM Storage option (ie  is not grouped with a Report Repository), after completing this test, you  should immediately proceed to run test <strong>DRPT_RM_Mapping_DICOM_Option.</strong> </p> </p> <H3>Description</H3> <p>This test verifies that the Report Manager is submitting valid PDF/A documents encapsulated in    a properly-formatted MDM message using the CARD-7 transaction. The Report Manager''s    ability to change the status of a report is tested in another test.</p>  <H3>Evaluation</H3> <p>You will find the samples from this system in kudu under <b>Connectathon --> Connectathon...objects</b></p> <p>It will be more efficient if you do the evaluation of test    <strong>DRPT_RM_Submission_Scrutiny</strong> and <strong>DRPT_RM_Mapping_DICOM_Option</strong> at    the same time for one Report Manager system.  Note, however, that if a Report Manager    does not support the <strong>DICOM Storage</strong> option, it is not required to run test     <strong>DRPT_RM_Mapping_DICOM_Option.</strong> </p> <p>The Connectathon Monitor will inspect the MDM message    submitted by the Report Manager into Kudu under <b>Connectathon --> Connectathon...Objects</b>  Patient name should be:     <em>RMs-kudu-system-name^SCRUTINY</em>. </p>  <p>Verify: </p><ol start="1" type="1">     <li>The encapsulated document is valid PDF/A (tool needed).</li>     <li>MSH Segment - required fields:</li> </ol><ol start="1" type="1">     <ul type="disc">      <li>MSH-1                 Field Separator</li>      <li>MSH-2                 Encoding Characters</li>      <li>MSH-3                 Sending Application</li>      <li>MSH-4                 Sending Facility</li>      <li>MSH-5                 Receiving Application</li>      <li>MSH-6                 Receiving Facility</li>      <li>MSH-9                 Message Type.   Value:  MDM^T02</li>      <li>MSH-10               Message Control</li>      <li>MSH-11               Processing ID</li>      <li>MSH-12               Version ID</li>     </ul> </ol><ol start="3" type="1">     <li>EVN Segment - required fields:</li> </ol><ol start="1" type="1">     <ul type="disc">      <li>EVN-2                      Recorded Date/Time</li>     </ul> </ol>   <ol start="4" type="1">     <li>PID Segment - required fields:</li> </ol><ol start="1" type="1">     <ul type="disc">      <li>PID-3                        Patient Identifier List</li>      <li>PID-5                   Patient Name</li>     </ul> </ol><ol start="5" type="1">    <li>PV1 Segment - required fields:</li> </ol>  <ol start="1" type="1">     <ul type="disc">      <li>PV1-2                        Patient Class </li>     </ul> </ol>  <ol start="6" type="1">     <li>ORC Segment - required fields:</li> </ol><ol start="1" type="1">     <ul type="disc">      <li>ORC-1                             Order Control</li>      <li>ORC-2                             Placer Order Number (if the value of Assigning Authority indicates that the Placer Order number      was generated by the Report Creator, the Report Manager must be able to replace it with an      identifier supplied by the Order Placer ) </li>      <li>ORC-3                             Filler Order Number (if the value of Assigning Authority indicates that the Filler Order number      was generated by the Report Creator, the Report Manager must be able to replace it with an      identifier supplied by the Order Filler )</li>     </ul> </ol>  <ol start="7" type="1">     <li>OBR Segment - required fields:</li> </ol>  <ol start="1" type="1">     <ul type="disc">      <li>OBR-1                             Set ID</li>      <li>OBR-2                             Placer Order Number Placer Order Number (if the value of Assigning Authority indicates that the      Placer Order number was generated by the Report Creator, the Report Manager must be able to      replace it with an identifier supplied by the Order Placer )</li>      <li>OBR-3                             Filler Order Number (if the value of Assigning Authority indicates that the Filler Order number      was generated by the Report Creator, the Report Manager must be able to replace it with an      identifier supplied by the Order Filler )</li>      <li>OBR-4                             Universal Service ID</li>      <li>OBR-7                             Observation Date/Time</li>      <li>OBR-25               Result Status.   Value must be one of:  R       P   F  or  C</li>     </ul> </ol>  <ol start="8" type="1">     <li>TXA Segment - required fields:</li> </ol><ol start="1" type="1">     <ul type="disc">      <li>TXA-1                  Set ID</li>      <li>TXA-2                  Document Type</li>      <li>TXA-12                Unique Document Number</li>      <li>TXA-14                Placer Order Number (if the value of Assigning Authority indicates that the Placer Order number      was generated by the Report Creator, the Report Manager must be able to replace it with an      identifier supplied by the Order Placer )</li>      <li>TXA-15                Filler Order Number (if the value of Assigning Authority indicates that the Filler Order number      was generated by the Report Creator, the Report Manager must be able to replace it with an      identifier supplied by the Order Filler )</li>      <li>TXA-17                     Document Completion Status.  Value must be one of:  PA, AU, LA</li>      <li>TXA-22                Authentication Person, Time Stamp</li>     </ul> </ol>  <ol start="9" type="1">     <li>      <em>NOTE:  This segment is optional in the msg sent by the RM.<br> OBX Segment for      Study Instance UID – required fields:</em>     </li> </ol>  <ol start="1" type="1">     <ul type="disc">      <li>       <em>OBX-1                   Set ID</em>      </li>      <li>       <em>OBX-2                   Value Type = HD</em>      </li>      <li>       <em>OBX-3                   Observation Identifier.  Value is 113014^DICOM Study^DCM</em>      </li>      <li>       <em>OBX-5                   Observation Value.  Value shall include the Study Instance UID as an ISO OID</em>      </li>      <li>       <em>OBX-11                 Observation Result Status.  Value must be:</em>      </li>     </ul> </ol>  <ol start="10" type="1">     <li>OBX Segment for the Encapsulated Report - required fields:</li> </ol>  <ol start="1" type="1">     <ul type="disc">      <li>OBX-1                             Set ID</li>      <li>OBX-2                             Value Type = ED</li>      <li>OBX-3                             Observation Identifier.  Shall contain the report title.</li>      <li>OBX-5.2         Type      of Data.  Value is ''Application''</li>      <li>OBX-5.3              Subtype.  Value is ''PDF''.</li>      <li>OBX-5.4              Encoding.  Value is ''Base64''.</li>      <li>OBX 5.5              Data.  Value is the Base 64-encoded PDF (in PDF/A format)</li>      <li>OBX-11               Observation Result Status.  Value must be one of:  R       P   F  or  C</li>     </ul> </ol>  <ul>     <li>      <em>Note:  Additional OBX segments may be present</em>     </li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (133, 1, 0, '2009-11-24 10:53:16.39', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Report Repositories which support the DICOM Storage option  are required to run this test.</p> <p>    Note that this test should be performed later in the week  after the Report Repository has collected as many reports as possible from all  of the various Report Creators.&nbsp; It is to  the vendor&rsquo;s advantage to verify that they have retrieved and displayed reports  from all Report Creator Actors/Vendors possible.&nbsp;&nbsp; </p> </p><H3>Description</H3><p>This test the ability of the Report Reader and Report Repository to exchange reports using DICOM Query/Retrieve.</p><H3>Evaluation</H3><p>The <strong>Report Reader</strong> should demonstrate &lsquo;live&rsquo; for the Connectathon Monitor, the ability to query  the Report Repository, then retrieve reports and display them. </p><ol start="1" type="1">     <li>The       CARD-10 transaction requires the following attributes to be supported by       the Report Reader as query keys.&nbsp;       Likewise, the Report Repository (Query SCP) must return values for       each of these attributes in the C-FIND response.&nbsp; Verify the ability to query by, and       return values for:     <ul>       <li>Verification Flag (0040,A493)</li>       <li>Concept Name Code Sequence (0040,A043)        <ul>         <li>&gt;Code Value (0008,0100)</li>         <li>&gt;Coding Scheme Designator (0008,0102)</li>        </ul>       </li>      </ul>     </li>         <li>Other       query/return keys are required by the RAD-14 transaction.&nbsp; This is a subset of those and a       combination of these should be verified:</li> </ol><ul>     <ul>      <li>Study  Date (0008,0020) or Performed Procedure Step Start Date (0040,0244)</li>      <li>Patient  ID (0010,0020)</li>      <li>Patient  Name (0010,0010)</li>      <li>Accession  Number (0008,0050)</li>     </ul> </ul><ol start="3" type="1">     <li>Verify       that the reports were successfully received on the Report Reader.</li>     <li>Verify       that the PDF for each report is viewable on the Report Reader application.</li> </ol> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (134, 1, 0, '2009-11-24 10:53:16.392', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test is for Report Repository actors grouped with a PAM Patient Demographics Consumer    which supports the &ldquo;Merge&rdquo; option.&nbsp; This test is a super-set of the    test steps in test <em>PAM_ID_Mgmt_Europe</em>.&nbsp; If you are a Report Repository in DRPT,    you must run this test instead of that one.</p> <p> A DRPT Report Creator actor is needed to help with this test.&nbsp; It is marked as an    &lsquo;optional&rsquo; actor because it is not required to complete 3 instances of this    test for its Connectathon work.</p> <p> Patient Names created by the Patient Demographics Supplier will follow a pattern to make    things easy to follow. The last name shall have 3 components (with no separators): </p> <ul type="disc">     <li>The letters Pam </li>     <li>The Report Repository&rsquo;s Kudu system name</li>     <li>Any special characters required in the test; (eg &ouml;; might be null)</li> </ul> <p>In the test instructions, last names will look like this: </p> <ul type="disc">     <li>Pam<strong>system</strong>letters</li> </ul> <p>where <strong>system</strong> marks your system, and ''letters'' are specific to the test.</p> <p> First name will be used to distinguish different parts of the test. </p> </p><H3>Description</H3><p>This test verifies the ability of the Report Repository to keep demographics associated with a    report updated based on patient update and merge messages received from the Patient Demographics    Supplier.</p><p> This test is based on the use case defined in the PAM profile. This version of the test    differs slightly from the NA version with some extra characters in patient names.</p><H3>Evaluation</H3><p>See the test step descriptions.</p><p> Verify: </p><ol start="1" type="1">     <li>Both systems properly hand the &ouml; character in patient name     Pam<strong>system</strong>&ouml;^Cd </li>     <li>The Report Repository should show you a screen capture of the report for patient      Pam<strong>system</strong>&ouml;^Cd (the 1st updated patient name).</li>     <li>The Report Repository should show you a screen capture of the report for patient      Pam<strong>system</strong>^Ef.&nbsp; (the second patient)</li>     <li>Find a Report Reader or RID Display system and query the Report Repository for patient      Pam<strong>system</strong>&ouml;^Cd and retrieve all associated reports.&nbsp; You     should see both reports from the previous screen captures.&nbsp; Both reports should be     associated with patient Pam<strong>system</strong>&ouml;^Cd.</li> </ol><p>If the Report Repository cannot show this with screen captures, the Connectathon monitor will    ask to see the test performed in real time.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (135, 1, 0, '2009-11-24 10:53:16.394', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test is for Report Repository actors grouped with a PAM  Patient Demographics Consumer which supports the &ldquo;Merge&rdquo; option.&nbsp; This test is a super-set of the test steps in  test <em>PAM_Identity_Management</em>.&nbsp; If you are a Report Repository in DRPT, you  must run this test instead of that one.</p> <p>    A DRPT Report Creator actor is needed to help with this  test.&nbsp; It is marked as an &lsquo;optional&rsquo;  actor because it is not required to complete 3 instances of this test for its  Connectathon work.     Patient Names created by the Patient Demographics Supplier  will follow a pattern to make things easy to follow. The last name shall have 2  components (with no separators): </p> <ul>     <li>The letters Pam </li>     <li>The Report Repository&rsquo;s Kudu system  name</li> </ul> <p>    In the test instructions, last names will look like this: </p> <ul>     <li>Pam<strong>system</strong> </li> </ul> <p>    where <strong>system</strong> marks your kudu system name.</p> <p>    First name will be used to distinguish different parts of  the test. </p> </p><H3>Description</H3><p>This test  verifies the ability of the Report Repository to keep demographics associated  with a report updated based on patient update and merge messages received from  the Patient Demographics Supplier.</p><p>    This test is based on the use case defined in the PAM profile. This version of the test differs slightly from the Europe version which tests some extra characters in  patient names.</p><H3>Evaluation</H3><p>See the test step descriptions.</p><p>Verify: </p><ol start="1" type="1">     <li>The       Report Repository should show you a screen capture of the report for       patient Pam<strong>system</strong>^Cd (the 1st updated patient name).</li>     <li>The       Report Repository should show you a screen capture of the report for       patient Pam<strong>system</strong>^Ef.&nbsp; (the       second patient)</li>     <li>Find a       Report Reader or RID Display system and query the Report Repository for       patient Pam<strong>system</strong>^Cd and retrieve all associated reports.&nbsp; You should see both reports from the previous       screen captures.&nbsp; Both reports       should be associated with patient Pam<strong>system</strong>^Cd.</li> </ol><p>If the Report  Repository cannot show this with screen captures, the Connectathon monitor will  ask to see the test performed in real time.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (136, 1, 0, '2009-11-24 10:53:16.397', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test  should be performed later in the week after the Report Repository has collected  as many reports as possible from all of the various Report Creators.&nbsp; It is to the vendors advantage to verify that  they have retrieved and displayed reports from all Report Creator  Actors/Vendors possible.&nbsp;&nbsp; </p> <p>The representative of the Report Repository should drive  this test. You should find a RID Image Display which can query and display your  reports; don&rsquo;t rely on the Display systems to come and find you.&nbsp; &nbsp;The  RID Image Display is listed as an optional actor in this test since it may be  testing this functionality with other Information Sources registered in the RID  profile.</p> </p><H3>Description</H3><p>This test case tests the web query and retrieval of  PDF reports.</p><H3>Evaluation</H3><p>For each query, verify that the Retrieve Summary (XHTML  list of reports) displayed at the Display Actor is accurate as compared to the  Report Repository database.</p><p>After the document is retrieved via ITI-12, at the <strong>Report Repository,</strong> via the database,  log files, or some other means provided by the vendor, note the following  information and compare to <strong>RID Display</strong> information:</p><ul>     <li>Patient  Name </li>     <li>Patient  ID </li>     <li>Document  Title </li>     <li>Report Status </li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (137, 1, 0, '2009-11-24 10:53:16.399', 'epoiseau', '<p>This test case tests the web query and retrieval of  PDF reports. All Report Repositories, whether they support the DICOM option or are combined with the Report Manager Actor, are required to be grouped with/support a RID Information Source. Note that this test should be performed later in the week after the Report Repository has collected as many reports as possible from all of the various Report Creators.  It is to the vendors'' advantage to verify that they have retrieved and displayed reports from all Report Creator Actors/Vendors possible.    </p> <H3> Evaluation: </H3> <pre> For each query, verify that the Retrieve Summary (XHTML list of reports) displayed at the Display Actor is accurate as compared to the Report Repository database.  After the document is retrieved via ITI-12, at the Report Repository, via the database, log files, or some other means provided by the vendor, note the following information and compare to RID Display information: ''	Patient Name  ''	Patient ID  ''	Order Filler Number   ''	Document Title   ''	Report Status  ''	Date of report ''	Time of report ''	Signing Physician Name </pre> </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (138, 1, 0, '2009-11-24 10:53:16.401', 'epoiseau', '<p>This use case tests the DICOM query and retrieve of a DICOM pdf object. This test case is only valid when the Report Manager is NOT grouped with the Report Repository, that is, this test case is only valid if the Report Repository DOES support the DICOM OPTION. Note that this test should be performed later in the week after the Report Repository has collected as many reports as possible from all of the various Report Creators.  It is to the vendors'' advantage to verify that they have retrieved and displayed reports from all Report Creator Actors/Vendors possible.    </p> <H3> Evaluation: </H3> <p> <pre> At the Report Repository, via the database, log files, or some other means provided by the vendor, note the following information and compare to Report Reader information: ''	Patient Name (0010, 0010) ''	Patient ID (0010, 0020) ''	Order Filler Number  (0040, 2017) ''	Study Instance UID (0020, 000D)  ''	Document Title (0042, 0010)  ''	Report Status (0040, A493) as Verified or Unverified  For the various queries, manually record the number of responses that the Report Repository should have had and the number which were received. At the Report Reader, verify that the following Query Response Attributes are also accurate: ''	Report Title (0042, 0010)  ''	Report Status (0040,A493) is available as ''VERIFIED'' or ''UNVERIFIED''  ''	Content Date (0008,0023) ''	Content Time (0008,0033)  Upon viewing the reports at the Report Reader, view and verify the following items: ''	Patient Name (0010, 0010) ''	Patient ID (0010, 0020) ''	Order Filler Number  (0040, 2017) ''	Document Title (0042, 0010)  ''	Report Status (0040, A493) translated from OBX11 to Verified or Unverified correctly ''	Signing Physician Name </pre> </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (139, 1, 0, '2009-11-24 10:53:16.403', 'epoiseau', '<H3>Special Instructions</H3><p> <p>The Referral Requestor must configure its system to print to the Connectathon network    printer.</p> <p>You may want to do this test in parallel with test <i>DRR_Retrieve_Referral_Folder</i>.</p> </p><H3>Description</H3><p>In the DRR profile, the Referral Requestor is required to be able to create a paper version of    the referral information. This test verifies that functionality. You will be required to print a    referral request ''real-time'' in the presence of a Connectathon monitor. The ability of the    Referral Dispatcher to interpret this paper is tested in another test.</p><H3>Evaluation</H3><p>The Referral Requestor system will print a referral request for the Connectathon Monitor.    Verify:</p><ul>     <li>The paper referral contains a clearly-deliniated region in which is printed the     XDSFolder.uniqueID of the folder for the referral request. The XDSfolder.uniqueID is printed     using OCR-A fonts; this is required.</li> </ul><p>Optionally, the system may be able to print a bar-code version of the XDSFolder.uniqueID. The    Referral Requestor may print on the referral document additional explanatory information for the    patient, but the format of this additional information is not specified by IHE. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (140, 1, 0, '2009-11-24 10:53:16.405', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Referral Requestor and Referral Dispatcher actors which support the <b>Request Referral Option</b> run this test.</p> <p>Prior to starting this test, the Referral Requestor system should ensure that the XDS Folder    containing the referral documentation has been stored and is available on an XDS    Registry/Repository (or it can be transferred via XDM or XDR during the test). Given the different methods available    for transferring the referral (XDS/XDM/XDR), the Referral Requestor and Referral Dispatcher need to    do some negotiation in advance of starting this test to ensure they have complementary capabilities.</p> </p><H3>Description</H3><p>This tests the ability of the Referral Requestor to send the referral request using the ORM mechanism, and the ability of the Referral Dispatcher to extract information from the referral ORM and retrieve the referral documents.</p><H3>Evaluation</H3><p>The Connectathon monitor may ask you to demonstrate the functionality in this test real-time.</p><p>The ORM received by the <strong>Referral Dispatcher</strong> (copied into the chat window for this test) contains:</p><ul> <li>valid value(s) in <b>PID-3</b> Patient Identifier List</li> <li>a valid value in <b>PID-5</b> Patient Name</li> <li>the value ''NW'' in <b>ORC-1</b> Order Control</li> <li>no values for <b>ORC-3</b> Filler Order Number or <b>ORC-4</b> Placer Order Number</li> <li>the value for XDSFolder.uniqueID in <b>OBR-18</b> Placer Field 1 (a length of up to 250 characters)</li> </ul><p>The <b>Referral Dispatcher</b> will show that the referral document(s) were successfully retrieved and are available for use in its system.  At a minimum this will be a Referral Summary document formatted per the PCC XDS-MS profile.</p><p>The <b>Referral Requestor</b> receives a response to its order that indicates that the referral was accepted (or rejected) by the Referral Dispatcher.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (141, 1, 0, '2009-11-24 10:53:16.407', 'epoiseau', '<H3>Special Instructions</H3><p> <p>The Referral Requestor may want to do this test in parallel with test     <i>DRR_Print_Referral_Request.</i> </p> <p>Prior to starting this test, the Referral Requestor system should ensure that the XDS Folder    containing the referral documentation has been stored and is available on an XDS    Registry/Repository (or it can be transferred via XDM or XDR during the test). Given the different methods available    for transferring the referral (XDS/XDM/XDR), the Referral Requestor and Referral Dispatcher need to    do some negotiation in advance of starting this test to ensure they have complementary capabilities.</p> </p><H3>Description</H3><p>This tests the ability for the Referral Dispatcher to retrieve the folder of referral documents    pointed to on the paper referral printed by the Referral Requestor.</p><H3>Evaluation</H3><p>The Connectathon monitor may ask you to demonstrate the functionality in this test real-time.</p><ol> <li>The <b>Referral Requestor</b> creates an XDSFolder:</li> <ul>     <li>The folder contains one or more documents related to this referral request.</li>     <li>One document is a Referral Summary per the XDS-MS profile.  (Note: verifying the proper formatting of this document is done a separate XDS-MS test).  The presence of other related documents is not required; there is no requirement on the format of other documents, if present.</li>     <li>If the Referral Requestor writes the folder to media (XDM CD-R, USB or Zip over email), there is only one folder permitted per instance of media  </li>     </ul> <li>The <strong>Referral Dispatcher</strong> will demonstrate for the Connectathon monitor its    ability to import the XDSFolder.uniqueID from the paper referral. This may be using an (optional)    bar code printed on the paper, using OCR, or by manually entering the XDSFolder.uniqueID into its    system.</li> <li>The <strong>Referral Dispatcher</strong> will import the contents of the folder referenced on    the printed referral document. This may be done via an XDS retrieve, and XDR ''provide and register'' or XDM import    (CD-R, USB, email).</li> <li>Verify the contents of the folder on the Referral Requestor versus those on the Referral Dispatcher.  (The capability of the Referral Dispatcher to process the Referral Summary is verified in a separate XDS-MS test.)</li> </ol> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (142, 1, 0, '2009-11-24 10:53:16.41', 'epoiseau', '<H3>Special Instructions</H3>
 <H3>Description</H3>
 <H3>Instructions</H3>
 <p>The Document Consumer should obtain the Patient Identifier for the signed document(s) from the
 Document Source. The Document Consumer needs to retrieve the original document and the digital
 signature document from the Document Repository.</p>
 
 <p>The Document Consumer will need to demonstrate at least one of the signature verification
 mechanisms described in the DSG Integration Profile. These are listed in the Evaluation section.</p>
 
 <H3>Evaluation</H3>
 <p>The monitor shall observe the Document Consumer verifying the signature using at least one of the 
 following mechanisms:
 
  <br/>a. Verify the integrity of the signature itself,
  <br/>b. Verify a), plus that it is a valide signature,
  <br/>c. Verify b), plus that the specific documents are also unmodified and are
         the documents that were signed. This may be imposible if access to the
         documents is denied.
  <br/>d. Verify b), plusthat there is a submission set reference in the manifest and
         that the documents listed in the manifest are the complete list of documents
         in the submission set on the XDS Registry,
  <br/>e. Verify b), plus that all of the documents are available and unmodified,
  <br/>f. Verify d), plus that all of the documents are available and unmodified.
 </p>
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (143, 1, 0, '2009-11-24 10:53:16.411', 'epoiseau', '<H3>Special Instructions</H3>
 <p>The DSG profile references the XDS profile. Substitute an implementation
 of XDS.a or XDS.b and complete the test.</p>
 
 <H3>Description</H3>
 <p>In DSG_SubmitSignedDocument, the Document Creator signs at least one document by
 <ul>
  <li>storing at least one document in a Document Repository, registering the document with a Document Repository,
  <li>creating an appropriate Digital Signature document and storing that document in a Document Repository,
  <li>submitting an Association object to the Document Repository that connects the digital signature XDSDocumentEntry
      object to the XDSDocumentEntry object it signs.
 </ul>
 
 <H3>Instructions</H3>
 <p>The Document Source needs to locate a Document Repository/Registry pair that will store documents.
 Those two actors are not part of this test, but you need their assistance to complete the work.</p>
 
 <p>The Document Source shall create at least one document and store that in a Document Repository.
 The Document Source then creates the appropriate Digital Signature document, and stores that in the same
 Documentn Repository (not a profile requirement, but a simplification for testing).
 The Document Source then submits an Association object to the repository to link the signature document
 to the original document.</p>
 
 <p>After the documents are submitted, notify Document Consumers that these documents are available. It is
 advised to do this as quickly as possible in case you need help from the combination of the Document
 Registry and Document Repository. As the Document Consumer to run the test DSG_ProcessSignedDocument.</p>
 
 <H3>Evaluation</H3>
 <p>There is no formal evaluation for this test. After the documents are submitted, the real evaluation
 occurs at DSG_ProcessSignedDocument. The monitor can mark this test as completed without evaluation.
 </p>
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (144, 1, 0, '2009-11-24 10:53:16.414', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p> </p><H3>Description</H3><p>This test verifies the Report Creator&rsquo;s ability to correctly encode the DICOM Encapsulated PDF    object, and the Image Manager&rsquo;s ability to store it. </p><H3>Evaluation</H3><p>On the Image Manager, verify that the report is successfully stored.</p><p> <br> The Connectathon Monitor finds the report for patient     <em>RM_kudu_system_name^RR_kudu_system_name.</em>&nbsp;&nbsp; Dump the DICOM header and    verify the values for the attributes in the table below.</p><p>     <br> If Column 3 says &ldquo;EYECARE-7 Type 1&rdquo;, this indicates that the    Enscapsulated PDF object is required to have a value in this attribute, and the EYECARE-7    transaction has extended the DICOM requirements.</p><p> <br> If Column 3 says &ldquo;Type 1&rdquo;, this indicates that the Enscapsulated PDF    object is required to have a value in this attribute, but the EYECARE-7 transaction does not    specify a special requirement.</p><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td valign="top">       <p align="center">        <strong>DICOM tag</strong>       </p>      </td>     <td valign="top">       <p align="center">        <strong>Attribute Name</strong>       </p>      </td>     <td valign="top">       <p align="center">        <strong>Value</strong>       </p>      </td>     </tr>     <tr>      <td valign="top">       <p>(0008,0016)</p>      </td>     <td valign="top">       <p>SOP Class UID</p>      </td>     <td valign="top">       <p>1.2.840.10008.5.1.4.1.1.104.1</p>      </td>     </tr>     <tr>      <td valign="top">       <p>(0008,0018)</p>      </td>     <td valign="top">       <p>SOP Instance UID</p>      </td>     <td valign="top">       <p>&nbsp;</p>      </td>     </tr>     <tr>      <td valign="top">       <p>(0008,0023)</p>      </td>     <td valign="top">       <p>Content Date</p>      </td>     <td valign="top">       <p>EYECARE-7 &ndash; Type 1</p>      </td>     </tr>     <tr>      <td valign="top">       <p>(0008,0033)</p>      </td>     <td valign="top">       <p>Content Time</p>      </td>     <td valign="top">       <p>EYECARE-7 &ndash; Type 1</p>      </td>     </tr>     <tr>      <td valign="top">       <p>(0008,002A)</p>      </td>     <td valign="top">       <p>Acquisition Datetime</p>      </td>     <td valign="top">       <p>&nbsp;</p>      </td>     </tr>     <tr>      <td valign="top">       <p>(0008,0060)</p>      </td>     <td valign="top">       <p>Modality</p>      </td>     <td valign="top">       <p>Defaults to &ldquo;OT&rdquo; if RC does not know the value.</p>      </td>     </tr>     <tr>      <td valign="top">       <p>(0008,0064)</p>      </td>     <td valign="top">       <p>Conversion Type</p>      </td>     <td valign="top">       <p>Type 1</p>      </td>     </tr>     <tr>      <td valign="top">       <p>(0020,000D)</p>      </td>     <td valign="top">       <p>Study Instance UID</p>      </td>     <td valign="top">       <p>Type 1 &ndash; RC generates</p>      </td>     </tr>     <tr>      <td valign="top">       <p>(0020,000E)</p>      </td>     <td valign="top">       <p>Series Instance UID</p>      </td>     <td valign="top">       <p>Type 1 &ndash; RC generates</p>      </td>     </tr>     <tr>      <td valign="top">       <p>(0020,0011)</p>      </td>     <td valign="top">       <p>Series Number</p>      </td>     <td valign="top">       <p>Type 1 &ndash; RC generates</p>      </td>     </tr>     <tr>      <td valign="top">       <p>(0020,0013)</p>      </td>     <td valign="top">       <p>Instance Number</p>      </td>     <td valign="top">       <p>Type 1 &ndash; RC generates</p>      </td>     </tr>     <tr>      <td valign="top">       <p>(0040,A073)</p>       <p>&nbsp;</p>       <p>&gt;(0040,A075)</p>       <p>&gt;(0040,A027)</p>       <p>&gt;(0040,A030)</p>      </td>     <td valign="top">       <p>Verifying Observer Sequence</p>       <p>&gt;Verifying Observer Name<br> &gt;Verifying Organization</p>       <p>&gt;Verification DateTime</p>      </td>     <td valign="top">       <p>Type 1C <br> Shall have a value if Verification Flag (0040,A493) is VERIFIED.<br> Type 1</p>       <p>Type 1</p>       <p>&nbsp;</p>       <p>Type 1</p>      </td>     </tr>     <tr>      <td valign="top">       <p>(0040,A491)</p>      </td>     <td valign="top">       <p>Completion Flag</p>      </td>     <td valign="top">       <p>Type 1 <br> Value shall be either PARTIAL or COMPLETE</p>      </td>     </tr>     <tr>      <td valign="top">       <p>(0040,A493)</p>      </td>     <td valign="top">       <p>Verification Flag</p>      </td>     <td valign="top">       <p>EYECARE-7 &ndash; Type 1</p>      </td>     </tr>     <tr>      <td valign="top">       <p>(0042,0011)</p>      </td>     <td valign="top">       <p>Encapsulated Document</p>      </td>     <td valign="top">       <p>This is the PDF/A report itself &ndash; unencoded from base64 to PDF binary.</p>      </td>     </tr>     <tr>      <td valign="top">       <p>(0042,0012)</p>      </td>     <td valign="top">       <p>MIME Type</p>      </td>     <td valign="top">       <p>Value shall be &ldquo;application/pdf&rdquo;</p>      </td>     </tr> </table> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (145, 1, 0, '2009-11-24 10:53:16.416', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Note that this test should be performed later in the week after the Report Repository has collected as many reports as possible from all of the various Report Creators.  It is to the Report Reador vendor&rsquo;s advantage to verify that they have retrieved and displayed reports from all Report Creator Actors/Vendors possible.   </p> </p><H3>Description</H3><p>This test the ability of the Report Reader and Report Repository to exchange reports using DICOM Query/Retrieve</p><H3>Evaluation</H3><p>The <strong>Report Reader</strong> should demonstrate &lsquo;live&rsquo; for the Connectathon Monitor, the ability to query  the Report Repository, then retrieve reports and display them. </p><ol start="1" type="1">     <li>The EYECARE-8       transaction requires the following attributes to be supported by the       Report Reader as query keys.&nbsp;       Likewise, the Report Repository (Query SCP) must return values for       each of these attributes in the C-FIND response.&nbsp; Verify the ability to query by, and       return values for:</li>     <ol start="1" type="1">      <li>Completion        Flag (0040,A491)</li>      <li>Verification        Flag (0040,A493)</li>      <li>Verifying        Observer Sequence (0040,A073)</li>      <ul type="square">       <li>&gt;Verification         DateTime (0040,A030)</li>       <li>&gt;Verifying         Observer Name (0040,A075)</li>      </ul>      <li>Concept        Name Code Sequence (0040,A043)</li>      <ul type="square">       <li>&gt;Code         Value (0008,0100)</li>       <li>&gt;Coding         Scheme Designator (0008,0102)</li>      </ul>     </ol>     <li>Other       query/return keys are required by the RAD-14 transaction.&nbsp; This is a subset of those and a       combination of these should be verified:</li>     <ol start="1" type="1">      <li>Study        Date (0008,0020) or Performed Procedure Step Start Date (0040,0244)</li>      <li>Patient        ID (0010,0020)</li>      <li>Patient        Name (0010,0010)</li>      <li>Accession        Number (0008,0050)</li>     </ol>     <li>Verify       that the reports were successfully received on the Report Reader.</li>     <li>Verify       that the PDF for each report is viewable on the Report Reader application.</li> </ol> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (146, 1, 0, '2009-11-24 10:53:16.418', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p> </p><H3>Description</H3><p>This is a test to ensure that the Image Display query the Image Manager and retrieve DICOM evidence objects. Rendering of the objects is tested in a separate test.</p><H3>Evaluation</H3><p>The Connectathon Monitor will ask the Image Display to show evidence that it can successfully retrieve the studies from different Evidence Creator and Modality actors. This may be by rendering the objects in the study, but the correctness of the rendering is not evaluated here.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (147, 1, 0, '2009-11-24 10:53:16.422', 'epoiseau', '<H3>Special Instructions</H3><p> <p>If you have completed test <strong>EyeCare_Evidence_Creator_IM</strong> in the EyeCare Workflow test plan, and  have stored all of the types of objects (SOP Classes) that your Evidence  Creator or Image Manager supports, you have completed the requirements of this  test.</p> </p><H3>Description</H3><p>The Evidence Creator and PACS test their interfaces for  these actions:</p><ul>     <ul>      <li>Storage of Evidence Documents</li>      <li>Storage Commitment </li>     </ul> </ul><H3>Evaluation</H3><p>Connectathon Monitor will ask the Image Manager to show  evidence that:</p><ul>     <li>All evidence objects were successfully stored</li>     <li>Storage Commitment was successful  (N-EVENT-REPORT) was sent to the Evidence Creator.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (148, 1, 0, '2009-11-24 10:53:16.424', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p> </p><H3>Description</H3><p>This is a test to ensure that the Image Display can render evidence documents created by an Evidence Creator actor. You will likely use an Image Manager as a go between to transmit the data, but the Image Manager is not part of the test.</p><H3>Evaluation</H3><p>Connectathon Monitor will ask the Image Display to render the documents from the Evidence Creator. The Monitor will ask that Evidence Creator actor representative to be present to provide advice to the authenticity of the rendering. In general, we are looking for the EC representative to say: &ldquo;Yes, that is my document and that is a reasonable rendering for the end user.&rdquo;</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (149, 1, 0, '2009-11-24 10:53:16.425', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test is run by Modalities who can send DICOM evidence objects as well as images.</p> </p><H3>Description</H3><p>The Modality and PACS test their interfaces for these  actions:</p><ul>     <ul>      <li>Storage of Evidence Documents </li>      <li>Storage Commitment </li>     </ul> </ul><H3>Evaluation</H3><p>Connectathon Monitor will ask the Image Manager to show evidence that:</p><ul>     <li>All evidence objects were successfully stored</li>     <li>Storage Commitment was successful (N-EVENT-REPORT) was sent to the Evidence Creator.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (150, 1, 0, '2009-11-24 10:53:16.427', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Only Modalities capable of creating Evidence Documents run this test.</p> </p><H3>Description</H3><p>This is a test to ensure that the Image Display can render evidence documents created by an    Modality actor. You will likely use an Image Manager as a go between to transmit the    data, but the Image Manager is not part of the test.</p><H3>Evaluation</H3><p>Connectathon Monitor will ask the Image Display to render the documents from the Modality. The Monitor will ask that Modality actor representative to be present to provide    advice to the authenticity of the rendering. In general, we are looking for the Modality representative    to say: &ldquo;Yes, that is my document and that is a reasonable rendering for the end user.&rdquo;</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (151, 1, 0, '2009-11-24 10:53:16.43', 'epoiseau', '<H3>Special Instructions</H3><p>None</p><H3>Description</H3> <p>The ECG_Adv_Display test is used by the Display Actor to retrieve multiple reports for display from an Information Source. The Project Manager will observe the Display actor requesting each of the various types listed in the IHE Cardiology Technical Framework for this Integration Profile. The test will use one or more patients known to the Information Source, possibly those loaded during ECG_LoadInformationSource.</p>  <p>If the Information Source supports other Summary Request types, the RID test cases should be executed as well.</p>  <p>This test case tests the CARD-5 and CARD-6 Transactions.</p>  <p>For evaluation, the Project Manager will observe the query and result for multiple reports. Verify visually that the ECG page looks reasonable and contains the following information:</p>  <p>Patient Name, Patient ID, local date and time of  ECG recording,  voltage and timescale, lead labels, and frequency information, interpretation information and measurements . The ECG report must state either whether the interpretation is CONFIRMED or UNCONFIRMED, but the exact term to use is not mandated by the profile.</p> <H3>Evaluation</H3> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (152, 1, 0, '2009-11-24 10:53:16.432', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p> <H3>Description</H3> <p>The ECG_LoadInformationSource 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>Your peers will use the <a href=system_con_object.php target=OBJECT>Objects Information</a> section of Kudu to find out about your data. So please do not forget to fill information about your data in there</p>  <p>The suggested patient list is: </ul>  <li>Peter Peterson u2013 234561</li>  <li>Tommy Thompson u2013 234562</li>  <li>Johnny Johnson - 234563</li> </li> </p>  <H3>Evaluation</H3> <p>There is no formal evaluation required of the data that you have loaded into your system. Show the Project Manager you have completed this test when your system is properly loaded and show him/her that you correctly filled out the necessary information in the <a href=system_con_object.php target=OBJECT>Objects Information</a> section of the kudu webtool, . You may find that you have to load new data later; do not report updated information.</p>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (153, 1, 0, '2009-11-24 10:53:16.434', 'epoiseau', '<H3>Special Instructions</H3> <p>None</p> <H3>Description</H3> <p>The ECG_Retrieve test is used by the Display Actor to retrieve various types of reports from an Information Source. The Project Manager will observe the Display actor requesting each of the various types listed in the IHE Cardiology Technical Framework for this Integration Profile. The test will use one or more patients known to the Information Source, possibly those loaded during ECG_LoadInformationSource.</p>  <p>If the Information Source supports other Summary Request types, the RID test cases should be executed as well. This test case tests the CARD-6 Transaction.</p>  <H3>Evaluation</H3> <p>For evaluation, the Project Manager will observe the query and result for each summary type. Verify visually that the ECG page looks reasonable and contains the following information:</p>  <p>Patient Name, Patient ID, local date and time of  ECG recording,  voltage and timescale, lead labels, and frequency information, interpretation information and measurements .  The ECG must state either CONFIRMED or UNCONFIRMED.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (154, 1, 0, '2009-11-24 10:53:16.436', 'epoiseau', '<H3>Special Instructions</H3> <p>None</p> <H3>Description</H3> <p>The ECG_SummaryRequest_HTML test is used by the Display Actor to request summary reports from an Information Source. The Project Manager will observe the Display actor requesting each of the Summary Request types listed in the IHE Cardiology Technical Framework for this Integration Profile. The test will use one or more patients known to the Information Source, possibly those loaded during ECG_LoadInformationSource.</p>  <p>If the Information Source supports other Summary Request types, the RID test cases should be executed as well.</p>  <H3>Evaluation</H3>  <p>For evaluation, the Project Manager will observe the query and result for each summary type. Verify list of ECGs is returned via HTML page.  Verify visually that the ECG page looks reasonable and contains the following information:</p>  <p>Patient Name, Patient ID, local date and time of  ECG recording,  voltage and timescale, lead labels, and frequency information, interpretation information and measurements .  The ECG report must state either whether the interpretation is CONFIRMED or UNCONFIRMED, but the exact term to use is not mandated by the profile.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (155, 1, 0, '2009-11-24 10:53:16.439', 'epoiseau', '<H3>Special Instructions</H3> <p>None</p> <H3>Description</H3> <p>The ECG_SummaryRequest_XML test is used by the Display Actor to request summary reports from an Information Source. The Project Manager will observe the Display actor requesting each of the Summary Request types listed in the IHE Cardiology Technical Framework for this Integration Profile. The test will use one or more patients known to the Information Source, possibly those loaded during ECG_LoadInformationSource.</p>  <p>If the Information Source supports other Summary Request types, the RID test cases should be executed as well. This test case tests the CARD-5 Transaction- XML list responses.</p>  <H3>Evaluation</H3> <p>For evaluation, the Project Manager will observe the query and result for each summary type. Verify list of ECGs is returned via XML list.  Verify visually that the ECG page looks reasonable and contains the following information:</p>  <p>Patient Name, Patient ID, local date and time of  ECG recording,  voltage and timescale, lead labels, and frequency information, interpretation information and measurements .  The ECG report must state either whether the interpretation is CONFIRMED or UNCONFIRMED, but the exact term to use is not mandated by the profile.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (156, 1, 0, '2009-11-24 10:53:16.44', 'epoiseau', '<H3>Special Instructions</H3><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 echo 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 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>If the Image Display supports the STRESS ECHO option, verify:   <ul>      <li>Each waveform is labeled with the lead name.</li>      <li>The following values must be displayed:       <ul> 	     <li>Protocol Name: either the value of (0018,1030), or the value of Code Meaning from the Performed Protocol Code Sequence (0040,0260)</li>          <li>Number of Stages</li>          <li>Number of Views in Stage</li>          <li>Code Meaning from the Stage Code Sequence (0040,0102)</li>          <li>Code Meaning from the View Code Sequence (0054,0220)</li>          <li>Stage Number (0008,2122), numbering starting with 1</li>          <li>View Number (0008,2128), numbering starting with 1</li>        </ul> 	 </li> </ul> </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>  </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (157, 1, 0, '2009-11-24 10:53:16.443', 'epoiseau', '<H3>Special Instructions</H3> You may combine this test with test ECHO_MOD_STRESS_OPT to reduce the number of tests which must be run. <H3>Description</H3> This test verifies the ability of the Image Display actor to display a ECHO STRESS image sets from Modality various vendors (CARD-TF-2: 4.2.3). <H3>Evaluation</H3> <p>On the <strong>Image Display</strong> actor: </p> <ul> <li> Either display every image loop of each study and verify the image encoding and patient demographics are accurate or manually edit the image headers to verify.  Verify that Stress Echo images can be properly identified and arranged for viewing. </ul> <p>On the <strong>Modality</strong> or other storage device (if you also ran ECHO_MOD_STRESS_OPT), manually view the image headers.  All elements listed below are required by the Stress Echo option: </p> <ul> <li>(0008,2122) Stage Number '' stage numbering starting with 1  <li>(0008,2128) View Number '' view numbering starting with 1 <li>(0040,000A) Stage Code Sequence '' contains only values from CARD-TF-2: 4.2-4 <ul>  <li>         P5-01201 Image acquisition at baseline <li>         P5-01202 Pre-stress image acquisition  <li>         P5-01203 Mid-stress image acquisition <li>         P5-01204 Peak-stress image acquisition <li>         P5-01205 Image acquisition during recovery </ul> <li>(0054, 0220) View Code Sequence '' contains only values from CARD-TF-2: 4.2-5 <ul> <li>         G-A19B Apical two chamber <li>         G-A19C Apical four chamber <li>         G-0395 Apical long axis <li>         G-0396 Parasternal long axis <li>         G-0397 Parasternal short axis <li>         G-0398 Parasternal short axis at the aortic valve level <li>         G-0399 Parasternal short axis at the level of the mitral chords <li>         G-039A Parasternal short axis at the Mitral Valve level <li>         G-039B Parasternal short axis at the Papillary Muscle level <li>         G-039C Right Ventricular Inflow Tract View <li>         G-039D Right Ventricular Outflow Tract View <li>         G-039E Subcostal long axis <li>         G-039F Subcostal short axis <li>         G-03A0 Suprasternal long axis  <li>        G-03A1 Suprasternal short axis </ul> <li>OPTIONAL: (0008,2120) Stage Name and View Name (0008,2127) may also be included. </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (158, 1, 0, '2009-11-24 10:53:16.446', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p> </p><H3>Description</H3><p>The ECHO_EvidenceCreator_PACS_Display test exercises the <strong><u>Echo Workflow Profile </u></strong>transactions  between an Evidence Creator, an Image Manager/Image Archive and an Image  Display. In the Echo Workflow Integration profile, the Evidence Creator must  perform a Performed Procedure Step and then   produce these documents (SR reports, not images) and store them on the  Image Manager. These documents must also be committed using the Storage  Commitment transaction.  These are a  superset of the transactions in the Evidence Documents profile, which requires  CARD-2 (storage) and CARD-3 (storage commit) only.  </p><p>    The Image Display must be able to render and display all  Templates for the SOP Classes which they accept.</p><p>    An Evidence Creator must produce documents from the  following list and an Image Manager must be able to store those documents:</p><ul>     <li>Enhanced SR</li>     <li>Comprehensive SR</li> </ul><p>The Echo Option Templates include:</p><ul>     <li>5100 Vascular Ultrasound</li>     <li>5200 Echocardiography</li> </ul><p>All supported SOP Classes and all supported Templates  within those SOP Classes must be tested and verified.   </p><p>    To aide in evaluation, it is in your best interest to  begin with an image or Modality Worklist where most of the information listed  below is known to be present, otherwise you will spend a significant amount of  time justifying the absence of the information.</p><H3>Evaluation</H3><p>On the <strong>Image Manager:</strong> </p><p>The Connectathon Monitor should observe evidence from the Image Manager that these documents     were stored. This can be a display on the Image Manager, a 3rd party display or logs or database     on the Image Manager if no display is readily available. At the Image Manager, all of the     following attributes of the Structured Report object from the Modality shall be verified to match     the original image or MWL information: (see Rad TF-2: Appendix A, Table A.2-1 and section A.3):</p><ul>      <li>Study Instance UID (0020, 000D)</li>      <li>Referenced Request Sequence (0040, A370) <ul>       <li>>Study Instance UID (0020, 000D)</li>       <li>>Referenced Study Sequence (0008, 1110)</li>       <li>>Accession Number (0008, 0050)</li>       <li>>Requested Procedure ID (0040, 1001)</li>       <li>>Requested Procedure Description (0032, 1060)</li>       <li>>Requested Procedure Code Sequence (0032, 1064)</li>      </ul>      </li>      <li>Performed Procedure Code Sequence (0040, A372)</li>      <li>Referenced Study Component Sequence<ul>       <li> >Referenced SOP Class UID (0008, 1150)</li>       <li> >Referenced SOP Instance UID (0008, 1155)</li>      </ul>      </li>      <li>Patient Name (0010, 0010)</li>      <li>Patient ID (0010, 0020)</li>      <li>Patient’s Birth Date (0010, 0030)</li>      <li>Patient’s Sex (0010, 0040)</li>      <li>Referring Physicians Name (0008, 0090)</li>      <li>Completion Flag (0040,A491)</li>     </ul><p>The Connectathon Monitor should also observe logs in the Image Manager that demonstrate the     Storage Commitment transaction. All of the following attributes shall be verified in the Storage     Commit message from the Modality:</p><ul>      <li>Referenced SOP Sequence (0008, 1199)<ul>       <li> >Reference SOP Class (0008, 1150)</li>       <li>>Referenced SOP Instance UID (0008, 1155)</li>      </ul>      </li>     </ul><p>At the <strong>Image Display:</strong> The Connectathon monitor should observe the Image     Display and its ability to interpret/render the Evidence Documents. The Connectathon monitor     should observe the original report at the Image Manger, the Acqusition Modality, the Evidence     Creator, or another Image Display and spot check the Image Display/Report creator to verify the     contents of the Structured Report are displayed correctly and completely.      </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (159, 1, 0, '2009-11-24 10:53:16.451', 'epoiseau', '<H3>Special Instructions</H3> The Image Manager/Archive must receive images from Modalities registered in the ECHO profile 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> <p>On the <strong>Image Display</strong> </p> <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.<br>       <br>     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: <br>     <strong>STUDY LEVEL</strong> Query Keys:</li>   <ul>     <ul>       <li>Study Date  (0008,0020)</li>       <li>Study Time  (0008,0030)</li>       <li>Accession Number  (0008,0050) </li>       <li>Patient Name  (0010,0010)</li>       <li>Study ID (0020,0010) </li>       <li>Study Instance UID  (0020,000D)</li>       <li>Modalities in Study  (0008,0061)</li>       <li>Referring  Physician''s Name (0008,0090)</li>     </ul>   </ul> </ul> <p><strong>SERIES LEVEL</strong> Query Keys:</p> <ul>   <ul>     <ul>       <li>Modality (0008,0020)</li>       <li>Series Number  (0020,0011) </li>       <li>Series Instance UID  (0020,000E)</li>       <li>Requested Procedure  ID (0040,1001) </li>       <li>Scheduled Procedure  Step ID (0040,0009)  </li>       <li>PPS Start Date  (0040,0244) </li>       <li>PPS Start Time  (0040,0245)</li>     </ul>   </ul> </ul> <p><strong>IMAGE LEVEL</strong> Query Keys:</p> <ul>   <ul>     <ul>       <li>Instance Number  (0020,0013) </li>       <li>SOP Instance UID  (0008,0016)</li>     </ul>   </ul> </ul> <ul>   <li>Verify the ability  to retrieve by study, by series and by image.</li>   <li>Verify that studies  are fully retrieved.  (Correct rendering  of the images is verified in a different test -- ECHO_DISPLAY).</li> </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (160, 1, 0, '2009-11-24 10:53:16.453', 'epoiseau', '<H3>Special Instructions</H3> <b><i> This test should be run on the 1st 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 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 ECHO 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). The ECHOCARDIOGRAPHY option is required; Image Managers must support all of the following SOP classes (CARD TF-2:4.2.2):  <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> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (161, 1, 0, '2009-11-24 10:53:16.455', '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!   If your modality supports the "Stress Echo" option, you should submit at least one sample study of this type.</p> </p> <H3>Description</H3> <p>All Acquisition Modalities and Evidence Creators participating in the Cardiology profiles must 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 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><p>Acquisition Modalities in the ECHO profile must support the ECHOCARDIOGRAPHY option, requiring them to support multi-frame image storage.</p><p>If the <b>STRESS ECHO option</b> is supported, View and Stage information must be encoded according to the requirements in CARD TF-2:4.2.3.</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>If the Modality  supports <strong>STRESS ECHO</strong> option, the Connectathon  Monitor will access a sample study for the Modality on the CENTRAL_ARCHIVE.   View the DICOM header and  verify:</p> <ul> <li>The following  attributes are required to have valid values:   </li> </ul><div align="center"> <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> </div><p> <em>Notes:1.  Extra-protocol images (i.e., images not associated with the stress echo  exam protocol) shall have the View Number empty or omitted.</em> <br>      <em>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.</em> </p> <ul> <li>Performed Protocol  Code Sequence (0040,0260) contain codes taken from:<br> </li> </ul><div align="center"> <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">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> </div><ul> <li>Stage Code Sequence  (0040,000A) contains codes taken from:<br>        <br> </li> </ul><div align="center"> <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">P5-01201</p> </td>       <td width="306" valign="top"> <p>Image acquisition at baseline</p> </td>      </tr>      <tr>        <td width="122" valign="top"> <p align="center">SRT</p> </td>       <td width="122" valign="top"> <p align="center">P5-01202</p> </td>       <td width="306" valign="top"> <p>Pre-stress image acquisition</p> </td>      </tr>      <tr>        <td width="122" valign="top"> <p align="center">SRT</p> </td>       <td width="122" valign="top"> <p align="center">P5-01203</p> </td>       <td width="306" valign="top"> <p>Mid-stress image acquisition</p> </td>      </tr>      <tr>        <td width="122" valign="top"> <p align="center">SRT</p> </td>       <td width="122" valign="top"> <p align="center">P5-01204</p> </td>       <td width="306" valign="top"> <p>Peak-stress image acquisition</p> </td>      </tr>      <tr>        <td width="122" valign="top"> <p align="center">SRT</p> </td>       <td width="122" valign="top"> <p align="center">P5-01205</p> </td>       <td width="306" valign="top"> <p>Image acquisition during recovery</p> </td>      </tr> </table> </div><ul> <li>View Code Sequence  (0054,0220) contains codes taken from:<br>        <br> </li> </ul><div align="center"> <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<br>        </p> </td>       <td width="337" valign="top"> <p>Code Meaning <br>        </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> </div>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (162, 1, 0, '2009-11-24 10:53:16.459', 'epoiseau', '<H3>Special Instructions</H3> You may combine this test with test ECHO_DISPLAY_STRESS_OPT to reduce the number of tests which must be run. <p> The Modality system should arrive at the Connectathon with these images PRE-OBTAINED and PRE-LOADED or you will waste a great deal of time! </p> <p> Ideally, you would run this test with an Image Manager or other storage device (MESA test tool) capable of displaying the DICOM image header.   When you run the test with an Image Display, you are testing the interoperablility with that actor. </p> <H3>Description</H3> This test verifies that Echo Modality actors properly encode ECHO STRESS image sets with the required STRESS ECHO DATA ELEMENTS.   (CARD-TF-2: 4.2.3).    <H3>Evaluation</H3> On the <strong>Image Manager</strong> or other device capable of displaying the image headers, verify the elements listed below are required by the Stress Echo option: <ul> <li>(0008,2122) Stage Number '' stage numbering starting with 1  <li>(0008,2128) View Number '' view numbering starting with 1 <li>(0040,000A) Stage Code Sequence '' contains only values from CARD-TF-2: 4.2-4 <ul>  <li>         P5-01201 Image acquisition at baseline <li>         P5-01202 Pre-stress image acquisition  <li>         P5-01203 Mid-stress image acquisition <li>         P5-01204 Peak-stress image acquisition <li>         P5-01205 Image acquisition during recovery </ul> <li>(0054,0220) View Code Sequence '' contains only values from CARD-TF-2: 4.2-5 <ul> <li>         G-A19B Apical two chamber <li>         G-A19C Apical four chamber <li>         G-0395 Apical long axis <li>         G-0396 Parasternal long axis <li>         G-0397 Parasternal short axis <li>         G-0398 Parasternal short axis at the aortic valve level <li>         G-0399 Parasternal short axis at the level of the mitral chords <li>         G-039A Parasternal short axis at the Mitral Valve level <li>         G-039B Parasternal short axis at the Papillary Muscle level <li>         G-039C Right Ventricular Inflow Tract View <li>         G-039D Right Ventricular Outflow Tract View <li>         G-039E Subcostal long axis <li>         G-039F Subcostal short axis <li>         G-03A0 Suprasternal long axis  <li>        G-03A1 Suprasternal short axis </ul> <li>OPTIONAL: (0008,2120) Stage Name and (0008,2127) View Name may also be included. </ul> <p>On the Image Display actor, (if you also ran test ECHO_DISPLAY_STRESS_OPT) </p> <ul> <li> Either display every image loop of every study and verify the image encoding and patient demographics are accurate or manually edit the image headers to verify.  Verify that Stress Echo images can be properly identified and arranged for viewing. </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (163, 1, 0, '2009-11-24 10:53:16.461', 'epoiseau', '<H3>Special Instructions</H3> This test is equivalent to the Cardiology CATH_Modality_IM_Interface and STRESS_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>Use Case E1 - Patient Registered/Procedure Ordered  <li>Use Case E6 - Stress Echo Staged Protocol (if the Modality supports the "Stress Echo" option) <li>MPPS Abandoned Case <li>Storage of Images <li>Storage Commitment </ul> 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 (164, 1, 0, '2009-11-24 10:53:16.463', '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 E4 - Intermittently Connected Modality with Ad Hoc Procedure, Patient Registered, Unscheduled Procedure (CARD TF-1: 4.3.3; 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  <li>(0008, 1032) Procedure Code Sequence is empty <li>In (0040,0270) - Scheduled Step Attributes Sequence, the following  <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 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 (165, 1, 0, '2009-11-24 10:53:16.466', 'epoiseau', '<H3>Special Instructions</H3> This test is identical to the CATH and Radiology SWF Orders Connectathon Test Cases, but uses Echo orders.  It only needs to be executed within one profile. <p> Use the RIS MALL as an ADT simulator to register patients for this test. </p> <H3>Description</H3>  <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 10110 or 10310 are cancelled. <li>There is an order 10350 for patient SYS_NAME^ECHO-ORDERS2. </ul> <p> On the <strong>DSS/OF</strong> user interface or database, verify that: </p> <ul> <li>There is no order 10110 waiting to be scheduled for patient SYS_NAME^ECHO-ORDERS1. <li>There is a procedure 910350 for patient SYS_NAME^ECHO-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 10350 for patient SYS_NAME^ECHO-ORDERS2 . </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (166, 1, 0, '2009-11-24 10:53:16.467', 'epoiseau', '<H3>Special Instructions</H3> <p> Use the RIS Mall as an ADT and OP simulator to register patients and create orders.  </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 test verifies the ability of the DSS/Order Filler and Acquisition Modality in the full scheduled workflow, specifically ECHO Use Case E1 (CARD-TF-1: 4.3.1).  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 (John Doe) Patient is registered, an Order is created and a Procedure is scheduled and performed.  Finally, the Doe patient is reconciled.  The DSS/OF''s ability to be a PPS manager is also tested.  <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 informed 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 </ul> <H3>Evaluation</H3> On the <strong>DSS/OF</strong>, verify: <ul> <li>A copy of the N-CREATE PPS to the DSS/OF (transaction RAD-6) has been captured, eg in [test-case-no]-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 from the OP and provided in the MWL: <ul> <li>(0040,0001) Requesed Procedure ID </ul> <li>There is no entry for patient Doe^SYS_NAME. </ul> </ul> <p> On the <strong>Image Manager</strong>, find the study for patient Merge^SYS_NAME.  Verify that: <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> <li>The DSS/OF forwarded the N-SET PPS message by viewing the captured message, eg in [test-case-no]-pps-complete.txt. <li>There are no images for patient Doe^SYS_NAME. </ul> </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (167, 1, 0, '2009-11-24 10:53:16.469', 'epoiseau', '<H3>Special Instructions</H3> This test case is used for Full Workflow testing with as complete a complement of actors in the ECHO profile as possible.  If necessary, use the RIS Mall for ADT, OP and/or OF functionality.   <p> <b><i>If a DSS/OF is available, run test ECHO_USE_CASE_E3_E7 instead.</b></i> </p> <p> 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> 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_ECHO. </p> <H3>Description</H3> This test verifies the ability of the actors in the ECHO profile in the full scheduled workflow, specifically ECHO Use Case E1 (CARD-TF-1: 4.3.1). 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.  If an Evidence Creator is participating, Case E7 steps are performed. <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:ECHO_workflow.doc>this document</a> which connectathon monitors will use as they guide the test systems through the workflow.  </p> <H3>Evaluation</H3> <p>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:<br>   On the <strong>DSS/OF</strong>, verify: </p> <ul type="disc">   <li>There is no entry for patient Workflow^SYS_NAME (it was updated       to be with patient Merge^SYS_NAME). </li>   <li>Verify that the PPS is associated with the original Requested       Procedure from the OP and provided in the MWL: </li>   <ul type="circle">     <li>(0040,0001) Requested Procedure ID </li>   </ul> </ul> <p>On the <strong>Image Display</strong> (or Image  Manager if there is no Display), find the study for patient  Merge^SYS_NAME. Verify that: </p> <ul type="disc">   <li>The images objects are successfully received/rendered on the       Display. Check that the following fields match what was provided in the       MWL: </li>   <ul type="circle">     <li>(0008,0050) Accession Number </li>     <li>(0020,000D) Study Instance UID </li>   </ul>   <li>There are no images for patient Doe^SYS_NAME. </li> </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (168, 1, 0, '2009-11-24 10:53:16.472', 'epoiseau', '<H3>Special Instructions</H3> None. <H3>Description</H3> <p> This test verifies Image Managers can queue Storage Commitment N-EVENT-REPORT messages for INTERMITTENTLY CONNECTED MODALITIES, especially Echo (CARD-TF-2:4.3.1).   This test uses ECHO Use Case E2 (CARD-TF-1: 3.2.1).  This is the simplest case where the Patient has been Registered, the Order is created, and the Procedure is scheduled. </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. <li>[CARD-1] Modality notifies PPS Manager of in progress study. <li>[RAD-7] Modality notifies PPS Manager of completed study. </ul> <H3>Evaluation</H3> On the <strong>Image Manager</strong> verify: <ul> <li>The images created at the modality contain the Study Instance UID generated by the DSS/OF. <li>By viewing captured messages in a log file named [test-case-no]-assocneg.txt, that, after the modality was reconnected, association negotation from the modality triggered the IM to initiate a separate association to the modality to send queued N-EVENT-REPORT messages. <li>All SC N-EVENT-REPORT messages have been sent from the IM to the Echo modality. </ul> <p> On the <strong>Modality</strong> verify: </p> <ul> <li>Storage Commitment N-EVENT-REPORT messages (transaction CARD-3) were received at the Modality by viewing the captured message, eg in [test-case-no]-sc.txt. </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (169, 1, 0, '2009-11-24 10:53:16.473', 'epoiseau', '<H3>Special Instructions</H3> This test case is used for Full Workflow testing with as complete a complement of actors in the ECHO profile as possible.  If necessary, use the RIS Mall for ADT and OP functionality.   <p> Because of the use case being tested, RIS Mall should NOT be used for DSS/OF functionality.  If no DSS/OF is available for this test, run ECHO_USE_CASE_E1_E7 instead. </p> 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> 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_ECHO.  </p> <H3>Description</H3> This test verifies the ability of the actors in the ECHO profile in the full scheduled workflow, specifically STRESS Use Case E3 (CARD-TF-1: 4.3.3). A Patient is registered, an Order is created and a Procedure is scheduled, but the Modality is not connected to the network so cannot get Modality Worklist, so patient and procedure information is manually entered at the modality. After the procedure is performed, it connects to the network so that MPPS and C-STORE messages are sent.  The DSS/OF then initiates Patient and Procedure Reconciliation. If an Evidence Creator is participating, Case E7 steps are performed <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:ECHO_workflow.doc>this document</a> which connectathon monitors will use as they guide the test systems through the workflow, </p> <H3>Evaluation</H3> <p>The Connectathon Monitor will  check the results of each transaction as the test is executed.<br> Also:<br> On the <strong>OP</strong>, verify that the status of the original requested procedure is  Complete.<br> On the <strong>DSS/OF</strong>, verify: </p> <ul type="disc">   <ul type="circle">     <li>Its system successfully reconciled the originally scheduled        procedure with what was actually performed on the modality (received via        MPPS).</li>   </ul> </ul> <p>On the <strong>Image Display</strong> (or <strong>Image Manager</strong> if there is no Display), find the study for patient ECHO-Workflow^SYS_NAME.  Verify that: </p> <ul type="disc">   <li>The images objects are successfully received/rendered on the       Display. Check that the following fields match what was entered on the       ADT.'' This confirms that the DSS/OF       successfully notified the IM of the full patient demographics in the       RAD-12 transaction: </li>   <ul type="circle">     <li>(0010,0030) Patient Birth Date </li>   </ul> </ul>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (170, 1, 0, '2009-11-24 10:53:16.476', 'epoiseau', '<H3>Special Instructions</H3> <p> <p>Evidence Creator actors perform ONE instance of this test. <strong>This should be done on the first day of the Connectathon</strong>.</p> <p>The Evidence 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 Evidence Creators participating in Cardiology 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>Evidence Creators 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 (171, 1, 0, '2009-11-24 10:53:16.478', '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> <p>The Composite Package for EDES is a term invented by the PCC Project Manager      to serve as a handle for the requirement that a Content Creator must create      three types of documents. In this package, the Content Creator must create:    <ol>      <li>ED Nursing Note</li>      <li>ED Physician Note</li>      <li>ED Composite Triage Note</li>     </ol> </p> <p>As the Content Consumer processes documents, it shall process all three      kinds of documents produced by the Content Creator. The Content Creator      shall create all three documents, and the Content Consumer shall process      all three documents.   </p> </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 three documents produced by a single Content Creator. The Content Consumer demonstrates which of the 4 processing options are supported for the documments.<br>   When examining the processing of the document, the Connectathon Monitor should evaluate the document with at least these items in mind:</p><ul> <li>Sections in the document are appropriate per the definitions in PCC TF</li> <li>A default style sheet is provided by the Content Creator. The Content Consumer is required to render the document with the  default style sheet. As an option, the Content Consumer can render with a  different style sheet.</li> </ul><H3>Evaluation</H3><p>In the evaluation, the Connectathon Monitor is looking for evidence that the Content Consumer can interpret the documents 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 EDES Integration Profile.<br>   The monitor shall check for these values in the document.  If the Content Consumer supports the view option, this data shall be rendered for display. Other options may not include processing each entry, so evaluation will require some judgment.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (172, 1, 0, '2009-11-24 10:53:16.481', '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>  <p>The Triage Package for EDES is a term invented by the PCC Project Manager      to serve as a handle for the requirement that a Content Creator must create      three types of documents. In this package, the Content Creator must create:    <ol>      <li>ED Triage Note</li>      <li>ED Nursing Note</li>      <li>ED Physician Note</li>     </ol> </p> <p>As the Content Consumer processes documents, it shall process all three      kinds of documents produced by the Content Creator. The Content Creator      shall create all three documents, and the Content Consumer shall process      all three documents.   </p> </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 three documents produced by a single Content Creator. The Content Consumer demonstrates which of the 4 processing options are supported for the documments.<br>   When examining the processing of the document, the Connectathon Monitor should evaluate the document with at least these items in mind:</p><ul> <li>Sections in the document are appropriate per the definitions in PCC TF</li> <li>A default style sheet is provided by the Content Creator. The Content Consumer is required to render the document with the  default style sheet. As an option, the Content Consumer can render with a  different style sheet.</li> </ul><H3>Evaluation</H3><p>In the evaluation, the Connectathon Monitor is looking for evidence that the Content Consumer can interpret the documents 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 EDES Integration Profile.<br>   The monitor shall check for these values in the document.  If the Content Consumer supports the view option, this data shall be rendered for display. Other options may not include processing each entry, so evaluation will require some judgment.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (173, 1, 0, '2009-11-24 10:53:16.483', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> <p>An EDES Composite Package is a term invented by PCC Project Managers. It is a package around the requirement that a Content Creator must produce at leat three documents. The EDES Composite Package is used to list three specific documents:  <ol> <li>Nursing Note</li> <li>ED Physician Note</li> <li>Composite Triage Note</li> </ol> </p> <p>The goal of this test is to create three valid documents (the Composite Pacakge) and publish those documents in a location to make it easy for other participants to locate.</p> </p> <H3>Description</H3><p>Each Content Creator has been assigned one well known patient (see test Content_Creator_Demographics) with a Patient ID in the proper domain. Create the three EDES documents adn use the demographics for this patient and patient ID (if possible).</p><p>For any of the coded values (allergies, medications, etc.)  use only coded values found in the MESA/Connectathon Code Tables document. That  document should list between 3 and 5 legal coded values. Do not invent codes or  import other codes. If you find that document lacking, inform the Connectathon  monitor about appropriate coded values for inclusion.</p><ol> <li>These next steps refer to storing the document and reference information in the Kudu tool. You will find the page in the Kudu tool by selecting Connectathon and then Connectathon Images/CDs/Objects. The link to that page is <em><a href=system_con_object.php>Objects Information</a></em> </li>  <li>Enter the Patient ID,  Patient Name, company name, your name, and your Kudu system name into the description of the <em>Connectathon Images/CDAs/Objects</em>.</li> <li>Create a screen capture of a rendering of the separate objects. We recognize that not all renderings will be the same.</li> <li>Name the documents EDES_Composite_kudu.xml, EDES_Nursing_kudu.xml and EDES_Physician_kudu where <strong><em>kudu</em></strong> is your Kudu system name.</li> <li>Upload information, snapshot and xml files in the <em>Connectathon Images/CDAs/Objects</em> section of Kudu.</li> <li> Upload your documents according to the instructions on that  page. Update the <em> Connectathon Images/CDAs/Objects Publication/rendering page</em> page to list your document/zip file.</li> <li>Find the Connectathon monitor or monitors responsible for Document Scrutiny. Make sure they are aware your document has been placed into the Kudu tool.</li> <li>If you support XDS, complete XDS test that requires you to store and register your document with a repository/registry. You do not need to complete that XDS store step in order to complete this test. In fact, once you have uploaded the proper documentation into Kudu, mark this test complete.</li> </ol><p>These items describe the minimum content that must be  present in the Composite Triage and Nursing Note document. Additional content is acceptable, but the  document must contain the following information:</p><p>The content of various modules is defined at http://ihewiki.wustl.edu/wiki/index.php/PCC_Connectathon_Content_Test_Requirements. Use the wiki page to find the right content and incorporate into your document.</p><p>As defined in the PCC TF, you must include the following content modules. Optional modules are allowed.         The list of modules that are required and should be examined for the EDES Nursing Note are: <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td> Vital Signs</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2</td></tr>  <tr><td> Assessments</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.4</td></tr>  <tr><td> Procedures and Interventions</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.11</td></tr>  <tr><td> Medications Administered</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.21</td></tr>  <tr><td> Intravenous Fluids Administered</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.6</td></tr>  <tr><td> ED Disposition</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.10</td></tr> </table>         The list of modules that are required and should be examined for the EDES Physician Note are: <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td>Referral Source</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.3</td></tr>  <tr><td>Mode of Arrival</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.10.3.2</td></tr>  <tr><td>Chief Complaint</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1</td></tr>  <tr><td>Reason for Visit</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1.1</td></tr>  <tr><td> History of Present Illness</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.4</td></tr>  <tr><td> Advanced Directives</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.34</td></tr>  <tr><td> Current Medications</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.19</td></tr>  <tr><td> Allergies</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.13</td></tr>  <tr><td> List of Surgeries</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.11</td></tr>  <tr><td> Immunizations</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.23</td></tr>  <tr><td> Family History</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.14</td></tr>  <tr><td> Social History</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.16</td></tr>  <tr><td>Vital Signs</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2</td></tr>  <tr><td>Physical Examination</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.9.15</td></tr>  <tr><td>Procedures Performed</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.11</td></tr>  <tr><td>Test Results Lab, ECG, Radiology</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.27</td></tr>  <tr><td>Consultations</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.8</td></tr>  <tr><td>Progress Note</td><td>1.3.6.1.4.1.19376.1.5.3.1.1.13.2.7</td></tr>  <tr><td>ED Diagnoses,</td><td>1.3.6.1.4.1.19376.1.5.3.1.1.13.2.9</td></tr>  <tr><td>ED Disposition</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.10</td></tr> </table>         The list of modules that are required and should be examined for the ED Composite Triage and Nursing Note are: <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td> Chief Complaint</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1</td></tr>  <tr><td> Reason for Visit</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1.1</td></tr>  <tr><td> Mode of Arrival</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.10.3.2</td></tr>  <tr><td> History of Present Illness</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.4</td></tr>  <tr><td> Current Medications</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.19</td></tr>  <tr><td> Allergies</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.13</td></tr>  <tr><td> Acuity Assessment</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.2</td></tr>  <tr><td> Vital Signs</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2</td></tr>  <tr><td> Procedures and Interventions</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.11</td></tr>  <tr><td> ED Disposition</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.10</td></tr> </table> </p> <H3>Evaluation</H3> <p>This will be evaluated with the EDES_Scrutiny_Composite_Package and EDES_Process_Composite_Package tests.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (174, 1, 0, '2009-11-24 10:53:16.486', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> <p>An EDES Triage Package is a term invented by PCC Project Managers. It is a package around the requirement that a Content Creator must produce at leat three documents. The EDES Triage Package is used to list three specific documents:  <ol> <li>Triage Note</li> <li>Nursing Note</li> <li>ED Physician Note</li> </ol> </p> <p>The goal of this test is to create three valid documents (the Triage Pacakge) and publish those documents in a location to make it easy for other participants to locate.</p> </p><H3>Description</H3><p>Each Content Creator has been assigned one well known patient (see test Content_Creator_Demographics) with a Patient ID in the proper domain. Create the three EDES documents adn use the demographics for this patient and patient ID (if possible).</p><p>For any of the coded values (allergies, medications, etc.)  use only coded values found in the MESA/Connectathon Code Tables document. That  document should list between 3 and 5 legal coded values. Do not invent codes or  import other codes. If you find that document lacking, inform the Connectathon  monitor about appropriate coded values for inclusion.</p><ol> <li>These next steps refer to storing the document and reference information in the Kudu tool. You will find the page in the Kudu tool by selecting Connectathon and then Connectathon Images/CDs/Objects. The link to that page is <em><a href=system_con_object.php>Objects Information</a></em> </li>  <li>Enter the Patient ID,  Patient Name, company name, your name, and your Kudu system name into the description of the <em>Connectathon Images/CDAs/Objects</em>.</li> <li>Create a screen capture of a rendering of the separate objects. We recognize that not all renderings will be the same.</li> <li>Name the documents EDES_Triage_kudu.xml, EDES_Nursing_kudu.xml and EDES_Physician_kudu where <strong><em>kudu</em></strong> is your Kudu system name.</li> <li>Upload information, snapshot and xml files in the <em>Connectathon Images/CDAs/Objects</em> section of Kudu.</li> <li> Upload your documents according to the instructions on that  page. Update the <em> Connectathon Images/CDAs/Objects Publication/rendering page</em> page to list your document/zip file.</li> <li>Find the Connectathon monitor or monitors responsible for Document Scrutiny. Make sure they are aware your document has been placed into the Kudu tool.</li> <li>If you support XDS, complete XDS test that requires you to store and register your document with a repository/registry. You do not need to complete that XDS store step in order to complete this test. In fact, once you have uploaded the proper documentation into Kudu, mark this test complete.</li> </ol><p>These items describe the minimum content that must be  present in the Triage Note document. Additional content is acceptable, but the  document must contain the following information:</p><p>The content of various modules is defined at http://ihewiki.wustl.edu/wiki/index.php/PCC_Connectathon_Content_Test_Requirements. Use the wiki page to find the right content and incorporate into your document.</p><p>As defined in the PCC TF, you must include the following content modules. Optional modules are allowed.         The list of modules that are required and should be examined for the Triage Note are: <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td> Chief Complaint</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1</td></tr>  <tr><td> Reason for Visit</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1.1</td></tr>  <tr><td> Mode of Arrival</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.10.3.2</td></tr>  <tr><td> History of Present Illness</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.4</td></tr>  <tr><td> Current Medications</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.19</td></tr>  <tr><td> Allergies</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.13</td></tr>  <tr><td> Acuity Assessment</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.2</td></tr>  <tr><td> Vital Signs</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2</td></tr> </table>          The list of modules that are required and should be examined for the EDES Nursing Note are: <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td> Vital Signs</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2</td></tr>  <tr><td> Assessments</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.4</td></tr>  <tr><td> Procedures and Interventions</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.11</td></tr>  <tr><td> Medications Administered</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.21</td></tr>  <tr><td> Intravenous Fluids Administered</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.6</td></tr>  <tr><td> ED Disposition</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.10</td></tr> </table>          The list of modules that are required and should be examined for the EDES Physician Note are: <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td>Referral Source</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.3</td></tr>  <tr><td>Mode of Arrival</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.10.3.2</td></tr>  <tr><td>Chief Complaint</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1</td></tr>  <tr><td>Reason for Visit</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1.1</td></tr>  <tr><td> History of Present Illness</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.4</td></tr>  <tr><td> Advanced Directives</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.34</td></tr>  <tr><td> Current Medications</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.19</td></tr>  <tr><td> Allergies</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.13</td></tr>  <tr><td> List of Surgeries</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.11</td></tr>  <tr><td> Immunizations</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.23</td></tr>  <tr><td> Family History</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.14</td></tr>  <tr><td> Social History</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.16</td></tr>  <tr><td>Vital Signs</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2</td></tr>  <tr><td>Physical Examination</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.9.15</td></tr>  <tr><td>Procedures Performed</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.11</td></tr>  <tr><td>Test Results Lab, ECG, Radiology</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.27</td></tr>  <tr><td>Consultations</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.8</td></tr>  <tr><td>Progress Note</td><td>1.3.6.1.4.1.19376.1.5.3.1.1.13.2.7</td></tr>  <tr><td>ED Diagnoses,</td><td>1.3.6.1.4.1.19376.1.5.3.1.1.13.2.9</td></tr>  <tr><td>ED Disposition</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.10</td></tr> </table> </p> <H3>Evaluation</H3> <p>This will be evaluated with the EDES_Scrutiny_Triage_Package and EDES_Process_Triage_Package tests.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (175, 1, 0, '2009-11-24 10:53:16.489', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> <p>The monitor in charge of PCC documents will scrutinize your CDA content. He/she might not finish that work on Day 1. You need to publish the document and mark this test done to trigger the monitor to review your document.</p> <p> <em>You need to be able to produce legal content at the start of the event.</em> </p> <p>As part of the Composite Package, you need to produce three different    documents: ED Nursing Note, ED Physician Note, ED Composite Triage Note </p> </p><H3>Description</H3><p>One Connectathon Monitor will be assigned to scrutinize EDES documents.      The purpose of this test is to have a single person with domain knowledge examine one      example of each document.      The Connectathon Monitor is looking for proper document structure, proper use of coded values      and content that was specified in the Publish test.</p> <p>The Content Creator should use the same documents produced and stored in the Kudu tool in the EDES_Publish_Composite_Package test.</p><p>The Connectathon Monitor will take the files offline and perform evaluation.      The monitor will document any deficiencies and ask the Content Creator to correct      during the Connectathon.</p> <H3>Evaluation</H3> <p>Monitors please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) the Content Creators have submitted. </p> <p>The NIST Evaluation tools are found at <a href="http://xreg2.nist.gov/cda-validation/index.html">      http://xreg2.nist.gov/cda-validation/index.html</a>.      For documents not supported by the NIST tool, use the schematron file found at IHESCHEMATRON.   </p><p>In the evaluation, the Connectathon Monitor will follow these steps:    <ol>      <li>Verify that creator has supplied three documents:      <ul>        <li>ED Nursing Note</li>        <li>ED Physician Note</li>        <li>ED Commposite Triage and Nursing Note</li>       </ul>      </li>      <li>Use CDA validation tool to make sure document is legal CDA document</li>      <li>Use Schematron test tool to see that document passes schematron tests for EDES</li> <li>NB: In the modules listed in the next item, we are only examining modules with optionality of type R.   We are ignoring modules with optionality O or R2.</li> <li>Examine EDES documents by hand (possibly with style sheet) and examine for EDES specific content         in these sections.         Values are found on the         <a href="http://ihewiki.wustl.edu/wiki/index.php/PCC_Connectathon_Content_Test_Requirements">Connectathon wiki: PCC Content Test Requirements</a>          The list of modules that are required and should be examined for the EDES Nursing Note are: <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td> Vital Signs</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2</td></tr>  <tr><td> Assessments</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.4</td></tr>  <tr><td> Procedures and Interventions</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.11</td></tr>  <tr><td> Medications Administered</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.21</td></tr>  <tr><td> Intravenous Fluids Administered</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.6</td></tr>  <tr><td> ED Disposition</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.10</td></tr> </table>         The list of modules that are required and should be examined for the EDES Physician Note are: <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td>Referral Source</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.3</td></tr>  <tr><td>Mode of Arrival</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.10.3.2</td></tr>  <tr><td>Chief Complaint</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1</td></tr>  <tr><td>Reason for Visit</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1.1</td></tr>  <tr><td> History of Present Illness</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.4</td></tr>  <tr><td> Advanced Directives</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.34</td></tr>  <tr><td> Current Medications</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.19</td></tr>  <tr><td> Allergies</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.13</td></tr>  <tr><td> List of Surgeries</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.11</td></tr>  <tr><td> Immunizations</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.23</td></tr>  <tr><td> Family History</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.14</td></tr>  <tr><td> Social History</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.16</td></tr>  <tr><td>Vital Signs</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2</td></tr>  <tr><td>Physical Examination</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.9.15</td></tr>  <tr><td>Procedures Performed</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.11</td></tr>  <tr><td>Test Results Lab, ECG, Radiology</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.27</td></tr>  <tr><td>Consultations</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.8</td></tr>  <tr><td>Progress Note</td><td>1.3.6.1.4.1.19376.1.5.3.1.1.13.2.7</td></tr>  <tr><td>ED Diagnoses,</td><td>1.3.6.1.4.1.19376.1.5.3.1.1.13.2.9</td></tr>  <tr><td>ED Disposition</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.10</td></tr> </table>         The list of modules that are required and should be examined for the ED Composite Triage and Nursing Note are: <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td> Chief Complaint</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1</td></tr>  <tr><td> Reason for Visit</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1.1</td></tr>  <tr><td> Mode of Arrival</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.10.3.2</td></tr>  <tr><td> History of Present Illness</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.4</td></tr>  <tr><td> Current Medications</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.19</td></tr>  <tr><td> Allergies</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.13</td></tr>  <tr><td> Acuity Assessment</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.2</td></tr>  <tr><td> Vital Signs</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2</td></tr>  <tr><td> Procedures and Interventions</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.11</td></tr>  <tr><td> ED Disposition</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.10</td></tr> </table>      </li>     </ol> </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (176, 1, 0, '2009-11-24 10:53:16.491', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> <p>The monitor in charge of PCC documents will scrutinize your CDA content. He/she might not finish that work on Day 1. You need to publish the document and mark this test done to trigger the monitor to review your document.</p> <p> <em>You need to be able to produce legal content at the start of the event.</em> </p> <p>As part of the Triage Package, you need to produce three different    documents: ED Triage Note, ED Nursing Note, ED Physician Note </p> </p> <H3>Description</H3> <p>One Connectathon Monitor will be assigned to scrutinize EDES documents.      The purpose of this test is to have a single person with domain knowledge examine one      example of each document.      The Connectathon Monitor is looking for proper document structure, proper use of coded values      and content that was specified in the Publish test.</p><p>The Content Creator should use the same documents produced and stored in the Kudu tool in the EDES_Publish_Triage_Package test.</p><p>The Connectathon Monitor will take the files offline and perform evaluation.      The monitor will document any deficiencies and ask the Content Creator to correct      during the Connectathon.</p> <H3>Evaluation</H3> <p>Monitors please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) the Content Creators have submitted. </p> <p>The NIST Evaluation tools are found at http://xreg2.nist.gov/cda-validation/index.html.      For documents not supported by the NIST tool, use the schematron file found at IHESCHEMATRON.   </p><p>In the evaluation, the Connectathon Monitor will follow these steps:    <ol>      <li>Verify that creator has supplied three documents:      <ul>        <li>ED Triage Note</li>        <li>ED Nursing Note</li>        <li>ED Physician Note</li>       </ul>      </li>      <li>Use CDA validation tool to make sure document is legal CDA document</li>      <li>Use Schematron test tool to see that document passes schematron tests for EDES</li> <li>In the next step, we only test modules of optionality R. We ignore modules with optionality O or R2.</li> <li>Examine EDES documents by hand (possibly with style sheet) and examine for EDES specific content         in these sections.         Values are found on the         <a href="http://ihewiki.wustl.edu/wiki/index.php/PCC_Connectathon_Content_Test_Requirements">Connectathon wiki: PCC Content Test Requirements</a>         The list of modules that are required and should be examined for the Triage Note are: <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td> Chief Complaint</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1</td></tr>  <tr><td> Reason for Visit</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1.1</td></tr>  <tr><td> Mode of Arrival</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.10.3.2</td></tr>  <tr><td> History of Present Illness</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.4</td></tr>  <tr><td> Current Medications</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.19</td></tr>  <tr><td> Allergies</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.13</td></tr>  <tr><td> Acuity Assessment</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.2</td></tr>  <tr><td> Vital Signs</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2</td></tr> </table>          The list of modules that are required and should be examined for the EDES Nursing Note are: <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td> Vital Signs</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2</td></tr>  <tr><td> Assessments</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.4</td></tr>  <tr><td> Procedures and Interventions</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.11</td></tr>  <tr><td> Medications Administered</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.21</td></tr>  <tr><td> Intravenous Fluids Administered</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.6</td></tr>  <tr><td> ED Disposition</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.10</td></tr> </table>          The list of modules that are required and should be examined for the EDES Physician Note are: <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td>Referral Source</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.3</td></tr>  <tr><td>Mode of Arrival</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.10.3.2</td></tr>  <tr><td>Chief Complaint</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1</td></tr>  <tr><td>Reason for Visit</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1.1</td></tr>  <tr><td> History of Present Illness</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.4</td></tr>  <tr><td> Advanced Directives</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.34</td></tr>  <tr><td> Current Medications</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.19</td></tr>  <tr><td> Allergies</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.13</td></tr>  <tr><td> List of Surgeries</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.11</td></tr>  <tr><td> Immunizations</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.23</td></tr>  <tr><td> Family History</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.14</td></tr>  <tr><td> Social History</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.16</td></tr>  <tr><td>Vital Signs</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2</td></tr>  <tr><td>Physical Examination</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.9.15</td></tr>  <tr><td>Procedures Performed</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.11</td></tr>  <tr><td>Test Results Lab, ECG, Radiology</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.27</td></tr>  <tr><td>Consultations</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.8</td></tr>  <tr><td>Progress Note</td><td>1.3.6.1.4.1.19376.1.5.3.1.1.13.2.7</td></tr>  <tr><td>ED Diagnoses,</td><td>1.3.6.1.4.1.19376.1.5.3.1.1.13.2.9</td></tr>  <tr><td>ED Disposition</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.10</td></tr> </table>      </li>     </ol> </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (177, 1, 0, '2009-11-24 10:53:16.494', 'epoiseau', '<h3>Special Instructions</h3> <h3>Description</h3> <p>One assigned Connectathon Monitor will be assigned to scrutinize EDR documents. The purpose of this test is to have a single person with domain knowledge examine one example of each document. The Connectathon Monitor is looking for proper document structure, proper use of coded values and any other CDA or IHE specific requirements defined in PCC TF 3.</p>  <p>The Content Creator should use the same documents produced and stored in the Connectathon Wiki in the EDR_Load test.</p>  <p>The Connectathon Monitor will take the files offline and perform evaluation. The monitor will document any deficiencies and ask the Content Creator to correct during the Connectathon.</p>  <h3>Evaluation</h3> <p>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>   <p>This test needs to be completed by Day 2 at 12:00, and is better completed the afternoon of Day 1if possible. This will give downstream Content Consumers better test documents.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (178, 1, 0, '2009-11-24 10:53:16.497', '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 Monday at 17:00 if possible. If you complete after Tuesday at 12:00, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p>  <h3>Description</h3> <p>The Content Creator shall create/register one patient in the proper affinity domain: SYSTEM_NAME^EDR. Use the HIMSS Registration Tool to register this patient and obtain a patient identifier.</p>  <p>Create the appropriate document for the EDR patient.</p>  <p>For any of the coded values (allergies, medications, etc.) use only coded values found in the MESA/Connectathon Code Tables document. That document should list between 3 and 5 legal coded values. Do not invent codes or import other codes. If you find that document lacking, inform the Connectathon monitor about appropriate coded values for inclusion.</p> <ol>  <li>Create a readme.txt file that lists the Patient ID, Patient Name, company name, your name, and your Kudu system name.</li>  <li>Create a screen capture of a rendering of the EDR document. We recognize that not all renderings will be the same.</li>  <li>Name the document EDR_kudu.xml where kudu is your Kudu system name.</li>  <li>Create a zip file named EDR_kudu.zip that contains the three documents listed above.</li>  <li>Find the Connectathon Wiki page that references EDR documents. Upload your document according to the instructions on that page. Update the Wiki page to list your document/zip file.</li>  <li>If you support XDS, complete XDS_Doc_Source_Stores_Document or XDS_Embedded_Repository_Registers_Document using the EDR document.</li> </ol> <p>These items describe the minimum content that must be present in the EDR document. Additional content is acceptable, but the document must contain the following information:</p>  <table border="1" cellspacing="0" cellpadding="0">   <tr>     <td width="319" valign="top"><p>42349-1: REASON FOR REFERRAL</p></td>     <td width="319" valign="top"><p>Patient is otherwise healthy and is exhibiting chest    pain.</p></td>   </tr>   <tr>     <td width="319" valign="top"><p>10164-2: HISTORY OF PRESENT ILLNESS</p></td>     <td width="319" valign="top"><p>Patient has no history of cardiac illnes.</p></td>   </tr>   <tr>     <td width="319" valign="top"><p>11450-4: PROBLEM LIST</p></td>     <td width="319" valign="top"><p>Stress fracture, right foot (healed) , date 1-Aug-2002<br />       Ear infection, active, date 1-Oct-2006</p></td>   </tr>   <tr>     <td width="319" valign="top"><p>10160-0: HISTORY OF MEDICATION USE</p></td>     <td width="319" valign="top"><p>Amoxicillin (250 mg tabs) / 3 times per day / oral / 1-Oct-2006 '' 10-Oct-2006</p></td>   </tr>   <tr>     <td width="319" valign="top"><p>10155-0: HISTORY OF ALLERGIES</p></td>     <td width="319" valign="top"><p>Allergen: Iodinated contrast<br />       Reaction: laryngeal oedema<br />       Comments: Reaction occurs within 10 minutes</p></td>   </tr> </table>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (179, 1, 0, '2009-11-24 10:53:16.499', 'epoiseau', '<h3>Special Instructions</h3> <h3>Description</h3> <p>There are four processing options defined for the Content Consumer:  <ul>   <li>View</li>   <li>Document Import</li>   <li>Section Import</li>   <li>Discrete Data Import</li>  </ul> </p>  <p>In this test, the Content Consumer locates the EDR document produced by a single Content Creator. The Content Consumer demonstrates which of the 4 processing options are supported for the documment.</p>  <p>When examining the processing of the document, the Connectathon Monitor should evaluate the document with at least these items in mind:  <ul>   <li>Sections in the document are appropriate per the definitions in PCC TF 3: 3.3</li>   <li>A default style sheet is provided by the 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> </p>  <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 Connectathon Monitor is then looking for evidence that the Consumer processes at least one of the options as specified in the EDR Integration Profile.</p>  <p>The monitor shall check for these values in the document. If the Content Consumer supports the view option, this data shall be rendered for display. Other options may not include processing each entry, so evaluation will require some judgment.</p>  <table>  <tr><td>42349-1: REASON FOR REFERRAL</td><td>Patient is otherwise healthy and is exhibiting chest pain.</td></tr>  <tr><td>10164-2: HISTORY OF PRESENT ILLNESS</td><td>Patient has no history of cardiac illnes.</td></tr>  <tr><td>11450-4: PROBLEM LIST</td><td>Stress fracture, right foot (healed) , date 1-Aug-2002<br />          Ear infection, active, date 1-Oct-2006</td></tr>  <tr><td>10160-0: HISTORY OF MEDICATION USE</td><td>Amoxicillin (250 mg tabs) / 3 times per day / oral / 1-Oct-2006 '' 10-Oct-2006  </td></tr>  <tr><td>10155-0: HISTORY OF ALLERGIES</td><td>Allergen: Iodinated contrast<br /> Reaction: laryngeal oedema<br /> Comments: Reaction occurs within 10 minutes<br />  </td></tr> </table>      ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (180, 1, 0, '2009-11-24 10:53:16.502', '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 Referral document produced by a single Content Creator. The Content Consumer demonstrates which of the 4 processing options are supported for the documment.<br>   When examining the processing of the document, the Connectathon Monitor should evaluate the document with at least these items in mind:</p><ul> <li>Sections in the document are appropriate per the definitions in PCC TF</li> <li>A default style sheet is provided by the Content Creator. The Content Consumer is required to render the document with the  default style sheet. As an option, the Content Consumer can render with a  different style sheet.</li> </ul><H3>Evaluation</H3><p>In the evaluation, the Connectathon Monitor is looking for evidence that the Content Consumer can interpret the document produced by the Content Creator. That is a test of both actors. The Connetathon Monitor is then looking for evidence that the Consumer processes at least one of the options as specified in the EDR Integration Profile.<br>   The monitor shall check for these values in the document.  If the Content Consumer supports the view option, this data shall be rendered for display. Other options may not include processing each entry, so evaluation will require some judgment.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (181, 1, 0, '2009-11-24 10:53:16.504', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> <p>The goal of this test is to create one valid EDR Referral note and publish it in a location to make it easy for other participants to locate.</p> </p><H3>Description</H3><p>Each Content Creator has been assigned one well known patient (see test Content_Creator_Demographics) with a Patient ID in the proper domain. Create a document that uses the demographics for this patient and patient ID (if possible).</p><p>For any of the coded values (allergies, medications, etc.)  use only coded values found in the MESA/Connectathon Code Tables document. That  document should list between 3 and 5 legal coded values. Do not invent codes or  import other codes. If you find that document lacking, inform the Connectathon  monitor about appropriate coded values for inclusion.</p><ol> <li>These next steps refer to storing the document and reference information in the Kudu tool. You will find the page in the Kudu tool by selecting Connectathon and then Connectathon Images/CDs/Objects. The link to that page is <em><a href=system_con_object.php>Objects Information</a></em> </li>  <li>Enter the Patient ID,  Patient Name, company name, your name, and your Kudu system name into the description of the <em>Connectathon Images/CDAs/Objects</em>.</li> <li>Create a screen capture of a rendering of the EDR document. We recognize that not all renderings will be the same.</li> <li>Name the document EDR_Referral_kudu.xml where <strong><em>kudu</em></strong> is your Kudu system name.</li> <li>Upload information, snapshot and xml files in the <em>Connectathon Images/CDAs/Objects</em> section of Kudu.</li> <li> Upload your 2 documents according to the instructions on that  page. Update the <em> Connectathon Images/CDAs/Objects Publication/rendering page</em> page to list your document/zip file.</li> <li>Find the Connectathon monitor or monitors responsible for Document Scrutiny. Make sure they are aware your document has been placed into the Kudu tool.</li> <li>If you support XDS, complete XDS test that requires you to store and register your document with a repository/registry. You do not need to complete that XDS store step in order to complete this test. In fact, once you have uploaded the proper documentation into Kudu, mark this test complete.</li> </ol><p>These items describe the minimum content that must be  present in the ED Referral document. Additional content is acceptable, but the  document must contain the following information:</p><p>The content of various modules is defined at http://ihewiki.wustl.edu/wiki/index.php/PCC_Connectathon_Content_Test_Requirements. Use the wiki page to find the right content and incorporate into your document.</p><p>As defined in the PCC TF, you must include the following content modules. Optional modules are allowed.         The list of modules that are required and should be examined are:  <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td> Reason for Referral</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.1</td></tr>  <tr><td> History Present Illness</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.4</td></tr>  <tr><td> Active Problems</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.6</td></tr>  <tr><td> Current Meds</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.19</td></tr>  <tr><td> Allergies</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.13</td></tr>  <tr><td>Mode of Transport to the Emergency Department</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.10.3.2</td></tr>  <tr><td> Advance Directives</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.34</td></tr>  </table> </p> <H3>Evaluation</H3> <p>This will be evaluated with the EDR_Scrutiny_Referral and EDR_Process_Referral tests.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (182, 1, 0, '2009-11-24 10:53:16.506', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> <p>The monitor in charge of PCC documents will scrutinize your CDA content. He/she might not finish that work on Day 1. You need to publish the document and mark this test done to trigger the monitor to review your document.</p> <p> <em>You need to be able to produce legal content at the start of the event.</em> </p> </p> <H3>Description</H3> <p>One Connectathon Monitor will be assigned to scrutinize EDR documents.      The purpose of this test is to have a single person with domain knowledge examine one      example of each document.      The Connectathon Monitor is looking for proper document structure, proper use of coded values      and content that was specified in the Publish test.</p> <p>The Content Creator should use the same documents produced and stored in the Kudu tool in the EDR_Publish_Referral test.</p> <p>The Connectathon Monitor will take the files offline and perform evaluation.      The monitor will document any deficiencies and ask the Content Creator to correct      during the Connectathon.</p>  <H3>Evaluation</H3> <p>Monitors please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) the Content Creators have submitted. </p>  <p>The NIST Evaluation tools are found at <a href="http://xreg2.nist.gov/cda-validation/index.html">http://xreg2.nist.gov/cda-validation/index.html</a> .      For documents not supported by the NIST tool, use the schematron file found at IHESCHEMATRON.   </p><p>In the evaluation, the Connectathon Monitor will follow these steps:    <ol>      <li>Use CDA validation tool to make sure document is legal CDA document</li>      <li>Use Schematron test tool to see that document passes schematron tests for EDR Referral</li>  <li>Examine EDR Referral document by hand (possibly with style sheet) and examine for EDR specific content         in these sections.         Values are found on the         <a href="http://ihewiki.wustl.edu/wiki/index.php/PCC_Connectathon_Content_Test_Requirements">Connectathon wiki: PCC Content Test Requirements</a>         The list of modules that are required and should be examined are:  <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td> Reason for Referral</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.1</td></tr>  <tr><td> History Present Illness</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.4</td></tr>  <tr><td> Active Problems</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.6</td></tr>  <tr><td> Current Meds</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.19</td></tr>  <tr><td> Allergies</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.13</td></tr>  <tr><td>Mode of Transport to the Emergency Department</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.10.3.2</td></tr>  <tr><td> Advance Directives</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.34</td></tr>  </table>   </li> <li>NB: We are ignoring modules that are designated with optionality of O or R2.</li>     </ol> </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (183, 1, 0, '2009-11-24 10:53:16.508', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test is run by Image Display systems which support  any of the cardiology options in the Evidence Documents profile:</p> <ul>     <ul>      <li>Cath Evidence option</li>      <li>Echo Evidence option</li>      <li>CTA/MRA Evidence option</li>      <li>Stress Test Evidence option </li>     </ul> </ul> <p>In order to run this test, Evidence Creator actors which  support these options must complete the tests in which they store their evidence  documents (SRs) to Image Manager systems.&nbsp;  These tests are named ED_Creator_PACS_*_Option.</p> </p><H3>Description</H3><p>In this test, the Image Display demonstrates its ability  to cardiology evidence documents (SRs) created by various Evidence Creator  systems.</p><p>    The Image Display must be able to render and display all  Templates for the SOP Classes which it accepts.</p><p>    The Image Display system should drive this test.&nbsp; The representative of the Image&nbsp; Display system should identify an Evidence  Creator system which supports the same cardiology option(s) as its system. Ask  the Evidence Creator vendor representative which Image Manager/Image Archive it  has stored its evidence documents (SRs) to.</p><p>    Note 1: The Evidence Creator is a required actor in this  test.&nbsp; It has&nbsp; no transactions to perform, but will be  identified so that it can be given credit for interoperability with the Image  Display who renders its SRs.</p><p>    Note 2:&nbsp; The Image  Manager system is identified as &lsquo;optional&rsquo; for this test because it is needed  to help out with Image Display system, allowing it to Query/Retrieve SRs from  its system.&nbsp; Image Managers are not  required to complete&nbsp; 3 instances of this  test.</p><H3>Evaluation</H3><p>FOR ALL CARDIOLOGY OPTIONS (Cath Evidence, Echo Evidence,  CTA/MRA Evidence, Stress Test Evidence:</p><ul>     <li>The Connectathon Monitor should observe &lsquo;live&rsquo;  the ability of the Image Display to query and retrieve SRs from an Image  Manager system (not the Central Archive).</li>     <li>The Connectathon Monitor should observe the  Image Display and its ability to interpret/render the Evidence Documents from  the Evidence Creator. All SOP Classes and Templates which the Evidence Creator  supports should be displayed.</li>     <li>The Connectathon Monitor should observe the original  report at the Evidence Creator (the creator of the SR), the Image Manager, or  another Image Display and spot check the Image Display/Report creator to verify  the contents of the Structured Report are displayed <u>correctly</u> and <u>completely</u> </li>     <li>The Image Display must demonstrate its ability  to show abnormal measurements with &ldquo;readily visible emphasis&rdquo;, (e.g., font,  bold, text or background color, specialized window area, etc.).</li> </ul><p>For the <strong>CTA/MRA Evidence </strong>option:</p><ul>     <li>The Image Display must demonstrate that it can  display a hyperlink to a referenced object for a content item with value type  of IMAGE.</li>     <li>The Image Display must demonstrate that it can  display a hyperlink to a referenced object with rendering of spatial  coordinates for a content item with value type of SCOORD.</li> </ul><p>For the <strong>Stress Test Evidence </strong>option:</p><ul>     <li>The Image Display must demonstrate that it can  display a hyperlink to a referenced object for a content item with value type  of IMAGE.</li>     <li>The Image Display must demonstrate that it can  display a hyperlink to a referenced object with rendering of temporal or  spatial coordinates for a content item with value type of TCOORD or SCOORD.</li>     <li>The Image Display actor must  demonstrates user control for rendering of ECG ST elevation or depression  measurements either in units of mV or in units of mm (based on conventional  scaling of 0.1 mV/mm). </li>     <li>For SR documents  encoded using Template x3300, the Image Display must render the contents of the  Template x3304 Stress Test Measurement Groups (subsidiary to a Template x3303  Stress Test Phase Data CONTAINER) <strong><u>in  a tabular format</u></strong>. </li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (184, 1, 0, '2009-11-24 10:53:16.511', 'epoiseau', '<p>This test is the same as ED_Modality_PACS. It is a separate test because the Evidence Creator creates the Evidence Documents.<p>  <p>The purpose of the test is to test the storage and storage commitment, not  the rendering of the evidence documents</p>  <p>The ED_Creator_PACS test exercises the Evidence Document profile transactions between an Evidence Creator and an Image Manager/Image Archive. In the Evidence Documents profile, the Evidence Creator must produce these documents (SR reports, not images) and store them on the Image Manager. These documents must also be committed using the Storage Commitment transaction.</p>  <p>An Evidence Creator must produce documents from the following list and an Image Manager must be able to store those documents: <ul>  <li>Mammography CAD SR</li>  <li>Basic Text SR</li>  <li>Enhanced SR</li>  <li>Comprehensive SR</li>  <li>Chest CAD SR</li> </ul> </p>    <p>For evaluation, the Project Manager should observe evidence from the Image Manager that these documents were stored. This can be a display on the Image Manager, a 3rd party display or logs on the Image Manager if no display is readily available.</p>  <p>The Project Manager should also observe logs in the Image Manager that demonstrate the Storage Commitment transaction.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (185, 1, 0, '2009-11-24 10:53:16.514', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test is run by Evidence Creators which support the  CTA/MRA Evidence option in the Cardiology Evidence Documents profile.</p> <p>    This test is similar to ED_Modality_PACS_ CTA/MRA_Option.  It is a separate test because the Evidence Creator can also create the SOP  Class instances. </p> </p><H3>Description</H3><p>The ED_Creator_PACS_CTA/MRA_Option test exercises the  Evidence Documents profile transactions between an Evidence Creator and an  Image Manager/Image.&nbsp; In the Evidence  Documents profile, the Evidence Creator must produce these documents (SR  reports, not images) and store them on the Image Manager. These documents must  also be committed using the Storage Commitment transaction.</p><p>    An Evidence Creator must produce documents from the  following list and an Image Manager must be able to store those documents for  the CTA/MRA Evidence Option:</p><ul>     <li>Enhanced SR</li> </ul><p>The CTA/MRA Evidence Option Templates include:</p><ul>     <li>3900 CT/MR Cardiovaascular Analysis Report</li> </ul><p>To aid in evaluation, it is in your best interest to begin  with an image or Modality Worklist where most of the information listed below  is known to be present, otherwise you will spend a significant amount of time  justifying the absence of the information.</p><H3>Evaluation</H3><p>On the <strong>Image Manager</strong>: The Connectathon Monitor should observe evidence from    the Image Manager that these documents were stored. This can be a display on the Image Manager, a    3rd party display or logs or database on the Image Manager if no display is readily    available.&nbsp; At the Image Manager, all of the following attributes of the Structured    Report object from the Modality shall be verified to match the original image or MWL    information:&nbsp;&nbsp; (see Rad TF-2: Appendix A, Table A.2-1 and section A.3):</p><p> Study Instance UID&nbsp; (0020, 000D)</p><p> Referenced Request Sequence&nbsp; (0040, A370)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Study Instance UID&nbsp; (0020, 000D)</p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced Study Sequence (0008, 1110)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Accession Number&nbsp; (0008, 0050)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure ID (0040, 1001)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure Description (0032, 1060)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure Code Sequence&nbsp; (0032, 1064)</p><p> Performed Procedure Code Sequence (0040, A372)</p><p> Referenced Study Component Sequence</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Class UID&nbsp; (0008, 1150)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Instance UID&nbsp; (0008, 1155)</p><p> Patient Name&nbsp;&nbsp; (0010, 0010)</p><p> Patient ID&nbsp;&nbsp; (0010, 0020)</p><p> Patient&rsquo;s Birth Date (0010, 0030)</p><p> Patient&rsquo;s Sex&nbsp; (0010, 0040)</p><p> Referring Physicians Name (0008, 0090)</p><p> Completion Flag (0040,A491)</p><p>The Connectathon Monitor should also observe logs in the Image Manager that demonstrate the    Storage Commitment transaction.&nbsp; All of the following attributes shall be verified in    the Storage Commit message from the Evidence Creator:</p><p> Referenced SOP Sequence (0008, 1199)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Reference SOP Class (0008, 1150)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Instance UID (0008, 1155)</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (186, 1, 0, '2009-11-24 10:53:16.516', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test is run by Evidence Creators which support the Cath Evidence option in the Cardiology    Evidence Documents profile.</p> <p> If you are an Evidence Creator in the Cardiac Catheterization Workflow Integration (CATH)    profile, you should run test CATH_EvidenceCreator_PACS_Display instead of this test.</p> <p>This test is similar to ED_Modality_PACS_ Cath_Option. It is a separate test because the    Evidence Creator can also create the Evidence Documents.</p> </p><H3>Description</H3><p>The ED_Creator_PACS _Cath_Option test exercises the Evidence Document profile transactions    between an Evidence Creator and an Image Manager/Image Archive. In the Evidence Documents    profile, the Evidence Creator must produce these documents (SR reports, not images) and store    them on the Image Manager. These documents must also be committed using the Storage Commitment    transaction.</p><p> An Evidence Creator must produce documents from the following list and an Image Manager must    be able to store those documents:</p><ul>     <li>Enhanced SR</li>     <li>Comprehensive SR</li>     <li>Procedure Log</li> </ul><p>The Cath Option Templates include:</p><ul>     <li>3001 Procedure Log</li>     <li>3202 Ventricular Analysis</li>     <li>3213 Quantitative Arterial Analysis</li>     <li>3250 Intravascular Ultrasound</li>     <li>3500 Hemodynamics</li> </ul><p>All supported SOP Classes and all supported Templates within those SOP Classes must be tested    and verified.&nbsp;&nbsp; </p><p> To aid in evaluation, it is in your best interest to begin with an image or Modality Worklist    where most of the information listed below is known to be present, otherwise you will spend a    significant amount of time justifying the absence of the information.</p><H3>Evaluation</H3><p>On the <strong>Image Manager</strong>: The Connectathon Monitor should observe evidence from    the Image Manager that these documents were stored. This can be a display on the Image Manager, a    3rd party display or logs or database on the Image Manager if no display is readily    available.&nbsp; At the Image Manager, all of the following attributes of the Structured    Report object from the Modality shall be verified to match the original image or MWL    information:&nbsp;&nbsp; (see Rad TF-2: Appendix A, Table A.2-1 and section A.3):</p><p> Study Instance UID&nbsp; (0020, 000D)</p><p> Referenced Request Sequence&nbsp; (0040, A370)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Study Instance UID&nbsp; (0020, 000D)</p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced Study Sequence (0008, 1110)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Accession Number&nbsp; (0008, 0050)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure ID (0040, 1001)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure Description (0032, 1060)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure Code Sequence&nbsp; (0032, 1064)</p><p> Performed Procedure Code Sequence (0040, A372)</p><p> Referenced Study Component Sequence</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Class UID&nbsp; (0008, 1150)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Instance UID&nbsp; (0008, 1155)</p><p> Patient Name&nbsp;&nbsp; (0010, 0010)</p><p> Patient ID&nbsp;&nbsp; (0010, 0020)</p><p> Patient&rsquo;s Birth Date (0010, 0030)</p><p> Patient&rsquo;s Sex&nbsp; (0010, 0040)</p><p> Referring Physicians Name (0008, 0090)</p><p> Completion Flag (0040,A491)</p><p>The Connectathon Monitor should also observe logs in the Image Manager that demonstrate the    Storage Commitment transaction.&nbsp; All of the following attributes shall be verified in    the Storage Commit message from the Evidence Creator:</p><p> Referenced SOP Sequence (0008, 1199)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Reference SOP Class (0008, 1150)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Instance UID (0008, 1155)</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (187, 1, 0, '2009-11-24 10:53:16.519', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test is similar to ED_Modality_PACS_Display. It is a separate test because the Evidence    Creator can also create the Evidence Documents.</p> </p>  <H3>Description</H3> <p>The ED_Creator_PACS_Display test exercises the Radiololgy Evidence Documents profile    transactions between an Evidence Creator and an Image Manager/Image Archive and a Display system.    In the Evidence Documents profile, the Evidence Creator must produce these documents (SR reports,    not images) and store them on the Image Manager. These documents must also be committed using the    Storage Commitment transaction.</p> <p>An Evidence Creator must produce documents from the following list and an Image Manager must be    able to store those documents:</p>  <ul>     <li>Mammography CAD SR</li>     <li>Basic Text SR</li>     <li>Enhanced SR</li>     <li>Comprehensive SR</li>     <li>Chest CAD SR</li> </ul> <p>All supported SOP Classes and all supported Templates within those SOP Classes must be tested    and verified. </p> <p>The Image Display must be able to render all Templates for the SOP Classes which it supports.</p> <p>To aid in evaluation, it is in your best interest to begin with an image or worklist where most    of the information listed below is known to be present, otherwise you will spend a significant    amount of time justifying the absence of the information.</p>  <H3>Evaluation</H3> <p>On the <strong>Image Manager:</strong> </p> <p>The Connectathon Monitor should observe evidence from the Image Manager that these documents    were stored. This can be a display on the Image Manager, a 3rd party display or logs or database    on the Image Manager if no display is readily available. At the Image Manager, all of the    following attributes of the Structured Report object from the Modality shall be verified to match    the original image or worklist information: (see Rad TF-2- Appendix A, Table A.2-1 and section    A.3):</p>  <ul>     <li>Study Instance UID (0020, 000D)</li>     <li>Referenced Request Sequence (0040, A370)<ul>       <li> >Study Instance UID (0020, 000D)</li>       <li>Referenced Study Sequence (0008, 1110)</li>       <li> >Accession Number (0008, 0050)</li>       <li> >Requested Procedure ID (0040, 1001)</li>       <li> >Requested Procedure Description (0032, 1060)</li>       <li> >Requested Procedure Code Sequence (0032, 1064)</li>      </ul>     </li>     <li>Performed Procedure Code Sequence (0040, A372)</li>     <li>Referenced Study Component Sequence<ul>       <li> >Referenced SOP Class UID (0008, 1150)</li>       <li> >Referenced SOP Instance UID (0008, 1155)</li>      </ul>      <li>Patient Name (0010, 0010)</li>      <li>Patient ID (0010, 0020)</li>      <li>Patient''s Birth Date (0010, 0030)</li>      <li>Patient''s Sex (0010, 0040)</li>      <li>Referring Physicians Name (0008, 0090)</li>     </li> </ul>  <p>On the <strong>Image Manager</strong>: </p> <p>The Connectathon monitor should also observe logs in the Image Manager that demonstrate the    Storage Commitment transaction. All of the following attributes shall be verified in the Storage    Commit message from the Evidence Creator:</p>  <ul>     <li>Referenced SOP Sequence (0008, 1199)<ul>       <li> >Reference SOP Class (0008, 1150)</li>       <li> >Referenced SOP Instance UID (0008, 1155)</li>      </ul>     </li> </ul> <p>On the <strong>Image Display:</strong> </p> <p>The Connectathon Monitor should observe the Image Display and its ability to interpret/render    the Evidence Documents. The Connectathon monitor should observe the original report at the Image    Manger, the Acqusition Modality, the Evidence Creator, or another Image Display and spot check    the Image Display/Report creator to verify the contents of the Structured Report are displayed    correctly and completely. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (188, 1, 0, '2009-11-24 10:53:16.523', 'epoiseau', '<H3>Special Instructions</H3>  <p>This test is similar to ED_Modality_PACS_Display_Cath_Option. It is a separate test because the Evidence Creator can also create the Evidence Documents.     ED_Creator_PACS_Display_Cath test should only be run if the Cardiology options are supported. </p>  <H3>Description</H3> <p> The ED_Creator_PACS_Display_Cath_Option test exercises the Evidence Document profile transactions between an Evidence Creator and an Image Manager/Image Archive. In the Evidence Documents profile, the Evidence Creator must produce these documents (SR reports, not images) and store them on the Image Manager. These documents must also be committed using the Storage Commitment transaction. <p> An Evidence Creator must produce documents from the following list and an Image Manager must be able to store those documents for the <b>Cath Option</b>:</p> <pre> ''	Enhanced SR ''	Comprehensive SR ''	Procedure Log  The Cath Option Templates include:  ''	3001 Procedure Log ''	3202 Ventricular Analysis ''	3213 Quantitative Arterial Analysis ''	3250 Intravascular Ultrasound ''	3500 Hemodynamics </pre> <p> All supported SOP Classes and all supported Templates within those SOP Classes must be tested and verified.    </p> <p> The Image Display must be able to render all Templates for the SOP Classes which it accepts. </p> <p> To aid in evaluation, it is in your best interest to begin with an image or Modality Worklist where most of the information listed below is known to be present, otherwise you will spend a significant amount of time justifying the absence of the information. Use the patient naming convention of:  ED-CATH- COMPANYCREATOR_n^COMPANYPACS, where ''n'' is an incrementing number for how many SOP Classes and templates the Evidence Creator is capable of generating.   For example, if it were a Philips workstation and a Sectra PACS the patient name might be: ''ED-PhilipsIU33_1^SectraPACS'' </p> <H3>Evaluation</H3> <p> In the Kudu chat window, record all SOP Classes and all Templates which were tested, including all Patient Names, Patient IDs, and Study Instance UIDs for locating information at a later time for verification. </p> <p> The Connectathon Monitor should observe evidence from the <b>Image Manager </b>that these documents were stored. This can be a display on the Image Manager, a 3rd party display or logs or database on the Image Manager if no display is readily available.  At the Image Manager, all of the following attributes of the Structured Report object from the Evicence Creator shall be verified to match the original image or MWL information:   (see Rad TF Vol2: Append A, Table A.2-1 and section A.3): </p> <pre>  Study Instance UID  (0020, 000D) Referenced Request Sequence  (0040, A370) 	>Study Instance UID  (0020, 000D) 	>Referenced Study Sequence (0008, 1110) 	>Accession Number  (0008, 0050) 	>Requested Procedure ID (0040, 1001) 	>Requested Procedure Description (0032, 1060) 	>Requested Procedure Code Sequence  (0032, 1064) Performed Procedure Code Sequence (0040, A372) Referenced Study Component Sequence  	>Referenced SOP Class UID  (0008, 1150) 	>Referenced SOP Instance UID  (0008, 1155) Patient Name   (0010, 0010) Patient ID   (0010, 0020) Patient''s Birth Date (0010, 0030) Patient''s Sex  (0010, 0040) Referring Physicians Name (0008, 0090) Completion Flag (0040,A491)  </pre> <p> The Connectathon monitor should also observe logs in the <b>Image Manager</b> that demonstrate the Storage Commitment transaction.  All of the following attributes shall be verified in the Storage Commit message from the Evicence Creator: </p> <pre> Retrieve AE Title (0008, 0054) Referenced SOP Sequence (0008, 1199) 	>Reference SOP Class (0008, 1150) 	>Referenced SOP Instance UID (0008, 1155)  </pre> <p> The Connectathon onitor should observe the <b>Image Display</b> and its ability to interpret/render the Evidence Documents. The Connectathon monitor should observe the original report at the Image Manger, the Evicence Creator, the Evidence Creator, or another Image Display and spot check the Image Display/Report creator to verify the contents of the Structured Report are displayed correctly and completely.    </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (189, 1, 0, '2009-11-24 10:53:16.525', 'epoiseau', '<H3>Special Instructions</H3> <p>This test is similar to ED_Modality_PACS_Display_Echo_Option. It is a separate test because the Evidence Creator can also create the SOP Class instances.     This test is only used if the modality supports the Cardiology options. </p> <p> The ED_Creator_PACS_Display_Echo_Option test exercises the Evidence Document profile transactions between an Evidence Creator, an Image Manager/Image Archive and an Image Display. In the Evidence Documents profile, the Evidence Creator must produce these documents (SR reports, not images) and store them on the Image Manager. These documents must also be committed using the Storage Commitment transaction. </p> An Evidence Creator must produce documents from the following list and an Image Manager must be able to store those documents for the <b>Echo Option</b>:</p> <pre> ''	Enhanced SR ''	Comprehensive SR  The Echo Option Templates include:  ''	5100 Vascular Ultrasound ''	5200 Echocardiography </pre> <p> All supported SOP Classes and all supported Templates within those SOP Classes must be tested and verified.    </p> <p> The Image Display must be able to render and display all Templates for the SOP Classes which it accepts. </p> <p> To aid in evaluation, it is in your best interest to begin with an image or Modality Worklist where most of the information listed below is known to be present, otherwise you will spend a significant amount of time justifying the absence of the information. </p> <p> Use the patient naming convention of:  ED-COMPANYCREATOR_n^COMPANYPACS, where ''n'' is an incrementing number for how many SOP Classes and templates the Modality is capable of generating.   For example, if it were a Philips workstation and a Sectra PACS the patient name might be: ''ED-PhilipsIU33_1^SectraPACS'' </p>  <H3>Evaluation</H3> <p> In the Kudu chat window, record all SOP Classes and all Templates which were tested, including all Patient Names, Patient IDs, and Study Instance UIDs for locating information at a later time for verification. </p> <p> The Connectathon Monitor should observe evidence from the <b>Image Manager </b>that these documents were stored. This can be a display on the Image Manager, a 3rd party display or logs or database on the Image Manager if no display is readily available.  At the Image Manager, all of the following attributes of the Structured Report object from the Evidence Creator shall be verified to match the original image or MWL information:   (see Rad TF Vol2: Append A, Table A.2-1 and section A.3): </p> <pre> Study Instance UID  (0020, 000D) Referenced Request Sequence  (0040, A370) 	>Study Instance UID  (0020, 000D) 	>Referenced Study Sequence (0008, 1110) 	>Accession Number  (0008, 0050) 	>Requested Procedure ID (0040, 1001) 	>Requested Procedure Description (0032, 1060) 	>Requested Procedure Code Sequence  (0032, 1064) Performed Procedure Code Sequence (0040, A372) Referenced Study Component Sequence  	>Referenced SOP Class UID  (0008, 1150) 	>Referenced SOP Instance UID  (0008, 1155) Patient Name   (0010, 0010) Patient ID   (0010, 0020) Patient''s Birth Date (0010, 0030) Patient''s Sex  (0010, 0040) Referring Physicians Name (0008, 0090) Completion Flag (0040,A491) </pre> <p> The Connectathon Monitor should also observe logs in the <b>Image Manager</b> that demonstrate the Storage Commitment transaction.  All of the following attributes shall be verified in the Storage Commit message from the Modality: </p> <pre> Retrieve AE Title (0008, 0054) Referenced SOP Sequence (0008, 1199) 	>Reference SOP Class (0008, 1150) 	>Referenced SOP Instance UID (0008, 1155) </pre> <p> The Connectathon Monitor should observe the <b>Image Display </b>and its ability to interpret/render the Evidence Documents. The Connectathon monitor should observe the original report at the Image Manger, the Evidence Creator, or another Image Display and spot check the Image Display/Report creator to verify the contents of the Structured Report are displayed correctly and completely.    </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (190, 1, 0, '2009-11-24 10:53:16.528', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test is run by Evidence Creators which support the Echo Evidence option in the Cardiology    Evidence Documents profile.</p> <p> This test is similar to ED_Modality_PACS_Display_Echo_Option. It is a separate test because    the Evidence Creator can also create the SOP Class    instances.&nbsp;&nbsp;&nbsp;&nbsp; </p> </p><H3>Description</H3><p>The ED_Creator_PACS_ Echo_Option test exercises the Evidence Documents profile transactions    between a Evidence Creator and an Image Manager/Image Archive. In the Evidence Documents profile,    the Evidence Creator must produce these documents (SR reports, not images) and store them on the    Image Manager. These documents must also be committed using the Storage Commitment transaction.</p><p> A Evidence Creator must produce documents from the following list and an Image Manager must be    able to store those documents for the Echo Option:</p><ul>     <li>Enhanced SR</li>     <li>Comprehensive SR</li> </ul><p>The Echo Option Templates include:</p><ul>     <li>5100 Vascular Ultrasound</li>     <li>5200 Echocardiography</li> </ul><p>All supported SOP Classes and all supported Templates within those SOP Classes must be tested    and verified.&nbsp;&nbsp; </p><p>To aid in evaluation, it is in your best interest to begin with an image or Modality Worklist    where most of the information listed below is known to be present, otherwise you will spend a    significant amount of time justifying the absence of the information.</p><H3>Evaluation</H3><p>On the <strong>Image Manager</strong>: The Connectathon Monitor should observe evidence from    the Image Manager that these documents were stored. This can be a display on the Image Manager, a    3rd party display or logs or database on the Image Manager if no display is readily    available.&nbsp; At the Image Manager, all of the following attributes of the Structured    Report object from the Modality shall be verified to match the original image or MWL    information:&nbsp;&nbsp; (see Rad TF-2: Appendix A, Table A.2-1 and section A.3):</p><p> Study Instance UID&nbsp; (0020, 000D)</p><p> Referenced Request Sequence&nbsp; (0040, A370)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Study Instance UID&nbsp; (0020, 000D)</p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced Study Sequence (0008, 1110)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Accession Number&nbsp; (0008, 0050)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure ID (0040, 1001)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure Description (0032, 1060)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure Code Sequence&nbsp; (0032, 1064)</p><p> Performed Procedure Code Sequence (0040, A372)</p><p> Referenced Study Component Sequence</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Class UID&nbsp; (0008, 1150)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Instance UID&nbsp; (0008, 1155)</p><p> Patient Name&nbsp;&nbsp; (0010, 0010)</p><p> Patient ID&nbsp;&nbsp; (0010, 0020)</p><p> Patient&rsquo;s Birth Date (0010, 0030)</p><p> Patient&rsquo;s Sex&nbsp; (0010, 0040)</p><p> Referring Physicians Name (0008, 0090)</p><p> Completion Flag (0040,A491)</p><p>The Connectathon Monitor should also observe logs in the Image Manager that demonstrate the    Storage Commitment transaction.&nbsp; All of the following attributes shall be verified in    the Storage Commit message from the Evidence Creator:</p><p> Referenced SOP Sequence (0008, 1199)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Reference SOP Class (0008, 1150)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Instance UID (0008, 1155)</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (191, 1, 0, '2009-11-24 10:53:16.531', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test is run by Evidence Creators which support the  Stress Test Evidence option in the Cardiology Evidence Documents profile.</p> <p>    This test is similar to ED_Modality_PACS_Stress  Test_Option. It is a separate test because the Evidence Creator can also create  the SOP Class instances.&nbsp;&nbsp;&nbsp;&nbsp; </p> </p><H3>Description</H3><p>The ED_Modality_PACS_Stress_Test_Option test exercises the  Evidence Documents profile transactions between an Evidence Creator and an  Image Manager/Image Archive. In the Evidence Documents profile, the Evidence  Creator must produce these documents (SR reports, not images) and store them on  the Image Manager. These documents must also be committed using the Storage  Commitment transaction.</p><p>    An Evidence Creator must produce documents from the  following list and an Image Manager must be able to store those documents for  the CTA/MRA Evidence Option:</p><ul>     <li>Enhanced SR</li> </ul><p>The CTA/MRA Evidence Option Templates include:</p><ul>     <li>x3300 Stress Testing Report &ndash; DICOM Supplement  128</li> </ul><p>To aid in evaluation, it is in your best interest to begin  with an image or Modality Worklist where most of the information listed below  is known to be present, otherwise you will spend a significant amount of time  justifying the absence of the information.</p><H3>Evaluation</H3><p>On the <strong>Image Manager</strong>: The Connectathon Monitor should observe evidence from    the Image Manager that these documents were stored. This can be a display on the Image Manager, a    3rd party display or logs or database on the Image Manager if no display is readily    available.&nbsp; At the Image Manager, all of the following attributes of the Structured    Report object from the Modality shall be verified to match the original image or MWL    information:&nbsp;&nbsp; (see Rad TF-2: Appendix A, Table A.2-1 and section A.3):</p><p> Study Instance UID&nbsp; (0020, 000D)</p><p> Referenced Request Sequence&nbsp; (0040, A370)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Study Instance UID&nbsp; (0020, 000D)</p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced Study Sequence (0008, 1110)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Accession Number&nbsp; (0008, 0050)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure ID (0040, 1001)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure Description (0032, 1060)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure Code Sequence&nbsp; (0032, 1064)</p><p> Performed Procedure Code Sequence (0040, A372)</p><p> Referenced Study Component Sequence</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Class UID&nbsp; (0008, 1150)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Instance UID&nbsp; (0008, 1155)</p><p> Patient Name&nbsp;&nbsp; (0010, 0010)</p><p> Patient ID&nbsp;&nbsp; (0010, 0020)</p><p> Patient&rsquo;s Birth Date (0010, 0030)</p><p> Patient&rsquo;s Sex&nbsp; (0010, 0040)</p><p> Referring Physicians Name (0008, 0090)</p><p> Completion Flag (0040,A491)</p><p>The Connectathon Monitor should also observe logs in the Image Manager that demonstrate the    Storage Commitment transaction.&nbsp; All of the following attributes shall be verified in    the Storage Commit message from the Evidence Creator:</p><p> Referenced SOP Sequence (0008, 1199)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Reference SOP Class (0008, 1150)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Instance UID (0008, 1155)</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (192, 1, 0, '2009-11-24 10:53:16.534', 'epoiseau', '<p>The purpose of the ED_Display_Creator_Evidence test is for an Image Display/Report Creator to demonstrate that it can interpret/display the Evidence Documents created by an Evidence Creator and produce a DICOM Structured Report object using that data.</p>  <p>The Image Display will retrieve the Evidence Documents from the Image Manager (that may receive these documents either during this test or during a prior ED_Creator_PACS test). These documents are from one or more of the following types: <ul>  <li>Mammography CAD SR</li>  <li>Basic Text SR</li>  <li>Enhanced SR</li>  <li>Comprehensive SR</li>  <li>Chest CAD SR</li> </ul> </p> <p>For evaluation, the Project Manager should observe the Image Display and its ability to interpret/render the Evidence Documents. The Project Manager should observe the Image Display/Report creator incorporate the evidence into a DICOM Structured Report. Although not listed as a test partner, the Report Creator should send the report to a Report Manager. This can also be examined by the Project Manager.</p>  <p>Note : Image Display shall be grouped to a Report Creator for the ED profile</p> <p>Note : The role of the IM and RM can be played by the Central Archive</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (193, 1, 0, '2009-11-24 10:53:16.536', 'epoiseau', '<p>The purpose of the ED_Display_Modality_Evidence test is for an Image Display/Report Creator to demonstrate that it can interpret/display the Evidence Documents created by a Modality and produce a DICOM Structured Report object using that data.</p>  <p>The Image Display will retrieve the Evidence Documents from the Image Manager (that may receive these documents either during this test or during a prior ED_Modality_PACS test). These documents are from one or more of the following types: <ul>  <li>Mammography CAD SR</li>  <li>Basic Text SR</li>  <li>Enhanced SR</li>  <li>Comprehensive SR</li>  <li>Chest CAD SR</li> </ul> </p> <p>For evaluation, the Project Manager should observe the Image Display and its ability to interpret/render the Evidence Documents. The Project Manager should observe the Image Display/Report creator incorporate the evidence into a DICOM Structured Report. Although not listed as a test partner, the Report Creator should send the report to a Report Manager. This can also be examined by the Project Manager.</p>  <p>Note : Image Display shall be grouped to a Report Creator for the ED profile</p> <p>Note : The role of the IM and RM can be played by the Central Archive</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (194, 1, 0, '2009-11-24 10:53:16.537', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Image Display actors which support the CTA/MRA Evidence option perform one instance of this test.</p> </p><H3>Description</H3><p>This test ensures that the Image Display actor supports all SOP classes required by this option.</p><H3>Evaluation</H3><p>For the <strong>CTA/MRA Evidence </strong>option:</p><ul>     <li>The Image Display must  demonstrate for the Connectathon Monitor that it can render <strong><u>each</u></strong> of these SOP classes (all  are required) :</li> </ul><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td valign="top"> <p align="center"> <strong>SOP Class UID </strong>  </p> </td>     <td valign="top"> <p align="center"> <strong>SOP Class Name </strong>  </p> </td>     </tr>     <tr>      <td valign="top"> <p>1.2.840.10008.5.1.4.1.1.88.22 </p> </td>     <td valign="top"> <p>Enhanced SR </p> </td>     </tr>     <tr>      <td valign="top"> <p>1.2.840.10008.5.1.4.1.1.2 </p> </td>     <td valign="top"> <p>CT Image Storage </p> </td>     </tr>     <tr>      <td valign="top"> <p>1.2.840.10008.5.1.4.1.1.2.1 </p> </td>     <td valign="top"> <p>Enhanced CT Image    Storage </p> </td>     </tr>     <tr>      <td valign="top"> <p>1.2.840.10008.5.1.4.1.1.4 </p> </td>     <td valign="top"> <p>MR Image Storage </p> </td>     </tr>     <tr>      <td valign="top"> <p>1.2.840.10008.5.1.4.1.1.4.1 </p> </td>     <td valign="top"> <p>Enhanced MR Image    Storage </p> </td>     </tr>     <tr>      <td valign="top"> <p>1.2.840.10008.5.1.4.1.1.7 </p> </td>     <td valign="top"> <p>Secondary Capture Image    Storage </p> </td>     </tr>     <tr>      <td valign="top"> <p>1.2.840.10008.5.1.4.1.1.7.2 </p> </td>     <td valign="top"> <p>Multi-frame Grayscale    Byte Secondary Capture Image Storage </p> </td>     </tr>     <tr>      <td valign="top"> <p>1.2.840.10008.5.1.4.1.1.7.4 </p> </td>     <td valign="top"> <p>Multi-frame True Color    Secondary Capture Image Storage </p> </td>     </tr> </table> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (195, 1, 0, '2009-11-24 10:53:16.54', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Image Display actors which support the Stress Test Evidence option perform one instance of this test.</p> </p><H3>Description</H3><p>This test ensures that the Image Display actor supports all SOP classes required by this option.</p><H3>Evaluation</H3><p>For the <strong>Stress Test Evidence </strong>option:</p><ul>     <li>The Image Display must  demonstrate that it can render <strong><u>each</u></strong> of these SOP classes (all are required) :</li> </ul><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td valign="top"> <p align="center"> <strong>SOP Class UID </strong>  </p> </td>     <td valign="top"> <p align="center"> <strong>SOP Class Name </strong>  </p> </td>     </tr>     <tr>      <td valign="top"> <p>1.2.840.10008.5.1.4.1.1.88.22 </p> </td>     <td valign="top"> <p>Enhanced SR </p> </td>     </tr>     <tr>      <td valign="top"> <p>1.2.840.10008.5.1.4.1.1.88.33 </p> </td>     <td valign="top"> <p>Comprehensive SR </p> </td>     </tr>     <tr>      <td valign="top"> <p>1.2.840.10008.5.1.4.1.1.9.1.1 </p> </td>     <td valign="top"> <p>12-Lead ECG Waveform    Storage </p> </td>     </tr>     <tr>      <td valign="top"> <p>1.2.840.10008.5.1.4.1.1.9.1.2 </p> </td>     <td valign="top"> <p>General ECG Waveform    Storage </p> </td>     </tr>     <tr>      <td valign="top"> <p>1.2.840.10008.5.1.4.1.1.88.40 </p> </td>     <td valign="top"> <p>Procedure Log </p> </td>     </tr>     <tr>      <td valign="top"> <p>1.2.840.10008.5.1.4.1.1.104.1 </p> </td>     <td valign="top"> <p>Encapsulated PDF </p> </td>     </tr>     <tr>      <td valign="top"> <p>1.2.840.10008.5.1.4.1.1.6.1 </p> </td>     <td valign="top"> <p>Ultrasound Image    Storage </p> </td>     </tr>     <tr>      <td valign="top"> <p>1.2.840.10008.5.1.4.1.1.3.1 </p> </td>     <td valign="top"> <p>Ultrasound Multi-frame Image    Storage </p> </td>     </tr>     <tr>      <td valign="top"> <p>1.2.840.10008.5.1.4.1.1.20 </p> </td>     <td valign="top"> <p>Nuclear Medicine Image    Storage </p> </td>     </tr>     <tr>      <td valign="top"> <p>1.2.840.10008.5.1.4.1.1.7 </p> </td>     <td valign="top"> <p>Secondary Capture Image    Storage </p> </td>     </tr>     <tr>      <td valign="top"> <p>1.2.840.10008.5.1.4.1.1.7.2 </p> </td>     <td valign="top"> <p>Multi-frame Grayscale    Byte Secondary Capture Image Storage </p> </td>     </tr>     <tr>      <td valign="top"> <p>1.2.840.10008.5.1.4.1.1.7.4 </p> </td>     <td valign="top"> <p>Multi-frame True Color    Secondary Capture Image Storage </p> </td>     </tr> </table> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (196, 1, 0, '2009-11-24 10:53:16.542', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p> </p><H3>Description</H3><p>In the Evidence Documents profile, the Report Creator actor is grouped with an Image Display.    The Report Creator does not directly support any transactions in this profile, but does have    functionality required by the profile.</p><H3>Evaluation</H3><p>For <strong>Radiology Image Display/Report Creator</strong> actors, the system will display for    the Connectathon Monitor:</p><ul>     <li>its ability to Query/Retrieve evidence documents</li>     <li>its ability to transfer some contents of the retrieved document into the report it    creates</li> </ul><p>For <strong>Cardiology Image Display/Report Creator</strong> actors, the system will display    for the Connectathon Monitor:</p><ul>     <li>its ability to copy a user-selected Content Item and its subsidiary content tree from an SR     document to the clinical report created by the Report Creator. </li>     <li>If the clinical report created by the Report Creator is an SR, the copied content shall be     placed in an appropriate location in the target SR in accordance with its Template. </li>     <li>The Image Display / Report Creator shall copy the full subsidiary content tree, including any     IMAGE Content Items that are included through by-reference relationships. The Observation     Datetime of the copied data shall reflect the effective Observation Datetime of the Content Item     in the source SR document. </li>     <li>If the clinical report created by the Report Creator is not an SR (e.g., a PDF or a CDA), the     semantics of the copied data is to be appropriately transformed for the format of the report,     and does not necessarily require the full coded structures present in the SR. </li>     <li>A clinical report with structured coded content (i.e., an SR or a CDA) shall reference the     source SR document by SOP Instance UID. </li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (197, 1, 0, '2009-11-24 10:53:16.544', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test is run by Image Display systems which support  any of the cardiology options in the Evidence Documents profile:</p> <ul>     <ul>      <li>Cath Evidence option</li>      <li>Echo Evidence option</li>      <li>CTA/MRA Evidence option</li>      <li>Stress Test Evidence option </li>     </ul> </ul> <p>In order to run this test, Acquisition Modality actors  which support these options must complete the tests in which they store their  evidence documents (SRs) to Image Manager systems.  These tests are named  ED_Modality_PACS_*_Option.</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>In this test, the Image Display demonstrates its ability  to cardiology evidence documents (SRs) created by various Acquisition Modality  systems.</p><p>    The Image Display must be able to render and display all  Templates for the SOP Classes which it accepts.</p><p>    The Image Display system should drive this test.  The representative of the Image  Display system should identify an Acquisition  Modality System which supports the same cardiology option(s) as its system. Ask  the Modality vendor representative which Image Manager/Image Archive it has  stored its evidence documents (SRs) to.</p><p>    Note 1: The Acquisition Modality is a required actor in  this test.  It has  no transactions to perform, but will be  identified so that it can be given credit for interoperability with the Image  Display who renders its SRs.</p><p>    Note 2:  The Image  Manager system is identified as ''optional'' for this test because it is needed  to help out with Image Display system, allowing it to Query/Retrieve SRs from  its system.  Image Managers are not  required to complete  3 instances of this  test.</p><H3>Evaluation</H3><p>FOR ALL CARDIOLOGY OPTIONS (Cath Evidence, Echo Evidence,  CTA/MRA Evidence, Stress Test Evidence:</p><ul>     <li>The Connectathon Monitor should observe ''live''  the ability of the Image Display to query and retrieve SRs from an Image Manager  system (not the Central Archive).</li>     <li>The Connectathon Monitor should observe the  Image Display and its ability to interpret/render the Evidence Documents from  the Acquisition Modality. All SOP Classes and Templates which the Acquistion  Modality supports should be displayed.</li>     <li>The Connectathon Monitor should observe the  original report at the Acquisition Modality (the creator of the SR), the Image  Manager, or another Image Display and spot check the Image Display/Report  creator to verify the contents of the Structured Report are displayed <u>correctly</u> and <u>completely</u> </li>     <li>The Image Display must demonstrate its ability  to show abnormal measurements with ''readily visible emphasis'', (e.g., font,  bold, text or background color, specialized window area, etc.).</li> </ul><p>For the <strong>CTA/MRA Evidence </strong>option:</p><ul>     <li>The Image Display must demonstrate that it can  display a hyperlink to a referenced object for a content item with value type  of IMAGE.</li>     <li>The Image Display must demonstrate that it can  display a hyperlink to a referenced object with rendering of spatial  coordinates for a content item with value type of SCOORD.</li> </ul><p>For the <strong>Stress Test Evidence </strong>option:</p><ul>     <li>The Image Display must demonstrate that it can  display a hyperlink to a referenced object for a content item with value type  of IMAGE.</li>     <li>The Image Display must demonstrate that it can  display a hyperlink to a referenced object with rendering of temporal or spatial  coordinates for a content item with value type of TCOORD or SCOORD.</li>     <li>The Image Display actor must  demonstratea user control for rendering of ECG ST elevation or depression  measurements either in units of mV or in units of mm (based on conventional  scaling of 0.1 mV/mm). </li>     <li>For SR documents  encoded using Template x3300, the Image Display must render the contents of the  Template x3304 Stress Test Measurement Groups (subsidiary to a Template x3303  Stress Test Phase Data CONTAINER) <strong><u>in  a tabular format</u></strong>. </li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (198, 1, 0, '2009-11-24 10:53:16.547', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test is run by Acquisition Modalities which support  the CTA/MRA Evidence option in the Cardiology Evidence Documents profile.</p> <p>    This test is similar to ED_Creator_PACS_ CTA-MRA_Option.  It is a separate test because the Modality can also create the SOP Class  instances.&nbsp;&nbsp;&nbsp;&nbsp; </p> </p><H3>Description</H3><p>The ED_Modality_PACS_CTA/MRA_Option test exercises the  Evidence Documents profile transactions between a Modality and an Image  Manager/Image Archive. In the Evidence Documents profile, the Modality must  produce these documents (SR reports, not images) and store them on the Image  Manager. These documents must also be committed using the Storage Commitment  transaction.</p><p>    A Modality must produce documents from the following list  and an Image Manager must be able to store those documents for the CTA/MRA  Evidence Option:</p><ul>     <li>Enhanced SR</li> </ul><p>The CTA/MRA Evidence Option Templates include:</p><ul>     <li>3900 CT/MR Cardiovaascular Analysis Report</li> </ul><p>To aid in evaluation, it is in your best interest to begin  with an image or Modality Worklist where most of the information listed below  is known to be present, otherwise you will spend a significant amount of time  justifying the absence of the information.</p><H3>Evaluation</H3><p>On the <strong>Image Manager</strong>: The Connectathon Monitor should observe evidence from    the Image Manager that these documents were stored. This can be a display on the Image Manager, a    3rd party display or logs or database on the Image Manager if no display is readily    available.&nbsp; At the Image Manager, all of the following attributes of the Structured    Report object from the Modality shall be verified to match the original image or MWL    information:&nbsp;&nbsp; (see Rad TF-2: Appendix A, Table A.2-1 and section A.3):</p><p> Study Instance UID&nbsp; (0020, 000D)</p><p> Referenced Request Sequence&nbsp; (0040, A370)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Study Instance UID&nbsp; (0020, 000D)</p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced Study Sequence (0008, 1110)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Accession Number&nbsp; (0008, 0050)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure ID (0040, 1001)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure Description (0032, 1060)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure Code Sequence&nbsp; (0032, 1064)</p><p> Performed Procedure Code Sequence (0040, A372)</p><p> Referenced Study Component Sequence</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Class UID&nbsp; (0008, 1150)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Instance UID&nbsp; (0008, 1155)</p><p> Patient Name&nbsp;&nbsp; (0010, 0010)</p><p> Patient ID&nbsp;&nbsp; (0010, 0020)</p><p> Patient&rsquo;s Birth Date (0010, 0030)</p><p> Patient&rsquo;s Sex&nbsp; (0010, 0040)</p><p> Referring Physicians Name (0008, 0090)</p><p> Completion Flag (0040,A491)</p><p>The Connectathon Monitor should also observe logs in the Image Manager that demonstrate the    Storage Commitment transaction.&nbsp; All of the following attributes shall be verified in    the Storage Commit message from the Modality:</p><p> Referenced SOP Sequence (0008, 1199)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Reference SOP Class (0008, 1150)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Instance UID (0008, 1155)</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (199, 1, 0, '2009-11-24 10:53:16.549', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test is run by Acquisition Modalities which support the Cath Evidence option in the    Cardiology Evidence Documents profile.</p> <p> This test is similar to ED_Creator_PACS_Cath_Option. It is a separate test because the    Acquisition Modality can also create the SOP Class instances.&nbsp;&nbsp; </p> </p><H3>Description</H3><p>The ED_Modality_PACS_ Cath_Option test exercises the Evidence Document profile transactions    between a Modality and an Image Manager/Image Archive. In the Evidence Documents profile, the    Modality must produce these documents (SR reports, not images) and store them on the Image    Manager. These documents must also be committed using the Storage Commitment transaction.</p><p> A Modality must produce documents from the following list and an Image Manager must be able to    store the SOP Classes for the Cath Option:</p><ul>     <li>Enhanced SR</li>     <li>Comprehensive SR</li>     <li>Procedure Log SR</li> </ul><p>The Cath Option Templates include:</p><ul>     <li>3001 Procedure Log</li>     <li>3202 Ventricular Analysis</li>     <li>3213 Quantitative Arterial Analysis</li>     <li>3250 Intravascular Ultrasound</li>     <li>3500 Hemodynamics</li> </ul><p>All supported SOP Classes and all supported Templates within those SOP Classes must be tested    and verified.&nbsp;&nbsp; </p><p>To aide in evaluation, it is in your best interest to begin with an image or Modality Worklist    where most of the information listed in the Evaluation section is known to be present, otherwise    you will spend a significant amount of time justifying the absence of the information.</p><H3>Evaluation</H3><p>On the <strong>Image Manager</strong>: The Connectathon Monitor should observe evidence from    the Image Manager that these documents were stored. This can be a display on the Image Manager, a    3rd party display or logs or database on the Image Manager if no display is readily    available.&nbsp; At the Image Manager, all of the following attributes of the Structured    Report object from the Modality shall be verified to match the original image or MWL    information:&nbsp;&nbsp; (see Rad TF-2: Appendix A, Table A.2-1 and section A.3):</p><p> Study Instance UID&nbsp; (0020, 000D)</p><p> Referenced Request Sequence&nbsp; (0040, A370)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Study Instance UID&nbsp; (0020, 000D)</p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced Study Sequence (0008, 1110)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Accession Number&nbsp; (0008, 0050)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure ID (0040, 1001)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure Description (0032, 1060)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure Code Sequence&nbsp; (0032, 1064)</p><p> Performed Procedure Code Sequence (0040, A372)</p><p> Referenced Study Component Sequence</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Class UID&nbsp; (0008, 1150)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Instance UID&nbsp; (0008, 1155)</p><p> Patient Name&nbsp;&nbsp; (0010, 0010)</p><p> Patient ID&nbsp;&nbsp; (0010, 0020)</p><p> Patient&rsquo;s Birth Date (0010, 0030)</p><p> Patient&rsquo;s Sex&nbsp; (0010, 0040)</p><p> Referring Physicians Name (0008, 0090)</p><p> Completion Flag (0040,A491)</p><p>The Connectathon Monitor should also observe logs in the Image Manager that demonstrate the    Storage Commitment transaction.&nbsp; All of the following attributes shall be verified in    the Storage Commit message from the Modality:</p><p> Referenced SOP Sequence (0008, 1199)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Reference SOP Class (0008, 1150)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Instance UID (0008, 1155)</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (200, 1, 0, '2009-11-24 10:53:16.551', 'epoiseau', '<H3>Special Instructions</H3>  <p> <p>This test is similar to ED_Creator_PACS_Display. It is a separate test because the Acquisition    Modality can also create the Evidence Documents. </p> <p> <strong>Modality</strong> and <strong>Image Display</strong> actors which support any of these    Cardiology options should run the test(s) indicated in the following table, instead of this one:</p> <table border="1" cellspacing="0" cellpadding="0">     <tr>      <td valign="top">       <p align="center">        <strong>ED Cardiology Option</strong>       </p>      </td>     <td valign="top">       <p align="center">        <strong>Required Test</strong>       </p>      </td>     </tr>     <tr>      <td valign="top">       <p>Cath Evidence Option</p>      </td>     <td valign="top">       <p>ED_Modalilty_PACS_Display_Cath_Option</p>      </td>     </tr>     <tr>      <td valign="top">       <p>Echo Evidence Option</p>      </td>     <td valign="top">       <p>ED_Modalilty_PACS_Display_Echo_Option</p>      </td>     </tr>     <tr>      <td valign="top">       <p>Stress Test Evidence Option</p>      </td>     <td valign="top">       <p>ED_Modalilty_PACS_Display_Stress_Option</p>      </td>     </tr>     <tr>      <td valign="top">       <p>CTA/MRA Evidence Option</p>      </td>     <td valign="top">       <p>ED_Modalilty_PACS_Display_CTA-MRA_Option</p>      </td>     </tr> </table> </p>  <H3>Description</H3>  <p>The ED_Modality_PACS test exercises the Evidence Documents profile transactions between a    Modality and an Image Manager/Image Archive. In the Evidence Documents profile, the Modality must    produce these documents (SR reports, not images) and store them on the Image Manager. These    documents must also be committed using the Storage Commitment transaction.</p>  <p>A Modality must produce documents from the following list and an Image Manager must be able to    store those documents:</p>  <ul>     <li>Mammography CAD SR</li>     <li>Basic Text SR</li>     <li>Enhanced SR</li>     <li>Comprehensive SR</li>     <li>Chest CAD SR</li> </ul>  <p>All supported SOP Classes and all supported Templates within those SOP Classes must be tested    and verified. </p>  <p>To aid in evaluation, it is in your best interest to begin with an image or Modality Worklist    where most of the information listed in the Evaluation section is known to be present, otherwise    you will spend a significant amount of time justifying the absence of the information.</p>  <H3>Evaluation</H3>  <strong>Image Manager:</strong> <p>The Connectathon Monitor should observe evidence from the Image Manager that these documents    were stored. This can be a display on the Image Manager, a 3rd party display or logs or database    on the Image Manager if no display is readily available. </p> <p>At the Image Manager, all of the following attributes of the Structured Report object from the    Modality shall be verified to match the original image or MWL information: (see Rad TF-2:    Appendix A, Table A.2-1 and section A.3):</p><ul>     <li>Study Instance UID (0020, 000D)</li>     <li>Referenced Request Sequence (0040, A370) <ul>       <li>>Study Instance UID (0020, 000D)</li>       <li>>Referenced Study Sequence (0008, 1110)</li>       <li>>Accession Number (0008, 0050)</li>       <li>>Requested Procedure ID (0040, 1001)</li>       <li>>Requested Procedure Description (0032, 1060)</li>       <li>>Requested Procedure Code Sequence (0032, 1064)</li>      </ul>     </li>     <li>Performed Procedure Code Sequence (0040, A372)</li>     <li>Referenced Study Component Sequence<ul>       <li> >Referenced SOP Class UID (0008, 1150)</li>       <li> >Referenced SOP Instance UID (0008, 1155)</li>      </ul>     </li>     <li>Patient Name (0010, 0010)</li>     <li>Patient ID (0010, 0020)</li>     <li>Patient''s Birth Date (0010, 0030)</li>     <li>Patient''s Sex (0010, 0040)</li>     <li>Referring Physicians Name (0008, 0090)</li>     <li>Completion Flag (0040,A491)</li> </ul>  <p>The Connectathon Monitor should also observe logs in the Image Manager that demonstrate the    Storage Commitment transaction. All of the following attributes shall be verified in the Storage    Commit message from the Modality:</p>  <ul>     <li>Referenced SOP Sequence (0008, 1199)<ul>       <li> >Reference SOP Class (0008, 1150)</li>       <li>>Referenced SOP Instance UID (0008, 1155)</li>      </ul>     </li> </ul> <p>On the <strong>Image Display:</strong> The Connectathon monitor should observe the Image    Display and its ability to interpret/render the Evidence Documents. The Connectathon monitor    should observe the original report at the Image Manger, the Acqusition Modality, the Evidence    Creator, or another Image Display and spot check the Image Display/Report creator to verify the    contents of the Structured Report are displayed correctly and completely.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (201, 1, 0, '2009-11-24 10:53:16.554', 'epoiseau', '<H3>Special Instructions</H3> <p>This test is similar to ED_Creator_PACS_Cath_Option. It is a separate test because the Acquisition Modality can also create the SOP Class instances.     This test is only used if the modality supports the Cardiology options. </p> <H3>Description</H3> <p> The ED_Modality_PACS_Display_Cath_Option test exercises the Evidence Document profile transactions between a Modality and an Image Manager/Image Archive. In the Evidence Documents profile, the Modality must produce these documents (SR reports, not images) and store them on the Image Manager. These documents must also be committed using the Storage Commitment transaction. A Modality must produce documents from the following list and an Image Manager must be able to store the SOP Classes for the<b> Cath Option</b>: </p> <pre> ''	Enhanced SR ''	Comprehensive SR ''	Procedure Log SR </pre> <p>The Cath Option Templates include: </p> <pre> ''	3001 Procedure Log ''	3202 Ventricular Analysis ''	3213 Quantitative Arterial Analysis ''	3250 Intravascular Ultrasound ''	3500 Hemodynamics </pre> <p> All supported SOP Classes and all supported Templates within those SOP Classes must be tested and verified.    The Image Display must be able to render and display all Templates for the SOP Classes which it accepts. </p> <p> To aid in evaluation, it is in your best interest to begin with an image or Modality Worklist where most of the information listed below is known to be present, otherwise you will spend a significant amount of time justifying the absence of the information. </p> <p> The Acquisition Modality can perform a SWF Unscheduled Case or an MPPS Simple Case to generate data. The MESA RIS Mall is available for MWL functions or may begin with a specific image.  Use the patient naming convention of:  ED-CATH-COMPANYMODALITY_n^COMPANYPACS, where ''n'' is an incrementing number for how many SOP Classes and templates the Modality is capable of generating.   For example, if it were a Philips modality and a Sectra PACS the patient name might be: ''ED-PhilipsIU33_1^SectraPACS'' <H3>Evaluation</H3> In the Kudu chat window, record all SOP Classes and all Templates which were tested, including all Patient Names, Patient IDs, and Study Instance UIDs for locating information at a later time for verification. <p> The Connectathon Monitor should observe evidence from the <b>Image Manager</b> that these documents were stored. This can be a display on the Image Manager, a 3rd party display or logs or database on the Image Manager if no display is readily available.  At the Image Manager, all of the following attributes of the Structured Report object from the Modality shall be verified to match the original image or MWL information:   (see Rad TF Vol2: Append A, Table A.2-1 and section A.3):  </p> <pre> Study Instance UID  (0020, 000D) Referenced Request Sequence  (0040, A370) 	>Study Instance UID  (0020, 000D) 	>Referenced Study Sequence (0008, 1110) 	>Accession Number  (0008, 0050) 	>Requested Procedure ID (0040, 1001) 	>Requested Procedure Description (0032, 1060) 	>Requested Procedure Code Sequence  (0032, 1064) Performed Procedure Code Sequence (0040, A372) Referenced Study Component Sequence  	>Referenced SOP Class UID  (0008, 1150) 	>Referenced SOP Instance UID  (0008, 1155) Patient Name   (0010, 0010) Patient ID   (0010, 0020) Patient''s Birth Date (0010, 0030) Patient''s Sex  (0010, 0040) Referring Physicians Name (0008, 0090) Completion Flag (0040,A491) </pre> <p> The Connectathon Monitor should also observe logs in the <b>Image Manager</b> that demonstrate the Storage Commitment transaction.  All of the following attributes shall be verified in the Storage Commit message from the Modality: </p> <pre> Retrieve AE Title (0008, 0054) Referenced SOP Sequence (0008, 1199) 	>Reference SOP Class (0008, 1150) 	>Referenced SOP Instance UID (0008, 1155) </pre> <p> The Connectathon Monitor should observe the <b>Image Display</b> and its ability to interpret/render the Evidence Documents. The Connectathon monitor should observe the original report at the Image Manger, the Acqusition Modality, the Evidence Creator, or another Image Display and spot check the Image Display/Report creator to verify the contents of the Structured Report are displayed correctly and completely.    </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (202, 1, 0, '2009-11-24 10:53:16.557', 'epoiseau', '<H3>Special Instructions</H3> <p>This test is similar to ED_Creator_PACS_Display_Echo_Option. It is a separate test because the Acquisition Modality can also create the SOP Class instances.     This test is only used if the modality supports the Cardiology options. </p>  <H3>Description</H3> <p> The ED_Modality_PACS_Display_Echo_Option test exercises the Evidence Document profile transactions between a Modality and an Image Manager/Image Archive. In the Evidence Documents profile, the Modality must produce these documents (SR reports, not images) and store them on the Image Manager. These documents must also be committed using the Storage Commitment transaction. A Modality must produce documents from the following list and an Image Manager must be able to store those documents for the Echo Option: </p> <pre> ''	Enhanced SR ''	Comprehensive SR  The Echo Option Templates include: ''	5100 Vascular Ultrasound ''	5200 Echocardiography </pre> <p> All supported SOP Classes and all supported Templates within those SOP Classes must be tested and verified.    </p> <p> The Image Display must be able to render and interpret all Templates for the SOP Classes which it accepts. To aid in evaluation, it is in your best interest to begin with an image or Modality Worklist where most of the information listed below is known to be present, otherwise you will spend a significant amount of time justifying the absence of the information. </p> <p> The Acquisition Modality can perform a SWF Unscheduled Case or an MPPS Simple Case to generate data. The MESA RIS Mall is available for MWL functions or may begin with a specific image.  Use the patient naming convention of:  ED-COMPANYMODALITY_n^COMPANYPACS, where ''n'' is an incrementing number for how many SOP Classes and templates the Modality is capable of generating.   For example, if it were a Philips modality and a Sectra PACS the patient name might be: ''ED-PhilipsIU33_1^SectraPACS''. </p> <H3>Evaluation </H3> <p> In the Kudu chat window, record all SOP Classes and all Templates which were tested, including all Patient Names, Patient IDs, and Study Instance UIDs for locating information at a later time for verification. </p> <p> The Connectathon Monitor should observe evidence from the <b>Image Manager</b> that these documents were stored. This can be a display on the Image Manager, a 3rd party display or logs or database on the Image Manager if no display is readily available.  At the Image Manager, all of the following attributes of the Structured Report object from the Modality shall be verified to match the original image or MWL information:   (see Rad TF Vol2: Append A, Table A.2-1 and section A.3):  </p> <pre> Study Instance UID  (0020, 000D) Referenced Request Sequence  (0040, A370) 	>Study Instance UID  (0020, 000D) 	>Referenced Study Sequence (0008, 1110) 	>Accession Number  (0008, 0050) 	>Requested Procedure ID (0040, 1001) 	>Requested Procedure Description (0032, 1060) 	>Requested Procedure Code Sequence  (0032, 1064) Performed Procedure Code Sequence (0040, A372) Referenced Study Component Sequence  	>Referenced SOP Class UID  (0008, 1150) 	>Referenced SOP Instance UID  (0008, 1155) Patient Name   (0010, 0010) Patient ID   (0010, 0020) Patient''s Birth Date (0010, 0030) Patient''s Sex  (0010, 0040) Referring Physicians Name (0008, 0090) Completion Flag (0040,A491) </pre> <p> The Connectathon Monitor should also observe logs in the <b>Image Manager</b> that demonstrate the Storage Commitment transaction.  All of the following attributes shall be verified in the Storage Commit message from the Modality:  </p> <pre> Retrieve AE Title (0008, 0054) Referenced SOP Sequence (0008, 1199) 	>Reference SOP Class (0008, 1150) 	>Referenced SOP Instance UID (0008, 1155) </pre> <p> The Connectathon Monitor should observe the <b>Image Display </b>and its ability to interpret/render the Evidence Documents. The Connectathon Monitor should observe the original report at the Image Manger, the Acqusition Modality, the Evidence Creator, or another Image Display and spot check the Image Display/Report creator to verify the contents of the Structured Report are displayed correctly and completely.    </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (203, 1, 0, '2009-11-24 10:53:16.559', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test is run by Acquisition Modalities which support the Echo Evidence option in the    Cardiology Evidence Documents profile.</p> <p> This test is similar to ED_Creator_PACS _Echo_Option. It is a separate test because the    Acquisition Modality can also create the SOP Class    instances.&nbsp;&nbsp;&nbsp;&nbsp; </p> </p><H3>Description</H3><p>The ED_Modality_PACS_ Echo_Option test exercises the Evidence Document profile transactions    between a Modality and an Image Manager/Image Archive. In the Evidence Documents profile, the    Modality must produce these documents (SR reports, not images) and store them on the Image    Manager. These documents must also be committed using the Storage Commitment transaction.</p><p> A Modality must produce documents from the following list and an Image Manager must be able to    store those documents for the Echo Option:</p><ul>     <li>Enhanced SR</li>     <li>Comprehensive SR</li> </ul><p>The Echo Option Templates include:</p><ul>     <li>5100 Vascular Ultrasound</li>     <li>5200 Echocardiography</li> </ul><p>All supported SOP Classes and all supported Templates within those SOP Classes must be tested    and verified.&nbsp;&nbsp; </p><H3>Evaluation</H3><p>On the <strong>Image Manager</strong>: The Connectathon Monitor should observe evidence from    the Image Manager that these documents were stored. This can be a display on the Image Manager, a    3rd party display or logs or database on the Image Manager if no display is readily    available.&nbsp; At the Image Manager, all of the following attributes of the Structured    Report object from the Modality shall be verified to match the original image or MWL    information:&nbsp;&nbsp; (see Rad TF-2: Appendix A, Table A.2-1 and section A.3):</p><p> Study Instance UID&nbsp; (0020, 000D)</p><p> Referenced Request Sequence&nbsp; (0040, A370)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Study Instance UID&nbsp; (0020, 000D)</p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced Study Sequence (0008, 1110)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Accession Number&nbsp; (0008, 0050)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure ID (0040, 1001)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure Description (0032, 1060)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure Code Sequence&nbsp; (0032, 1064)</p><p> Performed Procedure Code Sequence (0040, A372)</p><p> Referenced Study Component Sequence</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Class UID&nbsp; (0008, 1150)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Instance UID&nbsp; (0008, 1155)</p><p> Patient Name&nbsp;&nbsp; (0010, 0010)</p><p> Patient ID&nbsp;&nbsp; (0010, 0020)</p><p> Patient&rsquo;s Birth Date (0010, 0030)</p><p> Patient&rsquo;s Sex&nbsp; (0010, 0040)</p><p> Referring Physicians Name (0008, 0090)</p><p> Completion Flag (0040,A491)</p><p>The Connectathon Monitor should also observe logs in the Image Manager that demonstrate the    Storage Commitment transaction.&nbsp; All of the following attributes shall be verified in    the Storage Commit message from the Modality:</p><p> Referenced SOP Sequence (0008, 1199)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Reference SOP Class (0008, 1150)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Instance UID (0008, 1155)</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (204, 1, 0, '2009-11-24 10:53:16.561', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test is run by Acquisition Modalities which support  the Stress Test Evidence option in the Cardiology Evidence Documents profile.</p> <p>    This test is similar to ED_Creator_PACS_Stress  Test_Option. It is a separate test because the Modality can also create the SOP  Class instances.&nbsp;&nbsp;&nbsp;&nbsp; </p> </p><H3>Description</H3><p>The ED_Modality_PACS_Stress_Test_Option test exercises the  Evidence Documents profile transactions between a Modality and an Image  Manager/Image Archive. In the Evidence Documents profile, the Modality must  produce these documents (SR reports, not images) and store them on the Image  Manager. These documents must also be committed using the Storage Commitment  transaction.</p><p>    A Modality must produce documents from the following list  and an Image Manager must be able to store those documents for the CTA/MRA  Evidence Option:</p><ul>     <li>Enhanced SR</li> </ul><p>The CTA/MRA Evidence Option Templates include:</p><ul>     <li>x3300 Stress Testing Report &ndash; DICOM Supplement  128</li> </ul><p>To aid in evaluation, it is in your best interest to begin  with an image or Modality Worklist where most of the information listed below  is known to be present, otherwise you will spend a significant amount of time  justifying the absence of the information.</p><H3>Evaluation</H3><p>On the <strong>Image Manager</strong>: The Connectathon Monitor should observe evidence from    the Image Manager that these documents were stored. This can be a display on the Image Manager, a    3rd party display or logs or database on the Image Manager if no display is readily    available.&nbsp; At the Image Manager, all of the following attributes of the Structured    Report object from the Modality shall be verified to match the original image or MWL    information:&nbsp;&nbsp; (see Rad TF-2: Appendix A, Table A.2-1 and section A.3):</p><p> Study Instance UID&nbsp; (0020, 000D)</p><p> Referenced Request Sequence&nbsp; (0040, A370)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Study Instance UID&nbsp; (0020, 000D)</p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced Study Sequence (0008, 1110)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Accession Number&nbsp; (0008, 0050)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure ID (0040, 1001)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure Description (0032, 1060)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Requested Procedure Code Sequence&nbsp; (0032, 1064)</p><p> Performed Procedure Code Sequence (0040, A372)</p><p> Referenced Study Component Sequence</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Class UID&nbsp; (0008, 1150)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Instance UID&nbsp; (0008, 1155)</p><p> Patient Name&nbsp;&nbsp; (0010, 0010)</p><p> Patient ID&nbsp;&nbsp; (0010, 0020)</p><p> Patient&rsquo;s Birth Date (0010, 0030)</p><p> Patient&rsquo;s Sex&nbsp; (0010, 0040)</p><p> Referring Physicians Name (0008, 0090)</p><p> Completion Flag (0040,A491)</p><p>The Connectathon Monitor should also observe logs in the Image Manager that demonstrate the    Storage Commitment transaction.&nbsp; All of the following attributes shall be verified in    the Storage Commit message from the Modality:</p><p> Referenced SOP Sequence (0008, 1199)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Reference SOP Class (0008, 1150)</p><p>    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &gt;Referenced SOP Instance UID (0008, 1155)</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (205, 1, 0, '2009-11-24 10:53:16.565', 'epoiseau', '<H3>Special Instructions</H3><p>
 <p>None</p>
 
 <H3>Description</H3>
 <p>The EUA_CCOWSession test demonstrates the combination of CCOW communication with Kerberos authentication.
 The User Context Participant performs CCOW operations with the Context Manager. The Context Manager communicates
 with at least one User Context Participant which can also authenticate the user with Kerberos.</p>
 
 <H3>Evaluation</H3>
 
 
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (206, 1, 0, '2009-11-24 10:53:16.566', 'epoiseau', '<H3>Special Instructions</H3><p>
 <p>None</p>
 </p><H3>Description</H3>
 
 <p>The EUA_KerberizedCommunication test is designed to demonstrate communication between two systems using Kerberos authentication.
 The system that initiates the communication first authenticates the user with Kerberos. Then, all communication initiated by that system with
 the server application shall be secured by Kerberos.
 </p>.
 
 <p>The Client Authentication Agent will login using the baxa account. All communication will occur with that user.</p>
 
 <H3>Evaluation</H3>
 <p>The two kerberized applications will need to demonstrate evidence that the communication is protected by Kerberos and not
 just working without authentication.
 </p>
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (207, 1, 0, '2009-11-24 10:53:16.569', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p> </p><H3>Description</H3><p>The EUA_KerberosAuthentication test demonstrates user authentication using Kerberos. The Client Authentication Agent will attempt to login with different usernames.</p><H3>Evaluation</H3><p>Of the steps below, the first authentication request is expected to succeed. The second request should fail (unregistered account). The third request should also fail (cannot reach Authentication Server).</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (208, 1, 0, '2009-11-24 10:53:16.57', 'epoiseau', '<H3>Special Instructions</H3><p>
 <p>None</p>
 </p><H3>Description</H3><p>The purpose of the EUA_Load test is for each Kerberos Authentication Server actor to load account information to identify valid users. We use a specific set of account names.</p><p>The account information is:</p><ol>
     
 <li>weaver, Timothy Weaver</li>
 
 <li>roszek, Jeannette Roszek</li>
 
 <li>baxa, Timothy Baxa</li>
 
 <li>danke, Loren Danke</li>
 
 <li>liu, Cheng Liu</li>
 
 <li>lopez, Gabriella Lopez</li>
 
 </ol>
 
 <p>Set the password of the weaver account to weaver. Other passwords will be specified by a monitor or project manager at the time
 of testing to make sure that the clients are using the accounts managed by the Authentication Server and not using local passwords.</p>
 
 <H3>Validation</H3>
 <p>For validation, the Project Manager will take the word of the Kerberos Authentication Server. No further tests will work without this step.</p>
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (209, 1, 0, '2009-11-24 10:53:16.573', 'epoiseau', '<p>Evidence Creators/Modalities create Evidence Documents. These are then passed to an Image Manager and rendered by an Image Display ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (210, 1, 0, '2009-11-24 10:53:16.575', 'epoiseau', '<h3>You do not have to run this test</h3>  <p>This is an optional test where MIR staff members will validate one DICOM object using a beta version of the Gazelle tools tied to the David Clunie DICOM3tools software.</p>  <p>If you have loaded a sample DICOM object on the Central Archive, we will run this test for you. If you have not loaded your sample, well, you should have done that.</p>  <p>An MIR staff member will grab one of your samples from the Central Archive, validate that sample using the Gazelle software, and drop the output in the chat window for your review. You do not need to do anything with this during the Connectathon. Our goal is to produce a summary statistic that indicates overall success/failure for the Connectathon. We will not report individual results. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (211, 1, 0, '2009-11-24 10:53:16.577', 'epoiseau', '<h3>You do not have to run this test</h3>  <p>This is an optional test where MIR staff members will validate one DICOM object using a beta version of the Gazelle tools tied to the DVTK software.</p>  <p>If you have loaded a sample DICOM object on the Central Archive, we will run this test for you. If you have not loaded your sample, well, you should have done that.</p>  <p>An MIR staff member will grab one of your samples from the Central Archive, validate that sample using the Gazelle software, and drop the output in the chat window for your review. You do not need to do anything with this during the Connectathon. Our goal is to produce a summary statistic that indicates overall success/failure for the Connectathon. We will not report individual results. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (212, 1, 0, '2009-11-24 10:53:16.579', 'epoiseau', '<H3>Special Instructions</H3><p></p><H3>Description</H3><p>ADT system broadcasts ADT messages to Order Fillers (only). Observer will ask Order Fillers to    show results of ADT messages</p><H3>Evaluation</H3><p>On the <strong>Order Filler</strong>, the Connectathon monitor will verify:</p><ul>     <li>HL7 messages (see log files) were received from ADT</li>     <li>The patient COMPANY^George is registered in the Order Placer database.</li>     <li>The patient COMPANY^Monday is no longer registered (or inactive or whatever is appropriate     for your system).</li>     <li>The patient Michael is registered in the Order Placer database.</li>     <li>The patient Mike is no longer registered (or inactive).</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (213, 1, 0, '2009-11-24 10:53:16.581', 'epoiseau', '<H3>Special Instructions</H3><p></p><H3>Description</H3><p>ADT system broadcasts ADT messages to Order Placers (only). Observer will ask Order Placers to    show results of ADT messages</p><H3>Evaluation</H3><p>On the <strong>Order Placer</strong>, the Connectathon monitor will verify:</p><ul>     <li>HL7 messages (see log files) were received from ADT</li>     <li>The patient COMPANY^George is registered in the Order Placer database.</li>     <li>The patient COMPANY^Monday is no longer registered (or inactive or whatever is appropriate     for your system).</li>     <li>The patient Michael is registered in the Order Placer database.</li>     <li>The patient Mike is no longer registered (or inactive).</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (214, 1, 0, '2009-11-24 10:53:16.583', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Modalities which support this option run one instance of this test.</p> </p><H3>Description</H3><p>The Billing and Material Management option allows an Acquisition Modality to communicate that information to an Order Filler (RAD TF-2: 4.7.4.1.2.3)..</p><H3>Evaluation</H3><p>The <strong>Order Filler</strong> shall demonstrate that the Billing and  Material content was received. This can be done via the User Interface or  database, or by capturing a copy of the MPPS message from the Modality. If a  message is captured, the evaluator will check the contents of: </p><ul type="disc">     <li>(0040,0320)       Billing Procedure Step Sequence </li>     <li>(0040,0321)       Film Consumption Sequence </li>     <li>(0040,0424)       Billing Supplies and Devices Sequence </li> </ul><p>For reference, the following is an extract from RAD TF-2: 4.7.4.1.2.3.:<br>    A modality that supports the BILLING AND MATERIAL  MANAGEMENT option shall be able to provide content within at least one of the  Billing Procedure Step Sequence, Film Consumption Sequence and Billing Supplies  and Devices Sequence. </p><p>&nbsp;</p><p align="center"> <strong>Table 4.7-2 Billing and Material Management Code Module  Attributes</strong> </p><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td width="213" valign="top"> <br>      Attribute name </td>     <td width="94" valign="top"> <p>Tag</p> </td>     <td width="312" valign="top"> <p>Attribute Description</p> </td>     </tr>     <tr>      <td width="213" valign="top"> <p>Billing Procedure Step Sequence</p> </td>     <td width="94" valign="top"> <p>(0040,0320)</p> </td>     <td width="312" valign="top"> <p>Contains billing codes for the Procedure Type performed    within the Procedure Step. The sequence may have zero or more Items <br>      See note IHE-1, IHE-2</p> </td>     </tr>     <tr>      <td width="213" valign="top"> <p>&gt; Code Value</p> </td>     <td width="94" valign="top"> <p>(0008,0100)</p> </td>     <td width="312" valign="top"> <p>&nbsp;</p> </td>     </tr>     <tr>      <td width="213" valign="top"> <p>&gt; Coding Scheme Designator</p> </td>     <td width="94" valign="top"> <p>(0008,0102)</p> </td>     <td width="312" valign="top"> <p>&nbsp;</p> </td>     </tr>     <tr>      <td width="213" valign="top"> <p>&gt; Code Meaning</p> </td>     <td width="94" valign="top"> <p>(0008,0104)</p> </td>     <td width="312" valign="top"> <p>&nbsp;</p> </td>     </tr>     <tr>      <td width="213" valign="top"> <p>Film Consumption Sequence</p> </td>     <td width="94" valign="top"> <p>(0040,0321)</p> </td>     <td width="312" valign="top"> <p>Information about the film consumption for this Performed    Procedure Step. The sequence may have zero or more Items.<br>      Note: This is only for films printed from this device.<br>      See note IHE-3</p> </td>     </tr>     <tr>      <td width="213" valign="top"> <p>&gt;Number of Films</p> </td>     <td width="94" valign="top"> <p>(2100,0170) </p> </td>     <td width="312" valign="top"> <p>Number of films actually printed.</p> </td>     </tr>     <tr>      <td width="213" valign="top"> <p>&gt;Medium Type</p> </td>     <td width="94" valign="top"> <p>(2000,0030)</p> </td>     <td width="312" valign="top"> <p>Type(s) of medium on which images were printed.</p> </td>     </tr>     <tr>      <td width="213" valign="top"> <p>&gt;Film Size ID</p> </td>     <td width="94" valign="top"> <p>(2010,0050)</p> </td>     <td width="312" valign="top"> <p>Size(s) of film on which images were printed.</p> </td>     </tr>     <tr>      <td width="213" valign="top"> <p>Billing Supplies and Devices Sequence</p> </td>     <td width="94" valign="top"> <p>(0040,0324)</p> </td>     <td width="312" valign="top"> <p>Contains billing codes for chemicals, supplies and    devices for billing used in the Performed Procedure Step. The sequence may    have one or more Items.</p> </td>     </tr>     <tr>      <td width="213" valign="top"> <p>&gt;Billing Item Sequence</p> </td>     <td width="94" valign="top"> <p>(0040,0296)</p> </td>     <td width="312" valign="top"> <p>Codes values of chemicals, supplies or devices required    for billing. The sequence may have zero or one Items. See note IHE-4</p> </td>     </tr>     <tr>      <td width="213" valign="top"> <p>&gt;&gt; Code Value</p> </td>     <td width="94" valign="top"> <p>(0008,0100)</p> </td>     <td width="312" valign="top"> <p>&nbsp;</p> </td>     </tr>     <tr>      <td width="213" valign="top"> <p>&gt;&gt; Coding Scheme Designator</p> </td>     <td width="94" valign="top"> <p>(0008,0102)</p> </td>     <td width="312" valign="top"> <p>&nbsp;</p> </td>     </tr>     <tr>      <td width="213" valign="top"> <p>&gt;&gt; Code Meaning</p> </td>     <td width="94" valign="top"> <p>(0008,0104)</p> </td>     <td width="312" valign="top"> <p>&nbsp;</p> </td>     </tr>     <tr>      <td width="213" valign="top"> <p>&gt;Quantity Sequence</p> </td>     <td width="94" valign="top"> <p>(0040,0293)</p> </td>     <td width="312" valign="top"> <p>Sequence containing the quantity of used chemicals or    devices. The sequence may have zero or one Items.</p> </td>     </tr>     <tr>      <td width="213" valign="top"> <p>&gt;&gt;Quantity</p> </td>     <td width="94" valign="top"> <p>(0040,0294)</p> </td>     <td width="312" valign="top"> <p>Numerical quantity value.</p> </td>     </tr>     <tr>      <td width="213" valign="top"> <p>&gt;&gt;Measuring Units Sequence</p> </td>     <td width="94" valign="top"> <p>(0040,0295)</p> </td>     <td width="312" valign="top"> <p>Unit of measurement. The sequence may have zero or one    Items. Baseline CID 82</p> </td>     </tr>     <tr>      <td width="213" valign="top"> <p>&gt;&gt;&gt; Code Value</p> </td>     <td width="94" valign="top"> <p>(0008,0100)</p> </td>     <td width="312" valign="top"> <p>&nbsp;</p> </td>     </tr>     <tr>      <td width="213" valign="top"> <p>&gt;&gt;&gt; Coding Scheme Designator</p> </td>     <td width="94" valign="top"> <p>(0008,0102)</p> </td>     <td width="312" valign="top"> <p>&nbsp;</p> </td>     </tr>     <tr>      <td width="213" valign="top"> <p>&gt;&gt;&gt; Code Meaning</p> </td>     <td width="94" valign="top"> <p>(0008,0104)</p> </td>     <td width="312" valign="top"> <p>&nbsp;</p> </td>     </tr> </table><p>(IHE-1)&nbsp;&nbsp;&nbsp;&nbsp; Billing Procedure Step Sequence Attribute shall be  present if Modality supports the BILLING AND MATERIAL MANAGEMENT option.  It may be sent zero-length if one of Film Consumption Sequence or Billing  Supplies and Devices Sequence is also populated.<br>    &nbsp;(IHE-2)&nbsp;&nbsp;&nbsp; A Modality  Billing Code Table shall be configured on the Acquisition Modality. This table  shall be synchronized with the Department System Scheduler/Order Filler. The  codes provided by the Acquisition Modality might not be the same as the code  the Department System Scheduler/Order Filler is required to use when posting  Charges to the Charge Processor.<br>    (IHE-3)&nbsp;&nbsp;&nbsp;&nbsp; Film  Consumption Sequence shall be present if films have been printed during this  Performed Procedure Step. Information provided in Film Consumption Sequence may not be sufficient to properly calculate  charges. For example, to take into account quality and sensitivity of film,  Department System Scheduler/Order Filler shall obtain additional information  before calculating and posting charges to the Charge Processor.<br>    (IHE-4)&nbsp;&nbsp;&nbsp;&nbsp; Different coding schemes may be used for codes of  Billing Items, for example, DCMR Context ID 12 - Radiographic Contrast Agent  may be used to record quantity of contrast used.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (215, 1, 0, '2009-11-24 10:53:16.586', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Use the RIS Mall to register a patient and place an order for this patient. If you have an available ADT and/or Order Placer, please use them. They will not appear in the Kudu tool, but can participate in the testing process.</p> <p>If a DSS/OF system is not available, please run test EyeCare_Modality_IM_Interface instead.</p> </p><H3>Description</H3><p>The Order Filler, Modality and PACS test their interfaces  for these actions</p><ul>     <li>HL7 scheduling ORM from Order Filler to Image  Manager</li>     <li>Simple MPPS Case with billable codes</li>     <li>MPPS Abandon Case</li>     <li>Storage of Images</li> </ul><H3>Evaluation</H3><p>Connectathon Monitor will ask the <b>Image Manager</b> to show  evidence that:</p><ul>     <li>It received a Procedure Scheduled ORM from the  Order Filler.</li>     <li>The images for patient W-MOD^IM are successfully  stored</li>     <li>The PPS N-CREATE message contains codes for  billing in one or more of the Billing Procedure Step Sequence (0040,0320).</li>     <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>     <li>It received MPPS Discontinued forwarded from the  Image Manager in the Abandoned case (forwarded by the Image Manager).</li> </ul><p>Connectathon Monitor will ask the <b>Modality</b> to show  evidence that it supports both Patient-Based and Broad MWL queries.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (216, 1, 0, '2009-11-24 10:53:16.588', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Use the RIS MALL as an ADT and OP simulator to register the patient and provide an order number during this test.</p> </p><H3>Description</H3><p>This test verifies the case where the order is placed at the  DSS/OF 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 Case E4 (EYECARE TF-1:  3.6.4). <br>     <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 type="disc">     <li>[EYECARE-1]       Modality Worklist </li>     <li>[EYECARE-2]       Image Storage </li>     <li>[CARD-3]       Storage Commitment </li>     <li>[RAD-6]       [EYECARE-6] The ability of the PPS Manager to forward MPPS messages       received. </li> </ul><H3>Evaluation</H3><p>On the <strong>Image Manager</strong>, verify that the objects stored  for this test contain: </p><ul>     <li>Patient       ID and Patient Name (OF_SYSTEM-IM_SYSTEM^DOE-REALNAME) generated at the       ADT (Received in RAD-12). </li>     <li>No       objects exist for patient OF-SYSTEM^DOE_IN_DEPT. </li>     <li>If       there are errors, check the message captured in [test-case-no]pat-upd-case4.txt. </li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (217, 1, 0, '2009-11-24 10:53:16.59', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Each Image Manager system should run this test once.</p> </p><H3>Description</H3><p>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 Eye Care Case E6 (EYECARE TF-1: 3.6.6). It is recommended that Image Manager actors find another Image Manager partner and &ldquo;swap&rdquo; this test role with them, ie., run this test twice, alternating &lsquo;sending&rsquo; and &lsquo;receiving&rsquo; roles.</p><H3>Evaluation</H3><b> Image Manager</b> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (218, 1, 0, '2009-11-24 10:53:16.592', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p> </p><H3>Description</H3><p>This is a test to ensure that the Image Display can query the Image Manager and retrieve DICOM    objects. It also checks required SOP Class and Transfer Syntax support. Display of objects is    tested in another test..</p><H3>Evaluation</H3><p>Connectathon Monitor will ask the <strong>Image Display</strong> to show evidence that:</p><ul>     <li>The Connectathon Monitor will ask the Image Display operator to demonstrate its support for     the DICOM Study Root Q/R Information Model and Hierarchical Search.<br>      <br> It will demonstrate on its User Interface the ability to offer its user the following     attributes as selection criteria (note that these required query keys for the Image Displays SCU     (RAD TF-2: Table 4.14-1); the Connectathon Monitor will look for a reasonable subset). Query the     Image Manager for combinations of: <br>      <strong>STUDY LEVEL</strong> Query Keys:</li>     <ul>      <ul>       <li>Study Date (0008,0020)</li>       <li>Study Time (0008,0030)</li>       <li>Accession Number (0008,0050) </li>       <li>Patient Name (0010,0010)</li>       <li>Study ID (0020,0010) </li>       <li>Study Instance UID (0020,000D)</li>       <li>Modalities in Study (0008,0061)</li>       <li>Referring Physician&rdquo;s Name (0008,0090)</li>      </ul>     </ul> </ul><blockquote>     <p> <strong>SERIES LEVEL</strong> Query Keys:</p> </blockquote><ul>     <ul>      <ul>       <li>Modality (0008,0020)</li>       <li>Series Number (0020,0011) </li>       <li>Series Instance UID (0020,000E)</li>       <li>Requested Procedure ID (0040,1001) </li>       <li>Scheduled Procedure Step ID (0040,0009)&nbsp; </li>       <li>PPS Start Date (0040,0244) </li>       <li>PPS Start Time (0040,0245)</li>      </ul>     </ul> </ul><blockquote>     <p> <strong>IMAGE LEVEL</strong> Query Keys:</p> </blockquote><ul>     <ul>      <li>Instance Number (0020,0013) </li>      <li>SOP Instance UID (0008,0016)</li>     </ul> </ul><ul>     <li>It can successfully retrieve the studies requested.&nbsp; At least one of the following     SOP classes with a Compressed transfer syntax will be demonstrated: <ul>       <li>Ultrasound&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;       1.2.840.10008.5.1.4.1.1.6.1</li>      </ul>     </li>     <ul>      <li>Ultrasound      Multi-frame&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;      1.2.840. 10008.5.1.4.1.1.3.1</li>      <li>Opthalmic 8 bit      Photography&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;      1.2.840. 10008.5.1.4.1.1.77.1.5.1</li>      <li>Opthalmic 16 bit      Photography&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;      1.2.840. 10008.5.1.4.1.1.77.1.5.2</li>      <li>Stereometric      Relationship&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;      1.2.840. 10008.5.1.4.1.1.88.33</li>      <li>Opthalmic Tomography Image      Storage&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;      1.2.840.10008.5.1.4.1.1.77.1.5.4</li>     </ul>     <li>Note that Image Managers are required to support both of the following transfer syntaxes,     although you may not be able test with both: &nbsp;JPEG Baseline (1.2.840.10008.1.2.50) or     JPEG Lossless, Non-Hierarchical, First-Order Prediction (1.2.840.10008.1.2.70).</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (219, 1, 0, '2009-11-24 10:53:16.596', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p> </p><H3>Description</H3><p>The Evidence Creator and the Image Manager test their  interfaces for these actions:</p><ul>     <li>      C-STORE of evidence objects</li>     <li>Storage Commitment</li> </ul><H3>Evaluation</H3><p>Connectathon Monitor will ask the <strong>Image Manager</strong> to show  evidence that:</p><ul>     <li>  The evidence objects are successfully stored.  </li>     <li>Note that Images or Evidence Documents  reconstructed on a different piece of equipment (than the original images) must  be in a separate series.</li>     <li>Storage Commitment was successful  (N-EVENT-REPORT) was sent to the Evidence Creator.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (220, 1, 0, '2009-11-24 10:53:16.598', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Modality systems which support this option run one instance of this test.  They should solicit the help of an Image Manger which can capture a copy of their PPS messages.</p> </p><H3>Description</H3><p>This test demonstrates support for the PPS Exception Management option (RAD TF-2: 4.7.4.1.2.3). </p><H3>Evaluation</H3><p>On the <strong>Image Manager</strong>, the Connectathon Monitor will examine a copy of the PPS COMPLETE message.  Verify that the contents of the Procedure Step Discontinuation Reason Code Sequence (0040,0281) is populated with Code Value, Coding Scheme Designator (DCM), and Code Meaning taken from DICOM 2007 PS 3.16 Annex B, Context ID 9300.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (221, 1, 0, '2009-11-24 10:53:16.599', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p> </p><H3>Description</H3><p>This is a test to ensure that the Image Display can render an image or other  document produced by an acquisition modality. You will likely use an Image Manager as a go between to transmit the data, but the Image Manager is not part of the test.</p><H3>Evaluation</H3><p>Connectathon Monitor will ask the Image Display to render  the image(s) from the Acquisition Modality. Monitor will ask that modality  representative be present to provide advice as to the authenticity of the  rendering. In general, we are looking for the modality operator to say: &ldquo;Yes,  that is my image and that is a reasonable rendering for the end user.&rdquo;</p><p>Verify the ability to display the value of <strong>Series Description</strong> for each series  displayed (RAD-TF:4.16.4.2.3)</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (222, 1, 0, '2009-11-24 10:53:16.601', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p> </p><H3>Description</H3><p>Acquisition Modality and Image Managers which support the Eye Care Measurement Option run this test.</p><H3>Evaluation</H3><p>Connectathon Monitor will check that the Measurements were  stored on the Image Manager.&nbsp; </p><p> Acquisition Modalities which support the Eye Care  Measurement Option must support at least one of the folllowing SOP  Classes.&nbsp; Image Managers must support  all.</p><ul type="disc">     <li>1.2.840.10008.5.1.4.1.1.xxxx Lensometry  Measurements</li>     <li>1.2.840.10008.5.1.4.1.1.xxxx  Autorefraction Measurements</li>     <li>1.2.840.10008.5.1.4.1.1.xxxx Keratometry Measurements</li>     <li>1.2.840.10008.5.1.4.1.1.xxxx Subjective  Refraction Measurements</li>     <li>1.2.840.10008.5.1.4.1.1.xxxx Visual Acuity Measurements</li>     <li>1.2.840.10008.5.1.4.1.1.xxxx Spectacle  Prescription Report</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (223, 1, 0, '2009-11-24 10:53:16.603', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You will use the RIS Mall to register a patient and obtain a worklist entry for the Modality.    If you have an available Order Filler for this purpose, run test EyeCare_Brief_Workflow instead.</p> <p>Modality actors should be configured to send PPS messages to the Image Manager system.</p> </p><H3>Description</H3><p>The Modality and PACS test their interfaces for these actions:</p><ul>     <li>Simple and Append Cases </li>     <li>MPPS Abandoned Case</li>     <li>Storage of Images</li>     <li>Storage Commitment<br>     </li> </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><p>Connectathon Monitor will ask the<strong> Image Manager</strong> to show evidence that:</p><ul>     <li>In the SIMPLE case, the images for patient MOD^IM are successfully stored</li>     <li>The PPS N-CREATE message contains codes for billing in the Billing Procedure Step Sequence     (0040,0320).</li>     <li>Storage Commitment was successful (N-EVENT-REPORT was sent).</li>     <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>     <li>It received MPPS Discontinued from the Modality in the Abandoned case.</li> </ul><p>For the <strong>APPEND CASE</strong>, the Connectathon Monitor will ask the Image Manager to    show evidence that: </p><ul>     <li>The images for patient MOD-IM^APPEND are successfully stored</li>     <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>     <li>&nbsp;(0040,0253) Performed Procedure Step ID is different for the two procedure steps     performed on the modality (original and appended steps). </li>     <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. </li>     <ul>      <li>Study Instance UID (0020,000D) should be that received from the DSS/OF (RIS Mall).</li>      <li>Also Study Date, Study Time and Study Description attributes are the same in image IODs for      the original PPS, and those appended. </li>     </ul>     <li>Storage Commitment was successful (N-EVENT-REPORT was sent).&nbsp; Check:</li>     <ul>      <li>(0008, 1199) Referenced SOP Sequence </li>      <ul>       <li>&gt; (0008, 1150) Reference SOP Class </li>       <li>&gt; (0008, 1155 Referenced SOP Instance UID</li>      </ul>      <p>&nbsp;</p>     </ul> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (224, 1, 0, '2009-11-24 10:53:16.608', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Each Acquistion Modality and Order Filler should one run  instance of this test.&nbsp; You may have to  run more than one to assist your partners.</p> <p>    The Image Manager is identified as an optional actor in  this test.&nbsp; It is needed to receive the  forwarded PPS message from the DSS/OF.</p> </p><H3>Description</H3><p>    This tests the case where a generic order is placed and  scheduled.&nbsp; The Modality demonstrates its  ability to select a specific protocol to perform.&nbsp; In the MPPS message, it specifies the  Performed Protocol Codes, which differ from the Requested &amp; Scheduled  Procedure codes which it received in the MWL.&nbsp;  The capability supports accurate charge posting.</p><p>    This is also the test case where the DSS/OF demonstrates  its ability to forward MPPS messages to the IM as a PPS Manager.</p><p>    The DSS/OF is the PPS Manager in this test.&nbsp; The DSS/OF should solicit the help of one  Image Manager to receive its forwarded PPS messages.</p><H3>Evaluation</H3><p>On the <strong>Modality user interface</strong>, the Connectathon monitor will verify:</p><ul>     <li>that the user can select a specific protocol after a generic procedure is received via MWL.  It can complete    the procedure using that protocol and send those codes in the PPS message for that procedure.</li> </ul><p>On the <strong>DSS/OF</strong>, the Connectathon monitor will verify:</p><ul>     <li>MPPS messages are received.  The contents of the Performed Protocol Code Sequence (0040,0260) reflects what was     selected on the Modality user interface.  The code number and description DIFFERS from the values in the Requested     Procedure Code Sequence (0032,1064) and the Scheduled  Protocol Code Sequence (0040,0260) in the Scheduled Step Attributes Sequence (0040,0270).</li> <li>These performed codes are now associated with this patients record on the DSS/OF</li> </ul><p>On the <strong>Image Manager</strong>, the Connectathon monitor will verify:</p><ul>     <li>it received the PPS messages forwarded from the DSS/OF.</li>     </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (225, 1, 0, '2009-11-24 10:53:16.61', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test exercises the exchange of HL7 messages between  DSS/OF and IM actors, including those for Eye Care Case E3 (Unidentified  Patient) and E7 (Cancel Procedure).&nbsp; </p> <p> It also tests the ability of these actors to act as a PPS  Manager.&nbsp; During the Connectathon, each  DSS/OF and Image Manager <strong>must execute at  least one instance of this test where it assumes the role of PPS Manager </strong>and  successfully forwards PPS messages to its partner. </p> <p>A Modality actor is needed to assist with the first part  of this test.&nbsp; It will generate PPS  Messages to be sent to whichever system is the PPS Manager.&nbsp; (No Modality functionality is evaluated in  this test &ndash; any Modality may be used; contents of PPS messages and Modality  C-STORE are evaluated elsewhere.)</p> <p>The RIS Mall is used for the ADT and OP systems; you may  use actual systems for these actors, if available.</p> </p><H3>Description</H3><p>This test verifies interoperability between DSS/OF and Image  Manager/Archive actors, specifically for these transactions:</p><ul>      <li>[RAD-6]      PPS In Progress (forwarding this message)</li>      <li>[EYECARE-6]        PPS Completed (forwarding this message)</li>      <li>[RAD-12]        Patient Update (name change)</li>      <li>[RAD-4]        Procedure Scheduled</li>      <li>[RAD-13]        Procedure Updated </li>     </ul><H3>Evaluation</H3><p>Verify that the system performing the role of <strong>PPS Manager</strong>: </p><ul type="disc">     <li>Properly       forwarded both PPS In Progress and PPS Complete to its partner.&nbsp; These messages should be captured on the       receiving (non-PPS-Mgr) system.</li> </ul><p>On the <strong>Image Manager</strong> verify: </p><ul type="disc">     <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>     <li>The       images stored on the Image Manager are updated with this new name.</li>     <li>It       received an ORM to indicate a procedure was scheduled for patient OF_XYZ-IM_ABC^SCHEDULE.&nbsp; .&nbsp;       In the ORM:</li>     <ul type="circle">      <li>ORC-1        is &ldquo;NW&rdquo;</li>      <li>ORC-2        contains a Placer Order number from RIS Mall</li>      <li>ORC-3        contains a Filler Order number generated by the DSS/OF</li>      <li>ORC-5        is &ldquo;SC&rdquo;</li>      <li>ORC-7        contains a value for the Date/Time of the SPS (in the 4th        component)</li>      <li>OBR-18        contains accession number</li>      <li>OBR-19        contains RP ID</li>      <li>OBR-20        contains SPS ID</li>      <li>OBR-24        contains the DICOM Modality (defined terms)</li>      <li>XDS-1        contains Study Instance UID of the form: <em>&lt;UIDvalue&gt;^&lt;ApplID value&gt;</em>^Application^DICOM</li>     </ul>     <li>It       received an ORM to indicate the procedure was cancelled.&nbsp; The ORM contains:</li>     <ul type="circle">      <li>a        value of &ldquo;CA&rdquo; in ORC-1 and ORC-5</li>     </ul>     <li>&nbsp;The ORC and OBR elements are unchanged       from the previous Procedure Scheduled message, especially:</li>     <ul type="circle">      <li>OBR-2        and ORC-2 Placer Order Number (RIS Mall value)</li>      <li>OBR-3        and ORC-3 Filler Order Number</li>      <li>ORC-4        Placer Group Number</li>      <li>ZDS-1        Study Instance UID</li>     </ul> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (226, 1, 0, '2009-11-24 10:53:16.612', 'epoiseau', '<H3>Special Instructions</H3><p> <ul>     <li>Use the RIS Mall to register a patient and  create an order (Requested Procedure) for this test.</li>     <li>The Modality should be configured to send MPPS  to the DSS/OF.</li>     <li>The Modality will C-STORE images in this test,  but storage to an Image Manager is not part of the evaluation.&nbsp; If there is not an available Image Manager to  C-STORE to, the Modality should be configured to send its objects to the  Connectathon MESA Tools or CENTRAL_ARCHIVE.</li> </ul> </p><H3>Description</H3><p>In this test, the Modality and DSS/OF test their  interfaces for these actions:</p><ul>     <li>Modality Worklist</li>     <li>The Unscheduled Case &ndash; Eye Care Case E5</li> </ul><p>Note that the ability of the DSS/OF to forward MPPS  messages as a PPS Manager is not exercised in this test.</p><H3>Evaluation</H3><p>Connectathon Monitor will ask the <strong>Acquistion</strong> <strong>Modality</strong> to  show evidence that: </p><ul>     <li>It supports BOTH Broad and Patient-Based MWL  queries.:<br>      <u>Broad Worklist</u>: The Modality operator should demonstrate on its user  interface the ability to query by combination of SPS Start Date, Modality type,  Scheduled AE title.<br>      <u>Patient-Based Worklist</u>: 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.</li> </ul><ul>      <li>In the Unscheduled Case, the MPPS message sent  by the Modality (captured on the DSS/OF) contains:</li>      <ul>       <li>(0010,0010) Temporary Patient ID created by the  Modality (Patient ID reconciliation is not evaluated in this test)</li>       <li>(0020,000D) Study Instance UID created by the  Modality </li>       <li>(0008, 1032) Procedure Code Sequence is empty</li>       <li>In (0040,0270) &ndash; Scheduled Step Attributes  Sequence, the following attributes are empty (zero-length):<br>       - (0008,1110) Referenced Study Sequence<br>       - (0008,0050) Accession Number<br>       - (0032,1060) RP Description<br>       - (0040,1001) Requested Procedure ID <br>       - (0040,0007) SPS Description<br>       - (0040,0008) Scheduled Procedure Code Sequence<br>       - (0040,0009) SPS ID</li>      </ul> </ul><p>Connectathon Monitor will ask the <strong>DSS/OF</strong> to show evidence that:</p><ul>      <li>It creates valid DICOM Study Instance UIDs  (0020,000D):<br>      - containing a registered root of the form: 1.2.yyy.xxxxxx where yyy is a 3  digit country code (eg 840 for US), and xxxxxx is a six-digit organization code  provided by ANSI.<br>      - each component (separated by &ldquo;.&rdquo;) consists of one or more digits.&nbsp; The first digit of each component shall not  be zero unless the component is a single digit.<br>      - maximum length of 64 characters</li>      <li>For the Unscheduled case, a RP/SPS has been  created for this procedure using the modality-provided Study Instance UID  received in the MPPS.</li>     </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (227, 1, 0, '2009-11-24 10:53:16.615', 'epoiseau', '<H3>Special Instructions</H3> <p>None.</p>  <H3>Description</H3> <p>Order Placers and Order Fillers should synchronize ordering codes to make sure that all procedures that can be ordered are available in their systems.</p>  <H3>Evaluation</H3> <p>Connectathon Monitor will ask Order Filler to show evidence that the worklist has been populated for modalties to perform queries.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (228, 1, 0, '2009-11-24 10:53:16.617', 'epoiseau', '<H3>Special Instructions</H3><p></p> <p>Content Consumers please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) your peers have submitted. </p> <H3>Description</H3><p>There are four processing options defined for the Content  Consumer:</p><ul> <li>View</li> <li>Document Import</li> <li>Section Import</li> <li>Discrete Data Import</li> </ul><p>In this test, the Content Consumer locates the FSA Braden Scale document produced by a single Content Creator. The Content Consumer demonstrates which of the 4 processing options are supported for the documment.<br>   When examining the processing of the document, the Connectathon Monitor should evaluate the document with at least these items in mind:</p><ul> <li>Sections in the document are appropriate per the definitions in PCC TF</li> <li>A default style sheet is provided by the Content Creator. The Content Consumer is required to render the document with the  default style sheet. As an option, the Content Consumer can render with a  different style sheet.</li> </ul><H3>Evaluation</H3><p>In the evaluation, the Connectathon Monitor is looking for evidence that the Content Consumer can interpret the document produced by the Content Creator. That is a test of both actors. The Connetathon Monitor is then looking for evidence that the Consumer processes at least one of the options as specified in the FSA Integration Profile.<br>   The monitor shall check for these values in the document.  If the Content Consumer supports the view option, this data shall be rendered for display. Other options may not include processing each entry, so evaluation will require some judgment.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (229, 1, 0, '2009-11-24 10:53:16.619', '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 FSA Geriatric Depression document produced by a single Content Creator. The Content Consumer demonstrates which of the 4 processing options are supported for the documment.<br>   When examining the processing of the document, the Connectathon Monitor should evaluate the document with at least these items in mind:</p><ul> <li>Sections in the document are appropriate per the definitions in PCC TF</li> <li>A default style sheet is provided by the Content Creator. The Content Consumer is required to render the document with the  default style sheet. As an option, the Content Consumer can render with a  different style sheet.</li> </ul><H3>Evaluation</H3><p>In the evaluation, the Connectathon Monitor is looking for evidence that the Content Consumer can interpret the document produced by the Content Creator. That is a test of both actors. The Connetathon Monitor is then looking for evidence that the Consumer processes at least one of the options as specified in the FSA Integration Profile.<br>   The monitor shall check for these values in the document.  If the Content Consumer supports the view option, this data shall be rendered for display. Other options may not include processing each entry, so evaluation will require some judgment.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (230, 1, 0, '2009-11-24 10:53:16.621', '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 FSA Pain Scale document produced by a single Content Creator. The Content Consumer demonstrates which of the 4 processing options are supported for the documment.<br>   When examining the processing of the document, the Connectathon Monitor should evaluate the document with at least these items in mind:</p><ul> <li>Sections in the document are appropriate per the definitions in PCC TF</li> <li>A default style sheet is provided by the Content Creator. The Content Consumer is required to render the document with the  default style sheet. As an option, the Content Consumer can render with a  different style sheet.</li> </ul><H3>Evaluation</H3><p>In the evaluation, the Connectathon Monitor is looking for evidence that the Content Consumer can interpret the document produced by the Content Creator. That is a test of both actors. The Connetathon Monitor is then looking for evidence that the Consumer processes at least one of the options as specified in the FSA Integration Profile.<br>   The monitor shall check for these values in the document.  If the Content Consumer supports the view option, this data shall be rendered for display. Other options may not include processing each entry, so evaluation will require some judgment.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (231, 1, 0, '2009-11-24 10:53:16.623', '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 FSA Physical Function document produced by a single Content Creator. The Content Consumer demonstrates which of the 4 processing options are supported for the documment.<br>   When examining the processing of the document, the Connectathon Monitor should evaluate the document with at least these items in mind:</p><ul> <li>Sections in the document are appropriate per the definitions in PCC TF</li> <li>A default style sheet is provided by the Content Creator. The Content Consumer is required to render the document with the  default style sheet. As an option, the Content Consumer can render with a  different style sheet.</li> </ul><H3>Evaluation</H3><p>In the evaluation, the Connectathon Monitor is looking for evidence that the Content Consumer can interpret the document produced by the Content Creator. That is a test of both actors. The Connetathon Monitor is then looking for evidence that the Consumer processes at least one of the options as specified in the FSA Integration Profile.<br>   The monitor shall check for these values in the document.  If the Content Consumer supports the view option, this data shall be rendered for display. Other options may not include processing each entry, so evaluation will require some judgment.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (232, 1, 0, '2009-11-24 10:53:16.625', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> <p>The goal of this test is to create one valid document (Referral, Discharge, PHR Extract) that contains the FSA Braden Scale section and publish it in a location to make it easy for other participants to locate.</p> </p><H3>Description</H3><p>Each Content Creator has been assigned one well known patient (see test Content_Creator_Demographics) with a Patient ID in the proper domain. Create a document that uses the demographics for this patient and patient ID (if possible).</p><p>For any of the coded values (allergies, medications, etc.)  use only coded values found in the MESA/Connectathon Code Tables document. That  document should list between 3 and 5 legal coded values. Do not invent codes or  import other codes. If you find that document lacking, inform the Connectathon  monitor about appropriate coded values for inclusion.</p><ol> <li>These next steps refer to storing the document and reference information in the Kudu tool. You will find the page in the Kudu tool by selecting Connectathon and then Connectathon Images/CDs/Objects. The link to that page is <em><a href=system_con_object.php>Objects Information</a></em> </li>  <li>Enter the Patient ID,  Patient Name, company name, your name, and your Kudu system name into the description of the <em>Connectathon Images/CDAs/Objects</em>.</li> <li>Create a screen capture of a rendering of the FSA document. We recognize that not all renderings will be the same.</li> <li>Name the document FSA_Braden_Scale_kudu.xml where <strong><em>kudu</em></strong> is your Kudu system name.</li> <li>Upload information, snapshot and xml files in the <em>Connectathon Images/CDAs/Objects</em> section of Kudu.</li> <li> Upload your documents according to the instructions on that  page. Update the <em> Connectathon Images/CDAs/Objects Publication/rendering page</em> page to list your document/zip file.</li> <li>Find the Connectathon monitor or monitors responsible for Document Scrutiny. Make sure they are aware your document has been placed into the Kudu tool.</li> <li>If you support XDS, complete XDS test that requires you to store and register your document with a repository/registry. You do not need to complete that XDS store step in order to complete this test. In fact, once you have uploaded the proper documentation into Kudu, mark this test complete.</li> </ol><p>These items describe the minimum content that must be  present in the Discharge document. Additional content is acceptable, but the  document must contain the following information:</p><H3>Evaluation</H3><p>This will be evaluated with the FSA_Scrutiny_Braden_Scale and FSA_Process_Braden_Scale tests.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (233, 1, 0, '2009-11-24 10:53:16.627', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> <p>The goal of this test is to create <em>three</em> valid documents (Referral, Discharge, PHR Extract) that contain the FSA Geriatric Dpression Scale section and publish them in a location to make it easy for other participants to locate.</p> <p>Three specific sets of answers to the questions are provided with a known  result. You are to produce three separate documents with the specified  answers to the questions and proper computed result.</p> </p><H3>Description</H3><p>Each Content Creator has been assigned one well known patient (see test Content_Creator_Demographics) with a Patient ID in the proper domain. Create a document that uses the demographics for this patient and patient ID (if possible).</p><p>For any of the coded values (allergies, medications, etc.)  use only coded values found in the MESA/Connectathon Code Tables document. That  document should list between 3 and 5 legal coded values. Do not invent codes or  import other codes. If you find that document lacking, inform the Connectathon  monitor about appropriate coded values for inclusion.</p><ol> <li>These next steps refer to storing the document and reference information in the Kudu tool. You will find the page in the Kudu tool by selecting Connectathon and then Connectathon Images/CDs/Objects. The link to that page is <em><a href=system_con_object.php>Objects Information</a></em> </li>  <li>Enter the Patient ID,  Patient Name, company name, your name, and your Kudu system name into the description of the <em>Connectathon Images/CDAs/Objects</em>.</li> <li>Create a screen capture of a rendering of the FSA document. We recognize that not all renderings will be the same.</li> <li>Name the documents FSA_Geriatric_Depression_yes_kudu.xml, FSA_Geriatric_Depression_no_kudu.xml, FSA_Geriatric_Depression_mixed_kudu.xml where <strong><em>kudu</em></strong> is your Kudu system name.</li> <li>Upload information, snapshot and xml files in the <em>Connectathon Images/CDAs/Objects</em> section of Kudu.</li> <li> Upload your documents according to the instructions on that  page. Update the <em> Connectathon Images/CDAs/Objects Publication/rendering page</em> page to list your document/zip file.</li> <li>Find the Connectathon monitor or monitors responsible for Document Scrutiny. Make sure they are aware your document has been placed into the Kudu tool.</li> <li>If you support XDS, complete XDS test that requires you to store and register your document with a repository/registry. You do not need to complete that XDS store step in order to complete this test. In fact, once you have uploaded the proper documentation into Kudu, mark this test complete.</li> </ol><p>These items describe the minimum content that must be  present in the Discharge document. Additional content is acceptable, but the  document must contain the following information:</p><H3>Evaluation</H3><p>This will be evaluated with the FSA_Scrutiny_Geriatric_Depression and FSA_Process_Geriatric_Depression tests.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (234, 1, 0, '2009-11-24 10:53:16.63', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> <p>The goal of this test is to create one valid document (Referral, Discharge, PHR Extract) that contains the FSA Pain Scale Assessment section and publish it in a location to make it easy for other participants to locate.</p> </p><H3>Description</H3><p>Each Content Creator has been assigned one well known patient (see test Content_Creator_Demographics) with a Patient ID in the proper domain. Create a document that uses the demographics for this patient and patient ID (if possible).</p><p>For any of the coded values (allergies, medications, etc.)  use only coded values found in the MESA/Connectathon Code Tables document. That  document should list between 3 and 5 legal coded values. Do not invent codes or  import other codes. If you find that document lacking, inform the Connectathon  monitor about appropriate coded values for inclusion.</p><ol> <li>These next steps refer to storing the document and reference information in the Kudu tool. You will find the page in the Kudu tool by selecting Connectathon and then Connectathon Images/CDs/Objects. The link to that page is <em><a href=system_con_object.php>Objects Information</a></em> </li>  <li>Enter the Patient ID,  Patient Name, company name, your name, and your Kudu system name into the description of the <em>Connectathon Images/CDAs/Objects</em>.</li> <li>Create a screen capture of a rendering of the FSA document. We recognize that not all renderings will be the same.</li> <li>Name the document FSA_Pain_Scale_kudu.xml where <strong><em>kudu</em></strong> is your Kudu system name.</li> <li>Upload information, snapshot and xml files in the <em>Connectathon Images/CDAs/Objects</em> section of Kudu.</li> <li> Upload your documents according to the instructions on that  page. Update the <em> Connectathon Images/CDAs/Objects Publication/rendering page</em> page to list your document/zip file.</li> <li>Find the Connectathon monitor or monitors responsible for Document Scrutiny. Make sure they are aware your document has been placed into the Kudu tool.</li> <li>If you support XDS, complete XDS test that requires you to store and register your document with a repository/registry. You do not need to complete that XDS store step in order to complete this test. In fact, once you have uploaded the proper documentation into Kudu, mark this test complete.</li> </ol><p>These items describe the minimum content that must be  present in the Discharge document. Additional content is acceptable, but the  document must contain the following information:</p><H3>Evaluation</H3><p>This will be evaluated with the FSA_Scrutiny_Pain_Scale and FSA_Process_Pain_Scale tests.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (235, 1, 0, '2009-11-24 10:53:16.632', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> <p>The goal of this test is to create one valid document (Referral, Discharge, PHR Extract) that contains the FSA Physical Function section and publish it in a location to make it easy for other participants to locate.</p> </p><H3>Description</H3><p>Each Content Creator has been assigned one well known patient (see test Content_Creator_Demographics) with a Patient ID in the proper domain. Create a document that uses the demographics for this patient and patient ID (if possible).</p><p>For any of the coded values (allergies, medications, etc.)  use only coded values found in the MESA/Connectathon Code Tables document. That  document should list between 3 and 5 legal coded values. Do not invent codes or  import other codes. If you find that document lacking, inform the Connectathon  monitor about appropriate coded values for inclusion.</p><ol> <li>These next steps refer to storing the document and reference information in the Kudu tool. You will find the page in the Kudu tool by selecting Connectathon and then Connectathon Images/CDs/Objects. The link to that page is <em><a href=system_con_object.php>Objects Information</a></em> </li>  <li>Enter the Patient ID,  Patient Name, company name, your name, and your Kudu system name into the description of the <em>Connectathon Images/CDAs/Objects</em>.</li> <li>Create a screen capture of a rendering of the FSA document. We recognize that not all renderings will be the same.</li> <li>Name the document FSA_Physical_Function_kudu.xml where <strong><em>kudu</em></strong> is your Kudu system name.</li> <li>Upload information, snapshot and xml files in the <em>Connectathon Images/CDAs/Objects</em> section of Kudu.</li> <li> Upload your documents according to the instructions on that  page. Update the <em> Connectathon Images/CDAs/Objects Publication/rendering page</em> page to list your document/zip file.</li> <li>Find the Connectathon monitor or monitors responsible for Document Scrutiny. Make sure they are aware your document has been placed into the Kudu tool.</li> <li>If you support XDS, complete XDS test that requires you to store and register your document with a repository/registry. You do not need to complete that XDS store step in order to complete this test. In fact, once you have uploaded the proper documentation into Kudu, mark this test complete.</li> </ol><p>These items describe the minimum content that must be  present in the Discharge document. Additional content is acceptable, but the  document must contain the following information:</p><H3>Evaluation</H3><p>This will be evaluated with the FSA_Scrutiny_Physical_Function and FSA_Process_Physical_Function tests.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (236, 1, 0, '2009-11-24 10:53:16.635', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> <p>The monitor in charge of PCC documents will scrutinize your CDA content. He/she might not finish that work on Day 1. You need to publish the document and mark this test done to trigger the monitor to review your document.</p> <p>If you do not start this test until the second or third day, it means that you were not prepared to produce content at the start of the Connectathon. You need to be able to produce legal content at the start of the event. You cannot spend the week debugging your CDA documents.</p> </p><H3>Description</H3><p>One Connectathon Monitor will be assigned to scrutinize FSA documents.      The purpose of this test is to have a single person with domain knowledge examine one      example of each document.      The Connectathon Monitor is looking for proper document structure, proper use of coded values      and content that was specified in the Publish test.</p><p>The Content Creator should use the same documents produced and stored in the Kudu tool in the FSA_Publish_Braden_Scale test.</p><p>The Connectathon Monitor will take the files offline and perform evaluation.      The monitor will document any deficiencies and ask the Content Creator to correct      during the Connectathon.</p> <H3>Evaluation</H3> <p>Monitors please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) the Content Creators have submitted. </p> <p>The NIST Evaluation tools are found at http://xreg2.nist.gov/cda-validation/index.html.      For documents not supported by the NIST tool, use the schematron file found at IHESCHEMATRON.   </p><p>In the evaluation, the Connectathon Monitor will follow these steps:    <ol>      <li>Use CDA validation tool to make sure document is legal CDA document</li>      <li>Use Schematron test tool to see that document passes schematron tests for FSA</li>      <li>Examine FSA by hand (possibly with style sheet) and examine for FSA specific content         in these sections.         Values are found on the         <a href="http://ihewiki.wustl.edu/wiki/index.php/PCC_Connectathon_Content_Test_Requirements">Connectathon wiki: PCC Content Test Requirements</a>         The list of modules that are required and should be examined are:      <ul>        <li></li>        <li></li>       </ul>      </li>     </ol> </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (237, 1, 0, '2009-11-24 10:53:16.637', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> <p>The monitor in charge of PCC documents will scrutinize your CDA content. He/she might not finish that work on Day 1. You need to publish the document and mark this test done to trigger the monitor to review your document.</p> <p>If you do not start this test until the second or third day, it means that you were not prepared to produce content at the start of the Connectathon. You need to be able to produce legal content at the start of the event. You cannot spend the week debugging your CDA documents.</p> </p><H3>Description</H3><p>One Connectathon Monitor will be assigned to scrutinize FSA documents.      The purpose of this test is to have a single person with domain knowledge examine one      example of each document.      The Connectathon Monitor is looking for proper document structure, proper use of coded values      and content that was specified in the Publish test.</p><p>The Content Creator should use the same documents produced and stored in the Kudu tool in the FSA_Publish_Geriatric_Depression test.</p><p>The Connectathon Monitor will take the files offline and perform evaluation.      The monitor will document any deficiencies and ask the Content Creator to correct      during the Connectathon.</p> <H3>Evaluation</H3> <p>Monitors please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) the Content Creators have submitted. </p> <p>The NIST Evaluation tools are found at http://xreg2.nist.gov/cda-validation/index.html.      For documents not supported by the NIST tool, use the schematron file found at IHESCHEMATRON.   </p><p>In the evaluation, the Connectathon Monitor will follow these steps:    <ol>      <li>Use CDA validation tool to make sure document is legal CDA document</li>      <li>Use Schematron test tool to see that document passes schematron tests for FSA</li>      <li>Examine FSA by hand (possibly with style sheet). There are supposed to be three documents         with different answers to the questions (all yes, all no, mixed)</li>      <li>Examine FSA by hand (possibly with style sheet) and examine for FSA specific content         in these sections.         Values are found on the         <a href="http://ihewiki.wustl.edu/wiki/index.php/PCC_Connectathon_Content_Test_Requirements">Connectathon wiki: PCC Content Test Requirements</a>         The list of modules that are required and should be examined are:      <ul>        <li></li>        <li></li>       </ul>      </li>     </ol> </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (238, 1, 0, '2009-11-24 10:53:16.639', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> <p>The monitor in charge of PCC documents will scrutinize your CDA content. He/she might not finish that work on Day 1. You need to publish the document and mark this test done to trigger the monitor to review your document.</p> <p>If you do not start this test until the second or third day, it means that you were not prepared to produce content at the start of the Connectathon. You need to be able to produce legal content at the start of the event. You cannot spend the week debugging your CDA documents.</p> </p><H3>Description</H3><p>One Connectathon Monitor will be assigned to scrutinize FSA documents.      The purpose of this test is to have a single person with domain knowledge examine one      example of each document.      The Connectathon Monitor is looking for proper document structure, proper use of coded values      and content that was specified in the Publish test.</p><p>The Content Creator should use the same documents produced and stored in the Kudu tool in the FSA_Publish_Pain_Scale test.</p><p>The Connectathon Monitor will take the files offline and perform evaluation.      The monitor will document any deficiencies and ask the Content Creator to correct      during the Connectathon.</p>  <H3>Evaluation</H3> <p>Monitors please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) the Content Creators have submitted. </p> <p>The NIST Evaluation tools are found at http://xreg2.nist.gov/cda-validation/index.html.      For documents not supported by the NIST tool, use the schematron file found at IHESCHEMATRON.   </p><p>In the evaluation, the Connectathon Monitor will follow these steps:    <ol>      <li>Use CDA validation tool to make sure document is legal CDA document</li>      <li>Use Schematron test tool to see that document passes schematron tests for FSA</li>      <li>Examine FSA by hand (possibly with style sheet) and examine for FSA specific content         in these sections.         Values are found on the         <a href="http://ihewiki.wustl.edu/wiki/index.php/PCC_Connectathon_Content_Test_Requirements">Connectathon wiki: PCC Content Test Requirements</a>         The list of modules that are required and should be examined are:      <ul>        <li></li>        <li></li>       </ul>      </li>     </ol> </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (239, 1, 0, '2009-11-24 10:53:16.641', 'epoiseau', '<H3>Special Instructions</H3><p> <p>You need to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> <p>The monitor in charge of PCC documents will scrutinize your CDA content. He/she might not finish that work on Day 1. You need to publish the document and mark this test done to trigger the monitor to review your document.</p> <p>If you do not start this test until the second or third day, it means that you were not prepared to produce content at the start of the Connectathon. You need to be able to produce legal content at the start of the event. You cannot spend the week debugging your CDA documents.</p> </p><H3>Description</H3><p>One Connectathon Monitor will be assigned to scrutinize FSA documents.      The purpose of this test is to have a single person with domain knowledge examine one      example of each document.      The Connectathon Monitor is looking for proper document structure, proper use of coded values      and content that was specified in the Publish test.</p><p>The Content Creator should use the same documents produced and stored in the Kudu tool in the FSA_Publish_Physical_Function test.</p><p>The Connectathon Monitor will take the files offline and perform evaluation.      The monitor will document any deficiencies and ask the Content Creator to correct      during the Connectathon.</p> <H3>Evaluation</H3> <p>Monitors please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) the Content Creators have submitted. </p> <p>The NIST Evaluation tools are found at http://xreg2.nist.gov/cda-validation/index.html.      For documents not supported by the NIST tool, use the schematron file found at IHESCHEMATRON.   </p><p>In the evaluation, the Connectathon Monitor will follow these steps:    <ol>      <li>Use CDA validation tool to make sure document is legal CDA document</li>      <li>Use Schematron test tool to see that document passes schematron tests for FSA</li>      <li>Examine FSA by hand (possibly with style sheet) and examine for FSA specific content         in these sections.         Values are found on the         <a href="http://ihewiki.wustl.edu/wiki/index.php/PCC_Connectathon_Content_Test_Requirements">Connectathon wiki: PCC Content Test Requirements</a>         The list of modules that are required and should be examined are:      <ul>        <li></li>        <li></li>       </ul>      </li>     </ol> </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (240, 1, 0, '2009-11-24 10:53:16.643', 'epoiseau', '<h3>Special Instructions</h3> <p>The Image Display may use the Connectathon CENTRAL_ARCHIVE  as a source of different vendors'' images, and BSPS and Spatial Registration  objects.  These can be found by querying  for patient name "FUS*".  </p> <p>Image Displays must demonstrate for the Connectathon Monitor  rendering of fusion studies created by <u>three</u> different vendors'' Evidence  Creators and/or Modalities.  </p> <p>You will not be able to complete this test until Tuesday  or later during the Connectathon, since Evidence Creators will still be storing  to the CENTRAL_ARCHIVE the studies you will need on the first day of the  Connectathon.</p> <h3>Description</h3> <p>The test verifies that the Image Display can display a  variety of Fusion studies --  image sets  from various vendors and Spatial Registration and BSPS objects from different  Evidence Creators.</p> <h3>Evaluation</h3> <p>On the <strong>Image  Display</strong> verify that all Fusion studies can be accurately  rendered.  <br>     <u>Multiple</u> datasets created by the Evidence Creator  must be evaluated.<br>     <u>For each study</u>, the Connectathon Monitor will:</p> <ol> <ul>   <li>E18: Compare the results with those on the Evidence Creator  which did the blending, as necessary.  </li>   <li>E19:Image Displays must demonstrate fusion of two series of  images acquired and reconstructed on two different Acquisition Modalities, each  with a different Frame of Reference (eg a CT or MR series and a PET or SPECT  series; it is also possible that a hybrid modality creates original image  datasets with different Frames of Reference).    The dataset will include both a Spatial Registration and BSPS object.</li>   <li>E20: Verify that the Image Display application allows the  user to navigate the dimensions of the image data to a specific space or time.</li>   <li>E21: Verify that the two datasets can be displayed side-by-side  (not fused).</li>   <li>E22: Verify that the user can adjust the transparency of the  fusion overlay (blending factor).  By  adjusting the blending factor, the user is able to view the unfused data sets.</li>   <li>E23: Verify that user of the Image Display application can  display MPR (Multi-Planar Reconstructed) planes of fused data.</li>   <li>E24: Verify that the user of the Image Display can  demonstrate direct independent control over the Upper Window Level display  parameters for all NM and PET images.</li>   <li>E25: Verify that the value of Series Description (0008,103E)  is displayed on the Image Display user interface</li>   <li>E26: For studies on which the EC did Spatial Registration,  verify that the value of Derivation Code Sequence (0008,9215) is displayed on  the Image Display user interface.  The  value shall be 113085 "Spatial Resampling". </li>   <li>E27: If  the Evidence Creator has stored derived, re-sampled images after registration,  the NM image DICOM datasets must contain values in the following attributes:</li> </ul> <ol> <ul>   <li>(0020,0052) Frame of Reference UID</li>   <li>(0020,0037) Image Orientation (in (0054,0022)  Detector Information Sequence)</li>   <li>(0020,0032) Image Position (in (0054,0022)  Detector Information Sequence)</li>   <li>(0018,0088) Spacing Between Slices</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (241, 1, 0, '2009-11-24 10:53:16.646', 'epoiseau', '<h3>Special Instructions</h3> <p>You should run FUS_MOD_ED and FUS_EC_STORE  before this test.</p> <H3>Description</h3> <p>The purpose of this test is to verify that an Image Manager  can accept and store BSPS and Spatial Registration objects created by Evidence  Creators in the Fusion profile.</p> <p>Storage Commitment is also tested.</p> <h3>Evaluation</h3> <p>On the <strong>Image Manager</strong>:</p> <ol> <ul>   <li><i>(we will do this verification step only if there are problems on the fusion display; otherwise we will assume that all objects were correctly stored and retrieved)</i>:  E7: verify that BSPS and Spatial Registration objects are  received. 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)</li>   <li>E8: (at least) two Spatial Registration objects should be  stored.  These objects have different SOP  instance UIDs)</li>   <li>E9: The Spatial Registration object(s) are stored in the  most recent of the studies containing the registered images</li>   <li>E10: The BSPS(s) are stored in the most recent of the  studies containing the registered images</li>   <li>E11: verify that the Spatial Registration object(s), BSPSs,  and images are each stored in different series</li>   <li>E12: verify via a log file or status display that Storage  Commitment for these objects was successful.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (242, 1, 0, '2009-11-24 10:53:16.648', 'epoiseau', '<h3>Special Instructions</h3> <p>Evidence Creators will need the Acquisition Modalities to  complete sending their images datasets to the CENTRAL_ARCHIVE (in test  FUS_MOD_STORE) before they will be able to run this test.  You will need to obtain these images prior to  running this test.  </p> <h3>Description </h3> <p>This test case is used to gather at the Connectathon  CENTRAL_ARCHIVE Spatial Registration and BSPS objects created by Evidence  Creators.  This will enable Image Manager  and Image Display actors to access these datasets for their testing.  You can use the studies you created in test  FUS_MOD_EC.</p> <p>Evidence Creator actors will also directly sending these  DICOM objects to Image Manager actors in test FUS_EC_IM.  Storage Commitment is tested in that test.</p> <h3>Evaluation</h3> <p>There is no formal evaluation for this test.   You should show the Connectathon Monitor the  Patient Names of the studies for which you stored Spatial Registration and BSPS  so that he/she can verify successful storage of these objects to the  CENTRAL_ARCHIVE.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (243, 1, 0, '2009-11-24 10:53:16.65', 'epoiseau', '<h3>Special Instructions</h3> <p>Evidence Creators and Image Managers which are also  registered as a Secure Node must execute this test.</p> <p>Run one instance of this test.</p> <h3>Description </h3> <p>This test case verifies that Evidence Creators and Image  Managers which are Secure Nodes create the correct audit record when they store  Spatial Registration and BSPS objects.</p> <h3>Evaluation</h3> <ul>   <li>E37: The Connectathon Monitor will verify that the Evidence  Creator sent valid audit records to the Audit Record Repository when it  C-STOREd both the BSPS and Spatial Registration object.&nbsp; The ATNA Trigger event for these two  transactions is &ldquo;<strong>Begin-storing-instances</strong>&rdquo;.</li>   <li>E38: The Connectathon  Monitor will verify that the Image Manager sent valid audit records to the  Audit Record Repository when it received both the BSPS and Spatial Registration  object.&nbsp; The ATNA Trigger event for these  two transactions is &ldquo;<strong>Instances-stored</strong>&rdquo;.</li> </ul>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (244, 1, 0, '2009-11-24 10:53:16.651', 'epoiseau', '<h3>Special Instructions</h3> <p>Image Managers should run  FUS_EC_IM before running this test.</p>    <h3>Description</h3>  <p>This test verifies that an Image Display can Query/Retrieve fusion  studies containing image datasets, a BSPS and a Spatial Registration object.<br>   The rendering capabilities of the Image Display are tested  in test FUS_DISPLAY.</p> <h3>Evaluation</h3> <p>On the <strong>Image Display</strong>:</p> <ol> <ul>   <li>E16: The Connectathon Monitor should observer real-time the  Image Display querying and retrieving from   the Image Manager</li>   <li>E17: verify that all images and the BSPS and Spatial  Registration objects are received.  (The  ability to render these objects is tested in another test.)</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (245, 1, 0, '2009-11-24 10:53:16.653', 'epoiseau', '<h3>Special Instructions</h3> <p>The Image Display may use the Connectathon CENTRAL_ARCHIVE  as a source of different vendors'' images, and BSPS and Spatial Registration  objects.  These can be found by querying  for patient name "FUS*".  </p> <p>Image Displays must demonstrate for the Connectathon Monitor  rendering of fusion studies created by <u>three</u> different vendors'' Evidence  Creators and/or Modalities.  </p> <p>You will not be able to complete this test until Tuesday  or later during the Connectathon, since Modalities will still be storing to the  CENTRAL_ARCHIVE the studies you will need on the first day of the Connectathon.</p> <h3>Description</h3> <p>The test verifies that the Image Display can display a  variety of Fusion studies --  image sets,  BSPS, and, optionally, Spatial Registration objects from various hybrid  modality vendors.</p> <h3>Evaluation</h3> <p>On the <strong>Image  Display</strong> verify that all Fusion studies can be accurately  rendered.  <br>     <u>Multiple</u> datasets created by the Modality must be  evaluated.</p> <p><u>For each study</u>, the  Connectathon Monitor will:</p> <ul>   <li>E28: Compare the results with those on the Modality which  did the blending, as necessary.  </li>   <li>E29: Image Displays must demonstrate fusion of two series of  images with the same Frame of Reference (it is also possible that a hybrid  modality creates original image datasets with different Frames of  Reference).   The dataset will include a  BSPS object, and may include a Spatial Registration.</li>   <li>E30:   Verify that the Image Display application allows the  user to navigate the dimensions of the image data to a specific space or time.</li>   <li>E31: Verify that the two datasets can be displayed  side-by-side (not fused).</li>   <li>E32: Verify that the user can adjust the transparency of the  fusion overlay (blending factor).  By  adjusting the blending factor, the user is able to view the unfused data sets.</li>   <li>E33: Verify that the user of the Image Display can  demonstrate direct independent control over the Upper Window Level display  parameters for all NM and PET images.</li>   <li>E34: Verify that the Image Display can perform any  resampling needed for the fused display.   This is done when the two image datasets have different pixel  resolution, pixel spacing, slice thickness, number of slices, slice positions,  or slice orientations.  </li>   <li>E35: If the two datasets have different pixel spacing or  slice thickness, ask the Image Display to scroll through slices in increments  of the original slices of the underlying set, and also in the increments of the  original slice or pixel spacing of the superimposed dataset.</li>   <li>E36: Verify that the values of Series Description  (0008,103E) and Derivation Code Sequence (0008,9215) are displayed on the Image  Display user interface.</li> </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (246, 1, 0, '2009-11-24 10:53:16.657', 'epoiseau', '<h3>Special Instructions</h3> <p>The Image Fusion profile does not specify how the images  are obtained by the Evidence Creator.  <br>   Images will be available on the Connectathon  CENTRAL_ARCHIVE after Modalities complete their FUS_MOD_STORE test.<br>  </p> <p>This is a test between Modality and Evidence Creator  actors.  However, part of the evaluation  requires that the result of the fusion performed on the EC be displayed; this,  the Image Display is identified as an ''optional'' actor (the Display  functionality is not evaluated in this test, but a Display system is required  to help during the evaluation).</p> <h3>Description </h3> <p>This test case ensures that Evidence Creators can perform  registration and blending on images from various imaging modality systems.<br>   Evidence Creator actor will store the resulting BSPS and  Spatial Registration objects to the Connectathon CENTRAL_ARCHIVE in  FUS_EC_STORE.  Evidence Creator actors  will also directly sending these DICOM objects to Image Manager actors in test  FUS_EC_IM.  Storage Commitment is tested  in that test.</p> <h3>Evaluation</h3> <p>The Connectathon Monitor will ask the <strong>Evidence Creator </strong>to demonstrate in its application:<strong></strong></p> <bl>  <li>E1... that it can register to image datasets which do not  share a Frame of Reference.  It performs  translations, rotation and scaling, as required).   The Evidence Creator demonstrates its  method/algorithms for registration.   (Specific methods are not mandated by the profile.)  <strong></strong></li>   <li>E2... (recommended functionality) that it records the name  and description of the method of registration within the Spatial Registration  object.<strong></strong></li>   <li>E3... it can set the  contrast/window settings for the underlying grayscale dataset<strong></strong></li>   <li>E4... it can set the windowing and color map for the  overlay dataset<strong></strong></li>   <li>E5... it can set the transparency for the overlay dataset<strong></strong></li> <bl>  <p>The Connectathon Monitor will ask the <strong>Evidence Creator </strong>to identify the <strong>Image Display</strong> system which holds the studies the Evidence Creator  used in this test :<strong></strong></p> <bl> <ul>   <li>E6...<u>For each study</u>, the Connectathon Monitor will  view the fused display on the Image Display system.  The Image Display is used to verify that the  registration and blending parameters were encoded properly by the Evidence  Creator.  If the study is not properly  displayed, the Connectathon Monitor may ask the Evidence Creator to show the  contents of the DICOM attributes in the BSPS and Spatial Registration object to  verify that they were properly encoded to help identify the source of the  problem.<strong></strong></li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (247, 1, 0, '2009-11-24 10:53:16.659', 'epoiseau', '<h3>Special Instructions</h3> <p>You should run FUS_MOD_STORE  before this test.</p>   <h3>Description</h3> <p>The purpose of this test is to verify that an Image Manager  can accept and store images, BSPS, and (optionally) Spatial Registration  objects created by Modalities in the Fusion profile.</p> <p>Storage Commitment is also tested.</p> <h3>Evaluation</h3> <p>On the <strong>Image Manager</strong>:</p> <ol> <ul>   <li>i>(we will do this verification step only if there are problems on the fusion display; otherwise we will assume that all objects were correctly stored and retrieved)</i>:  E13: verify that images, BSPS and (optionally) Spatial  Registration objects are received. 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).</li>   <li>E14: verify that the BSPS and (optionally) Spatial  Registration objects are in a different series than the images.</li>   <li>E15: verify via a log file or status display that Storage  Commitment for these objects was successful.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (248, 1, 0, '2009-11-24 10:53:16.661', 'epoiseau', '<h3>Special Instructions</h3> <p>Acquistion Modalities should complete this test on the  first day of the Connectathon to enable Evidence Creators, Image Display and  Image Archives to complete their tests that depend on this one.</p> <h3>Description </h3> <p>This test case is used to gather images and BSPS objects  at the Connectathon CENTRAL_ARCHIVE for other actors'' testing.  </p> <p> <strong><em><u> The  Acquisition Modalities must arrive at the Connectathon with representative  image sets already prepared</u></em></strong>.   In general, Acquisition Modalities should provide studies that  demonstrate the <u>entire range of capabilities/options</u> available on your  modality.  A wide variety will improve  the interoperability testing with Evidence Creator and Image Display actors.<br> </p> <p> Acquisition Modalities must store image datasets which  Evidence Creators can use to do spatial registration and blending.  You will send some image series with the same  Frame of Reference, and others with different Frame of Reference.<br> </p> <p> Acquisition Modalities which store two acquired datasets with the same Frame of Reference are also required to be able to create and store a Blended Softcopy Presentation   State.  </P. <p> Support of Spatial Registration is optional for Modalities  (see RAD TF-1:20.1).  If the Modality can  do Spatial Registration, these objects shall be stored as well.  </p> <p><p>You must use the following  conventions for creating patient names for your studies; examples follow:  <br>     <br>   -  <em>FUS_<kudu-system-name>^SameFoR<br>          </em>(use for images which ECs can use to do  blending; <br>           these series have the same Frame  of Reference)<br>   <em><br>    - FUS_<kudu-system-name>^DifferentFoR<br>           </em>(use for images which ECs can use to do  registration & blending; <br>           these series have a different  Frame of Reference)</p> <em>-  FUS_<kudu-system--name>^Blended<br>        </em>(use for studies where your Acq Modality did the  blending; <br>        you store images and BSPS (Spat  Reg optional))<em><br> </em>  </p>  <p>Storing of BSPS, Spatial Registration objects and image  series for fusion to the CENTRAL_ARCHIVE will enable Evidence Creator, Image  Manager and Image Display actors to access these datasets for their testing.<br>  </p>Acquisition Modality actors could also find time to test  directly sending these DICOM objects to Image Manager actors.</p> <h3>Evaluation</h3> <p>There is monitor formal evaluation for this test.   The purpose is to gather samples on the Central Archive.  Your samples will be checked with a DICOM validator.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (249, 1, 0, '2009-11-24 10:53:16.663', 'epoiseau', '<h3>Special Instructions</h3> <p>Acquisition Modalities and Image Managers which are also  registered as a Secure Node must execute this test.</p> <p>Run one instance of this test.</p> <h3>Description </h3> <p>This test case verifies that hybrid Modalities which are  Secure Nodes create the correct audit record when it stores Spatial  Registration (opt) and BSPS objects to an Image Manager.'' Image Managers also log this transaction.</p> <h3>Evaluation</h3> <p>Vendors should seek a monitor on the security team to evalute this test.  If you''re not sure how to find one, seek help from a connectathon manager.</p> <ul>   <li>E39: The Connectathon Monitor will verify that the Modality  sent valid audit records to the Audit Record Repository when it C-STOREd both  the BSPS and Spatial Registration object.''  The ATNA Trigger event for these two transactions is ''<strong>Begin-storing-instances</strong>''.</li>   <li>E40: The Connectathon  Monitor will verify that the Image Manager sent valid audit records to the  Audit Record Repository when it received both the BSPS and Spatial Registration  object.'' The ATNA Trigger event for these  two transactions is ''');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (250, 1, 0, '2009-11-24 10:53:16.665', 'epoiseau', '<h3>Special Instructions</h3> <p>Acquisition Modalities and Image Managers which are also  registered as a Secure Node must execute this test.</p> <p>Run one instance of this test.</p> <h3>Description </h3> <p>This test case verifies that hybrid Modalities which are  Secure Nodes create the correct audit record when it stores Spatial  Registration (opt) and BSPS objects to an Image Manager.'' Image Managers also log this transaction.</p> <h3>Evaluation</h3> <p>Vendors should seek a monitor on the security team to evalute this test.  If you''re not sure how to find one, seek help from a connectathon manager.</p> <ul>   <li>E39: The Connectathon Monitor will verify that the Modality  sent valid audit records to the Audit Record Repository when it C-STOREd both  the BSPS and Spatial Registration object.''  The ATNA Trigger event for these two transactions is ''<strong>Begin-storing-instances</strong>''.</li>   <li>E40: The Connectathon  Monitor will verify that the Image Manager sent valid audit records to the  Audit Record Repository when it received both the BSPS and Spatial Registration  object.'' The ATNA Trigger event for these  two transactions is ''');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (251, 1, 0, '2009-11-24 10:53:16.667', 'epoiseau', '<h3>Special Instructions</h3> <p>Image Displays and Image Managers which are also  registered as a Secure Node must execute this test.</p> <p>Run one instance of this test.</p> <h3>Description </h3> <p>This test case verifies that Image Displays which are  Secure Nodes create the correct audit record when it retrieves a Spatial  Registration object from an Image Manager.   You will need an Image Manager to help with this test.</p> <h3>Evaluation</h3> <p>Vendors should seek a monitor on the security team to evalute this test.  If you''re not sure how to find one, seek help from a connectathon manager.</p> <ol> <ul>   <li>E41: The Connectathon Monitor will verify that the Image  Display sent a valid audit record to the Audit Record Repository when it  retrieved a Spatial Registration object from the Image Manager.  The ATNA Trigger event for this transaction  is "<strong>Study-used</strong>".</li>   <li>E42: The Connectathon Monitor will verify that the Image  Manager sent a valid audit record to the Audit Record Repository when it sent a  Spatial Registration object from to the Image Display in response to the  retrieve request.  The ATNA Trigger event  for this transaction is "<strong>Instances  Stored</strong>".</li> </ul>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (252, 1, 0, '2009-11-24 10:53:16.669', 'epoiseau', '<h3>Special Instructions</h3> <p>Image Displays and Image Managers which are also  registered as a Secure Node must execute this test.</p> <p>Run one instance of this test.</p> <h3>Description </h3> <p>This test case verifies that Image Displays which are  Secure Nodes create the correct audit record when it retrieves a Spatial  Registration object from an Image Manager.   You will need an Image Manager to help with this test.</p> <h3>Evaluation</h3> <p>Vendors should seek a monitor on the security team to evalute this test.  If you''re not sure how to find one, seek help from a connectathon manager.</p> <ol> <ul>   <li>E41: The Connectathon Monitor will verify that the Image  Display sent a valid audit record to the Audit Record Repository when it  retrieved a Spatial Registration object from the Image Manager.  The ATNA Trigger event for this transaction  is "<strong>Study-used</strong>".</li>   <li>E42: The Connectathon Monitor will verify that the Image  Manager sent a valid audit record to the Audit Record Repository when it sent a  Spatial Registration object from to the Image Display in response to the  retrieve request.  The ATNA Trigger event  for this transaction is "<strong>Instances  Stored</strong>".</li> </ul>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (253, 1, 0, '2009-11-24 10:53:16.671', 'epoiseau', 'empty description in Kudu');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (254, 1, 0, '2009-11-24 10:53:16.674', 'epoiseau', 'empty description in Kudu');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (255, 1, 0, '2009-11-24 10:53:16.676', 'epoiseau', '<h3>Special Instructions</h3> <p>Read the description; do not enter this as a test in Kudu to be graded. These are reminders. If you can think of other reminders to help your peers, mention these to Steve Moore to get the description modified. </p> <h3>Description</h3> <p>This is the checklist of things for most of the HIMSS 2007 demonstrators who support XDS as Document Source and Document Consumer actors.</p> <ul>   <li>Check with Larry McKnight and John Donnelly about demo requirements (Monday)</li>   <li>If I am to receive an A04, use RIS Mall to send local ID for FARNSWORTH^STEVE. You should be able to do that on Monday.  (Sasi Suruliraj is in charge of the RIS Mall.)</li>   <li>If I need to send an A04 to a PIX Manager, make sure you do that as part of the MESA tests for FARNSWORTH.</li>   <li>Make sure you are on the list of A04 receivers in the HIMSS ADT/Registration system (Donnelly/Perry).     Test out that A04 starting Tuesday or Wednesday.</li>   <li>Make appropriate PIX or PDQ query (FARNSWORTH) to get the global ID </li>   <li>If Document Source, submit document.</li>   <li>If Document Consumer, use ITI-18 Stored Query to retrieve</li>   <li>Do everything with TLS.  </li>   <li>Make sure you understand the distinction between the local ID for a patient and the global ID for the affinity domain.</li> </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (256, 1, 0, '2009-11-24 10:53:16.678', 'epoiseau', '<H3>Special Instructions</H3> <p>The HITSP C19 places no constraints on the IHE XUA Transaction. The HITSP C19 Service Provider  actor must complete each of the Prerequisite tests identified below. </P>	  <H3>Prerequisite:</H3> <p>Require: </P> <li>XUA_Do_This_First <li>XUA_X-Service_Provider_Setup <li>XUA_Doc_Source_ProvideandRegister <li>XUA_PDQv3_Query <li>XUA_PDQv3_Supplier_Policy_Test <li>XUA_PDQv3_Supplier_Restrict_Access <li>XUA_PIXv3_Mgr_Policy_Test <li>XUA_PIXv3_Mgr_Restrict_Access <li>XUA_PIXv3_Query <li>XUA_QED_Query <li>XUA_QED_Restrict_Access <li>XUA_QED_Source_Policy_Test <li>XUA_Registry_Policy_Test <li>XUA_Registry_Restrict_Access <li>XUA_Repository_Policy_Test <li>XUA_Repository_Restrict_Access <li>XUA_Retrieve_Doc <li>XUA_RFD_Form_Mgr_Policy_Test <li>XUA_RFD_Form_Mgr_Restrict_Access <li>XUA_RFD_Retrieve_Submit <li>XUA_Stored_Query <li>XUA_XDR_Recipient_Policy_Test <li>XUA_XDR_Recipient_Restrict_Access</li>	                   			 <H3>Evaluation:</H3 <p>The monitor will validate that all prerequisite tests are successfully completed.</P>  <H3>Description:</H3> <p>Complete all IHE prerequisite tests. Once these tests are completed, notify the Connectathon monitor or monitors responsible for HITSP C19 Service Provider Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (257, 1, 0, '2009-11-24 10:53:16.681', 'epoiseau', '<H3>Special Instructions</H3> <p>The HITSP C19 places no constraints on the IHE XUA Transaction. The HITSP C19 Service User  actor must complete each of the Prerequisite tests identified below. </P>	  <H3>Prerequisite:</H3> <p>Require: </P> <li>XUA_Do_This_First <li>XUA_Doc_Source_ProvideandRegister <li>XUA_PDQv3_Query <li>XUA_PDQv3_Supplier_Restrict_Access <li>XUA_PIXv3_Mgr_Restrict_Access <li>XUA_PIXv3_Query <li>XUA_QED_Query <li>XUA_QED_Restrict_Access <li>XUA_Registry_Restrict_Access <li>XUA_Repository_Restrict_Access <li>XUA_Retrieve_Doc <li>XUA_RFD_Form_Mgr_Restrict_Access <li>XUA_RFD_Retrieve_Submit <li>XUA_Stored_Query <li>XUA_XDR_Recipient_Restrict_Access</li>                     			 <H3>Evaluation:</H3> <p>The monitor will validate that all prerequisite tests are successfully completed.</P>  <H3>Description:</H3> <p>Complete all IHE prerequisite tests. Once these tests are completed, notify the Connectathon monitor or monitors responsible for HITSP C19 Service User Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (258, 1, 0, '2009-11-24 10:53:16.682', 'epoiseau', '<H3>Special Instructions</H3> <p>See pre-requisite tests. All IHE Patient Demographics Supplier Required tests constrained as described in ''T23_PDQ_Constraints.xls'' located at http://xreg2.nist.gov/hit-testing/index.html  (The transport protocol for audit record communication shall be BSD syslog, per the IHE ATNA specification;  The ''provisional format'' for audit records defined in IHE ATNA shall not be use)</p>			  <li> Note:JCF - 011509 Need prerequisite test: Missing Content Consumer Actor</li>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (259, 1, 0, '2009-11-24 10:53:16.684', 'epoiseau', '<H3>Special Instructions</H3> <p>See pre-requisite tests. All IHE Patient Demographics Supplier Required tests constrained as described in ''T23_PDQ_Constraints.xls'' located at http://xreg2.nist.gov/hit-testing/index.html <a href="http://xreg2.nist.gov/hit-testing/index.html ">here</a>.  (The transport protocol for audit record communication shall be BSD syslog, per the IHE ATNA specification;  The ''provisional format'' for audit records defined in IHE ATNA shall not be use)</p>		  <li> Note: JCF - 011509 Need prerequisite test: Missing Content Creator Actors</li>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (260, 1, 0, '2009-11-24 10:53:16.686', 'epoiseau', '<H3>Special Instructions</H3>  <p>The  HITSP C28 Content Consumer  applies content constraints to the IHE EDES Document. A spreadsheet containing the full list of constraints associated with C28, can be found at <strong><a href="http://xreg2.nist.gov/hit-testing/Documents/Constraints/C28_Emergency_Care_Summary_Doc_Constraints.xls">HITSP C28 Constraints</a></strong>.</p>   <p>These constraints are verified in test ''HITSP_C28_Document_Scrutiny'' listed in the prerequisite tests below. The  HITSP C28 Content Consumer actor must complete each of the Prerequisite tests identified below. </P> 	 <H3>Prerequisite:</H3> <p>Require:</p> <li>EDES_Process_Composite_Package <li>EDES_Process_Triage_Package</li>   <H3>Evaluation:</H3 <p>The monitor will validate that all prerequisite tests are successfully completed. </P>  <H3>Description:</H3> <p>Complete all IHE and HITSP prerequisite tests. Once these tests are completed, notify the Connectathon monitor or monitors responsible for  HITSP C28 Content Consumer Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (261, 1, 0, '2009-11-24 10:53:16.688', 'epoiseau', '<H3>Special Instructions</H3>  <p>The  HITSP C28 Content Creator  applies content constraints to the IHE EDES Document. A spreadsheet containing the full list of constraints associated with C28, can be found at <strong><a href="http://xreg2.nist.gov/hit-testing/Documents/Constraints/C28_Emergency_Care_Summary_Doc_Constraints.xls">HITSP C28 Constraints</a></strong>.</p>   <p>These constraints are verified in test ''HITSP_C28_Document_Scrutiny'' listed in the prerequisite tests below. The  HITSP C28 Content Creator  actor must complete each of the Prerequisite tests identified below. </P> 	 <H3>Prerequisite:</H3> <p>Require:</p> <li>Content_Creator_Demographics <li>EDES_Publish_Composite_Package <li>EDES_Publish_Triage_Package <li>EDES_Scrutinize_Composite_Package <li>EDES_Scrutinize_Triage_Package <li>EDES_Process_Composite_Package <li>EDES_Process_Triage_Package <li>HITSP_C28_Document_Scrutiny</li>   <H3>Evaluation:</H3 <p>The monitor will validate that all prerequisite tests are successfully completed. </P>  <H3>Description:</H3> <p>Complete all IHE and HITSP prerequisite tests. Once these tests are completed, notify the Connectathon monitor or monitors responsible for  HITSP C28 Content Creator  Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (262, 1, 0, '2009-11-24 10:53:16.691', 'epoiseau', '<a href="#1">Description</a><br> <a href="#2">Minimum Document Content Requirements</a><br> <a href="#3">Submission of Test Files for Evaluation</a><br> <a href="#4">Evaluation</a><br> <a href="#5">Special Instructions</a><br> <a href="#6">Additional Resources</a><br><br>  <h2><a id=''1''>Description</a></h2> <font size=2> <p>The goal of this test is to create one valid <strong>HITSP/C28 HITSP Emergency Care Summary Document Using IHE Emergency Department Encounter Summary (EDES) Component, Version 1.1 or later</strong> and publish it in a location to make it easy for other participants to locate. This posted copy will also be used by the HITSP test monitors to verify results; see the steps below for submitting your content file.</p> </font>  <h2><a id=''2''>Minimum Document Content Requirements</a></h2> <font size=2> <p>The HITSP/C28 requires Level 2 encoding (section-level codes). For valid code sets and values (allergies, medications, etc.) use only coded values found in the <strong>HITSP/C28</strong>, <strong>HITSP/35 EHR Lab Result Terminology Component</strong>, <strong>HITSP/C80 Clinical Document and Message Terminology Component</strong>, and <strong>HISTP/C83 CDA Content Modules Component</strong>. Do not invent codes or  import other codes.</p>  <p>The minimum content that must be present in the HITSP/C28 document for any given use case is defined in the HITSP Interoperability Specifications and related documents; unless specifically prohibited by the specifications, additional content is acceptable but cannot cause a parsing error.</p>  <p>For any of the coded values (allergies, medications, etc.) use only coded values found in the HITSP/C28 and related documents (C35, C80, C83).</p> </font>  <p>Each Content Creator has been assigned one well known patient (see test Content_Creator_Demographics) with a Patient ID in the proper domain. Create a document that uses the demographics for this patient and patient ID (if possible).</p> </font>  <h2><a id=''3''>Submission of Test Files for Evaluation</a></h2> <font size=2> <p>These next steps refer to storing the completed document and reference information in the Kudu tool. You will find the page in the Kudu tool by selecting Connectathon and then Connectathon Images/CDs/Objects. The link to that page is <em><a href="system_con_object.php">Objects Information</a></em></p>  <ol> <li>Name the CDA XML document that is being tested <strong>HISTP_C28_kudu.xml</strong> where <strong><em>kudu</em> </strong> is your Kudu system name.  <ul><li><em>Note:</em> There is no obligation to render the HITSP C28 document, but providing a stylesheet for local rendering will greatly facilitate review of the document by the HITSP Monitors.</li></ul> </li><br>  <li>Validate the document against the HITSP/C28 Profile located at <a href=''http://xreg2.nist.gov/cda-validation/validation.html''>CDA Guideline Validation</a> site until the report indicates the file has no errors for the sections under review</li><br>  <li>Capture the report generated by the NIST content validator, save as <strong>HISTP_C28_kudu.htm</strong> where <strong><em>kudu</em> </strong> is your Kudu system name.</li><br>  <li>Create a zip file that contains both the test file and the report (and stylesheet if available) named <strong>HISTP_C28_kudu.zip</strong> where <strong><em>kudu</em> </strong> is your Kudu system name.</li><br>  <li>Navigate to the <em><a href="system_con_object.php">Objects Information</a></em> page within Kudu.</li><br>  <li>Enter the Patient ID, Patient Name, company name, your name, and your Kudu system name into the description of the <em>Connectathon Images/CDAs/Objects</em>.</li><br>  <li>Upload your zip file according to the instructions in the <em>Connectathon Images/CDAs/Objects</em> section of Kudu.</li><br>  <li>Update the <em>Connectathon Images/CDAs/Objects Publication/rendering page</em> page to list your document/zip file.</li><br>  <li>Notify the Connectathon monitor or monitors responsible for HITSP C28 Document Scrutiny. Make sure they are aware your document has been placed into the Kudu tool and is ready to be reviewed.</li><br>  <li>If you support XDS or any other pre-requisite, complete any test that requires you to store and register your document with a repository/registry. You do not need to complete that XDS store step in order to complete this test.</li> </ol>  </font>  <a id=''4''><H2>Evaluation</a></h2> <font size=2>  <p>This will be evaluated with the HISTP Content Creator tests.</p>  <p>The evaluation will consist of a review of the NIST validation report for the submitted file. Where there are additional content requirements, the file will be reviewed to ensure the proper content is present. This may be via an inspection of the raw text, or via a stylesheet. </font>  <h2><a id=''5''>Special Instructions</a></h2> <font size=2> <p>You are encouraged to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> </font>  <h2><a id=''6''>Additional Resources</a></h2> <font size=2> <p>The HISTP Interoperability Specifications and related documents can be freely obtained from <strong><a href="http://hitsp.org">www.hitsp.org</a></strong>. Example files, schematron rules, and other support documents, as well as a web-service interface to the validator, can be found at <strong><a href="http://xreg2.nist.gov/cda-validation/index.html">CDA Guideline Validation</a></strong> site.</p> </font>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (263, 1, 0, '2009-11-24 10:53:16.693', 'epoiseau', '<H3>Special Instructions</H3>  <p>The  HITSP C32 Component applies content constraints to the IHE XPHR Document. A spreadsheet containing the full list of constraints associated with C32, can be found at <strong><a href="http://xreg2.nist.gov/hit-testing/Documents/Constraints/Reg_Med_History_Doc_ISC-32_Constraints.xls">HITSP C32 Constraints</a></strong>.</p>   <p>These constraints are verified in test ''HITSP_C32_Document_Scrutiny'' listed in the prerequisite tests below. The  HITSP C32 Content Consumer actor must complete each of the Prerequisite tests identified below. </P> 	 <H3>Prerequisite:</H3> <p>Require:</p> <li>XPHR_Process_Extract <li>XPHR_Process_Update</li>   <H3>Evaluation:</H3 <p>The monitor will validate that all prerequisite tests are successfully completed. </P>  <H3>Description:</H3> <p>Complete all IHE and HITSP prerequisite tests. Once these tests are completed, notify the Connectathon monitor or monitors responsible for  HITSP C32 Content Consumer Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (264, 1, 0, '2009-11-24 10:53:16.696', 'epoiseau', '<H3>Special Instructions</H3>  <p>The  HITSP C32 Component applies content constraints to the IHE XPHR Document. A spreadsheet containing the full list of constraints associated with C32, can be found at <strong><a href="http://xreg2.nist.gov/hit-testing/Documents/Constraints/Reg_Med_History_Doc_ISC-32_Constraints.xls">HITSP C32 Constraints</a></strong>.</p>   <p>These constraints are verified in test ''HITSP_C32_Document_Scrutiny'' listed in the prerequisite tests below. The  HITSP C32 Content Creator actor must complete each of the Prerequisite tests identified below. </P> 	 <H3>Prerequisite:</H3> <p>Require:</p> <li>XPHR_Publish_Extract <li>XPHR_Scrutinize_Extract <li>XPHR_Process_Extract <li>HITSP_C32_Document_Scrutiny</li>  <p>Conditional - Required if Option is Selected:</p> <li>XPHR_Publish_Update <li>XPHR_Process_Update <li>XPHR_Scrutinize_Update</li>   <H3>Evaluation:</H3 <p>The monitor will validate that all prerequisite tests are successfully completed. </P>  <H3>Description:</H3> <p>Complete all IHE and HITSP prerequisite tests. Once these tests are completed, notify the Connectathon monitor or monitors responsible for  HITSP C32 Content Creator Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (265, 1, 0, '2009-11-24 10:53:16.698', 'epoiseau', '<table width="700pt"> <body> <tr> <td> <a href="#1">Description</a><br> <a href="#2">Minimum Document Content Requirements</a><br> <a href="#3">Submission of Test Files for Evaluation</a><br> <a href="#4">Evaluation</a><br> <a href="#5">Special Instructions</a><br> <a href="#6">Additional Resources</a><br><br>  <h2><a id=''1''>Description</a></h2> <font size=2> <p>The goal of this test is to create one valid <strong>HITSP/C32 Summary Documents Using HL7 Continuity of Care Document (CCD) Component, Version 2.1 or later</strong> and publish it in a location to make it easy for other participants to locate. This posted copy will also be used by the HITSP test monitors to verify results; see the steps below for submitting your content file.</p> </font>  <h2><a id=''2''>Minimum Document Content Requirements</a></h2> <font size=2> <p>The HITSP/C32 requires Level 2 encoding (section-level codes). For valid code sets and values (allergies, medications, etc.) use only coded values found in the <strong>HITSP/C32</strong>, <strong>HITSP/35 EHR Lab Result Terminology Component</strong>, <strong>HITSP/C80 Clinical Document and Message Terminology Component</strong>, and <strong>HISTP/C83 CDA Content Modules Component</strong>. Do not invent codes or  import other codes.</p>  <p>The minimum content that must be present in the HITSP/C32 document for any given use case is defined in the HITSP Interoperability Specifications and related documents; unless specifically prohibited by the specifications, additional content is acceptable but cannot cause a parsing error.</p>  <p>For any of the coded values (allergies, medications, etc.) use only coded values found in the HITSP/C32 and related documents (C35, C80, C83).</p> </font>  <p>Each Content Creator has been assigned one well known patient (see test Content_Creator_Demographics) with a Patient ID in the proper domain. Create a document that uses the demographics for this patient and patient ID (if possible).</p> </font>  <h2><a id=''3''>Submission of Test Files for Evaluation</a></h2> <font size=2> <p>These next steps refer to storing the completed document and reference information in the Kudu tool. You will find the page in the Kudu tool by selecting Connectathon and then Connectathon Images/CDs/Objects. The link to that page is <em><a href="system_con_object.php">Objects Information</a></em></p>  <ol> <li>Name the CDA XML document that is being tested <strong>HISTP_C32_kudu.xml</strong> where <strong><em>kudu</em> </strong> is your Kudu system name.  <ul><li><em>Note:</em> There is no obligation to render the HITSP C32 document, but providing a stylesheet for local rendering will greatly facilitate review of the document by the HITSP Monitors.</li></ul> </li><br>  <li>Validate the document against the NIST validation tools until the report indicates the file has no errors for the sections under review</li><br>  <li>Capture the report generated by the NIST content validator, save as <strong>HISTP_C32_kudu.htm</strong> where <strong><em>kudu</em> </strong> is your Kudu system name.</li><br>  <li>Create a zip file that contains both the test file and the report (and stylesheet if available) named <strong>HISTP_C32_kudu.zip</strong> where <strong><em>kudu</em> </strong> is your Kudu system name.</li><br>  <li>Navigate to the <em><a href="system_con_object.php">Objects Information</a></em> page within Kudu.</li><br>  <li>Enter the Patient ID, Patient Name, company name, your name, and your Kudu system name into the description of the <em>Connectathon Images/CDAs/Objects</em>.</li><br>  <li>Upload your zip file according to the instructions in the <em>Connectathon Images/CDAs/Objects</em> section of Kudu.</li><br>  <li>Update the <em>Connectathon Images/CDAs/Objects Publication/rendering page</em> page to list your document/zip file.</li><br>  <li>Notify the Connectathon monitor or monitors responsible for HITSP C32 Document Scrutiny. Make sure they are aware your document has been placed into the Kudu tool and is ready to be reviewed.</li><br>  <li>If you support XDS or any other pre-requisite, complete any test that requires you to store and register your document with a repository/registry. You do not need to complete that XDS store step in order to complete this test.</li> </ol>  </font>  <a id=''4''><H2>Evaluation</a></h2> <font size=2>  <p>This will be evaluated with the HISTP Content Creator tests.</p>  <p>The evaluation will consist of a review of the NIST validation report for the submitted file. Where there are additional content requirements, the file will be reviewed to ensure the proper content is present. This may be via an inspection of the raw text, or via a stylesheet. </font>  <h2><a id=''5''>Special Instructions</a></h2> <font size=2> <p>You are encouraged to complete this test by Day 1 at 17:00. If you complete after Day 1, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.</p> </font>  <h2><a id=''6''>Additional Resources</a></h2> <font size=2> <p>The HISTP Interoperability Specifications and related documents can be freely obtained from <strong><a href="http://hitsp.org">www.hitsp.org</a></strong>. Example files, schematron rules, and other support documents, as well as a web-service interface to the validator, can be found at <strong><a href="http://xreg2.nist.gov/cda-validation/index.html">CDA Guideline Validation</a></strong> site.</p> </font>    </font> </td> </tr> </body> <table width="700pt"> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (266, 1, 0, '2009-11-24 10:53:16.70', 'epoiseau', '<H3>Special Instructions</H3>  <p>The  HITSP C37 Content Consumer applies content constraints to the IHE XD*Lab Document. A spreadsheet containing the full list of constraints associated with C37, can be found at <strong><a href="http://xreg2.nist.gov/hit-testing/Documents/Constraints/C37_Lab_Report_Doc_Constraints.xls">HITSP C37 Constraints</a></strong>.</p>   <p>These constraints are verified in test ''HITSP_C37_Document_Scrutiny'' listed in the prerequisite tests below. The  HITSP C37 Content Consumer actor must complete each of the Prerequisite tests identified below. </P> 	 <H3>Prerequisite:</H3> <p>Required:</p> <li>XDLAB_Process_XDLAB</li>   <H3>Evaluation:</H3 <p>The monitor will validate that all prerequisite tests are successfully completed. </P>  <H3>Description:</H3> <p>Complete all IHE and HITSP prerequisite tests. Once these tests are completed, notify the Connectathon monitor or monitors responsible for  HITSP C37 Content Consumer Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (267, 1, 0, '2009-11-24 10:53:16.702', 'epoiseau', '<H3>Special Instructions</H3>  <p>The  HITSP C37 Content Creator applies content constraints to the IHE XD*Lab Document. A spreadsheet containing the full list of constraints associated with C37, can be found at <strong><a href="http://xreg2.nist.gov/hit-testing/Documents/Constraints/C37_Lab_Report_Doc_Constraints.xls">HITSP C37 Constraints</a></strong>.</p>   <p>These constraints are verified in test ''HITSP_C37_Document_Scrutiny'' listed in the prerequisite tests below. The HITSP C37 Content Creator actor must complete each of the Prerequisite tests identified below. </P> 	 <H3>Prerequisite:</H3> <p>Required:</p> <li>XDLAB_Document_Scrutiny <li>XDLAB_Load <li>XDLAB_Process_XDLAB <li>HITSP_C37_Document_Scrutiny</li>   <H3>Evaluation:</H3 <p>The monitor will validate that all prerequisite tests are successfully completed. </P>  <H3>Description:</H3> <p>Complete all IHE and HITSP prerequisite tests. Once these tests are completed, notify the Connectathon monitor or monitors responsible for HITSP C37 Content Creator Validation Test. </P>	');
