INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (268, 1, 0, '2009-11-24 10:53:16.704', '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/C37 Lab Report Document Component, Version 2.2 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/C37 requires Level 3 encoding (section-level and clinical statement/entry coding). For valid code sets and values (allergies, medications, etc.) use only coded values found in the <strong>HITSP/C37</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>. Your file should include 3-5 fully coded examples. Do not invent codes or  import other codes.</p>  <p>The minimum content that must be present in the HITSP/C37 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/C37 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_C37_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 C37 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/C37 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_C37_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_C37_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 C37 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 (269, 1, 0, '2009-11-24 10:53:16.707', 'epoiseau', '<H3>Special Instructions</H3>  <p>The  HITSP C38 Component applies content constraints to the IHE XDS-MS Document. A spreadsheet containing the full list of constraints associated with C38, can be found at <strong><a href="http://xreg2.nist.gov/hit-testing/Documents/Constraints/C38_Patient_Level_Quality_Data_Constraints.xls">HITSP C38 Constraints</a></strong>.</p>   <p>These constraints are verified in test ''HITSP_C38_Document_Scrutiny'' listed in the prerequisite tests below. The  HITSP C38 Content Creator actor must complete each of the Prerequisite tests identified below. </P> 	 <H3>Prerequisite:</H3> <p>Require:</p> <li>XDSMS_Process_Discharge	 <li>XDSMS_Process_Referrall</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 C38 Content Creator Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (270, 1, 0, '2009-11-24 10:53:16.709', 'epoiseau', '<H3>Special Instructions</H3>  <p>The  HITSP C38 Component applies content constraints to the IHE XDS-MS Document. A spreadsheet containing the full list of constraints associated with C38, can be found at <strong><a href="http://xreg2.nist.gov/hit-testing/Documents/Constraints/C38_Patient_Level_Quality_Data_Constraints.xls">HITSP C38 Constraints</a></strong>.</p>   <p>These constraints are verified in test ''HITSP_C38_Document_Scrutiny'' listed in the prerequisite tests below. The  HITSP C38 Content Creator actor must complete each of the Prerequisite tests identified below. </P> 	 <H3>Prerequisite:</H3> <p>Require:</p> <li>HITSP_C38_Document_Scrutiny</li> <p>Conditional - Required if Option is Selected: </P> <li>XDSMS_Publish_Discharge	  <li>XDSMS_Publish_Referral	  <li>XDSMS_Scrutinize_Discharge <li>XDSMS_Scrutinize_Referral <li>XDSMS_Process_Discharge <li>XDSMS_Process_Referral</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 C38 Content Creator Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (271, 1, 0, '2009-11-24 10:53:16.711', '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/C38 Patient Level Quality Data Document Using IHE Medical Summary (XDS-MS) 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/C38 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/C38</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/C38 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/C38 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_C38_TYPE_kudu.xml</strong> where <strong><em>kudu</em> </strong> is your Kudu system name and <strong><em>TYPE</em></strong> is DIS for discharge summary and REF for referral.  <ul><li><em>Note:</em> There is no obligation to render the HITSP C38 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/C38 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_C38_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_C38_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 C38 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 (272, 1, 0, '2009-11-24 10:53:16.716', 'epoiseau', '<H3>Special Instructions</H3>  <p>The  HITSP C48 Component applies content constraints to the IHE XDS-MS Document. A spreadsheet containing the full list of constraints associated with C48, can be found at <strong><a href="http://xreg2.nist.gov/hit-testing/Documents/Constraints/C48_Encounter_Doc_Constraints.xls">HITSP C48 Constraints</a></strong>.</p>   <p>These constraints are verified in test ''HITSP_C48_Document_Scrutiny'' listed in the prerequisite tests below. The  HITSP C48 Content Creator actor must complete each of the Prerequisite tests identified below. </P> 	 <H3>Prerequisite:</H3> <p>Require:</p> <li>XDSMS_Process_Discharge	 <li>XDSMS_Process_Referral</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 C48 Content Creator Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (273, 1, 0, '2009-11-24 10:53:16.718', 'epoiseau', '<H3>Special Instructions</H3>  <p>The  HITSP C48 Content Creator applies content constraints to the IHE XDS-MS Document. A spreadsheet containing the full list of constraints associated with C48, can be found at <strong><a href="http://xreg2.nist.gov/hit-testing/Documents/Constraints/C48_Encounter_Doc_Constraints.xls">HITSP C48 Constraints</a></strong>.</p>   <p>These constraints are verified in test ''HITSP_C48_Document_Scrutiny'' listed in the prerequisite tests below. The  HITSP C48 Content Creator actor must complete each of the Prerequisite tests identified below. </P> 	 <H3>Prerequisite:</H3> <p>Require:</p> <li>HITSP_C48_Document_Scrutiny</li> <p>Conditional - Required if Option is Selected: </P> <li>XDSMS_Publish_Discharge	  <li>XDSMS_Publish_Referral	  <li>XDSMS_Scrutinize_Discharge <li>XDSMS_Scrutinize_Referral <li>XDSMS_Process_Discharge	 <li>XDSMS_Process_Referral</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 C48 Content Creator Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (274, 1, 0, '2009-11-24 10:53:16.72', '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/C48 Patient Level Quality Data Document Using IHE Medical Summary (XDS-MS) Component Version 2.4 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/C48 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/C48</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/C48 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/C48 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_48_TYPE_kudu.xml</strong> where <strong><em>kudu</em> </strong> is your Kudu system name and <strong><em>TYPE</em></strong> is DIS for discharge summary and REF for referral.  <ul><li><em>Note:</em> There is no obligation to render the HITSP C48 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/C48 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_C48_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_C48_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 C48 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 (275, 1, 0, '2009-11-24 10:53:16.724', 'epoiseau', '<H3>Special Instructions:</H3> <p>The HITSP C62 Content Consumer places no constraints on the IHE CT Transaction. The HITSP C62 Content Consumer actor must complete each of the Prerequisite test identified below. </P>	  <H3>Prerequisite:</H3> <p>Requier:</p> <li>XDSSD_Process_PDF <li>XDSSD_Process_Text</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 C62 Content Consumer Validation Test.</P>		');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (276, 1, 0, '2009-11-24 10:53:16.726', 'epoiseau', '<H3>Special Instructions:</H3> <p>The HITSP C62 Content Creator places no constraints on the IHE CT Transaction. The HITSP C62 Content Creator  actor must complete each of the Prerequisite test identified below. </P>	  <H3>Prerequisite:</H3> <p>Requier:</p> <li>XDSSD_Document_Scrutiny <li>XDSSD_Load_PDF <li>XDSSD_Load_Text <li>XDSSD_Process_PDF <li>XDSSD_Process_Text <li>HITSP_C62_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 prerequisite tests. Once these tests are completed, notify the Connectathon monitor or monitors responsible for HITSP C62 Content Creator  Validation Test.</P>		');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (277, 1, 0, '2009-11-24 10:53:16.728', 'epoiseau', '<H3>Special Instructions</H3> <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 <strong>HITSP/C62 Unstructured Document Component, Version 1.0 or later</strong> and publish it in a location to make it easy for other participants to locate.</p>  <p><strong>Note:</strong> The HITSP/C62 requires a valid CDA document (header) with a nonXMLBody. For valid code sets and values use only coded values found in the <strong>HITSP/C62</strong> itself,  <strong>HITSP/C80 Clinical Document and Message Terminology Component</strong>, and the <strong>HISTP/C83 CDA Content Modules Component</strong>. </p>  <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>  <h3>Minimum Document Content Requirements</h3> <p>The minimum content that must be present in the HITSP/C62 document for any given use case is defined in the HITSP Interoperability Specifications and related documents; additional content is acceptable but cannot cause a parsing error.</p>  <H3>Evaluation</H3> <p>This will be evaluated with the HISTP Content Creator tests.</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 HITSP C62 and related documents (C83, C80). The document should contain between 3 and 5 legal coded values. Do not invent codes or  import other codes.</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>Capture the report generated by the NIST content validator that indicates the file has no errors.</li> <li>Name the document HISTP_C62_kudu.xml where <strong><em>kudu</em> </strong> is your Kudu system name.</li> <li>Upload your documents according to the instructions in the <em>Connectathon Images/CDAs/Objects</em> section of Kudu.</li> <li>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 HITSP C62 Document Scrutiny. Make sure they are aware your document has been placed into the Kudu tool.</li> <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> <p><em>Note:</em> There is no obligation to render the HITSP C62 document, but providing a local rendering will greatly facilitate review of the document by the HITSP Monitors.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (278, 1, 0, '2009-11-24 10:53:16.733', '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>Notes: JCF -011509 Need prerequisite test: Missing C76</li> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (279, 1, 0, '2009-11-24 10:53:16.735', '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> Notes:  JCF - 011509 Need prerequisite test: Missing Profile C76</li> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (280, 1, 0, '2009-11-24 10:53:16.737', 'epoiseau', '<H3>Special Instructions</H3>  <p>The HITSP C78 Immunization Document Content Consumer applies content constraints to the IHE XDS-MS Document. A spreadsheet containing the full list of constraints associated with C78, can be found at <strong><a href="http://xreg2.nist.gov/hit-testing/Documents/Constraints/C78_Patient_Level_Quality_Data_Constraints.xls">HITSP C38 Constraints</a></strong>.</p>   <p>These constraints are verified in test ''HITSP_C78_Document_Scrutiny'' listed in the prerequisite tests below. The HITSP C78 Immunization Document Content Consumer actor must complete each of the Prerequisite tests identified below. </P> 	 <H3>Prerequisite:</H3> <p>Require:</p> <li>IC_Process_Immunization_Content</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 C78 Immunization Document Content Consumer Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (281, 1, 0, '2009-11-24 10:53:16.738', 'epoiseau', '<H3>Special Instructions</H3>  <p>The HITSP C78 Immunization Document Content Creator  applies content constraints to the IHE XDS-MS Document. A spreadsheet containing the full list of constraints associated with C78, can be found at <strong><a href="http://xreg2.nist.gov/hit-testing/Documents/Constraints/C78_Patient_Level_Quality_Data_Constraints.xls">HITSP C78 Constraints</a></strong>.</p>   <p>These constraints are verified in test ''HITSP_C78_Document_Scrutiny'' listed in the prerequisite tests below. The HITSP C78 Immunization Document Content Creator  actor must complete each of the Prerequisite tests identified below. </P> 	 <H3>Prerequisite:</H3> <p>Require:</p> <li>IC_Publish_Content <li>IC_Scrutinize_Immunization_Content <li>IC_Publish_Content</li> <li>HITSP_C78_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 C78 Immunization Document Content Creator Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (282, 1, 0, '2009-11-24 10:53:16.741', '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> <p>The goal of this test is to create one valid <strong>HITSP/C78 Immunization Document Component, Version 1.0</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>  <h2><a id=''2''>Minimum Document Content Requirements</a></h2>  <p>The HITSP/C78 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/C78</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/C78 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/C78 and related documents (C35, C80, C83).</p>   <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>   <h2><a id=''3''>Submission of Test Files for Evaluation</a></h2>  <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_C78_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 C78 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_C78_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_C78_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 C78 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>    <a id=''4''><H2>Evaluation</a></h2>   <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.   <h2><a id=''5''>Special Instructions</a></h2>  <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>   <h2><a id=''6''>Additional Resources</a></h2>  <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>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (283, 1, 0, '2009-11-24 10:53:16.744', '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>JCF -011509 Need prerequisite test: Missing Profile C82</li>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (284, 1, 0, '2009-11-24 10:53:16.747', '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 Profile C82</li>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (285, 1, 0, '2009-11-24 10:53:16.749', 'epoiseau', '<H3>Special Instructions</H3> <p>The HITSP T15 Audit Transaction applies the following constraints to the IHE ATNA Record Audit Transactions: <li>The transport protocol for audit record communication shall be BSD syslog, per the IHE ATNA specification</li>  <li>The ''provisional format'' for audit records defined in IHE ATNA shall not be used</li>  <p>The HITSP T15 Audit Record Repository actor must complete each of the Prerequisite tests identified below. </P>	  <H3>Prerequisite:</H3>   <p>Require: </P>  <li>ATNA_Logging </li> <li>T17_Node</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 T15 Audit Record Repository Validation Test. </P>	 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (286, 1, 0, '2009-11-24 10:53:16.75', 'epoiseau', '<H3>Special Instructions</H3> <p>The HITSP T15 Audit Transaction applies the following constraints to the IHE ATNA Record Audit Transactions: <li>The transport protocol for audit record communication shall be BSD syslog, per the IHE ATNA specification</li>  <li>The ''provisional format'' for audit records defined in IHE ATNA shall not be used</li>  <p>The HITSP T15 Audit Record Repository actor must complete each of the Prerequisite tests identified below. </P>	  <H3>Prerequisite:</H3> <p>Require:</p> <li>T17_Node <li>ATNA_Logging <li>ATNA_Inquisition <Strong>(Questionnaire section 3)</Strong> </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 forT15 Audit Record Source Validation Test. </P>	  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (287, 1, 0, '2009-11-24 10:53:16.752', 'epoiseau', '<H3>Special Instructions</H3> <p>The HITSP T16 Consistent Time Transaction places no constraints on the IHE CT Transaction. The HITSP T16 Time Client actor must complete each of the Prerequisite tests identified below. </P>			  <H3>Prerequisite:</H3> <p>Require:</p> <li>CT_Client_Synch</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 T16 Consistent Time Transaction Time Client Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (288, 1, 0, '2009-11-24 10:53:16.754', 'epoiseau', '<H3>Special Instructions:</H3> <p>The HITSP T16 Consistent Time Transaction places no constraints on the IHE CT Transaction. The HITSP T16 Time Server actor must complete each of the Prerequisite test identified below. </P>	  <H3>Prerequisite:</H3> <p>Require:</p> <li>CT_Pool</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 T16 Time Transaction Time Server Validation Test.</P>	  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (289, 1, 0, '2009-11-24 10:53:16.757', 'epoiseau', '<H3>Special Instructions</H3> <p>The HITSP T17 Node  Transaction places no constraints on the IHE ATNA Record Audit Transactions. The HITSP T17 Node  actor must complete each of the Prerequisite tests identified below. </P>	  <H3>Prerequisite:</H3> <p>Require:</p> <li>ATNA_Inquisition <Strong> (Questioner section 2)</Strong></li>    <p>Conditional - Required if Option is Selected:</p>  <li>ATNA_Authenticate_HTTP <li>ATNA_Authentication_DICOM <li>ATNA_Authentication_HL7_V2</li> <li>ATNA_Authentication_Webservices</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 T17 Node Validation Test. </P>	 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (290, 1, 0, '2009-11-24 10:53:16.759', 'epoiseau', '<table width="700pt"> <body> <tr> <td> <H3>Special Instructions</H3>   <p>The message generated by the Patient Demographic Consumer must conform to the HITSP Constraints to the message content.  <p><strong>Note:</strong> HITSP T23 applies constraints only to the QPD segment of the PDQ Query Message. Additional content constraints are associated with the PDQ Response Message contents. A spreadsheet containing the full list of constraints associated with T23, can be found at <strong><a href="http://xreg2.nist.gov/hit-testing/Documents/Constraints/T23_PDQ_Constraints">HITSP T23 Constraints</a></strong>.</p>    <H3>Evaluation</H3>  <p>In order to verify the test, the monitor will: <li>Request the T23 Patient Demographic Consumer to show the HL7 PDQ Query message transmitted to the Patient Demographic Source <li>Validate that the HL7 Query message content conforms to the HITSP specified constraints </p>  <H3>Description</H3> <p>The goal of this test is to verify that the messages generated by the Patient Identity Consumer conform to the HITSP Constraints. </p> <p> The HITSP T23 constrains the PDQ Query QPD Segment as follows: <li>QDP-2	  - Must contain a unique value from the Patient Demographics Consumer that identifies each specific query message; an incrementing number may be used if desired <li>QPD-3.4.2 - Must be an ISO object identifier (OID) and QPD-3.4.3 must contain ''ISO'' <li>QPD-8.4.3 - Must be an ISO object identifier (OID) and QPD-8.4.3 must contain ''ISO'' <li>QPD-3.1    - The IHE Pediatric Demographic Option cited for optional constraint by the Interoperability Specification. Testing conformance to the IHE tests associated with this option is encouraged, but not required  <p>The HITSP T23 does not further constrain the PDQ Query MSH or RCP segments   <h3><a id=''6''>Additional Resources</a></h3> <p>The HISTP Interoperability Specifications and related documents can be freely obtained from <strong><a href="http://hitsp.org">www.hitsp.org</a></strong>.   </font> </td> </tr> </body> <table width="700pt"> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (291, 1, 0, '2009-11-24 10:53:16.761', 'epoiseau', '<table width="700pt"> <body> <tr> <td> <H3>Special Instructions</H3>   <p>The message generated by the Patient Demographic Source must conform to the HITSP Constraints to the message content.  <p><strong>Note:</strong> HITSP T23 applies constraints only to the QPD and PID segments of the PDQ Response Message. Additional content constraints are associated with the PDQ Query Message contents. A spreadsheet containing the full list of constraints associated with T23, can be found at <strong><a href="http://xreg2.nist.gov/hit-testing/Documents/Constraints/T23_PDQ_Constraints.xls">HITSP T23 Constraints</a></strong>.</p>    <H3>Evaluation</H3>  <p>In order to verify the test, the monitor will: <li>Request the T23 Patient Demographic Supplier to show the HL7 PDQ Response message transmitted to the Patient Demographic Consumer <li>Validate that the HL7 Query message content conforms to the HITSP specified constraints </p>  <H3>Description</H3> <p>The goal of this test is to verify that the messages generated by the Patient Identity Consumer conform to the HITSP Constraints. </p> <p> The HITSP T23 constrains the PDQ Response QPD Segment as follows: <li>QDP-3.4.2 - Must be an ISO object identifier (OID)  <li>QDP-3.4.3 - Must contain ''ISO''  <p> The HITSP T23 constrains the PDQ Response PID Segment as follows: <li> 3.4.2  Assigning Authority''s Universal ID (R)- Shall only contain ISO Object Identifier (OID)   <li>  3.4.3  Assigning Authority''s Universal ID Type (R) - Shall only contain ''ISO'' Note: ''ISO'' is the code that means ''OID'' <li>  5.3  	Middle Names (RE) - If more than one middle name is available, all available middle names shall be concatenated with separating spaces in this component   <li>  10.3  	Name of Coding System #1 (O) - HL70005  		 <li>  11.1.1 Street or Mailing Address (O)- Though not required by HL7 standard, use of national postal service standardized values is strongly recommended   <li>  11.1.2 Street Name (O) -  Though not required by HL7 standard, use of national postal service standardized values is strongly recommended  	 <li>  11.1.3 Dwelling Number (O) - Though not required by HL7 standard, use of national postal service standardized values is strongly recommended    	 <li>  11.2  	Other Designation (O) - May be used for second line of Street Address   <li>  11.3  	City (O)- Though not required by HL7 standard, use of national postal service standardized values is strongly recommended   <li>  11.4  	State / Province (O) - Though not required by HL7 standard, use of national postal service standardized values is strongly recommended  	 <li>  11.5  	ZIP / Postal Code (O) - Though not required by HL7 standard, use of national postal service standardized values is strongly recommended   	 <li>  11.6  	Country (O) - Though not required by HL7 standard, use of national postal service standardized values is strongly recommended  	  			 <li>  13  	Phone Number - Home (O) - If repetition occurs, then first occurrence shall be the primary telephone number used for patient contact. 6  <li>  13.5  	Country Code (O) - Though not required by HL7 standard, use of international and national standardized values is strongly recommended. For Country Code, if no value is present, 1assumed for United States and Canada   <li>  13.6  	Area / City Code (O) - Though not required by HL7 standard, use of international and national standardized values is strongly recommended. For Country Code, if no value is present, 1assumed for United States and Canada <li>  13.7  	Local Number (O) - Though not required by HL7 standard, use of international and national standardized values is strongly recommended. For Country Code, if no value is present, 1assumed for United States and Canada <li>  22.3  	Name of Coding System #1 (O) - HL70189   <li>  22.6  	(O) <li> Values for components 22.4 and 22.5 shall be selected from the U. S. Government Race and Ethnicity Codes:  Available from: Health Information and Surveillance Systems Board, Centers for Disease Control and Prevention, Mailstop C08, 1600 Clifton Road, NE, Atlanta, Georgia 30333  <p>The HITSP T23 does not further constrain the PDQ Query MSH or RCP segments   <h3><a id=''6''>Additional Resources</a></h3> <p>The HISTP Interoperability Specifications and related documents can be freely obtained from <strong><a href="http://hitsp.org">www.hitsp.org</a></strong>.   </font> </td> </tr> </body> <table width="700pt"> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (292, 1, 0, '2009-11-24 10:53:16.764', 'epoiseau', '<H3>Special Instructions</H3>  <p>The  HITSP T23 Patient Demographics Consumer Transaction applies the following constraints to the IHE PDQ Query Message: <li>QDP-2	  - Must contain a unique value from the Patient Demographics Consumer that identifies each specific query message; an incrementing number may be used if desired <li>QPD-3.4.2 - Must be an ISO object identifier (OID) and QPD-3.4.3 must contain ''ISO'' <li>QPD-8.4.3 - Must be an ISO object identifier (OID) and QPD-8.4.3 must contain ''ISO'' <li>QPD-3.1    - The IHE Pediatric Demographic Option cited for optional constraint by the Interoperability Specification. Testing conformance to the IHE tests associated with this option is encouraged, but not required  <p>These constraints are verified in test ''HITSP_T23_PDQ_PDC_MSG_CNST'' listed in the prerequisite tests below. The  HITSP T23 Patient Demographics Consumer actor must complete each of the Prerequisite tests identified below. </P> 	 <H3>Prerequisite:</H3> <p>Require:</p> <li>PDQ_Exact_Name <li>PDQ_Multiple_Query</li> <li>HITSP_T23_PDQ_PDC_MSG_CNST</li> <p>Conditional - Required if Option is Selected: </P> <li>PDQ_PDO_Query_with_Twin_Data <li>PDQVisitQuery</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 T23 Patient Demographics Consumer Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (293, 1, 0, '2009-11-24 10:53:16.766', 'epoiseau', '<H3>Special Instructions</H3>  <p>The  HITSP T23 Patient Demographics Supplier Transaction applies the following constraints to the IHE PDQ Response Message: <li>QDP-3.4.2 (R) - Must be an ISO object identifier (OID)  <li>QDP-3.4.3 (R) - Must contain ''ISO'' <li> 3.4.2  Assigning Authority''s Universal ID (R)- Shall only contain ISO Object Identifier (OID)   <li> 3.4.3  Assigning Authority''s Universal ID Type (R) - Shall only contain ''ISO'' Note: ''ISO'' is the code that means ''OID'' <li> 5.3  	Middle Names (RE) - If more than one middle name is available, all available middle names shall be concatenated with separating spaces in this component   <li>  10.3  	Name of Coding System #1 (O) - HL70005  		 <li>  11.1.1 Street or Mailing Address (O)- Though not required by HL7 standard, use of national postal service standardized values is strongly recommended   <li>  11.1.2 Street Name (O) -  Though not required by HL7 standard, use of national postal service standardized values is strongly recommended  	 <li>  11.1.3 Dwelling Number (O) - Though not required by HL7 standard, use of national postal service standardized values is strongly recommended    	 <li>  11.2  	Other Designation (O) - May be used for second line of Street Address   <li>  11.3  	City (O)- Though not required by HL7 standard, use of national postal service standardized values is strongly recommended   <li>  11.4  	State / Province (O) - Though not required by HL7 standard, use of national postal service standardized values is strongly recommended  	 <li>  11.5  	ZIP / Postal Code (O) - Though not required by HL7 standard, use of national postal service standardized values is strongly recommended   	 <li>  11.6  	Country (O) - Though not required by HL7 standard, use of national postal service standardized values is strongly recommended  	  			 <li>  13  	Phone Number - Home (O) - If repetition occurs, then first occurrence shall be the primary telephone number used for patient contact. 6  <li>  13.5  	Country Code (O) - Though not required by HL7 standard, use of international and national standardized values is strongly recommended. For Country Code, if no value is present, 1assumed for United States and Canada   <li>  13.6  	Area / City Code (O) - Though not required by HL7 standard, use of international and national standardized values is strongly recommended. For Country Code, if no value is present, 1assumed for United States and Canada <li>  13.7  	Local Number (O) - Though not required by HL7 standard, use of international and national standardized values is strongly recommended. For Country Code, if no value is present, 1assumed for United States and Canada <li>  22.3  	Name of Coding System #1 (O) - HL70189   <li>  22.6  	(O) <li> Values for components 22.4 and 22.5 shall be selected from the U. S. Government Race and Ethnicity Codes:  Available from: Health Information and Surveillance Systems Board, Centers for Disease Control and Prevention, Mailstop C08, 1600 Clifton Road, NE, Atlanta, Georgia 30333   <p>These constraints are verified in test ''HITSP_T23_PDQ_PDS_MSG_CNST'' listed in the prerequisite tests below. The  HITSP T23 Patient Demographics Supplier actor must complete each of the Prerequisite tests identified below. </P>  <H3>Prerequisite:</H3> <p>Require:</p> <li>PDQ_Load <li>PDQ_Continuation_Test <li>PDQ_Exact_Name <li>PDQ_Multiple_Query <li>HITSP_T23_PDQ_PDS_MSG_CNST <p>Conditional - Required if Option is Selected: </P> <li>PDQ_PDO_Load <li>PDQ_PDO_Query_with_Twin_Data <li>PDQVisitQuery</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 T23 Patient Demographics Supplier Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (294, 1, 0, '2009-11-24 10:53:16.768', 'epoiseau', '<H3>Special Instructions</H3> <p>The HITSP T29 Notification of Document Availability Transaction places no constraints on the IHE NAV Transaction. The HITSP T29 Notification Receiver actor must complete each of the Prerequisite tests identified below. </P>	 <H3>Prerequisite:</H3> <p>Require:</p> <li>NAV_Notification_Exchange</li> <p>Conditional - Required if Option is Selected:</P> <li>NAV_Acknowledgement_Option </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 T29 Notification Receiver Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (295, 1, 0, '2009-11-24 10:53:16.77', 'epoiseau', '<H3>Special Instructions</H3> <p>The HITSP T29 Notification of Document Availability Transaction places no constraints on the IHE NAV Transaction. The HITSP T29 Notification Sender actor must complete each of the Prerequisite tests identified below. </P>	 <H3>Prerequisite:</H3>  <p>Require: </P>   <li>NAV_Notification_Exchange</li>  <p>Conditional - Required if Option is Selected: </P>  <li>NAV_Acknowledgement_Option </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 T29 Notification Sender Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (296, 1, 0, '2009-11-24 10:53:16.774', 'epoiseau', '<H3>Special Instructions</H3> <p>The HITSP T31 Document Recipient Transaction places no constraints on the IHE XDR Transaction. The HITSP T31 Document Recipient actor must complete each of the Prerequisite tests identified below. </P>			  <H3>Prerequisite:</H3> <p>Require:</p> <li>XDR_Doc_Source_Recipient</li> <p>Conditional - Required if Option is Selected:</p> <li>BPPC_XDR_Enforcement</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 T31 Document Recipient Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (297, 1, 0, '2009-11-24 10:53:16.776', 'epoiseau', '<H3>Special Instructions</H3> <p>The HITSP T31 Document Source Transaction places no constraints on the IHE XDR Transaction. The HITSP T31 Document Source actor must complete each of the Prerequisite tests identified below. </P>			  <H3>Prerequisite:</H3> <p>Require:</p> <li>XDR_Doc_Source_Recipient</li> <p>Conditional - Required if Option is Selected:</p> <li>BPPC_XDR_Enforcement</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 T31 Document Source Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (298, 1, 0, '2009-11-24 10:53:16.778', 'epoiseau', '<H3>Special Instructions:</H3> <p>The latest HITSP T33 Portable Media Creator places no constraints on the IHE XDM Transaction. Prior releases of T33 restricted physical media to either CD-R or USB, but imposed no additional requirements on the IHE XDM Transaction. The HITSP T33 Portable Media Creator  actor must complete each of the Prerequisite test identified below. </P>	  <H3>Prerequisite:</H3> <p>Require:</p> <li>XDM_Audit_Export</li>  <p>Conditional - Required if Option is Selected:</p> <li>BPPC_Portable_Media_Creator_Enforcement	 <li>BPPC_Portable_Media_Importer_Enforcement <li>XDM_CD-R_Creation <li>XDM_USB_Creation <li>XDM_CD-R_Import <li>XDM_USB_Import <li>XDM_Zip_over_Email_Option</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 T33 Portable Media Creator Validation Test.</P>	  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (299, 1, 0, '2009-11-24 10:53:16.78', 'epoiseau', '<H3>Special Instructions:</H3> <p>The latest HITSP T33 Portable Media Creator places no constraints on the IHE XDM Transaction. Prior releases of T33 restricted physical media to either CD-R or USB, but imposed no additional requirements on the IHE XDM Transaction.  The HITSP T33 Portable Media Importer actor must complete each of the Prerequisite test identified below. </P>	  <H3>Prerequisite:</H3> <p>Require:</p> <li>XDM_Audit_Import</li>  <p>Conditional - Required if Option is Selected:</p>	 <li>BPPC_Portable_Media_Importer_Enforcement <li>XDM_CD-R_Import <li>XDM_USB_Impor <li>XDM_Zip_over_Email_Optiont</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 T33 Portable Media Importer Validation Test.</P>	  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (300, 1, 0, '2009-11-24 10:53:16.783', '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 receive and display one valid <strong>HITSP/T63 Emergency Message Distribution Element Alert Message</strong> and provide the associated screenshots to the HITSP test monitors to verify results; see the steps below for submitting your content file.</p> </font>  <h2><a id=''2''>Minimum Content Requirements</a></h2> <font size=2> <p>The HITSP/T63 requires conformance to the OASIS EDXL-DE. Content details are available at ''http://www.oasis-open.org/committees/download.php/17228/EDXL-DE_Spec_v1.0.pdf''</p>  <p>The minimum content that must be present in the HITSP/T63 message 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.</p> </font>  <h2><a id=''3''>Submission of Test Files for Evaluation</a></h2> <font size=2>  <li>Receive a valid HITSP/T63 Alert message.   <li>Notify the Connectathon monitor or monitors responsible for HITSP T63 Message Transmitter Test. Show the monitor the application receipt of the T63 message. Capture screenshots of the message as communicated to the user.</li><br> </ol>  </font>  <a id=''4''><H2>Evaluation</a></h2> <font size=2>  <p>This will be evaluated by examining the application and screenshots associated with receipt of the T63 message.</p> </font>  <h2><a id=''5''>Special Instructions</a></h2> <font size=2> </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>. </font>  </font> </td> </tr> </body> <table width="700pt">');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (301, 1, 0, '2009-11-24 10:53:16.785', '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/T63 Emergency Message Distribution Element Alert Message</strong> and provide the message and associated screenshots to the HITSP test monitors to verify results; see the steps below for submitting your content file.</p> </font>  <h2><a id=''2''>Minimum Content Requirements</a></h2> <font size=2> <p>The HITSP/T63 requires conformance to the OASIS EDXL-DE. Content details are available at ''http://www.oasis-open.org/committees/download.php/17228/EDXL-DE_Spec_v1.0.pdf''</p>  <p>The minimum content that must be present in the HITSP/T63 message 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.</p> </font>  <h2><a id=''3''>Submission of Test Files for Evaluation</a></h2> <font size=2>  <li>Create a zip file that contains both the test message and the screenshots named <strong>HISTP_T63_kudu.zip</strong> where <strong><em>kudu</em> </strong> is your Kudu system name.</li><br>  <li>Notify the Connectathon monitor or monitors responsible for HITSP T63 Message Transmitter Test. Provide the monitor with the zip file containing the message and the screenshots</li><br> </ol>  </font>  <a id=''4''><H2>Evaluation</a></h2> <font size=2>  <p>This will be evaluated by examining the T63 message and screenshots.</p> </font>  <h2><a id=''5''>Special Instructions</a></h2> <font size=2> </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>. </font>  </font> </td> </tr> </body> <table width="700pt">');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (302, 1, 0, '2009-11-24 10:53:16.789', 'epoiseau', '<H3>Special Instructions</H3>  <p>The  HITSP T64 DNS Server Transaction places no constraints on the IHE PWP Transaction. The  HITSP T64 DNS Server actor must complete each of the Prerequisite tests identified below. </P>	 			 <li>Notes: -JCF Missing Profile T64 <H3>Prerequisite:</H3> <p>Require:</p> <li>PWP_Consumer_Config</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 T64 DNS Server  Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (303, 1, 0, '2009-11-24 10:53:16.79', 'epoiseau', '<H3>Special Instructions</H3>  <p>The  HITSP T64 Personnel White Pages Consumer Transaction places no constraints on the IHE PWP Transaction. The  HITSP T64 Personnel White Pages Consumer actor must complete each of the Prerequisite tests identified below. </P>	 			  <H3>Prerequisite:</H3> <p>Require:</p> <li>PWP_Consumer_Config <li>PWP_Bind <li>PWP_Query</li> <p>Optional:</p> <li>PWPDNS</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 T64 Personnel White Pages Consumer Validation Test. </P>				');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (304, 1, 0, '2009-11-24 10:53:16.792', 'epoiseau', '<H3>Special Instructions</H3>  <p>The  HITSP T64 Personnel White Pages Directory Transaction places no constraints on the IHE PWP Transaction. The  HITSP T64 Personnel White Pages Directory actor must complete each of the Prerequisite tests identified below. </P>	 			  <H3>Prerequisite:</H3> <p>Require:</p> <li>PWP_Load <li>PWP_Bind <li>PWPDNS <li>PWP_Query</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 T64 Personnel White Pages Directory Validation Test. </P>				 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (305, 1, 0, '2009-11-24 10:53:16.794', 'epoiseau', '<H3>Special Instructions</H3>  <p>The HITSP T66 Value Set Consumer Transaction places no constraints on the IHE SVS Transaction. The  HITSP T66 Value Set Consumer actor must complete each of the Prerequisite tests identified below. </P>	  <H3>Prerequisite:</H3> <p>Require:</p> <li>None</li> <p>Conditional - Required if Option is Selected: </P> <li>SVS_Retrieve_Value_Sets_HTTP <li>SVS_Retrieve_Value_Sets_SOAP</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 T66 Value Set Consumer Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (306, 1, 0, '2009-11-24 10:53:16.796', 'epoiseau', '<H3>Special Instructions</H3>  <p>The HITSP T66 Value Set Repository Transaction places no constraints on the IHE SVS Transaction. The  HITSP T66 Value Set Repository actor must complete each of the Prerequisite tests identified below. </P>	  <H3>Prerequisite:</H3> <p>Require:</p> <li>SVS_Load_Repository <li>SVS_Retrieve_Value_Sets_HTTP <li>SVS_Retrieve_Value_Sets_SOAP</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 T66 Value Set Repository Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (307, 1, 0, '2009-11-24 10:53:16.799', 'epoiseau', '<H3>Special Instructions</H3>  <p>The HITSP T67 Referral Dispatcher Transaction places no constraints on the IHE DRR Transaction. The  HITSP T67 Referral Dispatcher actor must complete each of the Prerequisite tests identified below. </P>	 <p>See pre-requisite tests. Referral Request must be represented by a Document (content not specified here). Used with either HITSP/TP13, HITSP/T31, or HITSP/T33.</p>   <H3>Prerequisite:</H3> <p>Require:</p> <li>DRR_Retrieve_Referral_Folder</li> <p>Conditional - Required if Option is Selected: </P> <li>DRR_Request_Referral_option</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 T67 Referral Dispatcher Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (308, 1, 0, '2009-11-24 10:53:16.801', 'epoiseau', '<H3>Special Instructions</H3>  <p>The HITSP T67 Referral Requestor Transaction places no constraints on the IHE DRR Transaction. The  HITSP T67 Referral Requestor  actor must complete each of the Prerequisite tests identified below. </P>	 <p>See pre-requisite tests. Referral Request must be represented by a Document (content not specified here). Used with either HITSP/TP13, HITSP/T31, or HITSP/T33.</p>  		 <H3>Prerequisite:</H3> <p>Require:</p> <li>DRR_Retrieve_Referral_Folder <li>DRR_Print_Paper_Referral</li> <p>Conditional - Required if Option is Selected: </P> <li>DRR_Request_Referral_option</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 T67 Referral Requestor  Validation Test. </P>	 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (309, 1, 0, '2009-11-24 10:53:16.803', 'epoiseau', 'The T81 Test Tool is designed to be used by HIT developers and implementers during the development of software that implements the URL-based implementation of the Conext-aware Information Retrieval (infobutton) standard. These tools can be used for self-testing to determine if a URL is correct with respect to the specifications identified within the following HITSP constructs. <br> <H1>Special Instructions</h1>  For complete information go to <a href=''http://xreg2.nist.gov:8080/t81/index.html''>T81 Test Tool</a> site, from this site you can also navigate to example files and other useful information.<br><br>  The test is performed by doing a post to <a href=''http://xreg2.nist.gov:8080/t81/process.jsp''>http://xreg2.nist.gov:8080/t81/process.jsp</a>  <H1>Evaluation</H3> This test will require the presence of the monitor who will check that the test has completed without error. ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (310, 1, 0, '2009-11-24 10:53:16.804', 'epoiseau', '<H3>Special Instructions</H3>  <p>The HITSP T81 Knowledge_Resource  Transaction places no constraints on the HL7 Info Button profile. </P>	  <p>Please contact a HITSP monitor prior to starting this test (Table G10)</p>  <H3>Evaluation:</H3 <p>The monitor will validate that the test is successfully completed. </P> ');












INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (323, 1, 0, '2009-11-24 10:53:16.832', 'epoiseau', '<H3>Special Instructions</H3>  <p>The HITSP TP20 Access Control Service  Transaction places no constraints on the IHE QED Transaction. The HITSP TP20 Access Control Service actor must complete each of the Prerequisite tests identified below. </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>Notes: JCF - 011509 Need prerequisite test: </p> 	 <H3>Prerequisite:</H3> <p>Require:</p> <li></li> <p>Conditional - Required if Option is Selected: </P> <li></li> <p>Optional:</p>			  <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 TP20 Access Control Service Validation Test. </P>	 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (324, 1, 0, '2009-11-24 10:53:16.834', 'epoiseau', '<H3>Special Instructions</H3>  <p>The HITSP TP20 Service Provider Transaction places no constraints on the IHE QED Transaction. The HITSP TP20 Service Provider actor must complete each of the Prerequisite tests identified below. </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>Notes: JCF - 011509 Need prerequisite test: </p> 	 <H3>Prerequisite:</H3> <p>Require:</p> <li></li> <p>Conditional - Required if Option is Selected: </P> <li></li> <p>Optional:</p>			  <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 TP20 Service Provider Validation Test. </P>	 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (325, 1, 0, '2009-11-24 10:53:16.836', 'epoiseau', '<H3>Special Instructions</H3>  <p>The HITSP TP20 Service User Transaction places no constraints on the IHE QED Transaction. The HITSP TP20 Service User actor must complete each of the Prerequisite tests identified below. </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>Notes: JCF - 011509 Need prerequisite test: Missing TP20 Profile.</p> 	 <H3>Prerequisite:</H3> <p>Require:</p> <li></li> <p>Conditional - Required if Option is Selected: </P> <li></li> <p>Optional:</p>			  <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 forHITSP TP20 Service User Validation Test. </P>	 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (326, 1, 0, '2009-11-24 10:53:16.838', 'epoiseau', '<H3>Special Instructions</H3> <p>The HITSP TP21 Query for Existing Data Transaction places no constraints on the IHE QED Transaction. The HITSP TP21 Clinical Data Consumer actor must complete each of the Prerequisite tests identified below. </P>	 <H3>Prerequisite:</H3> <p>Require: </P>  <li>None</li> <p>Conditional - Required if Option is Selected: </P>  <li>QED_QueryDiagnosticResults </li>  <li>QED_QueryImmunizations </li>                <li>QED_QueryMedications</li>                      <li>QED_QueryProblemsAllergies</li>                       <li>QED_QueryProfessionalServices</li>                        <li>QED_QueryVitalSigns</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 TP21 Clinical Data Consumer Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (327, 1, 0, '2009-11-24 10:53:16.841', 'epoiseau', '<H3>Special Instructions</H3> <p>The HITSP TP21 Query for Existing Data Transaction places no constraints on the IHE QED Transaction. The HITSP TP21 Clinical Data Source actor must complete each of the Prerequisite tests identified below. </P>	 <H3>Prerequisite:</H3> <p>Require: </P>  <li>QED_Preload</li> <p>Conditional - Required if Option is Selected: </P>  <li>QED_QueryDiagnosticResults </li>  <li>QED_QueryImmunizations </li>                <li>QED_QueryMedications</li>                      <li>QED_QueryProblemsAllergies</li>                       <li>QED_QueryProfessionalServices</li>                        <li>QED_QueryVitalSigns</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 TP21 Clinical Data Source Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (328, 1, 0, '2009-11-24 10:53:16.843', 'epoiseau', '<H3>Special Instructions</H3> <p>The HITSP TP21 Query for Existing Data Transaction places no constraints on the IHE QED Transaction. The HITSP TP21 Clinical Data Consumer actor must complete each of the Prerequisite tests identified below. </P>	 <H3>Prerequisite:</H3> </p>Require:</p>  <li>QED_Preload </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 TP21 Content Source QED Preload Validation Test. </P>	                   ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (329, 1, 0, '2009-11-24 10:53:16.846', 'epoiseau', '<table width="700pt"> <body> <tr> <td> <H3>Special Instructions</H3>   <p>The message generated by the Patient Identity Consumer must conform to the HITSP Constraints to the message content.  <p><strong>Note:</strong> HITSP TP22 applies constraints only to the QPD segment of the PIX Query Message. Additional content constraints are associated with the PIX Feed Message and the PIX Response message contents. A spreadsheet containing the full list of constraints associated with TP22, can be found at <strong><a href="http://xreg2.nist.gov/hit-testing/Documents/Constraints/TP22_Patient_Identity_CrossRef_Constraints.xls">HITSP TP22 Constraints</a></strong>.</p>    <H3>Evaluation</H3>  <p>In order to verify the test, the monitor will: <li>Request the TP22 Patient Identity Consumer to show the HL7 PIX Query message transmitted to the PIX Manager <li>Validate that the HL7 Query message content conforms to the HITSP specified constraints </p>  <H3>Description</H3> <p>The goal of this test is to verify that the messages generated by the Patient Identity Consumer conform to the HITSP Constraints. </p> <p> The HITSP TP22 constrains the PIX Query QPD Segment as follows: <li>QPD-3.4.2 Shall only contain ISO Object Identifier (OID)   <li>QPD-3.4.3 Must Contain "ISO"    <p>The HITSP TP22 does not further constrain the PIX Query MSH or RCP segments   <h3><a id=''6''>Additional Resources</a></h3> <p>The HISTP Interoperability Specifications and related documents can be freely obtained from <strong><a href="http://hitsp.org">www.hitsp.org</a></strong>.   </font> </td> </tr> </body> <table width="700pt"> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (330, 1, 0, '2009-11-24 10:53:16.847', 'epoiseau', '<table width="700pt"> <body> <tr> <td> <H3>Special Instructions</H3>   <p>The messages generated by the Patient Identity Manager must conform to the HITSP Constraints to the message content.  <p><strong>Note:</strong> HITSP TP22 applies constraints only to the PID and QPD segments of the PIX Response Message. Additional content constraints are associated with the PIX Feed Message and the PIX Query message contents. A spreadsheet containing the full list of constraints associated with TP22, can be found at <strong><a href="http://xreg2.nist.gov/hit-testing/Documents/Constraints/TP22_Patient_Identity_CrossRef_Constraints.xls">HITSP TP22 Constraints</a></strong>.</p>   <H3>Evaluation</H3>  <p>In order to verify the test, the monitor will: <li>Request the TP22 Patient Identity Manager to show the HL7 PIX Response message transmitted to the PIX Consumer <li>Validate that the HL7 Feed message content conforms to the HITSP specified constraints </p>  <H3>Description</H3> <p>The goal of this test is to verify that the messages generated by the Patient Identity Manager conforms to the HITSP Constraints. </p> <p> The HITSP TP22 constrains the PIX Response QPD Segment as follows: <li>QPD-3.4.2  must be an ISO object identifier ISO Object Identifier (OID) <li>QPD-3.4.3 Must Contain  "ISO" Note: "ISO" is the code that means "OID"   <p> The HITSP TP22 constrains the PIX Response PID Segment as follows: <li>PID-3.4.2   Assigning Authority''s Universal ID (R) - Shall only contain ISO Object Identifier (OID)   <li>PID-3.4.3   Assigning Authority''s Universal ID Type (R) - Shall only contain "ISO" Note: "ISO" is the code that means "OID"  <p>The HITSP TP22 does not further constrain the PIX Response MSH, MSA, ERR, or QAK segments   <h3><a id=''6''>Additional Resources</a></h3> <p>The HISTP Interoperability Specifications and related documents can be freely obtained from <strong><a href="http://hitsp.org">www.hitsp.org</a></strong>.  </font> </td> </tr> </body> <table width="700pt">');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (331, 1, 0, '2009-11-24 10:53:16.849', 'epoiseau', '<table width="700pt"> <body> <tr> <td> <H3>Special Instructions</H3>   <p>The messages generated by the Patient Identity Source must conform to the HITSP Constraints to the message content.  <p><strong>Note:</strong> HITSP TP22 applies constraints only to the PID and MRG segments of the PIX Feed Message. Additional content constraints are associated with the PIX Query Message and the PIX Response message contents. A spreadsheet containing the full list of constraints associated with TP22, can be found at <strong><a href="http://xreg2.nist.gov/hit-testing/Documents/Constraints/TP22_Patient_Identity_CrossRef_Constraints.xls">HITSP TP22 Constraints</a></strong>.</p>   <H3>Evaluation</H3>  <p>In order to verify the test, the monitor will: <li>Request the TP22 Patient Identity Source to show the HL7 PIX Feed message transmitted to the PIX Manager <li>Validate that the HL7 Feed message content conforms to the HITSP specified constraints </p>  <H3>Description</H3> <p>The goal of this test is to verify that the message generated by the Patient Identity Source conforms to the HITSP Constraints. </p> <p> The HITSP TP22 constrains the PIX Feed MRG Segment as follows: <li>MRG-1.4.2  Assigning Authority''s Universal ID - Shall only contain ISO Object Identifier (OID)   <li>MRG-1.4.3 Assigning Authority''s Universal ID Type - Shall only contain "ISO" Note: "ISO" is the code that means "OID"  <li>MRG-7.3   Middle Names - If more than one middle name is available, all available middle names shall be concatenated with separating spaces in this component      <p> The HITSP TP22 constrains the PIX Feed PID Segment as follows: <li>PID-3.4.2   Assigning Authority''s Universal ID (R) - Shall only contain ISO Object Identifier (OID)   <li>PID-3.4.3   Assigning Authority''s Universal ID Type (R) - Shall only contain "ISO" Note: "ISO" is the code that means "OID" <li>PID-5.3      Middle Names (RE) - If more than one middle name is available, all available middle names shall be concatenated with separating spaces in this component   <li>PID-11.1.1 Street or Mailing Address (O) - Though not required by HL7 standard, use of national postal service standardized values is strongly recommended   <li>PID-11.1.2 Street Name (O) - Though not required by HL7 standard, use of national postal service standardized values is strongly recommended   	 <li>PID-11.1.3 Dwelling Number (O) - Though not required by HL7 standard, use of national postal service standardized values is strongly recommended    	 <li>PID-11.2   Other Designation (O) - May be used for second line of Street Address   <li>PID-11.3   City  (O) - Though not required by HL7 standard, use of national postal service standardized values is strongly recommended   <li>PID-11.4  State / Province (O) - Though not required by HL7 standard, use of national postal service standardized values is strongly recommended    	 <li>PID-11.5  ZIP / Postal Code (O) - Though not required by HL7 standard, use of national postal service standardized values is strongly recommended   	 <li>PID-13    Phone Number (O) - Home - If repetition occurs, then first occurrence shall be the primary telephone number used for patient contact. <li>PID-13.5  Country Code (O) - Though not required by HL7 standard, use of international and national standardized values is strongly recommended. For Country Code, if no value is present, 1 assumed for United States and Canada   <li>PID-13.6  Area / City Code (O) - Though not required by HL7 standard, use of international and national standardized values is strongly recommended. For Country Code, if no value is present, 1 assumed for United States and Canada    	 <li>PID-13.7  Local Number (O) - Though not required by HL7 standard, use of international and national standardized values is strongly recommended. For Country Code, if no value is present, 1 assumed for United States and Canada   	 <li>Though not required by HL7 standard, use of the International Standards Organization Codes for Representation of Names and Countries, ISO-3166, is strongly recommended; available from:  American National Standards Institute  25 West 43rd Street, Fourth Floor  New York, NY 10036    <p>The HITSP TP22 does not further constrain the PIX Feed MSH or EVN segments   <h3><a id=''6''>Additional Resources</a></h3> <p>The HISTP Interoperability Specifications and related documents can be freely obtained from <strong><a href="http://hitsp.org">www.hitsp.org</a></strong>.   </font> </td> </tr> </body> <table width="700pt">');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (332, 1, 0, '2009-11-24 10:53:16.852', 'epoiseau', '<H3>Special Instructions</H3>  <p>The HITSP TP22 Patient Identity Consumer Transaction applies the following constraints to the IHE PIX Query message: <li>QPD-3.4.2 Shall only contain ISO Object Identifier (OID)   <li>QPD-3.4.3 Must Contain "ISO"    <p>These constraints are verified in test ''HITSP_TP22_PIX_Consumer_MSG_CNST'' listed in the prerequisite tests below. The HITSP TP22 Patient Identity Consumer  actor must complete each of the Prerequisite tests identified below. </P>  <H3>Prerequisite:</H3>    <p>Require:<P> <li>HL7_Proxy_Test <li>PIX_Client</li> <li>HITSP_TP22_PIX_Consumer_MSG_CNST</li> <p>Conditional - Required if Option is Selected: </P> <li>PIX_CLIENT_Upd_Notif_Option</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 TP22 Patient Identity Consumer Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (333, 1, 0, '2009-11-24 10:53:16.853', 'epoiseau', '<H3>Special Instructions</H3>  <p>The HITSP TP22 Patient Identity Source Transaction applies the following constraints to the IHE PIX Feed Message: <li>MRG-1.4.2  Assigning Authority''s Universal ID - Shall only contain ISO Object Identifier (OID)   <li>MRG-1.4.3 Assigning Authority''s Universal ID Type - Shall only contain "ISO" Note: "ISO" is the code that means "OID"  <li>MRG-7.3   Middle Names - If more than one middle name is available, all available middle names shall be concatenated with separating spaces in this component     <li>PID-3.4.2   Assigning Authority''s Universal ID (R) - Shall only contain ISO Object Identifier (OID)   <li>PID-3.4.3   Assigning Authority''s Universal ID Type (R) - Shall only contain "ISO" Note: "ISO" is the code that means "OID" <li>PID-5.3      Middle Names (RE) - If more than one middle name is available, all available middle names shall be concatenated with separating spaces in this component   <li>PID-11.1.1 Street or Mailing Address (O) - Though not required by HL7 standard, use of national postal service standardized values is strongly recommended   <li>PID-11.1.2 Street Name (O) - Though not required by HL7 standard, use of national postal service standardized values is strongly recommended   	 <li>PID-11.1.3 Dwelling Number (O) - Though not required by HL7 standard, use of national postal service standardized values is strongly recommended    	 <li>PID-11.2   Other Designation (O) - May be used for second line of Street Address   <li>PID-11.3   City  (O) - Though not required by HL7 standard, use of national postal service standardized values is strongly recommended   <li>PID-11.4  State / Province (O) - Though not required by HL7 standard, use of national postal service standardized values is strongly recommended    	 <li>PID-11.5  ZIP / Postal Code (O) - Though not required by HL7 standard, use of national postal service standardized values is strongly recommended   	 <li>PID-13    Phone Number (O) - Home - If repetition occurs, then first occurrence shall be the primary telephone number used for patient contact. <li>PID-13.5  Country Code (O) - Though not required by HL7 standard, use of international and national standardized values is strongly recommended. For Country Code, if no value is present, 1 assumed for United States and Canada   <li>PID-13.6  Area / City Code (O) - Though not required by HL7 standard, use of international and national standardized values is strongly recommended. For Country Code, if no value is present, 1 assumed for United States and Canada    	 <li>PID-13.7  Local Number (O) - Though not required by HL7 standard, use of international and national standardized values is strongly recommended. For Country Code, if no value is present, 1 assumed for United States and Canada   	 <li>Though not required by HL7 standard, use of the International Standards Organization Codes for Representation of Names and Countries, ISO-3166, is strongly recommended; available from:  American National Standards Institute  25 West 43rd Street, Fourth Floor  New York, NY 10036    <p>These constraints are verified in test ''HITSP_TP22_PIX_SRC_MSG_CNST'' listed in the prerequisite tests below.  The HITSP TP22 Patient Identity Source actor must complete each of the Prerequisite tests identified below. </P>  <H3>Prerequisite:</H3>    <p>Require:<P> <li>PIX_FEED</li> <li>HITSP_TP22_PIX_SRC_MSG_CNST</li> <p>Conditional - Required if Option is Selected: </P> <li>PIX_PDO_Source_Loads_Twin_Data <li>PIX_PDO_Source_to_PIX_Mgr</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 TP22 Patient Identity Source  Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (334, 1, 0, '2009-11-24 10:53:16.867', 'epoiseau', '<H3>Special Instructions</H3>  <p>The HITSP TP22 Patient Identity Cross-Reference Manager Transaction applies the following constraints to the IHE PIX Response Message: <li>QPD-3.4.2  must be an ISO object identifier ISO Object Identifier (OID) <li>QPD-3.4.3 Must Contain  "ISO" Note: "ISO" is the code that means "OID" <li>PID-3.4.2   Assigning Authority''s Universal ID (R) - Shall only contain ISO Object Identifier (OID)   <li>PID-3.4.3   Assigning Authority''s Universal ID Type (R) - Shall only contain "ISO" Note: "ISO" is the code that means "OID"  <p>These constraints are verified in test ''HITSP_TP22_PIX_MGR_MSG_CNST'' listed in the prerequisite tests below. The HITSP TP22 Patient Identity Cross-Reference Manager actor must complete each of the Prerequisite tests identified below. </P>  <H3>Prerequisite:</H3>    <p>Require:<P> <li>PIX_Mgr_Configuration <li>PIX_Seed_Mgr <li>PIX_CLIENT_Upd_Notif_Option <li>PIX_FEED</li> <li>HITSP_TP22_PIX_MGR_MSG_CNST</li> <p>Conditional - Required if Option is Selected: </P> <li>PIX_PDO_Source_to_PIX_Mgr</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 TP22 Patient Identity Cross-Reference Manager Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (335, 1, 0, '2009-11-24 10:53:16.868', 'epoiseau', '<H3>Special Instructions</H3>  <p>The HITSP TP30 Consent Directive Requestor Transactions place no constraints on the IHE BPPC Content Consumer/Document Consumer Transactions. The HITSP TP30 Consent Directive Requestor  actor must complete each of the Prerequisite tests identified below. </P> <H3>Prerequisite:</H3> <p>Require:</p> <li>BPPC_Content_Consumer</li> <p>Conditional - Required if Option is Selected: </P> <li>BPPC_Consumer_Proof_Option <li>BPPC_Consumer_Enforcement</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 TP30 Consent Directive Requestor  Validation Test. </P>	  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (336, 1, 0, '2009-11-24 10:53:16.87', 'epoiseau', '<H3>Special Instructions</H3>  <p>The HITSP TP30 Consent Originator Transactions place no constraints on the IHE Content Creator/Document Source Transactions. The HITSP TP30 Consent Originator actor must complete each of the Prerequisite tests identified below. </P> <H3>Prerequisite:</H3> <p>Require:</p> <li>BPPC_Content_Consumer</li> <p>Conditional - Required if Option is Selected: </P> <li>BPPC_Content_Creator <li>BPPC_Source_Enforcement <li>BPPC_Consumer_Enforcement</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 TP30 Consent Originator Validation Test. </P>	  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (337, 1, 0, '2009-11-24 10:53:16.872', 'epoiseau', '<H3>Special Instructions</H3> <p>The  TP49 / TP89 Document Consumer Transaction places no constraints on the IHE XDS-I Transactions. The  TP49 / TP89 Document Consumer actor must complete each of the Prerequisite tests identified below. </P>	 <H3>Prerequisite:</H3> <p>Require: </P>	 <li>XDS.a_Consumer_Query_Retrieve</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  TP49 / TP89 Document Consumer Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (338, 1, 0, '2009-11-24 10:53:16.874', 'epoiseau', '<H3>Special Instructions</H3> <p>The HITSP TP49/TP89 Document Repository Transaction places no constraints on the IHE XDS-I Transactions. The HITSP TP49/TP89 Document Repository  actor must complete each of the Prerequisite tests identified below. </P>	 <H3>Prerequisite:</H3> <p>Require: </P>	 <li>XDSI_Load_DICOM_Instances <li>XDSI_Load_PDF_Report <li>XDSI_Load_Text_Report</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 TP49/TP89 Document Repository Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (339, 1, 0, '2009-11-24 10:53:16.876', 'epoiseau', '<H3>Special Instructions</H3> <p>The  TP49 / TP89  Document Source Transaction places no constraints on the IHE XDS-I Transactions. The  TP49 / TP89  Document Source actor must complete each of the Prerequisite tests identified below. </P>	 <H3>Prerequisite:</H3> <p>Require: </P>	 <li>XDS.a_Consumer_Query_Retrieve</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  TP49 / TP89  Document Source Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (340, 1, 0, '2009-11-24 10:53:16.878', 'epoiseau', '<H3>Special Instructions</H3> <p>The  TP49 / TP89 Imaging Document Consumer Transaction places no constraints on the IHE XDS-I Transactions. The  TP49 / TP89 Imaging Document Consumer  actor must complete each of the Prerequisite tests identified below. </P>	 <H3>Prerequisite:</H3> <p>Require: </P>	 <li>None</li> <p>Conditional - Required if Option is Selected: </P> <li>XDSI_Retrieve_DICOM_CMove <li>XDSI_Retrieve_DICOM_WADO <li>XDSI_Retrieve_PDF_Report <li>XDSI_Retrieve_Text_Report</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  TP49 / TP89 Imaging Document Consumer Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (341, 1, 0, '2009-11-24 10:53:16.88', 'epoiseau', '<H3>Special Instructions</H3> <p>The  HITSP TP49 / TP89 Imaging Document Source Transaction places no constraints on the IHE XDS-I Transactions. The HITSP TP49 / TP89 Imaging Document Source actor must complete each of the Prerequisite tests identified below. </P>	 <H3>Prerequisite:</H3> <p>Require: </P>	 <li> None</li> <p>Conditional - Required if Option is Selected: </P> <li>XDSI_Load_DICOM_Instances <li>XDSI_Load_PDF_Report <li>XDSI_Load_Text_Report <li>XDSI_Retrieve_DICOM_CMove <li>XDSI_Retrieve_DICOM_WADO <li>XDSI_Retrieve_PDF_Report <li>XDSI_Retrieve_Text_Report</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 TP49 / TP89 Imaging Document Source Validation Test. </P>	');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (342, 1, 0, '2009-11-24 10:53:16.882', 'epoiseau', '<H3>Special Instructions</H3> <p>The HITSP TP50 Form Archiver Source Transaction places no constraints on the IHE RFD Transaction. The HITSP TP50 Form Archiver actor must complete each of the Prerequisite tests identified below. </P>			  <H3>Prerequisite:</H3> <p>Require:</p> <li>RFD_Archive_Form</li>  <p>Conditional - Required if Option is Selected:</p> <li>RFD_Archive_Form_SOAP</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 TP50 Form Archiver Validation Test. </P>	 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (343, 1, 0, '2009-11-24 10:53:16.884', 'epoiseau', '<H3>Special Instructions</H3> <p>The HITSP TP50 Form Filler Transaction places no constraints on the IHE RFD Transaction. The HITSP TP50 Form Filler actor must complete each of the Prerequisite tests identified below. </P>			  <H3>Prerequisite:</H3> <p>Require:</p> <li>RFD_Archive_Form <li>RFD_Retrieve_Form <li>RFD_Submit_Form</li>  <p>Conditional - Required if Option is Selected:</p> <li>RFD_Archive_Form_SOAP <li>RFD_Retrieve_Form_SOAP <li>RFD_Submit_Form_SOAP</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 TP50 Form Filler Validation Test. </P>	  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (344, 1, 0, '2009-11-24 10:53:16.886', 'epoiseau', '<H3>Special Instructions</H3> <p>The HITSP TP50 Form Manager Transaction places no constraints on the IHE RFD Transaction. The HITSP TP50 Form Filler actor must complete each of the Prerequisite tests identified below. </P>			  <H3>Prerequisite:</H3> <p>Require:</p> <li>RFD_Load_Manager <li>RFD_Archive_Form <li>RFD_Retrieve_Form</li> <p>Conditional - Required if Option is Selected:</p> <li>RFD_Archive_Form_SOAP <li>RFD_Retrieve_Form_SOAP <li>RFD_Submit_Form_SOAP</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 TP50 Form Manager Validation Test. </P>	  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (345, 1, 0, '2009-11-24 10:53:16.888', 'epoiseau', '<H3>Special Instructions</H3> <p>The HITSP TP50 Form Receiver Transaction places no constraints on the IHE RFD Transaction. The HITSP TP50 Form Receiver actor must complete each of the Prerequisite tests identified below. </P>			  <H3>Prerequisite:</H3> <p>Require:</p> <li>RFD_Submit_Form </li>  <p>Conditional - Required if Option is Selected:</p> <li>RFD_Submit_Form_SOAP</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 TP50 Form Receiver Validation Test. </P>	  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (346, 1, 0, '2009-11-24 10:53:16.89', 'epoiseau', '<H3>Special Instructions</H3>
 <p>
 Systems capable of sending HL7v2 messages are required to run at least one connectathon test where you send the messages for that test to your partner through the HL7 Proxy.  If your system supports multiple actor/profile pairs that sends HL7v2 messages, <b>you are only required to run one test using the proxy</b>; however, you are encouraged to use the proxy more than this.  It captures and validates your messages.</p>
 <p>It will be easy to find your messages in the proxy viewer if you start your associated connectathon test (with its unique number in kudu) before you send your messages for the test.</p>
 <p>
 You can find the proxy ports for your HL7 test partners in gazelle under <b>Configurations-->All Configurations</b>
 <p>
 <p>Here is <a href="http://ihewiki.wustl.edu/wiki/index.php/How_to_use_the_HL7_Proxy_during_the_Connectahton">additional information on the HL7 Proxy.</a></p>
 <H3>Description</H3>
 <p>Choose at least one of your regular connectathon tests where you''re required to send HL7v2 messages to a test partner.  Send messages to your partner via the HL7 proxy, rather than directly to their system.</p>
 
 <p>You should send at least one V2 message that your system would naturally send. For example:
  <ul>
   <li>ADT System: Send an ADT A04 message</li>
   <li>Order Placer: ORM O01</li>
   <li>Order Filler: Scheduling message that goes to Image Manager, or A08 that goes to Image Manager</li>
  </li>
 </p>
 
 <H3>Evaluation</H3>
 The connectathon monitor will look for evidence of validated messages in kudu under <b>Connectathon-->HL7 Proxy</b>.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (347, 1, 0, '2009-11-24 10:53:16.893', 'epoiseau', '<H3>Special Instructions</H3><p>NONE</p> <H3>Test Description</H3> <p>This test shows only the transaction specific to the option. Prior to performing this test, it is required to perform a simple case.  In other words : Order, MWL, Acquisition, PPS, Storage</p> <H3>Evaluation</H3> Image Manager must demonstrate this transaction for Connectathon Monitor.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (348, 1, 0, '2009-11-24 10:53:16.895', '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 Immunization Content 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 Immunization Content 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 (349, 1, 0, '2009-11-24 10:53:16.899', '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 Immunization Content document 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 IC_Content_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.a or XDS.b, complete the 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> History of Immunizations</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.23</td></tr> </table>   </p> <H3>Evaluation</H3> <p>This will be evaluated with the IC_Scrutinize_Immunization_Content and IC_Process_Immunization_Content tests.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (350, 1, 0, '2009-11-24 10:53:16.901', '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 IC 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 IC_Publish_Content 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 Consumers 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 Immunization Content</li>  <li>Examine EDR Referral document by hand (possibly with style sheet) and examine for IC 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> History of Immunizations</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.23</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 (351, 1, 0, '2009-11-24 10:53:16.903', 'epoiseau', '<H3>Special Instructions</H3> Observation Creators run one instance of this test. <H3>Description</H3> In this test, the Connectathon Monitor examines the contents of the ORU message sent by the Observation Creator actor.  Evaluation focuses on the general structure of the message and the contents of the HL7 v3-derived XML payload.   <p> In effect, this test replaces the automated checking of message content that is missing in the MESA Tools. </p> <H3>Evaluation</H3>  <p>The Connectathon Monitor will use the following tables to  evaulate the contents of the messsage. More than one message may be examined.<br>   The contents of the  ''Value'' column detail requirements for the value of that field either a  specific value or the source of the value.  If there is an ''x'' in the ''Present'' column, that field must be present  in the ORU message with some valid value.<br>   The Connectathon Monitor will note any differences in the  Kudu chat window.</p> <table border="1" cellspacing="0" cellpadding="0">   <tr>     <td width="626" colspan="6" valign="top"><p><strong><em>All observation ORU messages    will be checked for the following:</em></strong></p></td>   </tr>   <tr>     <td width="66" valign="top"><p align="center"><strong>Verified</strong></p></td>     <td width="66" valign="top"><p align="center"><strong>Segment</strong></p></td>     <td width="66" valign="top"><p align="center"><strong>Field #</strong></p></td>     <td width="168" valign="top"><p align="center"><strong>Description</strong></p></td>     <td width="130" valign="top"><p align="center"><strong>Value</strong></p></td>     <td width="130" valign="top"><p align="center"><strong>Present</strong></p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p><strong>MSH</strong></p></td>     <td width="66" valign="top"><p align="center">7</p></td>     <td width="168" valign="top"><p>Date/Time of Message</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">9.1</p></td>     <td width="168" valign="top"><p>Message Type/Msg Code</p></td>     <td width="130" valign="top"><p align="center">ORU</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">9.2</p></td>     <td width="168" valign="top"><p>Message Type/Trigger Event</p></td>     <td width="130" valign="top"><p align="center">R01</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">10</p></td>     <td width="168" valign="top"><p>Message Control ID</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">11</p></td>     <td width="168" valign="top"><p>Processing ID</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">''x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">12</p></td>     <td width="168" valign="top"><p>Version ID</p></td>     <td width="130" valign="top"><p align="center">2.5</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p><strong>PID</strong></p></td>     <td width="66" valign="top"><p align="center">3.1</p></td>     <td width="168" valign="top"><p>Patient Identifier List/ ID number</p></td>     <td width="130" valign="top"><p><em>Format must be</em> ''model:xxx/serial:yyy'' </p></td>     <td width="130" valign="top"><p>''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">3.4</p></td>     <td width="168" valign="top"><p>Pat ID List/ Assigning Authority</p></td>     <td width="130" valign="top"><p align="center">Must contain the Device    Manufacturer Name</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">3.5</p></td>     <td width="168" valign="top"><p>Pat ID List/Identifier Type Code</p></td>     <td width="130" valign="top"><p align="center">MS</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">5</p></td>     <td width="168" valign="top"><p>Patient Name</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">''x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p><strong>PV1</strong></p></td>     <td width="494" colspan="4" valign="top"><p>This segment is optional.</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p><strong>OBR</strong></p></td>     <td width="66" valign="top"><p align="center">1</p></td>     <td width="168" valign="top"><p>Set ID '' OBR</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">3</p></td>     <td width="168" valign="top"><p>Filler Order Number</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">4.1</p></td>     <td width="168" valign="top"><p>Universal Service ID/<br>       Identifier</p></td>     <td width="130" valign="top"><p align="center">Value is either <br>       ''Implant''<br>       or<br>       ''Follow-up''</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">4.2</p></td>     <td width="168" valign="top"><p>Universal Service ID/<br>       Text</p></td>     <td width="130" valign="top"><p align="center">Value is either ''HL7 v2.5 device    observations at Implant''<br>       Or<br>       ''HL7 v2.5 device observations for a    Follow-up''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">7</p></td>     <td width="168" valign="top"><p>Obs. Date/Time</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">25</p></td>     <td width="168" valign="top"><p>Result Status</p></td>     <td width="130" valign="top"><p align="center">Value is ''R'', ''P'', ''F'', or ''C''</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p><strong>OBX</strong></p></td>     <td width="66" valign="top"><p align="center">1 </p></td>     <td width="168" valign="top"><p>Set ID '' OBX</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">2</p></td>     <td width="168" valign="top"><p>Value Type</p></td>     <td width="130" valign="top"><p align="center">ED</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">3.1</p></td>     <td width="168" valign="top"><p>Observation Identifier / Identifier</p></td>     <td width="130" valign="top"><p align="center">IDC</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">3.2</p></td>     <td width="168" valign="top"><p>Observation Identifier / Text</p></td>     <td width="130" valign="top"><p align="center">Implantable Cardiac Device    Follow-up Observation</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">3.3</p></td>     <td width="168" valign="top"><p>Observation Identifier / Name of Coding System</p></td>     <td width="130" valign="top"><p align="center">99IHE</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">5.2</p></td>     <td width="168" valign="top"><p>Observation Value/ Type of Data</p></td>     <td width="130" valign="top"><p align="center">Application</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">5.3</p></td>     <td width="168" valign="top"><p>Observation Value/ Data Subtype</p></td>     <td width="130" valign="top"><p align="center">XML</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">5.4</p></td>     <td width="168" valign="top"><p>Observation Value/ Encoding</p></td>     <td width="130" valign="top"><p align="center">Base64</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">5.5</p></td>     <td width="168" valign="top"><p>Observation Value/ Data</p></td>     <td width="130" valign="top"><p align="center"><em>Additional    requirements for the contents of the XML payload are contained immediately    below this table.</em></p></td>     <td width="130" valign="top"><p align="center">X<br>             <em>(this is the encapsulated    Base64-encoded XML document)</em></p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">11</p></td>     <td width="168" valign="top"><p>Observation Result Status</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">17.1</p></td>     <td width="168" valign="top"><p>Obs. Method / Identifier</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">17.2</p></td>     <td width="168" valign="top"><p>Obs. Method / Text</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">17.3</p></td>     <td width="168" valign="top"><p>Obs. Method /Name of Coding System</p></td>     <td width="130" valign="top"><p align="center"><em>IEEE P1073.1.1.3</em></p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr> </table> <p>''</p> <p>The Connectathon Monitor will verify the contents of the <strong><u>XML payload</u> </strong>in OBR-5.5 as  follows: </p> <ul>   <li>The XML payload is encoded based on the  Hierarchical Message Definition (HMD) included in CARD TF-2:Table 4.12-10.'' That table is not duplicated here.</li>   <li>The payload passes verification of the schema  defined by the IDCO profile.'' The  Observation Creator may have provided proof of schema validation prior to the  Connectathon.'' If not, it must be  demonstrated here.</li>   <li>Observations are contained in groups; either:</li>   <ul>     <li><em>subject->medicalDeviceAct->component1->organizer-><strong>deviceObservation</strong></em></li>     <li><em>subject->medicalDeviceAct->component2-><strong>patientObservation</strong></em></li>     <li><em>subject->medicalDeviceAct->component3-><strong>deviceTherapy</strong></em></li>     <li><strong><em>deviceTherapySetting</em></strong></li>   </ul>   <li><u>Observation items</u> within groups contain,  at least:<strong></strong></li>   <ul>     <li><em>code</em> element attribute '' the value is a  Reference ID defined by IEEE P1073.1.1.3</li>     <li><em>codeSystemName</em> element attribute = IEEE P1073.1.1.3</li>   </ul>   <li><u>Observation items</u> within the groups will  be spot-checked by the Connectathon Monitor.''  Items within each type of group have special requirements as follows:<strong></strong></li>   <ul>     <li>''For <strong><em>deviceObservation</em></strong>, <strong><em>patientObservation</em></strong> and <strong><em>deviceTherapySetting </em></strong>items:<strong></strong></li>     <ul>       <li>The<em> value </em>element  is required and contains the value of the observation.<strong></strong></li>       <li>The <em>nullFlavor</em> attribute of the <em>value</em> element is  used instead of the <em>value</em> attribute  in case where value does not exist, but there is a need to communicate the  reason of absence<strong></strong></li>     </ul>     <li>For <strong><em>deviceTherapy </em></strong>items:<strong></strong></li>     <ul>       <li>The<em> text </em>element  is required and contains the value of the observation (a st.<strong></strong></li>       <li>The <em>nullFlavor</em> attribute of the <em>text</em> element is used  instead of the <em>value</em> attribute if  text is missing.<strong></strong></li>     </ul>   </ul>   <li>If the Connectathon Monitor identifies an  observation with a <em>nullFlavor</em> attribute in the <em>value</em> or <em>text</em> element, it may optionally be  checked to ensure that the codes used are taken from CARD TF-2:4.12.5.2.5.12<strong></strong></li> </ul> <table border="1" cellspacing="0" cellpadding="0">   <tr>     <td colspan="4" valign="top"><p><strong><em>The XML    payload (OBR-5.5) in the ORU message will be checked for the following (Note    that there are optional elements with constraints identified in the IDCO    profile that are not checked in this test; however, an Obervation Processor    or Obersevation Repository may comment on these elements when they attempt to    interpret them in another test):</em></strong></p></td>   </tr>   <tr>     <td valign="top"><p align="center"><strong>Verified</strong></p></td>     <td valign="top"><p align="center"><strong>Element</strong></p></td>     <td valign="top"><p align="center"><strong>Constraint / Value </strong></p></td>     <td valign="top"><p align="center"><strong>Present</strong></p></td>   </tr>   <tr>     <td valign="top"><p>''</p></td>     <td valign="top"><p>e<em>ffectiveTime</em></p></td>     <td valign="top"><p>Value is the timestamp of the session that captured the    device summary data.</p></td>     <td valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td valign="top"><p>''</p></td>     <td valign="top"><p>e<em>ffectiveTime</em></p></td>     <td valign="top"><p>If OBX-14 is set in the HL7 2.5 OBX segment, these    values match.</p></td>     <td valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td valign="top"><p>''</p></td>     <td valign="top"><p><em>recordTarget->patient->patientPerson</em></p></td>     <td valign="top"><p>Sequence of <em>id</em> elements match the PID-3</p></td>     <td valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td valign="top"><p>''</p></td>     <td valign="top"><p><em>author->assignedEntity->assignedPerson</em></p></td>     <td valign="top"><p>''</p></td>     <td valign="top"><p align="center">x (note more than    one author element may be present)</p></td>   </tr>   <tr>     <td valign="top"><p>''</p></td>     <td valign="top"><p><em>author->assignedEntity->assignedPerson->name</em></p></td>     <td valign="top"><p>Contains at least the <em>family </em>and <em>given</em> elements</p></td>     <td valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td valign="top"><p>''</p></td>     <td valign="top"><p><em>author->assignedEntity->representedOrganization</em></p></td>     <td valign="top"><p>Contains the information of the clinic/hospital where    interrogation took place</p></td>     <td valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td valign="top"><p>''</p></td>     <td valign="top"><p><em>subject</em></p></td>     <td valign="top"><p>Only one <em>subject</em> element is allowed.<br>             <em>subject</em> contains only one<em> medicalDeviceAct</em> element.</p></td>     <td valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td valign="top"><p>''</p></td>     <td valign="top"><p><em>subject->medicalDeviceAct->effectiveTime</em></p></td>     <td valign="top"><p>''</p></td>     <td valign="top"><p align="center">Is NOT present</p></td>   </tr>   <tr>     <td valign="top"><p>''</p></td>     <td valign="top"><p><em>subject->medicalDeviceAct</em> -><em>primaryPerformer</em>-><em>assignedDevice-> id.extension</em></p></td>     <td valign="top"><p>Is set to the combination of IEEE1073.1.1.3 nomenclature    terms MDC_IDC_DEVICE_MODEL and MDC_IDC_DEVICE_SERIAL_NUMBER, formatted by    same rules that apply to PID-3.1 in HL7 2.5 PID segment (''model:xxx/serial:yyy'').'' This identifies the Implantable Cardiac    Device</p></td>     <td valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td valign="top"><p>''</p></td>     <td valign="top"><p><em>subject->medicalDeviceAct->component1->organizer->subject->assignedDevice</em></p></td>     <td valign="top"><p>Contains the same value as <em>medicalDeviceAct</em> -><em>primaryPerformer</em>-><em>assignedDevice </em>above</p></td>     <td valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td valign="top"><p>''</p></td>     <td valign="top"><p><em>subject->medicalDeviceAct->component1</em></p></td>     <td valign="top"><p>The cardinality of this element is the number of leads +    1.</p></td>     <td valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td valign="top"><p>''</p></td>     <td valign="top"><p><em>subject->medicalDeviceAct->component1</em></p></td>     <td valign="top"><p>Contains one <em>organizer</em> element</p></td>     <td valign="top"><p>''</p></td>   </tr> </table> <p>''</p> <table border="1" cellspacing="0" cellpadding="0">   <tr>     <td width="626" colspan="6" valign="top"><p><strong><em>Including an encapsulated    PDF document within the ORU is optional.</em></strong><br>             <strong><em>All observation ORUs which    contain an encapsulated PDF document will also be checked for the following:</em></strong></p></td>   </tr>   <tr>     <td width="66" valign="top"><p align="center"><strong>Verified</strong></p></td>     <td width="66" valign="top"><p align="center"><strong>Segment</strong></p></td>     <td width="66" valign="top"><p align="center"><strong>Field #</strong></p></td>     <td width="168" valign="top"><p align="center"><strong>Description</strong></p></td>     <td width="130" valign="top"><p align="center"><strong>Value</strong></p></td>     <td width="130" valign="top"><p align="center"><strong>Present</strong></p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p><strong>OBX</strong></p></td>     <td width="66" valign="top"><p align="center">1 </p></td>     <td width="168" valign="top"><p>Set ID '' OBX</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">2</p></td>     <td width="168" valign="top"><p>Value Type</p></td>     <td width="130" valign="top"><p align="center">ED</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">3.1</p></td>     <td width="168" valign="top"><p>Observation Identifier / Identifier</p></td>     <td width="130" valign="top"><p align="center">18750-0</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">3.2</p></td>     <td width="168" valign="top"><p>Observation Identifier / Text</p></td>     <td width="130" valign="top"><p align="center">Cardiac Electrophysiology Report</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">3.3</p></td>     <td width="168" valign="top"><p>Observation Identifier / Name of Coding System</p></td>     <td width="130" valign="top"><p align="center">LN</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">5.2</p></td>     <td width="168" valign="top"><p>Observation Value/ Type of Data</p></td>     <td width="130" valign="top"><p align="center">Application</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">5.3</p></td>     <td width="168" valign="top"><p>Observation Value/ Data Subtype</p></td>     <td width="130" valign="top"><p align="center">PDF</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">5.4</p></td>     <td width="168" valign="top"><p>Observation Value/ Encoding</p></td>     <td width="130" valign="top"><p align="center">Base64</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">5.5</p></td>     <td width="168" valign="top"><p>Observation Value/ Data</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x<br>             <em>(this is the encapsulated Base64-encoded    PDF document)</em></p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">''</p></td>     <td width="428" colspan="3" valign="top"><p>The attached PDF document shall contain in its contents the device ID and    patient ID.'' It shall also contain the    patient name, if known.</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">11</p></td>     <td width="168" valign="top"><p>Observation Result Status</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr> </table> <table border="1" cellspacing="0" cellpadding="0">   <tr>     <td width="626" colspan="6" valign="top"><p><strong><em>Including observations and    measurements within v2.5 OBX segments is optional.</em></strong><br>             <strong><em>All observation ORUs which    contain individual observations and measurements encoded in discrete OBX    segments will also be checked for the following:</em></strong></p></td>   </tr>   <tr>     <td width="626" colspan="6" valign="top"><p>****Note that there may be multiple OBRs.''    The OBR Segment is used to set the context for the observations    contained in the OBX segments.'' CARD    TF-2: Table 4.12-1 contains requirement for the format of OBRs for Pulse    Generator and Lead Observation results.'' <br>             <br>       The specs below apply to each OBR.<br>       ****Note that within each OBR there may be multiple OBXs.'' The specs below apply to each OBX.</p></td>   </tr>   <tr>     <td width="66" valign="top"><p align="center"><strong>Verified</strong></p></td>     <td width="66" valign="top"><p align="center"><strong>Segment</strong></p></td>     <td width="66" valign="top"><p align="center"><strong>Field #</strong></p></td>     <td width="168" valign="top"><p align="center"><strong>Description</strong></p></td>     <td width="130" valign="top"><p align="center"><strong>Value</strong></p></td>     <td width="130" valign="top"><p align="center"><strong>Present</strong></p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p><strong>OBR</strong></p></td>     <td width="66" valign="top"><p align="center">1</p></td>     <td width="168" valign="top"><p>Set ID '' OBR</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">3</p></td>     <td width="168" valign="top"><p>Filler Order Number</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">4.1</p></td>     <td width="168" valign="top"><p>Universal Service ID/<br>       Identifier</p></td>     <td width="130" valign="top"><p align="center">Value is either <br>       ''Implant''<br>       or<br>       ''Follow-up''</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">4.2</p></td>     <td width="168" valign="top"><p>Universal Service ID/<br>       Text</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">7</p></td>     <td width="168" valign="top"><p>Obs. Date/Time</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">20.1</p></td>     <td width="168" valign="top"><p>Filler-20 / Identifier</p></td>     <td width="130" valign="top"><p align="center">Contains the concatenated    model-serial number of the Implanted Cardiac Device that is being reported on</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">20.2</p></td>     <td width="168" valign="top"><p>Filler-20 / Text</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">20.3</p></td>     <td width="168" valign="top"><p>Filler-20 /Name of Coding System</p></td>     <td width="130" valign="top"><p align="center"><em>IEEE P1073.1.1.3</em></p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">25</p></td>     <td width="168" valign="top"><p>Result Status</p></td>     <td width="130" valign="top"><p align="center">Value is ''R'', ''P'', ''F'', or ''C''</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p><strong>OBX</strong></p></td>     <td width="66" valign="top"><p align="center">1 </p></td>     <td width="168" valign="top"><p>Set ID '' OBX</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">2</p></td>     <td width="168" valign="top"><p>Value Type</p></td>     <td width="130" valign="top"><p align="center">Value is ''ST'', ''CWE'', ''DTM'', ''NM'',    or ''ST''</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">3.1</p></td>     <td width="168" valign="top"><p>Observation Identifier / Identifier</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">3.2</p></td>     <td width="168" valign="top"><p>Observation Identifier / Text</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">3.3</p></td>     <td width="168" valign="top"><p>Observation Identifier / Name of Coding System</p></td>     <td width="130" valign="top"><p align="center"><em>IEEE P1073.1.1.3</em></p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">5</p></td>     <td width="168" valign="top"><p>Observation Value</p></td>     <td width="130" valign="top"><p align="center">This is the actual value of the    observation.</p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">11</p></td>     <td width="168" valign="top"><p>Observation Result Status</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">17.1</p></td>     <td width="168" valign="top"><p>Obs. Method / Identifier</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">17.2</p></td>     <td width="168" valign="top"><p>Obs. Method / Text</p></td>     <td width="130" valign="top"><p align="center">''</p></td>     <td width="130" valign="top"><p align="center">x</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p align="center">17.3</p></td>     <td width="168" valign="top"><p>Obs. Method /Name of Coding System</p></td>     <td width="130" valign="top"><p align="center"><em>IEEE P1073.1.1.3</em></p></td>     <td width="130" valign="top"><p align="center">''</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="494" colspan="4" valign="top"><p>In general, the Connectathon Monitor will verify that there is a discrete    OBX segment for each individual observation reported in the XML payload    within the ORU.</p></td>   </tr>   <tr>     <td width="66" valign="top"><p>''</p></td>     <td width="66" valign="top"><p>''</p></td>     <td width="494" colspan="4" valign="top"><p>The Connectathon Monitor my spot-check consistency between observations    reported in discrete OBXs and those in the XML payload.</p></td>   </tr> </table>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (352, 1, 0, '2009-11-24 10:53:16.911', 'epoiseau', '<H3>Special Instructions</H3> None. <H3>Description</H3> This tests the interaction between Observation Creators and Observation Processors.  It ensures that the Observation Processor can properly parse and interpret the observations contained in the HL7 ORU received from the Observation Processor.  It is a test of both actors (proper encoding of the message / proper parsing and use of the message contents). <H3>Evaluation</H3>   <p>In the evaluation, the Connectathon Monitor is looking for  evidence that the Observation Processor can import/interpret/process received  from the Observation Creator. <br>   There may be some overlap with the type of evaluation done  in test IDCO_Process_Observations, but this test focuses on the ability of the  Observation Processor to process observations/measurements encoded by a  specific Observation Creator system.&nbsp; If  there are discrepencies, the Connectathon Monitor will work with  representatives of both systems to determine if the error is in the encoding or  in the interpretation/processing.</p> <ul> <ul>   <li>The operator of the Observation Processor system  will be asked to demonstrate via the application&rsquo;s user interface, or some  other method, that the contents of the observation message are processed in  some way that is specific its system. </li>   <li>The Connectathon Monitor will identify multiple  individual observations within the HL7 ORU&rsquo;s XML payload and observe specifically  how they are &lsquo;processed&rsquo; by the Observation Processor system.&nbsp; The means of &lsquo;processing&rsquo; of observations  will vary, so evaluation will require some judgment.</li>   <li>Verify that the Observation Processor sent an  ACK to the Observation Creator.</li> </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (353, 1, 0, '2009-11-24 10:53:16.913', 'epoiseau', '<H3>Special Instructions</H3> This test is run once by Observation Processor actors who support the PIX-Based Reconciliation Option.   <p> Prior to running this test, the PIX Manager actor must already have the Patient Identifier of the device registered and have done its internal mapping to the patient''s record in the receiving domain. </p> <H3>Description</H3> Observation Processors are required to cross-reference patient identifiers across two Patient Identifier Domains:  the device vendor systems providing the observations and the clinics receiving the observations. <p> Observation Processors who support the PIX-based Reconciliation option must demonstrate that observations are associated with the proper Patient Identifier in the receiving Domain.  The Monitor uses best judgment when observing the system. </p> <H3>Evaluation</H3> <p>The Connectathon Monitor will observe the Observation  Processor application.   The operator of the Observation Processor  system will be asked to demonstrate it Patient Identifier mapping  mechanism.  This may be an automated or  manual method.  <br>   In general, the Connectathon Monitor is looking for a  method (not necessarily polished) that a vendor would be willing to  demonstrateto a customer as a part of a product.  </p> <ul> <ul>   <li>The Connectathon Monitor may ask to see a copy  of the QBP^Q23 message from the [ITI-9] message.  </li> </ul> <ul>   <li>QBP-3.1  contains the Patient Identifier from the observation message (a concatentation  of the device model number and the device serial number</li>   <li>QBP-3.4  contains the value for Assigning Authority.   This is the Device Manufacturer.</li> </ul> <ul>   <li><em>If the mapping  method is automatic</em>:<br>     The Connectathon Monitor will ask you to <u>demonstrate</u> this mapping  mechanism in action, eg </li> </ul> <ul>   <li>Receive  an obervation including a Patient ID in the format as specified in the  [CARD-12] transaction – concatenation of the device model number and device  serial numberl</li>   <li>Query  for the Patient ID from the receiving domain (and optionally receive Patient  Updates via ADT^A31, ie. [ITI-10])</li>   <li><an  automatic mapping method happens here></li>   <li>The  observations included in the received observation message are now associated  with the correct Patient ID from the receiving Domain.  The best way to demonstrate this is in the  output ‘processed’ observations.</li> </ul> <ul>   <li><em>If the mapping  method is manual</em>:<br>     The Connectathon Monitor will ask you to <u>describe</u> the manual mapping  procedure, including the method for obtaining the values of the Patient IDs in  the ‘receiving’ Patient ID Domain (eg in the clinic receiving the  observations).<br>     <br>     The Connectathon Monitor may ask you to <u>demonstrate</u> this mapping  mechanism in action, eg </li> </ul> <ul> <ul>   <li>Receive  an obervation including a Patient ID in the format as specified in the  [CARD-12] transaction – concatenation of the device model number and device  serial numberl</li>   <li>Query  for the Patient ID from the receiving domain (and optionally receive a Patient  Updates via ADT^A31, ie. [ITI-10])</li>   <li>Demonstrate  the mechanism, eg a User Interface, where the operator will perform the mapping  between the Patient ID received in the observation message and the Patient ID (or  multiple matching Patient IDs) in the receiving Domain.</li>   <li>The  observations included in the received observation message are now associated  with the correct Patient ID from the receiving Domain.  The best way to demonstrate this is in the  output ‘processed’ observations.</li> </ul>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (354, 1, 0, '2009-11-24 10:53:16.917', 'epoiseau', '<H3>Special Instructions</H3> Observation Processors run one instance of this test. <H3>Description</H3> In this test, the Observation Processor demonstrates for the Connectathon Monitor the method and outcomes of processing the values received in the observation message.  <p> The Monitor uses best judgment when observing the system. </p> <H3>Evaluation</H3>  The Connectathon Monitor will observe the Observation Processor application.   The operator of the Observation Processor system will be asked to demonstrate via the application''s user interface, or some other method, that the contents of the observation message are processed in some way that is specific to that application.   This may be, for example, by including the observations within derivative products, such as clinical reports, databases or trans-coded / reformatted results. <p> In general, the Observation Processor is intended to be part of a larger system and not just middleware or a repository. The Connectathon Monitor is looking for a system (not necessarily polished) that a vendor would be willing to demonstrate as a product to a customer. The Connectathon Monitor will not allow a system to pass that whose functionaltiy is limited to ACKing the received HL7 observation messages, or which uses a series of command line tools to process observations. </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (355, 1, 0, '2009-11-24 10:53:16.919', 'epoiseau', '<H3>Special Instructions</H3> This test is run once by Observation Processor actors who DO NOT support the PIX-Based Reconciliation Option.   <p> If the PIX-based Reconciliation Option is supported, then the Observation Processor actor will instead run all required tests for the PIX Consumer actor in the PIX Profile and test IDCO_PIX-based_Reconciliation_Option. </p> <H3>Description</H3> Observation Processors are required to cross-reference patient identifiers across two Patient Identifier Domains:  the device vendor systms providing the observations and the clinics receiving the observations. <p> Observation Processors who do not support the PIX-based Reconciliation option must demonstrate their implementation-specific ID mapping mechanism in this test.  The Monitor uses best judgment when observing the system. </p> <H3>Evaluation</H3>  <p>The Connectathon Monitor will observe the Observation  Processor application.&nbsp; &nbsp;The operator of the Observation Processor  system will be asked to demonstrate its Patient Identifier mapping  mechanism.&nbsp; This may be an automated or  manual method.&nbsp; <br>   In general, the Connectathon Monitor is looking for a  method (not necessarily polished) that a vendor would be willing to  demonstrateto a customer as a part of a product.&nbsp; </p> <ul> <ul>   <li><em>If the  method is automatic</em>:<br>     The Connectathon Monitor will ask you to <u>describe</u> the mapping mechanism,  including the method for obtaining the values of the Patient IDs in the  &lsquo;receiving&rsquo; Patient ID Domain (eg in the clinic receiving the observations).<br>     <br>     The Connectathon Monitor may ask you to <u>demonstrate</u> this mapping  mechanism in action, eg </li> </ul> <ul>   <li>Receive  an obervation including a Patient ID in the format as specified in the  [CARD-12] transaction &ndash; concatenation of the device model number and device serial  numberl</li>   <li>Receive  (or enter) a Patient ID (different value) from a receiving Domain</li>   <li>&lt;an  automatic mapping method happens here&gt;</li>   <li>The  observations included in the received observation message are now associated  with the correct Patient ID from the receiving Domain.&nbsp; The best way to demonstrate this is in the  output &lsquo;processed&rsquo; observations.</li> </ul> <ul>   <li><em>If the  method is manual</em>:<br>     The Connectathon Monitor will ask you to <u>describe</u> the manual mapping  procedure, including the method for obtaining the values of the Patient IDs in  the &lsquo;receiving&rsquo; Patient ID Domain (eg in the clinic receiving the  observations).<br>     <br>     The Connectathon Monitor may ask you to <u>demonstrate</u> this mapping  mechanism in action, eg </li> </ul> <ul> <ul>   <li>Receive  an obervation including a Patient ID in the format as specified in the  [CARD-12] transaction &ndash; concatenation of the device model number and device  serial numberl</li>   <li>Receive  (or enter) a Patient ID (different value) from a receiving Domain</li>   <li>Demonstrate  the mechanism, eg a User Interface, where the operator will perform the mapping  between the Patient ID received in the observation message and one of the  (many) possible Patient IDs in the receiving Domain.</li>   <li>The  observations included in the received observation message are now associated  with the correct Patient ID from the receiving Domain.&nbsp; The best way to demonstrate this is in the  output &lsquo;processed&rsquo; observations.</li> </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (356, 1, 0, '2009-11-24 10:53:16.922', 'epoiseau', '<H3>Special Instructions</H3> None. <H3>Description</H3> This test allows an Order Filler to demonstrate its use of the Image Availability query. The Order Filler receives MPPS messages from an Acquisition Modality, queries an Image Manager for images and then performs some other action based on the Image Manager response. <H3>Evaluation</H3>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (357, 1, 0, '2009-11-24 10:53:16.926', 'epoiseau', '<h3>Special Instructions</h3> <p>Importers which support the Scheduled Import Option must run  this test.<br> <p>  If your actor also supports the  Uncheduled Import option, run 3 instances of a combination of the Importer/Img  Mgr tests, eg 2 instances of IRWF_IMP_IM_Sched and 1 instance of  IRWF_IMP_IM_Unsched.'' <br> </p>   <p>In the descriptions to follow, the patient last name,  SYS_NAME, should be a combination of both the Image Manager and Importer systems  under test, for example: PACS_ABC-IMP_XYZ. <br>   </p> <p>Use the RIS Mall as an ADT, OP and DSS/OF simulator to  register patients and create and schedule orders for import. The Importer  system should take responsibility for creating the patients and orders for the  test. <br>   </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. <br> </p> <p> Before starting this test with an Image Manager, the  Importer must have the items ready to import (images/films/documents), and the  patients and orders must already be scheduled in RIS Mall.</p> <h3>Description </h3> <p>This tests C-STORE, Storage Commitment and Performed  Procedure Step transactions between Importer and Image Manager actors.<br>   The ability of Image Managers, as PPS Managers, to forward  PPS messages to a DSS/OF is not evaluated in this test.</p> <h3>Evaluation</h3> <p>On the <strong>Image Manager</strong> user interface or database:</p> <ul>   <li>For patient SYS_NAME^SCHED, verify that all of  the imported objects in the study have been successfully stored.</li>   <li>Check that the following fields match what was  provided in the MWL for patient SYS_NAME^SIMPLE: </li>   <ul>     <ul>       <ul>         <li>(0010,0010) Patient Name</li>         <li>(0010,0020) Patient ID </li>         <li>(0008,0050) Accession Number</li>       </ul>     </ul>   </ul> </ul> <ul type="disc">   <ul type="disc">     <li>For        the <strong>ABANDONED CASE</strong>, the PPS-Discontinued should have been captured        on the Image Manager or in the Kudu chat window.'' Find the PPS message for        SYS_NAME^ABANDON. Verify that: </li>   </ul> </ul> <ul>   <li>The Performed Procedure Step Status was sent  with a value of DISCONTINUED</li>   <li>The Procedure Step Discontinuation Reason Code  Sequence (0040,0281) has a value for Code Meaning (0040,0281) of one of these  five values:</li>   <ul>     <li>Objects  incorrectly formatted</li>     <li>Object  Type not supported</li>     <li>Object  Set incomplete</li>     <li>Media  Failure</li>     <li>Incorrect  Worklist Entry Selected</li>   </ul> </ul> <p>On the <strong>Importer</strong> or in Kudu, view a copy of the  captured Storage Commitment N-EVENT-REPORT.''  All of the following attributes shall be verified in the Storage Commit  message: </p> <ul> <ul>   <li>(0008, 0054) Retrieve AE Title </li>   <li>(0008, 1199) Referenced SOP Sequence </li> </ul> <ul> <ul>   <li>(0008, 1150) Reference SOP Class </li>   <li>(0008, 1155) Referenced SOP Instance UID </li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (358, 1, 0, '2009-11-24 10:53:16.928', 'epoiseau', '<h3>Special Instructions</h3> <p>This test is for Importers which support Unscheduled Import  Option.  If your actor also supports the  Scheduled Import option, run 3 instances of a combination of the Importer/Img  Mgr tests, eg 2 instances of IRWF_IMP_IM_Sched and 1 instance of  IRWF_IMP_IM_Unsched.  <br>   <p>You must run test IRWF_PDQ_1 through IRWF_PDQ_3  first.  You  should use the demographics from the patients you queried for in IRWF_PDQ_2 for  studies you import for this test.  You  will need two different patients for this test.<br>   </p><p>Before starting this test with an Image Manager, the  Importer must have the items ready to import (images/films/documents), and the  patient demographics received via the Patient Demographic Query transaction already  on its system.</p> </p><h3>Description </h3> <p>This tests C-STORE, Storage Commitment and Performed  Procedure Step transactions between Importer and Image Manager actors.<br>   The ability of Image Managers, as PPS Managers, to forward  PPS messages to a DSS/OF is not tested in this test.</p> <h3>Evaluation</h3> <p>On the <strong>Image Manager</strong> user interface or database:</p> <ul>   <li>The Kudu chat window will tell you the Patient  Name and ID used for the import. Verify that all of the imported objects in the  study have been successfully stored.</li>   <li>Check that the following attributes in the  imported objects match what was provided in the Patient Demographic Query:</li>   <ul>     <ul>       <ul>         <li>(0010,0010) Patient Name</li>         <li>(0010,0020) Patient ID</li>       </ul>     </ul>   </ul> </ul> <ul type="disc">   <ul type="disc">     <li>Verify:  (0008,0050) Accession Number must be        zero-length</li>     <li>Verify:  (0020,000D) Study Instance UID<br>       - If a this was a DICOM study imported from CD/DVD or via the network,        the Study Instance UID must be the same as the original imported DICOM        object.<br>       - If this was a scanned film or document, the Importer must generate a        valid DICOM UID, ie:</li>   </ul> </ul> <ul>   <li>contains 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.</li>   <li>each component (separated by ".") consists of  one or more digits.  The first digit of  each component shall not be zero unless the component is a single digit.</li>   <li>maximum length of 64 characters)</li> </ul> <ul type="disc">   <ul type="disc">     <li>For        the <strong>ABANDONED CASE</strong>, the PPS-Discontinued should have been captured        on the Image Manager or in the Kudu chat window.  Find the PPS message for the patient        recorded in Kudu. Verify that: </li>   </ul> </ul> <ul>   <li>The Performed Procedure Step Status was sent  with a value of DISCONTINUED</li>   <li>The Procedure Step Discontinuation Reason Code  Sequence (0040,0281) has a value for Code Meaning (0040,0281) of one of these  five values:</li>   <ul>     <li>Objects  incorrectly formatted</li>     <li>Object  Type not supported</li>     <li>Object  Set incomplete</li>     <li>Media  Failure</li>     <li>Incorrect  Worklist Entry Selected</li>   </ul> </ul> <p>On the <strong>Importer</strong> or in Kudu, view a copy of the  captured Storage Commitment N-EVENT-REPORT.   All of the following attributes shall be verified in the Storage Commit  message: </p>  <ul>   <li>(0008, 0054) Retrieve AE Title </li>   <li>(0008, 1199) Referenced SOP Sequence </li>  <p></p>   <li>(0008, 1150) Reference SOP Class </li>   <li>(0008, 1155) Referenced SOP Instance UID </li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (359, 1, 0, '2009-11-24 10:53:16.93', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Importer actors which support the Scheduled Import option  must run this test.</p> <p>This test is based on SWF_MWL in the Scheduled Workflow  Integration Profile.  If your Importer actor  has already run that test, you do not need to run this one.</p> <p>In this test, you will be asked to create patient names  where the last name will contain the name of the Importer system under-test,  eg. IMPORTER-Company-Name^TOMORROW.</p> <p>Please use the suggested patient name format; it helps make  the later test evaluation much more efficient. </p> </p><H3>Description</H3><p>This test verifies the ability of the DSS/Order Filler and  Importer to exchange patient and procedure information using [RAD-5] Query Modality  Worklist and the ability of the Importer to constrain the worklist it requests  (RAD-TF-2: 4.5.1).</p><p>The Importer must support either Patient-Based Query, Broad  Query, or both.</p><p>In the Patient Based Query, an Importer should support all  combinations of: Patient Name (0010,0010), Patient ID (0010,0020), Accession  Number (0008,0050), Requested Procedure ID (0040,1001).</p><p>In the Broad Query, an Importer should support all  combinations of: SPS Start Date (0040,0002), Importer (0008,0060), Scheduled  Station AE Title (0040,0001). </p><H3>Evaluation</H3><p>The Importer must demonstrate <strong>some method for  constraining worklist</strong>.   Connectathon Monitor will ask the <strong>Acquistion</strong> <strong>Modality</strong> to  show evidence that: </p><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.     The Connectathon Monitor should ask the Importer operator to demonstrate on its  user interface the ability to query by combination of SPS Start Date, Modality  type, Scheduled AE title.     <strong><em><u>and/or</u></em></strong> </li> <li>it supports Patient-Based MWL queries.</li> <li>The Connectathon Monitor should ask the Importer operator to demonstrate on its  user interface the ability to query by combination of Patient Name, Patient ID,  Accession Number and Requested Procedure ID</li> </ul><p>On the <strong>Importer</strong>, there may be <strong>2 captured files </strong>to  examine: </p><ul> <li>In <strong>[test-case-no]-todaymwl.txt</strong>, the worklist should contain:     <ul>        <li>Two worklist items (IMPORTER-Company-Name-B^MWL1 and IMPORTER-Company-Name-C^MWL2)</li>        <li>Patient IMPORTER-Company-Name-A^TOMORROW should not appear. </li>      </ul> 	 </li> <li>In <strong>[test-case-no]-patnamemwl.txt</strong>, the worklist should contain:     <ul type="circle">        <li>Three worklist items. </li>      </ul> </li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (360, 1, 0, '2009-11-24 10:53:16.934', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Importer actors which support the Unscheduled Import option must run this test.</p> <p>Prior to this test, the Patient Demographics Supplier actor must first complete test PDQ_Load.</p> </p><H3>Description</H3><p>This test verifies the ability of the Patient Demographic Supplier and Importer to exchange Patient Demographic Query transaction. (ITI TF-2:2.4.21 and RAD TF-3:4.59.4.1.2.3.1). </p><p>The Importer must support either Patient-Based Query, Broad  Query, or both.</p><p>In the Patient Based Query, an Importer should support all  combinations of: Patient Name (0010,0010), Patient ID (0010,0020), Accession  Number (0008,0050), Requested Procedure ID (0040,1001).</p><p>In the Broad Query, an Importer should support all  combinations of: SPS Start Date (0040,0002), Importer (0008,0060), Scheduled  Station AE Title (0040,0001). </p><H3>Evaluation</H3><p>Connectathon monitor should observe query in real time and evaluate response.</p><p>The semantics of the PDQ query are not defined by the Technical Framework. Some systems may return more than one record for this query. The purpose of the evaluation is to determine if a response is returned and if the behavior is reasonable.</p><p>For example, if the supplier always returns the entire database for any name search, that would not be a reasonable implementation. That would fail this test.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (361, 1, 0, '2009-11-24 10:53:16.936', 'epoiseau', '<h3>Special Instructions</h3> <p>Importer actors which support the Unscheduled Import option  must run this test.<br>   Prior to this test, the Patient Demographics Supplier actor  must first complete test PDQ_Load (see PDQ Connectathon Test Plan document). </p> <h3>Description </h3> <p>This test verifies the ability of the Patient Demographic  Supplier and Importer to exchange Patient Demographic Query transaction. (ITI  TF-2:2.4.21 & RAD TF-3:4.59.4.1.2.3.1). ''</p> <H3>Evaluation</H3> <p>Connectathon monitor should observe all queries in real time and evaluate response. PDQ Consumer should demonstrate configuration/logs indicating the PDQ Supplier that is queried.</p>  <p>PDQ Supplier does not need to demonstrate any results unless there are problems. In that case, access to logs would be helpful.</p>  <p>Not all Consumers will support all queries. Only evaluate those queries supported by the Consumer.</p>  <p><b>We especially want to see the query result that uses the Kudu name of the demographics supplier. This will help to show the monitor you are sending a query to the proper system.</b></p>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (362, 1, 0, '2009-11-24 10:53:16.938', 'epoiseau', '<H3>Description</H3> <p>The IRWF_PDQ_Continuation_Test is for the implementation of continuation pointers in query responses. Patient Demographic Consumers are not required by the TF to support this feature, so Supplier systems will need to seek a partner. <p>The PDQ Consumer may be an <b>Importer</b> actor (with the Unscheduled Option) in the IRWF profile.</p> Consumers are encouraged to help. </p> <p> This test is applicable to HL7 v2.5 systems.  The Patient Demographic Supplier should load enough patients that could result in query matches and make use of the continuation protocol. You may have to use your imagination here as the normal test data is for very few patients.</p>  <p>Patient Demographic Consumers may have to perform some configuration to use a lower number of accepted records to assist the Demographic Supplier in using the continuation protocol.</p>    <H3>Evaluation</H3> <p>Show the Connectathon monitor evidence that the Demographics Consumer is configured to limit the number of responses, thus forcing continuation.  The Demographics Supplier must also demonstrate its ability to limit the number of query responses to the value sent in RPC-2 of the query message. </p> The Connectathon monitor should observe the query in real time and see two items (if possible): <ul> <li>Log information at the consumer or supplier indicating the continuation protocol </li> <li>Behavior at the client that indicates continuation. </li> </ul> </p>  <p>Both of the items requested may be difficult to obtain; these depend on the implementations.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (363, 1, 0, '2009-11-24 10:53:16.94', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p> </p><H3>Description</H3><p>The PDQ_Multiple_Query test requires PDQ Consumers to send different types of queries to a PDQ Supplier. Some PDQ Consumers may not have user interfaces that support all of the intended queries.</p><p>The PDQ Consumer may be an <b>Importer</b> actor in the IRWF profile.</p><p>Each query is made assuming a single domain that can be left unspecified in QDP-8 (What Domains Returned). The syntax of wild card queries is not specified by the IHE Technical Framework. There may be some negotiation between Consumer and Supplier actors.</p><H3>Evaluation</H3><p>Connectathon monitor should observe all queries in real  time and evaluate response. PDQ Consumer should demonstrate configuration/logs  indicating the PDQ Supplier that is queried.    PDQ Supplier does not need to demonstrate any results  unless there are problems. In that case, access to logs would be helpful.     The PDQ Supplier is required to support queries containing  the fields listed below.  Not all  Consumers will support all queries. Evaluate as many query combinations as are supported  by the Consumer.</p><ul>     <li>PID.3  Patient  Identifier List</li>     <li>PID.5  Patient  Name</li>     <li>PID.7  Date/Time  of Birth</li>     <li>PID.8  Administrative  Sex</li>     <li>PID.11            Patient  Address</li>     <li>PID.18            Patient  Account Number</li> </ul><p>The PDQ Supplier is required to support at least all exact  matches to the query parameters sent by the Consumer.  The Technical Framework does not further  specify matching requirements (eg wildcards, upper and lower case, alternate  spellings'')      The Connectathon Monitor may ask to see a copy of the  QBP^Q22 query message to check values in the following fields:</p><ul>     <li>MSH-9            ''QBP^Q22''</li>     <li>QPD-1             ''IHE  PDQ Query''</li>     <li>QPD-3             <em>This field contains the query paramaters.</em> </li>     <li>QDP-8             <em>If specified, only component 4 (Assigning  Authority) has a value.</em> </li>     <li>RPC-1             ''I'' <em>To request an immediate reponse.</em> </li>     <li>RPC-2             <em>Note: This field, Quantity Limited Request,  is tested in PDQ_Continuation_Test.  A  value such as ''25^RD'' requests 25 records at a time be returned from the PDQ  Supplier.</em> </li> </ul><p>The Connectathon Monitor may ask to see a copy of the  RSP^K22 query message to check values in the following fields:</p><ul>         <li>MSH-3            <em>This field (Sending Application) contains  the value received from the PDQ Consumer in MSH-5 (Receiving Application)</em> </li>     <li>MSH-9            ''RSP^K22''</li>     <li>QAK-2             ''OK'' <em>if data is returned</em> </li>     <li>QDP                <em>Fields in this segment are the same as those  received in the query.</em> </li>     <li>PID                 PID.3  and PID.5 <em>(Patient ID and Name) are  required.  The Supplier must also return  fields for which it has values</em> </li> </ul><p> <b>We especially want to see the query result that uses the Kudu name of the demographics supplier. This will help to show the monitor you are sending a query to the proper system.</b> </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (364, 1, 0, '2009-11-24 10:53:16.943', 'epoiseau', 'To be defined');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (365, 1, 0, '2009-11-24 10:53:16.944', 'epoiseau', '<h3>Description</h3>  <p>The purpose of the KIN_Archive test is for all creators of Key Object Notes (Modalities, Evidence Creators) to create two Key Object Notes and to store those on the Central Archive. The creator of the note should also store all of the images of the study to which the note pertains. The first note should reference a single image; the second note should reference 2-3 images. </p> <p>In order to identify the creator of the note, it would be most beneficial if the Patient Name chosen reflected the company/product of the system creating the Key Object Note. This is relatively easy for Modalities as they create the original images. This may take more imagination by Evidence Creators as they typically do not create the original images.</p> <p>By having the company/product name in the Patient Name field, other tests will be much easier to perform.</p> <p>As all images/notes are stored to one Central Archive, run this test one time, <strong>preferably on the first day of the connectathon</strong> so that others can test with your data during the rest of the connectathon.</p> <p>Once the data are on the Central Archive fill out the <em>Object Information</em> section so that your peer can find out the data you have stored on the central archive.</p> <p>There are extra worthless brownie points available for those who create Key Object Notes that refer to individual frames in a multi-frame image, , or that reference GSPS objects associated with an image object, or that reference objects outside the current study.</p>  <h3>Evaluation</h3> <p>In order to validate the test, the project manager will check <ul><li>that the objects are stored on the Central Archive,</li><li>that there is a corresponding entry in the <em>Objects Information</em> section of the webtool.</li></ul></p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (366, 1, 0, '2009-11-24 10:53:16.947', 'epoiseau', '<H3>Special Instructions</H3> Please note that this test can easily be combined with the other KIN test.   <h3>Description</h3>  <p>The purpose of the KIN_Archive test is for all creators of Key Object Notes (Modalities, Evidence Creators) to create two Key Object Notes and to store those on the Central Archive. The creator of the note should also store all of the images of the study to which the note pertains. The first note should reference a single image; the second note should reference 2-3 images. </p> <p>In order to identify the creator of the note, it would be most beneficial if the Patient Name chosen reflected the company/product of the system creating the Key Object Note. This is relatively easy for Modalities as they create the original images. This may take more imagination by Evidence Creators as they typically do not create the original images.</p> <p>By having the company/product name in the Patient Name field, other tests will be much easier to perform.</p>  <p>As all images/notes are stored on the  Central Archive <a href=show_system_config.php?system=PACS_CENTRAL_ARCHIVE target=PACS_CENTRAL_ARCHIVE><IMG src=/common/images/config.jpg border=0 width=16></a> . Run this test one time, <strong>preferably on the first day of the connectathon</strong> so that others can test with your data during the rest of the connectathon.</p> <p>Once the data are on the Central Archive fill out the <em><a href=system_con_object.php target=OBJECT>Objects Information</a></em> section of the kudu webtool so that your peer can find out the data you have stored on the central archive.</p> <p>There are extra worthless brownie points available for those who create Key Object Notes that refer to individual frames in a multi-frame image, , or that reference GSPS objects associated with an image object, or that reference objects outside the current study.</p>  <h3>Evaluation</h3> <p>In order to validate the test, the project manager will check <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 target=OBJECT>Objects Information</a></em> section of the kudu webtool</li></ul></p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (367, 1, 0, '2009-11-24 10:53:16.95', 'epoiseau', '<h3>Special Instructions</h3> None  <h3>Description</h3>  <p>This is a test between Evidence Creators, Image Managers, and Image Displays to insure that the Image Display can receive and properly display Key Object Notes created by the Evidence Creator and stored by the Evidence Creator on the Image Manager.  <strong>Participants in both CPI and KIN may combine this test with the CPI_C_SOFT test; however, two evaluations will still occur (i.e., KON_CREATOR evaluates the Key Object Note display, while CPI_C_SOFT evaluates the display consistency).</strong>  <ol>  <li>Identify and retrieve one study with several images.  This is most likely a CT or MR study with one series and a number of slices (hopefully 10-20).</li>  <li>Select one image as the Key Image.  The Evidence Creator should create a Key Object Note that references that one image  and send the note and all images to the Image Display under test. The title of the Key Object  Note should be one of the titles drawn from DICOM CID 7010 (see DICOM Part 16), some of which are listed here for convenience. <ol> <li>(113000,DCM,"Of Interest")</li> <li>(113002,DCM,"For Referring Provider")</li> <li>(113003,DCM,"For Surgery ")</li> <li>(113005,DCM,"For Conference")</li> <li>(113006,DCM,"For Therapy")</li> <li>(113007,DCM,"For Patient")</li> <li>(113008,DCM,"For Peer Review")</li> <li>(113009,DCM,"For Research")</li> </ol> If possible, the Evidence Creator should insert an appropriate description into the Key Object Note (e.g. modifier or text).  There are extra worthless brownie points available for those who create Key Object Notes that refer to individual frames in a multi-frame image, or that reference GSPS objects associated with an image object, or that can reference objects from a different study. </li> <li> The Evidence Creator sends the Key Object Note to the Image Manager using Storage Commitment.  (It is assumed that the Evidence Creator also sends the images and related DICOM objects to the Image Manager as well.)</li> <li>The Image Display retrieves the Key Object Note along with the related images and other objects from the Image Manager.</li>  <li>The Image Display should display all images.  The  Image Display should render the Key Object Note with the single referenced image.</li>  <li>Repeat the test with the same images and a different Key Object Note that references several images (2-3).</li>  </ol>  </p>  <h3>Evaluation</h3>  <p> <ul> <li>The Project Manager will check that the Image Display properly recognized the Key Image Note and highlighted or displayed the selected image or images, and that any description of the key object note is available. </li> <li> The Project Manager also will ask to see evidence of a Storage Commitment for the Key Object Note. </li> <li> Also, if the Key Object Note also includes a GSPS object that references an image object listed in the Key Object Note, the Project Manager should note whether or not the Image Display utilized the GSPS in displaying images from the Key Object Note.  It is not a failure if the Image Display ignores the GSPS object, but there are extra worthless brownie points available if the Image Display does correctly utilize the GSPS object.</li> </ul> </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (368, 1, 0, '2009-11-24 10:53:16.952', 'epoiseau', '<h3>Description</h3>  <p>This is a test between Modalities, Image Managers,  and Image Displays to insure that the Image Display can receive and properly display Key Object Notes created by the Modality and stored by the Modality on the Image Manager.  <strong>Participants in both CPI and KIN may combine this test with the CPI_M_SOFT test; however, two evaluations will still occur (i.e., KON_MOD evaluates the Key Object Note display, while CPI_M_SOFT evaluates the display consistency).</strong>  <ol>  <li>Modality generates series of images (more than 1 image, preferably 5-15)</li>  <li>Select one image as the Key Image. Create a Key Object Note that references that one image  and send the note and all images to the Image Display under test. The title of the Key Object  Note should be one of the titles drawn from DICOM CID 7010 (see DICOM Part 16), some of which are listed here for convenience. <ol> <li>(113000,DCM,"Of Interest")</li> <li>(113002,DCM,"For Referring Provider")</li> <li>(113003,DCM,"For Surgery ")</li> <li>(113005,DCM,"For Conference")</li> <li>(113006,DCM,"For Therapy")</li> <li>(113007,DCM,"For Patient")</li> <li>(113008,DCM,"For Peer Review")</li> <li>(113009,DCM,"For Research")</li> </ol> If possible, the Modality should insert an appropriate description into the Key Object Note (e.g. modifier or text).  There are extra worthless brownie points available for those who create Key Object Notes that refer to individual frames in a multi-frame image, or that reference GSPS objects associated with an image object, or that can reference objects from a different study.</li> <li> The Modality sends the Key Object Note to the Image Manager using Storage Commitment.  (It is assumed that the Modality also sends the images and related DICOM objects to the same Image Manager as well.)</li> <li>The Image Display retrieves the Key Object Note along with the related images and other objects from the Image Manager.</li> <li>Image Display should display all images.  Image Display should render Key Object Note with the single referenced image.</li>  <li>Repeat the test with the same images and a different Key Object Note that references several images (2-3).</li>  </ol>  </p>  <h3>Evaluation</h3>  <p> <ul> <li>The Project Manager will check that the Image Display properly recognized the Key Image Note and highlighted or displayed the selected image or images, and that any description of the key object note is available. </li> <li> The Project Manager also will ask to see evidence of a Storage Commitment for the Key Object Note.  </li> <li>Also, if the Key Object Note also includes a GSPS object that references an image object listed in the Key Object Note, the Project Manager should note whether or not the Image Display utilized the GSPS in displaying images from the Key Object Note.  It is not a failure if the Image Display ignores the GSPS object, but there are extra worthless brownie points available if the Image Display does correctly utilize the GSPS object. </li> </ul> </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (369, 1, 0, '2009-11-24 10:53:16.954', 'epoiseau', '<H3>Special Instructions</H3> <p>Find the data your peers have stored Central Archive by referring to the <em><a href=system_con_object.php target=OBJECT>Objects Information</a></em> section of the kudu webtool.</p>.  <H3>Description</H3> <p>KON_RETRIEVE checks to see that an Image Display can properly display Key Object Notes. </p>  <p>For this test, an Image Display will be asked to render at least 5 Key Object Notes from the Central Archive. The Project Manager, not the participant, will select which 5 Key Object Note objects will be rendered for test evaluation. If the Project Manager has concerns about an Image Display’s capabilities to render Key Object Notes, the Project Manager may ask the participant to render more than 5 Key Object Notes. The Project Manager may select Key Object Note objects similar to those provided for the MESA tests, and/or may select images stored onto the Central Archive by other participants (see the KIN_Archive test).</p>  <p>An Image Display runs this test only one time for evaluation purposes. However, participants are encouraged to experiment with rendering a variety of Key Object Note objects that will be available in the Central Archive to insure that their implementation can truly handle objects from multiple of vendors. The Project Managers will announce which 5 Key Object Note objects will be used for evaluation after the first day of test, in order to give Key Object Note creators time to store their example images in the Central Archive.  Evaluations of this test cannot start until after this announcement is made.</p>  <H3>Evaluation</H3> <p>The Project Manager will check that the Image Display properly recognized the Key Image Note and highlighted or displayed the selected image or images, and that any description of the key object note is available.  Also, if the Key Image Note also includes a GSPS object, the Project Manager should note whether or not the Image Display utilized the GSPS in displaying images from the Key Image Note.  It is not a failure if the Image Display ignores the GSPS object, but there are extra worthless brownie points available if the Image Display does correctly utilize the GSPS object.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (370, 1, 0, '2009-11-24 10:53:16.956', 'epoiseau', '<h3>Special Instructions</h3><p>None</p> <h3>Description</h3> <p>This test corresponds to transaction LAB-5 of IHE Laboratory Technical Framework. The actors using this transaction are the Order Filler and the Automation Manager. </p> <p>The Order Filler manages the test results notified by the Automation Manager.</p> <h3>Evaluation</h3>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (371, 1, 0, '2009-11-24 10:53:16.959', 'epoiseau', '<h3>Special Instructions</h3><p>None</p> <h3>Description</h3> <p>The purpose here is to test the transaction LAB-2</p> <p>There are 3 possible messages. At least one of the three pairs shall be supported</p> <ul> <li> OML^O21: laboratory order message. This is a battery-centric structure: It contains a list of ordered batteries, a list of specimens underneath each battery, and a list of containers underneath each specimen. This structure implies duplication of specimen/container information whenever two batteries use the same specimen. It is more appropriate for ordering batteries that need several specimens (e.g. creatinine clearance, glucose tolerance test). </li> <li> OML^O33: Laboratory order for multiple orders related to a single specimen. This is a specimen-centric structure providing for each specimen a list of containers and a list of batteries (ORC/OBR segment groups) using this specimen. The batteries are not related to the containers. </li> <li> OML^O35: Laboratory order for multiple orders related to a single container of a specimen. This message structure provides for each specimen a list of containers, and for each container the list of batteries that are to be performed on that container. This structure is more appropriate when the ordered batteries are sorted by container.</li> </ul> <h3>Evaluation</h3>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (372, 1, 0, '2009-11-24 10:53:16.96', 'epoiseau', '<h3>Special Instructions</h3> <p>None</p> <h3>Description</h3> <p>This transaction is used if the Order Filler issues a new order to the Automation Manager.</p> <p>In addition, this transaction is used to cancel and/or modify an order that was previously sent to the Automation Manager.</p> <p>It is also possible to cancel a previous order and send a new order to modify it.</p> <h3>Evaluation</h3>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (373, 1, 0, '2009-11-24 10:53:16.962', 'epoiseau', '<h3>Special Instructions</h3> <p>This test is on two steps:</p> <ol> <li>LTW Result Laboratory:  Some batteries one the same specimen</li> <li>LTW Result Laboratory: One battery on more than one specimen</li> </ol>  <h3>Description:</h3> <ol> <li>LTW Result Laboratory:  Some batteries one the same specimen <ul type="square"> <li>The aim of this test is to show multiple batteries of tests on a unique specimen.</li> <li>The order is created directly on the Order Filler.</li> <li>The Order Filler sends some results to the Order Result Tracker.</li> <li>The Project Manager will ask the Order Result Tracker to show laboratory results.</li> </ul> </li> <li>LTW Result Laboratory: One battery on more than one specimen <ul type="circle"> <li>The order is created directly on the filler.</li> <li>The specimen is collected in different dates.</li> <li>The Order Filler sends some results to the Order Result Tracker.</li> <li>In the Order Filler, a test is deleted, this deletion is transmitted to the Order Result Tracker.</li> </ul> </li> </ol> <h3>Evaluation:</h3> <ol> <p>LTW Result Laboratory:  Some batteries one the same specimen</p> <li>To be checked in the OUL or ORU messages: <ul type="square"> <li> the different status (ORC-5, OBR-25 and OBX-11) for result not validated, for final result and for a correction of result</li> <li>the information of the specimen, such as specimen type (SPM-4) or specimen collection date (SPM-17)</li> <li>each message is transmited in recapitulative mode (all results for l>battery are sent)</li> </ul> </li> <li>To be checked on the Order Result Tracker: <ul type="square"> <li>the different results</li> <li>the different status of the result</li></ul>  </li> <p>LTW Result Laboratory: One battery on more than one specimen</p> <li>To be checked in OUL or ORU messages: <ul ype="circle"> <li>the different status ORC-5, OBR-25 and OBX-11 for result not validated, for deletion of result, for validated result</li> <li>the information of the specimen like specimen type SPM-4 or specimen collection date SPM-17</li> <li>each message is in recapitulative mode</li></ul> </li> <li>To be checked on the Order Result Tracker: <ul ype="circle"> <li>the different results</li> <li>the different dates of collection date for each specimen</li> <li>the different status of the result (deleted result)</li> <li>The Observer will ask the Order Result Tracker to show laboratory results.</li></ul> </li> </ol>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (374, 1, 0, '2009-11-24 10:53:16.964', 'epoiseau', '<h3>Special Instructions</h3><p>None</p><h3>Description</h3> <p>The purpose here is to test the transaction LAB-1</p> <p>There are 3 possible messages. At least one of the three pairs shall be supported</p> <ul> <li> OML^O21: laboratory order message. This is a battery-centric structure: It contains a list of ordered batteries, a list of specimens underneath each battery, and a list of containers underneath each specimen. This structure implies duplication of specimen/container information whenever two batteries use the same specimen. It is more appropriate for ordering batteries that need several specimens (e.g. creatinine clearance, glucose tolerance test). </li> <li> OML^O33: Laboratory order for multiple orders related to a single specimen. This is a specimen-centric structure providing for each specimen a list of containers and a list of batteries (ORC/OBR segment groups) using this specimen. The batteries are not related to the containers. </li> <li> OML^O35: Laboratory order for multiple orders related to a single container of a specimen. This message structure provides for each specimen a list of containers, and for each container the list of batteries that are to be performed on that container. This structure is more appropriate when the ordered batteries are sorted by container.</li> </ul> <h3>Evaluation</h3> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (375, 1, 0, '2009-11-24 10:53:16.968', 'epoiseau', '<h3>Special instructions</h3> There is no POCRG actor involved in that test.  You may find a friendly POCRG actor, or the system implementing the POCDM actor may also implement the POCRG actor.    <h3>Description</h3> The purpose of the test is to check that the triggers "New Observations" and "Unordered Observations" are correctly triggering the ORU messages.  <h3>Evaluation</h3> Monitor should verify that the messages match the triggers.  Monitor should verify that the ORU messages are acknowledge with ACK^R33 messages.  <ul> <li>check for the order filler number in the ACK messages</li> </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (376, 1, 0, '2009-11-24 10:53:16.97', 'epoiseau', 'The actor Label Instruction Provider sends an order message including labelling instructions to the actor Label Broker');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (377, 1, 0, '2009-11-24 10:53:16.972', 'epoiseau', 'To be Completed');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (378, 1, 0, '2009-11-24 10:53:16.973', 'epoiseau', '<H3>Special Instructions</H3> In order to run that test the Data Manager needs :  <ul> <li>A friendly Order Placer </li> <li>Some way to have the observation entered in the POCDM actor : Using observations from a friendly POCRG is a solution. Other solution might be to use a simulator</li> </ul> <H3>Description</H3> The purpose of this test is to test the LAB-32 transaction between the Data Manager actor and the Order Filler. There are 2 cases to test in this test : <ol> <li>Unordered observation : in this case the Order Filler needs to return an order number</li> <li>New observation : in this case the Order Filler needs to search in its record for an order that matches the criteria found in the observation provided in ORU^R31 message</li> </ol> <H3>Evaluation</H3> <ol> <li>Unordered Observation <ul> <li>Check that the message send from the POCDM to the OF is of type ORU^R30</li> <ll>Use the proxy, and check the validation of the message by the Gazelle HL7 External Validation Service tool</li> <li>Check that the OF generates a new filler order number and provides it correctly to the POCDM (the value is provided in the ACK^R33 message at MSA.3</li> <li>Check that the ORU^R30 triggers a LAB-2 message (From the OF to the OP). The purpose of this message is for the OF to request the OP an Placer Order number. It is understood that the OP is not part of this test and that the OP may not provide any response. We are checking here the "TRIGGERING" of the LAB-2 message. The integration with the LAB-2 message will be tested in the group test.</li> <li>In case we actually have an OP acting in this test, check that the Placer Order Number is correctly stored in the OF database.</li> </ul> </li> <li>New observation  <ul> <li>Check that the message send from the POCDM to the OF is of type ORU^R31</li> <li>Use the proxy, and check the validation of the message by the Gazelle HL7 External Validation Service tool</li> <li>Check that the Order Filler tries to match an existing order in its data base, corresponding to this set of observations. The criteria used are in the context of the connectathon based only on the Patient. (Note that this are relaxed policies. In the real life the criteria, which are depending on site-defined policies, may be more complex.) </li> <li>In case no order can be matched in the Order Filler data base : Please check the evaluation steps of "Unordered Observation"</li> <li>If an order is matched :Check that the ORU^R31 triggers a LAB-1 message. "Order status change" notified by the Order Filler to the Order Placer is the purpose of this message. </li> </ul> </li> </ol>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (379, 1, 0, '2009-11-24 10:53:16.976', 'epoiseau', '<H3>Special Instructions</H3> You can run this test in the two modes: <ul> <li>Basic Profile with Patient Related Observation</li> <li>Continuous Mode With QC(non-patient) related Observation </li> </ul> <H3>Description</H3>  The purpose of this test is to test the LAB-31 transaction between the Device (POCRG) actor and the POCDM (Observation Reviewer)  actor. There are 2 cases to test in this test : <ol>  <li>Basic Profile: in this case the sending of observations messages requires these prior conditions :      <ul>       <li>Establishment of a conversation POCRG to POCDM</li>       <li>Sending Device Status POCRG to POCDM</li>        <li>Sending of the message "Request Observation" by POCDM to POCRG</li>      </ul> </li>        <li>Continuous Mode : in this case the event of reception of any observation by the the POCRG actor triggered the obseravtions message at once.</li>  </ol> <H3>Evaluation</H3> Please copy a dump of the all transaction messages in the chat window for the monitor to evaluate it. <ol> <li>Basic Profile  <ul> <li>Check the three steps described</li> <li>Check that the message send by the POCDM actor to the POCRG actor is OBS.R01</li> <li>Check in the POCDM data base the observation stored and the patient ID</li> <li>Compare the patient ID from the POCRG message to the POCDM data base.</li> </ul>  </li>  <li>Continuous Mode  <ul> <li>Check that the message send by the POCDM actor to the POCRG actor is OBS.R02</li> <li>Check in the POCDM data base the observation stored and verify the configuration rules verified.</li> <li>Compare the observation from the POCRG message to the POCDM data base.</li>  </ul>  </li>  </ol> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (380, 1, 0, '2009-11-24 10:53:16.977', 'epoiseau', '<H3>Special Instructions</H3> You can run this test only  <ul> <li>If POCRG and POCDM actors are in "Continuous mode".</li> and  <li>If you implements the option Patient Identity Checking of LPOCT Integration Profile</li> </ul>  <H3>Description</H3> The purpose of this test is to test the LAB-30 transaction between the Device (POCRG) actor and the POCDM (Observation Reviewer)  actor.  <H3>Evaluation</H3> <li>Check that the message send by the POCDM actor to the POCRG actor is OBS.R01 and contains status_cd =''INI''. Please copy a dump of the OBS.R01 message in the chat window for the monitor to evaluate it. The monitor will check the following content in that message : <ul> <li>OBS.R01/HDR/HDR.control_id</li> <li>OBS.R01/SVC/SVC.status_cd ="INI"</li> <li>OBS.R01/SVC/PT/PT.patient_id</li> </ul> </li> <li>Check in the POCDM acknowledgement message ACK.R01. <ul> <li>ACK.R01/ACK/ACK.ack_control_id</li> <li>ACK.R01/ACK/ACK.note_txt</li> </ul> </li> Verify that  <ul> <li>OBS.R01/HDR/HDR.control_id = ACK.R01/ACK/ACK.ack_control_id</li> <li>OBS.R01/SVC/PT/PT.patient_id is the identifier of the patient named in ACK.R01/ACK/ACK.note_txt </li> </ul> </li');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (381, 1, 0, '2009-11-24 10:53:16.979', 'epoiseau', '<H3>Special Instructions</H3>    <li>This is a group test. Group tests are managed by a monitor.</li> <ul>  <li>POCRG ans POCDM actors shall support the option "Patient identity checking".</li>  <li>POCDM shall supported "Supervision by Laboratory"</li>  <li>If necessary, use the RIS Mall for OP functionality.</li> </ul>  <H3>Description</H3> <li>The purpose of this test is to test a complete workflow for the LPOCT profile.</li> <ol> <li>Order Placer OP create a new order(e.g. urine sticks)</li> <li>POCRG enter manually all information relevant for testing as an operator. It will precise  the operator identifier an name if known and the patient/visit identifier</li> <li>POCRG iniate then a Patient checking identity :  Test Step for Transaction LAB-30 : Patient Identity Checking</li>  <li>POCRG enter manually the results to the test, and sends the observation set with its related data :Test Step for Transaction LAB-31 : Produced observation set </li> <li>Test Step for Transaction LAB-32 :  Accepted Observation Set</li> </ol> <H3>Evaluation</H3> <p>The Connectathon Monitor will  check the results of each transaction as the test is executed.<br> For example <ol>  <li>For LAB-30 transaction : the patient_id in POCRG message OBS.R01 is the same patient in the POCDM data base.  </li> <li> For LAB-31 transaction : display on the POCDM the observation received. </li> <li>For LAB-32 transaction if: <ol> <li>the order match an existing order in the OF data base that triggered "Ordered Result Received" (Transaction LAB-1 ).</li> <li>otherwise that triggered "Create Placer Order" (Transaction LAB-2)</li> </ol> </li> <li>You can also compare the order placer and the order filler number assigned </li> <li>At last verify that the status of this order on the ORT is completed</li> </ol>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (382, 1, 0, '2009-11-24 10:53:16.981', 'epoiseau', '<p>The purpose of this test is to test a complete workflow for the LSWF profile.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (383, 1, 0, '2009-11-24 10:53:16.984', 'epoiseau', '<H3>Special Instructions</H3>    <p>None</p> <H3>Description</H3> <p>The purpose of this test is to test a complete workflow for the LTW profile.</p> <p>This test has 2 steps:</p>  <li>Placer Odering Step</li> <li>Filler Ordering Step</li> <H3>Evaluation</H3> <p>Demonstrate transactions for Connectathon monitor.</p> <p>The Connectathon Monitor will  check the results of each transaction as the test is executed.</p> <li>Check that the message send by all the actors are corrected depends on the transaction</li> <li>Use the proxy, and check the validation of the message by the Gazelle HL7 External Validation Service tool</li> <ol> <li>For the placer ordering step :       <p>check the oder placer number on the field: ORC-4, ORC-2 or OBR-2 in the messages used for the transactions.</p> </li> <li>For the fthe filler ordering step:  <p>check the filler order number on the field : ORC-3 or OBR-3 in the messages used for the transactions</p> </li> <li>Check when the OP and the ORT actors are different in the test that the "Order Status Changed LAB-1 Transactions" are triggered. </li> </ol> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (384, 1, 0, '2009-11-24 10:53:16.986', 'epoiseau', '<H3>Special Instructions</H3> It is possible that the sample images provided by the Acquisition Modality actors at the Connectathon do not fully exercise the Image Display requirements in the MAMMO profile.  The Connnectathon Project Manager, Mammography clinical expert, or a Connectathon Monitor may ask an Image Diplay actor to execute one or more of the tests in the <i>IHE/MESA Image Display Tests - Mammography Image Profile </i>document. <p> (Not all of the tests in this document were required in pre-Connectathon testing.) </p> <H3>Description</H3> These tests use an image set compiled by David Clunie to exercise the requirements in the MAMMO profile.  These studies are available on the Connectathon CENTRAL_ARCHIVE.  The Test Steps and Evaluation are contained in the <i>IHE/MESA Image Display Tests - Mammography Image Profile </i>document.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (385, 1, 0, '2009-11-24 10:53:16.988', 'epoiseau', '<H3>Special Instructions</H3> A clinical expert or a general Connecathon Monitor will evaluate this test.  If you are using a clinical expert, the representative of the Image Display system is responsible for arranging a time for him/her to do the evaluation with you. <H3>Description</H3> This test verifies that the Image Display is capable of displaying annotation with values from attributes required by the MAMMO profile, and by default ensuring that they are encoded correctly in the DICOM images by the Acquisition Modality. Several datasets with different views will be produced during this test. The Modality can send images directly to the workstation (DICOM C-STORE, though not an IHE transaction), or the Modality can send the images to the CENTRAL_ARCHIVE for later retrieval by the Image Display. <H3>Evaluation</H3> The Connectathon Monitor will check for the display of each attribute.   If an attribute is not seen on the Image Display, the Connectathon Monitor may ask the Acquisition Modality or Image Display actor to dump the DICOM header to verify that it was encoded properly.  <p>The Connectathon Monitor will check for the display of  each attribute.   If an attribute is not  seen on the Image Display, the Connectathon Monitor may ask the Acquisition  Modality or Image Display actor to dump the DICOM header to verify that it was  encoded properly.<br>    <br>   (1) The Image Display will demonstrate that the following <strong>''<em>Clinical''  attributes</em></strong> are displayed.  If  annotated on the image, these shall be displayed opposite the chest wall (as  determined by Patient Orientation (0020,0020)) to avoid covering breast tissue.</p> <ul>   <li>E7: Patient''s Name                                    (0010,0010)</li>   <li>E8: Patient ID                                           (0010,0020) </li>   <li>E9: Patient''s Birth Date                            (0010,0030)</li>   <li>E10: Patient''s Age                                      (0010,1010)</li>   <li>E11: Acquisition Date                                 (0008,0022) </li>   <li>E12: Acquisition Time                                 (0008,0032)</li>   <li>E13: Operators'' Name                                 (0008,1070)  <br>                                                                  (this may be name or initials)</li>   <li>E14: Institution Name                                 (0008,0080)</li>   <li>E15: Station Name                                      (0008,1010)</li>   <li>E16: Gantry ID                                           (0018,1008) <br>                                                                  (for  CR; overrides Station Name,<br>                                                                    which is plate reader)</li> </ul> <p>(2) The Image Display will demonstrate that the following <strong>''<em>Investigative''  attributes</em></strong> are made available to the ordinary user, but they need not  necessarily be annotated directly on the image, e.g. They might be displayed in  a separate pop-up window.</p> <ul>   <li>E17: Manufacturer                                      (0008,0070)</li>   <li>E18: Institution Address                             (0008,0081)</li>   <li>E19: Manufacturer''s Model Name              (0008,1090)</li>   <li>E20: Device Serial Number                         (0018,1000)</li>   <li>E21: Detector ID                                         (0018,700A)</li>   <li>E22: Software Versions                              (0018,1020)</li>   <li>E23: Date of Last Detector Calibration      (0018,700C)</li> </ul> <p> (3) The Image  Display will demonstrate that <strong>''<em>Technical'' attributes</em></strong> are displayed.<br>   If annotated on the image, these shall be displayed  opposite the chest wall (as determined by Patient Orientation (0020,0020)) to avoid covering breast tissue.  <i>Note that some attributes to be displayed may be displayed in different units of measuremen than those encoded in DICOM (e.g. Organ Dose is encoded in dGy but is always displayed in mGy, Compression Force is encoded in Newton (N) but it is usually displayed in kilogram force (kgf), etc.). The the unit of measurements used for the display may be chosen by the vendor.</i></p> <ul>   <li>E24: KVP                                                    (0018,0060)</li>   <li>E25: Exposure                                             (0018,1152)</li>   <li>E26: Exposure Time                                    (0018,1150)</li>   <li>E27: Filter Material                                     (0018,7050)</li>   <li>E28: Anode Target Material                        (0018,1191)</li>   <li>E29: Compression Force                             (0018,11A2)</li>   <li>E30: Body Part Thickness                           (0018,11A0)</li>   <li>E31: Positioner Primary Angle                    (0018,1510)</li>   <li>E32: Relative X-ray Exposure                     (0018,1405)</li>   <li>E33: Entrance Dose in mGy                        (0040,8302)</li>   <li>E34: Organ Dose                                         (0040,0316)</li> </ul> <p>E35: (4)  The Image Display will demonstrate that it is possible to turn on or off the <strong><em>Clinical,  Investigative</em></strong> or <strong><em>Technical</em></strong> annotations at the user''s  discretion.</p> <p>(5) The Image Display will demonstrate that rendering of <strong><em>View  Information</em></strong> conforms to the requirements in the MAMMO Profile.  Details follow:</p> <ol> <ul>   <li>E36: Image Displays annotate the viewport with abbreviations  derived from the value of Image Laterality (0020,0062), View Code Sequence  (0054,0220) and any values of View Modifier Code Sequence (0054,0222) Items  that are present.  See next item.</li>   <li>E37: The specific abbreviations to be displayed are as  defined as follows (unless overridden by national extensions).  Notes that spaces and other delimiters are  permitted between components of the abbreviations.</li> </ul> <pre> View for Mammography (DICOM CID 4014) SNM3	R-10224 		medio-lateral 			ML SNM3 	R-10226 		medio-lateral oblique 			MLO SNM3	R-10228 		latero-medial 			LM SNM3 	R-10230 		latero-medial oblique 			LMO SNM3 	R-10242 		cranio-caudal 			CC SNM3 	R-10244 		caudo-cranial (from below) 		FB SNM3 	R-102D0 		superolateral to inferomedial oblique 	SIO SNM3 	R-102CF 		exaggerated cranio-caudal 		XCC SRT 	R-1024A 		cranio-caudal exaggerated laterally 	XCCL SRT 	R-1024B 		cranio-caudal exaggerated medially 	XCCM View Modifier for Mammography (DICOM CID 4015) SNM3 	R-102D2 		Cleavage (CC)			CV SNM3 	R-102D1 		Axillary Tail (MLO)			AT SNM3	R-102D3 		Rolled Lateral (any) 			...RL SNM3 	R-102D4 		Rolled Medial (any)			...RM SRT 	R-102CA 		Rolled Inferior (any) 			...RI SRT 	R-102C9 		Rolled Superior (any) 			...RS SNM3 	R-102D5 		Implant Displaced (any) 		...ID SNM3 	R-102D6 		Magnification (any) 			M... SNM3 	R-102D7 		Spot Compression (any) 		S... SNM3 	R-102C2 		Tangential (any) 			TAN </pre>  <ol> <ul>   <li>The Image Laterality shall be prepended to the  abbreviation, e.g., a right CC view shall be displayed as "RCC"</li>   <li>A CC view with a cleavage modifier shall be  annotated as only "CV" if Image Laterality has a value of "B", i.e., the "CC"  shall not be displayed, and the laterality shall be omitted (in which case the  left and right breast can be determined from the value of Patient Orientation  (0020,0020)); otherwise "LCV" or "RCV" shall be used</li>   <li>A right MLO view with the axillary tail modifier  shall be annotated only as "RAT", i.e., the "MLO" shall not be displayed</li>   <li>The implant displaced modifier shall be appended  as a suffix to the view, as if it were defined as "...ID", e.g., a right implant  displaced CC view would be annotated as "RCCID"</li>   <li>A spot compression modifer shall be prepended as  a prefix to the view, as if it were defined as "S...", e.g., a left spot compression  CC view would be annotated as "LSCC"</li>   <li>A tangential modifier shall be annotated as only  "TAN", i.e., the "CC" or whatever else is encoded as the view, shall not be  displayed</li>   <li>When multiple prefix or suffix modifiers are  present, they shall be sorted alphabetically, e.g. a right magnified, spot  compression, implant displaced, rolled lateral CC view would be annotated as  "RMSCCIDRL"</li> </ul> <p>E38: (7) The Image Display will demonstrate that it is  possible to turn on or off the <strong><em>View</em></strong> annotation at the user''s  discretion.</p> <p>(8) The Image Display will demonstrate that display of <strong><em>Size  Information</em></strong> conforms to the requirements in the MAMMO Profile.  The Image Display shall be capable of  annotating the displayed images with the following:</p> <ul>   <li><u>E39: </u><strong><u>Pixel Size Magnification -- Number of  displayed pixels relative to the number of encoded image pixels,</u></strong> such  that a factor of 1.0 (or 100%) means 1:1 rendition, a factor of less than 1.0  means that one pixel on the display represents more than one pixel in the  encoded image (minification), and a factor of greater than 1.0 means that  pixels in the encoded image have been replicated or interpolated to span  multiple displayed pixels (magnification)</li>   <li><u>E40: </u><strong><u>True Size Magnification -- Size of the displayed pixels relative to true size</u></strong>, such that a factor of 1.0 (or  100%) means true size, a factor of less than 1.0 means smaller than true size,  and a factor of greater than 1.0 means larger than true size</li> </ul> <p> (9) The Image  Display will demonstrate that it:</p> <ul>   <li>E41: can display a ruler or caliper indicating the physical  size of the displayed image, for the purpose of providing a visual cue to the  user of the general size of the features in the image.</li>   <li>E42: enables the user to turn on or off the ruler</li>   <li>E43: provides a means of accurately measuring distance  between two points based on the physical size of the image pixels</li> </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (386, 1, 0, '2009-11-24 10:53:16.993', 'epoiseau', '<H3>Special Instructions</H3> The Evidence Creator should use images produced in the MAMMO_MOD_Store or MAMMO_MOD_IM_Interface test as data for this test. No mechanism for getting "For Processing" images to the Evidence Creator is defined in the MAMMO profile.  The Evidence Creator can ask a Modality to push images directly to it or it may retrieve the images from the CENTRAL_ARCHIVE. <H3>Description</H3> The Evidence Creator and Image Manager test their interfaces for: <ul> <li>Storage of SRs - [RAD-43] Evidence Document Stored <li>Storage Commitment - [RAD-10] </ul> This test is focused on the C-STORE and Storage Commit transactions.  The contents of the SRs themselves are tested in test MAMMO_EC_Display. <H3>Evaluation</H3> Connectathon Monitor will ask the Image Manager to show evidence that: <ul> <li>E4: The SRs are successfully stored <li>E5: the objects are stored as full-fidelity objects (ie., no DICOM data elements are deleted). <li>E6: Storage Commitment was successful (N-EVENT-REPORT was sent). </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (387, 1, 0, '2009-11-24 10:53:16.995', 'epoiseau', '<H3>Special Instructions</H3> The Image Manager/Archive must complete test MAMMO_MOD_IM  before this test can be run with the Image Display actor.     <p> If the Image Display or Image Manager actor also participates in the SWF profile, it must run at least one instance of this test, but may also run two instances of SWF_ID_IM with different actors in order to meet both the SWF and MAMMO requirements. </p> <H3>Description</H3> The test verifies the ability of the Image Display and Image Manager actors for these transactions: <ul> <li>[RAD-14] Query Images <li>[RAD-16] Retrieve Images <li>[RAD-44] Query Evidence Documents <li>[RAD-45] Retrieve Evidence Documents </ul> The specific requirements for rendering digital mammography images and Mammography CAD SR objects are tested in other tests. <H3>Evaluation</H3> <p><i> Evaluators and participants should note that this section contains all query keys documented in the Technical Framework.  At the North American Connectathon in Chicago, many Display vendors were surprised that these are requirements.  We are *not* failing systems this year if you do not support everything below.  However, the Connectathon Monitor will verify that you have a reasonable implementation that allows you to query the Image Manager using different parameters. </i></p> On the <b>Image Display </b>  <ul> <li>The Connectathon Monitor will ask the operator to demonstrate it can query/retrieve MAMMO CAD SRs. <li>The Connectathon Monitor will ask the operator to demonstrate its support for the DICOM Study Root Q/R Information Model and Hierarchical Search. <p> It will demonstrate on its User Interface the ability to offer its user the following attributes as selection criteria (i.e., these required query keys for the Image Displays SCU (RAD TF-2 Table 4.14-1)). Query the Image Manager for combinations of:  </p> <b>STUDY LEVEL</b> Query Keys: <ul> <li>Study Date (0008,0020) <li>Study Date (0008,0020) <li>Study Time (0008,0030) <li>Accession Number (0008,0050)  <li>Patient''s Name (0010,0010) <li>Patient ID (0010,0020) <li>Study ID (0020,0010)  <li>Study Instance UID (0020,000D) <li>Modalities in Study (0008,0061) <li>Referring Physician''s Name (0008,0090) </ul> <b>SERIES LEVEL</b> Query Keys: <ul> <li>Modality (0008,0020) <li>Series Number (0020,0011)  <li>Series Instance UID (0020,000E) <li>Request Attributes Sequence (0040,0275).Requested Procedure ID (0040,1001)  <li>Request Attributes Sequence (0040,0275).Scheduled Procedure Step ID (0040,0009)   <li>Performed Procedure Step Start Date (0040,0244)  <li>Performed Procedure Step Start Time (0040,0245) </ul> <b>IMAGE LEVEL</b> Query Keys: <ul> <li>Instance Number (0020,0013)  <li>SOP Instance UID (0008,0018) </ul> <p> </p> <li>Verify the ability to retrieve by study, by series and by image. <li>If the Image Display supports query / retrieve by SOP Class UID (0008,0016), to retrieve just "For Presentation" images, test this capability. <li>Verify that studies are fully retrieved.  (Correct rendering of the images and Mammography CAD SR is verified in different tests). </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (388, 1, 0, '2009-11-24 10:53:16.997', 'epoiseau', '<H3>Special Instructions</H3> This tests focus on the requirements for display of FFDM images.  Rendering of images and Mammography CAD SRs is tested in MAMMO_MOD_EC_Display. <p> When entering results for this test in Kudu, the Image Display should initiate an instance of this test <b>when the results are complete</b>.  This allows you to also give credit to the Acquisition Modality which supplied the images without locking that system out of other testing while the Image Display is working on the rendering. </p> A clinical expert will evaluate this test.  The representative of the Image Display system is responsible for arranging a time for him/her to do the evaluation with you. <H3>Description</H3> The MAMMO_MOD_Display test is used to determine if the Acquisition Modality is entering the proper data in the DICOM FFDM images, and to determine if the Image Display is rendering the images properly. Several types of datasets will be produced for this test.  <p> The Image Display can retrieve sample images which the Modality stored to the Connectathon CENTRAL_ARCHIVE in test MAMMO_MOD_Store. Alternatively, the Modality can send images directly to the workstation (DICOM C-Store, though not an IHE transaction). </p> <p>Image Display please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find out what your peers have uploaded on the central archive </p> <H3>Evaluation</H3> Project Managers may find it helpful to dump the DICOM header in the images when evaluating this test.  Use Image Display to dump DICOM headers and to display images. If the Image Display cannot dump the DICOM header, we will find another method to check attribute values. <p> (1) The Image Display will demonstrate that: </p> <ul> <li>E44: it can display simultaneously a set of current and prior conventional four view screening mammography images (left and right CC and MLO views) <li>E45: it allows the user to adjust the grayscale contrast.  The Evaluator ensures that grayscale contrast adjusts smoothly and continuously without sudden discontinuities or loss of quality in the very dark or light regions. <li>E46: when contrast is adjusted or the image is inverted, the air outside the breast tissue remains uniformly black when conditional there is pixel padding (0028,0120) or Pixel Padding Value Range (0028,0tbd) is encoded in the image header <li>E47: the initial display of the images is the correct orientation and justification, without the user needing to flip or rotate into achieve the correct orientation <p><i>(Note the following from RAD TF-2:4.16.4.2.2.1.1.2:  "...images are normally displayed such that the axilla is towards the top of the viewport, except for cleavage views (which contain two axillas)."</i></p> <li>E48: it allows the user to select or configure hanging protocols defining: <ul> <li>the placement of images relative to one another  <li>the required orientation of the images <li>the display of current and prior images <li>the sequence of layouts displayed  </ul> <li>E49: it can justify the image horizontally to the left or right side of the viewport rather than centering it, to avoid displaying any unnecessary padding between the adjacent chest walls of back to back images <li>E50: does not display excessive window decoration (such as scroll bars) between back to back viewports <li>E51: it can display multiple images such that all images are at the <b>same relative physical size</b>,  <p><i>(Note the following from RAD TF-2:4.16.4.2.2.1.1.3.1: " For example, a user reviewing a four-view screening mammogram together with a four-view prior mammogram might want to display eight viewports, each showing one view, such that the each view is at the same relative physical size, even if the images were obtained on detectors with different sized pixels. This allows the user to compare features in the prior and current images to visually assess whether or not they have changed in size.)"</i></p> <li>E52: it can display multiple images such that <b>all images are true size</b> <p><i>(Note the following from RAD TF-2:4.16.4.2.2.1.1.3.2:  "True size is defined as the display of an image such that an object in the image when measured with a hand-held ruler on the surface of the display measures as closely as possible to the true physical size of the object if located on the front face of the detector housing. This mode of display is not intended for geometrically magnified views, since the geometrically magnified view would then be displayed too small.)"</i></p> <li>E53: it can display multiple images such that each encoded pixel occupies one display pixel in the viewport. If the size of the pixel data exceeds the size of the viewport, it may not be possible to display all of the encoded pixels at once, in which case some form of pan or quadrant navigation functionality is provided.  (Since there is no minification or magnification, images with different pixel physical size will be displayed in this mode such that the physical size in the patient will appear different.) <li>E54: it provides the user with the ability to select amongst the window and VOI LUT choices available in the image object. Subsequent to the initial application of the chosen contrast transformation, the Image Display actor allows the user to adjust the contrast without reverting to a purely linear transformation. <p><i>(Note the following from RAD TF-2:4.16.4.2.2.1.1.3.4:  "...If the chosen contrast transformation is a lookup table, then the Image Display shall allow the input value of the lookup table to be stretched and translated so as to give the affect of adjusting contrast and brightness whilst applying the same general shape as the curve encoded in the lookup table. To provide feedback to the user, the "window width" can be reported as the adjusted range of input values to the LUT, and the "window center" can be reported as the center value of that range."</i></p>  <li>E55: To test "accidental reading of prior studies", the Image Display will demonstrate that it can display a warning to the use if none of the studies being displayed is within a user-configurable period from the current real time.  The Image Display will demonstrate how this time period can be configured.   (It may be necessary to reconfigure this value on the image display, or to edit a DICOM header to change the Acquistion Date (0008,0022) in order to test this condition. <li>E56: To test that the Image Display is able to conform to local, regional or national regulatory requirements for luminance settings, the Image Display will demonstrate that the minimum and maximum luminance for the display is configurable. </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (389, 1, 0, '2009-11-24 10:53:17.001', 'epoiseau', '<H3>Special Instructions</H3> When entering results for this test in Kudu, the Image Display should initiate an instance of this test when the results are complete.  This allows you to also give credit to the Evidence Creator (which created the Mammography CAD SR) and the Acquisition Modality (which supplied the images) without locking those two systems out of other testing while the Image Display is working on the rendering.  (The Modality is tested indirectly because the CAD is done on a Modality vendor''s images; this is an ''optional'' test for Acq Modality actors since this is not a requirement in the profile, but you may be asked to run this test to help your Image Display colleagues.) <p> The Evidence Creator should use the images produced in test MAMMO_MOD_Store as data for this test.   </p>  <p>Image Displays, please use the <em><a href=system_con_object.php>Objects Information</a></em> page under ''Objects to Render'' to find out what your Modality peers have uploaded on the Central Archive </p>  <p> No mechanism for getting "For Processing" images to the Evidence Creator is defined in the MAMMO profile.  The Evidence Creator can ask a Modality to push images directly to it or it may retrieve the images from the CENTRAL_ARCHIVE. </p> The Image Display can retrieve images and SRs from the CENTRAL_ARCHIVE, or the EC can C-STORE directly to the workstation (though this not a transaction in the MAMMO profile). <p>A clinical expert will evaluate this test.  The representative of the Image Display system is responsible for arranging a time for him/her to do the evaluation with you. </p> <H3>Description</H3> The MAMMO_MOD_EC_Display test is used to determine if the MAMMO Evidence Creator is entering the proper data in the Mammography CAD SR objects and to determine if the Image Display is rendering them properly. <p>This test is also used to send sample SRs to the CENTRAL_ARCHIVE to give other systems access to these objects, along with the images. </p> <H3>Evaluation</H3> Project Managers will find it helpful to dump the DICOM header in the Mammography CAD SR object when evaluating this test.  Use Image Display to dump DICOM headers and to display images. If the Image Display cannot dump the DICOM header, we will find another method to check attribute values. <p> (1) The Image Display will demonstrate that: </p> <ul> <li>E57: it makes the user aware that CAD marks are available for display <li>E58: it indicates whether or not CAD marks are currently activated <li>E59: if more than one set of Mammography CAD SR objects are available that are applicable to the same image (e.g. CAD was run more than once on the same images), <b>then all shall be made available</b> for display at the user''s discretion <li>E60: it displays the date and time the CAD was performed </ul> <p> The Image Display will demonstrate that it applies marks on the displayed image for all findings encoded in the Mammography CAD SR object with a (111056, DCM, "<b>Rendering Intent</b>") value of (111150, DCM, "<b>Presentation Required</b>"). </p> <p> E61: (3) The Image Display will demonstrate that the CAD marks are displayed properly when the image is flipped or rotated.</p> <p> E62: (4) The Image Display will demonstrate that it makes the following annotations available for display <i>if they are encoded in the SR</i>: <ul> <li>E63: Manufacturer	(0008,0070) <li>E64: (111001, DCM, "Algorithm Name") and (111003, DCM, "Algorithm Version") <li>E65: (111071, DCM, "CAD Operating Point") <li>E66: Content Date (0008,0023) and Content Time (0008,0033) </ul> <p> E67: (5) Ask the workstation to display all data produced by Evidence Creator. The Evidence Creator may have created Mammography CAD SRs for multiple studies created by the Modality system.  Evaluate these also. </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (390, 1, 0, '2009-11-24 10:53:17.004', 'epoiseau', '<H3>Special Instructions</H3> This test is a subset of the SWF_MOD_IM_Interface Connectathon Test Case (MPPS is not tested here). For Modality and Image Manager systems participating in the SWF profile you should run SWF_MOD_IM_Interface instead to avoid doing redundant testing. <H3>Description</H3> The Modality and Image Manager test their interfaces for  <ul> <li>Storage of Images <li>Storage Commitment </ul> <H3>Evaluation</H3> Connectathon Monitor will ask the Image Manager to show evidence that: <ul> <li>E1: The images for patient MOD^IM are successfully stored <li>E2: the objects are stored as full-fidelity objects (ie., no DICOM data elements are deleted). <li>E3: Storage Commitment was successful (N-EVENT-REPORT was sent). </ul>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (391, 1, 0, '2009-11-24 10:53:17.005', 'epoiseau', '<H3>Special Instructions</H3> Acquisition Modality actors perform ONE instance of this test.  If your Modality is registered in the Scheduled Workflow profile, you may have already run test SWF_MOD_Store.  <b>This should be done on the first day of the Connectathon.</b> <H3>Description</H3> All Acquisition Modalities participating in the MAMMO profile must store images to the Connectathon CENTRAL_ARCHIVE. This will give Image Manager, Evidence Creator, Image Display and Print Composer actors to access these images for their testing.  <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> In general, Acquisition Modalities should provide studies that demonstrate the <b>entire range of capabilities/options</b> available on your modality.  A wide variety will improve the interoperability testing with Image Manager, CAD, Image Display and Printer systems.  E.g., consider the following when selecting samples to store: </p> <ul> <li>Images must contain all required attributes identified in RAD TF-1:4.8.4.1.2.3. <li>Both For Processing and For Presentation images should be stored (Digitizer modalities store only For Presentation images) <li>Image Display actors will benefit from displaying studies  <ul> <li>with different View (0054,0220) and View modifiers (0054,0222) and Patient Orientation (0020,0020) encoded <li>different pixel sizes, as encoded in Imager Pixel Spacing (0018,1164) <li>a variable matrix size <li>VOI LUT Function (0028,1056) with values of SIGMOID, LINEAR, with and without Window Width and Window Center attributes encoded <li>with background air suppression by encoding Pixel Padding Value (0028,0120) or Pixel Padding Value Range (future attribute tbd) </ul> <li>Acquisition Modalities that support the Partial View option must also store a study of this type. </ul>  <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>Optionally, the Connectathon Monitor may view a DICOM header for an image in one or more studies and verify that the attributes required as R+ in RAD TF-2 Table 4.8.4.1.2.3-1 are encoded. </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (392, 1, 0, '2009-11-24 10:53:17.01', 'epoiseau', '<H3>Special Instructions</H3> A clinical expert will evaluate this test.  The representative of the Print Server system is responsible for arranging a time for him/her to do the evaluation with you. <H3>Description</H3> In general, Print Composers should submit print requests that demonstrate the entire range of capabilities/options available on your system.  A wide variety of print requests will improve the interoperability testing with Print Servers.  Consider the criteria in the Evaluation section when selecting samples to print. <p>The Connectathon CENTRAL_ARCHIVE is the source for Mammography studies. </p> <H3>Evaluation</H3> Connectathon Monitors will examine the printed images, checking the following criteria: <p> (1) The Print Composers will demonstrate that it: <ul> <li>E67: does 12-bit printing <li>E68: justifies the images such that the chest wall is printed as close to the edge of the film as the Print Server is capable. <li>E69: can burn into the pixel data these <b>identification and clinical annotations</b> defined for Image Displays: <ul> <li>Patient''s Name			 <li>Patient ID			  <li>Patient''s Birth Date 		 <li>Patient''s Age			 <li>Acquisition Date			  <li>Acquisition Time			 <li>Operators'' Name (this may be name or initials) <li>Institution Name 	 <li>Station Name			 <li>Gantry ID (not req''d for Apr 08 EU Connectathon) </ul> <li>E70: can burn into the pixel data the <b>Institution Address</b> (0008,0081) <li>E71: can burn into the pixel data these <b>Technical Factor</b> annotations: <ul> <li>KVP				 <li>Exposure				 <li>Exposure Time	 <li>Filter Material		 <li>Anode Target Material		 <li>Compression Force			 <li>Body Part Thickness			 <li>Positioner Primary Angle	 <li>Relative X-ray Exposure	 <li>Entrance Dose in mGy	 <li>Organ Dose	 </ul> <li>E72: can burn into the pixel data <b>annotation of View Information</b> derived from Image Laterality (0020,0062), View Code Sequence (0054,0220) and any values of View Modifier Code Sequence (0054,0222) items that are present.  The specific abbreviations match the format required for Image Display actors. <li>E73: can burn into the pixel data <b>a ruler, caliper or other form of distance scale</b> <li>E74: can burn into the pixel data aVOI LUT transformation (linear, sigmoid or tabular) <i>as selected by the user</i> from those available in the original image <i>or as otherwise provided by the user</i> </ul> <p> E75: (2) The Connectathon Monitor will verify that the Print Composer sends the Maximum Density attribute (2010,0130) in the print request. </p> <p> (3) The Print Server will demonstrate that it: </p> <ul> <li>E76: does 12-bit printing <li>E77: prints on transmissive media <li>E78: is capable of true size printing  <p><i>(Note the following from RAD TF-2: 4.23.4.8:  "...true size printing(is) based on the Requested Image Size (2020,0030) and shall attain the requested size with a precision of a maximum 2% error in linear distance (this precision requirement is chosen based not any implied or required accuracy of measurements from film or projection radiography, but rather because current electrical, mechanical and optical technology readily allows for this precision, and deviation beyond this value indicates a fundamental flaw in the implementation of the protocol or logic)"</i></p> <li>E79: can print with a border between the chest wall edge of the digital mammography image and the physical edge of the film no greater than 5mm, so that the printed films can be hung on a light box with the chest wall edges of corresponding views directly abutted.  <li>E80: can apply the Maximum Density attribute (2010,0130) received in the print request, and prints with a maximum optical density no less than 3.5 <li>E81: can use a Presentation LUT Shape (2050,0020) value of either "IDENTITY" or "LIN OD" and the Presentation LUT Sequence (2050,0010) <p><i>"LIN OD" and the Presentation LUT Sequence (2050,0010) (Note the following from RAD TF-2: 4.23.4.8:  "... support for a Presentation LUT Shape value of "LIN OD" by Print Servers is specified for Mammography since the expected transmitted illumination of mammography view boxes on which printed film may be hung exceeds the range of illumination for which the Barten model is defined, and hence it may be difficult to achieve consistency between prints, and between prints and displays. It allows the Print Composer to use "LIN OD" to have greater control over the optical density of the printed film, and to take what action is necessary to result in consistency of appearance for the anticipated viewing conditions.")</p></i> </ul> <ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (393, 1, 0, '2009-11-24 10:53:17.014', 'epoiseau', '<H3>Special Instructions</H3><p> <p></p> <p>Experience has shown that Connectathon tests are run most efficiently if 2, or at most 3,    systems are involved in a test. Thus, most tests exercise an exchange of transactions between 2    actors. </p> <p>Later in the week, Connectathon systems are assigned to groups to test an end-to-end workflow    for all actors in profiles such as Radiology SWF and MAWF, Cardiology CATH, ECHO and STRESS, and    the ITI XDS.a and XDS.b profiles. Workflow tests are executed step-by-step during an assigned    2-hour time slot under the supervision of a Connectathon monitor who helps facilitate the process    and checks for results as transactions are exchanged between systems. </p> <p> <b>You should not start this test on your own.</b> A Connectathon Monitor will visit your    system when it''s time to start the Group test you''re assigned to.</p> <p>Test Set-up:</p> <ol>     <li>All systems must ensure they''re configured to talk to their partners in this Group test     BEFORE the start time of the test.</li>     <li>The DSS/OF will schedule this procedure for the Modality system in this test: (MAWF0002,     99IHERADTF, Screening Mammography, left). The DSS/OF can create its own patient or use an ADT     system to create a patient for this test. The Connectathon Monitor may give you a patient name     to use; otherwise, make up your own.</li>     <li>The Image Manager should be configured as the PPS Manager to forward PPS messages to the     DSS/OF.</li>     <li>The Modality should configure its system to send PPS messages to the Image Manager. </li>     <li>The Image Manager should be configured to <b>      <i>hide</i>     </b> images rejected for safety and quality reasons.</li> </ol> </p><H3>Description</H3><p>This Group test runs through transactions described in the use case <b>View Corrections after     Completed Image Acquisition</b> in RAD TF-23: 23.3.2. A screening procedure for the left breast    is scheduled, but the modality mistakenly labels the acquisition as the right breast and stores    the images to the Image Manager. Later, the modality acquires new images that are labeled    correctly and stores them. It creates a Key Object Selection that lists the incorrect images and    marks them "Rejected for Patient Safety Reasons". Later, when the study is retrieved by the Image    Display, only the correct images are retrieved and displayed, since the Image Manager has been    configured to hide incorrect images from requests to query/retrieve.</p><H3>Evaluation</H3><p>Connectathon monitors: See verification items in each test step.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (394, 1, 0, '2009-11-24 10:53:17.016', 'epoiseau', '<H3>Special Instructions</H3><p> <p>The Image Manager must run this test <i>before</i> it runs test    <b>MAWF_Quality_Reject_ID_IM</b>.</p> <p>The Image Manager must be configured for "Regular Use", ie.  When the Image Manager receives a Key Object Select with the Document Title, "Rejected for Quality    Reasons", for the KOS instance and all its referenced images, the Image Manager returns SOP Instance UIDs in Query Responses, and the instances    in Patient, Study, Series, or Instance level retrievals.  (Rad TF-3: 4.66.4.1.3).  IE, it does not hide images rejected for quality reasons.</p> <p>An Acquisition Modality is needed to help with this test to store a study to the Image Manager,    but there is no Modality functionality evaluated in this test.</p> <p>The Evidence Creator must be configured to send its Creator PPS messages and Key Object    Selections to the Image Manager.</p> <p>DSS/OF actors are only required to run one instance of this test. (However, it may be asked to    run more than one to help other systems finish their testing.)</p> </p><H3>Description</H3><p>This tests the interaction between the Evidence Creator and Image Manager for rejecting images    for quality reasons by exchanging KOS,  Creator PS, and Storage Commitment messages.  It also verifies the ability of the Image Manager to send an Instance Availability Notification message to the DSS/OF when images are stored, and then to indicate that the images are available.</p><p>The ability of the Image Manager to ''hide'' or not hide the images in response to a query/retrieve request    from an Image Display is tested in other tests.</p><H3>Evaluation</H3><p>On the <strong>Evidence Creator</strong>, the Connectathon monitor may ask the operator to    demonstrate how to use the application to mark images as rejected, although this behavior is not    constrained by the Technical Framework.</p><p>On the <strong>Image Manager</strong>, the Connectathon monitor will verify:</p><ul>     <li>The Key Object Selection Document Title code is <i>(113001, DCM, Rejected for Quality      Reasons)</i> </li>     <li>The Document Title Modifier code is one of</li>     <ul>      <li>111207, DCM, Image artifact(s)</li>      <li>111208, DCM, Grid artifact(s)</li>      <il>111209, DCM, Posititioning</il>      <li>...etc...</li>      <li>111221, DCM, Unknown failure</li>      <li>113026, DCM, Double Exposure</li>     </ul>     <li>The Key Object Selection is stored as an instance in a new series of the rejected images''     study.</li>     <li>The Storage Commitment request was received from the Evidence Creator.</li> </ul><p>On the <strong>DSS/OF</strong>, the Connectathon monitor will verify:</p><ul>     <li>Instance Availability Notification message was received from the Image Manager.</li>     <li>It can demonstrate that all 4 images in the study are marked      available.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (395, 1, 0, '2009-11-24 10:53:17.018', 'epoiseau', '<H3>Special Instructions</H3><p> <p>The Image Manager must run test <b>MAWF_Quality_Reject_EC_IM</b> or test     <b>MAWF_Quality_Reject_Mod_IM</b>    <i>before</i> it runs this test.</p> <p>The Image Manager must remain configured for "Regular Use", ie. When the Image Manager receives a    Key Object Selection instance with the Document Title, "Rejected for Quality Reasons", for the KOS instance    and all its referenced images, the Image Manager returns SOP Instance UIDs in Query Responses,    and the instances in Patient, Study, Series, or Instance level retrievals. (Rad TF-3:    4.66.4.1.3). IE, it does not hide images rejected for quality reasons.</p> </p><H3>Description</H3><p>An Image Manager receives notification via a Key Object Selection document that some of the    images it has stored have been rejected for quality or patient safety. </p><p>The study used for this test is a 4-view screening mammogram created in test     <b>MAWF_Quality_Reject_EC_IM</b> or <b>MAWF_Quality_Reject_Mod_IM</b>. The two images for the    left breast (CC and MLO) were rejected for quality reasons.</p><p>The Image Display will demonstrate the query and retrieve real-time during evaluation.</p><p>The Image Display will also demonstrate its ability to query and retrieve a Key Image Note and respond to its contents.   </p><H3>Evaluation</H3><p>On the <strong>Image Display</strong>, the Connectathon monitor will observe the query and    retrieve real-time:</p><ul>     <li>At the beginning of the evaluation, verify that the study does not already exist on the     Image Display system. </li>     <li>Ask the Image Display to query the Image Manager for the patient''s     study. If the Image Display is capable of an image-level query, verify that 4 images appear     on the list returned by the Image Manager. </li>     <li>Ask the Image Manager to retrieve the study     (patient-level or study-level retrieve). Verify that all 4 images returned by the Image Manager.</li> </ul><p>Note that the KOS indicates that the two images for the left breast were rejected for quality (not safety) reasons.</p><p>The Image Display is required  by the MAWF profile to be configurable to support the 3 following behaviors in the event it receives a KOS indicating "rejected for quality reasons". The    Image Display will demonstrate for the Connectathon Monitor how it configures its system, <b>and the affect on the different settings on how the images in this study are displayed</b>.(The    Technical Framework does not constrain how the configuration is done, eg it may be through a service user    interface, a database setting, or something else.)</p><ol>     <li>Suppress from presentation the rejected instances in a KOS</li>     <li>Present the rejected instances referenced in this KOS and the KOS</li>     <li>Ignore the KOS and present the rejected images</li> </ol> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (396, 1, 0, '2009-11-24 10:53:17.02', 'epoiseau', '<H3>Special Instructions</H3><p> <p>The Image Manager must run this test <i>before</i> it runs test    <b>MAWF_Quality_Reject_ID_IM</b>.</p> <p>The Image Manager must be configured for "Regular Use", ie.  When the Image Manager receives a Key Object Select with the Document Title, "Rejected for Quality    Reasons", for the KOS instance and all its referenced images, the Image Manager returns SOP Instance UIDs in Query Responses, and the instances    in Patient, Study, Series, or Instance level retrievals.  (Rad TF-3: 4.66.4.1.3).  IE, it does not hide images rejected for quality reasons.</p> <p>The Modality must be configured to send its PPS messages and Key Object Selections to the Image    Manager.</p> <p>DSS/OF actors are only required to run one instance of this test. (However, it may be asked to    run more than one to help other systems finish their testing.)</p> </p><H3>Description</H3><p>This tests the interaction between the Modality and Image Manager for rejecting images for    quality reasons by exchanging PPS, KOS and Storage Commitment messages.  It also verifies the ability of the Image Manager to send an Instance Availability Notification message to the DSS/OF when images are stored, and then to indicate that the images are available.</p><p>The ability of the Image Manager to ''hide'' or ''not hide''  the images in response to a query/retrieve request    from an Image Display is tested in other tests.</p><H3>Evaluation</H3><p>On the <strong>Modality</strong>, the Connectathon monitor may ask the operator to demonstrate    how to use the application to mark images as rejected, although this behavior is not constrained    by the Technical Framework.</p><p>On the <strong>Image Manager</strong>, the Connectathon monitor will verify:</p><ul>     <li>The Key Object Selection Document Title code is <i>(113001, DCM, Rejected for Quality      Reasons)</i> </li>     <li>The Document Title Modifier code is one of</li>     <ul>      <li>111207, DCM, Image artifact(s)</li>      <li>111208, DCM, Grid artifact(s)</li>      <il>111209, DCM, Posititioning</il>      <li>...etc...</li>      <li>111221, DCM, Unknown failure</li>      <li>113026, DCM, Double Exposure</li>     </ul>     <li>The Key Object Selection is stored as an instance in a new series of the rejected images''     study.</li>     <li>The Storage Commitment request was received from the Evidence Creator.</li> </ul><p>On the <strong>DSS/OF</strong>, the Connectathon monitor will verify:</p><ul>     <li>Instance Availability Notification message was received from the Image Manager.</li>     <li>It can demonstrate that all 4 images in the study are marked     available.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (397, 1, 0, '2009-11-24 10:53:17.022', 'epoiseau', '<H3>Special Instructions</H3><p> <p>In order to run this test, the Acquisition Modality must first successfully complete test <b>     MAWF_Recall_OF_Mod</b>. </p> <p>The Image Display does the work in this test (retrieve and display the images). The Modality is    listed as an actor in this test so it gets credit for properly encoding the images displayed.</p> <p>The Image Display may be able to retrieve the study for this test from the Connectathon DICOM    Archive. Alternatively, the Acquisition Modality can send the images directly to the Image    Display system.</p> <p>If you obtain the study from the Connectathon DICOM Archive, the patient name will be of the    form: <b>Recall^Mod-system-name^OF-system-name</b> </p> </p><H3>Description</H3><p>Image Display systems present Recall case</p><H3>Evaluation</H3><p>The study in this test was created in a different test: MAWF_Recall_OF_Mod. It is a screening    mammogram of the left breast, followed by a diagnostic mammogram of the left breast, all obtained    under the same order (same Accession Number). The patient was recalled for a diagnostic procedure    due to clinical findings in the screening exam.</p><p>On the <strong>Image Display</strong> system, the Connectathon monitor will verify:</p><ul>     <li>The screening and diagnostic images are in the same study (have the same Accession Number).</li>     <li>The screening and diagnostic images are presented in one display layout .</li> </ul><p>The Technical Framework requires that the Image Display actor be able to display different procedures or additional views in specific presentation layouts, eg for conversion, recall or supplemmental images.  The connectathon monitor may ask to see how  the Display system can be configured to present Mammography images based on information in the images in the Procedure Code Sequence, Performed Protocol Code Sequence and Reason for Performed Procedure Code Sequence.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (398, 1, 0, '2009-11-24 10:53:17.026', 'epoiseau', '<H3>Special Instructions</H3><p> <p>The Acquisition Modality should complete this test before starting test <b>     MAWF_Recall_Mod_Display</b>.</p> <p>The Acquisition Modality will store its images to the Connectathon DICOM Archive. Exchange of    MPPS messages is not examined in this test.</p> </p><H3>Description</H3><p>This tests the interaction between the DSS/OF and the Acquisition Modality in the Recall Case    where, after initial screening images are acquired, an additional recall procedure is scheduled    for the same order (ie using the same Accession Number). The worklist item contains a Reason for    Requested Procedure Code of  <i>"Recall for patient symptoms/ clinical findings"</i>. The Image Display''s    handling of these images is tested in a different test: <b>MAWF_Recall_Mod_Display</b>.</p><H3>Evaluation</H3><p>The patient name and the accession number for the study stored for this test should be recorded    in the chat window. You will do your verification for this test on the Connectathon DICOM    Archive, where the images were stored.</p><p>On the <strong>Connectathon DICOM Archive</strong>:</p><ul>     <li>Find the study for this patient. You will be viewing the DICOM header for these images.</li>     <li>Verify that there are 3 images for this study, 2 screening images, plus 1 diagnostic image of     the left breast.</li>     <li>All three image headers contain the same Accession Number (0008,0050).</li>     <li>The Requested Procedure Code Sequence (0032,1064) Code Value, Designator, Meaning attributes     are populated with either <i>(MAWF0002, 99IHERADTF, Screening Mammography, left)</i> or      <i>(MAWF0005, 99IHERADTF, Diagnostic Mammography, left)</i> as appropriate.</li>     <li>The Reason for Requested Procedure Code Sequence (0040,100A) Code Value, Designator, Meaning     attributes are populated with either <i>(R-42453, SRT, Screening)</i> or <i>(111592      DCM, Recall for patient symptoms/ clinical findings)</i> as appropriate. (The diagnostic     image may have 2 items in the sequence, also including, for example <i>R-408C3, SRT,      Diagnostic</i>).</li>     <li>These attributes are populated:</li>l       <ul>         <li>Procedure Code Sequence (0008,1032) -- this sequence must contain codes from RAD TF-2:Table 4.5-5 (required for Connectathon testing)</li>         <li>Protocol Name (0018,1030) </li>         <li>Reason for Performed Procedure Code Sequence (0040,1012)</li>         <li>Performed Procedure Step Description (0040,0254)</li>         <li>Performed Protocol Code Sequence (0040,0260) </li>       </ul> </ul><p>If any of those values is missing or not correct, this test does not pass. In that case,    participants must determine if these values were not passed correctly in the MWL, or not encoded    properly at the modality.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (399, 1, 0, '2009-11-24 10:53:17.03', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Acquisition Modality actors perform ONE instance of this test. <b>This should be done on the     first day of the Connectathon </b>  </p> <p>The Modality system should arrive at the Connectathon with images for this test    <b>PRE-OBTAINED</b> and <b>PRE-LOADED</b> or you will waste a great deal of time! </p> <p>It is critical for Modality systems to bring sample images to the Connectathon that match the    Procedure Error and Procedure Modification cases in the MAWF profile. This test gathers your    images in a common repository so they are accessible by Image Display and Image Manager systems.    Images are captured on the connectathon DICOM Central Archive.</p> <p>Refer to RAD TF-1:23.3.1 for background information on the Procedure Error and Procedure    Modification use cases applicable to the sample images.</p> <p>To cover the test cases, please submit the following (both FOR PROCESSING and FOR PRESENTATION    images). You may find that images you have can be used for more than one of these cases:</p> <ol>     <li> <b>Supplemental Views Case:</b> standard 4-view screening images (MLO and CC view of each     breast) PLUS additional views (could be images due to presence of implants, due to large     breasts, accessory breast tissue, or add''l magnification views due to suspicious calcifications.</li>     <li> <b>Conversion Case:</b> eg unilateral to bilateral diagnostic: standard 4-view screening     images for left breast and also right breast.</li>     <li> <b>Screening Recall Case:</b> standard 4-view screening PLUS additional diagnostic images (eg     magnification view).</li>     <li> <b>Screening Technical Recall Case: </b> standard 4-view screening exam (will be used twice,     the 2nd time as a recall.</li> </ol> <p>To aid your partners in finding your samples, use the following guidance when creating patient names for your studies:</p> <ol>     <li> <i>Your-company-name</i>^Supplemental^Views  eg BestMedicalCo^Supplemental^Views</li>     <li> <i>Your-company-name</i>^Conversion^Case  eg BestMedicalCo^Conversion^Case</li>     <li> <i>Your-company-name</i>^Screening^Recall  eg BestMedicalCo^Screening^Recall</li>     <li> <i>Your-company-name</i>^Technical^Recall eg BestMedicalCo^Technical^Recall</li> </ol> </p><H3>Description</H3><p>You will store sample DICOM images, as identified in the Special Instructions section, to the connectathon DICOM Central Archive.  Note the suggested patient names.</p><p>Modalities could also find time to test directly sending their images to Image Manager and    Image Display actors.</p><H3>Evaluation</H3><p>There is no formal evaluation for this test. The purpose is to get sample images into the Central Archive    for others'' testing.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (400, 1, 0, '2009-11-24 10:53:17.033', 'epoiseau', '<p>Modality performs different procedures (with different MPPS cases) and communicates those results with the Image Manager</p> <p>In the descriptions to follow, SYS_NAME is a combination of the Modality and DSS/Order Filer systems under test For example: AGFACRSIEMENSIM Find and ADT, Order Placer, DSS trio to help with this test. This may be the MESA RIS Mall. Use the ADT system to register 5 inpatients:  <ul> <li>SYS_NAME^ONE</li> <li> SYS_NAME^TWO</li> <li>SYS_NAME^THREE </li> <li>SYS_NAME^FOUR </li> <li>SYS_NAME^FIVE</li> </ul>  <p>Use the Order Placer or RIS MALL to place single orders for TWO, THREE, FOUR</p> <p>Use the Order Placer or RIS MALL to  place two orders for FIVE that can be used for the Group Case</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (401, 1, 0, '2009-11-24 10:53:17.035', 'epoiseau', '<p>Modality performs different procedures (with different MPPS cases) and communicates those results with the Order Filler. Image Manager also participates and gets ADT events.</p>  <p>We are testing the Modality worklist query. Show the observer that the modality can query the MWL using any combination of the following keys : Patient''s Name (0010,0010), Patient ID (0010,0020), Accession Number (0008,0050), Requested Procedure ID (0040,1001)</p>  <p>We are testing the different MPPS cases : In Progress, Completed, Append, Abandonned');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (402, 1, 0, '2009-11-24 10:53:17.037', 'epoiseau', '<H3>Special Instructions</H3> Modalities which support this option run <strong>one instance</strong> of this test. <H3>Description</H3> <p>This test demonstrates support for the ASSISTED ACQUISITION PROTOCOL SETTING option (RAD-TF-2:4.6.4.1.2.4.2).  A Modality supports use of the protocol codes specified in the SPS selected from the MWL.</p> <H3>Evaluation</H3> This test shall be evaluated real-time.  The modality operator demonstrates for the Connectathon monitor that he/she can accept the protocol proposed by the set of Protocol Codes provided for the SPS selected from the worklist.  The operator shall not manually enter the attributes of the acquisition protocol.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (403, 1, 0, '2009-11-24 10:53:17.041', 'epoiseau', '<H3>Special Instructions</H3> Modalities which support this option run one instance of this test.None. <H3>Description</H3> <p>The Billing and Material 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> The Order Filler 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> <li>(0040,0320) Billing Procedure Step Sequence <li>(0040,0321) Film Consumption Sequence <li>(0040,0324) Billing Supplies and Devices Sequence </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (404, 1, 0, '2009-11-24 10:53:17.043', '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>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><ul>     <li>DCM 110500 Doctor cancelled procedure</li>     <li>DCM 110501 Equipment failure</li>     <li>DCM 110502 Incorrect procedure ordered</li>     <li>DCM 110503 Patient allergic to media/contrast </li>     <li>DCM 110505 Patient refused to continue procedure</li>     <li>DCM 110506 Patient taken for treatment or surgery</li>     <li>DCM 110507 Patient did not arrive</li>     <li>DCM 110508 Patient pregnant</li>     <li>DCM 110509 Change of procedure for correct charging</li>     <li>DCM 110510 Duplicate order</li>     <li>DCM 110511 Nursing unit cancel</li>     <li>DCM 110512 Incorrect side ordered</li>     <li>DCM 110513 Discontinued for unspecified reason</li>     <li>DCM 110514 Incorrect worklist entry selected</li>     <li>DCM 110515 Patient condition prevented continuing</li>     <li>DCM 110516 Equipment change</li>     <li>DCM 110521 Objects incorrectly formatted</li>     <li>DCM 110522 Object Types not supported</li>     <li>DCM 110523 Object Set incomplete</li>     <li>DCM 110524 Media Failure </li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (405, 1, 0, '2009-11-24 10:53:17.045', 'epoiseau', '<H3>Special Instructions</H3> Modalities which support this option run one instance of this test. The DSS/OF is an optional participant; RIS Mall could be used instead. <H3>Description</H3> The PPS Group Case allows an Acquisition Modality supporting the MODALITY GROUP CASE option to select two or more Scheduled Procedure Steps (SPS) from a Modality Worklist and perform a single acquisition. The PPS messages from the modality indicate the multiple scheduled steps and the single acquisition (RAD-TF-2:4.6.4.1.2.3.6 and A.1-4).  <p> Support for the Group Case is required for Acquisition Modalities in the PGP Profile (RAD TF-2:4.6.4.1.2.3.4). </p> <H3>Evaluation</H3> Examine the saved MPPS message.   The accession number (0008,0050) and the Study Instance UID (0020,000D) for the single PPS are the same as recorded in the Kudu chat window (and provided in the MWL).');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (406, 1, 0, '2009-11-24 10:53:17.047', 'epoiseau', '<H3>Special Instructions</H3>   <ul>    <li>Notification Senders are required to support one of the "Acknowledgement Request..." options     (SMTP, POP3 and/or IMAP). To run this test, you will need to seek a Notification Receiver which     supports the "Send Acknowledgement" option.</li>    <li>For the purpose of testing NAV acknowledgements, the Notification Sender will create an email     account for itself that it will encode in the notification as an embedded <b>mailto</b> link.     This can be a gmail account, for example. </li>    <li>Test <b>NAV_Exchange_Notification</b> should be run in parallel with this one. Steps 10-60     are the same in both tests, plus a few more added at the end here, so you can get credit for     both tests. </li>    </ul> <H3>Description</H3>   <p>In this test, a Notification Receiver (XDS Doc Consumer) acknowleges receipt of a notification    message by sending an email to the Notification Sender (XDS Doc Source or Doc Registry).</p> <h3>Evaluation</h3>  <p>The acknowlegement must be sent immediately upon receipt and processing of the notification    message on the Notification Receiver (Document Consumer).</p>   <p>The Connectathon monitor will ask to see the email received on the <strong>Notification    Sender</strong> (Document Source or Doc Registry) system. Check:</p>   <ol>    <li>The Subject of the email contains: "XDS%20Acknowledgement: signataureId value"</li>    <li>The content type of the message is ASCII text.</li>    <li>The first line of the message contains "OK" , or, "NOT OK" if this is a negative     acknowledgement.</li>    <li>One or more blank lines follow the ''ok'' line.</li>    <li>The remaining text may be a plain text message suitable for human viewing, but not processed     by the Notification Sender actor.</li>    <li>The entire message body shall contain no more than 100 lines or 3000 characters of data     (incl. CR and LF).</li>   </ol>   <p>Ihe NAV supplement indicates that the Notification Sender "processes" the acknowledgement    message. The TF is intentionally vague when it uses the term "process". There are no specific    "Expected Actions" in the ITI-28 transaction. Certainly, no user interface is required. IHE tries    not to define application behavior. You should be able to describe to the connectathon monitor    how your system behaves when it receives the acknowledgement (as expected), and what it does in    the event no acknowledgement comes back (ie is there something that would trigger the user at the    Doc Source to resend the email?). </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (407, 1, 0, '2009-11-24 10:53:17.052', 'epoiseau', '<H3>Special Instructions</H3> It is unlikely that a vendor will participate in the Connectathon by bringing an SMTP server. This server will be provided as part of Connectathon infrastructure.  <H3>Description</H3> This is the baseline test for the NAV profile. The Notification Sender sends an email through an SMTP server to a Notification Receiver. The Notification Receiver opens the email and follows the link to a set of XDS documents. The Receiver then replies to the Sender.  <H3>Evaluation</H3> The Connectathon monitor should look at the following items: <ul> <li>Email subject line (ITI TF 2:3.25.4.1.2 The subject line of the message should be human readable to support intermediation of the message by a patient).</li>  <li>If the sender implements the Acknowledgement option, look for a mailto link in the message to acknowledge the notification.</li>  <li>The attachment is as specified in ITI TF 2:3.25.4.1.2: The second multipart must be of type application/xml, and shall supply a Content-disposition header that specifies that this multipart is an attachment, with the filename set to the value ''IHEXDSNAV-UUID.xml'', where UUID is a unique id for the notification message.</li>  <li>The Notification Receiver is able to process the attachment and retrieve XDS documents.</li>  <li>The Notification Sender receives an Acknowledgement email (if that option is supported).</li> </ul> ');

INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (409, 1, 0, '2009-11-24 10:53:17.057', 'epoiseau', '<H3>Special Instructions</H3> This tests focuses on the requirements for display of NM Images for Image Display actors which support the MPR Option. This option adds funtionality to the General NM Option, ie systems which support only the Cardiac NM Option will not run this test.  <p> A clinical expert will evaluate this test.  The representative of the Image Display system is responsible for arranging a time for him/her to do the evaluation with you. </p> <H3>Description</H3> The NMI_MOD_Display_MPR_Option tests the Image Display''s ability to do Multi-Planar Reconstruction of SPECT (RECON TOMO).     <p> The Image Display can retrieve sample images for testing MPR from the CENTRAL_ARCHIVE. Alternatively, the Modality can send images directly to the workstation. </p> <H3>Evaluation</H3> Problems identified during each evaluation step should be noted in the Kudu chat window. <p> (1) The Connectathon Monitor <b>will ask the Image Display to demonstrate that</b>: </p> <ul> <li>E44: it can resample a set of slices to generate orthogonal slices in the other two planes (e.g. generating coronal and sagittal slices from a set of transverse slices).  <li>E45: it supports viewing of three orthogonal plane views at the same time <li>E46: It provides a method of navigating the volume (i.e. controlling the specific sagittal, coronal and transverse images shown).  </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (410, 1, 0, '2009-11-24 10:53:17.059', 'epoiseau', '<H3>Special Instructions</H3> <p>Image Display please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find out what your peers have uploaded on the central archive </p> <H3>Description</H3> The NMI_EC_Display test is used to determine if the NM Evidence Creator is entering the proper data in the DICOM NM images and to determine if the Image Display is rendering the images properly.  <p> Evidence Creators in the NMI profile create derivitive data from original NM image data.  In this test, the Evidence Creator must perform all of the functions it is capable of, which may include: </p> <ul> <li>Reconstruction, reorientation, filtering, or other processing of NM data, with output of NM modality image objects.  <li>Registration between an NM data set and another data set.  </ul> Evidence Creator actors have the same requirements as Acquisition Modalities for attributes which must be included in the DICOM header.  See RAD TF-2:4.8.4.1.2.2. or the Evaluation section for test NMI_MOD_Store. <p> The Evidence Creator should use the images produced in the NMI_MOD_Store as data for this test. The Evidence Creator should ask a modality to push images directly to it or to retrieve images from the Central Archive. Only data for a Myocardial Perfusion Study are necessary </p>  <H3>Evaluation</H3>  <p>Connectathon Monitors will use the Image Display to dump DICOM headers and to display images. If the Image Display cannot dump the DICOM header, we will find another method to check attribute values. <ul>  <li>E47: Check standard tags and datatypes. Are R and R+ tags present in the dataset?</li>  <li>E48: Can the cardiac processing package pick out the stress and rest files using the DICOM tages in the files, without using the series description.  (Note:  this step is likely to require pre-prepared data in which the DICOM tags and series descriptions are mutually contradictory; otherwise it may not be possible to test.)</li>  <li>E49: Short short axis data is created, does it have both the apex to base tag and the short axis tag?</li>  <li>E50: When inputting data, does the software distinguish between short axis and transaxial data by the presence or absence of the short axis tag, and does it use this tag and the apex to base tag to process data appropriately?   [To test this in a complete manner, we may need to manuallly change the tags, and verify that it changes the way the data appears in the processing program]. <(Note:  this step is likely to require pre-prepared data in which the DICOM tags and series descriptions are mutually contradictory; otherwise it may not be possible to test.)/li>  <li>E51: Ask workstation to display all data produced by Evidence Creator. Use analysis similar to that determined for modality.</li> </ul> </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (411, 1, 0, '2009-11-24 10:53:17.061', 'epoiseau', '<H3>Special Instructions</H3> None <H3>Description</H3> Evidence Creators in the NMI profile which support the Result Screen Export option must run this test. <p> This tests the ability of Evidence Creators to export snapshots of Results Screens as DICOM objects so that they can be viewed elsewhere on Generic DICOM display systems.   </p> Types of Result Screens include: <ul> <li><b>Static Result Screens</b> - Result screens which do not include moving components. <li><b>Dynamic Result Screens </b>(optional functionality) - Result screens which include moving images or graphics, such as a beating heart or rotating image <li><b>Greyscale Result Screens</b> - Result screens which are completely presented in shades of grey, and, optionally, result screens which present images in greyscale and only use small amounts of color for the graphics. <li><b>Color Result Screens </b>(optional functionality) - Result screens which use color presentation </ul> <H3>Evaluation</H3> (1) On the <b>Evidence Creator</b>, verify that: <ul> <li>E52: Static Result Screens are stored using DICOM Secondary Capture (SC) IODs or Multi-Frame Secondary Capture (MFSC) IODs (preferred). <li>E53: if multiple Static Result Screens are stored in a DICOM MFSC object, the Cine module is not included. The order of the Static frames in the MFSC represents the intended display order of the result screens.  <li>E54: DICOM MFSC IODs is used for storing Dynamic Result Screens. The cine module shall be included as described in Table 4.18-1. The frames shall be ordered to present a cine of the Dynamic Result Screen. The number of frames is not specified here. If there are several cine regions in the result screen and the length of their cine "cycle" is not the same, it is acceptable if there is a "jump" in the playback when the MFSC cycle loops back to the beginning.  <li>E55: (optional) export of Color Result Screens is 24-bit RGB.  <li>E56: (optional) Dynamic Color Result Screens are stored as Multi-frame True Color Secondary Capture Image Storage IODs <li>E57: If the system supports Color Result Screens, it also supports export of result screens as 8-bit grayscale. </ul> <p> (2) The Connectathon Monitor <b>will ask the Image Display to demonstrate that</b>: <ul> <li>E58: it can display DICOM Secondary Capture images (including specifically 8 and 16 bit monochrome and 24 bit RGB).  <li>E59: it can display DICOM Multi-Frame Secondary Capture images (including specifically 8-bit monochrome and 24-bit True Color) <li>E60: for Multi-Frame Secondary Capture images which contain a Cine module, it can cine the frames. The default cine rate shall be the value in the Cine module, or the maximum rate of the Image Display, whichever is slower.  <li>E61: it can display result screens at their original pixel resolution. If the display size is equal to or greater than the size of the result screen, this should be done as the default.  If the display size is less than the size of the result screen, it provides some sort of panning capability.  <li>E62: it can scale result screens using a fixed aspect ratio. If the display size is smaller than the size of the result screen, this is done to fit the result screen onto the display as the default. </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (412, 1, 0, '2009-11-24 10:53:17.064', 'epoiseau', '<H3>Special Instructions</H3><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>This tests focuses on the requirements for display of NM Images for Image Display actors which support the Cardiac NM Option. When entering results for this test in Kudu, the Image Display should initiate an instance of this test when the results are complete. This allows you to also give credit to the Acquisition Modality which supplied the images without locking that system out of other testing while the Image Display is working on the rendering and evaluation.</p> <p>A clinical expert will evaluate this test. The representative of the Image Display system is responsible for arranging a time for him/her to do the evaluation with you.</p> </p>  <H3>Description</H3> <p>The NMI_MOD_Display_Cardiac_NM_Option test is used to determine if the Acquisition Modality is entering the proper data in the DICOM NM images, and to determine if the Image Display is rendering the images properly. Several types of datasets will be required for this test. The Image Display can retrieve sample images which the Modality stored to the Connectathon CENTRAL_ARCHIVE in test NMI_MOD_Store. Alternatively, the Modality can send images directly to the workstation (DICOM C-STORE, though not an IHE transaction in the NMI profile</p>  <H3>Evaluation</H3>  <p>Connectathon Monitors may find it helpful to dump the DICOM header in the images when evaluating this test.  Use Image Display to dump DICOM headers and to display images. If the Image Display cannot dump the DICOM header, we will find another method to check attribute values.</p>  <p>Problems identified during each evaluation step should be noted in the Kudu chat window.</p><p>(1) These requirement are specific to the Cardiac NM option.</p> <p> Depending on the test images available, or other factors, the Connectathon Monitor <strong>may choose to evaluate a subset of the items listed below</strong>.</p>  <p> The Connectathon Monitor <strong>will ask the Image Display to demonstrate that</strong>:</p>  <ul> <li>E24: it can take a cardiac short axis data set and generate the corresponding vertical long axis, and horizontal long axis data sets.  For each axis, multiple frames are displayed, in a left-to-right (preferred) or top-to-bottom format.</li> <li>E25: when two SPECT image sets are compared, they are displayed simultaneously as a series of frames, either one above the other (preferred) or one next to the other.</li> <li>E26: short axis data is displayed as serial frames with the apical slices first, progressing from the cardiac apex to the base of the heart.  The heart shall be displayed with the following orientation: <ul> <li>E27: short axis data is  displayed as serial frames with the apical slices first, progressing from the  cardiac apex to the base of the heart.   The heart shall be displayed with the following orientation:</li> </ul> </li> </ul><pre> Anterior wall Septum    (heart)     Lateral wall Inferior wall </pre>  <ul> <li>E27: short axis slices are labeled to convey they are “Short axis, apex to base”.  </li> <li>E28: vertical long axis data is displayed as serial frames with the septal slices first, progressing to the lateral wall.  The heart shall be displayed with the following orientation:</li> </ul><pre> Anterior wall  Base    (heart)     Apex Inferior wall </pre>  <ul> <li>E29: vertical long axis slices are labeled to convey they are “Vertical long axis, septal to lateral”.</li> <li>E30: horizontal long axis data is displayed as serial frames with the inferior slices first, progressing to the anterior wall.   The heart shall be displayed with the following orientation:</li> </ul>  <pre>     Apex Septum    (heart)     Lateral Wall     Base </pre>  <ul> <li>E31: horizontal long axis slices are labeled to convey they are “Horizontal long axis, inferior to anterior”. </li> <li>E32: images with the value of "ATTN" (i.e. Attenuation Corrected) in Corrected Image (0028,0051) are labeled as such.</li> <li>E33: images with the value of "prone" in the Patient Orientation Modifier Code Sequence (0054,0412) are labeled as such.</li> <li>E34: it allows the user to window the Stress data independently of the Rest data, such that windowing affects all displayed Stress frames in the short and long axis views.</li> <li>E35: it allows the user to window the Rest data independently of the Stress data, such that windowing affects all displayed Rest frames in the short and long axis views.</li> <li>E36: it allows the user to window both Stress and Rest simultaneously in a manner that preserves the relative scaling of the two datasets.    In other words, when  both images are selected and the desired window is changed, the changes occur in a proportional manner for each image.  </li>  <p>Note:  The following example is included in RAD TF-2:4.16.4.2.2.3.2:  The stress image is displayed with a window settings of (0,100), corresponding to the lower and upper window levels.  The rest image is displayed with window settings of (0,50).  The user adjusts the stress upper level to yield a window setting of (0,120).  The user then selects both the stress and rest images, and adjusts the windowing to perform a 10% background subtraction on both images simultaneously, resulting in (12,120) for the stress image set, and (5,50) for the rest image set.  Thus the relative scaling of the two images is preserved during this last adjustment.</p>  <li>E37: allows the user to  adjust the Stress and Rest frame positions so that corresponding frames are  displayed. (This typically appears as  sliding one row of frames to the right or to the left.)</li> <li>E38: the display order  of the data sets follows the profile requirements. Regardless of the order in which the data  sets were selected by the user, the display order in the ACC NM Cardiac Display  is determined by the Patient State (the value is stored within the Acquisition Context Sequence (0040,0555) in  the Concept Code sequence (0040,A168)).  </li> </ul>  <p>The display order for different Patient   State values is as  follows:</p> <ol> <li>Cardiac Stress</li> <li>Resting, Reinjection</li> <li>Redistribution</li> <li> Delayed Redistribution</li> </ol>  <p>  Note: If the  user selects two data sets with the same Patient State,  the display order is undefined. </p>  <ul> <li>E39: the value of Patient State for each data set is displayed.</li> </ul> <p>Note: The following example is included in RAD  TF-2:4.16.4.2.2.3.2: A typical set of cardiac images will include one Cardiac  Stress short axis image, and because it has highest precedence in the above  list, it is placed into the first image position in the ACC NM Cardiac  Display. Images are typically selected  in pairs, and the pair of selected data sets will typically include a Cardiac  Stress data set, which is therefore placed in the first position in the  ACC NM Cardiac Display, and a Cardiac Rest data set, which is placed in the  second position ( in the ACC NM Cardiac display. If the selected data sets consist of only a  rest image and a redistribution image, then the rest image is placed into the  first position, since it has the highest precedence.</p>  <ul> <li>E40: it is able to perform multiplanar reconstruction (MPR)  of two re-oriented (short axis) cardiac RECON TOMO data sets to display the  data in the standard format endorsed by the American College  of Cardiology (ACC NM Cardiac Display). </li> <li>E41: is able  to display simultaneously multiple framesets. These may be from the same Image,  different Images, different Series, or different Studies. (The Image Display is not required to display  simultaneously multiple framesets with different Image Types.)</li> <li>E42: for each  Image Type, it displays simultaneously at least the number of framesets  required in the Cardiac NM Option column of RAD TF-2: Table 4.16-1</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (413, 1, 0, '2009-11-24 10:53:17.069', 'epoiseau', '<H3>Special Instructions</H3> <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> This tests focuses on the requirements for display of NM Images for Image Display actors which support the General NM Option.   When entering results for this test in Kudu, the Image Display should initiate an instance of this test when the results are complete.  This allows you to also give credit to the Acquisition Modality which supplied the images without locking that system out of other testing while the Image Display is working on the rendering and evaluation. <p> A clinical expert will evaluate this test.  The representative of the Image Display system is responsible for arranging a time for him/her to do the evaluation with you. </p> <H3>Description</H3> The NMI_MOD_Display_General_NM_Option test is used to determine if the Acquisition Modality is entering the proper data in the DICOM NM images, and to determine if the Image Display is rendering the images properly. Several types of datasets will be required for this test.  <p> The Image Display can retrieve sample images which the Modality stored to the Connectathon CENTRAL_ARCHIVE in test NMI_MOD_Store. Alternatively, the Modality can send images directly to the workstation (DICOM C-STORE, though not an IHE transaction in the NMI profile). </p> <H3>Evaluation</H3> Connectathon Monitors may find it helpful to dump the DICOM header in the images when evaluating this test.  Use Image Display to dump DICOM headers and to display images. If the Image Display cannot dump the DICOM header, we will find another method to check attribute values. <p> Problems identified during each evaluation step should be noted in the Kudu chat window. </p> <p> (1) The Connectathon Monitor <b>will ask the Image Display to demonstrate that</b>: </p> <ul> <li>E43: for each Image Type, it displays simultaneously at least the number of framesets required in the General NM Option column of RAD TF-2:Table 4.16-1 </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (414, 1, 0, '2009-11-24 10:53:17.071', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Acquisition Modality actors perform ONE instance of this test.  If the Modality also participates in the SWF profile, this test is a duplicate of SWF_MOD_Store.  <em>This should be done on the first day of the Connectathon.</em> </p> <p>The Modality system should arrive at the Connectathon with images for this test PRE-OBTAINED and PRE-LOADED; see guidance on images in the Description section of this test.  Evidence Creators may need</p> </p>  <H3>Description</H3> <p>All Acquisition Modalities participating in the NMI profile should store NM images to the CENTRAL_ARCHIVE. This will enable Image Manager and Image Display actors to access these images for their testing. </p>  <p>You must enter a description of your study in the <em><a href=system_con_object.php?selected=create_object>Objects Information</a></em>.  Please upload there a screen capture of the object so that we can use it for comparison when your peers will render your images.</p> <p>This test is also used to determine if the NM modality is entering the proper data in the DICOM NM images.</p>  <p>To aid in Connectathon testing, recommendations follow for which images are needed for subsequent testing by Image Displays, Evidence Creators and Image Managers.  Minor changes may be made to this, depending on what images are actually available for use at time of testing.</p>  <p>Please create patient names for your studies which contain your system name plus an indication of the contents of the study, eg patient name = MOD_XYZ_NM^Static-Lung-Perfusion</p> <p>Acquisition Modalities must provide samples that will enable Image Displays to exercise the requirements in both the General NM Option and the Cardiac NM Option.</p>  <p>Selected images will be used for testing of required R and R+ tags.</p> <strong>These are studies to be used for General NM Option testing by Image Displays:</strong> <ul> <li>LUNG multiple STATIC images in separate series, hopefully 8+ images in at least 2 series; used for testing of fit display.</li> <li>RENAL Two phase DYNAMIC in single image; used for testing of selection of part of a study (by phase), and subsequent display of each part both as grid display and cine.</li> <li>BONE WHOLEBODY exam with anterior and posterior views in same image; used for testing of display of wholebody images, for display of image labels,  and for testing of NM-style windowing.</li> <li>RVG three GATED images, likely 64x64; used for display of multiple cines at same time; aalso used for testing of appropriate choice of default zoom of images at time of display.</li> <li>BONE RECON TOMO (SPECT) exam; used for testing MPR, (optional under basic NM display, required under review option.</li> </ul>  <p> <strong>These are studies to be used for Cardiac NM Option testing by Image Displays:</strong> </p> <ul> <li>PERFUSIONTOM Rest and stress images. There should be two SPSs; used to test cardiac tags both before and after reconstruction.</li> <li>PERFUSIONGATED Two image sets, rest and stress, though it is likely only the stress will be gated; used for testing of output of dynamic result screens (Multi-frame SC) from Evidence Creator, and for testing of display of these Multi-frame SC images on image display.</li> <li>PERFUSIONRECON Two image sets, rest and stress; used for testing of creation of color an grayscale static result screens (SC) from Evidence Creator, for testing of applying pseudocolor maps to grayscale SC images on image displays, for testing of NM style windowing of SC images (presuming windowing of SC images is allowed on display as recommended), and for testing of comparison display using two short axis datasets.   Recon tomo data also used for testing the use of cardiac tags by Evidence Creators, possibly by having variations of the data set with altered tags that should change the processing result.</li> </ul>  <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> Depending on the test images available, or other factors, the Connectathon Monitor <strong>may choose to evaluate a subset of the items listed below.</strong> </p>    <br>   (1) Detailed attribute requirements are contained in the  table below</p> <ul>   <li>E1: All images are the Nuclear Medicine SOP Class  1.2.840.5.1.4.1.1.20</li>   <li>E2: Check that the R and R+ tags identfied below are  present.</li> </ul> <p align="center">The attributes  identified in this table are required in the MMI Profile:</p> <p> </p> <div align="center">   <table border="1" cellspacing="0" cellpadding="0">     <tr>       <td width="124" rowspan="3" valign="top"><p>Attribute</p></td>       <td width="81" rowspan="3" valign="top"><p>Tag</p></td>       <td width="354" colspan="11" valign="top"><p>Image Type</p></td>     </tr>     <tr>       <td width="202" colspan="7" valign="top"><p>General</p></td>       <td width="152" colspan="4" valign="top"><p>Cardiac</p></td>     </tr>     <tr>       <td width="29"><p>S<br>         T<br>         A<br>         T<br>         I<br>         C</p></td>       <td width="38" colspan="2"><p>D<br>         Y<br>         N<br>         A<br>         M<br>         I<br>         C</p></td>       <td width="34"><p>W<br>         H<br>         O<br>         L<br>         E<br>         B<br>         O<br>         D<br>         Y</p></td>       <td width="32"><p>G<br>         A<br>         T<br>         E<br>         D</p></td>       <td width="34"><p>T<br>         O<br>         M<br>         O</p></td>       <td width="34"><p>R<br>         E<br>         C<br>         O<br>         N<br>         <br>         T<br>         O<br>         M<br>         O</p></td>       <td width="38"><p>T<br>         O<br>         M<br>         O</p></td>       <td width="38"><p>R<br>         E<br>         C<br>         O<br>         N<br>         <br>         T<br>         O<br>         M<br>         O</p></td>       <td width="38"><p>G<br>         A<br>         T<br>         E<br>         D<br>         <br>         T<br>         O<br>         M<br>         O</p></td>       <td width="38"><p>R<br>         E<br>         C<br>         O<br>         N<br>         <br>         G<br>         A<br>         T<br>         E<br>         D<br>         <br>         T<br>         O<br>         M<br>         O</p></td>     </tr>     <tr>       <td width="124" valign="top"><p>Detector Information Sequence</p></td>       <td width="81" valign="top"><p>(0054,0022)</p></td>       <td width="354" colspan="11" valign="top"><p> </p></td>     </tr>     <tr>       <td width="124" valign="top"><p>> Image Position</p></td>       <td width="81" valign="top"><p>(0020,0032)</p></td>       <td width="35" colspan="2" valign="top"><p> </p></td>       <td width="32" valign="top"><p> </p></td>       <td width="34" valign="top"><p> </p></td>       <td width="32" valign="top"><p> </p></td>       <td width="34" valign="top"><p> </p></td>       <td width="34" valign="top"><p>R+</p></td>       <td width="38" valign="top"><p> </p></td>       <td width="38" valign="top"><p>R+</p></td>       <td width="38" valign="top"><p> </p></td>       <td width="38" valign="top"><p>R+</p></td>     </tr>     <tr>       <td width="124" valign="top"><p>> Image Orientation</p></td>       <td width="81" valign="top"><p>(0020,0037)</p></td>       <td width="35" colspan="2" valign="top"><p> </p></td>       <td width="32" valign="top"><p> </p></td>       <td width="34" valign="top"><p> </p></td>       <td width="32" valign="top"><p> </p></td>       <td width="34" valign="top"><p>R+</p></td>       <td width="34" valign="top"><p>R+</p></td>       <td width="38" valign="top"><p>R+</p></td>       <td width="38" valign="top"><p>R+</p></td>       <td width="38" valign="top"><p>R+</p></td>       <td width="38" valign="top"><p>R+</p></td>     </tr>     <tr>       <td width="124" valign="top"><p>> View Code    Sequence  </p></td>       <td width="81" valign="top"><p>(0054,0220)</p></td>       <td width="354" colspan="11" valign="top"><p> </p></td>     </tr>     <tr>       <td width="124" valign="top"><p>>> Code Value</p></td>       <td width="81" valign="top"><p>(0008,0100)</p></td>       <td width="35" colspan="2" valign="top"><p> </p></td>       <td width="32" valign="top"><p> </p></td>       <td width="34" valign="top"><p>R+</p></td>       <td width="32" valign="top"><p> </p></td>       <td width="34" valign="top"><p> </p></td>       <td width="34" valign="top"><p> </p></td>       <td width="38" valign="top"><p> </p></td>       <td width="38" valign="top"><p>R+1 </p></td>       <td width="38" valign="top"><p> </p></td>       <td width="38" valign="top"><p>R+1 </p></td>     </tr>     <tr>       <td width="124" valign="top"><p>>> Coding Scheme    Designator</p></td>       <td width="81" valign="top"><p>(0008,0102)</p></td>       <td width="35" colspan="2" valign="top"><p> </p></td>       <td width="32" valign="top"><p> </p></td>       <td width="34" valign="top"><p>R+</p></td>       <td width="32" valign="top"><p> </p></td>       <td width="34" valign="top"><p> </p></td>       <td width="34" valign="top"><p> </p></td>       <td width="38" valign="top"><p> </p></td>       <td width="38" valign="top"><p>R+1 </p></td>       <td width="38" valign="top"><p> </p></td>       <td width="38" valign="top"><p>R+1 </p></td>     </tr>     <tr>       <td width="124" valign="top"><p>Slice Progression Direction</p></td>       <td width="81" valign="top"><p>(0054,0500)</p></td>       <td width="35" colspan="2" valign="top"><p> </p></td>       <td width="32" valign="top"><p> </p></td>       <td width="34" valign="top"><p> </p></td>       <td width="32" valign="top"><p> </p></td>       <td width="34" valign="top"><p> </p></td>       <td width="34" valign="top"><p> </p></td>       <td width="38" valign="top"><p> </p></td>       <td width="38" valign="top"><p>R+2 </p></td>       <td width="38" valign="top"><p> </p></td>       <td width="38" valign="top"><p>R+2 </p></td>     </tr>     <tr>       <td width="124" valign="top"><p>Spacing Between Slices</p></td>       <td width="81" valign="top"><p>(0018,0088)</p></td>       <td width="35" colspan="2" valign="top"><p> </p></td>       <td width="32" valign="top"><p> </p></td>       <td width="34" valign="top"><p> </p></td>       <td width="32" valign="top"><p> </p></td>       <td width="34" valign="top"><p> </p></td>       <td width="34" valign="top"><p>R+4 </p></td>       <td width="38" valign="top"><p> </p></td>       <td width="38" valign="top"><p>R+4 </p></td>       <td width="38" valign="top"><p> </p></td>       <td width="38" valign="top"><p>R+4 </p></td>     </tr>     <tr>       <td width="124" valign="top"><p>Acquisition Context    Sequence</p></td>       <td width="81" valign="top"><p>(0040,0555)</p></td>       <td width="354" colspan="11" valign="top"><p> </p></td>     </tr>     <tr>       <td width="124" valign="top"><p>> Concept-Name Code    Sequence</p></td>       <td width="81" valign="top"><p>(0040,A043)</p></td>       <td width="35" colspan="2" valign="top"><p> </p></td>       <td width="32" valign="top"><p> </p></td>       <td width="34" valign="top"><p> </p></td>       <td width="32" valign="top"><p> </p></td>       <td width="34" valign="top"><p> </p></td>       <td width="34" valign="top"><p> </p></td>       <td width="38" valign="top"><p>R+3 </p></td>       <td width="38" valign="top"><p>R+3 </p></td>       <td width="38" valign="top"><p>R+3 </p></td>       <td width="38" valign="top"><p>R+3 </p></td>     </tr>     <tr>       <td width="124" valign="top"><p>> Concept Code Sequence</p></td>       <td width="81" valign="top"><p>(0040,A168)</p></td>       <td width="35" colspan="2" valign="top"><p> </p></td>       <td width="32" valign="top"><p> </p></td>       <td width="34" valign="top"><p> </p></td>       <td width="32" valign="top"><p> </p></td>       <td width="34" valign="top"><p> </p></td>       <td width="34" valign="top"><p> </p></td>       <td width="38" valign="top"><p>R+3 </p></td>       <td width="38" valign="top"><p>R+3 </p></td>       <td width="38" valign="top"><p>R+3 </p></td>       <td width="38" valign="top"><p>R+3 </p></td>     </tr>     <tr>       <td width="124" valign="top"><p> Corrected Image </p></td>       <td width="81" valign="top"><p>(0028,0051) </p></td>       <td width="35" colspan="2" valign="top"><p> </p></td>       <td width="32" valign="top"><p> </p></td>       <td width="34" valign="top"><p> </p></td>       <td width="32" valign="top"><p> </p></td>       <td width="34" valign="top"><p> </p></td>       <td width="34" valign="top"><p>R+5 </p></td>       <td width="38" valign="top"><p> </p></td>       <td width="38" valign="top"><p>R+5 </p></td>       <td width="38" valign="top"><p> </p></td>       <td width="38" valign="top"><p>R+5 </p></td>     </tr>     <tr>       <td width="124" valign="top"><p>Patient    orientation code sequence </p></td>       <td width="81" valign="top"><p>(0054,0410) </p></td>       <td width="354" colspan="11" valign="top"><p> </p></td>     </tr>     <tr>       <td width="124" valign="top"><p>> Patient orientation modifier code sequence </p></td>       <td width="81" valign="top"><p>0054,0412) </p></td>       <td width="35" colspan="2" valign="top"><p> </p></td>       <td width="32" valign="top"><p> </p></td>       <td width="34" valign="top"><p> </p></td>       <td width="32" valign="top"><p> </p></td>       <td width="34" valign="top"><p>R+</p></td>       <td width="34" valign="top"><p>R+</p></td>       <td width="38" valign="top"><p>R+</p></td>       <td width="38" valign="top"><p>R+</p></td>       <td width="38" valign="top"><p>R+</p></td>       <td width="38" valign="top"><p>R+</p></td>     </tr>   </table> </div> <p> </p> <ul>   <li>E3: When Image Type (0008,0008) is RECON, the ''Spacing between Slices'' attribute (0018,0088)  contains a valid value.</li>   <li>E4: When Image Type (0008,0008) is RECON TOMO or  RECON GATED TOMO, the Image Position (0020,0032), Image Orientation  (0020,0037), and the View Code Sequence (0054,0220) describe the orientation of  the reconstructed frames within the Image. </li>   <li>E5: When the Image Type (0008,0008) is WHOLEBODY,  the useful image data is generally rectangular in shape (e.g. 256x1024).  Acquisition Modalities and Evidence Creators create these images without  padding to create square frames.</li>   <li>E6: Images are stored with the frames sorted into  "vector sorted order". That is, the frames are ordered such that the frames are  sorted first by the values of the first vector, then within a value for the  first vector, the frames are sorted by the values of the second vector, etc.. </li>   <li>E7: In cardiac images, check additional cardiac  tags: Within the Detector Information Sequence (0054,0022), the View Code  Sequence (0054,0220) should contain one of these values:</li> </ul> <div align="center">   <table border="1" cellspacing="0" cellpadding="0">     <tr>       <td valign="top"><p>Coding Scheme<br>         Designator</p></td>       <td valign="top"><p>Code Value</p></td>       <td valign="top"><p>Code Meaning</p></td>     </tr>     <tr>       <td valign="top"><p align="center">SNM3</p></td>       <td valign="top"><p>G-A186</p></td>       <td valign="top"><p>Short Axis</p></td>     </tr>     <tr>       <td valign="top"><p align="center">SNM3</p></td>       <td valign="top"><p>G-A18A</p></td>       <td valign="top"><p>Vertical Long Axis</p></td>     </tr>     <tr>       <td valign="top"><p align="center">SNM3</p></td>       <td valign="top"><p>G-A18B</p></td>       <td valign="top"><p>Horizontal Long Axis</p></td>     </tr>   </table> </div> <ul>   <li>E8: In cardiac images, check additional cardiac  tags: Within the Detector Information Sequence (0054,0022), the Slice  Progression Direction (0054,0500) contains either APEX_TO_BASE and BASE_TO_APEX. </li>   <li>E9: In cardiac images, check additional cardiac  tags:  </li>   <li>The Acquisition Context Sequence (0040,0555) contains the  Concept Name Code Sequence (0040,A043) with a value of (DCM, 109055, "Patient State") </li>   <li>the Concept Code Sequence (0040,A168) shall use values from:<br>   </li> </ul> <div align="center">   <table border="1" cellspacing="0" cellpadding="0">     <tr>       <td valign="top"><p>Coding Scheme<br>         Designator</p></td>       <td valign="top"><p>Code Value</p></td>       <td valign="top"><p>Code Meaning</p></td>     </tr>     <tr>       <td valign="top"><p align="center">SRT</p></td>       <td valign="top"><p>F-01604</p></td>       <td valign="top"><p>Resting State</p></td>     </tr>     <tr>       <td valign="top"><p align="center">DCM</p></td>       <td valign="top"><p>109091</p></td>       <td valign="top"><p>Cardiac Stress State </p></td>     </tr>     <tr>       <td valign="top"><p align="center">DCM</p></td>       <td valign="top"><p>109092</p></td>       <td valign="top"><p>Reinjection State </p></td>     </tr>     <tr>       <td valign="top"><p align="center">DCM</p></td>       <td valign="top"><p>109093</p></td>       <td valign="top"><p>Redistribution State </p></td>     </tr>     <tr>       <td valign="top"><p align="center">DCM</p></td>       <td valign="top"><p>109094</p></td>       <td valign="top"><p>Delayed Redistribution State</p></td>     </tr>   </table> </div>  <p>The samples will also be checked by a DICOM validator run on all studies stored to the central archive.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (415, 1, 0, '2009-11-24 10:53:17.075', 'epoiseau', '<H3>Special Instructions</H3> <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>  This tests focuses on the requirements for which apply to all Image Display actors in the NMI Profile (ie they are not specific to the Cardiac NM Option or the General NM Option.   <p>When entering results for this test in Kudu, the Image Display should initiate an instance of this test when the results are complete.   This allows you to also give credit to the Acquisition Modality which supplied the images without locking that system out of other testing while the Image Display is working on the rendering. </p> <p> A clinical expert will evaluate this test.  The representative of the Image Display system is responsible for arranging a time for him/her to do the evaluation with you. </p> <H3>Description</H3> The NMI_MOD_Display test is used to determine if the Acquisition Modality is entering the proper data in the DICOM NM images, and to determine if the Image Display is rendering the images properly. Several types of datasets will be required for this test.  <p> The Image Display can retrieve sample images which the Modality stored to the Connectathon CENTRAL_ARCHIVE in test NMI_MOD_Store. Alternatively, the Modality can send images directly to the workstation (DICOM C-STORE, though not an IHE transaction in the NMI profile). </p> <H3>Evaluation</H3> <p>Connectathon Monitors may find it helpful to dump the  DICOM header in the images when evaluating this test.  Use Image Display to dump DICOM headers and  to display images. If the Image Display cannot dump the DICOM header, we will  find another method to check attribute values.</p> <p><strong>Problems identified  during each evaluation step should be noted in the Kudu chat window</strong>.</p> <p>The functionality in this section is required for all  Image Displays in the NMI profile. <br>   Depending on the test images  available, or other factors, the Connectathon Monitor may choose to evaluate a subset of the items listed below.<br>   <br>   (1) The Connectathon Monitor <strong>will ask the Image Display to demonstrate</strong> that:</p> <ul>   <li>E10: it displays the frames in the order they are  stored in the image. </li>   <li>E11: it performs the frame selections  shown for each Image Type.  Reference the  table below. (Note that a frameset only references frames from a single Image.)</li> </ul> <p>Note that the requirements for  display of the number of simultaneous framesets differ between the Cardiac NM  Option and General NM Option, so those requirements are tested in the  option-specific tests.</p> <p><u>Table  4.16-1.  Selection, Sorting and Viewing  Requirements for NM Images</u></p> <div align="center">   <table border="1" cellspacing="0" cellpadding="0" width="622">     <tr>       <td width="99" rowspan="2" valign="top"><br>         Image Type<br>         (0008,0008)<br>         Value 3 </td>       <td width="157" rowspan="2" valign="top"><p>Frame <br>         Increment Pointer<br>         (0028,0009)<br>         [i.e. vectors]</p></td>       <td width="94" rowspan="2" valign="top"><p align="left">Required<br>         Frame<br>         Selection 1<br>         E =     single<br>         <u>E </u>= all</p></td>       <td width="145" colspan="2" rowspan="2" valign="top"><p>Display<br>         Capabilities<br>         (See     4.16.4.2.2.3.2)</p></td>       <td width="126" colspan="4" valign="top"><p># of<br>         Simultaneous Framesets</p></td>       <td width="1"></td>     </tr>     <tr>       <td width="63" colspan="2" valign="top"><p><u>General<br>         NM Option</u></p></td>       <td width="65" colspan="3" valign="top"><p><u>Cardiac NM</u> Option</p></td>     </tr>     <tr>       <td width="99" rowspan="2" valign="top"><p>STATIC</p></td>       <td width="157" rowspan="2" valign="top"><p>Energy Window (0054,0010)<br>         Detector (0054,0020)</p></td>       <td width="94" rowspan="2" valign="top"><p><strong><u>E D</u></strong><br>         E <strong><u>D</u></strong>  <u></u><br>         <strong><u>E</u></strong> D  </p></td>       <td width="144" valign="top"><p>Grid Display</p></td>       <td width="62" colspan="2" valign="top"><p align="center">1</p></td>       <td width="64" colspan="2" valign="top"><p align="center">1</p></td>       <td width="3" colspan="2"></td>     </tr>     <tr>       <td width="144" valign="top"><p>Fit Display</p></td>       <td width="62" colspan="2" valign="top"><p align="center">12</p></td>       <td width="64" colspan="2" valign="top"><p align="center">12</p></td>       <td width="3" colspan="2"></td>     </tr>     <tr>       <td width="99" valign="top"><p>WHOLEBODY</p></td>       <td width="157" valign="top"><p>Energy Window(0054,0010) <br>         Detector(0054,0020)</p></td>       <td width="94" valign="top"><p><strong><u>E D</u></strong><br>         E <strong><u>D</u></strong>   <u></u><br>         <strong><u>E</u></strong> D  </p></td>       <td width="144" valign="top"><p>Whole body    Display</p></td>       <td width="62" colspan="2" valign="top"><p align="center">2</p></td>       <td width="64" colspan="2" valign="top"><p align="center">- </p></td>       <td width="3" colspan="2"></td>     </tr>     <tr>       <td width="99" rowspan="2" valign="top"><p>DYNAMIC. </p></td>       <td width="157" rowspan="2" valign="top"><p>Energy Window (0054,0010)<br>         Detector (0054,0020)<br>         Phase (0054,0100)<br>         Time Slice (0054,0030)</p></td>       <td width="94" rowspan="2" valign="top"><p><strong><u>E D P T</u></strong><br>         E D P <strong><u>T</u></strong>  <br>         E D <strong><u>P</u></strong> <strong><u>T</u></strong></p></td>       <td width="144" valign="top"><p>Grid Display</p></td>       <td width="62" colspan="2" valign="top"><p align="center">1</p></td>       <td width="64" colspan="2" valign="top"><p align="center">1</p></td>       <td width="3" colspan="2"></td>     </tr>     <tr>       <td width="144" valign="top"><p>Cine</p></td>       <td width="62" colspan="2" valign="top"><p align="center">1</p></td>       <td width="64" colspan="2" valign="top"><p align="center"><u>1 </u> </p></td>       <td width="3" colspan="2"></td>     </tr>     <tr>       <td width="99" rowspan="2" valign="top"><p>GATED</p></td>       <td width="157" rowspan="2" valign="top"><p>Energy Window (0054,0010)<br>         Detector (0054,0020)<br>         R-R Interval (0054,0060)<br>         Time Slot (0054,0070)</p></td>       <td width="94" rowspan="2" valign="top"><p><strong><u>E D I T</u></strong>   </p></td>       <td width="144" valign="top"><p>Grid Display</p></td>       <td width="62" colspan="2" valign="top"><p align="center">1</p></td>       <td width="64" colspan="2" valign="top"><p align="center">1</p></td>       <td width="3" colspan="2"></td>     </tr>     <tr>       <td width="144" valign="top"><p>Cine</p></td>       <td width="62" colspan="2" valign="top"><p align="center">3</p></td>       <td width="64" colspan="2" valign="top"><p align="center">6</p></td>       <td width="3" colspan="2"></td>     </tr>     <tr>       <td width="99" rowspan="2" valign="top"><p>TOMO</p></td>       <td width="157" rowspan="2" valign="top"><p>Energy Window (0054,0010)<br>         Detector (0054,0020)<br>         Rotation (0054,0050)<br>         Angular View (0054,0090)</p></td>       <td width="94" rowspan="2" valign="top"><p><strong><u>E D R A</u></strong>  <strong><u></u></strong></p></td>       <td width="144" valign="top"><p>Grid Display</p></td>       <td width="62" colspan="2" valign="top"><p align="center">1</p></td>       <td width="64" colspan="2" valign="top"><p align="center">1</p></td>       <td width="3" colspan="2"></td>     </tr>     <tr>       <td width="144" valign="top"><p>Cine</p></td>       <td width="62" colspan="2" valign="top"><p align="center">3</p></td>       <td width="64" colspan="2" valign="top"><p align="center">3</p></td>       <td width="3" colspan="2"></td>     </tr>     <tr>       <td width="99" rowspan="2" valign="top"><p>GATED TOMO</p></td>       <td width="157" rowspan="2" valign="top"><p>Energy Window(0054,0010)<br>         Detector (0054,0020)<br>         Rotation (0054,0050)<br>         R-R Interval     (0054,0060)<br>         Time Slot (0054,0070)<br>         Angular View (0054,0090)</p></td>       <td width="94" rowspan="2" valign="top"><p><strong><u>E D R I T A</u></strong><br>               <strong><u>E D R I</u></strong> <strong><u>T</u></strong> A<br>               <strong><u>E D R I</u></strong> T <strong><u>A</u></strong> </p></td>       <td width="144" valign="top"><p>Grid Display</p></td>       <td width="62" colspan="2" valign="top"><p align="center">1</p></td>       <td width="64" colspan="2" valign="top"><p align="center">1</p></td>       <td width="3" colspan="2"></td>     </tr>     <tr>       <td width="144" valign="top"><p>Cine</p></td>       <td width="62" colspan="2" valign="top"><p align="center">1</p></td>       <td width="64" colspan="2" valign="top"><p align="center"><u>3</u></p></td>       <td width="3" colspan="2"></td>     </tr>     <tr>       <td width="99" rowspan="2" valign="top"><p>RECON TOMO</p></td>       <td width="157" rowspan="2" valign="top"><p>Slice (0054,0080)</p></td>       <td width="94" rowspan="2" valign="top"><p><strong><u>S</u></strong>  </p></td>       <td width="144" valign="top"><p>Grid Display </p></td>       <td width="62" colspan="2" valign="top"><p align="center">1</p></td>       <td width="64" colspan="2" valign="top"><p align="center">1</p></td>       <td width="3" colspan="2"></td>     </tr>     <tr>       <td width="144" valign="top"><p>ACC NM    Cardiac Display</p></td>       <td width="62" colspan="2" valign="top"><p align="center"><u> </u></p></td>       <td width="64" colspan="2" valign="top"><p align="center">2</p></td>       <td width="3" colspan="2"></td>     </tr>     <tr>       <td width="99" rowspan="2" valign="top"><p>GATED RECON<br>         TOMO</p></td>       <td width="157" rowspan="2" valign="top"><p>R-R Interval (0054,0060)<br>         Time Slot (0054,0070)<br>         Slice (0054,0080)</p></td>       <td width="94" rowspan="2" valign="top"><p><strong><u>I T S</u></strong> <strong><u></u></strong><br>               <strong><u>I T</u></strong> S<br>               <strong><u>I</u></strong> T <strong><u>S</u></strong></p></td>       <td width="144" valign="top"><p>Grid Display</p></td>       <td width="62" colspan="2" valign="top"><p align="center">1</p></td>       <td width="64" colspan="2" valign="top"><p align="center">1</p></td>       <td width="3" colspan="2"></td>     </tr>     <tr>       <td width="144" valign="top"><p>ACC NM    Cardiac Display with Cine</p></td>       <td width="62" colspan="2" valign="top"><p align="center"> </p></td>       <td width="64" colspan="2" valign="top"><p align="center">2</p></td>       <td width="3" colspan="2"></td>     </tr>   </table> </div> <p> </p> <p>Note 1: <em>The Frame Selection column refers to the  Frame Increment Pointer vectors by their first letter (except for R-R Interval  which uses for Interval).  A letter  shown underlined and bold (e.g. <strong><u>E</u></strong> ) indicates that all values for that vector are selected.  A letter shown in plain text (e.g. E )  indicates that a single value for that vector has been selected.  So in the case of the TOMO Image Type, <strong><u>E R D A</u></strong> means that all frames of  the image are selected; while E R D <strong><u>A</u></strong> means that the selected frames represent all Angular Views for a specific  Energy Window, a specific Detector and a specific Rotation</em> </p> <p>(2) The Connectathon Monitor <strong>will ask the Image Display to demonstrate</strong> that:</p> <ul>   <li>E12: its Grid Display  contains a single frameset arranged  in a 2D grid of frames </li>   <li>E13: the Wholebody display contains, simultaneously,  both the anterior and posterior frames of an NM whole body image.  (Note: These images will typically be  rectangular in shape (taller than wide) and are typically 256 x 1024 or 512 x  1024 in size. The display system should display them as rectangular frames (and  not pad them to make them square.)<br>   </li> </ul> <p><strong><u>CINE</u></strong><br>   (3) The Connectathon Monitor will <strong>ask the Image Display to demonstrate</strong> that:</p> <ul>   <li>E14: for Cine display, displays a cine of the  selected frames as indicated by the order they are stored in the Image.</li>   <li>E15: for Cine display, when the framesets have the  same number of frames, displays the cines in synchronization (i.e. the first  frame of each frameset should display simultaneously, the second frame of each  frameset should display simultaneously, etc.). </li>   <li>E16: for Cine display, enables the use to adjust  intensity for each frameset independently</li>   <li>E17: provides direct control over the Upper Window  Level and the Lower Window Level display parameters independently from each  other for both grayscale and pseudocolor display . This control shall be  available for all frames as a group and for each frameset individually.  Optionally is it also useful to support adjustment of individual frames. </li>   <li>E18: enables users effectively invert the image (in  the sense of switching between a MONOCHROME1 and MONOCHROME2 interpretation);  for grayscale image display only.<br>   </li> </ul> <p><br>     <strong><u>INTENSITY and COLOR</u></strong><br>   (4) The Connectathon Monitor <strong>will ask the Image Display to demonstrate</strong> that:</p> <ul>   <li>E19: if it supports a color screen, it displays  frames of grayscale images using a pseudo-color lookup table. </li>   <li>E20: if it supports a color screen, it allows the  user to select from a configured set of pseudo-color lookup tables.</li>   <li>E21: if it supports a color screen, it provides a  method of adding new pseudo-color lookup tables. (This may be an administrative  function.)<br>       <br>   </li> </ul> <p><strong><u>IMAGE  ZOOM</u></strong><br>   (5) The Connectathon Monitor <strong>will ask the Image Display to demonstrate</strong> that:</p> <ul>   <li>E22: the user can zoom the frames where zooming  consists of resampling and displaying the frame at a larger or smaller matrix  size. For example, re-sample a 128x128 frame to create a 256x256 frame.</li>   <li>E23: zooming the image preserves the aspect ratio  (that is, the same zoom factor is applied in both the x and y dimensions).</li> </ul> <p><strong><u>RESULT  SCREENS<br>         <em><br>       </em></u></strong><em>(Display of Result Screens is  tested in test </em>NMI_EC_Result_Screen_Option<em>.)</em> </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (416, 1, 0, '2009-11-24 10:53:17.079', 'epoiseau', '<H3>Special Instructions</H3> This should only be run by Modality or Image Manager actors who are not participating in one of the workflow profiles (eg. Scheduled Workflow or Stress).  If the Modality or IM is participating in one of these profiles, it should run test SWF_Modality_IM_Interface or STRESS_Modality_IM_Interface instead of this one.  (MPPS is not required in the NMI profile, so it is not exercised in this test.) <H3>Description</H3> The Modality and Image Manager test their interfaces for these actions: <ul> <li>[RAD-8]: C-STORE <li>[RAD-10]: Storage Commitment </ul> <H3>Evaluation</H3> On the Image Manager verify: <ul> <li>E66: All images were successfully stored. <li>E67: Storage Commitment was successful (N-EVENT-REPORT was sent) . </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (417, 1, 0, '2009-11-24 10:53:17.081', 'epoiseau', '<p>The NMI_PACS_Display test is used to determine if Image Display actors can query for and display appropriate attributes from the Query SCP and to retrieve images and make certain that no information has been omitted. If a Modality and Image Display want to use a specific PACS for this test and NMI_Mod_Display, these tests can be run simultaneously. <ol>  <li>Image Display should query for and display these attributes: Series Description.</li> </ol> </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (418, 1, 0, '2009-11-24 10:53:17.084', 'epoiseau', '<H3>Special Instructions</H3> <p>The NMI_Worklist test exercises some of the Worklist scenarios described in IHE-Rad TF: App E. Some of the test cases are covered in other Modality/RIS tests and need not be covered again here.</p>  <p>This test mentions an Order Filler actor, but this is not required of Order Fillers. The Acquisition Modality should find an Order Filler that is willing to assist or use the RIS Mall to Order/Schedule the appropriate procedure.</p>  <H3>Description</H3> <p>The Order Filler should schedule the procedures as described below and the modality will perform the defined steps. For evaluation, the Project Manager should examine MPPS logs on the Order Filler for evidence the steps were completed. Project Manager will examine GUI on Acquisition Modality to see if worklist entries look reasonable.</p>  <p>To aid in connectathon testing, recommendations are provided for which images to use for subsequent testing.  Minor changes may be made to this, depending on what images are actually available for use at time of testing.    In addition to below, selected images will be used for testing of required R and R+ tags.</p>  <p>LUNG: multiple STATIC images in separate series, hopefully 8+ images in at least 2 series, use for testing of fit display.</p>  <p>BONE: WHOLEBODY exam with anterior and posterior views in same image, use for testing of display of wholebody images, for display of image labels,  and for testing of NM-style windowing.</p>  <p>RENAL: Two phase DYNAMIC in single image, use for testing of selection of part of a study (by phase), and subsequent display of each part both as grid display and cine.</p>  <p>RVG: three GATED images, likely 64x64, use for display of multiple cines at same time, and for testing of appropriate choice of default zoom of images at time of display</p>  <p>PERFUSIONTOM: Rest and stress images. There should be two SPS. Use to test cardiac tags both before and after reconstruction.</p>  <p>PERFUSIONGATED: Two image sets, rest and stress, though it is likely only the stress will be  gated;  use for testing of output of dynamic result screens (Multi-frame SC) from evidence creator, and for testing of display of these Multi-frame SC images on image display.</p>  <p>PERFUSIONRECON: Two image sets, rest and stress, use for testing of creation of color an grayscale static result screens (SC) from evidence creator, for testing of applying pseudocolor maps to grayscale SC images on image displays, for testing of NM style windowing of SC images (presuming windowing of SC images is allowed on display as recommended), and for testing of comparison display using two short axis datasets.  Also use recon tomo data for testing the use of cardiac tags by evidence creators, possibly by having variations of the data set with altered tags that should change the processing result.</p>  <p>BONERECON: RECON TOMO (SPECT) exam, used for testing MPR, (optional under basic NM display, required under review option.</p>  <H3>Evaluation</H3> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (419, 1, 0, '2009-11-24 10:53:17.086', 'epoiseau', 'Several patients are admitted/registered and then Order Placers and Order Fillers exchange order and status information. If your system is not an ADT, please find a friendly ADT to admit/register the patient');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (420, 1, 0, '2009-11-24 10:53:17.088', 'epoiseau', '<H3>Description</H3> This test tries to exercises the different options of the PAM profile. Please perform the options that are relevant for the systems under test.  Please note that Kudu is not performing the matching of peers according to the options supported by the systems. This is somethings you have to figure out by discussing with your peers. <p> For this test the two peers need to share a common Patient! This may be performed one way or the other : RIS MALL might be used, or if systems are also implementing the actors PDS and PDC, then these actors could be used to perform the sharing of the common Patient.  </p> <H3>Evaluation</H3> Evaluation should check <ul> <li>Validity of the HL7 messages : correct trigger, correct version. </li> <li>Functional validation : does the target perform the expected action</li> </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (421, 1, 0, '2009-11-24 10:53:17.09', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This tests the transactions required by both Patient Encounter Suppliers and Consumers in the    PAM profile. The various options in the profile are tested in    <b>PAM_Adv_Encounter_Management.</b> </p> <p>At the beginning of this test, the Patient Encounter Supplier should admit the following    patients using <b>ADT^A01^ADT_A01</b>. Note that the patient''s first name is the kudu system name (or    vendor name) of the receiving system, the Patient Encounter Consumer:</p> <ol>     <li>Pampatientone^PEC-kudu-system-name</li>     <li>Pampatienttwo^PEC-kudu-system-name</li>     <li>Pampatientthree^PEC-kudu-system-name</li>     <li>Pamdischarged^PEC-kudu-system-name</li>     <li>Pammerge^PEC-kudu-system-name</li> </ol> </p><H3>Description</H3><p>This tests the exchange of messages between Patient Encounter Suppliers and Patient Encounter    Consumers for the following events: </p><ul>     <li>Admit inpatient, and cancel admit</li>     <li>Register outpatient</li>     <li>Discharge patient, and cancel discharge</li>     <li>Update patient information</li>     <li>Merge patient identifier list</li> </ul><p>Support for messaging associated with these events is required by the PAM profile.</p><H3>Evaluation</H3><p>The PEC is required to ACK all messages received from the PES.</p><p>On the <strong>Patient Encounter Consumer</strong>, the Connectathon monitor will verify that    the messages were received and the patient''s status has been updated on the PEC system:</p><ul>     <li>Pampatienttwo is not an inpatient (his admission was cancelled</li>     <li>Pampatientthree is an inpatient (his discharge was cancelled)</li>     <li>Pamdischarged is discharged or has status "visit ended"</li>    <li>Pampatientmerge is the subsumed patient from the merge.</li>    <li>Pampatientone''s birthdate is 1911-11-11.</li> <li>Pampatientone  is the surviving patient from the merge </li>      </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (422, 1, 0, '2009-11-24 10:53:17.091', 'epoiseau', '<H3>Special Instructions</H3><p> <p> PDC and PDS actors which support the <b>Merge option</b> run this test. If your system    supports the Link/Unlink option, run test PAM_ID_Mgmt_Link.</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> <ol>     <li>The letters Pamö</li>     <li>3-5 letters that distinquish your company/system</li> </ol> <p>In the test instructions, names will look like this:    <center>Pamö<b>system^</b>letters</center> where <b>system</b> marks your system. </p> </p><H3>Description</H3><p>This test is based on the use case defined in the PAM profile. </p><ol>     <li> Create Patient: Pamö<b>system</b>. The Patient Demographics Supplier creates a new patient      Pamö<b>system</b>^Ab. Fill in DOB, Sex and other demographics as if this was a known patient.     Patient Demographics Supplier sends A28 message to Patient Demographics Consumer to inform consumer of     patient information. </li>     <li>Patient Ab now changes first name to ''Cd''. Patient Demographics Supplier sends A31 message to     indicate new patient name: Pamö<b>system</b>. At this point, Patient Demographics Consumer should     provide a screen capture or database dump in the logs to indicate it now has the updated name in     its local database. The Connectathon Monitor will review later.</li>     <li>A new, but unknown, patient is now entered in the Patient Demographics Supplier system. Patient     Demographics Supplier should create the patient Pam<b>system</b>^Ef as a new patient with limited     demographics. Patient Demographics Supplier sends A28 message to Patient Demographics Consumer to inform     consumer of patient information. Patient Demographics Consumer should perform a screen capture or     database dump to indicate it now has Pam<b>system</b>^Ef entered in its system.</li>     <li>Patient Demographics Supplier now understands that Ef is the same as Cd. Patient Demographics Supplier     sends A40 merge message to Patient Demographics Consumer. The surviving patient in the database     should be Pamö<b>system</b>^Cd. Patient Demographics Consumer should perform a screen capture or     database dump that indicates Pam<b>system</b>^Ef is no longer active/available (depends on your     implementation). </li>     <li>Bonus points that will not be graded. If you can somehow demonstrate clinical records that     existed under the individual records for Cd and Ef that are now merged under Cd, that is the     intent of the A40 merge operation. This will not be evaluated by the Connectathon monitor.</li> </ol><H3>Evaluation</H3><p> The Connectathon monitor will ask the Patient Demographics Consumer to show database dumps or    screen captures that show the state of the system at three different points in time: <ol>      <li>After the demographic update to change the name from Ab to Cd.</li>      <li>After sending the demographic for the (unknown) Ef.</li>      <li>After the merge of Ef and Cd (with Cd surviving). Ef should no longer be visible.</li>.    </ol> If the Patient Identity Consumer cannot show this with screen captures or log information,    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 (423, 1, 0, '2009-11-24 10:53:17.094', 'epoiseau', '<H3>Special Instructions</H3><p> <p> PDC and PDS actors which support the <b>Link/Unlink option</b> run this test. If your system    supports the Merge option, run test PAM_ID_Mgmt (or PAM_ID_Mgmt_Europe at the European connectathon).</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 2 components (with no separators):</p> <ol>     <li>The letters Pamlink</li>     <li>3-5 letters that distinquish your company/system</li> </ol> <p>In the test instructions, names will look like this:     <center>Pamlink<b>system^</b>letters</center> where <b>system</b> marks your system. </p> </p><H3>Description</H3><p>This test is based on the use case defined in the PAM profile. </p><ol>     <li> Create Patient: Pamlink<b>system</b>. The Patient Demographics Supplier creates a new patient      Pamlink<b>system</b>^Ab. Fill in DOB, Sex and other demographics as if this was a known patient.     Patient Demographics Supplier sends A28 message to Patient Demographics Consumer to inform consumer of     patient information. </li>     <li>Patient Ab now changes first name to ''Cd''. Patient Demographics Supplier sends A31 message to     indicate new patient name: Pamlink<b>system</b>. At this point, Patient Demographics Consumer should     provide a screen capture or database dump in the logs to indicate it now has the updated name in     its local database. The Connectathon Monitor will review later.</li>     <li>A new, but unknown, patient is now entered in the Patient Demographics Supplier system. Patient     Demographics Supplier should create the patient Pamlink<b>system</b>^Ef as a new patient with limited     demographics. Patient Demographics Supplier sends A28 message to Patient Demographics Consumer to     inform consumer of patient information. Patient Demographics Consumer should perform a screen     capture or database dump to indicate it now has Pamlink<b>system</b>^Ef entered in its system.</li>     <li>Patient Demographics Supplier now understands that Ef is the same as Cd. Patient Demographics     Source sends A24 Link message to Patient Demographics Consumer. According ITI TF-2:3.30.6.1.1, linking two or more patients does not     require the actual merging of patient information; following a link event, the affected patient data records should remain distinct.     The PDC system should be able to demonstrate that  both patients Pamlink<b>system</b>^Cd and  Pamlink<b>system</b>^Cd exist     as distinct records in its system;  perform a screen     capture or database dump that indicates both patient ^Cd and ^Ef exist as linked records in the PDC system.     (depends on your implementation). </li>     <li>Bonus points that will not be graded. If you can somehow demonstrate clinical records that     existed under the individual records for Cd and Ef that are now linked to Cd. This will not be evaluated by the Connectathon monitor.</li> </ol><H3>Evaluation</H3><p> The Connectathon monitor will ask the Patient Demographics Consumer to show database dumps or    screen captures that show the state of the system at three different points in time: <ol>      <li>After the demographic update to change the name from Ab to Cd.</li>      <li>After sending the demographic for the (unknown) Ef.</li>      <li>After the Link of Ef and Cd, the records of both Cd and Ef are still visible (ie one of these is not subsumed).  How the link is manifested on the PDC is not defined by tthe Technical Framework.</li>.    </ol> If the Patient Identity Consumer cannot show this with screen captures or log information,    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 (424, 1, 0, '2009-11-24 10:53:17.096', 'epoiseau', '<H3>Special Instructions</H3><p> <p> PDC and PDS actors which support the <b>Merge option</b> run this test. If your system    supports the Link/Unlink option, run test PAM_ID_Mgmt_Link.</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 2 components (with no separators):</p> <ol>     <li>The letters Pam</li>     <li>3-5 letters that distinquish your company/system</li> </ol> <p>In the test instructions, names will look like this:     <center>Pam<b>system^</b>letters</center> where <b>system</b> marks your system. </p> </p><H3>Description</H3><p>This test is based on the use case defined in the PAM profile. </p><ol>     <li> Create Patient: Pam<b>system</b>. The Patient Demographics Supplier creates a new patient      Pam<b>system</b>^Ab. Fill in DOB, Sex and other demographics as if this was a known patient.     Patient Demographics Supplier sends A28 message to Patient Demographics Consumer to inform consumer of     patient information. </li>     <li>Patient Ab now changes first name to ''Cd''. Patient Demographics Supplier sends A31 message to     indicate new patient name: Pam<b>system</b>. At this point, Patient Demographics Consumer should     provide a screen capture or database dump in the logs to indicate it now has the updated name in     its local database. The Connectathon Monitor will review later.</li>     <li>A new, but unknown, patient is now entered in the Patient Demographics Supplier system. Patient     Demographics Supplier should create the patient Pam<b>system</b>^Ef as a new patient with limited     demographics. Patient Demographics Supplier sends A28 message to Patient Demographics Consumer to inform     consumer of patient information. Patient Demographics Consumer should perform a screen capture or     database dump to indicate it now has Pam<b>system</b>^Ef entered in its system.</li>     <li>Patient Demographics Supplier now understands that Ef is the same as Cd. Patient Demographics Supplier     sends A40 merge message to Patient Demographics Consumer. The surviving patient in the database     should be Pam<b>system</b>^Cd. Patient Demographics Consumer should perform a screen capture or     database dump that indicates Pam<b>system</b>^Ef is no longer active/available (depends on your     implementation). </li>     <li>Bonus points that will not be graded: If you can somehow demonstrate clinical records that     existed under the individual records for Cd and Ef that are now merged under Cd, that is the     intent of the A40 merge operation. This will not be evaluated by the Connectathon monitor.</li> </ol><H3>Evaluation</H3><p> The Connectathon monitor will ask the Patient Demographics Consumer to show database dumps or    screen captures that show the state of the system at three different points in time: <ol>      <li>After the demographic update to change the name from Ab to Cd.</li>      <li>After sending the demographic for the (unknown) Ef.</li>      <li>After the merge of Ef and Cd (with Cd surviving). Ef should no longer be visible.</li>.    </ol> If the Patient Identity Consumer cannot show this with screen captures or log information,    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 (425, 1, 0, '2009-11-24 10:53:17.099', 'epoiseau', '<H3>Special Instructions</H3> <p>None</p>  <H3>Description</H3> <p>The goal of the Print calibration tests is to demonstrate that printed output conforms to the GSDF.  Although the participant may use whatever procedure is appropriate to their product for calibrating the output, the project managers will evaluate whether or not the output conforms to the GSDF by following the procedure outlined in  section 2 of the document <i>Test Plan for Print Servers</i>.</p>  <p>You will need to bring: <ol> <li> the means for calibrating the printer output,</li> <li> Densitometer,</li> <li> test cases, (available from web site),</li> <li> the means to send the test cases to the Print Server,</li> <li>  <em>gsdf_lum.xls</em>, (Excel spreadsheet, available from web site),</li> <li> the means to run macros in spreadsheet (Windows 98/NT/2000/XP),</li> <li> light box (dual unit or two single units)</li> </ol>  </p>  <p>Please first calibrate the printer to the GSDF, and then proceed as described in the above mentioned document to print the test cases, make the measurments, enter the measurements into the Excel spreadsheet, and give a copy of the test results to the project manager. </p> <p> It is recommended that participants calibrate their displays on the first day of the connectathon.  Although the evaluation will be done after the ''starting bell'' of the connectathon, participants can do their initial calibration during system setup. </p>  <H3>Evaluation</H3> <p>The project manager will review the printed test cases and the output from the Excel spreadsheet, and may spot check the densitometer measurements.  The participant system passes if each individual measurement point as well as the average fall within 20% of the desired GSDF curve, as calculated by the spreadsheet, and if there are no visible artifacts in the printed images.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (426, 1, 0, '2009-11-24 10:53:17.101', 'epoiseau', '<H2>Creating a patient for PCD Connectathon Tests</H2>  <p> PCD Systems require only a minimal set of parameters. KUDU requires information not needed by PCD systems as of 2009, and does not include some information that PCD requires. The data required by PCD are generated as follows: </p>  <p> Sending System: Company Name and System Identifier (an abbreviation of KUDU assignment) if the company has more than one system in the Connectathon. </p> <p> Medical Record Numbers (MRNs):  <ul> <li> Namespace ID: Two letters that identify the company followed by the year (always 2009 for the systems listed for the 2009 NA Connectathon), three digits to accommodate different patients for the same company with multiple systems. </li> <li> Local ID: The same as namespace ID with the addition of the letter ''L'' in front. </li></ul> </p> <p> First and Last Names:  <ul> <li> Last name is a combination of the company name and a few letters relating to the KUDU system identifier. This permits companies to have patients for multiple systems. </li> <li> Select from the patient list to match the desired location. Two patients are available at each location. </li> <li> Additional patients can be added if needed following the pattern established here. </li></ul> </p> <p> Date of Birth: January 1, 1961 for the first patient for any system. Additional patients are on the first of succeeding months.</p> <p> Location: Unless otherwise assigned, one of the following related to the Sending System: </p> <ul> <li> Initials identifying the company followed by ''Surgery, OR-1''</li> <li> Initials identifying the company followed by ''Surgery, OR-2''</li> <li> Initials identifying the company followed by ''3 West ICU, 10-1''</li> <li> Initials identifying the company followed by ''3 West ICU, 10-2''</li> <li> Initials identifying the company followed by ''4 East ICU, 03-1''</li> <li> Initials identifying the company followed by ''4 East ICU, 04-2''</li> </ul> <p><strong>When companies have multiple systems, locations are further distinguished by adding -x to the company initials. x is a letter distinguishing each system.</strong></p> <p></p> <p> Mother''s Maiden Name, Height and Weight: As provided in the table on the ftp site, but not provided by the ADT system. </p> <p> Physical home address: Required by the ADT system, not used by PCD.</p> <p> The Patient Demographics table for companies and systems in the 2009 North American Connectathon is found at <strong>ftp://ftp.ihe.net/Patient_Care_Devices/Connectathons/PatientDemographics/ <strong></p> <p> Follow the pattern found in the spreadsheet to add companies and systems. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (427, 1, 0, '2009-11-24 10:53:17.103', 'epoiseau', '<h2>Special Instructions</h2>
 <p>The PDI media creation tests are supervised by an assigned Connectathon Monitor.  On Monday of the connectathon, a monitor will visit you and ask you to create a PDI CD.
 </p>
 <p>If you support either <strong>Privacy Protection Using PBE </strong>or <strong>Privacy Protection using PKI</strong>, you <em><u>should not protect</u></em> this piece of test media, if possible. You will create another DVD in the <strong>PDI_Privacy_Protection_*</strong> test.   </p>
 <h2>Description</h2>
 <p>The PDICreateCD test allows a Portable Media Creator to create a CD on demand.</p>
 <p> The goal of the test is for the Project Manager to <em>witness</em> the creation of the CD. </p>
 <ul>
 <li> Cennectathon Monitor will provide a CD to the system under test.</li>
 <li>The Project Manager will mark the CD (Sharpie or other marker) and observe the CD writing process. </li>
 <li>The Media Creator may automatically write a paper label over the mark made by the Project Manager.</li>
 </ul>
 <p>If you support the <strong>Sending Software option</strong>, that should be included on the media.</p>
 <p>If you support the <strong>Basic Viewer option</strong>, that should be included on the media.   </p>
 <h2>Evaluation</h2>
 <p>For evaluation, the Connectathon Monitor will 
 <ul>
 <li>take the CD to <em>media reader</em> actors and ask them to read the CD and perform appropriate functions.</li>
 
 <li>check that there is no autorun file on the CD. The TF framework mention that  Media Creator should avoid using automatic launching. If there is such a file the test is not failed but the Connectathon Monitor warns about the risk of the auto run </li>
 </ul>
 </p>
 <p>Functionality of the <b>Sending Software</b> or <b>Basic Viewer</b>, if included, is evaluated in another test.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (428, 1, 0, '2009-11-24 10:53:17.105', 'epoiseau', '<H3>Special Instructions</H3> <p>None.</p>  <H3>Description</H3> <p>The PDIDisplayImages test requires an Image Display (Radiology) Actor to read and display the image content of a CD created by a Portable Media Creator :  access imaging evidence objects (images, Presentation States, Key Image Notes, Evidence Documents) reading interchange media and allow the user to view these objects.</p>  <H3>Evaluation</H3> <p> The Project Manager will hand the CD to the Image Display Actor and expect the system to display the content (see above) at that time. The Portable Media Creator representative should observe the display to help with questions about the intention of the images.</p> <p> If the Image Display Actor is unable to display the content, the Project Manager will retrieve the disk and ask the two systems to create a duplicate disk for further testing.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (429, 1, 0, '2009-11-24 10:53:17.107', 'epoiseau', '<h3>Special Instructions</H3> <p>Portable Media Creators that do not record  Reports on the media, should not take part in this test. </p>  <H3>Description</H3> <p>The PDIDisplayReports test requires a Report Reader Actor to read and display the report content of a CD created by a Portable Media Creator. The Project Manager will hand the CD to the Report Reader Actor and expect the system to display the content at that time. The Portable Media Creator representative should observe the display to help with questions about the intention of the reports.</p>  <H3>Evaluation</H3> <p>For evaluation, the Project Manager will take CDs produced in the test PDICreateCD and ask the Report Reader Actor to read the CD and display the DICOM Structured Reports. If the Report Reader Actor is unable to display the report content, the Project Manager will retrieve the disk and ask the two systems to create a duplicate disk for further testing.</p>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (430, 1, 0, '2009-11-24 10:53:17.109', 'epoiseau', '<H3>Special Instructions</H3> None. <H3>Description</H3> <p>The PDIDisplayWeb test requires a Display (ITI) Actor to read and display the web content of a CD created by a Portable Media Creator. The Project Manager will hand the CD to the Display Actor and expect the system to display the web content at that time. The Portable Media Creator representative should observe the display to help with questions about the intention of the web pages.</p>  <H3>Evaluation</H3> <p> For evaluation, the Project Manager will take CDs produced in the test PDICreateCD and ask the Display Actor to read the CD and display the Web Content. If the Display Actor is unable to display the web content, the Project Manager will retrieve the disk and ask the two systems to create a duplicate disk for further testing. </p> <p> The Display should view the "web-viewable" diagnostic and therapeutic imaging information on interchange media.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (431, 1, 0, '2009-11-24 10:53:17.11', 'epoiseau', '<H3>Special Instructions</H3>
 <p>None.</p>
 
 <H3>Description</H3>
 <p>The PDIMediaImport test requires a Portable Media Importer Actor to read a CD created by a Portable Media Creator and to import the DICOM composite objects on the CD. The Connectathon Monitor will hand the CD to the Media Importer Actor and expect the system to import the content at that time. 
 </p>
 
 <H3>Evaluation</H3>
 <p>
 For evaluation, the Connectathon Monitor will take CDs produced in the test PDICreateCD and ask the Portable Media Importer Actor to read the CD. If the Portable Media Importer Actor is unable to import the correct data, the Connectathon Monitor will retrieve the disk and ask the two systems to create a duplicate disk for further testing. </p>
 <p>The Media Importer should show evidence that the system has modified attributes as appropriate to import data into the system.
 </p>
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (432, 1, 0, '2009-11-24 10:53:17.112', 'epoiseau', '<H3>Special Instructions</H3> <p>None.</p>  <H3>Description</H3> <p> The PDIPrintImages test requires a Print Composer Actor to read a CD created by a Portable Media Creator and to print the images to a Print Server actor. The Project Manager will hand the CD to the Print Composer Actor and expect the system to print the content at that time. The Portable Media Creator representative should observe the films to help with questions about the intention of the images.</p> <H3>Evaluation</H3> For evaluation, the Project Manager will take CDs produced in the test PDICreateCD and ask the Print Composer Actor to read the CD. If the Print Composer Actor is unable to print the correct images, the Project Manager will retrieve the disk and ask the two systems to create a duplicate disk for further testing. ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (433, 1, 0, '2009-11-24 10:53:17.114', 'epoiseau', 'empty description in Kudu');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (434, 1, 0, '2009-11-24 10:53:17.116', 'epoiseau', '<h3>Special Instructions</H3> <H1> <i>DO test ATNA_Authentication_HL7_V2 instead.  Do not do this test!</i></H1>  This test is only for PDQ implementations that also support ATNA.  <H3>Description</H3> Repeat the PDQ_Exact_Name or other PDQ test using ATNA TLS communication and logging. <H3>Evaluation</H3> The Connectathon monitor will observe log or real time information indicating that TLS communication was used and that appropriate ATNA logging was completed. This is vague on purpose; a better description would list the log messages that are expected. ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (435, 1, 0, '2009-11-24 10:53:17.118', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p>  <H3>Description</H3> <p>The PDQ_Continuation_Test is for the implementation of continuation pointers in query responses. Patient Demographic Consumers are not required by the TF to support this feature, so Supplier systems will need to seek a partner.  Consumers are encouraged to help. </p> <p> This test is applicable to HL7 v2.5 systems.  The Patient Demographic Supplier should load enough patients that could result in query matches and make use of the continuation protocol. You may have to use your imagination here as the normal test data is for very few patients.</p>  <p>Patient Demographic Consumers may have to perform some configuration to use a lower number of accepted records to assist the Demographic Supplier in using the continuation protocol.</p>  <p>The PDQ Consumer may be an <b>Importer</b> actor in the IRWF profile.</p>  <H3>Evaluation</H3> <p>Show the Connectathon monitor evidence that the Demographics Consumer is configured to limit the number of responses, thus forcing continuation.  The Demographics Supplier must also demonstrate its ability to limit the number of query responses to the value sent in RPC-2 of the query message. </p> The Connectathon monitor should observe the query in real time and see two items (if possible): <ul> <li>Log information at the consumer or supplier indicating the continuatioin protocol </li> <li>Behavior at the client that indicates continuation. </li> </ul> </p>  <p>Both of the items requested may be difficult to obtain; these depend on the implementations.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (436, 1, 0, '2009-11-24 10:53:17.12', 'epoiseau', '<H3>Special Instructions</H3>
 Only PDQ Patient Demographics Supplier (PDS) and Patient Demographics Consumer (PDC) actors which support the <i>Patient Demographics & Visit Query option</i> will run this test.
 
 <h3>Description</h3>
 This tests the interaction between the PDS and PDC actors for the QBP^ZV1 query and RSP^ZV2 response messages.
 <p>
 Patient demographics fields for query (from the PID segment) are tested in the PIX_CLIENT test.  The visit fields (from the PV1 segment) are tested in this test.  PDS and PDC actors may support one or more of the fields listed in the Evaluation section; neither actor is required to support all.  PDS and PDC partners need to speak to each other to discover which fields are supported in common.  (It may be difficult to find partners to exercise all of the fields your application supports.)</p>
 <p>Once common fields are discovered, ensure that the PDS contains records that will show that the query results distinguish between different patient records.</p>
 <H3>Evaluation</H3>
 Verify that the <b>Patient Demographics Supplier</b> is able to issue queries based on filters specified by the Patient Demographics Consumer in the fields listed below.  
 <p>Verify that the <b>Patient Demographics Supplier</b> supports responding to queries based on filters specified by the Patient Demographics Consumer in the following fields.  
 </p>
 <p>
 Note that the PDC and PDS are only required to support one or more of these (not all), but they should test as many of them as their application supports:
 <ul>
 <li>PV1.2 - Patient Class</li>
 <li>PV1.3 - Assigned Patient Location</li>
 <li>PV1.7 - Attending Doctor</li>
 <li>PV1.8 - Referring Doctor</li>
 <li>PV1.9 - Consulting Doctor</li>
 <li>PV1.10 - Hospital Service</li>
 <li>PV1.17 - Admitting Doctor</li>
 <li>PV1.19 - Visit Number</li>
 </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (437, 1, 0, '2009-11-24 10:53:17.122', 'epoiseau', '<H3>Special Instructions</H3><p>
 <p>Patient Demographics Suppliers must run test PDQ_Load before this can be run.</p>
 <p>Run this test and then immediately follow with PDQ_Multiple_Query with the same partner.</p>
 <p>The test is designed to return one result for one patient. Depending on the search engine, you
    might get multiple patients.</p>
 <p>
 <b>NOTE:</b>
 </p>
 <ul>
    
 <li>
 <strong>Different IHE profiles treat the HL7 assigning authority (PID 3.4)   differently. The Assigning Authority has 3 subcomponents</strong>
 </li>
    
 <ol>
     
 <li>Namespace ID (text string)   </li>
     
 <li>Universal ID (OID)   </li>
     
 <li>Universal ID type (the string <strong>ISO</strong> when you use an OID) </li>
    
 </ol>
    
 <li>
 <strong>PDQ Requirements for Connectathon</strong>
 </li>
     
 <ol>
      
 <li>Patient Demographics Consumer</li>
      
 <ul>
       
 <li>If you specify a value in QPD-8, only component 4 (Assigning Authority)   shall be valued (ITI TF-2: 3.21.4.1.2.2.2).   </li>
       
 <li>If you specify a value in QPD-8, we recommend you provide all three   components of the Assigning Authority: Namespace ID, Universal ID, Universal ID   Type. </li>
      
 </ul>
      
 <li>Patient Demographics Supplier</li>
      
 <ul>
       
 <li>The TF is silent on how to format PID 3.4.   </li>
       
 <li>For the Connectathon, we will require all three components: Namespace ID,   Universal ID, Universal ID type </li>
      
 </ul>
     
 </ol>
     
 </ul>
 </p><H3>Description</H3><p>The <b>PDQ_Exact_Name</b>  test allows a PDQ Consumer actor to make a query of a PDQ Supplier using a
    search by exact name. Each consumer will make one query of a supplier.</p>
 <p>This test uses a single, known domain that is specified by the Connectathon affinity domain. The value that should be used as the Assigning Authority is the "master" OID identified in the table in the <b>PDQ_Load</b> test.<p>
 <p>The Patient Demographics Consumer shall be able to support at least one of the following
    mechanisms for specifying QPD-8 (What Domains Returned):</p><ul>
    
 <li>Transmit an empty value and receive all identifiers in all domains known by the Patient
     Demographics Supplier (one or more domains), or</li>
    
 <li>Transmit a single value and receive zero or more identifiers in a single domain, or</li>
    
 <li>Transmit multiple values and receive mutiple identifiers in those multiple domains.</li>
 </ul><p>The purpose of this test is to establish that one query is operational.</p><H3>Evaluation</H3><p>Connectathon monitor should observe query in real time and evaluate response.</p><p>The semantics of the PDQ query are not defined by the Technical Framework. Some systems may
    return more than one record for this query. The purpose of the evaluation is to determine if a
    response is returned and if the behavior is reasonable.</p><p>For example, if the supplier always returns the entire database for any name search, that would
    not be a reasonable implementation. That would fail this test.</p><p>Notes on use of QDP-8 (What Domains Returned) - Ref ITI TF-2:3.21.4.1.2.2.2</p><ul>
    
 <li>If QPD-8 is empty, the Patient Demographics Supplier shall return all Patient IDs known by
     the Patient Demographics Supplier for each patient that matches the search criteria.</li>
    
 <li>If QPD-8 is specified and the domains are recognized,the Patient Demographics Supplier shall
     return the Patient IDs for each patient that matches the search criteria. </li>
    
 <li>Any domain not recognized by the Patient Demographics Supplier is an error condition. </li>
 </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (438, 1, 0, '2009-11-24 10:53:17.125', 'epoiseau', '<H3>Special Instructions</H3><p>
 <p>PDQ Suppliers run one instance of this test. If you can load these patients into your system
    prior to arriving at the Connectathon, you will be ahead of the game.</p>
 </p>
 <H3>Description</H3>
 <p>The purpose of the PDQLoad test is for each PDQ Supplier actor to load the information
    describing each patient in the test system .</p>
 <p>To support XDS tests,  load patient demographics provided in advance by the Connectathon Project Manager. These
    demographics include one ''well-known'' patient, FARNSWORTH^STEVE. It also includes one patient for
    each XDS Document Source at the connectathon. These patients have a
    last name matching the Source''s kudu system name, and a woman''s first name, eg. patient
    "Ehrxyzmedical^Mary". These demographics should be provided to you in a spreadsheet.</p>
 <p>To support PDQ profile tests, load the demographics listed in the table below. Also, load one additional record that uses the
    Kudu system name of the Patient Demographics Supplier as the patient name. This will be used in
    later queries. These patients are used for both the HL7 v2.5 and v3 tests.</p>
 <p>The PDQ Supplier can use the HIMSS Patient Registration tool to load these patients; locate these patient in the tool and have it send you A04 messages. Or, load this by hand.</p><p>
    <b>These are the patients to load for the North American connectathon:</b>
 </p><table border="1" cellpadding="0" cellspacing="0" bordercolor="#333333">
    
 <tr>
     
 <th>Name</th>
     <th> ID</th>
     <th>DOB</th>
     <th>SSN (if applicable)</th>
     <th>Address</th>
    
 </tr>
    
 <tr>
     
 <td>MOORE^CHIP</td>
     <td>PDQ113XX01^^^IHENA&1.3.6.1.4.1.21367.2009.1.2.300&ISO^PI</td>
     <td>19380224</td>
     <td></td>
     <td>10 PINETREE^^WEBSTER^MO^63119</td>
    
 </tr>
    
 <tr>
 <td>MOORE^RALPH</td><td>PDQ113XX02^^^IHENA&1.3.6.1.4.1.21367.2009.1.2.300&ISO^PI</td><td>19510707</td>><td></td>
     <td>510 S KINGSHIGHWAY^^ST. LOUIS^MO^63110</td>
 </tr>
    
 <tr>
 <td>MOHR^ALICE</td><td>PDQ113XX03^^^IHENA&1.3.6.1.4.1.21367.2009.1.2.300&ISO^PI</td><td>19580131</td>><td></td><td>
      820 JORIE BLVD.^^OAK BROOK^IL^60523</td>
 </tr>
    
 <tr>
 <td>MOODY^WARREN</td><td>
      PDQ113XX04^^^IHENA&1.3.6.1.4.1.21367.2009.1.2.300&ISO^PI</td><td>19780820</td>><td></td><td>1000
      CLAYTON RD^^CLAYTON^MO^63105</td>
 </tr>
    
 <tr>
 <td>MOONEY^STAN</td><td>PDQ113XX05^^^IHENA&1.3.6.1.4.1.21367.2009.1.2.300&ISO^PI</td><td>19780920</td>><td></td><td>
      100 TAYLOR^^ST LOUIS^MO^63110</td>
 </tr>
    
 <tr>
 <td>FARNSWORTH^STEVE</td><td>101^^^IHENA&1.3.6.1.4.1.21367.2009.1.2.300&ISO^PI</td><td>19781208</td>><td>163-12-5432
      </td><td>820 JORIE BLVD^^CHICAGO^IL^60523</td>
 </tr>
    
 <tr>
 <td>Your-Kudu-System-Name^JAY</td><td>make-a-patient-ID-value^^^IHENA&1.3.6.1.4.1.21367.2009.1.2.300&ISO^PI</td><td>19240202</td>><td>343-12-2216
      </td><td>111 MICHIGAN AVE. ^CHICAGO^IL^60501</td>
 </tr>
 </table>
 <b>These are the patients to load for the European connectathon:</b>
 </p><table border="1" cellpadding="0" cellspacing="0" bordercolor="#333333" bgcolor="#E0DFE3">
    
 <tr>
 <td width="115" valign="top" bordercolor="#0000FF" bgcolor="#99CCFF">
 <p>Name</p>
 </td>
     <td width="204" valign="top" bordercolor="#0000FF" bgcolor="#99CCFF">
 <p>ID</p>
 </td>
     <td width="90" valign="top" bordercolor="#0000FF" bgcolor="#99CCFF">
 <p>DOB</p>
 </td>
     <td width="42" valign="top" bordercolor="#0000FF" bgcolor="#99CCFF">
 <p>Sex</p>
 </td>
     <td width="312" valign="top" bordercolor="#0000FF" bgcolor="#99CCFF">
 <p>Address </p>
 </td>
 </tr>
    
 <tr>
 <td width="115" valign="top" bordercolor="#333333">
 <p>MOORE^CHIP</p>
 </td>
     <td width="204" valign="top" bordercolor="#333333">
 <p>PDQ113XX01^^^&1.3.6.1.4.1.21367.2009.2.2.700&ISO</p>
 </td>
     <td width="90" valign="top" bordercolor="#333333">
 <p>19380224</p>
 </td>
     <td width="42" valign="top" bordercolor="#333333">
 <p>M</p>
 </td>
     <td width="312" valign="top" bordercolor="#333333">
 <p>10 PINETREE^^WEBSTER^MO^63119 </p>
 </td>
 </tr>
    
 <tr>
     
 <td width="115" valign="top" bordercolor="#333333">
      
 <p>MOORE^RALPH</p>
     
 </td>
     <td width="204" valign="top" bordercolor="#333333">
      
 <p>PDQ113XX02^^^VIENNA&1.3.6.1.4.1.21367.2009.2.2.700&ISO^PI</p>
     
 </td>
     <td width="90" valign="top" bordercolor="#333333">
      
 <p>19480724</p>
     
 </td>
     <td width="42" valign="top" bordercolor="#333333">
      
 <p>M</p>
     
 </td>
     <td width="312" valign="top" bordercolor="#333333">
      
 <p>510 S KINGSHIGHWAY^^ST. LOUIS^MO^63110 </p>
     
 </td>
    
 </tr>
    
 <tr>
     
 <td width="115" valign="top" bordercolor="#333333">
      
 <p>MOHR^ALICE</p>
     
 </td>
     <td width="204" valign="top" bordercolor="#333333">
      
 <p>PDQ113XX03^^^VIENNA&1.3.6.1.4.1.21367.2009.2.2.700&ISO^PI</p>
     
 </td>
     <td width="90" valign="top" bordercolor="#333333">
      
 <p>19580131</p>
     
 </td>
     <td width="42" valign="top" bordercolor="#333333">
      
 <p>F</p>
     
 </td>
     <td width="312" valign="top" bordercolor="#333333">
      
 <p>820 JORIE BLVD.^^OAK BROOK^IL^60523 </p>
     
 </td>
    
 </tr>
    
 <tr>
     
 <td width="115" valign="top" bordercolor="#333333">
      
 <p>MOODY^WARREN</p>
     
 </td>
     <td width="204" valign="top" bordercolor="#333333">
      
 <p>PDQ113XX04^^^VIENNA&1.3.6.1.4.1.21367.2009.2.2.700&ISO^PI 19780820</p>
     
 </td>
     <td width="90" valign="top" bordercolor="#333333">
      
 <p> 
 </p>
     
 </td>
     <td width="42" valign="top" bordercolor="#333333">
      
 <p>M</p>
     
 </td>
     <td width="312" valign="top" bordercolor="#333333">
      
 <p>1000 CLAYTON RD^^CLAYTON^MO^63105</p>
     
 </td>
    
 </tr>
    
 <tr>
     
 <td width="115" valign="top" bordercolor="#333333">
      
 <p>MOONEY^STAN</p>
     
 </td>
     <td width="204" valign="top" bordercolor="#333333">
      
 <p>PDQ113XX05^^^VIENNA&1.3.6.1.4.1.21367.2009.2.2.700&ISO^PI</p>
     
 </td>
     <td width="90" valign="top" bordercolor="#333333">
      
 <p>19780920</p>
     
 </td>
     <td width="42" valign="top" bordercolor="#333333">
      
 <p>M</p>
     
 </td>
     <td width="312" valign="top" bordercolor="#333333">
      
 <p>100 TAYLOR^^ST LOUIS^MO^63110</p>
     
 </td>
    
 </tr>
    
 <tr>
     
 <td width="115" valign="top" bordercolor="#333333">
      
 <p>FERGUSON^CHIP</p>
     
 </td>
     <td width="204" valign="top" bordercolor="#333333">
      
 <p>PDQ113XX13^^^VIENNA&1.3.6.1.4.1.21367.2009.2.2.700&ISO^PI</p>
     
 </td>
     <td width="90" valign="top" bordercolor="#333333">
      
 <p>19930914</p>
     
 </td>
     <td width="42" valign="top" bordercolor="#333333">
      
 <p>M</p>
     
 </td>
     <td width="312" valign="top" bordercolor="#333333">
      
 <p>4970 OAKLAND^^ST LOUIS^MO^63110</p>
     
 </td>
    
 </tr>
    
 <tr>
     
 <td width="115" valign="top" bordercolor="#333333">
      
 <p>RENDEL^GRACE</p>
     
 </td>
     <td width="204" valign="top" bordercolor="#333333">
      
 <p>PDQ113XX12^^^VIENNA&1.3.6.1.4.1.21367.2009.2.2.700&ISO^PI</p>
     
 </td>
     <td width="90" valign="top" bordercolor="#333333">
      
 <p>19720814</p>
     
 </td>
     <td width="42" valign="top" bordercolor="#333333">
      
 <p>F</p>
     
 </td>
     <td width="312" valign="top" bordercolor="#333333">
      
 <p>200 BEMISTON^^CLAYTON^MO^63105</p>
     
 </td>
    
 </tr>
    
 <tr>
     
 <td width="115" valign="top" bordercolor="#333333">
      
 <p>SANDERS^CHIP</p>
     
 </td>
     <td width="204" valign="top" bordercolor="#333333">
      
 <p>PDQ113XX11^^^VIENNA&1.3.6.1.4.1.21367.2009.2.2.700&ISO^PI</p>
     
 </td>
     <td width="90" valign="top" bordercolor="#333333">
      
 <p>19420224</p>
     
 </td>
     <td width="42" valign="top" bordercolor="#333333">
      
 <p>M</p>
     
 </td>
     <td width="312" valign="top" bordercolor="#333333">
      
 <p>100 EUCLID^^WEBSTER^MO^63119</p>
     
 </td>
    
 </tr>
    
 <tr>
     
 <td width="115" valign="top" bordercolor="#333333">
      
 <p>Your-Kudu-System-Name^JAY</p>
     
 </td>
     <td width="204" valign="top" bordercolor="#333333">
      
 <p>make-a-patient-ID-value^^^VIENNA&1.3.6.1.4.1.21367.2009.2.2.700&ISO^PI</p>
     
 </td>
     <td width="90" valign="top" bordercolor="#333333">
      
 <p>19420202</p>
     
 </td>
     <td width="42" valign="top" bordercolor="#333333">
 <p>M</p>
 </td>
     <td width="312" valign="top" bordercolor="#333333">
 <p>111 MICHIGAN AVE. ^CHICAGO^IL^60501</p>
 </td>
    
 </tr>
 </table><p>
    
 <H3>Evaluation</H3><p>Connectathon monitor will accept the word of the operator that data are loaded. If data are not
    loaded, no subsequent tests will work.</p>
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (439, 1, 0, '2009-11-24 10:53:17.128', 'epoiseau', '<H3>Special Instructions</H3> None.  <H3>Description</H3> <p>The PDQ_Multiple_Query test requires PDQ Consumers to send different types of queries to a PDQ Supplier. Some PDQ Consumers may not have user interfaces that support all of the intended queries.</p> <p>The PDQ Consumer may be an <b>Importer</b> actor in the IRWF profile.</p>  <p>Each query is made assuming a single domain that can be left unspecified in QDP-8 (What Domains Returned). The syntax of wild card queries is not specified by the IHE Technical Framework. There may be some negotiation between Consumer and Supplier actors.</p>  <H3>Evaluation</H3> <p>Connectathon monitor should observe all queries in real  time and evaluate response. PDQ Consumer should demonstrate configuration/logs  indicating the PDQ Supplier that is queried.<br>   PDQ Supplier does not need to demonstrate any results  unless there are problems. In that case, access to logs would be helpful.<br>   The PDQ Supplier is required to support queries containing  the fields listed below.  <b>Not all Consumers will support all queries. </b>Evaluate as many query combinations as are supported  by the Consumer.</p> <ul>   <li>PID.3  Patient  Identifier List</li>   <li>PID.5  Patient  Name</li>   <li>PID.7.1  Date/Time  of Birth</li>   <li>PID.8  Administrative  Sex</li>   <li>PID.11            Patient  Address</li>   <li>PID.18            Patient  Account Number</li> </ul> <p>The PDQ Supplier is required to support at least all exact  matches to the query parameters sent by the Consumer.  The Technical Framework does not further  specify matching requirements (eg wildcards, upper & lower case, alternate  spellings...)  <br>   The Connectathon Monitor may ask to see a copy of the  QBP^Q22 query message to check values in the following fields:</p> <ul>   <li>MSH-9            "QBP^Q22"</li>   <li>QPD-1             "IHE  PDQ Query"</li>   <li>QPD-3             <em>This field contains the query paramaters.</em></li>   <li>QDP-8             <em>If specified, only component 4 (Assigning  Authority) has a value.</em></li>   <li>RPC-1             "I" <em>To request an immediate reponse.</em></li>   <li>RPC-2             <em>Note: This field, Quantity Limited Request,  is tested in PDQ_Continuation_Test.  A  value such as "25^RD" requests 25 records at a time be returned from the PDQ  Supplier.</em></li> </ul> <p>The Connectathon Monitor may ask to see a copy of the  RSP^K22 query message to check values in the following fields:</p> <ul>    <li>MSH-3            <em>This field (Sending Application) contains  the value received from the PDQ Consumer in MSH-5 (Receiving Application)</em></li>   <li>MSH-9            "RSP^K22"</li>   <li>QAK-2             "OK" <em>if data is returned</em></li>   <li>QDP                <em>Fields in this segment are the same as those  received in the query.</em></li>   <li>PID                 PID.3  and PID.5 <em>(Patient ID and Name) are  required.  The Supplier must also return  fields for which it has values</em></li> </ul>   <p><b>We especially want to see the query result that uses the Kudu name of the demographics supplier. This will help to show the monitor you are sending a query to the proper system.</b></p>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (440, 1, 0, '2009-11-24 10:53:17.13', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Patient Demographics Suppliers which support the Pediatric Demographics Option must run this ''test'' which ensure    the proper pediatric demographics are in its system in order to run subsequent tests on the    Pediatric Demographics option. Ideally, this would happen before arriving at the Connectathon.    For the NA2009 Connectathon, they are located here:    http://ihewiki.wustl.edu/wiki/images/d/d3/Connectathon_TwinUseCases.xls</p> <p>PIX Managers must run this test before running test <i>PIX_PDO_Query</i>.</p> </p><H3>Description</H3><p>This test is used to populate the PDQ Supplier with demographics of "twins". The data is a    actual data with last names changed.</p><p></p><H3>Evaluation</H3><p>There is no formal evaluation for this test. If the set-up in this test is not done, subsequent    PDQ_PDO tests will not work.</p><p>The Connectathon monitor will mark this test as verified when you say it is complete.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (441, 1, 0, '2009-11-24 10:53:17.133', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Patient Demographics Consumers and Suppliers which support the Pediatric Demographics option    run this test.</p> <p>Test <i>PDQ_PDO_Load</i>, which loads the PDS with twin demographics, must be run by the    Patient Demographics Supplier before this test can be run. For the NA2009 Connectathon, the    spreadsheet containing this twin demographics data is located here:    http://ihewiki.wustl.edu/wiki/images/d/d3/Connectathon_TwinUseCases.xls</p> </p><H3>Description</H3><p>This tests the Patient Demographics Consumer actor''s ability to provide Pediatric Demographics    as query parameters and to be able to receive and process Pediatric Demographics Fields. Patient    Demographics Supplier actors must able to match on Pediatric fields supplied as a query key, and    return Pediatric Demographics in the query response(s).</p><p>Pediatric Demographics are identified as:</p><ul>     <li>Mother''s Maiden Name (query parameter)</li>     <li>Patient Home Telephone (query parameter)</li>     <li>Patient Multiple Birth Indicator</li>     <li>Patient Birth Order</li>     <li>Last Update Date/Time</li>     <li>Last Update Facililty</li> </ul><H3>Evaluation</H3><p>The Connectathon monitor should access the spreadsheet of twin test data that was loaded by the    PDS system prior to the connectathon. For the NA2009 Connectathon, it is located here:    http://ihewiki.wustl.edu/wiki/images/d/d3/Connectathon_TwinUseCases.xls</p><p>The Connectathon monitor will visit the <strong>Patient Demographics Consumer</strong> and will    ask to see, real-time, a subset (or all) of the queries in the test steps.</p><p>The PDC system must demonstrate that it can include patient telephone number and mother''s    maiden name as a query parameter to the PDS. If it cannot, the PDC does not pass the test.</p><p>In preparation for this test, the PDS has been loaded with values for each of these fields for    all patients in this test. Each query response returned by the PDS must contain values for all of    these fields, or it does not pass the test.</p><ul>     <li>PID.3 Patient Identifier List (including PID.3.1 ID and PID.3.4 assigning authority)</li>     <li>PID.5 Patient Name</li>     <li>PID.6 Mother''s Maiden Name</li>     <li>PID.7 Date/Time of Birth</li>     <li>PID.8 Administrative Sex</li>     <li>PID.11 Patient Address</li>     <li>PID.13 Home Phone Number</li>     <li>PID.24 Multiple Birth Indicator</li>     <li>PID.25 Birth Order</li>     <li>PID.33 Last Update Date/Time</li>     <li>PID.34 Last Update Facility</li> </ul><p>Note that the Patient Demographics Option does not specify that the PDC system display all of    these attributes, but since the intent is that these fields are used (by a human or a computer)    to identify twins, these fields should accessible/useable for that purpose on the PDC    application.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (442, 1, 0, '2009-11-24 10:53:17.135', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p> </p> <H3>Description</H3> <p>PDQv3_Continuation_Test  is for the  implementation of HL7 Continuation Protocol '' General Query Activate Query Continue (QUQI_IN000003UV01) by the PDQ  Consumer and the Patient Registry Find Candidates Query Response message (PRPA_IN201306UV02) by the PDQ Supplier.  Patient Demographic Consumers are not required by the TF to support this feature, so Supplier systems will need to seek a  partner.  Consumers are encouraged to  help.</p> <p>The Patient Demographic Supplier should load enough  patients that could result in query matches and make use of the continuation  protocol. You may have to use your imagination here as the normal test data is for very few patients.</p> <p>Patient Demographic Consumers may have to perform some  configuration to use a lower number of accepted records to assist the  Demographic Supplier in using the continuation protocol.</p> <H3>Evaluation</H3> <p>Show the Connectathon monitor evidence that the  Demographics Consumer is configured to limit the number of responses, thus  forcing continuation.  The Demographics  Supplier must also demonstrate its ability to limit the number of query  responses to the value sent in attribute continuationQuantity attribute.</p> <p>The Connectathon monitor should observe the query in real  time and see two items (if possible):</p> <ul>     <li>Log information at the consumer or supplier indicating  the continuation protocol</li>     <li>Behavior at the client that indicates  continuation.</li> </ul> <p>Both of the items requested may be difficult to obtain;  these depend on the implementations.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (443, 1, 0, '2009-11-24 10:53:17.137', 'epoiseau', '<H3>Special Instructions</H3><p>
 <p>Patient Demographics Suppliers must run test PDQ_Load before this can be run.</p>
 <p>Run this test and then immediately follow with PDQv3_Multiple_Query with the same partner.</p>
 <p>The test is designed to return one result for one patient. Depending on the search engine, you might get multiple patients.</p>
 </p>
 <H3>Description</H3>
 <p>The PDQv3_Exact_Name test allows a PDQ Consumer actor to make a query of a PDQ Supplier using a search by exact name. Each consumer will make one query of a supplier.</p>
 <p>This test uses a single, known domain that is specified by the HIMSS affinity domain. This value should be used as the Assigning Authority: VIENNA&1.3.6.1.4.1.21367.2009.1.2.700 &ISO.</p>
 <p>The Patient Demographics Consumer shall be able to support at least one of the following mechanisms for selecting the Paitne Identity Domain from which patient identifiers are returned: </p>
 <ul>
      
 <li>Transmit an empty value in the DataSource.value attribute and receive all identifiers in all domains known by the Patient Demographics Supplier (one or more domains), or</li>
      
 <li>Transmit a single value in DataSource.value and receive zero or more identifiers in a single domain, or</li>
      
 <li>Transmit multiple DataSource parameters, one for each domain for which it wishes to receive identifiers, and receive mutiple identifiers in those multiple domains.</li>
      
 </ul><p>The purpose of this test is to establish that one query is operational.</p>
 <H3>Evaluation</H3><p>Connectathon monitor should observe query in real time and evaluate response.</p>
 <p>The semantics of the PDQ query are not defined by the Technical Framework. Some systems may return more than one record for this query. The purpose of the evaluation is to determine if a response is returned and if the behavior is reasonable.</p>
 <p>For example, if the supplier always returns the entire database for any name search, that would not be a reasonable implementation. That would fail this test.</p>
 <p>Notes on use of DataSource parameter in the query</p><ul>
    
 <li>If DataSource.value is empty, the Patient Demographics Supplier shall return all Patient IDs known by the Patient Demographics Supplier for each patient that matches the search criteria.</li>
    
 <li>If one or more DataSource parameter is specified and the domains are recognized,the Patient Demographics Supplier shall return the Patient IDs for each patient that matches the search criteria. </li>
    
 <li>Any domain not recognized by the Patient Demographics Supplier is an error condition. </li>
    
 </ul>
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (444, 1, 0, '2009-11-24 10:53:17.139', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p> </p> <H3>Description</H3> <p>The PDQv3_Multiple_Query test requires PDQ Consumers to send different types of queries to a PDQ Supplier. Some PDQ Consumers may not have user interfaces that support all of the intended queries.</p> <p>Each query (Using the HL7v3 Patient Registry Find Candidates Query) is made assuming a single domain Assigning Authority that can be specified with an empty value in the DataSource.value attribute. The syntax of wild card queries is not specified by the IHE Technical Framework. There may be some negotiation between Consumer and Supplier actors.</p> <H3>Evaluation</H3> <p>Connectathon monitor should observe all queries in real  time and evaluate response. PDQ Consumer should demonstrate configuration/logs  indicating the PDQ Supplier that is queried.</p> <p> PDQ Supplier does not need to demonstrate any results  unless there are problems. In that case, access to logs would be helpful.</p> <p>The PDQ Supplier is required to support queries with the  attributes listed below.  Not all  Consumers will support all queries. Evaluate as many query combinations as are  supported by the Consumer.</p> <ul>     <li> <em>LivingSubjectId</em> </li>     <li> <em>LivingSubjectName</em> </li>     <li> <em>LivingSubjectBirthTime</em> </li>     <li> <em>LivingSubjectAdministrativeGender</em> </li>     <li> <em>Patient.Address</em> </li>     <li> <em>OtherIDsScopingOrganization (ie the Assigning Authority)</em> </li> </ul><p>The PDQ Supplier is required to support at least all exact  matches to the query parameters sent by the Consumer.  The Technical Framework does not further  specify matching requirements (eg wildcards, upper and lower case, alternate  spellings'')  </p><p> <strong>We especially  want to see the query result that uses the Kudu name of the demographics  supplier. This will help to show the monitor you are sending a query to the  proper system.</strong>  </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (445, 1, 0, '2009-11-24 10:53:17.141', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Patient Demographics Consumers and Suppliers which support the Pediatric Demographics option    run this test.</p> <p>Test <i>PDQ_PDO_Load</i>, which loads the PDS with twin demographics, must be run by the    Patient Demographics Supplier before this test can be run. For the NA2009 Connectathon, the    spreadsheet containing this twin demographics data is located here:    http://ihewiki.wustl.edu/wiki/images/d/d3/Connectathon_TwinUseCases.xls</p> </p><H3>Description</H3><p>This tests the Patient Demographics Consumer actor''s ability to provide Pediatric Demographics    as query parameters and to be able to receive and process Pediatric Demographics Fields. Patient    Demographics Supplier actors must able to match on Pediatric fields supplied as a query key, and    return Pediatric Demographics in the query response(s).</p><p>For PDQv3, Pediatric Demographics are identified as:</p><ul>     <li>MothersMaidenName (query parameter)</li>     <li>PatientTelecom (query parameter)</li> </ul><H3>Evaluation</H3><p>The Connectathon monitor should access the spreadsheet of twin test data that was loaded by the    PDS system prior to the connectathon. For the NA2009 Connectathon, it is located here:    http://ihewiki.wustl.edu/wiki/images/d/d3/Connectathon_TwinUseCases.xls</p><p>The Connectathon monitor will visit the <strong>Patient Demographics Consumer</strong> and will    ask to see, real-time, a subset (or all) of the queries in the test steps.</p><p>The PDC system must demonstrate that it can include patient telephone number and mother''s    maiden name as a query parameter to the PDS. If it cannot, the PDC does not pass the test.</p><p>In preparation for this test, the PDS has been loaded with values for each of these fields for    all patients in this test. Each query response returned by the PDS must contain values for all of    these fields, or it does not pass the test.</p><ul>     <li>LivingSubjectID (ie patient ID)</li>     <li>LivingSubjectName (ie patient name)</li>     <li>MothersMaidenName</li>     <li>LivingSubjectBirthTime</li>     <li>LivingSubjectAdministrativeGender</li>     <li>PatientAddress</li>     <li>PatientTelecom</li> </ul><p>Note that the Patient Demographics Option does not specify that the PDC system display all of    these attributes, but since the intent is that the fields MothersMaidenName and PatientTelecom are used (by a human or a computer)    to identify twins, these fields should accessible/useable for that purpose on the PDC    application.</p> ');
